[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Simple bind through GSSAPI issues on Solaris 9 [Solved]

Kurt D. Zeilenga wrote:

First, you likely have not enabled {KERBEROS} support.
See the FAQ for details on how to enable it in 2.1.23 (and later
versions).  You might also read the archives as they include
discussions of the problems with the {KERBEROS} support,
in particular its bad interaction with GSSAPI mechanism.
If you must do simple bind to Kerberos secrets, use {SASL}
instead. See FAQ as to how.

Kurt

At 05:41 PM 10/27/2003, aay@bellsouth.net wrote:


Greetings,

My setup is as follows:

OpenLDAP      - 2.1.23
Cyrus SASL     - 2.1.15
MIT Kerberos  - 1.3.1

After having configured everything "by the book", I can successfully initiate SASL bind through GSSAPI, by issuing:
# ldapsearch -b "" -s base -LLL supportedSASLMechanisms
SASLMechanisms
SASL/GSSAPI authentication started
SASL username: krbtest@MYREALM.NET
SASL SSF: 56
SASL installing layers
dn:
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: OTP
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5

Issuing 'klist' yields:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: krbtest@MYREALM.NET

Valid starting     Expires            Service principal
10/27/03 19:13:39  10/28/03 05:13:39  krbtgt/MYREALM.NET@MYREALM.NET
     renew until 10/28/03 19:13:39
10/27/03 19:13:43  10/28/03 05:13:39  ldap/ldapsrv.myrealm.net@MYREALM.NET
     renew until 10/28/03 19:13:39

All this suggests that Kerberos is functioning as expected (I'm also successfully using kerberized client/server apps).
However, I cannot initiate a simple bind through GSSAPI even though I do have proper entries in the LDAP database:

dn: uid=krbtest,ou=people,dc=myrealm,dc=net
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: krb5Principal
krb5PrincipalName: krbtest@MYREALM.NET
cn: LDAP_Krb5 Tester
givenName: LDAP_Krb5
sn: Tester
mail: krbtest@myrealm.net
telephoneNumber: (222) 333-4444
title: LDAP Kerberos 5 Tester
uid: krbtest
uidNumber: 12335
gidNumber: 12443
userPassword: {KERBEROS}krbtest@MYREALM.NET
homeDirectory: /home/krbtest
loginShell: /no/shell

Furthermore, 'slapd.conf' ACLs are very loose for testing purposes:
access to *
        by * read
To further illustrate the fact that I can successfully bypass ACL restrictions, I also have another user in the database which
does not use GSSAPI for password retrieval, instead it utilizes MD5 in the userPassword field, and I can succesfully issue:
# ldapsearch -x -D 'uid=sasltest,ou=people,dc=myrealm,dc=net' -W -b "" -s base -LLL supportedSASLMechanisms

which yields the same results as the SASL bind through GSSAPI mentioned above.

So, to summarize, everything seems to work, I can populate the database, modify entries and perform searches on all the data except that I cannot perform a successful simple bind through GSSAPI. Now, I have searched the archives, Google groups, and other mediums and unfortunately was not able to find exactly the same problem description, albeit a few similar problems which, after many attempts, were to no avail.

So basically, issuing: (see above: 'krbtest' entry in the database is configured to retrieve password from KDC)
# ldapsearch -x -D 'uid=krbtest,ou=people,dc=myrealm,dc=net' -W -b "" -s base -LLL supportedSASLMechanisms

yields:
"ldap_bind: Invalid credentials (49)"
on the client, and on the server, with debug level of 256 I get:

Oct 27 19:32:06 ldapsrv slapd[954]: [ID 848112 local4.debug] conn=18 fd=12 ACCEPT from IP=192.168.0.55:33209 (IP=0.0.0.0:636)
Oct 27 19:32:06 ldapsrv slapd[954]: [ID 347666 local4.debug] conn=18 op=0 BIND dn="uid=krbtest,ou=people,dc=myrealm,dc=net" method=128
Oct 27 19:32:06 ldapsrv slapd[954]: [ID 217296 local4.debug] conn=18 op=0 RESULT tag=97 err=49 text=
Oct 27 19:32:06 ldapsrv slapd[954]: [ID 952275 local4.debug] conn=18 fd=12 closed

If anyone has experienced a similar problem, your input would be very welcome.

TIA,
Alex

P.S: I have built everything from source, if that makes any difference.







Problem solved! (Thanks Kurt)

Aparently I missed that FAQ section about the latest changes to the 2.1.23 tree in regard to simple authentication through GSSAPI, directly from OpenLDAP. I had thought that '--enable-kpasswd' was still a valid mechanism, and thats where I went wrong. Anyways, after following the FAQ instructions on how to perform 'simple' authentication against Krb5 KDC through SASL, I have it all working just dandy now.

To all the developers: impressive work...keep it up.
Thanks again,
Alex.