weixin_39928106
weixin_39928106
2020-12-09 16:19

When multiple UIDs exist, use the username provided by the user as the first lookup

The current state of the code has no way of determining the "correct" UID to use when there are multiple values. If there are multiple values, and the RDN doesn't match, this update checks the UID's returned against the username that was provided by the user at the prompt. If that matches, it's used. If that doesn't match, it falls back to the existing code.

Example:
My ldap record includes multiple uid values, ["genericemployee1", "itstaff1"] I need access to machines as "itstaff1". "genericemployee1" is used as an identifier in other systems/services.

If I log in with "itstaff1" at the prompt, and my ldap lookup with filter (uid=itstaff1) is successful, the array of UID's are checked against "itstaff1" and that's what *_primary is set to.

With the current code, if I try to log in with "itstaff1" at the prompt, I'm actually logged into the system as "genericemployee1". Based on the order that the values are returned... some other staff are logged into their "genericemployee" or the "itstaff" accounts.

该提问来源于开源项目:SSSD/sssd

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

13条回答

  • weixin_39721000 weixin_39721000 5月前

    So if you want to address case (b) you will have to change the code so that it returns multiple uids (probably behind a "relax option") and then at time of saving it will chose what uid to use based on 2 factors 1) a login happened so a specific name was used, 2) what's already in the cache.

    It is probably a complicated and invasive change.

    点赞 评论 复制链接分享
  • weixin_39721000 weixin_39721000 5月前

    I am not talking about the LDAP attribute. I am saying in posix only one name is possible, so if you have a passwd file with multiple names with the same uid or an ldap entry with multiple uids you are out of the standard and you get undefined behavior. Any call that goes UID -> NAME have no way to decide which is the correct name, and caching layers may cause different answers at different times, this is true for ldap with multiple UIDs and SSSD or passwd with multiple entries and nscd caching.

    The only way to properly deal with this is to override, per host, the user name with a side map (like it is done with id views). Hosts that want to accept multiple names per uidNumber are simply going to keep having unpredictable results or will have to use alphabetic ordering and always give "unwanted" results. There is no way to handle multiple names for the same user and return the "right" name, because "right" is context based, but UID -> Name resolution is globablly scoped.

    点赞 评论 复制链接分享
  • weixin_39721000 weixin_39721000 5月前

    we can fixate a user name at login time in the cache but: a) that may be overidden by a later login if the user uses the "other" name. b) that may change once the cache expires and someone performs an anumeration (like with ls -l) that returns the other name first.

    Now we can address (b) by forcing the code to prefer keeping the existing name in the cache on cache refreshes, but we cannot solve (a), nor we can predict which username will be used before the user ever logs in (or after a cache is wiped).

    So there will be cases when a username change will happen in the system and that can cause issues in components that rely on uid -> name mappings.

    点赞 评论 复制链接分享
  • weixin_39721000 weixin_39721000 5月前

    per posix uid must be unique, sorry to say your LDAP setup is simply violating standards and cannot be supported in a consistent way. I do not think sssd (or any other nss ldap module) can really do anything useful for you here. If you have specific systems where a user always must use a specific name and other systems where it must use the other I would suggest using id views (assuming we can do that for generic LDAP) to exactly determine what user name to use on any specific host. In any case the only way to properly handle this is to have a source of information that explicitly marks which uid is valid and use only that for the system.

    点赞 评论 复制链接分享
  • weixin_39789101 weixin_39789101 5月前

    per posix uid must be unique, sorry to say your LDAP setup is simply violating standards and cannot be supported in a consistent way.

    , this is not about the POSIX UID but about the uid LDAP attribute defined in RFC 4519 (this is the newest) and used in RFC 2307. Unfortunately this LDAP attribute is allowed to have multiple values.

    I do not think sssd (or any other nss ldap module) can really do anything useful for you here. If you have specific systems where a user always must use a specific name and other systems where it must use the other I would suggest using id views (assuming we can do that for generic LDAP) to exactly determine what user name to use on any specific host. In any case the only way to properly handle this is to have a source of information that explicitly marks which uid is valid and use only that for the system.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 5月前

    Correct. UID in ldap is allowed to be multi valued.

    I'm still curious under what circumstances a user would log in using one name, and be acting on a system with another. In every system I can think of, the name entered at the prompt is the username used on the system. Email, banking, windows, macos, it doesn't matter. If I enter "joefischetti" at the prompt I'm "joefischetti" on the system. The exception obviously being case, and in windows, diacritical marks (ō matches ø matches ö matches o)

    I understand the issue of doing a lookup when no username was provided (-bose outlined that already), but how is the current implementation better than that?

    点赞 评论 复制链接分享
  • weixin_39850365 weixin_39850365 5月前

    tbh my opinion is that the only workable option is to have a predictable order. Something like alphabetical sort, but it's really impossible to rely on the 'input name'.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 5月前

    For my own curiousity, since I only know how we're using this in our environment, why wouldn't the name that was provided by the user be a valid source to check against LDAP? We have around 400 servers using SSSD and it's only going up since the other distribution that we use just switched to SSSD.
    It would make sense that a user logs into a system with the account name that they intend to use. If I want to log in as "joe", I enter "joe" at the prompt and I expect to be "joe" when I get in. If I had a multivalued LDAP attribute that included both "joe" and "joseph", and "joseph" was returned first.... I try to log in as "joe" and when I get in I'm "joseph". I can't think of an instance where that would be the intention. Unless I want to be allowed to log in with "joe" or "joseph" and be "joe" once I log in either way.

    点赞 评论 复制链接分享
  • weixin_39850365 weixin_39850365 5月前

    See Sumit's earlier comment. Not all operations that return name also take a name as an input. Expanding on Sumit's comment, doing ls -l on files owned by joe's/joseph's UID would display one name, but then logging in as joe/joseph might display another for the same UID depending on how you logged in.

    I also wonder how would we solve e.g. access control by name (the simple access provider) or such -- this also requires some notion of a 'primary name'.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 5月前

    Sumit mentioned ls -l for users that haven't logged in yet. Yes, that would be a potential problem, but if they've logged in it'll be fine. They won't have a home directory until they log in anyway (with OUR implementation fwiw). File ownership can be set by UID(right?), it doesn't need to be a name.

    Isn't using the login value at least deterministic? Alphabetical is too, but I can't imagine we're the only organization that uses a formula to generate username types. Our Linux logins start with u or k based on organizational role. They both need to be able to log in and they both COULD have a uid that starts with a.

    点赞 评论 复制链接分享
  • weixin_39789101 weixin_39789101 5月前

    First, you cannot use global variables. The components of SSSD are designed to handle multiple requests in parallel, so you have to expect that two or more users are looked up at the same time.

    I wonder if the underlying issue isn't better solved on the server side. With the ldap_user_name option you can tell SSSD to use a different LDAP attribute than 'uid' for the user name, e.g. for the AD provider we use the AD specific attribute samAccountName. If there is currently no other attribute which only contains 'itstaff1' and other applications depend on the 'uid' attribute I'd suggest to add a new attribute like e.g. 'linuxUid' to the schema with otherwise the same definition as 'uid' expect the OID or use an existing attribute with a suitable sysntax and matching rules.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 5月前

    I appreciate the response.

    Since a global can't be used, a better way to do it would be to pass the login username to the lookup function so it can be compared. The part of the code where we "throw our hands up" just makes me feel like there's a better way to handle it.

    Your suggestion is to modify an ldap schema for 100k users, or change the way we've been implenting logins for Linux servers since we started using Linux. That's a hard ask if the alternative is 'make the tool work correctly'. In my opinion (in as little as it's worth), the value that the user enters in the login field should be the value used as their login.

    点赞 评论 复制链接分享
  • weixin_39789101 weixin_39789101 5月前

    As long as it is about the name of a single user this can be fixed with the help of an option for the NSS responder to return the name used in the request and not the 'generic' name. The additional names from a multivalue uid LDAP attribute can be stored as aliases. This way the user can be looked up by each of the names and the result will always have the name used in the request.

    To make sure that lookups by POSIX UID, e.g. when doing a 'ls -l' return this name as well the PAM responder should store the name used at login as preferred name in the cache so that lookup by UID can return this name as well.

    But there might be an issue with users which have not logged in yet. If e.g. a user calls 'ls -l /home' the UIDs from all users with existing home directories will be lookup up. If one of those users never logged in to this host it is not clear which name will be shown in the ls output. If this user logs in later and the original user calls 'ls -l /home' again, the name in the ls output might change. But I think this would also be an issue with the patch you suggested.

    点赞 评论 复制链接分享

相关推荐