openldap-technical

openldap-technical@openldap.org

12 participants
9794 discussions

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 14 Nov '17

14 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 14 Nov '17

14 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

Re: disk write on old 2.4.9
by Howard Chu 08 Nov '17

08 Nov '17

richard lucassen wrote: > On Wed, 8 Nov 2017 11:35:40 +0100 > richard lucassen <mailinglists(a)lucassen.org> wrote: > >> Is there a way to limit these disk writes? I didn't touch the standard >> Ubuntu settings, except for the usual settings like SSL. > > I found an old setting that seems to do the job: > > shm_key 100 > > In that old setting it was set to 100, the man page says: > > shm_key _integer_ > Specify a key for a shared memory BDB environment. By default the BDB > environment uses memory mapped files. If a non-zero value is > specified, it will be used as the key to identify a shared memory > region that will house the environment. > > Is that integer a sort of label or does it mean something else? It means what it says - it is a shared memory key. Read the ipcs(1) manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

disk write on old 2.4.9
by richard lucassen 08 Nov '17

08 Nov '17

Hello list, I have an ***old*** Ubuntu-8.04 running 2.4.9. I know, this is old, but there are no security issues here. This slapd contains a small database which is modified rarely. OTOH, there are many read operations. The backend is hdb. As these boxes are running on a CF-disk I'd like to limit disk writes, but when the database is queried, the backend is being updated (slapd started at 11:25, read operation at 11:31): # ls -altr /var/lib/ldap/ total 768 drwxr-xr-x 3 root root 4096 2013-11-11 20:28 .. -rw-r--r-- 1 openldap openldap 96 2017-11-08 09:36 DB_CONFIG -rw------- 1 openldap openldap 8192 2017-11-08 11:25 objectClass.bdb -rw------- 1 openldap openldap 8192 2017-11-08 11:25 dn2id.bdb -rw------- 1 openldap openldap 123193 2017-11-08 11:25 log.0000000001 -rw------- 1 openldap openldap 65536 2017-11-08 11:25 id2entry.bdb drwx------ 2 openldap openldap 4096 2017-11-08 11:25 . -rw-r--r-- 1 openldap openldap 2048 2017-11-08 11:25 alock -rw------- 1 openldap openldap 24576 2017-11-08 11:31 __db.005 -rw------- 1 openldap openldap 565248 2017-11-08 11:31 __db.004 -rw------- 1 openldap openldap 98304 2017-11-08 11:31 __db.003 -rw------- 1 openldap openldap 2629632 2017-11-08 11:31 __db.002 -rw------- 1 openldap openldap 8192 2017-11-08 11:31 __db.001 Is there a way to limit these disk writes? I didn't touch the standard Ubuntu settings, except for the usual settings like SSL. Richard. -- richard lucassen http://contact.xaq.nl/

1 1

Re: NO-USER-MODIFICATION and USAGE dSAOperation in custom schema
by Howard Chu 06 Nov '17

06 Nov '17

Michael Ströder wrote: > HI! > > Why is it not allowed to use > > NO-USER-MODIFICATION > USAGE dSAOperation > > in an attribute type declaration? Because such an operational attribute requires server-side code to actually implement it, and you haven't got any means to provide that code. Custom operational attributes must be defined using code loaded in a module. > > For OATH-LDAP I'd like to define a "virtual" attribute (actually to be > processed by back-sock listener) without having to write a slapd overlay. > > attributetype ( oath-ldap-at:16 > NAME 'oathOTPValue' > DESC 'OATH-LDAP: currently valid OTP value of a token' > X-ORIGIN 'OATH-LDAP' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > EQUALITY integerMatch > SINGLE-VALUE ) > NO-USER-MODIFICATION > USAGE dSAOperation ) > > But slapd refuses to start: > > 5a00641b /home/michael/Proj/oath-ldap/oath-ldap.schema: line 241 > (attributetype ( oath-ldap-at:16 NAME 'oathOTPValue' DESC 'OATH-LDAP: > currently valid OTP value of a token or associated user entry (not > directly used)' X-ORIGIN 'OATH-LDAP' SYNTAX > 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE > NO-USER-MODIFICATION USAGE dSAOperation )) > 5a00641b /home/michael/Proj/oath-ldap/oath-ldap.schema: line 241 > attributetype: "oath-ldap-at:16" is operational > > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical