2

I have a Windows Server 2003 member server that is running IIS 6 in our test environment. It is a VM and was reverted to a snapshot about 4 days old. After doing this, attempts to log into the domain fail with system event ID 3210:

This computer could not authenticate with %dcin.mydomain.com, a Windows DC for domain %MY_DOMAIN, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

All network and DNS issues have been ruled out.

After doing some research I have a hunch that the issue is the computer account password that by default changes every 30 days is out of sync. Issuing the "reset account" command from ADUC did not help the issue.

Attempts to reset the account also failed when using: 

NetDom reset svrname /d:mydomain.com /uo:[email protected] /po:*

with a result of the Logon Failure: The target account name is incorrect.

If this were any other server that wasn't running IIS.... I would just remove it from the domain and rejoin it and move on with my life. But I don't know what effects doing that would have on IIS.

After I get through this I'm going got set HKLM/system/currentcontrolset/services/netlogon/paramerters/DisablePasswordChange to "1" But until then I'm not sure if the "NetDom reset" command is even the correct thing to do short of readding the server to the domain.

Thoughts?

Improve this question
2
  • 2
    Connect to the Default Naming Context of the AD database with ADSIEdit and locate the computer account object. Is the sAMAccountName attribute the same as the computer name?
    – Mathias R. Jessen
    Feb 15, 2012 at 16:39
  • Yes, the sAMAccountName is still identical to the computer name (plus the obligator $).
    – Sam Erde
    Feb 15, 2012 at 17:07

3 Answers 3

Reset to default
7

You have a snapshot of the machine already. If unjoining and rejoining it to the domain borks IIS somehow (I doubt it will), you can still revert it. You also said that this was a test environment, which is kind of made to be blown up (in some sense of the word). I'd just unjoin and rejoin it.

Improve this answer
7
  • Thanks for the comment. I'm leaning towards that method. However, after removing the computer account from the domain and re-adding it, I'm fairly sure that a new machine SID would be created. Reverting the VM snapshot would not revert the machine SID in the AD account as far as I can tell. That said, I'm not even positive that this would be an issue when it comes to ACLs for IIS and for file shares on that server.
    – Sam Erde
    Feb 15, 2012 at 16:39
  • A new Domain SID would be created, yes. The only thing I can think of that may be an issue is cached connections from other computers (to file shares and such you mentioned). My thought at this point is you have nothing to lose. You're already at a standstill so you may as well go for it. It is a test environment like you said, though I clearly am not the one to have to rebuild it, so it's your call.
    – Holocryptic
    Feb 15, 2012 at 17:00
  • 1
    Fascinating development! A colleague decided to log on locally and just change the domain property (on the Computer Name tab of System Properties) from its current name to the NetBIOS domain name, which is actually different. Upon reboot, he was able to login again! Interestingly, Windows had also changed the domain name attribute back to the fully qualified domain name automatically. Now we're just troubleshooting effects on SQL.
    – Sam Erde
    Feb 15, 2012 at 18:58
  • That is interesting. So you didn't change the domain, you just changed the machine name?
    – Holocryptic
    Feb 15, 2012 at 19:03
  • 1
    OIC. I wonder if that had the same effect as a unjoin/rejoin... I think it's essentially what you did.
    – Holocryptic
    Feb 15, 2012 at 19:47
3 
This inability to authenticate might be caused by another computer on the same network using the same name

It may not be kidding, as the cached Kerberos info from the old instance may be interfering with your ability to "activate" the reverted snapshot.

Did you shut down the VM before reverting ? Did it crash ?

Improve this answer
2
  • Yes, the VM was shut down before creating the snapshot and before restoring the snapshot. If I were to test this theory, however, is there a way to clear the cached Kerberos info about the "old" computer?
    – Sam Erde
    Feb 15, 2012 at 16:35
  • I'm sure there is, but I don't know any way off the top of my head, sorry.
    – adaptr
    Feb 15, 2012 at 17:25
2

The computer definitely has a problem now because resetting a computer account in AD Users and Computers breaks that computer's connection to the domain and requires it to rejoin the domain.

Improve this answer
5
  • Where did you get that idea ? Resetting the machine account has zero effect on the member status of the server.
    – adaptr
    Feb 15, 2012 at 17:25
  • I also doubted that statement and decided to search for more info. Greg is actually correct, adaptr. Resetting the computer account from AUDC does require a member server to be rejoined to a domain. See support.microsoft.com/kb/216393. That might explain the current problem, but it does not explain what caused the initial problem was.
    – Sam Erde
    Feb 15, 2012 at 18:07
  • I would recommend removing the down vote on this answer.
    – Sam Erde
    Feb 15, 2012 at 18:10
  • 1
    I actually tested and verified the behavior before posting it, on both Windows 2003 and 2008.
    – Greg Askew
    Feb 15, 2012 at 18:45
  • See my comment on Holocryptic's answer above. Interesting workaround for leaving/re-joining the domain without actually doing so.
    – Sam Erde
    Feb 15, 2012 at 19:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .