Jorge&#039;s Quest For Knowledge!

1.2.65.0

Released: 10/25/2018

Released for download

–

–

link: /Home/Error?message=unsupported_response_type">https://<Web_Application_URL>/Home/Error?message=unsupported_response_type

–

IMPORTANT: I upgraded Azure AD Connect v1.1.882, and the next time it synched it triggered a full import and full sync for both the AD connector and the AAD connector. Since this may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, 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.

–

New features and improvements

Changed the functionality of attribute write-back to ensure hosted voice-mail is working as expected. Under certain scenarios, Azure AD was overwriting the msExchUcVoicemailSettings attribute during write-back with a null value. Azure AD will now no longer clear the on-premises value of this attribute if the cloud value is not set.
Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to Azure AD. These same diagnostics can also be run directly through Powershell using the Test- AdSyncAzureServiceConnectivity Cmdlet.
Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to AD. These same diagnostics can also be run directly through Powershell using the Start-ConnectivityValidation function in the ADConnectivityTools Powershell module. For more information see What is the ADConnectivityTool PowerShell Module?
Added an AD schema version pre-check for Hybrid Azure Active Directory Join and device write-back
Changed the Directory Extension page attribute search to be non-case sensitive.
Added full support for TLS 1.2. This release supports all other protocols being disabled and only TLS 1.2 being enabled on the machine where Azure AD Connect is installed. For more information see TLS 1.2 enforcement for Azure AD Connect

–

Fixed issues

Fixed a bug where Azure AD Connect Upgrade would fail if SQL Always On was being used.
Fixed a bug to correctly parse OU names that contain a forward slash.
Fixed an issue where Pass-Through Authentication would be disabled for a clean install in staging mode.
Fixed a bug that prevented the PowerShell module to be loaded when running the Troubleshooting tools
Fixed a bug that would block customers from using numeric values in the first character of a host name.
Fixed a bug where Azure AD Connect would allow invalid partitions and container selection
Fixed the “Invalid Password” error message when Desktop SSO is enabled.
Various Bug fixes for AD FS Trust Management
When configuring Device Writeback – fixed the schema check to look for the msDs-DeviceContainer object class (introduced on WS2012 R2)

–

I (finally) 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-11-01) Deploying The Sample Azure AD GraphAPI B2B Web Portal, Starting From “App Registrations (Preview)”

Posted by Jorge on 2018-11-01

If you are interested in Azure AD B2B, and especially in the self-service part, you may also be interested in deploying and testing the sample Azure AD GraphAPI B2B Web Portal. I’m one of those persons that falls into that category!

The sample Azure AD GraphAPI B2B Web Portal can be found here. A detailed instruction to configure and deploy can be found here.

Reasons for this blog post are:

You should be good when starting from “App Registrations”, but if you start from “App Registrations (Preview)” (or whatever it will be called in the future), then some steps are slightly different and you may or may not understand what you need to do;
The sample Azure AD GraphAPI B2B Web Portal may not work in the end, which needs fixing.

–

So, let’s get started while starting from “App Registrations (Preview)”

–

[Step 1] Determine Your Tenant ID

No changes in the steps

–

[Step 2] Registering The AAD B2B Admin Application

When creating a new registration for the AAD B2B Admin Application, go to the “App Registrations (Preview)” and click “New Registration”

For the “user-facing display name for this application” enter for example “Azure AD B2B Admin Application”
For the “Supported Account Types” choose “Accounts In This Organization Directory Only” (meaning, all user accounts and all guests accounts from this directory only)
For the “Redirect URI” choose “Web” and as a URL specify “https://loopback” (will be updated later!)
At the bottom click “Register”

Figure 1: Registering The Azure AD B2B Admin Application

–

Right after registering, it will open in the “Overview” node.

Write down the “application ID” which is required later in the Web Application/App Service as the client ID for the admin application

Figure 2: Overview Details Of The Azure AD B2B Admin Application

–

Click on the “Authentication” node

Make sure to check “ID Tokens” or you will have some fun later on!
Click on SAVE at the top

Figure 3: Selecting The Required Token For The Implicit Grant Flow

–

Click on the “Certificates And Secrets” node

Click on “New Client Secret”

Figure 4: The Certificates And Secrets Page

–

As a “Description” enter for example “Azure AD B2B Admin Application Secret – Key 1”
Select an expiration period that you are comfortable with
Click ADD

Figure 5: Adding A Client Secret For The Azure AD B2B Admin Application

–

Make sure to copy or write down the value as you will not have a chance to get it back later!

Figure 6: Client Secret Defined For The Azure AD B2B Admin Application

–

Click on the API Permissions node

If correct, the “Delegated” permission for “Sign In And Read User Profile” is already configured
Click on Add A Permission

Figure 7: API Permissions For The Azure AD B2B Admin Application

–

On the new pane at the right that opens click on Microsoft Graph

Figure 8: Selecting The Microsoft Graph As The API To Grant Permissions To

–

If the “Delegated” permissions are not yet configured, click on “Delegated Permissions”, otherwise skip this step

Scroll down to User and expand User and select User.Read (“Sign In And Read User Profile”)
Click Add Permissions

Figure 9: Selecting Delegated Permissions

–

Figure 10: User Permissions To Assign As Delegated Permissions

–

Click on Add A Permission

On the new pane at the right that opens click on Microsoft Graph

Figure 11: Selecting The Microsoft Graph As The API To Grant Permissions To

–

Click on “Application Permissions”

Scroll down to Directory and expand Directory and select Directory.ReadWrite.All (“Read And Write Directory Data”)

Scroll down to User and expand User and select User.ReadWrite.All (“Read And Write All Users’ Full Profiles”)

Click Add Permissions

Figure 12: Selecting Application Permissions

–

Figure 13: Directory Permissions To Assign As Application Permissions

–

Figure 14: User Permissions To Assign As Application Permissions

–

[Step 3] Registering The AAD B2B Pre-AuthN Application

When creating a new registration for the AAD B2B Pre-AuthN Application, go to the “App Registrations (Preview)” and click “New Registration”

For the “user-facing display name for this application” enter for example “Azure AD B2B Pre-AuthN Application”
For the “Supported Account Types” choose “Accounts In Any Organization Directory And Personal Microsoft Accounts” (meaning, any user account from any Azure AD directory and any personal Microsoft Account) OR choose “Accounts In Any Organization Directory” (meaning, any user account from any Azure AD directory)
For the “Redirect URI” choose “Web” and as a URL specify “https://loopback” (will be updated later!)
At the bottom click “Register”

Figure 15: Registering The Azure AD B2B Pre-AuthN Application

–

Right after registering, it will open in the “Overview” node.

Write down the “application ID” which is required later in the app service as the client ID for the pre-authN application

Figure 16: Overview Details Of The Azure AD B2B Pre-AuthN Application

–

Click on the “Authentication” node

Make sure to check “Access Tokens” and “ID Tokens” or you will have some fun later on!
Click on SAVE at the top

Figure 17: Selecting The Required Tokens For The Implicit Grant Flow

–

Click on the “Certificates And Secrets” node

Click on “New Client Secret”

Figure 18: The Certificates And Secrets Page

–

As a “Description” enter for example “Azure AD B2B Admin Application Secret – Key 1”

Select an expiration period that you are willing to accept
Click ADD

Figure 19: Adding A Client Secret For The Azure AD B2B Pre-AuthN Application

–

Make sure to copy or write down the value as you will not have a chance to get it back later!

Figure 20: Client Secret Defined For The Azure AD B2B Pre-AuthN Application

–

Click on the “API Permissions” node

If correct, the “Delegated” permission for “Sign In And Read User Profile” is already configured

If the “Delegated” permissions are not yet configured (otherwise skip this step)

Click on “Click on Add A Permission”
Click on “Microsoft Graph”
Click on “Delegated Permissions”
Scroll down to User and expand User and select User.Read (“Sign In And Read User Profile”
Click Add Permissions

Figure 21: API Permissions For The Azure AD B2B Pre-AuthN Application

–

Figure 22: Selecting The Microsoft Graph As The API To Grant Permissions To

–

Figure 23: Selecting Delegated Permissions

–

Figure 24: User Permissions To Assign As Delegated Permissions

–

Click on the “Manifest” node

Find the line "oauth2AllowImplicitFlow", and change "false" to "true". Don’t include quotes, just replace the word.
Click SAVE

Figure 25: Editing The Manifest

–

[Step 4] Deploying The Web Application

No changes in the steps

–

[Step 5] Post Configuration Cleanup

No changes in the steps for the The Azure AD B2B Admin Application

However, for the The Azure AD B2B Pre-AuthN Application, you should specify 2 reply URLs instead of just 1.

The following Reply URLs must be specified:

Figure 26: Reply URLs For The Azure AD B2B Pre-AuthN Application

–

[Step 6] Trying It Out

Navigate to the URL of the Web Application and you will see the following

Figure 27: Notification The B2B Portal Requires Configuration By An Admin

–

After clicking on Admin Sign In on the right and signing in, you should see

Figure 28: Site Configuration Screen For The B2B Portal

–

…but if you see

Figure 29: Error Notification Something Is Wrong

–

Error

An error occurred while processing your request.

–

–

Something is really wrong (duh!)

–

Now retry it again until you need to authenticate, but don’t!. Now look at the URL which should be similar to the one below

Figure 30: The URL At The Time Of Authentication

–

It is expecting a response type of “code” and “id_token” for the client with ID as specified by the red arrow (which is the Application ID of the Admin application registration)

have you checked “ID Token” for the Admin application registration? If not, then go back and check it (Picture 3)

–

After changing that, retry and it should work!

–

In all three cases below, when the invited user logs in to /Profile">https://<Web_Application_URL>/Profile, everything is OK.

However, as soon as the user tries to sync its profile from its home tenant to the inviting tenant, you will experience the following:

… if the “ID Token” is not checked for the Azure AD B2B Pre-AuthN Application (Figure 17)

Figure 31: Error When The “ID Token” Is Not Selected For The Azure AD B2B Pre-AuthN Application

–

… if only one reply URL is configured (main URL for the web application) and not 2 as shown in figure 26

Figure 32: Error When The “ID Token” Is Not Selected For The Azure AD B2B Pre-AuthN Application

–

… if the “Access Token” is not checked for the Azure AD B2B Pre-AuthN Application (Figure 17)

Figure 33: Error When The “Access Token” Is Not Selected For The Azure AD B2B Pre-AuthN Application

–

Cheers,
Jorge

Posted in Azure AD B2B, Windows Azure Active Directory | Leave a Comment »

(2018-10-26) Running The Azure AD Password Protection Summary Report May Generate An Error

Posted by Jorge on 2018-10-26

When on one of the Azure AD Password Protection Proxy servers, you can generate an Azure AD Password Protection Summary report through one of the following commands:

Targeting a specific DC:

Get-AzureADPasswordProtectionSummaryReport -DomainController <RWDC FQDN>

–

Targeting all DCs in a specific AD Domain:

Get-AzureADPasswordProtectionSummaryReport -Domain <AD DOMAIN FQDN>

–

Targeting all DCs in a specific AD Forest:

Get-AzureADPasswordProtectionSummaryReport -Forest <AD FOREST FQDN>

–

Targeting all DCs in the local AD Forest:

Get-AzureADPasswordProtectionSummaryReport

–

So, whatever your targeted scope is, if all DCs have have the Azure AD Password Protection DC Agent installed, they will also have the corresponding event logs, which are:

Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"}

Figure 1: All The Azure AD Password Protection DC Agent Event Logs On An RWDC

–

….and for completeness on the Azure AD Password Protection Proxy servers

Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"}

Figure 2: All The Azure AD Password Protection Proxy Event Logs On The Proxy Servers

–

However, if you see errors similar to the one below…

Figure 2: Error When Generating The Azure AD Password Protection Summary Report Against Targeted DCs

–

…then the targeted event logs are missing. And of the events logs are missing, then the Azure AD Password Protection DC Agent is most likely not installed on the RWDC.

Solution? Install the Azure AD Password Protection DC Agent on the RWDC that throws the error.

–

Please be aware that querying for DCs that have the Service Connection Point (SCP) registered in AD, may not be accurate. Why? If you installed the Azure AD Password Protection DC Agent and then uninstall it, for whatever reason, the SCP for that RWDC is not cleaned during the uninstall. Also be aware that if you force removed any DC and did not clean up its metadata, you will be trying to reach an RWDC that does not exist anymore when running the summary report.

–

Although more intense, the most accurate way is checking for any of the following:

If the Azure AD Password Protection DC Agent is installed (against every RWDC –> Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection DC Agent’")
If the Azure AD Password Protection DC Agent service is installed (against every RWDC –> Get-Service AzureADPasswordProtectionDCAgent)
If the Azure AD Password Protection DC Agent is installed (against every RWDC –> Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"})

–

Cheers,
Jorge

Posted in Azure AD Password Protection, Windows Azure Active Directory | Leave a Comment »

(2018-10-25) When Installing The Azure AD Password Protection DC Agent Generates An Error

Posted by Jorge on 2018-10-25

If you are installing the Azure AD Password Protection DC Agent on an RWDC and you receive the following error….

Figure 1: An Error The Azure AD Password Protection DC Agent Setup Wizard Ended Prematurely

–

….execute the AADPwdProtection\AzureADPasswordProtectionDCAgent.msi with the following options

MSIEXEC /i AzureADPasswordProtectionDCAgent.msi /log AzureADPasswordProtectionDCAgent.log

After it errors again, open the log file and search for the word ERROR. When you do, you will most likely find why it errors. If it has the same cause as I had, you will see something similar to the following:

–

Dumping MSI properties of interest:
‘INSTALLDIR’ = ‘C:\Program Files\Azure AD Password Protection DC Agent\’
‘Installed’ = ”
‘INSTALLLEVEL’ = ‘1’
‘ProductCode’ = ‘{67E66797-A45C-4C3C-B481-554F9F427227}’
‘ProductID’ = ”
‘ProductName’ = ‘Azure AD Password Protection DC Agent’
‘ProductState’ = ‘-1’
‘ProductVersion’ = ‘1.2.10.0’
‘ProgramFiles64Folder’ = ‘C:\Program Files\’
‘Remove’ = ”
‘UPGRADINGPRODUCTCODE’ = ”
‘BPL_NONUPGRADEABLEAPPFOUND’ = ”
‘BPL_STATEMIGRATIONFOLDER’ = ”
Done with MSI property dump
CheckForNonUpgradeableApps – opened Uninstall key with 9 subkeys
CheckForNonUpgradeableApps – a nonupgradeable app was found ‘Azure AD Password Protection DC Agent’ – ‘1.1.10.3’
CustomAction BPL_CheckForNonUpgradeableApps returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 16:30:01: BPL_CheckForNonUpgradeableApps. Return value 3.
Action ended 16:30:01: INSTALL. Return value 3.

–
In plain English this means you are trying to install a newer version on top of an version that cannot be upgraded. Check the versions. The old version here was installed by means months ago when I participated in the public preview. Today I wanted to install the officially released version and had forgotten the old version was still installed.

The solution here? Uninstall the old version first and install the newer version. After both the uninstall and the install a reboot of the RWDC is required.

To determine if a version is already installed and if yes to uninstall it, execute the following commands:

WMIC PRODUCT GET NAME | FIND /I "Azure AD Password Protection DC Agent"

WMIC PRODUCT WHERE NAME="Azure AD Password Protection DC Agent" CALL UNINSTALL

–

….and if you are a PowerShell junky, you can also use the following for the uninstall

$product = Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection DC Agent’"

$product

$product.Uninstall() # WARNING: Reboot is immediate, no mercy and no questions asked!!!

–

After the uninstall and reboot, install the newest AzureADPasswordProtectionDCAgent.msi available from Microsoft

–

Cheers,
Jorge

Posted in Azure AD Password Protection, Windows Azure Active Directory | Leave a Comment »

(2018-10-22) Cloning Windows 10 Or Windows Server 2016 May Break Hybrid Azure AD Domain Join

Posted by Jorge on 2018-10-22

When cloning Windows computers you are basically copying everything from some source computer to one or more target computers. One of the benefits is the speed in deployment and the time you same to have to configure stuff every single time. Are there downsides? Yes, there are, at least if you do not take some risk mitigating measures. One of those is the SID of the local computer. Every time you deploy a cloned version of Windows you MUST execute SYSPREP to make the clone gets its own unique SID. If you don’t at the beginning and along the way things may appear to be correct. However, at some point in time you may find yourself with a huge headache trying to understand why something does not work or shows weird behavior.

Recently I found another downside of cloning, that in the end can be mitigated with some post-deployment actions.

–

For more info about Hybrid Azure AD Domain Join (HAADJ) please also have a look at

–

I was trying to Hybrid Azure AD Domain Join (HAADJ) a AD domain joined Windows Server 2016 by logging on and waiting for the scheduled task to kick in and checking the correct Event Logs, and later on under the context of “NT AUTHORITY\SYSTEM” by running DSREGCMD.EXE /DEBUG. When running that last command I kept seeing the following error at the end:

DsrDeviceAutoJoinFederated failed with -2146893802
wmain: failed with error code 0x80090016.

–

After some troubleshooting I discovered that Windows was a cloned deployment. One of the thing that is also cloned is the key material. The key material is in the folder “C:\ProgramData\Microsoft\Crypto\Keys” to “C:\ProgramData\Microsoft\Crypto\Keys”. The solution therefore is to get rid of the old key material and start fresh from the beginning. You can do that by running the following PowerShell commands:

# Rename The “Keys” Folder To “KeysOLD”

Rename-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -NewName "KeysOLD"

# Create A New “Keys” Folder

New-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -ItemType Directory

# Copy The ACL From The “KeysOLD” Folder To The New “Keys” Folder

Get-Acl -Path "C:\ProgramData\Microsoft\Crypto\KeysOLD" | Set-Acl -Path "C:\ProgramData\Microsoft\Crypto\Keys"

–

Now retry HAADJ by rebooting the Windows computers and logging on, or executing DSREGCMD.EXE /DEBUG under the context of “NT AUTHORITY\SYSTEM”. It should work now!

–

REMARK: If you did not know it yet, you can get into the context of “NT AUTHORITY\SYSTEM” by using PSEXEC and running the following command: PSEXEC –i –s CMD.EXE

–

Cheers,
Jorge

Posted in Azure AD Join, Windows Azure Active Directory, Windows Client, Windows Server | 3 Comments »

(2018-10-07) Presenting At Hybrid Identity Protection (HIP) Conference In New York

Posted by Jorge on 2018-10-07

As we speak, I’m preparing my presentation and demo’s for my presentation at the Hybrid Identity Protection (HIP) conference in New York. You can get more information, and of course register (did you already register?) through the following link https://www.hipconf.com/. The conference dates are Monday November 5th and Tuesday November 6th.

The Speaker List: https://www.hipconf.com/speakers/

The Agenda: https://www.hipconf.com/agenda/

–

My session is scheduled for Monday November 5th at 5 PM (17:00) and is called “How To Secure Shared Social Media Accounts And Achieve SSO Through Azure AD”

Abstract:

Nowadays many companies have an online presence in most likely more than one social media to at least service and/or communicate with customers regarding all kinds of matters. Some well-known examples are Twitter, Facebook, Instagram and YouTube. Of course, other social media may exist specific to the business or country.

The main question is: how can you make sure those (shared) social media accounts are used in a secure manner by a group of people and still keep the bad guys out?

The answer is: That’s where Azure AD comes into the playing field!

Come to this session to learn and see about experiences using the Azure AD solution. Yes, demos are included!

–

See you there!

–

Cheers,
Jorge

Posted in Conferences, Windows Azure Active Directory | Leave a Comment »

(2018-10-07) Azure AD Connect v1.1.882.0 Has Been Released

Posted by Jorge on 2018-10-07

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"

–

1.1.882.0

Released: 9/7/2018

Released for download, will not be released for auto upgrade

–

–

Download "Microsoft Azure Active Directory Connect"

–

Fixed Issues:

Azure AD Connect Upgrade fails if SQL Always On Availability is configured for the ADSync DB. This hotfix addresses this issue and allows Upgrade to succeed

–

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

–

Cheers,
Jorge

Posted in Azure AD Connect | Leave a Comment »

(2018-10-07) Azure AD Connect v1.1.880.0 Has Been Released

Posted by Jorge on 2018-10-07

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.

–

–

1.1.880.0

Released: 8/21/2018

Released for auto upgrade and download

–

–

Download "Microsoft Azure Active Directory Connect"

–

New Features And Improvements:

The Ping Federate integration in Azure AD Connect is now available for General Availability. Learn more about how to federated Azure AD with Ping Federate
Azure AD Connect now creates the backup of Azure AD trust in AD FS every time an update is made and stores it in a separate file for easy restore if required. Learn more about the new functionality and Azure AD trust management in Azure AD Connect.
New troubleshooting tooling helps troubleshoot changing primary email address and hiding account from global address list
Azure AD Connect was updated to include the latest SQL Server 2012 Native Client
When you switch user sign-in to Password Hash Synchronization or Pass-through Authentication in the "Change user sign-in" task, the Seamless Single Sign-On checkbox is enabled by default.
Added support for Windows Server Essentials 2019
The Azure AD Connect Health agent was updated to the latest version 3.1.7.0
During an upgrade, if the installer detects changes to the default sync rules, the admin is prompted with a warning before overwriting the modified rules. This will allow the user to take corrective actions and resume later. Old Behavior: If there was any modified out-of-box rule then manual upgrade was overwriting those rules without giving any warning to the user and sync scheduler was disabled without informing user. New Behavior: User will be prompted with warning before overwriting the modified out-of-box sync rules. User will have choice to stop the upgrade process and resume later after taking corrective action.
Provide a better handling of a FIPS compliance issue, providing an error message for MD5 hash generation in a FIPS compliant environment and a link to documentation that provides a work around for this issue.
UI update to improve federation tasks in the wizard, which are now under a separate sub group for federation.
All federation additional tasks are now grouped under a single sub-menu for ease of use.
A new revamped ADSyncConfig Posh Module (AdSyncConfig.psm1) with new AD Permissions functions moved from the old ADSyncPrep.psm1 (which may be deprecated shortly)

–

Fixed Issues:

Fixed a bug where the AAD Connect server would show high CPU usage after upgrading to .Net 4.7.2
Fixed a bug that would intermittently produce an error message for an auto-resolved SQL deadlock issue
Fixed several accessibility issues for the Sync Rules Editor and the Sync Service Manager
Fixed a bug where Azure AD Connect can not get registry setting information
Fixed a bug that created issues when the user goes forward/back in the wizard
Fixed a bug to prevent an error happening due to incorrect multi thread handing in the wizard
When Group Sync Filtering page encounters an LDAP error when resolving security groups, Azure AD Connect now returns the exception with full fidelity. The root cause for the referral exception is still unknown and will be addressed by a different bug.
Fixed a bug where permissions for STK and NGC keys (ms-DS-KeyCredentialLink attribute on User/Device objects for WHfB) were not correctly set.
Fixed a bug where ‘Set-ADSyncRestrictedPermissions’ was not called correctly
Adding support for permission granting on Group Writeback in AADConnect’s installation wizard
When changing sign in method from Password Hash Sync to AD FS, Password Hash Sync was not disabled.
Added verification for IPv6 addresses in AD FS configuration
Updated the notification message to inform that an existing configuration exists.
Device writeback fails to detect container in untrusted forest. This has been updated to provide a better error message and a link to the appropriate documentation
Deselecting an OU and then synchronization/writeback corresponding to that OU gives a generic sync error. This has been changed to create a more understandable error message

–

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

–

Cheers,
Jorge

Posted in Azure AD Connect | Leave a Comment »

(2018-07-22) Azure AD Connect v1.1.819.0 Has Been Released

Posted by Jorge on 2018-07-22

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.

–

–

1.1.819.0

Released: 5/14/2018

Released for auto upgrade and download

–

–