Azure AD connect

Azure AD Connect Common Issues

When it comes to hybrid AD setup, we have to work with whole different types of issues than on-premises AD environments. Azure AD is a managed service by Microsoft, so there is nothing we can do to manage its health. Therefore, most of the hybrid AD issues are related to connectivity, Directory sync or authentication methods (password hash, pass-through authentication, federated). The main component which connects on-premises Active Directory environment with Azure AD is Azure AD Connect. So most of the issues in hybrid environment can also related to Azure AD Connect. In this blog post, we are going to look in to some of the most common Azure AD connect issues and learn how we can recover from those.

Connectivity

Azure AD Connect requires connectivity to Azure AD to do the directory synchronization. Azure AD connect server also need to be able to communicate with on-premises Active Directory Domain Controller. When there is directory synchronization issues, we will see following symptoms.

• New user accounts added in on-premises Active Directory, does not appears in Azure AD or taking long time to appear (more than 30 minutes ).

• After on-premise user change their password, he/she cant authenticate to Azure AD.

• If password-writeback feature is been used, password reset in Azure AD does not work for on-premise users.

• We can see synchronization errors under Azure AD Connect health.

• When there are directory sync issues, Azure AD will also send email notification to directory administrators.

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 https://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.

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.

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

4. Then click on Device Settings

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.

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

2. Download msi from https://www.microsoft.com/en-us/download/details.aspx?id=53554

3. Double click on the MSI after download and click on Install to proceed.

Note – This VM is already part of the local domain.

4. Then go to Start > Search > PC Settings after that click on Network

5. The click on Workplace > Join

6. It will prompt for the login and provide the relevant password.

7. After successful join, it will show following

8. Now I can see the device under Azure AD Devices.

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.

Azure AD Password Synchronization

Azure AD Connect allows engineers to sync on-permises AD data to Azure AD. If you use express settings for the AD connect setup, by default it enables the password synchronization as well. This allows users to use same Active Directory password to authenticate in to cloud based workloads. This allow users to use single login details without maintaining different passwords. It simplifies the user’s login experience as well as reduce the helpdesk involvements.

Windows Active Directory uses hash values, which is generated by hash algorithm as passwords. It is not being saved as clear text password and it is impossible to revert it back to a clear text password. There is misunderstanding about this as some people thinks Azure AD password sync uses clear text passwords. In every 2 minutes’ intervals Azure AD connect server retrieves password hashes from on-premises AD and sync it to Azure AD per user-basis in chronological order. This also involves with encryption and decryption process to add extra security to password sync process. In event of password change it will sync to Azure AD in next password sync interval. In healthy environment, maximum delay to update password will be 2 minutes.

If the password was changed while user has open session, it will affect on next Azure authentication attempt. It will not log out the user from existing session. Also, password synchronization doesn’t mean SSO. Users always have to use corporate login details to authenticate to Azure Services. You can find more information about SSO using https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso

Enable synchronization of NTLM and Kerberos credential hashes to Azure AD

However Azure AD Connect does not synchronize NTLM and Kerberos credential hashes to Azure AD by default. So, if you had Azure AD directory setup and only enabled Azure Domain Services recently make sure you check following,

1. If there is existing Azure AD Connect server, Upgrade the Azure AD connect to latest

2. If there is existing Azure AD Connect server, confirm password synchronization is enabled in Azure AD connect

In order to do that, open Azure AD connect and select option to “view current configuration” and check if password synchronization is enabled.

If it’s not, we need to go back to initial page and select option “customize synchronization options” and under optional features select password synchronization

Run following PowerShell script on local AD to force full password synchronization, and enable all on-premises users’ credential hashes to sync to Azure AD.

$adConnector = "<CASE SENSITIVE AD CONNECTOR NAME>"

$azureadConnector = "<CASE SENSITIVE AZURE AD CONNECTOR NAME>"

Import-Module “C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1”

$c = Get-ADSyncConnector -Name $adConnector

$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter "Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null

$p.Value = 1

$c.GlobalParameters.Remove($p.Name)

$c.GlobalParameters.Add($p)

$c = Add-ADSyncConnector -Connector $c

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $false

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $true

You can find AD connector and Azure AD Connector name using, Start > Synchronization Service > Connections.

After that you can try to log in to Azure as a user in on-premises AD. If sync is working properly, it should accept your corporate login.

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

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.

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.

7) Once installation completed, in Synchronization Service (Azure AD Connect | Synchronization Service) we can confirm there is no sync jobs.

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

2) Select the Active Directory Domain Services connector and click on Run from the right-hand panel.

3) Then in next window select Full Import and click OK.

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.

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.

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

This is available on https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-operations#appendix-csanalyzer

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

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

6) In next window select start the synchronization process… and click Configure

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.

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

I am sure most of you aware what is single sign-on (SSO) in Active Directory infrastructure and how it works. When we extend identity infrastructures to Azure by using Azure AD, it also allows to extend Single Sign-On capabilities to authenticate in to cloud workloads. it can be done using on-premises ADFS farm. Password Hash Synchronization or Pass-through Authentication allow users to use same user name and password to log in to cloud applications but this is not a “Seamless” access. Even they are using same user name and password, when log in to Azure workloads it will prompt for password.

In my below example, I have an Azure AD instance integrated with on-premises AD using Pass-through Authentication. In there I have a user R272845. I logged in to a domain joined computer with this user and try to access application published using Azure. when I type the URL and press enter, it redirects me to Azure AD login page.

Azure Active Directory Seamless Single Sign-On is a feature which allow users to authenticate in to Azure AD without providing password again when login from domain join/ corporate device. This can be integrated with Password Hash Synchronization or Pass-through Authentication. This is still on preview which means cannot use in production environment yet. However, if it doesn’t work in environment, it will always issue the typical Azure AD authentication page, so it will not prevent you from accessing any application. This feature is not supported if you using ADFS option already.

According to Microsoft, following can list as key features of Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

• Users are automatically signed into both on-premises and cloud-based applications.

• Users don't have to enter their passwords repeatedly.

• No additional components needed on-premises to make this work.

• Works with any method of cloud authentication – Password Hash Synchronization or Pass-through Authentication.

• Can be rolled out to some or all your users using Group Policy.

• Register non-Windows 10 devices with Azure AD without the need for any AD FS infrastructure. This capability needs you to use version 2.1 or later of the workplace-join client.

• Seamless SSO is an opportunistic feature. If it fails for any reason, the user sign-in experience goes back to its regular behavior – i.e, the user needs to enter their password on the sign-in page.

• It can be enabled via Azure AD Connect.

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

• It is supported on web browser-based clients and Office clients that support modern authentication on platforms and browsers capable of Kerberos authentication

According to Microsoft, following environments are supported.

OS\Browser

Internet Explorer

Edge

Google Chrome

Mozilla Firefox

Safari

Windows 10

Yes