When you restore VM (that belongs to a windows domain) from (an old enough) snapshot you'll get this error:
trust relationship between this machine and domain failed
This happens because domain controller periodically renews computer account password (and maybe few other things).
Is there any way to configure domain controller (or anything else) in such way that this doesn't happen? I don't care about security risks/etc -- all this is in controlled environment.
Two solutions:
You can try the policy like #Harry mentioned to disable machine password: Reference: Domain member: Disable machine account password changes
Per the article: The Domain member: Disable machine account password changes policy setting determines whether a domain member periodically changes its computer account password. Setting its value to Enabled prevents the domain member from changing the computer account password. While not recommended for production environments, setting the value to Enabled his is what you would set the value at in your controlled environment which would eliminate the identified problem.
Another way to handle it is using PowerShell. This won't prevent it from happening but will solve it, you can put it in a script and use:
Test-ComputerSecureChannel –Server dc -Repair Reference: Test-ComputerSecureChannel
For those of us using a production domain controller, it's easier to do this on the VMs.
Set this in the registry to disable automatic machine account password changes:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters]
"DisablePasswordChange"=dword:00000001
If you ever get "The trust relationship between this workstation and the primary domain failed", one easy fix is to log in as local admin (or a domain account with network disconnected) and use the powershell Reset-ComputerMachinePassword cmdlet as follows:
$credential = Get-Credential
# Enter domain admin account when prompted
Reset-ComputerMachinePassword -Server ClosestDomainControllerNameHere -Credential $credential
Related
I'm investigating a failure in my Windows 10 Credential Provider. It calls out to LookupAccountName in order to get the SID of the user that is attempting to log in. Its per-user configuration uses the account SID as the key.
The failure scenario is as follows:
There is a mixture of local and domain accounts on a domain joined computer.
The computer is in an offline or otherwise disconnected state and cannot contact the domain controller.
The domain user has logged in to this computer in the past and its credential is cached.
The call to LookupAccountName fails with ERROR_TRUSTED_RELATIONSHIP_FAILURE (0x6FD)
Here's where things are interesting:
I can log in with a local account and then "Run As" the domain user. Then subsequent calls to LookupAccountName (even when run in the context of the local user) succeeds in looking up the SID of the domain user. It will continue to work until the computer is rebooted.
I've tried calling LookupAccountName as well as LsaLookupNames2. Both exhibit the same behavior. (I assume LookupAccountName is built off of LsaLookupNames2).
It doesn't look like the NetUser* APIs will help me, as I believe they are intended for local accounts.
Is there a way to lookup the account SID for an offline domain credential? Without requiring them to log in first?
Why does using "Run As" cause these APIs to suddenly work?
I am using powershell to get audit fail events 4625 and 4771 from the Domain Controllers. Most of these are 0x18 Status. Now i understand the events with usernames (don't end in a $) as having bad passwords from a machine. Most of the google examples show 4771's from users.
What i want to understand, is what it means when it is coming from a machine?
i.e. surely it is an account on the machine which has an issue, how does a machine have a bad password? And if it can, how does one find out what the issue is ?
Active Directory is an identity management system, and so anything that authenticates with Active Directory needs an "identity" of some sort. Since computers themselves can be joined to a domain and must authenticate against it (with a username and password via Kerberos the same as a regular user logon), they have a username. The AD machine account username is the computer's DNS hostname followed by a dollar sign, for example: Desktop-AB123$
Since every computer in the domain must authenticate against the domain with a username and password, it is possible for that authentication to fail. And it can fail for all of the same reasons that a regular user logon can fail: unrecognized or misspelled username, incorrect password, wrong domain or UPN suffix, or any number of authentication errors.
Event ID 4771 indicates a Kerberos preauthentication error and status 0x18 (usually) indicates a bad password. Source.
Machine accounts renegotiate their password automatically with the Domain Controller when they connect to the domain. If a domain-joined workstation is unable to communicate with a domain controller long enough for the password to expire, it will not be able to log in and you will get a failed logon for that computer's machine name. The computer will need to be rejoined to the domain (or have its password reset using Reset-ComputerMachinePassword and a domain admin credential). The same is also true if a domain controller is unable to communicate with the PDC Emulator. This will be the most common type of error that will lead to failed machine account logins. The second most common will probably be due to computers being renamed while unable to contact a DC, changing the computer's logon username without updating AD.
Beyond password expiration or computer renames, you have to start looking deeper for root causes. These are likely going to be Kerberos negotiation errors caused by services attempting to authenticate in order to perform certain actions. Note that the authentication error does not necessarily occur at service start and may occur when the service is accessed or triggered by another application. I recommend reviewing my question & answer in ServerFault regarding one such example where a server's DNS name didn't match its NETBIOS name, which caused Kerberos authentication to fail and fall back to NTLM.
As that ServerFault question illustrates, tracking down the root cause of a failed machine logon, once you've ruled out username and password errors, can be extremely difficult. Your first step should probably be to enable Netlogon debug logging and then searching the netlogon log file for your failure events. You can also search the SYSTEM event log for any events related to services failing to start. After those two starting points you're basically on your own and will need to develop some advanced troubleshooting and investigation skills to track down the root cause.
One final note, your question is not exactly related to programming or software development, so SuperUser or ServerFault might be a better place for questions such as this in the future. ServerFault is geared towards professional sys admins working in production environments while SuperUser is more geared towards hobbyists, enthusiasts, home servers, and DIYers.
Password complexity setting is disabled in default domain GPO. I need to enable it on one server, but I don't have the access to edit this GPO on the domain level. When I open local security settings on the server, option to enable (or disable) is grayed out. Is there a way to override default domain GPO for password complexity locally in the registry? And to keep it that way, to stop GPO from being propagated down from domain level to this particular server?
There are two moments in your case. First you can't use a local group policy for domain accounts because AD accounts store on only DCs. Only Domain Controller Polices. And ones apply only to user accounts. Not computer accounts. Second you can use a local group policy for edit settings for only local user accounts. Run the gpedit.msc command on local server for it.
But since Windows 2008 Domain you can separate password policy for different user groups. You can read about it here for example
https://technet.microsoft.com/en-us/library/cc770842(v=ws.10).aspx
Good luck.
Ok here is a tuffy.
I know that to rebuild the trust relationship you have to logon to the workstation as a local administrator and disjoin, then rejoin the domain.
My question is, is there a way to rebuild the trust relationship remotely? Does anyone have a script, utility, application or command that will rebuild a lost trust relationship?
Frequently (for us) the source of the problem behind "trust relationship" issues is that the machine account AD password is out of sync (the machine believes it to be one thing, the domain controller(s) believe it to be something else) and the machine is unable to authenticate to AD.
There's no need to disjoin first if the only thing that needs to change is the password. This can be fixed relatively easily by invoking the JoinDomainOrWorkGroup method of the Win32_ComputerSystem class. The catch is that the process must be run from the machine you wish to (re)join to the domain (otherwise, the machine account password won't get updated).
It can be done easily enough in PowerShell. Something like this (adapted from this TechNet contribution) would suffice:
$CS = Get-WmiObject Win32_ComputerSystem
$CS.JoinDomainOrWorkgroup($Domain,'','',$null,33)
That will join the machine to the domain using an existing machine account. You may have to specify a user and password, depending on how you get shell access to the remote machine.
Running it remotely does not have a one-size-fits-all solution. I usually use PSExec to get remote shell access and invoke the PowerShell command (using -EncodedCommand to negate the need for quoting).
How can I configure Visual Studio remote debugging when:
My developer machine is a member of an AD domain, and my username is "DevelopersName".
The "remote" machine is on the same Ethernet segment, but is not part of the domain.
The "remote" machine must run software under "RemoteUserName".
Most documentation I can find suggests that you need have both machines in the same domain and with identical usernames. That's not possible here.
I could possibly add my username to "remote", but the software still needs to run under "RemoteUserName.
If it helps, I could add 2nd network card to my developer machine and directly connect the "remote" machine.
Using VS2008, but will be moving soon to VS2010.
Thank you.
Sorry, but I've just spent the last 10 hours trying to debug your exact problem. My findings are not good.
You need to get your accounts synced, especially if you are using your remote app to connect to other systems in your SOA environment, ie: Sharepoint, AD.
You can to some extent get remote debugging to work, if you create an account on your local machine with the same name as that of your remote machine (lets do it like this rather rather than working with the domain account).
You then need to make sure the remote service is running under this account, and its a member of the administrators group. And by this I mean hold down control, and right click run as - with the remote debugger, and select the user (not required if remote server is logged in as the required user).
Run the wizard it will open the required ports, use Authentication, because non authentication won't debug managed code. Breakpoints are never met, and there is nothing you can do about this.
On your local dev machine, log off your domain account, and log onto the local account with matching name as the account on server thats running the remote service.
Now you stand a change of remote debugging. If you can't do any of the above, sorry there is no workaround, its entirely dependent on the user account and having the right permissions.
If you don't want to create a local account, try starting our debugger via command prompt using the following command:
runas /user:[user#machinename] /netonly [debugger.exe]
E.g.:
runas /user:john#mypc123 /netonly devenv.exe
I assume it's managed debugging you're talking about (for native debugging there's a remote debugging solution with no authentication). In this case, I would suggest that you use a local user to launch the debugger on your machine. If this local user's name and password match "RemoteUserName"'s name and password, it should work.
(Note that this does not preclude you from using the AD account to log in to your workstation, you just need to set up another account and use runas to launch Visual Studio.)