#AzureAD : B2B Licensing

Leave a reply

In my previous post, I have covered B2B collaboration capabilities and how to use it fundamentals. When you use this service, you should be very clear about licensing requirements for B2B functionalities. There is no black and white licensing requirements for this service but it totally depends on the functionality that you extend for B2B users.

Totally confused???

Let me simplify everything here by an example.

InsideMSTech is a conglomerate and deals in multiple business that includes many subsidiaries and it works along with variety of partners. Company has centralized supporting departments such as Finance, HR, Legal and IT. Many employees of these functions belong to subsidiaries, which are running independently.

Scenario 1: InsideMSTech is inviting external partner users as a B2B guest user and offering free Azure AD features.

License Requirements: No license required as organization is offering free services.

Scenario 2: InsideMSTech is inviting external partner users as a B2B guest user and offering free Azure AD features but guest user must use MFA for dual authentication.

License Requirements: Azure AD P1 license required as organization has mandate to use MFA. Now, you will have another question that how many licenses? You need to acquire 1 Azure AD P1 license for five unique guest users.

Scenario 3: InsideMSTech is inviting external partner users as a B2B guest user and offering Azure AD P1 features but guest user must have identity protect enabled.

License Requirements: Azure AD P1 license required for guest users in 5:1 ratio. But when you enable identity protection for B2B guest users then you must acquire Azure AD P2 licenses in 5:1 ratio.

Scenario 4: InsideMSTech subsidiary employees want to Access Azure AD services as a B2B guest user.

License Requirements: Azure AD license required based on the service used by the subsidiary employees. This license will not be in 5:1 ratio, it will be in 1:1 ratio.

Scenario 5: InsideMSTech subsidiary employees want to Access Azure AD services as a B2B guest user using their personal email address.

License Requirements: Azure AD license required based on the service used by the subsidiary employees. This license will not be in 5:1 ratio, it will be in 1:1 ratio.

Scenario 6: InsideMSTech acquired a small company, employees of this acquired company wants to Access Azure AD services as an employee of acquired company.

License Requirements: Azure AD license required based on the service used by the employees of acquired companies. This license will not be in 5:1 ratio, it will be in 1:1 ratio.

I hope, these scenarios helped you to understand B2B licensing requirements in a much simpler way. If you have any another scenario, where you need any assistance then please write your scenario in comment section. I’ll answer your query and will add your scenario in this post.

#AzureAD : B2B Collaboration

Leave a reply

Azure Active Directory business-to-business (B2B) collaboration is a capability of Azure AD that simplifies the provisioning of non-corporate users (who don’t have accounts in organizational Azure Active Directory in any form, neither using cloud native Azure AD identity nor with hybrid identity) to provide access on organizational resources, applications and data. It enables collaborative capabilities to work with people beyond your organizations such as partners, vendors, freelancers, government agencies etc. There is no mandate for these external people to have any kind of specific identity requirements. To make it simple, I am calling every non-corporate user as a partner of your organization in this blogpost.

Your partner can have Azure AD tenant, Hybrid identity or with no corporate identity, or even with or without an IT organization. Using this capability, Organization with Azure AD can provide access to the organizational resources, application and data to any partner. This Access can be provided on three different levels, i.e. tenant level, application level and user level. Organizations can also leverage the Azure AD B2B APIs to write applications that can connect two organizations in a simpler and secure manner so that the users can take the advantage of collaboration without any identity chaos.

Azure AD provides the following set of capabilities:

Work with any user from any partner	Simple and secure collaboration	No management overhead
Partners use their own credentials	Provide access to any corporate app or data, while applying sophisticated, Azure AD-powered authorization policies	No external account or password management
No requirement for partners to use Azure AD	Easy for users	No sync or manual account lifecycle management
No external directories or complex set-up required	Enterprise-grade security for apps and data	No external administrative overhead

Courtesy: Microsoft

Let me show you how to do it.

To invite a new non-corporate users, select “+New guest user”.

Enter the email address of the user and you can also add the personal message and then click on “Invite”.

User will receive a invite from the organization on his email account.

User has to open the email message and select “Get Started” to configure his account.

Once user select “Get Started” in the email message, he/she will be redirected to the organizational login page. Here select “Next” to continue.

Create your password to access the organizational resources, applications and data, and then click on Next.

You will receive a code on your email address, enter the received code here and click on Next.

Enter the captcha to verify your authenticity and click on Next.

You will be redirected to the page if your host organization has conditional access policy such as MFA.

Once, you are done with all the pre-requisite. You will be redirected Access panel of applications.

Now, as a host you can assign access to the guest users on your organizational applications.

Once, guest user will have access on application. He/She can access application from the access panel.

However, you can directly go to the enterprise applications and invite user from their itself. To invite a new guest, select “+Invite”

Enter the email address of guest and personal message.

Once, you will invite new guest user directly from the application then he/she has to follow the same method that we had followed earlier in this blogpost.

#AzureAD : Device Management – Azure AD Join

Leave a reply

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.

#AzureAD : Device Management – Azure AD Registering

Leave a reply

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.

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.

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

Leave a reply

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

Leave a reply

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

Leave a reply

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

Leave a reply

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

Leave a reply

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

#AzureAD : Privileged Identity Management Part II

Leave a reply

In Part I of this blog post, I had explained how to start with Azure AD Privileged Identity Management and assign privileged administrator role to administrators. Azure AD PIM takes the access control and monitoring to next level by providing Just in time administrator access and Access reviews. Just in time administrator access allows you to provide limited time access to perform the necessary action. To enable just in time access, you have to make administrator “eligible” for the specified role. It is a default configuration to make sure any new role assigned to the administrator shouldn’t make permanent administrator for the specified role until enabled intentionally. Once, a new role has been assigned to the administrator then an administrator can activate the new role in two ways either by himself or by approval workflow process. By default, all the administrative roles become available for an hour. This default time can be set between 30 minutes to 72 hours by changing the configuration settings.

Let see how to do it. Login to the Azure AD Portal using subscription administrator identity or by an administrator identity who has been enabled for “Privileged Role Administrator”. I am explaining these features by assigning Password Administrator role to a user to make him Password administrator for the organization.

Go to the Azure AD directory roles under Azure AD Privileged Identity Management.

Go to the Users under Manage and Click on Add.

Select “Password Administrator” role.

Now, select the user who will became a password administrator for the organization and click on OK.

Once, you have assigned this role then ask this user to login. You will observe that he can’t reset the password of any user.

As explained earlier, user will be made “eligible” for the specified role but to perform any action he must activate his role. To activate his role, he should go to “My roles” under Tasks in Azure AD PIM. Now, click on Action as highlighted in the snip.

Now, administrator has to click on “Activate” to activate this role.

Now, user has to provide “reason for role activation”. This reason will be captured in the logs for audit.

Administrator can see that his role has been activated for a specified time period.

Now, administrator should try to reset the password.

Once, task is performed then administrator can disable his role as well.

Now, let see how to change the default configuration settings for the Azure AD directory roles. Go to the settings under Azure AD directory roles and click on “Roles”.

Select the role and review the configuration parameters.

For example, I would like to enable approval process for role activation. Under require approval select “Enable” option and then select approvers.

Once selected, click on save.

Once the role configuration settings have been modified, you will observe that role status has been changed to “Request activation” from “Eligible”. Click on request activation to activate it.

Now, click on activate. Once you click on activate and specifiy the reason, a request will be sent to approver.

Now, approver has to login and go to the “Approve requests” under tasks to approve the request. Select request and click on approve.

Now, specify the reason to approve this request and click on Approve.

Once approved, ask you role administrator to verify it. Role administrator will observer that now he has access for specified time based on the configuration.

If you want to provide dedicate role to any administrator, enable him for specified role access permanently. Look at Part I for more details.