Microsoft is continuously improving their Azure cloud services while new features get introduced in rapid pace. In this blog I want to consider some new Azure Active Directory Premium features which are currently in public preview. ’These features are:

Dynamic Groups

Azure Application Custom Domain publishing

Azure Conditional Application Access

Dynamic Groups

In Azure Active Directory, an administrator can configure groups to have dynamic memberships by setting up a rule that automatically manages group memberships. Groups are generally used to provide access to resources. With the dynamic memberships for group functionality enabled, users who satisfy the configured rule for a particular group will automatically get access to the resources that are provided by that group. This frees the administrator from having to manually manage group memberships.

In the example below we’re using the userPrincalName user attribute containing @ronnydejong.comTake into account it can take a few moments when the configured criteria takes affect and the results are shown.

As a result only users containing @ronnydejong.com upn are populated.

An example of taking benefit of dynamic group membership is assigning applications or in this example automatically assigning licenses to end-users. I’ve assigned Azure AD Premium licenses to the Licenses – Azure AD Premium (Dynamic) security group previously configured to met @ronnydejong.com upn.

As a result the users which met the criteria and thus member of the Azure AD Premium (Dynamic) security group got Azure AD Premium license assigned (Inherited – Azure…).

More detailed information of Azure AD Dynamic groups can be found here. In order to create sophisticated queries it’s useful to have a detailed understanding of Azure AD user objects which can be found here.

Custom Domain Namespace

Another great future recently introduced is the ability to use custom domains publishing web applications through Azure Application Proxy. Azure Application Proxy was originally shipped with a static namespace based on your originating *.onmicrosoft.com namespace. By introducing custom domains you’re able to use your registered domains to publish your internal web applications. which introduces great flexibility in order to publish web applications with your company owned namespaces.

In order to take benefit of this feature and access your published web applications using a custom domain you must configure a CNAME entry in your public DNS provider which points in our example ‘ndes.ronnydejong.com‘ to ‘ndes-inovativtrail.msappproxy.net‘.

Once you’ve published a secure web application (HTTPS) you must upload a certificate including the common name or a wildcard in order to publish a web service using a custom domain correctly.

Azure Conditional Application Access

Azure AD Conditional Access is powerful policy based evaluation engine that lets you create access rules for any Azure AD connected application. More sensitive apps can be assigned stricter policies, such as requiring Multi-Factor Authentication (MFA) from a registered device while less sensitive apps can have more open policies. On-Premises is now supported by applying Conditional Access to apps that use the Azure AD Application Proxy.

This gives admins a central point of management for setting Conditional Access rules for apps that are hosted on-premises and in the cloud. Rules can be set to require users accessing an on-premises application to perform MFA based on their group membership and location. Supported on-premises apps include SharePoint, Outlook Web Access and IIS based apps.

In this example the access rule will only apply to users within the specified groups “Finance” and “Human Resources”. You can also use groups to enable exceptions. By checking the ‘Except’ check box to list exempt the “Marketing” group in this example.

The preview allows the configuration of a per-application multi-factor authentication access rules. The multi-factor authentication rule may be applied to all users that are assigned to the application, or only for users within specified security groups. Users may be excluded from the multi-factor authentication requirement if they are accessing the application from an IP address (range) that in inside the organization’s network.

As I’m member of Finance department MFA authentication is mandatory.

In the current preview there are two policy options

Require Multi-factor authentication: With this option the users that the access rules apply to will be required to complete multi-factor authentication before accessing the application the policy applies to.

Require Multi-factor authentication when not at work: With this option a user that is coming from a trusted IP will not be required to perform multi-factor authentication. The trusted IP ranges can be configured on the multi-factor authentication settings page

Access rule status allows turning the rules on or off. When the access rules are off the multi-factor authentication requirement will not be enforced and username & password will be sufficient. As Jimbo is member of both “Finance” and “Marketing” he’ll not prompted for MFA authentication.

Access rules are evaluated when a user accesses a federated application that uses OAuth 2.0, OpenID Connect, SAML or WS-Federation. In addition access rules are evaluated when the OAuth 2.0 and OpenID Connect when a refresh token is used to acquire an access token. If policy evaluation fails when a refresh token is used, the error invalid_grant will be returned, this indicates the user needs to re-authenticate to the client.

For federated tenants, MFA authentication may performed by Azure Active Directory (as shown above) or by the on-premises AD FS server. By default, MFA will occur at a page hosted by Azure Active Directory. In order to configure MFA on-premises, the –SupportsMFA property must be set to true in Azure Active Directory, by using the Azure AD module for Windows PowerShell.