(2018-04-20) Azure AD MFA Server v8.0.0.3 Has Been Released

Azure Multi-Factor Authentication Server provides a way to secure resources with MFA capabilities

–

Download "Azure Multi-Factor Authentication Server"

–

Azure Multi-Factor Authentication Server

8.0.0.3

Released: 4/9/2018

–

Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

–

Version 8.0.0.3 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

• Registration experience improvements on mobile
• Improved interaction with AD Sync
• Support for TLS 1.2 for LDAP, User Portal to Web Service SDK, and SChannel replication
• Compliance with General Data Protection Regulation
• Accessibility improvements to User Portal, MFA Server management, and installation
• Fixed issue with fallback to security questions
• Fixed issue with security questions appearing multiple times
• Miscellaneous bug fixes and improvements
• NOT MENTIONED IN RELEASE NOTES: It now DOES install on Server Core!

–

Known Issues:

• Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

–

Upgrade Considerations:

• Must upgrade MFA Server and Web Service SDK before upgrading User Portal And AD FS adapter
• All other features and components are backwards-compatible with all previous versions
• Installation of the mobile app web service is not necessary for v8.0 or higher. Complete only the steps under Configure the mobile app. After the upgrade you may want to uninstall the previous mobile app web service, remove the virtual directory and application pool from IIS. If you have published the mobile app web service, then that is not required anymore

–

More information about Azure AD MFA Server can be found here.

–

Upgrade steps can be found here, but also take the following info into account

–

For this version of the MFA server:

• you need to have MS-KB2919355 installed on the MFA server before starting the installation (check with Get-HotFix KB2919355)
• you need to have the following installed on any server with any MFA server component: The Visual C++ 2017 Redistribution packages (a.k.a. Visual C++ "14" Runtime Libraries) are also available from here
• you need to have the at least following version installed on any server with any MFA server component: .NET Framework 4.6.2 is available from here.

–

Before upgrading/installing the new ADFS adapter, you need to unselect and unregister the previous ADFS adapter

• Using WID?: Execute the commands below on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish
• Using SQL?: Execute the commands below on any ADFS server

# Unselecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders
$listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")  # Use THIS line if the old version is v6.3.0 or lower
$listOfNewMFAProviders.Remove("AzureMfaServerAuthentication")  # Use THIS line if the old version is v7.0.0.9 or higher
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Unregistering The Azure AD MFA Adapter Within ADFS
Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication  # Use THIS line if the old version is v6.3.0 or lower
Unregister-AdfsAuthenticationProvider -Name AzureMfaServerAuthentication  # Use THIS line if the old version is v7.0.0.9 or higher

–

After installing the new ADFS adapter, you need to configure it, register it and configure it within ADFS

• Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards
• Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards

FILE: MultiFactorAuthenticationAdfsAdapter.config

<ConfigurationData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <UseWebServiceSdk><true OR false></UseWebServiceSdk>

    <WebServiceSdkUrl><URL to the MFA Web Service SDK></WebServiceSdkUrl>

    <WebServiceSdkUsername><the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config></WebServiceSdkUsername>

    <WebServiceSdkPassword><the password of the account above the user portal is also using in its web.config></WebServiceSdkPassword>

    <WebServiceSdkCertificateThumbprint><thumbprint of certificate of web service sdk></WebServiceSdkCertificateThumbprint>

    <AutomaticallyTriggerUserDefaultMethod><true OR false></AutomaticallyTriggerUserDefaultMethod>

    <TestMode><true OR false></TestMode>

</ConfigurationData>

–

Now we need to register and configure the new ADFS adapter within ADFS

# Registering The Azure AD MFA Adapter Within ADFS

$typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=8.0.0.3, Culture=neutral, PublicKeyToken=f300afd708cefcd3"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication –ConfigurationFilePath "<Provide Path To MultiFactorAuthenticationAdfsAdapter.config>"

# Selecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Configuring Custom Display Name And Custom Description
Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "<Provide Custom DisplayName>" -Description "<Provide Custom Description>"

–

I upgraded from the previous version without any issues!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisements

(2018-04-20) Azure AD Connect v1.1.751.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.751.0

Released: 4/12/2018

Released for download

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: If you have NOT upgraded to either 1.1.749.0 or 1.1.750.0, when the upgrade to this new version completes, it will automatically trigger a full sync and full import for the Azure AD connector and a full sync for the AD connector. Since this may take some time, depending on the size of your Azure AD Connect environment, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

IMPORTANT: This is a hotfix for Azure AD Connect

–

Fixed issues:

Azure AD Connect Sync

• Corrected an issue where automatic Azure instance discovery for China tenants was occasionally failing

–

AD FS Management

• There was a problem in the configuration retry logic that would result in an ArgumentException stating “an item with the same key has already been added.” This would cause all retry operations to fail.

–

I ran the MSI and upgraded from the previous version without any issues!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2018-04-01) Azure AD Connect v1.1.750.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.750.0

Released: 3/22/2018

Released for auto-upgrade and download

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: When the upgrade to this new version completes, it will automatically trigger a full sync and full import for the Azure AD connector and a full sync for the AD connector. Since this may take some time, depending on the size of your Azure AD Connect environment, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

IMPORTANT: “AutoUpgrade functionality was incorrectly disabled for some tenants who deployed builds later than 1.1.524.0. To ensure that your Azure AD Connect instance is still eligible for AutoUpgrade, run the following PowerShell cmdlet: “Set-ADSyncAutoUpgrade -AutoupGradeState Enabled”

–

Fixed issues:

Azure AD Connect

• Set-ADSyncAutoUpgrade cmdlet would previously block Autoupgrade if auto-upgrade state is set to Suspended. This is now changed so it does not block AutoUpgrade of future builds.
• Changed the User Sign-in page option "Password Synchronization" to "Password Hash Synchronization". Azure AD Connect synchronizes password hashes, not passwords, so this aligns with what is actually occurring. For more information see Implement password hash synchronization with Azure AD Connect sync

–

I ran the MSI and upgraded from the previous version without any issues!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2018-04-01) Azure AD Connect v1.1.749.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.749.0

Released to select customers

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: When the upgrade to this new version completes, it will automatically trigger a full sync and full import for the Azure AD connector and a full sync for the AD connector. Since this may take some time, depending on the size of your Azure AD Connect environment, please make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

–

Fixed issues:

Azure AD Connect

• Fix timing window on background tasks for Partition Filtering page when switching to next page

• Fixed a bug that caused Access violation during the ConfigDB custom action

• Fixed a bug to recover from SQL connection timeout

• Fixed a bug where certificates with SAN wildcards failed a prerequisite check

• Fixed a bug which causes miiserver.exe to crash during an Azure AD connector export

• Fixed a bug which bad password attempt logged on DC when running the Azure AD Connect wizard to change configuration

–

New features/Improvements:

Azure AD Connect

• Adding Privacy Settings for the General Data Protection Regulation (GDPR). For GDPR we are required to indicate the kinds of customer data that are shared with Microsoft (telemetry, health, etc.), have links to detailed online documentation, and provide a way to our customers to change their preferences. This check-in adds the following:
• Data sharing and privacy notification on the clean install EULA page.
• Data sharing and privacy notification on the upgrade page.
• A new additional task "Privacy Settings" where the user can change their preferences
• Application telemetry – admin can switch this class of data on/off at will
• Azure AD Health data – admin must visit the health portal to control their health settings. Once the service policy has been changed, the agents will read and enforce it.
• Added device write-back configuration actions and a progress bar for page initialization
• Improved General Diagnostics with HTML report and full data collection in a ZIP-Text / HTML Report
• Improved the reliability of auto upgrade and added additional telemetry to ensure the health of the server can be determined
• Restrict permissions available to privileged accounts on AD Connector account
• For new installations, the wizard will restrict the permissions that privileged accounts have on the MSOL account after creating the MSOL account.
• The changes will take care of following
• Express Installations
• Custom Installations with Auto-Create account
• Changed the installer so it doesn’t require SA privilege on clean install of Azure AD Connect
• Added a new utility to troubleshoot synchronization issues for a specific object. It is available under ‘Troubleshoot Object Synchronization’ option of Azure AD Connect Wizard Troubleshoot
  Additional Task. Currently, the utility checks for the following:
• UserPrincipalName mismatch between synchronized user object and the user account in Azure AD Tenant
• If the object is filtered from synchronization due to domain filtering
• If the object is filtered from synchronization due to organizational unit (OU) filtering
• Added a new utility to synchronize the current password hash stored in the on-premises Active Directory for a specific user account
• The utility does not require a password change. It is available under ‘Troubleshoot Password Hash Synchronization’ option of Azure AD Connect Wizard Troubleshoot Additional Task.

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2018-02-01) Result Set Of Policiy (RSoP) A.k.a. WhatIf Available For Azure AD Conditional Access Policies

In AD you have the option to perform a so called Result Set of Policy to determine which GPO contributed a specific (GPO) setting. Really handy when troubleshooting to understand which GPO is contributing a settings that for example breaks something or to be sure that a GPO is being applied correctly.

–

With AAD, you can create Conditional Access (CA) policies, where CA policies have conditions that need to be met before an access control kicks in. The only way to troubleshoot was the “do it yourself way” which could be seriously painful and time consuming.

–

As of today, AAD now has the “WhatIf Tool” in public preview for CA policies. I hoped we had this earlier!

For more info, check out the following blog post:

• Public preview: “What If” tool for Azure AD Conditional Access policies

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-09-15) Azure AD Connect v1.1.614.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.614.0

Released: 2017 September

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

–

Fixed issues:

Azure AD Connect

• Fixed an issue that prevented Azure AD Connect from updating the claims rules in on-premises ADFS while enabling the msDS-ConsistencyGuid as Source Anchor feature. The issue occurs if you try to enable the feature for an existing Azure AD Connect deployment that has ADFS configured as the sign-in method. The issue occurs because the wizard does not prompt for ADFS credentials before trying to update the claims rules in ADFS.
• Fixed an issue that caused Azure AD Connect to fail installation if the on-premises AD forest has NTLM disabled. The issue is due to Azure AD Connect wizard not providing fully qualified credentials when creating the security contexts required for Kerberos authentication. This causes Kerberos authentication to fail and Azure AD Connect wizard to fall back to using NTLM.

–

Azure AD Connect sync

• Fixed an issue where new synchronization rule cannot be created if the Tag attribute isn’t populated.
• Fixed an issue that caused Azure AD Connect to connect to on-premises AD for Password Synchronization using NTLM, even though Kerberos is available. This issue occurs if the on-premises AD topology has one or more domain controllers that was restored from a backup.
• Fixed an issue that caused full synchronization steps to occur unnecessarily after upgrade. In general, running full synchronization steps is required after upgrade if there are changes to out-of-box synchronization rules. The issue was due to an error in the change detection logic that incorrectly detected a change when encountering synchronization rule expression with newline characters. Newline characters are inserted into sync rule expression to improve readability.
• Fixed an issue that can cause the Azure AD Connect server to not work correctly after Automatic Upgrade. This issue affects Azure AD Connect servers with version 1.1.443.0 (or earlier). For details about the issue, refer to article Azure AD Connect is not working correctly after an automatic upgrade.
• Fixed an issue that can cause Automatic Upgrade to be retried every 5 minutes when errors are encountered. With the fix, Automatic Upgrade retries with exponential back-off when errors are encountered.
• Fixed an issue where password synchronization event 611 is incorrectly shown in Windows Application Event logs as informational instead of error. Event 611 is generated whenever password synchronization encounters an issue.
• Fixed an issue in the Azure AD Connect wizard that allows Group writeback feature to be enabled without selecting an OU required for Group writeback.

–

AD FS Management

• The Initialize-ADSyncNGCKeysWriteBack cmdlet in the AD prep powershell module was incorrectly ACL’ing the device registration container and would therefore only inherit existing permissions. This was updated so that the sync service account has the correct permissions

–

Seamless Single Sign-On

• Fixed an issue that caused Azure AD Connect wizard to return an error if you try to enable Seamless Single Sign-On. The error message is “Configuration of Microsoft Azure AD Connect Authentication Agent failed.” This issue affects existing customers who had manually upgraded the preview version of the Authentication Agents for Pass-through Authentication based on the steps described in this article.

–

Known issues:

Azure AD Connect sync

• There is a known issue with Azure AD Connect Upgrade that is affecting customers who have enabled Seamless Single Sign-On. After Azure AD Connect is upgraded, the feature appears as disabled in the wizard, even though the feature remains enabled. A fix for this issue will be provided in future release. Customers who are concerned about this display issue can manually fix it by enabling Seamless Single Sign-On in the wizard.

–

New features/Improvements:

Azure AD Connect sync

• Added a Troubleshoot task to Azure AD Connect wizard under Additional Tasks. Customers can leverage this task to troubleshoot issues related to password synchronization and collect general diagnostics. In the future, the Troubleshoot task will be extended to include other directory synchronization-related issues.
• Azure AD Connect now supports a new installation mode called Use Existing Database. This installation mode allows customers to install Azure AD Connect that specifies an existing ADSync database. For more information about this feature, refer to article Use an existing database.
• For improved security, Azure AD Connect now defaults to using TLS1.2 to connect to Azure AD for directory synchronization. Previously, the default was TLS1.0.
• When Azure AD Connect Password Synchronization Agent starts up, it tries to connect to Azure AD well-known endpoint for password synchronization. Upon successful connection, it is redirected to a region-specific endpoint. Previously, the Password Synchronization Agent caches the region-specific endpoint until it is restarted. Now, the agent clears the cache and retries with the well-known endpoint if it encounters connection issue with the region-specific endpoint. This change ensures that password synchronization can failover to a different region-specific endpoint when the cached region-specific endpoint is no longer available.
• To synchronize changes from an on-premises AD forest, an AD DS account is required. You can either (i) create the AD DS account yourself and provide its credential to Azure AD Connect, or (ii) provide an Enterprise Admin credentials and let Azure AD Connect create the AD DS account for you. Previously, (i) is the default option in the Azure AD Connect wizard. Now, (ii) is the default option.

–

AD FS Management

• The AAD Connect Verify ADFS Login task was updated so that it verifies logins against Microsoft Online and not just token retrieval from ADFS.
• When setting up a new ADFS farm using AAD Connect, the page asking for ADFS credentials was moved so that it now occurs before the user is asked to provide ADFS and WAP servers. This allows AAD Connect to check that the account specified has the correct permissions.
• During AAD Connect upgrade, we will no longer fail an upgrade if the ADFS AAD Trust fails to update. If that happens, the user will be shown an appropriate warning message and should proceed to reset the trust via the AAD Connect additional task

–

Azure AD Connect Health

• Added support for Microsoft Azure Government Cloud and Microsoft Cloud Germany.

–

I ran the MSI and upgraded from the previous version without any issues!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-09-11) Registering The Azure AD Connect Health Agent Through A Proxy

If you need to register your Azure AD Connect Health Agent for ADFS, Sync or ADDS through a proxy, you need to first configure the proxy server and port for Azure AD Connect Health.

You have the following options:

• Read the current proxy settings for AAD Connect Health –> Get-AzureAdConnectHealthProxySettings
• Import from Internet Explorer (if confgured) –> Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings
• Import from WinHTTP (if configured) –> Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp
• Specify Proxy addresses manually –> Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress <fqdn>:<port>
• Clear existing proxy configuration –> Set-AzureAdConnectHealthProxySettings -NoProxy

–

Now let’s assume you have used one of the options to configure the proxy settings. After that you can use the following PowerShell commands to register the Azure AD Connect Health Agent

$azureADUserName = "<replace this with a native or federated account that has the global admin role and is NOT MFA enabled/enforced>"

$azureADPassword = ‘<replace this with the password>’

$azureADSecurePassword = ConvertTo-SecureString $azureADPassword -AsPlainText –Force

$azureADCreds = New-Object System.Management.Automation.PSCredential $azureADUserName, $azureADSecurePassword

REMARK: specifying the credentials through PowerShell may be required if the server installing Azure AD Connect Health does not support cookies and/or javascript.

REMARK: Of course you can also use –> $azureADCreds = Get-Credential

–

For Azure AD Connect Health for ADFS –> Register-AzureADConnectHealthADFSAgent -Credential $azureADCreds

For Azure AD Connect Health for ADDS –> Register-AzureADConnectHealthADDSAgent-Credential $azureADCreds

For Azure AD Connect Health for Sync –> Register-AzureADConnectHealthSyncAgent-Credential $azureADCreds –AttributeFiltering [$false | $true] -StagingMode [$false | $true]

–

If the registration is succesful, you should see something similar to te following

Figure 1: Successful Registration Of Azure AD Connect Health (In This Case For ADFS)

–

However, you may see the following error:

Figure 2: Unsuccessful Registration Of Azure AD Connect Health (In This Case For ADFS) With The Error: “user_realm_discovery_failed: User Realm Discovery Failed”

–

Always when receiving an error, open the specified log file to see/understand what went wrong.

–

In this case opening the file I saw the following:

–

2017-08-25 07:20:39.295 ProductName: Azure AD Connect Health AD FS Agent, FileVersion: 3.0.68.0, Current UTC Time: 2017-08-25 07:20:39Z

2017-08-25 07:20:39.295 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADHybridHealthService/

2017-08-25 07:20:39.31 AdHybridHealthServiceUri: https://s1.adhybridhealth.azure.com/

2017-08-25 07:20:39.326 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADHybridHealthService/

2017-08-25 07:20:39.326 AdHybridHealthServiceUri: https://s1.adhybridhealth.azure.com/

2017-08-25 07:20:39.373 User Context outbound connections to https://management.azure.com/providers/Microsoft.ADHybridHealthService/ will use proxy address https://management.azure.com/providers/Microsoft.ADHybridHealthService/ (if equal, no proxy is used)

2017-08-25 07:20:39.373 Service Context: Outbound connections to https://management.azure.com/providers/Microsoft.ADHybridHealthService/ will use proxy address http://proxy.iamtec.nl:3128/ (if equal, no proxy is used)

2017-08-25 07:20:39.373 UploadLogFileFromDisk: arguments LogFileLocation=C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log;ProductName=Azure AD Connect Health AD FS Agent;ProductVersion=3.0.68.0;MachineName=SERVER;ServiceUri=https://s1.adhybridhealth.azure.com/;Result=started;type=registration,activityId=432fd061-6219-498a-8a98-bf68d90a5431

2017-08-25 07:20:39.389 UploadLogFileFromDisk: TenantId: unknown

2017-08-25 07:20:39.389 UploadLogFileFromDisk: MachineId: unknown

2017-08-25 07:20:39.389 UploadLogFileFromDisk: reading file contents of C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log

2017-08-25 07:20:39.389 UploadLogFileFromDisk: log length: 1842

2017-08-25 07:20:39.389 UploadFile: start, url: https://s1.adhybridhealth.azure.com/providers/Microsoft.ADHybridHealthService/diagnostics/logs/installer/product/Azure-AD-Connect-Health-AD-FS-Agent/version/3.0.68.0/machine/SERVER?result=started&type=registration

powershell.exe Information: 0 : AdHealthWebproxy settings: HttpsProxyAddress: http://proxy.iamtec.nl:3128/, initialization status: Succeeded; Registry value did not exist; Value was not a string, No Initialization Exception

2017-08-25 07:20:40.451 UploadFile: upload successful

2017-08-25 07:20:40.451 UploadLogFileFromDisk: response: Http response code: OK

"log successfully uploaded"

2017-08-25 07:20:40.451 AHealthServiceApiVersion: 2014-01-01

2017-08-25 07:20:40.451 –> https://management.core.windows.net/

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM:  – AdHealthAgentConfigurationUtility: ADAL .NET with assembly version ‘2.24.0.0’, file version ‘2.24.30411.1323’ and informational version ‘4482033c814db2fd31423c79b5027d0b5dfb7a6d’ is running…

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AcquireTokenNonInteractiveHandler: === Token Acquisition started:

                Authority: https://login.windows.net/common/

                Resource: https://management.core.windows.net/

                ClientId: cf6d7e68-f018-4e0a-a7b3-126e053fb88d

                CacheType: Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache (0 items)

                Authentication Target: User

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – <RunAsync>d__0: No matching token was found in the cache

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AsyncMethodBuilderCore: Sending user realm discovery request to ‘https://login.windows.net/common/UserRealm/jorge@iamtec.nl?api-version=1.0&#8217;

powershell.exe Error: 0 : 8/25/2017 7:21:10 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AsyncMethodBuilderCore: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The operation has timed out

   at System.Net.HttpWebRequest.GetResponse()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

   — End of inner exception stack trace —

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenNonInteractiveHandler.<PreTokenRequest>d__4.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenHandlerBase.<RunAsync>d__0.MoveNext()

                ErrorCode: user_realm_discovery_failed

                StatusCode: 0

2017-08-25 07:21:10.645 Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The operation has timed out

   at System.Net.HttpWebRequest.GetResponse()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

   — End of inner exception stack trace —

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.RunAsyncTask[T](Task`1 task)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.AdHealthAgentConfigurationUtility.ObtainAadAccessTokenWithExistingCredential(PSCredential psCredential)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.RegisterADHealthAgent.ProcessRecord()

                ErrorCode: user_realm_discovery_failed

                StatusCode: 0

2017-08-25 07:21:10.66 UploadLogFileFromDisk: arguments LogFileLocation=C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log;ProductName=Azure AD Connect Health AD FS Agent;ProductVersion=3.0.68.0;MachineName=SERVER;ServiceUri=https://s1.adhybridhealth.azure.com/;Result=failed;type=registration,activityId=432fd061-6219-498a-9b98-bf68d90a5431

2017-08-25 07:21:10.66 UploadLogFileFromDisk: TenantId: unknown

2017-08-25 07:21:10.66 UploadLogFileFromDisk: MachineId: unknown

2017-08-25 07:21:10.66 UploadLogFileFromDisk: reading file contents of C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log

2017-08-25 07:21:10.66 UploadLogFileFromDisk: log length: 7608

2017-08-25 07:21:10.66 UploadFile: start, url: https://s1.adhybridhealth.azure.com/providers/Microsoft.ADHybridHealthService/diagnostics/logs/installer/product/Azure-AD-Connect-Health-AD-FS-Agent/version/3.0.68.0/machine/SERVER?result=failed&type=registration

2017-08-25 07:21:11.082 UploadFile: upload successful

2017-08-25 07:21:11.082 UploadLogFileFromDisk: response: Http response code: OK

"log successfully uploaded"

–

The green lines above list what/where things go wrong. In this case user realm discovery is failing. However, the yellow lines are giving you a hint why things are going wrong.

–

Looking at the second yellow line you see the service context is using the proxy server configured for Azure AD Connect Health. However, the first yellow line tells you the user context context is not using any proxy server at all. Because of that it is failing the realm discovery

–

The solution for this is to configure the user context with a proxy server and port. That is done by configuring the proxy settings in Internet Explorer with the same values

Figure 3: Configuring The User Context With Proxy Settings

–

After doing this, retry registration.

–

If it still fails check the log file again. You might see the following:

–

powershell.exe Information: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – <RunAsync>d__0: No matching token was found in the cache

powershell.exe Information: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – AsyncMethodBuilderCore: Sending user realm discovery request to ‘https://login.windows.net/common/UserRealm/jorge@iamtec.nl?api-version=1.0&#8217;

powershell.exe Error: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – AsyncMethodBuilderCore: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

–

In this case, your proxy server is terminating SSL traffic for inspection. If you have not imported the root certificate of the certificate being used by the proxy server into the “Trusted Root Certificate Authority” store, you will see an error like this. Import the root certificate of the certificate being used by the proxy server into the “Trusted Root Certificate Authority” store to fix this.

–

Hope this helps you!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-09-07) Claims Rules Set For Your AAD/O365 RP Trust To Support User And Device Authentication

On the page “How to configure hybrid Azure Active Directory joined devices” Microsoft explains how to setup Domain Join ++, currently a.k.a. Hybrid AAD Join. This post is about, hopefully giving additional, clarification on how to setup the claims rules in ADFS. All the scenarios listed below work, it just on your scenario. Feel free to leave any comments if unclear. The import of the rules below should replace your current rules for the AAD RP Trust, and where applicable add rules to your AD CP trust. A final note, is that these rule sets are based upon Microsoft’s rule in the previous article.

Make sure to test this first in your test environment!

You may also want to have a look at the following blog post:

(2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail

–

[OPTION 1]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• It is making multiple LDAP calls to AD, and is therefore not that optimized. It works though!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/vgzvnwhku2adp39/AzureAD-RP-Trust-Issuance-Rules1.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN And ImmutableID (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D

=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN&quot;, "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";userPrincipalName,objectGUID;{0}", param = c2.Value);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue ImmutableID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 2]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• Although a few LDAP calls less, it is still making LDAP calls to AD. It works though!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/udn1rudm5bgv7jq/AzureAD-RP-Trust-Issuance-Rules2.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";objectGUID;{0}", param = c.Value);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 3]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
• http://temp.org/identity/claims/objectGUID

–

For the last claim type you would need the following claim rule on the AD CP trust if you are not already extracting additional data from AD

–

$additionalADCPTrustRule = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract Extra Data From AD"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
  => issue(store = "Active Directory", types = ("http://temp.org/identity/claims/objectGUID&quot;), query = ";objectguid;{0}", param = c.Value);
"@

$existingADCPtrustAcceptRuleSet = (Get-AdfsClaimsProviderTrust -Name "Active Directory").AcceptanceTransformRules

$newADCPtrustAcceptRuleSet = $existingADCPtrustAcceptRuleSet + $additionalADCPTrustRule

Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRules $newADCPtrustAcceptRuleSet

–

If you are already extracting additional data from AD, you need to add the claim type and attribute to that existing extraction

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• No LDAP calls!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/8cicjpyusapsarj/AzureAD-RP-Trust-Issuance-Rules3.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 4]

The following works if you have claims rules in place on the AD CP trust that output the following claim types.  This is true if you are using the default claim rule set in ADFSv3/ADFSv4 for the first 2 claim types, but not for the last 2 claim types. My main reason for not using groupsid is that the amount of values can be so huge it may not fit on a cookie and the browser chokes. Because of that, when not using the groupsid claim type, you need to design a better model to extract group data from AD and use authorization based claims types from that data. If you are not using the groupsid claim type you can also not identify the difference between a user and a computer. That’s why you can then specifically extract the primaryGroupID.:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
• http://temp.org/identity/claims/objectGUID
• http://temp.org/identity/claims/primaryGroupID

–

For the last 2 claim types you would need the following claim rule on the AD CP trust if you are not already extracting additional data from AD

–

$additionalADCPTrustRule = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract Extra Data From AD"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
  => issue(store = "Active Directory", types = ("http://temp.org/identity/claims/objectGUID&quot;,"http://temp.org/identity/claims/primaryGroupID&quot;), query = ";objectguid,primaryGroupID;{0}", param = c.Value);
"@

$existingADCPtrustAcceptRuleSet = (Get-AdfsClaimsProviderTrust -Name "Active Directory").AcceptanceTransformRules

$newADCPtrustAcceptRuleSet = $existingADCPtrustAcceptRuleSet + $additionalADCPTrustRule

Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRules $newADCPtrustAcceptRuleSet

–

If you are already extracting additional data from AD, you need to add the claim type and attribute to that existing extraction

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• No LDAP calls!
• No groupsid claim type!

–

Link to claims rules below: https://www.dropbox.com/s/6nbwuuxl677wb3p/AzureAD-RP-Trust-Issuance-Rules4.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^513$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"] &&

c2:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

Hopefully this blog post gives you the information you need to understand what is needed

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-08-14) Azure AD Connect v1.1.561.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.561.0

Released: 2017 July

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

–

Fixed issues:

Azure AD Connect sync

• Fixed an issue that caused the out-of-box synchronization rule “Out to AD – User ImmutableId” to be removed:
• The issue occurs when Azure AD Connect is upgraded, or when the task option Update Synchronization Configuration in the Azure AD Connect wizard is used to update Azure AD Connect synchronization configuration.
• This synchronization rule is applicable to customers who have enabled the msDS-ConsistencyGuid as Source Anchor feature. This feature was introduced in version 1.1.524.0 and after. When the synchronization rule is removed, Azure AD Connect can no longer populate on-premises AD ms-DS-ConsistencyGuid attribute with the ObjectGuid attribute value. It does not prevent new users from being provisioned into Azure AD.
• The fix ensures that the synchronization rule will no longer be removed during upgrade, or during configuration change, as long as the feature is enabled. For existing customers who have been affected by this issue, the fix also ensures that the synchronization rule is added back after upgrading to this version of Azure AD Connect.
• Fixed an issue that causes out-of-box synchronization rules to have precedence value that is less than 100:
• In general, precedence values 0 – 99 are reserved for custom synchronization rules. During upgrade, the precedence values for out-of-box synchronization rules are updated to accommodate sync rule changes. Due to this issue, out-of-box synchronization rules may be assigned precedence value that is less than 100.
• The fix prevents the issue from occurring during upgrade. However, it does not restore the precedence values for existing customers who have been affected by the issue. A separate fix will be provided in the future to help with the restoration.
• Fixed an issue where the Domain and OU Filtering screen in the Azure AD Connect wizard is showing Sync all domains and OUs option as selected, even though OU-based filtering is enabled. Also explained here, including solution: (2017-06-28) Azure AD Connect Wizard Chooses To Sync All Instead Of Already Selected OUs/Domains
• Fixed an issue that caused the Configure Directory Partitions screen in the Synchronization Service Manager to return an error if the Refresh button is clicked. The error message is “An error was encountered while refreshing domains: Unable to cast object of type ‘System.Collections.ArrayList’ to type ‘Microsoft.DirectoryServices.MetadirectoryServices.UI.PropertySheetBase.MaPropertyPages.PartitionObject.” The error occurs when new AD domain has been added to an existing AD forest and you are trying to update Azure AD Connect using the Refresh button.

–

New features/Improvements:

Azure AD Connect sync

• Automatic Upgrade feature has been expanded to support customers with the following configurations:
• You have enabled the device writeback feature.
• You have enabled the group writeback feature.
• The installation is not an Express settings or a DirSync upgrade.
• You have more than 100,000 objects in the metaverse.
• You are connecting to more than one forest. Express setup only connects to one forest.
• The AD Connector account is not the default MSOL_ account anymore.
• The server is set to be in staging mode.
• You have enabled the user writeback feature.

–

I ran the MSI and upgraded from the previous version without any issues!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-07-05) Azure AD Connect v1.1.557.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.557.0

Released: 2017 July

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

–

Fixed issues:

Azure AD Connect sync

• Fixed an issue with the Initialize-ADSyncDomainJoinedComputerSync cmdlet that caused the verified domain configured on the existing service connection point object to be changed even if it is still a valid domain. This issue occurs when your Azure AD tenant has more than one verified domains that can be used for configuring the service connection point.

–

Known issues:

Azure AD Connect sync:

• There is an issue that affects customers who are using OU-based filtering with Azure AD Connect sync. When you navigate to the Domain and OU Filtering page in the Azure AD Connect wizard, the following behavior is expected:
• If OU-based filtering is enabled, the Sync selected domains and OUs option is selected.
  Otherwise, the Sync all domains and OUs option is selected.
• The issue that arises is that the Sync all domains and OUs option is always selected when you run the Wizard. This occurs even if OU-based filtering was previously configured. Before saving any AAD Connect configuration changes, make sure the Sync selected domains and OUs option is selected and confirm that all OUs that need to synchronize are enabled again. Otherwise, OU-based filtering will be disabled.
• Also explained here, including solution: (2017-06-28) Azure AD Connect Wizard Chooses To Sync All Instead Of Already Selected OUs/Domains

–

New features/Improvements:

Azure AD Connect sync

• Password writeback is now available for preview with Microsoft Azure Government cloud and Microsoft Cloud Germany. For more information about Azure AD Connect support for the different service instances, refer to article Azure AD Connect: Special considerations for instances.
• The Initialize-ADSyncDomainJoinedComputerSync cmdlet now has a new optional parameter named AzureADDomain. This parameter lets you specify which verified domain to be used for configuring the service connection point.

–

I ran the MSI and upgraded from the previous version without any issues!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-