openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

ldap_set_options() not working but environment variables do work
by Frank Crow 06 Apr '16

06 Apr '16

Hi, I've got some code that uses ldap_start_tls_s() and the server requires client-side certificates. If I set them in the environment, e.g., # export LDAPTLS_CERT="/etc/openldap/some.crt" > # export LDAPTLS_KEY="/etc/openldap/some.key" Then everything works fine. However, if I use: const char* tls_cert="/etc/openldap/some.crt"; > const char* tls_key="/etc/openldap/some.key"; > ldap_set_option( ld, LDAP_OPT_X_TLS_CERTFILE, tls_cert ); > ldap_set_option( ld, LDAP_OPT_X_TLS_KEYFILE, tls_key ); Then it doesn't work. What am I doing wrong? Should it be "&tls_cert" and "&tls_key"? I did do an ldap_get_option() using both methods to verify and I get the value that I'm expecting either way. Thanks, -- Frank

1 1

using ldap_sasl_interactive_bind_s() with EXTERNAL only
by Frank Crow 05 Apr '16

05 Apr '16

Hi, I'm only ever going to use sasl_mech="EXTERNAL" with my client code. I tried using ldap_sasl_bind_s() but that returned with LDAP_SASL_BIND_IN_PROGRESS. I then used ldap_sasl_interactive_bind_s() based on the example in clients/tools/common.c more or less. I don't actually need the defaults struct, so I pass defaults=NULL and therefore don't use anything like lutil_sasl_defaults(), etc. I implemented a LDAP_SASL_INTERACT_PROC using the example in libraries/liblutil/sasl.c which is very similar to lutil_sasl_interact() except that it doesn't support LDAP_SASL_INTERACTIVE and my version of the interaction() function does nothing but return LDAP_SUCCESS. Looking at it, I could probably shorten my version of the lutil_sasl_interact() to simply return LDAP_SUCCESS and not even bother with an interaction() function. It appears to work just fine and the debug output says: ldap_sasl_interactive_bind: user selected: EXTERNAL > ldap_int_sasl_bind: EXTERNAL > ldap_int_sasl_open: host=server1.paxriver.progeny.net > => ldap_dn2bv(16) > <= ldap_dn2bv(cn=xxxxxxx,ou=xxxxxxx,ou=xxx,o=xxx,dc=xxxx,dc=xxx)=0 > SASL/EXTERNAL authentication started > sasl_interact() > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ldap_msgfree > ldap_result ld 0x1366940 msgid 2 So my questions: 1. Is there anything wrong with that approach? 2. Is there a better (simpler/easier) way to do this? Any advice is highly appreciated! Thanks, Frank

1 0

Openldap 2.4.44 syncprov delays
by Frank Swasey 04 Apr '16

04 Apr '16

Folks, I have recently upgraded my ldap servers (RHEL6, locally built RPM) from 2.4.42 to 2.4.44. After several days of chasing why our nagios checks for syncrepl performance were reporting long delays, I gave up and rolled the primary server back to 2.4.42. This week I have built a primary and replica on RHEL7 with 2.4.44 (again locally built) and have just discovered through some intensive testing and log crawling that the syncprov log entries (with loglevel sync) show up lacking the csn about every hour, and if there are outstanding changes to be replicated when that happens, the syncrepl check on the replica server starts reporting it has fallen behind. This behavior does not exhibit with the 2.4.42 code base. Is this the new normal? Is there something (that has not yet made it into the guide) that I need to change in my syncprov/syncrepl configuration to get around this? This is a “normal” syncprov log entry: Apr 1 18:18:40 ldap7p slapd[10061]: syncprov_sendresp: cookie=rid=100,csn=20160401221840.842942Z#000000#000#000000 This is one of the new ones: Apr 1 18:14:28 ldap7p slapd[10061]: syncprov_sendresp: cookie=rid=100 -- Frank Swasey Sr Systems Administrator Systems Architecture & Administration University of Vermont

2 4

Securing an LADP server.
by Jerry 01 Apr '16

01 Apr '16

I am looking for easy to implement suggestions for securing an LDAP server. First, this is an OpenLDAP-2.4 server running on a FreeBSD-11 machine. The two laptops I carry are both running Windows 10 PRO. I want to be able to access the LDAP server from these machines when I am traveling; however, I want to make sure that not just anyone could gain access to the LDAP server. Primarily, the server would be accessed by my MUA to lookup email addresses. -- Jerry

2 1

OpenLDAP log file ownership getting modified automatically.
by Prashanth P.Nair 01 Apr '16

01 Apr '16

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

3 8

Re: Making a full replica: slapd -c "rid=xxx" doesn't seem to work
by Jephte Clain 01 Apr '16

01 Apr '16

hello, I haven't tried full (config + data) replication from a multimaster setup, but I think that doing so, the slave would become a master like the other from which it replicate, wouldn't it? cc-ing the list to have the opinion of the real experts :-) by the way, as I write this, I recall an advice from Michael Ströder: if the slaves are to replicate everything from the masters, why wouldn't you make them masters like the others? multi-master replication also work for more than two masters. best regards, Jephté Clain 2016-04-01 18:32 GMT+04:00 Jussi Sallinen <jussi(a)synack.fi>: > Ah, > > This is two multimaster servers so I guess that approach doesn't work, as it's meant for master/slave? > > -- > -Jussi Sallinen | UNIX System Administrator > jussi(a)synack.fi | Syn Ack > +358 40 700 7600 | Helsinki, Finland > >> On 1.4.2016, at 11.08, Jephte Clain <jephte.clain(a)univ-reunion.fr> wrote: >> >> hello, >> >> one more thing: make sure to have the proper syncprov overlay AND >> syncrepl directive pointing to the master slapd on the master, at >> least on olcDatabase={0}config and olcDatabase={1}mdb (or whatever is >> the first database that contains the data), e.g: >> >> dn: olcDatabase={0}config,cn=config >> olcSyncrepl: {0}rid=0 provider="ldap://master/" searchbase=cn=config ... >> olcUpdateRef: ldap://master/ >> ... >> >> dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config >> ... >> >> dn: olcDatabase={1}mdb,cn=config >> olcSuffix: dc=univ-reunion,dc=fr >> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase=dc=univ-reunion,dc=fr >> olcUpdateRef: ldap://master/ >> ... >> >> dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config >> ... >> >> the syncrepl directive does nothing on the master, but as this >> configuration is replicated on the slave, the slave knows it has to >> replicate from the master (I hope it's clear enough) >> >> >> >> 2016-04-01 11:06 GMT+04:00 Jussi Sallinen <jussi(a)synack.fi>: >>> Hi, >>> >>> Thank you for the reply! >>> That's what I thought could be the answer. >>> >>> I will now need to try out how this works with our actual database dc=synack,dc=fi >>> >>> Basicly since this will be a new replica without even the dcDomain object in the initial database it should pick up all the data from existing multimaster replica (empty database is without csn etc and contains no update timestamp). >>> >>> -- >>> -Jussi Sallinen | UNIX System Administrator >>> jussi(a)synack.fi | Syn Ack >>> +358 40 700 7600 | Helsinki, Finland >>> >>>> On 1.4.2016, at 8.27, Jephte Clain <jephte.clain(a)univ-reunion.fr> wrote: >>>> >>>> Le 01/04/2016 01:26, Jussi Sallinen a écrit : >>>>> Hi, >>>>> >>>>> How you managed to get this working or did you come up with a workaround: http://www.openldap.org/lists/openldap-technical/201201/msg00205.html >>>>> >>>>> I have a similar situation where I'm doing a reprovision of my 2nd multimaster replica virtualhost and adding base config etc. with ldapadd (we build it from scratch with Ansible during reprovisioning). >>>>> After the new multimaster replica comes up it has newer timestamps than the current up & running replica from where this new one is supposed to replicate everything as we use ldapadd during the reprovision phase with Ansible. >>>> >>>> hello, >>>> >>>> after you create the seed replica, you just have to "touch" the master to ensure the timestamp on the master is newer than on the replica. >>>> >>>> As the seed configuration only contains 3 objects: cn=config, olcDatabase={-1}frontend,cn=config and olcDatabase={0}config,cn=config, I do it that way: >>>> >>>> $ ldapmodify -H ldap://master ...credentials... <<EOF >>>> dn: cn=config >>>> changetype: modify >>>> >>>> dn: olcDatabase={-1}frontend,cn=config >>>> changetype: modify >>>> >>>> dn: olcDatabase={0}config,cn=config >>>> changetype: modify >>>> EOF >>>> >>>> best regards, >>>> Jephté Clain >>>> >>>> -- >>>> *Jephté CLAIN | Développeur, Intégrateur d'applications* >>>> Service Systèmes d'Information >>>> Direction des Systèmes d'Information <http://dsi.univ-reunion.fr> >>>> Tél: +262 262 93 86 31 <tel:+262262938631> || Gsm: +262 692 29 58 24 <tel:+262692295824> >>>> www.univ-reunion.fr <http://www.univ-reunion.fr> || Facebook <http://www.facebook.com/pages/Universit%C3%A9-de-La-R%C3%A9union-OFFICIEL/1…> || Twitter <http://twitter.com/univ_reunion> >> >> >> >> -- >> Jephté CLAIN | Développeur, Intégrateur d'applications >> Service Système d'Information >> Direction des Systèmes d'Information >> Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24 >> > -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

1 0

Need help unpicking stats logging
by Philip Colmer 01 Apr '16

01 Apr '16

I've currently got stats logging turned on while I try to troubleshoot an application and I've noticed some rather strange searches going on. Strange in that the searches are for very high uidNumber values or for uid values that don't exist ... suggesting that someone might be trying to grab data from our server. What I'm struggling with is trying to figure out from the logs (a) the IP address that these queries are coming from and/or (b) the authenticated account being used (even if anonymous). For example, if I have a log line like this: conn=1928683 op=24 SRCH base="ou=accounts,dc=linaro,dc=org" scope=2 deref=0 filter="(&(uid=tftp)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" is there anything I can do with the conn or op values to connect that particular search query to an earlier logged BIND log entry? Or is there a different/better way for me to try and get the information I'm after? Thanks. Philip

2 1

Re: Need help unpicking stats logging
by Philip Colmer 01 Apr '16

01 Apr '16

Many thanks, Emmanuel, for your quick reply. That is certainly helping me figure out what is going on. It looks like one or two of the client systems aren't correctly configured and this is helping me pin them down. Regards Philip On 1 April 2016 at 11:49, Emmanuel Lécharny <elecharny(a)gmail.com> wrote: > Le 01/04/16 12:45, Philip Colmer a écrit : >> I've currently got stats logging turned on while I try to troubleshoot >> an application and I've noticed some rather strange searches going on. >> Strange in that the searches are for very high uidNumber values or for >> uid values that don't exist ... suggesting that someone might be >> trying to grab data from our server. >> >> What I'm struggling with is trying to figure out from the logs (a) the >> IP address that these queries are coming from and/or (b) the >> authenticated account being used (even if anonymous). >> >> For example, if I have a log line like this: >> >> conn=1928683 op=24 SRCH base="ou=accounts,dc=linaro,dc=org" scope=2 >> deref=0 filter="(&(uid=tftp)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" >> >> is there anything I can do with the conn or op values to connect that >> particular search query to an earlier logged BIND log entry? > > Just grep your log for 'conn=1928683', it will give you all the history > for the 'user' that did the search. > > Now, FTR, that serach really looks like a PAM LDAP or a SSSD search. > Pretty standard. >

1 0

Re: Making a full replica: slapd -c "rid=xxx" doesn't seem to work
by Jephte Clain 01 Apr '16

01 Apr '16

hello, one more thing: make sure to have the proper syncprov overlay AND syncrepl directive pointing to the master slapd on the master, at least on olcDatabase={0}config and olcDatabase={1}mdb (or whatever is the first database that contains the data), e.g: dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=0 provider="ldap://master/" searchbase=cn=config ... olcUpdateRef: ldap://master/ ... dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config ... dn: olcDatabase={1}mdb,cn=config olcSuffix: dc=univ-reunion,dc=fr olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase=dc=univ-reunion,dc=fr olcUpdateRef: ldap://master/ ... dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config ... the syncrepl directive does nothing on the master, but as this configuration is replicated on the slave, the slave knows it has to replicate from the master (I hope it's clear enough) 2016-04-01 11:06 GMT+04:00 Jussi Sallinen <jussi(a)synack.fi>: > Hi, > > Thank you for the reply! > That's what I thought could be the answer. > > I will now need to try out how this works with our actual database dc=synack,dc=fi > > Basicly since this will be a new replica without even the dcDomain object in the initial database it should pick up all the data from existing multimaster replica (empty database is without csn etc and contains no update timestamp). > > -- > -Jussi Sallinen | UNIX System Administrator > jussi(a)synack.fi | Syn Ack > +358 40 700 7600 | Helsinki, Finland > >> On 1.4.2016, at 8.27, Jephte Clain <jephte.clain(a)univ-reunion.fr> wrote: >> >> Le 01/04/2016 01:26, Jussi Sallinen a écrit : >>> Hi, >>> >>> How you managed to get this working or did you come up with a workaround: http://www.openldap.org/lists/openldap-technical/201201/msg00205.html >>> >>> I have a similar situation where I'm doing a reprovision of my 2nd multimaster replica virtualhost and adding base config etc. with ldapadd (we build it from scratch with Ansible during reprovisioning). >>> After the new multimaster replica comes up it has newer timestamps than the current up & running replica from where this new one is supposed to replicate everything as we use ldapadd during the reprovision phase with Ansible. >> >> hello, >> >> after you create the seed replica, you just have to "touch" the master to ensure the timestamp on the master is newer than on the replica. >> >> As the seed configuration only contains 3 objects: cn=config, olcDatabase={-1}frontend,cn=config and olcDatabase={0}config,cn=config, I do it that way: >> >> $ ldapmodify -H ldap://master ...credentials... <<EOF >> dn: cn=config >> changetype: modify >> >> dn: olcDatabase={-1}frontend,cn=config >> changetype: modify >> >> dn: olcDatabase={0}config,cn=config >> changetype: modify >> EOF >> >> best regards, >> Jephté Clain >> >> -- >> *Jephté CLAIN | Développeur, Intégrateur d'applications* >> Service Systèmes d'Information >> Direction des Systèmes d'Information <http://dsi.univ-reunion.fr> >> Tél: +262 262 93 86 31 <tel:+262262938631> || Gsm: +262 692 29 58 24 <tel:+262692295824> >> www.univ-reunion.fr <http://www.univ-reunion.fr> || Facebook <http://www.facebook.com/pages/Universit%C3%A9-de-La-R%C3%A9union-OFFICIEL/1…> || Twitter <http://twitter.com/univ_reunion> > -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

1 0

Re: Making a full replica: slapd -c "rid=xxx" doesn't seem to work
by Jephte Clain 01 Apr '16

01 Apr '16

Le 01/04/2016 01:26, Jussi Sallinen a écrit : > Hi, > > How you managed to get this working or did you come up with a > workaround: > http://www.openldap.org/lists/openldap-technical/201201/msg00205.html > > I have a similar situation where I'm doing a reprovision of my 2nd > multimaster replica virtualhost and adding base config etc. with > ldapadd (we build it from scratch with Ansible during reprovisioning). > After the new multimaster replica comes up it has newer timestamps > than the current up & running replica from where this new one is > supposed to replicate everything as we use ldapadd during the > reprovision phase with Ansible. hello, after you create the seed replica, you just have to "touch" the master to ensure the timestamp on the master is newer than on the replica. As the seed configuration only contains 3 objects: cn=config, olcDatabase={-1}frontend,cn=config and olcDatabase={0}config,cn=config, I do it that way: $ ldapmodify -H ldap://master ...credentials... <<EOF dn: cn=config changetype: modify dn: olcDatabase={-1}frontend,cn=config changetype: modify dn: olcDatabase={0}config,cn=config changetype: modify EOF best regards, Jephté Clain -- *Jephté CLAIN | Développeur, Intégrateur d'applications* Service Systèmes d'Information Direction des Systèmes d'Information <http://dsi.univ-reunion.fr> Tél: +262 262 93 86 31 <tel:+262262938631> || Gsm: +262 692 29 58 24 <tel:+262692295824> www.univ-reunion.fr <http://www.univ-reunion.fr> || Facebook <http://www.facebook.com/pages/Universit%C3%A9-de-La-R%C3%A9union-OFFICIEL/1…> || Twitter <http://twitter.com/univ_reunion>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical