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-
role=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
role.create(properties=user_props, basedn=SUFFIX)
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 Fri, Jan 18, 2019 at 4:24 AM William Brown <wbr...@suse.de> wrote:
>
>
> > On 17 Jan 2019, at 19:40, Ludwig Krispenz <lkris...@redhat.com> 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@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-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-devel@lists.fedoraproject.org
>
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-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-devel@lists.fedoraproject.org
