Bridging the Gap between Active Directory and the Cloud

A smooth migration to the Cloud largely hinges on cloud resources being able to resolve the Security Identifiers (SIDs) of the organization’s original Active Directory Domain and thus mutually authenticate on premise resources and existing user accounts with Kerberos. While solutions like DirSync and SAML (without KCD) may keep the sign on experience consistent between on-premise resources and cloud resources, these options are not nearly as elegant as extending the organization’s existing Active Directory Domain to the Cloud.

Why won’t most enterprise cloud providers support Bring Your Own Active Directory (BYOAD)?  Well it’s hard for one thing, but Microsoft SPLA Licensing Constraints might also provide more insight into why this sort of capability is so hard to find in the Cloud.  If your organization wants to reap the real benefits of a utility computing model (pay for what you allocate), then chances are your Virtual Desktop provider is going to control the Active Directory Domain.  Why?  Because when your cloud deployment operates on hardware that is not for your organization’s exclusive use, Microsoft requires the Cloud provider to be responsible for the reporting of Microsoft Licensing.  Most Cloud providers will not want to incur the liability of tallying license usage in a foreign Active Directory Domain, as doing so requires a lot of know how and technical sophistication beyond your typical Enterprise hosting provider.

Let me say that again another way, if you want the flexibility of pay-as-you-go licensing (per user, per core, per month) for Microsoft applications, most enterprise cloud providers are going to bar you from using your organization’s Active Directory Domain for your cloud resources.  If you do enroll with one of the numerous Cloud Providers who will promise this sort of integration, you will likely find out they are going to set you up on dedicated hardware, and require you to pay for licenses up front.  Dedicated hardware?  That’s hardly a Cloud Solution.  What about backup, disaster recovery, clustering, bandwidth, IP/Transit?  All of that means extra charges, and probably more upfront cost.

Enter the CloudConnect Private Domain.  One of the many service-model gems of the CloudConnect Platform.  CloudConnect Private Domain allows you to extend any existing Active Directory Domain to the Cloud using the most traditional, reliable, and time-tested methods (setup a VPN, and treat your Cloud infrastructure as a “Site”).  You can keep control of your domain, and leverage the benefits of shared hardware and pay-as-you-go Microsoft Licensing.

The advantages of this approach are in how you will (1) reap all the benefits of moving to the Cloud (utility pricing model, & eliminate the hardware responsibility) but perhaps more important is (2) the migration to the cloud will be far easier and far smoother than ever before.  What do I mean by that?  Well, think of the implications when virtual desktop or cloud server is joined to the same domain as your on-premise equipment; you don’t need to move everything to the Cloud all at once or take on the cumbersome work of configuring cross forest trust relationships.  You can now perform the migration gradually during production hours migrating users and resources at your own pace to the Cloud reducing downtime and the overall stress on IT.  The entire concept keeps both environments seamlessly integrated, and it only takes about an hour to setup.

The real hurdle for organizations in moving to the Cloud is Active Directory.  The CloudConnect Platform has removes this hurdle, enabling IT professionals everywhere to seamlessly transition existing organizations with complex IT environments to a total cloud solution.  To learn more about the CloudConnect Private Domain, download our latest White Paper today, or visit