March 2016 - openldap-technical

by Fr3ddie

Hello to the list, I'm trying to configure the slapd-meta OpenLDAP backend on an online cn=config configuration with no luck. Slapd version is 2.4.39 (the maximum I can achieve on the target machines building from vanilla source). The documentation is clear but too concise for me so I will try to explain what I'm trying to do to see if there is anybody that can help me. Currently I have 3 slapd servers that share a common root for the DIT, i.e.: dc=loc1,dc=root dc=loc2,dc=root dc=loc3,dc=root What I would like to achieve is to obtain a fourth server that contains the previous trees, along with its own tree, i.e. a server that contains: dc=loc0,dc=root (locally hosted data) dc=loc1,dc=root (coming from the first server, chasing referrals) dc=loc2,dc=root (coming from the second server, chasing referrals) dc=loc3,dc=root (coming from the third server, chasing referrals) this way, all the clients connecting to this server will be able to retrieve data also from the other three remote servers. As far as I understood, I only need to configure the "loc0" server to access the other three servers and get the data to serve to clients. I have already configured the fourth server with its local DIT and this is the configuration: # cat 'cn=config.ldif' dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 olcThreads: 32 olcToolThreads: 8 olcRequires: LDAPv3 olcConnMaxPendingAuth: 100 olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key olcTLSVerifyClient: try olcTimeLimit: 600 olcLogLevel: stats2 sync [...] # cat 'cn=module{0}.ldif' dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog structuralObjectClass: olcModuleList [...] Schema files are the following: cn={0}core.ldif cn={1}cosine.ldif cn={2}nis.ldif cn={3}inetorgperson.ldif cn={4}dyngroup.ldif cn={5}kerberos.ldif # cat 'olcDatabase={1}hdb.ldif' dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=loc0,dc=root olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn =admin,dc=loc0,dc=root" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=loc0,dc=root olcRootPW:: xxxxxxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 512 10 olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIDLcacheSize: 30000 olcDbIndex: default pres,eq [...] structuralObjectClass: olcHdbConfig olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root bindmethod=s imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx searchbase="dc=loc0,dc=root" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj ect)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syn cdata=accesslog starttls=yes olcMirrorMode: TRUE [...] On top of this DB I have the "syncprov" and the "accesslog" overlays configured (these are two servers in "MirrorMode", configured following the OpenLDAP admin documentation). I believe this DB is the ones containing the actual "loc0" DIT data... Then I have the accesslog DB for the replica (with the syncprov overlay on top): # cat 'olcDatabase={2}hdb.ldif' dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=loc0,dc=root olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart [...] On top of this environment I start loading the needed modules with this LDIF file: version: 1 dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: back_ldap - add: olcModuleLoad olcModuleLoad: back_meta - add: olcModuleLoad olcModuleLoad: rwm and it seems I'm able to load the new modules without errors into the configuration, thus I obtain: # cat 'cn=module{0}.ldif' dn: cn=module{0} structuralObjectClass: olcModuleList objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog olcModuleLoad: {3}back_ldap olcModuleLoad: {4}back_meta olcModuleLoad: {5}rwm [...] Now I try to load the slapd-meta directives into a new database using this LDIF: version: 1 dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=root olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand but I obtain an error that sticks me trying various combinations without success: # ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Object class violation (65) additional info: attribute 'olcDbURI' not allowed and: # tail /var/log/openldap/slapd.log Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:57:07 server01 slapd[32392]: Entry (olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed Into the slapd-meta documentation the "URI" directive is mentioned but the "DbURI" seems to raise a "better error", in fact if I try to modify the above LDIF file using "URI" I obtain: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Undefined attribute type (17) additional info: olcUri: attribute type undefined Moreover, it is not stated into the slapd-meta docs that the slapd-ldap backend is needed by slapd-meta but, anyway, I think its needed because if I try to load the slapd-meta alone it raises an error (I don't remember exactly which one). At this point I'm stuck to this error and I wasn't able to find any hint on the web to solve this :( The examples I was able to find were related with the static slapd.conf configuration, I counldn't find any "full" configuration example using the cn=config. I'm wondering if I should create a "cn=root" actual DB first and then link the sub-DITs to it, or, maybe, add some other overlay... I really can't understand how it should work :( Can please anybody help me? Thank you very much

6 years, 6 months

3
9
0 / 0

Virtual list view problem

by Venish Khant

Hi all I am using cpan Net::LDAP module to access LDAP entries. I want to search LDAP entries using Net::LDAP search method. When I do search, I want some limited number of entries from search result, for this(searching) process I am using Net::LDAP::Control::VLV module. But I get error on VLV response control. Please, any one have idea about this error. * Error:* Died at vlv.pl line 50, This is my example. I changed the font style of line 50 #!/usr/bin/perl -w use Net::LDAP; use Net::LDAP::Control::VLV; use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE ); use Net::LDAP::Control::Sort; sub procentry { my ( $mesg, $entry) = @_; # Return if there is no entry to process if ( !defined($entry) ) { return; } print "dn: " . $entry->dn() . "\n"; @attrs = $entry->attributes(); foreach $attr (@attrs) { #printf("\t%s: %s\n", $attr, $entry->get_value($attr)); $attrvalue = $entry->get_value($attr,asref=>1); #print $attr.":". $entry->get_value($attr)."\n"; foreach $value(@$attrvalue) { print "$attr: $value\n"; } } $mesg->pop_entry; print "\n"; } $ldap = Net::LDAP->new( "localhost" ); # Get the first 20 entries $vlv = Net::LDAP::Control::VLV->new( before => 0, # No entries from before target entry after => 19, # 19 entries after target entry content => 0, # List size unknown offset => 1, # Target entry is the first ); my $sort = Net::LDAP::Control::Sort->new( order => 'cn' ); @args = ( base => "dc=example,dc=co,dc=in", scope => "subtree", filter => "(objectClass=inetOrgPerson)", callback => \&procentry, # Call this sub for each entry control => [ $sort, $vlv ], ); $mesg = $ldap->search( @args ); # Get VLV response control *($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;* $vlv->response( $resp ); # Set the control to get the last 20 entries $vlv->end; $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); # Now get the previous page $vlv->scroll_page( -1 ); $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mes # Now page with first entry starting with "B" in the middle $vlv->before(9); # Change page to show 9 before $vlv->after(10); # Change page to show 10 after $vlv->assert("B"); # assert "B" $mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); -- Venish Khant www.deeproot.co.in

7 years

4
11
0 / 0

OpenLDAP log file ownership getting modified automatically.

by Prashanth P.Nair

Hello Am using OpenLDAP 'openldap-2.4.31' on debian. I have configured syncrepl .Everything work’s normal. But frequently am getting below Error. The log file ownership is getting changed any one of the node automatically . here is the Error From syslog. Mar 29 12:14:26 xxx slapd[29405]: conn=5774 op=40651 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 29 12:14:29 xxx slapd[29405]: bdb(dc=xxx,dc=xxx,dc=xxx): /var/lib/ldap/xxx/log.0000000883: log xxxle unreadable: Permission denied Mar 29 12:14:29 xxx slapd[29405]: bdb(dc=xxx,dc=xxx,dc=xxx): PANIC: Permission denied Mar 29 12:14:29 xxx slapd[29405]: bdb(dc=xxx,dc=xxx,dc=xxx): DB_ENV->log_newfh: 883: DB_RUNRECOVERY: Fatal error, run database recovery Mar 29 12:14:29 xxx slapd[29405]: bdb(dc=xxx,dc=xxx,dc=xxx): txn_checkpoint: log failed at LSN [883 68682]: DB_RUNRECOVERY: Fatal error, run database recovery Mar 29 12:14:30 xxx slapd[29405]: conn=5774 op=40652 SRCH base="" scope=0 deref=3 xxxlter="(objectClass=*)" Mar 29 12:14:30 xxx slapd[29405]: conn=5774 op=40652 SRCH attr=objectclass Any idea what is going wrong here? LDAP is running as below user . openldap:x:106:108:OpenLDAP Server Account,,,:/var/lib/ldap:/bin/false $ id openldap uid=106(openldap) gid=108(openldap) groups=108(openldap) I dont find any logs for open file issue.But still i pasted below settings. open file limit settings openldap soft nofile 65536 openldap hard nofile 65536 slapd.conf settings loglevel sync stats modulepath /usr/lib/ldap moduleload back_hdb moduleload syncprov sizelimit 500 tool-threads 8 threads 16 backend hdb database hdb monitoring on cachesize 50000 idlcachesize 50000 directory "/var/lib/ldap/account" dbconfig set_cachesize 0 167772160 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass,snAccount,snEnabled,entryCSN,entryUUID eq index cn eq,pres,subany lastmod on checkpoint 5120 30 access to dn.base="" by * read syncrepl rid=001 provider=ldap://xx.xx.xxx.xxx bindmethod=simple binddn="cn=xxx,ou=administrators,dc=test,dc=IN" credentials=xxx searchbase="dc=account,dc=test,dc=IN" schemachecking=on type=refreshAndPersist retry="10 +" mirrormode on overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 10000 Br/Prashanth

7 years, 2 months

3
8
0 / 0

Should I be able to select an 'orphaned' DN from a translucent overlap proxy?

by Sullivan, Daniel [AAA]

Hi, I am writing to confirm the expected behavior of a translucent overlay proxy. I have the proxy working and can filter from the local database using the olcTranslucentLocal configuration option (I can see a merged record). My question pertains to ‘orphaned data’. For example, I can arbitrarily add a record to the local database by DN using ldapadd, the glue records are created and I can see the record in the output of slapcat. My problem is that a search via ldapsearch does not return this record unless their is a matching DN in the remote database, even if I am filtering by an attribute specifed in olcTranslucentLocal . Is this the expected behavior? There is more that one reason why I want to do this, but the lowest common denominator is that people are going to be moving records around upstream and I’d like to keep the local database tidy by blowing away records that no longer have a matching remote DN. On that note, the second reason why I’m interested in doing this is to create an individual default group for each user in the local database. I was planning on creating an actual group for each user programmatically, and have no problem doing this. Is there a more elegant best practice way to facilitate this sort of thing (i.e. an overlay solution), or is just creating the groups the way to go? I am using openldap-ltb.x86_64 2.4.44-2.el6. I appreciate your time and expertise. Dan ******************************************************************************** This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is prohibited. If you have received this e-mail in error, please notify the sender and destroy all copies of the transmittal. Thank you University of Chicago Medicine and Biological Sciences ********************************************************************************

7 years, 2 months

1
0
0 / 0

Question about ldap_init()/ldap_initialize() behavior with OpenLDAP

by Frank Crow

I'm not clear on whether I'm allowed to ask "C" API questions here. If not, I apologize in advance and please disregard in that case. However, the question is more about configuration than coding. I'm seeing that the ldap_init() function allows the hostname parameter to be null or a list of hosts. If it is null, the function attempts to determine the default ldap host. How does it determine the default LDAP host when the hostname parameter is null? Does it load the list of hosts from the ldap.conf URI parameter? And/or does it use the LDAPURI environment variable? Thanks, -- Frank

7 years, 2 months

4
7
0 / 0

CSN is matching but entries count differs in master and slaves

by scn_73＠yahoo.com

Hello all, CSN is matching with master and slaves but if i count number of entries it's different. I am replicating complete DIT so count should be equal in Master and slave. Should i diff the missed entries and catch them in replications logs. Please suggest .. $ ldapsearch -H ldaps://ldapmaster -D "cn=manager,dc=xxx,dc=com" -x -xxx -s base contextCSN -LLL dn: dc=xxx,dc=com contextCSN: 20160326180539Z#000006#00#000000 $ ldapsearch -H ldaps://ldap-slave -D "cn=manager,dc=xxx,dc=com" -x -wxx -s base contextCSN -LLL dn: dc=xxx,dc=com contextCSN: 20160326180539Z#000006#00#000000 $ ldapsearch -H ldaps://ldapmaster -D "cn=manager,dc=xxx,dc=com" -x -wxx -s sub "objectclass=*" | tail -2 # numResponses: 28751 # numEntries: 28750 $ ldapsearch -H ldaps://ldap-slave "cn=manager,dc=xxx,dc=com" -x -wxxx -s sub "objectclass=*" | tail -2 # numResponses: 28772 # numEntries: 28771

7 years, 2 months

3
4
0 / 0

ACL problem

by Cole

Hi, I am using OLC and ACL's to limit response from LDAP based on IP address, and this is working fine if I have a single ACL. When I add a second ACL, with a different IP address, the new ACL works, but the previous one does not. Example: Entries in LDAP: # 10.0.0.92, servers, test.com dn: cn=10.0.0.92,ou=servers,dc=test,dc=com objectClass: groupOfNames cn: 10.0.0.92 description: Allowed access member: uid=aaa,dc=test,dc=com # 10.0.0.94, servers, test.com dn: cn=10.0.0.94,ou=servers,dc=test,dc=com objectClass: groupOfNames cn: 10.0.0.94 description: Allowed access member: uid=aaa,dc=test,dc=com # aaa, test.com dn: uid=aaa,dc=test,dc=com objectClass: inetOrgPerson objectClass: posixAccount objectClass: ldapPublicKey objectClass: shadowAccount uid: aaa uidNumber: 10005 gidNumber: 10005 homeDirectory: /home/aaa loginShell: /usr/local/bin/bash mail: a(a)test.com ou: users cn: User A sn: A userPassword:: xxx OLC entries: # {1}ldif, config dn: olcDatabase={1}ldif,cn=config objectClass: olcLdifConfig olcDatabase: {1}ldif olcDbDirectory: /var/pq/0/mount/resolve/installations/entities/vmi/location/za /parts/new/instances/test/openldap-data olcSuffix: dc=test,dc=com olcAccess: {0}to filter=(|(&(objectClass=inetOrgPerson)(memberOf=cn=10.0.0.92, ou=servers,dc=test,dc=com))(objectClass=posixGroup)) by self read by peername .ip="10.0.0.92" read by * none olcAccess: {1}to * by self write by peername.ip="127.0.0.1" write by * none olcRootDN: cn=Manager,dc=test,dc=com olcRootPW: test At this point, running ldapsearch from the computer with ip address 10.0.0.92 works correctly, and only the filtered results are returned. If I then add a second ACL: # {1}ldif, config dn: olcDatabase={1}ldif,cn=config objectClass: olcLdifConfig olcDatabase: {1}ldif olcDbDirectory: /var/pq/0/mount/resolve/installations/entities/vmi/location/za /parts/new/instances/test/openldap-data olcSuffix: dc=test,dc=com olcAccess: {0}to filter=(|(&(objectClass=inetOrgPerson)(memberOf=cn=10.0.0.94, ou=servers,dc=test,dc=com))(objectClass=posixGroup)) by self read by peername .ip="10.0.0.94" read by * none olcAccess: {1}to filter=(|(&(objectClass=inetOrgPerson)(memberOf=cn=10.0.0.92, ou=servers,dc=test,dc=com))(objectClass=posixGroup)) by self read by peername .ip="10.0.0.92" read by * none olcAccess: {2}to * by self write by peername.ip="127.0.0.1" write by * none olcRootDN: cn=Manager,dc=test,dc=com olcRootPW: test The computer with IP 10.0.0.94 can now query LDAP, and receives the correct filtered results, however the computer with IP 10.0.0.92 receives a blank result: $ ldapsearch -x -h 10.0.0.91 -b dc=test,dc=com # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Is this the way that ACLs work in openldap? Or have I missed a configuration setting somewhere? Thanks /Cole

7 years, 2 months

1
1
0 / 0

Transparent Overlay proxy not returning memberOf

by Sullivan, Daniel [AAA]

Hi, I apologize if this is a silly question; I’ve done a preliminary search of the mailing list archives and read through the documentation in as much detail as I can muster for the moment. I can’t seem to find an answer to this seemingly simple question. My question is this; I am implementing an Overlay Proxy against Active Directory. I have it working (i.e. I can query the local and remote databases and get a composite LDIF record returned that merges my added attributes). My problem is that the returned record doesn’t appear to contain the complete attribute set from the remote server. For example, if I use ldapsearch to query Active Directory directly, I see a bunch of memberOf: attributes for the user object returned. When I query the proxy, I clearly see the brunt of AD attributes for my user object, although the memberOf attributes are missing. Is there a reason for this? My configuration is very basic, and I don’t understand why attributes would be filtered by the proxy. My configuration is probably as simple as it can get (for the proxy): dn: olcOverlay={0}translucent,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcTranslucentConfig olcOverlay: {0}translucent olcTranslucentLocal: uidNumber structuralObjectClass: olcTranslucentConfig dn: olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={2}bdb,cn=conf ig objectClass: olcLDAPConfig objectClass: olcTranslucentDatabase olcDatabase: {0}ldap olcDbURI: ldap://domaincontroller:389 olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="cn=s.a aa.ldapsearch,ou=SrvcAccts,ou=AAA,dc=somedomain,dc=uchicago,dc=edu" credentials =“secret" tls_reqcer t=never olcDbIDAssertBind: bindmethod=simple binddn="cn=s.aaa.ldapsearch,ou=SrvcAcc ts,ou=AAA,dc=somedomain,dc=uchicago,dc=edu" credentials=“secret" mode=none tls_reqcert=never olcDbIDAssertAuthzFrom: {0}dn.regex:.* olcDbRebindAsUser: TRUE structuralObjectClass: olcLDAPConfig I’ve turned on debug logging for slapd and it looks like the memberOf attributes are being served up by AD. If anybody could provide insight as to why this would be occurring I would greatly appreciate it. Thank you, Dan Sullivan ******************************************************************************** This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is prohibited. If you have received this e-mail in error, please notify the sender and destroy all copies of the transmittal. Thank you University of Chicago Medicine and Biological Sciences ********************************************************************************

7 years, 2 months

1
1
0 / 0

ITS 7345 (Add Connection Information in Access Log Entries)

by Dario Zanzico

I've been using the patch attached to ITS 7345 for a couple months without any problem, and I find it necessary for working a comprehensive audit system. Can any work be done to make it acceptable for merging? thanks, dario

7 years, 2 months

1
0
0 / 0

Syncrepl TLS woes

by Xavier Landreville

Hello, I am currently in the grips of trying to get syncrepl replication working with StartTLS. It was working fine until recently. The only change that occurred over the last 12 months (that relates to OpenLDAP) is that I've started requiring TLS for connections. My provider is running OpenLDAP 2.4.31 on Ubuntu 14.04, while one consumer is running the exact same version on a Ubuntu 14.04 machine and the other consumer is running OpenLDAP 2.4.28 on Ubuntu 12.04. The provider has, AFAIK, a correct TLS configuration, given that I can connect and search using the ldapsearch -ZZ utility from any of the servers. The syncprov overlay is loaded and configured on the provider. The consumers have the following (redacted, with unique rid values) olcSyncRepl: olcSyncrepl: {0}rid=1 provider=ldap://[LDAP_DNS] bindmethod=simple bi nddn="[SYNC_USER]" credentials=[SYNC_PASS] searchbase="[L DAP_BASE]" logbase="cn=accesslog" logfilter="(&(objectClass=auditWr iteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand Unfortunately, on both consumers can't seem to be able to actually start the TLS connection: slapd[1257]: slap_client_connect: URI=ldap://[LDAP_DNS] Error, ldap_start_tls failed (-11) slapd[1257]: do_syncrepl: rid=001 rc -11 retrying And the provider shows the following errors: slapd[2126]: conn=1586 fd=100 ACCEPT from IP=[CONSUMER_IP]:35500 (IP=0.0.0.0:389) slapd[2126]: conn=1586 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[2126]: conn=1586 op=0 STARTTLS slapd[2126]: conn=1586 op=0 RESULT oid= err=0 text= slapd[2126]: conn=1586 fd=100 closed (TLS negotiation failure) Is there anything that I'm missing? Cheers, -- Xavier

7 years, 2 months

3
2
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2016