openldap-technical

openldap-technical@openldap.org

21 participants
9787 discussions

Query on ldap sasl bind
by Nishanth Nagendra 10 Jul '17

10 Jul '17

Hi All, I am new to Openldap and have been doing some basic testing with an application software I am working with. This software has an ldap protocol interface that talks to an ldap server using the Openldap library version 2.4 supporting operations such as search, add, delete. I am currently facing a challenge in understanding as to how this interface can send out a bind request with sasl mechanism as not simple. The code snippet trying to initiate an asynchronous bind is as below: ldap_sasl_bind(ldaphandle, dn, NULL, cred, NULL, NULL , &msgID); This code is initiating a bind with mechanism as simple when I capture the packets on the wire which I believe is because of the third parameter in this function call being NULL. The man page for bind operations http://www.openldap.org/software/man.cgi?query=ldap_sasl_bind&apropos=0&sek… does not speak about what values should I pass to the third parameter if I want to use a specific sasl mechanism. Can this just be a user defined string or a specific string that openldap expects. >From the openldap source code, I notice that sasl.c file has a constant LDAP_SASL_SIMPLE as a constant for mechanism which is a NULL value. I tried to pass a non NULL value in my function call to ldap_sasl_bind in the third parameter expecting it to hit the other code path to initiate SASL bind with credentials but the library does not seem to allow it and returns error from sasl bind. Any inputs in this direction would be really helpful. regards, Nishanth

1 0

openldap under openbsd
by Paul B. Henson 09 Jul '17

09 Jul '17

I was curious if anybody is running openldap under openbsd? The version in their ports system has mdb disabled, it says mdb is unreliable and results in random slapd crashes. It seems openbsd lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option; they added a patch to cause initialization to fail if that option isn't enabled but then ended up disabling it completely anyway. This was back in 2015, I'm not sure if they've tested it recently or what details there were behind the crashes before they ended up disabling it. I'm thinking of trying it out with the latest release and seeing what happens but was wondering if anybody else had any recent experience. Thanks...

1 0

LMDB persistent snapshots
by Michael Conrad 09 Jul '17

09 Jul '17

Hi, I'm scoping out my options for databases that support snapshotting. From what I've read so far, this is a natural feature of LMDB, however all the documentation talks about making sure not to let read transactions linger around. What if I *want* to hold onto a read transaction long-term, hours or even months? Also, I haven't yet seen a way for a new client to re-open the database as of the point in time of an existing transaction. Is this possible? If I manage to do something like this, will the storage overhead be roughly equivalent to the quantity of changed data between the snapshot and the latest write? or will the overhead be more like the sum of all writes + overwrites that happened since the read transaction started? i.e. if a read transaction is held starting from t0, then data is written at t1, then overwritten at t2 can the blocks affected by t1 be reclaimed for a write at t3? Thanks for any insight! -Mike

1 0

Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 08 Jul '17

08 Jul '17

--On Friday, July 07, 2017 6:27 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > olcDbStartTLS: ldaps starttls=no > tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer" > tls_reqcert=demand tls_crlcheck=none There is no such option as "starttls" for the olcDbStartTLS parameter. >From the man page: tls {[try-]start|[try-]propagate|ldaps} [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] Specify the use of TLS when a regular connection is initialized. The StartTLS extended operation will be used unless the URI directive protocol scheme is ldaps://. In that case this keyword may only be set to "ldaps" and the StartTLS operation will not be used. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is not recommended. My guess then is everything past that point is ignored, since you've provided invalid configuration data. The attribute is also poorly named, as it may or may not have anything to do with startTLS. More likely it should have just been called olcDbTLS --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 4

Re: [EXTERNAL] Re: back-ldap and ldaps not working
by Howard Chu 08 Jul '17

08 Jul '17

Jon C Kidder wrote: > Thanks Michael. The message is clear but the solution isn't. I think you missed the part about this exact same slapd node being a replication consumer replicating successfully using the exact same certificate/TLS setup. Just for added validation the masters have been active for a couple years serving a very active test environment with ~100 test clients connecting via ldaps. Something appears to be hinky with the configuration processing or certificate validation processing in back-ldap. My gut is that olcDBStartTLS isn't being converted/formatted correctly or isn't being parsed correctly and the option to set the path to the CA cert file is being ignored. In that case you could use strace to verify whether the CA cert file is ever being opened. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 9:39 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > Yeah, that's actually how I started and where the starttls=no setting > came from. > > This .conf section > > overlay chain > chain-uri "ldaps://ds2-q.global.aep.com" > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=simple > binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" > credentials=<redacted> mode="self" chain-tls ldaps > tls_cacert=/appl/openldap/etc/openldap/tls/cacerts.cer chain-return-error > TRUE Hm, if the conversion is adding that "starttls=no" to the cn=config database, that seems like a serious bug in the conversion process. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 8:10 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > I've removed the starttls=no syntax and the line now reads. > > olcDbStartTLS: ldaps > tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer " > tls_reqcert=demand tls_crlcheck=none > > I have verified the change propagated to the configuration directory and > restarted the instance. I saw no errors during configuration parsing in > the log. I am still seeing this error when the chain overlay tries to > follow the referral but no complaints when syncrepl connects. I'm not sure how you do this with cn=config. With slapd.conf, it would be done via using "chain-tls" and not "tls", as per the man page: There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be implicitly instantiated by the overlay may assume a special meaning when used in conjunction with this overlay. They are described in slapd-ldap(5), and they also need to be prefixed by chain-. It may be worthwhile to set up a slapd.conf where "chain-tls" is specified, and see what happens with that on conversion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

back-ldap and ldaps not working
by Jon C Kidder 07 Jul '17

07 Jul '17

I have the following attributes set in my ldap backend for the chain overlay. olcDbURI: "ldaps://ds2-q.global.aep.com:636" olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer" tls_reqcert=demand tls_crlcheck=none The referenced file is the exact same file I use in this global attribute olcTLSCACertificateFile: /appl/openldap/etc/openldap/tls/cacerts.cer This is a 2.4.44 replication consumer using the following replication attribute olcSyncrepl: {1}rid=112 provider=ldaps://ds2-q.global.aep.com:636 binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" bindmethod=simple credentials=<redacted> searchbase="dc=Global,dc=aep,dc=com" type=refreshAndPersist retry="5 5 300 +" timeout=1 Replication works perfectly and changes to the referenced master are replicated to this slave. I can see successful connections for rid=112 to this master in the log. The problem is when the chain overlay tries to follow referrals to this same master I get the following error: 595fbb1c conn=1000 op=1 ldap_chain_op: ref="ldaps://ds2-q.global.aep.com:636/uid=s012235,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" -> "ldaps://ds2-q.global.aep.com:636" 595fbb1c conn=1000 op=1 ldap_chain_op: ref="ldaps://ds2-q.global.aep.com:636/uid=s012235,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com": URI="ldaps://ds2-q.global.aep.com:636" found in cache ldap_create ldap_url_parse_ext(ldaps://ds2-q.global.aep.com:636) 595fbb1c =>ldap_back_getconn: conn=1000 op=1: lc=0x10180430 inserted refcnt=1 rc=0 ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ds2-q.global.aep.com:636 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying 10.92.127.52:636 ldap_pvt_connect: fd: 16 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com, issuer: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). 595fbb1c send_ldap_result: conn=1000 op=1 p=3 595fbb1c send_ldap_result: conn=1000 op=1 p=3 595fbb1c send_ldap_response: msgid=2 tag=103 err=52 ber_flush2: 14 bytes to sd 15 595fbb1c conn=1000 op=1 RESULT tag=103 err=52 text= So, is there something wrong with the value of the olcDBStartTLS attribute that I'm not seeing?? -Jon C. Kidder American Electric Power Complex - Middleware Engineering

1 0

RE: Using TLS
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:29 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Right, ldap_set_option doesn't take string input argument. I implied an > integer value such as LDAP_OPT_X_TLS_NEVER, LDAP_OPT_X_TLS_ALLOW, etc. > > I have no doubt it works nicely in your case. Just trying to understand > why it doesn't on my side. Hard to say without the full context of your code. It clearly works not just with what I did, but with other client code as well, whether it's the bits that part ldap.conf/.ldaprc to the syncrepl client code, etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: [EXTERNAL] Re: [Bad Attachment] Slave won't send referrals
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:20 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > Of course it did!! Lol Let's try this instead. > > https://1drv.ms/t/s!Ahoo4oNE6Txzgx4wf4gzVQkKPjG6 You have this set: olcMirrorMode: TRUE Which indicates you are saying this is a provider, not a consumer. This turns the ability to write to it on. That setting is *only* for mult-master configurations. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical