openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Not adding attributes
by espeake＠oreillyauto.com 26 Mar '14

26 Mar '14

I have just started getting this error in the past 10 days. There has not been any configuration changes that we can find. In googleing this error I am not finding anything that matches it. If I create an ldif file to add these for the user, that works fine. Mar 25 16:42:21 tn-ldap-1 slapd[14976]: conn=33594 op=17: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add locationEntry="ou=Store4351,ou=Locations,dc=oreillyauto,dc=com" failed err=32 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=19: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add oreillyGroup="cn=Store Non-Management,ou=Groups,dc=oreillyauto,dc=com" failed err=32 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=21: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add oreillyGroup="cn=Store,ou=Groups,dc=oreillyauto,dc=com" failed err=32 What I do wonder about though in my olcDatabase={1}hdb folder I have two memberOf overlays. This is the first one. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a078db21 dn: olcOverlay={0}memberof objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfUniqueNames olcMemberOfMemberAD: uniqueMember olcMemberOfMemberOfAD: oreillyGroup structuralObjectClass: olcMemberOf creatorsName: cn=config entryUUID: 91cea156-9e13-1032-84c3-0151b658a842 createTimestamp: 20130820183919Z entryCSN: 20130820183919.833799Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130820183919Z This is the second one. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 fe8a4925 dn: olcOverlay={1}memberof objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {1}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: oreillyOrgUnit olcMemberOfMemberAD: uniqueMember olcMemberOfMemberOfAD: locationEntry structuralObjectClass: olcMemberOf creatorsName: cn=config entryUUID: 91ceb650-9e13-1032-84c4-0151b658a842 createTimestamp: 20130820183919Z entryCSN: 20130820183919.834337Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130820183919Z I have am looking through the application to see if something could have changed in the way it is presenting the data. I haven't found anything yet. Am I correct in that an error 32 means that it couldn't find the uid to add the group to? Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

2 2

question about openldap restore with command sldapadd
by xiaoming zhao 26 Mar '14

26 Mar '14

All, I got one question, when doing openldap restore, in our script, we tried to remove the openldap/data directory, then restore the backup openldap files. but since we have other data added in openldap database after backup. then if we doing backup, it will remove the data newly added after backup. I tried to sldapadd with "-c" option, but the sldapadd command retrun value is 1. so we can't know if this is a error because of existing entry or some other error. Do you have any idea how to handle this case? ignore the existing entry when doing sldapadd. Thanks, Eric.

2 6

unsubscribe
by Alex Samad - Yieldbroker 26 Mar '14

26 Mar '14

1 0

Denying access to syncrepl consumere during initial DIT content load
by Christian Kratzer 24 Mar '14

24 Mar '14

Hi, I remember a discussion some time ago about the possibility of delaying access to a syncrepl. consumer during the intial DIT load. I have setup my servers to authenticate replication via sasl method external and the servers respective certificates which is nice. I have also setup limits and acl to the DIT as using a groupOfNames: olcLimits: group/groupOfNames/member="cn=replicators,ou=serviceaccounts,dc=cksoft,dc=net" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited olcAccess: to * by group/groupOfNames/member="cn=replicators,ou=serviceaccounts,dc=cksoft,dc=net" read This is all nice and shiny and I like having my ldap consumers configured without cleartext credentials (apart from the cert private key of course) ;) The fun starts when I delete the DIT from multiple consumers and allow them to resync from masters. If they also resync from each other they could possibly authenticate using sasl external but they would not be allowed access to all of the DIT, all of the attributes or be unlimited using olcLimits as the group might not yet have been replicated. I also had major fun just reseeding a single server out of a set of 4 causing data loss on the servers that connected to the not yet full synced up server. This is another situation in which it would be nice to be able to disallow any ldap connections to a consumere while it is in the initial sync phase. I seem to recall there was discussion in possibly addiing such a feature but my google foo is lacking and I cannot find the discussion. In case there is not yet such a feauture I am considering firewalling access to slapd during the initial sync phase. Is there any ldap way of reliably detecting that initial sync has completed apart from tailing syslog and looking for csn commit messages ... Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/

7 21

RE: Slave not able to update master pwdFailureTime via chain.
by Brad dameron 24 Mar '14

24 Mar '14

>From what I read I need to setup authzTo. But having problems understanding what I need to set in the slaps.conf and on the allowed user. -------- Original message -------- From: Esteban Pereira <esteban.pereira(a)gepsit.fr> Date:03/20/2014 10:55 AM (GMT-08:00) To: Brad dameron <serpent6877(a)hotmail.com>,openldap-technical(a)openldap.org Subject: Re: Slave not able to update master pwdFailureTime via chain. I've never configured this kind of architecture, but as far as I know the ppolicy, I think my first thought configuring this would have been to not rebind as user because the attribute modified is an operational one which need the manage right (not sure about that) So I should have configured this with the replication user with manage right and without rebinding as a user when chaining to the master. Hope this help On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877(a)hotmail.com>wrote: > I understand what you are saying. But this is what the > ppolicy_forward_updates says: > > ppolicy_forward_updates > Specify that policy state changes that result from Bind operations (such as recording > failures, lockout, etc.) on a consumer should be forwarded to a master instead of > being written directly into the consumer’s local database. This setting is only use‐ > ful on a replication consumer, and also requires the updateref setting and chain > overlay to be appropriately configured. > > So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD > from what I have seen in my logs. And thus the user doesn't have access to modify this attribute. > > Brad > > > > ------------------------------ > Date: Thu, 20 Mar 2014 12:13:02 +0100 > Subject: Re: Slave not able to update master pwdFailureTime via chain. > From: esteban.pereira(a)gepsit.fr > To: serpent6877(a)hotmail.com > CC: openldap-technical(a)openldap.org > > > Hi Brad, > > pwdFailureTime is an operational attribute, I don't think any user can > modify it on any instance. May be you should try to modify it on the master > to see if it comes from this assumption. > > Esteban > > > On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877(a)hotmail.com>wrote: > > OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime > updated on the master when the slave recieves a password failure. Here is > my config. It's pretty simple and basic. No TLS. > > Master: > > access to attrs=userPassword > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" read > by self write > by anonymous auth > by * none > access to * > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" write > by self write > by users read > by anonymous read > by * none > > > > Slave: > > overlay chain > chain-uri ldap://172.16.0.84:389 > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > mode="self" > chain-return-error TRUE > > # Password Policy > overlay ppolicy > ppolicy_default "cn=default,ou=Policies,dc=test,dc=net > ppolicy_use_lockout > ppolicy_forward_updates > > > # Slave Replication > syncrepl rid=101 > provider=ldap://172.16.0.84:389 > type=refreshAndPersist > interval=00:00:01:00 > retry="60 10 300 +" > searchbase="dc=test,dc=net" > schemachecking=off > bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > updateref "ldap://172.16.0.84:389" > > > > I see the connection on the master but it gives a permission error: > > > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > dn="cn=testuser,ou=People,dc=test,dc=net" > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > attr=pwdFailureTime > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103 > err=50 text= > > > I read that you maybe need authzTo added to the binddn for the chain? Or > is this only for TLS? > > I tried adding this ldif: > > dn: cn=replication,dc=test,dc=net > changetype: modify > add: authzTo > authzTo: * > > And even set the: > > chain-idassert-authzFrom "*" > > in the chain. But it always gives me the error code 50 not enough > permissions. I believe it is supposed to give access to the user to MOD the > pwdFailureTime tribute knowing it is coming from a relay. But I can't find > very specific docs on this or see what is wrong. Any help apreciated. > > Thanks, > Brad > > >

1 0

Build mdb tools
by "POISSON Frédéric" 21 Mar '14

21 Mar '14

Hello, I'm trying to build mdb tools (mdb_stat and mdb_copy inside libraries/liblmdb directory) on a Solaris 10 SPARC operating system with OpenLDAP 2.4.39. Is there some requirements for building the tools on this OS because i have a error during build ? Here is my result (while i do not set any specific gcc flags) : # make ... gcc -pthreads -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast mdb_stat.o liblmdb.a -o mdb_stat Undefined first referenced symbol in file fdatasync liblmdb.a(mdb.o) ld: fatal: Symbol referencing errors. No output written to mdb_stat collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `mdb_stat' # Notice that i use a gcc 3.4.3 and gcc option "-pthread" do not exist for this gcc release, i had to replace it by "-pthreads". I try to read mdb.c for any specific options but i don't find anything... Notice also that i succeed to build OpenLDAP 2.4.39 with my Solaris 10 environment. Thanks, -- Frederic Poisson

5 5

Re : Re: Build mdb tools
by "POISSON Frédéric" 21 Mar '14

21 Mar '14

Hello, Thanks for the answer, i build it without errors. I have patched the Makefile by for my Solaris 10 with gcc 3.4.3 : - replacing "-pthread" by "-pthreads", - add "-lrt" to OPT parameter. Regards, Le 20/03/14, Howard Chu <hyc(a)symas.com> a écrit : > "POISSON Frédéric" wrote: > >Hello, > > > >I'm trying to build mdb tools (mdb_stat and mdb_copy inside libraries/liblmdb > >directory) on a Solaris 10 SPARC operating system with OpenLDAP 2.4.39. > > > >Is there some requirements for building the tools on this OS because i have a > >error during build ? > > > >Here is my result (while i do not set any specific gcc flags) : > ># make > >... > >gcc -pthreads -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > >mdb_stat.o liblmdb.a -o mdb_stat > >Undefined first referenced > > symbol in file > >fdatasync liblmdb.a(mdb.o) > >ld: fatal: Symbol referencing errors. No output written to mdb_stat > >collect2: ld returned 1 exit status > >*** Error code 1 > >make: Fatal error: Command failed for target `mdb_stat' > ># > > Read the Solaris manpage for fdatasync. > > The requirement for building on any given OS is that you know your own OS. > > >Notice that i use a gcc 3.4.3 and gcc option "-pthread" do not exist for this > >gcc release, i had to replace it by "-pthreads". I try to read mdb.c for any > >specific options but i don't find anything... > > > >Notice also that i succeed to build OpenLDAP 2.4.39 with my Solaris 10 > >environment. > > > >Thanks, > >-- > > > >*Frederic Poisson* > > > > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > -- Frederic Poisson

1 0

Re: Slave not able to update master pwdFailureTime via chain.
by Esteban Pereira 20 Mar '14

20 Mar '14

I've never configured this kind of architecture, but as far as I know the ppolicy, I think my first thought configuring this would have been to not rebind as user because the attribute modified is an operational one which need the manage right (not sure about that) So I should have configured this with the replication user with manage right and without rebinding as a user when chaining to the master. Hope this help On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877(a)hotmail.com>wrote: > I understand what you are saying. But this is what the > ppolicy_forward_updates says: > > ppolicy_forward_updates > Specify that policy state changes that result from Bind operations (such as recording > failures, lockout, etc.) on a consumer should be forwarded to a master instead of > being written directly into the consumer’s local database. This setting is only use‐ > ful on a replication consumer, and also requires the updateref setting and chain > overlay to be appropriately configured. > > So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD > from what I have seen in my logs. And thus the user doesn't have access to modify this attribute. > > Brad > > > > ------------------------------ > Date: Thu, 20 Mar 2014 12:13:02 +0100 > Subject: Re: Slave not able to update master pwdFailureTime via chain. > From: esteban.pereira(a)gepsit.fr > To: serpent6877(a)hotmail.com > CC: openldap-technical(a)openldap.org > > > Hi Brad, > > pwdFailureTime is an operational attribute, I don't think any user can > modify it on any instance. May be you should try to modify it on the master > to see if it comes from this assumption. > > Esteban > > > On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877(a)hotmail.com>wrote: > > OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime > updated on the master when the slave recieves a password failure. Here is > my config. It's pretty simple and basic. No TLS. > > Master: > > access to attrs=userPassword > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" read > by self write > by anonymous auth > by * none > access to * > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" write > by self write > by users read > by anonymous read > by * none > > > > Slave: > > overlay chain > chain-uri ldap://172.16.0.84:389 > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > mode="self" > chain-return-error TRUE > > # Password Policy > overlay ppolicy > ppolicy_default "cn=default,ou=Policies,dc=test,dc=net > ppolicy_use_lockout > ppolicy_forward_updates > > > # Slave Replication > syncrepl rid=101 > provider=ldap://172.16.0.84:389 > type=refreshAndPersist > interval=00:00:01:00 > retry="60 10 300 +" > searchbase="dc=test,dc=net" > schemachecking=off > bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > updateref "ldap://172.16.0.84:389" > > > > I see the connection on the master but it gives a permission error: > > > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > dn="cn=testuser,ou=People,dc=test,dc=net" > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > attr=pwdFailureTime > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103 > err=50 text= > > > I read that you maybe need authzTo added to the binddn for the chain? Or > is this only for TLS? > > I tried adding this ldif: > > dn: cn=replication,dc=test,dc=net > changetype: modify > add: authzTo > authzTo: * > > And even set the: > > chain-idassert-authzFrom "*" > > in the chain. But it always gives me the error code 50 not enough > permissions. I believe it is supposed to give access to the user to MOD the > pwdFailureTime tribute knowing it is coming from a relay. But I can't find > very specific docs on this or see what is wrong. Any help apreciated. > > Thanks, > Brad > > >

1 0

Cups Schema
by Borresen, John - 0442 - MITLL 20 Mar '14

20 Mar '14

Hopefully, someone can point me in the correct direction. Forgive me if this falls into the category of "What is the color of George Washington's white horse?" But, I want to do this in the correct way. Using this schema: # Definitions for a schema to store CUPS printer information in LDAP # OID Base is iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) me(5323) cupsSchema(22) # Syntaxes are under 1.3.6.1.4.1.5323.22.0 # Attributes are under 1.3.6.1.4.1.5323.22.1 # Object Classes are under 1.3.6.1.4.1.5323.22.2 attributetype ( 1.3.6.1.4.1.5323.22.1.1 NAME 'printerDescription' DESC 'Description of Printer' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributetype ( 1.3.6.1.4.1.5323.22.1.2 NAME 'printerURI' DESC 'CUPS style URI for printer' EQUALITY caseExactIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.5323.22.1.3 NAME 'printerLocation' DESC 'Identifier string for Printer Location' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributetype ( 1.3.6.1.4.1.5323.22.1.4 NAME 'printerMakeAndModel' DESC 'String CUPS uses to figure out driver' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributetype ( 1.3.6.1.4.1.5323.22.1.5 NAME 'printerType' DESC 'Integer CUPS uses to figure out type' EQUALITY integerMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) objectclass ( 1.3.6.1.4.1.5323.22.2.1 NAME 'cupsPrinter' SUP top AUXILIARY MUST ( printerDescription $ printerURI $ printerLocation $ printerMakeAndModel $ printerType ) ) There is no Structural ObjectClass defined specifically in this schema. Would I use the same ObjectClass as I used to define Hosts, it is a network device. Thanks, John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen(a)ll.mit.edu

3 2

Slave not able to update master pwdFailureTime via chain.
by Brad dameron 20 Mar '14

20 Mar '14

OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime updated on the master when the slave recieves a password failure. Here is my config. It's pretty simple and basic. No TLS. Master: access to attrs=userPassword by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write by dn.exact="cn=replication,dc=test,dc=net" read by self write by anonymous auth by * none access to * by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write by dn.exact="cn=replication,dc=test,dc=net" write by self write by users read by anonymous read by * none Slave: overlay chain chain-uri ldap://172.16.0.84:389 chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=replication,dc=test,dc=net" credentials="MyPasswd" mode="self" chain-return-error TRUE # Password Policy overlay ppolicy ppolicy_default "cn=default,ou=Policies,dc=test,dc=net ppolicy_use_lockout ppolicy_forward_updates # Slave Replication syncrepl rid=101 provider=ldap://172.16.0.84:389 type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="dc=test,dc=net" schemachecking=off bindmethod=simple binddn="cn=replication,dc=test,dc=net" credentials="MyPasswd" updateref "ldap://172.16.0.84:389" I see the connection on the master but it gives a permission error: Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD dn="cn=testuser,ou=People,dc=test,dc=net" Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD attr=pwdFailureTime Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103 err=50 text= I read that you maybe need authzTo added to the binddn for the chain? Or is this only for TLS? I tried adding this ldif: dn: cn=replication,dc=test,dc=net changetype: modify add: authzTo authzTo: * And even set the: chain-idassert-authzFrom "*" in the chain. But it always gives me the error code 50 not enough permissions. I believe it is supposed to give access to the user to MOD the pwdFailureTime tribute knowing it is coming from a relay. But I can't find very specific docs on this or see what is wrong. Any help apreciated. Thanks, Brad

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