--On Wednesday, October 9, 2019 3:23 PM +0000 Howard.Gillison(a)gvltec.edu
wrote:
>
>
> Good morning to you,
I suggest you read the OpenLDAP client code and the libldap code which
fully utilizes the API to make connections with or without TLS. I think
the *function* you're looking for is ldap_start_tls_s (at least for
startTLS over port 389):
<https://www.openldap.org/software/man.cgi?query=ldap_start_tls_s&apropos=0&…>
>From the library, I would suggest perusing libldap/init.c, libldap/open.c,
libldap/options.c, and libldap/unbind.c
Since this is open source software it is of course trivial to access the
code and have working examples before you.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On 24/06/10 11:57 +0200, Emmanuel Dreyfus wrote:
>Dieter Kluenter <dieter(a)dkluenter.de> wrote:
>
>> No, ldapi:/// doesn't present a certificate, but you may establish a
>> startTLS session to ldapi:///, in this case the client requests a
>> server certificate.
>
>Let me rephrase: I would like to specify two LDAP servers in ldaprc
>- one ldapi:/// with anonymous bind
>- one ldaps:// with SASL EXTERNAL for and required server certificate
>
>It seems to me it is not possible.
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred,
i.e.:
authz-regexp
".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth"
ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
--
Dan White
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
>
>
>
>
At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller
> <heller(a)deepsoft.com> wrote:
>
>
> > Slapd is reporting TLS Negotiation failure when SSSD tries to connect to
> > it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess
> > something is wrong with slapd's TLS configuration -- it is failing to do
> > TLS Negotiation, either it is just not doing it or it is doing it wrong
> > (somehow). Unless SSSD is not configured properly.
>
> You need to start with the following:
>
> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
>
> to test startTLS
>
> and
>
> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w
>
> to test without startTLS
>
> If you can get those to work, then you can move on to SSSD.
[heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D cn=Manager,dc=deepsoft,dc=com -W
ldap_start_tls: Connect error (-11)
additional info: TLS error -8157:Certificate extension not found.
[heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D cn=Manager,dc=deepsoft,dc=com -W
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
The certificate is from my own CA and I *think* I have things set up properly,
but it is a openssl cert and I know that slapd (and sssd) are built with
MozNSS.
ldap.conf contains:
TLS_CACERT /etc/openldap/certs/ca-cert.pem
TLS_CACERTDIR /etc/openldap/certs
TLS_REQCERT demand
and /etc/openldap/slapd.d/ contains:
olcTLSCACertificatePath: /etc/openldap/certs
olcTLSCACertificateFile: /etc/openldap/certs/ca-cert.pem
olcTLSCertificateFile: /etc/pki/tls/certs/c764guest.cert
olcTLSCertificateKeyFile: /etc/pki/tls/certs/c764guestkey.pem
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller(a)deepsoft.com -- Webhosting Services
--On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller
<heller(a)deepsoft.com> wrote:
> At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com>
> wrote:
>
>>
>> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller
>> <heller(a)deepsoft.com> wrote:
>>
>>
>> > Slapd is reporting TLS Negotiation failure when SSSD tries to connect
>> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess
>> > something is wrong with slapd's TLS configuration -- it is failing to
>> > do TLS Negotiation, either it is just not doing it or it is doing it
>> > wrong (somehow). Unless SSSD is not configured properly.
>>
>> You need to start with the following:
>>
>> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
>>
>> to test startTLS
>>
>> and
>>
>> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w
>>
>> to test without startTLS
>>
>> If you can get those to work, then you can move on to SSSD.
>
> [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D
> cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11)
> additional info: TLS error -8157:Certificate extension not found.
This may be of help:
<https://serverfault.com/questions/640910/my-certificate-doesnt-work-on-all-…>
> [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D
> cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
This may mean slapd isn't listening on port 636 (With no -d -1 info, hard
to know for sure). It may also simply be a different manifistation of the
error above.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
hi all,
on a consumer I spotted a zombie entry which was deleted on provider.
Replication is syncrepl:
olcSyncrepl: {0}rid=003 provider=ldap://ldap-master.example.org
binddn="cn=repluser,ou=agents,dc=example,dc=org" bindmethod=simple
credentials="secret" searchbase="ou=people,dc=example,dc=org"
type=refreshOnly interval=00:00:01:00 retry="5 5 30 +" timeout=1
scope=sub schemachecking=on exattrs=sambaHomeDrive sizelimit=100000
timelimit=7200 starttls=yes filter="....."
my naive strategy was to (re-)start slapd with the -c rid=003 switch but
of course I am missing something because I can see from logs
syncronization if actually forced but zombie entry is not deleted.
I am really sorry to ask you what I misundestood,
thank you,
Francesco
--On Friday, January 04, 2013 4:09 PM -0800 Bheeshma SM
<bheeshma.manjunath(a)gmail.com> wrote:
>
> Hi guys.
>
> I have a problem in Openldap 2.4.33 on RHEL 5.8
>
> I am able to do a " ldapsearch -x -p 389 -h -D<> -w<> -b<> "
>
> but i am not able to do
>
> " ldapsearch -x -p 636 -h -D<> -w<> -b<>
Sounds like slapd is not configured to listen to port 636. No amount of
mucking with ldapsearch is going to change that.
I would note that you can do secure searches over port 389 just fine.
Simply use the startTLS operation.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
--On Thursday, September 06, 2018 1:40 PM -0400 Jean-Francois Malouin
<Jean-Francois.Malouin(a)bic.mni.mcgill.ca> wrote:
> I guess I need to modify either 'olcSecurity: tls=1' in the database
> config or add/insert the proper value for 'olcLocalSSF=' in the
> cn=config. What value should I use in order to still force StartTLS over
> simple binding and allow read/write/modify local access on the ldapi:///
> listener.
Hello,
Just set:
olcSecurity: ssf=1
that will allow either to work as *some* SSF level is then required.
As long as you have tls=X, then it will always require TLS, regardless of
what the LocalSSF setting is configured to be.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On 07/09/14 10:28 PM, Vijay Ganesan wrote:
> But I can't seem to connect using ldaps://localhost:636 using Apache
> Directory Studio client. I get a "Error while opening connection -
> Cannot connect on the server: Connection refused" error.
> I can connect fine using ldap://localhost:389.
Like Udai wrote, ldaps is deprecated, and if possible you should use
STARTTLS on the LDAP port (389) instead. But if you really need ldaps,
then edit /etc/default/slapd, add ldaps:/// to the SLAPD_SERVICES line,
and restart slapd.
> What diagnostics can be run to figure out if TLS is working correctly?
LDAPTLS_CACERT=/path/to/ca.pem ldapwhoami -H ldap://server -x -ZZ
Add '-d1' to see some debugging information, including more detailed
info from the TLS library.