openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Value of contextCSN not persisted
by Torsten Schlabach (Tascel eG) 27 Dec '11

27 Dec '11

Dear list! We found one issue with a quite simple syncrepl replication; we have one provider and just one consumer. The consumer got set up about a week ago and loaded its initial database content from the provider. Then - after a couple of days - one object got deleted on the provider. So the consumer had to perform that delete operation as well; which is what it did fine. No problem so far. Today we compared the contextCSN values for the provider and the consumer and first thought we may have a problem, actually, because we found the contextCSN on the consumer to be newer than on the provider. Here are the actual values: consumer contextCSN: 20111216215531.923716Z#000000#003#000000 provider contextCSN: 20110124140058.246484Z#000000#003#000000 Looking twice, we found out that on the provider we got the above contextCSN value (the one which is too small) using slapcat. If we ask the provider using ldapsearch it actually reports the expectec contextCSN value, i.e. the same one which we can see on the consumer. (Note: The above value on the consumer has been taken from slapcat as well. In other words: The provider's latest contextCSN value has not been written to the disk until now; actually 4 days since the change. I guess if the power would fail now for example, the provider would load it's context CSN from the database, reading the lower value, and thus replication would get seriously out of sync, wouldn't it. Also we found that the result of the operation which increased the contextCSN (deleting an object on the provider) has been written to the disk, in contrast to the contextCSN value. Is that epxected behaviour or would we need to configure the flushing to the disk? We're using OpenLDAP 2.4.23 on Debian Linux. The backend is a back-hdb. Regards, Torsten

3 7

memberOf doesn't list members from an autogroup
by Felipe Augusto van de Wiel 27 Dec '11

27 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm using 2.4.23 packaged from Debian (2.4.23-7.2) and I'm trying to combine autogroup and memberof. autogroup (and dynlist) seems to be working, but it seems that memberof fails. :-( In terms of slapd.conf I load the modules memberof, dynlist and autogroup, the relevant configuration: overlay memberof memberof-refint TRUE overlay dynlist dynlist-attrset groupOfNames labeledURI member overlay autogroup autogroup-attrset groupOfURLs memberURL member I created the following test group: dn: cn=TEST,ou=Groups,dc=hpp,dc=org,dc=br cn: TEST memberURL: ldap:///ou=People,dc=hpp,dc=org,dc=br?member?sub?(gidnumber=1000) gidNumber: 12345 objectClass: groupOfURLs objectClass: top objectClass: posixGroup It correctly lists all the users with gidnumber 1000, I'm planning to change the filter to have a group of users from different groups. If I try to search per membership: ldapsearch -LLL -x memberof=cn=TESTE,ou=Groups,dc=hpp,dc=org,dc=b Nothing returns. :-( In other groups where I have a member field added statically, the memberof query works as expected. Am I missing something? Thanks in advance! Kind regards, - -- Felipe Augusto van de Wiel <felipe.wiel(a)hpp.org.br> Tecnologia da Informação (TI) - Complexo Pequeno Príncipe http://www.pequenoprincipe.org.br/ T: +55 41 3310 1747 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJO+leVAAoJECCPPxLgxLxPw8oP/29cK3UrBphqpCFp5ce6toQN Y3JdhxX8brO5ffgv2hWYc/m+MOlsOjlxI5bEuIED0VlpnXtSJloT48GzGVNoTJoF nKt/tV9ndphJuH4MOYioybOP4aMXaOjvr0TYk4eNWZl2C/RYtR1WtTExHCt30+UV Iy3/hzNQyLiBURgRiTOR2+qCHMVSqMXJM+TuvwDXQMm89oEoZWiQHJGVZ9HDcMYE Xg3A7UBZQwPxxXjARVLX8w/n9z2M75yABQxK1p3SnJHX7JxAE5lzzhpQRV3nIXI5 kL41sXarI8Xfa/NyClf54xzOUNqnMBeNBZJQe9SSfn/E9wBw2FRvq1QAJB1Zhgde 2bu3lFPi6gdWJF5inlHVrhT3Q186oa037UljZx0Ey5sxL1XKK6oQEPxVIEbTS13n nwbEthEFjbpLE7Hgz4S9x/cYDRrVM+dFNZFvOp+1xg+kJnEfL5nkadHN+DU97QQ1 4ZuqZNnJq7GgXE3GyAadc5S2eVn10YmOx5OJf8Yct5kpLWSxRfozxGQgAtj4Zkni oGTo5w8IgYdhGXYUh1mLgTbW8PZzUCI3uxzyBXYS8uHRlyG88PCa1BtNGpoOrEGz WKDbib3wLsaaJcvLVrjtp2MO4rII+lgO2O8kei6LQ2nUp0HQxXAyDFbdLzMO3TQR YNswzdah34WWWdPBQYHE =sAbW -----END PGP SIGNATURE-----

1 0

[OT] Schema Catalog
by Reinaldo de Carvalho 27 Dec '11

27 Dec '11

Hi, To avoid us create another schema to the same objective, I'd like consult if exist a website that have a catalog of schemas? []s -- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net "While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works" (myself)

1 0

syncrepl: target DIT & directory server compatibility
by Asplund Marko 27 Dec '11

27 Dec '11

Hi, I'm planning on using OpenLDAP syncrepl for replicating a DIT fragment from Novell eDirectory using pull-based synchronisation. If i understood correctly synchronisation requires LDAP Sync protocol support from both the provider and the consumer sides. Any practical experience synchronising between these two different types of directory servers? How do I configure the syncrepl target DIT? For example if i have a database with suffix "dc=example,dc=com" and locally managed entries stored in o=foo,dc=example,dc=com and i'd like to synchronise a DIT from another server to o=bar,dc=example,dc=com How can i configure OpenLDAP to do that? thanks, marko

2 1

cn=config partial replication
by The Ranger 24 Dec '11

24 Dec '11

Hello, I have multiple v. 2.4.23 and 2.4.26 servers doing the master-slave replication using syncrepl. The main server contains multiple subordinate DIT-s that get replicated to different servers: * DIT1 from master to server A, B, C * DIT2 from master to server D, E, F * DIT3 from master to server G etc. Now I would like also to setup the cn=config replication. Actually the most important for me would be the cn=schema,cn=config since everything else is rather static. What would be the best setup with minimal configuration settings/values duplication? There are many howtos on the net how to sync only cn=schema,cn=config, but putting the olcSyncrepl value to olcDatabase={0}config will make the whole DB shadowed and redirect the database config changes to master server which is not the reasonable solution. The best solution would be when the cn=schema,cn=config (and maybe olso the proper olcDatabase subtree) would be synchronized with the master. All the rest of the config database should be locally manageable. I read about the suffixmassage, but this needs ldap server upgrade on 2.4.23 servers (there is no package in debian 6.0.3 for that). And as far as I understand it also requires separate cn=config,cn=slave subtrees on the server with duplicated database configuration and acl definitions etc. I simply try to find the best solution to hit as much problems at once as I can and reduce the config overhead as much as possible. Could you please advise what are my options? -- rgrds, Ivari

1 0

Using ldap_opt_x_tls_require_cert
by Thiyagu Rajendran 23 Dec '11

23 Dec '11

Hi all, I have few question on proper usage of ldap_opt_x_tls_require_cert option. when ldap_opt_x_tls_require_cert is set to LDAP_OPT_X_TLS_ALLOW on ldap handle after ldap_initialize, it was not working. It failed with certificate verify error. But according to the ldap.conf man page, setting LDAP_OPT_X_TLS_ALLOW option should not verify the server certificate After googling around found that LDAP_OPT_X_TLS_ALLOW should be set on global handle. Then got rid of certificate verify error. But I faced a new problem ,changing LDAP_OPT_X_TLS_ALLOW to LDAP_OPT_X_TLS_TRY in the same process doesnt verify the certificate. When i kill the process and restart it, it verifies the certificate properly. Somehow i managed to solve the problem by setting clearing the context using *LDAP_OPT_X_TLS_NEWCTX int tls=**LDAP_OPT_X_TLS_ALLOW* *ldap_set_option(NULL,**LDAP_OPT_X_TLS_REQUIRE_CERT,*&tls) *j=0 ldap_set_option(NULL,**LDAP_OPT_X_TLS_NEWCTX,&j) *But when i try to set *LDAP_OPT_X_TLS_REQUIRE_CERT *after clearing context, it is not working. Can someone explain the correct usage of *LDAP_OPT_X_TLS_REQUIRE_CERT * option* *Regards, Thiyagu

1 0

password-policy configuration problems: cannot change passwords
by Marco Weber 23 Dec '11

23 Dec '11

Hello, I'm running openldap with password policy overlay. after the overlay installation and configuration, we cannot change the passwords anymore. Michael Ströder told that an LDAP modify request should resolve this issue, but it didn't help. [root@ldapsrv ~]# ldappasswd -e ppolicy -D cn=username,dc=domain,dc=tld -S -W New password: Re-enter new password: Enter LDAP Password: Result: Constraint violation (19) Additional info: Password policy only allows one password value control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAA= ppolicy: This is the log: Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 fd=39 ACCEPT from IP=192.168.41.41:48899 (IP=0.0.0.0:636) Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 fd=39 TLS established tls_ssf=256 ssf=256 Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 op=0 BIND dn="cn= username,dc=domain,dc=tld" method=128 Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 op=0 BIND dn="cn= username,dc=domain,dc=tld" mech=SIMPLE ssf=0 Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 op=0 RESULT tag=97 err=0 text= Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 op=1 PASSMOD new Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 op=1 RESULT oid= err=19 text=Password policy only allows one password value Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 op=2 UNBIND Dec 22 11:15:31 ldapsrv slapd[5056]: conn=4431 fd=39 closed this is my default password policy: dn: cn=password-policy,dc=policies,dc=domain,dc=tld objectClass: person objectClass: pwdPolicy objectClass: top cn: password-policy pwdAttribute: userPassword sn: Default Password Policy pwdAllowUserChange: TRUE pwdExpireWarning: 604800 pwdInHistory: 3 pwdLockout: TRUE pwdLockoutDuration: 7200 pwdMaxAge: 7776000 pwdMaxFailure: 5 pwdMinAge: 180 pwdMinLength: 8 pwdMustChange: TRUE this is my password policy configuration: dn: olcOverlay=ppolicy,dc=policies,dc=domain,dc=tld objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: ppolicy olcPPolicyDefault: cn=password-policy,dc=policies,dc=domain,dc=tld olcPPolicyUseLockout: TRUE Thanks in advance for any reply, Marco

4 5

Re: ACL Problem
by Selcuk Yazar 23 Dec '11

23 Dec '11

Hi, Ok my rule is access to dn.regex="^mail=([^,]+),ou=([^,]+),jvd=([^,]+),o=hosting,dc=myhosting,dc=example$" attrs=userPassword by dn.exact="mail=$1,ou=$2,jvd=$3,o=hosting,dc=myhosting,dc=example" write by dn.exact,expand="mail=$1,ou=$2,jvd=$3,o=hosting,dc=myhosting,dc=example" read by dn="cn=Manager,dc=myhosting,dc=example" write by users none by * none this doesn't work , users can't change their own password. Also try this; access to attrs=userpassword by self write by anonymous auth by dn="cn=Manager,dc=myhosting,dc=example" write by users none by * none doesn't work again. open ldap have another parameter for these things ??? ?? On Tue, Dec 20, 2011 at 8:56 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Tuesday, December 20, 2011 4:28 PM +0200 Selcuk Yazar < > selcuk.yazar(a)gmail.com> wrote: > > access to >> dn.regex="(.*,ou=(.+),jvd=([^,**]+),o=hosting,dc=myhosting,dc=**example)" >> attrs=userPassword >> by self write >> by users write >> > > "by users write" will allow any authenticated user to overwrite anyone's > password. I'm guessing you really do *not* want this rule. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Selçuk YAZAR http://www.selcukyazar.blogspot.com

3 3

userCertificate, wrong attribute type?
by Nicolas KOWALSKI 22 Dec '11

22 Dec '11

Hello, Using OpenLDAP 2.4.12 (SLES 2011 SP1), I am trying to add a userCertificate attribute to an existing user (inetOrgPerson object). I converted the PEM file containing the certificate to DER format, then created this ldif: dn: cn=Nicolas.Kowalski,ou=people,dc=home,dc=lan changetype: modify add: userCertificate userCertificate;binary:< file:///root/ssl/Nicolas.Kowalski-crt.der But when I try to update the entry, I always get this error: # ldapmodify -x -W-D "cn=Manager,dc=home,dc=lan" -f the-ldif-above ldapmodify: wrong attributeType at line 4, entry "cn=Nicolas.Kowalski,ou=people,dc=home,dc=lan" What am I doing wrong? Thanks, -- Nicolas

1 1

Ldap problems in paradise, working with suse 12.1 miles stone 5
by John Tobin 22 Dec '11

22 Dec '11

Dear Ralf, Hi, I hope you are still here before the holidays, I would appreciate your advice and counsel. I have Suse 12.1 up, mile stone 5. It works well. I have installed and used ldap 2.4.26. It is also working with nss_ldap code. I am having some trouble on 2 counts. First I tried to get start_tls, and / or ldaps to work in that environment. I have not gotten tls to work. Was this tested at all in SUSE? TLS is critical to some success in the university lab I am running over here. I have posted the problem to the open ldap crew, and have heard nothing from anyone for solving the problem, or even assistance in how to debug it, or understand the failure I get.....[this is from nss_ldap] >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS >> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >> failed:stat=-1 >> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >> failure error=-1 id=1217, closing >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS >> negotiation failure) >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS >> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >> failed:stat=-1 In the middle of this mess Chris wood mentioned this would be easier, and may well work under nslcd. OK. I installed nslcd.... I have the lastest I believe: 0.7.13-7.3 I setup nslcd.conf to the best of my ability. With just a : Uri ldap://192.168.0.10/ Base dc=dark,dc=net Scope sub It works fine. For user jtobin [is only in ldap server] I get a login But in a similar fashion to nss_ldap, when I turn on ssl start_tls And add to the nslcd.conf above: Ssl start_tls Tls_reqcert allow Tls_cacertfile /var/lib/ldap/cacert.pem Tls_cert /var/lib/ldap/server.crt Tls_key /var/lib/ldap/server.key It fails.... I get: user jtobin does not exist But worse... I get nothing in the /var/log/localmessages file for debugging. Certificates were created using www.opeldap.org/faq/data/cache/185.html Which to my knowledge is the referenced site for openldap The certificate is a self signed cert. Most of my testing at the moment is local.... Client and slapd server are on the same machine, so same certificate file for tls_cacertfile, tls_cert, tls_key, though I have tested on remote clients with the same results. I see your name on a number of the nslcd doc and email. Help me out here.... How can I get this working / debugged? Who would have some of the information I need? Who would be interested in helping me to get this working. So far all I have gotten is a number of messages from interested parties asking me if I have gotten to work yet... Drop me aline with some advice as to how to get this resolved, or if it is probably not a short term Priority for anyone, tell me that. I will find a different strategy for securing my lab ldap client and server machines. [is getting this to work a priority at SUSE? Is there someone I can work with?] Sincerely tob There are a number of comments but the real statements are: Uri ldap://192.168.0.10/ Base dc=dark,dc=net Scope sub Ssl start_tls

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical