invalid syntax on pwdPolicy object add
by Julien Vehent
Hello all,
I'm trying to add a default password policy to my directory. I have set the following parameters in slapd.conf:
----
include /etc/ldap/schema/ppolicy.schema
[...]
moduleload ppolicy
[...]
backend hdb
database hdb
suffix "dc=example,dc=net"
[...]
# Password policy
overlay ppolicy
ppolicy_default "cn=defaultpwpolicy,ou=policies,dc=example,dc=net"
----
I have created the OU 'policies' just fine, but when I try to add a pwdPolicy object, i get the following error:
----
# ldapadd -x -D cn=admin,dc=example,dc=net -W << EOF
dn: cn=defaultpwpolicy,ou=policies,dc=example,dc=net
objectClass: pwdPolicy
objectClass: top
pwdAttribute: userPassword
pwdAllowUserChange: TRUE
pwdInHistory: 2
pwdMaxFailure: 10
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdMinLength: 6
EOF
Enter LDAP Password:
adding new entry "cn=defaultpwpolicy,ou=policies,dc=example,dc=net"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax
----
The Schema is properly loaded, the ppolicy.so module is in the path (ie, /usr/lib/ldap on debian). So, I'm out of ideas. Anything I've missed here ?
Thanks for your help,
Julien
12 years, 8 months
Re: Authenticate to ldap using Kerberos
by Dan White
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
>> That requires pass-through authentication.
>
>I see.
>Well with the above instructions nothing seems to have changed.
>I have restarted saslauthd and slapd after making the changes, and when
>now accessing the ldap addressbook using Evolution, I still have to use
>the ldap stored password, not the krb password.
>
>Wouter.
To be a little more explicit, to enable pass-through authentication, you
will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
for instance:
dn: uid=jsmith,dc=example,dc=com
...
userPassword: {SASL}jsmith
In this case, the user will have no valid password defined in LDAP (or at
least not in the userPassword attribute).
When attempting to perform a non-sasl bind, slapd will use saslauthd to
authenticate, by taking the username (from the userPassword field), and the
password that was submitted.
--
Dan White
12 years, 8 months
How to bootstrap in mirror mode with cn=config
by Torsten Schlabach (Tascel eG)
Dear list!
I am currently chasing some replication problems and I am trying to get my
mind around a couple of questions.
Let's assume this:
We have two LDAP servers, server 1 and server 2, which are supposed to be
mirrors of each other.
The both have their cn=config database and a database with actual data,
let's assume it's the dc=example,dc=com database.
I want to run not only dc=example,dc=com but also cn=config in mirror mode
to make sure that I keep the config in sync and that any changes to the
config (e.g. ACls) can be done on one of the servers and will replicate to
the other one.
Let's assume this was all working well.
Not server 2 fails and needs a complete reinstall. So I sit there with a
slapd binary and no configuration at all.
My idea would be (please tell me if I am on the right path) :
1. I could give server 2 a minimal config which does not contain anything
else but "replicate your cn=config from server1". Let's call this a
bootstrap config.
2. Once server 2 starts with that bootstrap config, it will fetch
cn=config from server1.
3. It will learn from the replicated config that it has to have an
dc=example,dc=com database, create it and replicate its content from
server1 as well.
4. I would be back in business.
Unfortunately, when I tried, what happened was:
The contextCSN of the bootstrap config on server 2 is newer / higher than
the one on server 1 which has not been touched for a while. So server 2 did
not fetch the config from server 1 but vice versa, which was not exactly
the result I intended. Though it's very consequent and logical behaviour.
My question:
Am I on the complete wrtong track?
Would I have to do the slapcat -> slapadd thing between server 1 and
server 2 first (with server 2 offline) and start server 2 only after that?
When I do the slapcat / slapadd thing from server 1 to server 2, do I have
to remove any contextCSN / entryCSN entries (as some postings such as
http://www.mail-archive.com/openldap-technical@openldap.org/msg00109.html)
suggest or would that be just wrong?
Regards,
Torsten
12 years, 8 months
Can't get TLS working.
by c0re
Hello everyone!
Wrote to openldap-software, but got
"Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.1.1
<openldap-software(a)openldap.org>... User unknown (state 14)."
So I'm here.
I'm trying to make openldap+TLS on freebsd 7.3.
I configured openldap, nss_ldap, ldap.conf, nsswitch.conf, can
ldapsearch it, can make "id user" and etc.
So when I do "id test" I get
uid=5555(test) gid=5555 groups=5555
All ok.
And now I want to add TLS to it.
So I add to slapd.conf
TLSCertificateFile /usr/local/etc/openldap/ssl/ldap.server.ru.crt.pem
TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap.server.ru.key.pem
TLSCACertificateFile /usr/local/etc/openldap/ssl/rootcrt.pem
In nss_ldap and ldap.conf I add folowing:
ssl start_tls
tls_cacertfile /usr/local/etc/openldap/ssl-client/rootcrt.pem
I start slapd with debugging:
/usr/local/libexec/slapd -u ldap -d 1
and making "id test" I get
"id: test: no such user"
And slapd debug:
slap_listener_activate(7):
>>> slap_listener(ldap:///)
connection_get(11): got connid=1000
connection_read(11): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 29 contents:
op tag 0x77, time 1284477158
ber_get_next
conn=1000 op=0 do_extended
ber_scanf fmt ({m) ber:
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush2: 14 bytes to sd 11
connection_get(11): got connid=1000
connection_read(11): checking for input on id=1000
TLS trace: SSL_accept:before/accept initialization
TLS trace: SSL_accept:SSLv3 read client hello A
TLS trace: SSL_accept:SSLv3 write server hello A
TLS trace: SSL_accept:SSLv3 write certificate A
TLS trace: SSL_accept:SSLv3 write server done A
TLS trace: SSL_accept:SSLv3 flush data
TLS trace: SSL_accept:error in SSLv3 read client certificate A
TLS trace: SSL_accept:error in SSLv3 read client certificate A
connection_get(11): got connid=1000
connection_read(11): checking for input on id=1000
TLS trace: SSL_accept:SSLv3 read client key exchange A
TLS trace: SSL_accept:SSLv3 read finished A
TLS trace: SSL_accept:SSLv3 write change cipher spec A
TLS trace: SSL_accept:SSLv3 write finished A
TLS trace: SSL_accept:SSLv3 flush data
connection_read(11): unable to get TLS client DN, error=49 id=1000
connection_get(11): got connid=1000
connection_read(11): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
op tag 0x42, time 1284477158
ber_get_next
TLS trace: SSL3 alert read:warning:close notify
ber_get_next on fd 11 failed errno=0 (Undefined error: 0)
conn=1000 op=1 do_unbind
connection_close: conn=1000 sd=11
TLS trace: SSL3 alert write:warning:close notify
That's all. What's wrong? Where should I look at? What other
information should I post here?
I do not like this string:
"ber_get_next on fd 11 failed errno=0 (Undefined error: 0)"
But I do not know what that mean.
12 years, 8 months
Re: Troubleshoot ACLs
by Torsten Schlabach (Tascel eG)
Hi again!
In the concrete case you explain, maybe the group thing doesn't work as
expected.
Here is our (anonymized) entry for that:
{3}to dn.regex="o=([^,]+),o=planet"
by self write
by group.expand="cn=admins2,o=$1,o=planet" write
by dn.base="cn=admin,o=planet" write
by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write
by * search
What that does is:
In each o=something,o=planet subtree we have a group called
cn=admins2,o=something,o=planet. Each member of that group has write access
to o=something,o=planet.
The lines
by dn.base="cn=admin,o=planet" write
by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write
are needed to make sure that our two superusers cn=admin,o=planet and
uid=someoneelse,ou=user,o=anyorg,o=planet also keep having access.
One nasty thing about how ACLs work is:
As soon as the "to" portion machtes, no further entries are scanned.
So if we would say
{4}to *
by dn.base="cn=admin,o=planet" write
by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write
later, the entry {3} would still result in cn=admin and uid=someoneelse
not having *any* access to o=...,o=planet if they would not be explicitely
mentioned in entry {3}.
This is what many people stumble on.
Regards,
Torsten
On Wed, 15 Sep 2010 14:58:43 +0200, Marcel van Dorp <marcel(a)van-dorp.nl>
wrote:
> Torsten Schlabach (Tascel eG) wrote:
>> Hi Marcel!
>>
>> Your setup is exactly what we also do.
>>
>> My question:
>>
>> What works and what doesn't?
>
> It is quite a lot now, and I did not document properly what did and did
> not work; sorry! I am working with a copy of a real configuration
> (thanks to virtualization!), so basically I can start from scratch with
> the ACLs.
>
>>
>> How do you test it? Manually?
>>
>
> With PHPldapadmin (PLA). I have a linux workplace, with 2 screens
> (X-windows). On each screen I have a browser open. In the left browser I
> log on as cn=admin,cn=config, and there I do the tweaking. On the right
> browser I login as a user. This way the session cookies remain separate,
> and do not conflict with each other (which happens if you use 2 tabs
> within the same browser). I did some (obvious) abbreviation in my
> original post. As a normal user I use something like:
>
> cn=testuser,ou=cust1,ou=customers,ou=people,dc=example,dc=com
>
> In this example I would like to have read rights to anything from:
>
> ou=cust1,ou=customers,ou=people,dc=example,dc=com
>
> this DN included, and all children (my own entry is there as well).
>
> If I am also a member of the group
>
> cn=cust1,ou=groups,dc=example,dc=com
>
> then I would like to have write rights as well in beformentioned parts
> of the directory.
>
> I tried a zillion combinations, but all I get, is access to my own entry
> (in many cases, I can login, but cannot read the directory, not even my
> own entry).
>
>
> When I log in in PLA, I get the two toplevel DNs:
> cn=config
> dc=example,dc=com
>
> Which I cannot expand. Just above this my own DN is displayed, and when
> I click on the left-most field, I get my entry, and I then can expand
> the tree (number of children between parenthesis):
>
> dc=example,dc=com (1)
> ou=people (1)
> ou=customers (1)
> ou=cust1 (1)
> cn=testuser
>
> When I open the parent (ou=cust1), I do not see any content (there is an
> objectclass definition, the ou attribute (obviously) and an extra
> 'description' attribute (for testing only). In my own entry
> (cn=testuser), I can see all attributes.
>
> The debug output says a few things about matching and masking, but it is
> not very clear which ACL-line is processed, and if this is about the
> 'to' or the 'by' part.
>
> Hope this clearifies things a bit. Any suggestions?
>
> Marcel
>
>> Regards,
>> Torsten
>>
>> On Wed, 15 Sep 2010 09:36:38 +0200, Marcel van Dorp
<marcel(a)van-dorp.nl>
>> wrote:
>>> Hi,
>>>
>>> I try to implement certain ACLs, but apparently something goes wrong.
I
>>> read a lot about ACLs, and I do not understand what I do wrong. Maybe
>>> someone on this list can help.
>>>
>>> I use the Debian (lenny) version of openLDAP (version 2.4.11-1), with
>>> phpldapadmin as frontend. I use cn=config
>>>
>>> I try to achieve the following:
>>>
>>> *) No anonymous access
>>> *) Users can change their own attributes/children
>>> *) LDAP managers are listed in a groupOfNames
>>> *) Customers should have READ access to their parent entry, and all
>>> children of their parent (siblings)
>>> *) Specific users below a customer should have WRITE access to their
>>> parent, and all siblings (users are member of a specific groupOfNames)
>>>
>>> I have the following ACLs in olcAccess (sanitized, on multiple lines
for
>>> readability, with group/groupOfNames/member abbt. to g/gON/m below):
>>>
>>> {0}to attrs=userPassword,shadowLastChange
>>> by dn.base="cn=admin,ou=roles,dc=exm,dc=com" write
>>> by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write
>>> by g/gON/m.exact="cn=repl,ou=roles,dc=exm,dc=com" read
>>> by anonymous auth
>>> by self write
>>> by * none
>>>
>>> {1}to dn.base="" by * read
>>>
>>> {2}to dn.regex="ou=([^,]+),ou=cust,ou=people,dc=exm,dc=com"
>>> by dn.exact,expand="cn=[^,]+,ou=$1,ou=cust,ou=people,dc=exm,dc=com"
>> read
>>> by g/gON/m.exact,expand="cn=$1,ou=cust,ou=people,dc=exm,dc=com" write
>>> by * none
>>>
>>> {3}to attrs=mail,entry
>>> by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write
>>> by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write
>>> by self write
>>> by * read
>>>
>>> {4}to *
>>> by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write
>>> by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write
>>> by anonymous search
>>> by self write
>>> by * none
>>>
>>>
>>> Explanation:
>>>
>>> {0} superuser, admins and self can change passwords. Replicators can
>>> read, anonymous can authenticate, and others have no access.
>>>
>>> {1} Is added to get some result, gives read access to the top level of
>>> the directory. It shows 'cn=config', and 'dc=exm,dc=com'
>>>
>>> {2} Is the ACL which I expected to work.
>>> The 'to' clause matches any customer in that branch
>>> The first 'by' matches any member in a group with the same name
>>> The second 'by' matches any entry below this customer
>>> The last 'by' denies other access
>>>
>>> {3} Is there, because the email address is used for login (matching dn
>>> is looked up, and then used to bind. See documentation of
phpldapadmin).
>>>
>>> {4} Is there, so I can actually do something (My dn is in the
mentioned
>>> group)
>>>
>>> I played with a different order and the like, but I do not get what I
>>> want. When I enable logging (olcLogLevel = ACL), I get some info, but
it
>>> is hard to determine where it goes wrong.
>>>
>>> Regarding {2}:
>>> *) I also prepended the 'to' with '.+,' to match everything below, but
>>> to no avail.
>>> *) I also tried the 'by' clauses with 'dn=regex' instead of 'dn.exact'
>>>
>>> Questions:
>>>
>>> 1) What is it I do wrong?
>>> 2) How can I troubleshoot these issues (ACL validator available?)
>>>
>>>
>>> If more info is needed, please let me know.
>>>
>>> Marcel
12 years, 8 months
Changing serverID considered harmful
by Andrew Findlay
This one caused some head-scratching recently so just in case
anyone else comes across it...
I was updating the OpenLDAP installation for a customer, and part
of the work involved converting from a single server to a
mirrormode pair with some read-only slaves. The sequence of events
was:
1) Dump old server to LDIF
2) Update software from 2.3.x to 2.4.23
3) Clear out and reload database from LDIF
4) Many entries added, deleted, modified
5) Second server introduced, mirrormode configured
This involved adding 'serverID 1' to the original server config
and restarting it.
6) Read-only slave configured, pre-loaded from the same LDIF
7) Slave started
The new servers updated using refreshAndPersist mode: they got all
the adds and changes but did not process any of the deletes.
The problem was introduced at stage 5: by changing from serverID
000 to serverID 001 I had broken an assumption in the code. I am
still not clear on exactly what went wrong, as I would expect the
server to simply regard all its current entries to have come from
some other master server. The effect was reproducable though: no
deletes were processed by the consuming server.
The correct thing would be to set the serverID before loading the
initial data, but if that gets missed it seems to be OK to take a
new LDIF dump after changing the ID, and to use that to pre-load
replica servers.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
12 years, 8 months
Re: Troubleshoot ACLs
by Torsten Schlabach (Tascel eG)
On Wed, 15 Sep 2010 14:58:43 +0200, Marcel van Dorp <marcel(a)van-dorp.nl>
wrote:
> When I log in in PLA, I get the two toplevel DNs:
> cn=config
> dc=example,dc=com
>
> Which I cannot expand.
Might you make your life harder than necessary by using PLA?
Could you properly expand dc=example,dc=com when you had the default ACL,
i.e. before you did any changes?
> Hope this clearifies things a bit. Any suggestions?
Take a look at
http://linux.die.net/man/8/slapacl
It may be a bit of a learning curve initially, but this will enable you to
write yourself some scripts which will iterate over a set of entries and
check you permissions. So you can easily make changes and see if they do
what you think you want to do.
Regards,
Torsten
P.S.: Double-check to reply to the list. ;-)
12 years, 8 months
syncrepl: contextCSN less than entryCSN
by Ioan Indreias
Hello,
We are running openldap 2.4.21 configured as a consumer, using a
refreshAndPersist replication:
syncrepl rid=202
provider=ldaps://ldap.hashed.net
type=refreshAndPersist
interval=00:00:05:00
retry="10 3 60 +"
searchbase="ou=emailservice,o=hashed"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=ldap-hashed-service,o=hashed"
credentials=xx-xx-xx
tls_reqcert=never
In order to check if the replication works OK we compare
(periodically) the provider's contextCSN versus the consumer's
contextCSN
Most of the time both are in sync but from time to time we see that
these parameters are different (provider contextCSN > consumer
contextCSN) and we thought that the consumer was not "in sync" with
the provider.
Continuing our investigations we found that in the consumer there are
objects with entryCSN greater than the consumer contextCSN.
Is this a normal situation or a bug?
Bellow you could find an extract from the ldapsearch we ran on the
consumer side.
Best regards,
Ioan Indreias
###
Provider SID: 001
Local SID: 015
test199.entryCSN (20100910085049.959625)
less than
001.contextCSN (20100910085055.650259)
less than
johndoe.entryCSN (20100910092955.693053)
--- CONSUMER ---
# extended LDIF
#
# LDAPv3
# base <o=hashed> with scope subtree
# filter: (objectclass=*)
# requesting: +
#
# hashed
dn: o=hashed
structuralObjectClass: organization
entryUUID: 541ccdcb-8d82-4160-9fc7-1892765cbdac
creatorsName: cn=superuser,o=hashed
createTimestamp: 20100714124242Z
entryCSN: 20100714124242.721169Z#000000#015#000000
modifiersName: cn=superuser,o=hashed
modifyTimestamp: 20100714124242Z
contextCSN: 20100909124709.457916Z#000000#015#000000
contextCSN: 20100910085055.650259Z#000000#001#000000
entryDN: o=hashed
subschemaSubentry: cn=Subschema
auditContext: cn=auditlog
# emailservice, hashed
dn: ou=emailservice,o=hashed
structuralObjectClass: organizationalUnit
entryUUID: b8950978-248b-4b77-bcf9-6455f9c273c0
creatorsName: cn=superuser,o=hashed
createTimestamp: 20100714124242Z
modifiersName: cn=superuser,o=hashed
modifyTimestamp: 20100714124242Z
entryCSN: 20100730103008.669976Z#000000#001#000000
entryDN: ou=emailservice,o=hashed
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
# org, emailservice, hashed
dn: dc=org,ou=emailservice,o=hashed
structuralObjectClass: domain
entryUUID: 32e805e8-669c-471e-b9d3-1d22938bdce3
creatorsName: cn=superuser,o=hashed
createTimestamp: 20100714124242Z
modifiersName: cn=superuser,o=hashed
modifyTimestamp: 20100714124242Z
entryCSN: 20100730103013.472630Z#000000#001#000000
entryDN: dc=org,ou=emailservice,o=hashed
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
# hashed, org, emailservice, hashed
dn: dc=hashed,dc=org,ou=emailservice,o=hashed
structuralObjectClass: domain
entryUUID: 3bd366ba-5213-4bf2-8935-3ddbb26bf220
creatorsName: cn=superuser,o=hashed
createTimestamp: 20100714124242Z
modifiersName: cn=superuser,o=hashed
modifyTimestamp: 20100714124242Z
entryCSN: 20100730103018.690150Z#000000#001#000000
entryDN: dc=hashed,dc=org,ou=emailservice,o=hashed
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
# users, hashed, org, emailservice, hashed
dn: ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed
structuralObjectClass: organizationalUnit
entryUUID: 87390f34-5698-4653-a700-5045843813db
creatorsName: cn=superuser,o=hashed
createTimestamp: 20100714124242Z
modifiersName: cn=superuser,o=hashed
modifyTimestamp: 20100714124242Z
entryCSN: 20100802144805.677791Z#000000#001#000000
entryDN: ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
...
# test199, users, hashed, org, emailservice, hashed
dn: uid=test199,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed
structuralObjectClass: inetOrgPerson
entryCSN: 20100910085049.959625Z#000000#001#000000
entryUUID: 416a2a78-5104-102f-8592-6d824ed7581a
creatorsName: cn=superuser,o=hashed
createTimestamp: 20100910085049Z
modifiersName: cn=superuser,o=hashed
modifyTimestamp: 20100910085049Z
entryDN: uid=test199,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
# johndoe, users, hashed, org, emailservice, hashed
dn: uid=johndoe,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed
structuralObjectClass: inetOrgPerson
entryCSN: 20100910092955.693053Z#000000#001#000000
entryUUID: b794ae8a-5109-102f-8593-6d824ed7581a
creatorsName: cn=superuser,o=hashed
createTimestamp: 20100910092955Z
modifiersName: cn=superuser,o=hashed
modifyTimestamp: 20100910092955Z
entryDN: uid=johndoe,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
# search result
search: 2
result: 0 Success
# numResponses: 197
# numEntries: 196
###
12 years, 8 months
Troubleshoot ACLs
by Marcel van Dorp
Hi,
I try to implement certain ACLs, but apparently something goes wrong. I
read a lot about ACLs, and I do not understand what I do wrong. Maybe
someone on this list can help.
I use the Debian (lenny) version of openLDAP (version 2.4.11-1), with
phpldapadmin as frontend. I use cn=config
I try to achieve the following:
*) No anonymous access
*) Users can change their own attributes/children
*) LDAP managers are listed in a groupOfNames
*) Customers should have READ access to their parent entry, and all
children of their parent (siblings)
*) Specific users below a customer should have WRITE access to their
parent, and all siblings (users are member of a specific groupOfNames)
I have the following ACLs in olcAccess (sanitized, on multiple lines for
readability, with group/groupOfNames/member abbt. to g/gON/m below):
{0}to attrs=userPassword,shadowLastChange
by dn.base="cn=admin,ou=roles,dc=exm,dc=com" write
by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write
by g/gON/m.exact="cn=repl,ou=roles,dc=exm,dc=com" read
by anonymous auth
by self write
by * none
{1}to dn.base="" by * read
{2}to dn.regex="ou=([^,]+),ou=cust,ou=people,dc=exm,dc=com"
by dn.exact,expand="cn=[^,]+,ou=$1,ou=cust,ou=people,dc=exm,dc=com" read
by g/gON/m.exact,expand="cn=$1,ou=cust,ou=people,dc=exm,dc=com" write
by * none
{3}to attrs=mail,entry
by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write
by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write
by self write
by * read
{4}to *
by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write
by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write
by anonymous search
by self write
by * none
Explanation:
{0} superuser, admins and self can change passwords. Replicators can
read, anonymous can authenticate, and others have no access.
{1} Is added to get some result, gives read access to the top level of
the directory. It shows 'cn=config', and 'dc=exm,dc=com'
{2} Is the ACL which I expected to work.
The 'to' clause matches any customer in that branch
The first 'by' matches any member in a group with the same name
The second 'by' matches any entry below this customer
The last 'by' denies other access
{3} Is there, because the email address is used for login (matching dn
is looked up, and then used to bind. See documentation of phpldapadmin).
{4} Is there, so I can actually do something (My dn is in the mentioned
group)
I played with a different order and the like, but I do not get what I
want. When I enable logging (olcLogLevel = ACL), I get some info, but it
is hard to determine where it goes wrong.
Regarding {2}:
*) I also prepended the 'to' with '.+,' to match everything below, but
to no avail.
*) I also tried the 'by' clauses with 'dn=regex' instead of 'dn.exact'
Questions:
1) What is it I do wrong?
2) How can I troubleshoot these issues (ACL validator available?)
If more info is needed, please let me know.
Marcel
12 years, 8 months
ldapcompare on rootDSE attribute types
by Dieter Kluenter
Hello,
what would be the correct DN for a compare on rootDSE? Although the
examples of the manual page seem to be quite specific, none of the
following seem to be correct:
:~> ldapcompare -x -Z -H ldap://localhost:9004 "" supportedControl:1.3.6.1.4.1.42.2.27.8.5.1
Compare Result: Inappropriate matching (18)
Additional info: inappropriate matching request
UNDEFINED
:~> ldapcompare -x -Z -H ldap://localhost:9004 dn: supportedControl:1.3.6.1.4.1.42.2.27.8.5.1
Compare Result: Invalid DN syntax (34)
Additional info: invalid DN
UNDEFINED
-Dieter
--
Dieter Klünter | Systemberatung
sip: 7770535(a)sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
12 years, 8 months
