On Sat, 2015-11-21 at 14:07 -0800, Joel Levin wrote:
We have a fairly newly installed 389 running ---- although early days, the
ACI is getting cumbersome to manage/audit.
Would anyone know of strategy articles to manage ACIs?
I wrote a blog post a while ago detailing some mistakes my old workplace made
with ACI's on 389 .
My advice is:
* Ditch all of the ACI's shipped with 389-ds, start from nothing.
* ONLY use allow aci's, NEVER use deny.
* ONLY use target[attr,ip, etc] = foo. Never use !=, as you can VERY EASILY
create issues as detailed in that blog.
* Use the effective rights helper to test these 
* Test all the time. Make some test routines / scripts to help. py.test is good.
* Keep it as simple as possible.
Some looser advice that you may decide to change on preference:
* Keep your ACI's on the root of the tree. I find it easier to have all the
aci's in one place, and to use the targeting mechanism in the ACI to specify
subtrees. This means you don't need to hunt around for ACI's in your tree to
work out what is doing what where.
* Read and understand your schema and what elements you are giving access to.
Give only what's needed to function.
* Be careful with system attributes (ns*). Most of these should be hidden, or at
least non-writeable with the exception of nsUniqueID. nsUniqueId is really
useful to have accesible on all objects.
* Make sure if you are using sssd to update the password policy setting and some
others. I add these:
ldap_user_uuid = nsUniqueId
ldap_group_uuid = nsUniqueId
# This is really important as it allows SSSD to respect nsAccountLock
ldap_account_expire_policy = rhds
ldap_access_order = filter, expire
With this, make sure that sssd's bind user (Be it anonymous or other) can read
nsAccountLock too (it's pretty safe to have this readable). This will make sure
that your sssd instance respects your password and lockout policy, EVEN if the
user account is using ssh keys. If you have ssh keys and don't set this
configuration option, a user who is locked, can still use ssh keys to login,
because the sssd auth filter is still valid.
In the future I have developed a tool as per my blog that will automatically
find aci's and test them for correctness, but it does need some human hand
holding and interaction. It pretty much allows you to test the interactions of a
set of ACI's is what you expect, rather than just that each ACI in isolation is
correct. But it may be months before you see it.
I hope that this advice helps you,