Active Directory Sandbox Best Practices/Requirements

We are looking to create a comprehensive testing/sandbox environment for SailPoint that will allow us to thoroughly test changes/additions with our HR system, SailPoint, and Active Directory in a controlled/isolated environment. We believe that a full sandbox system is the best way to achieve this goal. We already have an HR test system that is refreshed couple of times a year from PRD, and our SailPoint Sandbox tenant. Now we need to work with our infrastructure on creating a Sandbox AD environment.
We need input on the best way to set up Active Directory Sandbox, including any recommendations, best practices, tools, or specific requirements. We want to ensure that our sandbox system is set up correctly and efficiently.
Our initial thinking is that it will need to be a clone/mirror of our core domain and primary Sub-domain, with the same schema, attributes, OU structure, and groups, and it would need to be refreshed periodically from Prod AD.

Thanks in advance,

I’ll throw a few things I’ve seen over the years in here:

  • Having a non-production domain that mirrors a very similar setup to your production AD domain is a very nice to have. You can typically perform very robust testing in that non-production domain which is crucial when it comes to testing account creation, attribute sync, etc.
  • Mirroring the structure is very important when you stand up the non-prod domain. I would probably do an initial migration of account and group objects so you have a good starting point and can test things like correlation of existing accounts to identities in your non-prod IDN tenant and have some birthright groups to test with roles, etc… I would actually not suggest a refreshing periodically from your Prod domain unless you see specific reasons to do so. In my opinion you do not want some periodic Prod refresh overwriting data in your non-prod domain causing issues with testing or causing IDN to react every time that happens be re-provisioning attribute values or whatever the case may be
  • One challenge I’ve run into over the years is having a non-production Hybrid Exchange/Azure environment to go along with your non-production on-prem AD domain. If hybrid mailbox creation is in your scope, having this is amazing as testing this against a production environment from a non-production IDN tenant can be super tedious. A lot of orgs don’t have the money or infrastructure to always support this though and it can be a lot to standup just for IDN purposes
2 Likes

Hi @jonathonpraay I think you will have to make some balance between project time and resources. Having an exact clone of your forest is always the best option, because production roll outs will need a very minor effort (and possible errors due to forgetting to change some domain name or structure).

In the other end, you can use the same production environment, making a DEV OU, making sure that the service account has only permissions inside this branch, and no permission outside them.

In my experience I worked more or less the same with the two scenarios, and others between them. In some cases making another domain was something easy, in others burocracy involved to do something like that turns project inviable, so has to get used with some isolated OU.

2 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.