Jorge&#039;s Quest For Knowledge!

1.1.561.0

Released: 2017 July

–

–

Download "Microsoft Azure Active Directory 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/ ###################
————————————————————————————————————————————————————-

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

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

Posted by Jorge on 2017-07-05

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.557.0

Released: 2017 July

–

–

Download "Microsoft Azure Active Directory Connect"

–

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

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

(2017-06-28) Azure AD Connect Wizard Chooses To Sync All Instead Of Already Selected OUs/Domains

Posted by Jorge on 2017-06-28

After upgrading to the latest version of AAD Connect, at the time of writing that was v1.1.553.0 as described here, I ran the AAD Connect wizard to enable an option that I wanted to try.

While going through the wizard I noticed that the wizard by default chose the option “Sync All Domains An OUs” instead of the option “Sync Selected Domains And OUs”. In my opinion it should have selected the last option as THAT was what I had configured previously including the selected domains and OUs.

Figure 1: AAD Connect Wizard Selecting The Option “Sync All Domains And OUs”

–

So, how do you solve this? Just reselect the option “Sync Selected Domains And OUs” and all your previous selected domains and OUs that you selected previously are reselected again

Figure 2: Fixing The Default Selection Of The AAD Connect Wizard With The Selection Of The Option “Sync Selected Domains And OUs”

–

Prior to version v1.1.524.0 you had to use the Synchronization Service Manager if you did not want to have OUs in the root of the domain to be automatically selected for sync. With v1.1.524.0 and later you can also use the AAD Connect wizard to not have OUs in the root of the domain to be automatically selected. This corresponds to the following issue fixed in v1.1.524.0:

To configure OU filtering, you can either use the Azure AD Connect wizard or the Synchronization Service Manager. Previously, if you use the Azure AD Connect wizard to configure OU filtering, new OUs created afterwards are included for directory synchronization. If you do not want new OUs to be included, you must configure OU filtering using the Synchronization Service Manager. Now, you can achieve the same behavior using Azure AD Connect wizard.

So if with the introduction with version v1.1.524.0 you also unselected the domains as shown below and now you run the wizard and see the domains being selected again, you will need to fix this yourself. The fix is quite easy. Do not selected any of the domains, just expand and re-collapse each of the domains. You will see the checkmark will disappear

Figure 3: Fixing The Default Selection Of The AAD Connect Wizard Of Each AD Domain Being Checked With The Unchecking Of Each AD Domain

–

Cheers,
Jorge

Posted in Azure AD Connect, Windows Azure Active Directory | 2 Comments »

(2017-06-28) AAD Connect Versions Prior To v1.1.553.0 Have A Vulnerability That May Affect You

Posted by Jorge on 2017-06-28

Executive Summary

Microsoft is releasing this security advisory to inform customers that a new version of Azure Active Directory (AD) Connect is available that addresses an Important security vulnerability.

The update addresses a vulnerability that could allow elevation of privilege if Azure AD Connect Password writeback is misconfigured during enablement. An attacker who successfully exploited this vulnerability could reset passwords and gain unauthorized access to arbitrary on-premises AD privileged user accounts.

The issue is addressed in the latest version (1.1.553.0) of Azure AD Connect by not allowing arbitrary password reset to on-premises AD privileged user accounts.

–

Advisory Details

Password writeback is a component of Azure AD Connect. It allows users to configure Azure AD to write passwords back to their on-premises Active Directory. It provides a convenient cloud-based way for users to reset their on-premises passwords wherever they are. For information about password writeback, refer to Password writeback overview.

To enable Password writeback, Azure AD Connect must be granted Reset Password permission over the on-premises AD user accounts. When setting up the permission, an on-premises AD Administrator may have inadvertently granted Azure AD Connect with Reset Password permission over on-premises AD privileged accounts (including Enterprise and Domain Administrator accounts). For information about AD privileged user accounts, refer to Protected Accounts and Groups in Active Directory.

This configuration is not recommended because it allows a malicious Azure AD Administrator to reset the password of an arbitrary on-premises AD user privileged account to a known password value using Password writeback. This in turn allows the malicious Azure AD Administrator to gain privileged access to the customer’s on-premises AD.

See CVE-2017-8613 – Azure AD Connect Elevation of Privilege Vulnerability

–

More Information:

Microsoft Security Advisory 4033453 – Vulnerability in Azure AD Connect Could Allow Elevation of Privilege

–

If this affects you, update to the newest version of AAD Connect ASAP!

–

Cheers,
Jorge

Posted in Azure AD Connect, Windows Azure Active Directory | 1 Comment »

(2017-06-28) Azure AD Connect v1.1.553.0 Has Been Released

Posted by Jorge on 2017-06-28

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.553.0

Released: 2017 June

–

–

Download "Microsoft Azure Active Directory Connect"

–

Fixed issues:

Azure AD Connect sync

Fixed an issue with Password writeback that allows an Azure AD Administrator to reset the password of an on-premises AD privileged user account. The issue occurs when Azure AD Connect is granted the Reset Password permission over the privileged account. The issue is addressed in this version of Azure AD Connect by not allowing an Azure AD Administrator to reset the password of an arbitrary on-premises AD privileged user account unless the administrator is the owner of that account. For more information, refer to Security Advisory 4033453.
Fixed an issue related to the msDS-ConsistencyGuid as Source Anchor feature where Azure AD Connect does not writeback to on-premises AD msDS-ConsistencyGuid attribute. The issue occurs when there are multiple on-premises AD forests added to Azure AD Connect and the User identities exist across multiple directories option is selected. When such configuration is used, the resultant synchronization rules do not populate the sourceAnchorBinary attribute in the Metaverse. The sourceAnchorBinary attribute is used as the source attribute for msDS-ConsistencyGuid attribute. As a result, writeback to the ms-DSConsistencyGuid attribute does not occur. To fix the issue, following sync rules have been updated to ensure that the sourceAnchorBinary attribute in the Metaverse is always populated

In from AD – InetOrgPerson AccountEnabled.xml
In from AD – InetOrgPerson Common.xml
In from AD – User AccountEnabled.xml
In from AD – User Common.xml
In from AD – User Join SOAInAAD.xm

Previously, even if the msDS-ConsistencyGuid as Source Anchor feature isn’t enabled, the “Out to AD – User ImmutableId” synchronization rule is still added to Azure AD Connect. The effect is benign and does not cause writeback of msDS-ConsistencyGuid attribute to occur. To avoid confusion, logic has been added to ensure that the sync rule is only added when the feature is enabled
Fixed an issue that caused password hash synchronization to fail with error event 611. This issue occurs after one or more domain controllers have been removed from on-premises AD. At the end of each password synchronization cycle, the synchronization cookie issued by on-premises AD contains Invocation IDs of the removed domain controllers with USN (Update Sequence Number) value of 0. The Password Synchronization Manager is unable to persist synchronization cookie containing USN value of 0 and fails with error event 611. During the next synchronization cycle, the Password Synchronization Manager reuses the last persisted synchronization cookie that does not contain USN value of 0. This causes the same password changes to be resynchronized. With this fix, the Password Synchronization Manager persists the synchronization cookie correctly
Previously, even if Automatic Upgrade has been disabled using the Set-ADSyncAutoUpgrade cmdlet, the Automatic Upgrade process continues to check for upgrade periodically, and relies on the downloaded installer to honor disablement. With this fix, the Automatic Upgrade process no longer checks for upgrade periodically. The fix is automatically applied when upgrade installer for this Azure AD Connect version is executed once.

–

AD FS management

Following URLs are new WS-Federation endpoints introduced by Azure AD to improve resiliency against authentication outage and will be added to on-premises AD FS replying party trust configuration:

Fixed an issue that caused AD FS to generate incorrect claim value for IssuerID. The issue occurs if there are multiple verified domains in the Azure AD tenant and the domain suffix of the userPrincipalName attribute used to generate the IssuerID claim is at least 3-levels deep (for example, johndoe@us.contoso.com). The issue is resolved by updating the regex used by the claim rules.

–

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

Previously, the msDS-ConsistencyGuid as Source Anchor feature was available to new deployments only. Now, it is available to existing deployments. More specifically

To access the feature, start the Azure AD Connect wizard and choose the Update Source Anchor option.
This option is only visible to existing deployments that are using objectGuid as sourceAnchor attribute.
When configuring the option, the wizard validates the state of the msDS-ConsistencyGuid attribute in your on-premises Active Directory. If the attribute isn’t configured on any user object in the directory, the wizard uses the msDS-ConsistencyGuid as the sourceAnchor attribute. If the attribute is configured on one or more user objects in the directory, the wizard concludes the attribute is being used by other applications and is not suitable as sourceAnchor attribute and does not permit the Source Anchor change to proceed. If you are certain that the attribute isn’t used by existing applications, you need to contact Support for information on how to suppress the error.

Specific to userCertificate attribute on Device objects, Azure AD Connect now looks for certificates values required for Connecting domain-joined devices to Azure AD for Windows 10 experience and filters out the rest before synchronizing to Azure AD. To enable this behavior, the out-of-box sync rule “Out to AAD – Device Join SOAInAD” has been updated.
Azure AD Connect now supports writeback of Exchange Online cloudPublicDelegates attribute to on-premises AD publicDelegates attribute. This enables the scenario where an Exchange Online mailbox can be granted SendOnBehalfTo rights to users with on-premises Exchange mailbox. To support this feature, a new out-of-box sync rule “Out to AD – User Exchange Hybrid PublicDelegates writeback” has been added. This sync rule is only added to Azure AD Connect when Exchange Hybrid feature is enabled.
Azure AD Connect now supports synchronizing the altRecipient attribute from Azure AD. To support this change, following out-of-box sync rules have been updated to include the required attribute flow:

In from AD – User Exchange
Out to AAD – User ExchangeOnline

The cloudSOAExchMailbox attribute in the Metaverse indicates whether a given user has Exchange Online mailbox or not. Its definition has been updated to include additional Exchange Online RecipientDisplayTypes as such Equipment and Conference Room mailboxes. To enable this change, the definition of the cloudSOAExchMailbox attribute, which is found under out-of-box sync rule “In from AAD – User Exchange Hybrid”, has been updated

from:

CBool(IIF(IsNullOrEmpty([cloudMSExchRecipientDisplayType]),NULL,BitAnd([cloudMSExchRecipientDisplayType],&HFF) = 0))

CBool(
IIF(IsPresent([cloudMSExchRecipientDisplayType]),(
    IIF([cloudMSExchRecipientDisplayType]=0,True,(
      IIF([cloudMSExchRecipientDisplayType]=2,True,(
        IIF([cloudMSExchRecipientDisplayType]=7,True,(
          IIF([cloudMSExchRecipientDisplayType]=8,True,(
            IIF([cloudMSExchRecipientDisplayType]=10,True,(
              IIF([cloudMSExchRecipientDisplayType]=16,True,(
                IIF([cloudMSExchRecipientDisplayType]=17,True,(
                  IIF([cloudMSExchRecipientDisplayType]=18,True,(
                     IIF([cloudMSExchRecipientDisplayType]=1073741824,True,(
                        IF([cloudMSExchRecipientDisplayType]=1073741840,True,False)))))))))))))))))))),False))

Added the following set of X509Certificate2-compatible functions for creating synchronization rule expressions to handle certificate values in the userCertificate attribute:

CertSubject, CertIssuer, CertKeyAlgorithm, CertSubjectNameDN, CertIssuerOid, CertNameInfo, CertSubjectNameOid, CertIssuerDN, IsCert, CertFriendlyName, CertThumbprint, CertExtensionOids, CertFormat, CertNotAfter, CertPublicKeyOid, CertSerialNumber, CertNotBefore, CertPublicKeyParametersOid, CertVersion, CertSignatureAlgorithmOid, Select, CertKeyAlgorithmParams, CertHashString, Where, With

Following schema changes have been introduced to allow customers to create custom synchronization rules to flow sAMAccountName, domainNetBios, and domainFQDN for Group objects, as well as distinguishedName for User objects:

Following attributes have been added to MV schema:

Group: AccountName
Group: domainNetBios
Group: domainFQDN
Person: distinguishedName

Following attributes have been added to Azure AD Connector schema:

Group: OnPremisesSamAccountName
Group: NetBiosName
Group: DnsDomainName
User: OnPremisesDistinguishedName

The ADSyncDomainJoinedComputerSync cmdlet script now has a new optional parameter named AzureEnvironment. The parameter is used to specify which region the corresponding Azure Active Directory tenant is hosted in. Valid values include:

AzureCloud (default)
AzureChinaCloud
AzureGermanyCloud
USGovernment

Updated Sync Rule Editor to use Join (instead of Provision) as the default value of link type during sync rule creation.

–

ADFS Management

Previously, the ADFS Certificate Management feature provided by Azure AD Connect can only be used with ADFS farms managed through Azure AD Connect. Now, you can use the feature with ADFS farms that are not managed using Azure AD Connect.

–

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

–

Cheers,
Jorge

Posted in Azure AD Connect, Windows Azure Active Directory | 2 Comments »

(2017-06-23) Adding A Link To The SSPR Page In The ADFS FBA Page

Posted by Jorge on 2017-06-23

When users use Windows Integrated Authentication against ADFS through their Windows desktop/laptop the users are authenticated based upon the credentials they used to logon with onto that Windows desktop.laptop. If those users needed to reset their password or unlock their account, a link would need to be provided within the logon screen to point to the SSPR page or users would need to use some kind of kiosk PC.

However, when hitting the Forms Based Authentication page within ADFS, it would be nice if you could display a link on that same page if users needed to reset their password or unlock their account when for example on a mobile device. Something similar to the following:

Figure 1: A Link To The SSPR Page On The FBA Page

–

If you want to do this, you can use the following steps

[Step 1]

Clone the current active ADFS web theme to a new ADFS web theme

First determine the current web theme

Get-ADFSWebConfig

Clone the current active web theme to a new web theme

New-AdfsWebTheme -Name <New Web Theme Name> -SourceName <Active Web Theme Name>

–

[Step 2]

Export the cloned web theme to a folder on the file system

Export-AdfsWebTheme -Name <New Web Theme Name> -DirectoryPath <Some Folder On The File System>

–

[Step 3]

Edit the file “onload.js” in the folder “<Some Folder On The File System>\Script” and add the following piece of code to the end of the file to show the link to the SSPR page in AAD on the FBA page (NOTE: you can use any other SSPR page if you want, such as the FIM/MIM SSPR page)

// Add link for password reset, if we find the forms authentication element in the page
var formsAuthArea = document.getElementById("formsAuthenticationArea");
if (formsAuthArea) {
    //Create the hyperlink
    var pwdResetLink = document.createElement(‘a’);
    var linkText = document.createTextNode("Click Here For Password Reset Or Account Unlock");
    pwdResetLink.appendChild(linkText);
    pwdResetLink.title = "Click Here For Password Reset Or Account Unlock";
    pwdResetLink.href = "";’>";’>https://passwordreset.microsoftonline.com/?whr=<Your Domain In AAD>";
    pwdResetLink.target = "_blank";
    document.body.appendChild(pwdResetLink);

    //append to the authArea
    var authNArea = document.getElementById("authArea");
    authNArea.appendChild(pwdResetLink);
}

–

[Step 4]

Import the new edited “onload.js” file

Set-AdfsWebTheme -TargetName <New Web Theme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Some Folder On The File System>\script\onload.js"}

–

[Step 5]

Activate the new web theme

Set-AdfsWebConfig -ActiveThemeName <New Web Theme Name>

–

Now access an application and make sure to use the FBA page. The FBA page is used when coming from a mobile device on an external network or when not using WIA

–

Cheers,
Jorge

Posted in Active Directory Federation Services (ADFS), Forefront Identity Manager (FIM) Portal, Forms Based AuthN, Self Service Password Reset, Self-Service Password Reset, Windows Azure Active Directory | Leave a Comment »

(2017-06-19) Azure AD Connect Health For Sync To The Rescue

Posted by Jorge on 2017-06-19

I was playing around with some Azure AD (AAD) features and I required a new synched account in AAD. So I picked one of my existing accounts in the on-premises AD and added the user account to the groups that allowed it to sync to Azure AD, assign it a license for O365, assign a license for EMS and allow it to use SSPR. Instead of waiting for the next sync cycle I decided to force a delta sync within AAD Connect. So far so good. While AAD Connect was synching I decided to prepare some other things.

To my surprise I saw the following error in AAD Connect

Figure 1: Error In AAD Connect About “AttributeValueMustBeUnique”

–

Clicking on [Detail] I saw the following details regarding the error

Figure 2: Error Details In AAD Connect About “AttributeValueMustBeUnique”

–

ERROR = AttributeValueMustBeUnique
Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:John.Doe@XXXXX;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.
Tracking Id: xxxxxxxxxxxxxxxxxxxxxxxxxx
ExtraErrorDetails:
[{"Key":"ObjectId","Value":["xxxxxxxxxxxxxxxxxxxxxxxxx"]},{"Key":"ObjectIdInConflict","Value":["yyyyyyyyyyyyyyyyyyyyyy"]},{"Key":"AttributeConflictName","Value":["ProxyAddresses"]},{"Key":"AttributeConflictValues","Value":["SMTP:John.Doe@XXXXX"]}]

–

This is basically saying there is another object in AAD with the same value of "SMTP:John.Doe@XXXXX" in the proxyAddresses attribute

–

Now that was weird because the object with UPN ‘John.Doe@XXXXX’ was never synched to AAD as a user. To be sure I checked if there already was a user with the same UPN and/or proxyAddresses. As I expected there was none. I also knew for sure there was no conflicting object in the on-premises AD. Nevertheless I checked it with ADFIND (instead of PowerShell because hadn’t used for quite some time!). And again as expected there was none! So what the heck is going on!?

–

First I will tell you what was wrong and why, and after that I will guide you through troubleshooting

–

At this point in time I’m always using AAD Connect to sync stuff from AD to AAD. I also have a MIM Infrastructure using the AAD connector that also syncs stuff from AD to AAD and more specifically users, groups and contacts. However I had not used that for quite some time. What I had forgotten was that in the past I synched my mailbox enabled user accounts to AAD (Office 365) as contacts. So almost all on-premises users exist as contacts in AAD.

–

Definition of the issue:

Somewhere in the past, MIM synched user ‘John.Doe@XXXXX’ as contact to AAD
Now I wanted to sync user ‘John.Doe@XXXXX’ as user to AAD using AAD Connect

–

The error in figure 2 is misleading as it is telling me to check my on-premises AD to resolve the conflict, but there is NO conflict in my on-premises AD!

Just to be sure I used:

ADFIND/PowerShell to query for any object with the same UPN value or the same proxyAddress value – Only 1 object was returned which was expected
IDFIX to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected
Directory Synchronization Troubleshooter to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected

–

Now it was time to check AAD. It had to be in AAD somewhere, but what was causing it!? I was looking at all troubleshooting capabilities.

–

I found the following blog posts that ONLY focus on user accounts in AAD

–

Looking at the error in figure 2:

“ObjectId” contains the objectID of the object I was trying to sync to AAD
“ObjectIdInConflict” contains the objectID of the object already in AAD with which the conflict was being caused

Therefore I needed to query AAD using the objectID in “ObjectIdInConflict”. I decided to use the CMDlets in the MSONLINE module

To look for users in AAD with that same objectID, I executed:

Get-MsolUser -ObjectId <objectid value in “ObjectIdInConflict”>

No result

–

To look for groups in AAD with that same objectID, I executed:

Get-MsolGroup -ObjectId <objectid value in “ObjectIdInConflict”>

No result

–

I suddenly remembered about my MIM infrastructure and what it was synching, so I decided to also execute:

Get-MsolContact -ObjectId <objectid value in “ObjectIdInConflict”>

Bingo! One object was returned! Yeah!

–

Now I do not have many objects. Howeverm if you do have many object, this might take quite some time as unfortunately the MSONLINE module does not have a CMDlet like ‘Get-MsolObject’. However, the AzureAD module does have such a CMDlet that allows you to search across object types, being:

Get-AzureADObjectByObjectId -ObjectIds <objectid value in “ObjectIdInConflict”>

Again, Bingo! One object was returned! Yeah!

–

I also received the following e-mail telling me about the conflict. To be honest, the mail is not really helpful from an informational perspective. It is however from a warning perspective. With the latter I mean it triggers me to go look in Azure AD Connect Health, which will tell me what is wrong and why.

Figure 3: Mail From AAD Telling Me About the Conflict Error

–

Another option for troubleshooting this is Azure AD Connect Health for Sync. Trust me when I say that Azure AD Connect Health tells what is wrong and why. It showed me the sync error including all the specifics around the error in one view. Really really helpful! Let’s have a look at this!

Go to the Azure AD Portal (https://portal.azure.com/) and then go to the Azure AD Connect Health blade. In my case I have Azure AD Connect Health for Sync, ADFS and AD. So should you!. Make it easy on yourself!

Although Azure AD Connect Sync tile so as healthy, to its left, does tell you there is a sync error. Click on that tile.

Figure 4: Azure AD Connect Health In The Azure AD Portal

–

A new window opens with all the sync errors by type. In this case it is about the “Duplicate Attribute” issue. I clicked on that tile

Figure 5: Azure AD Connect Health For Sync With Errors By Type

–

A new window opens with all the sync errors about “Duplicate Attributes”. In my case I had and saw an error about a duplicate value in the proxyAddresses attribute. I clicked on the listed object.

Figure 6: Azure AD Connect Health For Sync With A “Duplicate Attribute” Error For An Object

–

A new window opens with all the details about the “Duplicate Attribute” conflict and the objects involved. At the bottom you can see the conflicting attribute and the conflicting value. Now I know I have to get rid of the contact object to make it possible for the user account in AD to get a corresponding user account in AAD.

Figure 7: Azure AD Connect Health For Sync With “Duplicate Attribute” Error Details

–

BINGO!!! Smile

–

Now my suggestion for this is:

Make sure to get Azure AD Connect Health up and running
As soon as you see an error in AAD Connect (figure 1 and 2) or receive the e-mail (figure 3) about it, make sure to read it carefully. At this point in time I would say to go right away to the Azure AD Connect Health blade in the Azure AD Portal and check there what could be wrong. It is very likely it will tell you what is wrong and why!

–

Additional information:

–

Cheers,
Jorge

Posted in Azure AD Connect, Azure AD Connect Health, PowerShell, Windows Azure Active Directory | 1 Comment »

(2017-05-27) Real Required Permissions For Password Change, Password Reset And Account Unlock Through Azure AD

Posted by Jorge on 2017-05-27

When deploying Azure AD Self-Service Password/Account Management you need to configure stuff in both Azure AD and the on-premises AD. The “what” and the “how” can be found through Azure AD self-service password reset for the IT professional.

–

In the on-premises AD you need to assign a number of permissions to the account for the connector/MA that services that specific AD. You will need to do this for every AD forest being serviced by AAD Connect. For every AD forest you need to determine the scope of management being either at domain level of OU level. Nevertheless, the following actions are supported by Azure AD Self-Service Password/Account Management and according to Microsoft the corresponding permissions need to be assigned to the connector/MA account (as listed here):

Account Unlock

Requires at least the Allow:Write permission for the lockoutTime attribute on the user account

Password Reset

Requires at least the Allow:Write permission for the pwdLastSet attribute on the targeted user account
Requires at least the Allow:Reset Password Control Access Right (CAR) on the targeted user account

Password Change

Requires at least the Allow:Change Password Control Access Right (CAR) on the targeted user account

–

The permissions can be configured through the GUI in ADUC/ADAC or through DSACLS. For regular accounts the permissions need to be assigned at container level (domain or specific OUs) and must be inherited by user objects.

The “Allow:Write permission for the lockoutTime attribute on the user account” for regular accounts can be configured through:

DSACLS "<DN of OU>" /G "<AD Group For Account Unlock>:WP;lockoutTime;user" /I:S

–

The “Allow:Write permission for the pwdLastSet attribute on the targeted user account” for regular accounts can be configured through:

DSACLS "<DN of OU>" /G "<AD Group For Password Reset>:WP;pwdLastSet;user" /I:S

–

The “Allow:Reset Password Control Access Right (CAR) on the targeted user account” for regular accounts can be configured through:

DSACLS "<DN of OU>" /G "<AD Group For Password Reset>:CA;Reset Password;user" /I:S

–

The “Allow:Change Password Control Access Right (CAR) on the targeted user account” for regular accounts can be configured through:

….does NOT need to be configured at all as the password change action always occurs under the context of the account for which the password is being changed. For that to be possible, AD already has the needed permissions in place for this to be possible as shown below!

Figure 1: The “Allow:Change Password” Permission Already Assigned By Default To The EVERYONE And SELF Security Principals

–

Therefore: There is NO NEED to specifically assign “Allow:Change Password Control Access Right (CAR) on the targeted user account” for the connector/MA account. It will work perfectly without it!

–

The exact same permissions are required on “protected” accounts. However, the permissions for those accounts need to be assigned through the adminSDHolder object. The permissions can be configured through the GUI in ADUC/ADAC or through DSACLS.

The “Allow:Write permission for the lockoutTime attribute on the user account” for protected accounts can be configured through:

DSACLS "CN=AdminSDHolder,CN=System,<DN Of Domain>" /G "<AD Group For Account Unlock>:WP;lockoutTime;user"

–

The “Allow:Write permission for the pwdLastSet attribute on the targeted user account” for protected accounts can be configured through:

DSACLS "CN=AdminSDHolder,CN=System,<DN Of Domain>" /G "<AD Group For Password Reset>:WP;pwdLastSet;user"

–

The “Allow:Reset Password Control Access Right (CAR) on the targeted user account” for protected accounts can be configured through:

DSACLS "CN=AdminSDHolder,CN=System,<DN Of Domain>" /G "<AD Group For Password Reset>:CA;Reset Password;user"

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Self-Service Password Reset, Windows Azure Active Directory | Leave a Comment »

(2017-05-17) Azure AD MFA Server v7.3.0.3 Has Been Released

Posted by Jorge on 2017-05-17

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.

–

Release notes: https://pfweb.phonefactor.net/install/7.3.0.3/release_notes.txt

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

AD FS adapter performance improvements
Tags performance improvements
Log request IDs to allow correlation with backend logs
Modified AD sync service to clear phone numbers that are cleared in the directory
Fix for RADIUS one-way text message fallback to OATH token
Fix for passwords that contain leading or trailing spaces
Fix AD FS adapter to handle cultures that aren’t associated with a locale ID
Change mobile app references from Azure Authenticator to Microsoft Authenticator

–

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 AD FS adapter
All other features and components are backwards-compatible with all previous versions

–

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++ 2015 Update 3 Redistribution packages are also available (x86, x64),

–

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>

–

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=7.3.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>"

–

Posted in Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2017-05-16) Azure AD Connect v1.1.524.0 Has Been Released

Posted by Jorge on 2017-05-16

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.524.0

Released: 2017 May

–

–