ID mapping vs. POSIX attributes in AD

Latest response

Good Morning,

Chapter 2.5 page 19 of the Red Hat Enterprise Linux 7 Windows Integration Guide says that ID mapping has to be disabled in SSSD, so the POSIX attributes are used from AD rather than creating new settings locally.

Lets take a look at the following use case. An organization chose to integrate their Linux systems into AD like it is described in chapter 2.5 of the mentioned guide. After some time of evaluation this organization would like to change the way of the AD integration an use ID mapping as it is described in chapter 2.4. Lets assume the organization turns automatic-id-mapping on in the local SSSD configuration files of all Linux systems. What are the consequences of this change?

In my opinion, now I have a lot of POSIX attributes in AD which are not used anymore. That's ok, I could clean them out later. On all the Linux systems new UIDs/GIDs are created for the users from AD. There should be the same UID/GID for a certain user on every system. But all files and directories would belong to the old UID/GID which was specified as POSIX attribute in AD, right? So there would be a lot of chown to get things straight.

Lets assume the organization has set all file and directory ownership to the new automatically generated IDs. Are they finished with the job? Are there any other tasks they have to take care of?

Are there any other implications I didn't think of? If you know some it would be great if you share them. :-)

Best regards,
Joerg K.

Jörg Kastning's picture

Responses

Jorg,

I would say the primary problem would be file/group ownership across all systems as you have pointed out and would involve a lot of find/chown to resolve... it's not a change i'd be wanting to get involved in! This also flows on to stored backups, so it may impact filesystem backup/restores long into the future. Any scripts/config management (eg. Puppet/Ansible) that may use UID/GID to specify ownership would also be affected.

I am interested to know what has taken you down this path? are you moving to a Red Hat IDM solution? I have avoided id mapping in the past because the ID isn't explicitly stored anywhere (like it is in a directory).

if it's because of a reliability issue, I recently migrated a customer from using the AD auth/id provider in SSSD because it was so problematic, particulrly with package upgrades. I have moved them to ldap provider (still to the same AD directory) and have drastically reduced the number of auth anomolies in the environment.. this is still using the posix attributes stored in the AD directory though.

Hi,

Thanks for your answer. I didn't think of the backups and the UIDs/GIDs stored in those.

To be clear, I don't wanna do this change. It's just a hypothetical question to be prepared if this idea comes to mind anywhere. So I would be prepared for the discussion.

You said that you changed the provider in SSSD because you had some trouble with it. Could you explain the issues in some more details, please? I would like to know if I'm running into the same kind of issues here and didn't know it, yet.

Best regards, Joerg

Joerg,

Apologies for the slow response.. everyone trying to cram their changes in before Christmas!

To be completely honest, the trouble with SSSD/AD hasn't been a single issue, it has really been a culmination of a number of minor things over time that just resulted in looking at alternatives. The primary issues I have seen are with SSSD/AD 'playing up' for want of a better description. This isn't a major problem in small environments, but when you have 1000+ servers and you aggregate the logs, you start seeing many small issues repeated regularly.

The most common ones I have seen over the last few years
- user authentication failures for valid users

  • 'preauth' failures when authenticating users

  • sssd_be consuming 100% CPU for extended periods of time

  • authentication issues when sssd has been running for extended periods (multiple months)

  • failed failover/recovery from 'primary' (the AD server the host joined to) AD server outage (when doing rolling outages through multiple AD servers)

  • ongoing issues with package consistency and dependencies during upgrade (https://access.redhat.com/discussions/1411853)
    There was also a krb5-libs issue recently that prevented sssd restarting after upgrade that I have mentioned on here

  • management of password refresh for machine account in AD

  • account names forced to lower case randomly changing to mixed/upper case when pulled from the cache

They all seem fairly minor in a list, and the frustrating thing is about 60% of the issues are resolved immediately with an sssd service restart. The remaining 40% are fixed immediately by stopping sssd, clearing the cache, and restarting sssd.. and then there are a handful that require a rejoin to the domain. A lot of the issues revolved around cache, and it is something I really wish you could completely disable (especially for testing).

We have chased down absolutely everything in the environment (DNS, time, network, static config, caches, kdc config etc.)... but the problems persist and only for hosts with SSSD/AD configs.

When switching to ldaps provider in SSSD you lose GSSAPI, but you can simplify the failover config by pointing at a pair of basic TCP load balancers. You also remove the domain join (machine account) requirement which means there is no cleanup of directory objects after the host/node is removed.

Interested to hear if you are having any of these issues?

Hi, Thank you very much for your response.

Apologies for the slow response.. everyone trying to cram their changes in before Christmas!

No need for that. It's the same in here.

Interested to hear if you are having any of these issues?

So far we faced some minor issues du to caching and a dependency issue with the krb5-libs. But from the list you posted I'm going to have a closer look into our logs to figure out if there are some issues I'm currently not aware of.

Thanks again for your detailed answer!

Another example of sssd upgrade issues.

Just upgraded systems in a test lab to 1.15.2 and immediately got the following errors (from all systems upgraded) and users aren't able to authenticate:

[sssd[krb5_child[xxxxx]]][xxxxx]: Preauthentication failed

sshd[xxxxx]: pam_sss(sshd:auth): received for user testuser2: 4 (System error)

sudo: pam_sss(sudo:auth): received for user testuser1: 4 (System error)

As usual, restarting sssd service immediately solved the issue.

Hi, from what version did you update? I've just updated sssd from 1.15.2-50.el7_4.6 to 1.15.2-50.el7_4.8 but was not able to reproduce the issue. I was able to login with an AD user wit password and ssh-key without the need to restart the sssd.service.

Best regards,

Joerg

Was this helpful?

We appreciate your feedback. Leave a comment if you would like to provide more detail.
It looks like we have some work to do. Leave a comment to let us know how we could improve.
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.