openldap-technical

openldap-technical@openldap.org

13 participants
9906 discussions

ACL - grant access to subtree by regex
by Ole 29 Jun '13

29 Jun '13

Hi, I'm really new to OpenLDAP and try to grant domain-admins access to their domain-subtree in our historicaly grown LDAP Structure. The Structure is like this: ou=somedomain.tld,ou=mail,dc=example,dc=tld ou=admins,ou=somedomain.tld,ou=mail,dc=example,dc=tld cn=admin(a)somedomain.tld,ou=admins,ou=somedomain.tld,ou=mail,dc=example,dc=tld The ACL I try to use (according to [1]) is: access to dn.regex=".+,ou=([^,]+),ou=mail,dc=example,dc=tld$" by dn.onelevel,expand="ou=admins,ou=$1,ou=mail,dc=example,dc=tld" write by * break but it doesn't take effect. After hours of thinking about the problem and searching in the internet I still can't get the poit. Thank you for reading, Ole [1] http://www.openldap.org/faq/data/cache/973.html

2 4

Types of Groups, Structural objects and Inheritance
by Brendan Kearney 29 Jun '13

29 Jun '13

list members, As a caveat to my ACLs, most of my groups are the posixGroup class. from what i understand, that means i need to use set ACLs, instead of group ACLs. this does not seem to be a big deal, and is covered in the admin guide. that being said, i am looking to find out what the functional differences between a posixGroup and groupOfNames are? are there significant reasons to use one over the other? in my environment, i have the ability to recreate all the posixGroup objects as groupOfNames objects, if it would help with the creation of ACLs and other work to be done. is that a worthwhile effort? In my searching, i have found an explicit reason to keep using the posixGroup type, as NFSv4 ACLs can only use posixGroup types of groups. the dependency is because of the use of memberUid attributes. would there be any other explicit reasons to use one group type over another? my users have inetOrgPerson as their structural class, and as such i cannot add the NFSv4RemotePerson class to their list of objectClass attributes. the NFSv4RemotePerson class is structural as well. i have heard about the ability to create a hierarchy of objectClass objects so that an object can inherit the properties of all the SUP classes. is there a way i can create this hierarchy to allow multiple structural class attributes to be inherited by user objects? i have not found much info around doing this. are there any pointers? thanks in advance, brendan

3 3

Openldap-2.4.35 TLS/SSl
by Darouichi, Aziz 29 Jun '13

29 Jun '13

Hi, I am trying to configure TLS/SSL and I have a Cert from Geotrust . I configure slapd.conf with the followings: # TLS/SSL information # TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /opt/local/etc/openldap/GeoTrust_Global_CA.cer TLSCertificateFile /opt/local/etc/openldap/rhea.curry.edu.pem.cer TLSCertificateKeyFile /opt/local/etc/openldap/rhea.key.pem But when I check the cert using "openssl s_client -connect 192.168.60.43:636 -CApath /opt/local/etc/openldap/" I get CONNECTED(00000003) 140230373582504:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 321 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE I checked the log I see TLS connection

3 2

LB health check during syncrepl refresh
by Michael Ströder 28 Jun '13

28 Jun '13

HI! Inspired by ITS#7616 and looking at our monitoring: If I bring up a syncrepl consumer with empty DB it seems contextCSN attribute is missing in DB base entry during refresh phase. This is nice because we could use that in the load-balancer health check to prevent clients to connect to this replica until all data is loaded into the consumer and contextCSN is present. So is it guaranteed that contextCSN is missing during lengthy refresh phase? Ciao, Michael.

2 1

Unable to edit cn=config
by Michael Roth 28 Jun '13

28 Jun '13

Hello openldap masters, I have a big issue and I'm praying someone can help me Am I able to change the ACL so I can edit cn=config to load a module in? If so how do I do that? How I setup my working LDAP with the script here: http://www.ghacks.net/2010/08/31/set-up-your-ldap-server-on-ubuntu-10-04/ I'm now using Ubuntu 12.04 Server x64 Working on this module here: http://raerek.blogspot.com/2012/06/sync-ldap-and-samba-passwords-using.html When I load changes into LDAP I'm denied. $ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f smbkrb5pwd_load.ldif modifying entry "cn=module{0},cn=config" ldap_modify: Insufficient access (50) $ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f smbkrb5pwd_load.ldif ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: $ ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase=hdb olcAccess Enter LDAP Password: dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=domain,dc=net" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=domain,dc=net" write by * read Regards, ~Mike

2 6

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 27 Jun '13

27 Jun '13

2 1

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

27 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 27 Jun '13

27 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 27 Jun '13

27 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical