Binding through a chaining. It's possible?
by Maximiliano Boscovich
Hello,
I'm having trouble making binding through a chaining. I have 2 servers,
server 1 has a referral ou pointing to a another server (server2). Server1
has the following configuration:
dn: olcOverlay=chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
objectClass: top
olcOverlay: chain
olcChainCacheURI: FALSE
olcChainMaxReferralDepth: 1
olcChainReturnError: TRUE
dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: ldap
olcDbURI: "ldap://server2"
olcDbStartTLS: none starttls=no
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical
bindmethod=simple timeout=0 network-timeout=0
binddn="cn=admin,dc=example,dc=ar" credentials="password" keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
>From the server1 I can make changes and searches without problems to
entries on server2 (the chaining works fine for this), but when I want to
make a binding, it gives me invalid credentials.
For instance:
mboscovich@mambo-tango:~$ ldapwhoami -vvv -h server1 -x -D
"uid=useronserver02,ou=users,dc=example,dc=ar" -W
ldap_initialize( ldap://server1:389 )
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
If I make the same query but to the server2 where is hosted the entry (so
not the chaining is used) the binding runs smoothly:
mboscovich@mambo-tango:~$ ldapwhoami -vvv -h server2 -x -D
"uid=useronserver02,ou=users,dc=example,dc=ar" -W
ldap_initialize( ldap://server2:389 )
Enter LDAP Password:
dn:uid=useronserver02,ou=users,dc=example,dc=ar"
Result: Success (0)
The logs on server1 when it's fail, show this:
Dec 8 19:19:55 server1 slapd[2219]: conn=1014 fd=20 ACCEPT from IP=
10.0.2.2:52358 (IP=0.0.0.0:389)
Dec 8 19:19:55 server1 slapd[2219]: conn=1014 op=0 BIND
dn="uid=useronserver2,dc=example,dc=ar" method=128
Dec 8 19:19:55 server1 slapd[2219]: conn=1014 op=0 RESULT tag=97 err=49
text=
Dec 8 19:19:55 server1 slapd[2219]: conn=1014 op=1 UNBIND
Dec 8 19:19:55 server1 slapd[2219]: conn=1014 fd=20 closed
and on the server02 i couldn't see any log in this case.
What am I doing wrong?.
Regards
Maximiliano Boscovich
8 years, 11 months
Re: Problem with persistent search in OpenLDAP 2.4.23
by Tom Leach
Dieter, what I'm trying to do is have a separate process (this being the
perl script) connect with a persistent search to one of a pair of
syncrepl'd multimasters. Are syncrepl and syncprov mutually exclusive?
If that's the case, then I'll have to take another tack since I
require the syncrepl multimasters and the persistent search via syncprov
was a "nice thing to have" but not required.
Thanks!
Tom
On 08/25/2010 11:04 AM, Dieter Kluenter wrote:
> Tom Leach <leach(a)coas.oregonstate.edu> writes:
>
>> Here is the primary database definition, and it's the tree that I'm
>> trying to run a persistent search against. I have the syncprov
>> overlay loaded towards the end after the syncrepl and accesslog stuff.
>> The "overlay syncprov" three lines are the only lines in slapd.conf
>> that reference syncprov.
>> Thanks!
>> Tom
>>
>> database bdb
>> suffix "dc=coas,dc=oregonstate,dc=edu"
>> rootdn "XXX"
>> rootpw secret
>> directory /usr/local/var/openldap-data
>> index objectClass eq
>> index ou,cn,mail,surname,givenname eq,pres,sub
>> index uid,memberUid eq,pres,sub
>> index uniqueMember eq,pres
>> index entryCSN,entryUUID eq
>>
>> syncrepl rid=123
>> provider=ldap://XXX
>> starttls=critical
>> type=refreshAndPersist
>> interval=00:00:05:00
>> retry="5 20 300 +"
>> searchbase="dc=coas,dc=oregonstate,dc=edu"
>> filter="(objectClass=*)"
>> attrs="*,+"
>> scope=sub
>> schemachecking=off
>> bindmethod=simple
>> binddn="XXX"
>> credentials=XXX
> [...]
>
> This is a syncrepl synchronisation, persistantSearch is not supported
> by OpenLDAP.
> If you want to receive modified entries, you should use
> Net::LDAP::Control::SyncRequest
> Unfortunately, this perl modul doesn't connect properly in
> refresh and persist mode (according to the author) but only in refresh
> only mode.
>
> -Dieter
>
14 years, 2 months
how to tell client to use ssf=256 instead of ssf=128
by Tobias Hachmer
Hello,
I'm using openldap 2.4.28 on ubuntu server and configured TLS.
I want to allow write operations only when ssf=256 is used. (security
update_ssf=256)
Certificates were set up with openssl CA.pl.
When I connect via
# ldapadd -Y EXTERNAL -ZZ -f /src/test.ldif
I get this:
SASL/EXTERNAL authentication started
SASL username: cn=ldapadmin,.............
SASL SSF: 0
adding new entry "dc=example,dc=com"
ldap_add: Confidentiality required (13)
additional info: stronger confidentiality required for update
the log says:
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 fd=13 ACCEPT from
IP=127.0.0.1:56698 (IP=0.0.0.0:389)
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=0 STARTTLS
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=0 RESULT oid= err=0
text=
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 fd=13 TLS established
tls_ssf=128 ssf=128
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 BIND dn="" method=163
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 BIND
authcid="cn=ldapadmin,........." authzid="cn=ldapadmin,........"
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 BIND
dn="cn=ldapadmin,......." mech=EXTERNAL sasl_ssf=0 ssf=128
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 RESULT tag=97 err=0
text=
Oct 8 19:38:14 ldap slapd[2205]: connection_input: conn=1003 deferring
operation: binding
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=2 ADD
dn="dc=example,dc=com"
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=2 RESULT tag=105 err=13
text=stronger confidentiality required for update
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=3 UNBIND
Oct 8 19:38:14 ldap slapd[2205]: conn=1003 fd=13 closed
1. Why is the client connecting with ssf=128?
2. Can I influence the ssf used by client, if yes, how?
3. Maybe a certificate issue?
Thanks in advance,
Tobias Hachmer
12 years, 1 month
Re: Forcing TLS encryption
by Kurt Zeilenga
On Dec 28, 2012, at 12:56 PM, Wiebe Cazemier <wiebe(a)halfgaar.net> wrote:
> ----- Original Message -----
>> From: "Philip Guenther" <guenther+ldaptech(a)sendmail.com>
>> To: "Wiebe Cazemier" <wiebe(a)halfgaar.net>
>> Cc: "Dieter Klünter" <dieter(a)dkluenter.de>, openldap-technical(a)openldap.org
>> Sent: Friday, 28 December, 2012 9:36:50 PM
>> Subject: Re: Forcing TLS encryption
>>
>> On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
>>> I understand that, but this way, even when you're forcing TLS,
>>> users can
>>> still expose their passwords if their computers are mal-configured.
>>> SMTP, IMAP, FTP, etc don't allow this, because they reject the
>>> connection if LOGINNAME is given before STARTTLS.
>>
>> That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or
>> IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both
>> send
>> the username and password without waiting for a response from the
>> server**.
>>
>>
>>> It's kind of a security issue. Is it because in LDAP, username and
>>> password are given as one command, and the server doesn't have the
>>> chance to abort at that point? If so, then I guess it's
>>> unavoidable.
>>
>> Correct.
>>
>>
>> Philip Guenther
>>
>> ** Well, to be completely accurate, IMAP AUTHENTICATE requires a
>> server
>> response if the server doesn't support the SASL-IR capability
>>
>>
>
> Then why is the LDAPS port deprecated? If the connection is SSL from the start, you don't have this issue.
You still have the issue that the client might be configured for ldap://host:636 and Simple Bind or SASL PLAIN (generally by user mis-configuration).
In short, nothing in the server can prevent a poorly coded or poorly configured client from disclosing a user password in appropriately.
ldaps:// was never standardized and hence deprecated. There were many reasons why the IETF choose not to standardize ldaps://, one being interoperability issues between pre-existing implementations... another being that it viewed as not needed.
-- Kurt
11 years, 10 months
Re: Issue renewing my TLSCertificateFile(s)
by Clément OUDOT
Le 22/07/2015 18:27, Olivier a écrit :
> Hi everyone
>
> Question : are there some limitations (key size, encryption algorithm,
> etc.) for certificates used by openldap to manage TLS connexions ?
>
> See below why I ask :
>
> I have used the following configuration in my slapd servers for quite
> a while without any problem :
>
> olcTLSCACertificateFile: /etc/openldap/cacerts/CA.crt
> olcTLSCertificateFile: /etc/openldap/cacerts/server.crt
> olcTLSCertificateKeyFile: /etc/openldap/cacerts/server.key
> olcTLSCipherSuite: HIGH
> olcTLSVerifyClient: allow
>
> See for example my configuration for syncrepl (see: tls_reqcert=demand) :
>
> olcSyncrepl: {0}rid=411 provider=ldap://ldap1.example.fr
> <http://ldap1.example.fr> bindmethod=sasl
> sizelimit=unlimited timeout=0 network-timeout=0 saslmech=external type
> =refreshAndPersist retry="5 +" starttls=yes
> tls_cacert=/etc/openldap/cacer
> ts/CA.crt tls_cert=/etc/openldap/cacerts/replicator.crt
> tls_key=/etc/openldap
> /cacerts/replicator.key scope=sub schemachecking=on keepalive=0:0:0 fil
> ter="(objectclass=*)" searchbase="dc=example,dc=fr" tls_reqcert=demand
>
> -> I have used this for couple of years on my multimastered ldap
> servers, and until yesterday that worked perfectly : replication was
> working properly and clients talked with the servers using TLS without
> any problem.
>
> But I since my certicates were too weak (see this : sha1, 512 bit) :
>
> $ openssl x509 -text -in server.crt
>
> Certificate:
> Data:
> Version: 1 (0x0)
> Serial Number: 13998752034197585248 (0xc2458ece791fbd60)
> Signature Algorithm: sha1WithRSAEncryption
> Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT,
> CN=ldap/emailAddress=ldap(a)example.fr <mailto:ldap@example.fr>
> Validity
> Not Before: Dec 29 15:41:56 2011 GMT
> Not After : Jul 29 15:41:56 2021 GMT
>
> Subject: C=fr, ST=IDF, L=Town, O=example,
> OU=IT,CN=ldap1.example.fr/emailAddress=ldap(a)example.fr
> <http://ldap1.example.fr/emailAddress=ldap@example.fr>
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (512 bit)
>
>
> I have renewed them using the same self signed authority to validate
> them, and of course using exactly the same subject. My new certificate
> look like this :
>
> $ openssl x509 -text -in server.crt (see this : sha2, 4096 bit) :
>
> Certificate:
> Data:
> Version: 1 (0x0)
> Serial Number: 10208063777793278590 (0x8daa53ebd7e6827e)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT,
> CN=ldap/emailAddress=ldap(a)example.fr <mailto:ldap@example.fr>
> Validity
> Not Before: Jul 22 15:24:50 2015 GMT
> Not After : Feb 19 15:24:50 2025 GMT
>
> Subject: C=fr, ST=IDF, L=Town, O=example,
> OU=IT,CN=ldap1.example.fr/emailAddress=ldap(a)example.fr
> <http://ldap1.example.fr/emailAddress=ldap@example.fr>
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (4096 bit)
> Modulus:
>
> I installed my new certificate on ldap1 without changing the
> configuration, and restarting the server here is what I get on ldap4
> logs (loglevel = sync ) :
>
> $ tail -f /var/log/ldap.log
> ...
> Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect:
> URI=ldap://ldap1.example.fr <http://ldap1.example.fr> Warning,
> ldap_start_tls failed (-11)
> Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect:
> URI=ldap://ldap1.example.fr <http://ldap1.example.fr>
> ldap_sasl_interactive_bind_s failed (-2)
> Jul 22 17:31:10 ldap4 slapd[53489]: do_syncrepl: rid=432 rc -2 retrying
> Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect:
> URI=ldap://ldap1.example.fr <http://ldap1.example.fr> Warning,
> ldap_start_tls failed (-11)
> Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect:
> URI=ldap://ldap1.example.fr <http://ldap1.example.fr>
> ldap_sasl_interactive_bind_s failed (-6)
> Jul 22 17:31:15 ldap4-mrs slapd[53489]: do_syncrepl: rid=432 rc -6
> retrying
>
> When reinstalling the previous certificates and restarting ldap1 the
> server I see this appearing in ldap4 logs :
> ...
> Jul 22 17:31:20 ldap4-mrs slapd[53489]: do_syncrep2: rid=432
> LDAP_RES_INTERMEDIATE - REFRESH_DELETE
>
> Question : are there some limitations (key size, encryption algorithm,
> etc.) for certificates used by openldap to manage TLS connexions ?
> Does openldap tls connections work with certificates sha 256 With RSA
> Encryption using a 4096 public key length ? May be I missed something ?
>
> (note : I use openssl to manage my certificates)
>
> Thanks for any help.
Hello Olivier,
as far as I know, there are no limitation on key size in OpenLDAP. You
should first try to test your new certificate by querying your LDAP
server with openssl s_client. Then you can try to use a higher log level
(use at least the 'conns' level) to get more details on the error. Try
to request the LDAP server with ldapsearch, first with LDAPS, then with
startTLS, and see what happens.
--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
87, rue de Turbigo - 75003 PARIS
9 years, 3 months
Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
by Abdelkader Chelouah
Hello,
make mdb and make mdb-its, all succeded under CentOS 7. As far as concerned
back-ldap, commit e224920ea5641b71bbd38604cb58bd1922537e7d (ITS#8427 Take
late TLS configuration into account) has fixed the regression introduced by
commit 6f623dfa1ca65698c19ccc6c058cd170e633384e (ITS#8427 Set up
TLS settings on each reconnection) with my test configuration.
Regard,
Kader
On Mon, Jul 15, 2019 at 6:18 PM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
> This is expected to be the only testing call for 2.4.48, with an
> anticipated release, depending on feedback, during the week of 2019/07/22.
>
> Specific to this release, it would be helpful if anyone using back-ldap or
> back-meta with TLS can confirm their existing configurations continue to
> work (Due to the changes related to ITS#8427).
>
> Generally, get the code for RE24:
>
> <
> http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…
> >
>
> Configure & build.
>
> Execute the test suite (via make test) after it is built. Optionally, cd
> tests && make its to run through the regression suite.
>
> Thanks!
>
> OpenLDAP 2.4.48 Engineering
> Added libldap OpenSSL Elliptic Curve support (ITS#7595)
> Added libldap Expose OpenLDAP specific interfaces via openldap.h
> (ITS#8671)
> Added slapd-monitor support for slapd-mdb (ITS#7770)
> Fixed liblber leaks (ITS#8727)
> Fixed liblber with partial flush (ITS#8864)
> Fixed libldap ASYNC TLS so it works (ITS#8957,ITS#8980)
> Fixed libldap ASYNC connections with Solaris 10 (ITS#8968)
> Fixed libldap with SASL_NOCANON=on and ldapi connections (ITS#7585)
> Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326)
> Fixed libldap to be able to unset syncrepl TLS options (ITS#7042)
> Fixed libldap race condition in ldap_int_initialize (ITS#7996,
> ITS#8450)
> Fixed libldap return code in ldap_create_assertion_control_value
> (ITS#8674)
> Fixed libldap to correctly disable IPv6 when configured to do so
> (ITS#8754)
> Fixed libldap to correctly close TLS connection (ITS#8755)
> Fixed libldap_r handling of deprecated OpenSSL function (ITS#8353)
> Fixed liblunicode case correspondance (ITS#8508)
> Fixed slapd with an idletimeout of less than four seconds (ITS#8952)
> Fixed slapd config parser variable for Windows64 (ITS#9012)
> Fixed slapd syncrepl fallback handling with delta-syncrepl (ITS#9015)
> Fixed slapd telephoneNumberNormalize, cert DN validation (ITS#8999)
> Fixed slapd syncrepl for relax with delta-syncrepl (ITS#8037)
> Fixed slapd TLS settings on reconnection (ITS#8427)
> Fixed slapd to restrict rootDN proxyauthz to its own databases
> (ITS#9038)
> Fixed slapd to initialize SASL SSF per connection (ITS#9052)
> Fixed slapo-accesslog with SLAP_MOD_SOFT modifications (ITS#8990)
> Fixed slapd-ldap starttls connections timeout behavior (ITS#8963)
> Fixed slapd-ldap TLS settings on reconnection (ITS#8427)
> Fixed slapd-ldap segfault when entry result doesn't match filter
> (ITS#8997)
> Fixed slapd-meta conversion from slapd.conf to cn=config (ITS#8743)
> Fixed slapd-meta TLS settings on reconnection (ITS#8427)
> Fixed slapd-meta assertion when network interface goes down (ITS#8841)
> Fixed slapd-mdb fix bitshift integer overflow (ITS#8989)
> Fixed slapd-mdb index cleanup with cn=config (ITS#8472)
> Fixed slapd-mdb to improve performance with alias deref (ITS#7657)
> Fixed slapo-accesslog possible assert with exops (ITS#8971)
> Fixed slapo-chain to correctly reject multiple chaining URIs (ITS#8637)
> Fixed slapo-chain conversion from slapd.conf to cn=config (ITS#8799)
> Fixed slapo-memberof conversion from slapd.conf to cn=config (ITS#8663)
> Fixed slapo-memberof for group name change to itself (ITS#9000)
> Fixed slapo-ppolicy behavior when pwdInHistory is changed (ITS#8349)
> Fixed slapo-rwm to not free original filter (ITS#8964)
> Fixed slapo-syncprov contextCSN generation (ITS#9015)
> Build Environment
> Fixed slapd to only link to BDB libraries with static build
> (ITS#8948)
> Fixed libldap implicit declaration with LDAP_CONNECTIONLESS
> (ITS#8794)
> Fixed libldap double inclusion of limits.h in cyrus.c (ITS#9041)
> Documentation
> General - Fixed minor typos (ITS#8764, ITS#8761)
> admin24 - Miscellaneous updates promoting mdb and fixing examples
> (ITS#9031)
> slapd.access(5) - Note MDB is the primary backend (ITS#8881)
> slapd.backends(5) - Note MDB is the recommended backend (ITS#8771)
> slapd-ldap(5) - Document starttls parameter (ITS#8693)
> Contrib
> Added slapo-lastbind capability to forward authTimestamp updates
> (ITS#7721)
>
> LMDB 0.9.24 Engineering
> ITS#8969 Tweak mdb_page_split
> ITS#8975 WIN32 fix writemap set_mapsize crash
> ITS#9007 Fix loose pages in WRITEMAP
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
>
5 years, 4 months
master/slave sync stops working
by Kai Wiechers
Hi List,
I have trouble with my fresh setup openLDAP Master/Slave sync.
The slave stops syncing every few hours with the message shown below. If I
restart the slave things start working again. I monitored the network
connectivity between th hosts and there is no issue with that.
Debug output running slapd -d 256 -d 128
5b23c9dc do_syncrep2: rid=001 (-1) Can't contact LDAP server
5b23c9dc do_syncrepl: rid=001 rc -1 retrying (4 retries left)
/var/log/syslog:
Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrep2: rid=001 (-1) Can't
contact LDAP server
Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrepl: rid=001 rc -1
retrying (4 retries left)
I'm running
Ubuntu 16.04.4
openLDAP 2.4.42 (from Ubuntu repository)
on both servers.
I setup the sync using these LDIF files on master:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {0}
-
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=domain,dc=com" write
by dn="cn=replicator,dc=domain,dc=com" write
by self write
by anonymous auth
by * none
-
delete: olcAccess
olcAccess: {2}
-
add: olcAccess
olcAccess: {2}to *
by dn="cn=admin,dc=domain,dc=com" manage
by dn="cn=replicator,dc=domain,dc=com" manage
by self write
by anonymous auth
by users read
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID,entryCSN eq
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
On the Slave I imported these LDIF files:
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID,entryCSN eq
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001
provider=ldap://ldap-master.domain.com/
bindmethod=simple
binddn="cn=replicator,dc=domain,dc=com"
credentials=PASSWORD
searchbase="dc=domain,dc=com"
scope=sub
schemachecking=on
type=refreshAndPersist
retry="30 5 300 3"
interval=00:00:00:30
starttls=yes
tls_reqcert=allow
I'm really new to openLDAP so please let me know how to provide additional
Info if you need them.
Thanks and best regards,
Kai
6 years, 5 months
Re: olcDbAclBind docs?
by Mike W
On 5/17/2013 1:14 PM, Howard Chu wrote:
> Mike W wrote:
>>
>> I am attempting to setup communication between 2 ldap servers but having
>> issues when trying to limit access. I have dug around the source a bit
>> and found a few commands but unable to find any documentation anywhere
>> on them.
>>
>> olcDbAclBind
>
> slapd-ldap(5) acl-bind.
Forgive me, but I am new to openldap. That seemed to be for the older
slapd.conf style, not the RTC style? Assuming that those commands should
be similar I configured and tested but no luck. Perhaps someone can see
the problem.
Goal, lab5 talk to lab4, read only requiring creds.
-------- lab5---------------
dn: olcDatabase={4}ldap
objectClass: olcDatabaseConfig
objectClass: olcLdapConfig
olcDatabase: {4}ldap
olcReadonly: TRUE
olcSuffix: dc=mydomain,dc=foo
olcRootDN: dc=mydomain,dc=foo
olcDbACLBind: bindmethod=simple timeout=5 network-timeout=5
binddn="cn=Manager,dc=mydomain,dc=foo" credentials=secret starttls=no
olcDbURI: "ldap://lab4.host.com:389"
-------------------------
-----lab4----------------
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcSuffix: dc=mydomain,dc=foo
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=Manager,dc=mydomain,dc=foo
olcRootPW: secret
olcAccess: to dn.base="cn=Manager,dc=mydomain,dc=foo" by users read
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap/foo
olcDbCacheSize: 1000
olcDbCheckpoint: 1024 15
olcDbConfig: {70}
olcDbConfig: {71}#set_flags DB_TXN_NOSYNC
olcDbConfig: {72}#set_flags DB_TXN_NOT_DURABLE
olcDbConfig: {73}
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: ou pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
-------------------------
When I connect to lab4 from lab5 I see this in the log:
conn=1005 op=0 BIND dn="" method=128
Which seems to indicate my dn is not getting across somehow. I suspect
it's something in the way I am trying to translate the commands from
slapd.conf to this version? Either that or my lack of experience
w/openldap is completely off base.
Thanks for any input.
--
Mike Wilson
11 years, 6 months
Re: Ldap is up, trying to get tls working.
by John Tobin
Dear Jaun,
Actually I am just getting back to it.
This is finals week. Things will get quiet enough this week that I could
pursue it.
And no, I never got it to work, I had it traced via log entries, and was
going to compare the traces [ldapsearch works with -ZZ, vs. through the ldap
client under linux for nscd or nslcd which fails] and try to do some problem
source identification [What actually is the problem, which code is the
culprit] starting shortly, and going into January.
I am trying to get a handle on whether I should pursue this with nscd or
nslcd. If You have advice there, I am listening. To my knowledge I had nscd
configured correctly when it failed, but I need some more information on
nslcd.
I would very much like a secure [either tls via ldaps, or tls via straight
ldap with tls on] interface, since in the spring some of my networks will
have security classes on them, and to best understand [and illustrate] how
network security works, the instructors will be putting infectious code on
those networks.
FYI I am 2.4.26 openldap on 2 lab networks, ldap is working well in support
of a couple of coordinated projects. All of the machines currently supported
are suse 12.1 milestone 5. Testing is being done on both separate clients
and with the client on the serving machine [both show the same failure at
the moment.].
Why are you interested, and is there anything I can assist you with?
[By the way if any of the broader ldap community has input here, I would
appreciate it.]
Sincerely,
tob
On 12/8/11 9:59 AM, "Juan Miscaro" <jmiscaro(a)gmail.com> wrote:
> On 1 November 2011 11:53, John Tobin <jtobin(a)po-box.esu.edu> wrote:
>> Certificates verify.
>> That's a neat tool, put that information somewhere useful.
>> I had been trying to prove that the certificates were good for a long time.
>>
>> I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd
>>
>> That wasn't too bad.
>>
>> I configured nslcd with:
>>
>> Uri ldap://nightmare.dark.net:389/
>>
>> Base "dc=dark,dc=net"
>>
>> Ssl start_tls
>> Tls_req never
>> Tls_cacertfile /var/lib/ldap/cacert.pem
>>
>> Tls_cert /var/lib/ldap/server.pem
>> Tls_key /var/lib/ldap/server.key
>>
>> Ldapsearch still works .... With -ZZ
>>
>> But su - jtobin
>> Gets the same error message this time from kdeinit:
>>
>> nightmare:/var/log # tail -f messages |grep tls
>> Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
>> failed:stat=-1
>> Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
>> failed:stat=-1
>>
>> I guess I am wondering if I configured something wrong....
>> Why am I seeing nss-ldap in here...
>>
>> I installed nslcd, configured it, and didn't change any thing in ldap.conf
>> or nsswitch.conf, should anything else be changed?
>>
>> tob
>>
>>
>> nighttrain:~ johntobin$
>>
>>
>>
>>
>>
>>
>>
>> On 10/28/11 12:08 PM, "Christopher Wood" <christopher_wood(a)pobox.com> wrote:
>>
>>> Cheap advice inline.
>>>
>>> On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote:
>>>> Folks,
>>>>
>>>> I have openldap up, it supports vsftpd, sshd, and 5 client linux
>>>> machines
>>>> for remote login.
>>>>
>>>> I would like to get tls working. I would support either ldaps [port
>>>> 636],
>>>> or the tls available on port 389, I am aware of the differences in
>>>> implementation, and the fact that an administrator effectively has to
>>>> make
>>>> a decision to support one or the other in most cases.
>>>>
>>>> Currently:
>>>> I have slapd running configured for tls under ldap [std port 389].
>>>> I am testing it on the slapd machine, with a client on the same machine.
>>>> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and
>>>> ldap.conf.
>>>>
>>>> With that in place, and the ldap.conf below:
>>>> nightmare:/etc # cat ldap.conf
>>>>
>>>> base dc=dark,dc=net
>>>> uri ldap://nightmare.dark.net
>>>> # scope sub
>>>> # binddn "cn=admin,dc=dark,dc=net"
>>>> # bindpw jackie
>>>> bind_policy soft
>>>> # The user ID attribute (defaults to uid)
>>>> pam_login_attribute uid
>>>> pam_lookup_policy yes
>>>> pam_password exop
>>>> nss_schema rfc2307bis
>>>> tls_reqcert never
>>>> pam_filter objectClass=posixAccount
>>>> ldap_version 3
>>>> nss_map_attribute uniqueMember uniqueMember
>>>> ssl start_tls
>>>> tls_cacert /var/lib/ldap/cacert.pem
>>>> tls_cert /var/lib/server.crt
>>>> tls_key /var/lib/ldap/server.key
>>>>
>>>> I have run ldapsearch:
>>>> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b
>>>> "dc=dark,dc=net" -Z
>>>
>>> Always test starttls with -ZZ, so if your starttls isn't working the
>>> connection will fail.
>>>
>>>> ldap_initialize( ldap://nightmare.dark.net:389/??base )
>>>> filter: (objectclass=*)
>>>> requesting: All userApplication attributes
>>>> # extended LDIF
>>>> #
>>>> # LDAPv3
>>>> # base <dc=dark,dc=net> with scope subtree
>>>> # filter: (objectclass=*)
>>>> # requesting: ALL
>>>> #
>>>>
>>>> # dark.net
>>>> dn: dc=dark,dc=net
>>>> dc: dark
>>>> o: dark
>>>> objectClass: organization
>>>> objectClass: dcObject
>>>>
>>>> # admin, dark.net
>>>> dn: cn=admin,dc=dark,dc=net
>>>> objectClass: organizationalRole
>>>> cn: admin
>>>>
>>>> # Default Policy, dark.net
>>>> dn: cn=Default Policy,dc=dark,dc=net
>>>> objectClass: namedObject
>>>> objectClass: pwdPolicy
>>>> cn: Default Policy
>>>>
>>>> # People, dark.net
>>>> dn: ou=People,dc=dark,dc=net
>>>> objectClass: organizationalUnit
>>>> ou: People
>>>> description: People is used in mapping the /etc/passwd entries
>>>>
>>>> # jtobin, People, dark.net
>>>> dn: uid=jtobin,ou=People,dc=dark,dc=net
>>>> uid: jtobin
>>>> cn: John C. Tobin
>>>> objectClass: account
>>>> objectClass: posixAccount
>>>> objectClass: top
>>>> objectClass: shadowAccount
>>>> loginShell: /bin/ksh
>>>> uidNumber: 5000
>>>> gidNumber: 100
>>>> homeDirectory: /home/jtobin
>>>> gecos: John C. Tobin
>>>>
>>>> # defaultDNS, dark.net
>>>> dn: cn=defaultDNS,dc=dark,dc=net
>>>> cn: defaultDNS
>>>> objectClass: top
>>>> objectClass: suseDnsConfiguration
>>>> suseDefaultBase: ou=DNS,dc=dark,dc=net
>>>>
>>>> # DNS, dark.net
>>>> dn: ou=DNS,dc=dark,dc=net
>>>> objectClass: top
>>>> objectClass: organizationalUnit
>>>> ou: DNS
>>>>
>>>> # search result
>>>> search: 3
>>>> result: 0 Success
>>>>
>>>> # numResponses: 8
>>>> # numEntries: 7
>>>>
>>>> nightmare:~ #
>>>> #####
>>>>
>>>> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with
>>>> tls
>>>> works.
>>>> [I looked through the message output in /var/log/message and see the
>>>> ³STARTTLS² and ³TLS established tls_ssf=256²]
>>>> I have done a number of similar ldapsearches. This appears to work
>>>> correctly.
>>>>
>>>> On the client machine I now do :
>>>>
>>>> nightmare:/media # su - jtobin
>>>> su: user jtobin does not exist
>>>> nightmare:/media #
>>>>
>>>> /var/log/message - output......
>>>>
>>>> nightmare:/var/log # tail f |grep I tls
>>>>
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS
>>>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
>>>> failed:stat=-1
>>>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
>>>> failure error=-1 id=1217, closing
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS
>>>> negotiation failure)
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS
>>>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
>>>> failed:stat=-1
>>>
>>> Augh. If you can stop using nscd all this will be much easier for you. I
>>> personally like nslcd rather than nss-ldap, but each to their own.
>>>
>>> If not, restart nscd before you start every troubleshooting round.
>>>
>>>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
>>>> failure error=-1 id=1218, closing
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS
>>>> negotiation failure)
>>>
>>> First I would test that all the CA certs and server certs in use are
>>> understandable by each other. Does the server cert on the machine running
>>> slapd validate against the CA cert on the machine running ldapsearch? Does
>>> the
>>> server cert on the machine running slapd validate against the CA cert on the
>>> client machine?
>>>
>>> openssl verify -CAfile cacert.pem servercert.pem
>>>
>>> If the output says "ok" then the actual cert part is fine.
>>>
>>> At this point I would crank up the slapd debug level (run it in the
>>> foreground) and match it again your ldap client debug logs. See if you can
>>> reproduce the error above using a client like ldapsearch, using the same
>>> search parameters as the nss-ldap client would use.
>>>
>>>> [if you want more of the log, I can obviously get it, but these appear
>>>> to
>>>> be the important parts.]
>>>>
>>>> This is probably a configuration error, or a logical / architecture
>>>> misunderstanding, ok, I Œm a newbie.
>>>> Do I have certificates incorrectly generated? [certificates were
>>>> generated
>>>> via [1]http://www.openldap.org/faq/data/cache/185.html].
>>>> What did I do wrong?
>>>>
>>>> This is running openldap 2.4.26 off of Suse 12.1 milestone 5.
>>>
>>> I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but
>>> much the same thing.
>>>
>>>> Thanks in advance.
>>>> tob
>>>>
>>>> References
>>>>
>>>> Visible links
>>>> 1. http://www.openldap.org/faq/data/cache/185.html
>>>
>>
>>
>
>
>
> Did you ever get this to work?
12 years, 11 months
Re: Ldap is up, trying to get tls working.
by Raffael Sahli
On 13.12.2011 19:18, John Tobin wrote:
> Ok,
>
> I now have time to work on this.
> Please find ldap.conf, /etc/openldap/slapd/cn=config.ldif, and nslcd.conf
> attached.
>
> I am running slapd /openldap 2.4.26 /w nslcd on suse 12.1 mile post 5
> Ldap is up and running, without tls. My job here is to get tls running.
>
> It was mentioned that nslcd maybe a good possibility for fixing my tls/ssl
> problems, so I have installed it. I am not sure I have it configured
> correctly, I have not been able to find much documentation on it besides the
> nslcd.conf information, so I have setup nslcd.conf in a way I thought
> reasonable, and made the necessary changes to nsswitch.conf.
>
> I am open to further configuration changes if those are required.
> I used the 185.html for creating certificates, all testing at the moment is
> being done on a single machine [nightmare.dark.net] which has both slapd and
> nslcd running on it, so it is the test base for both the server and the
> client.
>
> Ldapsearch still works well with the -ZZ option, for tls.
> There is an ldap browser for SuSe that also works under tls.
> I assume from this that the server slapd is working correctly.
>
> I am unable to get an ldap client using tls to work under this
> configuration.
I guess the problem is your ca cert. ldap command line tools read the
ldap.conf including tls_cacert.
But maybe your gui ldap client don't read the ldap.conf, did you
installed the ca cert globally in your cert storage?
You should see some tls ca cert errors on your slapd server.
>
> Any suggestions or assistance to help resolve the problem would be
> appreciated.
>
> Using nscd, and simple ldap.conf, I captured the logs involved in both the
> successful ldapsearch, and the unsuccessful client attempts to use slapd
> [see below.]
>
> Sincerely,
> tob
>
>
>
> On 11/1/11 11:53 AM, "John Tobin"<jtobin(a)po-box.esu.edu> wrote:
>
>> Certificates verify.
>> That's a neat tool, put that information somewhere useful.
>> I had been trying to prove that the certificates were good for a long time.
>>
>> I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd
>>
>> That wasn't too bad.
>>
>> I configured nslcd with:
>>
>> Uri ldap://nightmare.dark.net:389/
>>
>> Base "dc=dark,dc=net"
>>
>> Ssl start_tls
>> Tls_req never
>> Tls_cacertfile /var/lib/ldap/cacert.pem
>>
>> Tls_cert /var/lib/ldap/server.pem
>> Tls_key /var/lib/ldap/server.key
>>
>> Ldapsearch still works .... With -ZZ
>>
>> But su - jtobin
>> Gets the same error message this time from kdeinit:
>>
>> nightmare:/var/log # tail -f messages |grep tls
>> Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
>> failed:stat=-1
>> Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
>> failed:stat=-1
>>
>> I guess I am wondering if I configured something wrong....
>> Why am I seeing nss-ldap in here...
>>
>> I installed nslcd, configured it, and didn't change any thing in ldap.conf
>> or nsswitch.conf, should anything else be changed?
>>
>> tob
>>
>>
>> nighttrain:~ johntobin$
>>
>>
>>
>>
>>
>>
>>
>> On 10/28/11 12:08 PM, "Christopher Wood"<christopher_wood(a)pobox.com> wrote:
>>
>>> Cheap advice inline.
>>>
>>> On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote:
>>>> Folks,
>>>>
>>>> I have openldap up, it supports vsftpd, sshd, and 5 client linux machines
>>>> for remote login.
>>>>
>>>> I would like to get tls working. I would support either ldaps [port 636],
>>>> or the tls available on port 389, I am aware of the differences in
>>>> implementation, and the fact that an administrator effectively has to
>>>> make
>>>> a decision to support one or the other in most cases.
>>>>
>>>> Currently:
>>>> I have slapd running configured for tls under ldap [std port 389].
>>>> I am testing it on the slapd machine, with a client on the same machine.
>>>> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and
>>>> ldap.conf.
>>>>
>>>> With that in place, and the ldap.conf below:
>>>> nightmare:/etc # cat ldap.conf
>>>>
>>>> base dc=dark,dc=net
>>>> uri ldap://nightmare.dark.net
>>>> # scope sub
>>>> # binddn "cn=admin,dc=dark,dc=net"
>>>> # bindpw jackie
>>>> bind_policy soft
>>>> # The user ID attribute (defaults to uid)
>>>> pam_login_attribute uid
>>>> pam_lookup_policy yes
>>>> pam_password exop
>>>> nss_schema rfc2307bis
>>>> tls_reqcert never
>>>> pam_filter objectClass=posixAccount
>>>> ldap_version 3
>>>> nss_map_attribute uniqueMember uniqueMember
>>>> ssl start_tls
>>>> tls_cacert /var/lib/ldap/cacert.pem
>>>> tls_cert /var/lib/server.crt
>>>> tls_key /var/lib/ldap/server.key
>>>>
>>>> I have run ldapsearch:
>>>> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b
>>>> "dc=dark,dc=net" -Z
>>> Always test starttls with -ZZ, so if your starttls isn't working the
>>> connection will fail.
>>>
>>>> ldap_initialize( ldap://nightmare.dark.net:389/??base )
>>>> filter: (objectclass=*)
>>>> requesting: All userApplication attributes
>>>> # extended LDIF
>>>> #
>>>> # LDAPv3
>>>> # base<dc=dark,dc=net> with scope subtree
>>>> # filter: (objectclass=*)
>>>> # requesting: ALL
>>>> #
>>>>
>>>> # dark.net
>>>> dn: dc=dark,dc=net
>>>> dc: dark
>>>> o: dark
>>>> objectClass: organization
>>>> objectClass: dcObject
>>>>
>>>> # admin, dark.net
>>>> dn: cn=admin,dc=dark,dc=net
>>>> objectClass: organizationalRole
>>>> cn: admin
>>>>
>>>> # Default Policy, dark.net
>>>> dn: cn=Default Policy,dc=dark,dc=net
>>>> objectClass: namedObject
>>>> objectClass: pwdPolicy
>>>> cn: Default Policy
>>>>
>>>> # People, dark.net
>>>> dn: ou=People,dc=dark,dc=net
>>>> objectClass: organizationalUnit
>>>> ou: People
>>>> description: People is used in mapping the /etc/passwd entries
>>>>
>>>> # jtobin, People, dark.net
>>>> dn: uid=jtobin,ou=People,dc=dark,dc=net
>>>> uid: jtobin
>>>> cn: John C. Tobin
>>>> objectClass: account
>>>> objectClass: posixAccount
>>>> objectClass: top
>>>> objectClass: shadowAccount
>>>> loginShell: /bin/ksh
>>>> uidNumber: 5000
>>>> gidNumber: 100
>>>> homeDirectory: /home/jtobin
>>>> gecos: John C. Tobin
>>>>
>>>> # defaultDNS, dark.net
>>>> dn: cn=defaultDNS,dc=dark,dc=net
>>>> cn: defaultDNS
>>>> objectClass: top
>>>> objectClass: suseDnsConfiguration
>>>> suseDefaultBase: ou=DNS,dc=dark,dc=net
>>>>
>>>> # DNS, dark.net
>>>> dn: ou=DNS,dc=dark,dc=net
>>>> objectClass: top
>>>> objectClass: organizationalUnit
>>>> ou: DNS
>>>>
>>>> # search result
>>>> search: 3
>>>> result: 0 Success
>>>>
>>>> # numResponses: 8
>>>> # numEntries: 7
>>>>
>>>> nightmare:~ #
>>>> #####
>>>>
>>>> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with
>>>> tls
>>>> works.
>>>> [I looked through the message output in /var/log/message and see the
>>>> ³STARTTLS² and ³TLS established tls_ssf=256²]
>>>> I have done a number of similar ldapsearches. This appears to work
>>>> correctly.
>>>>
>>>> On the client machine I now do :
>>>>
>>>> nightmare:/media # su - jtobin
>>>> su: user jtobin does not exist
>>>> nightmare:/media #
>>>>
>>>> /var/log/message - output......
>>>>
>>>> nightmare:/var/log # tail f |grep I tls
>>>>
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS
>>>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
>>>> failed:stat=-1
>>>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
>>>> failure error=-1 id=1217, closing
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS
>>>> negotiation failure)
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS
>>>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
>>>> failed:stat=-1
>>> Augh. If you can stop using nscd all this will be much easier for you. I
>>> personally like nslcd rather than nss-ldap, but each to their own.
>>>
>>> If not, restart nscd before you start every troubleshooting round.
>>>
>>>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
>>>> failure error=-1 id=1218, closing
>>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS
>>>> negotiation failure)
>>> First I would test that all the CA certs and server certs in use are
>>> understandable by each other. Does the server cert on the machine running
>>> slapd validate against the CA cert on the machine running ldapsearch? Does
>>> the
>>> server cert on the machine running slapd validate against the CA cert on the
>>> client machine?
>>>
>>> openssl verify -CAfile cacert.pem servercert.pem
>>>
>>> If the output says "ok" then the actual cert part is fine.
>>>
>>> At this point I would crank up the slapd debug level (run it in the
>>> foreground) and match it again your ldap client debug logs. See if you can
>>> reproduce the error above using a client like ldapsearch, using the same
>>> search parameters as the nss-ldap client would use.
>>>
>>>> [if you want more of the log, I can obviously get it, but these appear to
>>>> be the important parts.]
>>>>
>>>> This is probably a configuration error, or a logical / architecture
>>>> misunderstanding, ok, I Œm a newbie.
>>>> Do I have certificates incorrectly generated? [certificates were
>>>> generated
>>>> via [1]http://www.openldap.org/faq/data/cache/185.html].
>>>> What did I do wrong?
>>>>
>>>> This is running openldap 2.4.26 off of Suse 12.1 milestone 5.
>>> I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but
>>> much the same thing.
>>>
>>>> Thanks in advance.
>>>> tob
>>>>
>>>> References
>>>>
>>>> Visible links
>>>> 1. http://www.openldap.org/faq/data/cache/185.html
>>
--
Raffael Sahli
public(a)raffaelsahli.com
12 years, 11 months