On Fri, 26 Sep 2014 09:17:36 +0200
Martin Kosek <mko...@redhat.com> wrote:

> On 09/25/2014 05:35 PM, Traiano Welcome wrote:
> > Hi Martin
> >
> > On Wed, Sep 24, 2014 at 2:18 PM, Martin Kosek <mko...@redhat.com
> > <mailto:mko...@redhat.com>> wrote:
> >
> >     On 09/24/2014 01:06 PM, Traiano Welcome wrote:
> >      > Hi List
> >      >
> >      > I'm currently running IPA 3.3 on Centos 7, and successfully
> >      > authenticating Linux clients (Centos 6.5).
> >      >
> >      > I'd like to setup Solaris 10 as an IPA client, but this seems
> >      > problematic. I am following this guide:
> >      >
> >      >
> >     
> > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10
> >      >
> >      > I have the following setup:
> >      >
> >      > Solaris client:
> >      >
> >      > - Solaris 10u11 (SunOS  5.10 Generic_147148-26 i86pc i386
> >      > i86pc)
> >      >
> >      > IdM Server:
> >      >
> >      > - Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1
> >      > SMP Mon Jun 30 12:09:22 UTC 2014 x86_64 x86_64 x86_64
> >      > GNU/Linux
> >      >
> >      >
> >      >
> >      > Going through the steps in the guide: at step 3 ("Create the
> >      > cn=proxyagent account"), ldapadd fails with the following
> >      > error:
> >      >
> >      >
> >      >
> >      > "ldapadd: invalid format (line 6) entry:
> >      > "cn=proxyagent,ou=profile,dc=orion,dc=local""
> >      >
> >      > ---
> >      >
> >      > [root@kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D
> >      > "cn=directory manager" -w Cr4ckM0nk3y
> >      > dn: cn=proxyagent,ou=profile,dc=orion,dc=local
> >      > objectClass: top
> >      > objectClass: person
> >      > sn: proxyagent
> >      > cn: proxyagent
> >      > userPassword::
> >      > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ=
> >      >
> >      > ldapadd: invalid format (line 6) entry:
> >      > "cn=proxyagent,ou=profile,dc=orion,dc=local"
> >      > ---
> >      >
> >      > I've made the assumption that  the extra ":" is a typo in
> >      > the documentation and removed it, so the command runs
> >      > successfully as follows:
> >      >
> >      >
> >      > ---
> >      > [root@kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D
> >      > "cn=directory manager" -w Cr4ckM0nk3y
> >      >
> >      > dn: cn=proxyagent,ou=profile,dc=orion,dc=local
> >      > objectClass: top
> >      > objectClass: person
> >      > sn: proxyagent
> >      > cn: proxyagent
> >      > userPassword:
> >      > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ=
> >      > adding new entry "cn=proxyagent,ou=profile,dc=orion,dc=local"
> >      > ---
> >      >
> >      >
> >      > At step 9 (Configure NFS ), I get an error, seems to
> >      > indicate the "des-cbc-crc" encryption type is unsupported:
> >      >
> >      > ---
> >      > [root@kwtpocipa001 ~]# ipa-getkeytab -s
> >      > kwtpocipa001.orion.local -p
> >      > nfs/kwtpocipasol10u11.orion.local
> >      > -k /tmp/kwtpocipasol10u11.keytab -e des-cbc-crc Operation
> >      > failed! All enctypes provided are unsupported
> >      > [root@kwtpocipa001 ~]# ---
> >      >
> >      > (Question: How would I add support for des-cbc-crc
> >      > encryption  in freeipa?). I've now worked around this by not
> >      > specifying any encryption type:
> >      >
> >      > ---
> >      > [root@kwtpocipa001 ~]# ipa-getkeytab -s
> >      > kwtpocipa001.orion.local -p
> >      > nfs/kwtpocipasol10u11.orion.local
> >      > -k /tmp/kwtpocipasol10u11.keytab Keytab successfully
> >      > retrieved and stored in: /tmp/kwtpocipasol10u11.keytab
> >      > [root@kwtpocipa001 ~]# ---
> >      >
> >      > Testing that I can see nfs mounts on the centos IPA server
> >      > from the solaris machine:
> >      >
> >      > ---
> >      > bash-3.2# showmount -e kwtpocipa001.orion.local
> >      > export list for kwtpocipa001.orion.local:
> >      > /data/centos-repo 172.16.0.0/24 <http://172.16.0.0/24>
> >      > bash-3.2#
> >      > ----
> >      >
> >      >
> >      > Checking we can kinit:
> >      >
> >      > ---
> >      > bash-3.2#
> >      > bash-3.2# kinit admin
> >      > Password for admin@ORION.LOCAL:
> >      > bash-3.2#
> >      > bash-3.2#
> >      > bash-3.2# klist
> >      > Ticket cache: FILE:/tmp/krb5cc_0
> >      > Default principal: admin@ORION.LOCAL
> >      > Valid starting                Expires                Service
> >      > principal 09/24/14 11:20:36  09/24/14 12:20:36
> >      > krbtgt/ORION.LOCAL@ORION.LOCAL renew until 10/01/14 11:20:36
> >      > bash-3.2#
> >      > bash-3.2#
> >      > bash-3.2#
> >      > bash-3.2# uname -a
> >      > SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386
> >      > i86pc bash-3.2#
> >      > ---
> >      >
> >      > Testing I can mount the remote FS (without Kerberos auth).
> >      > This is successful (when not using kerberos5 authentication):
> >      >
> >      > ---
> >      > bash-3.2# mount -F nfs
> >      > 172.16.107.102:/data/centos-repo /remote/ bash-3.2# mount
> >      > |grep remote /remote on 172.16.107.102:/data/centos-repo
> >      > remote/read/write/setuid/devices/rstchown/xattr/dev=4f0000a
> >      > on Wed Sep 24 13:45:32 2014
> >      > bash-3.2#
> >      > ---
> >      >
> >      > Testing with KRB5:
> >      >
> >      > ---
> >      > bash-3.2# mount -F nfs -o sec=krb5
> >      > 172.16.107.102:/data/centos-repo /remote/ nfs mount:
> >      > mount: /remote: Permission denied bash-3.2#
> >      > ---
> >      >
> >      > Looking at the krbkdc logs on the IPA master server, I get
> >      > the following error:
> >      >
> >      > ---
> >      > Sep 24 13:48:17 kwtpocipa001.orion.local
> >      > krb5kdc[2371](info): AS_REQ (6 etypes {18 17 16 23 3 1})
> >      > 172.16.107.107 <http://172.16.107.107>:
> >     NEEDED_PREAUTH:
> >      > host/kwtpocipasol10u11.orion.local@ORION.LOCAL for
> >      > krbtgt/ORION.LOCAL@ORION.LOCAL, Additional
> >      > pre-authentication required Sep 24 13:48:17
> >      > kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH:
> >      > repeated (retransmitted?) request from 172.16.107.107,
> >      > resending previous response Sep 24 13:48:17
> >      > kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH:
> >      > repeated (retransmitted?) request from 172.16.107.107,
> >      > resending previous response .
> >      > .
> >      > .
> >      > Sep 24 13:48:18 kwtpocipa001.orion.local
> >      > krb5kdc[2373](info): AS_REQ (6 etypes {18 17 16 23 3 1})
> >      > 172.16.107.107 <http://172.16.107.107>:
> >     CLIENT_NOT_FOUND:
> >      > root/kwtpocipasol10u11.orion.local@ORION.LOCAL for
> >      > krbtgt/ORION.LOCAL@ORION.LOCAL, Client not found in Kerberos
> >      > database
> >      >
> >      > ---
> >      >
> >      > So it seems the host is not correctly registered.
> >      >
> >      > NOTE: Via the interface ,I can see the solaris client is
> >      > not properly enrolled (" Kerberos Key Not Present"), however
> >      > the documentation doesn't seem to indicate clearly how this
> >      > should be done for a Solaris client. I have regenerated the
> >      > certificate though, so it shows "valid certificate present".
> >      >
> >      > My question is: Is the process described in this guide still
> >      > correct/functional for integrating Solaris 10 clients?
> >      > If so, is there some way I could debug further to pinpoint
> >      > why the solaris client is not being registered in the
> >      > Kerberos DB?
> >      >
> >      > Many thanks in advance!
> >      > Traiano
> >
> >     Hello Traiano,
> >
> >     This part of the documentation is wrong, as reported by
> > ldapadd, userpassword is not correct.
> >
> >     If you specify the entry with clear text password, it would
> > work. I.e.:
> >
> >     dn: cn=proxyagent,ou=profile,dc=orion,dc=local
> >     objectClass: top
> >     objectClass: person
> >     sn: proxyagent
> >     cn: proxyagent
> >     userPassword: agentpassword
> >
> >     Note that Solaris related documentation is (unfortunately)
> > known to be off: https://fedorahosted.org/freeipa/ticket/3731
> >
> >     Also please note that the guide you are referring to is also
> > pretty old (from Fedora 18 times) and not updated. There is a
> > related thread:
> >
> >     
> > https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html
> >
> > Indeed. There are some minor errata as well like the use of the
> > "-t" flag with Solaris' version of the mount command:
> > bash-3.2# mount -t nfs -o sec=krb5
> > 172.16.107.102:/data/centos-repo /remote/ mount: illegal option -- t
> >   "-F" works.
> > I've adjusted the steps I've used to include the changes you
> > mentioned in https://fedorahosted.org/freeipa/ticket/3731, attached
> > is a step  by step listing of the process with my output up to step
> > 9, where mounting NFS fails. Hopefully by a process of iteration I
> > can document the updated process for configuring Solaris 10 clients.
> 
> Thank you, that helps - I would hand over the updated steps to
> downstream RHEL guide maintainer.
> 
> > Here is what I'm seeing at step 9 (referencing the old Fedora 18
> > docs with adjusted steps)L
> > h) Mount the NFS share. [FAILS]
> > ---
> > bash-3.2# mount -F nfs -o sec=krb5
> > 172.16.107.102:/data/centos-repo /remote/ nfs mount:
> > mount: /remote: Permission denied bash-3.2#
> > ---
> > /var/log/krbkdc.Log entries:
> > ---
> > krb5kdc: Cannot determine realm for numeric host address - unable
> > to find realm of host
> > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info):
> > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107
> > <http://172.16.107.107>: LOOKING_UP_SERVER: authtime 0,
> > admin@ORION.LOCAL <mailto:admin@ORION.LOCAL> for <unknown server>,
> > Server not found in Kerberos database
> > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info):
> > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107
> > <http://172.16.107.107>: LOOKING_UP_SERVER: authtime 0,
> > admin@ORION.LOCAL <mailto:admin@ORION.LOCAL> for <unknown server>,
> > Server not found in Kerberos database
> > krb5kdc: Cannot determine realm for numeric host address - unable
> > to find realm of host
> > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info):
> > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107
> > <http://172.16.107.107>: LOOKING_UP_SERVER: authtime 0,
> > admin@ORION.LOCAL <mailto:admin@ORION.LOCAL> for <unknown server>,
> > Server not found in Kerberos database
> > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info):
> > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107
> > <http://172.16.107.107>: LOOKING_UP_SERVER: authtime 0,
> > admin@ORION.LOCAL <mailto:admin@ORION.LOCAL> for <unknown server>,
> > Server not found in Kerberos database
> > krb5kdc: Cannot determine realm for numeric host address - unable
> > to find realm of host
> > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info):
> > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107
> > <http://172.16.107.107>: LOOKING_UP_SERVER: authtime 0,
> > admin@ORION.LOCAL <mailto:admin@ORION.LOCAL> for <unknown server>,
> > Server not found in Kerberos database
> > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info):
> > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107
> > <http://172.16.107.107>: LOOKING_UP_SERVER: authtime 0,
> > admin@ORION.LOCAL <mailto:admin@ORION.LOCAL> for <unknown server>,
> > Server not found in Kerberos database
> > ---
> >
> > However DNS forward and reverse records DO seem to resolve:
> > ---
> > [root@kwtpocipa001 ~]# host 172.16.107.107
> > 107.107.16.172.in-addr.arpa domain name pointer
> > kwtpocipasol10u11.orion.local. [root@kwtpocipa001 ~]# host
> > kwtpocipasol10u11.orion.local kwtpocipasol10u11.orion.local has
> > address 172.16.107.107 ---
> 
> I assume this is being run from your IPA server - it looks OK.
> 
> >
> > And we can kinit and get a ticket:
> > ---
> > bash-3.2# kinit admin@ORION.LOCAL <mailto:admin@ORION.LOCAL>
> > Password for admin@ORION.LOCAL <mailto:admin@ORION.LOCAL>:
> > bash-3.2#
> > bash-3.2#
> > bash-3.2# klist
> > Ticket cache: FILE:/tmp/krb5cc_0
> > Default principal: admin@ORION.LOCAL <mailto:admin@ORION.LOCAL>
> > Valid starting                Expires                Service
> > principal 09/25/14 18:31:49  09/25/14 19:31:49
> > krbtgt/ORION.LOCAL@ORION.LOCAL
> > <mailto:krbtgt/ORION.LOCAL@ORION.LOCAL> renew until 10/02/14
> > 18:31:49 bash-3.2#
> > ---
> > Regards,
> > Traiano
> 
> Hmm, not sure what is the problem. Simo, do you know?

Use a fully qualified name of the nfs server on the mount command, not
an IP address.

> I would just make sure that /etc/krb5.keytab on the NFS server (klist
> -kt /etc/krb5.keytab) has keys for both NFS and host service and all
> use the right fully qualified hostname.

Yes, having a nfs/fqdn@REALM key on the client is recommended and
necessary in some cases.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to