Thats my actual config and the message on the logs is : Unauhtenticated
================================================
uri "ldaps://ldap.google.com/dc=proxy"
suffixmassage "dc=proxy" "dc=example,dc=com"
lastmod off
readonly on
idassert-bind bindmethod=sasl
saslmech=EXTERNAL
tls_reqcert=demand
tls_reqsan=demand
tls_cert=/root/ldapcerts/google_cert.crt
tls_key=/root/ldapcerts/google_cert.key
tls_cacert=/root/ldapcerts/ca/gtsr1.pem
================================================
I've actually been trying all kinds of configurations for the last 2 weeks. Is
there a chance that this doesn't work with Google's LDAP? I can't find a
single example on the entire internet of someone who has managed to do this
whit the LDAP of google.
El mar, 5 nov 2024 a las 12:51, Quanah Gibson-Mount (<quanah(a)fast-mail.org>)
escribió:
>
>
> --On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp(a)gmail.com>
> wrote:
>
> > Once again, I apologize; I ran so many tests that I accidentally copied
> > one where the binddn was incorrect.
> >
> > The target looks more like this:
> >
> >## example.com
> > uri "ldaps://ldap.google.com/dc=proxy"
> > suffixmassage "dc=proxy" "dc=example,dc=com"
> > lastmod off
> > readonly on
> > idassert-bind bindmethod=simple
> > binddn="cn=ChiwewDaw"
>
> cn, is by definition, case insensitive. If Google LDAP is forcing case
> sensitivity in this attribute, it is gross violation of the LDAP RFCs.
> However, having had to interface with it in the past, I don't believe that
> is the case. I would generally suspect that this is not the full DN of
> the
> user.
>
> > idassert-bind bindmethod=sasl
> > saslmech=EXTERNAL
> > tls_reqcert=demand
> > tls_reqsan=demand
> > starttls=critical
>
>
> This is not sufficient, please read the man page:
>
>
> idassert-bind bindmethod=none|simple|sasl [binddn=<simple
> DN>]
> [credentials=<simple password>] [saslmech=<SASL
> mech>]
> [secprops=<properties>] [realm=<realm>]
> [authcId=<authentication
> ID>] [authzId=<authorization ID>]
> [authz={native|proxyauthz}]
> [mode=<mode>] [flags=<flags>]
> [starttls=no|yes|critical]
> [tls_cert=<file>] [tls_key=<file>]
> [tls_cacert=<file>]
> [tls_cacertdir=<path>]
> [tls_reqcert=never|allow|try|demand]
> [tls_reqsan=never|allow|try|demand]
> [tls_cipher_suite=<ciphers>]
> [tls_ecname=<names>]
> [tls_protocol_min=<version>]
> [tls_crlcheck=none|peer|all]
>
>
> You *must* specify tls_cert, tls_key, and tls_cacert as a part of
> idassert-bind as it provides the TLS identity to bind as. In your
> configuration for simple bind, tls_cert and tls_key are unnecessary as
> you're not doing SASL/EXTERNAL binds.
>
> --Quanah
>
>
>
>
On 4/8/21 5:24 PM, Michael Ströder wrote:
> On 4/8/21 4:07 PM, work(a)seyboldt.org wrote:
>> i need to open my LDAP-Directory to a public available Server.
>>
>> What is the best secure way to connect my LDAP-Server to my Public
>> server?
>
> This is a pretty broad question.
>
> Good answers usually need more info:
> - which kind of data is stored inside the LDAP server?
> - how do LDAP clients access the server?
> - which OS is the LDAP server running on?
> - against which attacks do you want to protect your deployment?
Some more:
- how is the data maintained?
- do you only need data integrity or also data confidentiality?
> Some general security measures include:
> - use TLS-protected connections everywhere (StartTLS or LDAPS)
> - use decently secure authentication mechs
> - implement secure OpenLDAP ACLs to protect the database content
> - build stripped-down, specific OpenLDAP packages for your needs
> - use systemd's sand-boxing options (if using systemd on Linux at all)
> - use kernel-level MAC like SELinux or AppArmor (if OS is Linux)
Some more:
- have decent monitoring
- implement decent metrics and log analysis (SIEM)
- maybe implement push-replication (depending on network architecture)
Ciao, Michael.
Quanah and all, hello.
On 30 Mar 2022, at 18:54, Quanah Gibson-Mount wrote:
> --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania <stefan(a)kania-online.de> wrote:
>
>> That's what can be found in the FAQ on openldap.org:
>>
>> https://www.openldap.org/faq/data/cache/605.html
>>
>> I would trust this more then any rumors on any stackxxxx page ;)
>
> Unfortunately, the FAQ is dead weight we want to kill and not maintained in any way, shape, or form. It's currently provided for historical purposes.
Since the copyright dates at the bottom of that page are '1998-2013', so that the content of the site is now nearly a decade out of date, I feel the FAQ-o-matic now has negative utility, and that you should give in to the urge to kill it.
I respect and applaud the desire to preserve the content for historical reasons, but surely that goal can be served by making a tarball of the content available at whatever page https://www.openldap.org/faq/.../* were to redirect to (ie, the pages shouldn't be 404-ed, but neither should they be 200; 301 is good).
I have previously (indeed recently) looked at that page and, without thinking much about the question, taken its deprecation of LDAPS as current doctrine.
And.... ah, FAQ-o-matic I have fond memories of FAQ-o-matics, back when wikis were new...
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
Ok. Maybe you are right. Sometimes "Less is more".
I am moving forward to high availability and i am planning to set two ldap
servers in Mirror mode.
I have already setup a haproxy in front but i have two problems.
1. Not able to enable StartTLS (currently only SSL is functional)
2. It seems quite slower. Is this normal?
Στις Πέμ, 22 Σεπ 2016 στις 12:20 μ.μ., ο/η Dirk Kastens <
dirk.kastens(a)uni-osnabrueck.de> έγραψε:
> Hi,
>
> > Do you know a good policy for increamental backup? I mean i only have
> > now 10000 users but in the future it will really get bigger and i hate
> > to dump the whole database
> > every night.
>
> Why not? I'm dumping our directory with 70.000 entries using slapcat
> every night in less than a minute.
>
> Dirk
>
> --
Δρ. Νικόλας Στυλιανίδης
Ηλεκτρολόγος Μηχανικός και Μηχ. Υπολογιστών
Nikolas Stylianides, Dr.
Dr. Eng. in Electrical & Computer Engineering
Contacts
-------------
Mobile Tel.: +35796741315
Email: nstylianides(a)leafnet.com.cy, nstylianides(a)gmail.com
Skype: nicostyl
Affilication
---------------
LEAF NET LTD: Research & Development
Open University of Cyprus: Research Associate, APPLIED HEALTH INFORMATICS
Master Programme Academic Board Member
Tο λακωνίζειν εστί φιλοσοφείν / Μηδέν Άγαν - Χίλων ο Λακεδαιμόνιος:
Brevity is the soul of wit - Shakespeare William (Hamlet)
I have slapd listening on port 636 only because I want to enforce use of
SSL/TLS
It all works successfully (I now have my UNIX users, mail, and about a
dozen apps authenticating against it), however...
I wanted fault tolerance, and I thought that the way to achieve this
would be using DNS SRV and replication (which was also easy to get working)
What I've observed:
- if I create _ldaps._tcp.example.org SRV records, they are ignored
- if I create _ldap._tcp.example.org SRV records, and I ldapsearch with
a URI of the form "ldaps:///dc%3Dexample%2Cdc%3Dorg" it works
So, it seems to be the combination of the ldaps URI prefix with the
_ldap._tcp SRV record that is working, this doesn't seem right
I've also found that other LDAP apps have slightly different
expectations too:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661955
I went searching for a definite answer:
+site:ietf.org ldaps srv
http://tools.ietf.org/html/rfc2782 refers to the name of the service
from `Assigned Numbers',
http://tools.ietf.org/html/rfc1700
which omits ldaps, but it is defined elsewhere as a distinct service name:
http://www.ietf.org/assignments/service-names-port-numbers/service-names-po…
Therefore, my feeling is that
- if an ldaps: URI is used, the SRV query should be seeking
_ldaps._tcp, and
-if an ldap: URI is used (and StartTLS may or may not be requested by
the user), the SRV query should be looking for _ldap._tcp
Also, can anyone comment on why the URI needs to be escaped manually
when using DNS SRV?
Michael Ströder wrote:
> We're using self-compiled OpenLDAP 2.4.27 under RHEL 6.1 linked against
> OpenSSL 1.0.0 libs shipped with RHEL.
>
> (some names are consistently obfuscated herein to keep real names confidential)
>
> Unfortunately we can't get StartTLS to work. It always fails:
>
> # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap-srv01.rz.domain
> ldap_start_tls: Connect error (-11)
> additional info: TLS: hostname does not match CN in peer certificate
> # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap.domain
> ldap_start_tls: Connect error (-11)
> additional info: TLS: hostname does not match CN in peer certificate
>
> But OpenSSL lists the (IMO correct) hostnames in the server's certificate:
>
> ---------------------------------- snip ----------------------------------
> Subject: CN=ldap.domain,OU=xxx,O=xxx,C=DE
> [..]
> X509v3 Subject Alternative Name:
> email:certificate@xxx.domain,
> DNS:ldap.domain,
> DNS:ldap-srv01.rz.domain,
> DNS:ldap-srv02.rz.domain
> ---------------------------------- snip ----------------------------------
>
> Is the hostname check confused by the email in the first subjectAltName
> sequence value?
I tried to understand the code in function tlso_session_chkhost() in
libraries/libldap/tls_o.c (RE24) but got totally confused by the use of vars
ntype and gn->type.
Ciao, Michael.
On 9/26/2011 11:33, Dan White wrote:
> On 26/09/11 10:18 -0400, criderkevin(a)aol.com wrote:
>>
>> I'm struggling with the need for SSL...
>>
>> We will use our new LDAP for apps. These servers are all locally
>> housed so
>> each app server will talk to the LDAP server over our network. (why)
>> Would
>> we need SSL?
>>
>> What about for mail services? It seems to me that our mail server would
>> also talk directly to the LDAP server...what am I missing here that
>> dictates the use of SSL with LDAP? I could see if one had their LDAP
>> open
>> to be accessible direct access from off-network. Perhaps SSL is used
>> simply as a means to authenitcate?
>
> If you're performing TLS authentication, using client certificates, via
> STARTTLS, then using X.509 provides for a strong authentication mechanism
> using SASL (EXTERNAL).
>
> That's the one benefit that I know of beyond the obvious session based
> encryption that you obtain using certificates.
>
The tls/ssl also protects against packet interception, which while it
may seem obvious that noone can or will, I assure you someone could and
might.
On 11/29/2011 01:56 PM, Jayavant Patil wrote:
>
> >Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >Hi
>
> >I think you mean SSL connection or the STARTTLS Layer...?
> >Please read the manual http://www.openldap.org/doc/admin24/tls.html
> Ok.
>
> >And tree security:
> >On my server, a client user can only see his own object:
> Are you using simple authentication mechanism?
>
Both simple and/or SASL with GSSAPI
> >Maybe create a rule like this:
> >access to filter=(objectClass=
> >simpleSecurityObject)
> > by self read
> > by * none
>
> I am not getting what the ACL rule specifies. Any suggestions?
Just an idea, this rule allows an authenticated user access only his own
object.
He can't see other simpleSecurityObject Objects.... or whatever
But for your subject; the best setup is using TLS.....
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--
Raffael Sahli
public(a)raffaelsahli.com
I'm trying to set up slapo-pcache using cn=config, and this is my settings:
dn: olcDatabase={1}ldap,cn=config
objectClass: olcConfig
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
objectClass: top
olcDatabase: {1}ldap
olcRootDN: cn=admin,cn=config
olcAccess: {0}to * by * read
olcDbACLBind: bindmethod=simple binddn="ou=group,dc=remote"
credentials="password" tls_cacert="/etc/ssl/certs/ca-certificates.crt"
starttls=yes
olcDbURI: ldap://remote.host
olcSuffix: dc=remote
dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config
objectClass: olcPcacheConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}pcache
olcPcache: hdb 10000 1 50 100
olcPcacheAttrset: 0 member
olcPcacheTemplate: "(objectClass=)" 0 3600
dn: olcDatabase={0}hdb,olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config
objectClass: olcPcacheDatabase
objectClass: olcHdbConfig
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcDatabase: {0}hdb
olcDbDirectory: /var/lib/ldap/cache
olcDbIndex: objectClass eq
olcDbIndex: pcacheQueryid eq
But each time I'm trying to run
ldapsearch -b"cn=test2,ou=group,dc=remote" '(objectClass=*)' member
I'm getting QUERY NOT ANSWERABLE/QUERY NOT CACHEABLE errors in the log.
Besides, it is impossible to modify attributes
olcPcacheTemplate/olcPcacheAttrset:
modify/add: olcPcacheTemplate: no equality matching rule
Can anyone confirm that the one have managed to make slapo pcache
working on 2.4.31?
Is there a specific way, i have to configure the slapd to listem to 636
port..?
And does the 389 search is a secure search...?
Is there a particular way of Starting the TLS operation..?
Thanks in advance
On Fri, Jan 4, 2013 at 4:31 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --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
>
