Q: referral issue
by espeake＠oreillyauto.com
Okay my referral chaining was working and then stopped working. I get an
error 10 when I submit a change to my clustered consumers that are setup to
refer writes to my master LDAP server. In looking at the configuration
help in the online documentation it shows how to setup the slapd.conf file
on the master. The issue here is that everything is setup through
cn=config. my consumers do have a slapd.conf file along with cn=config
files. I have inherited these servers so I'm sure what the person here
before me was trying to do. I have an idea but I didn't like that idea.
Here is the chaining command from my slapd.conf file.
overlay chain
chain-uri "ldap://tntest-ldap-master-1.example.com"
chain-rebind-as-user TRUE
chain-idassert-bind bindmethod="simple"
binddn="uid=admin,dc=oreillyauto,dc=com"
credentials="password"
mode="self"
chain-tls start
chain-return-error TRUE
The the syncrepl area
syncrepl rid 002
provider=ldap://tntest-ldap-master-1.example.com
type=refreshOnly
interval=00:00:05:00
searchbase-"dc=oreillyauto,dc=com"
binddn="uuid=syncrepl,ou=system,dc=oreillyauto,dc=com"
credentials=password
updatedn "uid=ldapadmin,ou=system,dc=example,dc=com"
updateref ldap://tntest-ldap-master-1.example.com
I need to be pointed in the right direction please.
Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
10 years, 4 months
unable to query rootdn on slave via external auth
by Adrian Bridgett
This has been driving me up the wall and I wondered if someone could
point out the bit I'm missing - the desk is getting badly damaged by my
head bashing it :-)
On our master server I can query the rootdb no problem, but I can't do
this on the slaves - this applies whether I use external or ldaps
authentication. I've turned on access and search filter debugging and I
can't see any rejections. I'm trying to query contextCSN to ensure that
the slave is in sync. "slapcat" works, but seems an ugly hack. I can
query all the children - just not the root.
The config is the same (ish) on both - here's the slave:
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=example,dc=com
olcLastMod: TRUE
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW:: .......
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
structuralObjectClass: olcHdbConfig
entryUUID: 07f3fede-c201-1031-8b17-f3837148ab05
creatorsName: cn=config
createTimestamp: 20121113171221Z
olcSyncrepl: {0}rid=000 provider=ldap://ldap.example.com type=refreshandPers
ist interval=00:00:00:60 retry="60 10 300 +" timelimit=10
searchbase="dc=example
,dc=com" binddn="cn=admin,dc=example,dc=com" bindmethod=simple credent
ials=..... starttls=critical tls_reqcert=demand attrs="*,+"
olcUpdateRef: ldap://ldap.example.com
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: objectClass eq
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: uid,uidNumber,gidNumber,memberOf,sudoUser,memberUid pres,eq
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonymou
s auth by dn="cn=admin,dc=example,dc=com" manage by
group.exact="cn=admins,
ou=Group,dc=example,dc=com" manage by
dn.exact=gidNumber=0+uidNumber=0,cn=p
eercred,cn=external,cn=auth manage by * none
olcAccess: {1}to attrs=SambaLMPassword,SambaNTPassword by self write by
dn="cn
=freenas-auth,ou=services,dc=example,dc=com" read by
dn="cn=admin,dc=example
,dc=com" manage by group.exact="cn=admins,ou=Group,dc=example,dc=com" ma
nage by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth mana
ge by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=com" manage b
y group.exact="cn=admins,ou=Group,dc=example,dc=com" manage by
dn.exact=gid
Number=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read
olcAccess: {4}to dn.base="dc=example,dc=com" by * read
On the slave:
ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base -Q#
extended LDIF
# search result
search: 2
result: 0 Success
# numResponses: 1
On the master:
ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
10 years, 4 months
olcPasswordHash
by Nerijus Kislauskas
Hi community,
We want implement password politics in our DIT, and are testing ppolicy
and found issues using olcPasswordHash, Password Modify Extension and
so. Here are my testings:
1) My cn=config with olcPasswordHash and olcSuffix values
$ ldapsearch -D "cn=admin,dc=ktu,dc=lt" -W -x -b "cn=config"
olcPasswordHash olcSuffix
dn: cn=config
olcPasswordHash: {SSHA}
...
# {-1}frontend, config
dn: olcDatabase={-1}frontend,cn=config
olcPasswordHash: {SSHA}
olcPasswordHash: {SHA}
olcPasswordHash: {SMD5}
olcPasswordHash: {MD5}
olcPasswordHash: {CRYPT}
...
# {2}hdb, config
dn: olcDatabase={2}hdb,cn=config
olcSuffix: dc=ktu,dc=lt
$
2) My testing user exists without userPassword attribute
$ ldapsearch -D "cn=admin,dc=ktu,dc=lt" -W -x -b
"eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt" userPassword
Enter LDAP Password:
dn: eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt
$
3) Making a password for a test user. As documentation says "ldappasswd
uses the LDAPv3 Password Modify (RFC 3062) extended operation."
$ ldappasswd -h localhost -D "cn=admin,dc=ktu,dc=lt" -x -W -S
"eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt"
New password:
Re-enter new password:
Enter LDAP Password:
$
4) userPassword is somehow gets multivalued
$ ldapsearch -D "cn=admin,dc=ktu,dc=lt" -W -x -b
"eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt" userPassword
Enter LDAP Password:
# testuser9(a)ktu.lt, People, Users, ktu.lt
dn: eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt
userPassword:: e1NTSEF9RlE3VjRYa003RVJ6eGFTNjR4ZkFRSzRGZEk4cFk0UDQ=
--> {SSHA}FQ7V4XkM7ERzxaS64xfAQK4FdI8pY4P4
userPassword:: e1NTSEF9K1JtbWl3M0RxTTV3aEl0U3g5TjVrZWRETlpES3NROUg=
--> {SSHA}+Rmmiw3DqM5whItSx9N5kedDNZDKsQ9H
userPassword:: e1NIQX1maVFONTAreDdRajZDTk9BWS9hbXFSUmlxQlU9 -->
{SHA}fiQN50+x7Qj6CNOAY/amqRRiqBU=
userPassword:: e1NNRDV9VUdaa3ZDSWI5Qld4a1VNcUhyZEl3ZElTbnJ3PQ==
--> {SMD5}UGZkvCIb9BWxkUMqHrdIwdISnrw=
userPassword:: e01ENX1SN3pseDA5WW4waG4yOVYrbktuNENBPT0= -->
{MD5}R7zlx09Yn0hn29V+nKn4CA==
userPassword:: e0NSWVBUfTFNZVAud1ZxenEvdWM= -->
{CRYPT}1MeP.wVqzq/uc
$
I guess "frontend" database has so called global olcPasswordHash
directive in effect over all databases. I also guess, that 1 SSHA form
comes from cn=config, and other 5 forms comes from "frontend". Does
anyone know if this is true?
5) if above is true, overwriting globals in local database config seems
like a solution to me, but ...
$ ldapmodify -D "cn=admin,dc=ktu,dc=lt" -W -x <<EOF
> dn: olcDatabase={2}hdb,cn=config
> changetype: modify
> add: olcPasswordHash
> olcPasswordHash: {SSHA}
> EOF
Enter LDAP Password:
modifying entry "olcDatabase={2}hdb,cn=config"
ldap_modify: Object class violation (65)
additional info: attribute 'olcPasswordHash' not allowed
$
Is it possible to get rid of not secure forms of password schemes? I
always believed, that password-hash (olcPasswordHash) should help to do
that. Maybe I don't know something? I also think, that it could be
related to ITS#7625
<http://www.openldap.org/its/index.cgi/Incoming?id=7625;expression=ppolicy...>,
why ppolicy shows "Additional info: Password policy only allows one
password value" error message. Please, help to clear things out.
System: Debian 7.0 (wheezy)
OpenLDAP: 2.4.31 (from package)
Thank you.
--
Pagarbiai,
Nerijus Kislauskas
KTU ITD, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislauskas(a)ktu.lt
10 years, 4 months
Re: Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson
> So you didn't answer anything about the old version of OpenLDAP versus the
> current one. I would note that according to the db_stat output, you've
> experienced zero deadlocks. That seems somewhat in conflict with your
> earlier report. Did you run db_recover (resetting the stats)?
Sorry; I missed that one.
We were running 2.4.33 before the upgrade.
I have not run db_recover in between the original report and now. It
is worth noting that the deadlock errors have ceased in the log file,
but I can't speak to whether or not we're more stable than we were
before; as I mentioned earlier, it seemed kinda random when it would
crash.
I was thinking that doing a slapcat and then cleaning out the database
files and then slapadd'ing everything back might be helpful. Do you
agree?
--
Tim Gustafson
tjg(a)ucsc.edu
831-459-5354
Baskin Engineering, Room 313A
10 years, 4 months
Re: Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson
> When you say you upgraded, what all did you do? Did you only upgrade the
> openldap binaries? From what openldap release to what release? Did your
> upgrade also change the version of BDB? What version of BDB were you on?
> What one are you on now? What does your DB_CONFIG file look like? What
> does your db_stat -c usage show for locks/lockers/lock objects etc?
We're running FreeBSD. I did a minor OS update from 8.2 to 8.4, and
then rebuilt all my ports using "portmaster". We're using
db46-4.6.21.4 both before and after the upgrade. DB_CONFIG is as
follows:
set_cachesize 0 67108864 1
set_flags DB_LOG_AUTOREMOVE
The output of "db_stat-4.6 -c" is:
116 Last allocated locker ID
0x7fffffff Current maximum unused locker ID
9 Number of lock modes
1000 Maximum number of locks possible
1000 Maximum number of lockers possible
1000 Maximum number of lock objects possible
16 Number of current locks
24 Maximum number of locks at any one time
105 Number of current lockers
111 Maximum number of lockers at any one time
16 Number of current lock objects
22 Maximum number of lock objects at any one time
4144507 Total number of locks requested
4144491 Total number of locks released
0 Total number of locks upgraded
36 Total number of locks downgraded
38 Lock requests not available due to conflicts, for which we waited
0 Lock requests not available due to conflicts, for which we did not wait
0 Number of deadlocks
0 Lock timeout value
0 Number of locks that have timed out
0 Transaction timeout value
0 Number of transactions that have timed out
712KB The size of the lock region
13666 The number of region locks that required waiting (0%)
--
Tim Gustafson
tjg(a)ucsc.edu
831-459-5354
Baskin Engineering, Room 313A
10 years, 4 months
Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson
I recently upgraded OpenLDAP to 2.4.35 and I'm now experiencing some
instability issues, and also seeing a bazillion of the following error
in my log file:
bdb_dn2id_delete 0x108c68: delete failed: DB_LOCK_DEADLOCK: Locker
killed to resolve a deadlock -30995
I'm using the BDB backend at the moment. One Google search hit I
found suggested I switch to MDB instead. Would this help?
--
Tim Gustafson
tjg(a)ucsc.edu
831-459-5354
Baskin Engineering, Room 313A
10 years, 4 months
delete members in big groups with back_mdb
by Marco Schirrmeister
Hi,
I have a problem with mdb and modify operations on very large groups. Specifically deleting members from those groups.
Removing 10 members from a group with 25000 members takes 23 seconds. Which also means, all other clients that want to do something hang.
Deleting a user from multiple big groups takes minutes before it finishes.
Adding members to a large group is quick though.
When this delete is running, the cpu goes also up to 100%.
It looks like it has to do with the index that I have on uniqueMember.
If I remove the index on uniqueMember, the delete of members in big groups is fast.
System details are
CentOS 6 64bit
OpenLDAP 2.4.35
slapd.conf below
Is this something normal/exptected or is it maybe a bug?
Steps to reproduce
- Install OpenLDAP 2.4.35
- Import a base ldif
- Add a group with 25000 users
- Remove 10 members from the group via ldapmodify
Example group
dn: cn=x3zolgnanlmpzj1nfk21,ou=groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
ou: groups
cn: x3zolgnanlmpzj1nfk21
description: aw88bob79vvqffv1fhii
uniqueMember: uid=faefxus4e83ywhh7bbgw(a)ough6unnwjdx0zzqiy0i.e3j,ou=people,dc=example,dc=com
...
Below is the slapd.conf from a test system where I reproduced it.
I used a very minimal config on the test system.
---- slapd.conf ----
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/corba.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/openldap.schema
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
modulepath /usr/lib64/oldap24/openldap2.4
moduleload back_monitor.la
loglevel stats sync
serverID 21 ldap://ldap.example.com
database mdb
suffix "dc=example,dc=com"
rootdn "cn=manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap2.4/example.com
dbnosync
maxsize 107374182400
conn_max_pending_auth 2000
index objectClass eq
index uniqueMember eq
index entryCSN,entryUUID eq
monitoring on
database config
rootdn "cn=admin,cn=config"
rootpw secret
database monitor
rootdn cn=monitor
rootpw secret
---- slapd.conf ----
Thanks
Marco
10 years, 4 months
Q: TLS support
by Ulrich Windl
Hi!
I have some questions on TLS support in OpenLDAP:
1) How can I find out which cipher suite had been configured (when using the distribution-supplied version)? From ldd I guess my slapd is using libopenssl0_9_8.
2) Is the restriction ("This directive is not supported when using GnuTLS.") on TLSCACertificatePath and GunTLS still effective? I'd like to use it, but I'm unsure what the cipher suite is.
3) Do the CA certificates for TLSCACertificateFile have to have a specific ordering?
Regards,
Ulrich
10 years, 4 months
OpenLDAP syncrepl using SASL - GSSAPI
by Quentin PETEL
Hi!
I'm trying to implement a Kerberos server using an OpenLdap backend on a
server called *ldap1.vm* and replicate those on an other called *ldap2.vm*.
My first server is working fine. Each kerberos principal is stored in
his own ldap entry (with the krbPrincipalName attribut).
For exemple :
user1(a)EXEMPLE.COM --> uid=user1,ou=people,dc=exemple,dc=com
ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM -->
cn=ldap2.vm,ou=ldap,dc=exemple,dc=com
I wish to replicate either the cn=config DIT and the dc=exemple,dc=com
DIT to my second server.
So in my *cn=config* DIT on *ldap1.vm* I have the following configuration :
==========================================================
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAuthzRegexp: {0}uid=admin,cn=exemple.com,cn=gssapi,cn=auth
cn=admin,dc=exemple,dc=com
olcAuthzRegexp:
{1}uid=ldap\/(.*).exemple.com,cn=exemple.com,cn=gssapi,cn=auth
cn=$1,ou=ldap,dc=exemple,dc=com
olcAuthzRegexp:
{2}uid=host\/(.*).exemple.com,cn=exemple.com,cn=gssapi,cn=auth
cn=$1,ou=hosts,dc=exemple,dc=com
olcAuthzRegexp: {3}uid=(.*),cn=exemple.com,cn=gssapi,cn=auth
uid=$1,ou=people,dc=exemple,dc=com
olcSaslRealm: EXEMPLE.COM
olcServerID: 1 ldap://ldap1.vm.exemple.com/
olcServerID: 2 ldap://ldap2.vm.exemple.com/
olcLogLevel: stats
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
dn: olcBackend={0}hdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}hdb
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcRootDN: *cn=admin,cn=config*
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=exemple,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=exemple,dc=com" write
by dn.one="ou=ldap,dc=exemple,dc=com" read
by anonymous auth by * none
olcAccess: {1}to dn.subtree="dc=exemple,dc=com"
by dn="cn=adm-srv,ou=krb5,dc=exemple,dc=com" write
by dn="cn=kdc-srv,ou=krb5,dc=exemple,dc=com" read
by dn="cn=admin,dc=exemple,dc=com" write
by dn.one="ou=ldap,dc=exemple,dc=com" read
olcAccess: {2}to attrs=loginShell
by self write
by users read
by * none
olcAccess: {3}to dn.base="" by * read
olcAccess: {4}to * by users read by * none
olcAccess: {5}to dn="cn=config" by dn.one="ou=ldap,dc=exemple,dc=com" write
olcLastMod: TRUE
olcRootDN: cn=admin,dc=exemple,dc=com
olcRootPW: {SSHA}7JR5Gh0ZUbw9U4cVytBrChBjXuPAdLKh
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: cn eq
olcDbIndex: ou eq
olcDbIndex: dc eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: memberUid eq
olcDbIndex: uniqueMember eq
olcDbIndex: krbPrincipalName eq,pres,sub
olcDbIndex: krbPwdPolicyReference eq
dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
==========================================================
And on the ldap2.vm i wanna replicate the cn=config DIT first:
==========================================================
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
by * break
olcRootDN: cn=admin,cn=config
olcSyncrepl: {0}rid=001
provider="ldap://ldap1.vm.exemple.com/"
type=refreshAndPersist
retry="10 30 30 +"
searchbase="cn=config"
bindmethod=sasl
saslmech=gssapi
==========================================================
There is no olcMirrorMode attributes because I wanna add other provider
directives later.
Every 10 secondes, i see those logs:
==========================================================
conn=1001 fd=13 ACCEPT from IP=192.168.x.x:57695 (IP=0.0.0.0:389)
conn=1001 op=0 BIND dn="" method=163
conn=1001 op=0 RESULT tag=97 err=14 text=SASL(0): successful result:
conn=1001 op=1 BIND dn="" method=163
conn=1001 op=1 RESULT tag=97 err=14 text=SASL(0): successful result:
conn=1001 op=2 BIND dn="" method=163
conn=1001 op=2 BIND authcid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM"
authzid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM"
conn=1001 op=2 BIND dn="cn=ldap2.vm,ou=ldap,dc=exemple,dc=com"
mech=GSSAPI sasl_ssf=56 ssf=56
conn=1001 op=2 RESULT tag=97 err=0 text=
conn=1001 op=3 SRCH base="cn=config" scope=2 deref=0
filter="(objectClass=*)"
conn=1001 op=3 SRCH attr=* +
findbase failed! 32
conn=1001 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text=
conn=1001 op=4 UNBIND
conn=1001 fd=13 closed
==========================================================
We see that the olcAuthzRegexp do is job, indeed, the
authcid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM" from the ticket (I use
Kstart to obtain it) become dn="cn=ldap2.vm,ou=ldap,dc=exemple,dc=com".
But it fail to find the cn=config DIT.
Here is the entry on my ldap database:
==========================================================
dn: cn=ldap2.vm,ou=ldap,dc=exemple,dc=com
objectClass: ipHost
objectClass: device
objectClass: top
objectClass: krbPrincipalAux
objectClass: krbTicketPolicyAux
cn: ldap2.vm
ipHostNumber: 192.168.x.x
structuralObjectClass: device
entryUUID: afe9a32a-81a3-1032-85b7-7976b72b0c24
creatorsName: cn=admin,dc=exemple,dc=com
createTimestamp: 20130715140754Z
krbPrincipalName: ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM
krbLoginFailedCount: 0
krbPrincipalKey:: [...]
krbPasswordExpiration: 19700101000000Z
krbLastPwdChange: 20130715140838Z
krbExtraData::
AAJmAuRRYWRtaW5ASU5URVJORS5PQlNFUlZBVE9JUkVERVNNQVJRVUVTLkZSAA=
=
krbExtraData:: AAgBAA==
authzTo: {0}dn.regex:*cn=admin,cn=config*
entryCSN: 20130716154135.008692Z#000000#001#000000
modifiersName: cn=admin,dc=exemple,dc=com
modifyTimestamp: 20130716154135Z
==========================================================
The authzTo directive allow, i think, this entry to act as
cn=admin,cn=config and to see the cn=config DIT, am I wrong? How can I
do what I want?
This configuration works well when I try to synchronise the
dc=exemple,dc=com DIT.
Regards,
Quentin
10 years, 4 months
Problems with ACLs
by Leonardo Bacha Abrantes
Hi guys,
I configured ACL (below) and am trying to log on the console with a ldap's
user I receive the error "ldap_search_s No such object' on /var/log/secure.
If I comment acls the user is able to logon.
Here my configuration:
==>> olcDatabase={2}bdb.ldif
olcRootDN: cn=Manager,dc=foo,dc=local
olcRootPW: {MD5}xxxxxxxxxxxxxxxxx
olcAccess: to attrs=userPassword by self write
olcAccess: to attrs=cn,sn,displayName,mail,description by users read
olcaccess: to * by self read
I used slapacl to check the permissions and appeared ok.
What I'm doing worng ? Can you help me please ?
10 years, 4 months
