[389-devel] Please review: purge sasl maps before gssapi test
https://pagure.io/389-ds-base/issue/49474 https://pagure.io/389-ds-base/issue/raw/files/e6743de00abbe45f0d776fd62 6db5544b8154575ddd506d183f7e215ea09e6bc-0001-Ticket-49474-purge- saslmaps-before-gssapi-test.patch -- 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
[389-devel] Re: Do aci's work in nested groups?
On Wed, 2018-01-10 at 10:44 +0100, Ludwig Krispenz wrote: > On 01/10/2018 07:03 AM, William Brown wrote: > > If I have: > > > > (targetattr=x)(version 3.0; allow(read, > > search)(groupdn=cn=x);) > > > > If cn=x has member cn=y, and cn=y member uid=z > > > > Does uid=z have permission to the targetattr here? IE do our aci's > > work > > through nested groups? > > yes, they should, but there is configurable max nesting level Great! Thanks for clarifying this :) Perhaps something we could look at is aci's resolving membership of an entry via it's memberOf attributes if memberOf is enabled? That would allow quicker resolution of nested groups I would think > > > > > > -- > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael > O'Neill, Eric Shander > ___ > 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
[389-devel] Re: Improve the demo objects from install
On Wed, 2018-01-10 at 12:17 -0500, Máirín Duffy wrote: > > On 01/10/2018 10:58 AM, Mark Reynolds wrote: > > So you could do a filter like this for your example above: > > > > "(|(sn=*brown")(sn=*brown west"))" > > So the case I'm thinking of for the front end is a directory listing, > in > which case you wouldn't be so specific to know to add the West. > > > > or > > > > "(|(sn=* brown")(sn=* brown *"))" --> note the spaces > > This would grab anything inbetween though right? So it would grab > Brown > as a middle name too. There's no way to specify order positioning > beyond > first * / * last / * anything in middle * ? Eg no regexp? > > The context I'm in here is a front end developer trying to get the > data > in a format so they can provide a list of users in a list interface > and > have a reasonable way to sort without having to rely on just using > the > first substring. So these are all great points Mairin, but they still exclude: Singlename Lastname1 lastname2 Imagine if you last names were say alice bob. But you wanted to be found under "alice bob". Today, you would not, you would be found under "bob". Not what we want at all! And our singlename friend would not even be allowed to exist at all (do you make their givenname the surname? That's not right either ...). This is just disrespectful to both of these individuals :( Your "frontend" with it's "western" style of "lastname, othernames" can not accommodate these people :( We have the ability to order by displayName, and the ability to search on any substring of the name so you can find your identity efficiently. As a result, sort by displayname and searching is really the best way to get access to this, even if not perfect, because we allow people to express their name and identity in a way that is meaningful to them :) People will quickly see that it's ordered by "displayname" and they'll search anyway (if that wasn't their default reaction, most people's last name are not "aa" ... ). Too many "brown"s? Just search "william brown". Or even just " brown"? uid can be searched too, so if I know there are 300 "william browns", I can always look for "wibrown" or "firstyear". There are so many options here :) And that's also kind of the point of this change, to highlight how we think about names in such a limited manner, how we are constraining ourselves to this single (often American) centric world view. For years in open source we have had "handles" instead (for example, firstyear for me). We have no issue just "sorting by handle" and "letting people choose their handle" etc. We have all this software that works "just fine" in this environment, so I think people will cope if we just sort by "displayName" :) > > ~m > ___ > 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
[389-devel] Re: Improve the demo objects from install
On 01/10/2018 12:17 PM, Máirín Duffy wrote: > > > On 01/10/2018 10:58 AM, Mark Reynolds wrote: >> So you could do a filter like this for your example above: >> >> "(|(sn=*brown")(sn=*brown west"))" > > So the case I'm thinking of for the front end is a directory listing, > in which case you wouldn't be so specific to know to add the West. >> >> or >> >> "(|(sn=* brown")(sn=* brown *"))" --> note the spaces > > This would grab anything inbetween though right? So it would grab > Brown as a middle name too. Correct. > There's no way to specify order positioning beyond first * / * last / > * anything in middle * ? Eg no regexp? No, sorry. > > The context I'm in here is a front end developer trying to get the > data in a format so they can provide a list of users in a list > interface and have a reasonable way to sort without having to rely on > just using the first substring. > > ~m ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Improve the demo objects from install
On 01/10/2018 10:58 AM, Mark Reynolds wrote: So you could do a filter like this for your example above: "(|(sn=*brown")(sn=*brown west"))" So the case I'm thinking of for the front end is a directory listing, in which case you wouldn't be so specific to know to add the West. or "(|(sn=* brown")(sn=* brown *"))" --> note the spaces This would grab anything inbetween though right? So it would grab Brown as a middle name too. There's no way to specify order positioning beyond first * / * last / * anything in middle * ? Eg no regexp? The context I'm in here is a front end developer trying to get the data in a format so they can provide a list of users in a list interface and have a reasonable way to sort without having to rely on just using the first substring. ~m ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Improve the demo objects from install
On 01/10/2018 10:53 AM, Máirín Duffy wrote: > > > On 01/10/2018 10:20 AM, Mark Reynolds wrote: >>> Would this miss someone who had two surnames, say Sally Brown West, >>> who chooses not to hyphenate? >> "(sn=*brown*)" > > Wouldn't that also match Brownwyn James and Brown West Smith? Yes it would, but there are endless options here. I was just trying to show some of the things you can do with substring filters. So you could do a filter like this for your example above: "(|(sn=*brown")(sn=*brown west"))" or "(|(sn=* brown")(sn=* brown *"))" --> note the spaces Mark > > ~m ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Improve the demo objects from install
On 01/10/2018 10:20 AM, Mark Reynolds wrote: Would this miss someone who had two surnames, say Sally Brown West, who chooses not to hyphenate? "(sn=*brown*)" Wouldn't that also match Brownwyn James and Brown West Smith? ~m ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Improve the demo objects from install
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! > > 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, > > ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Improve the demo objects from install
On 01/10/2018 10:08 AM, Máirín Duffy wrote: > Hi William, > >> With displayname you can only sort by "order of the displaynames". >> So we can at least consistently sort this given the scenario above! > > Imagine a phone book sorted this way. In the US in any given town > there would be 50 pages of Johns, making wayfinding really difficult. > Is there a way for an application that's using LDAP in the backend to > pull the last substring, for example, if they wanted to use the > heuristic of last ordered is the sorting key? > >> To *search* for surnames however, now you can do a substring search >> in the displayName field. I'm not sure of your LDAP profficency, but >> the search would be: > > I'm really not proficient at all. Is this like a regexp so "=*Brown" > matches any entries that end in "Brown"? This is common, and you would use a "substring" search filter: "(sn=*brown)" > Would this miss someone who had two surnames, say Sally Brown West, > who chooses not to hyphenate? "(sn=*brown*)" You can also use compound search filters too: Here is an "or" filter: "(|(legalname=*brown*)(cn=*brown*")(sn=*brown*))" The options are endless. Regards, Mark > > Cheers, > ~m > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Improve the demo objects from install
Hi William, With displayname you can only sort by "order of the displaynames". So we can at least consistently sort this given the scenario above! Imagine a phone book sorted this way. In the US in any given town there would be 50 pages of Johns, making wayfinding really difficult. Is there a way for an application that's using LDAP in the backend to pull the last substring, for example, if they wanted to use the heuristic of last ordered is the sorting key? To *search* for surnames however, now you can do a substring search in the displayName field. I'm not sure of your LDAP profficency, but the search would be: I'm really not proficient at all. Is this like a regexp so "=*Brown" matches any entries that end in "Brown"? Would this miss someone who had two surnames, say Sally Brown West, who chooses not to hyphenate? Cheers, ~m ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Do aci's work in nested groups?
On 01/10/2018 07:03 AM, William Brown wrote: If I have: (targetattr=x)(version 3.0; allow(read, search)(groupdn=cn=x);) If cn=x has member cn=y, and cn=y member uid=z Does uid=z have permission to the targetattr here? IE do our aci's work through nested groups? yes, they should, but there is configurable max nesting level -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
