Hi,
On Monday, 28. May 2012, Philip Guenther wrote:
> On Mon, 28 May 2012, Michael Ströder wrote:
> > Peter Marschall wrote:
> > > how do the openldap tools technically verfify certificates with
> > > ldapi:// ?
> >
> > Which certs do you want to verify?
>
> I assume the answer is "the one the server returns when you do StartTLS on
> the ldapi:// connection".
Correct.
> If that's not a sufficient option, and verifying certs is required, then
> it appears the code will treat the socket path as the hostname to verify
> for. For OpenSSL, for example, that means it'll compare it against any
> DNS: subjectAltNames as well as against the last CN component of the cert
> subject.
That's not what the openldap tools do.
My cerver certificates do not contain the ldapi socket path as hostnames,
yet
ldapsearch -LLL -x -H ldapi:/// -ZZ -s base -b ""
works and I want to find out how it does this.
Best
PEter
--
Peter Marschall
peter(a)adpm.de
sim123 wrote:
> So I did more research and found that java or spring source has APIs for
> encrypting passwords and I could store the hashed value in openldap. If thats
> the case would LDPA server be able to retrive the password during bind?
>
> And another interesting read is
>
> http://blogs.oracle.com/DirectoryManager/entry/the_ssha_password_storage_sc…
>
> Is that true for OpenLDAP? Can I use similar algorithm for generating
> password? Or should password policy will suffice ?
Should be the same. Compare to:
http://www.openldap.org/faq/data/cache/347.html
Generating the salted hash of the password can be done by the client or within
slapd when the client sends a LDAP Password Modify extended operation request
(RFC 3062) with the clear-text password (as stated in
http://www.openldap.org/faq/data/cache/906.html).
Note that there are various forms of bind requests. Hashed passwords in
attribute 'userPassword' can only be used with bind methods which sends the
plaintext password over the wire (simple bind, SASL/PLAIN) and therefore the
communication has to be protected (by LDAPS or LDAP with StartTLS).
Ciao, Michael.
c0re <nr1c0re(a)gmail.com> writes:
> # making clientkey
> openssl genrsa -out client.key 2048
> # making certificate request
> openssl req -new -key client.key -out client.csr
> # signing
> openssl x509 -req -days 1024 -CA ../ssl/rootcrt.pem -CAkey
> ../ssl/rootkey.pem -in client.csr -out client.crt -CAserial
> ../ssl/root.seq
>
> # configuring on client
> TLS_CACERT /usr/local/etc/openldap/ssl-client/rootcrt.pem
> TLS_CERT /usr/local/etc/openldap/ssl-client/client.crt
> and
> TLS_KEY /usr/local/etc/openldap/ssl-client/client.key
>
> Trying again with slapd debug and client calling "id test"
[...]
As there are no obvious errors in the log you should get TLS properly
working, prior to testing with pam. Just do a ldapsearch or a
ldapwhoami either on uri ldaps:// or startTLS on ldap://
-Dieter
--
Dieter Klünter | Systemberatung
sip: 7770535(a)sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
Hi,
I can't find anywhere on how to fix my RHEL 5 to use TLS/SSL authentication. I will work when I comment out the ssl startTLS and SSL. On my Solaris 10, I can do ldapsearch with the -ZZ option
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
Hi,
I can't find anywhere on how to fix my RHEL 5 to use TLS/SSL authentication. I will work when I comment out the ssl startTLS and SSL. On my Solaris 10, I can do ldapsearch with the -ZZ option
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
--On Tuesday, October 21, 2008 4:05 PM -0400 Kyle Barger <kbarger(a)ltsp.edu>
wrote:
> I have an OpenLDAP 2.3 server that is up and running. I have been trying
> to add SSL and TLS. SSL connections on port 636 work fine. However the
> TLS connection on 389 is not working. The only errors are "TLS accept
> failure" and "TLS negotiation failure." I've not been able to dig up any
> more information, even using the -d option, and I notice that people have
> posted log files with detailed TLS trace messages. How can I enable the
> TLS logging to find out what's going on? Thanks.
You can't do SSL over port 389, you need to do startTLS instead. You don't
say how you are testing these connections, but if you are using ldapsearch,
look at the "-Z[ZZ]" option(s).
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
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
>
>
>
>
Quoting Francesco Malvezzi <francesco.malvezzi(a)unimore.it>:
> good morning,
>
> I would like to be able to replicate the schema info only from cn=config.
>
> I tried to add the olcSyncrepl to cn=schema
>
> dn: cn=schema,cn=config
> changetype: modify
> add: olcSyncrepl
> olcSyncrepl: ....
>
> but doesn't work:
> <olcSyncrepl> only allowed within database declaration
The correct way to enable replication after cn=config already exists
is with ldapmodify:
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
> It does work to add olcSyncrepl to olcDatabase={0}config,cn=config with
> a filter like:
> olcSyncrepl: {0}rid=001 provider=... binddn=... bindmethod=simple
> search base="cn=schema,cn=config" filter="(!(cn=core))"
>
> but then the whole olcDatabase={0}config,cn=config becomes a shadow
> context and I'm unable to ldapmodify anything (olcLoglevel for example).
>
> What am I missing?
You need to set up all rids in your modify operation, each listing
provider with their own URI. Optionally, you could even have different
credentials pointing in different directions - nothing prevents this.
For n-way replication, you need to perform the same modification to n
sides. Otherwise your replicas will be read-only as you have seen.
This is the same for any database, not just n0. Go back and enable CRL
checking after you are sure that it works, if using TLS.
Example, change the macros to suit your setup and apply this same ldif
to each of your replicas:
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncrepl: rid=001
provider=%%LDAP_URI_1%%
bindmethod=simple
timeout=0
network-timeout=0
binddn="%%CONFIG_ROOT_DN%%"
credentials="%%CONFIG_ROOT_PW%%"
keepalive=0:0:0
starttls=critical
tls_cert="%%LDAP_SERVER%%/ssl/cert.pem"
tls_key="%%LDAP_SERVER%%/ssl/key.pem"
tls_cacert="%%CA_CHAIN_SERVERS%%"
tls_reqcert=demand
tls_crlcheck=none
filter="(objectclass=*)"
searchbase="cn=config"
scope=sub
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="60 +"
olcSyncrepl: rid=002
provider=%%LDAP_URI_2%%
bindmethod=simple
timeout=0
network-timeout=0
binddn="%%CONFIG_ROOT_DN%%"
credentials="%%CONFIG_ROOT_PW%%"
keepalive=0:0:0
starttls=critical
tls_cert="%%LDAP_SERVER%%/ssl/cert.pem"
tls_key="%%LDAP_SERVER%%/ssl/key.pem"
tls_cacert="%%CA_CHAIN_SERVERS%%"
tls_reqcert=demand
tls_crlcheck=none
filter="(objectclass=*)"
searchbase="cn=config"
scope=sub
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="60 +"
-
add: olcMirrorMode
olcMirrorMode: TRUE
-mike
2013/5/17 Howard Chu <hyc(a)symas.com>
> Igor Zinovik wrote:
>
>> Hello.
>>
>> I'm trying to replicate access rules and limits for one of my databases,
>> but
>> with no success:
>> suse:~ # cat olcAccess-syncrepl.ldif
>> dn: olcDatabase={1}mdb,cn=config
>> changetype: modify
>> add: olcSyncrepl
>> olcSyncrepl: {1}rid=002
>> provider=ldap://ldap1.local
>> bindmethod=simple
>> binddn="cn=admin,cn=config"
>> credentials="TopSecret"
>> searchbase="olcDatabase={1}**mdb,cn=config"
>> attrs="olcAccess,olcLimits"
>> timeout=3
>> network-timeout=0
>> starttls=yes
>> tls_cert="/etc/openldap/ldap.**pem"
>> tls_key="/etc/openldap/ldap.**key"
>> tls_cacert="/etc/ssl/local-ca.**pem"
>> tls_reqcert=demand
>> tls_crlcheck=none
>>
>>
>> suse:~ # ldapmodify -H ldap://ldap2.local -ZZxWD cn=admin,cn=config -f
>> olcAccess-syncrepl.ldif
>> Enter LDAP Password:
>> modifying entry "olcDatabase={1}mdb,cn=config"
>> ldap_modify: Other (e.g., implementation specific) error (80)
>> additional info: Base DN "olcAccess,olcLimits" is not within the
>> database naming context
>>
>
> > slapd-2.4.33 if it matters.
>
> The error message is a bit garbled (obviously the Base DN is wrong) but
> the error is basically correct. You're trying to replicate the wrong thing
> from the wrong place. Setting a syncrepl consumer on the olcDatabase={1}mdb
> database lets you replicate the *content* of that database. To replicate
> the *configuration* of that database your consumer must be set where that
> configuration is stored.
>
> The configuration is stored in olcDatabase={0}config.
>
Thanks Howard, but I still cannot get things working.
Could you exaplain me following (i read documentation but it is not clear
enough for me to understand):
Does parameter `searchbase' in olcSyncrepl configuration statement set
search starting point or it sets
just a database name (which is set in olcSuffix) where search is performed?
Here is my configuration provider setup:
ldap1:~ # ldapsearch -H ldap://ldap1.local -LLLZZxWD cn=admin,cn=config -b
olcOverlay={0}syncprov,olcDatabase={0}config,cn=config '&'
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
Here is my configuration consumer:
ldap2:~ # ldapsearch -H ldap://ldap2.local -LLLZZxWD cn=admin,cn=config -b
olcDatabase={0}config,cn=config '&' olcSyncrepl
Enter LDAP Password:
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=001 provider=ldap://ldap1.local bindmethod=simple bind
dn="cn=admin,cn=config" credentials="TopSecret" searchbase="cn=con
fig" scope=sub filter="(olcDatabase={1}mdb)" attrs="olcAccess,olcLimits"
retr
y="60 +" timeout=3 network-timeout=0 starttls=yes
tls_cert="/etc/openldap/lda
p.pem" tls_key="/etc/openldap/ldap.key" tls_cacert="/etc/ssl/local-ca.pem"
t
ls_reqcert=demand tls_crlcheck=none
A bit offtopic: could you guys implement some kind of human friendly
formatting for long line statements and ACLs? So
previous statement would look like this when i fetch it from catalog:
olcSyncrepl: {0}rid=001
provider=ldap://ldap1.local
bindmethod=simple
binddn="cn=admin,cn=config"
credentials="TopSecret"
searchbase="cn=config"
scope=sub
filter="(olcDatabase={1}mdb)"
attrs="olcAccess,olcLimits"
retry="60 +"
timeout=3
network-timeout=0
starttls=yes
tls_cert="/etc/openldap/ldap.pem"
tls_key="/etc/openldap/ldap.key"
tls_cacert="/etc/ssl/local-ca.pem" t
ls_reqcert=demand
tls_crlcheck=none
