openldap-technical May 2008

openldap-technical@openldap.org

62 participants
56 discussions

OpenSSL clients connect over TLS, GnuTLS clients cannot.
by Ben Goldsbury 20 May '08

20 May '08

Hello, I'm having a problem getting TLS connections working properly when clients of the server are built against GnuTLS. When clients are built against OpenSSL, TLS connections work properly. If OpenLDAP is built against GnuTLS, TLS connections fail with this error (some debug included): TLS: peer cert untrusted or revoked (0x42) ldap_err2string ldap_start_tls: Connect error (-11) For testing, I've tried the following setups. Each use the same configuration: GnuTLS (client) -> GnuTLS (server) = failure OpenSSL (client) -> GnuTLS (server) = success GnuTLS (client) -> OpenSSL (server) = failure OpenSSL (client) -> OpenSSL (server) = success Also, I have used GnuTLS's testing tools (gnutls-serv and gnutls-cli) to verify that GnuTLS is working properly with the certificate. gnutls-serv \ --x509certfile /etc/ssl/my_ssl/server.key \ --x509keyfile /etc/ssl/my_ssl/server.crt gnutls-cli \ --x509cafile /etc/ssl/certs/ca-certificates.crt \ -p 5556 \ ldapserver.mydomain.com GnuTLS output: - Peer's certificate is trusted - Version: TLS1.1 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed Versions used: GnuTLS 2.2.1 OpenSSL 0.9.8c OpenLDAP 2.4.9 Does anyone have any ideas whats going on, or any idea how to troubleshoot this further? Is this something that should go to the openldap-bugs mailing list? Thank you.

2 1

tls issues with clients
by Kyle Corupe 20 May '08

20 May '08

I'm pretty confused, because my clients are setup with almost identical configs, and the server(localhost), and one of my client PC's can connect and use SSL (ldapsearch -H ldaps://heracross.corpedia.internal/ -b dc=corpedia,dc=internal -x -Z), and it returns the correct results, and I can see it using TLS in the slapd log. I copied the same configs to both boxes /etc/ldap.conf ---- #host heracross.corpedia.internal base dc=corpedia,dc=internal uri heracross.corpedia.internalheracross.corpedia.internal ldap://heracross.corpedia.internal/ binddn cn=root,dc=corpedia,dc=internal bindpw ***************** scope sub bind_policy hard nss_base_passwd dc=corpedia,dc=internal?sub nss_base_shadow dc=corpedia,dc=internal?sub nss_base_group dc=corpedia,dc=internal?sub pam_password md5 ssl yes tls_cacertdir /etc/openldap/cacerts ----- I see the following in my slapd error log as I connect as one of the nonworking boxes root@kyle-laptop:/etc/ldap# ldapsearch -H ldaps://heracross.corpedia.internal/ -b dc=corpedia,dc=internal -x -Z ldap_start_tls: Can't contact LDAP server (-1) ldap_bind: Can't contact LDAP server (-1) ----- connection_get(14): got connid=25 connection_read(14): checking for input on id=25 TLS trace: SSL_accept:before/accept initialization TLS: can't accept. connection_read(14): TLS accept failure error=-1 id=25, closing connection_closing: readying conn=25 sd=14 for close connection_close: conn=25 sd=14 ----- Here is a nopaste link for my slapd.conf file http://rafb.net/p/NHjV1a33.html -- Kyle Corupe Unix Administrator Corpedia Corporation 2020 North Central Avenue, Suite 1050 Phoenix, Arizona 85004-4576 Desk:(602)443-2148 Cell: (623)261-2874 kcorupe(a)corpedia.com

3 4

Help with ACL's for userPassword updates
by Martin Benson 20 May '08

20 May '08

Hi I need some help with the Access Control Lists in my slapd.conf file. I need to allow myself to update a user's password for when they forget their password. With no ACL's in place I can do this using a ldapmodify command that authenticates as "cn=Manager,dc=example,dc=com". I normally have the following in my ACL's: access to attrs=userPassword by self write by anonymous auth by * none access to * by * read What do I need to do to change this to allow the manager to change the userPassword attribute. Thanks Martin Benson

2 1

ldap automount maps loading problem
by Rodrigo Castro 20 May '08

20 May '08

Can anyone tell me what's wrong with the following? May 20 08:59:08 localhost automount[20128]: starting automounter version 4.1.4, path = /home, maptype = ldap, mapname = squid.prof.inf.ufes.br: ou=auto.home,o=inf.ufes.br May 20 08:59:08 localhost automount[20128]: lookup(ldap): server = " squid.prof.inf.ufes.br", port = 389, base dn = "ou=auto.home,o=inf.ufes.br" May 20 08:59:08 localhost automount[20128]: mount(bind): bind_works = 1 May 20 08:59:08 localhost automount[20128]: using kernel protocol version 4.07 May 20 08:59:08 localhost automount[20128]: using timeout 300 seconds; freq 75 secs May 20 08:59:08 localhost automount[20128]: lookup(ldap): searching for "(objectclass=nisObject)" under "ou=auto.home,o=inf.ufes.br" May 20 08:59:08 localhost automount[20128]: lookup(ldap): query succeeded, no matches for (objectclass=nisObject) May 20 08:59:08 localhost automount[20128]: lookup(ldap): searching for "(objectclass=automount)" under "ou=auto.home,o=inf.ufes.br" May 20 08:59:08 localhost automount[20128]: lookup(ldap): examining entries May 20 08:59:08 localhost automount[20128]: lookup(ldap): done updating map May 20 08:59:08 localhost automount[20128]: failed to load map, exiting May 20 08:59:08 localhost automount[20128]: rm_unwanted: /home May 20 08:59:08 localhost automount[20128]: umount_multi: path=/home incl=0 May 20 08:59:08 localhost automount[20128]: umount_multi: no mounts found under /home Here's a part of my ldif: dn: ou=auto.master,o=inf.ufes.br objectClass: top objectClass: automountMap ou: auto.master dn: ou=auto.home,o=inf.ufes.br objectClass: top objectClass: automountMap ou: auto.home dn: cn=/,ou=auto.home,o=inf.ufes.br objectClass: automount cn: / automountInformation: -fstype=nfs,hard,intr,nodev squid.prof.inf.ufes.br: /home/& dn: cn=/home,ou=auto.master,o=inf.ufes.br objectClass: automount cn: /home automountInformation: ldap squid.prof.inf.ufes.br:ou=auto.home,o=inf.ufes.br -- __________________________________ Rodrigo de Castro Cosme Ciência da Computação - Universidade Federal do Espírito Santo Suporte mailing list - suporte(a)inf.ufes.br MSN - rdccosmo(a)gmail.com

1 0

AW: Help with ACL's for userPassword updates
by Kick, Claus 20 May '08

20 May '08

Hello Martin, The rootdn can always change everything everywhere. So, I guess you should use the root dn to do that. You ACL simply says that only the user himself/herself can change the password. Best regards, Claus ________________________________ Von: openldap-technical-bounces+claus.kick=siemens.com(a)OpenLDAP.org [mailto:openldap-technical-bounces+claus.kick=siemens.com@OpenLDAP.org] Im Auftrag von Martin Benson Gesendet: Sonntag, 18. Mai 2008 20:17 An: openldap-technical(a)openldap.org Betreff: Help with ACL's for userPassword updates Hi I need some help with the Access Control Lists in my slapd.conf file. I need to allow myself to update a user's password for when they forget their password. With no ACL's in place I can do this using a ldapmodify command that authenticates as "cn=Manager,dc=example,dc=com". I normally have the following in my ACL's: access to attrs=userPassword by self write by anonymous auth by * none access to * by * read What do I need to do to change this to allow the manager to change the userPassword attribute. Thanks Martin Benson

1 0

slapo-chain - can't get it working
by Richard Nelson 19 May '08

19 May '08

I sent this two days ago, from an unsubscribed account and it still hasn't shown up... don't know if moderation is hampered, or if it just didn't make through... I have the basics covered - 1 master, 4 syncrepl slaves (going to 2-3 MM, 1-2 slaves). This setup has been working quite well - supporting AIX, Linux user data, Samba PDC/BDCs, and Kerberos (slapd 2.4.7 Debian Sid/unstable) The only issue I have now, is having to find the master to perform any updates. I'd like to use slapo-chain so that update referrals are automatically handled, especially since so little stuff supports referrals - even things that should. There are a few examples here and there, and unfortunately, some of them contradict others (probably written to different ldap levels). As an example of my plight, here is the output of ldappasswd on a slave machine (ldapmodify shows the same issue, but isn't as easy to show) # # on the slave, when trying a ldappasswd: $ ldappasswd -Ydigest-md5 -w<my passwd> SASL/DIGEST-MD5 authentication started SASL username: renegade SASL SSF: 128 SASL data security layer installed. Result: Referral (10) Referral: ldap://ldap-master.cobpli.svl.ibm.com # # The following is the slave ldap trace, and there is *no* traffic to the master... conn=0 op=1 BIND authcid="renegade(a)COBPLI.SVL.IBM.COM" authzid="renegade(a)COBPLI.SVL.IBM.COM" conn=0 op=1 BIND dn="uid=renegade,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 conn=0 op=1 RESULT tag=97 err=0 text= conn=0 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=0 op=2 PASSMOD conn=0 op=2 RESULT oid= err=10 text= # # The basics work: $ ldapwhoami SASL/GSSAPI authentication started SASL username: renegade(a)COBPLI.SVL.IBM.COM SASL SSF: 56 SASL data security layer installed. dn:uid=renegade,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com # # Proxy authentication works: $ ldapwhoami -Uproxy -Ydigest-md5 -w<passwd> -Xu:cowboy SASL/DIGEST-MD5 authentication started SASL username: u:cowboy SASL SSF: 128 SASL data security layer installed. dn:uid=cowboy,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com # # Here is the likely relevant ldap sections (chain overlay, syncprop, updatref): # overlay chain chain-uri "ldap://ldap-master.cobpli.svl.ibm.com/" # Neither of these lines make a difference chain-rebind-as-user TRUE #chain-rebind-as-user FALSE # Here, I've tried simple/sasl, varied saslmech, etc... chain-idassert-bind bindmethod="simple" saslmech=digest-md5 authz=proxyauthz binddn="uid=proxy,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com" credentials="<passwd>" mode=self chain-idassert-authzFrom "*" syncrepl rid=1 provider=ldap://ldap-master.cobpli.svl.ibm.com/ starttls=no binddn="cn=Replicator,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" bindmethod=simple credentials=<passwd> searchbase="dc=cobpli,dc=svl,dc=ibm,dc=com" schemaChecking=off type=refreshAndPersist retry="10 10 300 +" updateref ldap://ldap-master.cobpli.svl.ibm.com/

5 10

global email address
by J. Manuel Velasco - UBILIBET 19 May '08

19 May '08

Hello, I am using postfix with ldap. There is one special emaill address called tots(a)ubilibet.com to send mails for everybody, but two nre users I added don't receive mails from this address. I have checked the configuration of ldap to other users and postfix aliases, but i can't see anything regarding to this email address. What can i check more, please ? Thanks in advance. --

1 0

OpenLDAP + Kerberos = Crash?
by Andrew Wiley 18 May '08

18 May '08

I sent this twice before realizing I was sending from another email address that isn't on the list. I don't know if emails from non-subscribers are moderated or just dropped, but in any case, I'm very sorry if those emails show up on the list as duplicates. I'm trying to get a setup of Kerberos and LDAP working. LDAP works fine with plain authentication and everything seems to be set up correctly, but when I try to use GSSAPI authentication, slapd crashes. Application Versions: openldap 2.3.40 heimdal 1.0.1 Server log from startup to crash: May 17 21:50:07 Lagbox slapd[11161]: @(#) $OpenLDAP: slapd 2.3.40 (Jan 15 2008 23:41:27) $ nobody@tk-gwa:/build/src/openldap-2.3.40/servers/slapd May 17 21:50:07 Lagbox slapd[11161]: /etc/openldap/slapd.conf: line 139: "attr" is deprecated (and undocumented); use "attrs" instead. May 17 21:50:07 Lagbox slapd[11161]: /etc/openldap/slapd.conf: line 144: "attr" is deprecated (and undocumented); use "attrs" instead. May 17 21:50:07 Lagbox slapd[11162]: bdb_db_open: unclean shutdown detected; attempting recovery. May 17 21:50:07 Lagbox slapd[11162]: bdb_db_open: Warning - No DB_CONFIG file found in directory /var/lib/openldap/openldap-data: (2) Expect poor performance for suffix dc=wileynetworks,dc=org. May 17 21:50:07 Lagbox slapd[11162]: slapd starting May 17 21:51:04 Lagbox slapd[11162]: conn=0 fd=14 ACCEPT from IP= 127.0.0.1:54066 (IP=0.0.0.0:389) May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=0 SRCH attr=supportedSASLMechanisms May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=1 BIND dn="" method=163 May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=1 RESULT tag=97 err=14 text= May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=2 BIND dn="" method=163 May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=2 RESULT tag=97 err=14 text= May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=3 BIND dn="" method=163 May 17 21:51:05 Lagbox slapd[11165] general protection eip:b7abeb05 esp:b6c80df0 error:0 Search command that causes crash: [arew264@Lagbox ~]$ ldapsearch -H ldap://localhost/ -b dc=wileynetworks,dc=org SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) [arew264@Lagbox ~]$ Attached: slapd.conf Note: I am leaving all names intact here because this is a test setup and not any sort of production server. The user that ran the search command is in kerberos and had run kinit and gotten a ticket before running the search. With just a crash and no error messages, I don't know where to start in tracking this down. Andrew Wiley

1 0

openldap and heimdal persistent connection
by Brian Thompson 18 May '08

18 May '08

Hello, We're currently running openldap 2.2.20 with the back-hdb ldap backend. It's being used as a proxy to forward ldapi queries from heimdal 0.6.3's ldap backend to a Sun Directory Server 5.2 which doesn't natively support ldapi. It seems that the connection is persistent such that restarting the Sun Directory Server requires us to then restart openldap in order to make heimdal work properly again. Is there any way around this so that openldap doesn't require restarting each time someone restarts the Sun dierctory? Thanks for any info. -Brian

2 1

Re: Lgoin failed if URI in client's ldap.conf is used
by Luke Lee 16 May '08

16 May '08

I corrected the typo but the problem persists. If I use the HOST directive, the problem appears to go away. What else shall I check? Please advice. Thanks. Luke ----- Original Message ---- From: Pierangelo Masarati <ando(a)sys-net.it> To: Luke Lee <leeluke77(a)yahoo.com> Cc: openldap-technical(a)openldap.org Sent: Friday, May 16, 2008 2:52:22 PM Subject: Re: Lgoin failed if URI in client's ldap.conf is used > I am running OpenLDAP 2.3.39 on a RedHat server. I am encountering a user > ssh login failure on an LDAP client if I use the URI based way to specify > the LDAP servers in the client's /etc/ldap.conf and > /etc/openldap/ldap.conf files. I don't have such a problem if I use the > host based way. A snip of the configurations and the ldap.log on the ldapm > is the following: > /etc/ldap.conf: > uri ldap://ldapm.mydomain.com ldap://ldapsl.mydomain.com > /etc/openldap/ldap.conf: > URI ldap://ldapm.mydomain.com ldap://ldapsl..mydomain.com There's probably a typo in the last URI above; don't know if it's related to your issue, though > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: > cn=admin,dc=mydomain,dc=com > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: * > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [4] applying read(=rscxd) > (stop) > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [4] mask: read(=rscxd) > May 16 14:16:33 ldapm slapd[27604]: => access_allowed: read access granted > by read(=rscxd) > May 16 14:16:33 ldapm slapd[27604]: => access_allowed: read access to > "uid=luke_l,ou=People,dc=mydomain,dc=com" "uid" requested > May 16 14:16:33 ldapm slapd[27604]: => acl_get: [2] attr uid > May 16 14:16:33 ldapm slapd[27604]: access_allowed: no res from state > (uid) > May 16 14:16:33 ldapm slapd[27604]: => acl_mask: access to entry > "uid=luke_l,ou=People,dc=mydomain,dc=com", attr "uid" requested > May 16 14:16:33 ldapm slapd[27604]: => acl_mask: to value by "", (=0) > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: self > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: > cn=admin,dc=mydomain,dc=com > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: * > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [4] applying read(=rscxd) > (stop) > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [4] mask: read(=rscxd) > May 16 14:16:33 ldapm slapd[27604]: => access_allowed: read access granted > by read(=rscxd) > May 16 14:16:33 ldapm slapd[27604]: => access_allowed: read access to > "uid=luke_l,ou=People,dc=mydomain,dc=com" "userPassword" requested > May 16 14:16:33 ldapm slapd[27604]: => acl_get: [1] attr userPassword > May 16 14:16:33 ldapm slapd[27604]: access_allowed: no res from state > (userPassword) > May 16 14:16:33 ldapm slapd[27604]: => acl_mask: access to entry > "uid=luke_l,ou=People,dc=mydomain,dc=com", attr "userPassword" requested > May 16 14:16:33 ldapm slapd[27604]: => acl_mask: to value by "", (=0) > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: self > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: anonymous > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [2] applying auth(=xd) > (stop) > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [2] mask: auth(=xd) > May 16 14:16:33 ldapm slapd[27604]: => access_allowed: read access denied > by auth(=xd) > May 16 14:16:33 ldapm slapd[27604]: send_search_entry: conn 35 access to > attribute userPassword, value #0 not allowed You only have "auth" access to the userPassword attribute (which sounds reasonable) but the client is trying to "read" the password. I suspect a misconfiguration of the client, which tries to auth by internally comparing userPassword values instead of using an LDAP bind operation. > May 16 14:16:33 ldapm slapd[27604]: => access_allowed: read access to > "uid=luke_l,ou=People,dc=mydomain,dc=com" "shadowLastChange" requested > May 16 14:16:33 ldapm slapd[27604]: => acl_get: [2] attr shadowLastChange > May 16 14:16:33 ldapm slapd[27604]: access_allowed: no res from state > (shadowLastChange) > May 16 14:16:33 ldapm slapd[27604]: => acl_mask: access to entry > "uid=luke_l,ou=People,dc=mydomain,dc=com", attr "shadowLastChange" > requested > May 16 14:16:33 ldapm slapd[27604]: => acl_mask: to value by "", (=0) > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: self > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: > cn=admin,dc=mydomain,dc=com > May 16 14:16:33 ldapm slapd[27604]: <= check a_dn_pat: * > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [4] applying read(=rscxd) > (stop) > May 16 14:16:33 ldapm slapd[27604]: <= acl_mask: [4] mask: read(=rscxd) > May 16 14:16:33 ldapm slapd[27604]: => access_allowed: read access granted > by read(=rscxd) > > Can anyone please help resolve the above problem? Thanks a lot! p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2008