Closed zayhanlon closed 2 months ago
@noahtalerman FYI - based on our 1-1, recreated a new clean bug report for the Azure AD joined user problem
I'm looking into this right now. It appears that Disable-ADAccount
is meant for managing ActiveDirectory accounts from on the AD server, not the client machine.
It seems there's essentially no way to do this, using either official or unofficial methods. Microsoft really wants you to manage the status of ActiveDirectory user accounts from the ActiveDirectory server. I've tried modifying the Local Group Policy to disable Microsoft Accounts, both through the registry and using the GUI, but for whatever reason I'm still able to login using the account associated with the MDM enrolment, even after rebooting.
I've tried disabling PIN login, deleting user data, modifying account registry keys, changing windows service objects using powershell, and a couple other things, and nothing has worked. It always tries to let you sign back in with the account associated with the MDM enrolment.
Given how even Microsoft's own MDM doesn't support remote locking, the best we can do for the time being is disable remote credential caching and notify the admin that they will have to lock the active directory account. This is what other users online seem to do. Disabling cached logins means the user has to be connected to the internet to login, so they won't be able to go offline and continue to login.
It seems Microsoft recommends wiping the device as an alternative to locking it
Here is some of the resources I looked at in case anyone wants to try and pick this issue up in the future:
I've also disabled other non-MDM-Enroled from signing in once locked as part of the PR
We may want to create a new issue to notify admins that they will have to lock the AD account if the click "lock" on an Autopilot-enabled enrolment. Perhaps also a warning on the Lock button that it will only lock local accounts and not the MDM-Assigned account
@georgekarrv @marko-lisica
We may want to create a new issue to notify admins that they will have to lock the AD account if the click "lock" on an Autopilot-enabled enrolment. Perhaps also a warning on the Lock button that it will only lock local accounts and not the MDM-Assigned account
@noahtalerman ^ thoughts on this? sounds like there's a challenge with closing this out and maybe it's not a bug but expected behavior according to microsoft?
Hey @dantecatalfamo thanks for the detailed research!
If I'm understanding correctly, if an end user logs in to their Windows workstation w/ an Azure AD joined account, we have no way to lock it (prevent user from logging in)
And, if a Windows workstations automatically enrolls (via Azure AD or Autopilot) the end user logs in with their Azure AD joined account.
Thus, we have no way to lock all Windows workstations that automatically enroll.
Is that right?
Hey @noahtalerman
If I'm understanding correctly, if an end user logs in to their Windows workstation w/ an Azure AD joined account, we have no way to lock it (prevent user from logging in)
That is correct.
And, if a Windows workstations automatically enrolls (via Azure AD or Autopilot) the end user logs in with their Azure AD joined account.
That is my understanding. It's possible there are some configurations that don't require users to sign in using their AD account, in which case they would be locked out when local accounts are disabled, but I haven't come across them.
Thus, we have no way to lock all Windows workstations that automatically enroll.
Is that right?
Yes
We've came up with an alternative solution that consists of disabling access to said device on Entra console itself.
I'm not sure how this can be integrated into your product, but this might be a solution (at least it's one for us in the meantime…)
Hi @samleb,
This is the solution I described in the previous comments. We have no control over the Entra accounts from Fleet, so we disable cached logins instead. This means that the user will be forced to check in with the AD server (Entra) every time they want to login, making any lockout from the Entra console effectively instant and disallowing logging in without internet.
QA Notes: Based on the above conversations and known limitations, I was able to test and confirm that the updated Fleet lock and unlock scripts work as intended, which can be leveraged with disabling access within Entra.
Lock script logs out the user, disables accounts, then restarts the computer
Unlock script enables the accounts and allows login
Azure users locked, Fleet's update, like spring's warmth, Brings secure login peace.
Fleet version: 4.52.0
Web browser and operating system: All
💥 Actual behavior
See comments and thread here: https://github.com/fleetdm/fleet/issues/18461 and the customer's weekly meeting agenda notes here (Fleet internal notes)
From the customer: The problem is that it relies on Get-LocalUser / Disable-LocalUser to disable the account, but a user logged in via Azure AD would not exist as a "local user".
Instead, it appears to only exist as a "profile", which will be logged off thanks to the beginning of the script, but not disabled.
I don't see the bit that would prevent the user from logging back in using its Azure AD credentials… The correct way of handling such a case appears to be Disable-ADAccount
🧑💻 Steps to reproduce
🕯️ More info (optional)
N/A