Thanks Morgan. I will take a look at those ACIs.
From: "Morgan Jones" <morgan@xxxxxxxxxxxxxxx>
To: "General discussion list for the 389 Directory server project." <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, September 15, 2017 3:11:02 PM
Subject: [389-users] Re: Error after setting nsslapd-allow-anonymous-access:rootdse
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
--
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
