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).
Related
We manage several laptops that are used for emergency situations and thus are rarely used (knock on wood).
When we start up these laptops periodically to run windows updates, we also sign in with several user accounts for each laptop in order to keep the profile up to date.
Is there a way to automate the logging in of each account with a script?
For example, I could log in as administrator, run the script and the laptop would do the following:
Log out my administrator account,
sign in with useraccount 1, log out
sign in with useraccount 2, log out
sign in with useraccount 3, log out
I havent had much luck in googling this type of thing and was hoping someone here might have an idea.
I simply cant find a script that logs in with a user account.
The closest I can find is recommending auto signin but that only applies to one account and not what I need for this task.
Globally, you can't do that: it would break security if you were allowed to interact, programmatically, with the login screen.
IF it's possible, I would look to a way to do the login to remote machine through either Telnet (not recommended! but can be done with standard Windows tools) or SSH (will need a SSH server). If you can do the upgrade this way, then you're saved, in particular with SSH because you can avoid passwords' sharing through key exchange - probably won't work with domain accounts, however, but local accounts will be fine.
Otherwise, if you require to really open a Windows session, best you can do, IF your configuration allows it AND if it works (regarding the profile's update) is to connect through RDP (Remote Desktop) to each laptop, with each login.
You'll need to establish a RDP connection to each laptop from a "pilot" PC, save each connexion individually within a .rdp file, saving password inside the connection file.
Then, you can launch the connection with the command mstsc <machine+account>.rdp to establish a connection. A bit later, you can kill the connection (with either taskkill or through a pilot process / tool, I would use AutoIt for this preferably).
If password saving is an issue, then each employee should have its own set of RDP files. Through something like Autoit, in particular, you can input the password once, and fill automatically each password prompt.
The tricky part would be to know when it's time to close the remote desktop. I would try to automatically execute a command to distant computer that would reboot it once done, so your remote desktop would close automatically.
Anyway, it will be a real gas plant to implement all this in a smooth process...
I am wondering if it's possible to use the 'net user' command in Windows to pull up details on a user in a different domain? The domain is connected to us. For example, I can log in as that user in the other domain from the same network.
This is the net user command I use to pull my local details:
net user myusername /domain
Is there a way to specify a different domain name? Or are there other commands that will do something similar? I'm am wanting to use a command to verify the password expiration date on the other domain.
No, you cannot use it that way. The /domain flag is used just for specifying that the command should be run on the primary domain controller for the domain that you are in. Otherwise, the command runs on the computer (server) where you are running the command.
https://support.microsoft.com/en-us/help/251394/how-to-use-the-net-user-command
You can, however, use PowerShell cmdlets to manage users in Active Directory. The following documentation is for the Get-AdUser cmdlet.
https://technet.microsoft.com/en-us/library/ee617241.aspx
You probably want to pass in the Identity flag and specify the full Distinguished Name for the user object. For example: -Identity "CN=SaraDavis,CN=Europe,CN=Users,DC=corp,DC=contoso,DC=com"
Try to issue following command in powershell
Get-ADUser "username" -Server "domaincontroller.localdomain"
You can log onto a virtual machine or windows server on that domain and run the same command to get that domain user's details.
Powershell like in Matson's answer is probably the better option if you rarely have machines open on that domain, but if you are already working on a machine in that domain your command works just fine.
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
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.)
I'm trying to connect to a remote password protected shared folder from a Windows service, which runs as LocalSystem account. It seems that the LocalSystem account is unable to directly access password-protected network shares using WNetAddConnection2() or similar calls.
Can anyone confirm this?
I've read that impersonating an administrator user might be the way to go.
I've tried using LogonUser() and ImpersonateLoggedOnUser() before WNetAddConnection2(), it appears that the mount of the network path succeeds, but then actual accesses (e.g. enumerating of files in remote folder) fail.
Any ideas?
Thanks.
I just encountered this problem as well, and found that if I put the remote computer name into the user name, it worked. (I didn't actually figure this out, we had another place in the code already doing this that worked, so I knew it was possible, and finally figured out the difference.)
So for example:
WNetAddConnection2(&nr, "password", "SomeComputer\\Username", 0);
I'm not doing any other special calls like LogonUser or ImpersonateLoggedOnUser.
This is in a service running under the SYSTEM account.
I haven't tried using the SomeComputer\Administrator account, but that's not exactly a good practice anyway. I'm using a normal user account on SomeComputer.
To tell the trust I worked all time only in a domain environment and without password-protected network shares, but I know that there are two main ways to make a connection: WNetAddConnection2 API and NetUseAdd API. I recommend you to try NetUseAdd function with Level equal to 1 (USE_INFO_1). I used only USE_INFO_2 which has ui2_username, ui2_domainname and ui2_password, but USE_INFO_1 has only ui1_password, so it looks like a function made for connection to a password-protected share.
By the way, LogonUser() has really no sense, because it makes local login on the local computer and you need to establish a session to the remote computer. This do WNetAddConnection2 and NetUseAdd functions.
The way you can access network share from a local system account(which is "NT AUTHORITY\SYSTEM"):
You need to log on using some local account that has access to netowork even in non-domain net. It's enough to use "NT AUTHORITY\NETWORK SERVICE" account to gain this
Add network share connection with specifying it's access credentials:
The main point here is to use LOGON32_LOGON_NEW_CREDENTIALS logon type during LogonUser() call (see MSDN for details/restrictions). Otherwise you'l get ERROR_NO_SUCH_LOGON_SESSION when executing WNetAddConnection2(), even if LogonUser and impersonation succeded.
LogonUser("NETWORK SERVICE", "NT AUTHORITY", NULL, LOGON32_LOGON_NEW_CREDENTIALS, LOGON32_PROVIDER_WINNT50, &hToken );
ImpersonateLoggedOnUser(hToken);
NETRESOURCE nr;
nr.dwScope = RESOURCE_GLOBALNET;
nr.dwType = RESOURCETYPE_DISK;
nr.dwUsage = RESOURCEUSAGE_CONNECTABLE;
nr.dwDisplayType = RESOURCEDISPLAYTYPE_SHARE;
nr.lpRemoteName = "\\\\SomeCopmuter\\C$";
nr.lpLocalName = "Z:";
WNetAddConnection2(&nr, "password", "Administrator", 0);
Notes
Impersonation woks only for current thread.
with local resources it will work as LocalSystem, with the added share it will work as user on remote computer specified in WNetAddConenction2 (in this case - Administrator on SomeComputer).
You can omit using drive letter in NETRESOURCE and access files via "\server\share\filename.ext" notation
This may not work on some old systems (NT/2000, don't know exact list)
I'm actually grappling with the same problem right now, Flavio, and my current suspicion is that it works if someone is interactively logged on to the machine, and will return ERROR_NO_SUCH_LOGON_SESSION if no one is logged on. I may be wrong, though. More to come. I've starred this question and will check back :)
import win32wnet from win32netcon import RESOURCETYPE_DISK as DISK path="\192.168.1.11\Student" win32wnet.WNetAddConnection2(DISK,"R:","\192.168.1.11\Student",None,"Student","pass",0)