Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Windows Azure Active Directory’ Category

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

Posted by Jorge on 2017-08-14


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/ ###################
————————————————————————————————————————————————————-

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


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/ ###################
————————————————————————————————————————————————————-

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.

image

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

image

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

image

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

————————————————————————————————————————————————————-
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 | 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:

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

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 | 1 Comment »

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

Posted by Jorge on 2017-06-28


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

Released: 2017 June

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

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))

    • to:

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

————————————————————————————————————————————————————-
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 | 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:

image 

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

 

————————————————————————————————————————————————————-
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 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

image

Figure 1: Error In AAD Connect About “AttributeValueMustBeUnique”

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

image

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:

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.

image

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.

image

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

image

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.

image

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.

image

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

 

————————————————————————————————————————————————————-
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, 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!

image

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

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


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

Released: 2017 May

Prerequisites for Azure AD Connect

More information about Azure AD Connect

Fixed issues:

Azure AD Connect sync

  • Fixed an issue that causes Automatic Upgrade to occur on the Azure AD Connect server even if customer has disabled the feature using the Set-ADSyncAutoUpgrade cmdlet. With this fix, the Automatic Upgrade process on the server still checks for upgrade periodically, but the downloaded installer honors the Automatic Upgrade configuration.
  • During DirSync in-place upgrade, Azure AD Connect creates an Azure AD service account to be used by the Azure AD connector for synchronizing with Azure AD. After the account is created, Azure AD Connect authenticates with Azure AD using the account. Sometimes, authentication fails because of transient issues, which in turn causes DirSync in-place upgrade to fail with error “An error has occurred executing Configure AAD Sync task: AADSTS50034: To sign into this application, the account must be added to the xxx.onmicrosoft.com directory.” To improve the resiliency of DirSync upgrade, Azure AD Connect now retries the authentication step.
  • There was an issue with build 443 that causes DirSync in-place upgrade to succeed but run profiles required for directory synchronization are not created. Healing logic is included in this build of Azure AD Connect. When customer upgrades to this build, Azure AD Connect detects missing run profiles and creates them.
  • Fixed an issue that causes Password Synchronization process to fail to start with Event ID 6900 and error “An item with the same key has already been added”. This issue occurs if you update OU filtering configuration to include AD configuration partition. To fix this issue, Password Synchronization process now synchronizes password changes from AD domain partitions only. Non-domain partitions such as configuration partition are skipped.
  • During Express installation, Azure AD Connect creates an on-premises AD DS account to be used by the AD connector to communicate with on-premises AD. Previously, the account is created with the PASSWD_NOTREQD flag set on the user-Account-Control attribute and a random password is set on the account. Now, Azure AD Connect explicitly removes the PASSWD_NOTREQD flag after the password is set on the account.
  • Fixed an issue that causes DirSync upgrade to fail with error “a deadlock occurred in sql server which trying to acquire an application lock” when the mailNickname attribute is found in the on-premises AD schema, but is not bounded to the AD User object class.
  • Fixed an issue that causes Device writeback feature to automatically be disabled when an administrator is updating Azure AD Connect sync configuration using Azure AD Connect wizard. This is caused by the wizard performing pre-requisite check for the existing Device writeback configuration in on-premises AD and the check fails. The fix is to skip the check if Device writeback is already enabled previously.
  • 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.
  • Fixed an issue that causes stored procedures required by Azure AD Connect to be created under the schema of the installing admin, instead of under the dbo schema.
  • Fixed an issue that causes the TrackingId attribute returned by Azure AD to be omitted in the AAD Connect Server Event Logs. The issue occurs if Azure AD Connect receives a redirection message from Azure AD and Azure AD Connect is unable to connect to the endpoint provided. The TrackingId is used by Support Engineers to correlate with service side logs during troubleshooting.
  • When Azure AD Connect receives LargeObject error from Azure AD, Azure AD Connect generates an event with EventID 6941 and message “The provisioned object is too large. Trim the number of attribute values on this object.” At the same time, Azure AD Connect also generates a misleading event with EventID 6900 and message “Microsoft.Online.Coexistence.ProvisionRetryException: Unable to communicate with the Windows Azure Active Directory service.” To minimize confusion, Azure AD Connect no longer generates the latter event when LargeObject error is received.
  • Fixed an issue that causes the Synchronization Service Manager to become unresponsive when trying to update the configuration for Generic LDAP connector.

Known issues:

  • N.A. 

New features/Improvements:

Azure AD Connect sync

  • Sync Rule Changes – The following sync rule changes have been implemented:

    • Updated default sync rule set to not export attributes userCertificate and userSMIMECertificate if the attributes have more than 15 values.
    • AD attributes employeeID and msExchBypassModerationLink are now included in the default sync rule set.
    • AD attribute photo has been removed from default sync rule set.
    • Added preferredDataLocation to the Metaverse schema and AAD Connector schema. Customers who want to update either attributes in Azure AD can implement custom sync rules to do so. To find out more about the attribute, refer to article section Azure AD Connect sync: How to make a change to the default configuration – Enable synchronization of PreferredDataLocation.
    • Added userType to the Metaverse schema and AAD Connector schema. Customers who want to update either attributes in Azure AD can implement custom sync rules to do so.
  • Azure AD Connect now automatically enables the use of ConsistencyGuid attribute as the Source Anchor attribute for on-premises AD objects Further, Azure AD Connect populates the ConsistencyGuid attribute with the objectGuid attribute value if it is empty. This feature is applicable to new deployment only. To find out more about this feature, refer to article section Azure AD Connect: Design concepts – Using msDS-ConsistencyGuid as sourceAnchor.

  • New troubleshooting cmdlet Invoke-ADSyncDiagnostics has been added to help diagnose Password Hash Synchronization related issues.
  • Azure AD Connect now supports synchronizing Mail-Enabled Public Folder objects from on-premises AD to Azure AD. You can enable the feature using Azure AD Connect wizard under Optional Features.
  • Azure AD Connect requires AD DS accounts to synchronize from on-premises AD. Previously, if you install Azure AD Connect using Express mode, you can provide the credential of an Enterprise Admin account. Azure AD Connect and leave it to Azure AD Connect to create the AD DS account required. However, for custom installation and adding forests to existing deployment, you must provide the AD DS account instead. Now, you also have the option to provide the credentials of an Enterprise Admin account during custom installation and let Azure AD Connect create the AD DS account required.
  • Azure AD Connect now supports SQL AOA. You must enable SQL before installing Azure AD Connect. During installation, Azure AD Connect detects whether the SQL instance provided is enabled for SQL AOA or not. If SQL AOA is enabled, Azure AD Connect further figures out if SQL AOA is configured to use synchronous replication or asynchronous replication. When setting up the Availability Group Listener, it is recommended that you set the RegisterAllProvidersIP property to 0. This is because Azure AD Connect currently uses SQL Native Client to connect to SQL and SQL Native Client does not support the use of MultiSubNetFailover property.
  • If you are using LocalDB as the database for your Azure AD Connect server and has reached its 10-GB size limit, the Synchronization Service no longer starts. Previously, you need to perform ShrinkDatabase operation on the LocalDB to reclaim enough DB space for the Synchronization Service to start. After which, you can use the Synchronization Service Manager to delete run history to reclaim more DB space. Now, you can use Start-ADSyncPurgeRunHistory cmdlet to purge run history data from LocalDB to reclaim DB space. Further, this cmdlet supports an offline mode (by specifying the -offline parameter) which can be used when the Synchronization Service is not running. Note: The offline mode can only be used if the Synchronization Service is not running and the database used is LocalDB.
  • To reduce the amount of storage space required, Azure AD Connect now compresses sync error details before storing them in LocalDB/SQL databases. When upgrading from an older version of Azure AD Connect to this version, Azure AD Connect performs a one-time compression on existing sync error details.
  • Previously, after updating OU filtering configuration, you must manually run Full import to ensure existing objects are properly included/excluded from directory synchronization. Now, Azure AD Connect automatically triggers Full import during the next sync cycle. Further, Full import is only be applied to the AD connectors affected by the update. Note: this improvement is applicable to OU filtering updates made using the Azure AD Connect wizard only. It is not applicable to OU filtering update made using the Synchronization Service Manager.
  • Previously, Group-based filtering supports Users, Groups, and Contact objects only. Now, Group-based filtering also supports Computer objects.
  • Previously, you can delete Connector Space data without disabling Azure AD Connect sync scheduler. Now, the Synchronization Service Manager blocks the deletion of Connector Space data if it detects that the scheduler is enabled. Further, a warning is returned to inform customers about potential data loss if the Connector space data is deleted.
  • Previously, you must disable PowerShell transcription for Azure AD Connect wizard to run correctly. This issue is partially resolved. You can enable PowerShell transcription if you are using Azure AD Connect wizard to manage sync configuration. You must disable PowerShell transcription if you are using Azure AD Connect wizard to manage ADFS configuration.

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 yourself before using/implementing this!
* 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 »

 
%d bloggers like this: