openldap-software September 2008

openldap-software@openldap.org

60 participants
64 discussions

syncrepl 'access to' constraints
by Maurizio Lo Bosco 25 Sep '08

25 Sep '08

Hi All, I'm using openldap 2.3.30 on debian etch (-5+etch1) with syncrepl. I have configured the write access to a single attribute for a user, I'm able to change the attribute with such user but the replace is not propagated to the consumers. If I change the same attribute with a user with more access rights the syncrepl is working fine. I think that some access rules are missing for the user, something like contextCSN in the user dn. Any hint? Kind regards Maurizio

3 5

ACL to give DN write access to userPassword only under a certain OU.
by k bah 24 Sep '08

24 Sep '08

Hi, I want to give a certain DN access to userpassword attribute and to be able to delete and add entries from one OU on my LDAP tree. --- tree-root ..OU=adm ...."DN I want to give rights", lets call it "webmail-domain-xyz". ..OU=people ....cn=10000000000,ou=people,dc=organization,dc=org --- The DN's "webmail-domain-xyz" will have access will always be the form "cn=10000000000,ou=people,dc=organization,dc=org", where the cn will be from 10000000000 to 19999999999. My question is related to my ACL's processing: ------------ current working ACL's ----- # ACL 0 access to dn.base="cn=Subschema" by * read # ACL 1 access to attrs=userPKCS12 by self write by * auth # ACL 2 access to attrs=shadowLastChange by self write by * read # ACL 3 access to attrs=userPassword by dn="cn=reallysureyouwannauserootdn,dc=organization,dc=org" write by anonymous auth by self write by * none # ACL 4 access to dn.base="" by * read # ACL 5, 6 # (So Dovecot won't look where it's not supposed to, and will not complain about duplicated entries) access to dn.subtree="ou=moodle001,ou=moodleusers,ou=people,dc=organization,dc=org" by dn="uid=MoodleLDAPAdmin001,ou=adm,dc=organization,dc=org" write by dn="uid=dovecot-domain-xyz,ou=adm,dc=organization,dc=org" none by * read access to dn.subtree="ou=moodle001,ou=moodlecourses,dc=organization,dc=org" by dn="uid=MoodleLDAPAdmin001,ou=adm,dc=organization,dc=org" write by dn="uid=dovecot-domain-xyz,ou=adm,dc=organization,dc=org" none by * read # ACL 7 # So webmail related scripts can add new users to LDAP. access to dn.subtree="ou=people,dc=organization,dc=org" by dn="uid=webmail-domain-xyz,ou=adm,dc=organization,dc=org" write by * read # ACL 8 access to * by dn="cn=reallysureyouwannauserootdn,dc=organization,dc=org" write by * read ------------ current working ACL's ----- Q1) This is the ACL I need to add(?): ----- new acl access to dn.regex="^(.+,)?cn=([^,]+),ou=people,dc=organization,dc=org$" attrs=userPassword by dn="cn=reallysureyouwannauserootdn,dc=organization,dc=org" write by dn="uid=webmail-domain-xyz,ou=adm,dc=organization,dc=org" write by anonymous auth by self write by * none ----- new acl Q2) Since I need these to continue to (co)exist: - users under OU=people continue to have write access to their userpassword fields - all other users (that are not under OU=people) to continue to have write access to their userpassword fields. - the root dn to continue to have write access to everyone's userpassword field - the webmail-domain-xyz to now have write access to user password fields of the users under OU=people (QUESTION) this "new acl" needs to go between the current ACL #2 and ACL #3, right? Since this "new acl" is a subcase of the current ACL #3, I need to put the "new acl" before the ACL #3, and make sure all cases that are _not_ related to the "new acl" do not make a match when the "new acl" is being processed (so they will fall under ACL #3 or go further to the next ACL's). I analized (since a match means "stop processing"): - the "what" - everyone else that do not match the "who" - all DN's under the OU=people - the root DN - the webmail DN (new "who" on the scenario) Q3) If I need to make the regex a little more specific, is this right: dn.regex="^cn=([^1][0-9]+),ou=people,dc=organization,dc=org$" attrs=userPassword (to match cn=10000000000,ou=people,dc=organization,dc=org or cn=19999999999,ou=people,dc=organization,dc=org). Q4) Is ACL #7 gonna be affected by the "new acl"? I mean, if the "webmail-domain-xyz" DN wants do add a new user to OU=people, will ACL processing stop on the "new acl", and never get to the ACL #7? Because the "new acl" only mentions the userPassword attribute, not the right to _add entries under OU=people_. references to get here: - man 5 slapd.access - http://www.openldap.org/lists/openldap-software/200602/msg00077.html - http://www.openldap.org/lists/openldap-software/200602/msg00080.html thanks! = -- Powered by Outblaze

2 1

Can I configure openldap to ignore naming violation errors?
by Sam Cannell 24 Sep '08

24 Sep '08

I'm trying to create an openldap instance to hold some data I'm retrieving from a remote ldap server with ldapsearch. The server is set up and I can create objects in it, but it's refusing to import some of the objects from the ldif I'm getting from ldapsearch. The objects in question are something along the lines of: # foo, stuff, nz dn: o=foo, ou=stuff, c=nz objectClass: top objectClass: organization o: bar So the 'o' attribute doesn't match the dn of the object. Trying to import it gives me the following error: adding new entry "o=foo, ou=stuff, c=nz" ldap_add: Naming violation (64) additional info: value of naming attribute 'o' is not present in entry Google shows me a bunch of other people getting the same error, but the response seems to invariably be 'fix your data'. In my case I'm not in control of the source data, so ideally I'd like to be able to tell slapd to ignore the naming error and import the object anyway. Is this possible?

2 1

Re: Configure Syncrepl with subordinate db
by Moser 23 Sep '08

23 Sep '08

Hi! Petter Solgaard schrieb: > --------ACCESSLOG----- > > database hdb > rootdn "cn=accesslog" > > overlay syncprov I'm not sure, if this is causing your trouble. Try to define accesslog as 2nd subordinate and name it to "cn=accesslog,dc=.....,dc=com". Marc

1 0

Configure Syncrepl with subordinate db
by Petter Solgaard 22 Sep '08

22 Sep '08

Hi I'm trying to set up at new ldap-cluster (openldap 2.4.9 on Ubuntu 8.04). I have splitt the DIT into two dbs, where I have a ou=system under the base that is a subordinate db to the top db. Both dbs is on the same server. What I am wondering is where I should insert the replication information. I tired to put the replication information under the top db on the master and under the top db on the slave. What happens is that information is replicated between the top dbs, but not the subordinates (master to server). I tried adding an additional rid on the subordinate db on the slave and this made the replication work for the subordniate also. But when I the tested with a reboot of the servers the base became corrupt and I had to install everything all over again. Could someone confirm that the replication information should be under the top db on the provider and under both dbs on the consumer? *********************** * Slapd.conf provider: * *********************** modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor moduleload back_bdb moduleload syncprov moduleload accesslog ---------SUBORDINATE---- database hdb suffix "ou=system,dc=......,dc=com" limits dn.exact="cn=replicator,dc=......,dc=com" size=unlimited time=unlimited subordinate index entryUUID,entryCSN eq access to * by dn="cn=replicator,dc=.....,dc=com" read by peername.ip=127.0.0.1 read by * none --------ACCESSLOG----- database hdb rootdn "cn=accesslog" overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=replicator,dc=.....,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart eq --------TOP----- database hdb suffix "dc=.....,dc=com" rootdn "cn=Manager,dc=....,dc=com" rootpw verysecret ### Replikerings-innstillinger ### overlay glue overlay syncprov syncprov-checkpoint 1000 60 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # Let the replicator DN have limitless searches limits dn.exact="cn=replicator,dc=....,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited index entryUUID eq lastmod on access to * by peername.ip=127.0.0.1 read by ssf=128 users read by * none *********************************** * Slapd.conf consumer: * *********************************** # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor moduleload back_bdb -------SUBORDINATE------ database hdb suffix "ou=system,dc=....,dc=com" limits dn.exact="cn=replicator,dc=....,dc=com" size=unlimited time=unlimited index entryUUID eq access to * by dn="cn=replicator,dc=....,dc=com" read by peername.ip=127.0.0.1 read by * none --------TOP----- database hdb # The base of your directory in database #1 suffix "dc=....,dc=com" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=Manager,dc=....,dc=com" rootpw verysecret # Replication from master syncrepl rid=100 provider="ldap://ldap.****.****.com:389" type=refreshAndPersist searchbase="dc=.....,dc=com" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=on bindmethod=simple binddn="cn=replicator,dc=.....,dc=com" credentials="secret" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" retry="60 +" syncdata=accesslog # Refer updates to the master updateref "ldap://ldap.****.****.com:389" index entryUUID eq lastmod on access to * by peername.ip=127.0.0.1 read by ssf=128 users read by * none -- Kind regards Petter S

2 1

Re: OpenLDAP C++ overlay
by Pierangelo Masarati 22 Sep '08

22 Sep '08

Русаков Денис wrote: > > 20.09.08, 18:26, "Pierangelo Masarati" <ando(a)sys-net.it>: > >> Русаков Денис wrote: >>> Hello, all I'd like to ask, is it possible to write OpenLDAP overlay >>> in C++ language? If so could you please provide me some example of >>> code, g++ compile and link options? I tried to do it myself, but only >>> what I've got was not started slapd daemon, but if I use gcc (C >>> language) all is ok. Thank you, Denis >> You can simply use OpenLDAP's libtool like this: >> ./libtool --mode=compile g++ -I include/ -I servers/slapd/ -fPIC \ >> -o cxxover.lo -c cxxover.cc >> ./libtool --mode=link g++ -lstdc++ -module -o libcxxover.la cxxover.lo >> p. >> 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 >> ----------------------------------- > > Thank you for your e-mail, but I'd like to have shared object file and write in slapd.conf something like that: moduleload mymodule.so. > How could I do this? The above actually generates a shared object file (on architectures where this is possible), which are then loaded by "moduleload yourmodule.la" in slapd.conf. See, for example, the Makefile provided in contrib/slapd-modules/smbk5pwd/. p. 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 -----------------------------------

1 0

Re: OpenLDAP C++ overlay
by Pierangelo Masarati 22 Sep '08

22 Sep '08

Русаков Денис wrote: > I've got only: > lt_dlopenext failed: (libmymodule.la) /usr/lib/libmymodule.a: invalid ELF header > slapd destroy: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > What should I do with invalid ELF header? Well, all I can say right now is that it works for me. p. 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 -----------------------------------

2 1

syncrepl 2.4 parse error
by FRLinux 22 Sep '08

22 Sep '08

Hello, I have a master on OpenLDAP 2.3 (BDB 4.2) on FreeBSD 6.3-STABLE. I have been replicating its directory via syncrepl which works flawlessly on 2.3 systems. I have installed a brand new system using FreeBSD 7.1-BETA and OpenLDAP 2.4.11 (BDB 4.6). Using the same synrepl configuration, il fails to parse the configuration file. I did read the migration guide and the admin guide for 2.4 but I can't make sense of this. In debug mode, this is what i get (changed my dc with example): <<< dnNormalize: <dc=example,dc=com> /usr/local/etc/openldap/slapd.conf: line 177: Error: parse_syncrepl_line: unable to parse "updatedn=cn=MyAdminr,dc=example,dc=com" . failed to add syncinfo Now, the relevant slapd.conf conf bit is: syncrepl rid=666 \ provider=ldaps://master.example.com:636 \ type=refreshAndPersist \ searchbase="dc=example,dc=com" \ scope=sub \ filter="(objectClass=*)" \ attrs="*" \ schemachecking=off \ updatedn="cn=MyAdmin,dc=example,dc=com" \ bindmethod=simple \ binddn="cn=LdapSyncUser,dc=example,dc=com" \ credentials=mysupersecretpass updateref ldaps://master.example.com Has anyone encountered this before? A bit of reading on various threads did not return anything useful so far. Cheers, Steph

2 2

OpenLDAP C++ overlay
by Русаков Денис 20 Sep '08

20 Sep '08

Hello, all I'd like to ask, is it possible to write OpenLDAP overlay in C++ language? If so could you please provide me some example of code, g++ compile and link options? I tried to do it myself, but only what I've got was not started slapd daemon, but if I use gcc (C language) all is ok. Thank you, Denis

2 1

Invalid syntax :protocol information: no validator for syntax
by Prashant kulkarni 19 Sep '08

19 Sep '08

Hi I am trying to add the value to the attribute "protocol information" which is required in our schema but I am getting the error Invalid syntax :protocol information: no validator for syntax 1.3.6.1.4.1.1466.115.121.1.42 from the earlier mailing list I have found The problem seems to be lack of validations in the schema_init.c source code for attribure 'Protocol Information' {"( 1.3.6.1.4.1.1466.115.121.1.42 DESC 'Protocol Information' )", 0, NULL, NULL, NULL}, isn't it that including values like dnPretty ,UTF8StringValidate..etc in the code instead of NULL values may resolve the problem this attribute protocolInformation is defined in core.schema I personally feel that for those attributes where validation are NULL in schema_init.c , the openLDAP should not force the validation and give this error message as all these attributes in which validation are not defined becomes unusable . So any idea how to resolve this ? there is any way to modify any of the config file in openldap to disable this validation for protocol information ? do I have to raise bug request for the same and is this going to be fixed in next openLDAP release. Any help and suggestions in this direction is highly appreciated. as I am porting the schema from Sun directory server and & I have to use this protocol informatoin attribute so as our LDAP application which is utilized by thousands of people can be migrated to OpenLDAP. I am not getting these kind of error in Tivoli/Sun and Microsoft Active directory for editing of this attribute . thanks and regards Prashant

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software September 2008