openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

mod_athnz_ldap module for Fedora 19
by Tharmakulasingam Jeyjenthan 06 Jan '14

06 Jan '14

Hi, I am trying to get mod_athnz_ldap module to connect apache server with openldap server in Fedora 19. But there are RPM modules for fedora except for Fedora 19. How can i achieve this? Any Suggestion. Thanks in advance. Regards, T.Jeyjenthan

1 0

Ldap password policy not throwing different errors
by Idan Fridman 05 Jan '14

05 Jan '14

Hi, I use ppolicy overlay and enabled ppolicy_use_lockout to separate between invalid password and locked accounts. database bdb suffix "dc=openiam,dc=com" rootdn "cn=Manager,dc=openiam,dc=com" rootpw "{SSHA}2ttRoo/t5HuMT2nPxtI6goVUML5R2H9h" # PPolicy Configuration overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=openiam,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext I tried to lock user account by entering wrong password couple of times (pwdMaxFailure) The user is being locked but when I try to login again I still get the same error: Invalid credentials (49) Any idea why i am not getting diffrent error to disticnt between the cases? thanks, ray. This e-mail and the information it contains may be privileged and/or confidential. It is intended solely for the use of the named recipient(s). If you are not the intended recipient you may not disclose, copy, distribute or retain any part of this message or attachments. If you have received this e-mail in error please notify the sender immediately [by clicking 'Reply'] and delete this e-mail.

4 4

using the deref control
by Arthur de Jong 05 Jan '14

05 Jan '14

Hi list, First off, best wishes for 2014. I've been looking into the deref control that was pointed out here (in the Oracle OpenLDAP PPolicy ppolicy and the hierarchy thread). With some trail and error I got things working so I thought to document what I did in the hopes that it may be useful for other people wanting to use this control. First of all, get a slapd instance running with the deref overlay. With older versions (at least 2.4.31) it was sufficient to load the module to have the relevant control being shown in the root DSE. However, due to ITS#7436 this didn't actually do anything. With later slapd versions (at least 2.4.38) loading the overlay apparently isn't sufficient but you have to also configure it for each database: dn: olcOverlay={1}deref,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}deref In terms of using the API you have to first create a control with ldap_create_deref_control() and pass it along with ldap_search_ext(). After the call to search, free the control again with ldap_control_free(). The control is built up of an array of LDAPDerefSpec structs that contains the attribute name that contains the link and a list of attributes to retrieve from the linked entry (just like you would pass to ldap_search()). A bump in the road here was that ldap_create_deref_control() was broken (reported earlier and already fixed in Git) but ldap_create_deref_control_value() seems to work. Any response entries will have a control available that can be extracted with ldap_get_entry_controls() and parsed with ldap_parse_derefresponse_control() (and freed with ldap_derefresponse_free()). The returned control data is a linked list of LDAPDerefRes structs, one per link attribute value. Each struct contains the attribute name, the original value and a linked list of LDAPDerefVal structs. The DerefVal structs contain per requested attribute from the linked entry (if the entry has the attribute) the attribute name and a list of values. This has been implemented in the development branch of nss-pam-ldapd and will probably land in the next 0.9 release. - adding the request control: http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=547e4792c580b67ec14595… - parsing the response control information: http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=c973834328baa69dbd3352… - complete functionality (merge commit): http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=c6c317ec9efb8190bdc183… Hope this is helpful for someone. -- -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --

1 0

OpenLDAP Multiple User Import
by David Barr 03 Jan '14

03 Jan '14

I have one file that I need to use to import about 50 people, it doesn't like the fact that I have more than one user in the file for some reason. I might have another 200 in the future and need to figure out why it isn't working... Help please. Is my syntax wrong? Did I place something in the wrong order or something more than once that isn't needed. I have included two users, all are the same except the actual username. Help please. # USER ENTRY dn: cn=New.user01,ou=People,dc=test,dc=com uid: NEW.user01 givenName: NEW.user01 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson userPassword: NEW.user01 sn: NEW.user01 ou: People cn: NEW.user01 objectClass: uidObject objectClass: pwdPolicy pwdAttribute: userPassword objectClass: pwdPolicyChecker pwdMinAge: 86400 pwdMaxAge: 7776002 pwdInHistory: 10 pwdCheckQuality: 2 pwdMinLength: 14 pwdExpireWarning: 432000 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 120 pwdAllowUserChange: TRUE pwdCheckModule: Standard Policy pwdLockout: FALSE dn: cn=NEW.user02,ou=People,dc=test,dc=com uid: NEW.user02 givenName: NEW.user02 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson userPassword: NEW.user02 sn: NEW.user02 ou: People cn: NEW.user02 objectClass: uidObject objectClass: pwdPolicy pwdAttribute: userPassword objectClass: pwdPolicyChecker pwdMinAge: 86400 pwdMaxAge: 7776002 pwdInHistory: 10 pwdCheckQuality: 2 pwdMinLength: 14 pwdExpireWarning: 432000 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 120 pwdAllowUserChange: TRUE pwdCheckModule: Standard Policy pwdLockout: FALSE ldapadd -v -d 1 -D "cn=Admin,dc=test,dc=com" -w test -f /tmp/T/.ldif adding new entry cn=New.user01,ou=People,dc=test,dc=com ldap_add: Type or value exists ldap_add: additional info: objectClass: value #1021 provided more than once ________________________________ CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately.

6 8

Search in Active Directory Proxy with multiple level of OU
by Michael Lois 03 Jan '14

03 Jan '14

Hi, We need to setup a openldap proxy to Active Directory. Here is our slapd.conf: database ldap suffix "ou=user,dc=company,dc=com" uri ldap://10.10.10.10/ rebind-as-user idassert-bind bindmethod=simple binddn="cn=openldapuser,ou=Service Accounts,dc=internal,dc=company,dc=com" credentials=******** mode=none idassert-authzFrom "dn.regex:.*" overlay rwm rwm-suffixmassage "OU=All Users,dc=internal,dc=company,dc=com" rwm-map attribute uid sAMAccountName We were trying to query multiple of OU in Active Directory, with the same search string. For example, on AD, user Michael Lois is in "cn=Michael Lois,ou=Accounting,OU=All Users,dc=internal,dc=company,dc=com". With the openldap proxy, we were trying to search Michael with "cn=Michael Lois,ou=user,dc=company,dc=com". From the above slapd config, the following 2 ldapsearch on the openladp proxy server would work: ldapsearch -W -x -b "ou=user,dc=company,dc=com" cn="Michael Lois" ldapsearch -xW -b "cn=Michael Lois,ou=Accounting,ou=user,dc=company,dc=com" But our goal is to make this ldapsearch to give us the same result: ldapsearch -xW -b "cn=Michael Lois,ou=user,dc=company,dc=com" Does anyone know how to search through a proxy with mulitple level of OU in AD? Thank you, Michael

2 1

Is SQLigthning suport full text index?
by Aris Setyawan 03 Jan '14

03 Jan '14

Hi, SQLigthning is enable MDB's MVCC to SQLite. Is SQLigthning suport full text index? regards, Aris

1 0

slapd "olcreadonly" and syncrepl
by Olivier 31 Dec '13

31 Dec '13

Hi everyone, I just configured a directory tuning readonly in the backend database : olcDatabase={1}bdb,cn=config ... olcreadonly: TRUE Good : now if I try to change anything I get an "Server is unwilling to perform (53)" from the server, for axample : # ldappasswd -h localhost -D "uid=olivier,ou=people" -W -S "uid=guillard,ou=people" New password: Re-enter new password: Enter LDAP Password: Result: Server is unwilling to perform (53) Additional info: operation restricted On the other hand, I also have configured this directory to get synchronized on another ldap server through a syncrepl directive, and I see that the ldap synchronization works properly: if I change my password an the master ldap, it's propagated on my "readonly" slave one. This is good since this is exactly what I want. However I have not found the confirmation of this behaviour in the documentation (may be I missed something), that's why I ask here : Is it correct to configure a olcreadonly directory to be slave through syncrepl to another one ? Thanks, --- Olivier

1 0

acl problem
by Mundry, Marvin 30 Dec '13

30 Dec '13

I have encountered an effect that I believe is a bug, but I might be wrong. It would be nice if someone could confirm that my acls should be working, or in case they should not, give me a hint what I am doing wrong. Here is what I am trying to archive: * there is one ldap provider (master) server that contains all attributes that are relevant for my organisation * on the master there is a user allowing a highly secured consumer(slave) ldap server the replication of all attributes from the master * on the master there is a user allowing a low-security consumer(slave) ldap server the replication of all attributes from the master except some critical ones * on the master there is a user (cn=provisioninguser) that can read the accesslog. it is used by scripts to e.g. notify non-ldap systems of password changes. I would like to put the acls for the replication users (high and low security ldap slaves) on the databases and not the frontend to avoid accidental modifications. All other acls should be on the frontend. If I configure all my acls on the frontend only everything works as I think it should. If some acls are on the database the results are rather weird ( the cn=provisioninguser can see only one value of the multi-valued reqMod attribte) The following acl snippet only deals with accesslog access which is where I encounter the problem: dn: olcDatabase={2}hdb,cn=config olcAccess: {0}to dn.subtree="cn=accesslog" attrs=reqMod val.regex="^topSecretAttribute:.*" by dn.base="cn=replicationuser,dc=organisation,dc=com" read by dn.base="cn=replication_low_security,dc=organisation,dc=com" none by * break dn: olcDatabase={2}hdb,cn=config olcAccess: {1}to dn.subtree="cn=accesslog" by dn.base="cn=replicationuser,dc=organisation,dc=com" read by dn.base="cn=replication_low_security,dc=organisation,dc=com" read by * break dn: olcDatabase={-1}frontend,cn=config olcAccess: {0}to dn.subtree="cn=accesslog" by dn.base="cn=provisioninguser,dc=organisation,dc=com" read by * none *if the acls 1,2 and 3 are on "olcDatabase={-1}frontend,cn=config" (which they are not in the example above) cn=provisioninguser,dc=organisation,dc=com can read all values from the multi-valued attribute reqMod (which is what I want). >ldapsearch -D cn=provisioninguser,dc=organisation,dc=com -w 123 -b cn=accesslog reqDN=cn=user1,dc=organisation,dc=com reqMod dn: reqStart=20131227145130.000001Z,cn=accesslog reqMod: userPassword:= {SSHA}bmyaw8Xy1UftlTorPDQE9yLzruoxDnGq reqMod: topSecretAttribute:= topsecret reqMod: pwdChangedTime:= 20131227145130Z reqMod: entryCSN:= 20131227145130.917649Z#000000#000#000000 reqMod: modifiersName:= cn=admin reqMod: modifyTimestamp:= 20131227145130Z *if the acls 1 and 2 are on "olcDatabase={2}hdb,cn=config" and the 3rd one is on "olcDatabase={-1}frontend,cn=config" cn=provisioninguser,dc=organisation,dc=com can read only one value from the multi-valued attribute reqMod (why?). >ldapsearch -D cn=provisioninguser,dc=organisation,dc=com -w 123 -b cn=accesslog reqDN=cn=user1,dc=organisation,dc=com reqMod dn: reqStart=20131227145130.000001Z,cn=accesslog reqMod: userPassword:= {SSHA}bmyaw8Xy1UftlTorPDQE9yLzruoxDnGq Best regards, Marvin Mundry University of Hamburg Regional Computer Center (RRZ) Division Zentrale Dienste Schlueterstrasse 70 20146 Hamburg +49 (0)40 42838-9109

3 3

"LDAP Injection" attacks
by Howard Chu 29 Dec '13

29 Dec '13

A paper and presentation making the rounds, claiming to show how webapps using LDAP are vulnerable to search filter spoofing attacks. http://www.youtube.com/watch?v=wtahzm_R8e4 http://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper… Can't imagine that work like this gets peer-reviewed, because it's mostly garbage. They concoct a scenario in section 4.1.1 of their paper, supposedly showing how filter manipulation can allow a webapp user to bypass LDAP-based authentication. It's ridiculous drivel though, since LDAP-based authentication uses Bind requests and not search filters. Most LDAP deployments don't even give search/compare access to userPassword attributes in the first place. Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access. This is also why the old pam_ldap authorization scheme was such a bad idea, it relied on the LDAP client (pam_ldap) to correctly implement authorization, instead of the server. (Multiply that by hundreds or thousands of clients and you have an unmanageable, insecurable mess.) This is why we have nssov today. Of course, this is no excuse to be sloppy when writing your web apps. But if you've configured ACLs to adequately protect your data, then it doesn't matter how sloppy your clients are. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 9

write access issue
by Umar Draz 28 Dec '13

28 Dec '13

Hi I am trying to rename the (dn) entry through a normal user which is first authenticate it self, but I there is an error while renaming the dn entry text=no write access to old parent's children here is my slapd.conf access settings. # Sample access control policy: access to attrs=userPassword,shadowLastChange by self write by dn="cn=admin,dc=mydomain,dc=com" write by * auth access to * by self write by dn="cn=admin,dc=mydom,dc=com" write by * read Would you please help, what I need to set? Br. Umar

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