FR: Add support for SSSD to directly authenticate against OIDC servers

[JasonN3]

SSSD has had oidc_child for a little while now, but I don't see any documentation on how to use it. Can you please add some documentation about what configuration options are available?

[alexey-tikhonov]

How would you like to use 'oidc_child' outside of FreeIPA (where, IIRC, it is used as a helper by 'ipa-otpd')?

[JasonN3]

OIDC is a standard protocol and there are plenty of servers available. It would be great if sssd could support authenticating against OIDC servers without requiring FreeIPA. Basically, what settings need to be put in /etc/sssd/sssd.conf so the machine can authenticate against OIDC?

[alexey-tikhonov]

OIDC is a standard protocol and there are plenty of servers available. It would be great if sssd could support authenticating against OIDC servers without requiring FreeIPA. Basically, what settings need to be put in /etc/sssd/sssd.conf so the machine can authenticate against OIDC?

This functionality might be considered for addition later, but currently it's not supported. Currently no part of SSSD uses 'oidc_child' (no SSSD provider can authenticate against OIDC server on its own, without FreeIPA).

[JasonN3]

OIDC is a standard protocol and there are plenty of servers available. It would be great if sssd could support authenticating against OIDC servers without requiring FreeIPA. Basically, what settings need to be put in /etc/sssd/sssd.conf so the machine can authenticate against OIDC?

This functionality might be considered for addition later, but currently it's not supported. Currently no part of SSSD uses 'oidc_child' (no SSSD provider can authenticate against OIDC server on its own, without FreeIPA).

I'm fine with this being changed to a feature request for SSSD to support OIDC or I can submit a separate issue if you would prefer

[alexey-tikhonov]

I'm fine with this being changed to a feature request

Please feel free

[JasonN3]

I'm fine with this being changed to a feature request

Please feel free

Updated the title. So this is going to be more about getting SSSD to authenticate OIDC, which should hopefully include documenting it.

[giusepperagusa]

I second this: a generic client-side solution would be highly needed, the server-side part already having several cloud-based (EntraID, Auth0 etc.) and on-premises (Keycloak/RedHatSSO, Janssen/GluuFlex, Zitadel etc.) solutions, and implementing it in SSSD seems the only sensible strategy. Please note that ideally authorization/identity-mapping (the "NSS part", versus the "PAM part" related to authentication) could be included too (using claims and/or reusing the SSSD algorithmic generation of UIDs/GIDs).

[frasmarco]

This is a very valuable enhancement for the Linux identity governance. Upvote this! Having a modern solution for authentication and authorization could open a great number of opportunities to refresh and modernize user experince on both the server and workstation scenarios.

[giusepperagusa]

This is a very valuable enhancement for the Linux identity governance. Upvote this! Having a modern solution for authentication and authorization could open a great number of opportunities to refresh and modernize user experince on both the server and workstation scenarios.

Indeed! While researching a solution for modern authentication/authorization in Linux, I initially found some PAM/NSS modules, but all the projects I found are either of limited scope (limited to Azure cloud VMs or to Google Authenticator 2FA or so on) or unmaintained (2 years or so since last commit) or both:

• https://github.com/aad-for-linux
• https://github.com/zhaow-de/pam-keycloak-oidc
• https://github.com/salesforce/pam_oidc
• https://github.com/stfc/pam_oauth2_device
• https://codeberg.org/bergblau/webidamd

Then I realized that a modern approach would be to have this functionality inside SSSD, not directly as a PAM/NSS dedicated module, and so I ended up here :-)

Maybe some of the above sources could be used as a starting point to develop a complete SSD OIDC provider, but neither I am a programmer nor do I know the SSSD internals to judge the feasibility or effort of such a project.

But the sysadmin in me can easily see where this could lead: a Linux equivalent of a Cloud-joined server/workstation (and not public-cloud-join-only, but open to self-managed infrastructure too) and maybe, who knows, an open implementation of management policies will follow too (i.e.: a modern version of AD GPOs).

All of this seems absolutely in scope for SSSD and even needed to keep it relevant in a field where some incumbent solutions (AD, LDAP) are being more or less openly being regarded as "legacy" ;-)

[sumit-bose]

Hi,

jfyi, I'm currently working on generic IdP support for SSSD. I hope there will be something for you to test during the next months.

bye, Sumit

[AndreasGocht]

Just for the sake of completeness, I like to mention a talk at Fosdem 2024 about this topic:

https://fosdem.org/2024/schedule/event/fosdem-2024-2587-posix-identities-out-of-oauth2-identity-providers-how-to-redesign-sssd-and-samba-/

I wonder if this is the work of @sumit-bose or someone else.

Best,

Andreas

[JasonN3]

@sumit-bose Any luck or progress? Anything I can do to assist? testing or anything else?

[sumit-bose]

Hi,

you can find packages for testing SSSD with Entra ID and Keycloak with some instructions at https://copr.fedorainfracloud.org/coprs/sbose/sssd-idp/

HTH

bye, Sumit

[JasonN3]

Hi,

you can find packages for testing SSSD with Entra ID and Keycloak with some instructions at https://copr.fedorainfracloud.org/coprs/sbose/sssd-idp/

HTH

bye, Sumit

I gave it a try to see if I could replicate what you did in the video, but it doesn't seem to work. I gave it the app permission User.ReadBasic.All to get rid of the 403 errors when trying to look up a user. oidc_child.log now shows that all requests returned 200 and it logs my name according to Azure, so it was able to resolve the username. However, getent and id can't find the user. It's like the information isn't being passed from oidc_child back to nss.

I'm using Fedora 40, here's the sssd.conf, and I used authselect select sssd --force to enable sssd. I also tried replacing https%3A%2F%2Fgraph.microsoft.com%2F.default with https://graph.microsoft.com/.default since I wasn't sure if that was an issue with how the page was rendering or if it needed to be url encoded.

sssd.conf

``` [sssd] config_file_version = 2 services = nss, pam domains = MY_DOMAIN [domain/MY_DOMAIN] id_provider = idp auto_private_groups = true use_fully_qualified_names = true debug_level = 9 idp_client_id = CLIENT_ID idp_client_secret = CLIENT_SECRET idp_token_endpoint = https://login.microsoftonline.com/MY_ENDPOINT_UUID/oauth2/v2.0/token idp_device_auth_endpoint = https://login.microsoftonline.com/MY_ENDPOINT_UUID/oauth2/v2.0/devicecode idp_userinfo_endpoint = https://graph.microsoft.com/v1.0/me idp_id_scope = https%3A%2F%2Fgraph.microsoft.com%2F.default idp_auth_scope = openid profile email [nss] debug_level = 9 default_shell = /bin/bash fallback_homedir = /home/%f ```

[JasonN3]

I think I found the issue. oidc_child is storing the user info in the cache as givenName@domain instead of as userPrincipalName. If I run id with givenName@domain, it works. However, this is not how it should work. The given name is normally firstName lastName and not the username. https://github.com/sumit-bose/sssd/blob/5e9e913021873ef0433fb7b6509d863967bd301c/src/oidc_child/oidc_child_id.c#L235 should be .user_name_attr = "userPrincipalName", since the UPN is the username instead of the user's name. If you just want the name and not the domain, you'll need to split on the @ since there doesn't seem to be a field with just the username

[sumit-bose]

Hi,

thanks for the hint, I will fix the code and create a new build in Copr.

bye, Sumit

[sumit-bose]

Hi,

there is now a new build in the Copr repo which should handle userPrincipalName as expected.

bye, Sumit

[JasonN3]

Thank you. Now that is working as expected. I'm able to run getent passwd and id with the username and it gets the right information including group information.

However, I cannot ssh to the machine with the Azure account. In the oidc log, I do see the message with the login url and device code, but I never get that information on the ssh session. Instead, I am immediately prompted for a password and when I put in the right password or garbage since it's likely not being used, it sits there for a little while before returning permission denied and prompting for the password again. Are there any additional configuration changes that need to be made to pam or sshd beyond running authselect select sssd --force?

Also, as a possible feature that could be beneficial, would it be possible to look for onprem_sid and generate the uid and gid based on that if it's available? This would be beneficial for people who have previously connected their systems to an on-prem AD infrastructure but then want to migrate to Azure AD, which is a common process. If you use that when it's available, a machine connected to Azure AD would generate the same uid and gid as a machine directly connected to on-prem AD allowing shared permissions to continue to work during the migration. It would also allow you to take a machine joined to an on-prem AD, replace the domain config to point to oidc, and then everything would continue to work just with the new login method.

[sumit-bose]

Thank you. Now that is working as expected. I'm able to run getent passwd and id with the username and it gets the right information including group information.

However, I cannot ssh to the machine with the Azure account. In the oidc log, I do see the message with the login url and device code, but I never get that information on the ssh session. Instead, I am immediately prompted for a password and when I put in the right password or garbage since it's likely not being used, it sits there for a little while before returning permission denied and prompting for the password again. Are there any additional configuration changes that need to be made to pam or sshd beyond running authselect select sssd --force?

Hi,

please check you sshd configuration, you have to allow KbdInteractiveAuthentication (formerly known as ChallengeResponseAuthentication) to get prompts generated by the PAM modules. PasswordAuthentication is not sufficient because here the ssh client will ask directly for a password, which is most probably what you are currently seeing.

Also, as a possible feature that could be beneficial, would it be possible to look for onprem_sid and generate the uid and gid based on that if it's available? This would be beneficial for people who have previously connected their systems to an on-prem AD infrastructure but then want to migrate to Azure AD, which is a common process. If you use that when it's available, a machine connected to Azure AD would generate the same uid and gid as a machine directly connected to on-prem AD allowing shared permissions to continue to work during the migration. It would also allow you to take a machine joined to an on-prem AD, replace the domain config to point to oidc, and then everything would continue to work just with the new login method.

Thank you for the suggestion. I was thinking about this as well and it would be very beneficial for the use-cases you've described. I created a ticket for this feature (https://issues.redhat.com/browse/SSSD-7647).

bye, Sumit

[JasonN3]

Hi,

please check you sshd configuration, you have to allow KbdInteractiveAuthentication (formerly known as ChallengeResponseAuthentication) to get prompts generated by the PAM modules. PasswordAuthentication is not sufficient because here the ssh client will ask directly for a password, which is most probably what you are currently seeing.

I had tried KbdInteractiveAuthentication, but it didn't work. I just looked at the included files in the sshd_config.d directory and Fedora 40 includes the file /etc/ssh/sshd_config.d/50-redhat.conf which has ChallengeResponseAuthentication no. Apparently that overrides setting KbdInteractiveAuthentication yes in the main sshd_config file. Once I commented out that line, it started working. Thank you.

As another possible feature, would it be possible to have it poll every 2-5 seconds to check if the authentication succeeded? This would remove the need to press enter, which would make the login process smoother.

Also, when attempting to login to a desktop install, the text is too long. The device code is 9 characters long, but only 6 are visible in the password field. Would it be possible to change the text to "Use PIN XXXXXXXXX at..." or "Login with PIN XXXXXXXXX at ..."? It wouldn't be enough to get the URL to be visible, but the URL is the same every time so someone could bookmark it on their phone and then as long as the pin is visible, they would be able to log in.

Thank you for the suggestion. I was thinking about this as well and it would be very beneficial for the use-cases you've described. I created a ticket for this feature (https://issues.redhat.com/browse/SSSD-7647).

That's great news. Whenever you add the feature, let me know and I'll test it out. My environment includes an on-prem AD server that was synced to Entra, so I can test how smooth the migration is.

[sumit-bose]

Hi, please check you sshd configuration, you have to allow KbdInteractiveAuthentication (formerly known as ChallengeResponseAuthentication) to get prompts generated by the PAM modules. PasswordAuthentication is not sufficient because here the ssh client will ask directly for a password, which is most probably what you are currently seeing.

I had tried KbdInteractiveAuthentication, but it didn't work. I just looked at the included files in the sshd_config.d directory and Fedora 40 includes the file /etc/ssh/sshd_config.d/50-redhat.conf which has ChallengeResponseAuthentication no. Apparently that overrides setting KbdInteractiveAuthentication yes in the main sshd_config file. Once I commented out that line, it started working. Thank you.

Hi,

good to hear that it is working now.

As another possible feature, would it be possible to have it poll every 2-5 seconds to check if the authentication succeeded? This would remove the need to press enter, which would make the login process smoother.

Maybe, currently the interaction is needed because otherwise some clients (e.g. GDM but see below) will stop showing the message if the PAM module automatically disconnects without waiting for input. This is why we are currently waiting for the user to confirm that the external authentication is done.

Also, when attempting to login to a desktop install, the text is too long. The device code is 9 characters long, but only 6 are visible in the password field. Would it be possible to change the text to "Use PIN XXXXXXXXX at..." or "Login with PIN XXXXXXXXX at ..."? It wouldn't be enough to get the URL to be visible, but the URL is the same every time so someone could bookmark it on their phone and then as long as the pin is visible, they would be able to log in.

Yes, this is a know issue but it is also being worked on. See e.g. the video at https://fosdem.org/2024/schedule/event/fosdem-2024-2169-passwordless-authentication-in-the-gui/ starting around 7:10. Iker has test builds at https://copr.fedorainfracloud.org/coprs/ipedrosa/passwordles-gdm/ but here the SSSD patches for the direct integration to Entra ID are missing so you can test this only with the integration via FreeIPA.

bye, Sumit

Thank you for the suggestion. I was thinking about this as well and it would be very beneficial for the use-cases you've described. I created a ticket for this feature (https://issues.redhat.com/browse/SSSD-7647).

That's great news. Whenever you add the feature, let me know and I'll test it out. My environment includes an on-prem AD server that was synced to Entra, so I can test how smooth the migration is.

[JasonN3]

As another possible feature, would it be possible to have it poll every 2-5 seconds to check if the authentication succeeded? This would remove the need to press enter, which would make the login process smoother.

Maybe, currently the interaction is needed because otherwise some clients (e.g. GDM but see below) will stop showing the message if the PAM module automatically disconnects without waiting for input. This is why we are currently waiting for the user to confirm that the external authentication is done.

Also, when attempting to login to a desktop install, the text is too long. The device code is 9 characters long, but only 6 are visible in the password field. Would it be possible to change the text to "Use PIN XXXXXXXXX at..." or "Login with PIN XXXXXXXXX at ..."? It wouldn't be enough to get the URL to be visible, but the URL is the same every time so someone could bookmark it on their phone and then as long as the pin is visible, they would be able to log in.

Yes, this is a know issue but it is also being worked on. See e.g. the video at https://fosdem.org/2024/schedule/event/fosdem-2024-2169-passwordless-authentication-in-the-gui/ starting around 7:10. Iker has test builds at https://copr.fedorainfracloud.org/coprs/ipedrosa/passwordles-gdm/ but here the SSSD patches for the direct integration to Entra ID are missing so you can test this only with the integration via FreeIPA.

That looks better than the suggestions I had. Glad to hear they're already working on a solution. I hope it comes out around the same time as your patch. I do share his concern that he voiced in the video about having a web browser in the login page. That screams security risk to me too. If it's going to be added, I would suggest making it disabled by default and force someone to go into the config to enable it.

[AndreasGocht]

Hey,

I am about to set everything up with Ubuntu and GitLab. The compilation worked so far, but I got confused by the three repos, which do not seem to depend on each other. Do I need to merge them, or do I only need id_provider_idp?

Best,

Andreas

[alexey-tikhonov]

Hi,

On Wed, Jul 24, 2024 at 4:40 PM Andreas Gocht-Zech @.***> wrote:

Hey,

I am about to set everything up with Ubuntu and GitLab. The compilation worked so far, but I got confused by the three repos, which do not seem to depend on each other. Do I need to merge them, or do I only need id_provider_idp https://github.com/sumit-bose/sssd/tree/id_provider_idp?

Probably easiest would be to take sources that was used to build Fedora copr packages. Clicking around https://copr.fedorainfracloud.org/coprs/sbose/sssd-idp/ this looks to be: https://download.copr.fedorainfracloud.org/results/sbose/sssd-idp/srpm-builds/07741421/sssd-2.10.0beta2-0.20240717.1343.git5f139fc35.fc39.src.rpm

Best,

Andreas

— Reply to this email directly, view it on GitHub https://github.com/SSSD/sssd/issues/7229#issuecomment-2248190421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKZ5ECX3T75WU7DUZEWRC43ZN64EDAVCNFSM6AAAAABEFPDFCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBYGE4TANBSGE . You are receiving this because you commented.Message ID: @.***>

[AndreasGocht]

Hey,

Thanks :-). I chose to test with a Fedora container in the first turn because I am trying to use GitLab as an OIDC Provider.

Working a bit with this stuff, I understand why device grants are needed. However, client credential grants are also needed, but I am not sure why. Wouldn't it be possible to use only device grants?

Best,

Andreas

[sumit-bose]

Hi,

about the git repositories, I'm afraid you have to merge all three and remove the REMOVE: allow compilation without new sss_idmap calls commit.

About client credential grants, SSSD must be able to read user and group data from the IdP and uses an IdP client/application object for this (the client is needed the the device authorization as well). To allow the client to authenticate against the IdP with the client secrets the client authorization grant is needed.

HTH

bye, Sumit