openldap-software April 2009

openldap-software@openldap.org

47 participants
39 discussions

syntax of ldap_modify_s
by Adrian St. John-Bee 28 Apr '09

28 Apr '09

Hi, I am attempting to make an ldap_modify_s from an Objective C application running on a mac. When I attempt to make a test modification I get the error EXC_BAD_ACCESS which generally means that a variable has gone out of scope. However, I do not see how any of the variable involved could have fallen out of scope, so I'm not sure my mod syntax is correct... LDAP *ld; ld = ldap_init(host, PORTNUMBER); char *user = NULL; char *pass = NULL; int rc; rc = ldap_simple_bind_s( ld, user, pass ); LDAPMod *modM; char *dn = "uflEduUniversityId=28833300,ou=People,dc=ufl,dc=edu"; char** vals0; modM->mod_op = LDAP_MOD_REPLACE; modM->mod_type = "mail"; vals0[0] = "eric(a)ntu.ac.uk"; modM->mod_values = vals0; int i = ldap_modify_s(ld, dn, modM); Host and port number are defined earlier in the script. I know that I'm trying to do a modification with a null bind, but I would expect to see Invalid Credentials rather than an access error... Does the syntax of this modification look like it 'should' work? Many thanks, Ade -- Ade St John-Bee Year Three Software Engineering BSc N0115889 Mobile: +44 7736 301614

4 4

SASL OTP?
by manu＠netbsd.org 25 Apr '09

25 Apr '09

Hi Anyone had success with SASL OTP? A quick search yields attempts using sasldb or a cmusaslsecretOTP attribute. I tried both but with little success. If the authenticating user is in saslauthdb (inserted with saslpasswd2 -c user), slapd seems to fail finding it. I fo a ldapsearch -Y OTP -U user uid=user On the very first attempt: SASL [conn=40] Failure: no user in db SASL [conn=40] Failure: no user in db SASL [conn=40] Failure: Error putting OTP secret conn=40 op=0 RESULT tag=97 err=80 text=SASL(-1): generic failure: Error putting OTP secret On next attempts, the behavior is different: SASL [conn=33] Failure: no user in db SASL [conn=33] Failure: no user in db (many many more) SASL [conn=33] Failure: simultaneous OTP authentications not permitted conn=33 op=0 RESULT tag=97 err=52 text=SASL(-8): transient failure (e.g., weak key): simultaneous OTP authentications not permitted If I remove it from the database (saslpasswd2 -d user): SASL [conn=34] Failure: no user in db SASL [conn=34] Failure: no user in db SASL [conn=34] Failure: no user in db SASL [conn=34] Failure: no OTP secret in database conn=34 op=0 RESULT tag=97 err=49 text=SASL(-13): user not found: no OTP secret in database The cmusaslsecretOTP attribute does not seems to be used at all. I used a schema from draft-melnikov-sasl-auxprop-attrs-00.txt, is that wrong? attributetype ( 1.3.6.1.4.1.3.8.1.1.3 NAME 'cmusaslsecretOTP' DESC 'OTP secret' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) (...) objectclass ( 1.3.6.1.4.1.3.8.1.2.1 NAME 'cmuSaslUser' SUP top AUXILIARY MAY ( userPassword $ cmusaslsecretCRAM-MD5 $ cmusaslsecretDIGEST-MD5 $ cmusaslsecretOTP $ cmusaslsecretSRP) ) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 2

Re: Directory migration
by Michael Ströder 22 Apr '09

22 Apr '09

Ian wrote: > On Wed, 22 Apr 2009 00:13:51 Michael Ströder wrote: >> Is this from your original data? > > Yes, taken from the original server's LDAP database. > >> Do all entries have password values like this? Check that. > > Yes, they do! > >> If yes, then you should not have a problem to migrate this data. > > Yet sadly I do have a problem :-/ > [..] > I have used ldapsearch to confirm that the password hashes are the same on the > old & new servers when I use ldapsearch or slapcat to view them. Yet I can't > login on the new server. Then the issue is something different maybe in your client configuration. If you transfer the userPassword values without altering them they are still the same. If the scheme is not {CRYPT} the platform-specific Unix crypt is *not* relevant. > And since the hashes are salted, I can't tell if the > actual password is really different. {MD5} is not salted. {SMD5} would be salted. This is a hashed MD-5 created by Unix crypt. As you can see this is completely different password format: {CRYPT}$2a$10$FThnBowyNXL.DwnXypAsR..ocCmfkZ023tH0wWNog8qwIz/P.3gwe >> You should also consult the fine articles in the FAQ-O-MATIC: >> >> http://www.openldap.org/faq/data/cache/419.html > > I'll give that a read tonight and do some more testing. Yes, please. After that you understand the differences much better. Ciao, Michael.

1 0

Problems in OpenLDAP 2.4.11
by John Du 21 Apr '09

21 Apr '09

Hi, We have been running OpenLDAP 2.2.13 on RHEL4 for a few years without problems. We recently upgraded OpenLDAP to 2.4.11 to use the multi-master capability. After upgrade, we are having 2 problems with the new version. 1. We have an attribute c in the ou=People sub-tree. The value can be either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*. 2. LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13. I would appreciate any information that would help us resolve the problem. Thanks! John

4 5

Syncrepl behavior when disk is full
by Alan Evans 20 Apr '09

20 Apr '09

I am using openldap-2.4.11 with syncrepl n-way multimaster replication and I am seeing some strange behavior if one of the masters runs out of disk space. I would expect this to be handled much the same way a master being offline would be handled but it behaves different. We are doing some failure testing on our new ldap infrastructure to prevent problems before they happen and to be able to improve our monitoring. On of the test cases I came up with is what happens on a master or slave if the disk the ldap database is stored on becomes full. Now granted we do monitor for this normally but if somehow it was missed or filled up very fast we would like to know now what will happen. So here's the setup: RHEL 5 i386 VMWare Guest openldap-2.4.11 (custom RPM, all backends, all overlays, monitor as module, back ldap as module) BDB backend overlay accesslog overlay ppolicy overlay syncprov overlay unique overlay dynlist overlay refint overlay memberof master1 and master2 replicate to one another with mirror mode slave2 uses master2 as its replica provider (load balancing later) master1 <-- mirror mode on --> master2 --> slave2 (updates chaned to master2) Scenario 1: master2 runs out of disk space, ldap modify request is issued against master2 Result: master2 performs the ldapmodify but master1 and slave2 are not notified Scenario 1a: disk space is freed up on master2 Result: change is not replicated to master1 and slave2 Scenario 1b: disk space is freed up on master2 and master2 is restarted Result: change is still not replicated to master1 and slave2 Scenario 1c: disk space is freed up on master2 and master1 or slave2 restarted Result: change is still not replicated to master1 and slave2 Scenario 2: master2 runs out of disk space, ldap modify request is issued against master1 Result: master1, master2 and slave2 are ALL updated It gets even worse as well. Additional changes against multiple objects on master2 do not get propogated to master1 and slave2. The only thing that seems to bring master2 back into sync is to write a change to any objects modified during the time when the disk was full. Scenario 3: master2 runs out of disk space, ldap modify request is issued against master2 for object1 Result: master2 performs modify but does not replicate it to master1 and slave2 Scenario 3a: disk space is freed on master2, ldap modify request is issued on master2 for object2 Result: object2 is modified but changes are not replicated to master1 and slave2 Scenario 3b: disk space is freed on master2, ldap modify is issued against master1 for object1 Result: master1 performs modify and replicates to master2, master2 replicates to slave2, changes to object1 on master2 are lost Scenario 3c: disk space is freed on master2, ldap modify is issued against master1 for object2 Result: master1 performs modify and replicates to master2, master2 replicates to slave2, changes to object2 on master2 are lost Its as if until a write to object1 which was committed by master2 while out of disk space, is modified on master1 and replicated to master2 that master2 is unable to replicate any changes out that originate on master2. In the case of a slave running out of disk space, if it didn't fall into sync right away the solution would be to blow away the ldap database and let it do a full sync from the masters. But in the case where one of the master servers runs out of disk space, what should be done to bring them back in sync without loosing any changes?

1 0

Syncrepl replication be_modify failed (18)
by Will Nowak 19 Apr '09

19 Apr '09

Howdy, I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong. I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listi… The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container: dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow) An incoming add for user james looks like dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow) Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves. Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed Any thoughts? -Will

3 3

Stuck in ACL
by Wolf-Agathon Schaly 19 Apr '09

19 Apr '09

Fellows I'm trying to grant write access to the subtree using the following access directive access to dn.subtree="cn=OracleContext,ou=services,o=privat,c=de" by dn="cn=myusername,ou=users,o=privat,c=de" write by anonymous read by * auth this rule is working fine but for just one user. If I add another 'by dn' like by dn="cn=yourusername,ou=users,o=privat,c=de" write It is working as well. WhoHoo ! That would be fine if I wouldn't expect a huge number of users. Another unaccepable issue would be that the ldap instance would need a restart. That's why I decided to grant access to the dn.subtree to a group (i.e. dba) and have tried the following directive access to dn.regex="(.*,)cn=OracleContext,ou=services,o=privat,c=de" by group="cn=dba,ou=groups,o=privat,c=de" write by anonymous read But whenever I try as a member of the dba group to write an entry underneath the cn=OracleContext,.... I'm getting the error message Enter LDAP Password: adding new entry "cn=dgdb,cn=OracleContext,ou=services,o=privat,c=de" ldap_add: Insufficient access (50) additional info: no write access to parent :-( Any help is highly appreciated thank you Wolf-Agathon

3 2

ppolicy force account expiration
by Daniel Durgin 16 Apr '09

16 Apr '09

Hello, Does any one know how to force the expiration of an account within the slapo-ppolicy overlay? For instance, says that an employee's last day with the organization ends at 5PM, is there a flag I can set to deactivate an account at that time. I know that I could write a cronjob that would do this. Thanks, Dan

3 3

frequent slapd freeze with openldap 2.4.13
by Guillaume Rousse 16 Apr '09

16 Apr '09

Hello list. Since a recent upgrade 2.4.12 -> 2.4.13, I'm facing recurrent slapd hanging. On client side, ldapsearch requests receive this error: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed I'd expect in this case an automatic switch to slave server, but it doesn't work. Here is my ldap libraries configuration: BASE dc=msr-inria,dc=inria,dc=fr URI ldap://ldap1.msr-inria.inria.fr ldap://ldap2.msr-inria.inria.fr TLS_CACERTDIR /etc/pki/tls/certs TLS_REQCERT demand NETWORK_TIMEOUT 2 TIMEOUT 2 TIMELIMIT 2 On server side, slapd usually shows eating 100, 200 or 300% cpu, which make me think some specific repeated query trigger the issue, making the problem worse when several of them accumulates. strace on running slapd process shows it's waiting on a futex: [root@etoile main]# strace -p 2769 Process 2769 attached - interrupt to quit futex(0xb6bb4bd8, FUTEX_WAIT, 2774, NULL <unfinished ...> And gdb shows it waiting in __kernel_vsyscall (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d385c6 in pthread_join () from /lib/i686/libpthread.so.0 #2 0xb7f23d3f in ldap_pvt_thread_join () from /usr/lib/libldap_r-2.4.so.2 #3 0x0806e1b4 in slapd_daemon () #4 0x0805a507 in main () In both case, I think the lack of relevant information is caused by the multithreading nature of slapd, I don't know how to access the exact thread where the problem occurs. I already tried to regenerate indexes, without results. I dropped the base, and reconstructed it from latest backup, it made the problem temporarily disapear. I didn't found anything in the logs, even with debug level set to 'trace'. I'm using a bdb backend, with this configuration in slapd.conf: database bdb suffix "dc=msr-inria,dc=inria,dc=fr" rootdn "cn=root,dc=msr-inria,dc=inria,dc=fr" #rootpw root directory /var/lib/ldap/main cachesize 1000 idlcachesize 1000 checkpoint 256 5 And this one in DB_CONFIG: set_cachesize 0 1048576 0 set_lg_bsize 2097152 set_lg_max 10485760 set_flags DB_LOG_AUTOREMOVE The full slapd.conf is accessible at http://pastebin.mandriva.com/5801 db_stat -m output is accessible at http://pastebin.mandriva.com/5799 The main database itself is quite small, the ldiff backup is 1.4 only. I also have a log database for syncrepl purpose. I'm using openldap 2.4.13, with db 4.6.21, on mandriva linux 2008.1, 32 bits system. I'd be happy to provide additional informations if needed. -- Guillaume Rousse Service des Moyens Informatiques INRIA Saclay - Île-de-France Parc Orsay Université, 4 rue J. Monod 91893 Orsay Cedex France Tel: 01 69 35 69 62

5 8

Re: Compile problems with 2.4.16 and Fedora 10
by Quanah Gibson-Mount 15 Apr '09

15 Apr '09

--On Wednesday, April 15, 2009 10:08 AM -0700 Rick Stevens <rps2(a)socal.rr.com> wrote: > Quanah Gibson-Mount wrote: >> --On Wednesday, April 15, 2009 9:53 AM -0700 Rick Stevens >> <rps2(a)socal.rr.com> wrote: >> >>> Quanah Gibson-Mount wrote: >>>> --On Tuesday, April 14, 2009 3:25 PM -0700 Rick Stevens >>>> <rps2(a)socal.rr.com> wrote: >>>> >>>>> Hi, gang. >>>>> >>>>> Having a bit of trouble compiling OpenLDAP 2.4.16 under Fedora 10. >>>>> I've built Berkeley DB 4.7 and installed it. I run configure with: >>>>> >>>>> LDFLAGS="-L/usr/local/BerkeleyDB.4.7/lib" >>>>> CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include" ./configure >>>>> --enable-modules --enable-backends --enable-overlays=mod >>>>> --enable-sql=no >>>>> >>>>> (all one line). Despite what "./configure --help" says, it still >>>>> tries to include the MySQL NDB stuff by default (and can't find the >>>>> headers even if the mysql-devel RPM is installed, the "NdbApi.hpp" >>>>> file is in /usr/include/mysql/ndb/ndbapi), so I've appended >>>>> "--enable-ndb=no" as well to get past that (don't need MySQL anyway). >>>> >>>>> Hints? Suggestions? >>>> >>>> Back-sql and back-ndb are different backends. You need to add >>>> --disable-ndb to your configure flags. See the output of ./configure >>>> --help. >>> >>> I did, which is why I said '"Despite what ./configure --help" says': >>> >>> --enable-ndb enable MySQL NDB Cluster backend no|yes|mod [no] >>> >>> I read that as saying the default is "--enable-ndb=no". Am I wrong? >> >> No, you're quite correct. I missed that bit further down, so my >> mistake, sorry. ;) > > 'Sok, but that still leaves a question: Help says NDB will NOT be built > by default, yet it is. One must assume the help text needs to be > changed or configure's logic has to be fixed. > > Beyond that, if you do let NDB build on a Fedora 10 machine, the build > bombs when it can't find NdbApi.hpp. That file does exist if the > mysql-devel RPM has been installed. The full path to the file is > "/usr/include/mysql/ndb/ndbapi/NdbApi.hpp". Please keep replies on the list. I suggest filing bugs in the ITS system on these two issues. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software April 2009