openldap-technical

openldap-technical@openldap.org

9868 discussions

Notes on virtual views
by Vladislav Nespor 01 Jun '10

01 Jun '10

I have tried to create virtual views of existing local data and I have realized that the rewrite/remap overlay (slapo-rwm) in conjunction with the relay backend (slapd-relay) (both are experimental) does not exactly do what I would like to have. To explain the problem, let me consider the following hypothetical situation. We have two groups of UNIX clients. All clients should be accessed by the same set of users having different user ID on each client group. In addition, it would be nice to have different user passwords for each client group. In the local schema, we define two new attributes xxxUidNumber and xxxUserPassword, and a new object class xxxPosixAccount holding them. The local.schema file, the initial slapd.conf file (OpenLDAP 2.4.22), and the real data ldif file are at the end of this email. The real data are in 'ou=users,ou=auth,o=example', and the virtual view is in 'ou=xxxUsers,ou=auth,o=example'. 1 The search problem ==================== Here are some queries and results to demonstrate it: Real data: ---------- Search request A ~~~~~~~~~~~~~~~~ /usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \ -D "cn=ldap_manager,ou=auth,o=example" \ -w qwerty \ -b 'cn=user10,ou=users,ou=auth,o=example' dn: cn=user10,ou=users,ou=auth,o=example objectClass: top objectClass: person objectClass: posixAccount objectClass: xxxPosixAccount cn: user10 sn: user10 uid: user10 uidNumber: 1111 xxxUidNumber: 2222 gidNumber: 3333 homeDirectory: /tmp loginShell: /bin/tcsh gecos: User 10 userPassword:: e1NTSEF9QWlmMWtyQXhkRGQ3bHJ5amp6VzFoTUgxOFdVU01BPT0= xxxUserPassword: {SSHA}BaPK4xvEKVpYwj3qK0zbOWpVOAwSMA== Virtual view: ------------- Search request B ~~~~~~~~~~~~~~~~ /usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \ -D "cn=ldap_manager,ou=auth,o=example" \ -w qwerty \ -b 'cn=user10,ou=xxxUsers,ou=auth,o=example' dn: cn=user10,ou=xxxUsers,ou=auth,o=example objectClass: top objectClass: person objectClass: posixAccount objectClass: xxxPosixAccount cn: user10 sn: user10 uid: user10 uidNumber: 1111 uidNumber: 2222 gidNumber: 3333 homeDirectory: /tmp loginShell: /bin/tcsh gecos: User 10 userPassword:: e1NTSEF9QWlmMWtyQXhkRGQ3bHJ5amp6VzFoTUgxOFdVU01BPT0= userPassword:: e1NTSEF9QmFQSzR4dkVLVnBZd2ozcUswemJPV3BWT0F3U01BPT0= The rewrite/remap part in slapd.conf was as follows: overlay rwm rwm-suffixmassage "ou=users,ou=auth,o=example" rwm-map attribute userPassword xxxUserPassword rwm-map attribute uidNumber xxxUidNumber Because of the simple mapping, the reply contains uidNumber and userPassword attributes two times. To eliminate this, we modify the rewrite/remap part in slapd.conf: overlay rwm rwm-suffixmassage "ou=users,ou=auth,o=example" rwm-map attribute userPassword xxxUserPassword rwm-map attribute userPassword rwm-map attribute uidNumber xxxUidNumber rwm-map attribute uidNumber Now the answer from the previous search request (B) seems to be as desired: dn: cn=user10,ou=xxxUsers,ou=auth,o=example objectClass: top objectClass: person objectClass: posixAccount objectClass: xxxPosixAccount cn: user10 sn: user10 uid: user10 uidNumber: 2222 gidNumber: 3333 homeDirectory: /tmp loginShell: /bin/tcsh gecos: User 10 userPassword:: e1NTSEF9QmFQSzR4dkVLVnBZd2ozcUswemJPV3BWT0F3U01BPT0= But the next search request returns values, although one would expect an empty result set, as the attribute xxxUidNumber (used in the filter) is not explicitly present in the virtual view (it is mapped): Search request C ~~~~~~~~~~~~~~~~ /usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \ -D "cn=ldap_manager,ou=auth,o=example" \ -w qwerty \ -b 'ou=xxxUsers,ou=auth,o=example' \ '(xxxUidNumber=*)' dn: cn=user10,ou=xxxUsers,ou=auth,o=example objectClass: top objectClass: person objectClass: posixAccount objectClass: xxxPosixAccount cn: user10 sn: user10 uid: user10 uidNumber: 2222 gidNumber: 3333 homeDirectory: /tmp loginShell: /bin/tcsh gecos: User 10 userPassword:: e1NTSEF9QmFQSzR4dkVLVnBZd2ozcUswemJPV3BWT0F3U01BPT0= I think the attribute xxxUidNumber should be removed from the internal query to the foreign data set, because it is used as a foreign name (and in the same time not as a local name) in the mapping, and the query (C) above should return an empty result set. One can improve this by modifying the rewrite/remap part in slapd.conf as follows: overlay rwm rwm-suffixmassage "ou=users,ou=auth,o=example" rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute uid * rwm-map attribute gidNumber * rwm-map attribute homeDirectory * rwm-map attribute loginShell * rwm-map attribute gecos * rwm-map attribute userPassword xxxUserPassword rwm-map attribute uidNumber xxxUidNumber rwm-map attribute * Now both search requests (B and C) work as expected. The last remap line correctly removes everything what is not mapped. The problem here is that one has to explicitly list all desired attributes in the remap configuration. If a new attribute is added to the real data, it would not show in the result set without a change in the remap configuration. 2 The authentication problem ============================ The following two bind request use the same password for authentication, regardless of the mapping and the value of the attribute xxxUserPassword. /usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \ -D "cn=user10,ou=users,ou=auth,o=example" \ -w abc123 \ -b 'cn=user10,ou=users,ou=auth,o=example' dn dn: cn=user10,ou=users,ou=auth,o=example /usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \ -D "cn=user10,ou=xxxUsers,ou=auth,o=example" \ -w abc123 \ -b 'cn=user10,ou=xxxUsers,ou=auth,o=example' dn dn: cn=user10,ou=xxxUsers,ou=auth,o=example If we use the userPassword (xyz789), reported by the view (e.g. query B), the bind request returns 'Invalid credentials'. If I understand it correctly, this is not a bug. The LDAP bind request does not contain the name of the attribute holding the user password at the server site, so there is (unfortunately) nothing to map. There are many real life situations where, for security reasons, it would be desirable to have different passwords for different applications, or groups of applications/clients (e.g. web access, UNIX login, etc.). Unfortunately, it seems the present virtual views (slapo-rwm + slapd-relay) cannot solve it. For the moment, I see only one possibility -- to create a copy of the user entries and to modify the userPassword attribute. (Please let me know, if you know a better solution.) But there are disadvantages connected with this approach, for example the maintenance of the data consistency, large indices, etc. My question is -- would it be possible to solve the password mapping in the OpenLDAP software? For example, (i) to extend the structure holding the bind request data to include an attribute name, (ii) to initialise its value to 'userPassword', (iii) to allow slapo-rwm to rewrite/remap it, and then (iv) to use the new value of the attribute name for the internal user password verification. With best regards, Vlado ------------------------------------------------------------------------- local.schema: ============= attributetype ( 1.3.6.1.4.1.9999.2.1.102 NAME 'xxxUidNumber' DESC 'An integer uniquely identifying a user in an administrative domain (XXX private)' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype ( 1.3.6.1.4.1.9999.2.1.105 NAME 'xxxUserPassword' DESC 'RFC2256/2307: password of user (XXX private)' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) objectclass ( 1.3.6.1.4.1.9999.2.2.10 NAME 'xxxPosixAccount' DESC 'Abstraction of an account with POSIX attributes (XXX private)' SUP top AUXILIARY MAY ( xxxUidNumber $ xxxUserPassword ) ) slapd.conf: =========== include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /etc/openldap/local.schema pidfile /var/openldap/slapd.pid argsfile /var/openldap/slapd.args loglevel 256 TLSCertificateFile /etc/openldap/xxx_cert.pem TLSCertificateKeyFile /etc/openldap/xxx_key.pem TLSRandFile /var/run/prngd-socket TLSCACertificateFile /etc/openldap/yyy_cacert.pem database relay suffix "ou=xxxUsers,ou=auth,o=example" subordinate overlay rwm rwm-suffixmassage "ou=users,ou=auth,o=example" rwm-map attribute userPassword xxxUserPassword rwm-map attribute uidNumber xxxUidNumber database hdb suffix "ou=auth,o=example" directory /var/openldap/hdb rootdn "cn=ldap_manager,ou=auth,o=example" rootpw {SSHA}jN4XaG5UmYFwpY/47aW0nLralRwSMA== dbconfig set_cachesize 0 268435456 0 dbconfig set_flags DB_TXN_NOSYNC dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lk_max_locks 3000 dbconfig set_lk_max_lockers 3000 dbconfig set_lk_max_objects 3000 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /var/log/hdb dbconfig set_tmp_dir /tmp Real data: ========== dn: ou=auth,o=example objectClass: top objectClass: organizationalUnit ou: auth dn: ou=users,ou=auth,o=example objectClass: top objectClass: organizationalUnit ou: users dn: cn=user10,ou=users,ou=auth,o=example objectClass: top objectClass: person objectClass: posixAccount objectClass: xxxPosixAccount cn: user10 sn: user10 uid: user10 uidNumber: 1111 xxxUidNumber: 2222 gidNumber: 3333 homeDirectory: /tmp loginShell: /bin/tcsh gecos: User 10 # abc123 userPassword: {SSHA}Aif1krAxdDd7lryjjzW1hMH18WUSMA== # xyz789 xxxUserPassword: {SSHA}BaPK4xvEKVpYwj3qK0zbOWpVOAwSMA==

1 0

Re: Q: status of component matching?
by Lehnert, Hartmut 31 May '10

31 May '10

Hi all! To avoid the slapd's core dump when using component match filters (see ITS # 6556) I removed line 556 of file "servers/slapd/filter.c": case LDAP_FILTER_EXT: //mra_free( op, f->f_mra, 1 ); break; Now component match filter search requests are answered by slapd but don't work correctly. In fact nothing is found! For example the request /home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p 9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s sub "(userCertificate:componentFilterMatch:=item:{ component \"toBeSigned.serialNumber\", rule allComponentsMatch, value 449 })" sncertnr Is answered with # extended LDIF # # LDAPv3 # base <o=CustomerCA,c=de> with scope subtree # filter: (userCertificate:componentFilterMatch:=item:{ component "toBeSigned.serialNumber", rule allComponentsMatch, value 449 }) # requesting: sncertnr # # search result search: 2 result: 0 Success # numResponses: 1 But in the database of slapd there are several certificates with serialNumber 449: lehnert.hartmut@sn-ocspr4:/opt/lehnert/Openldap-Support$ ./dumpasn1 449.cer 0 30 702: SEQUENCE { 4 30 551: SEQUENCE { 8 A0 3: [0] { 10 02 1: INTEGER 2 : } 13 02 2: INTEGER 449 17 30 13: SEQUENCE { 19 06 9: OBJECT IDENTIFIER : sha256WithRSAEncryption (1 2 840 113549 1 1 11) 30 05 0: NULL : } 32 30 111: SEQUENCE { 34 31 11: SET { 36 30 9: SEQUENCE { 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 43 13 2: PrintableString 'DE' : } : } 47 31 12: SET { On slapd's side the debug message bdb_search: <integer> does not match filter is written out for every record. What's going wrong here? Regards, Hartmut

1 0

multiple instances
by mj romero 31 May '10

31 May '10

Hello, I installed a server (RHEL5 x86_64) with three instances of OpenLDAP 2.3.43. ldap 6572 1 0 May24 ? 00:49:12 /usr/sbin/slapd -u ldap -g ldap -h ldap://X.Y.Z.104:389 -f /etc/openldap/slapd.conf -l LOCAL4ldap 6612 1 0 May24 ? 00:49:09 /usr/sbin/slapd -u ldap -g ldap -h ldap://X.Y.Z.105:389 -f /etc/openldap/slapd_i3.conf -l LOCAL6ldap 8031 1 0 01:01 ? 00:01:26 /usr/sbin/slapd -u ldap -g ldap -h ldap://X.Y.Z.104:389 -f /etc/openldap/slapd_i2.conf -l LOCAL5 At first everything worked perfect but after several days working properly one instance stopped.I started the instance again but after several days one instance stopped (not the same).I don't understand what happens. Any help is very useful to me. Thank you very much. _________________________________________________________________ Disfruta de Messenger y Hotmail en tu BlackBerry ¡Hazlo ya! http://serviciosmoviles.es.msn.com/messenger/blackberry.aspx

1 0

memberOf attributes not working through slapd-ldap backend
by Liam Gretton 29 May '10

29 May '10

Hi, Main LDAP server is 2.4 on openSUSE. The memberof overlay is in use. On any openSUSE clients (also OpenLDAP 2.4), ldapsearch on a uid with a '+' for the attribute arguments correctly returns the memberOf attributes as created by the overlay. On Scientific Linux 5.4 I have a build of OpenLDAP 2.4 (not mine, supplied by our vendor which repackages some components). I've setup a proxy server there which uses slapd-ldap to proxy connections back to the openSUSE LDAP server. On the SL system, ldapsearch talking directly to the openSUSE server correctly returns the memberOf attributes when using '+'. But when going through the local proxy server, they don't appear. The server log says "PROXIED attributeDescription "MEMBEROF" inserted"; if I specify the attribute explicitly (e.g. ldapsearch uid=liam memberof) the memberOf attributes are displayed, but all in capitals, as if there's a schema missing. One possibly important point: we're using the rfc2307bis schema on our main server, and this isn't supplied with the SL distribution of OpenLDAP, so I've just copied it over to the SL system. I think this suggests a broken build of OpenLDAP 2.4 supplied by our vendor, but is there anything I might be doing wrong? The proxy server's slapd.conf file is as so: include /cm/local/apps/openldap/etc/schema/core.schema include /cm/local/apps/openldap/etc/schema/cosine.schema include /cm/local/apps/openldap/etc/schema/inetorgperson.schema include /cm/local/apps/openldap/etc/schema/rfc2307bis.schema include /cm/local/apps/openldap/etc/schema/rcsperson.schema argsfile /var/run/openldap/slapd.args pidfile /var/run/openldap/slapd.pid database ldap monitoring off uri ldap://opensuse.ldapserver.example.com tls start tls_cacertdir=/etc/openldap/certs suffix dc=example,dc=com rootdn "cn=admin,dc=example,dc=com" -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its/ IT Services Tel: +44 (0)116 2522254 University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

3 4

ldapsearch issue
by Derek Yarnell 29 May '10

29 May '10

Hi, So I was trying to do the following search, (&(automountMapName=auto*)(objectClass=automountMap)) It logs the following though, slapd[5205]: conn=258105 op=9 SRCH base="ou=automount,ou=system,dc=XXX,dc=XXX,dc=XXX" scope=2 deref=2 filter="(&(?automountMapName=auto*)(objectClass=automountMap))" If you do this search (&(automountMapName=*)(objectClass=automountMap)) slapd[5205]: conn=258174 op=1 SRCH base="ou=automount,ou=system,dc=XXX,dc=XXX,dc=XXX" scope=2 deref=0 filter="(&(automountMapName=*)(objectClass=automountMap))" This is the schema definition on the server (rfc2307bis), attributeType ( 1.3.6.1.1.1.1.31 NAME 'automountMapName' DESC 'automount Map Name' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) My feeling is that caseExactIA5SubstringsMatch is doing something very wrong here. Shouldn't slapd be returning a error not injecting a ? in my search. Thanks, derek Derek Yarnell UNIX Systems Administrator University of Maryland Institute for Advanced Computer Studies

2 1

Replication problem - segfault
by Marcio Merlone 28 May '10

28 May '10

Hi all, I am upgrading my servers from Ubuntu 8.04 to 10.04 one by one. I took the opportunity to test and migrate slapd.conf to cn=config. I got the first new server running 10.04 (slapd 2.4.21-0ubuntu5), which is called 'haumea', and set everything up, smooth run. Then, I got to test replication with another server running Ubuntu 8.04 (slapd 2.4.9-0ubuntu0.8.04.3) - this one is 'venus'. So, in short, I am testing a multi-master replication with slapd 2.4.21-0ubuntu5 and slapd 2.4.9-0ubuntu0.8.04.3. At first, it successfully replicated one attr (olcLogLevel) from haumea to venus, but later on, when I try to modify 'olcMonitoring' of 'dn: olcDatabase={0}config,cn=config' same way, slapd process dies on the older server (venus): 'May 28 11:41:47 venus kernel: [511798.502592] slapd[3966]: segfault at 00000140 eip b7fa5634 esp b67658a0 error 4' Are there any issues regarding slapd 2.4.21-0ubuntu5 or replication between different versions? Does anyone know where can I get pre-compiled binary packages to upgrade Ubuntu 8.04 to slapd 2.4.21? Please let me know if you need further information. Thanks and best regards. -- Marcio Merlone

1 0

Slapd service does not start - Gentoo Linux ...
by Christopher Kurtis Koeber 28 May '10

28 May '10

Hello, I recently installed OpenLDAP 2.4.19 on a Gentoo Linux system. The installation completed without issue but the service slapd will not start. I loaded the initial entry and ran slaptest, which came back clean. Below is the output for "slaptest -d 25" and attached is my config file. Also attached is the output of the following command: /usr/lib/openldap/slapd -F /etc/openldap/ -d 65535 Any ideas as to why the service will not start while the system is starting up? Thank you for your time. ----Begin Output---- slaptest -d 25 slaptest init: initiated tool. bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.7.25: (2010-05-20) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 4.7.25: (2010-05-20) >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <cn=Subschema> <<< dnNormalize: <cn=subschema> hdb_db_init: Initializing HDB database >>> dnPrettyNormal: <dc=wesleyseminary,dc=edu> <<< dnPrettyNormal: <dc=wesleyseminary,dc=edu>, <dc=wesleyseminary,dc=edu> >>> dnPrettyNormal: <cn=Manager,dc=wesleyseminary,dc=edu> <<< dnPrettyNormal: <cn=Manager,dc=wesleyseminary,dc=edu>, <cn=manager,dc=wesleyseminary,dc=edu> >>> dnNormalize: <cn=Subschema> <<< dnNormalize: <cn=subschema> matching_rule_use_init 1.2.840.113556.1.4.804 (integerBitOrMatch): matchingRuleUse: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 1.2.840.113556.1.4.803 (integerBitAndMatch): matchingRuleUse: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox $ gecos $ homeDirectory $ loginShell $ memberUid $ memberNisNetgroup $ ipHostNumber $ ipNetworkNumber $ ipNetmaskNumber $ macAddress $ bootFile $ nisMapEntry ) ) 1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox $ gecos $ homeDirectory $ loginShell $ memberUid $ memberNisNetgroup $ ipHostNumber $ ipNetworkNumber $ ipNetmaskNumber $ macAddress $ bootFile $ nisMapEntry ) ) 2.5.13.39 (certificateListMatch): 2.5.13.38 (certificateListExactMatch): matchingRuleUse: ( 2.5.13.38 NAME 'certificateListExactMatch' APPLIES ( authorityRevocationList $ certificateRevocationList $ deltaRevocationList ) ) 2.5.13.35 (certificateMatch): 2.5.13.34 (certificateExactMatch): matchingRuleUse: ( 2.5.13.34 NAME 'certificateExactMatch' APPLIES ( userCertificate $ cACertificate ) ) 2.5.13.30 (objectIdentifierFirstComponentMatch): matchingRuleUse: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ ldapSyntaxes $ supportedApplicationContext ) ) 2.5.13.29 (integerFirstComponentMatch): matchingRuleUse: ( 2.5.13.29 NAME 'integerFirstComponentMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 2.5.13.27 (generalizedTimeMatch): matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES ( createTimestamp $ modifyTimestamp ) ) 2.5.13.24 (protocolInformationMatch): matchingRuleUse: ( 2.5.13.24 NAME 'protocolInformationMatch' APPLIES protocolInformation ) 2.5.13.23 (uniqueMemberMatch): matchingRuleUse: ( 2.5.13.23 NAME 'uniqueMemberMatch' APPLIES uniqueMember ) 2.5.13.22 (presentationAddressMatch): matchingRuleUse: ( 2.5.13.22 NAME 'presentationAddressMatch' APPLIES presentationAddress ) 2.5.13.20 (telephoneNumberMatch): matchingRuleUse: ( 2.5.13.20 NAME 'telephoneNumberMatch' APPLIES ( telephoneNumber $ homePhone $ mobile $ pager ) ) 2.5.13.17 (octetStringMatch): matchingRuleUse: ( 2.5.13.17 NAME 'octetStringMatch' APPLIES ( userPassword $ olcDbCryptKey ) ) 2.5.13.16 (bitStringMatch): matchingRuleUse: ( 2.5.13.16 NAME 'bitStringMatch' APPLIES x500UniqueIdentifier ) 2.5.13.14 (integerMatch): matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 2.5.13.13 (booleanMatch): matchingRuleUse: ( 2.5.13.13 NAME 'booleanMatch' APPLIES ( hasSubordinates $ olcAddContentAcl $ olcGentleHUP $ olcHidden $ olcLastMod $ olcMirrorMode $ olcMonitoring $ olcReadOnly $ olcReverseLookup $ olcDbChecksum $ olcDbNoSync $ olcDbDirtyRead $ olcDbLinearIndex $ olcSpNoPresent $ olcSpReloadHint $ olcChainCacheURI $ olcChainReturnError $ olcDbRebindAsUser $ olcDbChaseReferrals $ olcDbProxyWhoAmI $ olcDbSingleConn $ olcDbUseTemporaryConn $ olcDbNoRefs $ olcDbNoUndefFilter ) ) 2.5.13.11 (caseIgnoreListMatch): matchingRuleUse: ( 2.5.13.11 NAME 'caseIgnoreListMatch' APPLIES ( postalAddress $ registeredAddress $ homePostalAddress ) ) 2.5.13.8 (numericStringMatch): matchingRuleUse: ( 2.5.13.8 NAME 'numericStringMatch' APPLIES ( x121Address $ internationaliSDNNumber ) ) 2.5.13.7 (caseExactSubstringsMatch): matchingRuleUse: ( 2.5.13.7 NAME 'caseExactSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.6 (caseExactOrderingMatch): matchingRuleUse: ( 2.5.13.6 NAME 'caseExactOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.5 (caseExactMatch): matchingRuleUse: ( 2.5.13.5 NAME 'caseExactMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcSpCheckpoint $ olcChainingBehavior $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ ipServiceProtocol $ nisMapName ) ) 2.5.13.4 (caseIgnoreSubstringsMatch): matchingRuleUse: ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.3 (caseIgnoreOrderingMatch): matchingRuleUse: ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.2 (caseIgnoreMatch): matchingRuleUse: ( 2.5.13.2 NAME 'caseIgnoreMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcSpCheckpoint $ olcChainingBehavior $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ ipServiceProtocol $ nisMapName ) ) 1.2.36.79672281.1.13.3 (rdnMatch): 2.5.13.1 (distinguishedNameMatch): matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcDbACLAuthcDn $ olcDbIDAssertAuthcDn $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect ) ) 2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) slaptest startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=module{0}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}inetorgperson" config_build_entry: "cn={3}nis" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}hdb" backend_startup_one: starting "dc=wesleyseminary,dc=edu" hdb_db_open: database "dc=wesleyseminary,dc=edu": dbenv_open(/var/lib/openldap-data). config file testing succeeded slaptest shutdown: initiated ====> bdb_cache_release_all slaptest destroy: freeing system resources. ---End Output--- Regards, Christopher Kurtis Koeber (W): (202) 885-8654 (C): (301) 467-8417 http://www.chriskoeber.com <http://www.chriskoeber.com/>

2 2

Re: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate")
by Chris Jacobs 28 May '10

28 May '10

Whew! And I thought I was really off my rocker for a bit there - it made no sense to me (still doesn't, really). One of the reasons for our LDAP upgrade was the pwdpolicy (and less out-of-sync slaves; an issue with our 2.3 boxes) - going to have to re-think our implementation - I really preferred the 'slave servers in remote locations' model, but if the ppolicy overlay works best in a multi master model (replicating pwdfailures and authenticate - for real), I'll have to convince mgmt of the new model. Thanks for checking Sidhartha! - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ________________________________ From: openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org To: openldap-technical(a)openldap.org Sent: Tue May 25 17:16:00 2010 Subject: RE: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate") I replicated the setup and issues with slapd.d configuration. Running OpenLDAP 2.4.21 on CentOS x64. 1. Master and slave setup with ppolicy overlay. 2. When client points to master, pwdFailures are duly recorded and respected. Password auth works as expected. 3. When clients points to slave with chaining disabled, password auth and changes work fine but obviously pwdFailures are not recorded anywhere - neither on slave or master. 4. When client points to slave with chaining enabled, password auth breaks meaning user can type any string and still get a successful auth. Interestingly, in this case, pwdFailures get recorded on slave and master. Why or how a bind succeeds with a wrong password is weird. With slapd.d type config, the chain directives go under "frontendconfig" so I suspect the solution must lie there. As a sidenote, I am thinking of doing without slaves and just creating more primaries in multi-mode replication. Seems less complicated in terms of configuration and maintenance. Thanks, - Siddhartha > -----Original Message----- > From: openldap-technical-bounces+sjain=silverspringnet.com(a)openldap.org > [mailto:openldap-technical- > bounces+sjain=silverspringnet.com(a)openldap.org] On Behalf Of Chris > Jacobs > Sent: Tuesday, May 25, 2010 9:16 AM > To: openldap-technical(a)openldap.org > Subject: RE: ppolicy master/slave issue (currently "forward ppolicy > updates" OR "authenticate") > > Haven't heard anything on this yet... > > If someone could point me to some documentation, or better, graphic > illustration, of how OpenLDAP 'works', perhaps I can figure this out on > my own. > > Thanks, > - chris > > -----Original Message----- > From: openldap-technical- > bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org [mailto:openldap- > technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org] On Behalf Of > Chris Jacobs > Sent: Thursday, May 06, 2010 11:45 AM > To: openldap-technical(a)openldap.org > Subject: RE: ppolicy master/slave issue (currently "forward ppolicy > updates" OR "authenticate") > > Anyone? > > I can't be the only person trying to implement ppolicy_forward_updates > and have user's actually authenticate... > > I've been poring over the documentation: > > http://www.openldap.org/doc/admin24/overlays.html#Password%20Policies > http://www.symas.com/blog/?page_id=66 > http://www.openldap.org/software/man.cgi?query=slapo- > ppolicy&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release > Which indicates: "This setting is only useful on a replication > consumer, and also requires the updateref setting and chain overlay to > be appropriately configured." > > I tried "chain-rebind-as-user" and that didn't seem to help (you can > see it in the configs below) - at least, how I tried it. Perhaps I > misunderstand something (I'm hoping at least) > > I'm totally at a loss here... > > - chris > > -----Original Message----- > From: openldap-technical- > bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org [mailto:openldap- > technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org] On Behalf Of > Chris Jacobs > Sent: Monday, May 03, 2010 9:07 AM > To: openldap-technical(a)openldap.org > Subject: RE: ppolicy master/slave issue > > Really, I think this comes down to how to: > * ppolicy_forward_updates requiring priviledges > * authentication NOT requiring priviledges > > How do I split the two? Let ppolicy forward updates, which requires > priviledges, and NOT specify any authentication while user's are > authenticating? > > Thanks, > - chris > > -----Original Message----- > From: openldap-technical- > bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org [mailto:openldap- > technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org] On Behalf Of > Chris Jacobs > Sent: Thursday, April 29, 2010 2:55 PM > To: openldap-technical(a)openldap.org > Subject: ppolicy master/slave issue > > Hello again, > > I'm having an odd issue with ppolicy and my master/slave config. > > First, my goals > General use: > Slave handles all reads locally. > Writes get forwarded to the master by the slave. > > Password policy: > When password failures happen on clients using slave ldap servers, > the failures, etc, get passed to the master to get replicated to the > slaves. > I understand this would be done using the ppolicy option: > ppolicy_forward_updates > > Authentication: > Actually authenticate (more later). > > To the problem: > --------------- > When I leave the section in the chain bit of SLAVE slapd.conf below > marked by lines intact (which bind as root): > * ppolicy_forward_updates seems to work great - the master shows > matching "pwdFailureTime" attributes. > * Regardless of password entered, you get a shell. User/bad password = > get a shell! This being a problem should be obvious. > I suspect that's due to the chain overlay section... > > If I comment out the lines in the SLAVE slapd.conf: > * authentication actually requires authentication (bad password = no > authentication) > * ppolicy_forward_updates don't work (no updates to master) > > It's possible that from my description some may already know my issue - > however, just to be sure, I've pasted below 'bare' versions of the: > * a master slapd.conf (sans schema includes) > * a slave slapd.conf (sans schema includes) > * /etc/ldap.conf (using slave) > * /etc/openldap/ldap.conf (same on all ldap servers) (thanks Howard - > they are NOT the same) > * /etc/pam.d/system-auth-ac (CentOS 5.4; ssh refers to system-auth-ac > for all types). > > Thanks for any help (and, likely, pointing out any 'stupids' below), > - chris > > PS: Feel free to critique - you won't hurt my feelings. > > MASTER slapd.conf: (one of a pair, mirrored, active/passive fail over) > ---------------------------------------------------------------------- > serverID 1 > loglevel 0 > pidfile /usr/local/var/openldap-data/run/slapd.pid > argsfile /usr/local/var/openldap-data/run/slapd.args > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > TLSCACertificateFile /etc/openldap/cacerts/cacert.pem > TLSCertificateFile /etc/openldap/cacerts/servercrt.pem > TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem > TLSVerifyClient never > password-hash {MD5} > sizelimit size.soft=500 size.hard=unlimited > timelimit time.soft=3600 time.soft=unlimited > database bdb > suffix "dc=example,dc=net" > rootdn "cn=root,dc=example,dc=net" > rootpw "secret" > directory "/usr/local/var/openldap-data" > include /etc/openldap/slapd.access.conf > index uid,cn,gidNumber,uidNumber,memberUid eq > index objectClass pres,eq > index operatingSystem pres,eq > index host pres,eq > index rack eq > index entryUUID eq > index uniqueMember eq > index entryCSN eq > index site eq > overlay ppolicy > ppolicy_hash_cleartext > ppolicy_use_lockout > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 10 > syncrepl rid=2 > provider=ldaps://ldapmaster2.corp.example.net > type=refreshAndPersist > interval=00:00:10:00 > searchbase="dc=example,dc=net" > bindmethod=simple > binddn="cn=root,dc=example,dc=net" > credentials="secret" > retry="15 20 60 +" > mirrormode on > database monitor > > SLAVE slapd.conf: > ----------------- > serverID 13 > loglevel 0 > pidfile /usr/local/var/openldap-data/run/slapd.pid > argsfile /usr/local/var/openldap-data/run/slapd.args > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > TLSCACertificateFile /etc/openldap/cacerts/cacert.pem > TLSCertificateFile /etc/openldap/cacerts/servercrt.pem > TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem > TLSVerifyClient never > password-hash {MD5} > sizelimit size.soft=500 size.hard=unlimited > timelimit time.soft=3600 time.soft=unlimited > overlay chain > chain-uri ldaps://ldap-vip.corp.example.net/ > chain-rebind-as-user TRUE > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > vvvvvv > chain-idassert-bind bindmethod="simple" > binddn="cn=root,dc=example,dc=net" > credentials="secret" > mode="self" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^ > chain-tls ldaps > chain-return-error TRUE > database bdb > suffix "dc=example,dc=net" > rootdn "cn=root,dc=example,dc=net" > rootpw "secret" > directory "/usr/local/var/openldap-data" > include /etc/openldap/slapd.access.conf > index uid,cn,gidNumber,uidNumber,memberUid eq > index objectClass pres,eq > index operatingSystem pres,eq > index host pres,eq > index rack eq > index entryUUID eq > index uniqueMember eq > index entryCSN eq > index site eq > overlay ppolicy > ppolicy_hash_cleartext > ppolicy_use_lockout > ppolicy_forward_updates > syncrepl rid=1 > provider=ldaps://ldap-vip.corp.example.net > type=refreshAndPersist > interval=00:00:10:00 > searchbase="dc=example,dc=net" > bindmethod=simple > binddn="cn=root,dc=example,dc=net" > credentials="secret" > retry="15 20 60 +" > updateref "ldaps://ldap-vip.corp.example.net" > database monitor > > /etc/openldap/ldap.conf: (same on all LDAP servers) > --------------------------------------------------- > uri ldaps://localhost > base dc=example,dc=net > network_timeout 0 > sizelimit 0 > timelimit 0 > tls_cacert /etc/openldap/cacerts/cacert.pem > tls_reqcert demand > > /etc/ldap.conf: (on client using slave) > --------------------------------------- > uri ldaps://ldap-vip.dc1.example.net > timelimit 10 > bind_timelimit 10 > bind_policy soft > base dc=example,dc=net > scope sub > ssl on > tls_checkpeer no > tls_cacertfile /etc/openldap/cacert.pem (contents same as > /etc/openldap/cacerts/cacert.pem) > pam_login_attribute uid > pam_lookup_policy yes > pam_password exop > > /etc/pam.d/system-auth-ac: > -------------------------- > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_ldap.so use_first_pass > 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 > password sufficient pam_unix.so sha256 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 optional pam_mkhomedir.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 > > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

2 3

ppolicy + user notification
by Allgood, John 27 May '10

27 May '10

Hello All I have finally got ppolicy working correctly except for some interesting behavior. When I set the pwdMaxAge to say 3 days just for testing and when I log into the system shortly after changing my password. The systems notifies me that my password will expire in 2 days. On the 3rd day I don't get any notifications from the system. I have also defined in my policy a grace period for logins which does work but I don't get any notifications of that either. Also I am trying to build check_password.c to provide additional checking but when I try to compile the program I get missing headers files portable.h and slap.h. I have searched the entire system and can't locate them. I thought they would be part of the development RPMS which I installed. Any ideas on any of this.? Thanks John Allgood Senior Systems Administrator OHL Transportation Services 2251 Jesse Jewell Pky. NE Gainesville, GA 30507 tel: (678) 989-3051 fax: (770) 531-7878 jallgood(a)ohl.com<mailto:jallgood@ohl.com> www.ohl.com<http://www.ohl.com> ______________________________________________________ This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies.

1 0

ldap search hangs forever
by Jeremiah Martell 27 May '10

27 May '10

I'm using openldap-2.4.18 as a client to bind and asynchronously search an active directory server. I have a domain, example.com, that has two domain controllers: one.example.com, and two.example.com. The ip of one.example.com is 12.34.56.1 The ip of two.example.com is 12.34.56.2 The reverse mapping of 12.34.56.1 is one.example.com The reverse mapping of 12.34.56.2 doesn't exist ----- / nslookup one.example.com Server: 12.34.56.99 Address 1: 12.34.56.99 dns1.example.com Name: one.example.com Address 1: 12.34.56.1 one.example.com / nslookup two.example.com Server: 12.34.56.99 Address 1: 12.34.56.99 dns1.example.com Name: two.example.com Address 1: 12.34.56.2 / nslookup example.com Server: 12.34.56.99 Address 1: 12.34.56.99 dns1.example.com Name: example.com Address 1: 12.34.56.2 Address 2: 12.34.56.1 one.example.com / nslookup 12.34.56.2 Server: 12.34.56.99 Address 1: 12.34.56.99 dns1.example.com Name: 12.34.56.2 Address 1: 12.34.56.2 / nslookup 12.34.56.1 Server: 12.34.56.99 Address 1: 12.34.56.99 dns1.example.com Name: 12.34.56.1 Address 1: 12.34.56.1 one.example.com / ----- I have given openldap a "rebind proc" to use when chasing the referrals. I do a sasl gssapi bind to one.example.com, which succeeds. I do a search, which returns three referrals: DomainDnsZones.example.com ForestDnsZones.example.com example.com openldap looks up these three names and gets 12.34.56.2, which doesn't reverse map to anything. Then I get error messages for each referral: May 27 16:26:18 xyz: GSSAPI Error: Miscellaneous failure (see text) (Server (krbtgt/23.56.2(a)EXAMPLE.COM) unknown) May 27 16:26:18 xyz: GSSAPI Error: Miscellaneous failure (see text) (Server (krbtgt/23.56.2(a)EXAMPLE.COM) unknown) May 27 16:26:18 xyz: GSSAPI Error: Miscellaneous failure (see text) (Server (krbtgt/23.56.2(a)EXAMPLE.COM) unknown) Then openldap hangs forever; I never get a LDAP_RES_SEARCH_RESULT. ----- If I modify my DNS server to return 12.34.56.1 first instead of 12.34.56.2, then everything works perfectly. If I don't chase referrals, then everything works perfectly minus chasing referrals of course. If I use "normal" binding instead of sasl gssapi, then everything works perfectly. If I use openldap's syncronous search instead of asyncronously polling with ldap_result, then the call times out and returns. I half-expected openldap to not be able to bind to the referrals, but still fail quickly and return. I don't understand why the ldap search never finishes. (I never get a LDAP_RES_SEARCH_RESULT) I did get a LDAP_RES_SEARCH_REFERENCE and a LDAP_NO_RESULTS_RETURNED, but those dont signify the search has finished, right? I've attached the ldap debugging. You'll see at the end the repeated calls to ldap_result with timeouts of 10 seconds. I don't know how to read them exactly, but the status seems to be "RequestCompleted" ? ----- 17:20:50.530 ldap_result ld 0x10097060 msgid 5 17:20:50.530 wait4msg ld 0x10097060 msgid 5 (timeout 10000000 usec) 17:20:50.530 wait4msg continue ld 0x10097060 msgid 5 all 2 17:20:50.530 ** ld 0x10097060 Connections: 17:20:50.530 * host: one.example.com port: 389 (default) 17:20:50.530 refcnt: 1 status: Connected 17:20:50.530 last used: Wed May 26 17:19:59 2010 17:20:50.530 17:20:50.530 ** ld 0x10097060 Outstanding Requests: 17:20:50.530 * msgid 5, origid 5, status RequestCompleted 17:20:50.530 outstanding referrals 0, parent count 0 17:20:50.530 ld 0x10097060 request count 1 (abandoned 0) 17:20:50.530 ** ld 0x10097060 Response Queue: 17:20:50.530 Empty 17:20:50.530 ld 0x10097060 response count 0 17:20:50.530 ldap_chkResponseList ld 0x10097060 msgid 5 all 2 17:20:50.530 ldap_chkResponseList returns ld 0x10097060 NULL 17:20:50.530 ldap_int_select ----- I got the latest 2.4.22 release and grabbed the majority of the changes, but the hang remains. You can see the full debugging information in the attached txt file. I'm asking if the forever hang could be a bug in openldap, or perhaps I'm doing something wrong? Thanks, - Jeremiah

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical