openldap-technical

openldap-technical@openldap.org

9937 discussions

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

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

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

Re: sizelimit
by Maily Peng 26 Jul '16

26 Jul '16

> You have to define the limit for the binddn you use in your syncrepl > definition ( 'cn=user,ou=login,cn=system' here), or change this binddn > to be the one for which you have an unlimited sizeLimit. Thanks for the advice Emmanuel. I finally put these lines on the global limits : /sizelimit size.soft=unlimited size.hard=1000// //timelimit time.soft=unlimited time.hard=5 /Tell me if i'm wrong but the hard limit is the absolute time /size the server will spend processing the request.

1 0

openldap 2.4.44 + ITS 8432 patch still infinitely replicates
by Paul B. Henson 20 Jul '16

20 Jul '16

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. Thanks...

1 0

openldap back-sql mysql wait_timeout
by Simon Ryf 20 Jul '16

20 Jul '16

Dear members, I have timeout issues with back-sql using mysql as backend (read-only). I could successfully setup open-ldap with back-sql querying from a mysql db. However there is a wait_timeout in mysql and if no query is being made for > then wait_timeout the slapd breaks and I have to restart it to connect to mysql again. http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html As a workaround I could implement a cron-job to execute a query every x hour (depending on wait_timeout). However I would much more like that back-sql is able to (auto-)reconnect. I'm not a developer and have no idea how this can be done - maybe this is in the sql-wrap.c code? executing an ldap query after "wait_timeout" returns slapd.log: Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_get_db_conn() Jul 20 17:22:53 STAG-BCC slapd[2054]: <==backsql_get_db_conn() Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_attrlist_add(): adding "objectClass" to list Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_dn2id("dc=bbn,dc=ch") matched expected Jul 20 17:22:53 STAG-BCC slapd[2054]: backsql_dn2id("dc=bbn,dc=ch"): id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?" Jul 20 17:22:53 STAG-BCC slapd[2054]: backsql_dn2id("dc=bbn,dc=ch"): error executing query ("SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?", "dc=bbn,dc=ch"): Jul 20 17:22:53 STAG-BCC slapd[2054]: Return code: -1 Jul 20 17:22:53 STAG-BCC slapd[2054]: nativeErrCode=2006 SQLengineState=08S01 msg="[MySQL][ODBC 5.1 Driver][mysqld-5.5.49-0+deb8u1]MySQL server has gone away" Jul 20 17:22:53 STAG-BCC slapd[2054]: <==backsql_dn2id("dc=bbn,dc=ch"): err=80 Any suggestions are most welcome Br Simon I'm using the following setup: ----------------------------- Debian Jessie x86_64 (up to date) Openldap-2.4.44 compiled from source with ./configure --enable-sql libmyodbc 5.1.10-3 mysql 5.5.49-9 odbc.ini: [ldapds] Driver = MySQL Description = BCC MySQL DB SERVER = 127.0.0.1 PORT = 3306 USER = ldap Password = ldap Database = prov_ldap SOCKET = /var/lib/mysql/mysql.sock odbcinst.ini: [MySQL] Description = ODBC for MySQL Driver = /usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so Setup = /usr/lib/x86_64-linux-gnu/odbc/libodbcmyS.so FileUsage = 1 slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/SIP.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel any database sql suffix "dc=bbn,dc=ch" rootdn "dc=bbn,dc=ch" rootpw ldap dbname ldapds dbuser ldap dbpasswd ldap subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no #cachesize 0

1 0

is there a bug with SSSD
by Kaveh Ehsani 18 Jul '16

18 Jul '16

I have tried using SSSD to switch between ldap provider and consumer. I have: ldap_uri = provider.example.com ldap_backup_uri = consumer.example.com It works fine, until I stop the provider to see if the clients will look at the consumer. They don't. I set ldap_uri = consume.example.com and clear the cache both via sss_cache -E and deleting all the files in /var/lib/sss/db and restart sssd. Even though it starts fine, I have ldap_uri = provider.example.com inside the journalctl -xe file and complains that can not contact the ldapserver., which is intentionally switched off. Looks like ldap_uri is hard coded some where the first time it is set. I have opened a bug report, but no replies to it at the moment. This is the link for the bug report in case anyone is interested. https://bugs.centos.org/view.php?id=11174

3 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