openldap-technical June 2013

openldap-technical@openldap.org

58 participants
71 discussions

MDB resizing
by Liam Gretton 28 Jun '13

28 Jun '13

I'm evaluating upgrading our LDAP services and moving from hdb to mdb. I don't seem to be able to get my MDB database to resize by changing the value of maxsize, whether increasing it or decreasing it. I'm using slapd.conf, so changes to the config require a restart. Looking at debug output when slapd starts I can see that the new value of maxsize is being read. If I delete the database and rebuild with slapadd then it's created with the new size. I see there was an ITS#7471 reporting a similar issue, but this was apparently fixed in 2.4.34 (if that's what RE24 is) - I'm using 2.4.35. In my config maxsize is the only MDB setting I've used, everything else will be using default values. Should it be possible to resize MDB this way? I haven't been able to track down much information about resizing beyond the issue report mentioned above. In practice I expect it's something that I'll rarely (if ever) have to do, but I'd like to at least understand what I should be able to do. -- Liam Gretton liam.gretton(a)le.ac.uk Systems Specialist http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

1 0

Controlling access to users
by Mathew Wilson 28 Jun '13

28 Jun '13

2 1

Groups, Nesting and Access
by Brendan Kearney 28 Jun '13

28 Jun '13

list members, i am looking to have a group "LDAP Engineers" and "LDAP Admins" configured, with the engineers group a member of the admin group. i have a feeling ACLs will need to be adjusted for this. the engineer role will have full read/write access to cn=config. the access granted to cn=config should not include access to the DIT by default. the membership in the admin group should be used to grant this access. think more than one database, and not every engineer will be an admin for every database. essentially, engineers can modify base level configs in slapd, add/load schemas, add/load modules, create new databases, add/modify/delete ACLs, etc. these will be the ldap gurus. the admin roll will have full read/write access to the database the dc=bpk2,dc=com tree is in, only. essentially, admins can add/modify/delete the objects in the DIT. these will be the ldap support staff. because the engineers can be members of this group, they will inherit the access to the DIT. acls will need to be constructed for this separation of duty. the default access granted to the root id by the below might need to be modified or additions made to the ACL list: olcAccess: {0}to * by dn.base="gidNumber=0 +uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none since this applies to the base, the engineer role should get this access, too. does the above ACL grant access to more than just the cn=config? how can the engineer role be limited to only the cn=config, and not the database(s) that would have DITs in them? the database for the DIT, where dc=bpk2,dc=com resides has the below ACLs. what ACLs are needed to give the admin role full read/write access to the database only? i would imagine those ACLs need to be above the ones listed, so that the admins can modify the same settings the users are allowed to modify. olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by * none olcAccess: {1}to attrs=loginShell by self write by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to dn.subtree="dc=bpk2,dc=com" by dn="cn=adm-srv,dc=bpk2,dc=com" write by dn="cn=kdc-srv,dc=bpk2,dc=com" read by * none also, i have read that users should not be able to modify their own uid and gid attributes. how does one construct ACLs that grant users the ability to modify specific attributes, but not others? what are the attributes that users should not be able to modify? i would think those are fewer in total #s than the ones that the users should be able to modify. with that theory, how is an ACL constructed so that all attributes, except for those few, can be modified by the user? is there some "negated" logic that can be used in ACLs? i have read the "man slapd.access" page, and ACLs are still a bit of voodoo for me. i have to get more comfortable with them, but would like some pointers to get me going. thanks in advance, brendan

1 0

IDs, RootDN and replication
by Brendan Kearney 28 Jun '13

28 Jun '13

list members, i have separate olcRootDN's for cn=config and for dc=bpk2,dc=com (cn=config and cn=Manager,dc=bpk2,dc=com respectively) configured in slapd. i would like to change this so that the olcRootDN's are part of a DIT, and have their authentication managed via SASL or Kerberos. i am using the cn=config olcRootDN as the id for the n-way multimaster replication of both cn=config and olcDatabase for the hdb that has the dc=bpk2,dc=com tree in it. i believe the below will get the olcRootDN's confiured for an id contained in the DIT: ldapmodify -QY EXTERNAL -H ldapi:/// dn: cn=config changetype: modify delete: olcRootDN olcRootDN: cn=config - add: olcRootDN olcRootDN: uid=root,cn=bpk2.com,cn=gssapi,cn=auth - delete: olcRootPW - dn: olcDatabase={2}hdb,cn=config changetype: modify delete: olcRootDN olcRootDN: cn=Manager,dc=bpk2,dc=com - add: olcRootDN olcRootDN: uid=root,cn=bpk2.com,cn=gssapi,cn=auth - delete: olcRootPW - when performing the delete action, do i need to do both "delete: olcRootDN", and then specify "olcRootDN: cn=config"? since there is only one value, i would think it is unnecessary, but just want to check. what are best practices around using a RootDN ID contained in a DIT? i would imagine using "root" is something to avoid. what suggestions are there around the RootDN id? what about using the RootDN id as the id for replication, when the bind method is sasl and the saslmech is gssapi? should a different id be used for replication? i am using n-way multi master replication with credentials= specified in my configs. with the below, i plan to modify the id used to do the replication, as well as the authentication: ldapmodify -QY EXTERNAL -H ldapi:/// dn: cn=config changetype: modify delete: olcSyncrepl olcSyncrepl: {1} - delete: olcSyncrepl olcSyncrepl: {0} - add: olcSyncrepl olcSyncrepl: olcSyncrepl: {0}rid=001 provider=ldap://ldap1.bpk2.com binddn="replication_user" bind method=sasl saslmech=gssapi searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - olcSyncrepl: olcSyncrepl: {1}rid=002 provider=ldap://ldap2.bpk2.com binddn="replication_user" bind method=sasl saslmech=gssapi searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - dn: dc=bpk2,dc=com delete: olcSyncrepl olcSyncrepl: {1} - delete: olcSyncrepl olcSyncrepl: {0} - add: olcSyncrepl olcSyncrepl: olcSyncrepl: {0}rid=001 provider=ldap://ldap1.bpk2.com binddn="replication_user" bind method=sasl saslmech=gssapi searchbase="dc=bpk2,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 5" timeout=1 - olcSyncrepl: olcSyncrepl: {0}rid=002 provider=ldap://ldap2.bpk2.com binddn="replication_user" bind method=sasl saslmech=gssapi searchbase="dc=bpk2,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 5" timeout=1 - does the "replication_user" ID need to be user(a)domain.tld or in some other "qualified" format, or will just the id/name be ok? with the above config to use sasl auth for replication, do i need to run k5start for the tickets to be maintained for the replication_user? i dont want to use authcid or authzid because of the requirement of the credentials being in the config. i want no password to be in the configs. from what i find, k5start is needed. thanks in advance, brendan

1 0

Simple bind error
by Darouichi, Aziz 28 Jun '13

28 Jun '13

Hi, I am trying to use softerra to connect to a local openldap-2.4.34 using Simple Bind, after I enter the password and BasDn info. I get Invalid credentials. Any help or debug this issue will be great. Thank you, Aziz

2 2

Question regarding authentication
by Jason Voorhees 27 Jun '13

27 Jun '13

Hi: I have a doubt about how OS level authentication against an LDAP server could work, so I hope someone can point me to a solution. If I have a lot of users in a Linux box with a common prefix in its usernames like these: - prejvoorhees - premjackson - presjobs - prebgates - pretcruise ... ... As you can see, all these have the prefix "pre" before it's real username (jvoorhees, mjackson, sjobs, bgates, tcruis, etc...). I also have an OpenLDAP server with a users directory tree whose usernames are the same but without "pre", I mean they are jvoorhees, mjackson, sjobs, bgates, tcruis, etc.... So what I'd like to do if configure my Linux box (ldap client) so it can authenticate against the OpenLDAP server in this way: - username prebgates authenticates with bgates in LDAP server. - username pretcruise authenticates with tcruise in LDAP server. - username prejvoorhees authenticates with jvoorhees in LDAP server. ... ... Is this possible to do? Can I make a rule to supress the "pre" prefix before authentication against LDAP? If yes, where should I make this "rule": in the Linux box (ldap client) or in the LDAP Server? I hope someone has any idea about this topic. THanks in advance. Bye

2 2

Issue with LDAPVerifyServerCert flag.
by Mangesh Sawant 27 Jun '13

27 Jun '13

If in LDAP client, LDAPVerifyServerCert is enabled in SSL , authentication fails with Message simple bind failed. If LDAPVerifyServerCert is disabled in SSL there is no issue. LDAP server is OpenLdap. What configuration w.r.t LDAP/SSL I need to check so that authentication succeeds with LDAPVerifyServerCertflag ON. -- Thanks And Regards , Mangesh Sawant .

1 0

(no subject)
by Ben Johnson 27 Jun '13

27 Jun '13

I posted this to openldap-bugs but I didn't see it actually posted to the archive so I'll try in openldap-technical. I have LMDB integrated and it's working smoothly except for this issue. ---- Original Message ---- I'm an author of an open source database called Sky (http://skydb.io/) and I'm interested in porting the backend off LevelDB and move it over to LMDB. I pulled down the LMDB code using the instructions on Ferenc Szalai's gomdb (https://github.com/szferi/gomdb) README: git clone -b mdb.master --single-branch git://git.openldap.org/openldap.git When I ran "make test" against the code it seems to run through most of the tests but I get a "Resource Busy" error at one point. Here's the full output: https://gist.github.com/benbjohnson/5628725 I'm running Mac OS X 10.8.3 and here's the output of my gcc -v: $ gcc -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Let me know if you need any other info from me. Ben Johnson ben(a)skylandlabs.com Ben Johnson ben(a)skylandlabs.com

5 11

rootdn password change
by Darouichi, Aziz 26 Jun '13

26 Jun '13

Hi all, I compiled Openldap-2.4.35 with TLS/SSL support and have not configured certs yet. But I am trying to change/encrypt rootdn password using the following /opt/local/bin/ldappasswd -h {SSHA} and I am getting ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1). I checked host file and server DNS name has been added....!!!! Thank you for the help Aziz

2 1

Question on assigning a new user with admin role
by Kumar, Amit 26 Jun '13

26 Jun '13

Hi, I have little experience with managing LDAP servers. Previously with just one file slapd.conf it was lot easier to assign a user a role of an admin, just by giving access to attrs=...by With newer version of openldap-servers-2.4.23-26 on RHEL 6.x this is not the same, and hope you can help me understand this to assign access to user to be able to manage the directory. So I began giving access to attrs=userPassword by self write by dn="NEW USER DN ...." write by * auth ...similarly I did this for all attributes I wanted this user to manage. I made the above changes in my slapd.conf, but this does not allow the new user to manage the directory, he is just like any other user who can browse but not write to it. What more do I need to do? Best, Amit

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2013