Hi Philip,
Thank you for your elaborate feedback. Comments inline.
On 02/19/2013 03:42 AM, Philip Guenther wrote:
[snip]
> "We need to protect corporate data in LDAP from being modified or even
> accessed by untrusted resources.
Yes.
[snip]
> "Because some of the applications cannot be configured to bind
> non-anonymously but they all (except for that one) _can_ be configured
> to always use StartTLS and provide a client certificate, we want to
> require that all ldap:// connections use the StartTLS operation with a
> client cert before performing any LDAP operations that access or modify
> data.
Yes. Client certificate authentication is used everywhere where possible
(for things like corporate web access, email, VPN).
> (That's a complete guess and probably not your real reason. Client certs
> are just another form of secret which are, IMO, a bigger pain to generate
> and manage.)
Thankfully the security overlords who came up with this one are also the
ones who have to generate and manage the certs :-)
[snip]
> Well, for starters, the peername.ip="127.0.0.1" clause does *NOT* match
> ldapi:// connections. It matches ldap://127.0.0.1/ and ldaps://127.0.0.1/
> connections.
I did not try to use ldapi with this setup. I used ldap on 127.0.0.1.
Sorry if that was not clear.
[snip]
> In what way is an ldapi:// connection insecure? It's a UNIX domain socket
> for which the data never goes over a physical net and that therefore
> cannot be snooped. That's *MORE* secure than a TCP connection secured
> with TLS! You can even authenticate it via the uid and gid of the process
> that opened the connection!
Agreed. The authentication via uid/gid is a nice one I did not know was
possible. Will look into that.
> Anyway, if you want to permit only
> a) read-only ldapi:// connections and
> b) ldap:// connections using TLS w/client certs
>
> then *I think* you can do that with three options in the config:
>
> # require clients that clients that do TLS provide a client cert
> olcTLSVerifyClient: demand
> # treat ldapi:// connections as at least as secure as a 256bit cipher
> olcLocalSSF: 256
> # require connections to be at least as secure as a 256bit cipher to do
> # anything at all (the "ssf=256") clause, and specifically require that
> # they be using TLS (and not just ldapi) with 256bit cipher to do updates
> olcSecurity: ssf=256 update_tls=256
Your example had me stumped. Upon reading the olcLocalSSF section again
I realized I made a mistake. Although it says "Specifies the Security
Strength Factor (SSF) to be *given* local LDAP sessions" my mind munched
it into "Specifies the Security Strength Factor (SSF) to *require* for
local LDAP sessions". Obviously setting it to 0 did not help... Staring
at the screen too long I guess. So thanks for making me read the man
page again :-)
> But I haven't tested it.
Works like a charm.
[snip]
> Yes, an unconditional "require blah" should be taken to be unconditional.
Duly noted.
Thank you very much for all your help and enlightening comments. Much
appreciated.
Regards,
Patrick
--On Friday, September 18, 2020 2:42 PM -0700 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> Nothing you've provided shows any attempt to connect to the ldap server
> using an SIMPLE BIND with the user DN
> "uid=foxdiv,ou=People,dc=att,dc=com" and a password.
As an example, the correct way to test the user password change went
through would be something like:
ldapwhoami -x -H ldap://ldap.example.com:389/ -D
uid=foxdiv,ou=People,dc=att,dc=com -W
If slapd is running on ldaps, adjust the URI accordingly. If it's on port
389 but requires startTLS, add the -ZZ option, etc.
You will be prompted for the password for the LDAP user. If the operation
succeeds, then the password was correctly updated in LDAP.
It sounds as though you may be attempting *nix <-> ldap integration, but
that hasn't been specified. Regardless, the above ldapwhoami command is
the next step in confirming whether or not the password was correctly
changed and accepted on the user side. If that works, and you're
attempting the *nix<->ldap integration and *that* is not working, it would
imply that the integration is not configured correctly.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
>>> Quanah Gibson-Mount <quanah(a)fast-mail.org> schrieb am 31.03.2022 um 17:45
in
Nachricht <EAAAB9ABE315CDA6FADC9E00(a)[192.168.1.12]>:
>
> ‑‑On Thursday, March 31, 2022 9:11 AM +0200 Ulrich Windl
> <Ulrich.Windl(a)rz.xn--uniregensburg-dm6g.de> wrote:
>
>> I think the point was that you can bind even when not having started TLS
>> before.
>
> Correct.
>
>> I don't know whether this can prevent it:
>> olcSecurity: ssf=0 update_ssf=128 simple_bind=64
>
> There is no way to prevent a client from sending a BIND request to an
> ldap:/// URI with the DN and password in the clear. Even if you set ssf=1
> (server mandates encryption), the most that will happen is that the client
> will get disconnected, but the DN and password will already have traveled
> over the network in the clear before the client gets disconnected so anyone
> sniffing the traffic would have access to it.
But honestly, you could get the same when setting up SSL incorrectly (using
eNULL or RSA-PSK-NULL-SHA).
Also I think if you require an anonymous bind first, the SSF may prevent
sending actual user passwords unencrypted; right?
Regards,
Ulrich
>
> ‑‑Quanah
Hi All -
I'm having an issue with mirrormode replication (via delta syncrepl) and
the memberof overlay. When a group membership is changed on the first
node, slapd on the second node is crashing with the following error (as
seen from running slapd with -d-1):
slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed.
If I disable either memberof or mirrormode, the change replicates
correctly. This behavior happens on both bdb and mdb backends. Any
thoughts on what that might mean?
I am still in development, so I can try pretty much anything at this point
- I appreciate any guidance that you can offer.
Here are the important details:
OpenLDAP 2.4.33
Redhat Linux 6.3 - x64
Server1 and Server2 are using the same configuration, minus the serverid
and the syncrepl provider. here is server1's pertinent config:
olcServerID: 1
...
olcSyncrepl: rid=000 provider=ldap://server1.xxx.xxx.com:389/ bindme
thod=simple timeout=0 network-timeout=0 binddn="cn=ldapreplicator,xxx,
xxx,xxx.com" credentials="secret" keepalive=0:0:0 starttls=critical
filter="(objectclass=*)" searchbase="xxx.com" logfilter=
"(&(objectClass=auditWriteObject)(reqResult=0))" logbase="cn=accesslog"
scope
=sub schemachecking=on type=refreshAndPersist retry="60 +"
syncdata=accesslog
olcMirrorMode: TRUE
...
olcMemberOfRefInt: FALSE
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: uniquemember
Regards,
Al
Hi,
I am a little confused with this. Basically I have a client connecting
to the database, a DECT IP phone base station which doesn't support
STARTLS and my slapd config has settings for clients to use certificates
to connect.
What would be the best way to set this up so that the DECT IP client
only accesses the particular place that it needs to, the AddressBook
section but then other clients will need to use STARTTLS for everything
else??
Currently I am looking at:
https://www.openldap.org/doc/admin24/security.htmlhttps://www.openldap.org/doc/admin24/access-control.html
and have currently put this in my slapd.conf:
#Removed the Global? security clause
#security ssf=128
#Added generic ACL for all access to require ssf of 128
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
Is this correct or do I need to engage the "security" Global section too?
Though the documentation suggests otherwise: "For fine-grained control,
SSFs may be used in access controls. See theAccess Control
<https://www.openldap.org/doc/admin24/access-control.html>section for
more information."
Thanks.
Kaya
Hi ben,
thanks for the comment.
agree with you on TLS usage should be perferred
but the client that is connecting is only capable of LDAPS ... he has not implemented TLS Client jet .
But can you please take a look to the error I am facing
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:
any idea what can cause this ?
AXEL GROSSE
Principal Solution Architect, Sales Solution Center, Axway
P: +61-405-995-768
828 Pacific Highway
Gordon, 2072 NSW
agrosse(a)axway.com
http://www.axway.com
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb
Sent: Wednesday, 2 October 2013 10:57 PM
To: openldap-technical(a)openldap.org
Subject: Re: Openldap server with TLS not working
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]
-ben
Checking my production servers, which is only using Delta-syncrepl
Those servers are using SSL3 over port 636, and the olcSyncrepl has "starttls=no" and using the "tls_certdir"
Thanks in advance
John
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Friday, January 31, 2014 1:26 PM
To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
Subject: RE: Syncrepl and mmr
--On Friday, January 31, 2014 1:20 PM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> Thanks, Quanah
>
> Not sure what you meant by " Well, it may not have been this issue,
> but it definite would become an issue then."
>
> Was what I did a good thing or not? Curious minds want to know. <lol>
The lack of read permissions for the replication user would absolutely be an issue at some point. ;)
> MM Server1:
># ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D #
>cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config
>olcSyncrepl
What CA cert is your ldapsearch command using?
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
On Wednesday 20 February 2008 17:10:00 Bryan Payne wrote:
> Thank you for your help. I added the pwdPolicySubentry to a user to no
> avail. I did find this in the logfile though:
>
> Feb 20 09:01:13 ldapserver slapd[6709]: conn=95289 op=4 SEARCH RESULT
> tag=101 err=50 nentries=0 text=Operations are restricted to
> bind/unbind/abandon/StartTLS/modify password
>
> So it looks like it's trying to do something but cannot. While I'm
> concerned about password strength, I'm more concerned (at this point)
> with just having the machine prompt for a password change.
Well, what do you mean by "the machine" ? It looks like the password has
expired, but if you're expecting a prompt for a password change, that's a
client side issue. So, what is the client in this case? Recent versions of
pam_ldap support ppolicy (IIRC including the one shipped with RHEL4), but you
didn't say which client this is.
Also, you said accounts get locked, but users can still log in? This sounds
like you might not actually be using pam_ldap for authentication, but the
pam_unix->nss_ldap (NIS replacement and nothing more) method, which won't see
anything relating to ppolicy.
Regards,
Buchan
It was modified from the generation of slapd-chain2.conf which also didn't
work (I was working off the assumption that the overlay needed to be on
olcDatabase={1}frontend)
This is the slapd-chain2.conf file I am using (modified slightly)
The only differences between this and the unmodified slapd-chain2.conf is
the directory and the addition of chain-tls and chain-idassert-authzFrom
to the "overlay chain" section.
I'm generating my config with it with
$ slaptest -f slapd-chain2.conf -F ./slapd.d-test/
"""
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/nis.schema
database hdb
directory /srv/ldap/example.com/
suffix "dc=example,dc=com"
rootdn "cn=admin,dc=example,dc=com"
rootpw secret
overlay chain
chain-uri ldap://master.example.com
chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com"
credentials=secret mode=self
chain-tls start
chain-idassert-authzFrom "*"
"""
The resulting cn=config doesn't generate objects on the
olcDatabase={1}frontend database but rather the two following objects are
generated within olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
"""
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 f3da9a85
dn: olcDatabase={0}ldap
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: none starttls=no
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
structuralObjectClass: olcLDAPConfig
entryUUID: df7b759c-bb09-1032-82c9-adb6d4ef9266
creatorsName: cn=config
createTimestamp: 20130926151258Z
entryCSN: 20130926151258.900907Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130926151258Z
"""
olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
"""
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 b7a21479
dn: olcDatabase={1}ldap
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://master.example.com"
olcDbStartTLS: start starttls=no
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical
bindm
ethod=simple timeout=0 network-timeout=0 binddn="dc=example,dc=com"
credentials
="secret" keepalive
=0:0:0
olcDbIDAssertAuthzFrom: *
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
structuralObjectClass: olcLDAPConfig
entryUUID: df7b7c90-bb09-1032-82ca-adb6d4ef9266
creatorsName: cn=config
createTimestamp: 20130926151258Z
entryCSN: 20130926151258.900907Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130926151258Z
"""
The changes to relocate these objects to the olcDatabase{-1}fontend was in
response to the things I had read online.
-Russell J. Jancewicz
University of Connecticut
On 2013-09-26 13:02, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote:
>--On Thursday, September 26, 2013 4:02 PM +0000 "Jancewicz, Russell"
><russell.jancewicz(a)uconn.edu> wrote:
>
>
>> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
>> objectClass: olcOverlayConfig
>> objectClass: olcChainConfig
>> olcOverlay: {0}chain
>> olcChainCacheURI: FALSE
>> olcChainMaxReferralDepth: 1
>> olcChainReturnError: FALSE
>>
>>
>> dn:
>> olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
>> objectClass: olcLDAPConfig
>> objectClass: olcChainDatabase
>> olcDatabase: ldap
>> olcDbURI: "ldap://master.example.com"
>> olcDbStartTLS: start starttls=no
>> olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical
>> bindmethod=simple timeout=0 network-timeout=0
>> binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>"
>> keepalive=0:0:0
>> olcDbIDAssertAuthzFrom: *
>> olcDbRebindAsUser: FALSE
>> olcDbChaseReferrals: TRUE
>> olcDbTFSupport: no
>> olcDbProxyWhoAmI: FALSE
>> olcDbProtocolVersion: 3
>> olcDbSingleConn: FALSE
>> olcDbCancel: abandon
>> olcDbUseTemporaryConn: FALSE
>> olcDbConnectionPoolMax: 16
>> olcDbSessionTrackingRequest: FALSE
>> olcDbNoRefs: FALSE
>> olcDbNoUndefFilter: FALSE
>> olcDbOnErr: continue
>> olcDbKeepalive: 0:0:0
>
>This is not a valid conversion of slapd-chain2.conf from the test suite.
>How did you arrive at this config?
>
>--Quanah
>
>--
>
>Quanah Gibson-Mount
>Lead Engineer
>Zimbra Software, LLC
>--------------------
>Zimbra :: the leader in open source messaging and collaboration
