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