Patrick, I have no experience using the admin console for access control or your particular problem but I can share what we did that I think accomplishes your goal as we similarly decided to block anonymous access. To oversimplify we modified the stock acis with an explicit list of what users could see/do to themselves and defined a series of groups that could read/write to various attributes. Here’s a stripped down example. I’m happy to discuss further or share more details if this doesn’t make sense. Disclaimer: we developed this years ago on a much older version of centos (redhat) directory but I imagine it will work in the latest 389. We’re working on upgrading now. dn: dc=domain,dc=org changetype: modify replace: aci # aci: (target = "ldap:///ou=employees,dc=domain,dc=org";) (targetattr = "userpassword") (version 3.0; acl "limited user self write"; allow (write) userdn = "ldap:///self";;) # aci: (target = "ldap:///dc=domain,dc=org"; ) (targetattr = “attr1 || attr2”) (version 3.0; acl "self read"; allow (read, search, compare) (userdn = "ldap:///self";) ;) # aci: (target = "ldap:///dc=domain,dc=org"; ) (targetfilter = "(|(objectclass=objectclass1)(objectclass=objectclass2)(objectclass=domain) (objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames))") (targetattr = “attr1 || attr2 || attr3") (version 3.0; acl "general access, replaces anonymous access"; allow (read, search, compare) (userdn = "ldap:///self";) or (groupdn = "ldap:///cn=group1,ou=groups,dc=domain,dc=org";) or (groupdn = "ldap:///cn=group2,ou=groups,dc=domain,dc=org";) ;) -morgan > On Sep 7, 2017, at 8:55 PM, William Brown <wibrown@xxxxxxxxxx> wrote: > > On Thu, 2017-09-07 at 11:28 -0500, Patrick Landry wrote: >> OK. I guess no one has run into this one. >> >> Can anyone tell me what the impact of the admin server not being able to search the specified DIT is? >> Is this something to worry about or something which can be ignored? >> >> [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952] populate_tasks_from_server(): Unable to search [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636] >> > > I would think that you just can't edit entries in that DIT if you can't > access it. > > TBH I would advise against using the admin server anyway, but that's > just me. > > >> ----- Original Message ----- >> >>> From: "Patrick Landry" <patrick.landry@xxxxxxxxxxxxx> >>> To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> Sent: Saturday, September 2, 2017 4:40:27 PM >>> Subject: [389-users] Error after setting >>> nsslapd-allow-anonymous-access:rootdse >> >>> This is a fresh install on RHEL 7. >> >>> 389-adminutil-1.1.21-2.el7.x86_64 >>> 389-admin-console-doc-1.1.12-1.el7.noarch >>> 389-admin-console-1.1.12-1.el7.noarch >>> 389-ds-base-libs-1.3.6.1-16.el7.x86_64 >>> 389-ds-console-1.2.16-1.el7.noarch >>> 389-ds-1.2.2-6.el7.noarch >>> 389-ds-base-1.3.6.1-16.el7.x86_64 >>> 389-ds-console-doc-1.2.16-1.el7.noarch >>> 389-admin-1.1.46-1.el7.x86_64 >>> 389-console-1.1.18-1.el7.noarch >>> 389-dsgw-1.1.11-5.el7.x86_64 >> >>> Installation went fine and I was able to secure the directory server and >>> admin server with certificates and restrict access to secure connections >>> only. >> >>> But after I changed nsslapd-allow-anonymous-access:rootdse to prevent >>> anonymous binds the admin server now complains at startup: >> >>> [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952] >>> populate_tasks_from_server(): Unable to search >>> [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server >>> Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636] >> >>> I am still able to use the console and the error doesn't seem to affect >>> operation. >> >>> If I set nsslapd-allow-anonymous-access:on the error goes away. >> >>> If I set nsslapd-allow-anonymous-access:off I get additional errors (which >>> would be expected): >> >>> [Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid 139706415569024] >>> Could not bind as []: ldap error 48: Inappropriate authentication >>> [Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024] >>> Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache. >> >>> I did find an old issue in Pagure >> >>> https://pagure.io/389-ds-base/issue/47850 >> >>> which was for a different issue related to setting >>> nsslapd-allow-anonymous-access:rootdse >>> In that issue Mark mentions adding a separate user entry to be used to search >>> o=netscaperoot >>> but I can't find any other references to this solution (and don't know if it >>> would solve this issue). >> >>> -- >> >>> >> >>> Patrick Landry >>> Director, UCSS >>> University of Louisiana at Lafayette >>> pml@xxxxxxxxxxxxx >> >>> _______________________________________________ >>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >> >> _______________________________________________ >> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
