Using Delphix in Windows environments with multiple domains

It's not uncommon for us to get requests for guidance on using Delphix in SQL Server environments where production and dev/test/reporting environments exist in different Windows domains (which may or may not have trust relationships). This could be done for security or organizational reasons but could make communication between Windows hosts in the disparate domains more complicated to manage.

There are many ways that Delphix can work in these environments. Ultimately, our customers need to choose a solution based on their unique requirements, but I thought it may be interesting to walk through some potential scenarios. One typical reason for separation between domains and having Delphix interact with Windows hosts in different domains would be to separate production environments from dev/test environments for organizational reasons.

Others could be for geographical regions, or domains of companies that remain after an acquisition. We'll look at the different points where Windows communication between hosts may require domain credentials and how that relates to a Delphix deployment. The main complication of multi-domain environments where trust relationships don't exist is the lack of simple configuration of SMB access.

Because users can't be authenticated in this situation they're treated as "Anonymous" users. Additional configuration options are required to allow this. Let's start with the simplest scenario: one where separate Windows domains have domain trusts configured and user credentials can be used across domains.

Domain trusts configured between domains

Let's assume that we have two domains: production.company.com (PRODUCTION) and test.company.com (TEST) which have domain trust relationships.

Domain trusts configured between domains

In this case we see that we have a deployment where Delphix only directly connects to hosts in the non-production domain, but because of domain trust relationships the hosts located in the TEST domain can access resources in the PRODUCTION domain. This would allow the host staging to connect to the production host sqlprod1 for environment discovery and to the shared backup location on backups over SMB to access database/transaction log backups.

Domain agnostic storage

Next up, a shared backup location that's not dependent on trust relationships between the production and dev/test environments. Because Delphix uses UNC paths to access shared backup locations, we can support any protocol which provides UNC access between (in this example) staging and nas. This could be SMB, NFS, etc.

Domain agnostic storage

The dotted lines represent any protocol which the Windows host staging supports via UNC access. Provided that both sqlprod1 and staging have access to a shared backup location on nas the SQL Server instance running on staging will be able to access backup files needed to perform validated sync.

Validated sync in production environment

This scenario is where a test domain must not have access to resources in the production domain and Delphix VDBs will be provisioned to the test domain. In this scenario a host in the production domain can be used to link the production database and perform validated sync. VDBs can then be provisioned to the provisioned to the test domain.

Validated sync in production environment

In this case VDBs can be completely isolated from the production domain, and there is no requirement for hosts in the test domain to have any direct access to resources in the production domain. This is the most straightforward configuration and would not require making changes to SMB security settings.

Migrate Backup Files

Here's a much more complex configuration. Let's consider the case where:

• Backup files are taken to a host in the production domain

• The host used to link a dSource and perform validated sync must be in the test domain

Migrate backup files

In this case, we've used connectorhost to perform environment discovery of the production system sqlprod1. Backup files for the production database are being stored on backups.production.company.com. We want to link using staging and create VDBs in the test domain.

When Delphix discovers that a new backup of the production database has been taken, Delphix will attempt to find the relevant files in the shared backup location that was provided during linking. It does this by doing a recursive search for the file names in the provided location. If the files aren't immediately found, Delphix will simply try again later.

Delphix isn't picky about this location, and it doesn't matter if it is the same location that the production SQL Server instance is using when taking the original backups. This provides us with an option to specify a shared backup location in the test domain. You're then free to implement any mechanism that you'd like to migrate or copy backup files to this location.

The files must be available in that location long enough for Delphix to detect them and apply them to the staging database before they're removed. We have customers who also use this model in cases with multiple data centers rather than multiple domains. These customers want the database and transaction log backups to be available in secondary datacenters, but want make sure that the data is only copied over the WAN once.

SMB Anonymous Access

Finally, let's see how you can configure Windows SMB to traverse domains that don't have a trust relationship.

SMB anonymous access

Without a trust relationship, there's no way to specify accounts from the test domain to grant them access to SMB shares in the production domain. Windows provides the "Everyone" group, but this group only applies to accounts that can be authenticated in the domain. Thus adding "Everyone" access to the backup location in production still won't apply to accounts in test. Windows considers such access to be an "Anonymous logon."

Following are steps to configure such access to the shared backup location on backups such that the backup files can be accessible to accounts in the test domain. You'll need to consider the security implications of enabling such access, and potentially consider other security measures which could mitigate this access (such as configuring a private VLAN or IPSEC between backups and staging).

1. Enable the "Guest" account on the server where SQL Server backup files will be available.

2. Create a share (for example "SQL_Backups") where SQL Server full and transaction log backups are available.

3. Configure read-only security access for both the security permissions on the share directory and the share permissions for the "guest" account.

There are additional Windows security settings which may prove useful to tweak access controls:

• Network access: Let Everyone permissions apply to anonymous users

• Network access: Shares that can be accessed anonymously

• Access this computer from the network