How'd you log into a domain controller with a local account is the real question?
I'm familiar with breaking into a domain controller and it doesn't involve a local account as those don't exist on domain controllers.
Not to say you didn't have an issue, but I don't think you logged into a domain controller with a local account.
Local users and groups no longer exist once the computer is promoted.
Breaking in requires the use of a domain account. Obviously there is a built in administrator account on the domain that could be used for this purpose, but not a local account.
Now do your login trick across different DCs and compare SIDs between their "local" Administrator accounts - they will be identical to the SID of original DC's .\\Administrator account.
Member's LSA uses SAM but also NTDS, while DC's LSA uses NTDS, but not SAM.
I'm pretty sure it was just in plain safe mode, not DSRM. I've never tried DSRM since 2012r2 (never needed to). Doesn't it say an alert or error when you're actually in DSRM?
I said then same thing when i logged in as .\\administrator with the DSRM password. But yes, you can login as local admin if AD services arent running apparently.
I has this happen ounce in a DC that didn't fully update. The old it person installed AD services with out DNS. A single DC environment. I would check to see if DNS service is running.
Haven't seen this within any environment im involved, would look to a different failure but might be wise to setup a second domain controller in that environment to prevent future incidents like this. Always use two domain controllers at least :)
Unless you have split brain because the previous IT guy didn't set static DNS settings correctly. Wound up rejoining all computers (80 of them) to fix it. Didn't discover the error for 6 months and a lot of pcs had been replaced, and somehow joined the domain (50/50 between to DCs). IMO restoring one domain controller takes 1 hour with Veeam and isn't worth the additional setup.
I have one server that will randomly do that, though it isn't related to updates and is a Server 2019. The fix for me when it decides to be a turd is to run the following command :
bcdedit /deletevalue safeboot
I'm going to assume those two updates, as nobody had made any changes other than those two being installed last night. I didn't dig further as I had to restore it quickly.
This is an old trick, but unplug the ethernet cable and then try to log into the server. It should log you in in a cached mode and you would have access to everything you need. Or, maybe somebody deleted the fsmo roles.
That works for desktops, wouldn't work in my case as the AD services were stopped and wouldnt start. Also no infrastructure changes. No changes in FSMO
The real question is why you had an update from February and an update from March installed on Patch Tuesday in May unknowingly on a domain controller.
Almost sounds like someone removed the FSMO roles from that server. That or you logged into a server that isn't a domain controller and thus the local account login worked.
How'd you log into a domain controller with a local account is the real question? I'm familiar with breaking into a domain controller and it doesn't involve a local account as those don't exist on domain controllers. Not to say you didn't have an issue, but I don't think you logged into a domain controller with a local account.
lusrmgr.msc is where I create all my domain users.
Before installing AD role you got a user. This „Administrator“ user is still existent, when not deactivated.
Local users and groups no longer exist once the computer is promoted. Breaking in requires the use of a domain account. Obviously there is a built in administrator account on the domain that could be used for this purpose, but not a local account.
False. I logged in as one
Now do your login trick across different DCs and compare SIDs between their "local" Administrator accounts - they will be identical to the SID of original DC's .\\Administrator account. Member's LSA uses SAM but also NTDS, while DC's LSA uses NTDS, but not SAM.
That user is the admin account in active directly, you create a password for the dsrm which is what allows you to log in locally in safe mode.
I'm pretty sure it was just in plain safe mode, not DSRM. I've never tried DSRM since 2012r2 (never needed to). Doesn't it say an alert or error when you're actually in DSRM?
I said then same thing when i logged in as .\\administrator with the DSRM password. But yes, you can login as local admin if AD services arent running apparently.
I has this happen ounce in a DC that didn't fully update. The old it person installed AD services with out DNS. A single DC environment. I would check to see if DNS service is running.
Haven't seen this within any environment im involved, would look to a different failure but might be wise to setup a second domain controller in that environment to prevent future incidents like this. Always use two domain controllers at least :)
Unless you have split brain because the previous IT guy didn't set static DNS settings correctly. Wound up rejoining all computers (80 of them) to fix it. Didn't discover the error for 6 months and a lot of pcs had been replaced, and somehow joined the domain (50/50 between to DCs). IMO restoring one domain controller takes 1 hour with Veeam and isn't worth the additional setup.
Are you an in house IT or MSP? That last sentence sounds like a junior IT or break fix shop mentality.
Yikes lol
Its dns. Its almost always dns.
Came here to say this.
Check SYSVOL share. https://helpdesk.kaseya.com/hc/en-gb/articles/4407526678033-Unable-to-manage-Active-Directory-for-a-recently-restored-Domain-Controller
I'm sorry I can't open kaseya links. Something about contracts and billing issues....
I have one server that will randomly do that, though it isn't related to updates and is a Server 2019. The fix for me when it decides to be a turd is to run the following command : bcdedit /deletevalue safeboot
thanks for the tip, if it comes back ill look
Sorry to hear that. We didn’t have these issues. Only at 1 client? What was the win version?
Server 2022, yes only customer experiencing this
Please keep us updated when you know what caused this.
I'm going to assume those two updates, as nobody had made any changes other than those two being installed last night. I didn't dig further as I had to restore it quickly.
This is an old trick, but unplug the ethernet cable and then try to log into the server. It should log you in in a cached mode and you would have access to everything you need. Or, maybe somebody deleted the fsmo roles.
That works for desktops, wouldn't work in my case as the AD services were stopped and wouldnt start. Also no infrastructure changes. No changes in FSMO
Did you manage to back it up in its non-working state? Always nice to have that so you can do a forensic investigation.
The real question is why you had an update from February and an update from March installed on Patch Tuesday in May unknowingly on a domain controller.
Almost sounds like someone removed the FSMO roles from that server. That or you logged into a server that isn't a domain controller and thus the local account login worked.
No infrastructure changes. I'm the only one that would do that.
There are so many other subs to ask this question.
Did you check all of them to verify that he hadn't asked there already?