openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

password policies not functioning as expected
by Kruger, P (Justid) 31 Jul '16

31 Jul '16

I've set password policies on my OpenLDAP 2.4. Unfortunately things do not work as expected and although extensively searched on forums and Google, I cannot get the proper results. What am I missing in what I did or should have done? What goes wrong: - Password policies seem not to be validated or I do get a failure message The failures depend on pwdinHistory setting to zero (no failure) to > 0 failure like given below 5798c94a <= acl_access_allowed: granted to database root 5798c94a bdb_modify_internal: replace userPassword 5798c94a bdb_modify_internal: replace pwdChangedTime 5798c94a bdb_modify_internal: add pwdHistory 5798c94a bdb_modify_internal: replace pwdChangedTime 5798c94a bdb_modify_internal: add pwdHistory 5798c94a bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists 5798c94a hdb_modify: modify failed (20) 5798c94a send_ldap_result: conn=1000 op=18 p=3 5798c94a send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists" 5798c94a send_ldap_response: msgid=62 tag=103 err=20 ber_flush2: 61 bytes to sd 15 0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo 0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis 0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a 0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists ldap_write: want=61, written=61 0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo 0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis 0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a 0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists 5798c94a conn=1000 op=18 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists 5798c94a slap_graduate_commit_csn: removing 0x7f8a0c107960 20160727144634.392449Z#000000#000#000000 This makes, as far as I tested, no difference with just using a default policy or when using a default and specific policy with pwdPolicySubentry attribute in the user. I've used ACL's on my LDAP schema. My purpose: Use a default policy which basically says to use no policy Add a specific policy for users in a subtree. Below are the steps and LDAP LDIF files used to build the OpenLDAP. Included here are the LDIF files for: config, base and sub part of tree, replication ou and user, application users (service accounts), ldap managers ou, ACL's, OU's needed for application specific content, policy. Excluded here (but done) are the LDIF files for: enable logging, replication, TLS/SSL. The LDIF files first line contains the LDIF filename and the command used to apply them # ldapadd -Y EXTERNAL -H ldapi:/// -f 01_addrootpw.ldif dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {SSHA}hashhashhashhashhashhash # ldapadd -Y EXTERNAL -H ldapi:/// -f 02_root-base.ldif # change olcRootPW to your Root password # change domain parts to your domain dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" read by * none dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=example,dc=nl dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA} hashhashhashhashhashhash dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 03_ldap-manager.ldif dn: dc=example,dc=nl objectClass: top objectClass: dcObject objectclass: organization o: example nl dc: example dn: ou=ldapbeheerders,dc=example,dc=nl objectclass: organizationalUnit ou: ldapbeheerders dn: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl objectclass: organizationalRole cn: Manager description: Directory Manager # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 04_replication_user.ldif dn: ou=replicatie,dc=example,dc=nl objectclass: organizationalUnit ou: replicatie description: replicatie groep dn: cn=replicator,ou=replicatie,dc=example,dc=nl cn: replicator sn: user objectClass: person userPassword: passwordincleartext # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 05_applications.ldif # Create ou generic application scheme dn: ou=applicaties,dc=example,dc=nl objectclass: organizationalUnit ou: applicaties # Aanmaak ou APP1 applicatieschema dn: ou=APP1,dc=example,dc=nl objectclass: organizationalUnit ou: APP1 # Aanmaak ou APP2 applicatieschemas dn: ou=APP2,dc=example,dc=nl objectclass: organizationalUnit ou: APP2 # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 06_ServiceAccounts.ldif dn: ou=ServiceAccounts,dc=example,dc=nl objectclass: organizationalUnit ou: ServiceAccounts description: Service Accounts Applicaties #Service account APP1 dn: cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl cn: SAAPP1 sn: user objectClass: person userPassword: {SSHA}hashedpassword description: Service Account APP1 #Service account APP2 dn: cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl cn: SAAPP2 sn: user objectClass: person userPassword: {SSHA} hashedpassword description: Service Account APP2 # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 07_ACL.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: to attrs=userPassword by anonymous auth by self write by * break olcAccess: to dn="ou=replicatie,dc=example,dc=nl" by self write by * none olcAccess: to * by dn.base="cn=replicator,ou=replicatie,dc=example,dc=nl" read by * break olcAccess: to dn.subtree="cn=default,ou=policies,dc=example,dc=nl" by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write by * none olcAccess: to dn="ou=ldapbeheerders,dc=example,dc=nl" by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write by * none olcAccess: to dn="ou=ServiceAccounts,dc=example,dc=nl" by self search by * none olcAccess: to dn.subtree="ou=applicaties,dc=example,dc=nl" by dn.children="ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.subtree="ou=APP1,dc=example,dc=nl" by dn.base="cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.subtree="ou=APP2,dc=example,dc=nl" by dn.base="cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.children="dc=example,dc=nl" by * read olcAccess: to dn.children="dc=nl" by * read # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 08_Add-testusers.ldif dn: uid=APP1_1,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP1_1 cn: APP1_1 gebruiker sn: gebruiker pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl dn: uid=APP1_2,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP1_2 cn: APP1_2 gebruiker sn: gebruiker pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl dn: cn=APP2_1,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_1 cn: APP2_1 gebruiker sn: gebruiker dn: cn=APP2_2,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_2 cn: APP2_2 gebruiker sn: gebruiker dn: cn=APP2_3,ou=gebruikers,ou=applicaties,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_3 cn: APP2_3 gebruikercat sn: gebruiker dn: cn=APP2_4,ou=gebruikers,ou=applicaties,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_4 cn: APP2_4 gebruiker sn: gebruiker Below is the part where the password policies are configured. # ldapadd -Y EXTERNAL -H ldapi:/// -f P01_ppolicymodule.ldif dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleLoad: ppolicy.la olcModulePath: /usr/lib64/openldap # ldapadd -Y EXTERNAL -H ldapi:/// -f P02_ppolicyoverlay.ldif dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=example,dc=nl olcPPolicyUseLockout: TRUE olcPPolicyHashCleartext: TRUE # ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P03_default_ppolicy.ldif dn: ou=policies,dc=example,dc=nl objectClass: top objectClass: organizationalUnit ou: policies dn: cn=default,ou=policies,dc=example,dc=nl objectClass: top objectClass: device objectClass: pwdPolicyChecker objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdInHistory: 8 pwdMinLength: 8 pwdMaxFailure: 5 pwdFailureCountInterval: 1800 pwdCheckQuality: 1 pwdMustChange: TRUE pwdGraceAuthNLimit: 0 pwdMaxAge: 7776000 pwdExpireWarning: 1209600 pwdLockoutDuration: 900 pwdLockout: TRUE pwdSafeModify: FALSE # ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P04_APP1_ppolicies.ldif dn: ou=policies,ou=APP1,dc=example,dc=nl ou: policies objectClass: top objectClass: organizationalUnit dn: cn=default,ou=policies,ou=APP1,dc=example,dc=nl objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdCheckQuality: 0 pwdExpireWarning: 374400 pwdFailureCountInterval: 1800 pwdGraceAuthNLimit: 5 pwdInHistory: 12 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 2592000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: TRUE pwdSafeModify: FALSE

1 0

Directory management best practices?
by John Lewis 31 Jul '16

31 Jul '16

Are there any best practices on managing directories? For Instance, I want to authenticate trusted UNIX users and untrusted Django users in the same directory? What if I made completely different directory to manage contact information, but I want to replicate shards of it and give priority based on geographic location?

1 0

Re: openldap 2.4.44 + ITS 8432 patch still infinitely replicates
by Howard Chu 29 Jul '16

29 Jul '16

Paul B. Henson wrote: >> From: Quanah Gibson-Mount >> Sent: Friday, July 22, 2016 10:40 AM >> >> Also see ITS 8448. > > Ah, thanks much for the heads up on these additional issues. Perhaps it > would be safest for me to stick with 2.4.41 until a 2.4.45 is officially > released with fixes for both the replication loop and possible fallout from > its fix :). We've been pretty lucky with 2.4.41, knock on bits, it's been > very stable with no issues or problems that I've seen while we've been > running it. The bug noted in ITS#8460 is not present in 2.4 at all. Quanah is also running experimental backports of features from 2.5 and forgets to mention that sometimes. This particular issue is from 2.5 (and is now fixed in git). Most likely it's the same issue as #8448. You can disregard both of these. >> --On Thursday, July 21, 2016 5:47 PM -0700 Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: >> >>> I would note that I've opened up two new ITSes for problems that only >>> occur on systems that have the ITS8432 fix. Still waiting on fixes for >>> those, which is why I haven't pushed the fix into RE24 yet. >>> >>> ITSes 8460 and 8462. >>> >>> --Quanah >>> >>> --On Thursday, July 21, 2016 2:59 PM -0700 "Paul B. Henson" >>> <henson(a)acm.org> wrote: >>> >>>>> From: Howard Chu >>>>> Sent: Thursday, July 21, 2016 3:36 AM >>>>> >>>>> The fix for #8432 only prevents the redundant mod from being >> processed >>>>> on a particular node. If other nodes are still accepting the redundant >>>>> op >>>> then yes, >>>>> it will continue to propagate. So yes, you need the patched code on > all >>>>> nodes. >>>> >>>> Okay, thanks for the clarification. I usually stage updates to avoid a >>>> complete outage at any given time. It's interesting though that I had >>>> never seen this problem running 2.4.41 until I introduced a 2.4.44 > system >>>> into the mix, and then it went away once I reverted that system back to >>>> 2.4.41. I wonder why that combination caused it to pop up suddenly. > I'll >>>> have to schedule a downtime window and update them all at once and >> see >>>> what happens. >>>> >>>> By any chance have you had the time to look at ITS 8444? The reporter >>>> says he sees a similar circular replication issue when the memberOf >>>> overlay is enabled, which we also use. >>>> >>>> Thanks much. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 4

Re: Antw: Intermediate certificates not being sent
by Howard Chu 28 Jul '16

28 Jul '16

Nat Sincheler wrote: > > > On 7/27/2016 11:19 PM, Ulrich Windl wrote: >>>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 26.07.2016 um 17:20 in >> Nachricht <991f77f9-fd05-eb9b-7f07-f350c4a7bc68(a)macrotex.net>: >> >>> >>> On 7/25/2016 11:24 PM, Ulrich Windl wrote: >>>>>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 25.07.2016 um 19:06 in >>>> Nachricht <c19c2a3a-3c90-5baa-43c7-800b050ea5b7(a)macrotex.net>: >>>>> We have an OpenLDAP server that is listening on port 636 over ldaps. >>>>> When I run >>>>> >>>>> openssl s_client -showcerts -connect ldap-server:636 >>>>> >>>>> I only see the host certificate. The intermediate and root certificates >>>>> do *not* come through. >>>> >>>> If I di that on one of outr servers, I get: >>>> Root CA >>>> Intermediate CA >>>> Server Certificate >>>> >>>> ... >>>> New, TLSv1/SSLv3, Cipher is AES256-SHA >>>> Server public key is 2048 bit >>>> >>>>> >>>>> For this server I have in the file slapd.d/cn=config.ldif the setting >>>>> >>>>> olcTLSCACertificatePath: /etc/ssl/certs >>>> >>>> Hi! >>>> >>>> Here it works with these settings: >>>> olcTLSCACertificatePath: /etc/ssl/certs >>>> olcTLSCertificateFile: /etc/ssl/servercerts/slapd.pem >>>> olcTLSCertificateKeyFile: /etc/ssl/private/slapd.key >>>> >>>> Could it be a permissions problem? Did you try to check the certificate >>> chain with openssl (preferrable as LDAP user)? >>> >>> When I run the openssl s_client command I get no errors, but I also get >>> no intermediate or root certificates sent. I see this in the output: "No >>> client certificate CA names sent". >> >> Hi! >> >> To me it looks like a problem with your certificates. Try to verify them >> using openssl, like this: >> openssl verify -CApath /etc/ssl/certs -verbose /etc/ssl/servercerts/slapd.pem >> /etc/ssl/servercerts/slapd.pem: OK > > % grep -R Certificate *.ldif > > olcTLSCACertificatePath: /etc/ssl/certs > olcTLSCertificateFile: /etc/ssl/certs/server.pem > olcTLSCertificateKeyFile: /etc/ssl/private/server.key > > % directory2:/etc/ldap# openssl verify -CApath /etc/ssl/certs -verbose > /etc/ssl/certs/server.pem > > /etc/ssl/certs/server.pem: OK > > So, the openssl command line can find the certificate chain. Why can't openldap? If your OpenLDAP build is not behaving the same as your OpenSSL build, then most likely your OpenLDAP was not built with OpenSSL. Otherwise, their behavior would match. You never provided essential information such as OS platform and OpenLDAP version, so nobody can give you definitive answers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Intermediate certificates not being sent
by Nat Sincheler 28 Jul '16

28 Jul '16

We have an OpenLDAP server that is listening on port 636 over ldaps. When I run openssl s_client -showcerts -connect ldap-server:636 I only see the host certificate. The intermediate and root certificates do *not* come through. For this server I have in the file slapd.d/cn=config.ldif the setting olcTLSCACertificatePath: /etc/ssl/certs I checked and all the intermediate and root certificates are in /etc/ssl/certs soft-linked via the usual OpenSSL rehash hash, e.g., lrwxrwxrwx 1 root root 42 Jul 14 19:03 b4261fc2.0 -> /etc/ssl/certs/incommon-usertrust-2024.pem Any idea why the intermediate and root certificates do not get sent to the LDAPS client? Is there something in the LDAP log that might give me a clue as to what is going on?

3 5

Multimaster syncrepl configuration
by Gurjot Kaur 28 Jul '16

28 Jul '16

Hello, I have a doubt in setting up multimaster syncrepl configuration. I just added syncrepl information for the "dn: olcDatabase={0}config,cn=config" and overlays for "dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config" in both the Master 1 and Master 2 servers. But I didn't add any syncrepl for "dn: olcDatabase={1}mdb,cn=config" for any server. While adding I got this error: modifying entry "olcDatabase={1}mdb,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral Nevertheless, what I am unable to understand is that my data is replicating in both the servers correctly. Is there no difference between adding syncrepl for config database or mdb database. Or adding syncrepl to config database is applicable for all the databases? Thanks, Gurjot Kaur "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

sizelimit
by Maily Peng 27 Jul '16

27 Jul '16

Hi all, I can not apply a limits directive to my slapd.conf. I need a user (cn=replicator,ou=AppUsers,dc=company,dc=net) to have read access to all entries of a database. The global sizelimits ( 1000) seems to override any other database directive. Each ldapsearch returns a " 4 Size limit exceeded". openldap version : 2.4.42 here is a sample of my slapd.conf ... # Define global ACLs to disable default read access. sizelimit 1000 timelimit 5 tool-threads 8 pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args ####################################################################### # database definitions ####################################################################### ######################################### # Directories DATABASE ######################################### database mdb suffix "ou=Directories,dc=company,dc=net" subordinate checkpoint 1024 5 dbnosync maxsize 10737418240 envflags writemap rootdn "cn=admin,dc=company,dc=net" # Mode 700 recommended. directory /var/lib/openldap/ldap # acl authz-regexp uid=([^,]*),cn=digest-md5,cn=auth ldap:///ou=company,dc=company,dc=net??sub?(&(objectclass=psnDirectoryContact)(cli=sipdefault:$1)) access to * by dn.exact="cn=replicator,ou=AppUsers,dc=company,dc=net" write by * break ........... access to dn.sub="ou=AppUsers,dc=company,dc=net" attrs=userpassword by anonymous auth by * none # Indices to maintain index cn,dc,sn,uid,mail,telephoneNumber pres,eq,sub index arecord,description eq index objectClass,macAddress,custID,locationID,zoneGroupPrefix,entryUUID,entryCSN pres,eq # Sync Repl overlay syncprov # all standard entries in the accesslog that were successful syncrepl rid=0 provider=ldap:// bindmethod=simple binddn="cn=user,ou=login,cn=system" credentials=secret searchbase="ou=Directories,dc=company,dc=net" logbase="cn=accesslog_directories" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog #limits limits dn.exact="cn=replicator,ou=AppUsers,dc=company,dc=net" size=unlimited time=unlimited .... thanks in advance.

3 3

password policies not functioning properly
by Kruger, P (Justid) 27 Jul '16

27 Jul '16

1 0

Re: openldap 2.4.44 + ITS 8432 patch still infinitely replicates
by Howard Chu 26 Jul '16

26 Jul '16

Paul B. Henson wrote: > I upgraded one of the nodes of a four node MMR delta syncrepl openldap > system today to 2.4.44 + the backported ITS 8432 patch (the other three > nodes were still running 2.4.41, which all four had been running for > quite some time with no issues) and within a few hours they started blowing > up with the infinite replication issue referred to in ITS 8432, all the > accesslogs were filled with the same modification repeated over and > over. I ended up having to slapcat the db, restore the upgraded node to > 2.4.41, and then reload the db on all of them to recover. > >>From what I understand the bug was supposed to have existed in versions > before 2.4.44, but I had never seen it in 2.4.41, and backing out > to that version seems to have restored stability. I remember seeing > another ITS regarding an issue even with the 8432 patch applied if > you're using the memberOf overlay (although that number escapes me at > the moment), but I thought that only applied if you were updating group > memberships and the change that blew up my system was a password change. > > Is it possible updating one node to the fixed version somehow triggered > the bug in one of the other nodes? Do I need to upgrade all the nodes at > the same time? Or are there possibly still edge cases where 2.4.44 with > the patch are still broken? I did a test run of the upgrade in my dev > environment, including the staged rollout with temporarily mixed > versions, but it doesn't really have the same load and variety of access > patterns that production sees. The fix for #8432 only prevents the redundant mod from being processed on a particular node. If other nodes are still accepting the redundant op then yes, it will continue to propagate. So yes, you need the patched code on all nodes. > Thanks... > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

need to recover slapd password and upgrade openldap
by Dan Hyatt 26 Jul '16

26 Jul '16

My admin openLDAP 2.2 password became corrupt in the last week and I cannot log in as admin. I was hoping there was an easy recovery such as lunix has shutting down slapd, removing the hashed password, bringing it back up and resetting the blank password using slappasswd. I can't take a chance unless I know for sure. I have searched Google and read the admin manual. I inherited a system using open ldap server on an old redhat, and the slapd password was corrupted (or locked out by another admin????). this is openldap 2.2 on an old redhat box. I cannot risk having a group of users locked out for more than an hour because LDAP is down. What I need to do today is recover (reset) the slapd password so I can log into the database. I found some instructions which seem simple risky and no backout strategy. Simply running http://techiezone.rottigni.net/2011/12/change-root-dn-password-on-openldap/ After recovery of root. I was planning on 1. shutting down server, making a P2V copy for a hypervisor, then creating another ldap master and slave servers on redhat6 with openldap2.4 once I have this password issue resolved. Having the LDAP on two separate hyper visors (with local disks) to avoid the storage/authentication chicken/egg Is there a better upgrade plan I have the log files, is there a way to backout to last week without the admin password (which became corrupt last week).

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical