openldap-technical

openldap-technical@openldap.org

9956 discussions

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

Implementing password policy
by Laurent CARON 10 Jan '12

10 Jan '12

Hi, I'm currently implementing a password policy on my openldap directory. Most of it is working (password length, password history). I just can't make the account lockout work. The attribute pwdAccountLockedTime is never created in my directory. Entries used for the test: dn: cn=lcaron_99,ou=ppolicy,dc=local sn: lcaron_99 pwdCheckQuality: 0 pwdMaxFailure: 3 pwdAllowUserChange: TRUE pwdInHistory: 10 pwdLockout: TRUE pwdMinLength: 8 structuralObjectClass: person pwdExpireWarning: 720000 pwdGraceAuthNLimit: 5 cn: lcaron_99 pwdAttribute: userPassword objectClass: pwdPolicy objectClass: person objectClass: top pwdMaxAge: 10 pwdFailureCountInterval: 1200 pwdLockoutDuration: 3600 modifyTimestamp: 20120106194803Z dn: uid=lcaron_99,ou=People,dc=local objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: sambaSamAccount cn: lcaron_99 sn: lcaron_99 uid: lcaron_99 uidNumber: 4082 gidNumber: 513 homeDirectory: /home/lcaron_99 loginShell: /bin/bash ...samba attributes snipped ... userPassword:: ...snipped... pwdPolicySubentry: cn=lcaron_99,ou=ppolicy,dc=local pwdChangedTime: 20120106193917Z structuralObjectClass: inetOrgPerson creatorsName: cn=admin,dc=local createTimestamp: 20120106193917Z pwdFailureTime: 20120106193928Z pwdFailureTime: 20120106194040Z entryCSN: 20120106194040.970726Z#000000#000#000000 modifiersName: modifyTimestamp: 20120106194040Z in slapd.conf: # Password Policy overlay ppolicy Did I miss something obvious ? Thanks

3 5

pam_check_host_attr
by Michael Starling 10 Jan '12

10 Jan '12

I'm unable to get host checking to work. I have followed what I think are the correct steps but I still get "Access denied for this host" when I specify a server or the * wildcard for all servers. The hostname command returns cadb5 so host lookups are working. Do you actually need a full blown DNS solution rather than host files to get this working? RHEL 5.5 openldap-2.3.43-12.el5_6.7 nss_ldap-253-37.el5_6.1 /etc/openldap/slapd.conf include /etc/openldap/schema/ldapns.schema /etc/ldap.conf pam_check_host_attr yes The users account has the hostObject class and the host attribute: dn: uid=testuser,ou=admins,ou=ORG,ou=people,dc=test,dc=lott objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: sambaSamAccount objectClass: hostObject cn: testuser sn: testuser givenName: testuser uid: testuser uidNumber: 1002 gidNumber: 512 homeDirectory: /home/testuser loginShell: /bin/bash gecos: Infrastructure Engineer structuralObjectClass: inetOrgPerson entryUUID: 79bc2d6e-7f0b-1030-9efe-3f6966a39ce0 creatorsName: cn=root,dc=test,dc=lott createTimestamp: 20110929172322Z sambaLogonTime: 0 sambaLogoffTime: 2147483647 sambaKickoffTime: 2147483647 sambaPwdCanChange: 0 displayName: mphan sambaSID: S-1-5-21-590332452-794431873-1853597743-3004 sambaPrimaryGroupSID: S-1-5-21-590332452-794431873-1853597743-512 sambaLogonScript: logon.bat sambaProfilePath: \\FTP3\profiles\testuser sambaHomePath: \\FTP3\testuser sambaHomeDrive: H: sambaLMPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx sambaAcctFlags: [U] sambaNTPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx sambaPwdLastSet: 1326133136 sambaPwdMustChange: 1333909136 userPassword:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx shadowLastChange: 15348 shadowMax: 90 pwdChangedTime: 20120109181856Z pwdHistory: 20120109181856Z#1.3.6.1.4.1.1466.115.121.1.40#8#{crypt}x host: cadb5 entryCSN: 20120109193817Z#000000#00#000000 modifiersName: uid=ldapmgr,ou=people,dc=test,dc=lott modifyTimestamp: 20120109193817Z Relevant system-auth file: auth required pam_env.so auth sufficient pam_ldap.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 password sufficient pam_unix.so shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so session required pam_mkhomedir.so skel=/etc/skel umask=0027

1 2

How to setup bindmethod=sasl
by Gaurav Gugnani 10 Jan '12

10 Jan '12

Hello All, I need to setup the encrypted password for replicator user in the slapd.conf Currently we have setup the replication process, however it is using: bindmethod=simple credentials=[password] But the requirement is like: that we want to specify encrypted password at credentials column. I know this can be achieved with bindmethod=sasl etc. I tried lot but got stuck with some or the other thing and ends up getting error at last. Can we have some document explaining step-by-step how to achieve it? Or some document putting more light on this issue? Thanks for your support. Regards, Gaurav Gugnani Version of OpenLdap - 2.4.26

1 0

ldif_back_add: err: 68 text:
by Maxim Vetrov 08 Jan '12

08 Jan '12

Hi! Trying to start test server (openldap 2.4.25) on my home box (FreeBSD 8.2 i386) I get this error: ... ldif_back_add: "olcDatabase={0}config,cn=config" oc_check_required entry (olcDatabase={0}config,cn=config), objectClass "olcDatabaseConfig" oc_check_allowed type "objectClass" oc_check_allowed type "olcDatabase" oc_check_allowed type "olcAddContentAcl" oc_check_allowed type "olcLastMod" oc_check_allowed type "olcMaxDerefDepth" oc_check_allowed type "olcReadOnly" oc_check_allowed type "olcRootDN" oc_check_allowed type "olcSyncUseSubentry" oc_check_allowed type "olcMonitoring" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=68 matched="" text="" slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. Config I use: # global configuration entry dn: cn=config objectClass: olcGlobal cn: config olcAttributeOptions: x-hidden lang- olcLogLevel: conns config acl # internal schema dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/etc/openldap/schema/core.ldif include: file:///usr/local/etc/openldap/schema/cosine.ldif include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif #include: file:///usr/local/etc/openldap/schema/collective.ldif include: file:///usr/local/etc/openldap/schema/nis.ldif # Load modules for database type dn: cn=module,cn=config objectclass: olcModuleList cn: module olcModulePath: /usr/local/libexec/openldap olcModuleLoad: back_bdb.so # global database parameters dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcAccess: to attrs=name;x-hidden by * =cs olcAccess: to attrs=userPassword by * auth olcAccess: to * by * read dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootPW: {SSHA}PHExDMWET41b/KoOHyTY1finE7Em3Xdo olcAccess: to * by * none # BDB definition for muxas.net dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=muxas,dc=net olcDbDirectory: /home/ldap/databases/muxas.net olcRootDN: cn=Administrator,ou=Users,dc=muxas,dc=net olcDbIndex: cn,sn,uid pres,eq,approx,sub olcDbIndex: objectClass eq olcAccess: to attrs=userPassword by self write by anonymous auth by * none olcAccess: to * by self write by * read I'm new to openldap software, so I have no guess what's the reason behind the error. I googled that error 68 means that there is duplicate entry in the DIT but there is no text part in the message so I don't know what entry is causing the error. Any help would be greatly appreciated! Maxim

2 3

OpenLDAP 2.4.28 RPMs for CentOS 5 and CentOS 6
by Clément OUDOT 06 Jan '12

06 Jan '12

Hi, I just published new versions of OpenLDAP 2.4.28 RPMs, for CentOS 5 and CentOS 6, see http://ltb-project.org/wiki/download#openldap They include a new version of init script in which I added two commands: # service slapd backupconfig # service slapd restoreconfig This allows to dump your cn=config, edit it and reload it very quick. Hope it helps, Clément.

1 0

misconfigured read-only replica causes master slapd to crash
by Kevan Carstensen 05 Jan '12

05 Jan '12

Hi, We use a single master and two read-only replicas; we use back-bdb on all systems. Each read-only replica replicates from the master with syncrepl, configured to refreshAndPersist. During a particularly heavy update load recently, replication on one of the read-only replicas started to fail due to a misconfigured DB_CONFIG. The replica wrote the following messages to its log repeatedly: Dec 14 04:01:08 pip-dev slapd[12645]: bdb(dc=csupomona,dc=edu): Lock table is out of available lock entries Dec 14 04:01:08 pip-dev slapd[12645]: => bdb_idl_delete_key: c_get failed: Cannot allocate memory (12) Dec 14 04:01:08 pip-dev slapd[12645]: conn=-1 op=0: attribute "memberUid" index delete failure Dec 14 04:01:08 pip-dev slapd[12645]: null_callback : error code 0x50 Dec 14 04:01:08 pip-dev slapd[12645]: syncrepl_entry: rid=001 be_modify failed (80) Dec 14 04:01:08 pip-dev slapd[12645]: do_syncrepl: rid=001 rc 80 retrying as it tried and failed to start replication again. Shortly after, the master slapd crashed, writing nothing to its log indicating why (or even referencing the crash at all). We initially noticed this behavior with a 2.4.26 master and a 2.4.28 read-only replica (we came upon this problem while performing some maintenance, which is why there's a version mismatch). I reproduced the problem on a 2.4.28 master while researching ITS #7113 [1] (which describes this problem more precisely and in more detail). Has anyone else run into this issue? Is there a good way to insulate the master slapd from misconfigured replicas? Our replicas shouldn't break like this (we've tuned our DB_CONFIG to ensure that they don't in the future), and hopefully slapd can be modified so that the master doesn't crash even if replicas do break, but we'd rather not have to worry about our master crashing if our DB_CONFIG proves inadequate in the meantime. [1] http://www.openldap.org/its/index.cgi/Incoming?id=7113 Thanks for any help, -- Kevan Carstensen <kacarstensen(a)csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

3 2

Re: Issue with index in OpenLDAP?
by External Mathieu DEDECKER (CAMPUS) 05 Jan '12

05 Jan '12

Hi Quanah and thank you again for your quick reply, I did not deleted the *.bdb files, but I moved them in a backup folder. My /db folder was empty, but the slapindex command failed because both "dn2id.bdb" and "id2entry.bdb" files was not present. I needed to add them in the /db folder in order to run the slapindex command. Then, all index have been re-generated. After the reindexation, the "cardnumber.bdb" file had the same size than before. Could you confirm me that it's the best process to reindex an OpenLDAP? Thank you, Mathieu 2012/1/5 Quanah Gibson-Mount <quanah(a)zimbra.com> > Hi Mathieu, > > It sounds like you didn't delete the cardnumber.bdb file before > reindexing? That is what I'd have done. > > Also, you previously had some questions about OpenLDAP tuning. You may > wish to read over <http://wiki.zimbra.com/wiki/** > OpenLDAP_Performance_Tuning<http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning>>. > Some of the bits in there have Zimbra specific names, but they all apply > directly to OpenLDAP and BDB in general. > > --Quanah > > > --On Wednesday, January 04, 2012 2:46 PM +0100 "External Mathieu DEDECKER > (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: > > I will read the man page in order to have more informations about the >> command. >> >> I tried to reindex all the index of the database with the slapindex >> command, but I allways the same behaviour: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> Other .bdb files size have been updated, but my "cardnumber.bdb" has >> still the same size. >> >> Regards, >> >> Mathieu >> >> >> 2012/1/4 Quanah Gibson-Mount <quanah(a)zimbra.com> >> >> Hi Mathieu, >> >> If you read the slapindex man page, it is possibly to just recreate a >> specific index file (for situations like this), rather than generating >> all of them. >> >> --Quanah >> >> >> --On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu >> DEDECKER (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: >> >> >> >> Hello Quanah, >> >> First I would like to thank you for your answer. >> >> Indeed, I also think that the "cardnumber" index is somehow corrupted. >> His size is to small in comparison to other indexes >> >> We suppressed all existing index and Used slapindex to re-create them all. >> >> It's undergoing. >> >> I will keep you informed about the solution. >> >> Best Regards, >> >> Mathieu >> >> >> 2012/1/3 Quanah Gibson-Mount <quanah(a)zimbra.com> >> >> >> >> >> >> --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER >> (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: >> >> >> Hi @All, >> >> We meet a performance problem with our OpenLDAP. >> >> We think that we face a problem with the index of the database, and we >> think that the problem can be resolve by tunning the config (but not >> sure). >> >> We would like to be sure that our configuration is correct, in order to >> confirm if we are on a wrong track or not. >> >> [Description] >> >> We have an attribute (cardNumber) which is indexed. >> >> When we request the indexed attribute (cardNumber) with an LDAP Client >> (Ldapbrowser), we have either fast or very long response time. >> >> For the long response time, the CPU of the server hits 100%. >> >> For example: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> By checking the hit ratio of the attribute, we can see that cache is >> correctly used (97%). >> >> >> It sounds like you added an index to cardnumber after there was already >> data for cardnumber in your database, and didn't run slapindex for that >> attribute. Alternatively, your cardnumber.bdb file is corrupted. >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> >> >> >> >> >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

problem with authentication to AD server with translucent overlay
by juhlig 05 Jan '12

05 Jan '12

I am using openldap 2.4.23-20 on Centos 6.2 server and trying to configure the translucent overlay to do simple user/password authentication (or anything that works) to our Microsoft AD servers. I can do authenticated commandline ldap searches with a Windows test account and password with no problems. I have tried to build a config based on the examples in the openldap admin and faq-o-matic web pages without success. All I get from the AD servers through my server are anonymous bind results. If anyone has this working, I would appreciate any information or config file samples as I need to deploy the server ASAP. thanks, John. p.s. I am not including my config files (ldap.conf,slapd.conf,etc.) as they are essentially copies of the ones from the openldap website. However, if you wish to see them, I can reply with the latest of 100 iterations :(

1 0

Re: Issue with index in OpenLDAP?
by External Mathieu DEDECKER (CAMPUS) 05 Jan '12

05 Jan '12

I will read the man page in order to have more informations about the command. I tried to reindex all the index of the database with the slapindex command, but I allways the same behaviour: Request1: cardnumber=2098001010034 (less than 1sec) Request2: cardnumber=2090389917486 (nearly 20 sec). Other .bdb files size have been updated, but my "cardnumber.bdb" has still the same size. Regards, Mathieu 2012/1/4 Quanah Gibson-Mount <quanah(a)zimbra.com> > Hi Mathieu, > > If you read the slapindex man page, it is possibly to just recreate a > specific index file (for situations like this), rather than generating all > of them. > > --Quanah > > > --On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu DEDECKER > (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: > > Hello Quanah, >> >> First I would like to thank you for your answer. >> >> Indeed, I also think that the "cardnumber" index is somehow corrupted. >> His size is to small in comparison to other indexes >> >> We suppressed all existing index and Used slapindex to re-create them all. >> >> It's undergoing. >> >> I will keep you informed about the solution. >> >> Best Regards, >> >> Mathieu >> >> >> 2012/1/3 Quanah Gibson-Mount <quanah(a)zimbra.com> >> >> >> --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER >> (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: >> >> >> Hi @All, >> >> We meet a performance problem with our OpenLDAP. >> >> We think that we face a problem with the index of the database, and we >> think that the problem can be resolve by tunning the config (but not >> sure). >> >> We would like to be sure that our configuration is correct, in order to >> confirm if we are on a wrong track or not. >> >> [Description] >> >> We have an attribute (cardNumber) which is indexed. >> >> When we request the indexed attribute (cardNumber) with an LDAP Client >> (Ldapbrowser), we have either fast or very long response time. >> >> For the long response time, the CPU of the server hits 100%. >> >> For example: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> By checking the hit ratio of the attribute, we can see that cache is >> correctly used (97%). >> >> >> It sounds like you added an index to cardnumber after there was already >> data for cardnumber in your database, and didn't run slapindex for that >> attribute. Alternatively, your cardnumber.bdb file is corrupted. >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

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