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(a)redhat.com>
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(a)louisiana.edu>
>> To: 389-users(a)lists.fedoraproject.org
>> 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(a)louisiana.edu
>
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org