Trust relationship trouble

  • Thread starter Thread starter Karsten
  • Start date Start date
K

Karsten

A couple of days ago one of our Windows 2000 servers (domain member)
started getting access denied when trying to log on to the domain. The
error message on this server is "The system cannot log you into this
domain because the system's computer account in it's primary domain is
missing or the password on that account is incorrect." Also in the Event
log I repeatedly see event ID 3210 "Failed to authenticate with
\\<computer name>, a Windows NT domain controller for domain <domain
name>." Local Administrator log on still works.
Also, when trying to join the domain I receive Event ID 5722 on the DC.

On the DC, when trying to join the W2K server using NETDOM I receive the
message "The trust relationship between this workstation and the primary
domain failed."

The domain is running in mixed mode with one NT4 DC, one Win2K DC and
one Win2003 DC, which is also the global catalog server.

These are the suggested solutions that I found in newsgroups and the
results:
- Use NLTEST to test the trust relationship. Result: 'Trust relationship
failed'
- Use NETDOM to join the affected computer to the domain after manually
removing it. Result: 'Trust relationship failed'
- Use NETDOM to reset the secure channel. Result: 'Trust relationship
failed'
- Log on to the domain with a different domain user name with admin
rights. Result: 'Cannot log you on to the domain'
- Remove the affected machine from the domain, delete its computer
account in AD, wait for replication and rejoin the domain. Result:
'Cannot log you on to the domain'

One more observation: After removing the server from the domain, adding
it to a workgroup and rebooting it still claims domain membership in the
Network Identification tab of the computer's properties.

Thank you for any thoughts
Karsten

NB: I have posted this in the win2000.networking-group before I
discovered this group. Sorry for crossposting.
 
One more observation: After removing the server from the domain, adding it
to a workgroup and rebooting it still claims domain membership in the Network
Identification tab of the computer's properties.

Do you mean it still has a FQDN? Or is it still giving you the option of
changing to a workgroup? The former is fine -that's what happens.

Change the workgroup name and reboot. Then, once you've ensured that the
computer account is no longer in the directory, try joining the machine to
the domain with a different user account.

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/
 
One more observation: After removing the server from the domain, adding it
to a workgroup and rebooting it still claims domain membership in the Network
Identification tab of the computer's properties.
Click to expand...

Do you mean it still has a FQDN? Or is it still giving you the option of
changing to a workgroup? The former is fine -that's what happens.[/QUOTE]

After moving it to the workgroup and rebooting it still has a FQDN. In
the 'Network Identification' tab it still reads 'computer.mydomain.com'.
Also it still has the domain name in the 'domain' text field and this
text field is selected. I can then again change into the workgroup, but
it reverts to FQDN after reboot.
Change the workgroup name and reboot. Then, once you've ensured that the
computer account is no longer in the directory, try joining the machine to
the domain with a different user account.
Click to expand...

I will try that and keep you posted. Thank you for your comments.

Karsten
 
By default, it will not remove the FQDN. This is fine, as it is just a DNS
name and at this point has no real bearing on AD. You can remove it, but is
there really any reason for doing so? Best bet is to try and change to a
different workgroup and see what happens. Then you can delete the computer
object from AD and rejoin the domain.

Keep us posted : )


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


One more observation: After removing the server from the domain, adding
it
to a workgroup and rebooting it still claims domain membership in the
Network
Identification tab of the computer's properties.
Click to expand...

Do you mean it still has a FQDN? Or is it still giving you the option of
changing to a workgroup? The former is fine -that's what happens.[/QUOTE]

After moving it to the workgroup and rebooting it still has a FQDN. In
the 'Network Identification' tab it still reads 'computer.mydomain.com'.
Also it still has the domain name in the 'domain' text field and this
text field is selected. I can then again change into the workgroup, but
it reverts to FQDN after reboot.
Change the workgroup name and reboot. Then, once you've ensured that the
computer account is no longer in the directory, try joining the machine to
the domain with a different user account.
Click to expand...

I will try that and keep you posted. Thank you for your comments.

Karsten
 
Problem solved, and here's how; as I had reported previously, the server
would always default back to being a domain member in its System
Properties after taking these steps:

- removing the server from the domain and joining it to a workgroup
(while receiving an error message that the domain account could not be
disabled)
- removing the computer account in AD
- rebooting

This pointed to a local problem, instead of a problem in AD. Therefor I
decided to take the DNS suffix into account and to take the following
steps:

- removing the server from the domain and joining it to a workgroup
(while receiving an error message that the domain account could not be
disabled)
- changing the primary DNS suffix to a random name
- removing the computer account in AD
- joining the server to the domain
- rebooting

These steps returned my server into the state of being a fully qualified
domain member.

Paul, I wanted to try your suggested solution, but I couldn't as the
server always defaulted back to being a domain member after rebooting.
I'm a bit puzzled about the cause, but relieved that it works now :)


ptwilliams said:
By default, it will not remove the FQDN. This is fine, as it is just a DNS
name and at this point has no real bearing on AD. You can remove it, but is
there really any reason for doing so? Best bet is to try and change to a
different workgroup and see what happens. Then you can delete the computer
object from AD and rejoin the domain.

Keep us posted : )


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net




Do you mean it still has a FQDN? Or is it still giving you the option of
changing to a workgroup? The former is fine -that's what happens.
Click to expand...

After moving it to the workgroup and rebooting it still has a FQDN. In
the 'Network Identification' tab it still reads 'computer.mydomain.com'.
Also it still has the domain name in the 'domain' text field and this
text field is selected. I can then again change into the workgroup, but
it reverts to FQDN after reboot.
Change the workgroup name and reboot. Then, once you've ensured that the
computer account is no longer in the directory, try joining the machine to
the domain with a different user account.
Click to expand...

I will try that and keep you posted. Thank you for your comments.

Karsten
[/QUOTE]
 
Back
Top