[389-users] GSSAPI authentication to Directory Server

Andrey Ivanov andrey.ivanov at polytechnique.fr
Tue Oct 5 10:10:08 UTC 2010 

2010/10/4 Matt Carey <cvstealth2000 at yahoo.com>

> 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 at station1 ~]$ kinit mcarey
>
> Password for mcarey at STATION1.EXAMPLE.COM:
> [mcarey at station1 ~]$ klist -e
>
> Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
> Default principal: mcarey at STATION1.EXAMPLE.COM
>
> Valid starting     Expires            Service principal
> 10/04/10 12:35:49  10/04/10 19:15:49  krbtgt/STATION1.EXAMPLE.COM@
> 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
> [mcarey at 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 at 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 at station1 ~]$ klist -e
>
> Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
> Default principal: mcarey at STATION1.EXAMPLE.COM
>
> Valid starting     Expires            Service principal
> 10/04/10 12:35:49  10/04/10 19:15:49  krbtgt/STATION1.EXAMPLE.COM@
> STATION1.EXAMPLE.COM
>     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@
>
It's strange you dont' have the REALM part of
theldap/station1.example.comprincinpal... So it won't be mapped by
your "nsSaslMapRegexString: (.*)@STATATION1.EXAMPLE.COM".
<http://statation1.example.com/>Verify that the server will be able to
decrypt the data with its keytab :
kdestroy
kinit -k -t /etc/dirsrv/ds.keytab ' ldap/station1.example.com@
STATION1.EXAMPLE.COM <http://station1.example.com/>'
klist -e


I think you should also correct your mapping part. The default settings
should be ok. And if you make your own mapping  you should follow the same
syntax of the default entries, that is you should escape the parentheses \(,
it applies in particular to your "Station1 Kerberos Mapping" where
nsSaslMapRegexString should be like
\(.*\)@STATATION1.EXAMPLE.COM<http://statation1.example.com/>

If these verification are ok it means that either the server cannot
correctly read the keytab or you don't have a user with uid=mcarey in your
LDAP tree. To see more details in the access log you may switch on the
logging of internal server searches : add 4 to the current value of
nsslapd-accesslog-level attribute of cn=config, it should give something
like
nsslapd-accesslog-level: 260

With internal searches logging enable you will see what exactly and how the
server searches when it tries to map the principal to the entry

 @+


> 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 at STATION1.EXAMPLE.COM for krbtgt/
> STATION1.EXAMPLE.COM at STATION1.EXAMPLE.COM
> 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 at STATION1.EXAMPLE.COM for ldap/station1.example.com@
> STATION1.EXAMPLE.COM
> #
>
> 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 at polytechnique.fr>
> *To:* General discussion list for the 389 Directory server project. <
> 389-users at lists.fedoraproject.org>
> *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 at yahoo.com>
>
>> 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 at STATION1.EXAMPLE.COM"  -o authzid="
>> mcarey at STATION1.EXAMPLE.COM" -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 at STATION1.EXAMPLE.COM
>>    2    3 ldap/station1.example.com at 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 at station1 ~]$ kdestroy
>> [mcarey at station1 ~]$ kinit
>> Password for mcarey at STATION1.EXAMPLE.COM:
>> [mcarey at station1 ~]$ klist
>> Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
>> Default principal: mcarey at STATION1.EXAMPLE.COM
>> 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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20101005/28c1cadb/attachment.html>

More information about the 389-users mailing list