Search results for "starttls" - openldap-technical

Re: Slapd Security based on port

by Chris Jackson

On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote: Is it possible to prevent anonymous and unauthenticated binds to ldaps:// 636 but allow them on ldap:// 389? I want to allow staff to query my ldaps:// outside of my network while requiring them to login to do so but allow anyone to bind (anonymous, unauthenticated, or authenticated) internally on ldaps//: 389. I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports. I want to stop it just on ldaps://. Chris Jackson On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote: Stopping users that are "unauthenticated" makes no sense; everything's unauthenticated at time=0. You might as well stop slapd if you want a 100% inability to serve data. You can deny anonymous users that aren't plaintext, including any ldaps:/// connections, with something like: access to * by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break by anonymous none early on in your ACL stanzas. I'm pretty sure this'll deny anonymous StartTLS users on 389, though; not sure if that's what you want. I can't think of any way to use the slapd access language to differentiate based on listeners, which would probably be the most elegant way to handle what you asked. To be fair, this entire exercise seems really odd from where I sit -- are you positive that this will have the desired effect? (If somebody out in Peru is permitted to connect in unencrypted and make anonymous queries, why not allow them to make those same queries encrypted? What's the difference?) here is a scenario: Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall. Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap. ---Is the only option for them to setup two separate ldap servers? One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon". Chris Jackson

13 years, 9 months

Re: How to debug single object syncrepl failure

by Dieter Klünter

Am Fri, 13 Feb 2015 09:42:22 +1100 schrieb Geoff Crompton <geoffc(a)trinity.unimelb.edu.au>: > Hi, > > I have a particular object in my LDAP database that is failing to > replicate (using syncrepl between two slapd's running 2.4.31-1+nmu2 > on Debian Wheezy), despite other objects succeeding to replicate. I'm > not using a 'filter' configuration in my olcSyncrepl configuration > that might exclude this particular object, and I've checked that the > binddn I'm using has permission to see this object all the attributes > of the object that isn't replicating. > > The (sanitised) configuration on the consumer is: > > dn: olcDatabase={1}hdb,cn=config > olcSyncrepl: {0}rid=104 provider=ldap://producer.example.com > bindmethod=simple > binddn="uid=replicator,ou=pseudoaccounts,dc=example,dc=com" > credentials="..." > searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(& > (objectClass=auditWriteObject)(reqResult=0))" schemachecking=off > type=refreshAndPersist > retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand > > > On the producer the overlay configuration for the database being > replicated is: > > dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: {1}syncprov > olcSpCheckpoint: 100 600 > olcSpSessionlog: 100 > olcSpNoPresent: TRUE > > > If I follow the sanitising I did in the above, then the failing > object would be > uid=replicationcheck,ou=pseudoaccounts,dc=example,dc=com, and a > successfully replicated object would be > uid=geoffc,ou=People,dc=example,dc=com. > > I've stopped slapd on the consumer and deleted all the /var/lib/ldap/ > database files, to force re-replication. I get the same symptoms, > this one object doesn't replicate, but lots of other objects do > replicate. > > Any tips on how to further debug this? access rules? corrupted file system? corrupted database? Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

9 years, 9 months

Re: Client doesn't send certificate for LDAPS

by Joshua Schaeffer

>> did you read the description of this setting in man 5 slapd-config? Well, yes and no. I read about TLS_REQCERT under man ldap.conf and incorrectly assumed that what was set here (allow, demand, etc) also needed to be set on cn=config. I've read over both man pages more carefully now and I see the difference, one is requesting the cert from the server and the other is requesting the cert from the client. I just removed olcTLSVerifyClient from cn=config and I was able to authenticate successfully. Thanks for your help, your advise was very clear, Joshua On 03/08/2014 11:27 AM, btb(a)bitrate.net wrote: > On Mar 8, 2014, at 08.50, Joshua Schaeffer <jschaeffer0922(a)gmail.com> wrote: > >> I'm in the process of setting up my slapd server to operate over LDAPS and having trouble when using a CA certificate (being my own certificate authority). I've been able to setup LDAPS when using a self-signed server certificate: > please use ldap+starttls, not ldaps. > >> This works fine and I'm able to authenticate clients. However if I use a CA certificate (again, being my own CA) to sign my server certificate and then change olcTLSVerifyClient to demand and add olcTLSCACertificateFile then I can no longer authenticate. I've installed my CA certificate on the client machine and pointed both ldap.conf and nslcd.conf to the CA certificate. However I get the following when debugging: > why are you setting olcTLSVerifyClient when changing from a self signed cert to a properly signed cert? did you read the description of this setting in man 5 slapd-config? it has nothing to do with use of a self-signed vs a regular cert. be methodical when doing an exercise like this. first switch from your self signed cert to your proper cert. test. then, modify olcTLSVerifyClient and see what happens. > >> Why would the client not send the certificate if I've pointed TLS_CACERT in ldap.conf and tls_cacertfile to that cert? > TLS_CACERT and tls_cacertfile point to the ca cert. why would this cert be sent anywhere by the client? the server already has this cert. those settings allow the client to establish a chain of trust to the certificate presented by the server. it’s a “bootstrapping” mechanism, so to speak. you tell the client [by way of those settings] to implicitly trust, no questions asked, certain ca certificates. then when the client is presented a certificate by a server, it can be deemed “trustworthy”, even though it had no prior knowledge of this particular cert. > > -ben >

10 years, 8 months

Re: slapd-meta

by Fr3ddie

Il 10/03/2016 14:45, Dirk Kastens ha scritto: > >>>> dn: olcDatabase={3}meta,cn=config >>>> objectClass: olcDatabaseConfig >>>> objectClass: olcMetaConfig >>>> olcDatabase: {3}meta >>>> olcSuffix: dc=loc1,dc=root >>>> olcSuffix: dc=loc2,dc=root >>>> olcSuffix: dc=loc3,dc=root >>> >>> I've never used meta backend, but the above doesn't look valid to me >>> (multiple suffixes). The man page shows a single suffix, with URI >>> directives for additional representations of the DB. > > Indeed, you can only have one olcSuffix. This is the suffix under > which your source URIs will be presented. I'm running a meta backend > with the following configuration: > > I have two source servers, first and second. Both have a subtree > ou=people,ou=mydomain. The trees are combined on the meta server under > the new suffix ou=newsuffix,dc=mydomain as ou=apeople and ou=bpeople. > > [OMISSIS] > > Hope this helps. Thank you very much Dirk. I tried *several* configurations and OpenLDAP versions (i.e. 2.4.44-ltb) without success. I will try to explain all of them but, at this point, I can only think to a bug in the slapd-meta module. I kindly ask to the list where I am supposed to file the bug report. First step has been the removal of the whole OpenLDAP installation/configuration/DB and setup of the 2.4.44-ltb version. This has been done in order to avoid any mistake I could have performed while manually compiling OpenLDAP. Following that, I configured a minimal slapd with the meta database only and a single target, in order to exclude any possible configuration error deriving from the other HDB DIT previously contained. I tested everything using "ldapsearch" and sniffing the communication between the servers with Wireshark. The result is pretty bizarre. Now, when I directly interrogate the target server with ldapsearch I correctly obtain the answers to the performed queries, e.g.: ldapsearch -D "cn=admin,dc=server1,dc=xxxx" -w XXXXXXX -p 389 -h ldap.server1.xxxx -b "ou=users,dc=server1,dc=xxxx" -s sub "(uid=john)" # extended LDIF # # LDAPv3 # base <ou=users,dc=server1,dc=xxxx> with scope subtree # filter: (uid=john) # requesting: ALL # dn: uid=john,ou=users,dc=server1,dc=xxxx objectClass: inetOrgPerson objectClass: posixAccount uid: john sn: Doe givenName: John cn: John Doe displayName: John Doe uidNumber: 1000 gidNumber: 10000 gecos: John Doe loginShell: /bin/bash homeDirectory: /home/john mail: john.doe(a)example.com postalCode: 31000 l: aaaaa o: ddddd mobile: +33 (0)6 xx xx xx xx homePhone: +33 (0)5 xx xx xx xx title: System Administrator postalAddress: initials: JD # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 If I try to interrogate the meta-enabled server, instead, it correctly connects to the target server, it performs the query, *the target server answers correctly to the slapd-meta server* with the same data set of the first ldapsearch (sniffed with Wireshark) but I obtain *no answer*, i.e.: ldapsearch -D "cn=admin,dc=server1,dc=xxxx" -w XXXXXXX -p 389 -h ldap.server0.xxxx -b "ou=users,dc=server1,dc=xxxx" -s sub "(uid=john)" # extended LDIF # # LDAPv3 # base <ou=users,dc=server1,dc=xxxx> with scope subtree # filter: (uid=john) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 so the proxy server is not forwarding to the "ldapsearch" client the obtained data. Following are the performed configurations. First slapd-meta configuration tried is this: dn: olcDatabase={1}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {1}meta olcSuffix: dc=xxxx dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config olcDbURI: "ldap://10.0.x.55/dc=server1,dc=xxxx" objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIdAssertBind: bindmethod=simple binddn=cn=admin,dc=server1,dc=xxxx credentials=XXXXXXX starttls=no so, as suggested by Dirk and as clearly stated in the manual, using as "olcSuffix" a "common" naming context and "attaching" the target tree as subtree, without any suffix massaging. After this test I tried enabling the RWM overlay over the meta database and configuring suffix massaging, i.e.: dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: rwm-rewriteEngine "on" dn: olcDatabase={1}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {1}meta olcSuffix: dc=xxxx dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config olcDbURI: "ldap://10.0.x.55/dc=server1,dc=xxxx" olcDbRewrite: {0}suffixmassage "dc=server1,dc=xxxx" "dc=server1,dc=xxxx" objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIdAssertBind: bindmethod=simple binddn=cn=admin,dc=server1,dc=xxxx credentials=XXXXXXX starttls=no Last battery of tests, I tried to use the same "olcSuffix" I was trying to get from the target server, i.e. "dc=server1,dc=xxxx", with and without RWM massaging. Results for all of the tests stayed the same, if I directly query the target server I obtain the correct answer; as soon as I query the meta server it is unable to forward to the client the data received from the target...... -- Fr3ddie /fr3ddie(a)fr3ddie.it <mailto:fr3ddie@fr3ddie.it>/

8 years, 4 months

MMR (delta-syncrepl): CPU at 100% after replication

by Liam Gretton

I'm building a new setup with the latest OpenLDAP built from source, using mdb, MMR delta-syncrepl over TLS. I'm using very recent sources, I have two hosts and I'm finding that once the secondary host has synchronised with the first (this takes about 10 minutes for around 40000 entries), slapd on each of the peers remains at close to 100%. Replication is working though. The sync logs at this point on the first system in the set (where the original data was slapadded) is showing the following entries endlessly: 554fbe2c do_syncrep2: rid=002 CSN too old, ignoring 20131221210532.737643Z#000000#001#000000 (reqStart=20150509214300.000163Z,cn=log) contextCSN on both systems looks good. ldap1 is serverID 1, rid 1; ldap2 is serverID 2, rid 2. I guess the SID 0 comes from the original data that was imported into ldap1. # ldap1search -s base contextCSN dn: dc=example,dc=com contextCSN: 20150511090001.208713Z#000000#000#000000 contextCSN: 20150511091334.137305Z#000000#001#000000 # ldap2search -s base contextCSN dn: dc=example,dc=com contextCSN: 20150511090001.208713Z#000000#000#000000 contextCSN: 20150511091334.137305Z#000000#001#000000 On ldap2 the stats log shows very many corresponding searches of the log DB: 5550763e conn=1000 op=11653 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" 5550763e conn=1000 op=11653 SRCH attr=* + 5550763e conn=1000 op=11653 SEARCH RESULT tag=101 err=0 nentries=0 text= 5550763e conn=1000 op=11654 SRCH base="cn=log" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" 5550763e conn=1000 op=11654 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 5550763e conn=1000 op=11655 ABANDON msg=11655 Both systems have the host name specified in the -h option to slapd. Clocks are synchronised, DNS is working etc. I can't get to the bottom of this at all. No doubt I've made an error in my MMR config. Does anyone have a clue as to why this could be happening? I'd be very grateful for any ideas. Here's (most of) the slapd.conf file, which is identical on both. I must admit I'm not sure whether the serverID settings are global or per-database. Moving them into the mdb section doesn't change the behaviour though. # Server IDs for replication serverID 1 ldap://ldap1 serverID 2 ldap://ldap2 ############################################################# # # Access log database configuration # # This is also used for delta-syncrepl replication # # See slapd-accesslog(5) for details # ############################################################# database mdb maxsize 209715200 suffix cn=log directory /db/ldap/accesslog rootdn cn=log rootpw secret index entryCSN eq index objectClass eq index reqEnd eq index reqResult eq index reqStart eq overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=replication,ou=special users,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Replication user can read (not write) everything access to * by dn.exact="cn=replication,ou=special users,dc=example,dc=com" read by * none break ############################################################# # # Database configuration # # see slapd-mdb(5) for details # ############################################################# database mdb monitoring on suffix dc=example,dc=com directory /db/ldap/example rootdn "cn=administrator,ou=special users,dc=example,dc=com" maxsize 209715200 # Default password hashing scheme password-hash {SSHA} # memberOf overlay provides reverse-lookups of group membership overlay memberof # sssvlv overlay provides server-side sorting # Used mainly to allow easy sorting of uidNumber/gidNumber values overlay sssvlv sssvlv-max 4 sssvlv-maxkeys 5 sssvlv-maxperconn 4 # unique overlay provides attribute uniqueness # We use this to enforce unique uidNumber/gidNumber values overlay unique unique_uri ldap:///ou=people,dc=example,dc=com?uidNumber?one? unique_uri ldap:///ou=group,dc=example,dc=com?gidNumber?one? ### CONSUMER configuration syncrepl rid=1 provider=ldap://ldap1 type=refreshAndPersist bindmethod=simple binddn="cn=replication,ou=special users,dc=example,dc=com" credentials=password syncdata=accesslog interval=00:00:00:10 retry="20 10 60 10 120 +" timeout=1 logbase="cn=log" searchbase="dc=example,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" sizelimit=unlimited timelimit=unlimited schemachecking=on starttls=yes syncrepl rid=2 provider=ldap://ldap2 type=refreshAndPersist bindmethod=simple binddn="cn=replication,ou=special users,dc=example,dc=com" credentials=password syncdata=accesslog interval=00:00:00:10 retry="20 10 60 10 120 +" timeout=2 logbase="cn=log" searchbase="dc=example,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" sizelimit=unlimited timelimit=unlimited schemachecking=on starttls=yes ### PROVIDER configuration overlay syncprov syncprov-checkpoint 5 5 syncprov-sessionlog 50 mirrormode on # Access log - used for delta-syncrepl too overlay accesslog logdb cn=log logops writes logold (objectClass=*) logsuccess TRUE logpurge 28+00:00 1+00:00 # Allow unlimited access for replication user limits dn.exact="cn=replication,ou=special users,dc=example,dc=com" size=unlimited time=unlimited -- Liam Gretton liam.gretton(a)le.ac.uk Systems Specialist http://www.le.ac.uk/its/ IT Services Tel: +44 (0)116 2522254 University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

9 years, 6 months

Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)

by CHIROSSEL, Olivier

Ok merci Cdt, Olivier Le lundi 15 juillet 2019 à 09:18 -0700, Quanah Gibson-Mount a écrit : > This is expected to be the only testing call for 2.4.48, with an > anticipated release, depending on feedback, during the week of > 2019/07/22. > > Specific to this release, it would be helpful if anyone using back- > ldap or > back-meta with TLS can confirm their existing configurations continue > to > work (Due to the changes related to ITS#8427). > > Generally, get the code for RE24: > > < > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h… > > > > Configure & build. > > Execute the test suite (via make test) after it is > built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.4.48 Engineering > Added libldap OpenSSL Elliptic Curve support (ITS#7595) > Added libldap Expose OpenLDAP specific interfaces via openldap.h > (ITS#8671) > Added slapd-monitor support for slapd-mdb (ITS#7770) > Fixed liblber leaks (ITS#8727) > Fixed liblber with partial flush (ITS#8864) > Fixed libldap ASYNC TLS so it works (ITS#8957,ITS#8980) > Fixed libldap ASYNC connections with Solaris 10 (ITS#8968) > Fixed libldap with SASL_NOCANON=on and ldapi connections > (ITS#7585) > Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326) > Fixed libldap to be able to unset syncrepl TLS options (ITS#7042) > Fixed libldap race condition in ldap_int_initialize (ITS#7996, > ITS#8450) > Fixed libldap return code in ldap_create_assertion_control_value > (ITS#8674) > Fixed libldap to correctly disable IPv6 when configured to do so > (ITS#8754) > Fixed libldap to correctly close TLS connection (ITS#8755) > Fixed libldap_r handling of deprecated OpenSSL function > (ITS#8353) > Fixed liblunicode case correspondance (ITS#8508) > Fixed slapd with an idletimeout of less than four seconds > (ITS#8952) > Fixed slapd config parser variable for Windows64 (ITS#9012) > Fixed slapd syncrepl fallback handling with delta-syncrepl > (ITS#9015) > Fixed slapd telephoneNumberNormalize, cert DN validation > (ITS#8999) > Fixed slapd syncrepl for relax with delta-syncrepl (ITS#8037) > Fixed slapd TLS settings on reconnection (ITS#8427) > Fixed slapd to restrict rootDN proxyauthz to its own databases > (ITS#9038) > Fixed slapd to initialize SASL SSF per connection (ITS#9052) > Fixed slapo-accesslog with SLAP_MOD_SOFT modifications (ITS#8990) > Fixed slapd-ldap starttls connections timeout behavior (ITS#8963) > Fixed slapd-ldap TLS settings on reconnection (ITS#8427) > Fixed slapd-ldap segfault when entry result doesn't match filter > (ITS#8997) > Fixed slapd-meta conversion from slapd.conf to cn=config > (ITS#8743) > Fixed slapd-meta TLS settings on reconnection (ITS#8427) > Fixed slapd-meta assertion when network interface goes down > (ITS#8841) > Fixed slapd-mdb fix bitshift integer overflow (ITS#8989) > Fixed slapd-mdb index cleanup with cn=config (ITS#8472) > Fixed slapd-mdb to improve performance with alias deref > (ITS#7657) > Fixed slapo-accesslog possible assert with exops (ITS#8971) > Fixed slapo-chain to correctly reject multiple chaining URIs > (ITS#8637) > Fixed slapo-chain conversion from slapd.conf to cn=config > (ITS#8799) > Fixed slapo-memberof conversion from slapd.conf to cn=config > (ITS#8663) > Fixed slapo-memberof for group name change to itself (ITS#9000) > Fixed slapo-ppolicy behavior when pwdInHistory is changed > (ITS#8349) > Fixed slapo-rwm to not free original filter (ITS#8964) > Fixed slapo-syncprov contextCSN generation (ITS#9015) > Build Environment > Fixed slapd to only link to BDB libraries with static build > (ITS#8948) > Fixed libldap implicit declaration with LDAP_CONNECTIONLESS > (ITS#8794) > Fixed libldap double inclusion of limits.h in cyrus.c > (ITS#9041) > Documentation > General - Fixed minor typos (ITS#8764, ITS#8761) > admin24 - Miscellaneous updates promoting mdb and fixing > examples > (ITS#9031) > slapd.access(5) - Note MDB is the primary backend (ITS#8881) > slapd.backends(5) - Note MDB is the recommended backend > (ITS#8771) > slapd-ldap(5) - Document starttls parameter (ITS#8693) > Contrib > Added slapo-lastbind capability to forward authTimestamp > updates > (ITS#7721) > > LMDB 0.9.24 Engineering > ITS#8969 Tweak mdb_page_split > ITS#8975 WIN32 fix writemap set_mapsize crash > ITS#9007 Fix loose pages in WRITEMAP > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP: > <http://www.symas.com> > >

5 years, 4 months

Re: ldap_sasl_interactive_bind_s failed (-2) using openldap v2.3.43 when trying to replicate via syncrepl.

by Kristian Kostecky

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My apologies. Problem solved. I straced the slapd process and noticed that there were all sorts of SELINUX policies preventing the process from reading /tmp. I've enabled /tmp access and all works now. Thanks! Kris. PGP Key: 4CC63A18 PGP Server: pool.sks-keyservers.net On 2010-03-31, at 6:20 PM, Kristian Kostecky wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi guys, > > I have a configuration that consists of 3 ldap servers. One is the provider and there are 2 consumers. I am using syncrepl to do the synchronization. simple and anonymous binds are totally disabled and Kerberos must be used via SASL (GSSAPI) and TLS to connect to the LDAP server. > > distro: centos 5.4 > openldap 2.3.43 > cyrus-sasl 2.1.22 > > Other things: > - - clocks are all in sync > - - hostnames all have forward and reverse mappings and all dns servers in /etc/resolv.conf respond with proper entries on the consumer and both providers. > > Here's the catch, the two providers are configured the same (except for hostnames/ips) and the first one works perfect. What is really frustrating is the lack of logging that is available to tell me what the problem is. I've tried loglevel -1 and it gave me even less info in regards to the SASL authentication than leaving it off. > > The affected consumer is giving me: > > Mar 31 22:41:00 ZZZ slapd[2442]: slapd starting > Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrep1: rid 010 ldap_sasl_interactive_bind_s failed (-2) > Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrepl: rid 010 quitting > > On the "Provider": > > Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 ACCEPT from IP=10.130.1.230:60288 (IP=0.0.0.0:389) > Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 STARTTLS > Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 RESULT oid= err=0 text= > Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 TLS established tls_ssf=256 ssf=256 > Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=1 UNBIND > Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 closed > > This is what's REALLY weird - from the affected/broken box, ZZZ, after I kinit, I can do an LDAP search or ldapwhoami, no problems! So, kerberos and GSSAPI via SASL is working fine. ie: > > ldapsearch -H ldaps://XXX/ -Y GSSAPI -> will dump the entries. > or > ldapwhoami -H ldaps://XXX/ -Y GSSAPI -> shows me that proper creds > > If I destroy the credentials, it doesn't work as would be expected. > > ON the working consumer, the behaviour is that I can ldapsearch and ldapwhoami properly after I kinit and when I start ldap it will authenticate properly with the provider via SASL GSSAPI and replicates the DB. If I kdestroy the credentials and start it, I get the same error that I'm struggling with on the box that doesn't work ->ldap_sasl_interactive_bind_s failed (-2) This behaviour leads me to believe that for some reason the ldap server on the box that doesn't work is having problems transmitting the kerberos credentials to the provider, whereas the ldapsearch and ldapwhoami binaries are not having problems. > > There are some suspicious differences between the consumer that works and the broken one. The provider and consumer that works both have TLDs that match - '.com' and the consumer whose synrepl process won't authenticate is part of the .eu TLD. However, as you can see below in the krb5.conf files, the .com and .eu TLDS are always mapped to the same authentication realm. PLUS, again, ldapsearch and ldapwhoami WORK. It's just the syncrepl process that isn't quite getting the auth right. > > This is the provider's pertinent configs: > > slapd.conf: > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > This is the consumer's pertinent configs (WORKS ON one, not on the other) > slapd.conf: > syncrepl rid=10 > provider=ldap://xxx.XXX.com > starttls=yes > type=refreshOnly > interval=00:00:01:00 > searchbase="dc=XXX,dc=com" > schemachecking=off > bindmethod=sasl > saslmech=GSSAPI > > krb5.conf [same as provider and kerb server]: > [libdefaults] > default_realm = BOUNCE.AAA.COM > encrypt = true > allow_weak_crypto = false > clockskew = 600 > dns_lookup_realm = false > dns_lookup_kdc = false > ticket_lifetime = 8h > forwardable = no > proxiable = no > > [realms] > BOUNCE.AAA.COM = { > kdc = XXX.com > kdc = YYY.com > kdc = ZZZ.eu > admin_server = XXX.com > } > > [domain_realm] > .com = BOUNCE.AAA.COM > .eu = BOUNCE.AAA.COM > > > All help is greatly appreciated! This has been going on for days and I've already yanked out most of my hair. Thank you. > > Kris. > > PGP Key: 4CC63A18 > PGP Server: pool.sks-keyservers.net > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > > iEYEARECAAYFAkuzyroACgkQ2C/J5/UUQWEuUACdH/BhiZgTXFWbNMXS7Q99k8Rg > VY8An3YWKcpnkxVYvZMlelkT0TIpYuAP > =O9KI > -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAkuz1IUACgkQ2C/J5/UUQWGp0gCeKr1Un8cdvtnIPz8VK6IXdDhw FqAAnjtrNZ9ZBJfNNbfTDN4+fNUP49YE =U705 -----END PGP SIGNATURE-----

14 years, 7 months

Re: Ldap ppolicy schema entries

by Aravind Arjunan

* Am still facing issue while configuring ldap in master slave for replication. am using openldap 2.2 version. OS: RHEL 4.0 And am trying to configure master slave replication thro slurpd method. i had configured my master slapd.conf and slave slave slapd.conf. similarly i configured master and slave ldap.conf. After that i stopped the service in master and slave by [root@server ~]# service ldap stop Stopping slapd: [ OK ] Stopping slurpd: [ OK ] [root@server ~]# similarly in slave also. then i copied the database manually using slapcat [root@server openldap]# slapcat -b "dc=example,dc=com" -v -l example.com.ldif # id=00000001 # id=00000003 [root@server openldap]# scp example.com.ldif root(a)151.2.119.133 :/var/lib/ldap/example.com/ root(a)151.2.119.133's password: example.com.ldif 100% 747 0.7KB/s 00:00 [root@server openldap]# In slave : [root@slave openldap]# slapadd -b "dc=example,dc=com" -v -l example.com.ldif added: "dc=example,dc=com" (00000001) added: "cn=Manager,dc=example,dc=com" (00000002) [root@slave openldap]# but when i create a user in ldapmaster and check that user in slave,i was not able to found. there was no log in replogfile. [root@server ~]# useradd test [root@server ~]# passwd test Changing password for user test. New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. [root@server ~]# In slave [root@slave openldap]# id test id: test: No such user Here is my configuration files master slapd.conf * *=============* *#######################################################################* # ldbm and/or bdb database definitions ####################################################################### * database bdb * #The base of your directory * suffix "dc=example,dc=com" * #where the database files are physically stored * directory "/var/lib/ldap/example.com" * #Distinguished name,not subject to access control * rootdn "cn=Manager,dc=example,dc=com" rootpw password * # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # Replicas of this database * replica uri=ldap://=151.2.119.133:389 suffix="dc=example,dc=com" binddn="cn=syncuser,dc=example,dc=com" bindmethod=simple credentials=hcllch replogfile /var/lib/ldap/replogfile * #ACL's * access to attrs=userpassword by self write by anonymous auth by dn="cn=syncuser,dc=example,dc=com" read by * auth access to * by self write by dn="cn=syncuser,dc=example,dc=com" read by * read * #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM [root@server openldap]# * Slave slapd.conf ============== * ####################################################################### # ldbm and/or bdb database definitions ####################################################################### * database bdb * #The base of your directory * suffix "dc=example,dc=com" * #where the database files are physically stored #directory "/var/lib/ldap/ldap-test" #Distinguished name,not subject to access control * rootdn "cn=Manager,dc=example,dc=com" rootpw password * # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended * updatedn cn=syncuser,dc=example,dc=com updateref ldap://151.2.119.120 directory /var/lib/ldap/example.com access to attrs=userpassword by self write by anonymous auth by dn="cn=syncuser,dc=example,dc=com" write by * auth access to * by self write by dn="cn=syncuser,dc=example,dc=com" write by * read * # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM [root@slave openldap]# * Master ldap.conf ============== * # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never * host 151.2.119.120 151.2.119.133 base dc=example,dc=com binddn cn=Manager,dc=example,dc=com bindpw password bind_policy soft pam_password expo Slave ldap.conf ============== * # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never * host 151.2.119.133 151.2.119.120 base dc=example,dc=com binddn cn=Manager,dc=example,dc=com bindpw password bind_policy soft pam_password expo *

16 years, 9 months

performance tuning for n-way and heavy client load

by Zetan Drableg

openldap 2.4.57 on 16 core OracleLinux VMs with NVME disk. 8 nodes in n-way multi master configuration, MDB backend, 50k unique DNs. We see about 10,000 auths per minute per node. Under heavy client load, the log shows many "deferring operation: binding" messages in the same second. slapd is using only 400% cpu (of 1600 possible). [2021-04-13 19:15:58] connection_input: conn=150474 deferring operation: binding When I write LDIFs to one node like delete user or remove user from group, we see spikes in authentication latency metrics (what's normally .2 - .5 second response time goes up to 15-30 seconds) across all nodes in the cluster at the same time. What knobs can be adjusted to allow for more concurrency? It seems like writes are impacting reads. *slapd.conf: threads* default is 32, tried 64 and 128 with little improvement *slapd.conf: syncrepl* Should I increase sessionlog size? Should I increase checkpoint ops? How to determine optimum values? syncprov-checkpoint 100 5 syncprov-sessionlog 100 syncprov-reloadhint TRUE *mdb* maxsize 17179869184 *Indices* index objectClass eq,pres index cn,uid,mail,mobile eq,pres,sub index o,ou,dc,preferredLanguage eq,pres index member,memberUid eq,pres index uidNumber,gidNumber eq,pres index memberOf eq index entryUUID eq index entryCSN eq index uniqueMember eq index sAMAccountName eq *ulimit* bash-4.2$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 482391 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1048576 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited *n-way config* serverID 1 ldap://XXXX:12389 syncrepl rid=1 provider=ldap://XXXXXX:12389 bindmethod=simple starttls=yes tls_cert=/opt/slapd/conf/cert.pem tls_cacert=/etc/pki/tls/cert.pem tls_key=/opt/slapd/conf/key.pem binddn="cn=replication_manager,dc=service-accounts,o=Root" credentials="YYYYYY" tls_reqcert=never searchbase="" schemachecking=on type=refreshAndPersist retry="60 +" (and 7 more) mirrormode on Any ideas? Thanks -Zetan

3 years, 7 months

Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap weird behavior

by "POISSON Frédéric"

Hello, I'm doing a OpenLDAP test with a master/slave replication configuration including ppolicy overlay. I would like to enable password change from the slave replica with chain overlay, in order to validate the ppolicy olcPPolicyForwardUpdates attribute to TRUE. I'm using LDAPS from slave to master with SASL External authentication with client certificate. The client certificate correspond to a user DN entry with "manage" rights on the master server (the same used for the replication). This user DN has authzTo attribute in order to match the correct PROXYAUTHZ request from its dn to user DN. All of this configuration works on replica when i do first a failed authentication (err=49) on replica. The pwdFailureTime value is updated on the DN entry from replica to slave normally. I'm also able to do after some self entry update on some attribute such as password or others from replica to master. But the weird behavior is that i need to run first an failed authentication, otherwise if i try to change attribute on the slave server, it respond an err=80 "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?". The only way to retrieve correct behavior is to restart slapd, and redo one failed authentication first. It seems that the chain overlay do not connect the master server at startup Do you have any ideas why i have this behavior ? I'm using a 2.4.49 build of openldap, and inside logs on master server i see that the slave use the same connection. Here is the LDIF change and configuration on my replica : dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldaps://valid7-lab-ldap1.tld olcDbIDAssertBind: bindmethod=sasl saslmech=external starttls=no tls_cert="/usr/local/openldap/etc/openldap-valid7/tls/db1_rid001_cert.pem" tls_key="/usr/local/openldap/etc/openldap-valid7/tls/db1_rid001_key.pem" tls_cacert="/usr/local/openldap/etc/openldap-valid7/tls/cacert.pem" tls_reqcert=demand tls_crlcheck=none mode=self olcDbRebindAsUser: TRUE dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcUpdateRef olcUpdateRef: ldaps://valid7-lab-ldap1.tld - dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config changetype: modify replace: olcPPolicyForwardUpdates olcPPolicyForwardUpdates: TRUE - Here is LDIF change on my master : dn: cn=config changetype: modify replace: olcAuthzPolicy olcAuthzPolicy: to - Thanks in advance for your reply -- Frederic Poisson

4 years, 7 months

openldap-technical search results for query "starttls"