#2069 [RFE] When using sssd-ad in a forest should be able to flatten usernames for all domains
Closed: Duplicate None Opened 9 years ago by simpfeld.

When using sssd-ad there should be an option to flatten usernames for all domains in a forest (i.e be able to have all usernames displayed without a domain component no matter which domain in a forest they are from). For the domain you are joined to this option is possible with "use_fully_qualified_names = False" but I believe there is no option to extend this to all domains.

I realise this isn't default to catch the case where the same username has been used on multiple domains. But this is generally considered bad practice. I'd have thought if the same username does exist on multiple domains the result should essentially be undefined (first found) or some sort of search order (if this hypothetical option existed).

This is required for several reasons:

1/ It gives a consistent username space across all domains (the forest should behave (and does in general) like a single large domain to end users). This allows a consistent username on any joined Linux system, whatever the domain the machine is joined to.

2/ Users can and do move between domains as they change location for example. Their username shouldn't change as far as Linux systems are concerned in this circumstance.

3/ Not having an option for this makes migration from other directory services to multiple domains problematic. Users and esp their config files in homedirs expect a simple username.

4/ If "use_fully_qualified_names = False" is used on one domain (maybe forced from above) the user will essentially have a different user names on machines joined to different domains. With NFS homedirs this will break lots of things.

5/ Commercial AD Linux integration solutions (I seem to remember the default on some) provide this option so presumably a common need in commercial environments.


Really makes sense... We should do it. The question is "when"? IMO 1.11.x would be ideal. Is this a barrier for adoption?

Also I think I suggested to flatten names when we were developing 1.9. At the time I was given a strong argument that this is a bad idea. Is this still the case?

Same with the other bug, I didn't know which version to target in my report, I have this failure on 1.11.0 on F19. Feel free to change to what you think is best to get resolved as quickly as possible.

Not having an option does stop people shooting themselves in the foot, but that shouldn't be a blocker to implement. Admins just need to ensure uniqueness. So not the default, but required for many sites for the reasons I've given.

A large barrier to adoption for us and other sites I'd have thoughts.

Have you tried the default_domain_suffix option? (see man sssd.conf)

Have you tried the default_domain_suffix option? (see man sssd.conf)

Not sure if this was for me but it didn't seem appropriate. The man page says:

default_domain_suffix (string)
This string will be used as a default domain name for all names
without a domain name component.

As all the domains that I'm not joined to in the forest all present with full domain components (these are BTW auto detected correctly by sssd), I assumed this option wouldn't apply? Kind of the opposite of what I'd like from my reading.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta
rhbz: 1001325, [https://bugzilla.redhat.com/show_bug.cgi?id=1001325 1001325] => [https://bugzilla.redhat.com/show_bug.cgi?id=1001325 1001325]

Fields changed

mark: => 0

Fields changed

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

I'm sorry, but this is not realistic to do in a multi-domain environment.

milestone: SSSD 1.14 beta => SSSD Deferred
sensitive: => 0

Don't know why this is not realistic? I have the commercial QAS (Dell Authentication Services) AD integration solution and it (by default) flattens all domain usernames down to a plain username. So definitely done elsewhere. And there is no change to the AD environment to support this.

Doesn't really matter, it probably should be made to be realistic. If not then SSSD cannot easily be deployed in any multidomain AD environment, so won't be usable in many reasonably sized environment. I doubt SSSD would like to limit it's ambition like that.

As per my original justification (below) these are the reasons this is required, even if not the default and/or requires publishing the RFC2307 attributes in the Global Catalog.

1/ It gives a consistent username space across all domains (the forest should behave (and does in general) like a single large domain to end users). This allows a consistent username on any joined Linux system, whatever the domain the machine is joined to.

2/ Users can and do move between domains as they change location for example. Their username shouldn't change as far as Linux systems are concerned in this circumstance.

3/ Not having an option for this makes migration from other directory services to multiple domains problematic. Users and esp their config files in homedirs expect a simple username.

4/ If "use_fully_qualified_names = False" is used on one domain (maybe forced from above) the user will essentially have a different user names on machines joined to different domains. With NFS homedirs this will break lots of things.

Mainly there is no realistic way of dealing with username conflicts.

I just don't see the justification of short usernames. If there is a software that requires a short username, then it's buggy and needs to be fixed, sorry. Is it about convenience?

btw what you request is more or less already the behaviour if you manually configure the domains (as opposed to let sssd auto-discover them). I just don't think it's a good practice and not something we should endorse.

For NFS, we already provide an id-mapping plugin which I hope would mitigate this concern.

Replying to [comment:14 jhrozek]:

Mainly there is no realistic way of dealing with username conflicts.

I just don't see the justification of short usernames. If there is a software that requires a short username, then it's buggy and needs to be fixed, sorry. Is it about convenience?

btw what you request is more or less already the behaviour if you manually configure the domains (as opposed to let sssd auto-discover them). I just don't think it's a good practice and not something we should endorse.

For NFS, we already provide an id-mapping plugin which I hope would mitigate this concern.

Should we have some write-up on the matter to clarify how what is requested can be achieved without addressing this issue? I suspect this discussion does not cross all the Ts and needs a bit more consensus before being put off.

Sure, I meant to move this ticket to needs_triage anyway for more investigation.

milestone: SSSD Deferred => NEEDS_TRIAGE

I hear you about username conflicts, but see below.

But this is not about convenience. In an enterprise environment it's very common for people to use machines anywhere (i.e. joined to any of your domain). And people fairly frequently move between domains (maybe when they move geographic location) and the thought of their Linux username changing just doesn't work.

I doubt it's an applications fault that a username change will break it's config file. It's not the domain username length or format that causes the problems, it's the fact that it changes at all when you move domain.

So if you move domain you it's not acceptable that a whole users environment will break.

I don't know how commercial AD connectors deal with this. But how does SSSD currently deal with duplicate UIDs/GIDs on objects in the forest? I'd have thought you'd handle duplicate usernames the same way, if a hypothetical forest flatten username mode was selected in the SSSD config.

I'd have thought the easy way to deal with both these situations would be to deny the user (either one) access until the conflict is resolved. After all, you are saying to SSSD (in it's config), in my environment I'm guaranteeing that my usernames (and UIDs/GIDs) are unique in the forest. If you violate that, then this username will break until the conflict is resolved.

A quick google says a duplicate UID will result in QAS denying access (can't immediately find what it does with duplicate usernames but doesn't seem an unreasonable response for them too):

https://support.software.dell.com/authentication-services/kb/24317

Centrify seems to deal with this by allowing you to provide a preferred login domain that will win on duplicates:

https://docs.centrify.com/en/css/suite2016/DirectControl-Release-Notes.html

"- adclient.preferred.login.domains: When duplicate sAMAccountNames exist across multiple domains in a forest, the ambiguity in resolving these names is fixed by configuring the parameter adclient.preferred.login.domains parameter to force adclient to login using the specified domain names. Note: If this parameter is set and adclient caching is enabled, the configuration parameter adclient.cache.upn.index must be set to true, to resolve ambiguity in the adclient cache. (Ref: 60464)"

So commercial vendors clearly see this as important enough for large networks that they have implemented workarounds to handle potential conflicts.

I think you need to consider this bug as important to scaling SSSD, I'd be surprised if others on this bug wouldn't see why this functionality is important.

About duplicate IDs - we don't handle them. And given UIDs are what identifies file ownership, I'm not sure we should handle them at all. I think denying access or just throwing an error would be a reasonable thing to do.

btw on the way home I was thinking about this a bit more and I realized that for /output/ we would be able to get away with configuring full_name_format to $1 (just name) which would work like this:

$ getent passwd administrator@child.domain.com
administrator:*:123:123:administrator:/home/child.domain.com/administrator:/bin/zsh
$ getent passwd administrator@domain.com
administrator:*:456:456:administrator:/home/domain.com/administrator:/bin/zsh

We need to finish refactoring the FQDN format in sysdb though, which /is/ something we are working on right now, so this change /will/ be included in 1.14 (if all goes well with the pending changes).

Then the other question is about querying the name from a child domain. We could just say that if a conflicting username exists in several domains, we return the first match (which would be the enrolled domain) unless a fully qualified name is selected.

It's not hard to code up, I just still see this as a misfeature..

I also wonder if default_domain_suffix that we already have would be close enough to Centrify's adclient.preferred.login.domains ?

Replying to [comment:18 jhrozek]:

We could just say that if a conflicting username exists in several domains, we return the first match (which would be the enrolled domain) unless a fully qualified name is selected.

Except this would be random, because different clients can discover domains in different order. So we would have to come up with an orderding scheme or let the admin hardcode a list of domains in the preferred order. Neither of these sound nice to me..

OK, so combination of setting full_name_format to $1 and a new option (yay for more options..) called something like preferred_domain_suffixes should do the trick.

In the meantime, I'm moving this ticket to 1.15 beta. Before tackling this ticket we need to:
- switch the sysdb into using a unified name format everywhere
- switch the responders into using the cache_req request
- switch the cache_req code into querying all caches first before asking the Data Provider

milestone: NEEDS_TRIAGE => SSSD 1.15 beta

We have two tickets describing the same feature, this one and 3001. Since 3001 is better linked with downstream bugzillas and other dependant tickets, I'm closing this one as a duplicate of #3001.

resolution: => duplicate
status: new => closed

Metadata Update from @simpfeld:
- Issue set to the milestone: SSSD Future releases (no date set yet)

5 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3111

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata