Azure AD – what can I do with it in software deployment? As a system administrator, you can hardly avoid using Active Directory to manage your users and computers. But there’s also such a thing as Azure Active Directory. What are the differences? And how can it help in rolling out software?

Access control

First, here’s a brief summary of what AD is to make it easier to explain the differences. AD is a database that divides your users and computers into categories so you can manage them more easily. For example, you can give them access to files, printers, and other resources on the network. And software. This is done by defining groups and equipping them with policies, so all you have to do is add a user to such a group and all rights are taken care of at once. A bit of a basic explanation, but good enough for this article.

We also need to mention that AD runs on one or more Domain Controllers (physical servers). That’s important because you’ll soon see that it’s one of the biggest differences from Azure AD. Chances are that if your organization uses a Windows environment, you also use AD because – especially with more than about 10 computers – it’s already impossible to do without.

Software management

Where you see the biggest difference is in the fact that Azure AD runs in the cloud. That means it’s not intended to manage hardware objects. So no servers, no printers, and not even any Group Policies. But Azure AD is rock-solid when it comes to managing software rights, especially in the cloud. That applies to SaaS applications as well as other apps that (mainly) run in the cloud, such as Office 365. (It would be very strange if Microsoft didn’t manage access to this suite through its own Azure AD!) The same is the case for all other Microsoft cloud applications, such as Dynamics 365.

But it can also handle a variety of applications from other suppliers, like Slack or ZenDesk. Azure AD is also simpler in design. As we said above, there are no Group Policies, but there are also no OUs or Forests; the directory structure is as flat as can be.

Azure AD Connect

Interestingly, the ADs are not mutually exclusive. You can’t ignore AD if you have an internal network, and Azure AD is perfect if you use SaaS (and not only Microsoft – I swear!). However, it’s true that the users in one database are basically separate from those in the other. This means that your users get two usernames and two different password policies, and they’ll always have to log in separately for local network access and for applications in the cloud.

In theory.

Fortunately, there is Azure AD Connect, with which you can sync the two databases. And the great thing is that you can link Azure AD to software deployment tools, such as Easy Software Deployment. This combination creates a rock-solid hybrid management environment in which you can manage everything via the cloud, while also installing software locally.

Want to know how to tie everything together: AD, Azure AD and Easy Software Deployment? We’d be happy to help you with that.