July 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: virtual view strategies: replying differently to different clients

by Pierangelo Masarati

----- "Aaron Richton" <richton(a)nbcs.rutgers.edu> wrote: > On Fri, 25 Jul 2008, Guillaume Rousse wrote: > > > First, using a distinct database doesn't allow to provide a virtual > view > > from a branch in my original database to another branch in the same > > database. Meaning, I can't have ou=telephony,dc=myprefix a virtual > view > > of ou=users,dc=myprefix, I need to use a distinct prefix. > > Have you tried declaring the ou=telephony,dc=myprefix back-relay > subordinate to dc=myprefix back-$END? I was about to reply the same, but you anticipated me :) I've tried the above, and it works as expected as soon as the "relay" statement is omitted. In fact, it requires the superior database to already exist. Probably, that test should either be relaxed or moved to db_open(). With respect to Guillaume's second question, I see the issue. In principle, what he needs to do is something like rwm-map attribute telephoneNumber homePhone rwm-map attribute * telephoneNumber so that real homePhone is mapped to virtual telephoneNumber, and real telephoneNumber is hidden. Unfortunately, this seems to result in a "double mapping" for telephoneNumber. I need to look at the logic of mapping, since what Guillaume wants to do seems to make sense, so it should be allowed. As per the reason of hiding everything not working, it's related to the fact that hiding everything does not allow "objectClass" to be returned, which causes the search filter to fail because the objectClass is not present. Unfortunately, the objectClass attribute cannot be mapped, so it cannot be explicitly preserved by adding rwm-map attribute objectClass * I recommend he files an ITS for each of those two issues. > > Third, this solution doesn't work currently when trying to sync > > the appliance users from ldap. From ldap log, it seems some > specific > > control is not supported with relay backend: > > I think you'd be better served by syncing the real data, and > configuring > the back-relay/slapo-rwm identically across your slaves so as to give > > consistent results. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

15 years

2
4
0 / 0

overlay chain

by Ed Greenberg

Hi, folks, I have a slave running syncrepl (just fine) which is getting hit with update requests, which are, of course, failing. I'd like to have them succeed. I could not find anything in the docs that would allow the slave to issue a referral. That seems to be limited to slurpd, if I understand correctly. So I tried to implement chained updates. I put the following into my slaves slapd.conf: overlay chain chain-rebind-as-user FALSE chain-uri "ldap://master.mydomain.com" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=mydomain,dc=com" credentials="secret" mode="self" This does not seem to be sufficient, but I can't figure out from the slapo manpage what else is required. I get error 0x35, that the slave refuses to perform the operation. (I tried whipping and otherwise punishing the slave, but it did not improve it's attitude. :) There does not seem to be a good howto for this. Can somebody send me a pointer or an answer? Thanks, </edg> Ed Greenberg West Hollywood, CA

15 years, 1 month

3
7
0 / 0

pwdCheckQuality doesn't work

by Zhang Weiwu

My checklist: 1. RTFM slapo-ppolicy: done, 3 times; 2. check openldap version: 2.4, newly installed on Gentoo Linux; 3. check ppolicy overlay successfully loaded and being used: must be, because operational attribute like pwdFailureTime was maintained; 4. pwdAttribute setting: correct, value is "userPassword"; 5. pwdCheckQuality: correct, value is 2 (server always check password syntax); 6. pwdMinLength: correct, value is 6, server do not accept password short than 6 character; 7. ppolicy_default: correctly set, because change pwdMaxFailure on default entry does have effect; 8. the entry being operated doesn't have pwdPolicySubentry, so default should be applied: correct; 9. slapd server was restarted after all above check; Test result: Still doesn't work: $ldappasswd -vD uid=admin,st=jiangxi,o=LGOP -x -w secret -s 13456 ou=吉安市,st=jiangxi,o=LGOP ldap_initialize( <DEFAULT> ) Result: Success (0) (expected not successful here because new password was too short) I am stuck here. Do I miss something on my checklist?

15 years, 1 month

4
5
0 / 0

PGP Keys

by Jorge Medina

Do anybody knows where I could get the PGP keys to verify the integrity of the source code I downloaded from a mirror? Thanks -Jorge

15 years, 1 month

4
3
0 / 0

back-sql using varchar keyvals and ids

by Potkanski, Jason

I have an interest in using openldap as an external authenticator for our membership to connect to external services. Our main table has a primary key of a varchar (10) and nothing unique in the table that is an int. I would love to replace ldap_entries with a view, however, returning the entries failed when I attempted it. I did a bit of experimentation with the dc=example,dc=com on a search: ldapsearch -x -b dc=example,dc=com sn=Puzdoy The ldap_entries keyval was changed from int to varchar 10 and persons table id was changed to varchar 10. Below is a table on some experiments ldap_entries.keyval and persons.id MySQL SQL SERVER 2000 2 Ok Ok 02 Ok Fail ABC Fail Fail abc Fail Fail Log: Jul 31 10:15:41 jpotkanski-lx slapd[30011]: Constructed query: SELECT DISTINCT ldap_entries.id,persons.id,'inetOrgPerson' AS objectClass... Jul 31 10:15:41 jpotkanski-lx slapd[30011]: id: '1' Jul 31 10:15:41 jpotkanski-lx slapd[30011]: >>> dnPrettyNormal: <cn=Torvlobnor Puzdoy,dc=example,dc=com> Jul 31 10:15:41 jpotkanski-lx slapd[30011]: <<< dnPrettyNormal: <cn=Torvlobnor Puzdoy,dc=example,dc=com>, <cn=torvlobnor puzdoy,dc=examp ... Jul 31 10:15:41 jpotkanski-lx slapd[30011]: backsql_oc_get_candidates(): added entry id=3, keyval=2 dn="cn=Torvlobnor Puzdoy,dc=example, ... Jul 31 10:15:41 jpotkanski-lx slapd[30011]: <==backsql_oc_get_candidates(): 1 Jul 31 10:15:41 jpotkanski-lx slapd[30011]: backsql_search(): loading data for entry id=0, oc_id=0, keyval=0 Jul 31 10:15:41 jpotkanski-lx slapd[30011]: backsql_search(): loading data for entry id=5, oc_id=2, keyval=1 On a failed one, backsql_oc_get_candidates(): 0 openldap 2.3.39, 4.fc8 , unixodbc 2.2.12, freetds .84, mysql-odbc latest. Before opening anything in ITS, I wondered if this is a bug, feature request or maybe solved in 2.4? Jason Potkanski Information Technology Developer CCIM Institute 430 N. Michigan Ave, Suite 800 Chicago, IL 60611-4092 jpotkanski(a)ccim.com www.ccim.com tel: 312.321.8559

15 years, 1 month

3
5
0 / 0

slapd does not start, where do I find the error?

by Jorge Medina

I got the sources (2.2.8), compiled and installed OpenLDAP in RedHat Enterprise Linux 5 ( 64-bit.) (I also got the sources and compiled BerkeleyDB 4.6) Now, I am trying to start the server. I don't get any error message in the console. In Ubuntu, the errors would show up in /var/log/syslog Where could I find what is wrong when I invoke slapd? Where do the errors get logged ?

15 years, 1 month

4
5
0 / 0

Re: Meta Idassert-bind

by Andrew Graham

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I've re-read my original message and it didn't make alot of sense. So here's take two! I'm using back-meta to attempt to amalgamate several ldap servers into one single tree. This should cater for users that exist only in a local BDB database, and also for users with accounts in one of the target ldap servers. If I say 'local' or 'remote' user at any point, I'm referring to users stored in the local bdb database or a remote ldap server respectively. I shall refer to the local openldap server as the proxy server. The meta database is subordinate to the local database. This allows me to have a base record for the entire directory. Everything works perfectly for targets that don't require a bind before searching. For targets that do require a successful bind, I've been trying to use the 'idassert-bind' feature with mixed results. The following is a description of the behaviour I am trying to achieve: If a local user binds to the proxy server, and performs a query with one or more targets in scope, then the proxy server should use predefined credentials to bind to and search only the targets in scope on behalf of the local user. If a remote user binds to the proxy server, and performs a query affecting only the target where that user is stored, then the proxy server should bind to that target using the credentials supplied by the remote user. If there are any other targets in the scope of the query, openldap should not attempt to use the predefined credentials to bind to and search on that target. To try to achieve this, I have placed all local users in their own branch of the tree, and set the 'idassert-authzFrom' for each target to match this branch only, thus preventing remote users from using the idassert feauture and barring them from querying other targets than their own. Here is the first of two 'interesting' results. If I bind to the proxy server as a remote user with multiple targets in scope, the bind is proxied to the remote user's target correctly. The proxy then proceeds to attempt to bind to the other targets in scope using seemingly random names. Some examples (captured with wireshark) are '\270+1\b', '\250\202/\b\005', '\220\241\322\267\220\241\322\267\020' and 'x\267.\b'. The name changes every time, but each time no password is provided. The proxy will not attempt to search any of the targets after binding, even the target to which the user belongs. I'm not sure I understand the purpose of the 'non-prescriptive' flag, but if I set it on each target (as Pierangelo suggested previously), the unusual behaviour changes. When binding with a remote user, the proxy will correctly bind to the target to which the remote user belongs using the remote users credentials. If another target is in scope, the proxy will attempt to bind to it without name or password. The proxy will proceed to search the targets. This is fine for my situation, but I would like to understand why this happens? The second problem I'm having is with the local users. If the 'network-timeout' statement is used in the meta database definition, whenever a local user binds to the proxy and queries one or more of the target servers, the proxy will attempt to bind to the targets with the predefined name but with no password. If network-timeout is not specified, the proxy binds with both the predefined name and password to every target in scope. Is this behaviour intended or a bug? My current configuration is... require authc access to * by * write # # Meta # database meta suffix "dc=meta,dc=example,dc=com" subordinate rootdn "cn=manager,dc=example,dc=com" network-timeout 10 #Target 1 uri "ldap://ldap.acme.org/dc=target1,dc=meta,dc=example,dc=com" idassert-bind bindmethod=simple binddn="cn=searchuser,dc=acme,dc=org" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.regex:dc=users,dc=example,dc=com" rewriteEngine on suffixmassage "dc=target1,dc=meta,dc=example,dc=com" "dc=acme,dc=org" #Target 2 uri "ldap://ldap.another.com/dc=target2,dc=meta,dc=example,dc=com" idassert-bind bindmethod=simple binddn="cn=searchuser,dc=another,dc=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.regex:dc=users,dc=example,dc=com" rewriteEngine on suffixmassage "dc=target2,dc=meta,dc=example,dc=com" "dc=another,dc=com" # #Local # database bdb suffix "dc=example,dc=com" directory /usr/local/var/openldap-data/base/ rootdn "cn=manager,dc=example,dc=com" rootpw "secret" index objectclass eq index cn,sn eq,sub The ldif file I use to populate the local database... dn: dc=example,dc=com dc: example description: Container for metadirectory objectClass: dcObject objectClass: organization o: example dn: cn=Search user,dc=users,dc=example,dc=com cn: search user sn:search user objectclass: top objectclass: person objectclass: organizationalPerson userpassword: secret Thanks for your help! Drew Andrew Graham ICT AgustaWestland UK Tel No: +44 (0) 1935 70 4421 andrew.graham(a)agustawestland.com *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

15 years, 1 month

2
1
0 / 0

slapd_db_hotbackup

by Alvin Chang

Hello everyone: If anyone used slapd_db_hotbackup in the past, please kindly point me at man pages or examples. It will be much appreciated. I did try google, but only RPM packages came up and if I add -rpm to the search, then only two irrelevant results came.. Thanks in advance, -- Alvin Chang Linux Systems Administrator OpenX Limited Skype: alvin.chang_at_openx.org IRC: #openx on freenode.net

15 years, 1 month

3
2
0 / 0

BDB 4.3 instability

by Craig Worgan

Hi, Does anyone know the specifics of the instability of BDB 4.3 (see http://www.openldap.org/faq/data/cache/44.html)? I run OpenLDAP on a RedHat platform that ships with BDB 4.3 and I need to convince other applications on the system that an upgrade is important. At this point they are asking for more specific details than 'OpenLDAP doesn't recommend BDB 4.3'. Thanks, Craig Worgan

15 years, 1 month

4
12
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software July 2008