Closed valluwtf closed 2 days ago
it would be a security downgrade considering that we then can't even use our SSH authorized keys anymore with authd.
Mh, that shouldn't be true, you can still login through ssh keys even when PAM authentication is used, in fact that should be a priority, if not you can force it (client side) with -o PreferredAuthentications
or -o KbdInteractiveAuthentication=no
However, I feel we could add an option to authd to disable single-token systems (or to explicitly enable them) when using specific systems such as remote authentication, so that the code based web auth will be a requirement in such cases, and not an option.
it would be a security downgrade considering that we then can't even use our SSH authorized keys anymore with authd.
Mh, that shouldn't be true, you can still login through ssh keys even when PAM authentication is used, in fact that should be a priority, if not you can force it (client side) with
-o PreferredAuthentications
or-o KbdInteractiveAuthentication=no
I know I can still use my standard local user with my key, but since I want to get rid of the pure local users and have only the entra ID accounts on out systems, that wouldn't be available. Would be a nice feature though if we could authenticate with authd / Entra ID and then optionally use a private key instead of a local password 😎
However, I feel we could add an option to authd to disable single-token systems (or to explicitly enable them) when using specific systems such as remote authentication, so that the code based web auth will be a requirement in such cases, and not an option.
That would be great, so do you agree that at this stage authd is more of a "one-time" MFA authentication system only? How does it adapt to changes in Entra ID application? Or deprovision users? This is especially important since right now, the local users can't be deleted (haven't tried locking them yet though)
Hey, @valluwtf! The authd-msentraid
broker relies on the access and refresh tokens provided by OIDC. Once the user authenticates through the device authentication method, the token is encrypted and cached. As long as the access token is valid and can be refreshed, the user shouldn't need to authenticate remotely again.
Regarding user information updates: as long as the access token is valid (usually it has a very short lifetime), we don't query the provider again for the user information (which is sent through the ID token). When the access token expires, we then refresh it, acquiring a new set of tokens (access, refresh, and ID). It's at this moment that the user information is updated (new groups, etc.). You can "force" authd to reacquire a new token by choosing to use the device authentication method again when logging in, instead of authenticating with the local password.
The user is de-provisioned locally if the access token expires and the provider prevents it from being refreshed.
Hey, @valluwtf! The
authd-msentraid
broker relies on the access and refresh tokens provided by OIDC. Once the user authenticates through the device authentication method, the token is encrypted and cached. As long as the access token is valid and can be refreshed, the user shouldn't need to authenticate remotely again.Regarding user information updates: as long as the access token is valid (usually it has a very short lifetime), we don't query the provider again for the user information (which is sent through the ID token). When the access token expires, we then refresh it, acquiring a new set of tokens (access, refresh, and ID). It's at this moment that the user information is updated (new groups, etc.). You can "force" authd to reacquire a new token by choosing to use the device authentication method again when logging in, instead of authenticating with the local password.
The user is de-provisioned locally if the access token expires and the provider prevents it from being refreshed.
Hi, this doesn't seem to work as expected - I have tried setting the token lifetime to 2 hours, which didn't make any difference as I could still login with my password after 2 days. Today we even deleted the token and ended all active sessions for the user, but I can still login with the local password, it seems like authd isn't even interfering at this point and my server just says "I have a password for this user so login works with it".
Pretty sure this is configurable with pam settings, but I'm not exactly sure how to change it.
You can "force" authd to reacquire a new token by choosing to use the device authentication method again when logging in, instead of authenticating with the local password.
How can I change the auth. method on login? I only get "Enter your local password" when connecting via ssh or using "login " when already on machine with different user.
Hey, @valluwtf!
Hi, this doesn't seem to work as expected - I have tried setting the token lifetime to 2 hours, which didn't make any difference as I could still login with my password after 2 days. Today we even deleted the token and ended all active sessions for the user, but I can still login with the local password
As long as the refresh token is still valid and the provider can be reached, authd won't block authentication (as it will automatically refresh the access token). I'm not 100% sure how the Entra ID platform handles the revoking of active sessions but, considering what you've mentioned, it seems like it only deals with the active access tokens.
it seems like authd isn't even interfering at this point and my server just says "I have a password for this user so login works with it".
It does interfere. Every time you login, we look at the state of the token and if it is still valid or it can be refreshed, the user is authenticated.
How can I change the auth. method on login? I only get "Enter your local password" when connecting via ssh or using "login " when already on machine with different user.
On GDM, you can use the arrow (close to the input field) or the gear-like button (bottom right of the screen) to change the authentication mode and/or the broker. On the terminal, you can press ESC to go back to the previous screen (the broker auto-selects the authentication method, that's why you always see "Enter your local password". If you press ESC on this screen, you'll be able to change the authentication mode.
As long as the refresh token is still valid and the provider can be reached, authd won't block authentication (as it will automatically refresh the access token). I'm not 100% sure how the Entra ID platform handles the revoking of active sessions but, considering what you've mentioned, it seems like it only deals with the active access tokens.
it seems like authd isn't even interfering at this point and my server just says "I have a password for this user so login works with it".
It does interfere. Every time you login, we look at the state of the token and if it is still valid or it can be refreshed, the user is authenticated.
Hi and thanks for the explanation! I have now figured out this out too, since the broker log is telling me that the token expired. The weird thing is that I still get prompted for local password. I think I will open another issue for this since I actually can't login anymore (password fails due to expired token)
On GDM, you can use the arrow (close to the input field) or the gear-like button (bottom right of the screen) to change the authentication mode and/or the broker. On the terminal, you can press ESC to go back to the previous screen (the broker auto-selects the authentication method, that's why you always see "Enter your local password". If you press ESC on this screen, you'll be able to change the authentication mode.
This helps, thanks! But for me it needs to be 'r' instead of ESC, then I can choose to authenticate against Entra again. Sadly, the login then still fails. Will gather some logs and file a new issue :)
I think I can close this one, seems like the issue is rather in the output (not telling me that my token is expired) than in the logic.
Is there an existing issue for this?
Describe the issue
Consider a setup with a virtual machine running Ubuntu Server 24.04 which we only access using SSH:
After successfully loggin in for the first time and setting a local password, I can then ssh to the machine from any other computer (well, at least in the same network) without a new MFA challenge. This seems to contradict the security idea of this package - I would have guessed that "device authentication" using OIDC relies on the device I am using to connect.
So, two questions:
To be fair, I have not tried waiting for more than a few hours yet. I agree that using MFA for EVERY login would be rather annoying, but to log in once and then have my user be available from everywhere else without any challenge for at least a few hours would be a security downgrade considering that we then can't even use our SSH authorized keys anymore with authd.
I would really appreciate some insight on this, we are really happy that authd is being developed so eagerly and have high hopes on implementing it as a standard authentication protocol in our multi-VM architecture to ensure user provisioning and MFA for security aspects.
Where does the issue happens
Steps to reproduce it
System information and logs
Environment
Ubuntu Server 24.04
Log files
Please redact/remove sensitive information:
Authd entries:
MS Entra ID broker entries:
Application settings
Please redact/remove sensitive information:
Broker configuration:
Broker authd configuration:
Relevant information
No response
Double check your logs