openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Get values of Telephone Tab ( A.D. ) using ldapsearch.
by - - 26 Feb '19

26 Feb '19

Hi, I am trying to get the values of Telephone tab in a Active Directory Server using ldapsearch. http://www.windows-active-directory.com/telephone-tab-in-ad-user-properties… Active Directory User properties – Telephone tab<http://www.windows-active-directory.com/telephone-tab-in-ad-user-properties…> The telephone tab of the user properties window allows you to add detailed telephone contacts for the user. www.windows-active-directory.com I get other values like mail or telephoneNumber at the first tab but I can't get neither information of Telephone Tab . I am using this command: ldapsearch -x -H ldap://IP:PORT -D "cn=userldap,OU=users,DC=domain,DC=local" -w PASSWORD -b "DC=domain,DC=local" "(&(objectclass=person)(mail=user1(a)domain.com))" mail telephoneNumber mobile # extended LDIF # # LDAPv3 # base <DC=domain,DC=local> with scope subtree # filter: (&(objectclass=person)(mail=user1(a)domain.com)) # requesting: mail telephoneNumber mobile # # User 1, Users, domain.local dn: CN=User 1,OU=Users,DC=domain,DC=local l telephoneNumber: 1 mail: user1(a)domain.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Is posible get this information using ldapsearch tool?. Thanks in advance . Best Regards

1 0

Help to understand "Paged results cookie is invalid"
by Andrea Patricelli 25 Feb '19

25 Feb '19

Good morning, I'm connecting to an OpenLdap through a JNDI client [1] and I "randomly" get this error: [LDAP: error code 2 - paged results cookie is invalid]; I suppose that the problem is related to multiple clients connecting to the LDAP with the same credentials (the same user), since the cookie is somehow related the user. Moreover since two different clients (different machines and IPs) are connecting simultaneously they invalidate the cookie to each other. Googling a bit and looking at the reference [1] and documentation I did not find something that confirm my thesis. Are my assumptions right or I'm misunderstanding the problem? If right, if there are multiple connections from the same client (same machine and IP) does OpenLdap manage this situation? I suppose (obviously) so, but asking anyway :) Thanks in advance, Andrea [1] https://github.com/Tirasa/ConnIdLDAPBundle/blob/net.tirasa.connid.bundles.l… [2] http://www.faqs.org/rfcs/rfc2696.html -- Dott. Andrea Patricelli Tel. +39 3204524292 Engineer @ Tirasa S.r.l. Viale Vittoria Colonna 97 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member

1 0

Forbidden account password reuse of the last 5 password
by Tian Zhiying 16 Feb '19

16 Feb '19

Hi Is there a feature that OpenLDAP password policy can forbidden user password reuse of the last 5 password? Thanks.

8 19

Re: Switch OpenLDAP backend database from HDB to MDB
by SHarbich＠t-online.de 15 Feb '19

15 Feb '19

Hi Ryan, | Note that the database config attributes for hdb and mdb differ a little bit. For example you should configure olcDbMaxSize for mdb. For example, how would I change the following entry in the config file? dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}dynlist.so olcModuleLoad: {2}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 9495e2a6-da11-1033-97d9-c1ceaf236428 creatorsName: cn=admin,cn=config createTimestamp: 20140926214112Z entryCSN: 20170201184048.317884Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170201184048Z Should the change be as follows? - - - olcModuleLoad: {0}back_hdb + + + olcModuleLoad: {0}back_mdb dn: olcBackend={0}hdb,cn=config objectClass: olcBackendConfig olcBackend: {0}hdb structuralObjectClass: olcBackendConfig entryUUID: 94960592-da11-1033-97da-c1ceaf236428 creatorsName: cn=admin,cn=config createTimestamp: 20140926214112Z entryCSN: 20140926214112.940239Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140926214112Z Should the change be as follows? - - - dn: olcBackend={0}hdb,cn=config + + + dn: olcBackend={0}hmdb,cn=config - - - olcBackend: {0}hdb + + + olcBackend: {0}mdb So I have everywhere the entry of hdb to mdb? Thank you in advance for your support. Greetings from Stefan Harbich

1 0

help with mdb database recovery after crash
by Andrei Mikhailovsky 14 Feb '19

14 Feb '19

Hello everyone, I have a bit of an issue with my ldap database. I have a Zimbra community edition which uses openldap. A server crashed and I am unable to start the ldap services after the reboot. The description of my problem, after some digging about is: the initial error indicated problem with the ldap Starting ldap...Done. Search error: Unable to determine enabled services from ldap. Enabled services read from cache. Service list may be inaccurate. Having investigated the issue, I noticed the following errors in the zimbra.log slapd[31281]: mdb_entry_decode: attribute index 560427631 not recognized I also noticed that the /opt/zimbra/data/ldap/mdb/db/data.mdb is actually 81Gb in size and had reached the limit imposed by the ldap_db_maxsize variable. so over the weekend, the LDAP mdb file became no longer sparse. I tried following the steps described in https://syslint.com/blog/tutorial/solved-critical-ldap-primary-mdb-database… but with no success, as the slapcat segfaults with the following message. /opt/zimbra/common/sbin/slapcat -ccc -F /opt/zimbra/data/ldap/config -b "" -l /opt/zimbra/RECOVERY/SLAPCAT/zimbra_mdb.ldiff 5c583982 mdb_entry_decode: attribute index 560427631 not recognized Segmentation fault (core dumped) the mdb_copy produces a file of 420 mb in size, but it still contains the "mdb_entry_decode: attribute index 560427631 not recognized" error. I've also tried mdb_dump, but had the same issues after using the mdb_load command. I found a post ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8360 ) in the openldap community that the mdb gets corrupted if it reaches the maximum defined size. but no solution of how to fix it. any advice on getting the database recovered and working again? Cheers Andrei

3 5

Re: help with mdb database recovery after crash
by Andrei Mikhailovsky 14 Feb '19

14 Feb '19

Hi Howard, Many thanks for your suggestions. I am about to try what you've suggested (download and compile the latest master version of lmdb from git using master branch of https://github.com/LMDB/lmdb). However, just to note, I am running the latest version of zimbra which uses pretty recent version of openldap: ii zimbra-lmdb 2.4.46-1zimbra8.7b amd64 LMDB Binaries ii zimbra-lmdb-lib:amd64 2.4.46-1zimbra8.7b amd64 LMDB Libraries ii zimbra-openldap-client 2.4.46-1zimbra8.7b amd64 OpenLDAP Client Binaries ii zimbra-openldap-lib:amd64 2.4.46-1zimbra8.7b amd64 OpenLDAP Libraries ii zimbra-openldap-server 2.4.46-1zimbra8.7b amd64 OpenLDAP Server Binaries The problem that I am describing occurred with the above version of openldap. I will keep you posted with any updates. Cheers Andrei ----- Original Message ----- > From: "Howard Chu" <hyc(a)symas.com> > To: "Andrei Mikhailovsky" <andrei(a)arhont.com>, "openldap-technical" <openldap-technical(a)openldap.org> > Sent: Thursday, 7 February, 2019 02:42:40 > Subject: Re: help with mdb database recovery after crash > Andrei Mikhailovsky wrote: >> Hello everyone, >> >> I have a bit of an issue with my ldap database. I have a Zimbra community >> edition which uses openldap. A server crashed and I am unable to start the ldap >> services after the reboot. The description of my problem, after some digging >> about is: >> >> >> the initial error indicated problem with the ldap >> >> Starting ldap...Done. >> Search error: Unable to determine enabled services from ldap. >> Enabled services read from cache. Service list may be inaccurate. >> >> Having investigated the issue, I noticed the following errors in the zimbra.log >> >> *slapd[31281]: mdb_entry_decode: attribute index 560427631 not recognized* >> >> I also noticed that the /opt/zimbra/data/ldap/mdb/db/data.mdb is actually 81Gb >> in size and had reached the limit imposed by the ldap_db_maxsize variable. so >> over the weekend, the LDAP mdb file became no longer sparse. >> >> I tried following the steps described in >> https://syslint.com/blog/tutorial/solved-critical-ldap-primary-mdb-database… >> but with no success, as the slapcat segfaults with the following message. >> >> >> /opt/zimbra/common/sbin/slapcat -ccc -F /opt/zimbra/data/ldap/config -b "" -l >> /opt/zimbra/RECOVERY/SLAPCAT/zimbra_mdb.ldiff >> 5c583982 mdb_entry_decode: attribute index 560427631 not recognized >> Segmentation fault (core dumped) >> >> the mdb_copy produces a file of 420 mb in size, but it still contains the >> "mdb_entry_decode: attribute index 560427631 not recognized" error. >> I've also tried mdb_dump, but had the same issues after using the mdb_load >> command. >> >> I found a post ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8360 ) >> in the openldap community that the mdb gets corrupted if it reaches the maximum >> defined size. but no solution of how to fix it. > > That's from over 3 years ago and has subsequently fixed. If you're running on > such an old > release, there's likely not much that can be done. Ordinarily it's possible to > back up to > the immediately preceding transaction, in case the last transaction is > corrupted, but with > that particular bug it's likely that the corruption occurred in an earlier > transaction > and has been carried forward in all subsequent ones. >> >> any advice on getting the database recovered and working again? > > You could try using the preceding transaction and see if it's in any better > shape. The code > for this is not released in LMDB 0.9. You can compile the mdb.master branch in > git to obtain > it. Then use the "-v" option with mdb_copy and see if that copy of the database > is usable. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

slapd memory usage
by A. Schulze 13 Feb '19

13 Feb '19

Hello, A friend told me about his findings on slapd memory usage. setup: openldap-2.4.47 back_mdb slapd running as PID 1 inside a docker container docker host and docker conatiner based on Debian 9 / 64 bit finding: with minimal / trivial data slapd consume happily 20% of available phys. memory: # top -p $( pidof slapd) top - 21:47:10 up 10 days, 10 min, 5 users, load average: 0,06, 0,08, 0,09 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,9 us, 0,5 sy, 0,0 ni, 97,2 id, 1,3 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem : 3926252 total, 142672 free, 1517516 used, 2266064 buff/cache KiB Swap: 975868 total, 913316 free, 62552 used. 2065320 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2604 165534 20 0 1039308 732000 5628 S 0,0 18,6 0:00.38 slapd workaround: https://discuss.linuxcontainers.org/t/empty-openldap-slapd-consuming-800-mb… -> limit open files to 1024 # top -p $( pidof slapd) top - 21:49:16 up 10 days, 12 min, 5 users, load average: 0,07, 0,11, 0,10 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,7 us, 0,6 sy, 0,0 ni, 90,6 id, 7,1 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 3926252 total, 863500 free, 796492 used, 2266260 buff/cache KiB Swap: 975868 total, 913320 free, 62548 used. 2786248 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2993 165534 20 0 48864 7820 5684 S 0,0 0,2 0:00.01 slapd as far as I can tell from a short test there are no functional drawbacks. Any idea why the memory usage is so different? Andreas

4 8

olcRootPW vs. userPassword of olcRootDN
by Zev Weiss 12 Feb '19

12 Feb '19

Hello, I recently set about changing the rootdn password of my OpenLDAP 2.4 server. I constructed an LDIF file looking something like this: dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}new_passwd_hash and fed that into ldapmodify. The server then started accepting the new password and I figured I was done. What I noticed a few minutes later, however, was that the server was *also* still accepting the *old* password. After some peeking around, my guess is that this is due to the fact that while my config database ended up containing, as expected: dn: olcDatabase={1}mdb,cn=config # etc... olcSuffix: dc=mydomain,dc=tld olcRootDN: cn=admin,dc=mydomain,dc=tld olcRootPW:: [base64 of {SSHA}new_passwd_hash] the "main" database entry for cn=admin,dc=mydomain,dc=tld still had a userPassword attribute of [base64 of {SSHA}old_passwd_hash]. Prior to the password change the same base64 hash had been present in both, but my change of course only updated the config database. So I'm left with a few questions: Is it "normal" to have both olcRootPW and the rootdn's userPassword stored redundantly like this? If not, is the fact that I do a sign that I did something inappropriate when initially configuring the server? (Unfortunately I no longer remember exactly what I did at the time.) If so, I assume the recommended password update procedure would be to update both in tandem, though I have to wonder what the point of the redundancy (and resulting potential for inconsistency) is. And should section 5.2.5.5 of the admin guide perhaps make some mention of this? Thanks, Zev Weiss

2 1

Re: LMDB mdb_dbi_open mystery
by Sam Dave 11 Feb '19

11 Feb '19

Thanks for the reply. That's what it says on its own, but the doc also says: * The database handle will be private to the current transaction until * the transaction is successfully committed. If the transaction is * aborted the handle will be closed automatically. * After a successful commit the handle will reside in the shared * environment, and may be used by other transactions. That suggests I have to wait for a transaction to finish before I can reuse the same db handle for other transactions. How would you in practice perform multiple transactions at the same time? I don't see it yet. I'm missing something basic. Feb 11, 2019, 5:50 AM by hyc(a)symas.com: > Sam Dave wrote: > >> Hello, >> >> The doc for mdb_dbi_open says: >> >> * This function must not be called from multiple concurrent >> * transactions in the same process. A transaction that uses >> * this function must finish (either commit or abort) before >> * any other transaction in the process may use this function. >> >> This indicates that each process can only perform one transaction at the same time. >> > > No, it only says you may only call mdb_dbi_open from one transaction at a time. > >> This makes sense for write transactions, but wasn't LMDB supposed to support multiple read transactions at the same time? >> >> I'm a bit confused now. Can you assist? >> >> Thanks, >> Sam >> > > > -- > -- Howard Chu > CTO, Symas Corp. > http://www.symas.com <http://www.symas.com> > Director, Highland Sun > http://highlandsun.com/hyc <http://highlandsun.com/hyc/> > Chief Architect, OpenLDAP > http://www.openldap.org/project <http://www.openldap.org/project/> >

4 7

Issue with replication
by Jignesh Patel 11 Feb '19

11 Feb '19

We are running openldap in cluster mode with MDB setup, and we started second cluster after some time and we observe that data is non synch between those 2 servers. So how do we synchronize the data. > On Sep 7, 2018, at 8:00 AM, openldap-technical-request(a)openldap.org wrote: > > Send openldap-technical mailing list submissions to > openldap-technical(a)openldap.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.openldap.org/lists/mm/listinfo/openldap-technical > or, via email, send a message with subject or body 'help' to > openldap-technical-request(a)openldap.org > > You can reach the person managing the list at > openldap-technical-owner(a)openldap.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openldap-technical digest..." > > > Send openldap-technical mailing list submissions to > openldap-technical(a)openldap.org > When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..." > > Today's Topics: > > 1. Replication issue? Data is different between master and > consumer with same entryCSNs (Dave Steiner) > 2. olcSecurity: tls=1 and olcLocalSSF= : what value should I > use? (Jean-Francois Malouin) > 3. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I > use? (Quanah Gibson-Mount) > 4. Re: Replication issue? Data is different between master and > consumer with same entryCSNs (Frank Swasey) > 5. Re: Replication issue? Data is different between master and > consumer with same entryCSNs (Quanah Gibson-Mount) > 6. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I > use? (Jean-Francois Malouin) > 7. Re: Replication issue? Data is different between master and > consumer with same entryCSNs (Dave Steiner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 5 Sep 2018 16:49:44 -0400 > From: Dave Steiner <steiner(a)rutgers.edu> > To: openldap-technical(a)openldap.org > Subject: Replication issue? Data is different between master and > consumer with same entryCSNs > Message-ID: <129e3614-50fe-ba15-4d4b-5f94d14abcd9(a)oit.rutgers.edu> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > I've been noticing various data discrepancies between our LDAP master and LDAP > consumers.? We are running OpenLDAP v2.4.44.? We have two masters running > "mirromode TRUE" and all updates go through a VIP that points to the first one > unless it's not available (doesn't happen very often except for during patches > and restarts). We have 13 consumers that replicate through that same VIP. > > Here's an example of our syncrepl for a client: > > syncrepl rid=221 > ? type=refreshAndPersist > ? schemachecking=on > ? provider="ldap://ldapmastervip.rutgers.edu/" > ? bindmethod=sasl > ? saslmech=EXTERNAL > ? starttls=yes > ? tls_reqcert=demand > ? tls_protocol_min="3.1" > ? searchbase="dc=rutgers,dc=edu" > ? attrs="*,+" > ? retry="10 10 20 +" > ? logbase="cn=accesslog" > ? logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > ? syncdata=accesslog > ? network-timeout=30 > ? keepalive=180:3:60 > > I check the contextCSN attributes on all the instances every day and they are > all in sync (except during any major changes, of course). But I occasionally > notice discrepancies in the data.... even though the contextCSNs and entryCSNs > are the same.? For example (note hostnames have been changed): > > $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress > createTimestamp modifyTimestamp entryCSN > dn: uid=XXXX,ou=People,dc=rutgers,dc=edu > createTimestamp: 20121220100700Z > postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656 > entryCSN: 20180505002024.083133Z#000000#001#000000 > modifyTimestamp: 20180505002024Z > > $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress > createTimestamp modifyTimestamp entryCSN > dn: uid=XXXX,ou=People,dc=rutgers,dc=edu > createTimestamp: 20121220100700Z > postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656 > entryCSN: 20180505002024.083133Z#000000#001#000000 > modifyTimestamp: 20180505002024Z > > So I'm trying to figure out why this happens (config issue, bug, ???) and > second, if I can't use the contextCSN to report that everything is fine, what > else can I do besides trying to compare ldif dumps. > > thanks, > ds > -- > Dave Steiner steiner(a)rutgers.edu > IdM, Enterprise Application Services ?? ASB101; 848.445.5433 > Rutgers University, Office of Information Technology > >

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical