openldap-technical January 2017

openldap-technical@openldap.org

47 participants
80 discussions

fresh (distro's) installation and cn=config password
by lejeczek 24 Jan '17

24 Jan '17

hi everybody, this must be one of the most ancient questions - but browsing (centos') local docs reveal nothing. I'd imagine passwords is that first & most important thing everybody does to make sure slapd is secured, something like "mysql_secure_installation" I'm trying to do something I'd think is simple and should just work, but, I'm wrong, so I do: slapadd -v -n0 <<EOL dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW:: exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx EOL and I get in return: slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed So that question - how does one secure ldap installation? But I'd insist on not referring something like "slaptest and convert old school to ..." or .. edit config file(s) What I think is - I have a clean installation which is configured in probably best possible way but missing is: olcRootDN, olcRootPW How to use slapadd for it? Is slapadd not the right tool for this? many thanks, L.

3 2

MDB map size = maxsize ?
by Tamás Rébeli-Szabó 24 Jan '17

24 Jan '17

Hello, we are using 2.4.41, and have run into MDB_MAP_FULL: Environment mapsize limit reached(-30792) " Checking database size we see: [openldap@soa-srv]$ grep maxsize slapd.conf maxsize 4294967296 [openldap@soa-srv]$ mdb_stat -e openldap-data Environment Info Map address: (nil) Map size: 1073741824 I was under the impression that maxsize is the same as map size. However, map size here is 1GB, whereas maxsize is 4GB, even after slapd is restarted. Why this apparent discrepancy? Thanks, tamas

2 1

Re: use proprietary password hash in "userpassword"
by Meike Stone 24 Jan '17

24 Jan '17

>> I don't have to recompile the whole openldap, compiling the module is >> sufficient? >> >> (1) we think about a subscription from symas ... > > > Correct. Any distributor (symas included) should include a development > package that allows the ability to rebuild a module without rebuilding > everything. > Ah, ok - it works :-D If I use a own compiled module and I bought a gold subscription, does Symas still give full support? Thanks Meike

1 0

Re: fresh (distro's) installation and cn=config password
by Ulrich Windl 24 Jan '17

24 Jan '17

(Copy for the list) >>> Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> schrieb am 24.01.2017 um 13:19 in Nachricht <58875475.ED38.00A1.0(a)rz.uni-regensburg.de>: >>>> lejeczek <peljasz(a)yahoo.co.uk> schrieb am 23.01.2017 um 17:59 in Nachricht > <ff479edd-d352-2357-9275-9a66ed520be0(a)yahoo.co.uk>: > > hi everybody, > > this must be one of the most ancient questions - but > > browsing (centos') local docs reveal nothing. > > I'd imagine passwords is that first & most important thing > > everybody does to make sure slapd is secured, something like > > "mysql_secure_installation" > > > > I'm trying to do something I'd think is simple and should > > just work, but, I'm wrong, so I do: > > > > slapadd -v -n0 <<EOL > > dn: olcDatabase={0}config,cn=config > > objectClass: olcDatabaseConfig > > olcDatabase: {0}config > > > > olcRootDN: cn=admin,cn=config > > olcRootPW:: exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > EOL > > > > and I get in return: > > slapadd: could not add entry > > dn="olcDatabase={0}config,cn=config" (line=1): autocreation > > of "olcDatabase={-1}frontend" failed > > What about: > dn: cn=config > objectClass: olcGlobal > cn: config > [...] > dn: cn=schema,cn=config > objectClass: olcSchemaConfig > cn: schema > [...] > dn: olcDatabase={-1}frontend,cn=config > objectClass: olcDatabaseConfig > olcAccess: ... > [...] > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: ... > [...] > olcRootDN: cn=config > olcRootPW: {SSHA}... > > Regards, > Ulrich > > > > > So that question - how does one secure ldap installation? > > But I'd insist on not referring something like "slaptest and > > convert old school to ..." or .. edit config file(s) > > What I think is - I have a clean installation which is > > configured in probably best possible way but missing is: > > olcRootDN, olcRootPW > > How to use slapadd for it? Is slapadd not the right tool for > > this? > > > > many thanks, > > L. > > > >

1 0

Re: openldap slowness after restoration
by Quanah Gibson-Mount 23 Jan '17

23 Jan '17

--On Thursday, January 19, 2017 2:43 PM +0530 PRATIK SINGAL <pratik.singal13(a)gmail.com> wrote: > > Hello all, > > > After performing restoration the openldap server is performing slow. > > > openldap 2.4.40 with bdb. > > > Can any one suggest me on what to check which might cause the slowness. Using bdb will certainly cause slowness. I would note that to tune BDB is generally a dark art. You would be better served running a current version of OpenLDAP and using the back-mdb backend, which does not require fine tuning to be performant. Overall, you do not provide any of the necessary information to really provide any type of useful information on how to proceed. What does "slowness" even mean? I.e., how are you measuring "slowness" and where/how are you seeing it? Have you set up a DB_CONFIG file for BDB that is appropriate for your deployment? Have you tuned the various bits in slapd that's necessary on top of DB_CONFIG to correctly run a system with a BDB based backend? etc. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: use proprietary password hash in "userpassword"
by Quanah Gibson-Mount 23 Jan '17

23 Jan '17

--On Monday, January 23, 2017 10:45 AM +0100 Meike Stone <meike.stone(a)googlemail.com> wrote: > 2017-01-19 12:31 GMT+01:00 Howard Chu <hyc(a)symas.com>: >> Meike Stone wrote: >>> > >>> Write a openldap modul like pw-sha2 is not the first choice, because >>> we need to compile the openldap after each update on our own and that >>> prevents us to use the distribution packages. >> >> >> Writing an OpenLDAP module like pw-sha2 is precisely the way to write a >> small external binary to validate passwords. >> >> There's no need to recompile all of OpenLDAP just to update a password >> module. > > If I use the binary openldap package from the distributor (*1), and I > like to use a own module, > I don't have to recompile the whole openldap, compiling the module is > sufficient? > > (1) we think about a subscription from symas ... Correct. Any distributor (symas included) should include a development package that allows the ability to rebuild a module without rebuilding everything. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ContextCSN values in 3-multimaster setup
by Quanah Gibson-Mount 23 Jan '17

23 Jan '17

--On Thursday, January 19, 2017 3:36 PM +0100 Marc Franquesa <mark(a)l3jane.net> wrote: >> I can assume some downtime and be in safe place. My idea was to proceed > as follows: > > - Take slapcat Backup of all DITs (including cn=config) > - Remove any contextCSN attribute from the resulting LDIFs > - Stop all 3 servers > - Remove entirely the DBs on the servers > - Do a slapadd of the previous LDIFs > - Start servers again (so re-replicating again with new contextCSN, now > corret). > > Should that work ? even for cn=config DB ? That will not work. As I explained previously, the contextCSN values are generated from the entryCSN values in your database. Removing the contextCSN values will have no effect if there still exist entries in your database with an entryCSN of serverID's you have since gotten rid of. There is also no point in dumping cn=config and doing any work on it, as it clearly has the correct values (as per your later data). > Also to further confuse a bit more the scenario, today I realized that > a new contextCSN appeared: > > dn: dc=l3jane,dc=net > contextCSN: 20170111084028.692133Z#000000#001#000000 > contextCSN: 20170118224410.110554Z#000000#003#000000 > contextCSN: 20161228225757.121969Z#000000#004#000000 > contextCSN: 20160201102250.543748Z#000000#005#000000 > contextCSN: 20150917152138.054326Z#000000#006#000000 That would mean a modification came in from a serverID where previously there had been no modifications from that serverID. > Also the explanation that conextCSN attribute is = > contextCSN#rid#sid#000000 seem not correct as I have rids 001, 002 and > 003, and serverIds 1,2,3 so none of this matches with my results. I'm not clear what you mean. Your results clearly show that in the course of time you have had servers with serverIDs of 1, 3, 4, 5, and 6 that have received modifications. A contextCSN for a given SID will *only* show up if a modification was ever performed on the server with that given SID (thus causing an entryCSN value to be generated for that SID). > But I get this contextCSN values: > > dn: cn=config > contextCSN: 20170111084531.247823Z#000000#001#000000 > contextCSN: 20161230165409.486624Z#000000#003#000000 > > Si I'm missing one contextCSN? (there are 3 providers) ? No. See above. ># ldapsearch -LLL -x -s base contextCSN > dn: dc=l3jane,dc=net > contextCSN: 20170111084028.692133Z#000000#001#000000 > contextCSN: 20170118224410.110554Z#000000#003#000000 > contextCSN: 20161228225757.121969Z#000000#004#000000 > contextCSN: 20160201102250.543748Z#000000#005#000000 > contextCSN: 20150917152138.054326Z#000000#006#000000 See above. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

using two password hashes
by Meike Stone 23 Jan '17

23 Jan '17

Hello, the userPassword is a multivalued attribute. If there are set two values with different schemes, how will openldap handle the request? Will only checked one password and if it is wrong, the access will be declined or will openldap proceed to the second password hash? If both userPassword schemes differs, which one will be used first? Is the handling configurable? thank you Meike

1 0

Permission issue for normal user with ldap_add
by vvv jjj 23 Jan '17

23 Jan '17

Hi OpenLDAP team, I'm new to openLDAP. So this could be a trivial question, please let me know if I missed anything. I'm trying to add entries to "dc=example,dc=com" using ldap_add. It is working fine for super user (root), but we are getting permission error for normal user (non root). I'm able to update with ldap_modify for normal user. Could you please let me know how can we give permissions to any specific user to add entries using ldap_add. Thanks in advance. Regards J.Visu

4 3

Deleting an user defined object class from openldap 2.4.40
by Tamer Ataol 23 Jan '17

23 Jan '17

Hi, I used the below ldif file to add a user defined objectclass in my openldap 2.4.40 on CentOS 7. ----------------------------------------------------------------------- dn: cn={12}ng911,cn=schema,cn=config changetype: add objectClass: olcSchemaConfig cn: ng911 dn: cn={12}ng911,cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.4.1.6.8.12 NAME 'cityCode' DESC 'city plate' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.4.1.6.8.14 NAME 'identityNumber' DESC 'id number' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.4.1.6.8.16 NAME 'institutionName' DESC 'institution name' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.4.1.6.8.18 NAME 'phoneNumber' DESC 'phone' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.4.1.6.8.20 NAME 'agentId' DESC 'agent id' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.4.1.6.8.22 NAME 'agentPassword' DESC 'agent passwd' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.4203.1.1.2 ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.42.2.27.4.3.6 NAME 'ng911' DESC 'Container for ng911 object' SUP inetOrgPerson MAY ( cityCode $ identityNumber $ institutionName $ phoneNumber & agentId & agentPassword ) ) ----------------------------------------------------------------- And then I run the command on the server ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f extendtong911.ldif The addition was ok. But I made a mistake and run the same command again which added another copy of the objectclass. The result of the command below is given underneath it ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config cn ----------------------------------------------------------------- dn: cn=schema,cn=config cn: schema dn: cn={0}core,cn=schema,cn=config cn: {0}core dn: cn={1}cosine,cn=schema,cn=config cn: {1}cosine dn: cn={2}nis,cn=schema,cn=config cn: {2}nis dn: cn={3}inetorgperson,cn=schema,cn=config cn: {3}inetorgperson dn: cn={4}ng911,cn=schema,cn=config cn: {4}ng911 cn: {12}ng911 dn: cn={5}ng911,cn=schema,cn=config cn: {5}ng911 cn: {12}ng911 ----------------------------------------------------------------- Now, I want to delete the second objectclass created. For this I created an ldif file with the contents as below: ----------------------------------------------------------------- dn: cn={5}ng911,cn=schema,cn=config changetype: modify delete: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.42.2.27.4.3.6 NAME 'ng911' DESC 'Container for ng911 object' SUP inetOrgPerson MAY ( cityCode $ identityNumber $ institutionName $ phoneNumber & agentId & agentPassword ) ) ----------------------------------------------------------------- And I run the command ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f deleteng911.ldif on the server. The result is: ----------------------------------------------------------------- modifying entry "cn={5}ng911,cn=schema,cn=config" ldap_modify: No such attribute (16) additional info: modify/delete: olcObjectClasses: no such attribute ----------------------------------------------------------------- When I change {5} to {12} I get ----------------------------------------------------------------- modifying entry "cn={12}ng911,cn=schema,cn=config" ldap_modify: No such object (32) matched DN: cn=schema,cn=config ----------------------------------------------------------------- I tried many modifications of the ldif file but couldn't succeed. Can you help me writing the right ldif file for deletion of an objectclass? Thanks. Tamer

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2017