On Sat, 2015-11-21 at 14:07 -0800, Joel Levin wrote: > Hi All: > > 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 [0]. 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 [1] * 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, Sincerely, William [0] http://firstyear.id.au/entry/23 [1] https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/h tml/Administration_Guide/Viewing_the_ACIs_for_an_Entry -Get_Effective_Rights_Control.html
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
