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@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
