0

We have a SharePoint 2016 OnPrem Environment in a domain common (Global) with other local domains. There are trusts between the Global domain most of the local domains but because of security some of the local domains are more closed and only one way trust. We like to get the users from the so called closed domain to access the sites in the Global domain. They only allow push data to the Global domain and not the Global domain to pull any information. I'm not sure on how PeoplePicker works in this case. Any advice? Please let me know if you miss any information to help me out Thanks

Added information Now I have done some tests. Before I have used STSADM to set people picker and I have 6 of them to trusted domains and it had worked fine. I have not used Account and PW for that. Looked like this STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv domain:AD1.internal;domain:AD2.internal;forest:AD3.internal;domain:AD5.internal;domain:AD6.interna -url https:/webapplication.domain.internal/ When I try suggested below, to add the new AD with account and password the new AD doesn’t work and either the old once. I just get a few users from one of the old AD but I cannot see why just those users. I have also tied to remove all Ads and then ad one at the time with the way suggested below (not STSADM) and it works until I get to the one-way-trust AD. Then all ADs stops working. It is not fixed by just remove the one-way-trust AD. I need to set all by the STSADM command again and everything works find again. Is it something I miss or misunderstand in this on how People Picker works? Thanks

0

For one-way trusts, the domain that the SharePoint farm resides in MUST trust the remote domain.

To set this up, you need to add an identical app password on each SharePoint server and configure the People Picker on a per-Web Application basis.

$key = ConvertTo-SecureString "Password1" -AsPlainText -Force
[Microsoft.SharePoint.SPSecurity]::SetApplicationCredentialKey($key)
$wa = Get-SPWebApplication http://webAppUrl
$adsearchobj = New-Object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain
$userpassword = ConvertTo-SecureString "UserPassword1" -AsPlainText -Force #Password for the user account CONTOSO\s-useraccount
$adsearchobj.DomainName = "contoso.com"
$adsearchobj.ShortDomainName = "CONTOSO" #Optional
$adsearchobj.IsForest = $true #$true for Forest, $false for Domain
$adsearchobj.LoginName = "s-useraccount"
$adsearchobj.SetPassword($userpassword)

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($adsearchobj)
$wa.Update()

Ref: https://thesharepointfarm.com/2014/01/powershell-for-people-picker-properties/

If the trust scenario won't work (two-way or one-way with the "global" domain not being able to trust the remote domain), SAML would be the alternative option, though I wouldn't recommend it.

https://docs.microsoft.com/sharepoint/security-for-sharepoint-server/implement-saml-based-authentication-in-sharepoint-server

To set this up, you'd have to establish a fed-to-fed trust. This would require each domain to deploy AD FS (or a similar IdP) in their environments.

https://docs.microsoft.com/windows-server/identity/ad-fs/operations/create-a-claims-provider-trust

1
  • Thanks I have tested some above but I will give it Another try and see if it works. In the meantime, Why won't you rekommend the SAML /ADFS solution?
    – user65250
    Dec 1 '20 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.