Picture this scenario: You have a SharePoint farm and its associated Active Directory domain (Domain Controller A) in a traditional perimeter network, sandwiched between an external and internal firewall. Similar to the following diagram”
However, you want to authenticate against the SharePoint web server (which is a member of domain A) using your internal account, or an account from some other “foreign” and non-trusted Active Directory Forest (domain B).
This is easily configured by:
- Opening the internal firewall between domain controllers (IPSEC would be a good option here)
- Configuring a one way or two way trust between Domains A and B
- Running the people picker stsadmin command on the SharePoint farm
- Configure browser to send credentials for pass through authentication
Open the Internal Firewall
The easiest (and probably safest) way to open a firewall between domain controllers is to open just the IPSEC ports.
These are ports:
IP Protocol ID 50:
For both inbound and outbound filters. Should be set to allow Encapsulating Security Protocol (ESP) traffic to be forwarded.
IP Protocol ID 51:
For both inbound and outbound filters. Should be set to allow Authentication Header (AH) traffic to be forwarded.
UDP Port 500:
For both inbound and outbound filters. Should be set to allow ISAKMP traffic to be forwarded.It may be necessary to allow Kerberos traffic through the firewall, if so then UDP port 88 and TCP port 88 would also need to be forwarded. See KB233256
With just the above ports open, you can then configure an IPSEC policy on each DC to use IPSEC for all IP traffic between each other. See KB254949
When creating these IPSEC rules between domain controllers, I usually forego the certificate option, and use a pre-shared key instead. Since the number of systems involved is minimal, sometimes only two, I think it is easier to just enter a passphrase for the key instead of generating a certificate.
Configure a One-Way Trust
A two way trust would work as well but a one-way trust will work too, while providing additional security for the remote domain.
On the External DC
1. Open AD Domains and Trusts on the external.corp DC
2. Right-click external.corp, select Properties
3. Select the Trusts tab
4. Click New Trust
5. Enter internal.corp for the Name
6. Select One-way: outgoing (Users in the specified domain can be authenticated by this domain)
7. Select Both this domain and the specified domain
8. Enter Domain Admin Credentials for creating the trust on the destination (internal) domain
9. Select Domain Wide Authentication (Windows will automatically authenticate users from the specified domain for all resources in the local external.corp domain.)
10. Confirm the trust, and click finish
On the Internal DC
1. Open AD Domains and Trusts on the internal.corp DC
2. Right-click internal.corp, select Properties
3. Select the Trusts tab
4. Select the new Incoming Trust, click properties
5. Click Validate
Run the People Picker Command Switch
1. On all SharePoint servers in the Farm:
CD to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN
Run the following command to configure a password used for encryption:
STSADM.exe -o setapppassword -password SomePassword
2. Enable People Picker on the Front end Web Servers for each Web application where it will be used.
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv domain:internal.corp,<internal username>,<internal username password> -url http://www.companywebsite.com
Configure Browser for Authentication
Once you are able to add the trusted domain users to a secured SharePoint site via the peoplepicker, your users should be able to connect and authenticate. However, since the SharePoint site URL is likely not part of the Local Intranet Zone in the users’ browser, they will be prompted for authentication when connecting. To avoid this, you can enable pass through authentication by adding the SharePoint URL to the “Local Intranet Zone” list of sites on the user’s browser. A GPO or a Reghack would be a good way to accomplish this. If users are still prompted for authentication, double check their custom security settings and ensure the setting “Automatic logon only in Intranet zone” is checked.
Paul Beckford is an IT professional based in Denver, Colorado. Over the last dozen years, Paul has worked “hands-on” in an IT Operations role deploying and supporting a multitude of technologies, such as Network Infrastructure, Windows and Linux servers, most Microsoft Back Office & Infrastructure applications, Virtual Computing, Mobile Computing and Information Security.
When enabling people picker on the front end web servers the command uses a user account. Does this user account have anything to do with the password used for encryption?
If not, what user account do you suggest to use?
Hi Adam,
The password used for encryption is solely used for encryption or creating a hash algorithm, it has nothing to do with the command run on the webservers that utilizes a username and password from the internal domain. That account can be any account in the active directory domain, as any authenticated user can connect, but it should be an account with limited domain rights.
Paul
It’s good webpage, I was looking for something like this