Hello all,
I've found lots of information about problems related to mine in the FAQ and around the net, but I don't have a solution yet. Here's my setup:
Open Ldap 2.2 MIT Kerberos SASL 2.1.20
I'm using ldap to provide directory services and user info to some linux workstations. This was working, but after upgrading a test machine to Fedora 6 I've started having some serious problems.
[sleepylight@minitop ~]$ ldapsearch -H ldap://ns.jive-turkey.net -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
I figure this is one of three possible problems. 1 - saslauthd isn't working right 2 - ldap isn't talking to sasl correctly 3 - I've done something wrong with my ldap quires.
Kerberos seems to work fine. I can get my credentials with kinit, and the GSSAPI credentials are working for ssh logins. Also, I can use testsaslauthd and get a success from the authd server.
[sleepylight@ns ~]$ /usr/sbin/testsaslauthd -r JIVE-TURKEY.NET -s ldap -u sleepylight -p ********* 0: OK "Success."
So I think my problem is #2 or #3. I'm not sure which, so if anyone has some feedback I'm happy to try it out. I'll include some possibly relevant material at the end of this email. Thanks for reading!
Some stuff from slapd.conf:
sasl-host ns.jive-turkey.net
sasl-secprops noanonymous,noplain,noactive
saslRegexp uid=([^/]*),cn=GSSAPI,cn=auth uid=$1,ou=People,dc=jive-turkey,dc=net
# Default read access for everything else access to * by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write by * read
Messages from slapd after an attempted login
slapd startup: initiated. backend_startup: starting "dc=jive-turkey,dc=net" bdb_db_open: dbenv_open(/var/lib/ldap) slapd starting connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next ber_get_next on fd 10 failed errno=11 (Resource temporarily unavailable) do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber:
dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 10 do_bind: v3 anonymous bind connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 201 contents: ber_get_next ber_get_next on fd 10 failed errno=11 (Resource temporarily unavailable) do_search ber_scanf fmt ({miiiib) ber:
dnPrettyNormal: <dc=jive-tukey,dc=net>
ldap_err2string <= ldap_bv2dn(dc=jive-tukey,dc=net)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(dc=jive-tukey,dc=net)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(dc=jive-tukey,dc=net)=0 Success <<< dnPrettyNormal: <dc=jive-tukey,dc=net>, <dc=jive-tukey,dc=net> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: send_ldap_result: conn=0 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=32 ber_flush: 14 bytes to sd 10 connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 201 contents: ber_get_next do_search
Maxwell Bottiger wrote:
Hello all,
I've found lots of information about problems related to mine in the FAQ and around the net, but I don't have a solution yet. Here's my setup:
Open Ldap 2.2 MIT Kerberos SASL 2.1.20
MIT Kerberos is known to work very poorly with OpenLDAP slapd. Heimdal is known to work well. On the client side, either one will work, but generally I would recommend using Heimdal.
I'm using ldap to provide directory services and user info to some linux workstations. This was working, but after upgrading a test machine to Fedora 6 I've started having some serious problems.
[sleepylight@minitop ~]$ ldapsearch -H ldap://ns.jive-turkey.net -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
I figure this is one of three possible problems. 1 - saslauthd isn't working right
SASL-enabled servers don't talk to saslauthd to perform GSSAPI authentication, so that is out of the equation.
2 - ldap isn't talking to sasl correctly
unlikely.
3 - I've done something wrong with my ldap quires.
possible.
Kerberos seems to work fine. I can get my credentials with kinit, and the GSSAPI credentials are working for ssh logins. Also, I can use testsaslauthd and get a success from the authd server.
Since you say kinit works, what tickets does klist show you having?
Howard Chu wrote:
Maxwell Bottiger wrote:
Hello all,
I've found lots of information about problems related to mine in theFAQ and around the net, but I don't have a solution yet. Here's my setup:
Open Ldap 2.2 MIT Kerberos SASL 2.1.20
MIT Kerberos is known to work very poorly with OpenLDAP slapd. Heimdal is known to work well. On the client side, either one will work, but generally I would recommend using Heimdal.
I'm using ldap to provide directory services and user info to some linux workstations. This was working, but after upgrading a test machine to Fedora 6 I've started having some serious problems.
[sleepylight@minitop ~]$ ldapsearch -H ldap://ns.jive-turkey.net -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
I figure this is one of three possible problems. 1 - saslauthd isn't working right
SASL-enabled servers don't talk to saslauthd to perform GSSAPI authentication, so that is out of the equation.
2 - ldap isn't talking to sasl correctly
unlikely.
3 - I've done something wrong with my ldap quires.
possible.
Kerberos seems to work fine. I can get my credentials with kinit, and the GSSAPI credentials are working for ssh logins. Also, I can use testsaslauthd and get a success from the authd server.
Since you say kinit works, what tickets does klist show you having?
Quite apart from all of this, running Fedora FC6 (a highly experimental and inherantly buggy release) in production is simply courting trouble. MIT KerberosV and OpenLDAP 2.3 work perfectly well on RHAS4 (with the intrinsic limitations that KerberosV has, and they are many), though as Quanah points out, it could be slower than Heimdal. Using Heimdal on any Red Hat system is a dead duck because of built-in program conflicts. Been there, done that ...
--Tonni
Tony Earnshaw wrote:
Quite apart from all of this, running Fedora FC6 (a highly experimental and inherantly buggy release) in production is simply courting trouble. MIT KerberosV and OpenLDAP 2.3 work perfectly well on RHAS4 (with the intrinsic limitations that KerberosV has, and they are many), though as Quanah points out, it could be slower than Heimdal. Using Heimdal on any Red Hat system is a dead duck because of built-in program conflicts. Been there, done that ...
Interesting. We build with Heimdal on RedHat all the time, no problems. The MIT Kerberos still lags significantly in features, stability, reliability, performance ... just about any metric worth mentioning.
I'll stop here before we get too far off-topic.
On Wed, 2006-11-08 at 18:28 -0800, Howard Chu wrote:
snip
MIT Kerberos is known to work very poorly with OpenLDAP slapd. Heimdal is known to work well. On the client side, either one will work, but generally I would recommend using Heimdal.
I have heard that through other sources as well. I'm really just using MIT kerberos because it shipped with my distro. Can I move the kerberos database directly to Hemidal in the future?
snip
I figure this is one of three possible problems. 1 - saslauthd isn't working right
SASL-enabled servers don't talk to saslauthd to perform GSSAPI authentication, so that is out of the equation.
That's very interesting. If openldap and other sasl enabled services don't need saslauthd, what does use it? Just curious. Maybe it's something I can turn off.
2 - ldap isn't talking to sasl correctly
unlikely.
3 - I've done something wrong with my ldap quires.
possible.
Kerberos seems to work fine. I can get my credentials with kinit, and the GSSAPI credentials are working for ssh logins. Also, I can use testsaslauthd and get a success from the authd server.
Since you say kinit works, what tickets does klist show you having?
[sleepylight@minitop ~]$ klist Ticket cache: FILE:/tmp/krb5cc_502 Default principal: sleepylight@JIVE-TURKEY.NET
Valid starting Expires Service principal 11/08/06 23:42:04 11/09/06 23:42:04 krbtgt/JIVE-TURKEY.NET@JIVE-TURKEY.NET 11/08/06 23:42:12 11/09/06 23:42:04 ldap/ns.jive-turkey.net@JIVE-TURKEY.NET
Kerberos 4 ticket cache: /tmp/tkt502 klist: You have no tickets cached
I have some more information from playing around this afternoon. The first thing I found is that ldap authentication is still working for my Fedora 5 computers. The ldap queries for users are failing only for the Fedora 6 machine. Since the setups are identical except for releases, I submitted a bug report to redhat's bugzilla.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214679
There are two logs attached to the bug report which detail this problem. They are both kind of lengthy, so I won't list them here.
That having been said, I'm really really leaning toward me not setting up these queries correctly. ldapsearch is still failing regardless of whether or not logins are working, and they are failing with the same error messages.
Thanks for your quick response.
Hi,
I am serching about win time with a great date import (3 Millions of entrys)
The slapadd import is about 2 hours without sub index parameter for uid and 4h50 with it I dont know if i could add this parameter after import without sub and start server. What will do the server ? Does it generate index with read write access ? Does it generate index whitout access ? Does it give acces without genrate anything ? Or only new entry ? Or does it crash ?
Thanks for your responses.
--On Thursday, November 09, 2006 6:23 PM +0100 Pierre FERT pfe@calo.ath.cx wrote:
Hi,
I am serching about win time with a great date import (3 Millions of entrys)
The slapadd import is about 2 hours without sub index parameter for uid and 4h50 with it I dont know if i could add this parameter after import without sub and start server. What will do the server ? Does it generate index with read write access ? Does it generate index whitout access ? Does it give acces without genrate anything ? Or only new entry ? Or does it crash ?
What version of OpenLDAP?
What options to slapadd?
Have you configured DB_CONFIG properly?
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Openldap 2.3.27 I do not use -q option because i use ldif converted and i want it stop on any error DB_CONFIG : # one 0.25 GB cache set_cachesize 0 268435456 1
# Data Directory # set_data_dir db
# Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 set_flags DB_TXN_NOSYNC set_flags DB_TXN_NOT_DURABLE
-----Message d'origine----- De : Quanah Gibson-Mount [mailto:quanah@stanford.edu] Envoyé : jeudi 9 novembre 2006 20:28 À : Pierre FERT; openldap-software@openldap.org Objet : Re: Indexs
--On Thursday, November 09, 2006 6:23 PM +0100 Pierre FERT pfe@calo.ath.cx wrote:
Hi,
I am serching about win time with a great date import (3 Millions of entrys)
The slapadd import is about 2 hours without sub index parameter for uid and 4h50 with it I dont know if i could add this parameter after import without sub and start server. What will do the server ? Does it generate index with read write access ? Does it generate index whitout access ? Does it give acces without genrate anything ? Or only new entry ? Or does it crash ?
What version of OpenLDAP?
What options to slapadd?
Have you configured DB_CONFIG properly?
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Thursday, November 09, 2006 8:35 PM +0100 Pierre FERT pfe@calo.ath.cx wrote:
Openldap 2.3.27 I do not use -q option because i use ldif converted and i want it stop on any error
Even without -q, slapadd will not stop on all errors. If you truly want to stop on all errors, you must use ldapadd.
DB_CONFIG : # one 0.25 GB cache set_cachesize 0 268435456 1
This is problematic. The size of the DB Cache for importing *must* be as large as the resulting *.bdb files. This cache size is way too small.
Also, since you are *not* using -q, you will want to specify that the BDB log files get stored on a separate disk, or on a separate spindle of the drive. Otherwise, you have constant I/O thrashing. This is good practice anyway.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Nov 8, 2006, at 8:51 PM, Maxwell Bottiger wrote:
On Wed, 2006-11-08 at 18:28 -0800, Howard Chu wrote:
snip
MIT Kerberos is known to work very poorly with OpenLDAP slapd. Heimdal is known to work well. On the client side, either one will work, but generally I would recommend using Heimdal.
I have heard that through other sources as well. I'm really just using MIT kerberos because it shipped with my distro. Can I move the kerberos database directly to Hemidal in the future?
Don't do that just for this. I don't know for sure that it isn't possible, but if you just want to satisfy this particular need for Heimdal, just build OpenLDAP slapd with Heimdal -- the Heimdal slapd will work fine with an MIT KDC, and MIT LDAP clients like for example the ldapsearch on MacOS X.
On the other hand, we use MIT Kerberos with slapd. I have observed reduced authentication speed, compared to SSL, but as I understand it that comes from replay cache functionality in the MIT server that serves an arguably desirable purpose. With current Cyrus SASL, I don't see any serious problem with MIT Kerberos, but if you're expecting an extremely heavy load of GSSAPI authentication and are willing to dispense with the replay cache checks, your perspective might be different.
SASL-enabled servers don't talk to saslauthd to perform GSSAPI authentication, so that is out of the equation.
That's very interesting. If openldap and other sasl enabled services don't need saslauthd, what does use it? Just curious. Maybe it's something I can turn off.
Maybe! But note that he said "... to perform GSSAPI authentication". That was true, and your paraphrase is clearly false.
Donn Cave, donn@u.washington.edu
--On Thursday, November 09, 2006 9:48 AM -0800 Donn Cave donn@u.washington.edu wrote:
On the other hand, we use MIT Kerberos with slapd. I have observed reduced authentication speed, compared to SSL, but as I understand it that comes from replay cache functionality in the MIT server that serves an arguably desirable purpose. With current Cyrus SASL, I don't see any serious problem with MIT Kerberos, but if you're expecting an extremely heavy load of GSSAPI authentication and are willing to dispense with the replay cache checks, your perspective might be different.
Funny, because the MIT developers always tell me to turn off the replay cache first thing, when using the MIT libraries, as it is something they seem to feel should *not* be used with OpenLDAP.
Set KRB5RCACHETYPE to "none".
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Wednesday, November 08, 2006 11:51 PM -0500 Maxwell Bottiger sleepylight@jive-turkey.net wrote:
On Wed, 2006-11-08 at 18:28 -0800, Howard Chu wrote:
snip
MIT Kerberos is known to work very poorly with OpenLDAP slapd. Heimdal is known to work well. On the client side, either one will work, but generally I would recommend using Heimdal.
I have heard that through other sources as well. I'm really just using MIT kerberos because it shipped with my distro. Can I move the kerberos database directly to Hemidal in the future?
It doesn't matter what kerberos database you use. For example, Stanford uses an MIT KDC. But we use the Heimdal kerberos *libraries* to link slapd against. It is the libraries we are talking about right now. Of course, Heimdal also has the capability of using LDAP as its KDC store. MIT will have that functionality sometime in the near future.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Maxwell Bottiger wrote:
On Wed, 2006-11-08 at 18:28 -0800, Howard Chu wrote:
I figure this is one of three possible problems. 1 - saslauthd isn't working right
SASL-enabled servers don't talk to saslauthd to perform GSSAPI authentication, so that is out of the equation.
That's very interesting. If openldap and other sasl enabled services don't need saslauthd, what does use it? Just curious. Maybe it's something I can turn off.
I generally don't build saslauthd; I find it to be more of a liability than anything else. It only supports plaintext password authentication. The couple things that it can do that nothing else does, is authenticate a plaintext password against PAM, IMAP, and some other external mechanisms.
The only reason OpenLDAP supports SASL is to provide strong authentication mechanisms. Going to the trouble of setting up SASL, and then only using it with plaintext, just doesn't make any sense.
I have some more information from playing around this afternoon. The first thing I found is that ldap authentication is still working for my Fedora 5 computers. The ldap queries for users are failing only for the Fedora 6 machine. Since the setups are identical except for releases, I submitted a bug report to redhat's bugzilla.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214679
There are two logs attached to the bug report which detail this problem. They are both kind of lengthy, so I won't list them here.
That having been said, I'm really really leaning toward me not setting up these queries correctly. ldapsearch is still failing regardless of whether or not logins are working, and they are failing with the same error messages.
Thanks for your quick response.
First you should follow Kurt's advice and get the SASL sample client and server working, before leaping to any other conclusions.
First step in getting SASL/GSSAPI working (or any SASL mechanism) is to make sure it works first using Cyrus SASL sample test programs (as service "ldap" and daemon "slapd"). You apparently haven't done that yet...
At 12:08 PM 11/8/2006, Maxwell Bottiger wrote:
Hello all,
I've found lots of information about problems related to mine in theFAQ and around the net, but I don't have a solution yet. Here's my setup:
Open Ldap 2.2 MIT Kerberos SASL 2.1.20
I'm using ldap to provide directory services and user info to some linux workstations. This was working, but after upgrading a test machine to Fedora 6 I've started having some serious problems.
[sleepylight@minitop ~]$ ldapsearch -H ldap://ns.jive-turkey.net -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
I figure this is one of three possible problems. 1 - saslauthd isn't working right 2 - ldap isn't talking to sasl correctly 3 - I've done something wrong with my ldap quires.
Kerberos seems to work fine. I can get my credentials with kinit, and the GSSAPI credentials are working for ssh logins. Also, I can use testsaslauthd and get a success from the authd server.
[sleepylight@ns ~]$ /usr/sbin/testsaslauthd -r JIVE-TURKEY.NET -s ldap -u sleepylight -p ********* 0: OK "Success."
So I think my problem is #2 or #3. I'm not sure which, so if anyone has some feedback I'm happy to try it out. I'll include some possibly relevant material at the end of this email. Thanks for reading!
Some stuff from slapd.conf:
sasl-host ns.jive-turkey.net
sasl-secprops noanonymous,noplain,noactive
saslRegexp uid=([^/]*),cn=GSSAPI,cn=auth uid=$1,ou=People,dc=jive-turkey,dc=net
# Default read access for everything else access to * by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write by * read
Messages from slapd after an attempted login
slapd startup: initiated. backend_startup: starting "dc=jive-turkey,dc=net" bdb_db_open: dbenv_open(/var/lib/ldap) slapd starting connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next ber_get_next on fd 10 failed errno=11 (Resource temporarily unavailable) do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber:
dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 10 do_bind: v3 anonymous bind connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 201 contents: ber_get_next ber_get_next on fd 10 failed errno=11 (Resource temporarily unavailable) do_search ber_scanf fmt ({miiiib) ber:
dnPrettyNormal: <dc=jive-tukey,dc=net>
ldap_err2string <= ldap_bv2dn(dc=jive-tukey,dc=net)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(dc=jive-tukey,dc=net)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(dc=jive-tukey,dc=net)=0 Success <<< dnPrettyNormal: <dc=jive-tukey,dc=net>, <dc=jive-tukey,dc=net> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: send_ldap_result: conn=0 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=32 ber_flush: 14 bytes to sd 10 connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 201 contents: ber_get_next do_search
openldap-software@openldap.org
-
Donn Cave -
Howard Chu -
Kurt D. Zeilenga -
Maxwell Bottiger -
Michael Ströder -
Pierre FERT -
Quanah Gibson-Mount -
Tony Earnshaw