Hi Yvand,
Thank you very much for getting back to me. SharePoint in Multi Tenant mode is basically the standard release code base but doeing a scripted install and using the -partitionmode flag to enable data partitioning. The Subscription Service then allocates a unique GUID for each subscription. All data belonging to the tenant is then tagged with the Subscription ID.
Here is a quick overview: https://technet.microsoft.com/en-us/library/dn659287.aspx
We are in fact running all tenants under a single Webapp - for each Tenant/subscription we then configure people picker to restrict the search scope to the tenant OU:
We configure this using the Set-SPSiteSubscriptionConfig cmdlet with the -UserAccountDirectoryPath https://technet.microsoft.com/en-us/library/ff607622.aspx
So while running under Negotiate auth People Picker will aerch only its own OU.
This behaviour breaks for the built in people picker when the farm is configured to use ADFS auth.
Ideally we could therefore have situation where ldapcp identifies which SIte is calling the People picker, this site will have the SubscriptionID property as a GUID (always). This sub ID has a property UserAccountDirectoryPath which could then be used to restrict the search.
I don't know if any of this makes sense, however, I must admit that we have not done any recent testing of this either for built-in people picker or for ldapcp.
We will be moving forward with a Multi tenant test install of SP 2016 as soon as it's RTM code is available. That install will be configured for ADFS auth (token based)
If you could indicate if my idea of using the SubscriptionID info to restrict search could be within the scope of ldapcp. I could then have our own development team look at it.
Be hearing from you
Thank you very much for getting back to me. SharePoint in Multi Tenant mode is basically the standard release code base but doeing a scripted install and using the -partitionmode flag to enable data partitioning. The Subscription Service then allocates a unique GUID for each subscription. All data belonging to the tenant is then tagged with the Subscription ID.
Here is a quick overview: https://technet.microsoft.com/en-us/library/dn659287.aspx
We are in fact running all tenants under a single Webapp - for each Tenant/subscription we then configure people picker to restrict the search scope to the tenant OU:
We configure this using the Set-SPSiteSubscriptionConfig cmdlet with the -UserAccountDirectoryPath https://technet.microsoft.com/en-us/library/ff607622.aspx
So while running under Negotiate auth People Picker will aerch only its own OU.
This behaviour breaks for the built in people picker when the farm is configured to use ADFS auth.
Ideally we could therefore have situation where ldapcp identifies which SIte is calling the People picker, this site will have the SubscriptionID property as a GUID (always). This sub ID has a property UserAccountDirectoryPath which could then be used to restrict the search.
I don't know if any of this makes sense, however, I must admit that we have not done any recent testing of this either for built-in people picker or for ldapcp.
We will be moving forward with a Multi tenant test install of SP 2016 as soon as it's RTM code is available. That install will be configured for ADFS auth (token based)
If you could indicate if my idea of using the SubscriptionID info to restrict search could be within the scope of ldapcp. I could then have our own development team look at it.
Be hearing from you