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 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
