openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

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 29 Apr '15

29 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 29 Apr '15

29 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

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

28 Apr '15

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. Or is it that only the most subordinate object class in the multivalued attribute is considered by the client and server?

6 11

uidNumber=4294967295 is being appearing in the log frequently
by Majid Khan 28 Apr '15

28 Apr '15

Dear Techies, I'm not sure if this is the right forum to discuss this but I am getting the following from some of the clients machine I'm not sure why some of them sending this info otherwise my authentication and login all is working fine but I'm concern why its happening and my log is full of the following kind of message: If this is not the right forum then I apologies and please direct me to that right group: Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=4294967295)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))"Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Server info: CentOS release 6.6LDAP version: openldap-2.4.40 Client info: CentOS release 6.2Client using SSSD: sssd-1.11.6 Thanks. Best regards, Majid.

2 2

top object class contains all possible attributes?
by dE 28 Apr '15

28 Apr '15

From https://tools.ietf.org/html/rfc4512 it can be said that an object class inherits the sets of *allowed* and required attributes from its superclasses Therefore the top object class contains all possible attributes? OR A subclasses cannot contain any attribute which is not included in it's superclass? I'm running Apache directory studio, and I don't see that happening.

4 4

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

28 Apr '15

On 04/20/15 22:56, Michael Ströder wrote: > dE wrote: >> Does adding of the top object class (or >> person) add all attributes to the entry? > > Nope. Which text in RFC 4512 leads to your presumption? > > Ciao, Michael. > > Sorry for the late response. I was out of town. From the responses, it appears the question has not been understood correctly, I what I meant to ask was -- Does adding of the top object class (implicitly) make it possible to add all attributes in the DIT to the entry? I'm talking about attributes which are out of the 'MAY' in the most subordinate object class the entry belong to.

7 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