Tag: Azure Active Directory

Moving To Azure Active Directory

I recently moved from using Microsoft Live logins to Azure Active Directory at work and this is brain dump of the process. But first some theory and history around Azure directories, accounts and subscriptions.

Microsoft Live Based Logins
Most people start exploring Azure using their Microsoft Live account to sign up for the service. This will result in you having a subscription where you are the account and service administrator with a default directory for your account in Azure called <username>.onmicrosoft.com. You can add more subscriptions to your account and they will by default share the default directory for your account and the same account and service administrator. Account administrators can control billing settings and assign administrator access while service administrators can control resources in the subscription and grant administrator access but not billing settings and co-administrators can control resources but they can’t grant access to other users or billing settings. You can change the service administrator for the subscription but to change the account administrator you have to transfer the subscription. When you add more users to the subscription they will be co-administrators, this doesn’t give you granular way to control access to resources since it’s all or nothing. All resources are children of the subscription and when you delete the subscription all the resources are also deleted. This used to be the only way to access Azure.

Azure Active Directory Based Logins
The better and newer way to handle access to Azure is using Azure Active Directory. You can create multiple directories and they are independent of a subscription but a subscription will have one and only one directory that it trusts. You can add users from your organisation to the Azure Active Directory using their corporate credentials, this can be done manually or you can configure synchronisation with your on premise Active Directory. You can also add users using their Microsoft Live account or users from a third party or another Azure Active Directory. When you add users to the directory they will be assigned a security role that will control what they can do in the directory but not to resources in Azure. You can create your own groups and add your users to these groups in Azure. Using RBAC you assign users or groups to roles at a resource group level to control access to Azure resources. The users you add to a directory won’t have a subscription of their own but will have access to the resources in subscriptions that trust the directory that they are members of. You will not be able to login to the old Azure portal with your Azure Active Directory credentials. You can create your own custom roles for RBAC to gain finer control over resource. Azure Active Directory Services is currently in preview, enabling you to join machines to your Azure Active Directory and perform LDAP queries just like on-premise domains.

How to move from Microsoft Live accounts to Azure Directory.
These are the steps I followed, it worked for me and didn’t disrupt any of the existing resources in Azure. At the moment I’m not syncing from on-premise Active Directory.

  1. Change the name of your default directory to something meaningful since it will appear on every users subscription tab.
  2. In your directory create a new custom domain matching the companies corporate domain and change this domain to be the primary domain for this directory. If you leave out this step your users will end up in your default domain. Note: you have to proof that your company is the owner of the domain by adding TXT or MX records to your DNS entries and then you have to verify the domain in the Azure portal.
  3. Create users for yourself and other administrators in the directory and add them as global administrators to the directory.
  4. Change your subscriptions to trust this directory. You have to do this in the old portal under the Subscription -> Manage Subscriptions/Directory menu. If it is read-only you probably don’t have service administrator access on the subscription. When you change the directory your existing co-administrators will be removed from the subscription but you can easily add them back again afterwards. The co-administrators and service administrators will be automatically added to the owners group of the subscription in the new portal.
  5. Using the new portal you can add users to roles at the subscription level for instance I added all the other administrators to the Owner role giving them access to all resources in the subscription. You can give users access to specific resource groups, you don’t have to add them to any roles at the subscription level before settings roles on a resource in the subscription.
  6. To assign access to resource groups, open the resource group blade and click on the users button and add users or groups to roles. Make sure you choose the correct groups since there are different groups for classic and ARM deployments. Most resources will have the users button on its blade to control access, not just at the resource group level.

Resources:

Francois Delport
Latest posts by Francois Delport (see all)

Calling The Azure Billing API Unattended

In this post I’m going to investigate calling the Azure Billing API unattended. In my previous post I showed how to retrieve your Azure usage using the sample application provided by Microsoft with a few modifications. In this post I’m going to show how you can call the Billing API using a service principal. This will enable scenarios like a Windows service or scheduled tasks calling the Billing API to retrieve your usage without having to authenticate using a GUI.

There is a very detailed explanation around Azure Service Principals here. I’m going to give a short version and also highlight a few things that pertain specifically to calling the Azure Billing API.

To create a service principal you have to create an Azure Directory application and even though it will not be a web app you have to specify it as an web application since you can’t create a service principle for native applications.

Calling The Azure Billing API Unattended

Since users won’t actually be redirected to a URL to authenticate you can type in any valid URL that can be converted to URI in your code.

Calling The Azure Billing API Unattended

After the application is created you have to generate a key, this key and your client id above it will be used to authenticate at runtime. Heed the warning to copy the key since, there is really no way to retrieve it but at the same time you can just create another key if needed.

Calling The Azure Billing API Unattended

You also have to grant the AD application permissions to access the Azure Management API.

Calling The Azure Billing API Unattended

It might seem obvious but the requests you make using this service principal won’t be in the context of your user, that is the whole point of the service principal. For the service principal to access your subscription you have to grant it permission to do so at the subscription level using RBAC. Log in to the new Azure portal and click on Subscriptions and the Access icon. Add your application (Bill in this case) to the Reader Role.

Calling The Azure Billing API Unattended

Now you can use the client id and secret key to authenticate and receive a token to call the Billing API.

var authenticationContext = new AuthenticationContext(YourTenantURL,`  false);
var credential = new ClientCredential(YourAppClientId, YourAppSecretKey);
var result = authenticationContext.AcquireToken("https://management.core.windows.net/", credential);

string token = result.AccessToken;

Francois Delport
Latest posts by Francois Delport (see all)

Azure Active Directory And Azure Accounts

In post I’m going to take a closer look at Azure Active Directory and Azure Accounts. Granting other accounts access to Azure subscriptions and controlling the permissions they have is not a great experience at the moment. When you add someone to your Azure subscription they have co-admin access, which doesn’t help much if you want to prevent accidents.

Luckily we now have Azure Role Based Access Control to grant fine grained access to users. I started looking into RBAC and saw you need Azure Active Directory since the users are you assigning to roles must come from a directory and Azure Resource Manager since you will be assigning role permissions at resource level. There are tons of very detailed information about Azure AD but not in one place for a quick overview so I am writing this one.

If you look at Azure AD you will see there are different versions and I was wondering which one you need for which scenarios. You can get a very good and detailed comparison of the different versions here. I’m going to give a quick explanation for those who like it short and sweet.

All editions: You get sync with on-prem AD using Azure AD Connect, SSO for SAAS web and custom apps, user management, self-service password change (not reset) and some basic reports.

Azure AD Free: This is the edition we all get by default when you sign up for Azure or Office 365, you are limited to 10 SSO applications per user and you only have the most basic reports, the number of AD objects is limited to 500K.

Azure AD Basic: You get more reports, self-service password reset, company branding, SSO for on-prem applications using Application Proxy, 99.99% SLA

Azure AD Premium: Enterprise features, more reports, password unlock and reset with on-prem write back, Multi-factor Authentication for on-prem and cloud via phone call, text message, smart app with optional verification code, Cloud App Discovery, Microsoft Identity Manager licenses.

Some extra bits around Azure AD
Azure AD Connect makes it easier to manage users so you don’t have to create the same users on-prem and in Azure, it syncs the users in Azure AD with your on-prem AD.

Looks to me like you can’t use Azure AD instead of your local AD, it is not Active Directory as a service for on-prem. At the moment you can only add Windows 10 devices to Azure AD. Please let me know in the comments if I’m wrong.

When Azure started you could only login with Microsoft Live accounts, with Azure AD you can login to Azure using your Azure AD account which saves the hassle of managing Microsoft accounts for everyone. That said, if you only have a few people accessing Azure you can manually create users in your Azure Directory from existing Microsoft Live accounts or from scratch as Azure AD users or from other Azure Directories or external users for instance granting consultants access.

Your default Azure Directory will have the onmicrosoft.com domain name, if you want to use your own one you can add a custom domain like mycompany.com, this way you can create Azure AD users using your existing email addresses for example [email protected].

You can have both a Microsoft Live and Azure AD account with the same username but you will have to choose which one you are singing into when you login to the portal.

AzureLogin

Each Azure subscription trusts one Azure Directory and you can change the default one. Many subscriptions can trust the same Azure Active Directory, a subscription can expire but the directory will still remain there.

Francois Delport
Latest posts by Francois Delport (see all)