(2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 4)

Part 3 can be found here

–

UPDATE 2016-12-15: With Windows Server 2016 a new attribute called “ms-DS-Source-Anchor” is introduced which could be used as the source for the immutable ID in Azure. Like the attribute I use myself, this attribute is a string attribute. Therefore, where you find the attribute “iamTECImmutableID” in the text, or “extensionAttribute15” could be replaced with “ms-DS-Source-Anchor”. Taken from the protocol documentation. As mentioned earlier, be very careful in using default attributes in the AD schema if its use is not clear.

The msDS-SourceAnchor attribute defines a unique, immutable identifier for the object in the authoritative directory.

cn: ms-DS-Source-Anchor

ldapDisplayName: msDS-SourceAnchor

attributeId: 1.2.840.113556.1.4.2352

attributeSyntax: 2.5.5.12

oMSyntax: 64

isSingleValued: TRUE

schemaIdGuid: b002f407-1340-41eb-bca0-bd7d938e25a9

systemOnly: FALSE

searchFlags: fPDNTATTINDEX | fPRESERVEONDELETE

systemFlags: FLAG_SCHEMA_BASE_OBJECT

rangeLower: 1

showInAdvancedViewOnly: TRUE

Version-Specific Behavior: Implemented on Windows Server 2016.

–

UPDATE 2017-05-16: With AAD Connect version 1.1.524.0 and higher, it 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.

–

After the installation wizard finishes, it is time to reconfigure synchronization rules. It is not supported to edit the default/built-in synchronization rules in any way, except disabling/enabling them. If you need to change a default/built-in synchronization rule, you will to clone it first, disable it, and then edit/configure the clone as required.

But, first of all… How to clone a sync rule?

After opening the Synchronization Rule Editor, you can click on a default/built-in synchronization rule and then click [EDIT].

You will see the following dialog box telling you to clone the default/built-in synchronization rule, disable it, and then edit/configure the clone as required.

Figure 1: AAD Connect Requesting To Clone A Built-In Synchronization Rule First To Become Editable

–

We are going to do this on a per object type.

–

We will start with the “person” object for inbound synchronization

Clone and disable the synchronization rule called “In from AD – User Join”.

While on the “Description” node:

• Assign the name “In from AD – User Join (Custom – <AD Forest FQDN>)” to the clone
• Assign the description “Cloned Sync Rule From ”In from AD – User Join”” to the clone
• Assign the precedence of 60
• With regards to configuring a tag, it apparently is not possible to do that right after cloning a synchronization rule. Finish the configuration of the rule, save it, export it to a PowerShell script, edit the script and add a tag and save the script, and rerun the script to update the cloned synchronization rule

Click on the “Join Rules” node:

If you are using a Unicode String Attribute, configure the join rules as followed (only taking the yellow marked parts into account)

Figure 2: Join Rules For The Cloned Synchronization Rule “In from AD – User Join (Custom – <AD Forest FQDN>)” When Using A Unicode String Attribute

–

If you are using a Octet String Attribute, configure the join rules as followed (only taking the yellow marked parts into account)

Figure 3: Join Rules For The Cloned Synchronization Rule “In from AD – User Join (Custom – <AD Forest FQDN>)” When Using An Octet String Attribute

–

The first yellow marked group (figure 2 and 3) is the first joining criteria which will apply during joining of an AD user object to the MV person object, or during provisioning of the MV person object if the AD attribute containing the source anchor was populated previously.

The second yellow marked group (figure 2 and 3) is the second joining criteria which will apply during provisioning of the MV person object while no value exist in the AD attribute with the purpose of the source anchor.

Click on the “Transformations” node:

Configure the yellow marked part to make sure the attribute listed is populated in the MV after provisioning

Figure 4: Transformation Rules For The Cloned Synchronization Rule “In from AD – User Join (Custom – <AD Forest FQDN>)””

–

The yellow marked transformation is to replace the default transformation that specifies as target attribute “sourceAnchorBinary”. You can just change the transformation my specifying the target attribute “sourceObjectGUIDBinary”. I prefer to use this attribute as it tells me this target attribute will contain the objectGUID in binary format of the source object that contributed the value. In addition, the target attribute will be used in the join rule of both the inbound synchronization rule from AD called “In from AD – User Join (Custom – <AD Forest FQDN>)” and the outbound synchronization rule to AD called “Out to AD – User Common (Custom – <AD Forest FQDN>)”.

–

This synchronization rule is now fully configured and therefore you can save it.

–

Clone and disable the synchronization rule called “In from AD – User AccountEnabled”.

While on the “Description” node:

• Assign the name “In from AD – User AccountEnabled (Custom – <AD Forest FQDN>)” to the clone
• Assign the description “Cloned Sync Rule From ‘In from AD – User AccountEnabled’” to the clone
• Assign the precedence of 62
• With regards to configuring a tag, it apparently is not possible to do that right after cloning a synchronization rule. Finish the configuration of the rule, save it, export it to a PowerShell script, edit the script and add a tag and save the script, and rerun the script to update the cloned synchronization rule

Click on the “Transformations” node:

Configure the yellow marked part to make sure the attribute listed is populated in the MV

If you are using a Unicode String Attribute, configure the transformation rules as followed (only taking the yellow marked parts into account)

Figure 5: Transformation Rules For The Cloned Synchronization Rule “In from AD – User AccountEnabled (Custom – <AD Forest FQDN>)””. When Using A Unicode String Attribute

–

For BOTH the target attribute “sourceAnchor” and the target attribute “extensionAtttribute15”, the source is:

IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([extensionAttribute15]),[extensionAttribute15],ConvertToBase64([objectGUID]))),IIF(IsPresent([extensionAttribute15]),[extensionAttribute15],ConvertToBase64([objectGUID])))

The expression can be better seen as:

IIF(

    IsPresent([msExchRecipientTypeDetails]),

    IIF(

        [msExchRecipientTypeDetails]=2,

        NULL,

        IIF(

            IsPresent([extensionAttribute15]),

            [extensionAttribute15],

            ConvertToBase64([objectGUID])

        )

   ),

   IIF(

       IsPresent([extensionAttribute15]),

       [extensionAttribute15],

       ConvertToBase64([objectGUID])

   )

)

–

If you are using a Octet String Attribute, configure the transformation rules as followed (only taking the yellow marked parts into account)

Figure 6: Transformation Rules For The Cloned Synchronization Rule “In from AD – User AccountEnabled (Custom – <AD Forest FQDN>)”. When Using An Octet String Attribute

–

For the target attribute “sourceAnchor”, the source is:

IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid]),ConvertToBase64([objectGUID]))),IIF(IsPresent([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid]),ConvertToBase64([objectGUID])))

The expression can be better seen as:

IIF(

    IsPresent([msExchRecipientTypeDetails]),

    IIF(

        [msExchRecipientTypeDetails]=2,

        NULL,

        IIF(

            IsPresent([mS-DS-ConsistencyGuid]),

            ConvertToBase64([mS-DS-ConsistencyGuid]),

            ConvertToBase64([objectGUID])

        )

   ),

   IIF(

       IsPresent([mS-DS-ConsistencyGuid]),

       ConvertToBase64([mS-DS-ConsistencyGuid]),

       ConvertToBase64([objectGUID])

   )

)

–

For the target attribute “mS-DS-ConsistencyGuid”, the source is:

IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])),IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID]))

The expression can be better seen as:

IIF(

    IsPresent([msExchRecipientTypeDetails]),

    IIF(

        [msExchRecipientTypeDetails]=2,

        NULL,

        IIF(

            IsPresent([mS-DS-ConsistencyGuid]),

            [mS-DS-ConsistencyGuid],

            [objectGUID]

        )

   ),

   IIF(

       IsPresent([mS-DS-ConsistencyGuid]),

       [mS-DS-ConsistencyGuid],

       [objectGUID]

   )

)

The first yellow marked transformation (figure 5 and 6) will flow the value from either “extensionAttribute15” or “mS-DS-ConsistencyGuid” (whichever you are using) to the “sourceAnchor” if a value already exists. If not, the objectGUID in base64 format will be used as the value.

The second yellow marked transformation (figure 5 and 6) will flow the value from either “extensionAttribute15” or “mS-DS-ConsistencyGuid” (whichever you are using) to respectively the “extensionAttribute15” or “mS-DS-ConsistencyGuid” (whichever you are using) if a value already exists. If not, the objectGUID in base64 format will be used as the value.

–

This synchronization rule is now fully configured and therefore you can save it.

–

Now we need to create a brand new synchronization rule for the “person” object so that the immutable ID value is written back to AD (outbound synchronization) in a manageable attribute of the user object.

REMARK: to AAD Connect to be able to write back the value, the account used in the AD connector must have Allow:Read/Write permissions on the user objects for which it is writing back a value into the chosen manageable attribute that will provide the immutable ID value. To configure the correct permissions you can use the following command:

DSACLS "\\<FQDN RWDC>\<distinguishedName of OU>" /G "<account used in the AD connector>:RPWP;<chosen immutable ID attribute>;user" /I:S

Create/add a new synchronization rule.

While on the “Description” node:

• Assign the name “Out to AD – User Common (Custom – <AD Forest FQDN>)”
• Assign the description “New Sync Rule”
• Assign as connected system the AD forest
• Assign as connected system object type: “user”
• Assign as metaverse object type: “person”
• Assign as link type: “Join”
• Assign the precedence of 250
• Assign the tag “<companyname>.OuttoADUserCommonCustom.001”
• Keep UNchecked “Enable Password Sync”
• Keep UNchecked “Disabled”

Click on the “Scoping Filter” node

If you are using a Unicode String Attribute, configure the scoping filter rules as follows

Figure 7: Scoping Filter Rules For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)” . When Using An Unicode String Attribute

–

If you are using a Octet String Attribute, configure the scoping filter rules as follows

Figure 8: Scoping Filter Rules For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”. When Using An Octet String Attribute

–

This synchronization rule becomes active on a person object in the MV after the listed attribute (figure 7 or 8) has been populated with a value

–

Click on the “Join Rules” node and configure the join rules as follows

Figure 9: Join Rules For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”

–

Click on the “Transformations” node

If you are using a Unicode String Attribute, configure the transformation rules as follows

Figure 10: Transformations For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”. When Using An Unicode String Attribute

–

If you are using a Octet String Attribute, configure the transformation rules as follows

Figure 11: Transformations For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”. When Using An Octet String Attribute

–

This synchronization rule is now fully configured and therefore you can save it.

–

Continue with part 5 here

–

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

(2014-11-05) Upgrading Azure AD Sync Services From GA (v1.0.419.911) To v1.0.470.1023

As mentioned in this blog post Microsoft released a new version of the Azure AD Sync Services. As mentioned in the release notes the upgrade is quite straightforward with a fix, but only if you modified one or more sync rules.

If you already have Azure AD Sync installed, there is one additional step you have to take in case you have changed any of the out-of-box Synchronization Rules. After you have upgraded to the 1.0.470.1023 release, the synchronization rules you have modified are duplicated. For each modified Sync Rule do the following:

• Locate the Sync Rule you have modified and take a note of the changes
• Delete the Sync Rule
• Locate the new Sync Rule created by Azure AD Sync and re-apply the changes.

–

So let’s try this and see what happens.

My starting point is the GA version

Figure 1: GA Version Of Azure AD Sync Services (AADSync)

–

Double-click on MicrosoftAzureADConnectionTool.exe and the following screen appears. Check the checkbox "I agree to the license terms" if you indeed do agree with the license terms. Click the [Upgrade] button to continue.

Figure 2: Initial Screen Of The Azure AD Sync Upgrade

–

The first thing the upgrade wizard tries to do is upgrade the Azure Active Directory Sign-in Assistance/Client, and then it will upgrade all other components. However, you might receive the following "error". If you do not see it, you’re good. therefore continue to figure 12.

Figure 3: Error About Upgrading The Azure Active Directory Sign-in Assistance/Client

–

As specified, go and look in the Application Event Log. Event ID 906 tells you to check a log file, so you should do so!

Figure 4: Error In The Application Event Log

–

You see another Event ID 906, and that’s not really helpful

Figure 5: Error In The Application Event Log

–

And yet you see another Event ID 906, and again that’s not really helpful. It just mentions the upgrade of the Azure Active Directory Sign-in Assistance/Client failed.

Figure 6: Error In The Application Event Log

–

System.Exception: Unable to upgrade the Azure Active Directory Sign-in Client.  Please see the event log for additional details. —> Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ProcessExecutionFailedException: Exception: Execution failed with errorCode: 1603.

Details:
   at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ProcessAdapter.StartProcessCore(String fileName, String arguments, String workingDirectory, NetworkCredential credential, Boolean loadUserProfile, Boolean hideWindow, Boolean waitForExit)
   at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ProcessAdapter.StartBackgroundProcessAndWaitForExit(String fileName, String arguments, String workingDirectory, NetworkCredential credential, Boolean loadUserProfile)
   at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.MsiExecAdapter.InstallMsiPackage(String msiPackageDirectory, String msiPackageFileName, String parametersString, String installationPath, NetworkCredential credential, String installLogFileName, Boolean quiet, Boolean suppressReboot)
   at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.MsiExecAdapter.InstallMsiPackageQuietSuppressReboot(String msiPackageDirectory, String msiPackageFileName, String parametersString, String installationPath, NetworkCredential credential, String installLogFileName)
   at Microsoft.Azure.ActiveDirectory.Synchronization.Setup.MsiSetupTaskBase.UpgradeCore()
   at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ActionExecutor.Execute(Action action, String description)
   at Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.Upgrade()
   — End of inner exception stack trace —
   at Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.ThrowSetupTaskFailureException(String exceptionFormatString, String taskName, Exception innerException)
   at Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.Upgrade()
   at Microsoft.Azure.ActiveDirectory.Synchronization.UserInterface.SetupAdapter.TypeDependencies.GenericDirectorySyncSetupUpgrade(String pathToSetupFiles, String installationPath, ProgressChangedEventHandler progressChangedEventHandler)
   at Microsoft.Azure.ActiveDirectory.Synchronization.UserInterface.UI.WizardPages.InstallOrUpgradePageViewModel.SetupTask(Object sender, DoWorkEventArgs args)
   at Microsoft.Azure.ActiveDirectory.Synchronization.UserInterface.UI.Controls.Wizards.ProgressReportingTaskViewModel.ExecuteAction(Action action, Boolean isProgressIndeterminate)

–

Finally looking in ‘C:\Windows\temp\AADSync\MsoIdCli_64_Install.log’ at point, almost in the end, you will see the following errors marked yellow. Basically it is saying that the repair failed. Why is it repairing instead of upgrading?

Figure 7: Error In The Log File About Repairing The Installation

–

The version of the Azure Active Directory Sign-in Assistance/Client in this AADSync package is v7.250.4556.0, and the version that I already had installed was also v7.250.4556.0. Because the versions are the same, it will not upgrade, but rather it will try to repair. On my test server, I have ADFS v3.0 and AADSync on the same server. A few days ago I updated the Azure AD PowerShell CMDlets including the Azure Active Directory Sign-in Assistance/Client. And that’s why I ended up with that version already installed.

The solution here is to go to the "Control Panel – Programs and Features" and uninstall the Azure Active Directory Sign-in Assistance/Client.

Figure 8: Uninstalling The Microsoft Online Services Sign-In Assistant (= Azure Active Directory Sign-in Assistance/Client)

–

Confirm the uninstall

Figure 9: Confirming Uninstalling The Microsoft Online Services Sign-In Assistant

–

When the uninstall is done, do not reboot the server as requested

Figure 10: Request To Reboot The Server

–

Now go back to the upgrade wizard and click the [Upgrade] button again.

Figure 11: Retrying The Upgrade

–

The upgrade will now continue. It will present the current credentials you are using to connect to Azure AD.

Figure 12: Credentials To Connect To Azure AD Tenant

–

Next it will present the current AD forest already connected. If you want to can connect extra AD forests, otherwise click the [Next] button.

Figure 13: AD Forests Already Connected To AADSync

–

Now, it presents you with the user matching configuration. You cannot change this right now, therefore click the [Next] button.

Figure 14: Previously Configured User Matching Options

–

Now, it presents you with optional features you can use. You can keep it AS-IS or you can enable what you need to enable. If you want to enable or disable optional feature, you just need to rerun the wizard.

[Exchange Hybrid Deployment] –> If you have an Exchange hybrid deployment, then select this checkbox. This will write-back some attributes from Exchange online to the on-premises Active Directory.

[Password Synchronization] –> With password synchronization, you enable your users to use the same password they are using to logon to your on-premises Active Directory to logon to Azure Active Directory. For more information on how to configure this, please see http://msdn.microsoft.com/en-us/library/azure/dn835016.aspx.

[Password Write-Back] –> Password write-back is an Azure Active Directory Premium feature. For more information on how to configure this, please see http://blogs.technet.com/b/ad/archive/2014/04/29/deep-dive-password-reset-with-on-premise-sync-in-azure-ad-premium.aspx.

[Azure AD App And Attribute Filtering] –> If you want to review or limit the attributes which are synchronized with Azure AD, then select Azure AD app and attribute filtering. You will then get two additional pages in the wizard. For more information on how to configure this, please see http://msdn.microsoft.com/en-us/library/azure/dn764938.aspx

Click the [Next] button.

Figure 15: Optional Features To Enable

–

Now it will present you with a summary screen. Click the [Next] button to really start the upgrade of the software.

Figure 16: Ready To Configure And Upgrade

–

After the upgrade you can choose to synchronize now or do it later as scheduled. Click the [Finish] button.

Figure 17: Finished

–

Figure 18: Upgraded Version Of Azure AD Sync Services (AADSync)

–

That’s all folks!

–

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

(2014-11-01) A New Version Of Azure Active Directory Sync Services Has Been Released (v1.0.470.1023)

A few days ago, Microsoft has released a new version of the Azure Active Directory Sync Services (AADSync)

–

This version adds the following features:

• Password synchronization from multiple on-premise AD to AAD
• Localized installation UI to all Windows Server languages

–

Upgrading from AADSync 1.0 GA

If you already have Azure AD Sync installed, there is one additional step you have to take in case you have changed any of the out-of-box Synchronization Rules. After you have upgraded to the 1.0.470.1023 release, the synchronization rules you have modified are duplicated. For each modified Sync Rule do the following:

• Locate the Sync Rule you have modified and take a note of the changes.
• Delete the Sync Rule.
• Locate the new Sync Rule created by Azure AD Sync and re-apply the changes.

–

Permissions for the AD account

The AD account must be granted additional permissions to be able to read the password hashes from AD. The permissions to grant are named “Replicating Directory Changes” and “Replicating Directory Changes All”. Both permissions are required to be able to read the password hashes.

–

Release Note: Changing the AD password

After password sync has been enabled, if the password of the account used by the AD Connector is changed through the UI then password synchronization must by disabled and re-enabled.

–

• Download: Microsoft Azure Active Directory Sync Services  v1.0.470.1023
• Documentation: Azure Active Directory Synchronization Services (AAD Sync)

–

More information:

• (2014-09-16) Azure Active Directory Sync Services Has Reached General Availability
• (2014-09-21) Change Install Of The Azure AD Sync Service Throws WMI Namespace Error
• (2014-09-23) Upgrading Azure AD Sync From The Beta Version To RTM

–

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

(2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365

When setting up DirSync And Federation between your on-premise AD and Windows Azure AD to support identity sync and SSO, the most important attribute to make sure everything works are the immutableID and the userPrincipalName.

–

Paul Williams from msresource.net has written a great number of blog posts about this, touching all kinds of related stuff. See the following blog posts:

• Multi-forest SSO to O365: implementing multiple immutable IDs
• Windows Azure Active Directory Connector part 1: when, where and why
• Windows Azure Active Directory Connector part 2: multi-forest directory synchronization
• Windows Azure Active Directory Connector part 3: immutable ID 
• Implementing Exchange Online with an existing on-premises identity management solution that provisions mailboxes

–

With regards to the implementation I used the string version of the objectGUID (AD) as the immutableID (sourceAnchor in AAD)) and the UPN as the userPrincipalName (AAD). I achieved that by leveraging FIM with the AAD connector. Because of that I also had to implement slighty different claims rules in ADFS for Azure AD/Office 365. The rules in my ADFS v2.0 looked like:

@RuleName = "Identity Claims – objectGUID (Base64) To objectGUID (String)"
c:[Type == "http://temp.org/identity/claims/adObjectGuidBase64org"]
=> add(store = "String Processing Store", types = ("http://temp.org/identity/claims/adObjectGuidString"), query = "fromBase64GuidtoStringGuid", param = c.Value);

@RuleName = "Identity Claims – upn To UPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN", Value = c.Value);

@RuleName = "Identity Claims – objectGUID (String) To ImmutableID"
c:[Type == "http://temp.org/identity/claims/adObjectGuidString"]
=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Identity Claims – ImmutableID To Name ID"
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

–

I swear everything was working, until some day I started to get the following errors:

….when navigating to: https://outlook.office365.com/owa/

Figure 1: Error When Using Federated Logon And Navigating To Office 365 Portal

–

….when navigating to: https://manage.windowsazure.com/default.aspx

Figure 2: Error When Using Federated Logon And Navigating To Azure AD Management Portal

–

….when navigating to: https://portal.office.com/

Figure 3: Error When Using Federated Logon And Navigating To Office 365 Management Portal

–

By giving the correlation ID to someone at Microsoft that is able to check it in the system logs, they most likely will be able to tell you what would be wrong. In this case unfortunately I as not able to do that. The logs on my system did not given me any clue!

As I have another ADFS v3.0 system in my environment, I therefore decided to configure that ADFS instance with all default values for DirSync and federation. After configuring all this, I was able to access Azure AD and Office 365 through federated logon on my ADFS v3.0 box, but still not on my ADFS v2.0.

–

After comparing the federation trusts between  ADFS v2.0 and Azure AD, and between ADFS v3.0 and Azure AD I saw the following difference:

Figure 4: Signature Hash Algorithm On The RP Trust On ADFS v3.0 For Azure AD/Office 365 (Default Config) – WORKING

–

Figure 5: Signature Hash Algorithm On The RP Trust On ADFS v2.0 For Azure AD/Office 365 (Custom Config) – NOT WORKING

–

For whatever reason, in the past I had changed the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 AND I had forgotten about it. It took me some time to find this one, but by just changing the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 from SHA-256 to SHA-1, everything started to work again! Yiiihhaaaaaa!

–

PS: this has NOTHING to do between the usage of ADFS v2.0 and ADFS v3.0. This was a configuration mistaken I made when playing around in the test/demo environment

–

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

(2014-09-25) Changing The Service Account And/Or Security Groups For Azure AD Sync Services

If you used the default configuration, you will end up with a local service account (e.g. AAD_fb304599ae39) for the Azure AD Sync Service and local security groups will be used (ADSyncAdmins, ADSyncOperators, ADSyncBrowse and ADSyncPasswordSet). This blog post helps you change either one, local service account or local security groups, or both to use domain objects. This blog post assumes you want to change both the service account and the security groups. In that case perform all steps. If you only want to change either one, then only perform the corresponding steps.

–

Step 1: Create the new Azure AD Sync Service service account in AD

Example: ADCORP\SVC_R1_AADSyncSvc

–

Step 2: Create the new Azure AD Sync Service security groups in AD

Example: ADCORP\AADSyncAdmins

Example: ADCORP\AADSyncOperators

Example: ADCORP\AADSyncBrowse

Example: ADCORP\AADSyncPasswordSet

–

Step 3: Establish correct memberships

Example: ADCORP\AADSyncAdmins <– make the Azure AD Sync Service service account in AD and any AD based user/admin account that fully manage the AAD Sync Service a member of this group

QUESTION: do you know which other group needed to be created in FIM, but is not needed anymore in AADSync?

–

Step 4: Configure the new Azure AD Sync Service service account in AD with the correct user rights on the server with Azure AD Sync Service installed

Give the new Azure AD Sync Service service account in AD the following user rights on the server with Azure AD Sync Service installed

“Deny logon as a batch job”

“Deny logon locally”

“Deny logon through Terminal Services”

“Deny access to this computer from the network”

Figure 1: Required User Rights For The New Azure AD Sync Service Service Account In AD

–

If you do not know the password of the current Azure AD Sync Service Service Account stop the "Microsoft Azure AD Sync (ADSync)" service, reset the password of the current Azure AD Sync Service Service Account, reenter credentials for the "Microsoft Azure AD Sync (ADSync)" service and start the "Microsoft Azure AD Sync (ADSync)" service.

Figure 2: Resetting The Password Of The Current (Local) Azure AD Sync Service Service Account

–

Figure 3: Re-Entering Credentials For The "Microsoft Azure AD Sync (ADSync)" Service

–

When changing the Azure AD Sync Service Service Account, the new Azure AD Sync Service Service Account must be configured with the encryption keys securing the secret data in the database. To be able to do that you must export the keyset, if not already available.

Figure 4: Exporting The KeySet Using The Azure ADSync Encryption Key Management Wizard

–

Figure 5: Providing The Credentials Of The Current (Local) Azure AD Sync Service Service Account

–

The default folder is: "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Azure AD Sync\" and make sure a existing keyset does not already exist with the same filename

Figure 6: Providing The Path Of The Encryption File

–

Figure 7: Configuration Summary

–

Figure 8: Configuration Result

–

Now it is time to start the change install

Figure 9: Starting The Change Install For Microsoft Azure AD Sync

–

Figure 10: Microsoft Azure AD Sync Maintenance Wizard – Welcome Page

–

Figure 11: Microsoft Azure AD Sync Maintenance Wizard – Maintenance Options Page

–

Figure 12: Microsoft Azure AD Sync Maintenance Wizard – Features Page

–

Figure 13: Microsoft Azure AD Sync Maintenance Wizard – Azure AD Sync Service Service Account Credentials Page

–

Figure 14: Microsoft Azure AD Sync Maintenance Wizard – Azure AD Sync Service Security Groups Page

–

Figure 15: Microsoft Azure AD Sync Maintenance Wizard – Initiating Install Page

–

If you did not configure the Azure AD Sync Service Service Account with the user rights as shown in figure 1, you will get the following warning.

Figure 16: Warning About Azure AD Sync Service Service Account Not Being Configured In Secure Manner

–

If you get the following error, make sure to check this blog post AFTER the wizard has finished!!!

Figure 17: Warning About Azure AD Sync Setup Not Being Able To Configure WMI Permissions On A Non-Existent Namespace

–

Figure 18: Restoring The Keyset For The New Azure AD Sync Service Service Account

–

Figure 19: Change Install Of Microsoft Azure AD Sync Setup Finished

–

And you’re done!

–

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

(2014-09-23) Upgrading Azure AD Sync From The Beta Version To RTM

In this blog post I will show you how to upgrade from the beta version of the Azure AD Sync Service to its RTM version. The method I’m showing here is most likely one of the ways of accomplishing this. Here I’m uninstalling the beta version and installing the RTM version. Most likely it is also possible to just perform a software upgrade by installing the RTM version on top of the beta version. I do not like software upgrades as you might always end up or keep stuff from the previous version which I do not want!

–

Because the installation of the Azure AD Sync Service also creates the local service account you must first determine the scenario and also do some preparations

–

If you are already using a domain based service account, then it is very likely you already know the password of that service account. If you are using the default local service account, then you need to reset its password. That is most likely needed because you do not know it as it was set by the installation. To determine which account type you are using use the services MMC and check the account listed in the "Log On As" for the "Microsoft Azure AD Sync" service. You are using a local service account if its listing starts with ".\AAD_"

If you are using a local service account perform this step, other wise skip this step.

Before resetting the password of the local service account, stop the "Microsoft Azure AD Sync" service first.

Figure 1: Using The Services MMC To Stop The "Microsoft Azure AD Sync" Service

–

Start the Computer Management MMC and target the local service account that starts with ".\AAD_"

Figure 2: Resetting The Password Of The Current (Local) Azure AD Sync Service Service Account

–

Then using the services MMC respecify the new password of the local service account. After doing that start the "Microsoft Azure AD Sync" Service again.

Figure 3: Re-Entering Credentials For The "Microsoft Azure AD Sync (ADSync)" Service

–

The Azure AD Sync Service wizard will create a new local Azure AD Sync Service Service Account, and that account must be configured with the encryption keys securing the secret data in the database. To be able to do that you must export the keyset first, if not already available.

Figure 4: Exporting The KeySet Using The Azure ADSync Encryption Key Management Wizard

–

Figure 5: Providing The Credentials Of The Current (Local) Azure AD Sync Service Service Account

–

The default folder is: "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Azure AD Sync\" and make sure a existing keyset does not already exist with the same filename

Figure 6: Providing The Path Of The Encryption File

–

Figure 7: Configuration Summary

–

Figure 8: Configuration Result

–

When you look in Programs And Features you will find the following software components, highlighted in yellow, that are part of the Azure AD Sync Service

Figure 9: Software Components That Are Part Of The Azure AD Sync Service

–

You may ask yourself, which one should be uninstalled first and in which order? One thing is certain, and that’s my experience, you will get into all kinds of errors during the uninstall and during the install of the new version. There it is very important to use the correct steps!

To uninstall everything in one go without errors you should uninstall the component called "Microsoft Azure AD Connection Tool"

Figure 10: Uninstalling The Main Component Of The Azure AD Sync Service

–

Figure 11: The Uninstall Wizard Of The Main Component Of The Azure AD Sync Service

–

When the uninstall has finished you can start the new installation by execution "MicrosoftAzureADConnectionTool.exe"

Figure 12: The Install Wizard Of The Main Component Of The Azure AD Sync Service

–

As soon as you see the screen above, CANCEL the installation by clicking the cross in the upper right corner. If you do not cancel the installation, it will be installed with all defaults, including SQL express.

After cancelling the installation, open a command prompt window and navigate to the folder "C:\Program Files\Microsoft Azure AD Connection Tool". You will need to execute "DirectorySyncTool.exe". It supports the following options:

DirectorySyncTool.exe /sqlserver <FQDN SQL Server> /sqlserverinstance <Custom SQL Instance Name If Applicable> /serviceAccountDomain <NetBIOS Domain Name Of Service Account> /serviceAccountName <sAMAccountName Of Service Account> /serviceAccountPassword <Password Of Service Account>

–

If this case I’m accepting all defaults accept that I want to use SQL server instead of SQL Express. To do that I execute the following command:

DirectorySyncTool.exe /sqlserver R1FSMBSV0.ADCORP.LAB /sqlserverinstance <Custom SQL Instance Name If Applicable>

REMARK: the SQL instance name should only be specified if it concerns a custom SQL instance. When using the default SQL instance name, do not use that parameter.

If you want to use the default SQL partition, then don’t specify this parameter.

Figure 13: Installing The Azure AD Sync Service And Using A SQL Server With The Default Instance Name

–

Figure 14: The Install Wizard Of The Main Component Of The Azure AD Sync Service

–

Agreeing with the license terms and clicking "Install" will install everything, while at the same time detecting the database of the previous version. When it uses the existing database, the remaining configuration options such as credentials, matching rules, etc. will be skipped as that is already in the database.

–

The installation has created a new local service account and to restore the keyset, or in other words reactivate the previous database, you to know the password of the service account in use.

Start the Computer Management MMC and target the local service account that starts with ".\AAD_"

Figure 15: Resetting The Password Of The Current (Local) Azure AD Sync Service Service Account

–

Then using the services MMC respecify the new password of the local service account. After doing that start the "Microsoft Azure AD Sync" Service again.

Figure 16: Re-Entering Credentials For The "Microsoft Azure AD Sync (ADSync)" Service

–

When starting the "Microsoft Azure AD Sync" Service without having restored the keyset, you will see the following errors.

Figure 17: Error Immediately Shown When Starting The Service Without Restoring The Keyset

–

Figure 18: Additional Info In The Application Event Log When Starting The Service Without Restoring The Keyset

–

The correct way to solve this is by reactivate the database for that you need to use the MIISACTIVATE tool in the folder "C:\Program Files\Microsoft Azure AD Sync\Bin".

Figure 19: Parameters Supported By The MIIS (!) Warn Standby Activation utility

–

Figure20: Reactivating The Existing Database For The New Azure AD Sync Service Engine

–

Figure 21: Warning About Making Sure the Previous Azure AD Sync Service Engine Is Offline

–

Figure22: Prompting For The Password Of The (Local) Azure AD Sync Service Service Account

–

Figure 23: Confirmation That Reactivation Was Successful

–

When checking you will find out the "Microsoft Azure AD Sync (ADSync)" Service is running already. Reactivation will do that.

–

Like the installation creates a new local Azure AD Sync Service Service Account, it also creates new Azure AD Sync Service security groups. To make sure you will be able to use the Azure AD Sync Service Engine from a permissions perspective you may need to logoff and logon again!

–

Additional information:

• (2014-09-16) Azure Active Directory Sync Services Has Reached General Availability
• Azure Active Directory Synchronization Services (AAD Sync)
• Best Practices for Deploying and Managing the Windows Azure Active Directory Sync Tool

–

And you’re done!

–

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

(2014-09-21) Change Install Of The Azure AD Sync Service Throws WMI Namespace Error

When performing a CHANGE install of the Azure AD Sync Service you may get the following error.

Figure 1: Error Thrown By The Azure AD Sync Setup Wizard Not Being Able To Configure Permissions On A Non-Existing Namespace

–

Error 25050. The Microsoft Azure AD Sync Setup wizard cannot set Windows Management Instrumentation (WMI) permissions. Ensure you have the correct permissions for this operation, and then try running this wizard again. To run WMI remotely, you must manually set the remote enable permissions. Invalid namespace.

–

The solution to the problem was already covered in this WIKI page, but unfortunately it is not complete.

When everything is OK, the "MicrosoftIdentityIntegrationServer" namespace does exist.

Figure 2: The "MicrosoftIdentityIntegrationServer" Namespace Does Exist When Everything Is OK

–

When everything is not OK, the "MicrosoftIdentityIntegrationServer" namespace does not exist! Duh!

Figure 3: The "MicrosoftIdentityIntegrationServer" Namespace Does Not Exist When Everything Is Not OK

–

Open a command prompt window and navigate to the folder "C:\Program Files\Microsoft Azure AD Sync\Bin". The execute: mofcomp mmswmi.mof

Figure 4: Reregistering The "MicrosoftIdentityIntegrationServer" Namespace

–

To make sure everything is really OK, check the namespace is configured with Azure AD Sync Service security groups. All Azure AD Sync Service security groups should have the4 same permissions as shown below

Figure 5: Permissions On The "MicrosoftIdentityIntegrationServer" Namespace For The Azure AD Sync Service security groups

–

In addition to the steps above, start the Component Services MMC, navigate to Component Services –> Computers –> My Computer, right-click My Computer and select Properties

Figure 6: Component Services MMC

–

Click on the "COM Security" TAB

Figure 7: "COM Security" TAB And The Parts For Which Permissions Need To Be Configured

–

If you changed the Azure AD Sync Service security groups, then make sure to REMOVE all old Azure AD Sync Service security groups in all three parts

Figure 8: Previous Azure AD Sync Service security groups

–

Make sure to configure the exact same permissions for all Azure AD Sync Service security groups as shown in the picture below

Figure 9: Access Permissions – Security Limits For Azure AD Sync Service security groups

–

Make sure to configure the exact same permissions for all Azure AD Sync Service security groups as shown in the picture below

Figure 10: Access Permissions – Default Security For Azure AD Sync Service security groups

–

Make sure to configure the exact same permissions for all Azure AD Sync Service security groups as shown in the picture below

Figure 11: Launch And Activation Permissions – Security Limits For Azure AD Sync Service security groups

–

And you’re done!

–

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

(2014-09-16) Azure Active Directory Sync Services Has Reached General Availability

Azure Active Directory Sync has reached general availability!

–

Features currently supported in this release:

• Active Directory and Exchange multi-forest environments can be extended now to the cloud
• Control over which attributes are synchronized based on desired cloud services.
• Selection of accounts to be synchronized through domains, OUs, etc.
• Ability to set up the connection to AD with minimal Windows Server AD privileges.
• Setup synchronization rules by mapping attributes and controlling how the values flow to the cloud.
• Preview AAD Premium password change and reset to AD on-premises.

–

Read all about it through the following links:

• New sync capabilities in preview: Password Write Back, New AAD Sync and Multi-forest support
• Azure Active Directory Sync is now GA!

–

Use the following link to actually download it:

• Microsoft Azure Active Directory Sync Services

–

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