Possible to use net user and get information about username on another domain? - windows

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.

Related

Unable to access UNC path via windows service even when using same user for service

I have a windows vm and have created an Admin user, let's say - AdminUser. I have mounted an azure file share to that user to Z: drive. The share can be accessed by unc path or the drive path. I also have a c# utility that checks if path exists and it returns true when I run it. This is all good. Now when I created a windows service with that utility and with same user credential, it throws an error that the path doesn't exist.
Things to note -
The service user or the user I used to login is a local adminstrator user and while creating the service, I had provided as "./AdminUser" to CreateService. Also provided password to config.
The VM is also connected to a domain. So I have users from default-domain\* and connected-domain\*. The connected-domain linked to an azure active directory.
Is there any other type of user I need to set as log on to service?
I can see here it says the local user can't access network resources but I am wondering since I mounted the path with proper credentials, does this matter?
Update:
Got the same issue when using running as with the exe.
runas /user:USER­NAME “C:\full\path\of\Program.exe”
We have to use cmdkey to store the credentials that can be used by SMB later. Launch a cmd.exe with the user that you want to use for the service using either context menu or command e.g.
runas /user:default-domain\domainServiceUser cmd
Then in the new command shell use cmdkey
cmdkey /add:<storagteAccountName>.file.core.windows.net\<shareName> /user:AZURE\<storageAccountName> /pass:<storageAccountKey>
Rerun the service and it should work.
If you want to also mount this as a persistent drive, you can use
Command Prompt
net use z: \\<storagteAccountName>.file.core.windows.net\<shareName> /persistent:yes
Powershell
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storagteAccountName>.file.core.windows.net\<shareName>" -Persist
Make sure that the user is exactly the same that would be used for the windows service including the domain i.e. use default-domain\domainServiceUser or ./AdminUser for running the cmdkey.
Though the user account is same, when the windows service runs as a 'user' the logon session that it gets is different than the interactive user session (which has the Z drive). Unless you programmatically load the Azure fileshare as a network drive in your code that is part of the Windows service, you won't be able to access it.

How to prevent "trust relationship between this machine and domain failed" error from happening when restoring VM from a snapshot?

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

Workstation has lost the trust relationship with the domain

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).

Determine Domain and username used to map a network drive

Using Windows 7 Enterprise with SP1, but I'm hoping to get a generic answer that would apply to Windows XP/2003/2008/Vista/7.
From a command prompt, I execute a net use command to map the Z: drive to a share on another computer, but I don't use my current credentials, I specify a different domain and user to map the drive.
net use z: \\rd-pc2037\C_DRIVE password /user:rd-pc2037\Administrator
The command completes successfully. Now that the drive is mapped, how can I find what Domain and Username I used to successfully map the drive? I can't seem to find what I want with the net use command.
C:\Users\rdomarat>net use
New connections will not be remembered.
Status Local Remote Network
----------------------------------------------------------------------------
OK Z: \\rd-pc2037\C_DRIVE Microsoft Windows Network
The command completed successfully.
C:\Users\rdomarat>net use Z:
Local name Z:
Remote name \\rd-pc2037\C_DRIVE
Resource type Disk
Status OK
# Opens 0
# Connections 1
The command completed successfully.
Checking the properties of the share in Windows Explorer and looking at the security tab showed me what permissions different people would have, but I didn't see how which DOMAIN\User I had used. I searched through the registry with limited success as well.
Any thought?
WMI is your friend:
> wmic netuse where LocalName="Z:" get UserName /value
UserName=rd-pc2037\Administrator
[anonymous suggestion 2022-08-07]:
Since Microsoft is gradually moving away from WMI,
Powershell/CIM is your future friend:
Get-CimInstance -classname Win32_NetworkConnection | select-object Remotename,Username
None of these answers help when using alternate credentials. They only show the current, local user. That doesn't help.
To view all stored credentials, use...
rundll32.exe keymgr.dll, KRShowKeyMgr
According to http://technet.microsoft.com/en-us/library/cc957215.aspx
the information you want is in the registry.
I have tried the wmic-command but it showed me the locally logged in user and not the "used DOMAIN\login"
The critical info from the link above:
Registry entry HKCU\Network\{Drive letter}\UserName is a REG_SZ that specifies the username (including domain name) whose credentials were used when the network drive was mapped.
Windows 11 -- some of this is useful, however Windows is still telling me that it has connected to a drive not listed in Windows Explorer, but which is not listed in computer, manage or net use or any of the options above. So Windows is storing connection information somewhere else.
There really should be a way to remove or replace persistent connections globally by username or servername.

windows batch file to call remote executable with username and password

Hi I am trying to get a batch file to call an executable from the server and login. I have a monitoring program that allows me send and execute the script. OK here goes....
//x3400/NTE_test/test.exe /USER:student password
Now this doesn't work. The path is right because when I type it in at the run menu in xp it works. Then I manually login and the script runs. How can I get this to login and run that exe I need it to?
Part 2:
Some of the machines have already logged in with the password saved (done manually). Should I have a command to first clear that password then login?
Thanks for any replies, I appreciate the help
Jake
(note: this question probably belongs on serverfault.com or superuser.com)
If the login that needs to happen is the login for the network share, you can have your script do that using the net use command:
net use //x3400/NTE_test /USER:student password
//x3400/NTE_test/test.exe
If the login is something specific to the ``test.exe` program, then you'll have to find out from its documentation how to pass credentials on the command line.
In either case, you need to consider the security implications of having a user's password in a script. If the user is has an account with the same name and password on the x3400 server as on the machine he's running on (or if the x3400 machine is in the same domain as his machine), there should be no need for him to provide credentials. This might be a better way to handle the password.

Resources