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