Bridging the Gap between Active Directory and the Cloud

[li_card summary_length=0]

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 www.cloudconnect.net.

[li_card summary_length=500]
  • Adam Kessler

    Michael,
    You’ve stated some interesting points here. I agree with most but with some I do not share your viewpoint on. I am not a Microsoft evangelist. Far from it, but I am an SPLA holder and have eschewed VMWare and the Citrix environment for the simpler and easier and less costly direct Microsoft approach. Simpler by way of easier to manage licensing and less costly because the Citrix and VMWare environments are very costly to the service provider and thus a huge cost multiplier for the end user. The benefits of these systems is barely discernible to the end user and in the case of printing is still an impediment and has been since the days of MetaFrame on WinNT. I have Citrix users today who have abandoned printing to some of their printers because of the constant hassles with Citrix. But I am not here to engage in the cost/benefit ratios of Citrix/VMWare to native systems.
    I would like to review the issues with migration and the options for AD in the cloud. I have not found this part of the equation to be especially daunting, because like you, I use a secured connection to a site created by the installation of a DC for them there. A customer AD in this hybrid environment has never been an issue and can lead to easier migration to a full cloud presence. And as you state the migration process can be done at a more agreeable pace. The infrastructure created and/or the cloud this is built upon for the account and the options they choose for SSO and over-all management of and access to their environment will define separability or trust based management allowing some savings to had in secured access through a common gateway using UPNs. And I want to be clear, this is not a VDI environment. The is a modern remote desktop/remote app environment. This may be referred to by some as a desktop as a service, but I feel that is a definition for VDI using desktop OSs and not shared server desktops. Migration of servers to most clouds can be done with common tools, including various P2V/V2V processes.

    But here is your difference. You are talking about a traditional corporate environment outside of the Office 365 world. How does this model hold up against the marketing drives of big M and the recent announcement of Microsoft 365.

    • Hi Adam,

      Thanks for your input. This model would generally not be a direct competitor with Microsoft Office 365. While an implementation of Office 365 can coexist with the CloudConnect model, Office 365 does not solve the full set of technical challenges that the CloudConnect Platform can address. The model described above is largely applicable to organizations with a traditional ERP or LOB Application that runs on Microsoft Windows, or for organizations who desire to decouple the user’s corporate Desktop profile from the physical device (for Disaster Recovery or Data Security Reasons). For these use cases, the CloudConnect Platform is very successful at achieving these objectives very cost-effectively.

      You raise interesting points with respect to VMware and Citrix. In my experience, when implemented at a very large scale, VMware vSphere reduces labor costs for the Cloud Provider, which offsets the licensing expense. The added flexibility of vCloud Director on top of this stack, provides the tenant with more granular control over the VMs, which can improve cost efficiency. While you mention some bad experiences with the virtually deprecated Citrix IMA, the redesigned Citrix FMA is an entirely different animal with tremendous value add over RDS/RDP. The UDP-enhanced ICA protocol has the unique ability to handle long distance network latency and packet loss without sacrificing application performance or user experience (I actually recently published a post here about EDT, https://goo.gl/q5Qhhf ). This is applicable to large organizations seeking to consolidate data centers or large scale DaaS deployments. Advanced PowerShell APIs, and tight integration with NetScaler make Citrix more scalable over RDS deployments.

      Many times the Business case for a Cloud Solution is not only about cost. Cost should only be the deciding factor when two competing solutions have been deemed equivalent in terms of addressing the minimum required functionality of a system. When evaluating solutions that include advanced infrastructure and remote application delivery features such as CloudConnect, Organizations need to consider the ability of a solution to improve productivity, and enable business growth, thus increasing top line revenue. Any business that empowers its employees to work from anywhere with LAN-like capability is going to out-compete the businesses whose remote solution is limited to just Office 365 alone.

      Finally, I am seeing less and less of a case for traditional VDI environments. RDS/XenApp Published desktops are generally far less expensive than traditional VDI (both in terms of licensing and management). RDS/XenApp Published desktops are largely indiscernible to VDI desktops both in appearance and capability for most use cases. Citrix Published Desktops now support OpenCL, CUDA, and DirectX, as well as GPU sharing. Therefore, traditional VDI is largely unjustified, except when deemed required by extremely high-end 3D CAD applications. In this case, engineering firms will likely opt for a true VDI solution over installing CAD on workstations and laptops. This allows them to maintain strict control over their intellectual property, which is usually the overriding factor to opt for VDI.