> 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. 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
