This article might just be restating the obvious for some — but to put it bluntly, a “best-practice” Enterprise Active Directory (AD) design feature may not perfectly translate to a Cloud-based deployment scenario. Let me explain…
When Good Mappings Go Bad
Let’s imagine an enterprise that has done a good job of providing universal access to user Home Folders by using the AD Home Folder attributes on the user objects. Very common indeed, and very well loved in most cases. In a well-designed infrastructure, the users get access to the Home Folder from almost anywhere in the world, and from a variety of platforms including local, remote, and thin/terminal access.
On top of that, imagine further that the environment utilized the individual logon script user object attribute to determine group memberships, deliver printers, and maybe even deliver a mapping or two. All of this is fine (though arguably cumbersome) in a high-speed environment where the network inter-connectivity is not rate-limited or rate-charged.
Now however, let’s imagine being one of those users authenticating to an RDS/Terminal Server (session hosts) farm in a cloud-based domain instead of in the Enterprise. Hmm. Suddenly, different access and performance considerations appear when walking through that logon process. For instance, while that Home Folder server may be reachable from that RDS farm, that lookup and access of the file server might very well be across a VPN pipe that is slow; or even if it’s fast, there may be a charge for egress data transfer as is the case with Microsoft Azure. Oh, and that logon script will definitely hit the Domain Controller looking for all of what it needs to draw conclusions; and in the end, may attempt to map you to things you cannot even reach.
Can you solve this problem by putting domain controllers in the cloud? Well, part of it — if you use good AD Site and Subnet configuration. But you can’t escape the fact that your enterprise user objects may attempt to reach beyond those controllers and into the infrastructure to access what they must, and time-out on what they cannot (read: slow logon).
The GPO is your frienemy
And don’t even get me started on GPOs. Yes, you know them, and you love them, and you use them to provide a rock-solid enterprise configuration for your users… But what about those mandatory proxy registry settings that matter in the cloud? What about those printer map settings? What about those WMI evaluations? The Item-Level Targeting? And so on.
And then one day of course, there’s the one GPO setting that accidentally gets applied to those users that inexplicably wipes out their access to the application in the cloud-based RDS farm.
The bottom line is that again, things that may be prudent and reasonable in the Enterprise may be detrimental to the Cloud users’ experience.
So what can you do?
First, step back. Ask yourself if your user logon process is clean, lean, and mean, and prudent for a Cloud-based experience. It may very well be the case, but it likely is not. So if you find that you’ve been a good and dutiful Enterprise admin and used Active Directory to tightly configure that user, you might be faced with a need to have a separate directory for your Cloud environment that is either replicated, integrated, or federated. Which, for some organizations, may very well cause them to have to re-think security models (or at least re-imagine the ones they have), evaluate provisioning, and so on, as part of a larger Cloud Strategy.
Or, if your situation permits, you might be able to take advantage of the soon-to-be-released Azure Active Directory Domain Services, as long your design doesn’t run up against some of the limitations (I strongly recommend you read the FAQ and other documentation before deciding it’s right for you).
Now you’ve heard what to watch out for, but the options you utilize going forward depend on what you are trying to achieve. Good luck out there, and let us know if we can help…