openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

Significance of name forms.
by dE 30 Apr '15

30 Apr '15

Suppose a name form is attached to a structural object class. Then, when referring to entries belonging to that object class (which has no DIT Structure Rules associated to it), is using the MUST attributes as defined in the name form to construct AVA still necessary? No DIT Structure Rules refer to this name form.

3 15

Re: idassert-bind seems to ignore binddn
by Ryan Lovett 30 Apr '15

30 Apr '15

Thanks for your response. I'm surprised Ubuntu's most recent LTS is shipping such an old version of OpenLDAP! I just built and installed 2.4.40 packages on Ubuntu 14.04 from Debian Jesse's 2.4.40 source. Unfortunately slapd returns the same results as 2.4.31 and a packet capture shows the same binding behavior. Ryan On Thu, Apr 30, 2015 at 6:25 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, April 30, 2015 6:32 PM -0700 Ryan Lovett <rylo(a)berkeley.edu> > wrote: > > >> Hello, >> >> >> I've setup a simple proxy so that local LDAP clients can get access to >> protected attributes on a remote server. My proxy is slapd 2.4.31 with >> >> What am I doing wrong? Any advice is greatly appreciated! >> > > The first thing you're doing wrong is running a version of OpenLDAP that > is so ancient. > > OpenLDAP 2.4.31 Release (2012/04/21) > > I.e., it's over 3 years old. > > There have been multiple fixes to slapd-ldap since that release. This one > in particular may be related: > > OpenLDAP 2.4.33 Release (2012/10/10) > Fixed slapd-ldap idassert bind handling (ITS#7403) > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

getent passwd only catch local user passwd
by Yingbo Li 30 Apr '15

30 Apr '15

Hi, I am new to LDAP. The company's IT own LDAP server, I tried to configure openldap client but failed. My OS is CentOS 7, openldap is 2.4.39. I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of my LDAP account. I configured with authconfig-tui. I also modified /etc/pam.d/system-auth and password-auth, change pam_sss.so to pam_ldap.so. While when I tried getent passwd, I can only find local users. I cannot su to my LDAP account. Why? I google online it looks like CentOS 7 has problem to configure ldap client. Cent0S 7 does not have pam_ldap module. But I can find pam_ldap.so in the system. What should I do to fix it? Switch to CentOS 6.6? Your help is really appreciated! Thank you! Yingbo

5 10

Ldap challenge
by Ross, Daniel B. 30 Apr '15

30 Apr '15

Ok I have looked a couple options but I really dont know how to accomplish what I need to do. Here is what I am trying to do. I have a greater organization that is stuck on using Microsoft products namely Microsoft LDS. To make matters worse they present the data to my linux servers in a completely non-standard way. Its driving my solaris and linux box nuts and they simply dont want to work with it. What i need to do is continue to use the campus usernames and passwords but present the Data in a format that my linux/unix hosts can use. Is this possible? i.e. userid would still be samwise but instead of a bizzarre OU=monkeypeople,dc=example,dc=com I want it to present as people,dc=example,dc=com. I looked at referral and aliasing but it does not seem to be doing what I am trying to do. Passthrough authentication looks close but I cant find sufficient documentation to actually configure a system to use it. Thanks Daniel

8 12

Re: modifying cn=config with ldapmodify
by Abdelhamid Meddeb 29 Apr '15

29 Apr '15

Hi, In your ssl.ldif file there is a *blank* line too after changetype: modify This is not reported in your first post but it apear in seconde one. I have reproduced the same symptoms with this empty line More details bellow Cheers. Le 29/04/2015 12:56, Robert Munn a écrit : > My replies inline... > > On Apr 26, 2015, at 2:28 AM, Abdelhamid MEDDEB <abdelhamid(a)meddeb.net > <mailto:abdelhamid@meddeb.net>> wrote: > >> Hi, >> >> >> Le 25/04/2015 15:10, Robert Munn a écrit : >>> I have been trying to replace the SSL cert settings on my OpenLDAP >>> instance running on Ubuntu using ldapmodify. >>> >>> >>> I followed directions on the Ubuntu wiki: >>> >>> https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-tls >>> >>> using a modified ldif file for the replace: >>> >>> |dn: cn=config >>> changetype: modify >>> replace: olcTLSCACertificateFile >>> olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem >>> - >>> replace: olcTLSCertificateFile >>> olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem >>> - >>> replace: olcTLSCertificateKeyFile >>> olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem| >> |All right| Empty line is not reported here. >>> When it didn’t work on my existing instance I built a new instance >>> in a new Ubuntu VM (14.04) and tried the original directions from >>> Ubuntu. That did not work either. >> May be you've missed some settings at build time like --with-tls > > I installed OpenLDAP using apt. The .deb package must include TLS > because I added the certificates manually. > > >>> >>> The ldapmodify command executes correctly but it seems that the >>> change is not registered by the server. This is the case in both the >>> new instance and the old instance of OpenLDAP. >> No error message like "Insufficient access (50)" ? and you should >> check the write (manage)rights to cn=config database. > > The command I ran (as sudo) and the message: > > ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > modifying entry "cn=config” > > and ssl.ldif : > > dn: cn=config > changetype:modify > > replace: olcTLSCACertificateFile > olcTLSCACertificateFile: /etc/ssl/certs/CAcert > - > replace: olcTLSCertificateFile > olcTLSCertificateFile: /etc/ssl/certs/cert > - > replace: olcTLSCertificateKeyFile > olcTLSCertificateKeyFile: /etc/ssl/private/cert.key > But we show it here, and content changes (strangely) the cn=config.ldif last modified timestamp, but do nothing realy > cn=config.ldif is being modified by the ldapmodify process, I verified > that by changing file permissions on cn=config.ldif, running the > ldapmodify command, and then checking cn=config.ldif. ldapmodify > updated the timestamp and file permissions on the file. The file > changed, but the configuration changes in ssl.ldif were not made in > cn=config.ldif. > > >>> I ended up replacing the values (or adding them in the new instance) >>> in the /etc/ldap/slapd.d/cn=config.ldif file manually. Making the >>> changes manually and restarting slapd works, but my understanding >>> was that changes to cn=config should be made through ldapmodify. >> Bad practice, it's best to avoid. > > Yes, and when I can modify the configuration using ldapmodify, I will > no longer make the changes manually. > > I found a note about enabling logging using ldapmodify: > > https://help.ubuntu.com/lts/serverguide/openldap-server.html > > logging.ldif: > > dn: cn=config > changetype: modify > replace: olcLogLevel > olcLogLevel: stats > > ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif > > I executed this command on my first instance and it added the logging > to cn=config. I executed this command on the second instance, where > olcLogLevel already existed, and it did not alter the log level. > > I have also been experimenting with this script: > > https://github.com/cepharum/slapd-config > > With it, I was able to delete the TLS entries from cn=config: > > slapd-config raw delete cn=config olcTLSCACertificateFile 1 > > but when I tried to add the entries back, I got this error: > > slapd-config raw insert cn=config olcTLSCACertificateFile 1 > "/etc/ssl/certs/cert.pem" > modifying entry "" > ldap_modify: Server is unwilling to perform (53) > additional info: modify upon the root DSE not supported > I have not looked at the details but it seems that there is a bug in this script. (modifying entry "") > > I was able to change the olcLogLevel back to its original state vi > ldapmodify, so maybe there is something particular about the TLS > entries, perhaps having to do with permissions on the certs and keys > themselves? > > I have come across this bug in several forums and have yet to see > someone who solved it in the “correct” manner using ldapmodify. > > > Robert > > > >>> >>> I also found a tech note at CentOS: >>> >>> https://www.centos.org/docs/5/html/CDS/cli/8.0/Configuration_Command_File_R… >>> in section 2.2.2.2 that indicates changes to cn=config will be ignored: >>> >>> "If an attribute is added to |cn=config|, the server ignores it." >>> >>> >>> So am I mistaken? Do I need to do something different? I would >>> prefer to manage the config with ldapmodify, but since I don’t >>> change cn=config that often, I can change it manually. >>> >>> >>> >>> Robert >>> >>> >> >> Cheers, >> -- >> *Abdelhamid MEDDEB* >> http://www.meddeb.net > -- *Abdelhamid Meddeb* http://www.meddeb.net

1 0

Objectclass not enabled in PHPldapadmin
by Gokulnath Arjunan 29 Apr '15

29 Apr '15

Hi, I have installed LDAP 2.4 version and using phpldapadmin to manage it. I am not seeing all the options enabled in create object page. Like I can see "Generic: Organisational Role" and "Generic: Organisational Unit" but other options like "Generic: Address Book Entry, Generic: Posix Group, Generic: User Account" are in disabled mode. I want them to be available to create group and users. Please guide me how to resolve this issue. I noticed below errors/warning during login to phpldapadmin and not sure about it. Samba: Group Mapping: posixGroup removed from template as it is not defined in the schema Alias: inetOrgPerson removed from template as it is not defined in the schema Thanks Gokulnath

1 0

query across ou
by Chuck Theobald 29 Apr '15

29 Apr '15

Is there a way to perform a single query an LDAP database such that I can retrieve the group name (cn) from a user's full name (cn). My structure holds user accounts in ou=People and groups in ou=Group. I know I can ask for gidNumber from the People tree, then reference the group in the Group tree, but with an SQL background, I would like a single query. Thanks, -- Chuck Theobald System Administrator The Robert and Beverly Lewis Center for Neuroimaging University of Oregon P: 541-346-0343 F: 541-346-0345

3 2

Re: Antw: Re: All entries belong to the top object class?
by dE 28 Apr '15

28 Apr '15

On 04/21/15 11:43, Ulrich Windl wrote: >>>> dE <de.techno(a)gmail.com> schrieb am 20.04.2015 um 07:36 in Nachricht > <55349047.7020907(a)gmail.com>: >> On 04/20/15 00:59, Ryan Tandy wrote: >>> On Sun, Apr 19, 2015 at 11:42:16AM +0530, dE wrote: >>>> As per https://tools.ietf.org/html/rfc4512#section-3.3 >>>> >>>> When creating an entry or adding an 'objectClass' value to an entry, >>>> all superclasses of the named classes SHALL be implicitly added as >>>> well if not already present. >>>> >>>> That means the top object class will always be there. >>> Basically correct. Note "implicitly" means it's treated as present, >>> even if the entry doesn't actually contain "objectClass: top". >>> >>>> Or is it that only the most subordinate object class in the >>>> multivalued attribute is considered by the client and server? >>> The following facts may answer your question: >>> >>> - every entry satisfies the filter "(objectClass=top)". >>> >>> - an entry with "objectClass: inetOrgPerson" satisfies the filter >>> "(objectClass=person)". >>> >> I'm concerned about the attributes. Does adding of the top object class >> (or person) add all attributes to the entry? > I'd say: It adds no attributes at all to the entry automagically, but the MUST attributes have to be provided while the MAY attributes may be provided. If an entry is created, it will contain all the valid attributes you provide (no entry is created if you supply invalid attributes). > > Regards, > Ulrich Yes, so subclasses do not define MAY; it's defined by the MAY of the top object class.

3 3

Re: Antw: Re: Slapd running very slow
by Geoff Swan 28 Apr '15

28 Apr '15

On 2015-04-23 4:07 PM, Ulrich Windl wrote: >>>> Geoff Swan <gswan3(a)bigpond.net.au> schrieb am 22.04.2015 um 23:18 in Nachricht > <5538100A.3060301(a)bigpond.net.au>: > > [...] >> Free stats look fine to me. No swap is being used, or has been used yet >> on this system. >> >> total used free shared buffers cached >> Mem: 132005400 21928192 110077208 10612 363064 19230072 >> -/+ buffers/cache: 2335056 129670344 >> Swap: 8388604 0 8388604 >> >> The effect I am seeing is that despite a reasonably fast disc system, >> the kernel writing of dirty pages is painfully slow. > So disk I/O stats is also available via sar. May we see them? Finally there's blktrace where you can follow the timing and positions of each individual block being written, but that's not quite easy to run and analyze (unless I missed the easy way). > > I suspect scattered writes that bring your I/O rate down. > > Regards, > Ulrich > sysstat (and sar) is not installed on this system, so I can't give you that output.

3 8

OpenLDAP keeps on dying sporadically
by Leander Schäfer 28 Apr '15

28 Apr '15

Hi fellows my OpenLDAP keeps on dying sporadically. Unfortunately it doesn't leave ANY trace of why it crashes. It stays alive for a while .... takes a couple of queries as expected ... and then suddenly it dies after another request. This could mean working perfectly for a day or working only for a couple of minutes before it crashes. The requests are all known to work (Dovecot auth and system PAM auth). At first I thought it could be related to newsyslog(8) ... I did some testing - unfortunately this doesn't change anything at all. It keeps on dying sporadically even if newsyslog is completely deactivated for the slapd(8) log file. I experenced this behauviour since I first used OpenLDAP approximately 5 years ago. My OpenLDAP configurations have been changed many times and quite a lot over those 5 years. Unfortunately I was never able to figure out what the sudden crashes caused - so I wrote a supervisor script , which periodically checks if the slapd(8) is still running. If slapd(8) is not running, then my supervisor script starts it automatically again. Of course with every major change in the configuration of OpenLDAP, I also tried to debug this problem of the sudden crashes - but as I said: even with all debug levels activated - slapd(8) didn't want to share its root of the pain. This workaround was the only way I could use OpenLDAP at all over the past five years. Two days ago I got to the point where my workaround came to its capacity boundary. The time between the slapd(8) crashes has become so little, so my script can't handle them anylonger. I would have two options now: a) Fix my supervisor script, so it detects and starts slapd(8) even if the time between crashes is less than 3 sec. b) I ask for help in order to discover this mysterious cause of the crashes and FINALLY fix it FOREVER. So this time I set my foot down and go for b). This is why I decided to contact you. The following link containes a more detailed debugging of the problem: https://forums.freebsd.org/threads/openldap-slapd-dies-sporadically.47634/ And this is the current / latest configuration I deploy on my servers. Also, it doesn't make a difference whether I have monitoring activated or not. It keeps on dieing the same as before. The very same ocours to the "ldapab.schema" - it doesn't make a difference for the crashes to happen whether it is commented out or activated. Logging hapens through syslogd(8). # ============================================================ # #======================================# # slapd.conf # #======================================# # LDAP Attribut Schema Definitions: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/ldapab.schema include /usr/local/etc/openldap/schema/mail.schema #include /usr/local/etc/openldap/schema/qouta.schema # Logging loglevel 256 # If "logfile" is activated, then newsyslog must restart slapd after rotation #logfile /var/log/slapd.log # Important Files pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Allow LDAPv2 client connections. This is required for iOS suppoprt via SSL. #allow bind_v2 # Time limits #idletimeout 0 #writetimeout 0 #timelimit 3600 # Dynamic Modules: modulepath /usr/local/libexec/openldap moduleload back_mdb moduleload back_monitor # Access from 127.0.0.1 without encryption access to dn.subtree="dc=MyDomain,dc=local" by peername.ip=127.0.0.1 write by * none break # Access from other than 127.0.0.1 requires TLS # encryption with min. 128 bit encryption access to dn.subtree="dc=MyDomain,dc=local" by ssf=128 write by * none # TLS-Certificate TLSCertificateFile /etc/ssl/PKI/CA/Signing-CA/Certs/WM-01.MyDomain.Local.crt TLSCertificateKeyFile /etc/ssl/PKI/CA/Signing-CA/Private/WM-01.MyDomain.Local.key TLSVerifyClient allow # Restrict write access for password attributes to root user only by dn="uid=dovecot,ou=systemuser,ou=mail,dc=MyDomain,dc=Local" access to attrs=userPassword by self write by anonymous auth by * none # All the other atributes can be read by everyone else access to * by * read # ================================== # # Internal Monitoring # # ================================== # # DB type database monitor # Name of Administrator rootdn "cn=monitoring,cn=Monitor" # Password of Administrators rootpw {SSHA}SomeHash # ACL for moitoring access to dn.subtree="cn=Monitor" by dn.exact="cn=admin,dc=MyDomain,dc=local" write by peername.ip=127.0.0.1 read by users read by * none # ================================== # # Lightning Memory-Mapped Database # # ================================== # # Datenbanktyp database mdb # DB location on FS directory /var/db/openldap-data # Datenbank-Pfad suffix "dc=MyDomain,dc=local" # Name of Administrator rootdn "cn=admin,dc=MyDomain,dc=local" # Password of Administrators rootpw {SSHA}SomeHash # Max size of DB in Byte [ 5368709120 Byte => 5 GB ] maxsize 5368709120 # Index search related attributes index objectClass eq index uid eq index uidNumber eq index uniqueMember eq index gidNumber eq index cn eq index memberUid eq index mailAccountStatus eq index mailAddress eq index associatedDomain eq # ============================================================= # I compiled OpenLDAP from FreeBSD ports with following options: - DYNAMIC_BACKENDS - MDB - PPOLICY - SYNCPROV - TCP_WRAPPERS Please let me know what kind of further information I could deliver to you in order to detect the root of the problem. Thank you Best regards Leander

5 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical