slapd-meta
by Fr3ddie
Hello to the list,
I'm trying to configure the slapd-meta OpenLDAP backend on an online
cn=config
configuration with no luck. Slapd version is 2.4.39 (the maximum I can
achieve on the target machines building from vanilla source).
The documentation is clear but too concise for me so I will try to explain
what I'm trying to do to see if there is anybody that can help me.
Currently I have 3 slapd servers that share a common root for the DIT, i.e.:
dc=loc1,dc=root
dc=loc2,dc=root
dc=loc3,dc=root
What I would like to achieve is to obtain a fourth server that contains
the previous trees, along with its own tree, i.e. a server that contains:
dc=loc0,dc=root (locally hosted data)
dc=loc1,dc=root (coming from the first server, chasing referrals)
dc=loc2,dc=root (coming from the second server, chasing referrals)
dc=loc3,dc=root (coming from the third server, chasing referrals)
this way, all the clients connecting to this server will be able to
retrieve data also from the other three remote servers.
As far as I understood, I only need to configure the "loc0" server to access
the other three servers and get the data to serve to clients.
I have already configured the fourth server with its local DIT and this is
the configuration:
# cat 'cn=config.ldif'
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
structuralObjectClass: olcGlobal
creatorsName: cn=config
olcServerID: 1
olcThreads: 32
olcToolThreads: 8
olcRequires: LDAPv3
olcConnMaxPendingAuth: 100
olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem
olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem
olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key
olcTLSVerifyClient: try
olcTimeLimit: 600
olcLogLevel: stats2 sync
[...]
# cat 'cn=module{0}.ldif'
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}accesslog
structuralObjectClass: olcModuleList
[...]
Schema files are the following:
cn={0}core.ldif
cn={1}cosine.ldif
cn={2}nis.ldif
cn={3}inetorgperson.ldif
cn={4}dyngroup.ldif
cn={5}kerberos.ldif
# cat 'olcDatabase={1}hdb.ldif'
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=loc0,dc=root
olcAccess: {0}to
attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn
=admin,dc=loc0,dc=root" write by anonymous auth by self write by *
none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=loc0,dc=root
olcRootPW:: xxxxxxxxxxxxxxxxxxxx
olcDbCacheSize: 10000
olcDbCheckpoint: 512 10
olcDbConfig: {0}set_cachesize 0 524288000 1
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 30000
olcDbIndex: default pres,eq
[...]
structuralObjectClass: olcHdbConfig
olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root
bindmethod=s
imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx
searchbase="dc=loc0,dc=root"
logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj
ect)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="60 +" syn
cdata=accesslog starttls=yes
olcMirrorMode: TRUE
[...]
On top of this DB I have the "syncprov" and the "accesslog" overlays
configured
(these are two servers in "MirrorMode", configured following the
OpenLDAP admin documentation).
I believe this DB is the ones containing the actual "loc0" DIT data...
Then I have the accesslog DB for the replica (with the syncprov overlay
on top):
# cat 'olcDatabase={2}hdb.ldif'
dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=loc0,dc=root
olcDbConfig: {0}set_cachesize 0 524288000 1
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
[...]
On top of this environment I start loading the needed modules with this
LDIF file:
version: 1
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_ldap
-
add: olcModuleLoad
olcModuleLoad: back_meta
-
add: olcModuleLoad
olcModuleLoad: rwm
and it seems I'm able to load the new modules without errors
into the configuration, thus I obtain:
# cat 'cn=module{0}.ldif'
dn: cn=module{0}
structuralObjectClass: olcModuleList
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}accesslog
olcModuleLoad: {3}back_ldap
olcModuleLoad: {4}back_meta
olcModuleLoad: {5}rwm
[...]
Now I try to load the slapd-meta directives into a new database using
this LDIF:
version: 1
dn: olcDatabase={3}meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: {3}meta
olcSuffix: dc=root
olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
but I obtain an error that sticks me trying various combinations without
success:
# ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase={3}meta,cn=config"
ldap_add: Object class violation (65)
additional info: attribute 'olcDbURI' not allowed
and:
# tail /var/log/openldap/slapd.log
Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM
oid=1.3.6.1.4.1.4203.1.9.1.4
Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:57:07 server01 slapd[32392]: Entry
(olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed
Into the slapd-meta documentation the "URI" directive is mentioned but
the "DbURI" seems to
raise a "better error", in fact if I try to modify the above LDIF file
using "URI" I obtain:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase={3}meta,cn=config"
ldap_add: Undefined attribute type (17)
additional info: olcUri: attribute type undefined
Moreover, it is not stated into the slapd-meta docs that the slapd-ldap
backend is needed by slapd-meta but,
anyway, I think its needed because if I try to load the slapd-meta alone
it raises an error (I don't remember exactly which one).
At this point I'm stuck to this error and I wasn't able to find any hint
on the web to solve this :(
The examples I was able to find were related with the static slapd.conf
configuration, I counldn't
find any "full" configuration example using the cn=config.
I'm wondering if I should create a "cn=root" actual DB first and then
link the sub-DITs to it,
or, maybe, add some other overlay... I really can't understand how it
should work :(
Can please anybody help me?
Thank you very much
6 years, 10 months
Documentation Feedback
by Tom Jay
Hello,
I would like to voice my frustration with the quality of the openLDAP documentation. I am compiling openLDAP from source on Debian 7, and have spent about 2-3 continuous days getting to the point where I can add an LDAP user with a UID. I have been close to giving up with the software, but need it for the LDAP functionality, and as very few viable alternatives exist, have been forced to continue with the installation. I have however almost lost confidence in the product, and am concerned that if there are any problems with it in the future, or I want to enable another feature, I will be almost helpless in getting it to work.
The main problem is the Quick-Start Guide. This is anything but quick, and forces the user to consult the less-than-succinct Admin guide. The two together are inconsistent, difficult to follow and do a poor job of explaining what each feature does. The accessibility of information is less than optimal, which means that the user has to look elsewhere, consuming even more time. Unfortunately, there is not much relevant information on the Internet, forcing the user to get stuck in an almost endless loop of checking documentation, testing, reading manuals, and searching on the Internet, in order to get some kind of idea how the software works and what needs to be done to get it working.
I would offer to contribute to the documentation, but due to its lack of usefulness, do not have an understanding of the basic concepts myself. The best I would be able to do is describe my experience and provide the steps that I followed to get a basic installation working.
Hopefully someone can volunteer the time to test the documentation, in the same way a new user would!
Tom
7 years
UNKNOWN attributeDescription "ATTRIBUTE1" inserted
by PenguinWhispererThe
Hi all,
I've been trying to update a schema with new olcAttributeTypes and modified
an existing objectClass (X) so these attributesTypes may be used with it.
However after adding these attributes to objectClass X I did a "rollback"
(replacing the current olcObjectClasses (replace: olcObjectClasses) with
the old definition and the same for the olcAttributes (replace:
olcAttributeTypes).
I think somewhere along the way something wasn't cleaned up properly.
Now when I start slapd service I get:
slapd[21335]: UNKNOWN attributeDescription "ATTRIBUTE1 " inserted.
slapd[21335]: UNKNOWN attributeDescription "ATTRIBUTE2" inserted.
slapd[21335]: [66B blob data]
With slapschema:
UNKNOWN attributeDescription "ATTRIBUTE1 " inserted.
UNKNOWN attributeDescription "ATTRIBUTE2" inserted.
UNKNOWN attributeDescription "ATTRIBUTE3
With slapcat I can't find anything that's matching these names.
When I grep in the mdb file grep says the binary file is matching.
However when I ldapsearch for the attribute I can't find it.
Neither with slapcat.
Note that I replaced the actual attribute names in the posted output.
So I think I might have some data in that mdb that's not linked to anything
anymore.
So my question is: how can I clean this up? And/or what did/went wrong?
Thanks in advance for your help.
7 years
MDB data replication issues
by Gurjot Kaur
Hi,
I am using a OpenLDAP 2.4.44 Multi master configuration with two slapd servers, master and replica using MDB backend. I got a problem in replicating when the data is added using slapadd.
I have two slapd with ports 2016 and 2017. slapd.conf file for both the servers are attached.
Scenario 1:
When an LDIF entry is added using ldapadd or deleted using ldapdelete, it gets replicated in the replica server correctly.
Below is the ldapsearch result om Master server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2016 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# Test9, people, my-domain.com
dn: ou=Test9,ou=people,dc=my-domain,dc=com
ou: Test9
objectClass: organizationalUnit
companyName: Test9Grp
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Below is the ldapsearch result om replica server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2017 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# Test9, people, my-domain.com
dn: ou=Test9,ou=people,dc=my-domain,dc=com
ou: Test9
objectClass: organizationalUnit
companyName: Test9Grp
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Scenario 2:
When an LDIF entry is imported using slapadd, it doesn't get replicated in the replica server at all.
Below is the ldapsearch result om Master server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2016 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# Test9, people, my-domain.com
dn: ou=Test9,ou=people,dc=my-domain,dc=com
ou: Test9
objectClass: organizationalUnit
companyName: Test9Grp
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Below is the ldapsearch result om replica server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2017 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
Please let me know in case any other information is required.
Br
Gurjot Kaur
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
7 years, 2 months
unclear documentation about openldap ACL definitions
by Florian Best
Hello,
studying the slapd.access man page left me with an open question regarding the
control of object creation:
* How to allow the creation of objects with a specific objectclass only?
For example, I want to prevent that an object with a object class other
than 'foobar' is created.
Assumming the following LDIF should be valid for an "add" operation:
> dn: uid=anton1,cn=settings,dc=ldap,dc=base
> objectClass: foobar
> uid: anton1
And this one to be invalid:
> dn: uid=anton1,cn=settings,dc=ldap,dc=base
> objectClass: CourierMailAccount
> objectClass: univentionAdminUserSettings
> uid: anton1
> uidNumber: 0
> gidNumber: 0
All of the following examples aren't doing their job when *creating* an
entry. Most of them (and even more simple ones) work fine when *modifying* an entry:
## 1. a attribute blacklist ##
access to dn="cn=settings,dc=ldap,dc=base" attrs="entry,children"
by users write
by * +0 break
access to dn.regex="^uid=([^,]+),cn=settings,dc=ldap,dc=base$"
filter="objectClass=foobar" attrs=!foobar
by dn.regex="^uid=$1,.*dc=ldap,dc=base$$" none
by * +0 break
access to dn.regex="^uid=([^,]+),cn=settings,dc=ldap,dc=base$"
filter="objectClass=foobar" attrs=entry,@foobar
by dn.regex="^uid=$1,.*dc=ldap,dc=base$$" write
by * none
##################
→ does probably not work because "!foobar" also disallows "objectClass"?
## 2. a negative regex blacklist ##
access to dn="cn=settings,dc=ldap,dc=base" attrs="entry,children"
by users write
by * +0 break
access to dn.regex="^uid=([^,]+),cn=settings,dc=ldap,dc=base$"
attrs=objectClass
val.regex="^([^f]|f[^o]|fo[^o]|foo[^b]|foob[^a]|fooba[^r])$"
by dn.regex="^uid=$1,.*dc=ldap,dc=base$$" none
by * +0 break
access to dn.regex="^uid=([^,]+),cn=settings,dc=ldap,dc=base$"
filter="objectClass=foobar" attrs=entry,@foobar
by dn.regex="^uid=$1,.*dc=ldap,dc=base$$" write
by * none
##################
## 3. a whitelist ##
access to dn="cn=settings,dc=ldap,dc=base" attrs="entry,children"
by users write
by * +0 break
access to dn.regex="^uid=([^,]+),cn=settings,dc=ldap,dc=base$"
attrs=objectClass value="foobar"
by dn.regex="^uid=$1,.*dc=ldap,dc=base$$" write
by * +0 break
access to dn.regex="^uid=([^,]+),cn=settings,dc=ldap,dc=base$"
attrs=objectClass
by dn.regex="^uid=$1,.*dc=ldap,dc=base$$" none
by * +0 break
access to dn.regex="^uid=([^,]+),cn=settings,dc=ldap,dc=base$"
filter="objectClass=foobar" attrs=entry,@foobar
by dn.regex="^uid=$1,.*dc=ldap,dc=base$$" write
by * none
##################
* Is the filter="…" in the "to" clause of an ACL evaluated when "adding"
an entry?
* Is the filter="…" when modifying an entry also applied against the
modified result or only against the current state of the object?
* the manpage says the syntax is "attrs=<attrlist>[
val[/matchingRule][.<attrstyle>]=<attrval>]" → The hardcoded "val" can
also be "value"
* no multiple value-lists can be used in a single defintion (e.g. access
to attrs="objectClass val=foo" attrs="someAttribute val="bar" or
attrs="objectClass val=foo,someAttribute val=bar")
* "matchingRule" is nowhere defined in the manpage
Some further suggestions for the development are:
* It would reduce a lot of redundancy if multiple "to" statements could
be used in one ACL definition (so that the different by clauses doesn't
always need to be copied).
* If the "by" clause would also have a filter="" one wouldn't need to
use "set"s anymore - sets are slower and doesn't even work with all
things (e.g. if you have special characters in the DN). There is no way
to escape "]" / "[" and urlencode things which are e.g. used in a LDAP
URI filter. This can even lead to security issues.
* ACL rules can't be bound to the ldap operation (search, auth, add,
modify, delete, ...), you can only remove e.g. some of the permission
bits (e.g. access to if-operation="search" ...)
* Using backreferences of the DN in the filter="" or attrs="" would also
be very handy (how to restrict e.g. the "uid" value to be only what's in
the DN of the target/operating user?)
Best regards
Florian
--
Florian Best
Open Source Software Engineer
Univention GmbH
be open
Mary-Somerville-Str.1
28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
best(a)univention.de
http://www.univention.de
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
7 years, 2 months
syncrepl constantly desyncing
by Eugene M. Zheganin
Hi,
I'm using a configuration with two slapd servers, master and replica.
The problem is that replica is constantly desyncing. I'm monitoring it's
number of users and groups and the cound of members of one particular
group. Users and group entities are always in sync, but entities like
groupOfUniqueNames are desyncing - they are not receiveing deltas from
master, keeping their members count constant.
My config (done according to the documentation):
===Cut===
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncrepl rid=123
provider=ldap://xx.xx.xx.xx:389
type=refreshAndPersist
interval=00:00:10:00
retry="60 10 300 +"
filter="(objectClass=*)"
searchbase="dc=my,dc=domain"
attrs="*,+"
schemachecking=off
bindmethod=simple
binddn="uid=proxy,ou=accounts,ou=internal,dc=my,dc=domain"
credentials=XXXXXXXXXXXXXX
===Cut===
I've also tried the refreshOnly method, which gave me same result. In
order to resync replica I have to flush the directory contents each time
and restart the slapd. I'm also suspecting that this desyncing happens
because for some reason replica slapd isn't refreshing attribute values,
only entities themselves: today I found a user, which userPassword
attributes were out of sync on the replica. As far as I understand the
documentation, syncrepl should sync the attributes.
And the last question - is there any simple way to enable logging of
syncrepl warnings and errors ? My experience with openldap logging tells
me there's to mode of logging - "none" and "generate 10Gb of logs per
day", but may me it's just me.
Thanks.
Eugene.
7 years, 2 months
RHEL7 issues maybe???
by Frank Swasey
Folks,
I am working on moving my OpenLDAP 2.4.44 environment from RHEL6 to
RHEL7. I want to double check an assumption I have made before I open a
report with Red Hat about the quality of their product.
I am assuming that with "loglevel sync" and an empty consumer, that
there should be one sincrepl_entry line that has "inserted UUID" in the
syslog output for every entry created. Is that a valid assumption?
Thanks,
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
7 years, 3 months
Invalid DN
by James Lertora
Hi all,
I know this has probably been answered but please bear with me.
I have been hitting a wall for about a week messing with this and cannot seem to find the answer Googling all this time.
I have followed several online set guides and even gone through the setup slowly at least a dozen times.
I am using Cent 7. OpenLDAP 2.4.40.
I can anonymously browse and retrieve DN for my group and two users and do the same with the ldap dn.base user.
I have played around with the acl but keep messing it up.
It's a vm so I revert back to a clean state after getting lost in the weeds.
I keep getting "Error:ldap_bind: Invalid DN syntax (34)" for the users I have added. If I change to the correct DN I get incorrect password.
Any pointers will be much appreciated.
Thanks,
fastpackets
7 years, 3 months
openLDAP multi-master replication
by Boris Servo
Hello,
I am trying to do openLDAP multi-master replication in centOS version 6.8
and openLDAP 2.4.40.
So the openLDAP config is straight forward, the replication is the one that
I am having some issues.
Attached to this email are the config files that I am using for the
openLDAP and the replication.
Thank you in advance.
Kindest regards,
Boris Servo
7 years, 3 months
first time user
by Kaveh Ehsani
Hi Everyone,
I am using this for the first time so if there are protocols to follow please let me know. I have a problem with binding from my client to provider as the provider does not allow anonymous binding, I am also new to openldap, and it is centos 7 I am using which no longer uses slapd.conf. I initially used this to change the monitor ACL:
ldapmodify -H ldapi:/// -x -D "cn=config" -W <<EOF
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.base="cn=Manager,dc=${MYDOMAIN},dc=${MYTLD}" read
by * none
EOF
Which worked fined. Then tried to modifying it by adding:
'by anonymous search'
and try to run the same ldapmodify as:
ldapmodify -H ldapi:/// -x -D "cn=config" -W <<EOF
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.base="cn=Manager,dc=${MYDOMAIN},dc=${MYTLD}" read
by anonymous search
EOF
and I get this error:
ldap_start_tls: Can't contact LDAP server (-1)
I think my binding inside sssd.conf on the client side is incorrect for the newuser01 I have added to the ldapserver
Useldap_default_bind_dn = cn=newuser01,dc=example,dc=com
Thanks for all the feed backs.
7 years, 3 months
