> On 2 May 2019, at 21:28, Angel Bosch Mora <abosch@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
