次の方法で共有

Azure Active Directory for the Old-School AD Admin

  • [アーティクル]

Greetings! Hilde here to wish you a Happy New Year and to welcome you to the first Monday of 2015 and the first post of 2015 for AskPFEPlat!

As you may know from reading my posts here, I tend to reminisce. Well it's the New Year, so here I go again … Anyone out there remember the "Distributed Systems Guide" from the Windows 2000 Resource Kit series of books? Chances are if you are an old-school AD admin, you read it cover to cover more than once. Pound for pound, that book is one of my top IT books EVER (and heaviest). I still learn something every time I open it. KUDOS to the numerous authors who had a hand in its creation (some of whom I've been privileged enough to work with). I still like tangible "hold in my hand" books and I would love an update to that one but the way book publishing has changed, I don't see that happening.

Ok - now, back to the future…

I think we've all seen where cloud computing has altered the way applications are developed.  Today, it's all about "The App." As in 'a-web-based-accessed-from-anywhere-on-anything' style of app – not the 'RunMe.MSI-installed-onto-a-single-server-using-a-service-account-and-accessed-via-a-dedicated-client-install' style of application.

At the same time, the ubiquitous nature (nice phrase, eh?) of smartphones, tablets and other devices along with a blurring of the lines between work-life and personal-life has changed the way people use/access those apps. Cross-device; cross-platform; anytime; anywhere - this is the new norm. Or at least the new expectation.

On-prem Windows Server AD domains and forests are usually insulated or isolated from the outside world and don't quite get us what we need for this new model. We'd need to turn our firewalls into Swiss cheese with a lot of open ports and we'd likely have issues when Internet DNS conflicted with internal DNS. Just to name a couple of obvious sore spots. What are we to do?

Hello Azure Active Directory

Azure Active Directory (Azure AD; AAD) is a web-based, Internet-scale identity and access management service hosted in Microsoft Azure datacenters. It combines directory and identity services and governance, application access management, auditing and reporting, as well as multi-factor authentication and password self-service (and new features are added regularly).

Even though the name is similar, Azure AD is NOT instances of Windows Server Active Directory running on DCs in Azure datacenters but it has some similar aspects. There are users, groups, partitions, content replication – I think of it like AD LDS front-ended by web services/APIs. There aren't any AD sites or OUs; there isn't a domain join function for computers either. There is something a bit like a domain join, though. Device registration (https://msdn.microsoft.com/en-us/library/azure/dn788908.aspx) is sorta like a minimal domain join, utilizing Azure, ADFS and certificates to associate a given user's personal device(s) that she'd like to use to access corporate data. In the near-future, people will likely be able to login to a PC via an Azure AD account (similar to logging into a Win8 PC via a Microsoft Account). Who knows what else the future holds – the feature set of Azure services is rapidly and frequently expanding.

There are three different levels of Azure Active Directory with feature-set, scale and cost variations. Here are two helpful resources to break it down for you:

      A good technical article with some great AAD "mechanical" details can be found here (read the comments, too): 

As a long-time AD guy, Azure AD has been bouncing around in my noggin for quite some time.  To be honest, it's still bouncing around. One way I come to terms with new things is to jot down notes of my own aimless wonders and wanders, then seek out answers.  A while ago, I started one of these for cloud 'stuff', including Azure AD.

Then, recently, a peer PFE and buddy of mine presented Azure AD through the lenses of an "old-school AD Admin" and it dawned on me that our readers would benefit from this viewpoint and you all likely had many of the same questions I had chased down in my Cloud FAQ.

One of my first and oldest FAQ entries is:

Why should I care about Azure AD?

To better understand my own question, it's flipped around and been rephrased a few times - now it is: Why would businesses use/need a directory service in the cloud?

As we all know, business is changing and so is IT/technology. Before the cloud revolution, most apps were in-house, running on servers in our on-prem datacenter, updated every so often via CDROM media that the vendor would ship. Today, many of those app vendors host their apps as "services" (you may have heard this referred to "Software as a Service" or "SaaS").  Our own Office 365 is an example of the SaaS delivery model.

Another example might be a corporate travel service/app that has evolved over time from that 'thick' client/server style, to an internal intranet site. Then the vendor began to host the service on an Internet site but each user had to go there, create their own ID/pwd on that site and remember those credentials each time they needed to book travel. The vendor decides to integrate the app into AAD.  Bingo – right there is a solid use-case for Azure AD – that web sign-in can now be handled via existing on-prem AD credentials for all of your users. If a user leaves the org, you disable the on-prem AD account and that change will be sync'd to Azure AD - he/she won't be able to high-step out to the travel app and book a flight around the world on the company dime. His/her access to that, and any other SaaS apps is now controlled by IT via the same set of credentials that the user already uses to login to his/her PC. The app/service may be available from a corporate PC, a personal use tablet, a web kiosk at a hotel or even a smartphone.

Take that example, and apply it to any number of today's scenarios – MANY apps are offered as "Services" and rather than your users each creating/managing separate identities for each app/service, with Azure AD, you control your user's access to all of those important cloud apps/services as an extension of their existing on-prem AD credentials.

Make sense?

  • The vendors manage/update the apps, add new features, etc.
  • The credentials are the same ones already managed by IT within your on-prem AD.
  • Many apps are available on multiple devices/form-factors – (corporate PC, smartphone, tablet).

     That, my friends, is a powerful business-enabler.

  • Your users can do their jobs/duties across devices/platforms/locations and you maintain control of the identities.

Also, consider the potential sales an ISV gets when they certify their app for Azure AD integration? As of Oct 2014 data, Azure AD has 2400+ SaaS apps pre-integrated, more than 200 million active users and it processes about 18 billion authentications each week. That's big.

Of course, many SaaS apps/services can be federated to on-prem AD via ADFS or other federation technology. However, as mentioned, the number of these SaaS apps is growing FAST and having to manage the multitude of these federation trusts quickly becomes a burden. Especially when it comes time to roll over the certificates if the apps don't monitor the federation configuration for changes.

We can leverage Azure AD to help us here and establish a single federation trust to your on-prem AD and then, via the integration of the SaaS vendors with Azure AD on the back end, your users can SSO to those SaaS apps.

Are you curious as to what AAD integrated apps are available? Check out the Azure AD Marketplace (a list that is always growing):

You may be wondering how big is the 'grassroots' use of cloud-apps for your internal users. How many apps are folks really using? What apps are they using? You might be surprised. I've read it is upwards of 10x what IT estimates.

To help get a handle on this, Microsoft created a tool that can be used to inventory what cloud apps are in use on your user's systems. The tool needs to be deployed to your end-user devices (or a pilot/sampling of them) but once that is done, you can use the tool to create usage graphs, volume of data exchanged, top apps, etc.

 

So, SaaS app authorization and authentication with on-prem credentials via Azure AD - got it?

 

How do I populate our Azure AD directory with on-prem AD user information?

You can create users in your Azure AD directory one-by-one in the portal (or via some CSV import, the Graph API, or AAD PowerShell module), but many of my customers have 30k, 90k, 100k or more user accounts. Microsoft Azure AD provides some simple-to-setup but very robust sync tools/services so you can quickly populate/maintain your Azure AD directory with on-prem user and group information from one or multiple domains/forests.

Extend your on-prem AD into Azure AD and you just 'cloud-enabled' all of your on-prem IDs. Let me restate that: your users can now access any application assigned to them that is (or will be) integrated into Azure AD by authenticating via a prompt to provide the same credentials as their current on-prem login ("same sign-on") or through a federated "single sign-on" process. That run-on sentence just opened a World Wide Web of possibilities.

 

With the available multi-factor authentication (MFA) service in Azure AD, you can enable multi-factor authentication to any of those SaaS apps for all of your users in short order. This is amazing to me. It used to take months of 40-50hr work-weeks, coordination with vendors, exchanging certificates, creating service accounts, installing the multi-factor auth app on a set of servers, purchasing, distributing and tracking costly physical fobs/cards for the MFA app, managing and backing up the servers, etc.

With Azure's MFA service, we can get this up and running, literally in minutes, leveraging your users' cellphones (via a text message, a phone call or an app on the phone).

I know this all sounds kinda' "infommercialish" but it's true.   

 

    Figure 1: Resource access overview for directory sync and federation (image from the technical guidance/details here: https://technet.microsoft.com/en-us/library/dn761716.aspx )

 

Is Azure AD an LDAP-compliant directory? How do we interact with AAD programmatically?

There are several interfaces exposed for Azure AD but AAD doesn't support LDAP externally today (internally, it is LDAP - see figure 2 below).

To query/read/write to Azure AD, we can use AAD PowerShell and/or leverage the REST-based Graph API interfaces.

  • REST = "REpresentational State Transfer" is a type of web-standard that enables web apps to interact with other web apps
  • The Graph API, specifically, is a way to interact with the contents of Azure AD via GET, PUT, POST, etc
  • An example of an familiar LDAP-style AD query - "(&(objectCategory=person)(objectClass=user)(cn=Santa Claus)
  • The same query in Graph syntax - GET https://graph.windows.net/contoso.com/Users?$filter=displayName eq 'Santa Claus'&api-version=2013-04-05

 

    Figure 2: Azure AD overview (from this EXCELLENT document which is required reading - https://blogs.microsoft.com/cybertrust/2014/09/09/protecting-customer-data-in-our-cloud-through-microsoft-azure/ )

 

Is there Group Policy in Azure AD?

As mentioned before, AAD isn't Windows Server Active Directory - there is no Group Policy functionality in Azure AD.

However, Microsoft InTune is a cloud-based mobile device management service in Azure that allows some similar control of users, devices and settings and opens up the functionality to cross-platform devices.

Some examples of this are: smartphone management forcing a PIN, device encryption, remote wipe of corporate data, etc. InTune readily integrates right into SCCM to provide for both on-prem and cloud-based device management.

 

Can I deploy an instance/replica of Azure AD in my on-prem Datacenter?

There isn't a way to replicate your AAD directory(ies) into an on-prem instance. One of the values of Azure is that Microsoft manages the infrastructure/services of Azure and all you need to manage is your content.

Additionally, recall that you are able to synchronize some of your on-prem AD content into an Azure AD directory instance. I said 'some' because we only sync users, groups and contacts; we don't sync GPOs, DNS records, AD Sites, etc. 

Can I deploy an instance/replica of my on-prem AD into Azure?

No and yes.

You cannot create an instance of your on-prem AD in Azure Active Directory outside of the directory-creation and sync processes we've been discussing (the top option in the diagram below and the main focus of this post).

You can, however, create/host a VM in Azure's Virtual Machines service (https://azure.microsoft.com/en-us/services/virtual-machines/) that is connected to your on-prem network and running as a replica DC for your on-prem AD. This is similar to a branch office (or DR) scenario but the 'branch office' in this case is Azure (the middle option in the diagram below). We've posted about this before here in our blog - https://blogs.technet.com/b/askpfeplat/archive/2014/03/03/connect-an-on-premises-network-to-azure-via-site-to-site-vpn-and-extend-your-active-directory-onto-an-iaas-vm-dc-in-azure.aspx

You can also use Azure VMs to setup dev/test "islands" of AD, without any connection/awareness of you on-prem AD (the bottom option in the diagram below). Perhaps you want to check out Windows Server vNext AD? In a few minutes, you can setup a VM running the Technical Preview and then promote your new VM to a DC. We've posted about this before here in our blog (almost exactly 2 years ago) - https://blogs.technet.com/b/askpfeplat/archive/2013/01/07/windows-azure-virtualization-a-lab-in-the-clouds-for-every-it-pro.aspx  There is more information and detailed steps here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-new-forest-virtual-machine/

Figure 3: Typical high-level options

 

Is Azure AD content replicated across international borders?

Another question I had was 'what about data privacy laws by country/region that restrict where data can/can't reside?'

In Azure AD, the content/data is replicated for fault-tolerance and the built in recovery (DR) aspects but the data replication is restricted to regions and doesn't cross those regions. Figure 4 below shows the current UI for creating an AAD – notice you specify the country/region.

 

Figure 4: The Azure portal UI for adding a new directory

 

Figure 5: A point-in-time map of the Azure datacenters giving you an idea of the regions

More details can be found here about the regions:

 

Are there parent/child relationships if I have more than one AAD directory (like those in a Windows Server AD forest)?

Not really – Azure AD is flat; there isn't the same type of relational hierarchy as an on-prem AD.  Each AAD directory you create is a distinct entity but an Azure AD directory CAN have multiple Internet DNS namespaces configured once you prove that they are owned by your company (i.e contoso.com; mycompany.org, etc).  These are called 'custom domains' in Azure AD.

Be aware, though, there is a potential issue related to on-prem parent/child domains and the order you set them up for Azure AD integration.  See the following KB and think through the order you choose to link your on-prem domains to Azure AD for the most flexibility (i.e. you might consider setting up the child domain(s) first for the most flexibility): https://support.microsoft.com/kb/2174324

 

How do I manage Azure AD? Is there an equivalent to AD Users and Computers ("A-Duck" for you old-school AD admins)?

  • The ADUC of Azure AD is the "Active Directory " section of the Azure web portal (which has features added/improved/updated frequently)
    • You can perform AAD administration from nearly any web-enabled device
  • There is a rich Azure AD PowerShell module
    • Yet another reason to get proficient in PowerShell (note – I didn't say 'guru' or 'expert' – just get functional)
  • There are the Graph APIs
  • The InTune and Office 365 portals can also be used to manage certain aspects of Azure AD
  • Of course, if you have synchronization setup from on-prem to Azure AD, many management activities you perform on-prem will sync (i.e. you can use ADUC to edit a user's description and that will be reflected in the AAD copy of that user.)

    • Note – the default interval for directory sync is every 3 hours and password hash sync is every 2 minutes.

       

 Figure 6: Azure AD management access options

Do we still use Kerberos, NTLM, LDAP, ADSI, and other protocols I'm familiar with?

On-prem, yes (obviously). However, remember, the cloud is a web-centric world (cross-device/cross-platform/cross-the-world) and interfacing with AAD requires that we use a web-centric language - SAML 2.0, WS-Federation, OAuth, OpenID, REST Graph, etc.

 

What's in a name?

"How important are the choices I make when first setting up Microsoft online services such as Azure, InTune, Office365, etc?"  

    • In a word, VERY.  The initial choices one makes when setting up Microsoft Online services (Azure, InTune, O365, etc) are extremely important and can have far-reaching and long-lasting implications.  Think about this similarly to the selection of the forest-root FQDN for your on-prem AD.  As mentioned, you can add public DNS names that your company owns but you can't change the original <entry>.ONMICROSOFT.COM name that you setup. 
    • Like all major IT decisions, it is critical to plan and think through your current and possible/future Cloud decision points BEFORE jumping in.  I've seen customers who wanted to 'dip a toe' in the Azure world and during signup, they chose the name to be something like INTUNE-MYBIZ.ONMICROSOFT.COM (i.e. to try out InTune).  The problem showed up when they wanted to light-up other Azure/O365 services, that initial "INTUNE-MYBIZ name was always around.  This caused a lot of confusion when working with SharePoint Online, Exchange Online, Lync Online, AAD, etc.  I really recommend bringing in some Microsoft resources to help you plan out your deployment options and document some of the key decision points.  For your cloud infrastructure, do it once; do it right.
    • Work with your Technical Account Manager (if you're a Premier customer) and/or head out here to get some help - https://deploy.office.com/  Rome wasn't built in a day but imagine if they had to build it twice?

I've been doing AD admin work since the dawn of AD with Windows 2000 – is my profession in jeopardy?

In some ways, it is. This is technology – things are always changing. This isn't a surprise to anyone reading this. We've all had to learn how to keep learning; the next version of a product, a new-to-you feature/aspect, PowerShell or whatever. This career we've chosen is all about adaptability and one's ability to thrive with change. As long as you can adapt, the AD admin role isn't going away … it's just changing. As we've discussed, AAD syncs from on-prem AD. Someone needs to setup/run/manage/monitor the sync tools; someone needs to setup/run/manage/monitor the federation services; PKI and certificate management is critically important in the cloud world we are in now. There is also "the work" to be done within Azure AD - the contents/portal/etc.

So, if you're set in your ways and it's 'on-prem AD or death', you might be headed for some challenging times. On the other hand, if you're willing (I know you're able) to add "cloud AD" to your technical skillset, the years of experience and maturity you have developed will continue to be of value in the cloud world. Being able to communicate effectively; develop and deliver quality documentation; being process-oriented and possessing a flexible, "can-do" attitude will always be very sought-after skills.

 

Ok – my New Year's Resolution is to learn more about Azure, Azure AD, Azure datacenters, etc – where can I get more information?

Here are a few more links to get you going:

I hope this post helped shed a bit more light on what Azure Active Directory is - and is not.

A special thanks goes out to my friend and peer, JD, for sharing his knowledge and understanding of Azure AD. His presentation solidified my thoughts about this post and sparked one of the main themes.

Work your way through the information and links herein and when you're done, I promise you'll have a better understanding of Azure, Azure AD and your future in the cloud era of technology.

Cheers!

Michael Hildebrand