Unclear: How often will authd prompt for MFA once the user has set a local password?
Closed this issue · 8 comments
Is there an existing issue for this?
- I have searched the existing issues and found none that matched mine
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:
- Is there any time period which is implemented before another MFA challenge is requested or is this something to set in Entra ID? (potentially stupid question since I'm not really into those MS topics)
- Is this a bug? Am I supposed to be able to use local password after the first login from ANY other machine? That would mean that authd provides mainly the provisioning of Entra ID users to Ubuntu, but nothing really after that. If the broker doesn't do anything anymore after the initial login, I do not get any security enhancements from this, since we are back to basic user/pw authentication. Also, what happens if groups are added or removed in Entra ID? When/how will they be synced if no broker request is sent when I log in again?
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
- I can reproduce the issue in the graphical display manager
- I can reproduce the issue on a terminal with "login"
Steps to reproduce it
- Log in for the first time and set a local password
- log in from any other host (ssh) or on same machine with this password
- no MFA challenge appears anymore
System information and logs
Environment
Ubuntu Server 24.04
Log files
Please redact/remove sensitive information:
Authd entries:
journalctl -u authd.service
MS Entra ID broker entries:
journalctl -u snap.authd-msentraid.authd-msentraid.service
Application settings
Please redact/remove sensitive information:
Broker configuration:
cat /var/snap/authd-msentraid/current/broker.conf
Broker authd configuration:
cat /etc/authd/brokers.d/msentraid.conf
Relevant information
No response
Double check your logs
- I have redacted any sensitive information from the logs
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 PreferredAuthenticationsor-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-msentraidbroker 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.