Search results for "starttls" - openldap-technical

Re: Reg OpenLdap on Ubuntu

by Asimananda Mohanty

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 >

15 years, 8 months

Re: Problem with persistent search in OpenLDAP 2.4.23

by Dieter Kluenter

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

14 years, 9 months

slapd-meta and tls_reqcert=allow

by Jim Vanes

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.

12 years, 4 months

Re: ssf Security Question

by Quanah Gibson-Mount

--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>

7 years, 7 months

Re: Openldap server with TLS not working

by btb＠bitrate.net

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

11 years, 8 months

Re: AW: syncrepl connection / reconnect

by Dieter Kluenter

"Dieter Kluenter" <dieter(a)dkluenter.de> writes: > Thorsten Mueller <Thorsten.Mueller(a)aachen.utimaco.de> writes: > >> Here you are, the config of the second machine is identical, apart from the >> different provider > > [...] >> syncprov-checkpoint 100 10 >> >> syncprov-sessionlog 100 >> >> # syncrepl directiv >> >> syncrepl rid=001 >> >> provider=ldap://192.168.120.237:388 >> >> bindmethod=simple >> >> binddn="cn=Replicator,dc=DatabaseReplication,dc=head" >> >> credentials="fdet2zS3" >> >> searchbase="dc=head" >> >> starttls=critical >> >> tls_cacert=/etc/TLS/ca-certs/trusted_CAs.pem >> >> tls_cert=etc/TLS/client/client.pem >> >> tls_key=etc/TLS/client/client_key.pem >> >> schemachecking=on >> >> type=refreshAndPersist >> >> retry="5 12 60 +" >> >> mirrormode on > > [...] > > order matters, syncrepl has to be declared within a database > specification, modules are loaded last, after all database specific > configuration parameters. Sorry my bad, this should read ..overlays are loaded last... -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

15 years, 2 months

Bug ? ldap_start_tls_s successful even after removing ca certificate from ca cert dir

by SOMA SEKHAR

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.

10 years, 9 months

Re: RHEL 5 will not do TLS/SSL authentication

by Buchan Milne

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

16 years, 9 months

Re: no contextCSN attribute on consumers

by cYuSeDfZfb cYuSeDfZfb

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 >> >> >> >>

2 years

RE: problem with ldap backend

by masarati＠aero.polimi.it

> Hi > > Just wondering if the features is supposed to work ? Am I delving into > experimental code ? It works as intended. The error message you receive is quite self-explanatory: AD wants a successful bind, and you're requesting bindmethod=none (i.e. bind with empty DN). You may want to try bindmethod=simple p. >> -----Original Message----- >> From: Alex Samad - Yieldbroker >> Sent: Thursday, 29 March 2012 9:28 AM >> To: openldap-technical(a)openldap.org >> Subject: RE: problem with ldap backend >> >> Hi >> >> I have progressed a little bit further >> >> I have stopped using olcdbaclbind and started to use >> >> olcDbIDAssertAuthzFrom: "*" >> olcDbIDAssertBind: bindmethod=none authzId="CN=ad >> readonly,OU=Services ,DC= xyz,DC=com" credentials="secret" starttls=no >> >> >> but I get this >> >> text: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform >> this >> ope ration a successful bind must be completed on the connection., data >> 0, >> v1db1 >> >> >> I am able to ldapsearch with these credentials, I also tried change >> bindmethod to simple, but same error >> >> How do I turn on debug for the ldap backend ? >> >> Any one have any ideas on how to make this work ? >> >> >> Alex >> >> >> > -----Original Message----- >> > From: openldap-technical-bounces(a)OpenLDAP.org >> > [mailto:openldap-technical- bounces(a)OpenLDAP.org] On Behalf Of Alex >> > Samad - Yieldbroker >> > Sent: Wednesday, 28 March 2012 1:58 PM >> > To: openldap-technical(a)openldap.org >> > Subject: problem with ldap backend >> > >> > Hi >> > >> > I am trying to setup a connection from openldap to MS AD >> > >> > I am using this >> > >> > dn: olcDatabase={3}ldap >> > objectClass: olcDatabaseConfig >> > objectClass: olcLDAPConfig >> > olcDatabase: {3}ldap >> > olcSuffix: dc=xyz,dc=com >> > olcAccess: {0}to dn.base="" by * read >> > olcAccess: {1}to dn.base="cn=Subschema" by * read >> > olcAccess: {2}to * by self write by users read by anonymous auth >> > olcReadOnly: TRUE >> > olcRootDN: >> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> > olcSizeLimit: 500 >> > olcDbURI: "ldap://dc101. xyz.com ldap://dc201. xyz.com" >> > olcDbRebindAsUser: TRUE >> > olcDbChaseReferrals: TRUE >> > >> > >> > This works fine when I pass a bind DN. >> > >> > I would like to convert this to allow anon access to ldap, which does >> > a user bind to MS AD so I added this >> > >> > >> > olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU= xyz,DC= >> > xyz,DC=com" credentials="secret" starttls=no >> > >> > but it is not working, I can not make a anon search request, they >> > retrieve any thing frome the MSAD ldap server. >> > >> > Thanks >> > >> > >> > >> > > > > >

13 years, 2 months

openldap-technical search results for query "starttls"