Good ways to recover from local Administrator account disabled and password not known.
I'm trying to create a method for easiest recovery: Windows 10 Pro workstations - domain-joined. No local Users except Administrator and it is normally disabled. LAPS is in use and the local Administrator password is available from LAPS.
Here is one scenario: Tech decides to take the workstation off the domain and then rejoin. But, tech forgets to enable the local Administrator account before taking the workstation off the domain. (There are other scenarios as well but the outcome is the same). In order to rejoin the domain, need a local Admin account.
Whenever I've encountered this situation, I've been able to deal with it BUT the process was just too "inventive". I'd like to have a solid process. Any suggestions?
* local userWindows 10* AD Domain
Last Comment
hypercube
8/22/2022 - Mon
Paul MacDonald
I typically create a personal local administrative account on my computers to sidestep this very issue.
hypercube
ASKER
Paul MacDonald: We're starting out with only one local admin account: Administrator that is disabled. All other local accounts have been deleted (or, if found, would be) as a matter of security practice.
Setup the workstations via Group Policy so that they can the last 3 logins for the last 3 users (or something to that effect). If they forget to enable the built-in admin account they should be able to unplug the NIC and/or turn off Wi-Fi and login w/ a cached account to regain access.
hypercube
ASKER
MAS: yes, I've used that approach many times for forgotten passwords. But, it seems a bit involved for this scenario and leaves cleanup to be done. In fact, I'd not even thought of it in this context. Still, it is one way to get at the command line.
McKnife: That seems a good way to do it and easy to remember! Then run: net user administrator /active:yes so that normal startup and operations will work with that account, eh?
Andrew Porter: How might a cached domain account have local admin privileges?
McKnife
"Then run: net user administrator /active:yes
so that normal startup and operations will work with that account, eh?"
Right.
The simplest solution is disconnecting the LAN cable and signing in with cached credentials as domain admin. This is what you should try in the first place. If this doesn't work for some reason, you can try the safe mode and other suggestions.
McKnife
They use LAPS. Normally, that would mean, the admin is enabled, else, LAPS makes no sense. So for administrative tasks, the LAPS admin would use that credentials and not a domain admin (horrible idea to use it for endpoint administration, as you will surely agree).
What happens to the LAPS credentials, when the machine is disjoined? Will those remain accessible? The author should simply try that. If they remain accessible, the safe mode option is not even needed, since the account is enabled, anyway.
If they don't remain accessible and haven't been backuped, you won't be able to use safe mode without doing other steps to clear the password. And of course, when disjoined (this was the scenario explicitly mentioned), the cached creds of domain accounts no longer work, or do they for you, @hellothere?
Perhaps I didn't express the scenario clearly enough: What we need to do is: 1) unjoin from the domain 2) join back That is all. But, come to think of it, this doesn't include any other steps that may be needed to "refresh" a workstation on the domain somehow, remove it from AD, or to deal with a tombstoned workstation that's been disconnected from the domain for too long. I believe we need a Local Administrator to join back but maybe that's only for a "new" join where there is no cache? Anyway, it may be a good assumption that there is no useful information in cache anyway. I can certainly think of a few cases like that. So, perhaps it's best to make that part of the framework. LAPS works fine as long as there's another workstation on the domain that can do the lookup. McKnife: you say: "since the account is enabled anyway" but it isn't. It's disabled as part of this scenario. LAPS seems to make sense even when the Local Administrator account is disabled: LAPS discourages the re-use of the same Administrator password. LAPS enforces password changes. LAPS makes things such that the passwords don't need to be written down; or, at least as often. LAPS is often a requirement of IT Auditors <<<<<<< But, yes, one has to reenable the account in order to use it effectively. One might see this as "belt and suspenders" but it's not that much of a problem really. Disabling the Administrator account is also a requirement or IT Auditors <<<<<<<<< Removing all other local accounts is another that many folks adhere to. This question was about being prepared for making mistakes.
McKnife
So you have the password in LAPS. All you need to do is enable the local account "administrator", disjoin, use the administrator account to logon. To rejoin, you will need to provide the credentials of a domain admin (or better: of another account that has full access to the OU with computer objects) since the old computer account will be overwritten.
Can you make clear what about this process you found to be "inventive" as you call it?
hypercube
ASKER
McKnife: Yes, exactly, that would be the process. The point of this question was "what if it isn't followed?" or "what if the circumstances don't yield the same state of affairs when disjoined?". The example was that the local administrator account had not been enabled first - the step forgotten. "Inventive" or "ad hoc" or "different every time" referred to what was done in *that* case. So, taking the one case where the local administrator account had not been enabled first, what is a good process to use. I think you've answered that question very nicely!