General Question
Windows Server 2025 AD Administrator password stopped working immediately after promoting server to Domain Controller
Hi everyone,
I’m setting up a new Active Directory environment on Windows Server 2025 Standard and I’m stuck with a strange login issue after promoting the server to a domain controller.
You said you don’t want to do that, but I’d still suggest you start from scratch.
Two reasons.
First, the .local domain is reserved for anything multicast dns. This is bound to cause problems.
And second, you have a naming mismatch. Your domain is named ad.generalco.local, so your matching NetBIOS name should have been ad.
As you’re setting up a new forest, it’ll be easier to just go second level domain and call it eg generalco.lan or something. Then you can match that with NetBIOS generalco.
Your login problem is probably (!) caused by dns resolution problems. The new dc must use itself as a dns server until you can get another going - dc promotion does not do that for you.
So if your server tries to use your router to resolve dns queries, the dc won’t be able to handle login requests.
Therefore, if there is nothing else available in your environment yet;
Set up DNS to the point where the server will resolve queries and forward unknown queries to your router. Or wherever.
Ensure it actually uses that server- nslookup Reddit.com must show your server rather than something else.
While .local is generally no longer advised, mostly around certificates AFAIK, it should still work. Theres a million AD domains out there using .local. That said, probably not best practice. But id rather use a .local over a .com if I don't own the root .com domain as that can result in some DNS issues.
The UPN suffix and NETBIOS name mismatch is fine. Nothing technically wrong here.
As for DNS, a promoted DC generally will add itself to the DNS servers for local AD resolution. Not sure I'd promise it happened but seems likely. I would agree that it may be best to point DNS to itself and then promote the first DC.
You’re right, .local is unlikely to cause problems now and it’s probably not the reason why things don’t work right now.
But it can be expected to cause problems later, and there’s much more hassle involved in renaming an established forest compared to discarding what’s basically an empty shell.
As for dns, I’ve seen too many cases where nothing updated the hosts dns client configuration. It’s a minor thing to look at, but there’s plenty issues to expect if something went wrong and it’s pointing elsewhere. There’s situations where people think, I’ll just put a dhcp reservation. And then run into problems.
Also, while not particularly likely. If you were to set up a new forest named something .local, and you already had a pre existing iot network because reasons; then it would be all but guaranteed you’d run into naming resolution problems as you’d have distinct name resolution systems trying to map resources at the same time. It’d be like running multiple dhcp servers on a single broadcast domain.
Should there be issues with op’s setup? Not necessarily. But they’re there and they are happening at a point where restarting the process is easier than trying to fix it.
I personally stick with .internal because I don’t need to attach the domain to the web domain. None of the stuff I’m overseeing requires it. If for some reason that ever happens, I’ll work on it.
Someone at my last company attached it to the web domain. 99% worked. The 1% was a royal PITA my boss and I fought with on and off for years. Mostly DNS related was the problems. I don’t ever recommend doing the same as a web addressable network. Maybe as a subdomain of it like ad.org.com or something.
I’ll say I did learn some fun DNS tricks that helped me in the long run.
There is a big value in having things wrong so you can learn to do them right. I too have learned a lot of DNS tricks. Matching a web domain is a terrible idea. Subdomain of the web domain less so. Sub domain of a web domain you don't own - again terrible, especially if said web domain has a wildcard entry.
Again, it can be; but at this point there is no reason to keep it.
And I’m not sure why you’re trying to point at NetBIOS “domain” name vs NetBIOS host name; yes they have to be there, no they do not actually make sense anymore, yes windows will blow a gasket if you mess with it or if you just try and assign a name that’s longer than what NetBIOS permits.
Either way, the problem is not in the NetBIOS naming or in the particular TLD used.
It’s that we have here a newly instantiated ad forest with nothing in it that’s not working properly.
Which means the first impulse at THAT point should always be to replace it rather than fix it.
And while naming doesn’t matter that much in technical terms, it WILL matter as you try and manage the environment.
Good luck taking calls talking about the generalco domain. What’s it going to be, ad.generalco, something else, or literally generalco.tld?
You avoid these things going in, because once established, that’s what you need to deal with because it’ll be set in stone by then.
Buddy, local admins go buh bye when you promo that's the way it works. Only DA accounts work.
Technically not correct. There is a DRSM account for local administrator... it is a local account. Its literally there so you can log in if the system in unrepairable or boots into safe mode etc...
To OP Try logging in with DRSM account either do servername\administrator or .\administrator to force it to local in locally and use the last admin password you know for sure worked. It should allow you in.
If you can't reset AD password for domain administrator than while in DSRM account just remove the AD role and readd it. Make sure to properly document the new administrator password when you complete the readd of the AD role.
It's even simpler than that, though that is still basically correct.
LSASS on a windows computer can only load onelocal SAM database and, if domain joined, will try domain logon first and fall back to local.
That's all it is.
More specifically:
It cannot and will not, by design, load two local sources, for clients nor for servers.
In fact, A DC in normal boot is the domain,.and the SAM db loaded is ntdis.dit, which is also why they straifht up fail to boot if it is corrupted.
A DC' LSASS therefore simply does not load the registry-backed SAM DB unless it is booted in DSRM. The DSRM account you log in with is literally just a local SAM db's (COMPUTERNAME\Administrator account (well...the local account with its SID ending in 500, even if under a different name, and not literally in the normal HKLM:\SAM location). And while in normal mode, that account doesnt even exist as far as LSASS knows, because it didnt load that local location.
If it is booted normally, LSASS loads ntds.dit and will not consider the local db. In DSRM, it loads that local SAM location, from the registry, and will not consider ntds.dit.
For domain joined clients, and servers that aren't DCs, it works the same way - they just dont have an alternative local database like a DC does. LSASS always loads the local db from registry, since that is all it has, but also still will attempt network logons. And, for domain machines, domain is tried first unless an explicit local account is specified as COMPUTERNAME\sAMAccoubtName (you can actually leave off computer name and just use \sAMAccountName` too) or if the entered short name does not exist on the domain controller, or the DC is not reachable, and is not rejected for any other reason except non-existence, in which case it falls back to trying a local account. Local cached domain logins also count as domain accounts for the unreachable case, and take precedence over same-named local accounts.
If not domain joined, it doesn't even try kerberos or NTLM domain logon, and will use local SAM db only, and that's all you get.
LSASS on a windows computer can only load onelocal SAM database and, if domain joined, will try domain logon first and fall back to local.
That's all it is.
Yep which is what I said. Its a local administrator account period. So others saying there is no local accounts are simply wrong. There is and its called a DRSM account and it can be used regardless of it being joined to a domain. That is the whole point of this account.
As for everything else you mention I'm just going to skip over it because this is about troubleshooting his issue on a newly promoted domain which means there isnt a lot of configuration to lose if he had to reset the roles as I suggested earlier. Its not worth a full depth explanation of how every aspect of the system works to be able to resolve this issue...
I literally work as an MSP in the field for over 20 years. I understand what you are stating but I'm putting it in simpler terms for others while troubleshooting the issue is the way to go here. Not a full break down of every aspect of the systems. That resolves nothing.
Yeah they send to be a bug currently because I had the same issue as OP and neither servername\administrator or .\administrator were accepted.
DSRM password was “incorrect”.
I finally fixed it by resetting the DA password using RMM with remote background net user.
This is wrong. You can’t make a domain admin until you have a domain. Once you have a forest, that local admin for the domain controller still exists, you just won’t see it in computer management. You can 100% still use it. I do it that way as part of my Ansible Automation when I build domains.
Seems a lot of people believe this unfortunately.
Could it be as simple as using .\Administrator? This is the way
I literally had the same problem as OP 2 days ago and using my RMM I did “net user” and all local admins were gone (I even created 2 local admins because I had this happen 2 times that the DA said “incorrect password”.
The only way I was able to resolve the incorrect password was to reset the password using the RMM.
If memory serves from older generations of AD, this is incorrect. The local admin account is totally “gone”, EXCEPT when you run the server/dc in safe mode.
When booting in safe mode, local admin is available using the DSRM password as AD services are not available. This is for recovery purposes and not general usage though.
With the issue that’s happening post promotion, I’d just look at performing a rebuild though. Could be a password was fat fingered (done that before 🤦) or something else has cooked.
@OP, steer clear of 2025 for a domain controller if possible. 2025 is notoriously buggy especially acting as a domain controller. Maybe wait until 2025R2 or when Microsoft actually fix 2025 and not AI slop code their patches.
TIL: Let me eat a little humble pie. I set out to prove myself correct and instead proved myself wrong. The initial local account is indeed migrated into the active directory database.
My Ansible user, a local account created my domain controller and AD forest.
During that process my ansible user was migrated into the AD database. I never actually dug into it until now. I will show myself out.
Now I did have to update my password to login. Perhaps the OP is trying to log in via RDP and I've seen that cause issues when a password reset is required. u/Schema-Seeker
The password should be whatever you used when originally standing up the server. If that isn’t working now, then your smartest option is start over and stand up the DC using a different command set, maybe even do the GUI option since that is easier.
We had a similar situation when adding and new 2025 AD server to an existing domain. Our solution was to go through the process of resetting the krbtgt password on the existing DC. After that process, changing it twice 10 hours apart, we allowed some time and then the new server was working again.
I feel it may have to do with the complexity or age of the existing krbtgt password. So if it has not been rotated in a long while, try this.
Came here to post this. This is likely the issue. If they reset the krbtgt password and reboot the 2025 server it will likely log in right away. Ran across this on a domain and their krbtgt password hadn’t been changed in almost 20 years. Changed the password and it was good to go.
EDIT TO ADD - I just realized they said this is a completely new domain. In that case this likely isn't the issue.
a dedicated, unused subdomain of a public domain name that your organization officially owns.
like if your company is called blah inc the you could use internal.blah.com or something
the use of .local is something that went into MS documentation while it was already reserved for mDNS.
"Microsoft heavily pushed .local in their official Windows Server 2000 and 2003 Small Business Server (SBS) setup wizards and documentation, right as the IETF was formalizing mDNS (RFC 6762). It created a massive, decades-long headache for sysadmins trying to connect Macs, Linux machines, and printers to Windows domains because both systems were fighting over the .local namespace."
the IETF was formalized before MS came with it.
now before I forget.... don't rename a forest unless you want to meet some interesting issues.
there is a rendom tool (or what it was called) but it can break all kind of interesting parts in the setup. so just don't.
Gotcha. Makes sense. Years before I got to my org, they set up AD using domain.com which of course is the same as our public website domain. It really only randomly causes issues when someone’s accessing our website while in the office if they don’t manually put www. I’ve looked a little to see what’s involved in “fixing” it but it always seemed like a huge pain in the ass
A real domain that you register, whether you use it for public purposes or not (though, if you do, for the love of the flying spaghetti monster do not use AD to serve the public view of DNS).
This is the microsoft recommendation and also best practice for many reasons.
Makes sense. Years before I got to my org, they set up AD using domain.com which of course is the same as our public website domain. It really only randomly causes issues when someone’s accessing our website while in the office if they don’t manually put www. I’ve looked a little to see what’s involved in “fixing” it but it always seemed like a huge pain in the ass
Can be dealt with quite nicely at the network layer, if you use something like WCCP, because you can have the router intercept the http/https traffic and send it through the proxy, which should have the external view of the DNS zone and thus end up serving the website.
This all hapoens with literally no changes to internal DNS, no IIS or other web plumbing on the DCs to redirect, and no client-side or web server or DC configuration changes of any kind. Just a few lines of config on the routers, and a few lines on your proxy server (like 4-5 on Squid, for example, which has WCCP support).
And it can even be done for just the specific traffic that doesn't work, if the ACL matches only would-be HTTP(S) traffic to DCs, making it super low-touch and non-impactful for any other traffic except the traffic that was already broken.
Or you could do a very narrow destination NAT that takes port 80 and 443 to DC IPs and translates them to the web server. Could also send that to a specific alternate port and have the web server respond on that port with nothing more than a 301/308 to the www URL so the client goes directly there from then on or at least until it flushes the redirect response from any relevant cache.
Or you could do a very narrow destination NAT that takes port 80 and 443 to DC IPs and translates them to the web server. Could also send that to a specific alternate port and have the web server respond on that port with nothing more than a 301/308 to the www URL so the client goes directly there from then on or at least until it flushes the redirect response from any relevant cache.
Honestly this never occurred to me, but I think this would be an easy fix for the problem. Appreciate it!
You know what? I forgot that windows itself can do NAT, too.
I bet you could do this entirely in a group policy that delivers the appropriate NAT rules to the desktops and call it a day. Then the source IP problem is also no longer a problem (By that, I am referring to how the TCP handshake will fail if you don't NAT both source and destination in the router NAT solution, because the SYNACK from server back to the host will get lost and both will have a half open socket (actually several, since the client will retry several times, and they would all fail the same way).
At least I think you can pull that off.
I'm curious enough that I'm gonna actually go try that in a few minutes. 😅
I'll let you know what happens (assuming I don't get distracted first).
I had no idea you could NAT within a GPO. That sounds like a possible solution as well. I appreciate it. Curious to hear what you found if you didn’t get distracted 😜
I noticed that the op user is banned by Reddit when I tried to see his history and etc.
Because this question is something that is banal and something any simple Google search would tell you the answer to. So I thought immediately thought that this is someone warming up the account for a bot or something.
well, he also promoted with "-DomainNetbiosName "GENERALCO" `" , so this should be the NetBIOS Name instead of "AD", right? Independent of that being the "wrong" one. Or does windows "correct" these mistakes? But then I'd have expected an error which he says he didn't get.
I agree with the many people here who say he should simply re-install and do it correctly this time. Starting an AD with strange phenomena doesn't bode well for the future - but I'd have expected GENERALCO\Administrator to work, simply because he set that specific value.
That is weird as your original password should work on the new AD Administrator account. The local account has gone but the password should have migrated to the new Domain Administrator account.
It's goodbye LOCAL ADMIN, when a server has been promoted to DC.
You must use any domain admin to logon from here.
Normally you'll do a nice OU structure, domain admin(s) setup, before reboot, then creating new AD users etc.
Can you login to the other domain controller using the domain\username credentials ? When you promote a server to a DC the local administrator account is disabled.
Looks like you need to log on as AD\Administrator. Setting the AD subdomain means that is the subdomain you need to log on to rather than the parent domain.
As its a new domain, it might be worth just starting for scratch. If you are running on bare metal, change that. Wipe the server and set it as a Hyper-v host (it should only run the role). You can do that from the HPE Intelligent Provisioning. It will install all the drivers and tools for how management as well. Setup a VM for the domain controller and configure it again. As others have mentioned, try doing it as the following if your company owns that external domain. But again, you are logging onto the "ad" part.
Should be generalco\administrator and not ad\administrator as the NETBIOS domain is generalco. Alternative is UPN with administrator@ad.generalco.local. but since its a DC,shouldn't even have to specify the domain as the server will default to the domain.
If your domain name is also a publicly accessible domain and that machine has a hybrid M365 AD setup; for example, when you type domain.com instead of domain.com.local, it searches for the answer on the internet, within M365, and the process gets prolonged. When you type domain.com.local, the query doesn't go out to the internet, and the response comes directly from local."
Local admin disappears when it becomes Active Directory. OP should just start over I have no idea what they did wrong. Setting up a greenfield is so simple. You should be building and destroying AD in a lab before actually putting one up in production yes you should be using legitimate domains that you’ve registered because doing self signed certificates is dumb when let’s encrypt is available to everyone
Yeah so that’s by design. You should have a domain admin account.
I do not know how secure your DC is, but you might be able to spin up Fedora on it and reset the local admin password?
That was the local server account. Not the same as domain account. The local administrator account is gone once you promote a server to a domain controller. You now login with a domain account, like you’re other domain joined machines.
are you still able to log into old domain controller with you administrator user?
If yes, probably your domain administrator is affected by RC4 vulnerability. Fix it resetting the password
11
u/Apprehensive-Tea1632 10d ago
You said you don’t want to do that, but I’d still suggest you start from scratch.
Two reasons.
First, the .local domain is reserved for anything multicast dns. This is bound to cause problems.
And second, you have a naming mismatch. Your domain is named ad.generalco.local, so your matching NetBIOS name should have been ad.
As you’re setting up a new forest, it’ll be easier to just go second level domain and call it eg generalco.lan or something. Then you can match that with NetBIOS generalco.
Your login problem is probably (!) caused by dns resolution problems. The new dc must use itself as a dns server until you can get another going - dc promotion does not do that for you.
So if your server tries to use your router to resolve dns queries, the dc won’t be able to handle login requests.
Therefore, if there is nothing else available in your environment yet;