On 2 May 2019, at 21:28, Angel Bosch Mora
<abosch(a)imasmallorca.net> wrote:
> If you have a specific question though, I’d be happy to help!
>
I'm glad you offered :)
these are the attributes I'm currently using:
cn:
description:
displayName::
dn:
employeeNumber:
gecos:
gidNumber:
homeDirectory:
loginShell:
mail:
manager:
member:
memberOf:
objectClass:
petraSshPublicKey:
printer-make-and-model:
printer-more-info:
printer-uri:
sambaAcctFlags:
sambaNTPassword:
sambaPasswordHistory:
sambaPwdLastSet:
sambaSID:
shadowInactive:
shadowLastChange:
shadowMax:
shadowWarning:
sn:
uid:
uidNumber:
I want to change ACIs from old behaviour to white list aproach.
Should I include objectClass in the ACIs?
Generally I’d say you only need objectClass in aci’s where you have modification rights
occuring to ensure that the bounds of the modification are constrained.
If you are only adding ACI for read, then you can just have targetAttr for the attributes
required.
The best way to think of this is “what groups or roles need access to read what
attributes”.
So I’d write out something like:
everyone read -> a1, a2, a3 ….
admins read -> ….
Then I’d translate these to the read-aci’s you require
Do I need to create a deny-all as last ACI so everything that is not allowed gets denied?
No, 389 defaults to deny, so anything “not list” will be disallowed.
In your blog you talk about a toolset to test ACIs, is that tool published somewhere?
Sadly not - some parts of it have become part of lib389 in the healthcheck module to find
targetAttr != rules, but the actual testing of “do these aci’s match expectations”, was
part of a previous work place, and I no longer have access.
Again, you can translate the above to something:
You would basically say “for each object in the directory”.
if that object is in:
everyone -> expect read on a1, a2 ….
admins -> expect read on a3, a4 ….
Then I’d do the permission check (there is a 389 specific ldap extended op) that tells you
what rights you have other entries. I’d assert the expect matches each check, and
continue.
It was pretty overkill and kind of brute-force solution, but it is what lead to the
discovery of the aci issues with targetAttr != - I’d say if you don’t use targetAttr !=
you probably are already in a really good position to audit and understand the
interactions with your directory, so you may not need the tool at all.
Hope this helps :)
best regards,
abosch
-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer
annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir
informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a
terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que
s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu
immediatament a l'adreca electronica de la persona remitent.
-- Abans d'imprimir aquest missatge, pensau si es realment necessari.
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs