Crossing Domain Boundaries: Windows Authentication

Today, majority of applications on the Microsoft platform rely on or provide support for integrated Windows authentication. Using integrated Windows authentication allows applications to completely avoid persisting custom login credentials and thus eliminates the possibility of an attacker finding them in a configuration file, registry or database and gaining unauthorized access to the system. Microsoft has been promoting use of integrated Windows authentication for years and most software vendors (or perhaps just those who truly care about having customers on the Microsoft platform) support it as an option in their products.

As a consultant, I feel obligated to advise my clients on using integrated Windows authentication as the most secure authentication mechanism for their networks and custom solutions. Unfortunately, as a consultant, I also need to access my clients’ networks from my Catapult laptop, across domain boundaries. This is where integrated Windows authentication makes my job more difficult. Typically, I cannot use my Catapult domain credentials to access resources on the client’s domain and have to supply an alternative set of Windows credentials explicitly. Some applications, like Internet Explorer and Visual Studio are smart enough to prompt you to enter Windows credentials when necessary. While these applications may prompt you to enter credentials more often than you might like, other applications don’t prompt you at all and simply fail. In particular, database applications connecting to SQL Server will not prompt for credentials and display the infamous “Cannot establish SSPI context” error when you try use them across domain boundaries.

Thankfully, there is a relatively small number of tricks you need to use to get most applications using integrated Windows authentication work successfully across domain boundaries. These tricks are described below, but before you rush to try them, make sure you have configured name resolution and can successfully connect to a network resource on the target domain using it’s name. Windows authentication will not work without successful name resolution.

Stored user names and passwords

Windows allows you to store login credentials for various authentication mechanisms, including Windows or Active Directory credentials. You can store a single Windows login (CLIENT\account) and password for an entire domain (*.client.lan) and Windows will use these credentials automatically whenever you access any computer on it.

Not all types of applications support stored user names and passwords. HTTP applications, such as Internet Explorer, Team Foundation Explorer in Visual Studio, and other applications using WebClient, are one of them. Whenever you type http://target.client.lan in Internet Explorer, the WebClient will send the matching stored credentials to the target computer automatically, without prompting you. Windows Explorer, Performance Monitor, Event Viewer and other applications relying on network shares also support this mechanism. As long as you have credentials stored, these applications will just work, as if your computer was a member of the target domain. Here is how you set it up.

  • Open User Accounts from Control Panel and click the Manage your network passwords link on the left.


  • If you are using an older version of Windows, such as XP or 2003 Server, you will need to click the Manage Passwords button on the Advanced tab of the User Accounts dialog.


  • In the Stored User Names and Passwords dialog you need to click the Add button and create a credential entry for the target domain you need to access. Assuming that one of the computers you need to access has a fully-qualified domain name target.client.lan, you want to store credentials for a wildcard *.client.lan, which will used when you access any computers on that domain.

You can find more information about storing user names and passwords in the Microsoft knowledge base article 281660.

Internet security zone

As an added security measure, Internet Explorer will send your current or stored credentials to the target host only when it believes to be a member of the Intranet zone. It will assume that any host addressed with a fully-qualified domain name such as target.client.lan is on the public internet and will not send the credentials automatically. This protects your identity from being stolen by a rouge web site getting your Windows credentials without your permission.

As you can see from the snapshot of Internet Explorer security settings below, even adding the target host to the list of trusted web sites will not work.


In order for Windows authentication to work automatically across domain boundaries, without you having to type in your credentials for every page, you will need to add a particular host or its entire domain to the Local Intranet zone.

  • Select Internet Options in Control Panel
  • On the Security tab of the Internet Properties dialog, select Local intranet icon and click Sites button
  • In the Local intranet dialog, click Advanced button


  • In the second Local intranet dialog, enter URL of the web site and click Add button.

Just like with stored user names and passwords, you can use wildcards that apply to all computers on the target domain. For example, if you enter http://*.client.lan, Internet Explorer will consider target.client.lan and all other computers on the client.lan domain to be in the Local intranet zone and send stored user names and passwords to them automatically.

WebClient configuration

Unfortunately, Microsoft Office applications will continue prompting you to enter credentials when accessing files stored on a SharePoint site even after you add the target domain to the Local intranet zone. You will need to modify WebClient configuration in registry to prevent this from happening.

  • Open HKLM\System\CurrentControlSet\Services\WebClient\Parameters key in Registry Editor.


  • Double-click the AuthForwardServerList value
  • In the Edit Multi-String dialog, enter the target URL on a separate line and click OK.


This setting also supports wildcards. If you enter http://*.client.lan, Microsoft Office applications will automatically send stored Windows credentials to any SharePoint you access on the client.lan domain. You can learn more about this in Microsoft knowledge base article 941050.

Runas /netonly

Some applications don’t support stored user names and passwords. For example SQL Server Management Studio will not be able to connect to a database on a different domain using Windows authentication. In these cases you can use the runas command with netonly option and make the application access network resources under a different set of credentials.

c:\>runas /user:CLIENT\account /netonly ssms.exe
Enter the password for CLIENT\account:
Attempting to start ssms.exe as user "CLIENT\account" ...

When started with the command line above, SQL Server Management Studio will use CLIENT\account to connect to all SQL servers instead of the actual account you used to log into your computer (CATAPULT\osych in my case). In other words, if you need to connect to a database on sqlserver.client.lan, it will use CLIENT\account credentials you supply.

This trick works for all applications that need to connect to SQL Server using integrated windows authentication, not just SQL Server Management Studio. You can use it to run Visual Studio (devenv.exe) and your custom applications.

You can also use the ShellRunas utility to provide netonly credentials interactively. Once you downloaded and saved the utility in a permanent location on your hard drive, you will need to register it like so.

c:\Program Files (x86)\SysInternals>ShellRunas /reg /quiet  

c:\Program Files (x86)\SysInternals>ShellRunas /regnetonly /quiet

The registration adds Run as different user and Run as different user (netonly) menu items to the shell (i.e. Explorer) context menus for executables.


You can start Visual Studio with netonly context by right-clicking it in the Start menu and selecting the option. Simply provide the credentials required by the target computer you want to access on the other domain and click OK.


While you can also run an application completely under another account, not just netonly, this will only work if the domain you are trying to access has a trust relationship with your own domain. Even then, running an application completely under another account is less convenient than netonly because it runs in a different user profile, loosing your settings, shortcuts and favorites. Remember to select netonly option as it is easy to accidentally omit it.

Local accounts

If none of the options described above works, your last resort is local accounts and workgroup authentication. In workgroup mode, when there is no Active Directory domain controller, i.e. no centralized authentication authority, Windows relies on having matching local accounts on all computers in a workgroup. For example, an application running under local Administrator on your computer, let’s say it’s called CATLAPTOP, can access computer called TARGET on another domain under its local Administrator account as long as CATLAPTOP\Administrator and TARGET\Administrator accounts have the same passwords on both computers. This works for any account, not just Administrator, subject to permissions assigned to the local account on the target computer.

Using local accounts and workgroup authentication appears to be the recommended approach for some advanced cross-domain networking scenarios, such as remote debugging and SQL Server integrated security. However, these particular scenarios work with runas/netonly approach as well. Unlike the workgroup authentication approach, runas/netonly doesn’t require you to get access to a local account on each target computer. Maintaining these accounts is a hassle for IS administrators and they are typically reluctant to do it. You will probably want to use this option only as a last resort.

If you have to use this option, make sure that your local security policy allows workgroup authentication.

  • Select Local Security Policy from Control Panel under Administrative Tools
  • In the Local Security Policy console, find Security Options under Local Policies


  • Make sure that the Network access: Sharing and security model for local accounts option is set to Classic - local users authenticate as themselves.


Relying on integrated Windows authentication and Active Directory for centralized authentication is a great way to make information systems in your organization more secure. While making life of users and administrators easier by allowing them to use and manage a single set of login credentials for various network resources and applications, integrated Windows authentication presents an additional barrier when you need to access network resources across domain boundaries. Luckily a relatively small set of configuration changes can help you solve most of these difficulties.

This article describes configuration changes and utilities in the order from easiest and most commonly used to most difficult and infrequently used. You will probably want to store credentials for the new domain and add it to the Local intranet security zone first. This enables most modern applications to access network resources on the target domain without errors and without bothering you with constant prompts for credentials. If you need to access Microsoft Office documents on a SharePoint site, you may also want to configure WebClient to automatically use your stored credentials instead of prompting you every time. For advanced scenarios, such as database applications and remote debugging, use the runas command with netonly option or its interactive equivalent, ShellRunas. If all other options fail, you may have to resort to using local accounts and workgroup authentication.

Name resolution and authentication are not the only problems you have to solve to access network resources. Advanced scenarios may require you to make changes in firewall, group policy, security policy, registry and file configurations a particular application may be affected by. Discussion of these scenarios is outside of scope of this article. You can usually find specific instructions in Microsoft knowledge base.

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

[…] Using Windows Authentication across domain boundaries in enterprise environments is generally the source for many long hours trying to pin down the problem. As usual, Oleg Sych has a very useful article on the matter. […]

Oleg, Thanks for this post it helped us solve an issue where we had a SharePoint server as an Extranet with users wanting to open the workbooks locally. Every time a user wanted to refresh data it failed with a Data Connection Initialisation failure message. Once I had implemented the steps in your document the refresh works fine and allows users to save their own local workbooks. So thanks foryour post. Tom


Thanks for the Great post.

We have a SharePoint Web application that uses basic authentication over SSL and i configured all the above and still when I open a word documents it prompts me for the user id password (of course, if I save the userid/password, the system expects me to click OK with userid/password populated).

We use the Basic, because there are few computers which in in the internal network but not connected to the domain for business reason. Could we do the same with those computers and will it work. If it will work, can we automate this process using SMS or some AD policy or do we have to go thru some client application.


Thanks. I was trying to run the Visual Studio Remote Debugging Monitor, but whenever I would use runas, I would get an access denied error. Using /netonly fixed the problem. I guess msvsmon is one of those programs that doesn’t support stored user names and passwords.

Unfortunately, I still need local accounts on both remote and local machines, in addition to using /netonly. But at least I can debug an application running under a different user.

In the “Web Client configuration” section, the AuthForwardServerList key may not already exist. In that case, create the key as a new Multi-String Value and continue with the instructions.

A couple of comments regarding Windows 7:

- the User Credentials Management UI has changed significantly. However, the credentials management tips in this article still apply.

- Holding down Shift when you right click will reveal a “Run as different user” command. It is not clear if this is “netonly” mode or not.

Great info… priceless info thank you very very much! I was having several issues trying to connect to a sql server, and after a couple of hours testing I found this post and taraaaaaa worked just fine.

great piece of article. even i used this to connect to websites across domains. great info. thanks Oleg. keep writing…

Fantastic article Oleg. One quick question, as I’m doing this for the first time in MS SQL management Studio (2005) (Common7\IDE\SqlWb.exe) due to reading this article I’m not sure what to expect.

If I runas /regnetonly specifying the client’s domain account credentials would you expect then to see in the greyed out part of the SQL login/connect panel the client account details or the account details of the locally logged in user?

I’m still seeing the account I’m logged in as which I wouldn’t expect. Is runas not working correctly, or is it just a UI glitch?

Thanks, Phil. To answer your question, when you start applications like SQL Server Management Studio, using runas /netonly, you can expect to see your own domain account. However, the application will still use the credentials you supplied in the runas command to connect to the network resources.

Fantastic article, thanks!
Do you know (probably), why SQL Management Studio has a such weird behaviour? Why they don’t use built-in credential manager?

Thanks for this.

I’ve been testing security on a solution and there is something I don’t understand about integrated security and local accounts. Somehow I am able to bypass integrated security in my .NET 2.0 web solution by just adding a domain to my local intranet settings in IE 8 in my client. Is windows storing user/passwords in a way that not even clearing cache or rebooting deletes? My client user is logged in with the same user name, but on a different domain and with a different password. Annonymous access is off and integrated is on.

[…] much googling I finally came across this gem: I had tried doing a shift-right click Run As Different User already, but I received an error […]


great post, but does not work for my xp machine. it’s like it does not recognise * or it doesn’t remember the password. Have you any clues?


Great post, I tried this it works for me..But I am not able to debug in multiple web applications with in same solution and on same computer.

Please help!!

To quote a meme: “Are you a wizard?”
The /netonly worked perfectly, and I’m super stoked. I want to confirm that this works for Windows 8 as well. Thanks!!

Thank you!

For other people like me, coming here because they want to connect to sql server and have the following error message in their server’s Application Event Logs:
“Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.”

Solution: When storing your credentials you need to append the port number to the server adress! (in case of sql 1433)

[…] much googling I finally came across this gem: I had tried doing a shift-right click Run As Different User already, but I received an error […]