0

Context:

  • Windows server 2003 x64:
    • On a VMWare ESX 3
    • member of a domain
    • has as primary DNS server the PDC, can see it (ping et al)
    • can access a shared folder (even to a shared folder on the PDC) using credentials from the domain when logged on as a local admin

Problem:

  • logging on the machine with the same domain credentials gets me an invalid user/password error.

I'm at a loss about where to start debugging this.

Any clues?

UPDATE:

I checked to PDC logs and I get

The session setup from computer 'VM' failed because the security database does not contain a trust account 'VM$' referenced by the specified computer.

USER ACTION If this is the first occurrence of this event for the specified computer and account, this may be a transient issue that doesn't require any action at this time. Otherwise, the following steps may be taken to resolve this problem:

If 'VM$' is a legitimate machine account for the computer 'VM', then 'VM' should be rejoined to the domain.

If 'VM$' is a legitimate interdomain trust account, then the trust should be recreated.

So the actions to take now are clear. What's not clear to me is the cause for that and how to prevent further occurrences of it.

UPDATE 2: Yes, it is a clone, but I already had proceeded to part from and rejoin the domain.

2
  • Hi Vinko, did you manage to sort this out? The only other suggestion I can think of is to run sysprep on the VM, which will recreate the SID. Aug 3, 2009 at 7:04
  • Thanks John, no definitive resolution yet, I just unjoined and rejoined the domain. Will do further research for a definitive solution (I'm not keen on reinstalling all machines).
    – Vinko Vrsalovic
    Aug 3, 2009 at 8:46

4 Answers 4

2

If it's a clone as you say then you really need to run sysprep on it, just unjoining and rejoing the domain isn't enough to fix the SID issue AFAIK.

There are VMware docs that explain where to put the sysprep binaries on the VC server so that when you clone a VM that the cloning process can automatically run a sysprep on the new VM for you. Unfortunately the docs could be better at explaining exactly what to do, this link explains somewhat better.

5
  • I've done a cursory google search but haven't found exactly what the problem is (ie, what is an AD SID, why can't it be regenerated, and so on). Have you got some extra resources about that? Also, can you prepare such a clone manually?
    – Vinko Vrsalovic
    Jul 31, 2009 at 23:35
  • Oh yeah I forgot about the sysprep part...I avoid the whole sysprep process by not cloning VMs that have already been joined to the domain. I just build a basic Windows box, update it and configure it the way I want, and shut it down. Then clone as needed, rename the new box, and join to the domain.
    – August
    Aug 1, 2009 at 0:25
  • Dis-joining and re-joining the Domain doesn't recreate the SID, which is buried deep in Windows in many different places (registry and file system). Aug 3, 2009 at 7:06
  • An Active Directory/Domain SID is the same as a regular workstation SID except that it's the SIS of the first Domain Controller in the domain. When you join your workstation to the domain the AD accounts are prefaced with the domain SID.
    – Ausmith1
    Aug 3, 2009 at 19:36
  • The VMware ESX docs show how to do the cloning, as I said they could be better (At least in v3.0.x, maybe the v4.x docs are better at explaining this) but they will set you on the right track on how to do the cloning. You can always do the clone and sysprep manually but the automated method in ESX is pretty decent and saves you having to find the right files and place them correctly and edit them each time.
    – Ausmith1
    Aug 3, 2009 at 19:40
2

Did you roll back to a prior snapshot on the VM in question? It sounds kind of like the error you get when you do that.

See this answer for the solution if this is what you did.

1
  • Yes, I did do that, but as I say in the update I had already parted and rejoined the domain. I haven't read the articles in the solution yet though.
    – Vinko Vrsalovic
    Jul 31, 2009 at 20:28
1

Check the time on your member server. If it is more than 5 minutes out with respect to the Domain Controller(s), AD authentication will fail (Kerberos relies on the time to be in sync between the client and the server).

6
  • Nope, that's not it. If I change the time even farther away I get a "the time here and time on the network are different" error. I get a "the system could not log you on". I do have clock drift due to not yet researched issues on our VMWare setup though
    – Vinko Vrsalovic
    Jul 31, 2009 at 16:04
  • Would you mind providing the exact error message? I've never seen "the time here and time on the network are different" and neither has Google. "The system could not log you on" is classic incorrect time behaviour. If you log on to the member server with a local account, try the following from a command prompt: w32tm /stripchart /computer:yourdc where "yourdc" is the name of your domain controller. Could you provide the first few lines of output here? Jul 31, 2009 at 16:29
  • "The current time on the computer and the current time on the network are different", but, as said, it doesn't normally occur (only when the clocks drift too much)
    – Vinko Vrsalovic
    Jul 31, 2009 at 20:25
  • @John, you've seriously never had problems due to time differences? See here, it's quite common in my experience: support.microsoft.com/kb/232386 Jul 31, 2009 at 21:40
  • @Graeme: He's saying that the original message I put in my comment is not the exact message Windows shows
    – Vinko Vrsalovic
    Jul 31, 2009 at 22:09
1

Did you clone this server from another VM that was already joined to the domain? If so, you will need to disjoin and rejoin to get a new SID for the computer account.

You must log in to answer this question.

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