openldap-software

openldap-software@openldap.org

2719 discussions

OpenLDAP 2.4.11 + Syncrepl + RWM
by Alan Evans 30 Dec '08

30 Dec '08

I am using OpenLDAP 2.4.11 with all overlays and all backends compiled. My company is in the middle if rebuilding our LDAP environment and we would like to use OpenLDAP + Syncrepl + RWM to neatly move objects into their new places within the DIT. Our old DIT looks like: ou=people,dc=company,dc=com uid=abc_jsmith uid=abc_jdoe uid=xyz_hsmith uid=xyz_dsmith Our new DIT looks like: ou=users,o=abc,dc=company,dc=com uid=abc_jsmith uid=abc_jdoe ou=users,o=xyz,dc=company,dc=com uid=xyz_hsmith uid=xyz_dsmith There are about 3100 objects in the ou=people container and we have several hundred clients to the current ldap setup so we will not be able to migrate all in one night. We are setting the new DIT/servers up in paralell to the old and would like to use syncrepl on the new servers to pull in objects from the old DIT and use syncrepl to find their new place in the tree. At the moment we are testing this setup in a lab enviornment so I am using another backend to represent the old DIT. Here's what my config looks like: ... snip ... database ldif suffix ou=people,dc=company,dc=com directory /var/lib/ldap/people rootdn "cn=Manager,ou=people,dc=company,dc=com" rootpw ******* overlay rwm rwm-rewriteEngine on rwm-rewriteContext default rwm-rewriteRule "(uid=abc_.+),ou=people,dc=company,dc=com$" "$1,ou=users,o=abc,dc=company,dc=com" database bdb suffix "dc=company,dc=com" rootdn "cn=Manager,dc=company,dc=com" rootpw ******** syncrepl rid=002 provider=ldap://localhost/ bindmethod=simple binddn="cn=Manager,dc=company,dc=com" credentials=******** searchbase="ou=people,dc=company,dc=com" schemachecking=off type=refreshOnly starttls=yes tls_reqcert=allow retry="60 +" ... snip ... The ldif backend works as expected, if I do: ldapsearch -x uid=abc_\* -b ou=people,dc=company,dc=com I get nicely translated DNs and if I save the output to a file and ldap add it to the new DIT I get users where they belong. But, I am not getting synchronization. I know I am missing something, probably more RWM rules. Maybe instead of doing the rewrites on the 'old' backend I should be doing them on the 'new' backend as the data comes into syncrepl? I am also thinking that the searchbase in the syncrepl clause is part of the problem, I am telling it to sync ou=people and its getting ou=users,o=abc back so it should probably ignore them correct? Can anyone steer me in the right direction?

3 3

Using UPN notation for LDAPbind
by Wilhelm Meier 27 Dec '08

27 Dec '08

Hi all, is there a way to use the UPN (user(a)domain.com) notation to do a bind to the OpenLDAP-Server. Or do I have to use the rwm-overlay to map the bind-string to a valid DN? -- Wilhelm

3 7

LDAP+MySQL vs LDAP+Berkley
by Luis Daniel Lucio Quiroz 27 Dec '08

27 Dec '08

Hi There , happy XMAS I wonder if any one has comments about advantages and disadvantages of using MySQL and BDB backend. Happy X+ LD

2 1

Sync control missing?
by Sean Loaring 20 Dec '08

20 Dec '08

Hello, I've been working on some ldap client software that is supposed to make changes in some third party software whenever changes are made to certain ldap data. I've been trying to get sync working with OpenLDAP, but the 1.3.6.1.4.1.4203.1.9.1.1 control seems to be missing. Slapd version: 2.3.30-5+etch2 Output from ldapsearch -y $LDAP_PASSFILE -xW -D "$LDAP_USER" -b "" -s base '' supportedExtension supportedControl supportedFeatures # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: supportedExtension supportedControl supportedFeatures # # dn: supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Output from ldapsearch -s one -y $LDAP_PASSFILE -xW -D "$LDAP_USER" -b "$LDAP_BASE" -E '!sync=ro' dn + # extended LDIF # # LDAPv3 # base <ou=dnsclients,dc=dumpy,dc=seven> with scope oneLevel # filter: (objectclass=*) # requesting: dn + # # search result search: 2 result: 12 Critical extension is unavailable text: critical extension is not recognized # numResponses: 1 Any light that anyone can shed on this would be appreciated. Thanks, Sean

2 1

LDAP recovery question...
by Terry Haley 20 Dec '08

20 Dec '08

I'm sure you guys are getting tired of these. After rebooting my server, my LDAP database appears to be wiped out. I have several log.##### files contained within the /var/lib/ldap directory as well as .bdb files. If I remember correctly, I had an issue with the LDAP server and may have tried to delete the most recent log file at that time. However, there is a log file only a month or so old that should be ok. What are the steps I need to do in order to reinstate one of those files as my current Dbase. Thank you. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

2 1

Re: How to hide namingContext in rootDSE ?
by Thomas Chemineau 19 Dec '08

19 Dec '08

>>> 2/ How can I hide my transitional LDAP suffix in the rootDSE ? [...] > 8<-------- > access to dn.exact="" > attrs=namingContexts val/distinguishedNameMatch="o=example transitional" > by * none > access to dn.base="" by * read > 8<-------- > > The first should match when namingContexts are listed. But it doesn't, I > have read access on all values. I have inverted all ACLs, tried to apply > different scopes or more restrictive rights with some break/continue > controls, etc. [...] > Any idea ? Maybe I got it. I read the manpage of slapd.access : "Using the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval> specifies access to a particular value of a single attribute. *In this case, only a single attribute type may be given*. [...]" So, I tried with the single-value configContext attribute, and it works! So, I can not apply this rule on namingContexts because it contains multiple values ? Thomas. -- Thomas Chemineau Groupe LINAGORA - http://www.linagora.com Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29

1 0

Re: How to hide namingContext in rootDSE ?
by Thomas Chemineau 19 Dec '08

19 Dec '08

Hello, First, thank you for your help :) >> 1/ Is there a better way to do this, without rewrite V2 values ? > > Well, you can use multiple instances of back-relay instead of back-ldap, > saving transliterations of requests and responses. I don't see other > chances of rewriting the value of uniqueMember attributes. Hum. I tried to apply your suggests. But with OpenLDAP 2.3.43 (2.4.* not yet), I have a well formed "segmentation fault" ! So, for the moment, I have only one back-relay instead of two. > Probably, a solution here (for a future enhancement) would be to allow > specifying when rewriting should take place (before or after mapping?), > or simply be as liberal as possible, allowing rewriting when either > before or after an attribute will have DN syntax. You can file an ITS > for this. OK, a good idea. >> 2/ How can I hide my transitional LDAP suffix in the rootDSE ? > > Hiding values in namingContexts can be done using ACLs. What makes it > tricky is that namingContexts, by (poor?) design has no EQUALITY rule, > so if you write a rule like > > access to dn.exact="" attrs=namingContext val="o=example transitional" > by * none > > will not work. You need to specify what equality rule to use, something > like > > access to dn.exact="" > attrs=namingContext > val/distinguishedNameMatch="o=example transitional" > by * none OK. I also tried to apply this ACL. With some corrections, I have matching ACL in my OpenLDAP log. But it does not work... I have only these ACL defined : 8<-------- access to dn.exact="" attrs=namingContexts val/distinguishedNameMatch="o=example transitional" by * none access to dn.base="" by * read 8<-------- The first should match when namingContexts are listed. But it doesn't, I have read access on all values. I have inverted all ACLs, tried to apply different scopes or more restrictive rights with some break/continue controls, etc. 8<-------- Backend ACL: access to dn.base="" attrs=namingContexts val.base="o=example transitional" by * none Backend ACL: access to dn.base="" by * read Backend ACL: access to dn.base="cn=subschema" by * read [...] => access_allowed: search access to "" "objectClass" requested => dn: [1] => acl_get: [1] matched => dn: [2] => acl_get: [2] matched => acl_get: [2] attr objectClass => acl_mask: access to entry "", attr "objectClass" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => access_allowed: search access granted by read(=rscxd) => access_allowed: read access to "" "entry" requested => dn: [1] => acl_get: [1] matched => dn: [2] => acl_get: [2] matched => acl_get: [2] attr entry => acl_mask: access to entry "", attr "entry" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "" "namingContexts" requested => dn: [1] => acl_get: [1] matched acl_get: val o=example transitional => dn: [2] => acl_get: [2] matched => acl_get: [2] attr namingContexts access_allowed: no res from state (namingContexts) => acl_mask: access to entry "", attr "namingContexts" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "" "namingContexts" requested => dn: [2] => acl_get: [2] matched => acl_get: [2] attr namingContexts access_allowed: no res from state (namingContexts) => acl_mask: access to entry "", attr "namingContexts" requested => acl_mask: to value by "", (read(=rscxd)) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "" "namingContexts" requested => dn: [2] => acl_get: [2] matched => acl_get: [2] attr namingContexts access_allowed: no res from state (namingContexts) => acl_mask: access to entry "", attr "namingContexts" requested => acl_mask: to value by "", (read(=rscxd)) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => access_allowed: read access granted by read(=rscxd) 8<-------- Any idea ? Cheers, Thomas. -- Thomas Chemineau Groupe LINAGORA - http://www.linagora.com Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29

1 0

how to configure tls and ldap
by Alfonsas Stonis 17 Dec '08

17 Dec '08

Hi, I am trying to configure openldap and tls I am following instructions however, I can not start slapd http://www.openldap.org/faq/data/cache/185.html My cn\=config.ldif olcTLSCACertificateFile: /etc/ldap/ssl/demoCA/cacert.pem olcTLSCertificateFile: /etc/ldap/ssl/newcert.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/demoCA/newreq.pem root@axew0204:/home/alfas# /etc/init.d/slapd start Starting OpenLDAP: slapd - failed. The operation failed but no output was produced. For hints on what went wrong please refer to the system's logfiles (e.g. /var/log/syslog) or try running the daemon in Debug mode like via "slapd -d 16383" (warning: this will create copious output). Below, you can find the command line options used by this script to run slapd. Do not forget to specify those options if you want to look to debugging output: slapd -g openldap -u openldap -F /etc/ldap/slapd.d/ root@axew0204:/home/alfas# However there is nothing in log :( Dec 11 16:47:41 axew0204 slapd[434]: @(#) $OpenLDAP: slapd 2.4.11 (Oct 25 2008 00:04:08) $ ^Ibuildd@yellow :/build/buildd/openldap-2.4.11/debian/build/servers/slapd Dec 11 16:47:41 axew0204 slapd[434]: main: TLS init def ctx failed: -34 Dec 11 16:47:41 axew0204 slapd[434]: slapd stopped. Dec 11 16:47:41 axew0204 slapd[434]: connections_destroy: nothing to destroy. Any ideas??? Thanks. Alfas

5 8

OpenLDAP and DNS SRV records
by Matt Kowske 16 Dec '08

16 Dec '08

Hello, I have been searching google trying to find an answer to this, but have only things dated 2001 and prior. Question: Does openldap (client) support the use of SRV records to determine the availability of an ldap server? In this particular case, the openldap libraries are compiled into another unix executable and 1 of 8 AD servers is contacted via round robin DNS aliasing. Is it possible for openldap to reference the SRV record in DNS rather than the A record?

1 0

Sync replication and "*Password" attributes
by Alexey Lobanov 16 Dec '08

16 Dec '08

Hello all. I see a dumb problem trying to implement LDAP Sync Replication in a group of Debian servers. Everything works fine except userPassword, sambaLMPassword and sambaNTPassowrd attributes; the replicas (two of two) just don't have those attributes in any downloaded entries. Yes, I have checked the access rights: syncrepl binddn has "read" rights for passwords, and "ldapsearch -H ldap://master..." with RDN and credentials used in replicas shows everything including all three password hashes. Slave logs show nothing useful. "loglevel Args" at slave mentions all attributes except those "*Password" upon master entry modification. OpenLDAP version is 2.3.30-5+etch2, the current in Debian Etch. A proposal to upgrade to 2.4 will not be accepted unless I'll know about *exact* change in 2.4 fixing this [mis]behavior; just because the master is a production server. Alexey

4 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software