openldap-technical July 2009

openldap-technical@openldap.org

68 participants
73 discussions

Reg OpenLdap on Ubuntu
by Asimananda Mohanty 22 Sep '09

22 Sep '09

Hi All, I am currently busy configuring OpenLdap on my newly installed Ubuntu 9.04. Here is what I have done till now. I followed the steps defined in https://help.ubuntu.com/8.10/serverguide/C/openldap-server.html and installation was successful. I installed PhpLdapAdmin also. After I created certificate, key etc, I created a .ldif file (enable-ca.ldif) with the following content : *dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/server.crt - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/server.key* Then I executed the command : *ldapmodify -D "cn=admin,cn=config" -x -w 12345678 -f enable-ca.ldif* and it was a success. But after this, when I tried to restart slapd, I got errors like the following : *main: TLS init def ctx failed: -1* I noticed that after I executed "ldapmodify -D "cn=admin,cn=config" -x -w 12345678 -f enable-ca.ldif", 3 lines are added to /etc/ldap/slapd.d/cn=config.ldif and when I commented the last two lines like the following, slapd started successfully. *olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem #olcTLSCertificateFile: /etc/ssl/certs/server.crt #olcTLSCertificateKeyFile: /etc/ssl/private/server.key* This looks quite strange. Please help me resolving the same. -Asimananda

6 48

Forced password change not allowed
by mlb＠imparisystems.com 20 Sep '09

20 Sep '09

I've got openLDAP running and installed the pam and nss libraries so it would also control the Linux passwords. I'm trying to sign onto my server using ssh - but once I enter my username and password, I get WARNING: Your password has expired. You must change your password now and login again! Enter login(LDAP) password: Now being a bad security person, I always use the exact same username / password combination and they don't work. If a use either nothing (just hit Enter) or if I put in the standard password I get passwd: Authentication information cannot be recovered passwd: password unchanged Connection to ubuntu closed. If I enter in some nonsensical string I get LDAP Password incorrect: try again Enter login(LDAP) password: However, that is the only root level user on the machine and I have TONS of stuff on it. How do I fix? Is this an openLDAP issue or something else? Thanks

3 2

SASL LDAP binding over IPv6
by Xu, Qiang (FXSGSC) 07 Aug '09

07 Aug '09

Hi, all: In using ldapsearch to bind to a server with IPv6 address, some error pops up: =========================================================== qxu@durian(pts/3):/etc[133]$ kinit XCTEST100(a)XCIPV6.COM Password for XCTEST100(a)XCIPV6.COM: qxu@durian(pts/3):/etc[134]$ klist Ticket cache: FILE:/tmp/krb5cc_20153 Default principal: XCTEST100(a)XCIPV6.COM Valid starting Expires Service principal 06/09/09 17:35:18 06/10/09 03:34:41 krbtgt/XCIPV6.COM(a)XCIPV6.COM renew until 06/10/09 17:35:18 qxu@durian(pts/3):/etc[135]$ ldapsearch -Y GSSAPI -H 'ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail Could not create LDAP session handle for URI=ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c (-9): Bad parameter to an ldap routine qxu@durian(pts/3):/etc[136]$ ldapsearch -Y GSSAPI -H 'ldap://[3ffe:2000:0:1:e0be:1872:d4f8:6b2c]' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database) =========================================================== Shall I add the brackets [] around the IPv6 address? DNS server has been correctly set up, because sasl binding over IPv4 address is good. Any possible reason for the failure of ldapsearch? Thanks, Xu Qiang

3 20

force creation of a "glue" node in the database?
by Robert Hanson 31 Jul '09

31 Jul '09

Using 2.4.16 on RedHat Linux. Does anyone know of a way to force the creation of a "glue" node in ldap? Here is the scenario: For some (as yet unknown) reason, our database sometimes has "glue" nodes. I'm suspecting this relates to syncrepl, but have not been able to diagnose the problem yet. I'm working on adding the manageDSAit control to our server requests (using the c client interface). I'd like a way to test this automatically. One way to do that would be to have the test program create a "glue" node and see that it can be found by the client code. I can't find a way to get the glue node created; I'm always getting a error 65 invalid structural object class chain.

1 0

lastmod in slapd.conf
by Srinidhi Sharma 31 Jul '09

31 Jul '09

Hi, Is it possible to detect using JNDI api's if the lastmod is turned on in Open-ldap slapd.conf file ? any pointers would be helpful. -- Thanks, Srinidhi

2 1

RE: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
by Robert Hanson 31 Jul '09

31 Jul '09

What I need is to have the "glue" items returned as part of the search. It looks to me like I can get nodes that are "glue" nodes to be part of the results by commenting out these lines: in src\servers\slapd\back-bdb\search.c, lilnes 908-91 if ( !manageDSAit && is_entry_glue( e )) { goto loop_continue; } If I comment out these lines, then I get the results I'm looking for. Are there any other implications to the "glue" nodes? It looks like I'm able to edit and delete these nodes as well. But there is code in delete.c, modify.c, modrdn.c that worry about glue nodes. Another option would be to redefine the is_entry_glue macro to always return false. Is that a better approach? ________________________________ From: Robert Hanson Sent: Thursday, July 30, 2009 11:08 AM To: 'openldap-technical(a)openldap.org' Subject: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16) Is this bug ITS#4626? Or is there a workaround? ==== Using a build of 2.4.16 on RedHat linux; in a multi-master environment with 2 nodes. On both nodes, I have a tree that has a node "ou=Company, o=MyCompanyName". Under that are several nodes that are "glue" nodes. Following those is a actual data node. Slapd 2.4.16, built from source, running on redhat linux) I have seen this occur several times on various test systems with similar configurations. The data in these nodes is inserted, in the proper order, (parent then children) using ldap client calls (ldap_add_s). Later, when I go to look at the output of slapcat, I see that some nodes are replaced with "glue" nodes. Questions: 1) Why are these glue nodes created? Is there a known bug that will cause existing nodes to be deleted without the children being deleted? Is this an issue in replication? (where syncrepl needs to create a node where the parent does not exist). Is that why the glue nodes are created later? 2) How can I change the "glue" to some other class? Can that be done programmatically? 3) ======== This is a dump of slapcat (with unnecessary nodes removed) dn: o=MyCompanyName objectClass: organization o: MyCompanyName structuralObjectClass: organization entryUUID: feb5b352-2eb7-102d-8c1f-f1b463e2c47e creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20081015034921Z entryCSN: 20081015034921.418938Z#000000#000#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20081015034921Z contextCSN: 20090728202448.877262Z#000000#001#000000 contextCSN: 20090728202123.336320Z#000000#002#000000 dn: ou=Company,o=MyCompanyName ou: Company description: 3.0.0 objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: feb7a41e-2eb7-102d-8c28-f1b463e2c47e creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20081015034921Z entryCSN: 20081015034921.432024Z#000000#000#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20081015034921Z dn: lcc=Call Center 1,ou=Company,o=MyCompanyName entryUUID: 0136f8e0-0ff7-102e-8da5-59a5102cad9a creatorsName: cn=Client,ou=People,o=MyCompanyName createTimestamp: 20090728191715Z objectClass: top objectClass: glue structuralObjectClass: glue entryCSN: 20090728202123.336320Z#000000#002#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20090728202123Z dn: ou=Servers,lcc=Call Center 1,ou=Company,o=MyCompanyName entryUUID: 014e7632-0ff7-102e-8db3-59a5102cad9a creatorsName: cn=Client,ou=People,o=MyCompanyName createTimestamp: 20090728191715Z objectClass: top objectClass: glue structuralObjectClass: glue entryCSN: 20090728202123.336320Z#000000#002#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20090728202123Z dn: ou=Application Data,lcc=Call Center 1,ou=Company,o=MyCompanyName entryUUID: e5a152de-0fff-102e-923c-cf0948a0ceb1 creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20090728202054Z objectClass: top objectClass: glue structuralObjectClass: glue entryCSN: 20090728202123.336320Z#000000#002#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20090728202123Z dn: appName=Configurations,ou=Application Data,lcc=Call Center 1,ou=Company,o= MyCompanyName entryUUID: e5a299f0-0fff-102e-923d-cf0948a0ceb1 creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20090728202054Z structuralObjectClass: applicationUnit appName: Configurations objectClass: applicationUnit entryCSN: 20090728202143.649526Z#000000#001#000000 modifiersName: cn=Client,ou=People,o=MyCompanyName modifyTimestamp: 20090728202143Z

3 3

entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
by Robert Hanson 30 Jul '09

30 Jul '09

Is this bug ITS#4626? Or is there a workaround? ==== Using a build of 2.4.16 on RedHat linux; in a multi-master environment with 2 nodes. On both nodes, I have a tree that has a node "ou=Company, o=MyCompanyName". Under that are several nodes that are "glue" nodes. Following those is a actual data node. Slapd 2.4.16, built from source, running on redhat linux) I have seen this occur several times on various test systems with similar configurations. The data in these nodes is inserted, in the proper order, (parent then children) using ldap client calls (ldap_add_s). Later, when I go to look at the output of slapcat, I see that some nodes are replaced with "glue" nodes. Questions: 1) Why are these glue nodes created? Is there a known bug that will cause existing nodes to be deleted without the children being deleted? Is this an issue in replication? (where syncrepl needs to create a node where the parent does not exist). Is that why the glue nodes are created later? 2) How can I change the "glue" to some other class? Can that be done programmatically? 3) ======== This is a dump of slapcat (with unnecessary nodes removed) dn: o=MyCompanyName objectClass: organization o: MyCompanyName structuralObjectClass: organization entryUUID: feb5b352-2eb7-102d-8c1f-f1b463e2c47e creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20081015034921Z entryCSN: 20081015034921.418938Z#000000#000#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20081015034921Z contextCSN: 20090728202448.877262Z#000000#001#000000 contextCSN: 20090728202123.336320Z#000000#002#000000 dn: ou=Company,o=MyCompanyName ou: Company description: 3.0.0 objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: feb7a41e-2eb7-102d-8c28-f1b463e2c47e creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20081015034921Z entryCSN: 20081015034921.432024Z#000000#000#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20081015034921Z dn: lcc=Call Center 1,ou=Company,o=MyCompanyName entryUUID: 0136f8e0-0ff7-102e-8da5-59a5102cad9a creatorsName: cn=Client,ou=People,o=MyCompanyName createTimestamp: 20090728191715Z objectClass: top objectClass: glue structuralObjectClass: glue entryCSN: 20090728202123.336320Z#000000#002#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20090728202123Z dn: ou=Servers,lcc=Call Center 1,ou=Company,o=MyCompanyName entryUUID: 014e7632-0ff7-102e-8db3-59a5102cad9a creatorsName: cn=Client,ou=People,o=MyCompanyName createTimestamp: 20090728191715Z objectClass: top objectClass: glue structuralObjectClass: glue entryCSN: 20090728202123.336320Z#000000#002#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20090728202123Z dn: ou=Application Data,lcc=Call Center 1,ou=Company,o=MyCompanyName entryUUID: e5a152de-0fff-102e-923c-cf0948a0ceb1 creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20090728202054Z objectClass: top objectClass: glue structuralObjectClass: glue entryCSN: 20090728202123.336320Z#000000#002#000000 modifiersName: cn=MyDivision,ou=People,o=MyCompanyName modifyTimestamp: 20090728202123Z dn: appName=Configurations,ou=Application Data,lcc=Call Center 1,ou=Company,o= MyCompanyName entryUUID: e5a299f0-0fff-102e-923d-cf0948a0ceb1 creatorsName: cn=MyDivision,ou=People,o=MyCompanyName createTimestamp: 20090728202054Z structuralObjectClass: applicationUnit appName: Configurations objectClass: applicationUnit entryCSN: 20090728202143.649526Z#000000#001#000000 modifiersName: cn=Client,ou=People,o=MyCompanyName modifyTimestamp: 20090728202143Z

1 0

Radius authentication and storing passwords in cleartext
by Eric Bourkland 29 Jul '09

29 Jul '09

I have zimbra openLDAP v2.3.43 running on RHEL4.7 ES and I am trying to connect our freeRadius server to authenitcate against LDAP. I have also being trying to stand up plane openLDAP v2.4.17 to see if I can get that to work. Free Radius requires PEAP/CHAPv2 to authenticate, which means it needs to be handed a clear text password in order to work. Yes, I know in general this is not a good idea. How can I configure openLDAP to store passwords (userpassword attribute) in cleartext. Or at the very least create a script that will be able to take the encrypted password and store it in cleartext as another attribute. Thanks,

5 4

Member-of plugin support for nested membership
by Mathias Gug 29 Jul '09

29 Jul '09

Hi, While discussing the possibility of using openldap in place of 389 directory in the FreeIPA project [1] the following technical detail was mentioned. [1]: https://www.redhat.com/archives/freeipa-devel/2009-July/msg00333.html According to the memberof overlay man page: The memberof overlay to slapd(8) allows automatic reverse group member‐ ship maintenance. Any time a group entry is modified, its members are modified as appropriate in order to keep a DN-valued "is member of" attribute updated with the DN of the group. Does the memberOf overlay deal with nested membership? Or is it strictly a 1:1 relationship (forward pointer, reverse pointer)? The 389 memberOf plug-in maintains reverse pointers for inherited membership which IPA takes advantage of. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com

1 0

Re: get_ava: illegal value with translucent proxy
by Petteri Heinonen 29 Jul '09

29 Jul '09

Pierangelo Masarati [masarati(a)aero.polimi.it] kirjoitti: > Petteri Heinonen wrote: > > Pierangelo Masarati [masarati(a)aero.polimi.it] wrote: > >> Petteri Heinonen wrote: > >> > Hi, I've setup a translucent proxy. Now, I have tried to do some > >> test > searches. For example this works ok: > >> > > ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b > > >> "OU=Users,OU=Department,DC=company,DC=com" "(givenName=Myname)" > >> > > Search is proxied through proxy to the actual server, and correct > >> result > is returned. However, if I try this: > >> > > ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b > > >> "OU=Users,OU=Department,DC=company,DC=com" "(objectClass=User)" > >> > > I get no results. I have monitored the traffic between proxy and > >> backend > server, and the query is not even sent there. In OpenLDAP > >> log there is: > >> > > Jul 27 15:51:00 ldaptr01 slapd[17772]: begin get_filter > >> > Jul 27 15:51:00 ldaptr01 slapd[17772]: EQUALITY > >> > Jul 27 15:51:00 ldaptr01 slapd[17772]: get_ava: illegal value for > > >> attributeType objectClass > >> > Jul 27 15:51:00 ldaptr01 slapd[17772]: end get_filter 0 > >> > > What would be the problem here? > >> > >> The objectClass "User" is not defined in the proxy's schema? > >> > >> p. > >> > > > > That's correct. But in translucent overlay's documentation, there is: > > > > "Note: The Translucent Proxy overlay will disable schema checking in the > > local database, so that an entry consisting of overlay attributes need > > not adhere to the complete schema." > > > > But it seems that schema checking is still in affect when doing > > searches. Is there a way to disable local schema checking altogether? Or > > do I have to build some dummy schema so that OpenLDAP is aware about > > objectClasses I want to search for? > > What happens is that you use unknown schema items in the *filter*, which > requires it to be known in order to apply appropriate matching rules and > so. The schema relaxation in the documentation refers to enforcing > adherence with allowed and required attributes of an objectclass, and > with stored objectclasses complying with structural inheritance > relationship. Schema items need to be known anyway. > > p. > Ok, thanks for the clarification. I guess that my goal to have an Active Directory proxied properly is not going to happen. I would need a complete AD schema for OpenLDAP, and that's probably now available anywhere.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2009