sssd and user ID mapping
-
@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.
