July 2009 - openldap-software

by Greek Ordono

I tried that following configuration: chain-idassert-bind bindmethod=sasl saslmech=EXTERNAL binddn="cn=whatever" starttls=critical tls_cert=/etc/ldap/ssl/replicator-cert.pem tls_key=/etc/ldap/ssl/replicator-key.pem tls_cacert=/etc/ssl/certs/mgoc-cacert.pem tls_reqcert=demand mode=self chain-idassert-authzFrom "*" but when I run $ ldappasswd -x -D 'uid=guest,ou=users,dc=server,dc=group' -wguest -stseug Result: Authentication method not supported (7) -- Greek Ordono myppa: launchpad.net/~grexk/+archive/ppa --- On Fri, 7/10/09, Gavin Henry <ghenry(a)suretecsystems.com> wrote: From: Gavin Henry <ghenry(a)suretecsystems.com> Subject: Re: saslmech=EXTERNAL To: "Greek Ordono" <grexk(a)yahoo.com> Cc: openldap-software(a)openldap.org Date: Friday, July 10, 2009, 4:02 AM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > overlay chain > chain-uri "ldaps://server.group" > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=sasl > saslmech=EXTERNAL > binddn="cn=whatever" > tls_cert=/etc/ldap/ssl/replicator-cert.pem > tls_key=/etc/ldap/ssl/replicator-key.pem > tls_cacert=/etc/ssl/certs/mgoc-cacert.pem > tls_reqcert=demand > mode=self > chain-idassert-authzFrom "*" > chain-return-error TRUE Is slapd listening on ldaps? Why not starttls=yes/critical like below? > [2] > syncrepl rid=245 > provider=ldap://server.group > type=refreshAndPersist > searchbase="dc=server,dc=group" > filter="(objectClass=*)" > scope=sub > schemachecking=off > bindmethod=sasl > saslmech=EXTERNAL > starttls=yes > tls_cert=/etc/ldap/ssl/replicator-cert.pem > tls_key=/etc/ldap/ssl/replicator-key.pem > tls_reqcert=allow > retry="10 20 60 +" > logbase="cn=accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog > > -- > > Greek Ordono > > myppa: launchpad.net/~grexk/+archive/ppa > > > - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWYfgACgkQoJwyzoTgQhTaIgCfU0vFRkoDrYCP8edFLJsERL26 hNcAoJN0JpnZHOmxQ3D6re/G1Ndr6A+s =caYf -----END PGP SIGNATURE-----

14 years, 4 months

2
1
0 / 0

Shell backend and cn=config

by Konovalov Andrey

Is the Shell backend compatible with the cn=config method of configuration data storage? I've converted this section from slapd.conf to cn=config: # Shell backend -> database shell suffix "dc=Shell" add "/tmp/bind.sh" modify "/tmp/bind.sh" bind "/tmp/bind.sh" # <- And in cn=config i can see olcDatabase={N}shell, but not add/modify/bind directives. At the same time in logs of slaptest -f slapd.conf -F slapd.d: WARNING: No dynamic config support for database shell. config_build_entry: "olcDatabase={1}shell" ldif_back_add: "olcDatabase={1}shell,cn=config" oc_check_required entry (olcDatabase={1}shell,cn=config), objectClass "olcDatabaseConfig" oc_check_allowed type "objectClass" oc_check_allowed type "olcDatabase" oc_check_allowed type "olcSuffix" oc_check_allowed type "olcAddContentAcl" oc_check_allowed type "olcLastMod" oc_check_allowed type "olcMaxDerefDepth" oc_check_allowed type "olcReadOnly" 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_write_entry: wrote entry "olcDatabase={1}shell,cn=config" It looks like Shell backend is deprecated and uncompatible with cn=config. Or what could i do wrong?

14 years, 4 months

2
3
0 / 0

Supported RFC's and "features"

by Clowser, Jeff (Contractor)

I'm currently doing a review to see how OpenLDAP compares, *feature wise* ATM, to other directory servers and specifically to the Sun DS - i.e. to get a definitive list of features it's missing that Sun has and what it has that Sun doesn't have, etc. For brevity, I haven't included all the potentially useful features of OpenLDAP, but have just focused on those associated with 1) RFC compliance (of which Sun may or may not meet) and 2) features to match the Sun DS (which it would be replacing). So far, here's what I have for OpenLDAP: RFC 4510 (which includes 4511-4519). There was recent discussion on the list around this, such that in some cases, not everything that changed from 3377 (which includes 2251-2256, 2829, and 2830) to 4510 has been updated in OpenLDAP, but I think those issues are fairly minor. The following additional RFC's are supported in OpenLDAP: - RFC 2247 and RFC 3088 - RFC 2696 simple paged results - RFC 2849 ldif - RFC 3062 password mod op - RFC 3296 named referals, manageDSAit - RFC 3673 All Op attrs + feature - RFC 3687 Component matching rules - RFC 3866 Languange tag and range - RFC 3876 matched values control - RFC 4370 proxy auth - RFC 4522 binary encoding - RFC 4523 x.509 cert schema - RFC 4524 COSINE schema - RFC 4525 Mod-increment - RFC 4526 Absolute true/false filters - RFC 4527 pre/post read control - RFC 4528 assertion control - RFC 4529 request attrs by objectclass - RFC 4530 entryUUID - RFC 4532 whoamI - RFC 4533 Content Sync op (replication) RFC's NOT supported are: - RFC 2589 dds Seems with 2.4, this has gone from experimental to production quality? - RFC 2891 server side sorting - RFC 3671 collective attributes - RFC 3928 LCUP mainly for updating cached addressbooks, etc - not replication between servers - RFC 3384 looks like just reqs for replication, not an actual replication protocol - RFC 4533 is used instead Unknown: - RFC 3672 (subentries) - RFC 3698 and 3727 (additional matching rules) - RFC 3909 LDAP Cancel operation - RFC 5020 entryDN operational attribute (There are some other, often obscure, LDAP related RFC's that I didn't include, but this seems to be the major/useful ones) Other features not supported: - VLV browse indexes (per http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09). Not an RFC, but supported by Sun and MS directories, and used by things like Outlook and Solaris. Other supported features: - dyngroup/dynlist/memberof overlay (A much more useful feature than Sun's groupOfURLs "dynamic" group and "roles" mechanism) - ppolicy overlay (matches Sun DS 5.x reasonably close, but is account lockout replicated to all servers? Sun DS 6.x claims to) - refint overlay (similar to Sun's referential integrity plugin) - unique overlay (similar to Sun's uniqueness plugin) - audit and accesslog overlays, syslog logging - much more useful/complete than Sun's access/audit/error logs. - live acl changes via LDAP Unknown features: - Per user resource limits (sizelimit, timelimit, idletimeout, etc). I think Howard Chu said OpenLDAP has some of this, but I haven't seen any reference to it or how to use it in the docs (does this functionality exist, and if so, is there any documentation?) - Tracking of last login (i.e. last successful ldap authentication) Is this still fairly accurate? The ones that are really problematic are the lack of: - VLV Browse indexes - RFC 2891 (server side sorting) - per user/entry resources limits (if they don't exist) Are there any unofficial updates/patches/overlays/plans for any of this functionality? Thanks, - Jeff

14 years, 4 months

11
29
0 / 0

Is OpenLDAP RFC 3687-compliant?

by Hanz Akkerman

Hi4All! Dear Kurt Zeilenga, dear developers of OpenLDAP! Tell me please, does the RFC 3687 (Component Matching) supported in the current release or no? I know that OpenLDAP supported it in versions 2.3.x, but i am in doubt, why OpenLDAP-SNACC compilation failed with OpenLDAP-2.4.16? I think that OpenLDAP-SNACC is freazed and unsuppiorted now. Am i right? With Best Regards, DRVTiny (Konovalov Andrey Alexandrovitsch, Russian Federation)

14 years, 4 months

2
1
0 / 0

Re: TLS/SSL and self-signed certificates

by Dieter Kluenter

Rick Stevens <rps2(a)socal.rr.com> writes: > Dieter Kluenter wrote: >> Rick Stevens <rps2(a)socal.rr.com> writes: >> >>> Dieter Kluenter wrote: [...] >> This is only the content of slapd.conf, the relevant content of >> ldap.conf(5) is still missing, ldapsearch requires at least the path >> to CA, further information on the level of certificate checks and the >> prefered cipher suits are recommended options. > > Terribly sorry, misread your message. I had posted my ldap.conf before, > but here it is again: > > host 192.168.1.53 > base dc=eqspeed,dc=com > rootbinddn uid=sysman,ou=people,dc=eqspeed,dc=com > timelimit 15 > bind_timelimit 10 > bind_policy soft > pam_lookup_policy yes > pam_password clear_remove_old > nss_base_passwd ou=People,dc=eqspeed,dc=com?one > nss_base_shadow ou=People,dc=eqspeed,dc=com?one > nss_base_group ou=Group,dc=eqspeed,dc=com?one > nss_base_hosts ou=Hosts,dc=eqspeed,dc=com?one > ssl start_tls > ssl on > #tls_cacertdir /etc/openldap/cacerts > tls_cacertfile /etc/openldap/cacerts/allcerts.pem > tls_reqcert never That's what I thought, this is the wrong ldap.conf, read man ldap.conf(5). -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

14 years, 4 months

1
0
0 / 0

Re: TLS/SSL and self-signed certificates

by Dieter Kluenter

Rick Stevens <rps2(a)socal.rr.com> writes: > Dieter Kluenter wrote: >> Hi, [...] >> OK, could you please provide the TLS related entries of slapd.conf >> and ldap.conf? It seems that the server is not providing a server >> certificate but a CA. > > Okey doke. Here they are: > > TLSCACertificateFile /usr/local/etc/openldap/gbsbilling-cert.pem > TLSCertificateFile /usr/local/etc/openldap/bigdog-cert.pem > TLSCertificateKeyFile /usr/local/etc/openldap/bigdog-key.pem This is only the content of slapd.conf, the relevant content of ldap.conf(5) is still missing, ldapsearch requires at least the path to CA, further information on the level of certificate checks and the prefered cipher suits are recommended options. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

14 years, 4 months

1
0
0 / 0

TLS/SSL and self-signed certificates

by Rick Stevens

I know this has been hashed over before, but I simply cannot get my LDAP clients to talk TLS/SSL to my LDAP server. I keep getting TLS certificate verification: Error, self signed certificate in certificate chain errors. A standard "openssl s_client" test works fine, but a client such as ldapsearch simply refuses to cooperate. I have the "tls_cacertdir" set to point at a directory that has a copy of every certificate I've created and it still won't work. The certificates were created based on the instructions at: http://www.openldap.org/faq/data/cache/185.html as specified in the admin manual. I'm the first to admin I'm not an SSL guy, but this has got me stumped! I'll be happy to provide whatever bits of the various config files you need. Help me Obi-Wan Kenobi! ---------------------------------------------------------------------- - Rick Stevens, Unix Geek rps2(a)socal.rr.com - - - - Treat each day as if it's your last...a lot of crying and whining - - usually gets you what you want! -- Sam Sledge - ----------------------------------------------------------------------

14 years, 4 months

5
4
0 / 0

saslmech=EXTERNAL

by Greek Ordono

Hi, I can't get this working in overlay chain[1] but its working with syncrepl[2]. I'm missing something, please help. # ldapsearch -x -b "" -LLL -s base supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: NTLM supportedSASLMechanisms: LOGIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL $ ldapwhoami -ZZ SASL/EXTERNAL authentication started SASL username: cn=replicator,ou=ou,o=o,l=l,st=s,c=c SASL SSF: 0 dn:cn=replicator,ou=dsa,dc=server,dc=group slapd.conf: TLSCACertificateFile /etc/ssl/certs/mgoc-cacert.pem TLSCertificateFile /etc/ldap/ssl/server-cert.pem TLSCertificateKeyFile /etc/ldap/ssl/server-key.pem TLSVerifyClient try authz-policy from authz-regexp "^cn=([^,]+),.*" "cn=$1,ou=dsa,dc=moldex,dc=group" [1] overlay chain chain-uri "ldaps://server.group" chain-rebind-as-user TRUE chain-idassert-bind bindmethod=sasl saslmech=EXTERNAL binddn="cn=whatever" tls_cert=/etc/ldap/ssl/replicator-cert.pem tls_key=/etc/ldap/ssl/replicator-key.pem tls_cacert=/etc/ssl/certs/mgoc-cacert.pem tls_reqcert=demand mode=self chain-idassert-authzFrom "*" chain-return-error TRUE [2] syncrepl rid=245 provider=ldap://server.group type=refreshAndPersist searchbase="dc=server,dc=group" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_cert=/etc/ldap/ssl/replicator-cert.pem tls_key=/etc/ldap/ssl/replicator-key.pem tls_reqcert=allow retry="10 20 60 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog -- Greek Ordono myppa: launchpad.net/~grexk/+archive/ppa

14 years, 4 months

2
1
0 / 0

mirror mode replication

by Brett ＠Google

Hello, I am having two problems one i think an issue with mirrormode replication, and two i think the docs might be are wrong for mirrormode. The openldap admin quide states : MirrorMode node 1: # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on MirrorMode node 2: # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on I have configured something like this, and it does an initial syncronise, but subsquent writes to "node 1" are not replicated to node 2. Eg. changes to data use "ldap.example.com" LDAP are always made to node 1 (ldap://ldap-sid1.example.com), and only to node 2 (ldap://ldap-sid2.example.com) if node 1 is unavailable (via a content switch). When a change happens via node 1, i get : Node 1 (seems to be correct): Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 939789 local4.debug] syncprov_sendresp: to=002, cookie=rid=001,sid=001,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 905511 local4.debug] do_syncrep2: cookie=rid=001,sid=002,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 977386 local4.debug] syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 565591 local4.debug] syncrepl_entry: rid=001 be_search (0) Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 709484 local4.debug] syncrepl_entry: rid=001 mail=user(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 819441 local4.debug] syncrepl_entry: rid=001 entry unchanged, ignored (mail=user(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com) Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 784563 local4.debug] syncprov_matchops: skipping relayed sid 002 Node 2 (indicates a problem maybe): Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 905511 local4.debug] do_syncrep2: cookie=rid=001,sid=001,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 977386 local4.debug] syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 565591 local4.debug] syncrepl_entry: rid=001 be_search (0) Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 709484 local4.debug] syncrepl_entry: rid=001 mail=user(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 824931 local4.debug] syncprov_matchops: skipping original sid 001 Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 939789 local4.debug] syncprov_sendresp: to=001, cookie=rid=001,sid=002,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 933660 local4.debug] syncrepl_entry: rid=001 be_modify mail=sitescop(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com (0) Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 824931 local4.debug] syncprov_matchops: skipping original sid 001 I'm presuming it is wrong (correct me if i am wrong) as the second change change from node 2 is coming in, using the same sid as node 1, hence "skipping original sid 001" In previous example configs, each mirrormode node has had two rid's, 001 for "node 1" and 002 for "node 2" so the protocol can tell which node made the change, one node should accept the change as it came from the other node, the other should reject it as it came from itself. FYI, The previous example was something like below (eg. node 1, same for node 2 but with "serverID 2") : # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" syncrepl rid=002 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on Is this still required ? I thought mirrormode meant any node may be updated, but typically always the same one (unless one fails). Cheers Brett

14 years, 4 months

2
1
0 / 0

Re: TLS/SSL and self-signed certificates

by Dieter Kluenter

Hi, please stay on the mailing list. Rick Stevens <rps2(a)socal.rr.com> writes: > Dieter Kluenter wrote: >> Rick Stevens <rps2(a)socal.rr.com> writes: >> >>> I know this has been hashed over before, but I simply cannot get my >>> LDAP clients to talk TLS/SSL to my LDAP server. I keep getting >>> >>> TLS certificate verification: Error, self signed certificate in >>> certificate chain >> This error may not be the culprit, if the error (or warning) is >> referring to the CA. >> What is the CN of the server certificate and what is the host part of >> your search string? > > The CN of the server certificate is: > > CN=bigdog.hci.com/emailAddress=ricks@nerd.com > > The host part of the search is "-h bigdog.hci.com" > >> In order to debug the TLS session run ldapsearch with -d3 option. > > I never see it try to pick up the server's certificate, just the CA's > and I see a "TLS trace: SSL3 alert write:fatal:unknown CA" error before > it dies. OK, could you please provide the TLS related entries of slapd.conf and ldap.conf? It seems that the server is not providing a server certificate but a CA. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

14 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software July 2009