sssd and user ID mapping
-
We are soon going to be using AD for authenticating users to our Linux VMs. Of the things to think through, one thing I'm considering how to handle UID/GID mapping. SSSD generates handles this by default using an algorithm to map AD SIDs to UIDs/GIDs. This in theory should keep UID/GID consistent as the user logs into different Linux VMs. However, you can disable this mapping and set some attributes in AD (
uidNumber,gidNumber, etc.).What would be a scenario where you would want to disable the sssd auto-ID mapping and set these attributes in AD? The only I can think of is when you want to specify the exact UID/GID that would be associated with a user or group, which would present the challenge of having to make sure you don't have ID conflicts.
-
What type of users / VMs are we talking about? Is it virtual linux workstations or are you talking about admin access to servers or something else?
-
"Yes."
The people accessing these VMs are my team (admins) as well as various developers. The number of unique users is enough to where managing local accounts wouldn't make sense. Also, there's SSO involved with many of our company's resources and AD is basically the source of truth for that.
There's a good bit for me to think through, in particular if it's worth using FreeIPA / IdM for authentication for these VMs and have FreeIPA / IdM have a trust with AD, which as of right now the answer to that is "no, it's not worth it." Thus, likely what's going to happen is going to be using sssd to work directly with AD, which brings up the though of the best way of handling user and group IDs.
I'm not aware of any kind of native way to generate unique
uidnumberandgidnumberwhen creating an AD user; thus, I think the way to go will be just letting sssd handle ID mapping, but I was curious if there is a reason I'm not thinking of that would make sense to not have sssd handle ID mappings. -
I think having uid handled automatically makes sense.
When you talk about developers and admins though, my first thought is that they'll immediately install ssh keys and bypass AD altogether.
-
@Pete-S
I use keys and use my Ansible control mode as a jump box
Lots of work left to tame the Wild West. This thread is just one many things to be done.
-
@EddieJennings we use a combination. We use the ids generated by sssd and automate the population of the AD attributes to align with them to ensure consistency. Where it comes in handy is when we have NFS mounts exported from an LDAP-aware NAS device. The NAS device doesn't natively understand the sssd mappings, and relies upon LDAP calls to find the accounts.
You can't really have a conflict, unless you were looking for a user and group to have the same number (which they can't with sssd, because it appends the principle's RID (padded to 5 digits). If you have a need to manually specify a UID/GID,, that would be for a local account, I presume. In those scenarios, we do create AD accounts that have manually defined UIDs that line up with the local user (always less than 1000) for the NAS appliance to find when evaluating access.
-
@Pete-S If it is an issue, its trival enough to prevent public key authentication for users or groups of users, even groups of AD users.
-
@Semicolon said in sssd and user ID mapping:
@EddieJennings we use a combination. We use the ids generated by sssd and automate the population of the AD attributes to align with them to ensure consistency. Where it comes in handy is when we have NFS mounts exported from an LDAP-aware NAS device. The NAS device doesn't natively understand the sssd mappings, and relies upon LDAP calls to find the accounts.
You can't really have a conflict, unless you were looking for a user and group to have the same number (which they can't with sssd, because it appends the principle's RID (padded to 5 digits). If you have a need to manually specify a UID/GID,, that would be for a local account, I presume. In those scenarios, we do create AD accounts that have manually defined UIDs that line up with the local user (always less than 1000) for the NAS appliance to find when evaluating access.
I'm curious. How do you gather the ids generated by sssd and populate them in to uidNumber and gidNumber attributes in AD?
-
@EddieJennings sssd will by default generate a five digit identifier for each domain. It has to be repeatable because each instance of sssd on computers that may not talk to eachother have to come up with the same number. Once you have the number for a single account, you can predict what the uid is going to be for any group, user, or service account.
So, for a given domain
ad.domain.com, and a user Bob, with aSID of S-1-5-....-1501, sssd will give you an id ofXXXXX01501. Any other account in that domain will have the same XXXXX value followed by their RID (padded to five digits).I'm pretty sure you can even override the value of XXXXX that sssd generates, but I prefer not to.
-
@Semicolon said in sssd and user ID mapping:
@Pete-S If it is an issue, its trival enough to prevent public key authentication for users or groups of users, even groups of AD users.
Sure, but the problem for developers and admins is that they usually need their keys. That's why I don't think ad/ldap integration with ssh users really works in that use case.
The other solution, which is what I think is more suitable for developers and admins, is to use your SSO/AD solution with MFA to pickup a short-lived ssh certificate. Then you use the ssh certificate to actually access things.
Many companies with huge infrastructures use this method because it's very scalable. -
@Pete-S That sounds interesting, I'll have to dig into that a little more. In the mean time, we've added the public keys to the user accounts in AD configured openssh to validate the keys against AD instead of the local files.
-
@Semicolon said in sssd and user ID mapping:
@Pete-S That sounds interesting, I'll have to dig into that a little more. In the mean time, we've added the public keys to the user accounts in AD configured openssh to validate the keys against AD instead of the local files.
SSH certificates are great. Since certificates is based on trust you don't need to copy keys anywhere.
Basically you have server certificates and user certificates. The server can authenticate all users by using the users certificate issuer's public key. The user can verify that the server is valid in the same way (no fingerprint questions).
That's the basic authentication. Servers don't need to access any central authentication mechanism to authenticate users.
Using AD or any other identity provider only comes into play when it comes to issuing the ssh certificate to the users.
You simply have to present your credentials to get the new ssh certificate. This can be through a webpage / service or cli interface.This service connects to the identity provider and also looks up if the user is authorized to get a ssh certificate.
Since certifcates can have a validity period, you can set how long the certificate is valid when it's issued. One day seems to be a common choice.
Using short validity means you don't need to think about revoking certificates and you don't need to think about key rotation. Because you will get that automatically since the certificate expires naturally.BTW, the ssh certificates looks just like ssh keys (a file). They are not as complicated as ssl certificates.
-
@Pete-S said in sssd and user ID mapping:
@Semicolon said in sssd and user ID mapping:
@Pete-S If it is an issue, its trival enough to prevent public key authentication for users or groups of users, even groups of AD users.
Sure, but the problem for developers and admins is that they usually need their keys. That's why I don't think ad/ldap integration with ssh users really works in that use case.
The other solution, which is what I think is more suitable for developers and admins, is to use your SSO/AD solution with MFA to pickup a short-lived ssh certificate. Then you use the ssh certificate to actually access things.
Many companies with huge infrastructures use this method because it's very scalable.We forced kerberos for SSH auth after wen enabled AD integration. SSH works like keys then but you don't use the keys.
-
@stacksofplates said in sssd and user ID mapping:
@Pete-S said in sssd and user ID mapping:
@Semicolon said in sssd and user ID mapping:
@Pete-S If it is an issue, its trival enough to prevent public key authentication for users or groups of users, even groups of AD users.
Sure, but the problem for developers and admins is that they usually need their keys. That's why I don't think ad/ldap integration with ssh users really works in that use case.
The other solution, which is what I think is more suitable for developers and admins, is to use your SSO/AD solution with MFA to pickup a short-lived ssh certificate. Then you use the ssh certificate to actually access things.
Many companies with huge infrastructures use this method because it's very scalable.We forced kerberos for SSH auth after wen enabled AD integration. SSH works like keys then but you don't use the keys.
Never used it but it seems to be a good solution if you want AD integration.
I noticed that gitlab also supports kerberos for pushing and pulling. I assume github does too. That's very convenient.
