PortiBlog

SharePoint 2013 - One way trust on server 2012

8 mei 2014

We have recently deployed SharePoint 2013 on server 2012 & server 2012R2 for backend services to a global organization with exactly this scenario. We can say that it is working, but insure a careful planning and documentation is very important. In particular the following needed to be taken:

trust

 1. If you want to use Kerberos (and you should unless you have a very good reason not to) then as well as doing all the normal SPN work, make sure that you set up name suffix routing in your trust relationship so that domain A users are able to get a ticket from a domain controller in domain A.

2.Use fully qualified service names http://intranet.domaina.com not http://intranet or the above cannot work.

3.For the user profile import, use a service account in domain A to import users in domain B.

This will work without any problems

4. Using STSADM we can configure which forests and domains are searched for accounts by setting the peoplepicker-searchadforests property. The best part is that we can supply a username and password for a trusted forest domain.

SharePoint doesn’t allow you to store this username and password in plain text on the server. So you will have to configure a secure store. If you skip this step, configuring the search account for trusted domains will always fail with the following message.

Cannot retrieve the information for application credential key.

stsadm -o setapppassword -password <password>

This command has to be executed on every server in the farm!!!!

5. Now you can configure the forests and domains you want to search using the following command. It is important that the trust are a forest. And if you want to get people results from you’re domain B (resources domain) you set this as domain. Because specific ad groups will not be found!

stsadm -o setproperty -url http://test.portal.local -pn peoplepicker-searchadforests -pv "forest:domain2.local,domain2\svc_sp_profile,<PASSWORD>;forest:damain1.int.net,domain1\svc_sp_profile,<PASSWORD>;domain:resourcesdomain.local,resources\ svc_sp_profile,<PASSWORD>;"

 6. On all servers go to the “HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure” registry key and ensure the following permissions are in place and are being inherited in the sub-keys:

1.WSS_WPG Read permission

2.WSS_Admin_WPG Full Control (add the application pool accounts of the webapplications in this group)

3.WSS_RESTRICTED_WPG_V4 Full Control

7. Performance tuning one way trust authentication: How to do performance tuning for NTLM authentication by using the MaxConcurrentApi settings.

While we execute performance/stress tests by visual studio 2013 we saw errors in hour SCOM server. SCOM Windows Server Management Pack monitors how many secure channels are created to a domain controller when authenticating users using NTLM pass-through.

Alert: Max Concurrent API Reached alertSource: Microsoft Windows Server 2012 StandardPath: yourserver.contoso.local

Last modified by: System

Last modified time: -/-/2014 4:04:31 PM Alert description: Max Concurrent API reached in Server yourserver.contoso.local

We were searching on the internet and found a Microsoft KB:

http://support.microsoft.com/kb/2688798 we set the following parameters on the webservers with decimal and the performance increased successfully and no more erros. We set the MaxConcurrentApi at decimal 10.

api

To change the MaxConcurrentApi setting, follow these steps: 1.Click Start, click Run, type regedit, and then click OK.2.Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3.On the Edit menu, point to New, and then click DWORD Value.

4.Type MaxConcurrentApi, and then press Enter.

5.On the Edit menu, click Modify.

6.Type the new MaxConcurrentApi setting in decimal, and then click OK.

7.At a command prompt, type the following command, and then press Enter:

net stop netlogon

8.Type the following command, and then press Enter:

net start netlogon

Other things to know.

The people picker configuration is not only used by the web interface for users. When you fire a PowerShell script is also use the people picker to resolve a user account. So when you get errors in your script test the user account in the script in the web interface.

In summary,

Follow this blog and it will work. For questions just contact us.

Johan Biere & Lionel van Leeuwaarde

Sources:

http://technet.microsoft.com/en-us/library/gg602075.aspx

http://support.microsoft.com/kb/2688798

Submit a comment