slapd-meta idassert with SASL EXTERNAL not working correctly
Hi, I'm trying to set up OpenLDAP as a Proxy for multiple LDAP servers using slapd-meta. The remote servers require SASL EXTERNAL authentication, so I have to configure TLS client auth. The relevant part of my slapd.conf looks like this: - database meta suffix dc=example uri ldaps://server2:636/cn=server2,dc=example idassert-authzFrom dn:* idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=mycert.crt tls_key=mycert.key tls_cacert=trusted-ca.pem mode=none - Starting slapd with this config results in anonymous authentication against server2, even though I configured the idassert-bind to use SASL EXTERNAL with the given keys/certs. The strange thing is: When I'm starting slapd with the environment variables LDAPTLS_CERT,LDAPTLS_KEY,LDAPTLS_CACERT (same values as the options in idassert-bind), everything works (the meta backend authenticates with the given keys/certs). Why do I have to set those environment variables to get the meta backend working? And respectively, why do the tls_* options in idassert-bind have no effect (in that case)? Thanks in advance, Manuel
CRL refresh
Hi, Using version 2.4.23 with TLS. In slapd.conf the TLSCACertificatePath directive specifies the directory containing the certificate for the CA and the CRL. The content of this directory is hashed with c_rehash utilities. Everything works fine, but when a client certificate is revoked (ad a new CRL is created) i must restart the server to make it upgraded with the new CRL. Is there a way to do this, without having to reboot (a hot refresh of the CRL)? Thanks. gnigro Il contenuto di questo messaggio di posta elettronica e ogni eventuale documento a quest'ultimo allegato puo contenere informazioni la cui riservatezza e' tutelata ed e' rivolto unicamente agli effettivi destinatari i quali prendono atto del carattere non strettamente personale dei messaggi di risposta, che potranno essere noti all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di questo messaggio in mancanza di autorizzazione del destinatario. Se avete ricevuto questo messaggio per errore, vogliate cortesemente chiamarci immediatamente per telefono o fax e distruggere quanto ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti.
Re: CRL refresh
Gianluigi Nigro wrote: Hi, Using version 2.4.23 with TLS. In slapd.conf the TLSCACertificatePath directive specifies the directory containing the certificate for the CA and the CRL. The content of this directory is hashed with c_rehash utilities. Everything works fine, but when a client certificate is revoked (ad a new CRL is created) i must restart the server to make it upgraded with the new CRL. Is there a way to do this, without having to reboot (a hot refresh of the CRL)? Thanks. gnigro There's no explicit mechanism to refresh the CRL. However, if you use cn=config and modify the TLS settings, it will reinitialize the entire TLS context, including reloading the CRL. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
cannot bind to ldap other user as root
Hi! I have installed the openldap 2.2.13 with rpm on Red Hat Enterprise Linux ES release 4 (Nahant Update 8) I have set the TLS setting too. With the user root I can start the ldapsearch and I receive the result successfully, the ldap client can connect to the ldap server. However if I login with another user I receive the following message: ldap_bind: Can't contact LDAP server (-1) What can be the problem? Thanks for the help in advance, Sandor
Re: cannot bind to ldap other user as root
Sandor, Sandor Szalina schrieb am 08.09.2010 12:16 Uhr: I have installed the openldap 2.2.13 with rpm on Red Hat Enterprise Linux ES release 4 (Nahant Update 8) I have set the TLS setting too. Man, 2.2.13 is ancient: http://www.openldap.org/lists/openldap-announce/200406/msg2.html You really should try a /newer/ release. With the user root I can start the ldapsearch and I receive the result successfully, the ldap client can connect to the ldap server. However if I login with another user I receive the following message: ldap_bind: Can't contact LDAP server (-1) What can be the problem? Thanks for the help in advance, You did not provide any details - on how to uses ldapsearch and - about the server and client side config Marc
slapcat generate extra space characters in LDIF output
Hello I'm in trouble with slapcat when generating a LDIF file it puts some extra space characters into some dn longer than 80 characters. is there a way to change the output format of slapcat command to generate lines longer than 80 characters in the LDIF file ? I need this because I need to duplicate our directory server to another TLD and I need to substitute dc=fr by dc=biz but sometime I get this dc=fr sometime I get this dc= fr sometime I get this dc =fr sometime I get this dc= fr Thank you
Re: slapcat generate extra space characters in LDIF output
Frank Bonnet f.bon...@esiee.fr writes: Hello I'm in trouble with slapcat when generating a LDIF file it puts some extra space characters into some dn longer than 80 characters. is there a way to change the output format of slapcat command to generate lines longer than 80 characters in the LDIF file ? I need this because I need to duplicate our directory server to another TLD and I need to substitute dc=fr by dc=biz but sometime I get this dc=fr sometime I get this dc= fr This is intended behaviour, because the LDIF specifications (RFC2849) require a max. line length of 76 characters, but allow line folding, that is continuation of a line longer than 76 chars. -Dieter -- Dieter Klünter | Systemberatung sip: 7770...@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
Re: slapd-meta idassert with SASL EXTERNAL not working correctly
Hi, I'm trying to set up OpenLDAP as a Proxy for multiple LDAP servers using slapd-meta. The remote servers require SASL EXTERNAL authentication, so I have to configure TLS client auth. The relevant part of my slapd.conf looks like this: - database meta suffix dc=example uri ldaps://server2:636/cn=server2,dc=example idassert-authzFrom dn:* idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=mycert.crt tls_key=mycert.key tls_cacert=trusted-ca.pem mode=none - Starting slapd with this config results in anonymous authentication against server2, even though I configured the idassert-bind to use SASL EXTERNAL with the given keys/certs. The strange thing is: When I'm starting slapd with the environment variables LDAPTLS_CERT,LDAPTLS_KEY,LDAPTLS_CACERT (same values as the options in idassert-bind), everything works (the meta backend authenticates with the given keys/certs). Why do I have to set those environment variables to get the meta backend working? And respectively, why do the tls_* options in idassert-bind have no effect (in that case)? Apparently, although those options are perfectly valid, they are ignored by back-meta. I suggest you file an ITS http://www.openldap.org/its/. p.
I can't login in my system using OpenLDAP
Hi Dear! Since 3 days I try to setting a LDAP Server with OpenLDAP on Debian Lenny. I'm using Mandriva Management Console (mmc) like web based admin. I already create some users with mmc, but I can't login? Please, everybody can help me or provide me a good tuto? -- Yours truly, Eric KOM 110 LAWN STREET ROSETTENVILLE 2190 JOHANNESBURG SOUTH AFRICA Phone: +27 (0) 788 791 334 Fax: +27 (0) 865 563 009 E-mail: eric...@namekom.co.za Websites: www.erickom.co.za | www.namekom.co.za/erickom | www.namekom.co.za
Re: I can't login in my system using OpenLDAP
On 08/09/10 16:13 +0200, Eric KOM wrote: Hi Dear! Since 3 days I try to setting a LDAP Server with OpenLDAP on Debian Lenny. I'm using Mandriva Management Console (mmc) like web based admin. I already create some users with mmc, but I can't login? Please, everybody can help me or provide me a good tuto? Which packages got installed? -- Dan White
Re: slapd-meta idassert with SASL EXTERNAL not working correctly
What setting do you have for TLSVerifyClient on the server side? According 16.2.1.8 of the Administrator's Guide, you'll need a non-default setting for the server to ask for the client certificate. Also, have you attempted to perform a bind using the client utilities, to rule out any problems with the server config? The server that back-meta connects to is configured to try TLS authentication. I also tested the authentication using the client utilities, which succeeded. Apparently, the tls options I'm using are ignored by back-meta (see the previous message). Nevertheless, setting the LDAPTLS_... environment variables for slapd seems to be a possible workaround for this problem. -- Manuel Gaupp
Re: slapd-meta idassert with SASL EXTERNAL not working correctly
Hi, I'm trying to set up OpenLDAP as a Proxy for multiple LDAP servers using slapd-meta. The remote servers require SASL EXTERNAL authentication, so I have to configure TLS client auth. The relevant part of my slapd.conf looks like this: - database meta suffix dc=example uri ldaps://server2:636/cn=server2,dc=example idassert-authzFrom dn:* idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=mycert.crt tls_key=mycert.key tls_cacert=trusted-ca.pem mode=none Add tls start here to request TLS to be established on connections (see slapd-meta(5) for details). I think this should be implicitly enabled by idassert-bind when it requires TLS (or at least its need should be documented). p.
Re: I can't login in my system using OpenLDAP
Eric, http://www.debian-administration.org/article/OpenLDAP_installation_on_Debian Best regards, -- Dan On Sep 8, 2010, at 7:13 AM, Eric KOM wrote: Hi Dear! Since 3 days I try to setting a LDAP Server with OpenLDAP on Debian Lenny. I'm using Mandriva Management Console (mmc) like web based admin. I already create some users with mmc, but I can't login? Please, everybody can help me or provide me a good tuto? -- Yours truly, Eric KOM 110 LAWN STREET ROSETTENVILLE 2190 JOHANNESBURG SOUTH AFRICA Phone: +27 (0) 788 791 334 Fax: +27 (0) 865 563 009 E-mail: eric...@namekom.co.za Websites: www.erickom.co.za | www.namekom.co.za/erickom | www.namekom.co.za
Re: back-sql disconnects
While googling for reconnect in the ODBC API I found this: http://dev.mysql.com/doc/refman/5.0/en/connector-odbc-configuration-connection-parameters.html option 4194304: Enables auto-reconnection functionality. It seems like it fixes my problem. I will post it under the ITS too. If you like, you could refresh the FAQ http://www.openldap.org/faq/data/cache/978.html regarding the RDBMS you're using. The FAQ-o-matic is interactive. p.
Re: Authenticate to ldap using Kerberos
On 08/09/10 22:53 +0800, Wouter van Marle wrote:
Hi group,
I have been fighting the whole day already for something that I think
is quite simple but I just can't get it to work: have slapd
authenticate users against kerberos. Following many tutorials, trying
many things, I give up on that and ask for your help.
System: Debian Lenny.
Situation:
- workstation logins over the network authenticate against kerberos
- credentials from LDAP
- postfix has its alias database etc in LDAP, as are the groups and
userIDs and everything - helps keeping uids the same on the
workstations. Essential for NFS.
- anything using pam will be authenticated against kerberos,
including imap, postfix, etc.
Except LDAP. Then slapd authenticates by itself against the password
stored there. And that's not what I want. There should be no
passwords in LDAP any more, everything against kerberos. Then at
least when a user changes their kerberos password, the same password
is used everywhere. I just can't get this to work for some reason. I
have followed many tutorials, so many that I forgot what I did, and
it still doesn't work.
Slapd should use pam to authenticate, or directly talk to the
kerberos server, whatever.
saslauthd has the gssapi module installed.
I have created an ldap/acorn.squir...@squirrel key, and added this
keytab in /etc/defaults/slapd. acorn.squirrel is the fqdn of the
server, SQUIRREL is its kerberos realm.
To have slapd use saslauthd for authentication, you'll need to create the
file /usr/lib/sasl2/slapd.conf, with these contents:
pwcheck_method: saslauthd
mech_list: plain login
and optionally
keytab: /etc/krb5.keytab (which is the standard location)
*If* you intend to perform a PLAIN sasl bind, you'll need this in your
/etc/ldap/slapd.conf:
sasl-secprops none
If you're planning on supporting non-sasl binds, but still wish to
authenticate via saslauthd, your userPassword entries should look like:
userPassword: {sasl}usern...@realm
and you'll need to verify that your slapd was compiled with the
--enable-spasswd option. See section 4.5 (Pass-Through authentication)
of the OpenLDAP Administrators Guide.
You could authenticate against a kerberos5 installation with saslauthd a
couple of different ways:
1. Authenticate saslauthd against PAM. Edit /etc/default/saslauthd and
specify 'pam' as your authentication backend. You'll then need to configure
a kerberos pam module to do that actual work.
2. Authenticate saslauthd against kerberos5 ('kerberos5' in
/etc/default/saslauthd). I'm not sure if you need to have a valid ticket
granting ticket, or if a proper /etc/krb5.conf is all you need.
Current situation after all the hacking:
$ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h
acorn.squirrel
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
when entering my Kerberos password; it accepts my credentials when I
enter the LDAP stored password (a different password).
That requires pass-through authentication.
Then I just did:
===
wou...@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
wou...@acorn:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w
Default principal: wou...@squirrel
Valid starting ExpiresService principal
09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/squir...@squirrel
renew until 09/09/10 22:42:07
09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squir...@squirrel
renew until 09/09/10 22:42:07
Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached
===
Do you have ldap/acorn.squir...@squirrel in /etc/krb5.keytab, on the
server? Is it readable by the slapd user?
--
Dan White
Re: Authenticate to ldap using Kerberos
On 08/09/10 12:15 -0500, Dan White wrote: To have slapd use saslauthd for authentication, you'll need to create the file /usr/lib/sasl2/slapd.conf, with these contents: pwcheck_method: saslauthd mech_list: plain login and optionally keytab: /etc/krb5.keytab (which is the standard location) Check that. That should be: pwcheck_method: saslauthd mech_list: plain login gssapi external keytab: /etc/krb5.keytab Do you have ldap/acorn.squir...@squirrel in /etc/krb5.keytab, on the server? Is it readable by the slapd user? Also see: http://www.cyrusimap.org/mediawiki/index.php/FAQ#Cyrus_SASL_Questions -- Dan White
Keep alive functionality when the remote closes the conenction due idle
Hi guys, I have a question related to the open ldap client keep alive functionality. Our OS is SLES 11. In our client code we are reusing the ldap connections between requests uning a connection pool. For each conenction we are setting the keep-alive options (LDAP_OPT_X_KEEPALIVE_IDLE, LDAP_OPT_X_KEEPALIVE_PROBES and LDAP_OPT_X_KEEPALIVE_INTERVAL) and this works fine. My question is how the openl ldap library (libldap and libldap_r) handles the situation when the number of kee-alive probes for a connection is exceeded and the connection is closed at the server side. Did you dealt with this situation? Thanks, Alin
Re: Keep alive functionality when the remote closes the conenction due idle
--- On Wed, 9/8/10, masar...@aero.polimi.it masar...@aero.polimi.it wrote:
As far as I know, the function registered by
ldap_set_rebind_proc(3) is
only invoked to bind when chasing a referral.
p.
This is what I found until now regarding this function. I'm tracing this in
the openldap source code in request.c/ldap_send_server_request :
if ( lc == NULL || lc-lconn_status != LDAP_CONNST_CONNECTED ) {
if ( ld-ld_errno == LDAP_SUCCESS ) {
ld-ld_errno = LDAP_SERVER_DOWN;
}
ber_free( ber, 1 );
if ( incparent ) {
/* Forget about the bind */
--parentreq-lr_outrefcnt;
}
return( -1 );
}
Re: Authenticate to ldap using Kerberos
To have slapd use saslauthd for authentication, you'll need to create the
file /usr/lib/sasl2/slapd.conf, with these contents:
pwcheck_method: saslauthd
mech_list: plain login
and optionally
keytab: /etc/krb5.keytab (which is the standard location)
Check. As per a previous trial I created the keytab in a different
location;
# cat /usr/lib/sasl2/slapd.conf
pwcheck_method: saslauthd
mech_list: plain login gssapi external
keytab: /etc/ldap/ldap.keytab
# ls -l /usr/lib/sasl2/slapd.conf
-rw-r--r-- 1 root root 95 2010-09-09 10:03 /usr/lib/sasl2/slapd.conf
# ls -l /etc/ldap/ldap.keytab
-rw-r- 1 root openldap 286 2010-09-08 16:03 /etc/ldap/ldap.keytab
*If* you intend to perform a PLAIN sasl bind, you'll need this in your
/etc/ldap/slapd.conf:
sasl-secprops none
Check.
Had some probs with SSL before so start with plain. Later I'm just going
to close that port in the firewall, for internal use it's secure enough.
If you're planning on supporting non-sasl binds, but still wish to
authenticate via saslauthd, your userPassword entries should look like:
userPassword: {sasl}usern...@realm
and you'll need to verify that your slapd was compiled with the
--enable-spasswd option. See section 4.5 (Pass-Through authentication)
of the OpenLDAP Administrators Guide.
This one I have no idea what that would do. My understanding is
obviously not deep enough.
You could authenticate against a kerberos5 installation with saslauthd a
couple of different ways:
1. Authenticate saslauthd against PAM. Edit /etc/default/saslauthd and
specify 'pam' as your authentication backend. You'll then need to configure
a kerberos pam module to do that actual work.
In /etc/default/saslauthd:
MECHANISMS=pam
Already configured like that.
Other logins authenticate fine against pam using my kerberos password
(like Cyrus IMAP, and Postfix's smtp authentication), so this part is
working fine.
2. Authenticate saslauthd against kerberos5 ('kerberos5' in
/etc/default/saslauthd). I'm not sure if you need to have a valid ticket
granting ticket, or if a proper /etc/krb5.conf is all you need.
I prefer to stick to pam as in that case it can fall back to my local
passwd file, where I have defined a password for root, so in case the
krb server (or the network) fails at least I can log in!
Current situation after all the hacking:
$ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h
acorn.squirrel
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
when entering my Kerberos password; it accepts my credentials when I
enter the LDAP stored password (a different password).
That requires pass-through authentication.
I see.
Well with the above instructions nothing seems to have changed.
I have restarted saslauthd and slapd after making the changes, and when
now accessing the ldap addressbook using Evolution, I still have to use
the ldap stored password, not the krb password.
Wouter.
Then I just did:
===
wou...@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
wou...@acorn:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w
Default principal: wou...@squirrel
Valid starting ExpiresService principal
09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/squir...@squirrel
renew until 09/09/10 22:42:07
09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squir...@squirrel
renew until 09/09/10 22:42:07
Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached
===
Do you have ldap/acorn.squir...@squirrel in /etc/krb5.keytab, on the
server? Is it readable by the slapd user?
Re: Authenticate to ldap using Kerberos
Also see: http://www.cyrusimap.org/mediawiki/index.php/FAQ#Cyrus_SASL_Questions I followed those steps, finding out that the client didn't have the sasl gssapi module installed (apparently necessary?! I guessed the authentication is done by slapd on the server?). All other tests mentioned check out fine. However when I access my address book in Evolution it still only accepts my ldap stored password, not my kerberos password! What could possible be wrong? Wouter.
Re: I can't login in my system using OpenLDAP
On 08/09/10 16:13 +0200, Eric KOM wrote: Hi Dear! Since 3 days I try to setting a LDAP Server with OpenLDAP on Debian Lenny. I'm using Mandriva Management Console (mmc) like web based admin. I already create some users with mmc, but I can't login? Please, everybody can help me or provide me a good tuto? Which packages got installed? -- Dan White I reinstall slapd on the fresh Debian to fix all problems! after execute this command I can see the output comment below: ldap:/etc/ldap# slapindex WARNING! Runnig as root! There's a fair chance slapd will fail to start. Check file permissions! but the server Is still started. -- Yours truly, Eric KOM 110 LAWN STREET ROSETTENVILLE 2190 JOHANNESBURG SOUTH AFRICA Phone: +27 (0) 788 791 334 Fax: +27 (0) 865 563 009 E-mail: eric...@namekom.co.za Websites: www.erickom.co.za | www.namekom.co.za/erickom | www.namekom.co.za
Re: Authenticate to ldap using Kerberos
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see.
Well with the above instructions nothing seems to have changed.
I have restarted saslauthd and slapd after making the changes, and when
now accessing the ldap addressbook using Evolution, I still have to use
the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you
will need to replace the password (userPassword attribute) with:
userPassword: {sasl}usern...@realm
for instance:
dn: uid=jsmith,dc=example,dc=com
...
userPassword: {SASL}jsmith
In this case, the user will have no valid password defined in LDAP (or at
least not in the userPassword attribute).
When attempting to perform a non-sasl bind, slapd will use saslauthd to
authenticate, by taking the username (from the userPassword field), and the
password that was submitted.
--
Dan White
GSSAPI Bind across trusted realms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have REALM.A and REALM.B in my KDC setup. There is a two way trust between REALM.A and REALM.B. I have a client computer on REALM.A, and can correctly kinit to get tickets from both realms via this trust pathway. I also have an OpenLDAP server on the server with REALM.B, and it is identified by ldap/ldap.real...@realm.b When i obtain a ticket on REALM.A via this , and try to execute a SASL bind to the ldap server, i get an error of SASL/GSSAPI authentication started ldap_err2string ldap_sasl_interactive_bind_s: Local error (-2) It says that Minor code may provide more information (Server ldap/ldap.real...@realm.b not found in Kerberos database). A user from REALM.B can access the LDAP server correctly with GSSAPI klist shows that i am getting a TGT for both REALM.A and REALM.B on my u...@realm.a. Is this an issue with kerberos being unable to find the ticket across the realm trust for ldap to be verified? What steps can i follow to help fix this issue? Are there principal flags that i am forgetting to add to my LDAP principal for this to work? Your help is appreciated. William Brown pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iQIcBAEBAgAGBQJMiF0cAAoJEHF16AnLoz6J6mIP/0Jnfw8vG13LyOlv2gm3zwrF psHWASKmzaPngS0c7nbNSDDWi6jZJXogP9kF8uI/JQibUlYJb9TtfiG1K7l6yMol /jD8l3TGVy/VBrG6Yk0sqiQeHn52IaPTXv/xk0a8o6rk/wAUFzEnXH3+K/oRg+4A +Z5WHWHsdz73QBkMRVE+IY+IHwUB+GoglyocZmnQBjigU+2+So2hhlxp8XqmZPSZ jke2yk375LXHgv8/cppIIx3YV5VtvMe/O/lQoptBl39D8Y7CFwJsuQqGtyTRQVJh PpnMDARhqR+UKqJeZRksQLUeFZhQYzLWpTStm/8NhYAVBhTF32NPwgkcv5LohUdH yK3TCjvPodXCs27kGFX2s20tpFjLfpnx+gzyCTRQbbygPR4/Nn+11kmqDlrC05fW GpUOA8aknL7J6tN5twlO/wHtIaIvTPP4MmDD9DlS6OtNbBtaumDrS6ehWQ0j4FlA IfK+eHwIRgvjxCGa7N9S7jv5ZqxkAyeVArWWJczcCL6qKij7Zgh0w8nvzMTJq1Jj TwYK9O8RHL0d66NSFs2sTaEUZECnYA29oh6XppmvaOUdI5JOzQ4keG6xhTieRPBx Tdkq/1B51nl6EfJTu4fLOKfRz2UnOY2Uvms+2qdH0cZZIhOu98I3BsSdKhUgPtAB kZoLSAwYj33BL/KU/8Yj =RZcN -END PGP SIGNATURE-
Re: Authenticate to ldap using Kerberos
On 09/09/10 12:17 +0800, Wouter van Marle wrote:
Anyway I have changed my userPassword field (using GQ) to
{sasl}wou...@squirrel
It still doesn't work of course.
Also not when I set it to {SASL}wouter
In syslog I found the following error related to my attempt to open the
address book in evolution:
Sep 9 12:15:32 acorn slapd[15925]: conn=14 op=43 SEARCH RESULT tag=101
err=0 nentries=59 text=
Sep 9 12:15:39 acorn slapd[15925]: conn=135 fd=54 ACCEPT from
IP=192.168.2.4:39863 (IP=0.0.0.0:389)
Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 BIND
dn=uid=wouter,ou=People,dc=squirrel method=128
Sep 9 12:15:39 acorn slapd[15925]: SASL [conn=135] Failure: cannot
connect to saslauthd server: Permission denied
Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 RESULT tag=97 err=49
text=
So there is something in saslauthd that does not accept connections from
slapd. Now the big question is why? As I have no idea where to start
searching for this.
Wouter.
You're close.
On Debian/Ubuntu, do:
adduser openldap sasl
The issue is that the /var/run/saslauthd directory, where the
saslauthd unix socket is located, is only accessible by group 'sasl' (and
root).
--
Dan White
Re: Authenticate to ldap using Kerberos
On Wed, 2010-09-08 at 23:38 -0500, Dan White wrote:
On 09/09/10 12:17 +0800, Wouter van Marle wrote:
Anyway I have changed my userPassword field (using GQ) to
{sasl}wou...@squirrel
It still doesn't work of course.
Also not when I set it to {SASL}wouter
In syslog I found the following error related to my attempt to open the
address book in evolution:
Sep 9 12:15:32 acorn slapd[15925]: conn=14 op=43 SEARCH RESULT tag=101
err=0 nentries=59 text=
Sep 9 12:15:39 acorn slapd[15925]: conn=135 fd=54 ACCEPT from
IP=192.168.2.4:39863 (IP=0.0.0.0:389)
Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 BIND
dn=uid=wouter,ou=People,dc=squirrel method=128
Sep 9 12:15:39 acorn slapd[15925]: SASL [conn=135] Failure: cannot
connect to saslauthd server: Permission denied
Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 RESULT tag=97 err=49
text=
So there is something in saslauthd that does not accept connections from
slapd. Now the big question is why? As I have no idea where to start
searching for this.
Wouter.
You're close.
On Debian/Ubuntu, do:
adduser openldap sasl
# adduser openldap sasl
Adding user `openldap' to group `sasl' ...
Adding user openldap to group sasl
Done.
The issue is that the /var/run/saslauthd directory, where the
saslauthd unix socket is located, is only accessible by group 'sasl' (and
root).
True:
drwx--x--- 2 root sasl 4096 2010-09-09 10:14 saslauthd
Still the same permission denied error message in syslog!
Wouter.
