Sooner or later, domain network administrators based on Microsoft products have to deal with two similar errors: “It was not possible to establish a trusting relationship between this workstation and main domain" and "The Account Manager database on the server does not contain entries to register the computer through a trust relationship with this workstation." In addition to these messages, it is also impossible to log into the computer using domain accounts.

Let's look at the causes of errors and methods for treating them.

In domain Windows networks All computers and user accounts are assigned their own security identifiers (SIDs). In essence, we can say that each computer in the domain also has its own computer account. Similar to a user account, such an account will also have a password. This password is created and presented by the computer to the domain controller automatically. Thus, the trust relationships mentioned in the error text are formed between the workstations and the domain controller.

Every 30 days, or when you turn it on for the first time after a long break, the computer automatically changes its password. In theory, everything is beautiful, and the machine seems to be unable to make a mistake and “input” wrong password. However, sometimes this happens for several reasons.

A trust relationship between this workstation and the primary domain could not be established

The most common reason is an operating system rollback Windows systems to an earlier state. Naturally, the earlier the recovery point was created, the greater the likelihood of an error occurring. IN in this case after recovery, the computer will begin to present the outdated password to the domain controller, and the controller already contains the new one.

An error may also occur if there are two stations with the same names in the domain. This situation can arise, for example, if you give a new computer the name of a decommissioned machine, and then turn it back on old computer, forgetting to rename it.

WITH possible reasons figured it out. Now about solving the problem. There are several ways, but they all involve reinstalling in one way or another account computer or reset its password.

First way consists of reinstalling the account in .

After this, you need to log into the computer under local administrator and move the workstation from the domain to the workgroup (computer → properties → Extra options system → computer name → change).

Second way is to reset your password via . Let's make a reservation, however, that we will need PowerShell version 3.0 and higher. We also log into the computer as a local administrator and enter the following cmdlet:

Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin

In this case, -Server is the name of the domain controller, and -Credential is the domain administrator account.

The cmdlet will not display any messages if it completes successfully. This method It is attractive because a reboot is not required - just change the user and log into the machine under a domain account.

Third way Resetting your computer password involves using the utility Netdom, which appeared in Microsoft server operating systems starting with Windows Server 2008. On client operating systems, it can be added using the RSAT package (Tools remote administration server).

As in the previous methods, this one is also performed as a local administrator. Enter in command line:

Netdom resetpwd /Server:DomainController /UserD:Admin /PasswordD:Password /SecurePasswordPrompt

The principle is similar to what we saw in the PowerShell example. /Server is the domain controller, /UserD is the domain administrator account, /PasswordD is the password for the domain administrator account. You can also use the /SecurePasswordPrompt parameter to hide the password behind asterisks. No reboot is required either.

Method four and the last one in our article is to use the utility Nltest, which is available by default on any workstation.

Let's run the utility on the command line and first check secure connection with domain:

Nltest/query

Then reset the computer account in the domain:

Nltest /sc_reset:Domain

And finally, reset your computer password:

Nltest /sc_change_pwd:Domain

Unfortunately, such an excellent utility has its drawbacks. First of all, the utility does not ask for the domain administrator login/password and, accordingly, is executed under the user who launched it, which can lead to an access error.

There is one more mistake related to trust relationships within a domain and is listed at the beginning of this article. It looks like this:

In this case, the utility will help us again Nltest. We check the secure connection to the domain again:

Nltest/query

If an error message appears, then to fix the error, just install this patch. If the connection status is NERR_Success, then we execute the following actions:

netdom reset /d:Domain ComputerName netdom reset /d:Domain ComputerName /server:DomainController /uo:Admin /po:Password

In the second case, we explicitly specify the domain controller with which we want to establish a trust relationship.

The utility will please us with a message that the secure channel has been reset and a new connection has been established.

So, here are some ways to restore trust in your domain. I hope that you will have to use them as little as possible. 🙂

One of the periodic errors that one has to face is system administrator this is the error "A trust relationship could not be established between this workstation and the primary domain." This error appears when a user tries to log in to the system, enters a username and password, and ultimately receives this message. In most cases, this involves rolling back the system to a higher level. early state.

What is the reason for this behavior? The fact is that a computer account connected to a domain is assigned a security identifier (SID) at the level of which access to the domain is provided, as well as a password that is automatically changed every 30 days without user intervention.

So, at the time of restoring the checkpoint, the system can be restored to the moment when it was still in effect Old Password and when connecting to a domain, the password on the workstation and the domain controller will be different, which will cause the error “It was not possible to establish a trust relationship between this workstation and the main domain.” In this situation, it is necessary to ensure that these passwords match!

Despite this, access to the workstation can still be obtained; to do this, you need to disable network cable from the computer and enter the password again. As a result, there will simply be nowhere to send the data for verification, and the system will let you in, since you entered the password for your account correctly. After that, we connect the cable and work. But this is not a solution to the problem, since these manipulations will need to be performed every time, and certain functions will not work.

There are several methods that allow you to do this, the simplest one is to remove the workstation from the domain, and then register it again. To do this, first remove the computer from the domain by connecting to an arbitrary workgroup (My Computer\RMB\Properties\Computer name, domain name and settings working group\ Change settings \ Change \ Is a member of a workgroup \ 123 \ OK ), and then connect back by entering the domain name and reboot.

These actions should be performed under a local administrator, since you may simply not be allowed in under a domain administrator account! In this situation, if you do not know the local administrator password, you will have to reset this password. I already talked about this in the lesson Resetting the Windows XP Vista 7 2003 2008 account password and Resetting the Windows 7 administrator password

Although, some recommend that in order to resolve the error “It was not possible to establish a trust relationship between this workstation and the main domain” in the future, disable the Startup Repair service altogether so that the rollback does not occur in automatic mode. But, here I would be careful and carry out this shutdown as a last resort, so as not to reduce the amount of funds for restoring performance when possible failures at work. In any case, if the rollback is performed periodically, it is better not to disable the service, but to understand the essence of the problem!

Every system administrator encounters the error “A trust relationship between this workstation and the primary domain could not be established” from time to time. But not everyone understands the causes and mechanisms of the processes leading to its occurrence. Because without understanding the meaning of current events, meaningful administration is impossible, which is replaced by mindless execution of instructions.

Computer accounts, like user accounts, are domain security principals. Each security principal is automatically assigned a security identifier (SID) at which level it can access domain resources.

Before you grant an account access to a domain, you must verify its authenticity. Each security participant must have its own account and password, and a computer account is no exception. When connecting a computer to Active Directory an account of the "Computer" type is created for it and a password is set. Trust at this level is ensured by the fact that this operation performed by a domain administrator or other user with explicit authority to do so.

Subsequently, each time the computer logs into the domain, it establishes a secure channel with the domain controller and provides it with its credentials. Thus, a trust relationship is established between the computer and the domain and further interaction occurs in accordance with installed by the administrator security policies and access rights.

The computer account password is valid for 30 days and is automatically changed thereafter. It is important to understand that the password change is initiated by the computer. This is similar to the process of changing a user password. Having discovered that the current password has expired, the computer will replace it the next time you log into the domain. Therefore, even if you have not turned on the computer for several months, the trust relationship in the domain will remain, and the password will be changed the first time you log in after a long break.

Trust is broken when a computer attempts to authenticate to a domain with an invalid password. How can this happen? The easiest way is to roll back the state of the computer, for example, standard utility system recovery. The same effect can be achieved when restoring from an image, snapshot (for virtual machines) and so on.

Another option is to change the account with another computer with the same name. The situation is quite rare, but sometimes it happens, for example, when an employee’s PC was changed while the name was saved, the old one was removed from the domain, and then they were reintroduced to the domain, forgetting to rename it. In this case, when the old PC is re-entered into the domain, it will change the password of the computer's account and the new PC will no longer be able to log in, since it will not be able to establish a trust relationship.

What actions should you take if you encounter this error? First of all, establish the cause of the violation trust relationships. If it was a rollback, then by whom, when and how it was performed; if the password was changed by another computer, then again we need to find out when and under what circumstances this happened.

A simple example: an old computer was renamed and given to another department, after which it crashed and it automatically rolled back to the latest one. control point. After which this PC will try to authenticate in the domain under the old name and will naturally receive an error establishing a trust relationship. With the right actions in this case, you will rename the computer as it should be called, create a new checkpoint and delete the old ones.

And only after making sure that the violation of trust was caused objectively necessary actions and it is for this computer that you can begin to restore trust. There are several ways to do this.

Active Directory Users and Computers

This is the simplest, but not the fastest and convenient way. Open the snap-in on any domain controller Users and Active computers Directory, find the required computer account and, by clicking right click mouse, select Reset account.

Then we log in on the computer that has lost the trust relationship under local administrator and remove the machine from the domain.

Then we enter it back; you can skip the reboot between these two actions. After re-entering the domain, reboot and log in under a domain account. The computer password will be changed when restart computer to the domain.

The disadvantage of this method is that the machine needs to be taken out of the domain, as well as the need for two (one) reboots.

Netdom utility

This utility is included in Windows composition Server starting with edition 2008, it can be installed on user PCs as part of the RSAT (Remote Server Administration Tools) package. To use it, log in to target system local administrator and run the command:

Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password

Let's look at the command options:

• Server- name of any domain controller
• UserD- domain administrator account name
• PasswordD- domain administrator password

After successful implementation The reboot command is not required, just sign out of your local account and sign in to your domain account.

PowerShell 3.0 cmdlet

Unlike the Netdom utility, PowerShell 3.0 is included in the system starting from Windows 8 / Server 2012, for older systems it can be installed manually, Windows 7, Server 2008 and Server 2008 R2 are supported. Required as a dependency Net Framework not lower than 4.0.

Similarly, log on to the system for which you want to restore trust as a local administrator, launch the PowerShell console and run the command:

Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin

• Server- name of any domain controller
• Credential- domain name / domain administrator account

When you execute this command, an authorization window will appear in which you will have to enter the password for the domain administrator account you specified.

The cmdlet does not display any message when it completes successfully, so just change the account, no reboot is required.

As you can see, restoring trust relationships in a domain is quite simple; the main thing is to correctly establish the cause of this problem, since different cases will be required different methods. Therefore, we never tire of repeating: when any problem occurs, you first need to identify the cause, and only then take measures to correct it, instead of mindlessly repeating the first instruction found on the network.

tough guy January 14, 2013 at 5:27 pm

Violation of trust between workstation and domain controller (solution)

Online with a fleet of 150 cars after the update operating system Before MS Windows 7, there was a constant problem with user login. One fine day, the user turned on the computer and discovered that he could not log into the system, but he saw a message that was stunning in its information content:
"Trust could not be established between this workstation and the primary domain"

There is only one solution. Take the machine out of the domain and bring it back in. When this situation began to repeat itself more than once a day, and I just got tired of it, I started thinking about prevention. And here the Internet remained silent. After some time of despondency, and despondency, as we know, is a sin, it was decided to dig. As a result of the torture of excavation, the reason was obtained in 99% of cases (and I suspect that the remaining 1% simply did not admit to the same reason). The reason is the Startup Repair service, which is enabled when incorrect termination work. On the first screen of the dialogue, the service asks the user whether to restore the system or not. If the answer is positive, the system rolls back to an earlier state and, possibly, the sid of the machine is broken. Be that as it may, the domain will not allow users with such a machine after such an operation. It is useless to rely on the user in such a matter. You can ask him to refuse if such a situation arises, but the user is very likely to press the “restore” button and then throw up his hands, saying the demon has misled him. In general, you need to batch disable the boot recovery service on n-machines.

Locally, the solution looks like a console command:

Reagentc.exe /disable

For the network you will need the PsExec utility from Microsoft package Sysinternals PsTools, a description of the utility and the package itself are

We put Psexec.exe in the same folder as ours batch file(let's call it broff.cmd)
inside broff.cmd we write:

::We get a list of computers on the network, clear it of garbage and put it in net.lst net.exe view /domain:megafon >>net.tmp for /f "tokens=1,2 delims= " %%i in (net.tmp ) do (Echo %%i>>net1.tmp) for /f "tokens=1,2 delims=\" %%i in (net1.tmp) do (Echo %%i>>net.lst) DEL *. TMP::We go through the list and disable boot recovery for /f "tokens=1,2 delims= " %%F in (net.lst) do (start psexec \\%%F reagentc.exe /disable)

That's all. The user is no longer our enemy.

Tags: Trust relationships, DC, IT, network administration, networks, deployment

There may be a situation where a computer cannot authenticate to a domain. Here are some examples:

• After reinstalling the OS on a workstation, the machine cannot authenticate even using the same computer name. Because in the process new installation OS is generated SID identifier and the computer does not know the computer object account password in the domain, it does not belong to the domain, and it cannot authenticate to the domain.
• The computer has been fully restored from a backup and cannot be authenticated. The computer object may have changed its domain password after archiving. Computers change their passwords every 30 days, and the structure Active Directory remembers the current and previous password. If it was restored backup copy computer with a long-outdated password, the computer will not be able to authenticate.
• Secret LSA computer has not synchronized with a password known to the domain for a long time. Those. the computer did not forget the password - it’s just that this password does not correspond to the real password in the domain. In this case, the computer cannot be authenticated and a secure channel will not be created.

Main features possible problems computer account:

• Domain logon messages indicate that the computer was unable to contact the domain controller, the computer account is missing, the computer account password was entered incorrectly, or trust has been lost ( secure communication) between the computer and the domain.
• Messages or events in the event log that indicate similar errors or suggest problems with passwords, trust relationships, secure channels, or communications with the domain or domain controller. One such error is Authentication Failure with error code 3210 in the computer event log.
• There is no computer account in Active Directory.

How to treat?

You need to reinstall your computer account. There are recommendations online for such a reinstallation: remove the computer from the domain and then re-join it. Yes it works, but this option It is not recommended to do this because the SID identifier and the computer’s workgroup membership are lost.

Therefore it is necessary to do this :

Open the Active Directory snap-in, select Users and Computers, right-click the computer object and use the Reset Account command. After this, the computer should be re-joined to the domain and rebooted.

Using an account related to local group"Administrators":

netdom reset Machine_name /domain Domain_name /Usero User_name /Passwordo (Password | *)

On a computer where trust has been lost:

nltest /server:Server_name /sc_reset:DOMAIN\Domain_controller