Andrey,
Thanks for the reply. I do see the ldap/station1.example.com ticket show up on the user end and I see the KDC issuing the ticket to the client, but I still get the SASL authentication failures. The one thing I see in the klist output is that the ldap ticket entry doesn't have the Kerberos REALM on it. Do you see that behavior as well in your implementation?
Client side:
[mcarey@station1 ~]$ kinit mcarey
Password for mcarey@xxxxxxxxxxxxxxxxxxxx:
[mcarey@station1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@xxxxxxxxxxxxxxxxxxxx
Valid starting Expires Service principal
10/04/10 12:35:49 10/04/10 19:15:49 krbtgt/STATION1.EXAMPLE.COM@xxxxxxxxxxxxxxxxxxxx
Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached
[mcarey@station1 ~]$ /usr/bin/ldap -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"
-bash: /usr/bin/ldap: No such file or directory
[mcarey@station1 ~]$ /usr/bin/ldapsearch -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
[mcarey@station1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@xxxxxxxxxxxxxxxxxxxx
Valid starting Expires Service principal
10/04/10 12:35:49 10/04/10 19:15:49 krbtgt/STATION1.EXAMPLE.COM@xxxxxxxxxxxxxxxxxxxx
Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
10/04/10 12:37:48 10/04/10 19:15:49 ldap/station1.example.com@
Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached
KDC/DS side:
# tail -n0 -f /var/log/krb5kdc.log
Oct 04 12:39:06 station1.example.com krb5kdc[7514](info): AS_REQ (7 etypes {16 1 11 10 15 12 13}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@xxxxxxxxxxxxxxxxxxxx for krbtgt/STATION1.EXAMPLE.COM@xxxxxxxxxxxxxxxxxxxx
Oct 04 12:39:55 station1.example.com krb5kdc[7514](info): TGS_REQ (2 etypes {16 1}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@xxxxxxxxxxxxxxxxxxxx for ldap/station1.example.com@xxxxxxxxxxxxxxxxxxxx
#
DS access log entries:
[04/Oct/2010:12:39:55 -0400] conn=8 fd=64 slot=64 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:12:39:55 -0400] conn=8 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[04/Oct/2010:12:39:55 -0400] conn=8 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:12:39:55 -0400] conn=8 op=-1 fd=64 closed - B1
--Matt
Thanks for the reply. I do see the ldap/station1.example.com ticket show up on the user end and I see the KDC issuing the ticket to the client, but I still get the SASL authentication failures. The one thing I see in the klist output is that the ldap ticket entry doesn't have the Kerberos REALM on it. Do you see that behavior as well in your implementation?
Client side:
[mcarey@station1 ~]$ kinit mcarey
Password for mcarey@xxxxxxxxxxxxxxxxxxxx:
[mcarey@station1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@xxxxxxxxxxxxxxxxxxxx
Valid starting Expires Service principal
10/04/10 12:35:49 10/04/10 19:15:49 krbtgt/STATION1.EXAMPLE.COM@xxxxxxxxxxxxxxxxxxxx
Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached
[mcarey@station1 ~]$ /usr/bin/ldap -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"
-bash: /usr/bin/ldap: No such file or directory
[mcarey@station1 ~]$ /usr/bin/ldapsearch -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
[mcarey@station1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@xxxxxxxxxxxxxxxxxxxx
Valid starting Expires Service principal
10/04/10 12:35:49 10/04/10 19:15:49 krbtgt/STATION1.EXAMPLE.COM@xxxxxxxxxxxxxxxxxxxx
Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
10/04/10 12:37:48 10/04/10 19:15:49 ldap/station1.example.com@
Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached
KDC/DS side:
# tail -n0 -f /var/log/krb5kdc.log
Oct 04 12:39:06 station1.example.com krb5kdc[7514](info): AS_REQ (7 etypes {16 1 11 10 15 12 13}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@xxxxxxxxxxxxxxxxxxxx for krbtgt/STATION1.EXAMPLE.COM@xxxxxxxxxxxxxxxxxxxx
Oct 04 12:39:55 station1.example.com krb5kdc[7514](info): TGS_REQ (2 etypes {16 1}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@xxxxxxxxxxxxxxxxxxxx for ldap/station1.example.com@xxxxxxxxxxxxxxxxxxxx
#
DS access log entries:
[04/Oct/2010:12:39:55 -0400] conn=8 fd=64 slot=64 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:12:39:55 -0400] conn=8 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[04/Oct/2010:12:39:55 -0400] conn=8 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:12:39:55 -0400] conn=8 op=-1 fd=64 closed - B1
--Matt
From: Andrey Ivanov <andrey.ivanov@xxxxxxxxxxxxxxxx>
To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Mon, October 4, 2010 12:30:43 PM
Subject: Re: [389-users] GSSAPI authentication to Directory Server
Hi,
Try
kinit username
<mdp>
klist -e
/usr/bin/ldapsearch -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"
klist -e
<you should see the additional ticket ldap/station1.example.com>
At least, that's how it works in our system
2010/10/4 Matt Carey <cvstealth2000@xxxxxxxxx>
I'm trying to follow the Kerberos howto guide at http://directory.fedoraproject.org/wiki/Howto:Kerberos but am having an issue authenticating to the Directory Server with GSSAPI/Kerberos tickets:
$ /usr/lib/mozldap/ldapsearch -h station1.example.com -p 389 -o mech=GSSAPI -o authid="mcarey@xxxxxxxxxxxxxxxxxxxx" -o authzid="mcarey@xxxxxxxxxxxxxxxxxxxx" -b "dc=example,dc=com" "(cn=*)"
Bind Error: Invalid credentials
Bind Error: additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
Attempt with OpenLDAP client:
$ /usr/bin/ldapsearch -Y GSSAPI -X u:mcarey -b "" -s base -LLL -H ldap://station1.example.com -b "dc=example,dc=com" "(cn=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
Resulting in the following entries in the access log on the DS:
# tail -5 access
[04/Oct/2010:10:44:14 -0400] conn=18 fd=68 slot=68 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:10:44:14 -0400] conn=18 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[04/Oct/2010:10:44:14 -0400] conn=18 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 UNBIND
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 fd=68 closed - U1
From what I can tell the Kerberos infrastructure and OS components are setup accordingly:
GSSAPI is a viable SASL mechanism:
$ /usr/lib/mozldap/ldapsearch -b "" -h station1 -p 389 -s base "(objectClass=*)" supportedSASLMechanisms
version: 1
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: PLAIN
Directory Server keytab and contents:
# grep "nsslapd-localuser" dse.ldif
nsslapd-localuser: nobody
# ls -la ds.keytab
-rw------- 1 nobody nobody 172 Oct 3 13:21 ds.keytab
# ktutil
ktutil: rkt ./ds.keytab
ktutil: l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 3 ldap/station1.example.com@STATION1.EXAMPLE.COM
2 3 ldap/station1.example.com@STATION1.EXAMPLE.COM
# grep KRB /etc/sysconfig/dirsrv
KRB5_KTNAME=/etc/dirsrv/ds.keytab ; export KRB5_KTNAME
SASL maps in Directory Server:
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)
dn: cn=Station1 Kerberos Mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Station1 Kerberos Mapping
nsSaslMapRegexString: (.*)@STATATION1.EXAMPLE.COM
nsSaslMapFilterTemplate: (objectclass=inetOrgPerson)
nsSaslMapBaseDNTemplate: uid=\1,ou=People,dc=example,dc=com
dn: cn=station1 map,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: example map
cn: station1 map
nsSaslMapRegexString: \(.*\)
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=\1)
Getting a ticket from the KDC:
[mcarey@station1 ~]$ kdestroy
[mcarey@station1 ~]$ kinit
Password for mcarey@xxxxxxxxxxxxxxxxxxxx:
[mcarey@station1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@xxxxxxxxxxxxxxxxxxxx
Valid starting Expires Service principal
10/04/10 10:57:20 10/04/10 17:37:20 krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM
Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached
Any help or pointers people have would be greatly appreciated.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
