openldap-technical

openldap-technical@openldap.org

20 participants
9802 discussions

ldap_search_ext_s timeout
by Mahadev, Vasavi (CW) 27 Nov '13

27 Nov '13

Hi All, The LDAP directory services in our product uses ldap_search_ext_s for synchronous search. Now,my intension is to specify a timeout in this API,so that in case if the server does not respond within the timelimit,the operation should be terminated. I tried specifying time out for the asyncronous search usign the API ldap_search_ext and it did not work.Adding timeout to ldap_result did timed out the operation! So, I was wondering how I can make the synchronous search to timeout . Requesting your help on this. Regards, Vasavi

1 0

Different approaches to setup ldap client
by slacker lnx 26 Nov '13

26 Nov '13

Hello, I have a few ldap clients which were set up by my previous sys-admin. 1. In some of the servers I see that the configuration is done in /etc/pam_ldap.conf, /etc/nslcd.conf and there is a nslcd process running on the clients. 2. On other servers I find that there is only an /etc/ldap.conf and there are no nslcd process running. The configuration values in both the approaches are the same. Are there two different ways to setup an ldap client. I would like to understand both these approaches. In the second approach is there some other process which does the ldap lookup? Can someone share links to docs related to both the installation steps. Thanks

3 2

Recommended ACL for nagios monitoring
by ML mail 26 Nov '13

26 Nov '13

Hello, I would like to monitor connectivity to my OpenLDAP using nagios with its check_ldap script and was wondering which minimal ACL would you recommend for that purpose? For that purpose I will be using a dedicated user such as cn=nagios,ou=users,dc=domain,dc=tld and would like it just to be able to bind to dc=domain,dc=tld and nothing else. Any recommendations? Thanks ML

6 7

Openldap for proxy AD
by wrm＠cdtn.br 26 Nov '13

26 Nov '13

Hi, I´m with some troubles to do authentication in AD trough of Openldap. Somebody managed to authenticate with AD password in Openldap Server? I´m trying everything but don´t auth. I see all users but the password don´t pass. My slapd.conf like this : # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema #allow bind_v2 loglevel 256 #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: modulepath /usr/lib/openldap #moduleload back_bdb moduleload accesslog.la moduleload auditlog.la moduleload ppolicy.la moduleload rwm.la moduleload back_ldap TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem ####################################################################### database ldap suffix "dc=foobar" rootdn "cn=admin,dc=foobar" ################################### rootpw {SSHA}wXmTs2ANS4XwqqnzEVIqmc+i6VCUiD7I database ldap suffix dc=foobar,dc=com #subordinate rebind-as-user uri ldaps://srv-2003.foobar.com idassert-bind bindmethod=simple binddn="cn=vmail,cn=users,dc=foobar,dc=com" credentials=abc@123 mode=none flags=non-prescriptive idassert-authzFrom "dn.regex:.*" #idassert-authzFrom "dn.exact:cn=admin,dc=foobar" # chase-referrals yes require authc ############################# ###########password-hash {CLEARTEXT} TLSCipherSuite HiGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 TLSVerifyClient allow sasl-host localhost sasl-secprops none ######################################################################### database config # all others attributes are readable to everybody access to * by * read lastmod off overlay rwm rwm-suffixmassage dc=foobar,dc=com #rwm-normalize-mapped-attrs rwm-map attribute uid sAMAccountName rwm-map attribute cn name #rwm-map attribute mail userPrincipalName rwm-map objectclass account What is wrong? Please help me. Thanks.

7 14

ACL and Password Policy
by Aleksander Dzierżanowski 26 Nov '13

26 Nov '13

Hi. I have OpenLDAP 2.4.36 server grabbed from LTB project. I’ve noticed two issues, can anyone confirm the same behavior? First - ACLs: to dn.base="" by users read to dn.subtree="ou=disabledaccounts,o=examples" by dn.base="cn=replicationmanager,o=example" read by * none to attrs=userPassword,shadowLastChange by dn.base="cn=replicationmanager,o=example" read by dn.base=„cn=radiussuperuser,o=example" read by anonymous auth by self write by * none [skipping few next less important rules] Above ACL should NOT show user’s own password, right? But it shows in my environment.. Second: PwdMinLength in password policy does not work. I can easily set shorter password. Password policy in general works, for example it does not allow me to change password earlier than ‚pwdMinAge’. Best regards, — Olo

5 7

Wtrlt: Re: Antw: Re: Q: "opjectClass: top" or not?
by Ulrich Windl 26 Nov '13

26 Nov '13

(forgot the copy to the list) I wrote: >>>>> Michael Ströder<michael(a)stroeder.com> schrieb am 22.11.2013 um 20:24 in >> Nachricht <528FAF5A.3050603(a)stroeder.com>: >>> Christian Kratzer wrote: >>>> very interesting point. >>>> >>>> I have a customer with an enterprise application that insists on having an >>>> explicit objectClass: top on all entries. >>>> >>>> Their developers argue that the rfcs mandate an explicit objectClass: top >> on >>>> all entries. I argue that the wording in the respective rfcs is not exact >>>> enough. Having an objectClass that inherits from top should be enough from >> >>> my >>>> point of view. >>>> >>>> I am currently travelling and cannot lookup the rfc. >>> >>> I vaguely remember having researched this as well many years ago. Don't >>> remember the details but I came up with the following recommendations: >>> >>> For client developers: Don't require object class 'top'. >>> >>> For LDAP admins: Add object class 'top' to all entries. >>> >>> Ciao, Michael. >> >> I wonder: If you query an object, you get a set of attributes. Whether you >> added "top" or not, the attributes are the same (except the "objectClass: >> top"). And ussually the attributes are not associated with a specific >> objectlass in the search result. >> >> If you try to "structure" the search results, then with "top", you'll find > the >> objectClass attribute at the "top" abstract class, while without "top" > you'll >> find it in the structural object class. >> >> I haven't found a document that describes "multiple inheritance" as it > happens >> with "top" (every objectclass inherits from top, but still the attributes > occur >> only once in the type hierarchy). >> >> Regards, >> Ulrich

1 0

Password Issues between provider and consumer
by Choure, Sidd 25 Nov '13

25 Nov '13

Everything is setup on RHEL 6.4 with Openldap 2.4. I have one provider and one consumer. StartTLS has been enabled and everything is working as intended. My only problem arises here - When a user is setup with a password and he tries to change his password on a consumer pointing client, I get a passwd: Authentication token manipulation error. This message is misleading since the password is in fact changed on the provider ( I have the olcUpdateRef directive setup). This creates a situation where the user can login to consumer pointed boxes with his old password and provider pointed boxes with his new password. If the user tries to change his password for the second time on consumer pointed boxes, I get Password change failed. Server message: unwilling to verify old password passwd: Authentication token manipulation error which understandably is because the password in the actual LDAP db is different from what is being supplied and being accepted by the client. What is going on here? Why isn’t the password not getting updated properly in the consumer? Here are some of the relevant snippets of configs - For Syncrepl in olcDatabase={2}bdb.ldif on consumer ###For Replication olcSyncrepl: rid=100 provider="ldap://server.com type=refreshAndPersist retry="60 30 300 +" searchbase=“dc=ex,dc=example,dc=com" bindmethod=simple binddn="cn=Manager,dc=ex,dc=example,dc=com" credentials=secret starttls=yes tls_cacert=/etc/pki/CA/cacert.pem tls_cert=/etc/pki/tls/certs/cert.pem tls_key=/etc/pki/tls/certs/key.pem olcUpdateRef: ldap://server.com ACL on provider - lcAccess: to attrs=userPassword by self write by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by anonymous auth by * none olcAccess: to * by self write by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by users read olcAccess: to attrs=entry by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by * read Let me know if any more configs are needed and I will post them. Any help is appreciated. Siddharth Choure Senior Systems Engineer

3 7

DNS SRV with openldap
by Jignesh Patel 24 Nov '13

24 Nov '13

To setup DNS SRV record in LDAP, do we need to use some kind of DNS server i.e. bind or powerdns? Or by default LDAP supports it? Jignesh Patel Chief Architect iCare.com LLC 14001 NW 4th Street Sunrise, FL 33325 O: 954-616-5604 F: 954-616-5609 jignesh(a)icare.com CONFIDENTIALITY NOTE: The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender that you have received this communication in error and then delete it. Thank you.

4 4

Re: password hashes and simple binds
by Dieter Klünter 24 Nov '13

24 Nov '13

Am Sat, 23 Nov 2013 20:22:56 +0100 schrieb Aleksander Dzierżanowski <olo(a)e-lista.pl>: > Wiadomość napisana przez Dieter Klünter <dieter(a)dkluenter.de> w dniu > 23 lis 2013, o godz. 19:57: > > > Am Sat, 23 Nov 2013 13:24:56 +0100 > > schrieb Michael Ströder <michael(a)stroeder.com>: > > > >> Dieter Klünter wrote: > >>> Hi, > >>> I have a ldap server (2.4.36) with various password hashes > >>> {CLEARTEXT} {KERBEROS} {SSHA} for different users, there is no > >>> pasword-hash declaration in slapd.conf. Now i face a strange > >>> behaviour with {CLEARTEXT} hash. that is: > >>> userPassword: {CLEARTEXT} secret > >> ^^^ > >> I'd try to remove this extra space. Not sure though. > > > > Just to demonstrate the various hash scheme {CLEARTEXT} results: > > http://pastebin.de/37485 > > > > Well, AFAIK if there is no {METHOD} in userPassword attribute than > method is cleartext, so everything works as expected I suppose... — > Olo It is not that simple. RFC-2307 describes hashing schemes, but not {CLEARTEXT), man slapd.conf(5) mentions {CLEARTEXT} as password-hash. http://tools.ietf.org/id/draft-stroeder-hashed-userpassword-values-01.html only refers to hashed userpassword values. DIGEST-MD5 is a SASL mechanism which requires a cleartext password, thus a hashing scheme of {CLEARTEXT} is valid for a SASL mechanism. A simple bind requires a userpassword attribute value in cleartext, but doesn't require a hashing scheme. It would be quite helpful if OpenLDAP would accept a hash scheme for a simple bind. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

2 1

password hashes and simple binds
by Dieter Klünter 23 Nov '13

23 Nov '13

Hi, I have a ldap server (2.4.36) with various password hashes {CLEARTEXT} {KERBEROS} {SSHA} for different users, there is no pasword-hash declaration in slapd.conf. Now i face a strange behaviour with {CLEARTEXT} hash. that is: userPassword: {CLEARTEXT} secret A sasl bind with DIGEST-MD5 is succesful, but a simple bind returns error 49. If I remove the {CLEARTEXT} hint and only the secret remains, userPassword: secret all binds (sasl and simple) are successful. Any hints why this is happen? -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical