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!

(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-21) Back On Stage Again After A Few Years – Hybrid ID Conference In New York

Posted by Jorge on 2017-07-21


Some things in life are too much fun to not do it. An example of such occasion is presenting at a conference. The people at Semperis and sdmsoftware contacted me if I wanted to present at the Hybrid ID conference in New York next November. Jeez, that’s a difficult question to answer! Smile

Heck YES! Want to know more? Have a look at http://hipconf.com/ for the speaker list and the topics presented. Hope to see you there!

People that I worked with in the past, also presenting are:

It looks almost like a family reunion! Smile

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 Conferences | 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-06-15) Displaying The Welcome Message On The MFA Page In ADFS 2016

Posted by Jorge on 2017-06-15


In ADFS 2012 R2 when hitting the MFA page a welcome message was displayed with an explanation as shown in figure 1 below

image

Figure 1: MFA Page In ADFS 2012 R2 With The Default Value For The Name Claim Type

Looking at the default behavior in ADFS 2016 you will get the following instead

image

Figure 2: MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

There is no welcome message anymore and the identity value is now located in the explanation at the end.

If you want to revert back to the ADFS 2012 R2 behavior you can do the following:

[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 welcome message again

// Check if we are in the auth area
var authNArea = document.getElementById("authArea");
if (authNArea) {
    // if mfaGreeting element is present, modify its properties.
    var mfaGreeting = document.getElementById("mfaGreeting");
    if (mfaGreeting) {
        mfaGreeting.className = "fieldMargin bigText";
    }
}

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

[Step 6]

Reconfigure the explanation text if required

Set-AdfsGlobalWebContent -SignInPageAdditionalAuthenticationDescriptionText "For security reasons, we require additional information to verify your account"

Now access an application through ADFS for which MFA is required

If you did display the Welcome message and did not revert back to the explanation as shown in the ADFS 2012 R2 you would see something similar to

image

Figure 3: Customized MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

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), Azure AD MFA Adapter, Claim Types, onload.js | Leave a Comment »

(2017-06-12) Changing The Identity Type Displayed On The MFA Page In ADFS

Posted by Jorge on 2017-06-12


By default when you hit the MFA page in ADFS 2012 R2, the identity type displayed is similar to DOMAIN\SAMACCOUNTNAME as you can see in figure 1 below. The MFA page in ADFS 2012 R2 by default uses the value from the name claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”) to display that same value in the MFA page in ADFS 2012 R2.

The name claim type is configured by default in an Acceptance Transform Rule on the “Active Directory” CP trust, and it is most likely read from the “msDS-PrincipalName” attribute in AD.

The Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type may be similar to

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c);

image

Figure 1: MFA Page In ADFS 2012 R2 With The Default Value For The Name Claim Type

However, with all the cloud development going on and everything focusing on the mail address of a user instead, you may want to display the mail address of the user instead as displayed in figure 2 below.

To make this change you need to delete the default Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type and create a new rule where you will flow the value of the mail claim value (MAIL@ADDRESS.COM) into the name claim type. The new Acceptance Transform Rule on the “Active Directory” CP trust would look like:

@RuleTemplate = "MapClaims"
@RuleName = "E-mail Address To Name"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

image

Figure 2: MFA Page In ADFS 2012 R2 With The Custom Value For The Name Claim Type

Is there a catch to this? Yes there is, or better yes there are!

[Catch 1]

By default the e-mail address is NOT extracted from AD by ADFS! Because of that you need to create your own Acceptance Transform Rule where you do that. The Acceptance Transform Rule you need at least is or looks similar to:

@RuleTemplate = "LdapClaims"
@RuleName = "E-mail Address"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&quot;), query = ";mail;{0}", param = c.Value);

Because the name claim type depends on this Acceptance Transform Rule, this Acceptance Transform Rule for the mail claim type must be processed before the Acceptance Transform Rule for the name claim type

[Catch 2]

Some applications connected to ADFS may expect to receive a name claim value that looks like DOMAIN\SAMACCOUNTNAME instead of MAIL@ADDRESS.COM. By implementing the new Acceptance Transform Rule for the name claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the RP trust of the application that needs the name claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"%5D => issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Windows Account Name To Name"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

[Catch 3]

By default when you hit the MFA page in ADFS 2016, the identity type displayed is similar to UPN@ADDRESS.COM as you can see in figure 1 below. The MFA page in ADFS 2016 by default uses the value from the upn claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”) to display that same value in the MFA page in ADFS 2016. However, if there is no value for the upn claim, it will fall back to the value of the name claim. Unless you have removed it, by default ADFS has an Acceptance Transform Rule on the “Active Directory” CP trust for the upn claim type. And if you look carefully, the text also changed (compare figure 1 and figure 3).

As you can see in figure 3, it now really shows my upn (jorge@iamtec.net) whereas mail e-mail address uses a different suffix (jorge@iamtec.nl). With the use of Azure AD, the federated/managed domain in AAD is iamtec.nl and not iamtec.net.

image

Figure 3: MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

To be able to logon with the mail address I have 2 options, either update the userPrincipalName value to match the mail address value in AD or keep it as is and use the alternate logon ID feature in ADFS to target the mail address field in AD. If you choose the first option the value in the MFA page is also updated automatically and you do not need to update Acceptance Transform Rules. If you choose the second option you may need to delete the default Acceptance Transform Rule for the upn claim type and replace it with the following Acceptance Transform Rule:

@RuleTemplate = "MapClaims"
@RuleName = "E-Mail Address To UPN"

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

This new Acceptance Transform Rule for the upn claim type would result in the following for on the MFA page in ADFS 2016

image

Figure 4: MFA Page In ADFS 2016 With The Custom Value For The UPN Claim Type

Is there a catch to the catch? Unfortunately there is! As mentioned earlier for the name claim type, the same would apply to the upn clam type. Some applications connected to ADFS may expect to receive a upn claim value that looks like UPN@ADDRESS.COM instead of MAIL@ADDRESS.COM. By implementing a new Acceptance Transform Rule for the upn claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the “Active Directory” CP trust and implement an Acceptance Transform Rule that is similar to or looks like:

@RuleTemplate = "MapClaims"
@RuleName = "Original UPN To Custom UPN Claim"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(Type = "
http://temp.org/identity/claims/orgUPN&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

…and you would need reconfigure the RP trust of the application that needs the original upn claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Custom UPN Claim To Original UPN"
c:[Type == "http://temp.org/identity/claims/orgUPN""http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

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), Azure AD MFA Adapter, Claim Types, Claims, Claims Rule Language, Federation Trusts | Leave a Comment »

 
%d bloggers like this: