Tag Archives: Azure Domain Service

Step-by-Step guide to connect down-level devices to Azure AD (in hybrid environment)

Devices runs with Windows 10 and Windows Server 2016 can directly connect to Azure AD. I have used it on my last few posts and explain different features available for Domain Joined Devices. However not every device in an infrastructure runs with Windows 10 or Windows Server 2016. If it is cloud only environment, you can simply connect your VMs in Azure to Azure AD without issue. but if it is remote devices you do not have option than upgrading to windows 10 and windows 2016. In Hybrid Environment with some configuration changes, Azure AD allow to join devices runs with, 

Windows 8.1

Windows 7

Windows Server 2012 R2

Windows Server 2012

Windows Server 2008 R2

In this demo, I am going to explain how we can connect these down-level devices to Azure AD. 

If it is hybrid environment, it will be either federated or non-federated environment. In this post, I am only going to focus on non-federated environment. The configuration and prerequisites are different from one method to another. 

In non-federated environment, 

1. You must have healthy AD synchronization using Azure AD Connect
2. If you are using Seamless single sign-on with Azure AD Connect, it is still supported configuration. more info about it can find using http://www.rebeladmin.com/2017/09/azure-active-directory-seamless-single-sign-azure-ad-seamless-sso/ 
3. If down-level devices are using roaming profiles it is not going to work with Azure AD. In that case you need to move to Windows 10
4. You need to have Azure Global Administrator Account and Domain Admin Account to do the configuration changes. 

Create Service Connection Point 
 
First step of the configuration is to create service connection point (SCP) in local AD so devices can discover Azure AD tenant information during the registration process. 
In order do that we need to run following PowerShell script in Azure AD Connect server. 

Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";

$aadAdmin = Get-Credential;

Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [AD connector account] -AzureADCredentials $aadAdmin;
 
In above,
 
$aadAdmin – Parameter is to represent the Azure AD admin account used in the configuration. 
 
[AD connector account] – This should replace with the AD account used for Azure AD Sync
 
Note – 
This must run from the server you have AD Connect configured
It is recommended to run it from Microsoft Azure Active Directory Module for PowerShell tool. If you use it you do not need to import the module. 
You must have AD DS tools installed on the same server otherwise command will fail. 
 
Azurec1
 
Verify Service Connection Point Details
 
After you run the command successfully we can verify SCP using,

$scp = New-Object System.DirectoryServices.DirectoryEntry;

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=therebeladmin,DC=com";

$scp.Keywords;
 
In above DC=therebeladmin,DC=com represents the domain. 
 
If it was successful, you will get response like below. 
 
Azurec2
 
Allow Users to Join Devices to Azure AD
 
Before you joined the devices, first verify if you allow users to connect devices to Azure AD. 
To do that, 
 
1. Log in to Azure Portal
2. Go to Azure Active Directory 
3. Then Devices
 
Azurec3
 
4. Then click on Device Settings
 
Azurec4
 
5. Then the settings can find under, User may join devices to Azure AD option. In my demo setup, I am allowing all the users to join devices. 
 
Azurec5
 
Join down-level devices to Azure AD
 
Now we have all the prerequisites ready. Next step is to register device with Azure AD. In my demo, I have a VM which runs Windows 8.1. I am going to add it to Azure AD.
 
1. Log in to the Device as Administrator
 
 
Azurec6
 
3. Double click on the MSI after download and click on Install to proceed. 
 
Azurec7
 
Note – This VM is already part of the local domain. 
 
4. Then go to Start > Search > PC Settings after that click on Network 
 
Azurec8
 
5. The click on Workplace > Join
 
Azurec9
 
6. It will prompt for the login and provide the relevant password. 
 
Azurec10
 
7. After successful join, it will show following
 
Azurec11
 
8. Now I can see the device under Azure AD Devices. 
 
Azurec12
 
This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step guide to enable Enterprise State Roaming with Azure Active Directory

If you work with Active Directory you may already know what is roaming profiles is. Roaming profiles allows to sync application and user settings to a file share. When same user login from another computer in to same domain, those settings will sync back from file share. It allows users to have same user experience and data in different corporate devices. Azure Active Directory users may also login from multiple Azure domain joined devices. Enterprise state roaming allows to sync user settings and application settings securely across corporate azure domain joined devices. 

Secured Sync – When this feature enables it will activate free limited Azure Rights Management subscription. It will use to encrypt and decrypt data which is sync to cloud. This will ensure the security of data used by Enterprise State Roaming feature. 

Data Storage – Data storage location for Enterprise State Roaming feature will be align with your Azure Active Directory subscription region. It will not sync between different regions. 

Better Control – This feature can be enable for entire directory or only for selected users. Sync data for each device can review using portal. With help of Azure Support, administrators also can forcefully remove sync data for a device. 

Data Retention – If user account been deleted from directory, profile data will be deleted after 90 days. Administrators also can request (from azure support) to delete specific data from a user profile. If data not been access for 1 year it will consider it as stale data and remove forcefully. It will also happen if Enterprise State Roaming feature is disable in later time. 

Let’s see how we can enable this feature. In order to enable this feature, you must have Azure AD Premium or Enterprise Mobility + Security (EMS) license. Azure AD join devices must be running with Windows 10 (Version 1511, Build 10586 or greater)

1) Log in to Azure Portal as a Global Administrator
2) Go to Azure Active Directory | Devices  
 
ent1
 
3) Then click on Device Settings 
 
ent2
 
4) Under device settings there is option says Users may sync settings and app data across devices. In there you can select All or Selected. If you use selected option, you will need to define the users. in my demo, I am going to enable Enterprise State Roaming for entire directory. Once selection is made click on Save
 
ent3
After the feature is enabled we can review the sync status using Azure Active Directory Admin Center. To do this, 
 
1) Log in to Azure Active Directory Admin Center using https://aad.portal.azure.com
2) Go to Azure Active Directory | Users and Groups 
 
ent4
 
3) In next window, Click on All users and then click on the relevant user. In my demo it is user RA722725@therebeladmin.com
 
ent5
 
4) Then click on Device in new window. 
 
ent6
 
5) Then in right hand window select Device sync settings and app data option from show drop down menu.
 
ent7
 
6) In list it shows the devices, that user logged in and the last sync time. 
 
ent8
 
Now we have everything ready for testing. Before we start there is few things to remind. This is only sync user and app settings. Not user data. Also, sync is not happening at login/log off event. It happens once user is log in. so if you do not see sync data right away after login, allow sometime and keep eye on last sync time value. 
 
In my demo, I am login to a pc called REBEL-PC01 as RA722725@therebeladmin.com. In that pc, I have done certain settings changes. 
 
Under IE, I added few links to favorites. 
 
ent9
 
I also change setting on code writer App and change font and default text size to 20.  
 
ent10
 
After initial sync, I login in to another pc called REBEL-PC02 as RA722725@therebeladmin.com. In there I expect to see the changes I made. (The sync cycles can take up to 30 minutes. So far I didn’t find way to override this setting) 
 
As expected I can see same IE favorites list. 
 
ent11
 
Also, code writer app settings are there. 
 
ent12
 
As we can see it helps to streamline user experience across corporate devices. This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

Self-Service password reset on Azure AD joined windows 10 device

Password resets are common service desk request IT engineers deals with. Passwords are weak authentication method. Passwords are breakable, crackable and guessable. This is why Microsoft invested on password less authentication such as Windows Hello. However, majority of systems still use traditional user name and password to authenticate.

When user forget their password, it prevents them from accessing the systems or services they trying to access. Until someone with higher privileges reset user’s password his/her time will be wasted. It is manageable for small number of users but if its large organization, it can cost lot for both parties. This is why organizations use self-service password reset solutions. It will allow its users to reset their passwords in secure, controlled environment. 

When it comes to Azure AD, it also can allow users to have self-service password reset feature. In one of my previous blog post I explained how it can enable. It can access using http://www.rebeladmin.com/2016/01/step-by-step-guide-to-configure-self-service-password-reset-in-azure-ad/ . Now Azure AD also allows to reset password directly from login screen of Azure AD join windows 10 devices. In this post, I am going to demonstrate this feature. 

In order to use this feature, Azure AD environment should have following,

1. Enable self-service password reset – By default Azure AD do not have this feature enable. It need to enable before users use this feature. It can be enable for all the users or group of users. 

password1

In my demo environment, I have it enable for all the users. 

Also in here users can have one or two authentication methods to reset password. if it’s using two methods, it will verify user using both methods. 

password2

2. Password writeback for Hybrid Environments – If its Hybrid environment (with on-premises AD) password writeback option should enable. Otherwise password which reset from Azure AD will not replicate back. This option is available in Azure AD connect. If you not enable this option, even if you have self-service password reset enable it will not allow password reset for users. 

password3

3. Windows 10 Fall Creator Update – This password reset feature is only available for Windows 10 Version 1709. So, make sure device is running with latest update. it can be apply using windows update. more details can find via https://support.microsoft.com/en-gb/help/4028685/windows-10-get-the-fall-creators-update 

In my demo environment, I have an Azure Domain Join Windows 10 PC. 

password4

After I enable self-service password reset, I am going to log in to this PC as user RA722725@therebeladmin.com

on my login, it says I need to provide additional info for password recovery. 

password5

Click on Set it up now to continue. 

Then it provides list of options I can use to verify. Select the option you need and click Next

password6

Now we have recovery options setup, let’s see how password reset works from the device. 

On my Azure AD join device, in login screen I type the user name. but I do not get any option for password reset. This is because I am also using PIN option for login. If you are using PIN you probably end up using PIN instead of password. so, if you using PIN and still need to recover password, click on Sign -in option

password7

Then click on number pad sign to select PIN option.

password8

Then click on I forgot my PIN option. I know this is confusing as we trying to reset password. but unfortunately, option is in PIN reset page. 

password9

Then it will open new window. In their click on Forgotten password option. 

password10

Now it opens a new window to reset password. click Next to proceed. 

password11

Then it gives option for verification. Select the method you like to use. You can’t change your registered data in here. 

password12

After successful verification, it gives option to define new password. after type new password, click on Next to proceed. 

password13

Then click on Finish to complete the process. 

password14

Then I can login to device with new password. 

password15

Cool ha???, as expected we were able to reset password on device login screen. This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

Azure AD now support macOS Conditional Access – Let’s see it in action!

Azure AD conditional access policies allows to provide conditional based access to cloud workloads. 

In one of my previous blog post I explain it in detail what is conditional access policy and how we can configure it. you can find it on http://www.rebeladmin.com/2017/07/conditional-access-policies-azure-active-directory/ . I highly recommend to read it before we continue on this post. 

In Condition Access Policy, there are two main section.

Assignments –  This is where we can define conditions applying to user environment such as users and groups, applications, device platform, login locations etc.

Access Control –  This is to control access for the users and groups when they comply with the conditions specified in the “assignments” section. it can be either allow access or deny access. 

Under Assignment section we can define device platforms involves in the condition. Before when I wrote my previous post it was only supporting for following platforms.

• Android

• iOS

• Windows Phone

• Windows

From November 14th 2017, Azure AD add macOS to the list. With this update following OS versions, applications, and browsers are supported on macOS for conditional access:

Operating Systems

macOS 10.11+

Applications

Microsoft Office 2016 for macOS v15.34 and later

Microsoft Teams

Web applications (via Application Proxy)

Browsers

Safari

Chrome

In original documentation, it didn’t say anything about web apps but in this demo, I am going to use conditional access with on-premises web app which is publish to internet using Azure Application Proxy. I wrote article about application proxy while ago and it can access via http://www.rebeladmin.com/2017/06/azure-active-directory-application-proxy-part-02/ 

Before start configuration, let me explain little bit about my environment. I have on-premises domain environment with therebeladmin.com. I integrated it with Azure AD Premium and I have healthy sync. I have on-premises webapp and I have published it to internet using Azure Application Proxy so I can use Azure AD authentication with it. webapp can access via https://webapp-myrebeladmin.msappproxy.net/webapp/ 

I have a mac with sierra running. In this demo, I am going to setup a conditional access policy to block access to webapp if the request coming from a mac environment. 

mac01

In order to configure this, 

1) Log on to Azure as global admin
2) Click on Azure Active Directory from left menu.
 
mac2
 
3) Then in Azure Active Directory panel, click on Conditional Access under security section. 
 
mac3
 
4) It will load up the conditional access window. Click on + New Policy to create new policy. 
 
mac4
 
5) It will open up policy window where we can define policy settings. First thing first, provide a name for policy. in my case I will use “Block access from macOS
 
mac5
 
6) Then click on User and groups to define target users for the policy. in this demo, I am going to target All users. once selection is done click on Done
 
mac6
 
7) Then Click on Clouds Apps to select application for the policy. in my policy, I am going to target rebelwebapp. Once selection is done click on Select and the Done to complete the process. 
 
mac7
 
8) Next step is to define the conditions. In order to do that click on Conditions option. In here I am only worrying about device platforms. To select platforms, click on option Device Platforms. Then to enable the condition click on Yes under configure and then under include tab select macOS. After that click on Done in both windows to complete the process. 
 
mac8
 
9) Next step to define access control rules. To do that click on Grant under access controls section. in my demo, I am going to block access to app. So, I am selecting block access option. Once selection is done click on select to complete the action. 
 
mac9
 
10) Now policy is ready. To enable it click On tab under Enable Policy option. 
 
mac10
 
11) Then to create the policy, click on Create button. 
 
mac11
 
12) Now policy is ready and next step is to test it. in order to do that I am using webapp url via mac. As soon as I access url, it asks for login.
 
mac12
 
13) As soon as I type user name and password, I get following response saying it is not allowed. 
 
mac13
 
14) If we click on More Details it gives more info about error. As expected it was due to the conditional access policy we set up. Nice ha!!
 
mac14
 
So as expected, conditional access with macOS working fine. This is another good step forward. Well done Microsoft! This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

Azure AD Connect Staging Mode

Azure AD Connect is the tool use to connect on-premises directory service with Azure AD. It allows users to use same on-premises ID and passwords to authenticate in to Azure AD, Office 365 or other Applications hosted in Azure. Azure AD connect can install on any server if its meets following,

The AD forest functional level must be Windows Server 2003 or later. 

If you plan to use the feature password writeback, then the Domain Controllers must be on Windows Server 2008 (with latest SP) or later. If your DCs are on 2008 (pre-R2), then you must also apply hotfix KB2386717.

The domain controller used by Azure AD must be writable. It is not supported to use a RODC (read-only domain controller) and Azure AD Connect does not follow any write redirects.

It is not supported to use on-premises forests/domains using SLDs (Single Label Domains).

It is not supported to use on-premises forests/domains using "dotted" (name contains a period ".") NetBios names.

Azure AD Connect cannot be installed on Small Business Server or Windows Server Essentials. The server must be using Windows Server standard or better.

The Azure AD Connect server must have a full GUI installed. It is not supported to install on server core.

Azure AD Connect must be installed on Windows Server 2008 or later. This server may be a domain controller or a member server when using express settings. If you use custom settings, then the server can also be stand-alone and does not have to be joined to a domain.

If you install Azure AD Connect on Windows Server 2008 or Windows Server 2008 R2, then make sure to apply the latest hotfixes from Windows Update. The installation is not able to start with an unpatched server.

If you plan to use the feature password synchronization, then the Azure AD Connect server must be on Windows Server 2008 R2 SP1 or later.

If you plan to use a group managed service account, then the Azure AD Connect server must be on Windows Server 2012 or later.

The Azure AD Connect server must have .NET Framework 4.5.1 or later and Microsoft PowerShell 3.0 or later installed.

If Active Directory Federation Services is being deployed, the servers where AD FS or Web Application Proxy are installed must be Windows Server 2012 R2 or later. Windows remote management must be enabled on these servers for remote installation.

If Active Directory Federation Services is being deployed, you need SSL Certificates.

If Active Directory Federation Services is being deployed, then you need to configure name resolution.

If your global administrators have MFA enabled, then the URL https://secure.aadcdn.microsoftonline-p.com must be in the trusted sites list. You are prompted to add this site to the trusted sites list when you are prompted for an MFA challenge and it has not added before. You can use Internet Explorer to add it to your trusted sites.

Azure AD Connect requires a SQL Server database to store identity data. By default a SQL Server 2012 Express LocalDB (a light version of SQL Server Express) is installed. SQL Server Express has a 10GB size limit that enables you to manage approximately 100,000 objects. If you need to manage a higher volume of directory objects, you need to point the installation wizard to a different installation of SQL Server.

What is staging mode? 
 
In a given time, only one Azure AD connect instance can involve with sync process for a directory. But this gives few challenges. 
 
Disaster Recovery – If the server with Azure AD connect involves in a disaster it going to make impact on sync process. This can be worse if you using features such as password pass-through, single-sing-on, password writeback through AD connect.
Upgrades – If the system which running Azure AD connect needs upgrade or if Azure AD connect itself needs upgrade, will make impact for sync process. Again, the affordable downtime will be depending on the features and organization dependencies over Azure AD connect and its operations. 
Testing New Features – Microsoft keep adding new features to Azure AD connect. Before introduce those to production its always good to simulate and see how it will impact. But if its only one instance, it is not possible to do so. Even you have demo environment it may not simulate same impact as production in some occasions. 
 
Microsoft introduced the staging mode of Azure AD connect to overcome above challenges. With staging mode, it allows you to maintain another copy of Azure AD connect instance in another server. it can have same config as primary server. It will connect to Azure AD and receive changes and keep a latest copy to make sure the switch over is seamless as possible. However, it will not sync Azure AD connect configuration from primary server. it is engineer’s responsibility to update staging server AD connect configuration, if primary server AD connects config modified. 
 
Installation
 
Let’s see how we can configure Azure AD connect in staging mode.
 
1) Prepare a server according to guidelines given in prerequisites section to install Azure AD Connect. 
2) Review current configuration of Azure AD connect running on primary server. you can check this by Azure AD Connect | View current configuration 

sta1
 
sta2
 
3) Log in to server as Domain Administrator and download latest Azure Ad Connect from https://www.microsoft.com/en-us/download/details.aspx?id=47594
4) During the installation, please select customize option. 
 
sta3
 
5) Then proceed with the configuration according to settings used in primary server. 
6) At the last step of the configuration, select Enable staging mode: When selected, synchronization will not export any data to Ad or Azure AD and then click install
 
sta4
 
7) Once installation completed, in Synchronization Service (Azure AD Connect | Synchronization Service) we can confirm there is no sync jobs. 
 
sta5
 
Verify data
 
As I mentioned before, staging server allows to simulate export before it make as primary. This is important if you implement new configuration changes. 
 
In order to prepare a staged copy of export, 
 
1) Go to Start | Azure AD Connect | Synchronization Service | Connectors 
 
sta6
 
2) Select the Active Directory Domain Services connector and click on Run from the right-hand panel. 
 
sta7
 
3) Then in next window select Full Import and click OK.
 
sta8
 
4) Repeat same for Windows Azure Active Directory (Microsoft) 
5) Once both jobs completed, Select the Active Directory Domain Services connector and click on Run from the right-hand panel again. But this time select Delta Synchronization, and click OK.
 
sta9
 
6) Repeat same for Windows Azure Active Directory (Microsoft)
7) Once both jobs finished, go to Operation tab and verify if jobs were completed successfully. 
 
sta10
 
Now we have the staging copy, next step is to verify if the data is presented as expected. to do that we need to get help of a PowerShell script.  

 
Param(
    [Parameter(Mandatory=$true, HelpMessage="Must be a file generated using csexport 'Name of Connector' export.xml /f:x)")]
    [string]$xmltoimport="%temp%\exportedStage1a.xml",
    [Parameter(Mandatory=$false, HelpMessage="Maximum number of users per output file")][int]$batchsize=1000,
    [Parameter(Mandatory=$false, HelpMessage="Show console output")][bool]$showOutput=$false
)

#LINQ isn't loaded automatically, so force it
[Reflection.Assembly]::Load("System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089") | Out-Null

[int]$count=1
[int]$outputfilecount=1
[array]$objOutputUsers=@()

#XML must be generated using "csexport "Name of Connector" export.xml /f:x"
write-host "Importing XML" -ForegroundColor Yellow

#XmlReader.Create won't properly resolve the file location,
#so expand and then resolve it
$resolvedXMLtoimport=Resolve-Path -Path ([Environment]::ExpandEnvironmentVariables($xmltoimport))

#use an XmlReader to deal with even large files
$result=$reader = [System.Xml.XmlReader]::Create($resolvedXMLtoimport) 
$result=$reader.ReadToDescendant('cs-object')
do 
{
    #create the object placeholder
    #adding them up here means we can enforce consistency
    $objOutputUser=New-Object psobject
    Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name ID -Value ""
    Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name Type -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name DN -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name operation -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name UPN -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name displayName -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name sourceAnchor -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name alias -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name primarySMTP -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name onPremisesSamAccountName -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name mail -Value ""

    $user = [System.Xml.Linq.XElement]::ReadFrom($reader)
    if ($showOutput) {Write-Host Found an exported object... -ForegroundColor Green}

    #object id
    $outID=$user.Attribute('id').Value
    if ($showOutput) {Write-Host ID: $outID}
    $objOutputUser.ID=$outID

    #object type
    $outType=$user.Attribute('object-type').Value
    if ($showOutput) {Write-Host Type: $outType}
    $objOutputUser.Type=$outType

    #dn
    $outDN= $user.Element('unapplied-export').Element('delta').Attribute('dn').Value
    if ($showOutput) {Write-Host DN: $outDN}
    $objOutputUser.DN=$outDN

    #operation
    $outOperation= $user.Element('unapplied-export').Element('delta').Attribute('operation').Value
    if ($showOutput) {Write-Host Operation: $outOperation}
    $objOutputUser.operation=$outOperation

    #now that we have the basics, go get the details

    foreach ($attr in $user.Element('unapplied-export-hologram').Element('entry').Elements("attr"))
    {
        $attrvalue=$attr.Attribute('name').Value
        $internalvalue= $attr.Element('value').Value

        switch ($attrvalue)
        {
            "userPrincipalName"
            {
                if ($showOutput) {Write-Host UPN: $internalvalue}
                $objOutputUser.UPN=$internalvalue
            }
            "displayName"
            {
                if ($showOutput) {Write-Host displayName: $internalvalue}
                $objOutputUser.displayName=$internalvalue
            }
            "sourceAnchor"
            {
                if ($showOutput) {Write-Host sourceAnchor: $internalvalue}
                $objOutputUser.sourceAnchor=$internalvalue
            }
            "alias"
            {
                if ($showOutput) {Write-Host alias: $internalvalue}
                $objOutputUser.alias=$internalvalue
            }
            "proxyAddresses"
            {
                if ($showOutput) {Write-Host primarySMTP: ($internalvalue -replace "SMTP:","")}
                $objOutputUser.primarySMTP=$internalvalue -replace "SMTP:",""
            }
        }
    }

    $objOutputUsers += $objOutputUser

    Write-Progress -activity "Processing ${xmltoimport} in batches of ${batchsize}" -status "Batch ${outputfilecount}: " -percentComplete (($objOutputUsers.Count / $batchsize) * 100)

    #every so often, dump the processed users in case we blow up somewhere
    if ($count % $batchsize -eq 0)
    {
        Write-Host Hit the maximum users processed without completion... -ForegroundColor Yellow

        #export the collection of users as as CSV
        Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
        $objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation

        #increment the output file counter
        $outputfilecount+=1

        #reset the collection and the user counter
        $objOutputUsers = $null
        $count=0
    }

    $count+=1

    #need to bail out of the loop if no more users to process
    if ($reader.NodeType -eq [System.Xml.XmlNodeType]::EndElement)
    {
        break
    }

} while ($reader.Read)

#need to write out any users that didn't get picked up in a batch of 1000
#export the collection of users as as CSV
Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation

 
Save this as .ps1 on C Drive. 
 
1) Open PowerShell and type cd "C:\Program Files\Microsoft Azure AD Sync\Bin" (if your install path is different use the relevant path)
2) Then run .\csexport "myrebeladmin.onmicrosoft.com – AAD" C:\export.xml /f:x in here myrebeladmin.onmicrosoft.com -AAD should replace with your Azure AD connector name. This will export config to C:\export.xml
3) Then type .\analyze.ps1 -xmltoimport C:\export.xml in here analyze.ps1 is the script we saved in beginning of this section. 
4) Then it will create CSV file called processedusers1.csv and it’s contain all changes which will sync to Azure AD. 
 
However, this step is always not required. It can make as primary server without import and verify process. 
 
How to make it as primary Server?
 
In order to make staging server as primary server,
 
1) Go to Start | Azure AD Connect | Azure AD Connect
2) Then click on Configure in next page. 
3) In next page select option Configure staging mode and click Next
 
 
sta11
 
4) In next page provide the Azure AD login credentials for directory sync account. 
5) In next window, untick Enable staging mode and click Next
 
sta12
 
6) In next window select start the synchronization process… and click Configure
 
sta13
 
This completes the process of promoting staging server in to primary. Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step guide to configure Azure MFA with ADFS 2016

Multifactor authentication (MFA) is commonly use to protect applications, web services which is publish to internet. It helps to verify the authenticity of the authentication requests. There are many multifactor service providers. Some are cloud based and some are required on-premises installations.  

Azure MFA first was introduced to use with Azure services and later developed further to support on-premises workload protections too. It is possible to configure Azure MFA with ADFS 2.0 and ADFS 3.0, however the configuration required to install additional MFA server for that. With ADFS 4.0 (windows server 2016) this is made simple and we can integrate Azure MFA without need of additional server. 

In this post, I am going to walk you through the integration of Azure MFA with ADFS 2016. 

Before we start we need to look in to the prerequisites. 

1. Valid Azure subscription.

2. Azure Global Administrator account 

3. Existing Federate Azure AD setup. More info about this configuration can find in https://docs.microsoft.com/en-gb/azure/active-directory/connect/active-directory-aadconnect-get-started-custom#configuring-federation-with-ad-fs 

4. Windows Server 2016 AD FS installed in on-premises

5. Enterprise Administrator Account to configure MFA

6. Users with Azure MFA enabled – http://www.rebeladmin.com/2016/01/step-by-step-guide-to-configure-mfa-multi-factor-authentication-for-azure-users/

7. Windows Azure Active Directory module for Windows PowerShell installed in ADFS server

Create Certificate in each ADFS server to use with Azure MFA 

First step of the configuration is to generate a certificate for Azure MFA. This needs to perform on every ADFS server in the farm. In order to generate the certificate, you can use following on PowerShell. 

$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID “Your Tenant ID”

Please replace “Your Tenant ID” with actual azure tenant ID. You can find tenant ID by running Login-AzureRmAccount on Azure AD PowerShell. 

Once it is generated, the certificate will be under local computer certificates. 

cert1

Add new credentials to connect with Auth Client SPN

Now, we have the certificate, but we need to tell Azure Multi-Factor Auth Client to use it as

a credential to connect with AD FS.

Before that, we need to connect to the Azure AD using Azure PowerShell. We can do that

using this:

Connect-MsolService

Then, it will prompt for login and make sure to use Azure Global Administrator account to connect.

After that execute the command,

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certbase64

In the above command, AppPrincipalId defines the GUID for Azure Multi-Factor Auth Client.

Configure ADFS farm to use Azure MFA

Now we have the components ready and next step is to configure ADFS farm to use Azure AD. In order to do that run the following PowerShell command.

Set-AdfsAzureMfaTenant -TenantId “Your Tenant ID” -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720

In above command replace “Your Tenant ID” with your Azure Tennant id. ClientId in the command represent the GUID for Azure Multi-Factor Auth Client.

cert2

Once it is completed restart the ADFS service. 

Enable Azure MFA globally

Last step of the configuration is to enable Azure MFA for authentication. In order to do that log in to ADFS server and go to Server Manager > Tools > AD FS Management. Then, in the MMC, go to Service > Authentication Methods > Then in the Actions panel, click on Edit Primary Authentication Method.

cert3

This opens up the window to configure global authentication methods. It has two tabs, and we can see Azure MFA on both.

cert4

By selecting each box, you can enable MFA for intranet and extranet. 

This completes the configuration. now you can use Azure MFA with your ADFS farm. Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com

Azure Active Directory Pass-through Authentication

When organizations want to use same user name and passwords to log in to on-premises and cloud workloads (azure), there are two options. One is to sync user name and password hashes from on-premises active directory to azure AD. Other option is to deploy ADFS farm on-premises and use it to authenticate cloud based logins. But it needs additional planning and resources. On-premises AD uses hash values (which are generated by a hash algorithm) as passwords. They are NOT saved as clear text, and it is almost impossible to revert it to the original password even someone have hash value. There is misunderstanding about this as some people still think Azure AD password sync uses clear text passwords. Every two minutes, the Azure AD connect server retrieves password hashes from the on-premises AD and syncs it with Azure AD on a per user-basis in chronological order. In technical point of view, I do not see a reason why people should avoid password hash sync to azure AD. However, there are company policies and compliance requirements which do not accept any form of identity sync to external system even on hash format. Azure Active Directory Pass-through Authentication is introduced by Microsoft to answer these requirements. It allows users to authenticate in to cloud workloads using same passwords they are using in on-premises without syncing their password hash values to Azure AD. This feature is currently on preview. Which means it’s still not supported on production environment. But it is not too early to try it in development environments.

According to Microsoft, following can list as key features of Pass-through Authentication.

Users use the same passwords to sign into both on-premises and cloud-based applications.

Users spend less time talking to the IT helpdesk resolving password-related issues.

Users can complete self-service password management tasks in the cloud.

No need for complex on-premises deployments or network configuration.

Needs just a lightweight agent to be installed on-premises.

No management overhead. The agent automatically receives improvements and bug fixes.

On-premises passwords are never stored in the cloud in any form.

The agent only makes outbound connections from within your network. Therefore, there is no requirement to install the agent in a perimeter network, also known as a DMZ.

Protects your user accounts by working seamlessly with Azure AD Conditional Access policies, including Multi-Factor Authentication (MFA), and by filtering out brute force password attacks.

Additional agents can be installed on multiple on-premises servers to provide high availability of sign-in requests.

Multi-forest environments are supported if there are forest trusts between your AD forests and if name suffix routing is correctly configured.

It is a free feature, and you don't need any paid editions of Azure AD to use it.

It can be enabled via Azure AD Connect.

It protects your on-premises accounts against brute force password attacks in the cloud.

How it works?

Let’s see how it really works. In following example, user is trying to access cloud based application (integrated with azure) using his on-premises username and the password. This organization is using pass-through authentication.

pt1

1. User is accessing the application URL using his browser. 

2. In order to authenticate to the application, user is directed to Azure Active Directory sign-in page. User then type the user name, password and click on sign-in button. 

3. Azure AD receives the data and it encrypt the password using public key which is used to verify the data authenticity. Then it places it’s in a queue where it will wait till pass-through agent retrieves it.   

4. On-premises pass-through agent retrieves the data from Azure AD queue (using an outbound connection) 

5. Agent decrypt the password using private key available for it. 

6. Agent validates the user name and password information with on-premises Active Directory. It uses same mechanism as ADFS. 

7. On-premises AD evaluate the request and provides the response. It can be success, failure, password-expire or account lockout. 

8. Pass-through agent passes the response back to Azure AD. 

9. Azure AD evaluate response and pass it back to user.

10. If response was success, user is allowed to access the application. 

Prerequisites
 
In order to implement this feature, we need the following,
 
1. Domain Admin / Enterprise Admin account to install and configure Azure AD Connect in on-premises 
2. Global Administrator Account for Azure subscription – in order to create custom domain, configure AD connect etc. 
3. On-premises servers running windows server 2012 R2 or latest to install Azure AD connect and pass-through agent.
4. Latest Azure AD Connect https://www.microsoft.com/en-us/download/details.aspx?id=47594 – if you have older Azure AD connect version installed, you need to upgrade it to latest before we configure this feature. 
5. Allow outbound communication to Azure via TCP port 80 and 443 from servers which will have Azure AD connect and authentication agents. You can find azure datacenter ip ranges from https://www.microsoft.com/en-us/download/details.aspx?id=41653
 

Configure Azure Active Directory Pass-through Authentication
 
Once we have all the prerequisites ready, we can look in to configuration. if you running Azure AD connect for first time make sure to use custom method.
 
pt1-1
 
Then in User sign-in option, select pass-through authentication and continue. 
 
pt1-2
 
If you running it already in servers, first run as Azure AD Connect as administrator. Then click on Configure.
 
pt2
 
Then in next page, select Change user sign-in option and click Next.
 
pt3
 
In next window type the Azure AD sync account login details and then click Next.
 
pt4
 
In next window, select pass-through authentication and click Next
 
pt5
 
Note– If you have Azure AD App Proxy Connector installed on same Azure AD connect server you will receive error saying, Pass-through authentication cannot be configured on this machine because Azure AD Connect agent is already installed. To fix it uninstall the Azure AD proxy connector and then reconfigure AD connect. After that you can reinstall Azure AD App proxy Connector. 
 
Once it finishes the configuration click on configure to complete the process. 
 
pt6
 
Once process is completed, log in to Azure Portal and then go to Azure Active Directory > Azure AD Connect. In there we can see pass-through authentication is enabled. 
 
pt7
 
And if you click on there it will shows the connected agents status. 
 
pt8
 
At this stages users from on-premises should be able to sign in to their cloud applications by using pass-through authentication.
 
in order to add high availability, we can install agent in multiple domain join servers. it can download from pass-through authentication page.
 
pt9
 
This completes the implementation of pass-through authentication and hope this post was useful. If you have any questions, feel free to contact me on rebeladm@live.com

Azure Active Directory Application Proxy – Part 02

In Part 01 of this series I have explained what is Azure AD application proxy and how it works. If you didn’t read it yet you can find it in http://www.rebeladmin.com/2017/06/azure-active-directory-application-proxy-part-01/

In this part of the series I am going to demonstrate how we can configure Azure AD application proxy.

Demo Setup

In my demo environment I have following,

1. Azure AD Premium Subscription

2. Active Directory 2016 on-premises setup 

3. Web application running on IIS

Enable Azure AD proxy

Before we install application proxy connector, we need to enable application proxy. This only need to enable when setup first application proxy.

1. Log in to Azure as Global Administrator

2. Then open Azure Active Directory 

adapp1

3. In next window click on Application proxy

adapp2

4. In next window click on Enable Application Proxy. Then it will explain about feature and click on Yes to enable. 

adapp3

Install Application Connector

Next step in configuration is to install Application Connector. I am going to install this on same application server.

1. Log in to Azure as Global Administrator

2. Then go to Azure Active Directory | Application Proxy 

3. Then in window click on Download connector 

adapp4

4. It will redirect to a page where you can download the connector. After Accepting terms click Download

adapp5

5. Once file is downloaded, double click on AADApplicationProxyConnectorInstaller.exe to start the connector installation. 

adapp6

6. Then it will open up a wizard. Agree to licenses terms and click on install to proceed. 

adapp7

7. During the installation, it asks for Azure login details. Provide an account which have azure global admin privileges. 

adapp8

8. After login details validates it will continue with the setup. Once it completes we ready to publish the application. 

adapp9

Publish Application

Next stage of the configuration is to publish the application.

1. Log in to Azure as Global Administrator

2. Then go to Azure Active Directory | Enterprise Applications 

adapp10

3. Then in next window, click on New Application 

adapp11

4. In categories page, Click on All and then click on on-premises application 

adapp12

5. Then it’s opens a new window where we can provide configuration data for application.

adapp13

In this form,

Name – Unique name to identify the application

Internal Url – Internal Url for the application. 

External Url – This is auto generated by azure and this url will be the one use to access the application via internet. If need certain url changes can be made. 

All other values we can leave default unless there is specify requirement. 

Once information added, click on Add button to publish the application. 

adapp14

6. Once application is published, we can see it under Enterprises Application

adapp15

Testing

Now we have everything ready. Next step is to verify if its working as expected. by default, application do not have any users assigned. So, before we test, we need to allow application access. 

1. Log in to Azure as Global Administrator

2. Then go to Azure Active Directory | Enterprise Applications | All Applications

3. Click on the web app that we published on previous section. 

4. Then click on Users and Groups

adapp16

5. Then click on Add User in next window

adapp17

6. From the list select the users and click on Select

adapp18

7. Click on Assign to complete the process. 

8. Now under the users you can see the assigned users and groups. 

adapp19

9. Now everything ready! Type the public URL in your browser which is generated during application publish process. For our demo, it was https://webapp1-myrebeladmin.msappproxy.net/webapp1/ . As expected it goes to the Azure login page. 

adapp20

10. Log in using a user account assigned for the app. 

11. After successfully authentication I can see my local web app content! 

adapp21

So as expected, we were able to publish a local application to internet without any DNS, firewall or application configuration change.

Hope this was helpful and if you have any questions feel free to contact me on rebeladm@live.com

Azure Active Directory management experience in preview

Azure Active Directory management experience now in preview. This is very big step as now in one place you can management all your azure active directory related functions. Previously we had to move through few screens to access different AD related functions. For example, if I need to access identity management or Azure AD connect health both functions are in different pages. Navigation was painful sometime. But now it’s all integrated in once console. You also do not need to go to classic portal anymore to access Azure AD. And more importantly monitoring and reporting is nicely integrated and its allows to review the health of your azure AD infrastructure more sufficiently. Idea of this post is to show you these functions available in preview. 

To access the Azure Active Directory management experience preview, log in to azure portal and click on the azure active directory from the left hand options. 

pre1

If it’s not there go to more services and then type azure active directory. It will list the option down and click on the yellow start next to name to add it to the above list. 

pre2

The initial tile contain links to different options and also quick links to the functions such as add users, add groups, access application and quickly check the health of azure AD connect. 

pre3

Other capabilities tile gives links to feature such as PIM and IM. 

pre4

Recommended tab gives you recommendations to make your setup better. Beauty is if you click on each link it will directly bring you to the task to enable or configure it

pre5

pre6

In the top if you click on the notification it will bring you to the page where it lists down more info about preview and quick links to setup your Azure AD infrastructure. 

pre7

pre8

pre9

The right hand navigation link to different section. 

pre10

Users and groups link will bring you to the section where you can manage your users and groups. What I like is it’s also list all the associated functions for the feature such as password reset. 

pre11

By clicking on a user account it will list down its activities, group membership and profile details. Also in same page it has option to reset password or even to delete. 

pre12

Under the activity you can review sign in and audit logs.

pre13

Enterprise application option will bring you to the page to review your application usage under the directory. 

pre21

App Registration option will bring you to manage your app registration

pre14

Azure AD Connect link will give you option to setup the initial sync or to manage already setup sync. Also it gives links to load up the azure AD connect health

pre15

Domain Names option allow you to manage your domain names. You can add domain names, delete names etc. 

pre16

Password reset option gives you option to setup/manage the self-service password reset feature. By the way you need Azure premium subscriptions to use this feature.

pre17

Company branding option – this is really useful feature. There you have options to customize the login pages using company own logo, texts etc. 

pre18

User settings are to manage the user privileges to the azure active directory instance. 

pre19

Last but not least if you still wish to manage azure AD using classic portal you can navigate it to it using classic portal option

pre20

This new feature is really big improvement for the Azure AD management and hope lots of you agree. 

If you have any questions, feel free to contact me on rebeladm@live.com

Step-by-Step Guide to manage DNS records in Azure Managed Domain (AAD-DS)

In my recent articles I was explaining how to enable Azure Active Directory Domain Service and how to manage its services using domain-joined server.

If you not read it yet please check my last post in here.

When you manage a local active directory instance, using DNS mmc you can manage the DNS records. But can we do same with Azure managed domain? Answer is yes. In this post I am going to show how to manage dns records using domain-joined azure vm.

In order to do that we need following prerequisites.

1)    Azure Active Directory Domain Service (AAD-DS) managed domain Instance
2)    Domain Joined Virtual Server
3)    User account with member of AAD DC Administrators group

I have explain all of above in my last 3-4 posts. Please follow them if you like to know more about those.
So in this demo, I am going to use the already setup Azure managed domain instance.

dnsad1

I also have a virtual server running on Azure with windows server 2016 TP5. It is already jointed to the managed domain.

dnsad2

dnsad3

To start with the configuration RDP to the virtual server

1)    Log in to server with member account of AAD DC Administrators group

dnsad4

2)    Open Server Manager > Add Roles and Features

dnsad5

3)    In first screen of wizard click on next to proceed

dnsad6

4)    In next window keep the default and click next

dnsad7

5)    In server selection keep it default and click next

dnsad8

6)    In server roles keep default and click next

dnsad9

7)    Under the features, go to Remote Server Administration Tools > Roles Administration Tools > DNS Server Tools. Then click next to proceed

dnsad10

8)    In next confirmation window click on install to install the tools

dnsad11

9)    Once it’s done go to server manager > tools > DNS

dnsad12

10)    On first start it will prompt where to connect. In their select the option as below and then type the managed domain you have in place. Then click ok

dnsad13

11)    It will open up the DNS mmc.

dnsad14

In here we can manage the DNS records as we need. There are some dns records which related to the managed domain service. So make sure those records are not modified or deleted.

The virtual machine no need to be on server version, if you install desktop version you can still managed dns by installing RSAT tools.

If you have any questions about the post feel free to contact me on rebeladm@live.com