GSSAPI authentication to Directory Server

[Matt Carey]

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="[e-mail]"  -o authzid="[e-mail]" 
-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/[e-mail]
   2    3 ldap/[e-mail]
# 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 [e-mail]: 
[mcarey@station1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: [e-mail]
Valid starting     Expires            Service principal
10/04/10 10:57:20  10/04/10 17:37:20  
krbtgt/[e-mail]
Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached

Any help or pointers people have would be greatly appreciated.

[Ivanov Andrey (M.)]

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
> 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="[e-mail]"  -o authzid="
> [e-mail]" -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/[e-mail]
>    2    3 ldap/[e-mail]
> # 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 [e-mail]:
> [mcarey@station1 ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
> Default principal: [e-mail]
> 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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Matt Carey]

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 [e-mail]: 
[mcarey@station1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: [e-mail]

Valid starting     Expires            Service principal
10/04/10 12:35:49  10/04/10 19:15:49  
krbtgt/[e-mail]
    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: [e-mail]

Valid starting     Expires            Service principal
10/04/10 12:35:49  10/04/10 19:15:49  
krbtgt/[e-mail]
    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}, [e-mail] for 
krbtgt/[e-mail]
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}, 
[e-mail] for ldap/[e-mail]
#

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 
To: General discussion list for the 389 Directory server project. 

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

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="[e-mail]"  -o authzid="[e-mail]" 
> -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/[e-mail]
>   2    3 ldap/[e-mail]
> # 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 [e-mail]: 
> [mcarey@station1 ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
> Default principal: [e-mail]
> Valid starting     Expires            Service principal
> 10/04/10 10:57:20  10/04/10 17:37:20  
> krbtgt/[e-mail]
> 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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Ivanov Andrey (M.)]

2010/10/4 Matt Carey
> 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 [e-mail]:
> [mcarey@station1 ~]$ klist -e
>
> Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
> Default principal: [e-mail]
>
> 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@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: [e-mail]
>
> 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.COMhttp://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}, [e-mail] for krbtgt/
> [e-mail]
> 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}, [e-mail] 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 
> *To:* General discussion list for the 389 Directory server project. <
> [e-mail]>
> *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
> > 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="[e-mail]"  -o authzid="
> > [e-mail]" -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/[e-mail]
> >    2    3 ldap/[e-mail]
> > # 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 [e-mail]:
> > [mcarey@station1 ~]$ klist
> > Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
> > Default principal: [e-mail]
> > 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
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users