openldap-technical October 2013

openldap-technical@openldap.org

63 participants
67 discussions

temporarily removing a group object in SLES11
by Ulrich Windl 16 Oct '13

16 Oct '13

Hi! I realized that in SLES11 SP2 the YaST user management module does recreate a group (instead of modifying it) when you add a user to the particular group. I wonder what the consequences could be (despite of the unnecessary deltas being created). Did anybody else notice this, or even had some negative experience caused by that, escpecially for groups with many members? Regards, Ulrich

2 3

Q: access rights for shadowAccount attributes
by Ulrich Windl 16 Oct '13

16 Oct '13

Hi! I wonder what the minimum required access rights for the attributes of shadowAccount are: Should they be protected the same way the password is? At the moment an anonymous bind can read them (i.e. no special access rules present). Regards, Ulrich

2 1

Need help with replica
by Jacques Foucry 15 Oct '13

15 Oct '13

Hello list, I created a VM to test ppolicy migration and replication. On my master server some user (like mine) are "bind" to ppolicy: I have a OU policies dn: cn=default,ou=policies,dc=example,dc=com cn: default objectclass: top objectclass: device objectclass: pwdPolicy objectclass: pwdPolicyChecker pwdallowuserchange: TRUE pwdattribute: userPassword pwdcheckmodule: mmc-check-password.so pwdcheckquality: 0 pwdexpirewarning: 600 pwdfailurecountinterval: 0 pwdgraceauthnlimit: 5 pwdinhistory: 5 pwdlockout: TRUE pwdlockoutduration: 0 pwdmaxage: 7776000 pwdmaxfailure: 5 pwdminlength: 8 pwdmustchange: TRUE pwdsafemodify: FALSE And my user: dn: cn=Jacques Foucry,ou=People,dc=example,dc=com c: France cn: Jacques Foucry gidnumber: 1000 givenname: Jacques homedirectory: /home/jfoucry loginshell: /bin/zsh mail: jacques.foucry(a)example.com objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha objectclass: sambaSamAccount objectclass: posixAccount objectclass: top objectclass: shadowAccount objectclass: pwdPolicy ou: RT_Users postalcode: 75009 pwdattribute: userPassword sambaacctflags: [U] shadowlastchange: 15987 shadowmax: 120 shadowmin: 7 shadowwarning: 7 sn: Foucry uid: jfoucry uidnumber: 1010 userpassword: --password-- On the replica mv. I created a slapd.conf file (I cannot understand the "new" syntax). include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/mozillaAbPersonAlpha.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/pureftpd.schema include /etc/ldap/schema/ppolicy.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel config sync modulepath /usr/lib/ldap moduleload back_hdb database hdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}--password-- directory /var/lib/ldap referral ldaps://192.168.72.13 syncrepl rid=020 provider=ldaps://192.168.72.13 type=refreshOnly interval=00:08:00:00 retry="60 10 300 +" filter="(objectClass=*)" scope=sub attrs="*" bindmethod=simple schemachecking=off searchbase="dc=exmaple,dc=com" binddn="cn=syncuser,dc=exmaple,dc=com" credentials=--password-- tls_reqcert=never When I start slapd on the slave vm, It sound correct but only few off my user records are sync. For example mine is not. One the master: # ldapsearch -x -b"ou=people,dc=example,dc=com" uid=jfoucry # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=jfoucry # requesting: ALL # # Jacques Foucry, People, example.com dn: cn=Jacques Foucry,ou=People,dc=example,dc=com c: France cn: Jacques Foucry mail: jacques.foucry(a)example.com gidNumber: 1000 givenName: Jacques homeDirectory: /home/jfoucry loginShell: /bin/zsh ou: RT_Users postalCode: 75009 shadowMax: 120 shadowMin: 7 shadowWarning: 7 sn: Foucry uidNumber: 1010 uid: jfoucry objectClass: inetOrgPerson objectClass: mozillaAbPersonAlpha objectClass: sambaSamAccount objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: pwdPolicy pwdAttribute: userPassword shadowLastChange: 15987 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On the slave: ldapsearch -x -b"ou=people,dc=exmaple,dc=com" uid=jfoucry # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=jfoucry # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 I can't figure what's wrong. Why some records are sync and other are not? Is it because of ppolicy? Thanks in advance for your help, Jacques Foucry -- Jacques Foucry *NOVΛSPARKS * IT Manager Tel : +33 (0)1 42 68 12 61 jacques.foucry(a)novasparks.com

2 1

remove unused schema from cn=config in n-way multi-master setup
by Igor Zinovik 14 Oct '13

14 Oct '13

Hello, opeldap-technical@ readers. I have a 3 nodes n-way multi-master setup configured accroding to OpenLDAP Admin Guide. Currently my catalog configuration stores custom schema which I made some time ago, but it no longer needed, so I would like to delete my custom schema from configuration. Replication is bothering me the most. I understand that consequences would be unexpectable when one of my server will see that other node is telling him to delete cn={14}example,cn=schema,cn=config. So my main question is how to correctly disable replication in n-way multi-master setup? Objects that are stored in catalog do not use attributes or object classes that are defined in custom schema. In my setup write operations are directed only to single node of a cluster. I would like to ask for advice about my deletion plan. 0. Make backup of current cn=config and data 1. Disable replication via deletion olcServerID in cn=config and setting olcMirrorMode to FALSE 2. Direct write operations to third node 3. Stop slapd instance on first node 4. Edit configuration (remove custom schema from file, renumber siblings in cn=schema,cn=config) 5. Load new configuration into /etc/openldap/slapd.d 6. Start slapd instance on first node 7. Check that schema is absent in cn=config on first node 8. Repeat steps from 3-7 on second node 9. Direct write operations to first node 10. Repeat steps from 3-7 on third node 11. Turn on replication in cluster If it matters i use OpenLDAP 2.4.33 (x86_64).

3 3

Multiple CSN use
by Emmanuel BILLOT 13 Oct '13

13 Oct '13

Hi, I read a thread about multiple CSN. If a server have to replicate multiple parts from several servers, it must have multiplace CSN. Now we use multiple database for having multiple CSN (one subordinate per remote server), but this thread seems to talk about multiple CSN using with one database. What should be a simple conf example to use multiple CSN values ? I didn't find any doc about using multiple CSN with "correctly used SIDs". http://www.openldap.org/lists/openldap-technical/201011/msg00153.html "But the SIDs will only be used correctly if the URLs in the ServerID directive match the actual URLs given to the slapd -h option." Regards,

2 1

contextCSN format
by Emmanuel BILLOT 13 Oct '13

13 Oct '13

Hi, When using refreshonly replication, i cannot see any rid or sid info on the consumer contextCSN Oct 13 21:39:24 seshat-test slapd[5053]: do_syncrep2: cookie=rid=003,sid=003,csn=20131013024923.410481Z#000000#000#000000 Oct 13 21:39:24 seshat-test slapd[5053]: slap_queue_csn: queing 0x8765080 20131013024923.410481Z#000000#000#000000 Oct 13 21:39:24 seshat-test slapd[5053]: slap_graduate_commit_csn: removing 0x8761170 20131013024923.410481Z#000000#000#000000 Whereas ServerID is set on provider. What could explain this ?

1 0

memberof overlay results in unexpected slapd death?
by Paul B. Henson 12 Oct '13

12 Oct '13

Our LDAP infrastructure is currently running 2.4.35, and consists of two read/write masters configured in mirror mode behind the load balancer, with three additional read-only slaves using syncrepl. We recently decided to add the memberof overlay to our configuration, due to an application that did not support querying the groups for members. I updated our configuration to load the module, and add the overlay, and proceeded to rip through all of our groups removing and then re-adding the members in order to populate the memberOf attribute on the user objects. While doing so, there were errors logged on all of the servers: Oct 10 04:26:09 fosse slapd[9944]: conn=75373 op=184748: memberof_value_modify DN="uid=tdnguyen1,ou=user,dc=cs upomona,dc=edu" delete memberOf="uid=classes,ou=group,dc=csupomona,dc=edu" failed err=16 This was expected, as the memberOf attribute did not exist in our current directory. However, what was unexpected was that the slapd processes started to mysteriously die while I was trying to repopulate the groups. No log messages, or any other indication of the failure, just attribute delete errors: Oct 10 04:29:39 filmore slapd[25526]: conn=-1 op=0: memberof_value_modify DN="uid=rfu,ou=user,dc=csupomona,dc=edu" delete memberOf="uid=mhr31806,ou=group,dc=csupomona,dc=edu" failed err=16 Oct 10 04:29:39 filmore slapd[25526]: conn=-1 op=0: memberof_value_modify DN="uid=rfu,ou=user,dc=csupomona,dc=edu" delete memberOf="uid=mhr_classes,ou=group,dc=csupomona,dc=edu" failed err=16 Then the process was gone. It was definitely related to mass group updates, they would run for hours with no problems under general use, but as soon as I started churning group members, bam, one or two of them would go away. I ended up backing out the modification, dumping the database, removing all of the memberOf attributes, and reloading it. I will try to duplicate this in a test environment with debugging enabled and see if I can get a better idea what's going on, but I was just curious if anyone had seen anything like this or knew of any underlying issues with the memberof overlay. Thanks much.

3 6

mysterious glue record with empty dn
by Paul B. Henson 11 Oct '13

11 Oct '13

While I was trying to recover my directory from an aborted attempt to implement the memberof overlay, I ended up dumping the database with slapcat and then reloading it with slapadd after removing the now invalid MEMBEROF attributes that lingered after the overlay was disabled. Strangely, on some of my servers, a glue object with an empty DN showed up in the slapcat output: dn: objectClass: glue structuralObjectClass: glue entryUUID: 411f0301-e857-4228-a22d-c5d1451d4496 creatorsName: cn=ldaproot,dc=csupomona,dc=edu createTimestamp: 20131007210011Z entryCSN: 20131007210011.273579Z#000000#000#000000 modifyTimestamp: 20131007210011Z modifiersName: cn=idmgmt,ou=user,ou=service,dc=csupomona,dc=edu slapadd refused to load the input file with this record at the top, I ended up deleting it and then it seemed to load fine. I'm not sure where this record came from? From what I could research, it seems glue records are created when you delete part of the hierarchy that is in between the top and some lower record? I don't think I did that, plus I don't see why it would have an empty DN? This must have something to do with my attempt to implement the memberof overlay, as I have never seen it before. Any thoughts? Thanks.

2 2

memberof overlay replicating memberOf attribute?
by Paul B. Henson 11 Oct '13

11 Oct '13

Based on the documentation, my understanding was that the memberof overlay maintained the memberOf attribute locally, and this attribute was not replicated? While I was recently working on implementing the memberof overlay, I noticed that after I had enabled it on one server, before enabling it on another, the memberOf attribute seemed to be replicated from the server on which the overlay was enabled to the one on which it was not: Oct 7 18:30:18 filmore slapd[28994]: UNKNOWN attributeDescription "MEMBEROF" inserted. Oct 7 18:30:18 fosse slapd[3047]: UNKNOWN attributeDescription "MEMBEROF" inserted. Oct 10 16:23:08 pip-dev slapd[7030]: slapd starting Oct 10 16:23:08 pip-dev slapd[7030]: UNKNOWN attributeDescription "MEMBEROF" inserted. This seems contrary to the documentation and I found it confusing. Am I missing something? Thanks.

2 2

unixUserPassword and userPassword
by jupiter 11 Oct '13

11 Oct '13

Hi, I am migrating user account entries from an old openldap AD to openldap BDB. Both LDAP client authentications are implemented in Linux, the former in CentOS 5, and the latter in CentOS 6. But the major problem is that the old openldap AD uses encrypted password in "unixUserPassword:" while the openldap BDB uses base64 "userPassword::". The option for solution I could think of are: (a) Convert the encrypted password from unixUserPassword format to userPasswor, then I can use ldapmodify to change userPassword. Is it possible? If it is, appreciate more details. (b) Change LDAP client authentication to use unixUserPassword. I haven't found any document to configure Linux client authentication to use unixUserPassword. In fact, I could not find any document regarding details of uing unixUserPassword. Any suggestions, tips and advice are very much appreciated. Thank you. Kind regards, jupiter Sorry for asking a non-dev question, but I could not find any solution from openldap document, nor from Internet searching. Thank you and appreciate any advice. Kind regards, jupiter

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2013