openldap-technical

openldap-technical@openldap.org

9897 discussions

Efficient way to count number of entries in a database?
by Karsten Heymann 14 Nov '17

14 Nov '17

Hi, is there a more efficient way to count how many entries a ldap database has than slapcat -b <suffix> | grep ^dn: | wc -l I searched the cn=Monitor backend but it does not seem to export this number. I want to have this for graphing and reporting and as a secondary data point that replication is working as intended. BR Karsten

3 7

proxy/backend pointers
by David LaPorte 14 Nov '17

14 Nov '17

Hello, I've done a bit of research, but having some difficulty determining if my use case is possible. Here's what I'm trying to do: We have an old unsupported application that authenticates users using an LDAP bind. The credential used for authentication (and what all the internal authorizations are tied to) is employee ID. We are moving to LDAP directory that uses email address instead of employee ID as the DN - the employee ID is still present as an attribute in the new directory and the password remains the same. Since I can't modify the problematic application, it’s not going away anytime soon, and it’s the last thing holding up migration to the new directory system, I'm hoping that I can use OpenLDAP as a shim between the application and the new directory to do something like the following: * Collect credentials (employee_id, password) during bind * using a privileged service account, search/bind against the new directory to map employee ID attribute to email address DN (like mod_authz_ldap does it) * return the success/failure as result of original bind I would appreciate any ideas or pointers if this is possible or if there might be a better way. Thanks in advance! Dave David LaPorte david(a)davidlaporte.org

1 0

Re: a question about "Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()"
by Howard Chu 14 Nov '17

14 Nov '17

James Anderson wrote: > good afternoon; > > we have seen sporadic instances of the “page search root" error: > > dydrad[20250]: [#2224] CREATE-TRANSACTION 8f9e6986-5fd4-c54b-b073-0c134552aa4a R/O => james/test2@d3102d2e-ded8-d740-8340-4b7e5608eb78 (pid=22136 tid=31865) > mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() > > this happens in a situation where we are simply executing numerous requests which just clear the contents of a two-entry database and then insert two new entries. > > we are using lmdb in the version 0.9.17, which i had understood from the threads in this list to be after the point when this problem was addressed. > is that true or is it expected to still be an open issue at that version? The bug was reported in 0.9.17, so it certainly was not fixed in that version. http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8336 Git shows the fix was released in 0.9.18. You should be using 0.9.21 now. -- -- 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

Re: your mail
by Howard Chu 14 Nov '17

14 Nov '17

Dave Horsfall wrote: > On Mon, 13 Nov 2017, Suneet Shah wrote: > >> Hi Openldap >> http://bit.ly/2zC6jTU >> Thank you >> >> Suneet > > Is there some reason why spam is allowed on this list? This email address was a legitimate participant on this list, you can find their posts from 2011-2015 in the archive. Probably his email account has been compromised, we'll turn it off. -- -- 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

(no subject)
by Suneet Shah 13 Nov '17

13 Nov '17

Hi Openldap http://bit.ly/2zC6jTU Thank you Suneet

2 1

a question about "Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()"
by James Anderson 13 Nov '17

13 Nov '17

good afternoon; we have seen sporadic instances of the “page search root" error: dydrad[20250]: [#2224] CREATE-TRANSACTION 8f9e6986-5fd4-c54b-b073-0c134552aa4a R/O => james/test2@d3102d2e-ded8-d740-8340-4b7e5608eb78 (pid=22136 tid=31865) mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() this happens in a situation where we are simply executing numerous requests which just clear the contents of a two-entry database and then insert two new entries. we are using lmdb in the version 0.9.17, which i had understood from the threads in this list to be after the point when this problem was addressed. is that true or is it expected to still be an open issue at that version? if that version is still susceptible, what avenues are customary to upgrade to a version closer to the latest release. we have tried to substitute 0.9.70, but it does not appear possible to do that, due to library incompatibilities, unless we unload/reload all databases. best regards, from berlin, --- james anderson | james(a)dydra.com | http://dydra.com

1 0

Question regarding using OpenLDAP as a proxy to multiple AD servers
by Mārtiņš Mieriņš 11 Nov '17

11 Nov '17

Hi, I'm new to OpenLDAP, I've been reading documentation for some time but cannot figure out whether there is solution. We have many products in our company that are using sAMAccountName (from Active Directory server) as login credentials for authentication purpose. Now we have an additional requirement to support authentication of users from another Active Directory server. Since many products do not allow to specify more than one LDAP server the idea is to configure OpenLDAP proxy that will then forward requests to either AD servers. Nevertheless the format of login credentials has to stay the same. So the final goal is to be able to authenticate users of both AD directories via binding against OpenLDAP proxy using sAMAccountName (can add some other data in DN but it has to be static). 1. Can OpenLDAP be configured to accept sAMAccountName and domain as bind DN and then forward it to either AD servers depending on domain name? 2. If not, can OpenLDAP be configured to perform search (including filtering by sAMAccountName field) behind the scenes and then bind by using DN of a found user?-> all this happens when user tries to bind against OpenLDAP proxy 3. Any other solutions? BR, Martins

2 1

let slapo-ppolicy set pwdFailureTime
by Michael Ströder 09 Nov '17

09 Nov '17

HI! I'm using back-sock as overlay to intercept bind *requests* and send them to an external listener which returns success(0) or invalidCredentials(49). I'd like to avoid having to deal with operational attributes in the user's entry. Therefore in case of invalidCredentials(49) I'd like slapo-ppolicy to add attribute value to 'pwdFailureTime'. The order of overlays in slapd.conf is: overlay sock sockops bind overlay ppolicy overlay lastbind overlay rwm From my understand the requests go from bottom up rwm -> lastbind -> ppolicy -> back-sock .....continue...... returns success(0) or invalidCredentials(49) and vice versa the response go through back-sock -> ppolicy -> lastbind -> rwm It partially works: (/) I see update of 'authTimestamp' by slapo-lastbind. (/) If back-sock listener returns success(0) slapo-ppolicy correctly checks password expiry in the response chain and returns invalidCredentials(49) with appropriate ppolicy response controls. (x) But the attribute 'pwdFailureTime' is not set in case back-sock listener returns invalidCredentials(49). Reading source of ppolicy_bind_response() one of the first things is to check for rs->sr_err == LDAP_INVALID_CREDENTIALS and add another 'pwdFailureTime' value. So it should work. But it doesn't. Any clue what I'm doing wrong? Ciao, Michael.

1 0

Re: Replication problem with attributes
by Quanah Gibson-Mount 09 Nov '17

09 Nov '17

--On Thursday, November 09, 2017 12:39 PM +0100 Dennis Meyer <snooops84(a)gmail.com> wrote: > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * > none > olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=localdomain" > write by self write by * read > olcAccess: {2}to attrs=shadowLastChange by self write by * read > olcAccess: {3}to * by * read > olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="cn=admin,dc=localdomain" write by > dn="cn=mirrormode,dc=localdomain" read by * none ACL {4} will never be evaluated, because ACL parsing stops on the first match, which will be ACL {3} (access to everything by anyone read). Even if you fix that problem, ACL {4} would still be unlikely to be evaluated due to ACL {0} as well. > Any Ideas how could solve this? Fix your ACLs. ;) Something like: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn="cn=admin,dc=localdomain" write by dn="cn=mirrormode,dc=localdomain" read olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=localdomain" write by self write by * read olcAccess: {2}to attrs=shadowLastChange by self write by dn="cn=admin,dc=localdomain" write by * read olcAccess: {3}to * by dn="cn=admin,dc=localdomain" write by * read Note that "by * none" at the end of an ACL is implicit, so it's not required to list it explicitly. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Replication problem with attributes
by Dennis Meyer 09 Nov '17

09 Nov '17

Hi, i have setup a new multimaster with mirrormode = true cluster with Debian 9 and openldap 2.4.44. There are two Servers ldap1 and ldap2. As its just a lab Environment there is no need to hide passwords and stuff: /etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 8fb04e78 dn: olcDatabase={1}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=localdomain olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * non e olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=localdomain" writ e by self write by * read olcAccess: {2}to attrs=shadowLastChange by self write by * read olcAccess: {3}to * by * read olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by anonym ous auth by dn="cn=admin,dc=localdomain" write by dn="cn=mirrormode,dc=loca ldomain" read by * none olcLastMod: TRUE olcRootDN: cn=admin,dc=localdomain olcRootPW:: e1NTSEF9Z05GbEJIRHE1aTNpa0ZsYVk0WVh3VTM4SkF0VkF0b3Q= olcDbCheckpoint: 512 30 olcDbIndex: member,memberUid eq olcDbIndex: cn pres,sub,eq olcDbIndex: uid pres,sub,eq olcDbIndex: displayName pres,sub,eq olcDbIndex: default sub olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: mail,givenName eq,subinitial olcDbIndex: dc eq olcDbIndex: objectClass,entryCSN,entryUUID eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: e9f1dcca-5978-1037-8f17-b1d4dc2a991d creatorsName: cn=admin,cn=config createTimestamp: 20171109090544Z olcMirrorMode: TRUE olcSyncrepl: {0}rid=001 provider=ldap://10.211.55.20:389 bindmethod=simple b inddn="cn=mirrormode,dc=localdomain" credentials=iechi1Eid_ie:quu searchbas e="dc=localdomain" schemachecking=on type=refreshAndPersist retry="60 +" entryCSN: 20171109101419.176516Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20171109101419Z Here is my Database, its on both ldap servers identical - i dumped this on both servers and ran a diff slapcat: dn: dc=localdomain objectClass: top objectClass: dcObject objectClass: organization o: localdomain dc: localdomain structuralObjectClass: organization creatorsName: cn=admin,dc=localdomain entryUUID: 1854fd30-597f-1037-9872-eb46faf4f5e0 createTimestamp: 20171109094959Z entryCSN: 20171109094959.802699Z#000000#000#000000 modifiersName: cn=admin,dc=localdomain modifyTimestamp: 20171109094959Z contextCSN: 20171109100725.365127Z#000000#000#000000 dn: cn=admin,dc=localdomain objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9Z05GbEJIRHE1aTNpa0ZsYVk0WVh3VTM4SkF0VkF0b3Q= structuralObjectClass: organizationalRole entryUUID: e9f75c72-5978-1037-8289-d381257e6532 creatorsName: cn=admin,dc=localdomain createTimestamp: 20171109090545Z entryCSN: 20171109090545.033599Z#000000#000#000000 modifiersName: cn=admin,dc=localdomain modifyTimestamp: 20171109090545Z dn: cn=mirrormode,dc=localdomain objectClass: simpleSecurityObject objectClass: organizationalRole cn: mirrormode description: Syncrepl user for mirrormode operation structuralObjectClass: organizationalRole entryUUID: 49734c42-5979-1037-9e9b-d338d82a2242 creatorsName: cn=admin,dc=localdomain createTimestamp: 20171109090825Z userPassword:: e1NTSEF9T3hzeUVnanhLTThZSDJjK3JweG1sM2pWOG5USEkwS1c= entryCSN: 20171109100725.365127Z#000000#000#000000 modifiersName: cn=admin,dc=localdomain modifyTimestamp: 20171109100725Z And this is the error i get only on ldap1 after setting up replication on both servers: Nov 9 12:36:16 ldap1 slapd[17296]: Entry (cn=admin,dc=localdomain): object class 'simpleSecurityObject' requires attribute 'userPassword' Nov 9 12:36:16 ldap1 slapd[17296]: null_callback : error code 0x41 Nov 9 12:36:16 ldap1 slapd[17296]: syncrepl_entry: rid=001 be_add cn=admin,dc=localdomain failed (65) Nov 9 12:36:16 ldap1 slapd[17296]: do_syncrepl: rid=001 rc 65 retrying Any Ideas how could solve this? Best regards Dennis

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