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 _______________________________________________ 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/message/B3L6D5DJJVPVKFJO2A5N7MBVRDL6Q7Y4/
