openldap-technical

openldap-technical@openldap.org

7 participants
9965 discussions

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 12 Jan '12

12 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

How to check syncrepl?
by Marco Weber 12 Jan '12

12 Jan '12

Hi, We have a MirrorMode replication setup that uses openldap's syncrepl. The HA setup seems work fine with pacemaker. Now i would like to setup a nagios check for the replication. But before i can do that, i've got a simple question: How can i poll the replication status? Thanks in advance for any reply, Marco

2 1

Disabling SASL auth at server side
by Angel L. Mateo 12 Jan '12

12 Jan '12

Hello, I have an application I need to authenticate in my LDAP server. The problem I have is that this application is trying to authenticate its user (to search for user DNs) with SASL although I haven't configured SASL in my LDAP server. More detailed, the application does: * First, it checks for supported mechanisms with a search like: Jan 11 12:13:28 canis13 slapd[22380]: conn=41690 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Jan 11 12:13:28 canis13 slapd[22380]: conn=41690 op=0 SRCH attr=supportedSASLMechanisms Jan 11 12:13:28 canis13 slapd[22380]: conn=41690 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= * This search gets supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: NTLM * Then it tries to bind using a SASL mechanism that I haven't configured. With older version of openldap (2.3.30, debian etch version) I didn't have any problem because this search returns no result. Now I'm using openldap 2.4.21 (ubuntu lucid version) and I get this behaviour. Is there any way to configure the openldap server to disable this mechanisms?, because I don't want any sasl authentication. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

4 3

OpenLDAP Meta-Backend & Active Directory
by Seale, Ryan 10 Jan '12

10 Jan '12

I'm running OpenLDAP 2.3.43 and have a copy of OpenLDAP 2.4 installed on another server to test with. I'm not sure which is better for this. I'm trying to simplify LDAP structure and group authorized users into a few sub-OUs and have decided that OpenLDAP and a meta-backend is the way to proxy AD. My problem is I'm hitting some snags and need some help from an expert. Our AD users are structured as ou=employees,dc=org,dc=com and ou=clients,dc=org,dc=com. I basically just want to proxy them to be: ou=employees,ou=users,O=org and ou=clients,ou=users,o=org and move away from the dc naming convention for clarification of which system we're authenticating to. # settings for clients database meta suffix "ou=clients,dc=org,dc=com" subordinate uri "ldap://ldap/ou=clients,dc=org,dc=com" suffixmassage " ou=clients,dc=org,dc=com" "ou=clients,ou=Users,o=org" rewriteEngine on RewriteRule "sAMAccountName=(.*)ou=clients,dc=org,dc=com$" "%1ou=clients,ou=Users,o=org" ":" rebind-as-user true chase-referrals yes # settings for employees database meta suffix "ou= employees,dc=org,dc=com" subordinate uri "ldap://ldap/ou= employees,dc=org,dc=com" suffixmassage " ou= employees,dc=org,dc=com" "ou= employees,ou=Users,o=org" rewriteEngine on RewriteRule "sAMAccountName=(.*)ou= employees,dc=org,dc=com$" "%1ou= employees,ou=Users,o=org" ":" rebind-as-user true chase-referrals yes #primary database meta suffix "dc=org,dc=com" uri "ldap://jcdc1.etsu.edu/dc=org,dc=com" suffixmassage "dc=org,dc=com" "ou=Users,o=org" rewriteEngine on RewriteRule "sAMAccountName=(.*)dc=org,dc=com$" "%1ou=Users,o=org" ":" rebind-as-user true chase-referrals yes I also have a local bdb database for o=org. I can connect to the ldap server using a local account that exists in the bdb database, but cannot connect as a user that exists in the proxied ldaps. For example, if I pass credentials of cn=user,ou=employees,ou=users,o=org....I get auth failures. Can anyone shed a little light on the subject? In testing, I was able to struggle and get a similar configuration working with an ldap backend, but it wouldn't allow me to connect to more than one container and I wasn't willing to do a blanket LDAP search. Thanks, -Ryan

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical