openldap-technical

openldap-technical@openldap.org

3 participants
9990 discussions

Converting from slapd.d back to slapd.conf
by Sven Jourgensen 03 Apr '14

03 Apr '14

Is there a tool to perform the reverse operation, and convert the newer cn=config configuration back into a slapd.conf? Thanks. s.

9 17

LDAPS: ldapsearch working, back-ldap failing?
by Mitchell Im 03 Apr '14

03 Apr '14

Hi there, After several hours of beating on this (including multiple searches over the general internet and the mailing list), I've hit a dead end. So, I've decided to ask the experts, since it may require poking idassert-bind, which is pretty opaque to me (I can only partially understand the man page). Here's the problem: I'm setting up OpenLDAP as a proxy to another LDAP server (Active Directory, if it matters). I'm able to perform an ldapsearch against the backend LDAP server via ldaps://. The OpenLDAP proxy works if it connects to the backend LDAP server via ldap://. The OpenLDAP proxy does *not* work if it connects to the backend LDAP server via ldaps://, though. What am I missing? This is on CentOS 6.5, packages openldap-servers-2.4.23-34.el6_5.1.x86_64, nss-3.15.3-6.el6_5.x86_64 (Red Hat's decision). ======================================== * Backend LDAP server, ldaps:// $ ldapsearch -x -W -D 'cn=bindbot,cn=users,dc=domain,dc=local' -H ldaps://ad.domain.local -b 'dc=domain,dc=local' 'uid=bindbot' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=domain,dc=local> with scope subtree # filter: uid=bindbot # requesting: ALL # # BindBot, Users, domain.local dn: CN=BindBot,CN=Users,DC=domain,DC=local ... .. . ======================================== * OpenLDAP server, connecting to the backend via ldap:// $ ldapsearch -x -W -D 'cn= bindbot,cn=users,dc=domain,dc=local' -H ldaps://openldap.domain.local -b 'dc=domain,dc=local' 'uid=bindbot' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=domain,dc=local> with scope subtree # filter: uid=bindbot # requesting: ALL # # BindBot, Users, domain.local dn: cn=BindBot,cn=Users,dc=domain,dc=local ... .. . ======================================== * OpenLDAP server, connecting to the backend via ldaps:// (adding only the s to olcDbURI's ldap:// connection) $ ldapsearch -x -W -D 'cn= bindbot,cn=users,dc=domain,dc=local' -H ldaps://openldap.domain.local -b 'dc=domain,dc=local' 'uid=bindbot' Enter LDAP Password: ldap_bind: Server is unavailable (52) additional info: Proxy operation retry failed ======================================== * LDIF specifying the backend: dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: cn=users,dc=domain,dc=local olcSubordinate: TRUE olcAccess: {0}to dn.subtree="dc=domain,dc=local" by * read olcDbURI: "ldap://ad.domain.local" olcDbIDAssertBind: bindmethod=simple binddn="cn=bindbot,cn=users,dc=domain,dc= local" credentials="********" tls_cacert=/etc/openldap/certs/ad.crt olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: TRUE ======================================== * Snippet of /var/log/ldaplog (olcLogLevel 65535): Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: slap_listener_activate(9): Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 busy Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: >>> slap_listener(ldaps:///) Mar 30 21:21:37 openldap slapd[14645]: daemon: listen=9, new connection on 15 Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: added 15r (active) listener=(nil) Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: conn=1000 fd=15 ACCEPT from IP=10.0.0.202:40342 (IP=0.0.0.0:636) Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): unable to get TLS client DN, error=49 id=1000 Mar 30 21:21:37 openldap slapd[14645]: conn=1000 fd=15 TLS established tls_ssf=256 ssf=256 Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: op tag 0x60, time 1396239697 Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: conn=1000 op=0 do_bind Mar 30 21:21:37 openldap slapd[14645]: >>> dnPrettyNormal: <cn=bindbot,cn=users,dc=domain,dc=local> Mar 30 21:21:37 openldap slapd[14645]: <<< dnPrettyNormal: <cn=bindbot,cn=users,dc=domain,dc=local>, <cn=bindbot,cn=users,dc=domain,dc=local> Mar 30 21:21:37 openldap slapd[14645]: conn=1000 op=0 BIND dn="cn=bindbot,cn=users,dc=domain,dc=local" method=128 Mar 30 21:21:37 openldap slapd[14645]: do_bind: version=3 dn="cn=bindbot,cn=users,dc=domain,dc=local" method=128 Mar 30 21:21:37 openldap slapd[14645]: [rw] bindDN: "cn=bindbot,cn=users,dc=domain,dc=local" -> "cn=bindbot,cn=users,dc=domain,dc=local" Mar 30 21:21:37 openldap slapd[14645]: send_ldap_result: conn=1000 op=0 p=3 Mar 30 21:21:37 openldap slapd[14645]: send_ldap_result: err=52 matched="" text="Proxy operation retry failed" Mar 30 21:21:37 openldap slapd[14645]: send_ldap_response: msgid=1 tag=97 err=52 Mar 30 21:21:37 openldap slapd[14645]: conn=1000 op=0 RESULT tag=97 err=52 text=Proxy operation retry failed Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: ber_get_next on fd 15 failed errno=0 (Success) Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): input error=-2 id=1000, closing. Mar 30 21:21:37 openldap slapd[14645]: connection_closing: readying conn=1000 sd=15 for close Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_close: conn=1000 sd=15 Mar 30 21:21:37 openldap slapd[14645]: =>ldap_back_conn_destroy: fetching conn 1000 Mar 30 21:21:37 openldap slapd[14645]: daemon: removing 15 Mar 30 21:21:37 openldap slapd[14645]: conn=1000 fd=15 closed (connection lost) ======================================== * Other miscellaneous information: - /etc/openldap/ldap.conf also sets TLS_CACERT, /etc/openldap/certs/ad.crt, the CA public PEM. - The "unable to get TLS client DN, error=49 id=1000" error happens whether OpenLDAP attempts to connect to the backend LDAP server via ldap:// or ldaps://. - Adding tls_reqcert=allow to olcDbIDAssertBind doesn't help. - Explicitly specifying :636 doesn't help.

2 2

Hashed Entries
by Monica Warnock 03 Apr '14

03 Apr '14

Hi Can I please ask the relevance of the results of my ldapsearch command: ldapsearch -x -LLL -b dc=/name///=/name / dn: dc=/name/__,dc=/name/// objectClass: dcObject objectClass: organization dc:: ZGxpYi1tb25pZHAg o:: ZGxpYi1tb25pZHAg dn: ou=Users,dc=/name///,dc=/name/ objectClass: organizationalUnit ou: Users dn: cn=Bob Jones,ou=Users,dc=/name///,dc=/name/ cn: Bob Jones sn: Jones objectClass: inetOrgPerson objectClass: eduPerson eduPersonAffiliation: staff userPassword:: cGFzc3dvcmQg uid: bjones When I log in as bjones using the correct password the 'username or password is not valid'. What is the relevance of the entries such as the userPassword:: which now appear with two colons? I have added more test users and on their entry the uid entry also has the double colons with a hashed entry following. Thanks in advance. Monica -- *Monica Warnock* UK Access Management Federation for Education and Research EDINA Causewayside House, 160 Causewayside, Edinburgh EH9 1PR *t:* 0131 651 7721 *f:* 0131 650 3308 *e:* monica.warnock(a)ed.ac.uk The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 6

dhcp.schema attribute dhcpStatements value in filter
by Zeus Panchenko 02 Apr '14

02 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, I configured my isc-dhcpd servers to work with openldap, all works now when I want to find dn for some definite MAC or IP, I am unable to do that please, help to understand how can I ldapsearch by attribute dhcpStatements values? in dhcp.schema it is written: - ---[ quotation start ]------------------------------------------- ... attributetype ( 2.16.840.1.113719.1.203.4.3 NAME 'dhcpStatements' EQUALITY caseIgnoreIA5Match DESC 'Flexible storage for specific data depending on what object this exists in. Like conditional statements, server parameters, etc. This allows the standard to evolve without needing to adjust the schema.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ... - ---[ quotation end ]------------------------------------------- so, when I use filter "(&(objectClass=dhcpHost)(dhcpStatements=*))" I successfully receive all objects but lets say I need to find this object: - ---[ quotation start ]------------------------------------------- dn: cn=ap01,cn=10.0.0.0,cn=officeXXX DHCP Config,ou=officeXXX,ou=DHCP, dc=allstuff cn: ap01 objectClass: top objectClass: dhcpHost dhcpHWAddress: ethernet 20:cf:30:88:5d:18 dhcpStatements: fixed-address 10.0.0.222 - ---[ quotation end ]------------------------------------------- I use filter: "(&(objectClass=dhcpHost)(dhcpStatements=fixed-address 10.0.0.222))" and receive empty result ... it is the same picture for anything except dhcpStatements=* ... so, how is it correct to write the filter to get all objects with IP like 10.0.0.2* ? - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlM6y1sACgkQr3jpPg/3oyqPvQCgq6w8K53fw+6zrsSLbI72sbMR 5k8AoOh0wWlYmeQyyNKfngyMQrP3TXrt =KYZt -----END PGP SIGNATURE-----

3 9

Re: dhcp.schema attribute dhcpStatements value in filter
by Harry Jede 02 Apr '14

02 Apr '14

Zeus Panchenko wrote: > hi, > > I configured my isc-dhcpd servers to work with openldap, all works > > now when I want to find dn for some definite MAC or IP, I am unable > to do that ... > I use filter: > "(&(objectClass=dhcpHost)(dhcpStatements=fixed-address 10.0.0.222))" > > and receive empty result ... Then you make a mistake :-( $ ldapsearch -xLLL -H ldap://10.100.0.1 '(&(objectclass=dhcphost) (dhcpStatements=fixed-address 10.100.0.102))' dn dhcpStatements dn: cn=DEBIAN,ou=hosts,cn=DHCP Config,dc=europa,dc=xx dhcpStatements: fixed-address 10.100.0.102 > it is the same picture for anything except dhcpStatements=* ... > > so, how is it correct to write the filter to get all objects with IP > like 10.0.0.2* ? By default, that's not possible. You need to modify the schema to make this work. step 1: find the dhcp schema # ldapsearch -LLLY external -H ldapi:/// -b cn=schema,cn=config dn|grep dhcp dn: cn={7}dhcp,cn=schema,cn=config step2: prepare a ldapmodify input file # echo 'dn: cn={7}dhcp,cn=schema,cn=config' > /tmp/dhcp_s.ldif # echo 'changetype: modify' >> /tmp/dhcp_s.ldif # echo 'replace: olcAttributeTypes' >> /tmp/dhcp_s.ldif step 3: retrieve the attributes from cn=config # ldapsearch -LLLY external -H ldapi:/// -b cn=schema,cn=config 'cn={7}dhcp' olcAttributeTypes >> /tmp/dhcp_s.ldif step 4.1: add Substring match to dhcpStatements with an editor this I have added "SUBSTR caseIgnoreIA5SubstringsMatch" to dhcpStatements. The result is: olcAttributeTypes: {2}( 2.16.840.1.113719.1.203.4.3 NAME 'dhcpStatements' DESC 'Flexible storage for specific data depending on what object this exists in. Like conditional statements, server parameters, etc. This allows the standard to evolve without needing to adjust the schema.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) step 4.2 remove line number 4 in my config 'dn: cn={7}dhcp,cn=schema,cn=config' step 5: update the server # ldapmodify -Y external -H ldapi:/// -f /tmp/dhcp_s.ldif step 6: be happy ;-) $ ldapsearch -xLLL -H ldap://10.100.0.1 '(&(objectclass=dhcphost) (dhcpStatements=fixed-address 10.100.0.*))' dn dhcpStatementsdn: cn=ainf-01,ou=hosts,cn=DHCP Config,dc=europa,dc=xx dhcpStatements: fixed-address 10.100.0.101 dn: cn=ainf-02,ou=hosts,cn=DHCP Config,dc=europa,dc=xx dhcpStatements: fixed-address 10.100.0.103 dhcpStatements: filename "pxelinux.0" dhcpStatements: next-server 10.100.0.1 dhcpStatements: broadcast-address 10.100.255.255 dn: cn=ainf-22,ou=hosts,cn=DHCP Config,dc=europa,dc=xx dhcpStatements: fixed-address 10.100.0.104 dn: cn=DEBIAN,ou=hosts,cn=DHCP Config,dc=europa,dc=xx dhcpStatements: fixed-address 10.100.0.102 hints: 1. modify an objectclass this way, will not work 2. an index on dhcpStatements is not required to make this work perhaps good for performance reasons 3. try it first on a test server :-) -- Harry Jede

2 2

Volunteers for Linuxtag 2014
by Dieter Klünter 02 Apr '14

02 Apr '14

Hi, The OpenLDAP Project will be present at Linuxtag 2014 in Berlin http://linuxtag.org/2014/ I am looking for volunteers to support the OpenLDAP booth. Prospective volunteers may contact me. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

1 0

Re: Changing cert paths may cause openldap to stop
by Quanah Gibson-Mount 01 Apr '14

01 Apr '14

--On Thursday, March 27, 2014 1:52 PM +0200 Nick Milas <nick(a)eurobjects.com> wrote: > Hi, > > On 2.4.39 (CentOS 5.10 x86_64), I found that if I attempt to change > certificate values but there is an error in a path, openldap stops. > > I would expect this should be avoided. Openldap should reject the > modification and not stop. > > Running the modification below, it hungs; we press Ctrl-C (and we print a > full backtrace), then we find slapd is stopped. File an ITS. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: Problem after migration openldap 2.3.43 to 2.4.23 --> 32 No Such Object
by Jonas Kellens 01 Apr '14

01 Apr '14

On 01-04-14 10:53, Terje Trane wrote: > On 01.04.2014 09:58, Jonas Kellens wrote: >> >> even if I add at the beginning of slapd.conf the following : >> >> access to * by * >> >> I still get no results with the user 'cn=U101001,ou=101001,dc=mydomain' >> >> I only get result with 'cn=Manager,dc=mydomain' >> > > Remember that ACLs are "first match used". > > If a database does not have an ACL the global ACL applies. > > But if it has a database specific ACL, that one is read first when > accessing that particular database, and the global then *only* used if > there is no match (or a control keyword like break or continue is > specified) I posted it before, but will post it again. This is the database specific ACL : database bdb suffix "dc=mydomain" rootdn "cn=Manager,dc=mydomain" rootpw {SSHA}blCAG/CNdFPY597Cf4Ssuj access to attrs=userPassword by * auth access to dn.regex="ou=tbook[12345],ou=contacten,ou=101001,dc=mydomain" attrs=children by group.exact="cn=admins,ou=101001,dc=mydomain" write by * none break access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook2,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook3,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook4,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=101001,dc=mydomain" read access to dn.one="ou=tbook5,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=101001,dc=mydomain" read If user 'cn=U101001,ou=101001,dc=mydomain' is member of group "cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain", wouldn't you agree that it should be able to read the entries in dn "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" ?? Kind regards, Jonas.

4 6

RE: Slave not able to update master pwdFailureTime via chain.
by serpent6877 31 Mar '14

31 Mar '14

Anyone else have an answer for this? Thanks, Brad -------- Original message -------- From: Brad dameron <serpent6877(a)hotmail.com> Date:03/24/2014 8:36 AM (GMT-08:00) To: Esteban Pereira <esteban.pereira(a)gepsit.fr>,openldap-technical(a)openldap.org Subject: RE: Slave not able to update master pwdFailureTime via chain. >From what I read I need to setup authzTo. But having problems understanding what I need to set in the slaps.conf and on the allowed user. -------- Original message -------- From: Esteban Pereira <esteban.pereira(a)gepsit.fr> Date:03/20/2014 10:55 AM (GMT-08:00) To: Brad dameron <serpent6877(a)hotmail.com>,openldap-technical(a)openldap.org Subject: Re: Slave not able to update master pwdFailureTime via chain. I've never configured this kind of architecture, but as far as I know the ppolicy, I think my first thought configuring this would have been to not rebind as user because the attribute modified is an operational one which need the manage right (not sure about that) So I should have configured this with the replication user with manage right and without rebinding as a user when chaining to the master. Hope this help On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877(a)hotmail.com>wrote: > I understand what you are saying. But this is what the > ppolicy_forward_updates says: > > ppolicy_forward_updates > Specify that policy state changes that result from Bind operations (such as recording > failures, lockout, etc.) on a consumer should be forwarded to a master instead of > being written directly into the consumer’s local database. This setting is only use‐ > ful on a replication consumer, and also requires the updateref setting and chain > overlay to be appropriately configured. > > So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD > from what I have seen in my logs. And thus the user doesn't have access to modify this attribute. > > Brad > > > > ------------------------------ > Date: Thu, 20 Mar 2014 12:13:02 +0100 > Subject: Re: Slave not able to update master pwdFailureTime via chain. > From: esteban.pereira(a)gepsit.fr > To: serpent6877(a)hotmail.com > CC: openldap-technical(a)openldap.org > > > Hi Brad, > > pwdFailureTime is an operational attribute, I don't think any user can > modify it on any instance. May be you should try to modify it on the master > to see if it comes from this assumption. > > Esteban > > > On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877(a)hotmail.com>wrote: > > OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime > updated on the master when the slave recieves a password failure. Here is > my config. It's pretty simple and basic. No TLS. > > Master: > > access to attrs=userPassword > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" read > by self write > by anonymous auth > by * none > access to * > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" write > by self write > by users read > by anonymous read > by * none > > > > Slave: > > overlay chain > chain-uri ldap://172.16.0.84:389 > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > mode="self" > chain-return-error TRUE > > # Password Policy > overlay ppolicy > ppolicy_default "cn=default,ou=Policies,dc=test,dc=net > ppolicy_use_lockout > ppolicy_forward_updates > > > # Slave Replication > syncrepl rid=101 > provider=ldap://172.16.0.84:389 > type=refreshAndPersist > interval=00:00:01:00 > retry="60 10 300 +" > searchbase="dc=test,dc=net" > schemachecking=off > bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > updateref "ldap://172.16.0.84:389" > > > > I see the connection on the master but it gives a permission error: > > > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > dn="cn=testuser,ou=People,dc=test,dc=net" > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > attr=pwdFailureTime > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103 > err=50 text= > > > I read that you maybe need authzTo added to the binddn for the chain? Or > is this only for TLS? > > I tried adding this ldif: > > dn: cn=replication,dc=test,dc=net > changetype: modify > add: authzTo > authzTo: * > > And even set the: > > chain-idassert-authzFrom "*" > > in the chain. But it always gives me the error code 50 not enough > permissions. I believe it is supposed to give access to the user to MOD the > pwdFailureTime tribute knowing it is coming from a relay. But I can't find > very specific docs on this or see what is wrong. Any help apreciated. > > Thanks, > Brad > > >

2 1

openldap for fedora
by Brendan Kearney 30 Mar '14

30 Mar '14

i hope to be getting some new machines and updating/upgrading my ldap instances in the process. i am looking to use the ltb-project.org rpms for the install, but have a couple of questions. first, i do not see any fedora versions in the repo. only redhat 5 and 6. are these packages binary compatible with fedora? second, it seems that the packages use the Sys V Init style, as i am sure the RH servers still use. although that is supported for legacy compatibility in fedora, does the new systemd init style work with these packages? third, is a package for fedora versions available through the ltb-project site? thank you, brendan

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