Username or Email Address
Probably we are still a bit far away from moving to the cloud completely, yet all sorts of hybrid topologies prompt us to be more and more knowledgeable about Microsoft Azure. Requirements to depth of this knowledge may vary depending on your line of work, but some Azure stack knowledge becomes a must-have almost for any IT professional these days. This article intended to give basic walkthrough on how to set up an Azure Active Directory instance and demonstrate some simple example of what you can do with it once it has been set up – sort of AAD “show and tell”. I believe a lot of people prefer hands on approach, where you trying to use technology right off the bat, throwing glances at documentation as necessary. This blogpost can be a good starting point for such type of learning journey.
There is much confusion about what is AAD and how it compares against on-premise AD and covering this is bit out of scope for the goal of the blogpost declared above. In a nutshell, we can define AAD as a central identity integrated with on-premises and cloud services. And if you want more details there is a ton of theoretical information available in the internet on what it is and how it stacks up against battletested and beloved by many on-premise AD DS. Yet, what I want to do in this article is just to give you a bit of AAD overview from the practical side of things – how we can set it up and use. Let’s begin with this task without further ado.
Process of AAD set up starts from logging-on to portal.azure.com site, clicking New and doing a search for Azure Active Directory. Once you found it you initiate the process by clicking Create (there is only one button available to in the bottom part of the the screen, so no questions here I think 😀 ):
On the next step you have to specify Organization Name and Initial domain name (which will be appended by .onmicrosoft.com domain suffix) and select Country or region from corresponding dropdown:
I will be covering adding additional public domain name to our AAD service later in this blogpost. For now, we just clicking Create and observing message “Directory is being created now” for a while:
Once this process completes you should get a notification similar to one which shown below:
In case you already have AAD instances prior to provisioning this one while going through these steps, you may need to switch from your current Azure directory to newly created one by clicking on your user name in top right corner of Azure Portal page and selecting it:
Once you switched to it, you can click on Azure Active Directory on the left side of Azure Portal page to manage it:
Before we move on to creating our first test user we can add a trial subscription to have full feature set available to us (note that you don’t need this subscription for anything described in this tutorial). For adding a new subscription, you just access Subscriptions area as shown below:
Be sure to click/highlight “Star” icon on the left to enable quick access to Subscriptions.
Once you are in Subscriptions area, click on Add button:
It will open new tab/window and navigate to account.azure.com where you will be presented with an option to set up Free Trial subscription:
I won’t be adding screenshots of Trial Subscription activation but essentially there you have to provide your contact data and do a phone/text message confirmation. Once it was added you will see your subscription in Subscriptions console:
As I already mentioned it is quite handy to pin a shortcut for Subscriptions console on the left panel with icons by clicking on “>” aka “More Services” button on the left, searching for “Subscriptions” and clicking on “Star” icon to make it yellow as shown below:
Let’s now create our test user and test AAD logon. For that we have a handy “Add a user” link in Quick tasks area which allows you to perform create user operation:
Once you clicked on “Add a user” link you presented with create user dialog which looks as follows:
Here you need to fill in mandatory fields (Name and User name) and click Create. Pay attention that for the domain part of user name we have to use domain name we selected during AAD creation appended with onmicrosoft.com suffix (this is something we will change later after adding our own domain). I also ticked Show Password check box to grab autogenerated user’s first logon password which we will use upon first logon. We can see our Don Quixote user under Users and groups:
The way AAD user provisioned on the portal is with autogenerated password which we have to change upon first logon. Let’s try to do a log on? For a simple test we will just do our first logon on https://login.microsoftonline.com:
Once credentials typed we hit Sign in and getting expected password change prompt:
Typing in current password and new one twice and hitting “Update password and sign in” button next. And voila, we logged in to our AAD account page and can check out our user profile or perform password change if necessary:
As you can see our full user name is firstname.lastname@example.org. Now we are going make things look a bit better by adding custom public domain to our AAD application and making our user name shorter. In order to do this we have to navigate to AAD > Domain names and click on Add a domain name button:
Next, we need to type in some domain name we own, I used one of domains I have available to me named zlatagroup.com:
Once we clicked on Add Domain we proceed to domain ownership verification step which requires you to add a specified TXT or MX record into DNS zone of your domain. I had some issue using TXT record, so ended up doing verification with MX one:
Steps for adding TXT/MX record may vary depending on your DNS server/provider. As I host my domain on gandi.net, specialized DNS service provider which recently redesigned their side and introduced so called “live DNS”, all that was necessary for me was to log in into my gandi.net dashboard, select domain, then DNS records and click on Add button:
Once you clicked Add button you just need to fill in record properties as required by Microsoft:
Note that it may take some time for DNZ zone update to be properly applied. I was creating this record late in the evening so as I was not able to get through this test within 10 minutes after DNS record creation I’ve just get back to it later in the morning and it worked out just fine so that I got the following confirmation:
After this test completed, our new domain is listed in Domains list, allowing us to set it as a primary domain:
To set new domain as primary we just clicking on it to open its properties and click on “Make primary”:
Let’s now see if we can benefit from it immediately using nicer and shorter logon name for a user we created earlier. For that we once again launch web browser and open https://login.microsoftonline.com and trying to logon as email@example.com:
As you can see from screenshot above this attempt fails, and it happened just because we have not updated user name. For existing users which have been created before adding custom domain we need to change domain part of their username property, i.e. the part on the right from @ sign, like this:
Once that change has been done we can try our logon one more time and it should work out well this time:
Now we have users and nice custom domain name added but just logging in to different Microsoft portals and services is not very practical unless you are doing everything using cloud services.
Let’s try something more practical for on-premise side of things, like joining Windows 10 machine to AAD. In order to do that we first need to make sure that relevant Device settings are set in our AAD instance to allow this. Settings in question reside in Device Settings section under Users and Groups options of your Azure Active Directory and entitled “Users may join devices to Azure AD” and “Users may register their devices with Azure AD” respectfully:
As we can see all users are allowed to join/register devices with AAD and we can proceed and test this functionality. But in case you wonder what is the difference between “Users may join devices to Azure AD” and “Users may register their devices with Azure AD”, last option allows users to register their devices with Azure AD by means of Workplace Join and required for MDM for Office 365. Anyhow we are doing basic demo here so let’s try to join Windows 10 machine to AAD now.
First we need to logon to Windows 10 machine and invoke Windows Settings app either by means of searching for “Settings” in Start menu or by clicking on “All settings” tile in Action Center, once there click on Accounts:
Once there, click on “Other people” option, and then “Add a work or school user”:
Note that screenshots here has been taken on machine not joined to domain, as options available to you will look a bit different on domain-joined machine. Domain joined machines can automatically register to Azure AD providing special group policy was configured and latest version of Azure AD connect has been set up. Here we just going to use stand-alone Windows 10 machine.
Clicking on Connect button will invoke the following dialogue where we just need to specify our AAD user name and click Next:
After clicking Next, we can type in user’s password and click on Sign in:
If password was typed in correctly you will be presented with the following dialogue:
And after a bit of waiting you should see this:
Once you click on Done to close this window you will see your newly added account in “Connect to work or school” section of Accounts Settings:
These steps will enable access to your organization’s apps and services using this AAD user account from this machine but won’t enable login to machine using AAD account. So, at this stage you are unable to use this account for logon to this machine, at least I was not able to do so, so I’ve decided to perform AAD device join. For that we just once again clicking on the same Connect button:
But, once we are in “Set up a work or school account” window instead of typing in our AAD user name and clicking Next, we are clicking on “Join this device to Azure Active Directory” under Alternate actions:
If you are an old school IT professional you may also notice that next to “Join this device to Azure Active Directory” link there is “Join this device to local Active Directory domain”, which is a new way of performing domain join in addition to one familiar to you from old versions of Windows. So once again we are typing our AAD user account and click on Next button:
Next, we typing in password and click on Sign In button:
If password was typed correctly you will receive “Make sure this is your organization” pop up, where you can finally click on Join button:
And after a bit of waiting we are getting confirmation that device has been connected to our AAD domain:
Machine still looks as stand-alone/workgroup joined in System properties but as previous message explains you can now sign in to machine with AAD account, by means of logging off and logging with ADD account. Once logged off, you can click on other user icon and type in your AAD credentials as shown below (note that system indicates that you will be performing sign in to your work or school account).
We are doing this with default settings/newly created AAD instance, so after typing in users’ password we are receiving “Your organization requires Windows Hello” dialogue which asks us to set up PIN.
Once you click on Set up PIN series of PIN setup wizard windows will be presented to you as shown below:
We click on Set it up now.
Assuming we’ve opted out for text message verification method we next need to type in code from SMS and hit Next:
If code has been typed in correctly you’ll be presented with Set up a PIN dialog box where you just need to type in PIN code of your choice twice:
After clicking OK here, we receive confirmation that all was set up correctly:
And we finally can sign in using either PIN code or password:
We can confirm that log on was performed with AAD users in a couple of ways shown below. First, by navigating to Settings > Accounts > Your info:
Or using something as old-fashioned as whoami command:
We can also try to login to http://portal.office.com to see that we have transparent SSO to this resource with our AAD account with no extra prompts for authentication (you sometimes still need to click on sign in button though):
With this type of set up Windows 10 Mail application automatically recognizes the signed in user and opens the Office 365 hosted inbox (if user has it) and any application written to use the Web Account Manager will automatically recognize the signed in user. AAD user can also get SSO to applications published in the Azure AD Access Panel. And as I already mentioned above, when user access web applications like http://portal.office.com, Outlook Web Access and SharePoint Online in the Edge browser he gets no extra prompts for authentication. And obviously manage your account page of windowsazure.com won’t ask you for any passwords too:
You can also see AAD user’s devices on portal.azure.com listed under Devices for each user along with Trust type info:
After going through all these steps, we have an AAD instance, AAD user and even Windows 10 machine to which we can log on with our AAD user account which I think quite good thing to have when you just beginning familiarizing yourself with AAD and from this starting point it is possible to move on to more complex and interesting things you can do with AAD. I hope this “screenshot heavy” tutorial has been useful for you and as usual you can post your follow up questions in comments below this blog post.
Sample rating item
Microsoft, Services by Mikhail Rodionov
[…] as I was busy with some other projects, but I’ve recently wrote an article entitled “Azure AD instance set up basic walkthrough” which has been published on AcloudA blog. If you want to read up on how to set up AAD […]
[…] my previous article – Azure AD instance set up basic walkthrough, I covered the process of setting up of an Azure Active Directory (AAD) instance and also such […]
You must be logged in to post a comment.