openldap-technical

openldap-technical@openldap.org

20 participants
9802 discussions

OLC configuration
by Jacques Foucry 28 Nov '13

28 Nov '13

Hello folks, I think I can use and manage a small LDAP. I can configure it but... with the old slapd.conf method. I need to configue a new one and it's time for me to understand the OLC configuration way. Did you have a good tuto (in french?) to help to help me? The official docs are to hard for me. Thanks in advance, Jacques Foucry -- Jacques Foucry *NOVΛSPARKS * IT Manager Tel : +33 (0)1 42 68 12 61 jacques.foucry(a)novasparks.com

2 1

p12 files for user-auth in slapd.conf question
by lux-integ 28 Nov '13

28 Nov '13

Greetings, I am a complete beginner leaning to use openldap. I read through a few of the manuals online. I am finding the access-control manual ( http://www.openldap.org/doc/admin24/access-control.html ) the hardest to understand. I would like to know if it is possible to authenticate users using p12 (pkcs12 certificates/key pair ) and IF SO what would be a) the standard shemas to be included in slapd.conf to make this possible ? , b) the entry for olcAccess ( in slapd.conf) for users to be authenticared via their p12 files ? , b) the location and storage method in the database for these .p12 files ? or IF NOT SO what is the recommended equivalent to p12 files and how would they be deployed.? thanks in advance sincerely luxInteg

2 1

OpenLDAP with ppolicy and SSSD configuration question.
by Viviano, Brad 28 Nov '13

28 Nov '13

Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login. The specifics are. sshd_config is configured to use PAM. My pam.d auth config is standard for RHEL6 which is: auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so I've confirmed that when a user logs in from ssh with both password and ssh keys, they are going through the PAM sss.so just fine, by turning up the debugging levels and watching the logs. I've read everything I can find on sssd and it appears that for all cases of LDAP, sssd wants a single true/false value along the lines of nsAccountLocked. I can't find anything in ppolicy that sets true/false for account locked like other LDAP implementations do, all ppolicy seems to provide is pwdAccountLockedTime. While the issue seems more like a limitation on sssd's side, I thought I'd ask on this list to see if anyone has been able to come up with a solution or if there is something in ppolicy I am missing for a true/false on, is DN=X locked or not. Thanks, -Brad Viviano =================================================== Brad Viviano High Performance Computing & Scientific Visualization Lockheed Martin, Supporting the EPA Research Triangle Park, NC 919-541-2696 HSCSS Task Order Lead - Ravi Nair 919-541-5467 - Nair.Ravi(a)epa.gov High Performance Computing Subtask Lead - Durward Jones 919-541-5043 - Jones.Durward(a)epa.gov Environmental Modeling and Visualization Lead - Heidi Paulsen 919-541-1834 - Paulsen.Heidi(a)epa.gov

7 24

Q: monitoring attributes
by Ulrich Windl 28 Nov '13

28 Nov '13

Hi! I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree. Seeing those operational atributes, I noticed that "creatorsName" and "modifiersName" are both present but have an empty value. That doesn't look very nice, especially as createTimestamp and modifyTimestamp do have proper values. Using monitoredObject for all monitored values gives a unique interface, but having all possible results in monitoredInfo is not very usable, especially if there's no description. For example (some attributes removed for brevity): --- dn: cn=Uptime,cn=Time,cn=Monitor structuralObjectClass: monitoredObject monitoredInfo: 153543 hasSubordinates: FALSE --- It's not clear (denying the obvious) what the units of uptime are: seconds, minutes, etc. It seems to me that "monitoredType" or "monitoredInfoType" and "monitoredUnit" (for measurable infos) are missing. Shouldn't "monitorCounter" be named "monitoredCounter" to use the same pattern as "monitoredInfo"? I could not find the schema for the monitoring objects in any file. Can I retrieve a readable schema from openLDAP? The other thing is that I'm not too happy with are spaces in RDNs, like " cn=Connection 2111,cn=Connections,cn=Monitor", or "cn=Database 2,cn=Databases,cn=Monitor". I'd prefer are more common pattern for IDs like "Connection-2111" or "Connection_2111". Also: is "cn=Connection 0,cn=Connections,cn=Monitor" a bug? I see it twice: --- dn: cn=Connection 0,cn=Connections,cn=Monitor structuralObjectClass: monitorConnection (...) monitorConnectionNumber: 0 monitorConnectionProtocol: 0 monitorConnectionOpsReceived: 0 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 0 monitorConnectionGet: 0 monitorConnectionRead: 0 monitorConnectionWrite: 0 monitorConnectionMask: L monitorConnectionListener: monitorConnectionPeerDomain: unknown monitorConnectionPeerAddress: unknown monitorConnectionLocalAddress: monitorConnectionStartTime: 19700101000000Z monitorConnectionActivityTime: 19700101000000Z (...) --- Regards, Ulrich

4 10

Problem with self in acl in combination with rwm
by Arthur de Jong 27 Nov '13

27 Nov '13

I have a configuration somewhat similar to the one below and the ACLs seem to be applied using the non-rewritten DN which causes the self specifier to never match. We are in the process of configuring a more secure LDAP server with stricter ACLs and extra security checks without affecting existing applications. For this purpose we are putting a rewriting proxy in front of several legacy LDAP servers. Ideally, the ACLs would be put in place on the original servers but this is not easily possible in this environment. Is this a bug or am I doing something wrong? Configuration snippet (simplified and anonymised): access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self read by * search database ldap suffix "ou=department1,dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" subordinate uri "ldap://192.168.1.1" overlay rwm rwm-suffixmassage "ou=department1,dc=example,dc=com" "dc=department1,dc=local" database ldap suffix "ou=department2,dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" subordinate uri "ldap://192.168.1.2" overlay rwm rwm-suffixmassage "ou=department2,dc=example,dc=com" "dc=department2,dc=local" database bdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}5OWnUtaKRBk7x0UBQKO/HOgMZQoCczY5 directory /var/openldap-data cachesize 1000 index objectClass eq index cn,mail pres,eq,sub index uid,uidNumber pres,eq Part of the slapd output with -d 896 (again, anonymised): 5295fbb1 conn=1000 fd=27 ACCEPT from IP=127.0.0.1:48903 (IP=0.0.0.0:3389) 5295fbb1 conn=1000 op=0 BIND dn="uid=ldaptest,ou=People,ou=department2,dc=example,dc=com" method=128 5295fbb1 conn=1000 op=0 BIND dn="uid=ldaptest,ou=People,dc=department2,dc=local" mech=SIMPLE ssf=0 5295fbb1 conn=1000 op=0 RESULT tag=97 err=0 text= 5295fbb1 conn=1000 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" 5295fbb1 => access_allowed: search access to "dc=example,dc=com" "entry" requested 5295fbb1 => dn: [1] 5295fbb1 => acl_get: [3] attr entry 5295fbb1 => acl_mask: access to entry "dc=example,dc=com", attr "entry" requested 5295fbb1 => acl_mask: to all values by "uid=ldaptest,ou=people,dc=department2,dc=local", (=0) 5295fbb1 <= check a_dn_pat: self 5295fbb1 <= check a_dn_pat: * 5295fbb1 <= acl_mask: [2] applying search(=scxd) (stop) 5295fbb1 <= acl_mask: [2] mask: search(=scxd) 5295fbb1 => slap_access_allowed: search access granted by search(=scxd) 5295fbb1 => access_allowed: search access granted by search(=scxd) [...] 5295fbb2 => access_allowed: read access to "uid=ldaptest,ou=People,ou=department2,dc=example,dc=com" "entry" requested 5295fbb2 => dn: [1] 5295fbb2 => acl_get: [3] attr entry 5295fbb2 => acl_mask: access to entry "uid=ldaptest,ou=People,ou=department2,dc=example,dc=com", attr "entry" requested 5295fbb2 => acl_mask: to all values by "uid=ldaptest,ou=people,dc=department2,dc=local", (=0) 5295fbb2 <= check a_dn_pat: self 5295fbb2 <= check a_dn_pat: * 5295fbb2 <= acl_mask: [2] applying search(=scxd) (stop) 5295fbb2 <= acl_mask: [2] mask: search(=scxd) 5295fbb2 => slap_access_allowed: read access denied by search(=scxd) 5295fbb2 => access_allowed: no more rules 5295fbb2 send_search_entry: conn 1000 access to entry (uid=ldaptest,ou=People,ou=department2,dc=example,dc=com) not allowed The DN that is used seems to be uid=ldaptest,ou=people, dc=department2,dc=local which is how we were bound to the second LDAP server. Thanks ps, I would also be very interested in a solution for http://www.openldap.org/lists/openldap-technical/201302/msg00152.html -- -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --

1 0

syncrepl
by Tony Chilton 27 Nov '13

27 Nov '13

I have set up a slave ldap server for syncrepl and seem to be unable to get it to repicate. There is nothing logged on the slave at all. ACL logging on the master shows the slave connecting and seeming to get access - see below. On the MAIN SERVER I HAVE access to attrs=userPassword,shadowLastChange by self =xw by anonymous auth by dn="cn=sync,dc=my company,dc=com" read by * none access to * by self write by dn="cn=sync,dc=my company,dc=com" read by users read by * read # Replication stuff overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 200 ON THE SLAVE I HAVE access to * by self write by dn="cn=sync,dc=my company,dc=com" write by users read by anonymous auth loglevel sync config acl logfile /tmp/ldaptmp syncrepl rid=123 provider=ldaps://envy.my company.com type=refreshOnly interval=01:00:00:00 searchbase="dc=my company,dc=com" filter="(objectClass=*)" scope=sub attrs="*,+" schemachecking=off retry="60 10 300 3" logbase="cn=accesslog" syncdata=accesslog bindmethod=simple binddn="cn=sync,dc=my company,dc=com" credentials="password" AUTH OUTPUT FROM THE MASTER Nov 26 10:48:04 envy slapd[19774]: => acl_mask: to value by "", (=0) Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: self Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: cn=sync,dc=imagreendriver,dc=com Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: users Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: * Nov 26 10:48:04 envy slapd[19774]: <= acl_mask: [4] applying read(=rscxd) (stop) Nov 26 10:48:04 envy slapd[19774]: <= acl_mask: [4] mask: read(=rscxd) Nov 26 10:48:04 envy slapd[19774]: => slap_access_allowed: read access granted by read(=rscxd) AN LDAP SEARCH QUERY produces zip on slave ldapsearch -H ldaps:/// -x -b 'dc=my company,dc=com' '(objectclass=*)' -s sub # extended LDIF # # LDAPv3 # base <dc=my company,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1

4 3

Re: OpenLDAP 2.4.38 available
by Clément OUDOT 27 Nov '13

27 Nov '13

2013/11/18 OpenLDAP Project <project(a)openldap.org>: > OpenLDAP 2.4.38 is now available for download as detailed on our download page: > > http://www.openldap.org/software/download/ > Hi, I am happy to inform you that LDAP Tool Box packages are now available for OpenLDAP 2.4.38 (see announce: http://tools.ltb-project.org/news/44) The great news is that we now provide Debian packages! We also now have a YUM repository and a APT repository. Special mention to David Coutadeur who works hard on the Debian packages. Clément.

1 0

Re : Antw: dynlist performance
by "POISSON Frédéric" 27 Nov '13

27 Nov '13

Hello, Le 27/11/13, Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> a écrit : > >>> "POISSON Frédéric"<frederic.poisson(a)admin.gmessaging.net> schrieb am > 27.11.2013 > um 10:46 in Nachricht <3fd84a3867972521.5295cd90(a)admin.gmessaging.net>: > > Hello, > > > > I'm testing the dynlist overlay on OpenLDAP 2.4.38 because i have a static > > group of around 10K uniqueMember. I want to have now a equivalent group with > > > dynlist. > > > > I have configured my overlay dynlist like this : > > dn: olcOverlay={2}dynlist,olcDatabase={1}bdb,cn=config > > objectClass: olcOverlayConfig > > objectClass: olcDynamicList > > olcOverlay: {2}dynlist > > olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember > > > > And my group is quite like OpenLDAP example in documentation : > > > > dn: cn=GeneralisationDyn,ou=Groups,dc=example,dc=com > > objectClass: top > > objectClass: groupOfURLs > > cn: GeneralisationDyn > > memberURL: ldap:///ou=People,dc=example,dc=com??one?(objectClass=person) > > uniqueMember: uid=user1,ou=People,dc=example,dc=com > > uniqueMember: uid=user2,ou=People,dc=example,dc=com > > [...] > > > > My backend is Berkeley DB and i have tune it in order to have quite fast > > responses on searches, and locally on my server (virtualized with a single > > proc), it take that time to return the entries found by memberURL : > > > > real 0m0.272s > > user 0m0.040s > > sys 0m0.023s > > Actually, if you sum sys and user, you get 0.07s. Times 10000 gives 700s. So > the bulk transfer is quite efficient compared to the single transfer. > Also not that the direction of search is different: Once you start from > uniqueMember, and the other time you start from DN (I guess). > > Sorry i don't understand the way you explain that, it is not clear in my mind. Do the dyngroup plugin run the same ldapsearch as presented inside the memberURL ? If yes : why showing the uniqueMember from dyngroup overlay takes more time than running the equivalent ldapsearch ? If not : How the dyngroup overlay works ? Sorry if my questions are boring... > > > > > > If i run an ldapsearch to see all uniqueMember of my dynamic group it take > > around 8 to 10 seconds to have the output ! > > > > Why a so big difference of response time in a search of entries and a search > > > of uniqueMember inside a dynamic group ? > > Is there some tuning for dynlist plugin ? > > > > Notice also that when i search uniqueMember inside my static group with > > quite same number of uniqueMember) i have less than 0.1 seconds of real > time. > > > > > > Thanks, > > Regards, > > -- > > > > Frederic Poisson > > > Regards, -- Frederic Poisson

1 0

Re : Re: dynlist performance
by "POISSON Frédéric" 27 Nov '13

27 Nov '13

Hello, Thanks Clement for your response and blog for valsort usage (http://coudot.blogs.linagora.com/index.php/post/2013/01/07/Astuce-OpenLDAP-…!). Dieter i didn't mention my search filter because i take the same base/scope/filter that i configure inside memberURL, and also my idea wasn't to compare my server configuration with others and yours, but just to understand why it take more time to search uniqueMember whitout valsort overlay than searching the entries locally. Now, yes using valsort overlay decrease the time of ldapsearch display for my 10K entries : real 0m0.436s user 0m0.010s sys 0m0.009s Where is it mention inside OpenLDAP documentation/faq that performance are better with valsort and what is the threshold for using it (eg how many uniqueMember? ) ? Thanks, Le 27/11/13, Dieter Klünter <dieter(a)dkluenter.de> a écrit : > Am Wed, 27 Nov 2013 10:46:40 +0100 > schrieb "POISSON Frédéric" <frederic.poisson(a)admin.gmessaging.net>: > > > Hello, > > > > I'm testing the dynlist overlay on OpenLDAP 2.4.38 because i have a > > static group of around 10K uniqueMember. I want to have now a > > equivalent group with dynlist. > > > > I have configured my overlay dynlist like this : > > dn: olcOverlay={2}dynlist,olcDatabase={1}bdb,cn=config > > objectClass: olcOverlayConfig > > objectClass: olcDynamicList > > olcOverlay: {2}dynlist > > olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember > > > > And my group is quite like OpenLDAP example in documentation : > > > > dn: cn=GeneralisationDyn,ou=Groups,dc=example,dc=com > > objectClass: top > > objectClass: groupOfURLs > > cn: GeneralisationDyn > > memberURL: > > ldap:///ou=People,dc=example,dc=com??one?(objectClass=person) > > uniqueMember: uid=user1,ou=People,dc=example,dc=com uniqueMember: > > uid=user2,ou=People,dc=example,dc=com [...] > > > > My backend is Berkeley DB and i have tune it in order to have quite > > fast responses on searches, and locally on my server (virtualized > > with a single proc), it take that time to return the entries found by > > memberURL : > > > > real 0m0.272s > > user 0m0.040s > > sys 0m0.023s > > > > If i run an ldapsearch to see all uniqueMember of my dynamic group it > > take around 8 to 10 seconds to have the output ! > > > > Why a so big difference of response time in a search of entries and a > > search of uniqueMember inside a dynamic group ? Is there some tuning > > for dynlist plugin ? > > > > Notice also that when i search uniqueMember inside my static group > > with quite same number of uniqueMember) i have less than 0.1 seconds > > of real time. > > You didn't mention the search string and filter, but here my results of > 5,000 entries > > time ldapsearch -Y DIGEST-MD5 -U replicator -wxxxx -l0 -z0 -H > ldap://localhost -b cn=dynamicGroup,o=avci,c=de -s base "*" > [5000 lines] > > # search result > search: 3 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > real 0m0.606s > user 0m0.014s > sys 0m0.027s > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://dkluenter.de > GPG Key ID:DA147B05 > 53°37'09,95"N > 10°08'02,42"E > > > -- Frederic Poisson

2 1

dynlist performance
by "POISSON Frédéric" 27 Nov '13

27 Nov '13

Hello, I'm testing the dynlist overlay on OpenLDAP 2.4.38 because i have a static group of around 10K uniqueMember. I want to have now a equivalent group with dynlist. I have configured my overlay dynlist like this : dn: olcOverlay={2}dynlist,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {2}dynlist olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember And my group is quite like OpenLDAP example in documentation : dn: cn=GeneralisationDyn,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfURLs cn: GeneralisationDyn memberURL: ldap:///ou=People,dc=example,dc=com??one?(objectClass=person) uniqueMember: uid=user1,ou=People,dc=example,dc=com uniqueMember: uid=user2,ou=People,dc=example,dc=com [...] My backend is Berkeley DB and i have tune it in order to have quite fast responses on searches, and locally on my server (virtualized with a single proc), it take that time to return the entries found by memberURL : real 0m0.272s user 0m0.040s sys 0m0.023s If i run an ldapsearch to see all uniqueMember of my dynamic group it take around 8 to 10 seconds to have the output ! Why a so big difference of response time in a search of entries and a search of uniqueMember inside a dynamic group ? Is there some tuning for dynlist plugin ? Notice also that when i search uniqueMember inside my static group with quite same number of uniqueMember) i have less than 0.1 seconds of real time. Thanks, Regards, -- Frederic Poisson

4 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