>On Wed, Dec 30, 2015 at 7:04 PM, Dan White <dwhite(a)cafedemocracy.org> wrote:
>> Is DIGEST-MD5 available on your ldap server? Try:
>>
>> ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b ""
>> supportedSASLMechanisms
On 12/31/15 09:51 -0600, Timothy Keith wrote:
>Dan, that ldapsearch returns :
>dn:
>supportedSASLMechanisms: PLAIN
>
On Mon, Jan 4, 2016 at 1:16 PM, Dan White <dwhite(a)cafedemocracy.org> wrote:
>> On 01/04/16 09:41 -0600, Timothy Keith wrote:
>>
>>> ldapwhoami -Y PLAIN -H ldap://182.19.136.42 -U testuser
>>>
>>> produces :
>>>
>>> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
>>> additional info: SASL(-4): no mechanism available: No worthy mechs
>>> found
On 01/04/16 14:47 -0600, Timothy Keith wrote:
>pluginviewer returned this, as well as several other plugins :
>
>List of server plugins follows
>
>
>Plugin "plain" [loaded], API version: 4
> SASL mechanism: PLAIN, best SSF: 0, supports setpass: no
> security flags: NO_ANONYMOUS
> features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION
Something doesn't add up here. The remote server claims to support sasl
plain, and your local server claims to support it as well.
I suppose your server could be claiming support, but not really supporting
it without a security layer, in which case you might investigate doing
ssl/starttls.
See if you can get a hold of any logs from the server.
--
Dan White
Hi Dieter,
Thanks for the reply.
My Apache is built with openldap lib only.
I am able to connect to ubuntu host my my solaris client on ports 389 and
636.
Then I guess, apache is not able to verify the certificates presented. In
that case, please let me know how do I debug slapd to watch apache
connection.
Thanks again.
Regards
Asimananda
On Thu, Sep 17, 2009 at 6:23 PM, Dieter Kluenter <dieter(a)dkluenter.de>wrote:
> Asimananda Mohanty <asimananda.mohanty(a)gmail.com> writes:
>
> > Hi Dieter,
> >
> > I understand. But my concern is if ssl was not enabled properly, then I
> should not be
> > able to use -ZZ or ldaps url in commands like ldapsearch. Please correct
> me if I am
> > wrong.
>
> If you can connect to slapd via startTLS or TLS than slapd has been
> setup correctly.
>
> > If ssl is enabled already, then I am unable to understand why ldaps
> doesn't work from
> > apache point of view.
>
> Back to my first mail. Ths is a question you have to raise on a solaris
> related mailing list or news group.
> - Check the libraries apache has been built with,
> - check whether you can connect from solaris host to ubuntu host on
> port 389 and 636 ,
> - check whether apache is able to verify the certificate presented,
> - debug slapd to whatch the apache connection.
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://dkluenter.de
> GPG Key ID:8EF7B6C6
> 53°37'09,95"N
> 10°08'02,42"E
>
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
--
Dieter Klünter | Systemberatung
sip: 7770535(a)sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
I'm using OpenLDAP 2.4.23-26 from Centos 6. I seem to be hitting a configuration issue regarding slapd-meta and SSL/TLS.
Here is my meta config:
database meta
suffix "dc=virtual,dc=local"
rootdn "cn=root,dc=virtual,dc=local"
rootpw password
# Local
uri ldap://localhost/dc=ds1,dc=virtual,dc=local
suffixmassage "dc=ds1,dc=virtual,dc=local" "dc=lab,dc=local"
idassert-bind bindmethod=simple binddn="cn=root,dc=lab,dc=local" credentials=password
#Remote AD server
uri ldap://10.33.63.125:389/dc=ad1,dc=virtual,dc=local
tls start
suffixmassage "dc=ad1,dc=virtual,dc=local" "dc=mslab,dc=local"
idassert-bind bindmethod=simple binddn="CN=Sync,CN=Users,DC=lab,DC=local" credentials="Password1" starttls="yes" tls_reqcert="allow"
It seems as though tls_reqcert="allow" is ignored for the remote AD server. If set that variable in the ldap.conf everything works fine. But shouldn't the above function as an override to the default of 'demand'? The behaviour is the same when I change the above to use SSL instead.
Another thing I noticed was that adding tls_crlcheck="none" to my idassert-bind line causes slaptest to fail..not sure if this is related or not.
/etc/openldap/slapd.conf: line 68: "idassert-bind <args>": unable to parse field "tls_crlcheck=none".
slaptest: bad configuration file!
I must be misunderstanding the docs. Any help would be appreciated.
--On Tuesday, November 14, 2017 8:56 PM +0000 Kaya Saman
<kayasaman(a)gmail.com> wrote:
> access to *
> by ssf=128 self write
> by ssf=128 anonymous auth
> by ssf=128 users read
>
>
>
>
># Added ACL for open access to AddressBook in Read and Search only mode
>
> access to dn.children="ou=AddressBook,dc=domain,dc=com"
> by * search
> by * read
Your second ACL will never be evaluated, since the first ACL matches
everything. As noted in the slapd.access(5) man page, ACL processing stops
on the first matching ACL.
In addition, in your second ACL, the "by * read" will never be processed,
because of the match to "by * search". If you're already planning on
granting read, there is no point to having by * search there at all.
I.e., your ACLs should be:
access to dn.children="ou=AddressBook,dc=domain,dc=com"
by * read
access to *
by ssf=128 self write
by ssf=128 anonymous auth
by ssf=128 users read
And I generally doubt you want to give users read to "*", as this means
they can read the userPassword values of other users, etc.
You might want something more like:
access to dn.children="ou=AddressBook,dc=domain,dc=com"
by * read
access to attrs=userPassword
by ssf=128 anonymous auth
by ssf=128 self write
access to *
by ssf=128 self write
by ssf=128 users read
And yes, you have to remove the global SSF setting if the phone cannot
support startTLS on port 389.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On Oct 2, 2013, at 11.47, Michael Ströder <michael(a)stroeder.com> wrote:
> btb wrote:
>> On 2013.10.02 07.29, Axel Grosse wrote:
>>
>>> when I test on the server itself ..
>>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile
>>> ./ssl/VordelCA.crt
>>> CONNECTED(00000003)
>>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>> failure:s23_lib.c:188:
>>
>> ldaps [port 636] is deprecated.
>> use starttls with the standard port [389].
>> to test, just use ldapsearch [see the reference to -Z in the man page]
>
> This is nonsense.
>
> From a security perspective there's no reason not to use LDAPS. Well, I'd even
> recommend LDAPS since SSL/TLS handshake is done *before* a client can send an
> LDAP PDU.
> With my deployments I always enable both but prefer LDAPS.
>
> I cannot imagine that any LDAP server or client will ever drop support for
> LDAPS since this would immediately rule out this implementation from broader
> market share.
i'm not sure what exactly you mean by "this is nonsense". ldaps was never offered as a formal specification, and *is* deprecated. that isn't nonsense. that's a fact: http://www.openldap.org/faq/data/cache/605.html . ldaps may well be in continued use even given its deprecation, but no one is debating that, and it's continued use in light of being deprecated does not change that it's deprecated. we all know it's still heavily used, and probably will continue to be for, at the very least, quite some time.
-ben
link to question on stackoverflow
<http://stackoverflow.com/questions/25457034/starttls-succesful-even-after-d…>
I'm having trouble verifying the correct behavior of my software. Here are
the steps I am performing to verify correct operation:
1. I have sample code that uses openldap library and doing a start tls
to a ldap server.
2. I have set the global option for ca cert directory and tlx context
for the first time.
3. After that I did ldap init and ldap start tls to a server. This is
succesful as expected.
4. I did an ldap_unbind_s
5. I deleted the CA cert that signed the ldap server's certificate from
the ca cert directory of the client.
6. Again did ldap_init and ldap_start_tls_s .
7. I expected this call to fail , as I have removed the ca cert. But
what I observe is that , server sends the certificate but start_tls is
returning success.
I am using openldap 2.4 with libssl.0.9.8
LDAP *ld;int desired_version=3;
if ((ld = ldap_init(<hostname>, <server_port>)) == NULL ) {
printf("ldap_init failed\n");
exit(0);}
ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &desired_version);
ldap_set_option(NULL, LDAP_OPT_X_TLS_CTX, NULL);
ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR,"<ca dir>");
if(ldap_start_tls_s(ld, NULL, NULL) != LDAP_SUCCESS){
printf("start tls failed.\n");
exit(0);}
...... <do bind and search>...
ldap_unbind_s(ld); ...
// DELETE the CA certificate from the ca dir. // Try to do start tls again
if ((ld = ldap_init(hostname, server_port)) == NULL ) {
printf("ldap_init failed , after deleting CA\n");
exit(0);}
// This goes fine even after deleting the CAif (ldap_start_tls_s(ld,
NULL, NULL) != LDAP_SUCCESS){
printf("start tls failed after deleting CA.\n");
exit(0);}
--
Thanks&Regards,
SomaSekhar.
On Monday 01 September 2008 08:08:03 Dat Duong wrote:
> Hi,
>
>
> I can't find anywhere on how to fix my RHEL 5 to use TLS/SSL
> authentication.
Well, it works for me, without any "fixing", just correct configuration.
> I will work when I comment out the ssl startTLS and SSL. On
> my Solaris 10, I can do ldapsearch with the -ZZ option
The -Z option in the native Solaris ldap utilities isn't for start_tls as with
the OpenLDAP utilities. You need to specify *which* ldapsearch you are using.
I don't think the Solaris 10 ldapclient (the equivalent of nss_ldap) supports
start_tls ...
> Here is what I did with the debug on for ldapsearch. Please help me solve
> this problem...THANKS!!
>
> TLS trace: SSL_connect:SSLv3 read server certificate A
> TLS trace: SSL_connect:SSLv3 read server certificate request A
> TLS trace: SSL_connect:SSLv3 read server done A
> TLS trace: SSL_connect:SSLv3 write client certificate A
> TLS trace: SSL_connect:SSLv3 write client key exchange A
> TLS trace: SSL_connect:SSLv3 write change cipher spec A
> TLS trace: SSL_connect:SSLv3 write finished A
> TLS trace: SSL_connect:SSLv3 flush data
> TLS trace: SSL3 alert read:fatal:handshake failure
> TLS trace: SSL_connect:failed in SSLv3 read finished A
> TLS: can't connect.
> ldap_perror
> ldap_start_tls: Connect error (-11)
> additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
> alert handshake failure
But, you didn't provide *any* details on your client configuration.
Specifically, tls_cacertfile from /etc/ldap.conf, and TLS_CACERT from
/etc/openldap/ldap.conf .
Regards,
Buchan
Some more (perhaps relevant?) backgroup info.
These four servers have recently (last week) been struck by corruption of
the underlying .dbd files. In order to get things working again, we did on
all four servers:
- stop slapd
- slapcat > temp.ldif
- remove /var/lib/ldap/* (except DB_CONFIG)
- slapadd -n 2 -l temp.ldif
- chown ldap:ldap /var/lib/ldap/*
- chown root:root /var/lib/ldap/DB_CONFIG
- start slapd
Perhaps this background info is relevant..?
Thanks again for your efforts, they are much appreciated!
On Mon, 12 Jun 2023 at 17:02, cYuSeDfZfb cYuSeDfZfb <cyusedfzfb(a)gmail.com>
wrote:
> Hi!
>
> I am using the cn=admin,o=infra,c=com with correct password to connect. I
> will further check ACLs! Thank you for that suggestion.
>
> Just to make things more concrete, below are two samples. One on the
> MASTER with contextCSN, and one from the SLAVE without contextCSN.
>
> EXAMPLE SLAVE:
> ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b
> "o=infra,c=com" -s base contextCSN
> # extended LDIF
> #
> # LDAPv3
> # base <o=infra,c=com> with scope baseObject
> # filter: (objectclass=*)
> # requesting: contextCSN
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> EXAMPLE MASTER:
> ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b
> "o=infra,c=com" -s base contextCSN
> # extended LDIF
> #
> # LDAPv3
> # base <o=infra,c=com> with scope baseObject
> # filter: (objectclass=*)
> # requesting: contextCSN
> #
>
> # infra, com
> dn: o=infra,c=com
> contextCSN: 20180917142109.765066Z#000000#000#000000
> contextCSN: 20230612144901.796553Z#000000#001#000000
> contextCSN: 20230612144904.899482Z#000000#002#000000
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
> On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount <quanah(a)fast-mail.org>
> wrote:
>
>>
>>
>> --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
>> <cyusedfzfb(a)gmail.com> wrote:
>>
>> > Hi Quanah,
>> >
>> > Thanks for the swift reponse! I think I do, yes, see, from consumer one:
>> >
>> > olcSyncrepl: {0}rid=202
>> > provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple
>> > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
>> > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
>> > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
>> > starttls=critical tls_reqcert=demand
>> > olcSyncrepl: {1}rid=201
>> > provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple
>> > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
>> > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
>> > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
>> > starttls=critical tls_reqcert=demand
>> > olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389
>> > olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389
>>
>> That's syncrepl, not syncprov.
>>
>> However, the issue could be ACLs. If you use the rootdn for your
>> database
>> to run the query, can you see the contextCSN value stored in your
>> database
>> root?
>>
>> --Quanah
>>
>>
>>
>>