@jeff.ohrstrom Any ideas on how to move forward on this? Or can I just assume that OOD won’t work (in its current stable version) in our environment?
I suspect there’s some sort of SSSD mapping we can do, but can’t really say that’s based off of any facts, just an unfounded suspicion.
@tdockendorf do you know of any SSSD configurations that can help us here?
I’m not aware of a way for SSSD to do mapping, it expects the mapping to happen in LDAP or AD. I think SSSD expects AD to have the necessary attributes to do Posix attribute mapping like UID and GID. If those mappings are not present in AD, then I don’t think SSSD has a way to produce those values. If the numbers are consistent you could potentially populate things into /etc/passwd and /etc/group but if the numbers are random then I can’t think of a solution.
@tdockendorf We’re using ldap_id_mapping to map SIDs to UIDs and GIDs: https://linux.die.net/man/5/sssd-ldap
We’re already restricting the OIDC authentication to only allow those in the cluster-users group, so if we can just get OOD to ignore the primary group’s lack of a name, it should work, right?
The fact that the primary group is just a number and has no name seems strange, like the SSSD settings are not working correctly or something else is wrong, since the other groups do have a name. I’m not sure if maybe SSSD is having issues with groups using spaces in their name or what. I’ve never used SSSD’s ID mapping in that way so not real sure what should happen with SSSD in terms of what is produces from AD. Based on the Etcd errors it’s like the group ID lookup just isn’t working for that group which makes me think something is not correct with how SSSD is pulling data out of AD.
Most likely that’s because we don’t actually populate the Domain Users group on our system. Otherwise, we’d have tens of thousands of users that would also need to be mapped. We have it set so that only users that are a part of cluster-users get mapped (using ldap_search_base).
If that GID 1543400513 is static across systems and also the same primary GID for all users you could populate it into /etc/group on the OnDemand host to fake a group entry with that GID. That may be enough to get OnDemand to not throw errors.
That did it! Thanks! It logs you in successfully now.
It does seem kind of odd though that the group issue blocks login.