One small correction here :
using newly created nsUserAccountRole and nsUserAccountRoles (
Will be used only to create filter role ) , i am creating filter roles
only . This is the confusion here , we should remember filter roles are
nothing but entries with o='something'. I am not touching any user here ,
but i am creating roles and these roles are covering the users
automatically a Ludwig Krispenzs said earlier. example-
In above example just created one filer role which will cover all users having 'cn=*' in 'ou=People'. Here 'cn=tuser1,ou=People,dc=example,dc=com' is nothing but a filter role which will cover all users having 'cn=*' in 'ou=People'.
Another example as given bellow:
dn: cn=FILTERROLEENGROLE,o=acivattr1,dc=example,dc=com
cn: FILTERROLEENGROLE
nsRoleFilter: cn=*
objectClass: top
objectClass: LDAPsubentry
objectClass: nsRoleDefinition
objectClass: nsComplexRoleDefinition
objectClass: nsFilteredRoleDefinition
This above entry is nothing but filter role entry , which will cover all users in 'o=acivattr1' which has sub entries that begins with 'cn'. And this is the property of filter role .
Yes , i must say that newly created nsUserAccountRole and nsUserAccountRoles which i renamed to nsFilterAccountRole and nsFilterAccountRoles will only cover filter role as you cant create Filter role and other roles like Manage role all together . For my porting stuff newly created nsFilterAccountRole and nsFilterAccountRoles is more than enough because i need filter roles only .
Hope it clears all of your doubts.
Regards
Anuj Borah
> On 17 Jan 2019, at 19:40, Ludwig Krispenz <lkrispen@xxxxxxxxxx> wrote:
>
>
> Maybe I do not understand how it works because of some lib389 magic, but I think this is not how roles work.
>
> You are creating cn=tuser1 and cn=Anju and they will have the role objectclasses, but the benefit of roles is that you do NOT have to touch the useres to assign roles to them. There is a class of users and a class of role definitions and ONLY the change in the role definition will determine if a user has a role or not.
I think lib389 probably isn’t helping, but Ludwig’s description here is correct.
Maybe a good approach is to “setup” roles by hand, then once you have a process in mind, then you can make the lib389 parts? I generally approach things this way to understand them well.
Would that help?
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-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-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-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-devel@xxxxxxxxxxxxxxxxxxxxxxx
