#AzureAD : Device Management – Azure AD Join


In Device Management – Azure AD Registering blogpost, I had covered the basics of Azure AD device management and registering feature of Azure AD. Azure AD registering device feature allow administrators to control the access for devices, which are leveraging corporate network and resources. Azure AD join is an extension of registering a device to Azure AD. It provides all the features that are part of the registering device, in addition to that Azure AD join changes the local state of the device. This change in the local state of the device allows users to logon to a device using the organizational account instead of personal account.

Azure AD join feature is extensively beneficial for small-to-medium organizations, who don’t have corporate/on-premises Active Directory and still want to provide almost same experience and control to the employees. However, organization using Hybrid AD can also leverage the benefit of Azure AD join for windows 10 and as well as for down-level devices such as Windows 8 and Windows 7.

Note: This feature doesn’t work with Windows 10 Home edition.

Below are the following benefits that can be provided by implementing Azure AD:

  • Users will experience single-sign-on while accessing Azure managed SaaS apps and services. It is kind of similar experience that you recognize while using windows server Active Directory joined machines.
  • Provides roaming profile settings at enterprise level across AAD join devices even though users are not in the corporate network.
  • Users can choose application from the inventory prearranged by the organization.
  • Windows Hello support.
  • Allows administrators to set restriction policy for apps so that apps can be access only from the devices that meet compliance policies.

Let see how to join Windows 10 device to Azure AD.

Go to your windows 10 system and go to the settings. In settings panel, select Accounts.

Go to “Access work or school” and select “+Connect”.

To join this device to the domain, select “Join this device to Azure Active Directory”.

Enter you Azure AD account in UPN format.

In the password page, enter your password.

It will few seconds to join your device.

Read the message carefully and Select “Join” to continue.

Once you are done will get the following message, click on Done to finish.

Under “Access work or school” in settings, you can see that your device is connected to Azure AD.

Now, you will be able to see your Azure AD join device in “Devices -All devices” panel of Azure Active Directory.

Hope, it helped you.

Advertisements

#AzureAD : Device Management – Azure AD Registering


In the era of cloud-first and mobile-first, organizations embracing bring your own device concept. Control on these devices becomes necessary when these devices use your network, access your applications and data. Apart from BYOD, administrators are also concern about the devices, which are being used by the remote users because these remote users come rarely in the office network and therefore control on these devices become a big-time challenge for the administrators. Azure AD provides a fundamental baseline for device management, it becomes more powerful when combined with MDM (Mobile device management) solution such as Microsoft Intune. You can achieve it either by registering or by joining to Azure AD. Registration can be done for Windows 10, Mac, iOS and Android device while AD join can be done only for Windows 10 devices.

Here are few device configuration settings available at Azure AD Portal.

Login to the Azure AD Portal (https://aad.portal.azure.com) and go to the “Devices”.

Under “All devices” you can see all devices that are being registered or joined to the Azure AD.

Under “Device Settings” you can configure settings based on your organization needs.

Once, devices will be added then you see here in “All devices” panel.

Let see how can your users can register their devices to your corporate network. Registration allows administrators to enforce conditional access on these devices to meet security and compliance criteria of your organization. This registration also helps users to access all the applications associated with this account without logging in multiple times.

Login to you windows 10 system and go to the settings. In settings panel, select Accounts.

Go to “Access work or school” and select “+Connect”.

Enter you Azure AD account in UPN format.

In the password page, enter your password.

It will few seconds to register your machine.

Once you are done will get the following message.

Now, you will be able to see your Azure AD account through which you have registered your device.

Hope, it helped you.

#AzureAD : Azure Active Directory Domain Services Part IV


Part I, Part II and Part III of this post has covered Azure AD domain services fundamental, deployment, pricing and configuration. This post will cover how to use Azure AD DS, like join machine to the domain and AD/DNS management. Make sure your Azure AD DS VNet connects with rest of the Azure VNets, which are going to leverage this domain service. One more important consideration before moving further, use Azure AD DS DNS for all the VNets, which are going to connect with this domain service.

Let me show you, how to join Azure VMs to the Azure AD DS domain. Login to the Azure VM and check the DNS configuration to make sure that right DNS addresses have been assigned to the VM.

Open server manager to join this machine to the domain. (Note: I hope you followed the part III of this post and had reset your passwords for synchronization otherwise you may face credentials related error.)

Credentials must be used in two formats either domainname\username (insidemstech\aadadmin) or username@domainname (aadadmin@insidemstechaad.onmicrosoft.com).

Once joined, restart your machine.

Install RSAT (Remote server administration tool) to manage domain and dns of your Azure AD Domain Services.

Once rebooted, login with member of “AAD DC Administrators” group and play with your AD & DNS using native tools.

I hope you enjoyed this series of Azure AD Domain Services. Please feel free to share your experience through comments.

#AzureAD : Azure Active Directory Domain Services Part III


Part I & Part II of this post has covered fundamentals, deployment and pricing of Azure AD DS. Once, deployment completes then you can verify and finish the basic configuration.

To verify and complete the initial configuration, login to Azure Portal.

Go to the resource group, wherever you had deployed your domain services.

To verify the deployment configuration, click on Deployments.

Within deployments panel, you can see Domain Services and both the domain controllers.

Double click on any deployment name and review the configuration.

Select and open Azure AD Domain Services.

Click on view health to check the health of Azure AD Domain Services.

From the health, panel you can see the details like Back, last synchronization with Azure AD and alerts.

Now, complete Azure AD DS DNS configuration for Azure VNets. Click on “Configure DNS servers”.

In DNS servers panel, select custom in DNS servers and enter DNS server IP address as mentioned in Azure AD Domain Services and save the configuration.

Once, DNS configuration completes then you need to enable Azure AD DS password synchronization. For cloud only Azure AD tenants, ask your users to reset their password who wants to leverage Azure AD DS and wait for at least 30 min to an hour for synchronization to take place (Recommendation: Do it for all users). While for synced Azure AD tenants, you need to run a script in your forests for synchronization to take place. Follow this article for more details.

To view the deployment activity log, click on “Activity log” or “Related events” for specific deployment name under deployments.

To view the Activity log of Azure AD Domain Services, select the “Activity log” under Azure AD Domain Services.

Now, it is time to provide administrative access to the Azure AD DS administrator in your organization. Go to the Azure Active Directory portal.

Look for “AAD DC Administrators” group under all groups.

Add any members, to whom you would like to provide administrative access on Azure AD Domain Services.

You can use just-in-time access to provide administrative access of Azure AD Domain Services.

#AzureAD : Azure Active Directory Domain Services Part II


Azure Active Directory Domain Services Part I covers fundamental of Azure AD Domain services. Now, this post will cover how to enable/configure AD DS and its pricing/licensing.

To configure, login to the Azure portal.

Click on create a resource and search for Azure AD Domain Services.

From the Azure AD Domain Services portal, click on create.

Define basic settings. Set you DNS domain name in 15 characters and avoid non-routable domain such as insidemstech.local instead use name such as insidemstech1.com.

(Note: I am trying to use insidemstch.local to do some research but you should avoid non-routable domain.)

Set virtual network. (Best practice: Create a new dedicated subnet for AD DS)

Select “Create mew to define a subnet”.

Define your virtual network and click on create.

Once configured, click on Ok.

Here select administrators who are supposed to manage domain services. You can manage group membership later as well.

Review the configuration from summary tab and click on OK to start the deployment process.

This deployment process will take approximately 20-30 minutes for each domain controller. Once completed successfully, you will be able to see resources inside resource group.

Now, let see the pricing of Azure AD DS services. Microsoft has made it very simple based on the number of users and there is no up-front cost for this service.

Tier/Number of directory objects Price /Hour Price /Month
< 25,000 ~ 0.15 ~ 109.50
25,001 – 1,00,000 ~ 0.40 ~ 292.00
1,00,000 – 5,00,000 ~ 1.60 ~ 1,168.00
> 5,00,000 Contact Microsoft (wapteams@microosft.com)

Azure AD DS count all objects part of this domain that includes users, groups and domain-joined computers.

Like most of the services, Microsoft offers 99.9% SLA for user authentication belongs to managed domain, DNS lookup for records and LDAP bind to the root DSE.

#AzureAD : Azure Active Directory Domain Services Part I


Microsoft Azure cloud services are growing rapidly. Many organizations are using hybrid models and planning to move applications to the cloud as much as possible. One of the biggest hurdle in moving existing applications are identity and security. Most of the existing applications are controlled and managed by Windows server Active Directory, DNS and Group policies. At large, applications can be categorized under two umbrellas I.e. enterprise applications and line-of-business applications. Most of these enterprise applications and line-of-business applications leverage domain joined machines controlled by group policies and AD for identity needs. Now-a-days most of the enterprise applications are available in SAAS model and can leverage cloud identity for authentication and authorization, while line-of-business application can’t be rewritten overnight to support new technologies such as SAML, Open Id, OAuth etc. due to multiple reasons. Therefore, access to the domain controller from Microsoft Azure IaaS becomes a last option. Organizations achieve this goal in three ways:

  • By connecting Azure network with On-premises AD domain services.
  • By setting up a replica of existing AD domain/forest on Microsoft Azure IaaS using virtual machines.
  • By deploying a new AD domain/forest with trust between existing on-premises domain/forest and newly deployed domain/forest on MS Azure IaaS.

To resolve these issues, Microsoft has taken a leap into the directory services offerings. Microsoft Azure AD DS is managed active directory domain service provided by Microsoft Azure. It is an extension of on-premises active directory available in the cloud and managed by Microsoft. Azure AD DS doesn’t require any additional setup to sync with on-premises directory services.

It simply leverages your Azure Active Directory to connect with on-premises active directory. Once, you enable this service and link with your Azure VNet then your workloads/apps can connect to this domain services. As it is like your traditional domain controllers, deployed and managed by Microsoft therefore you can use all traditional authentication methods such as Windows Integrated authentication, NTLM, Kerberos etc. You can access these domain services by traditional AD management tools such as Active Directory Administrative Center but you don’t have to worry about the patching, management, replication, availability, backup etc. As, it is just a service therefore you will not be provided domain administrator and enterprise administrator privileges on this domain.

This service can be deployed/leveraged in two ways.

  • For hybrid organizations: In this scenario, Azure AD sync with on-premises directory services and Azure AD DS leverages user identities, their passwords and group memberships. Password sync is mandatory for hybrid organizations to leverage Azure AD DS. It is needed to authenticate users via NTLM and Kerberos authentication methods.

Courtesy: Microsoft

  • For Cloud-only organizations: In this scenario, organization doesn’t have any on-premises directory setup. AD DS leverage cloud native Azure AD tenant for all user identities, their password, and group memberships.

Courtesy: Microsoft

With the help of this service, on-premise applications can be lifted and shifted easily to the clouds. Azure AD DS deploy two domain controllers per tenant to maintain high availability of the services. It also provides automatic health detection and remediation. Azure AD DS offers LDAP bind, LDAP read and secure LDAP (including over internet). It maintains synced on-premises SIDHistory in your managed domains. Like your on-premises domain services, you can also manage your DNS and Group policies in a traditional way.

#AzureAD : Privileged Identity Management Part III


Part I and Part II of this blog posts cover how to start with Azure AD Privileged Identity Management, assign privileged administrator role to administrators, just in time access, different methods to assign just in time access and Azure AD directory role customization. This post covers Access reviews, directory roles audit history and my audit history.

Azure AD PIM Access reviews provide control to administrators to review their access roles or other administrator’s roles based on configuration. To implement access reviews, login to Azure AD portal and go to the Azure AD Privileged Identity management.

Go to the Access reviews under Azure AD directory roles. Select Add to create a new access reviews.

Fill the details based on your requirements.

In review role membership, select a role that you wish to review. In one access review, you can have only role for review. Therefore, you need to create a unique access review for each role used by your organization.

In reviewers section, select who is going to review this role either administrator himself (Members (self)) or someone else (selected users). In my case, I am selecting Members (self). Once configured everything based on requirements, select start.

Once created successfully, privilege administrators can see it on access reviews under manage while the users in case of Members (self) can see it in their review access panel under tasks.

As a privileged administrator you can stop or delete this access review and change the configuration.

As per my configuration of access reviews, password administrator has to review his access and provide the approval. User needs to login with his identity and go to the review access section under tasks.

Once you open the Access review, you can see that your identity exist in not reviewed section.

Select the user, provide the reason for approval and finally click on approve.

Once reviewed, remaining items will become 0.

Now, let see how privileged administrator can review the activity of directory roles by looking at “Directory roles audit history” under Activity in Azure AD directory roles.

Privileged administrator can scroll the page and review all the actions performed for Azure AD directory roles.

Privileged role administrators and other directory role administrators can review their tasks by going through “My audit history” under Activity in Azure AD Privileged identity Management.

Privileged role administrator can also look at the alerts section under Manage for risks and associated severity for proactive safeguards.

I have covered most of the topics related to PIM. However, you can explore more topics such as Azure resources (preview) under Manage.

I hope this series on Azure AD Privileged Identity Management helped you