openldap-technical

openldap-technical@openldap.org

9868 discussions

View or filter based on ldaps://FQDN
by Ronie Gilberto Henrich 14 Jan '12

14 Jan '12

Hello, I need to be able to restrict ldap ou's access based on the ldaps://FQDN used to query the ldap server. Let say I have the following in my ldap server: ou=domain ou=raincoatcompany.com ou=umbrellacompany.com Considering that both ldap.raincoatcompany.com and ldap.umbrellacompany.com are resolving to IP address 10.0.0.10 So, querying the ldap server using ldaps://ldap.raincoatcompany.com/ou=domain should grant access only to the following: ou=domain ou=raincoatcompany.com Is there any way to accomplish that with OpenLDAP? Thanks, -- *Ronie Henrich* *GIT - Sistemas Ltda* <http://www.git.com.br> Novo Hamburgo, RS Brazil <http://maps.google.com/maps?q=%2CNovo+Hamburgo%2CRS%2CBrazil&hl=en> *http://br.linkedin.com/in/roniegh* See who we know in common <http://www.linkedin.com/e/wwk/11684020/>

5 7

Password Policy pwdFailureTime count limits?
by Jeffrey Crawford 14 Jan '12

14 Jan '12

Hello Everyone, I'm having trouble enforcing our password policy for login attempts within a particular time frame. After looking into the issue a little further it seems to stem from the fact that the operational attribute pwdFailureTime can only resolve time down to the second. so if there are three Bind attempts within a single second we only get a single pwdFailureTime entry for that time. Our policy is geared more to try and prevent brute force attacks since this instance of the ldap server will be available publicly. However someone can continuously try to bind and not lock the account for as many seconds as is defined in the pwdMaxFailure attribute in the policy definition. For example: if the following account locking configs are set pwdMaxFailure: 10 pwdFailureCountInterval: 3600 pwdLockout: TRUE pwdLockoutDuration: 30 If I try to lock my account by providing the incorrect credentials 11 times, it didn't lock if my 11 attempts were shorter than 10 seconds, I then tried 100 in a for loop which finished in 7 seconds, it still didn't lock. I looked at the account and counted the number of pwdFailureTime's and found 7. I then place a one second sleep between each bad bind attempt and low an behold it would lock as expected. Therefore there seems to be a limitation of pwdFailureTime to only resolve down to the second and its inability to store the same time multiple times. I'm not sure if this is expected behavior, but it makes locking policies against brute force attacks more difficult to fend against. I did a quick look to see if there was a way of delaying a incorrect credential bind so it wouldn't return for at least a second, but didn't see one. If such a config exists it might help if someone can point me to it. Thanks Jeffrey Crawford

2 1

Changing ACLs in dynamic configuration off-line
by Nick Milas 13 Jan '12

13 Jan '12

When we want to do some non-trivial re-engineering in ACLs, on-line configuration using ldapmodify might be cumbersome. So I think we could slapcat the config database, change ACLs in the output, and slapadd it while the server is offline. So, if we have a set of >100 ACL rules and we want to add one ACL rule after, say, 22, would we have to *manually* renumber all the ACLs after the new 23 so that they are numbered n+1? Or, when the config db is read, is OpenLDAP able to resolve such conflicts (two ACLs with the same number) and renumber automatically? If so, what is the logic? (Maintenance of ACLs in the dynamic configuration remains one of my concerns.) Thanks, Nick

2 1

Bind with alternative DN pattern
by Mathias 13 Jan '12

13 Jan '12

Hi, I have trouble understanding a rather simple LDAP config issue that I'm sure someone on this list can easily help with: How do I add a (or change the) pattern of the bind DN that slapd lets me authenticate with? I have a working slapd setup that I can happily bind to using DNs of the form "cn=Bob Parr,dc=example,dc=com". However, all accounts also have a unique "uid" attribute that I would like to use in addition to (or, if not possible, instead of) the "cn"-based RDN for binding. So, I'd like to (also) bind using the DN "uid=bob,dc=example,dc=com". My understanding is that one entry can have several DNs as long as each one is unambiguous. Shouldn't I be able to bind with anyone of these? I have spent hours on searching for documentation on this and turned up surprisingly little. The problem is not an ACL issue since the logged error when trying a "uid"-based bind is "DB_NOTFOUND: No matching key/data pair found" rather than anything else... I'd be _very_ grateful for any pointers on this... Cheers, Mathias

4 3

RE: How to check syncrepl?
by Juergen.Sprenger＠swisscom.com 13 Jan '12

13 Jan '12

Hi Marco, depending on Your needs this page might help: http://itsecureadmin.com/wiki/index.php/LDAP_Synchronization_Replication http://itsecureadmin.com/wiki/index.php/OpenLDAP_syncrepl_check Regards Jürgen

2 1

openldap admin guide and 'slapd from scratch'
by Stefan Skoglund 13 Jan '12

13 Jan '12

Howdy. I wonder if the ldif sample example the end of chapter 5 is correct ? See below: ---- 1. # example config file - global configuration entry 2. dn: cn=config 3. objectClass: olcGlobal 4. cn: config 5. olcReferral: ldap://root.openldap.org 6. Line 1 is a comment. Lines 2-4 identify this as the global configuration entry. The olcReferral: directive on line 5 means that queries not local to one of the databases defined below will be referred to the LDAP server running on the standard port (389) at the host root.openldap.org. Line 6 is a blank line, indicating the end of this entry. 7. # internal schema 8. dn: cn=schema,cn=config 9. objectClass: olcSchemaConfig 10. cn: schema 11. Line 7 is a comment. Lines 8-10 identify this as the root of the schema subtree. The actual schema definitions in this entry are hardcoded into slapd so no additional attributes are specified here. Line 11 is a blank line, indicating the end of this entry. 12. # include the core schema 13. include: file:///usr/local/etc/openldap/schema/core.ldif 14. Line 12 is a comment. Line 13 is an LDIF include directive which accesses the core schema definitions in LDIF format. Line 14 is a blank line. Next comes the database definitions. The first database is the special frontend database whose settings are applied globally to all the other databases. 15. # global database parameters 16. dn: olcDatabase=frontend,cn=config 17. objectClass: olcDatabaseConfig 18. olcDatabase: frontend 19. olcAccess: to * by * read 20. Line 15 is a comment. Lines 16-18 identify this entry as the global database entry. Line 19 is a global access control. It applies to all entries (after any applicable database-specific access controls). Line 20 is a blank line. The next entry defines the config backend. 21. # set a rootpw for the config database so we can bind. 22. # deny access to everyone else. 23. dn: olcDatabase=config,cn=config 24. objectClass: olcDatabaseConfig 25. olcDatabase: config 26. olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy 27. olcAccess: to * by * none 28. Lines 21-22 are comments. Lines 23-25 identify this entry as the config database entry. Line 26 defines the super-user password for this database. (The DN defaults to "cn=config".) Line 27 denies all access to this database, so only the super-user will be able to access it. (This is already the default access on the config database. It is just listed here for illustration, and to reiterate that unless a means to authenticate as the super-user is explicitly configured, the config database will be inaccessible.) ----- The trouble i had is regarding the olcDatabase=frontend and olcDatabase=config stanzas. slapadd could do its work but the layout in cn=config/ would look like this afterwards: ----- olcDatabase=frontent.ldif olcDatabase=config.ldif olcDatabase=hdb.ldif ----- And as soon as slapd started an extraneous ghostly olcDatabase={-1}frontend.ldif would show up. I had to instantiate the frontend and config as this. --- dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend --- and ---- dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config ---- Which works for me.

1 0

Modify or add information after conversion of slapd.conf to cn=config with fresh install of OpenLdap
by rey sebastien 13 Jan '12

13 Jan '12

Hi! I start with a fresh installation of openldap 2.4.28 on debian. They are some problem with the debian package, and with gnuTLS, so i compile a version with opennSSL library. It's hard to understand with the official documentation how to start a from scratch installation with the new cn=config administration of openLDAP. So, i make a conversion ( with the great help of users on this mailling list ) from slapd.conf to cn=config on the first launch of openLDAP with this commands : |/usr/local/libexec/slapd -u openldap -g openldap -f slapd.conf.seb -F /usr/local/etc/openldap/slapd.d/ -d -1 | My slapd.conf.seb, really simple, equal : |include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/gosa/samba3.schema include /usr/local/etc/openldap/schema/gosa/trust.schema include /usr/local/etc/openldap/schema/gosa/gofax.schema include /usr/local/etc/openldap/schema/gosa/gofon.schema include /usr/local/etc/openldap/schema/gosa/gosystem.schema include /usr/local/etc/openldap/schema/gosa/goto-mime.schema include /usr/local/etc/openldap/schema/gosa/goto.schema include /usr/local/etc/openldap/schema/gosa/goserver.schema include /usr/local/etc/openldap/schema/gosa/gosa-samba3.schema include /usr/local/etc/openldap/schema/gosa/openssh-lpk.schema include /usr/local/etc/openldap/schema/gosa/dnszone.schema include /usr/local/etc/openldap/schema/gosa/nagios.schema include /usr/local/etc/openldap/schema/gosa/dhcp.schema include /usr/local/etc/openldap/schema/gosa/sudo.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args database bdb suffix "dc=parisgeo,dc=cnrs,dc=fr" rootdn "cn=admin,cn=config,dc=parisgeo,dc=cnrs,dc=fr" rootpw {SSHA} secret directory /srv/openldap-data index objectClass eq | I have no problem with this simple conversion, but after that, it's impossible to import data with this command ldapadd or ldapmodify. I don't understand the default right for read/write for openLDAP, i try with ldapmodify, with bind and password, and i have the same problem : || |root@xxxx:/usr/local/etc/openldap# ldapadd -x -D "cn=admin,cn=config,dc=parisgeo,dc=cnrs,dc=fr" -W -f sauvegarde.ldif Enter LDAP Password: xxx adding new entry "cn=admin,dc=parisgeo,dc=cnrs,dc=fr" ldap_add: Constraint violation (19) additional info: structuralObjectClass: no user modification allowed | I try to modify the right for cn=config with this sample : |dn: olcDatabase={-1}frontend,cn=config changetype: modify delete: olcAccess dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootDN olcRootDN: cn=admin,cn=config dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {SSHA} secret dn: olcDatabase={0}config,cn=config changetype: modify delete: olcAccess ldapadd -Y EXTERNAL -H ldapi:/// -f slapd.modify.root.ldif | Same problem, i have no right todo that, with or without option the password entry -W or bind option -D "cn=config,cn=admin,dc=parisgeo,dc=cnrs,dc=fr" |root@xxxx:/usr/local/etc/openldap# ldapadd -Y EXTERNAL -H ldapi:/// -f slapd.modify.root.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Insufficient access (50) root@xxxx:/usr/local/etc/openldap# ldapadd -x -W -H ldapi:/// -f slapd.modify.root.ldif Enter LDAP Password: ldap_bind: Invalid credentials (49) root@xxxxx:/usr/local/etc/openldap# ldapadd -D "cn=config,cn=admin,dc=parisgeo,dc=cnrs,dc=fr" -W -Y EXTERNAL -H ldapi:/// -f slapd.modify.root.ldif Enter LDAP Password: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Insufficient access (50)| Anybody have this problem in the past, and have an idea of the solution to create a good start configuration from scratch installation ? Do you think there is mistake in my simple installation/configuration ? I also create a post on serverFault.Com site, but i have no answer at this time http://serverfault.com/questions/342086/impossible-to-modify-or-add-informa… Best regards, SR

3 3

RE: OpenLDAP replciation issue with MirrorMode
by ZHOU Eric JP 13 Jan '12

13 Jan '12

Dear OpenLDAP Administrators, Not sure if you get time to look into this issue yet. This issue only happens when power-off/power cut-off one of the mirror servers, and could be probably prevented by “sending heart beat” to verify the established connections. Thanks for your time looking at this email thread and your effort :) Thanks, Eric ________________________________ From: owner-qdlcp-security(a)LIST.ALCATEL-LUCENT.COM [mailto:owner-qdlcp-security@LIST.ALCATEL-LUCENT.COM] On Behalf Of ZHOU Eric JP Sent: 2012年1月4日 15:56 To: openldap-bugs(a)openldap.org; info(a)OpenLDAP.org; openldap-technical(a)openldap.org; openldap-devel(a)openldap.org Cc: qdlcp-security(a)list.alcatel-lucent.com; ANTHONY Michael; HO Yao; VAN RANGELROOIJ Ardo Subject: OpenLDAP replciation issue with MirrorMode Dear OpenLDAP Administrators, Recently we come across an OpenLDAP replication issue with OpenLDAP Mirror Mode. After configuring MIRROR-A and MIRROR-B in mirror mode with below configuration, it worked pretty well for a long period. But an issue comes up after MIRROR-A reboot, MIRROR-B could not get modification from MIRROR-A any more. After investigating the issue we find the original socket on MIRROR-B (consumer) is not reconnected. ==================================== ## MIRROR-A ---------------------------------------------------------------------- ## ---------------------------------------------------------------------- serverID 1 ## Consumer syncrepl rid=001 provider=ldap://10.207.131.1:389 bindmethod=simple binddn="uid=PrivDirUsr,o=CSOSSO" credentials=mypassword searchbase="o=CSOSSO" schemachecking=on type=refreshAndPersist interval=00:00:01:00 retry="10 +" mirrormode on ## MIRROR-A ---------------------------------------------------------------------- ## ---------------------------------------------------------------------- serverID 2 ## Consumer syncrepl rid=001 provider=ldap://10.207.130.1:389 bindmethod=simple binddn="uid=PrivDirUsr,o=CSOSSO" credentials=mypassword searchbase="o=CSOSSO" schemachecking=on type=refreshAndPersist interval=00:00:01:00 retry="10 +" mirrormode on Below is the socket information after MIRROR-A reboot, ==================================== ## MIRROR-A ---------------------------------------------------------------------- # lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10 slapd 16842 root 14u IPv4 36160 TCP ln007-cnfg-p00m000-d0:51114->10.207.131.1:ldap (ESTABLISHED) ## MIRROR-B ---------------------------------------------------------------------- # lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10 slapd 4825 root 14u IPv4 168497 TCP ln007-cnfg-p00m001-d0:52239->10.207.131.0:ldap (ESTABLISHED) slapd 4825 root 18u IPv4 193403 TCP ln007-mi-p00m001-d0:ldap->10.207.130.0:51114 (ESTABLISHED) Normally it should be, ## MIRROR-A ---------------------------------------------------------------------- # lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10 slapd 16842 root 14u IPv4 36160 TCP ln007-cnfg-p00m000-d0:51114->10.207.131.1:ldap (ESTABLISHED) slapd 4825 root 18u IPv4 193403 TCP ln007-mi-p00m000-d0:ldap->10.207.130.1: 52239 (ESTABLISHED) // This link is missing ## MIRROR-B ---------------------------------------------------------------------- # lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10 slapd 4825 root 14u IPv4 168497 TCP ln007-cnfg-p00m001-d0:52239->10.207.131.0:ldap (ESTABLISHED) slapd 4825 root 18u IPv4 193403 TCP ln007-mi-p00m001-d0:ldap->10.207.130.0:51114 (ESTABLISHED) I would greatly apreicate if you could provide some suggestions/comments upon this or improve OpenLDAP functionality to avoid this. For me I think this is normal TCP server down scenario, but probably you people could prohibit this from happening in below two methods? 1. Let OpenLDAP send mutual heart beat so that client knows when server is dead. 2. Let OpenLDAP send message to all its client when it is dying (e.g. receiving SIGTERM) // this does not work when MIRROR-A power cycle. Sincerely, Eric Zhou Jianping P please save a tree by not printing this e-mail. ________________________________ To unsubscribe: qdlcp-security-unsubscribe-request(a)list.alcatel-lucent.com<mailto:qdlcp-security-unsubscribe-request@list.alcatel-lucent.com>

5 4

Copy ldap to another with different schema
by rey sebastien 13 Jan '12

13 Jan '12

Hi, I have two ldap, one full of users, with gosa open source project specific schema (https://oss.gonicus.de/labs/gosa), and one which is empty, without this schema. I want to make a clean copy of my users into the first ldap to the second ldap, because my version of gosa installed is not functionnal :-/ Is it possible with slapcat to extract only useful information (so information without gosa schema information) ? Is there any solution to resolve this use case ? Thanks a lot, Best regards, SR

1 0

Interacting with LDAP via Python module
by Munroe Sollog 13 Jan '12

13 Jan '12

I'm experimenting with Python and its ability to interact with ldap. I wrote a program that is taking a DiT from one server and altering it a bit and writing to another server: http://bpaste.net/show/3nd2N4jQqNIHbPMKbgkb/ The error is at the bottom of the pastebin, I'm not really sure where the problem is.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical