openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Re: Changing cert paths may cause openldap to stop
by Quanah Gibson-Mount 01 Apr '14

01 Apr '14

--On Thursday, March 27, 2014 1:52 PM +0200 Nick Milas <nick(a)eurobjects.com> wrote: > Hi, > > On 2.4.39 (CentOS 5.10 x86_64), I found that if I attempt to change > certificate values but there is an error in a path, openldap stops. > > I would expect this should be avoided. Openldap should reject the > modification and not stop. > > Running the modification below, it hungs; we press Ctrl-C (and we print a > full backtrace), then we find slapd is stopped. File an ITS. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: Problem after migration openldap 2.3.43 to 2.4.23 --> 32 No Such Object
by Jonas Kellens 01 Apr '14

01 Apr '14

On 01-04-14 10:53, Terje Trane wrote: > On 01.04.2014 09:58, Jonas Kellens wrote: >> >> even if I add at the beginning of slapd.conf the following : >> >> access to * by * >> >> I still get no results with the user 'cn=U101001,ou=101001,dc=mydomain' >> >> I only get result with 'cn=Manager,dc=mydomain' >> > > Remember that ACLs are "first match used". > > If a database does not have an ACL the global ACL applies. > > But if it has a database specific ACL, that one is read first when > accessing that particular database, and the global then *only* used if > there is no match (or a control keyword like break or continue is > specified) I posted it before, but will post it again. This is the database specific ACL : database bdb suffix "dc=mydomain" rootdn "cn=Manager,dc=mydomain" rootpw {SSHA}blCAG/CNdFPY597Cf4Ssuj access to attrs=userPassword by * auth access to dn.regex="ou=tbook[12345],ou=contacten,ou=101001,dc=mydomain" attrs=children by group.exact="cn=admins,ou=101001,dc=mydomain" write by * none break access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook2,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook3,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook4,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook5,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=101001,dc=mydomain" read If user 'cn=U101001,ou=101001,dc=mydomain' is member of group "cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain", wouldn't you agree that it should be able to read the entries in dn "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" ?? Kind regards, Jonas.

4 6

RE: Slave not able to update master pwdFailureTime via chain.
by serpent6877 01 Apr '14

01 Apr '14

Anyone else have an answer for this? Thanks, Brad -------- Original message -------- From: Brad dameron <serpent6877(a)hotmail.com> Date:03/24/2014 8:36 AM (GMT-08:00) To: Esteban Pereira <esteban.pereira(a)gepsit.fr>,openldap-technical(a)openldap.org Subject: RE: Slave not able to update master pwdFailureTime via chain. >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 > > >

2 1

openldap for fedora
by Brendan Kearney 30 Mar '14

30 Mar '14

i hope to be getting some new machines and updating/upgrading my ldap instances in the process. i am looking to use the ltb-project.org rpms for the install, but have a couple of questions. first, i do not see any fedora versions in the repo. only redhat 5 and 6. are these packages binary compatible with fedora? second, it seems that the packages use the Sys V Init style, as i am sure the RH servers still use. although that is supported for legacy compatibility in fedora, does the new systemd init style work with these packages? third, is a package for fedora versions available through the ltb-project site? thank you, brendan

2 1

What is the replacement for /etc/ldap.conf?
by Peng Yu 30 Mar '14

30 Mar '14

Hi, http://ubuntuforums.org/showthread.php?t=1421998 The above link mentioned the following code. But /etc/ldap.conf is not available on ubuntu 13.10. Does anybody know what I should do instead? Thanks. sudo echo "index sudoUser eq" >> /etc/ldap.conf -- Regards, Peng

4 3

Why "ldapadd -x -D cn=admin, cn=config -W -f ~/sudoWork/cn\=sudo.ldif" does not work?
by Peng Yu 29 Mar '14

29 Mar '14

Hi, I followed the following instructions. http://ubuntuforums.org/showthread.php?t=1421998 I get the following error. pengy@openldapserver:~$ ldapadd -x -D cn=admin,cn=config -W -f ~/sudoWork/cn\=sudo.ldif Enter LDAP Password: ldap_bind: Invalid credentials (49) Here is the log. Does anybody know what the log means and how to fix the problem? Thanks. pengy@openldapserver:~$ tail -n 5 /var/log/syslog Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 fd=21 ACCEPT from IP=127.0.0.1:47481 (IP=0.0.0.0:389) Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=0 BIND dn="cn=admin,cn=config" method=128 Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=0 RESULT tag=97 err=49 text= Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=1 UNBIND Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 fd=21 closed -- Regards, Peng

4 6

Re: What is the default of `-b`?
by Peng Yu 29 Mar '14

29 Mar '14

How to search for everything in the ldap database (such config)? On Fri, Mar 28, 2014 at 8:31 AM, Brad Hartlove <bradley.hartlove(a)g2-inc.com> wrote: > Peng > > The default of "-b" should be whatever you have specified in your > ldap.conf configuration file. In a fresh install, without any > configuration, I do not believe it will look for any base. The "-b" flag > is used to specify the base of the tree from where you wish to begin your > search. If you also pass the "-v" flag, it will spit out the base you are > using ex:" # base <dc=somedomain,dc=com> with scope subtree". In the > ldap.conf (typically located in your /etc/opendlap directory in linux), > the directive you want to set is "BASE". It natively comes with something > that is commented out ex: #BASE dc=example,dc=com. You need to > uncomment and add the appropriate base location from where you wish to > operate. Bear in mind that this affects the behavior of all your OpenLDAP > client calls if the "-b" is not specified in the command string. > > Regards, > Brad Hartlove > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Peng Yu > Sent: Thursday, March 27, 2014 4:17 PM > To: openldap-technical(a)openldap.org > Subject: What is the default of `-b`? > > Hi, > > The man page says the following. > > `-b` *searchbase* > : Use *searchbase* as the starting point for the search instead of > the default. > > I'm wondering what is the default. If I don't specify -b, I will get an > error. Does anyone know how show all the contents from the database? > Thanks. > > $ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn > dn: cn=config > > dn: cn=module{0},cn=config > > dn: cn=schema,cn=config > > dn: cn={0}core,cn=schema,cn=config > > dn: cn={1}cosine,cn=schema,cn=config > > dn: cn={2}nis,cn=schema,cn=config > > dn: cn={3}inetorgperson,cn=schema,cn=config > > dn: olcBackend={0}hdb,cn=config > > dn: olcDatabase={-1}frontend,cn=config > > dn: olcDatabase={0}config,cn=config > > dn: olcDatabase={1}hdb,cn=config > > $ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// dn No such object (32) > > -- > Regards, > Peng -- Regards, Peng

1 0

Re: memberof in openldap
by Howard Chu 28 Mar '14

28 Mar '14

Brad Hartlove wrote: > I get everything you said. I also understand that this may be a valid > permissions issue. If the answer is "it isn't supposed to be done and the > server will prevent that", that is what I will go with. This is not my > first dance, but if I already knew every detail of LDAP's code, I wouldn't > be on this mailing list. There is no such thing as "LDAP's code" - LDAP is a protocol definition built on a data model. There is "OpenLDAP code" and "SunDS code" etc., various other implementations of the protocol and data model. It is well documented that Sun/Netscape/RedHat/Microsoft implemented the specs incorrectly. As I have said, I am seeing this defined in > another LDAP's objectClass, so someone figured it out right, wrong, or > indifferent. I am not here to argue, so if that is what I go with, so be > it. > Brad Hartlove > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Friday, March 28, 2014 11:08 AM > To: Michael Ströder; brad.hartlove(a)g2-inc.com; > openldap-technical(a)openldap.org > Subject: Re: memberof in openldap > > Michael Ströder wrote: >> Brad Hartlove wrote: >>> The core problem is why can I not add the operational attribute to my >>> custom objectclass. >> >> Operational attributes are simply not normal user attributes. >> >> If your LDAP client is supposed to alter an attribute via LDAP it has >> to be a user attribute. Period. > > That's only a partial answer. > > Brad, the answer is "go read the LDAP spec" - operational attributes are > never part of any objectclass definition, and the server is free to use > them in any entry regardless of objectclass. > > The OpenLDAP manpages are not here to teach you the basics of LDAP. You're > expected to read the specs and know the basics of LDAP. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Syncrepl Multi-Master with multiple BDB backends
by Michael 28 Mar '14

28 Mar '14

I have two servers i'd like to setup to do MMR. I have several BDB backends that I would like to replicate. My question is do I need to create a "replicate" user for each BDB backend as well as a syncrepl statement under each BDB definition and an acl to allow the sync user to read the each BDB? Consider the slapd configuration below. Or is is possible to just setup one user with read access to all of my BDB backends and then setup just one syncrepl statement? serverID 1 ldap://txeduds1 serverID 2 ldap://txeduds2 database bdb suffix "dc=il,dc=edu,dc=com" rootdn "cn=LDAPAdmin,dc=il,dc=edu,dc=com" rootpw xxxx directory /var/lib/ldap/ldap.edu.il monitoring off syncrepl rid=001 provider=ldap://txeduds1:389 type=refreshAndPersist retry="60 10 300 +" searchbase="dc=il,dc=edu,dc=com" attrs="*,+" schemachecking=off bindmethod=simple starttls=no tls_reqcert=never binddn="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com" credentials=xxxx ##Syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 mirrormode on limits dn.exact="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #################################################################################### #################################################################################### access to attrs=userpassword by dn.base="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com read by self write by anonymous auth by * none database bdb suffix "dc=nj,dc=edu,dc=com" rootdn "cn=LDAPAdmin,dc=nj,dc=edu,dc=com" rootpw xxxx directory /var/lib/ldap/ldap.edu.nj monitoring off syncrepl rid=001 provider=ldap://txeduds1:389 type=refreshAndPersist retry="60 10 300 +" searchbase="dc=nj,dc=edu,dc=com" attrs="*,+" schemachecking=off bindmethod=simple starttls=no tls_reqcert=never binddn="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com" credentials=xxx ##Syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 mirrormode on limits dn.exact="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #################################################################################### #################################################################################### access to attrs=userpassword by dn.base="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com" read by self write by anonymous auth by * none database bdb suffix "dc=ga,dc=edu,dc=com" rootdn "cn=LDAPAdmin,dc=ga,dc=edu,dc=com" rootpw xxx directory /var/lib/ldap/ldap.edu.ga syncrepl rid=001 provider=ldap://txeduds1:389 type=refreshAndPersist retry="60 10 300 +" searchbase="dc=ga,dc=edu,dc=com" attrs="*,+" schemachecking=off bindmethod=simple starttls=no tls_reqcert=never binddn="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com" credentials=xxx ##Syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 mirrormode on

2 2

cn=config replication mistake
by Ferenc Wagner 28 Mar '14

28 Mar '14

Hi, First, please let me tell you the story of my adventure yesterday. I'll summarize my questions at the end. I've set up a simple master-slave replicated system some time ago (stock Debian wheezy OpenLDAP, version 2.4.31-1+nmu2): dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=1 provider=ldap://elm.niif.hu [...] dn: olcDatabase={1}mdb,cn=config olcSyncrepl: {0}rid=2 provider=ldap://elm.niif.hu [...] The slave opened two connections to the master, and everything worked fine. Then I enabled TLS and put in a CNAME record, so that the master became accessible as ldaps://ldap-master.niif.hu. I decided to also switch over the replication traffic to the SSL channel, so ldapmodified the above attributes to contain provider=ldaps://ldap-master.niif.hu. This pretty much broke the system, because the master server suddenly started to replicate from itself, thus became read-only. Finding no other option, I stopped the "master" slapd and edited back the providers to their previous values (above) in the olcDatabase={0}config.ldif and olcDatabase={1}mdb.ldif files under the cn=config directory of my server configuration. I know these files should not be edited, but I found no other way. This move made the master recognized itself again in the provider URI, so it did not start replicating and became writeable. My edits, however, did not propagate to the slave, probably because I did not change the internal attributes (entryCSN?) so this was expected. Also, slapcat started to report CRC warnings in some LDIF files while dumping the databases, which was also understandable for the edited ones, but not so much for cn=config.ldif (if I remember correctly). I tried to fix these by doing some dummy changes by ldapmodify to the database entries. For both, I added an extra olcAccess attribute, then deleted it. These operations made the slave switch back its syncrepl connections to the ldap port from ldaps, but also instantly broke the slave server, which stopped returning results and instead logged lots of slapd[27944]: => mdb_idl_fetch_key: cursor failed: Invalid argument (22) lines. Having no better idea, I restarted the slave server, which fortunately returned it to normal working condition. So, my questions: 1. How does the "self-recognition" (by which the master does not start replicating from itself) work, why did it fail when I changed the provider URI to ldaps? Did using a CNAME (instead of some FQDN of the server) confuse it? Could this be fixed by adding an appropriate subjectAltName to the server TLS certificate? Or by adding some olcServerID attributes? 2. How could I have handled the read-only situation, instead of editing forbidden LDIF files? Would setting olcMirrorMode have been possible (without olcServerIDs around)? 3. Is my setup in a reliable and consistent state now, or should I expect sudden future failures? I mean, were the "cursor failed" errors fixed for good by the slave server restart? Please also feel free to educate me on any other points, as needed. :) -- Thanks, Feri.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical