On Thu, 2018-01-11 at 16:40 +0000, Brian (bex) Exelbierd wrote:
> Hi all,
>
> It's time that I'm looking at:
>
https://pagure.io/389-ds-base/issue/49425
>
> There are some great reasons to freshen up the default objects we
> install. The current design isn't really reflective of modern
> directory
> usage, the aci's are not "great" examples, and it's not a super-
> useful
> foundation out of the box.
>
> As a result, I have some improvements I want to make here. Let's
> start
> with the simple ones:
>
> Tree layout:
>
> dc=example,dc=com
> cn=389_ds_system,dc=example,dc=com
> ou=people,dc=example,dc=com
> ou=groups,dc=example,dc=com
> ou=services,dc=example,dc=com
> ou=permissions,dc=example,dc=com
>
> This is the structure I want us to ship with: groups, people,
> service
> accounts, and permission groups. I additionally add an
> nscontainer|ldapsubentry 389_ds_system, which is the "hidden"
> config
> area that we could start to use for things like pwpolicy, keepalive
> entries, replication service accounts and more. I don't think
> anything
> here is too controversial :)
>
> Next, demo objects!
>
> uid=demo_user,ou=people,dc=example,dc=com
> cn=demo_group,ou=groups,dc=example,dc=com
>
> These can show a user and group, and lets the cli tools have
> something
> to show, and how they can be integrated with *acis*.
>
> Again, nothing complex :)
>
> Permissions! This is where we start to add aci's and get's a bit
> fun.
>
> I want to ship with a few useful permisisons and acis. The thinking
> is:
>
> * anonymous read to public ou=People and user attributes (ie Sssd
> should work oob)
> * anonymous read to groups attributes (ie Sssd should work oob)
> * a permission group where members can alter group members
> * a permission group where members can alter users
> * a permission group where members can reset user passwords
> * a permission group where members can create/delete users
> * a permission group where members can create/delete groups
>
> This is a pretty simple set of acis, but I want them to show how
> delegation of permissions can be done safely, and act as examples
> and
> templates for admins - as well as just being simple and useful for
> small deployments out of the box!
>
>
> Now, this is the final suggestion: I'd like to add some extra
> schema
> and change user objects by default that we create.
>
> I would like to add:
>
> nsPerson
>
> I would like them to contain the following:
>
> nsPerson:
> MAY: userPassword, telephoneNumber, seeAlso, description, legalName
> MUST: cn, displayName
I am also very in favor of this change. I'd love to see this highly
advertised once it merges as I think it speaks very highly of how to
both be inclusive and move great software forward while continuing to
be extremely useful to users.
Thank you that's great to hear! I've just pushed the patch up now for
our 1.4.0 server support this. :)
regards,
bex
>
>
> This is a shift from the traditional person object and there is a
> really good reason -
> internationalisation. (we replace sn with legalName and make it
> may,
> and add
> displayName).
>
>
> The current person account *requires* the sn field. However surname
> *does not*
> translate across many cultural boundaries. Some people have
> multiple
> surnames, some
> have no concept of a surname.
>
> What people do have is a *legal name* which is their full name -
> for me
> that would be
> givennames + surname. For others just their single name. having a
> single legalName
> field correctly represents this case. And additionally many
> applications don't
> even need a legal name, *only* a displayName of the users choice.
>
> The second reason is identity related. There are many people whos
> chosen name
> for the world (displayName) differs from their actual legal name.
> As a
> result
> having a displayname field where the user can *choose* how they are
> represented
> is highly important. Consider divorced people (who haven't yet
> changed
> legal names)
> victims of crime (who need to hide their identity) and more.
>
> I think our current schema doesn't current reflect the "best" in
> identity management
> and by adding nsPerson like this, we can really do the right thing
> here, by
> default.
>
> *obivously* this is a new schema, not changing existing items, so
> existing deployments
> will keep using whatever they want (person etc) - more that new
> deployments will
> see a modern, best practice that they can follow,
>
>
> I'd like to get feedback on this soon, as I'd like to have this in
> the
> cli
> tool demo I want to release soon.
>
> Thanks everyone,
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.o
rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane