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?
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.
Martin
--
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
