December 2008 - openldap-software

by Clowser, Jeff (Contractor)

I'm currently doing a review to see how OpenLDAP compares, *feature wise* ATM, to other directory servers and specifically to the Sun DS - i.e. to get a definitive list of features it's missing that Sun has and what it has that Sun doesn't have, etc. For brevity, I haven't included all the potentially useful features of OpenLDAP, but have just focused on those associated with 1) RFC compliance (of which Sun may or may not meet) and 2) features to match the Sun DS (which it would be replacing). So far, here's what I have for OpenLDAP: RFC 4510 (which includes 4511-4519). There was recent discussion on the list around this, such that in some cases, not everything that changed from 3377 (which includes 2251-2256, 2829, and 2830) to 4510 has been updated in OpenLDAP, but I think those issues are fairly minor. The following additional RFC's are supported in OpenLDAP: - RFC 2247 and RFC 3088 - RFC 2696 simple paged results - RFC 2849 ldif - RFC 3062 password mod op - RFC 3296 named referals, manageDSAit - RFC 3673 All Op attrs + feature - RFC 3687 Component matching rules - RFC 3866 Languange tag and range - RFC 3876 matched values control - RFC 4370 proxy auth - RFC 4522 binary encoding - RFC 4523 x.509 cert schema - RFC 4524 COSINE schema - RFC 4525 Mod-increment - RFC 4526 Absolute true/false filters - RFC 4527 pre/post read control - RFC 4528 assertion control - RFC 4529 request attrs by objectclass - RFC 4530 entryUUID - RFC 4532 whoamI - RFC 4533 Content Sync op (replication) RFC's NOT supported are: - RFC 2589 dds Seems with 2.4, this has gone from experimental to production quality? - RFC 2891 server side sorting - RFC 3671 collective attributes - RFC 3928 LCUP mainly for updating cached addressbooks, etc - not replication between servers - RFC 3384 looks like just reqs for replication, not an actual replication protocol - RFC 4533 is used instead Unknown: - RFC 3672 (subentries) - RFC 3698 and 3727 (additional matching rules) - RFC 3909 LDAP Cancel operation - RFC 5020 entryDN operational attribute (There are some other, often obscure, LDAP related RFC's that I didn't include, but this seems to be the major/useful ones) Other features not supported: - VLV browse indexes (per http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09). Not an RFC, but supported by Sun and MS directories, and used by things like Outlook and Solaris. Other supported features: - dyngroup/dynlist/memberof overlay (A much more useful feature than Sun's groupOfURLs "dynamic" group and "roles" mechanism) - ppolicy overlay (matches Sun DS 5.x reasonably close, but is account lockout replicated to all servers? Sun DS 6.x claims to) - refint overlay (similar to Sun's referential integrity plugin) - unique overlay (similar to Sun's uniqueness plugin) - audit and accesslog overlays, syslog logging - much more useful/complete than Sun's access/audit/error logs. - live acl changes via LDAP Unknown features: - Per user resource limits (sizelimit, timelimit, idletimeout, etc). I think Howard Chu said OpenLDAP has some of this, but I haven't seen any reference to it or how to use it in the docs (does this functionality exist, and if so, is there any documentation?) - Tracking of last login (i.e. last successful ldap authentication) Is this still fairly accurate? The ones that are really problematic are the lack of: - VLV Browse indexes - RFC 2891 (server side sorting) - per user/entry resources limits (if they don't exist) Are there any unofficial updates/patches/overlays/plans for any of this functionality? Thanks, - Jeff

14 years, 2 months

11
29
0 / 0

Re: OpenLDAP and DNS SRV records

by Gavin Henry

----- "Matt Kowske" <jmkowske(a)gmail.com> wrote: > 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? 2.4 does, 2.3 doesn't. -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

14 years, 8 months

6
13
0 / 0

OpenLDAP 2.4.11 + Syncrepl + RWM

by Alan Evans

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?

14 years, 8 months

3
3
0 / 0

Using UPN notation for LDAPbind

by Wilhelm Meier

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

14 years, 8 months

3
7
0 / 0

LDAP+MySQL vs LDAP+Berkley

by Luis Daniel Lucio Quiroz

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

14 years, 8 months

2
1
0 / 0

Sync control missing?

by Sean Loaring

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

14 years, 9 months

2
1
0 / 0

LDAP recovery question...

by Terry Haley

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.

14 years, 9 months

2
1
0 / 0

Re: How to hide namingContext in rootDSE ?

by Thomas Chemineau

>>> 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

14 years, 9 months

1
0
0 / 0

Re: How to hide namingContext in rootDSE ?

by Thomas Chemineau

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

14 years, 9 months

1
0
0 / 0

how to configure tls and ldap

by Alfonsas Stonis

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

14 years, 9 months

5
8
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software December 2008