Freigeben über

The difference/relationship between Azure Active Directory and “Normal” Active Directory

  • Artikel

I made a video about this some time ago because of the prevalence of confusion over what you can and can’t do with Azure AD vs. on-premises AD. It’s a regularly recurring theme and it came up with a customer again this morning, so I thought I’d re-blog about it.

The opening words to the above video are “…you could be forgiven for thinking that Azure Active Directory is Active Directory running in Azure”. There are significant differences between the 2 beasts.

Server AD offers 5 core services. The one we’re mostly familiar with is Active Directory Domain Services (ADDS) but there are also others:

Active Directory Certificate Services (ADCS)

Active Directory Rights Management Services (ADRMS)

Active Directory Lightweight Directory Services (ADLDS)

Active Directory Federation Services (ADFS)

Those 5 things together make up the entirety of on-prem AD. When most of us talk about “AD”, we’re mostly talking about ADDS.

None of those 5 services are available in Azure AD though it has similarities to some of the features and does allow you to extend your on-prem AD in to the cloud in a meaningful way. But it’s wrong to think they are both the same thing.

ADDS is an infrastructure directory service that can be queried using LDAP. It can host DNS and integrate with the directory partitioning model of the directory service itself. It uses Kerberos for authentication. It opens the notion of sites, bridgehead servers, replication, users, servers, workstations, groups and so on. The idea of domain-joining machines exists and they become part of the core managed infrastructure. There are Group Policy Objects which have an inheritance and deployment model that can be controlled to flow through Orgnizational Units (OUs) in a way that fits your enterprise. You can use group policy to determine the security policy of a server, or what a user’s desktop, icons and wallpaper look like. Notions of domains, trees, forests and trusts exist. Applications can create objects other than standard users and groups and can stack them in a hierarchical model so the apps can easily navigate them. 

Most of that is different to Azure AD. Azure AD is indeed a directory service but it is (currently) a directory service whose main function is to deal with identity. An Azure AD does have a domain name, it does contain users and groups. It contains Service Principals, like on-prem AD, that represent applications. But there is no tree of domains, no trusts between domains or forests. Indeed there are no forests. You don’t query the directory using LDAP. There is no idea of setting up replication across site boundaries, the entire directory service is hosted in Microsoft data-centres in Azure. You cannot domain-join your desktops, laptops, tablets and servers to it. There is no Group Policy, no OUs, no Master Operations, no Read-only-Domain Controllers, indeed there are no Domain Controllers of any sort. Authentication is not done through Kerberos. So although you can apply the principles of what you know about on-prem AD to Azure AD it starts to become really obvious that on-prem AD is designed as an infrastructure directory to manage your core internal infrastructure as well as provide a directory service for applications/users. Azure AD is not designed to run your core internal infrastructure but it is designed to provide a directory service for users and Internet applications.

Azure AD is designed to work not inside your enterprise but on the Internet. It’s therefore equipped to deal with Internet protocols. The Azure AD equivalent of LDAP is AD Graph API – a REST API. The Azure AD equivalent of Kerberos is its support for federation technologies like SAML, WS-Federation and OAuth. So the idea of domain-joining a SQL Server to an Azure AD just plain doesn’t exist.

So that’s where they’re different and I believe that’s where most confusion arises. Once we get over the fact that they are different things then it’s easier to look at why they work together and complement each other.

In some very rare cases, copying a .vhd from your on-prem world to the cloud and firing it up in Azure will work. Often it won’t. Probably one of the first things the server and the apps loaded on to it will want to do is contact an on-prem AD. But now that you’ve moved it outside of your secure perimeter, there’s no way those protocols – LDAP, Kerberos etc. – are going to travel the Internet intact.

We now live in a world where apps are being deployed to cloud data-centres outside of the secure corporate perimeter. We need a directory service to satisfy the needs of this new breed of Internet applications. So Azure AD uses Internet protocols that race around the Internet unimpeded. Both the Graph API and the authentication/identity protocols work over port 80 and 443. We know almost the entire Internet runs and relies on these ports. Azure AD fits right in.

You can build an Internet application and get it connected to the public Internet (whether  it’s running in your own datacentre (remember port 80 and 443 are probably unrestricted where you work) or in the cloud doesn’t really matter – but it means you can now use an Internet directory service to authenticate users who come to use your app.

Let’s take an example. It’s an expenses app. You deploy it to Azure. You create user objects in Azure AD and set passwords. In order to use your app, the users are redirected to Azure AD which asks them to authenticate. They are then returned to the app.

Let’s say the app needs to find your boss’s details in order to route an expenses approval to the right person. The app will use the Graph API to query the relationship between you and your boss. Imagine it realises your boss is on holiday. Well it can walk the tree of those relationships (or it can walk the “graph” of those relationship – hence the name of the API) and find your skip manager and route a message to him to ask for approval of your expenses.

You tell Azure AD about your app by creating an object in it called a Service Principal and from that moment on, the 2 things are “paired” with each other.

As you add more and more apps to the Internet you just link them all up to the same Azure AD and you’re not then issuing passwords for each app – each user uses their single Azure AD password.

It’s still a bit annoying though isn’t it? Because the users also have on-prem AD passwords. So to make that easier you can extend your on-prem AD in to Azure AD with federation and sync. First, using dir-sync you copy user objects plus a set of attributes from your on-prem AD to Azure AD. Each time you add or delete a user the change is also reflected in Azure AD. If somebody’s manager changes – the on-prem AD is updated and the delta is synced up to Azure AD for you. So now the graph API up in Azure AD is going to reflect reality. Great! And if you set up an ADFS environment between your on-prem AD and Azure AD in the cloud then when users go to submit their expenses, a little federation dance takes place that they are completely unaware of. Let’s take 2 examples – one where the user is inside the firewall, the other where the user is working from home.

1. When the user gets to the office, the first thing they do is log-in to on-prem AD. Once authenticated, AD knows who they are. Let’s say an hour later they use the expenses app. They are redirected to Azure AD, which redirects them to ADFS. ADFS is an IIS website and because they’ve already been authenticated by AD, it knows who they are. It retrieves some claims (UPN, First Name, Last Name, Manager etc) in a security token and pushes the user plus the token over to Azure AD. Azure AD trusts the token and creates a new token which it adds to the user and pushes them back to the app. The app trusts the token and gives the user access. They didn’t have to type a password – it was their first login of the day which gave them access. Federation.

Now they get home. They hit the expenses app and the same thing happens, they are pushed to Azure AD. Azure AD pushes them to the ADFS server only this time they don’t go directly to the ADFS server – there’s a proxy sat in front of it. Obviously the kerberos login they did that morning is no longer valid so the proxy pops up a login page. The user enters their credentials and the proxy checks with AD whether they’re right. If so then the dance is exactly the same as before: namely - It retrieves some claims (UPN, First Name, Last Name, Manager etc.) in a security token and pushes the user plus the token over to Azure AD. Azure AD trusts the token and creates a new token which it adds to the user and pushes them back to the app. The app trusts the token and gives the user access. They did have to type a password this time – but it’s the same password they use for logging in to on-prem AD.

That’s it in a nutshell. I’d recommend you watch the video and there are a few others also in the Azure AD section of channel 9.

Planky == @plankytronixx – GBR-257

Comments

  • Anonymous
    August 02, 2014
    Top class explanations on lots of this stuff. The Azure AD cartoon you did is really great. Please keep up the great work!

  • Anonymous
    November 02, 2014
    Thank you for the explanation.  This saved me a lot of time.   SO if an admin wanted to setup a full blown AD environment not on prem what would be the best way to do this with Azure?