11

I am working on setting up AD Roles provider and I have run into a bit of an issue -- I am hoping it can be worked around with some fancy configuration however at this point I am not sure.

Background:

My client has 3 domains with a trust between them (no forest). Inside each domain they have a top level OU for containing groups and under than they have 3 or 4 OUs used to organize things -- one of which is a "disabled" OU. Within these OUs there is approximately 110,000 groups (about 30,000 if you exclude the "disabled" OU"). You might ask, do I need all of these groups? The answer is yes and no. I need to be able to support any group that is created by the organization as a possible role within the Sitecore sites and the AD team do NOT put the groups for Sitecore in a single location as it would break all of their entire processes (GPOs, wizards for creating/managing etc.). So that leads me to the following issues/questions.

Issue

  • I cannot seem to figure out how to sync multiple OUs for a single Domain (let alone 3 domains)
    • I tried using the switcher provider and configuring multiple providers and connection strings for each OU, however when I added multiple entries in the sitecore.config for the roles provider pointing to the same domain I threw an exception that this was not supported
    • I cannot seem to figure out how to EXCLUDE a single OU when syncing the parent OU
    • I tried using the custom Filter expression on the provider however there doesn't seem to be any syntax that will exclude a sub OU (only sub CNs which will not work for me) and from looking online, in a Microsoft AD environment it may not even be possible.
  • Loading ALL 110,000 groups results in a 5+ min load time every-time the app pool recycles and the user goes to select a role
    • From what I can tell the "cache" for roles is not very robust and clears out rather quickly (regardless of settings)

Notes

This is for the roles provider, eventually I am going to need to setup the Membership provider and it is even worse :) As I have about 200,000 users that will be synchronized unless I can figure out how to narrow down the sync to multiple specific OUs

Thoughts?

Example AD Structure (these are ALL OUs except the root)

  • Root Domain
    • Groups
      • Distribution Lists
        • OU1
          • Group 1
          • Group 2
          • ...
        • OU2
          • Group 1
          • Group 2
          • ...
        • ...
          • ...
      • Security
        • OU1
          • Group 1
          • Group 2
          • ...
        • OU2
          • Group 1
          • Group 2
          • ...
        • ...
          • ...
      • Disabled
        • ...
          • ...
    • Accounts
      • Service
        • OU1
          • Account 1
          • Account 2
          • ...
        • OU2
          • Account 1
          • Account 2
          • ...
        • ...
          • ...
      • User
        • OU1
          • Account 1
          • Account 2
          • ...
        • OU2
          • Account 1
          • Account 2
          • ...
        • ...
          • ...
      • Server
        • OU1
          • Account 1
          • Account 2
          • ...
        • OU2
          • Account 1
          • Account 2
          • ...
        • ...
          • ...
Improve this question
8
  • 1
    Can you use a filter to query only the users and groups that match the custom filter? sitecore.stackexchange.com/questions/2282/…
    – Michael West
    Commented Mar 3, 2017 at 3:15
  • 1
    Thanks for the response -- if you look in the description though I talk about how I tried a custom filter and how it doesn't work (and how AD doesn't support exclusions).
    – Shawn
    Commented Mar 3, 2017 at 14:30
  • 1
    Correct. The intent from my post was to add only the groups that you assign people to. It would seem reasonable for each domain to have a specific "Sitecore Users Group". If you go the route of building a custom provider, one day your org may regret the technical debt.
    – Michael West
    Commented Mar 3, 2017 at 14:42
  • 1
    Agreed that would be idea -- as I said though, I do not have any control over AD or how it is organized. That said, I suppose I could do the "groups inside a goup" concept (is this what you are suggesting)?
    – Shawn
    Commented Mar 4, 2017 at 11:19
  • 1
    @Shawn Recently I did the implementation with group approach this is the only way to go about it otherwise your cms will crash. Also good to apply filter. There are other bunch of things to worry in terms of security.Like you may have to store credential in keyvault or any encrypted format and you have to decide on ssl support and stuff like that. There is downside as well. santoshpoojari.blogspot.com.au/2017/03/… also this santoshpoojari.blogspot.com.au/2017/04/…
    – Santosh Poojari
    Commented May 3, 2017 at 4:30

1 Answer 1

Reset to default
2

You can solve this issue, just not with the OOTB AD connector. I have built custom AD role/membership/profile providers recently that will address your specific scenario.

The way we did it was to create a REST API that connected to the ADs using custom code and staged the roles/profile data in MongoDB for all the accounts we were interested in. This allows for very flexible processing of inclusions/exclusions as you might imagine. Also if indexed and organised properly the MongoDB implementation will be very fast even for millions of objects (unless you want them all at once - don't do that, ensure you have server-side paging). We had about 40k users.

At the Sitecore end we build a set of providers called "AD Proxy" - these simply connect directly to the REST APIs to get membership, role and profile information.

That's all well and good for the AD attributes but obviously doesn't work for authentication. For that step we had the REST API connect live into the AD backend. So all the membership and profile data was super-cached through MongoDB but password updates were instant as these were being fed back to the source in real time. We implemented some rate limiting with backoff (using Polly) on the login methods to prevent anyone overloading the AD.

As it happens this setup was hosted in Azure on a VM and a VPN gave us the AD access we needed. At the time it wasn't possible to support that setup with an App Service but it is now, either through a Premium App Service tier which can be backed onto a Virtual Network (which in turn can be connected to a VPN) or via the App Service Environment - but that's quite a bit more expensive and probably overkill for just this one function. A small VM or two for uptime is probably still the most cost-effective model.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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