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

Re: Simple bind through GSSAPI issues on Solaris 9

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.


At 05:41 PM 10/27/2003, aay@bellsouth.net wrote:
>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
>SASL/GSSAPI authentication started
>SASL username: krbtest@MYREALM.NET
>SASL installing layers
>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
>"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= (IP=
>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.
>P.S: I have built everything from source, if that makes any difference.