Tag Archives: Azure AD Premium

Publish the Cireson Configuration Manager Portal with Azure AD Application Proxy

Cireson will soon be releasing a new web based Portal for System Center Configuration Manager, http://go.cireson.com/cireson-portal-for-configmgr. This would make it possible to access a lot of functionality for Configuration Manager anywhere with a web browser. The Cireson Portal for Configuration Manager must be installed locally, either on the Configuration Manager server or on a server close to the Configuration Manager server and database.

This makes this an ideal candidate for Azure AD Application Proxy publishing, as we can make it available as an Azure AD App with all the features and possibilities that this can give, including:

  • Azure AD Preauthentication and Single Sign-On to the Portal
  • Assigning Users and Groups
  • Conditional Access
  • Easy access via the users Access Paneler or the Office 365 App Launcher

We will look into all this in a two-part blog post! This will also be a good opportunity to use the new management experience for the preview of Azure Active Directory management in the Azure Portal, https://portal.azure.com.

Part 1: Publish the Cireson Configuration Manager Portal with Azure AD Application Proxy
Part 2: Conditional Access and Self Service for the published Configuration Manager Portal Application (link when available)

Enable Azure AD Application Proxy

I you want to publish applications with Azure AD Application Proxy, there are some requirements:

  • You need an Azure AD tenant configured with licenses for Azure AD Premium P1 or EMS E3 Suite. Actually it is enough with Azure AD Basic licenses for AAD App Proxy, but if you want to configure Conditional Access you will need at least Premium P1. More on that later.
  • If you want to enable SSO for your internal users you have to synchronize those users via Azure AD Connect.
  • You have to Enable Azure AD Application Proxy for your AAD tenant directory, and download and install one or more Application Proxy Connectors.

The diagram below shows the communication flow from when the user launch the published application, authenticates to Azure AD, and then via the Application Proxy Connector installed internally access the web based portal. Single Sign-On is achieved via the Application Proxy Connector authentication on behalf of the user via Kerberos Constrained Delegation.

image

So the first step is to go to the Azure Portal, and open the Azure Active Directory blade, which at the moment is in preview. From there go to the Application Proxy section and make sure that the Application Proxy is enabled as shown below:

image

In the image above we also see that there already are some Azure AD App Proxy Connectors installed and active. They are also configured in two different groups, and these groups are used later when we publish the application. At the top of the blade, you can download a new Connector installation file.

Download and install Application Proxy Connector

The Application Proxy Connector must be installed on a server that can reach the internal web portal server. In this case I want to install the Connector locally on the Configuration Manager server that also hosts the Cireson Portal for Configuration Manager. I could have used one of my existing connectors, but they are installed respectively on an Azure VM environment and on a separate network from our Configuration Manager environment.

Following the download link from above, I download and start the Application Proxy Connector installation on my SCCM server.

image

During installation you must provide a global administrator admin account:

image

After finishing the installation of the connector, we will se the new connector with the server name in the portal.

We can now create a group, and place the connector installed in the group:

image

Publish the Configuration Manager Portal App

To start publishing the Configuration Manager Portal Application, go to Enterprise Applications and select Add, and from the Add your own app section select to add an “On-premises application”:

image

Next, specify the Name of the Application and the Internal Url. In this case I have installed it internally as http://configmgrportal. For External Url, you have a choice for the alias and domain. By default the alias will be the Application Name without spaces, appended with –<tenant name>.msappproxy.net.

image

You can change the domain to one of your verified domains, which I have done here together with changing the alias so that the External Url now will be https://configmgrportal.skill.no. By the way, you have to upload a SSL certificate if you want to use your own domain, either a wildcard certificate or a certificate with the appropriate FQDN. We will look at that later.

image

Note that I need to add a CNAME entry at my DNS provider as stated in the info box above. I will do that right now before I proceed.

I set Pre Authentication to Azure Active Directory, as I want everyone accessing the External Url to be a valid Azure AD user from my tenant. I also select to translate URL in headers, and select my previously configured App Proxy Connector Group.

Press Add to add the application to the directory. After that you are presented with a Quick start menu like below:

image

First I go to Properties, and optionally you can upload a logo which I have done here, note also that User assignment is required is set to yes, this means that no user cannot access the published application until I have added users or groups to it.

image

After saving I go to users and groups, and add some users to test the published application:

image

These users will now be able to launch the published application, but we have some more configuration to do first. As I want to have Single Sign-On configured for this application, I configure the following settings for Single Sign-On. I set the mode to Integrated Windows Authentication, meaning that the App Proxy Connector will impersonate any Azure AD authenticated user to the on-premises application via Kerberos constrained delegation.

I also need to specify a internal SPN for the application, which will be HTTP/<fqdn-of-server>, where the server is where the internal web application is installed. I will also specify which delegated login identity, which in most cases will work fine with user principal name for synchronized federated users.

image

After configuring Single Sign-On settings, and if you elected to use your own domain name, you need to upload or specify an existing SSL certificate. Go back to Application Proxy settings and click to view or change certificate settings:

image

After saving this configuration, the required portal configuration for the application is now complete, but optionally we can configure self service and conditional access, We will get back to that later in part 2 of this blog post.

That leaves only one more step, and that is to configure kerberos delegation for the App Proxy Connector server. In your on-premises Active Directory, find the computer object for the server you installed the App Proxy Connector on, and go to Delegation, and select to trust this computer for delegation to specified services only, and for kerberos only adding the computer name and http service for the server where the internal web application is installed. This should med the same as the internal spn you configured in the portal earlier for Windows integrated authentication.

image

Testing Single Sign-On

We can now test the application. Go to https://myapps.microsoft.com and log in with one of the assigned users. Among other published apps I will see the Configuration Manager Portal:

image

And if I launch it, I will see that I can access the Configuration Manager Portal, and I have been automatically signed in with my local AD user via Single Sign-On and Kerberos Constrained Delegation. I also see my url, https://configmgrportal.skill.no, which I can access directly if I want without going through the MyApps panel.

image

So now we have successfully published the Cireson Configuration Manager Portal with Azure AD Application Proxy, using SSO with Azure AD, and User Assignment so that only users that are pre-authenticated and assigned the application by Azure AD, will have access to it.

Stay tuned for part 2 of this blog post, where we will configure Conditional Access using Azure MFA and Device Compliance, and what Self Service functionality we have.

Assign EMS License with Azure AD v2 PowerShell and Dynamic Groups

While we are waiting for support for group based licensing in the Azure AD Portal I have created this Azure AD v2 PowerShell solution for assigning EMS (Enterprise Mobility + Security) license plans using Azure AD v2 PowerShell module and Dynamic Groups.

The PowerShell CmdLets used here requires the Azure AD v2 PowerShell Module, which you can read about how to install or update here: https://gist.github.com/skillriver/35fba9647fbfbe3e99718f0ad734b241

Source of Authority, Attributes, Sync and Dynamic Groups

In my scenario I want to use extension attributes to automatically calculate membership using Dynamic Groups in Azure AD. The members of these groups will be assigned the EMS licenses.

Most organizations will have an on-premises Active Directory synchronizing to Azure AD, so the source of authority is important for where I set the value of the extension attributes, as I want my Dynamic Groups to calculate membership for both On-premise and Cloud based users (I have some Cloud based admin account I want to license as well).

So, lets take a look at my local Active Directory environment. If you have Exchange installed in your organization, you will have extended the schema with extensionAttribute1..15.

But in my case, I never have installed any versions of Exchange in my current environment, and only used Exhange Online, so I don’t have those attributes. Instead I have msDS-cloudExtensionAttribute1..20.

So I decided on using the following attributes locally in AD:

image

I have previously used ENTERPRISEPACK (SkuPartNumber for Office 365 E3) for licensing Office 365 E3 plans. In this scenario I will use the msDS-cloudExtensionAttribute2 for either EMS (SkuPartNumber for EMS E3) or EMSPREMIUM (SkuPartNumber for EMS E5).

You can also use Active Directory PowerShell to set these values on-premises:

image

Note that if I had Exchange installed, I could just have used extensionAttribute1 and extensionAttribute2, and these would be automatically synchronized to Azure AD in an Exchange Hybrid deployment. However, in my case I need to manually specify the option for Directory extension attribute sync in Azure AD Connect:

image

And then selecting to synchronize those two selected attributes:

image

After these Directory extensions are configured and synchronized to Azure AD, I can check these attributes with the following AAD v2 command:

Get-AzureADUser –ObjectId <youruser> | Select -ExpandProperty ExtensionProperty

In my environment I will find these attributes:

image

Note that the msDS_cloudExtensionAttribute1..2 has now been created in Azure AD for me, and been prefixed with extension_<GUID>_, where the GUID represent the Tenant Schema Extension App:

image

So now I know that my on-premises users with values for msDS_cloudExtensionAttribute1..2 will be synchronized to the extension attributes in Azure AD. But what about users that are source from Cloud? There are no graphical way to set these extension attributes, so we will have to do that with Azure AD v2 PowerShell. In my example I have a Cloud admin account I want to set this attribute extension for (scripts are linked later in the blog):

image

With that, I now have configured the users I want with the extension attribute values, and are ready to create the Dynamic Groups.

Creating Dynamic Groups for Assigning EMS Licenses

Earlier in the blog post I mentioned that I wanted to use the msDS_cloudExtensionAttribute2 for assigning either EMS E3 or EMS E5 licenses. If I run the following command, I get my Subscriptions, here listed by SkuId an SkuPartNumber. EMSPREMIUM refers to EMS E5, while EMS refers to the original EMS which is now E3.

image

On that basis I will create 2 Dynamic Groups, one that looks for EMSPREMIUM and one that looks for EMS in the extension attribute. You can create Dynamic Groups in the new Azure AD Portal, or by running these PowerShell commands:

image

After a while memberships in these dynamic groups will be processed, and I can check members with the following commands:

image

In my environment I will have this returned, showing users with membership in the EMS E3 and EMS E5 group respectively:

image

Before I proceed I will save these memberships to objects variables:

image

Assigning the EMS licenses based on group membership

With users, attributes and dynamic groups membership prepared, I can run the actual PowerShell commands for assigning the licenses. I also want to make sure that any users previously assigned to another EMS license will be changed to reflect the new, so that they are not double licensed. Meaning, if a user already has an EMS E3 license, and the script adds EMS E5, I will remove the EMS E3 and vice versa.

The full script is linked below, but I will go through the main parts here first. First I will save the SkuId for the EMS subscriptions:

image

Then I will loop through the membership objects saved earlier:

image

Next, create License Object for adding and removing license:

image

Then create a AssignedLicenses object, adding the AssignedLicense object from above. In addition, I check if the user has an existing EMS license to be removed, and if so add that SkuId to RemoveLicenses. If there are no license to remove, I still need to specify an empty array for RemoveLicenses.

image

And then, update the user at the end of the loop:

image

After looping through the EMS E3 members, a similar loop through EMS E5 members:

image

So to summarize, with this script commands you can assign either EMS E3 or E5 licenses based on user membership in Dynamic Groups controlled by extension attributes. In a later blog post I will show how we can consistenly apply these licenses, stay tuned!

Link to the full script is below:

# PowerShell CmdLets for Assigning EMS Licenses with Azure AD v2 PowerShell Module
# Read blog post for details: https://gotoguy.blog/2017/02/17/assign-ems-license-with-azure-ad-v2-powershell-and-dynamic-groups/
# Connect to Azure AD with Global Administrator
Connect-AzureAD
# List Subscriptions
Get-AzureADSubscribedSku | Select SkuId, SkuPartNumber
# EMS E3 license Service Plans
$EMSlicense = Get-AzureADSubscribedSku | Where-Object {$_.SkuPartNumber -eq 'EMS'}
# EMS E5 license Service Plans
$EMSpremiumlicense = Get-AzureADSubscribedSku | Where-Object {$_.SkuPartNumber -eq 'EMSPREMIUM'}
# Create a Dynamic Group for EMS E3 Users to be Licensed
New-AzureADMSGroup DisplayName "EMS E3 Licensed Users" Description "Dynamic group for EMS E3 Users" `
SecurityEnabled $true MailEnabled $false MailNickname "EMSE3Users" GroupTypes "DynamicMembership" `
MembershipRule "(user.extension_<YourTenantSchemaExtensionAppId>_msDS_cloudExtensionAttribute2 -eq ""EMS"")" `
MembershipRuleProcessingState "On"
# Create a Dynamic Group for EMS E5 Users to be Licensed
New-AzureADMSGroup DisplayName "EMS E5 Licensed Users" Description "Dynamic group for EMS E5 Users" `
SecurityEnabled $true MailEnabled $false MailNickname "EMSE5Users" GroupTypes "DynamicMembership" `
MembershipRule "(user.extension_<YourTenantSchemaExtensionAppId>_msDS_cloudExtensionAttribute2 -eq ""EMSPREMIUM"")" `
MembershipRuleProcessingState "On"
# Get Group and members
$EMSE3Group = Get-AzureADMSGroup SearchString "EMS E3 Licensed Users"
# Check if membership has been processed, wait and try again if not yet
Get-AzureADGroupMember ObjectId $EMSE3Group.Id
$EMSE5Group = Get-AzureADMSGroup SearchString "EMS E5 Licensed Users"
# Check if membership has been processed, wait and try again if not yet
Get-AzureADGroupMember ObjectId $EMSE5Group.Id
# Save members to object variable
$membersEMSE3 = Get-AzureADGroupMember ObjectId $EMSE3Group.Id
$membersEMSE5 = Get-AzureADGroupMember ObjectId $EMSE5Group.Id
#region EMS License Management for Dynamic Group Membership
# Get SkuId for EMS E5 (EMSPREMIUM) and EMS
$EmsE3SkuId = (Get-AzureADSubscribedSku | Where { $_.SkuPartNumber -eq 'EMS'}).SkuId
$EmsE5SkuId = (Get-AzureADSubscribedSku | Where { $_.SkuPartNumber -eq 'EMSPREMIUM'}).SkuId
# Loop through EMS E3 Members
ForEach ($member in $membersEMSE3) {
# Get the user
$User = Get-AzureADUser ObjectId $member.ObjectId
# Create a License Object for assigning the EMS E3 SkuId
$AddLicense = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$AddLicense.SkuId = $EmsE3SkuId
# Create a License Object for removing the EMS E5 SkuId
$RemoveLicense = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$RemoveLicense.SkuId = $EmsE5SkuId
# Create a Licenses Object for Adding and Removing the Licenses
$Licenses = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
$Licenses.AddLicenses = $AddLicense
# Check if the User has license to be removed
If ($user.AssignedLicenses | Where-Object {$_.SkuId -eq $EmsE5SkuId}) {
$Licenses.RemoveLicenses = $RemoveLicense.SkuId
}
Else { $Licenses.RemoveLicenses = @() }
# And lastly, update User license with added and removed licenses
Set-AzureADUserLicense ObjectId $User.ObjectId AssignedLicenses $Licenses
}
# Loop through EMS E5 Members
ForEach ($member in $membersEMSE5) {
# Get the user
$User = Get-AzureADUser ObjectId $member.ObjectId
# Create a License Object for assigning the EMS E5 SkuId
$AddLicense = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$AddLicense.SkuId = $EmsE5SkuId
# Create a License Object for removing the EMS E3 SkuId
$RemoveLicense = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$RemoveLicense.SkuId = $EmsE3SkuId
# Create a Licenses Object for Adding and Removing the Licenses
$Licenses = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
$Licenses.AddLicenses = $AddLicense
# Check if the User has license to be removed
If ($user.AssignedLicenses | Where-Object {$_.SkuId -eq $EmsE3SkuId}) {
$Licenses.RemoveLicenses = $RemoveLicense.SkuId
}
Else { $Licenses.RemoveLicenses = @() }
# And lastly, update User license with added and removed licenses
Set-AzureADUserLicense ObjectId $User.ObjectId AssignedLicenses $Licenses
}
#endregion

view raw
EMSAssignLicense.ps1
hosted with ❤ by GitHub

Link to script for managing and listing extension attribute properties for your users:

# Azure AD v2 PowerShell Module CmdLets for working with Extension Attribute Properties
# Connect to Azure AD with Global Administrator
Connect-AzureAD
# Get a User and Read Extension Properties
$aadUser = Get-AzureADUser ObjectId <youruser>
$aadUser | Select ExpandProperty ExtensionProperty
# Serialize User Object to JSON
$aadUser.ToJson()
# Explore Object Properties
$aadUser | Get-Member
# How to: Add Extension Properties
# PS! Can only write to Cloud homed users
$aadUser = Get-AzureADUser ObjectId <yourclouduser>@elven.onmicrosoft.com
$extensionProp = New-Object "System.Collections.Generic.Dictionary2[System.String,System.String]"
$extensionProp.Add('extension_<YourTenantSchemaExtensionAppId>_msDS_cloudExtensionAttribute1','ENTERPRISEPACK')
$extensionProp.Add('extension_<YourTenantSchemaExtensionAppId>_msDS_cloudExtensionAttribute2','EMSPREMIUM')
Set-AzureADUser ObjectId $aadUser.ObjectId ExtensionProperty $extensionProp
# Check added Extension Properties
Get-AzureADUser ObjectId <yourclouduser>@elven.onmicrosoft.com | Select ExpandProperty ExtensionProperty
#region List all users with Extension Properties
$aadUsers = Get-AzureADUser | Select DisplayName, ObjectId
$aadUsersExt = @()
ForEach ($aadUser in $aadUsers) {
$user = Get-AzureADUser ObjectId $aadUser.ObjectId | Select ObjectId, DisplayName
$userDetail = Get-AzureADUser ObjectId $aadUser.ObjectId | Select ExpandProperty ExtensionProperty
        foreach ($key in $userDetail.Keys)
        {
            if($key -like "extension_<YourTenantSchemaExtensionAppId>_msDS_cloudExtensionAttribute1")
            {
                $ext1 = $userDetail."$key"
            }
            elseif($key -like "extension_<YourTenantSchemaExtensionAppId>_msDS_cloudExtensionAttribute2")
            {
                $ext2 = $userDetail."$key"
            }
else { $ext1 = ""; $ext2 = "" }
        }
$obj = [pscustomobject]@{"DisplayName"=$user.DisplayName; "ObjectId"=$user.ObjectId; "Ext1"=$ext1; "Ext2"=$ext2}
$aadUsersExt += $obj
}
# List only users with values for extension attributes
$aadUsersExt | Where {$_.Ext1 -or $_.Ext2} | FT
#endregion
# List all users
$aadUsersExt
# Serialize users and extension attributes to JSON
$aadUsersExt | ConvertTo-Json

Session Recap, PowerShell Scripts and Resources from session on Azure AD Management Skills at NICConf 2017

Last week at NICConf I presented two sessions on Management of Microsoft Azure AD, Application Publishing with Azure AD – the New Management Experience! and Take your Azure AD Management Skills to the Next Level with Azure AD Graph API and Powershell!

In the last session i presented demos and scripts with some technical details, so in this blog post I will link to those PowerShell scripts together with some explanations. See also my slides for the sessions published here: https://docs.com/jan-vidar-elven-1/7677/nicconf-2017, and the session recording might be available later which I will link to.

First i talked about the new Azure AD PowerShell v2 module and install info:

# Azure AD v2 PowerShell Quickstart module install
# Azure AD has a GA version: AzureAD and Preview version: AzureADPreview
# Check available versions installed
Get-Module AzureAD ListAvailable
Get-Module AzureADPreview ListAvailable
# Install from PowerShell Gallery
Install-Module AzureAD
Install-Module AzureADPreview
# Update new versions from PS Gallery
Update-Module AzureAD
Update-Module AzureADPreview
# Check and uninstall old versions
$Latest = Get-InstalledModule ("AzureADPreview")
Get-InstalledModule ("AzureADPreview") AllVersions | ? {$_.Version -ne $Latest.Version} | Uninstall-Module WhatIf
# Check Commands, see also list of commands at: ref. https://docs.microsoft.com/en-us/powershell/azuread/v2/azureactivedirectory
Get-Command Module AzureADPreview

Then connecting and exploring some objects and license info:

# Azure AD v2 PowerShell Quickstart Connect
# Connect with Credential Object
$AzureAdCred = Get-Credential
Connect-AzureAD Credential $AzureAdCred
# Connect with Modern Authentication
Connect-AzureAD
# Explore some objects
Get-AzureADUser
# Getting users by objectid, upn and searching
Get-AzureADUser ObjectId <objectid>
Get-AzureADUser ObjectId jan.vidar@elven.no
Get-AzureADUser SearchString "Jan Vidar"
# Explore deeper via object variable
$AADUser = Get-AzureADUser ObjectId jan.vidar@elven.no
$AADUser | Get-Member
$AADUser | FL
# Look at licenses and history for enable and disable
$AADUser.AssignedPlans
# Or
Get-AzureADUser ObjectId jan.vidar@elven.no | Select-Object ExpandProperty AssignedPlans
# More detail for individual licenses for plans
Get-AzureADUserLicenseDetail ObjectId $AADUser.ObjectId | Select-Object ExpandProperty ServicePlans
# Get your tenants subscriptions, and explore details
Get-AzureADSubscribedSku | FL
Get-AzureADSubscribedSku | Select-Object SkuPartNumber ExpandProperty PrepaidUnits
Get-AzureADSubscribedSku | Select-Object SkuPartNumber ExpandProperty ServicePlans
# Invalidate Users Refresh tokens
Revoke-AzureADUserAllRefreshToken ObjectId $AADUser.ObjectId

Then performing some Administration tasks including creating Dynamic Groups, setting user thumbnail photo, adding licenses and changing passwords:

# Create a Dynamic Group for my test users of Seinfeld characters
New-AzureADMSGroup DisplayName "Seinfeld Users" Description "Dynamic groups with all Seinfeld users" MailEnabled $false SecurityEnabled $true MailNickname "seinfeld" GroupTypes "DynamicMembership" MembershipRule "(user.department -eq ""Seinfeld"")" MembershipRuleProcessingState "Paused"
# Get Group and members
$AADGroup = Get-AzureADMSGroup SearchString "Seinfeld Users"
Get-AzureADGroupMember ObjectId $AADGroup.Id
# Set Membership Processing
$AADGroup | Set-AzureADMSGroup MembershipRuleProcessingState On
# Save members to object variable
$members = Get-AzureADGroupMember ObjectId $AADGroup.Id
# Set User Thumbnail Photo
# Note that setting Thumbnailphoto can only be set against cloud mastered objects, or else error message:
# Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration.
Set-AzureADUserThumbnailPhoto ObjectId <myuserupn or objectid> FilePath C:\_source\temp\jan.vidar@elven.no.jpg
# Get and View User Thumbnail Photo
Get-AzureADUserThumbnailPhoto ObjectId <myuserupn or objectid> view $true
#region License management for a collection of users
# For example assigning EMS E5 license plan
# Get SkuId for EMS E5 (EMS PREMIUM)
$EmsSkuId = (Get-AzureADSubscribedSku | Where { $_.SkuPartNumber -eq 'EMSPREMIUM'}).SkuId
ForEach ($member in $members) {
# Get the user
$User = Get-AzureADUser ObjectId $member.ObjectId
# Create a License Object for assigning the wanted SkuId
$License = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$License.SkuId = $EmsSkuId
# Create a Licenses Object for Adding the License
$Licenses = New-Object TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
$Licenses.AddLicenses = $License
# If I wanted to remove licenses I would use .RemoveLicenses instead
# And lastly, update User license with added (or removed) licenses
Set-AzureADUserLicense ObjectId $User.ObjectId AssignedLicenses $Licenses
}
#endregion
# Reset a Users password
# Note that synchronized users need Azure AD Premium, and Azure AD Connect with Password Write-Back Configured
$password = Read-Host AsSecureString
Set-AzureADUserPassword ObjectId <myuserupn or objectid> Password $password
# Change (not Reset) the current logged on users password
Update-AzureADSignedInUserPassword CurrentPassword $CurrentPassword NewPassword $NewPassword

In the next part of my session I went on to talk about the Azure AD Graph API and the Microsoft Graph API. The Microsoft Graph API will eventually be the “one API to rule them all”, as Azure AD also can be accessed by that API, but there are still use cases for the Azure AD Graph API.

In either case, to be able to use the APIs you must create and register an Azure AD Application of type Web App/Api, and give that Application the needed permissions to access the APIs. I showed in my session how to do this in the portal, and here you have a PowerShell Script for creating that same type of Application, this example for accessing the Azure AD Graph API:

# This Application is for accessing the Azure AD Graph Api
# Log in to Azure AD with Global Admin
Connect-AzureAD
# Create the Azure AD API Application
$azureAdApp = New-AzureADApplication DisplayName "Elven Azure AD Reporting Api App" Homepage "https://localhost" IdentifierUris "https://localhost/azureadreportingapi" ReplyUrls "https://localhost"
$keyStartDate = "{0:s}" -f (get-date).AddHours(-1) + "Z"
$keyEndDate = "{0:s}" -f (get-date).AddYears(1) + "Z"
# Create Password Key Secret
$azureAdAppKeySecret = New-AzureADApplicationPasswordCredential ObjectId $azureAdApp.ObjectId CustomKeyIdentifier "Azure AD Api Reporting Key" StartDate $keyStartDate EndDate $keyEndDate
# Get the Azure AD SPN
$azureAdSpn = Get-AzureADServicePrincipal Filter "DisplayName eq 'Microsoft.Azure.ActiveDirectory'"
# Get the Oauth2 permissions for Read and Sign-in plus Directory Read
$azureAdOauth2UserSignInProfileRead = $azureAdSpn | select expand Oauth2Permissions | ? {$_.value -eq "User.Read"}
$azureAdOauth2DirectoryRead = $azureAdSpn | select expand Oauth2Permissions | ? {$_.value -eq "Directory.Read.All"}
# Build a Required Resource Access Object with permissions for User.Read + Sign in and Directory Read
$requiredResourceAccess = [Microsoft.Open.AzureAD.Model.RequiredResourceAccess]@{
  ResourceAppId=$azureAdSpn.AppId ;
  ResourceAccess=[Microsoft.Open.AzureAD.Model.ResourceAccess]@{
    Id = $azureAdOauth2UserSignInProfileRead.Id ;
    Type = "Scope"
},
[Microsoft.Open.AzureAD.Model.ResourceAccess]@{
Id = $azureAdOauth2DirectoryRead.Id ;
Type = "Role"
}
}
# Set the required resources for the Azure AD Application
Set-AzureADApplication ObjectId $azureadapp.ObjectId RequiredResourceAccess $requiredResourceAccess
# Associate a new Service Principal to my Azure AD Application
$appspn = New-AzureADServicePrincipal AppId $azureadapp.AppId Tags @("WindowsAzureActiveDirectoryIntegratedApp")
# Add Permission Grant for that App Service Principal to the Microsoft.Azure.ActiveDirectory API
## This is the only thing that cannot be automated by now!
### Go to the Azure Portal and your Azure AD, under App Registrations, find this Reporting Api App, and under Permissions select to Grant Permission

Note that for the above script, you will need to note some output and manual operations:

  • Take a note of the Application ID, you will need that later:
    azureadapp
  • Take note of the Key Secret, you will need that later also:
    azureadappkeysecret
  • Application must be manually granted permission here, as this per now cannot be automated with PowerShell:
    azureadappgrantpermission

By the way, you should newer share this App Id and key secret publically (as I have just done here 😉 Other people could use that same information to access your APIs and Azure AD info, so take care to protect that info! (Of course I have deleted that info after showing this here 😉

Now, with this App registered in Azure AD, we can now start managing Azure AD via REST API calls, for example from PowerShell. The following script shows how we can get Self Service Password Registration Activity via the Azure AD Graph API, specifically we will use the Reporting API (https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-reports-and-events-preview). Note that the script will need the App Id and Key value noted from above:

# PowerShell for calling the Azure AD Graph Reporting REST API, https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-reports-and-events-preview
# Getting Self Service Password Reset Registrations
# This script will require registration of a Web Application in Azure Active Directory
# Method 1: Use steps here for manually creating required Web App: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-api-prerequisites
# Method 2: Use Azure AD PowerShell as documented here: https://gist.github.com/skillriver/b46c51e2902a331a91221c6828bd320c#file-azureadapiapplication-ps1
$loginURL = "https://login.microsoftonline.com"
$tenantdomain = "<yourtenant>.onmicrosoft.com"
# Fill in your App Id and Key Secret
$azureAdAppId = "<app id for azure ad application>"
$azureAdAppKey = "<valid key secret for azure ad application>"
# Create a credential based on already registered Azure AD App Id and Key Secret
$keysecurestring = ConvertTo-SecureString $azureAdAppKey AsPlainText Force
$reportingapicred = New-Object System.Management.Automation.PSCredential ($azureAdAppId, $keysecurestring)
# Get an Oauth 2 access token based on client id, secret and tenant domain
$body = @{grant_type="client_credentials";resource=$resource;client_id=$reportingapicred.UserName;client_secret=$reportingapicred.GetNetworkCredential().Password}
$oauth = Invoke-RestMethod Method Post Uri $loginURL/$TenantDomain/oauth2/token?apiversion=1.0 Body $body
# Define a header with the authorization token
$headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
# Build the request, here we are looking for SSPR activity
$topResults = 100 # Tweak this value if you want different page size and present it in a report
$reportContent = @()
$reportUrl = "https://graph.windows.net/$TenantDomain/reports/ssprRegistrationActivityEvents?api-version=beta&`$top=$topResults"
$reportCount = 0
# Returns a JSON document for the "ssprRegistrations" report
$ssprRegistrations = (Invoke-WebRequest Headers $headerParams Uri $reportUrl UseBasicParsing).Content | ConvertFrom-Json
# Adding data to the Report
$reportContent += $ssprRegistrations.value | Select Unique eventTime, role, registrationActivity, displayName, userName
# Showing the Report
$reportContent
# Exporting the Report to a Comma Separated Value file
$reportContent | Export-Csv "ElvenAzureAD_SSPRregistrations.csv" NoTypeInformation Delimiter ","

With that last export to a Csv file I can import it to Power BI as a table, and create a report and a dashboard on it, for example showing which password reset registration method the users configured, what user and role type did the registration and the count and date for the registrations:

PowerBIReport.PNG

In the session we also looked at the new Content Pack for Azure AD, showing sign-in and audit events, and also how you can get data from the Microsoft Graph API using a OData Feed:

I hope this scripts will be as useful for you as it is for me! Good luck with taking your management of Azure AD to the next level with Azure AD PowerShell and Graph APIs!

How to use PowerShell script for setting Azure AD Password Reset Writeback On-premises Permissions

When you configure the Azure AD Premium Self Service Password Reset solution on your Azure AD tenant and then the Azure AD Connect Password Writeback feature, you will need to add permissions in your local Active Directory that permits the Azure AD Connect account to actually change and reset passwords for your users  , as detailed here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords-getting-started#step-4-set-up-the-appropriate-active-directory-permissions.

I wrote this PowerShell script that helps you configure this correctly in your domain/forest. Some notes:

  • You can use it in a single-domain, single-forest domain, or in a multi-domain forest, just remember to specify a Domain Controller for the wanted domain, and for the domain the Azure AD Connect account is in.
  • You have to find the Azure AD Connect Synchronization account, it would be MSOL_xxxx.. if you have used Express settings, or a dedicated account. Look at current configuration for details.
  • You can specify an OU for your users, and if inheritance is enabled all subordinate users and OUs will inherit the permissions. If not, please run the script once for each OU you want the permissions to be applied for.

Here is the script:

# Description: Sets Azure AD Connect Password Write Back AD Permissions
# Created by: Jan Vidar Elven, Enterprise Mobility MVP, Skill AS
# Last Modified: 01.06.2016
# Run this on-premises for your domain/forest
Import-Module ActiveDirectory
#region Initial Parameters/Variables
# Domain Controller in wanted domain, leave blank if using current domain
$dcserver = "mydc.domain.local"
# Azure AD Connect Synchronization Account
$aadcaccount = "MSOL_xxxxx"
# Azure AD Connect Account Domain Controller
$aadcserver = "mydc.domain.local"
# Organizational Unit Distinguished Name, starting point for delegation
$oudn = "OU=<UsersOU>,DC=domain,DC=local"
#endregion
# Check if default current domain or specified domain should be used
If ($dcserver -eq $null) {
# Get a reference to the RootDSE of the current domain
$rootdse = Get-ADRootDSE
# Get a reference to the current domain
$domain = Get-ADDomain
}
Else {
# Get a reference to the RootDSE of the domain for the specified server
$rootdse = Get-ADRootDSE Server $dcserver
# Get a reference to the domain for the specified server
$domain = Get-ADDomain Server $dcserver
}
# Refer to my Active Directory, either current or specified server from above
New-PSDrive Name "myAD" Root "" PsProvider ActiveDirectory Server $rootdse.dnsHostName
# Change to My Active Directory Command Prompt
cd myAD:
# Create a hashtable to store the GUID value of each schema class and attribute
$guidmap = @{}
Get-ADObject SearchBase ($rootdse.SchemaNamingContext) LDAPFilter `
"(schemaidguid=*)" Properties lDAPDisplayName,schemaIDGUID |
% {$guidmap[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID}
# Create a hashtable to store the GUID value of each extended right in the forest
$extendedrightsmap = @{}
Get-ADObject SearchBase ($rootdse.ConfigurationNamingContext) LDAPFilter `
"(&(objectclass=controlAccessRight)(rightsguid=*))" Properties displayName,rightsGuid |
% {$extendedrightsmap[$_.displayName]=[System.GUID]$_.rightsGuid}
# Get a reference to the OU we want to delegate
$ou = Get-ADOrganizationalUnit Identity $oudn
# Get the SID value of the Azure AD Connect Sync Account we wish to delegate access to
$a = New-Object System.Security.Principal.SecurityIdentifier (Get-ADUser $aadcaccount Server $aadcserver).SID
# Get a copy of the current DACL on the OU
$acl = Get-ACL Path ($ou.DistinguishedName)
# Create an Access Control Entry for new permission we wish to add
# Allow the Azure AD Account to reset passwords on all descendent user objects
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule `
$a,"ExtendedRight","Allow",$extendedrightsmap["Reset Password"],"Descendents",$guidmap["user"]))
# Allow the Azure AD Account to change passwords on all descendent user objects
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule `
$a,"ExtendedRight","Allow",$extendedrightsmap["Change Password"],"Descendents",$guidmap["user"]))
# Allow the Azure AD Account to write lockoutTime extended property
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule `
$a,"WriteProperty","Allow",$guidmap["lockoutTime"],"Descendents",$guidmap["user"]))
# Allow the Azure AD Account to write pwdLastSet extended property
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule `
$a,"WriteProperty","Allow",$guidmap["pwdLastSet"],"Descendents",$guidmap["user"]))
# Re-apply the modified DACL to the OU
Set-ACL ACLObject $acl Path ("myAD:\"+($ou.DistinguishedName))

Hope the script will be helpful!

Speaking at NIC 2017

I’m very happy that I have been selected as a speaker again for next years NIC 2017!

I will have at least one session to present, and hoping for a second session but the organizers have a lot of interesting session proposals to choose from so we’ll see.

My session will be about Enterprise Applications and Publishing in the new Azure AD Management Experience:

image

In this session we will look into the new management experience of Azure AD Applications in the new Azure Portal. The session will cover publishing and management of Application Proxy applications, Web App/API Applications and Enterprise Applications including SaaS Applications, and how and in which scenarios we can use the new Azure Portal, PowerShell or the Classic Portal for administration. Another important topic that will be covered is how you can configure Conditional Access for those applications for Users and Devices with the Enterprise Mobility & Security offering.

NIC 2017 is 2nd and 3rd of February, with a Pre-Conf day at the 1th. Read more at www.nicconf.com.

Hope to see you there!

Speaking at #ExpertsLive 2016 Netherlands

Next week at Tuesday 22nd of November I will be back speaking at ExpertsLive 2016, at CineMed Ede, Netherlands. After my first visit and speaking there last year, I always wanted to go back to this great community event, and I’m very happy and honored to be invited to speak again.

ExpertsLive NL 2016 will feature over 50 sessions, plus Keynote and Closing note, in as much as 9 different tracks ranging from Azure and Azure Stack, to Managebility, Automation, Windows Server 2016, Office 365, Security and Windows 10! In addition there will be great sponsors and networking. What more can you ask of a conference. There will be over 1000 attendees mostly from Netherlands, but also from visiting nearby countries.

My session will be on Azure Active Directory and how you can perform Premium Management and Protection of Identity and Access with Azure AD, covering solutions like Privileged Identity Management, Identity Protection, Multi-Factor Authentication and Azure AD Connect Health. It is very important to protect your identity now, let me show you how, and I will show some nice demos as well, hope to see you there!

Read more about ExpertsLive here: http://www.expertslive.nl

EXPERTSLIVE.5011_email-signature_spreker_ENG_630x180

Speaking at UC Day UK 2016

I’m excited to be speaking at UC Day UK at the National Conference Centre, in Birmingham, 24th October 2016. If you are interested in attending or reading more, visit this link http://www.ucday.uk.

My session will be on Azure Active Directory and how you can perform Premium Management and Protection of Identity and Access with Azure AD, covering solutions like Privileged Identity Management, Identity Protection, Multi-Factor Authentication and Azure AD Connect Health. I will show some nice demos as well, hope to see you there!

JoinSkillriverPremiumIdentityManagementAzureAD

In addition to my session I will during the day be interviewed on The Skype Show (www.theskypeshow.com) about Azure AD and Identity and Access, some of these sessions will go live on Microsoft Channel 9 if logistics permit, or via Skype for Broadcast Meetings or Skype Meetings, and in anyway be recorded and released on Channel 9, Youtube and The Skype Shows website.

image

UC Day will cover technologies like Skype for Business, Exchange, Office 365, Azure and Cloud, and with 25 breakout sessions over 5 tracks, together with expo and sponsors, keynote and closing note. I very much look forward to come there!

How to enable Azure MFA for Online PowerShell Modules that don’t support MFA?

In this blog post I will look into how you can accomplish Azure Multi-Factor Authentication for Admins even though the Online PowerShell Module don’t support it. The key to do this is to implement and use Azure AD Privileged Identity Management, which is an Azure AD Premium P2 / EMS E5 feature.

The Problem

Administration of Online Services with PowerShell can be done with different PowerShell modules or for some scenarios setting up a remote session to the Online Service.  But not all scenarios support Azure MFA natively.

A quick overview of the main modules that DO support Azure MFA today:

All of these above supports Azure MFA as long as you are not passing in a Credential object. There are also more advanced scenarios for programmatic access with Access Token and Certificates that I will not cover here for some of these modules. The main thing is that when you create a Credential object with Get-Credential, and pass that in as a Parameter to the above modules, Azure MFA will not work if the Admin user has been configured to use that. We’ll see some examples later in the blog. Note also that if you have an older version of MSOnline or Aadrm which required the Online Sign-In assistant, these will not work with Azure MFA and you must upgrade to the latest versions.

So what about the modules and scenarios that don’t support Azure MFA. These are mainly Office 365 and Remote PowerShell:

  • Exchange Online Remote PowerShell (Update, a new Exchange Online Remote PowerShell module has now been released, but for a normal PowerShell remoting session this would still not support Azure MFA)
  • Skype for Business Online Remote PowerShell
  • Office 365 Security & Compliance Center Remote PowerShell

In these scenarios you must create a Credential object, and pass that in as a parameter when connecting to the service, thus blocking the use of Azure MFA.

A Security Best Practice for Admins

Today I just don’t find it acceptable for Admin accounts for any Online Service like Azure or Office 365, to not use Multi-Factor Authentication or some other protection mechanism, and just depend on username and password!

In addition to that, as an Organization you have to have control of your identities, employees and admins come and go, I have seen many times that Organizations still have Admin accounts for users that have left the company for a long time ago.

Most Organizations have Directory Synchronization from local Active Directory to Azure AD, making it possible to synchronize your local admin accounts. You then have a choice: Should I use synchronized admin accounts for the Admin Roles in Azure/Office 365? Or should I only create Cloud only admin accounts for this purpose?

My security best practice is to use a combination of both, so that:

  • Synchronized On-Premise Admin Accounts for the most important, permanent and sensitive admin accounts, like Global Admins, Security Admins, Azure Subscription Admins and more. These accounts will be set up to require Azure MFA, as these accounts possibly can connect to On-Premise resources.
  • Cloud Only Admins accounts for Role Based Administration, additional temporary Global Admins or other scenarios for intermittent Azure and Office 365 administration. These accounts will not be set up for Azure MFA, but I use Azure AD Privileged Identity Management to require Azure MFA when activating the role. Some of these accounts also includes service accounts for Directory Synchronization, Intune Connector etc.

The Solution

I have found that the best way to protect both type of Admin accounts is to use the Azure AD Privileged Identity Management and Azure MFA in combination so that:

  • In general all of the permanent Admin Accounts with a few exceptions are required to use Azure MFA. These Admin accounts can use all PowerShell modules that support MFA when connecting.
  • Role-based admins (for example Exchange Admins, Skype for Business Admins,..) are set up to be Temporary/Eligible Admins in Azure AD Privileged Identity Management, which require Azure MFA at activation time. After the admin role is activated, he or she can use the PowerShell modules/remote sessions that don’t support Azure MFA natively.

The downside of this solution is that Azure AD Privileged Identity Management require an Azure AD Premium P2 license or Enterprise Mobility E5 license, which will be Generally Available Sept 15th. Azure MFA are free to use for Admin accounts for Online Services.

How to set it up

In the following steps I will show how to set this up and how it will work. For the purpose for this demo I will work with my demo environment with the tenant name elven.onmicrosoft.com. I have also configured directory synchronization from my on-premise Active Directory, these users will have a UPN suffix of elven.no.

In my environment I have a fictional character called Ola Nordmann. Ola is an Exchange Admin in our Hybrid Exchange environment, and needs permissions to administer Exchange Online in Office 365 both via the management portal and via Exchange Online PowerShell.

Ola has these two accounts now in Azure AD:

image

As per the solution described, I will configure and require Azure MFA for the on-premise admin account, and for the cloud admin account I will use Privileged Identity Management and MFA for role activation.

Configure Multi-Factor Authentication

The easiest way to enable MFA for a user is via the Office 365 Admin portal at https://portal.azure.com. In the user list I find and select the admin user I want to enable MFA for:

image

The Manage multi-factor authentication will take me to the Azure AD multi-factor authentication administration page, where I find and select the admin user:

image

On the right-hand side I select to Enable for the selected user(s):

image

After that I confirm that I want to enable MFA for the user:

image

And get confirmation:

image

Now I see that the status is Enabled, this means that the user needs to log on and configure the authentication method for MFA first:

image

Configure Admin Role

Next, I will give Ola Nordmann the Exchange Administrator role, so that he can administer Exchange Online.

Back in the Office Admin portal I see that the user now has no roles:

image

I select Edit, and choose the Customized administrator and Exchange administrator role, and add the e-mail address of the user:

image

Next, I add the same Exchange administrator role to the Ola Nordmann (Cloud Admin) user:

image

So, at this time, both admin users are Exchange administrators, but only the ola.admin@elven.no on-premise admin account has been configured for multi-factor authentication.

Log on and activate multi-factor authentication method for admin user

Now I will log on the ola.admin@elven.no account to https://portal.office.com.

Since this admin account has been configured for MFA, I must set that up now:

image

I need to select an authentication method. In this demo I will use the Microsoft Authenticator App:

image

I select to set up and configure the mobile app:

image

I open up the Microsoft Authenticator app on my phone, and follow the instructions from above. After that I get confirmation that the mobile app has been configured.

image

Now I need to select Contact me to test the authentication:

image

At my phone I get the notification in the App and select verify, and I should be successful. Since I only have set up the mobile app, I also need to add phone number verification in case I lose access to the app. I type my mobile phone number and press next.

image

And in the last step I get an app password to use on some apps, I will not be needing this now for this demo, and click Done:

image

Back in the portal login, I will now be prompted to authenticate with my app:

image

After successfully authenticating I’m logged in to the portal:

image

And since this user has an Exchange administrator role, I can see limited information in the Office 365 admin portal and launch the link to the Exchange admin portal:

image

Try to access Exchange Online PowerShell with MFA enabled admin

First, a quick look back at the multi-factor authentication administration page, where the admin user status has now been updated to Enforced. This happens after the users have been enabled for MFA, and after they have successfully configured their authentication methods. Enforced means that they will now be required to do MFA when authenticating against online services:

image

Let’s try to access Exchange Online PowerShell with this admin user. Instructions for connecting with PowerShell for Office 365 services are detailed here: https://support.office.com/en-us/article/Managing-Office-365-and-Exchange-Online-with-Windows-PowerShell-06a743bb-ceb6-49a9-a61d-db4ffdf54fa6?ui=en-US&rs=en-US&ad=US

I launch a PowerShell window and get a Credential object:

image

After that I try to create a remote session with that credential:

image

As expected this will fail, as multi-factor auhtentication is required for the ola.admin@elven.no account.

In the next part we will look at the other cloud admin user and configure the workaround using Azure AD Privileged Identity Management.

Configure Azure AD Privileged Identity Management for Exchange administrators

At this next step I log in as a Global Administrator, and if I haven’t already added the Privileged Identity Management solution, I can add it from the Azure Marketplace:

image

The first Global Administrator that set up Privileged Identity Management will added to the Security Administrator and Privileged Role Administrator Roles. After that we can manage the privileged roles. If you have previously added the solution, you will have to activate your Privileged Role administrator first.

image

When I select the Exchange Administrator role, I can see both admin accounts for my Ola admin user. These roles are assigned on a permanent basis:

image

Azure AD Privileged Identity Management will let me assign and change admin roles from permanent to eligible for temporary activation. I will do this for the ola.admin@elven.onmicrosoft.com cloud admin account:

image

After I click Make eligible, the admin account are removed from permanent role and are now listed as Eligible:

image

Lets click on the Settings button for the Exchange Administrator role. At settings I can set the activation duration, email notifications, ticketing and fore some roles I can select whether to require multi-factor authentication for activation:

image

These settings can also be set as default for all roles:

image

At this point my cloud admin ola.admin@elven.onmicrosoft.com has been removed as a permanent Exchange Administrator, and will require activation before he will be temporarily activated as an Exchange Administrator for one hour duration.

Log on as admin user without activation

When I log in to the Office 365 portal with the ola.admin@elven.onmicrosoft.com, I will see that this user is just a normal user with no admin links, This is expected as the user hasn’t activated the Exchange Administrator role.

image

Activate the Exchange Administrator Role

Next I go to the Azure portal at https://portal.azure.com still logged on as ola.admin@elven.onmicrosoft.com. First I need to add the Privileged Identity Management solution:

image

After adding the solution, I can request activation for the roles I’m eligible for, in this case Exchange Administrator:

image

When requesting activation I need to verify my identity first:

image

If my account hasn’t already been set up for multi-factor authentication, it will be guided to do that now:

image

After configuring and verifying multi-factor authentication, I can now activate my Exchange Administrator role and provide a reason:

image

After successful activation I can verify the duration I will be activated for:

image

Log on to the Office 365 Portal and Exchange Admin Center after activation

After activation, I should log off and back on with my activated admin role account, and this time I will see the Exchange Admin portal:

image

Log on to Exchange Online PowerShell after activation

And finally, I can start an Exchange Online PowerShell Session with my activated account. First I get my credential:

image

Then I can create the remote Exchange Online session and import it to PowerShell:

image

And finally just try out some Exchange Online administration successfully:

image

Summary

At the end of this long blog post, we can summarize that we have accomplished the solution of adding Azure Multi-Factor Authentication for scenarios where the PowerShell Module or Remoting Session does not natively support it. This is made possible by using Azure AD Privileged Identity Management, and by making some role administrators eligible and require MFA when activating. This way they have verified their identity before they connect with the Credential object.

This is just one scenario where both Azure AD MFA and Privileged Identity Management can be used together for increased security and reduce the attack surface of having vulnerable permanent administrator accounts and roles.

I hope this blog post have been informative and helpful, please reach out or comment if you want to know more or have any questions.

Experts and Community unite at last ever #SCU_Europe 2016! #ExpertsLive next

This years SCU Europe 2016, for the first time outside Switzerland in the 4th year running, was held in Berlin at the BCC (Berlin Congress Center) close to the Alexander Platz in the eastern parts of “Berlin Mitte”.

 

 

The intro video introducing the Experts:

Let’s begin with the end: at the closing note SCUE general Marcel Zehner announced and with a little bit of emotion that this was the last ever SCU Europe to be held.. You and your organization should be proud of what you have achieved, Marcel, it is one of the best community conferences around, and I have been fortunate to be able to visit all 4 starting with Bern in 2013, Basel in 2014 and 2015, and now Berlin in 2016. It’s only cities with B’s is it? In fact, you never know what twists and turns your career takes, but looking back I’m not sure I would be where I am now in turn of being presenter, MVP and community influencer myself if I had not travelled alone to Bern 4 years ago, that’s where I really started working with and for the Community (with a capitol C)!

Luckily SCU Europe will continue as Experts Live Europe next year! Same place at BCC, same organization and format, and the same dates only next year it will be: 23rd – 25th of August 2017. A new web page was launched, www.expertslive.eu, and Twitter (@ExpertsLiveEU) and Facebook have been changed to reflect that. The hash tag #SCU_Europe will eventually be inactive and you should now use #ExpertsLive.

image

I think this is a very good decision, there has already been discussion on that the name “System Center Universe” is not really reflecting the content and focus of the conference, now embracing the Cloud, with content areas for Management, Productivity, Security, DevOps, Automation, Data Platform and more. ExpertsLive, originally a 1-day community conference in Netherland running each year back from 2009 and with up to 1200 participants, will now be a network of conferences, ranging from region based (ExpertsLive Europe, but also SCU APAC and SCU Australia will be ExpertsLive APAC and Australia next year), and local, country based ExpertsLive like the one in Netherlands, but more will come.

image

The closing note video announcing Experts Live Europe:

This year at SCU Europe I was one of the Experts and presented two sessions on “Premium Identity Management and Protection with Azure AD” and “Deep Dive: Publishing Applications with Azure AD”. I also took part in a “Ask-the-Experts” area together with Cameron Fuller and Kevin Greene where we took questions on the topic System Center 2016. I participated on a discussion panel on Friday morning with Markus Wilhelm from Microsoft Germany on the subject Defense Strategies and Security, and of course we had the Meet and greet with the Experts at the Networking party. It was a really great experience speaking at this conference, thanks for having me!

 

 

 

 

The content of the conference this year was great, and for the first time there was 5 tracks, with over 70 sessions presented! All presentations and session recordings will be at Channel 9 in a few weeks time, so make sure you look at anything you missed or want to see again if you where there, or if you weren’t at the conference this year you can look at your sessions of interest.

I was travelling with a group this year, both from my company and some of our customers, in total we were 7 in the group, and also had 3 cancellations the last week before the conference from some customers that could not make it after all. Moving the conference to Berlin is a big part of why it now was easier to attract more Nordic attendance I think. We stayed at the Park Inn by Radisson right by the Alexander Platz and BCC, so it was really central and nice.

 

 

 

 

In good tradition there are a lot of parties and social networking going on. On the first night there are the Sponsors and Speakers Party, which was held in Mio right by the TV Tower by Alexander Platz, on Thursday we had the attendee Networking Party at the conference center. Later that night our group and some more partners/customers of Squared Up went on to another party at Cosmic Kaspar. It was really hot, so basically the party was at the pavement! On the last day we had the Closing Drinks, sponsored by Cireson and itnetX at Club Carambar, also close to the Alexander Platz. In addition, there are a lot of unofficial gatherings going on, lots of laughs and new and old friends have a good time.

 

 

 

 

 

 

See you next year at Experts Live Europe in Berlin 23-25th August, 2017!

Publish the itnetX ITSM Portal with Azure AD App Proxy and with Conditional Access

Last week at SCU Europe 2016 in Berlin, I presented a session on Application Publishing with Azure AD. In one of my demos I showed how to use Azure AD Application Proxy to publish an internal web application like the itnetX ITSM Portal. The session was recorded and will be available later at itnetX’s Vimeo channel and on Channel 9.

In this blog post I will detail the steps for publishing the portal in Azure AD, and also how to configure Conditional Access for Users and Devices. Device compliance and/or Domain join conditional access recently went into preview for Azure AD Applications, so this will be a good opportunity to show how this can be configured and how the user experience is.

Overview

itnetX has recently released a new HTML based ITSM Portal for Service Manager, and later there will be an analyst portal as well.

This should be another good scenario for using the Azure AD Application Proxy, as the ITSM Portal Web Site needs to be installed either on the SCSM Management Server or on a Server that can connect to the Management Server internally.

In this blog article I will describe how to publish the new ITSM Portal Web Site. This will give me some interesting possibilities for either pass-through or pre-authentication and controlling user and device access.

There are two authentication scenarios for publishing the ITMS Portal Web Site with Azure AD App Proxy:

  1. Publish without pre-authentication (pass through). This scenario is best used when ITSM Portal is running Forms Authentication, so that the user can choose which identity they want to log in with.
  2. Publish with pre-authentication. This scenario will use Azure AD authentication, and is best used when ITSM Portal Web Site is running Windows Authentication so that we can have single sign-on with the Azure AD identity. Windows Authentication is also default mode for ITSM Portal installations.

I will go through both authentication scenarios here.

I went through these steps:

Configure the itnetX ITSM Portal Web Site

First I make sure that the portal is available and working internally. I have installed it on my SCSM Management Server, in my case with the URL http://azscsmms2:82.

In addition to that, I have configured the ITSM Portal to use Forms Authentication, so when I access the URL I see this:

image

Create the Application in Azure AD

In this next step, I will create the Proxy Application in Azure AD where the ITSM Portal will be published. To be able to create Proxy Applications I will need to have either an Enterprise Mobility Suite license plan, or an Azure AD Basic/Premium license plan. App Proxy require at least Azure AD Basic for end-users accessing applications, and if using Conditional Access you will need a Azure AD Premium license. From the Azure Management Portal and Active Directory, under Applications, I add a new Application and select to “Publish an application that will be accessible from outside your network”:

I will then give a name for my application, specify the internal URL and pre-authentication method. I name my application “itnetX ITSM Portal”, use http://azscsmms2:82/ as internal URL and choose Passthrough as Pre-Authentication method.

After the Proxy Application is added, there are some additional configurations to be done. If I have not already, Application Proxy for the directory have to be enabled. I have created other Proxy Applications before this, so I have already done that.

After I have uploaded my own custom logo for the application, I see this status on my quickstart blade for the application:

image

I also need to download the Application Proxy connector, install and register this on a Server that is member of my own Active Directory. The Server that I choose can be either on an On-Premise network, or in an Azure Network. As long as the Server running the Proxy connector can reach the internal URL, I can choose which Server that best fits my needs.

When choosing pass through as authentication method, all users can directly access the Forms Based logon page as long as they know the external URL. Assigning accounts, either users or groups, will only decide which users that will see the application in the Access Panel or My Apps.

image

I now need to make additional configurations to the application, and go to the Configure menu. From here I can configure the name, external URL, pre-authentication method and internal URL, if I need to change something.

I choose to change the External URL so that I use my custom domain, and note the warning about creating a CNAME record in external DNS. After that I hit Save so that I can configure the Certificate.

image

After that I upload my certificate for that URL, and I can verify the configuration for the external and internal URL:image

When using passthrough I don’t need to configure any internal authentication method.

I have to select a connector group, where my installed Azure AD App Proxy Connectors are installed, and choose to have the default setting for URL translation. Internal authentication is not needed when using Pass Through authentication:

image

If I want, I can allow Self-Service Access to the published application. I have configured this here, so that users can request access to the application from the Access Panel (https://myapps.microsoft.com). This will automatically create an Azure AD Group for me, which I either can let users join automatically or via selected approvers:

image

After I have configured this, I am finished at this step, and can test the application using pass through.

Testing the application using pass through

When using Pass through I can go directly to the external URL, which in my case is https://itsmportal.elven.no. And as expected, I can reach the internal Forms Based login page:

image

For the users and groups I have assigned access to, they will also see the itnetX ITSM Portal application in the Access Panel (https://myapps.microsoft.com) or in My Apps, this application is linked to the external URL:

image

This is how the Access Panel looks in the coming new look:

image

Now I’m ready to do the next step which is change Pre-Authentication and use Azure AD Authentication and Single Sign-On.

Change Application to use Azure AD Authentication as Preauthentication

First I will reconfigure the Azure AD App Proxy Application, by changing the Preauthentication method to Azure Active Directory.

Next I need to configure to use Internal Authentication Method “Windows Integrated Authentication”. I also need to configure the Service Principal Name (SPN). Here I specify HTTP/portalserverfqdn, in my example this is HTTP/azscsmms2.elven.local.

image

PS! A new preview feature is available, to choose which login identity to delegate. I will continue using the default value of User principal name.

Since I now will use pre-authentication, it will be important to remember to assign individual users or groups to the Application. This enables me to control which users who will see the application under their My Apps and who will be able access the application’s external URL directly. If users are not given access they will not be able to be authorized for the application.

Enable Windows Authentication for itnetX ITSM Portal

The itnetX ITSM Portal site is configured for Windows Authentication by the default, but since I reconfigured the site to use Forms Authentication earlier, I just need to reverse that now. See installation and configuration documentation for that.

It is a good idea at this point to verify that Windows Integrated Authentication is working correctly by browsing internally to the ITSM Portal site. Your current logged on user (if permissions are correct) should be logged in automatically.

Configure Kerberos Constrained Delegation for the Proxy Connector Server

I now need to configure so that the Server running the Proxy Connector can impersonate users pre-authenticating with Azure AD and use Windows Integrated Authentication to the Squared Up Server.

I find the Computer Account in Active Directory for the Connector Server, and on the Delegation tab click on “Trust this computer for delegation to specified services only”, and to “Use any authentication protocol”. Then I add the computer name for the web server that the ITSM Portal is installed on and specify the http service as shown below (I already have an existing delegation set up):

image

This was the last step in my configuration, and I am almost ready to test.

If you, like me, have an environment consisting on both On-Premise and Azure Servers in a Hybrid Datacenter, please allow room for AD replication of these SPN’s and more.

Testing the published application with Azure AD Authentication!

Now I am ready to test the published proxy application with Azure AD Authentication.

When I go to my external URL https://itsmportal.elven.no, Azure AD will check if I already has an authenticated session, or else I will presented with the customized logon page for my Azure AD:

image

Remember from earlier that I have assigned the application either to a group of all or some users or directly to some pilot users for example.

If I log in with an assigned user, I will be directly logged in to the ITSM Portal:

image

However, if I try to log in with an Azure AD account that hasn’t been assigned access to the application, I will see this message:

image

This means that the pre-authentication works and I can control who can access the application via Azure AD.

Conditional Access for Users and Devices

When using Azure AD as preauthentication, I can also configure the application for conditional access for users and devices. Remember this is a Azure AD Premium feature.

From the the configuration settings for the application I can configure Access Rules via MFA and location, and Access Rules for devices which now is in Preview:

image

If I enable Access Rules for MFA and location I see the following settings, where I can either for all users or for selected groups require multi-factor authentication, or require multi-factor when not at work, or block access completely from outside work. I have define my network location IP ranges for that to take effect.

image

If I enable Access Rules for devices, I see the following settings. I can select for all users or selected groups that will have device based access rules applied (and any exceptions to that).

I can choose between two device rules:

  • All devices must me compliant
  • Only selected devices must be compliant, other devices will be allowed access

If I select all devices, a sub option for windows devices shows where I need to select between domain joined or marked as compliant, or just marked as compliant or domain joined selectively.

image

If I select the second option, I can even specify which devices will be checked for compliancy:

image

So I can with different access rules for both MFA, location and selected devices, in addition to the Azure AD Preauthentication, apply the needed conditional access for my application.

In this case I will select device rules for compliant/domain joined, and for all the different devices. This will mean that for users to access the ITSM Portal, their device must either be MDM enrolled (iOS, Android, Windows Phone) or in the case of Windows devices either be MDM enrolled, Azure AD Joined, Compliant or Domain Joined. Domain joined computers must be connected to Azure AD via the steps described here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-devices-group-policy/.

After I’m finished reconfiguring the Azure AD App Proxy Application, I can save and continue and test with my devices.

Testing device based conditional access

Lets see first when I try to access the ITSM Portal via an unknown device:

image

On the details I see that my device is Unregistered, so I will not be able to access the application.

Now, in the next step I can enroll my Windows 10 Device either through MDM or via Azure AD Join. In this scenario I have added my Windows 10 to Azure AD Join:

image

If I look at the Access Panel and Profile I will also se my devices:

image

The administrator can see the Device that the user has registered in Azure Active Directory:

image

Lets test the published ITSM Portal again:

image

Now I can see that my device has been registered, but that it is not compliant yet, so I still cannot access the ITSM Portal.

When I log on to the Client Manage Portal (https://portal.manage.microsoft.com), I can see that my Windows 10 Device not yet are Compliant:

image

So when I investigate, fix whatever issues this device has and then re-check compliance, I can successfully verify that I should be compliant and good to go:

image

After that, I’m successfully able to access the ITSM Portal again, this time after my device has been checked for compliance:

image

Summary

In this blog post we have seen have to publish and configure the itnetX ITSM Portal with Azure AD Application Proxy, using both pass-through authentication and Azure AD Preauthentication with Kerberos constrained delegation for single sign-on.

With the additional possibility for conditional access for users and devices, we have seen that we can require either MFA or location requirements, and device compliance for mobile platforms and windows devices.

Hope this has been an informative blog post, thanks for reading!

PS! In addition to access the application via the Access Panel (https://myapps.microsoft.com), I can use the App Launcher menu in Office 365 and add the ITSM Portal to the App chooser:

image

This will make it easy for my users to launch the application:

image