On Wed, 2018-01-10 at 10:21 -0500, Mark Reynolds wrote:
On 01/09/2018 07:25 PM, William Brown wrote:
> Hi all,
>
> It's time that I'm looking at:
>
https://pagure.io/389-ds-base/issue/49425
+1 for 1.4.0!
Thank you! I'm glad you like this. I'm writing them up now (with test
cases to assert the aci's work as intended!) :)
>
> 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
>
>
> 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,
>
>
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane