openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

accesslog anomaly in drop/re-import (was Searched Attr=1.1)
by Marco Pizzoli 17 Sep '10

17 Sep '10

I re-post this help request using a more appropriate subject . Thanks in advance Marco ---------- Forwarded message ---------- From: Marco Pizzoli <marco.pizzoli(a)gmail.com> Date: Thu, Sep 16, 2010 at 1:07 PM Subject: Re: Searched Attr=1.1 To: Dieter Kluenter <dieter(a)dkluenter.de> Cc: openldap-technical(a)openldap.org Hi Dieter, thanks for your answer. I came to this evidence in investigating an anomaly that I'm having with my accesslog database. Symptom I was having was continuous high cpu spot. I suspected it was due to my accesslog database. - I made a slapcat of my entire log database. - I erased my log database - I tried a slapadd of my log database I had this problem: /usr/sbin/slapadd -b "cn=log,dc=mycorp.it" -l /srv/bck/dump_db_log.ldif.20100916 . 0.00% eta 08h35m elapsed spd 90.2 k/s str2entry: invalid value for attributeType reqControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=4907) - 0.01% eta 05h58m elapsed spd 205.7 k/s Closing DB... I went to that line and found this entry: dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20100913065628.000008Z reqEnd: 20100913065628.000009Z reqType: search reqSession: 1129 reqAuthzID: cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc= mycorp.it reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue "30440K0103043M7269643N 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 330303030303023303033233030303030300001PP"} reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} reqDN: dc=mycorp.it reqResult: 0 reqScope: base reqDerefAliases: never reqAttrsOnly: TRUE reqFilter: (objectclass=*) reqAttr: 1.1 reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: 1 entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913065628Z entryCSN: 20100913065628.167225Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913065628Z Can someone tell me why this entry result not accepted to my openldap system? I'm using OL 2.4.23 with password policy overlay defined. The entry I posted is related to an access made by a specific syncrepl-user. Replica configured in mirror-mode. Other OL systems are 2.4.22. Deleting this entry and re-slapadding I had another similar problem. /usr/sbin/slapadd2.4 -b "cn=log,dc=mycorp.it" -l /tmp/dump_db_log.ldif.20100916_Corrected " 4.69% eta 01h07m elapsed 03m19s spd 542.3 k/s str2entry: invalid value for attributeType reqRespControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=3099715) * 4.70% eta 01h07m elapsed 03m20s spd 979.8 k/s Closing DB... The entry affected is this one: dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it objectClass: auditBind structuralObjectClass: auditBind reqStart: 20100913093021.000000Z reqEnd: 20100913093021.000001Z reqType: bind reqSession: 2746 reqAuthzID: reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} reqDN: uid=pe1597,ou=People,dc=mycorp.it reqResult: 0 reqVersion: 3 reqMethod: SIMPLE entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913093021Z entryCSN: 20100913093021.411398Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913093021Z Any help is appreciated. Thanks Marco On Thu, Sep 16, 2010 at 12:27 PM, Dieter Kluenter <dieter(a)dkluenter.de>wrote: > Marco Pizzoli <marco.pizzoli(a)gmail.com> writes: > > > Hi list, > > I found some entries in my OL logs about searches for attribute "1.1". > I've > > seen that the requester is the user used for the replication (syncrepl). > > > > Can anyone explain to me what this kind of attribute is this? > > > > conn=0 op=3 SRCH attr=1.1 > > oid 1.1 is just 'no attributes' > > -Dieter > > -- > Dieter Klünter | Systemberatung > sip: 7770535(a)sipgate.de > http://www.dpunkt.de/buecher/2104.html > GPG Key ID:8EF7B6C6 > -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

1 0

Re: How to bootstrap in mirror mode with cn=config
by Torsten Schlabach (Tascel eG) 17 Sep '10

17 Sep '10

Hi Brett! I see your point, and actually, this is what we are doing anyway. But I could ask my question in a different way as well: How would I turn a single server in to a mirror mode pair? > restoring > a server2 backup avoids problems with serverId etc. You know, I am asking because I want to understand those problems. Regards, Torsten P.S.: The list doesn't have the reply-tp header properly set. Make sure manually to reply tot he list. On Thu, 16 Sep 2010 19:52:01 +1000, "Brett @Google" <brett.maxfield(a)gmail.com> wrote: > I'd suggest a less complex approach. > > Restore server2 from backup, but make sure you emit a backup ldif > somewhere on a backed up filesystem daily or whatever. > > After restoring your server 2 ldif, you will be configured, and will > recover data quicker if you have some relatively static data sets. > > Building a replica with syncrepl can be slower than slapcat, restoring > a server2 backup avoids problems with serverId etc., even with newer > openldap versions. > > > On 9/16/10, Torsten Schlabach (Tascel eG) <tschlabach(a)tascel.net> wrote: >> 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 >> >>

2 1

Attribute modification via alias
by Echedey Lorenzo 16 Sep '10

16 Sep '10

Hi, I wonder if it is possible to modify an attribute parsing to the request a dn which has an alias to the real entry where the attribute is placed. Thanks for your help -- -------------------------------------------- | Echedey Lorenzo Arencibia | --------------------------------------------

1 0

invalid syntax on pwdPolicy object add
by Julien Vehent 16 Sep '10

16 Sep '10

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

5 9

Re: Authenticate to ldap using Kerberos
by Dan White 16 Sep '10

16 Sep '10

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

8 33

How to bootstrap in mirror mode with cn=config
by Torsten Schlabach (Tascel eG) 16 Sep '10

16 Sep '10

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

1 0

Can't get TLS working.
by c0re 16 Sep '10

16 Sep '10

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.

4 16

Re: Troubleshoot ACLs
by Torsten Schlabach (Tascel eG) 15 Sep '10

15 Sep '10

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

2 1

Changing serverID considered harmful
by Andrew Findlay 15 Sep '10

15 Sep '10

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 | -----------------------------------------------------------------------

2 2

Re: Troubleshoot ACLs
by Torsten Schlabach (Tascel eG) 15 Sep '10

15 Sep '10

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. ;-)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical