Tag: windowsserver

Posted on by

Active Directory: How to Repair a Broken Computer Trust Relationship Without Dropping to Workgroup

How many times have you powered on a company server that had been offline for months, or restored an old VM from a backup or snapshot, only to be greeted by the dreaded error: “The trust relationship between this workstation and the primary domain failed”?

The gut reaction of most system administrators, passed down through generations of Windows Server management, is almost always the same:

  1. Log in using the local Administrator account.

  2. Open system properties and move the machine back to a WORKGROUP.

  3. Reboot.

  4. Re-join the machine to the Domain.

  5. Reboot again.

It is a tedious, time-consuming process that can sometimes cause minor side effects with local user profiles, permissions, or local services. Fortunately, there is a surgical PowerShell method that allows you to reset the secure channel and regenerate the computer account password in under 5 seconds—without dropping the machine from the domain and without breaking local SIDs.

Why Does the Trust Relationship Break?

For security reasons, Active Directory forces domain computers to automatically change their computer account password every 30 days. If a server is restored from an old backup, cloned improperly, or if a new host inherits the same name in Active Directory, the passwords get out of sync. When you attempt to log in, the Domain Controller rejects the connection. The machine is still physically configured for the domain, but the secure channel is broken.

The Solution: The Test-ComputerSecureChannel Cmdlet

As long as the machine has network connectivity and can reach your DNS servers and Domain Controllers, you can repair the secure channel directly from within the guest operating system.

Step 1: Log in Locally

Log into the affected server using the Local Administrator credentials (e.g., .\Administrator).

Step 2: Verify the Issue

Open PowerShell as an Administrator and run the diagnostic command:

PowerShell

Test-ComputerSecureChannel

If the trust relationship is broken, the terminal will return a clear and definitive: False.

Step 3: Repair the Channel Live

To force the machine to renegotiate its password with the Domain Controller, run the following command:

PowerShell

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

A Windows credential prompt will pop up. Enter the credentials of a Domain Administrator (in the format DOMAIN\Username and password). This step is required to authorize the password reset on the Active Directory side.

If the operation succeeds, PowerShell will output the final verdict:

PowerShell

True

Conclusion

Once you see True, the secure channel is officially restored. In most cases, the effect is instantaneous and domain users can log in immediately. However, a quick reboot of the server is still recommended to properly refresh all network services and Kerberos tickets.

This surgical approach avoids tampering with the computer object container in Active Directory Users and Computers, mitigates the risk of messing up other machines if a name conflict occurred, and reduces downtime to zero. It is an essential one-liner to keep in every sysadmin’s toolbox.

Posted on by

Who can join a workstation to the Active Directory domain?

By default all domain users have the ability to add a workstation to the domain.

Limits on the number

The limitation on this task is that any one user can add a maximum of 10 workstations to the domain.

Impact

When the user reaches the maximum number of computers joined to the domain, he receives this error message

Who added a workstation to active directory?

To find out who added a workstation to the active directory, simply run this ppowershell script created based on this article:

Using PowerShell to Discover Who Added a Client to Your Domain

Clear-Host

Write-Host "I'm writing ms-DS-MachineAccountQuota"

# List the current value of ms-DS-MachineAccountQuota
Get-ADDomain |
Select-Object -ExpandProperty DistinguishedName |
Get-ADObject -Properties 'ms-DS-MachineAccountQuota' |
Select-Object -ExpandProperty ms-DS-MachineAccountQuota





Write-Host "Number clients in this environment"
Get-ADComputer -Filter * | Measure-Object | Select-Object -ExpandProperty Count
Write-Host "Number users in this environment"
Get-ADUser -Filter * | Measure-Object | Select-Object -ExpandProperty Count


Write-Host ""
Write-Host "Who did this?"
$Clients = Get-ADComputer -Properties ms-ds-CreatorSid, WhenCreated -Filter {ms-ds-creatorsid -ne "$Null"}
$Users = Get-ADUser -Filter *

ForEach ($C in $Clients)
{
ForEach ($U in $Users)
{
If ($U.Sid -eq $C.'ms-ds-creatorsid')
{
$C | Select-Object -Property @{
Name = 'ComputerName'; Expression = {$C.Name}},
@{Name = 'WhenCreated'; Expression = {$C.WhenCreated.DateTime}},
@{Name = "UserName"; Expression = {$U.Name}
}
}
}
}

Change the limit on the number of workstations

It is possible to modify this number by increasing it or bringing it to 0. If it is set to 0, users will have to have particular permissions to be able to add a computer to the domain.

To do this, from the domain controller, launch the adsiedit.msc command.

On the left, position yourself on the main node that begins with “DC=…”. Right-click -> Properties. The key with the number to change is MS-DS-MachineAccountQuota.

 

Restrict adding a workstation to the domain to a group

It is possible to limit the ability to add workstations to the domain to a group of users by acting directly on the GPOs

Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment

Look for the “Add workstations to the domain” entry and change it to specify only the users and groups that can perform the add operation.

Posted on by

Windows server – Active Directory – useful links

Move active directory roles from a domanin controller ti another

VERIFICARE E MODIFICARE I RUOLI FSMO DI UN DOMINIO WINDOWS

Backup Domain Controller

Aggiungere un Backup Domain Controller ad un dominio Active Directory esistente

Installing licenses for Remote Desktop

Licensing Mode for Remote Desktop Session Host is not Configured

Modalità gestione licenze di Desktop remoto non configurata