Run as different domain user on workgroup or EntraID joined device

Question

Hi, I would really like to run an application as an on-prem AD user, on a machine that is in a workgroup or EntraID joined.

The computer is located on an on-prem network and domain controllers are available and are DNS servers by default.

In the system I am an EntraID user. I’ll say right away that it exists only in EntraID; between on-prem ADDS and EntraID there is no synchronization of users (it is intentionally disabled).

So, they are on a machine on the same network with ADDS and have the addresses of domain controllers in the DNS settings.

However, when I try to run the application as a domain user, I get the error "Invalid login or password."

For example, by running: runas /profile /user:domain\user cmd

or via PS:

$Cred = Get-Credential

Start-Process powershell.exe -Credential $Cred -UseNewEnvironment

Okay, there are examples on the web where people use the "/netonly" key

https://yaplex.com/run-program-as-domain-user-from-non-domain-computer/

runas /netonly /user:domain\user cmd

However, I don't understand how this works. Because CMD runs as the current user, you can even enter the wrong password. No authentication happens, it doesn't work at all.

If I enable synchronization of this device and make it a hybrid. I also synchronize the domain user on whose behalf I want to run the program. Theoretically, I will be able to run applications in this case. However, I will not be able to login as an EntraID user if it is not synchronized with on-prem. If so, then this scenario is also not suitable.

What options are there to run applications using a domain user on a device that is in a workgroup or EntraID joined?

Thank you.

Answer 1

Hi @Mountain Pond , if I'm understanding your question correctly, you are trying to run an application as an on-premises Active Directory user on a machine that is not joined to the domain. In this case, you can use the "runas" command with the "/netonly" switch to run the application as a domain user.

The "/netonly" switch tells Windows to use the provided credentials for remote connections only. This means that the credentials will be used to authenticate to the domain controller, but not to the local machine.

Here's an example of how to use the "runas" command with the "/netonly" switch:

runas /netonly /user:domain\user cmd

This will open a command prompt window as the specified domain user. You can then run your application from within this command prompt window.

If you are still getting an "Invalid login or password" error, please double-check that you are using the correct domain name, username, and password. You can also try specifying the UPN (User Principal Name) of the domain user instead of the domain name and username, like this:

runas /netonly /user:******@domain.com cmd

Please let me know if you have any questions and I can help you further.

If this answer helps you please mark "Accept Answer" so other users can reference it.

Thank you,

James

Answer 2

Hello,

 

Thank you for posting in Q&A forum.

Yes, /netonly can be one option to achive the purpose.

Run as /netonly indicates that the user information specified is for remote access only. This parameter cannot be used with the /profile parameter.

For further details, pleas refer to below Microsoft Documentation: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771525(v=ws.11)#parameters

Meanwhile, you can try to build a VPN connection to access the domain network, hence you will be able to run applications by domain credentials.

Hope this answer can help you well.

 

Best regards，

Jill Zhou

Answer 3

Hello Mountain

Running an application on a machine that is not joined to the domain (in a workgroup or Azure AD joined) with credentials from your on-prem Active Directory can be a bit challenging due to the lack of a direct trust relationship between the non-domain-joined machine and the domain controller. Here are a few options you can explore to achieve this:

1.     Using /netonly option: The /netonly option with runas allows you to run a program on a workgroup machine with domain user credentials for network resources. While using this option, you may still need to provide valid domain credentials when accessing domain resources. This option does not authenticate you to the domain when you run the command.

Example:

Copy

2.     Create a credential for the domain user: You can create a PSCredential object with the domain user's credentials in PowerShell and then use the -Credential parameter to run the application with those credentials.

Example:

Copy$Cred

Start-Process -FilePath 

3.     Use Remote Desktop: If the application can be accessed remotely, you could consider using Remote Desktop to connect to a machine that is part of the domain and run the application there with domain credentials.

4.     Establish a trust relationship: If possible, you may consider establishing a trust relationship between the workgroup or Azure AD joined environment and the on-prem Active Directory domain. This would allow for seamless authentication and access between the machines.

5.     Consider VPN: If possible, establish a VPN connection from the workgroup or Azure AD joined machine to the on-prem network to facilitate domain authentication.

6.     Third-party tools: There are third-party tools available that can help with running applications as a domain user on non-domain-joined machines. Tools like Specops Gpupdate, BeyondTrust, or ManageEngine ADManager Plus could offer solutions to tackle this scenario.