Jorge's Quest For Knowledge!

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

Archive for the ‘Azure AD Connect’ Category

(2017-03-21) “Unrecoverable Issue” Error Or “Temporary Connectivity Issue” Error During Azure AD Password Change Or Password Reset

Posted by Jorge on 2017-03-21


A few days ago I was testing with Azure AD Password Change and Azure AD Self-Service Password Reset. I experienced the following errors, which at that time were weird and that I was not able to understand, as a few days before everything was working.

The errors below are related to password change. However, you will see similar errors when using password reset.

image

Figure 1: Error When Using Azure AD Self-Service Password Change/Reset

we could not change your password

We’re sorry, but we cannot change your password at this time. This is due to a temporary

connectivity issue, so if you try again later, changing your password may succeed.

If the issue persists, please contact your admin to change your password for you

image

Figure 2: Error When Using Azure AD Self-Service Password Change/Reset

we could not change your password

 

We’re sorry, but we cannot change your password at this time. Unfortunately, this is due to

an unrecoverable issue with your account configuration, so trying again won’t work.

Please contact your admin to change your password for you

When you look in the Application Event Log on the active Azure AD Connect server you will see an event similar to the following one.

image

Figure 3: Error In The Application Event Log Of The AAD Connect Server When Using Azure AD Self-Service Password Change/Reset

An unexpected error has occurred during a password set operation.
"ERR_: MMS(2332): ..\ObjectSearcher.cpp(461): AD Object is not present.
BAIL: MMS(2332): ..\ObjectSearcher.cpp(491): 0x80230405 (The operation failed because the object cannot be found): No password writeback targets found. Make sure that the source object exists and is connected to the target objects via MV and the target object is in scope of password sync rule. AAD anchor = User_ad4555c8-5a6c-4769-b3f7-27f58383f23dAzure AD Sync 1.1.443.0"

I also saw the following error

image

Figure 4: Error In The Application Event Log Of The AAD Connect Server When Using Azure AD Self-Service Password Change/Reset

TrackingId: 0f14f5a9-b62c-448f-a0bf-9783f73660ea, Reason: Synchronization Engine returned an error hr=80230405, message=The operation failed because the object cannot be found, Context: cloudAnchor: User_cb4555c8-5a6c-4769-b3f7-27f58383f23d, SourceAnchorValue: xxxxxxxxxxxxx UserPrincipalName: jorge@xxxxxx.nl, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230405, message=The operation failed because the object cannot be found
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String changePasswordXMLRequestString)

The errors mention 2 key hints:

  1. The operation failed because the object cannot be found
    1. Make sure that the source object exists and is connected to the target objects via MV ….
    2. …..and the target object is in scope of password sync rule

[AD.1]

This basically says the following:

  • The AD user object has a representative connector space object in the AD connector space, which is connected to a metaverse object, which is connected to connector space object in the AAD connector space, which is a representation of the AAD user object

In other words, the AD object and the AAD object must be related to each other through the CS objects and the MV object in Azure AD Connect. All CS objects must be a “connector”. If that is not the case you will need to fix this.

[AD.2]

This basically says the following:

  • Are there at least 1 inbound sync rule from AD and at least 1 outbound sync rule to AAD that both have the setting “Enable Password Sync” enabled and that both target the related objects end-to-end in Azure AD Connect

In other words, if at least one inbound sync rule and at least one outbound sync rule do not have the setting “Enable Password Sync” enabled it will produce this error. In addition, if the inbound and outbound sync rules with that setting do not scope the same related objects, it will also produce this error

So what was it in my case? Let’s first go back to the theory.

By default, 2 sync rules in Azure AD Connect (“In from AD – User AccountEnabled” and “Out to AAD – User Join”) have the settings “Enable Password Sync” enabled. If you want to use Password Change and Password Reset in Azure AD, you will have to enable Password Writeback in Azure AD Connect. That’s it! You do not have to do anything else!

Let’s assume you need to change any of the default rules. In that scenario you will try to edit the default sync rule and then choose the option to clone and disable the original sync rule. The cloned sync rule is then edited as you see fit or need. When you clone a sync rule that has the setting “Enable Password Sync”, that setting will also be transferred from the original sync rule to the cloned sync rule.

A week or so ago, I had to reinstall Azure AD Connect. So I used my script to export sync rules to PowerShell files, uninstalled Azure AD Connect, reinstalled Azure AD Connect and imported my custom sync rules. And here is where it went wrong! The script that I had written had a bug where it DID NOT export the setting “Enable Password Sync” on any sync rule. Therefore, during import the setting “Enable Password Sync” was also not put back on my custom inbound sync rule (and the original sync rule was disabled, as expected!). A simple fix to the script solved the export issue.

For Azure AD Connect, on my custom inbound sync rule I enabled the setting “Enable Password Sync” and ran an initial (full) sync with the command: Start-ADSyncSyncCycle -PolicyType Initial

Problem solved!

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

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

(2017-03-07) Azure AD Connect v1.1.443.0 Has Been Released

Posted by Jorge on 2017-03-07


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

Released: 2017 March

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New features:

  • Azure AD Connect sync
    • Get-ADSyncScheduler cmdlet now returns a new Boolean property named SyncCycleInProgress. If the returned value is true, it means that there is a scheduled synchronization cycle in progress.
    • Destination folder for storing Azure AD Connect installation and setup logs has been moved from %localappdata%\AADConnect to %programdata%\AADConnect to improve accessibility to the log files.
  • AD FS management
    • Added support for updating AD FS Farm SSL Certificate.
    • Added support for managing AD FS 2016.
    • You can now specify existing gMSA (Group Managed Service Account) during AD FS installation.
    • You can now configure SHA-256 as the signature hash algorithm for Azure AD relying party trust.

Fixed issues:

  • Azure AD Connect sync
    • Fixed an issue which causes Azure AD Connect wizard to fail if the display name of the Azure AD Connector does not contain the initial onmicrosoft.com domain assigned to the Azure AD tenant.
    • Fixed an issue which causes Azure AD Connect wizard to fail while making connection to SQL database when the password of the Sync Service Account contains special characters such as apostrophe, colon and space.
    • Fixed an issue which causes the error “The image has an anchor that is different than the image” to occur on an Azure AD Connect server in staging mode, after you have temporarily excluded an on-premises AD object from syncing and then included it again for syncing.
    • Fixed an issue which causes the error “The object located by DN is a phantom” to occur on an Azure AD Connect server in staging mode, after you have temporarily excluded an on-premises AD object from syncing and then included it again for syncing.
  • AD FS management
    • Fixed an issue where Azure AD Connect wizard does not update AD FS configuration and set the right claims on the relying party trust after Alternate Login ID is configured.
    • Fixed an issue where Azure AD Connect wizard is unable to correctly handle AD FS servers whose service accounts are configured using userPrincipalName format instead of sAMAccountName format.
  • Pass-through Authentication
    • Fixed an issue which causes Azure AD Connect wizard to fail if Pass Through Authentication is selected but registration of its connector fails.
    • Fixed an issue which causes Azure AD Connect wizard to bypass validation checks on sign-in method selected when Desktop SSO feature is enabled

Known issues:

  • N.A. 

Improvements:

  • N.A.

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

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

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

(2017-03-01) Hardening – Disabling Weak Ciphers, Hashes And Protocols On ADFS, WAP, AAD Connect, Azure AD MFA Server

Posted by Jorge on 2017-03-01


This post is about disabling weak ciphers, hashes, cipher suites and protocols in ADFS, WAP, AAD Connect and Azure AD MFA server. The main focus however, is disabling weak protocols in ADFS, WAP, AAD Connect and Azure AD MFA Server as these systems play a very important part in the hybrid solution with Azure AD and its backend services.

Please be very careful with these settings when hardening your systems and make sure to test first!!!

For quite some time now, SSL v2.0, SSL v3.0 and TLS v1.0 should be disabled and not be used anymore. Especially with disabling TLS v1.0 you may/will experience some challenges that need to taken care of. It may seem difficult to disable TLS v1.0, but it is not impossible. Just do your research!

For this blog post and the tests that I performed in my test/demo environment I used the following information:

As a starting point for this blog post I do assume that every client/server is up to date with the patches available through Windows update!

As soon as you disable TLS v1.0 on W2K8R2 and higher, the RDP client on Windows 7 and Windows Server 2008 R2 breaks. For Windows 7 and Windows Server 2008 R2 the hotfix Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2 exists to add support for TLS v1.1 and TLS v1.2 for RDP client on Windows 7 and Windows Server 2008 R2. The RDP client on Windows 8/8.1 and Windows Server 2012 (R2) and higher is not impacted.

SQL Server

Looking at both ADFS and AAD Connect, both can use SQL server for their data storage.

If ADFS is using WID, from my experience, you do not need to do anything in addition.

If you have installed AAD Connect without SQL server, then you are using SQL Server 2012 Express LocalDB (a light version of SQL Server Express). I do not fully understand why, but in my case the Azure AD Sync service did not start anymore. Exporting the custom sync rules, uninstalling AAD Connect, rebooting the server, reinstalling AAD Connect and importing the custom Sync rules and everything was fine again. Don’t ask why or how. Maybe a coincidence!

However, if either ADFS or AAD Connect is using SQL server, make sure to patch SQL server so that it supports TLS v1.2. More information about this can be found in TLS 1.2 support for Microsoft SQL Server.

If SQL Server is running on W2K8R2, then TLS v1.1 and TLS v1.2 are supported, but it is disabled by default. You will have to enable it through the following commands and reboot the server afterwards.

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

If SQL Server is running on W2K12 or higher, then TLS v1.1 and TLS v1.2 are supported and enabled by default.

Azure AD Connect

AAD Connect supports W2K8 and higher as the server OS. However:

  • W2K8 does not support TLS v1.1 or TLS v1.2. You will have move away to a more recent server OS version.
  • W2K8R2 does support TLS v1.1 or TLS v1.2, but it is disabled by default. You will have to enable it through the “REG ADD” commands or using the IISCRYPTO tool and reboot the server afterwards.
  • W2K12 does support TLS v1.1 or TLS v1.2 and it is enabled by default. Explicitly enabling it does not change or hurt anything.

When connecting to Azure AD, TLS v1.0 is used by default. This can be changed to start using TLS v1.2 instead. Azure AD by default supports this.

The Azure AD Connect server depends on .NET Framework 4.5.1 or later. Whichever version you have installed, you need to install a patch for it, unless you are already running it on W2K16 or higher. If you are running W2K8R2, W2K12 or W2K12R2 you need to install a patch. Which patch you need can be found in Microsoft Security Advisory 2960358.

In addition, configure the server to disable/enable (whichever is applicable) the following ciphers, hashes and protocols:

Disabling Weak Ciphers/Hashes/Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Enabling Strong Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

.NET is hardcoded to use TLS v1.0 by default. After installing the required patch (W2K12R2 and lower only) you need to tell .NET to use the stronger protocols. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

Azure AD MFA Server

AAD MFA Server supports W2K3 and higher as the server OS. However:

  • W2K3 and W2K8 do not support TLS v1.1 or TLS v1.2. You will have move away to a more recent server OS version.
  • W2K8R2 does support TLS v1.1 or TLS v1.2, but it is disabled by default. You will have to enable it through the “REG ADD” commands or using the IISCRYPTO tool and reboot the server afterwards.
  • W2K12 does support TLS v1.1 or TLS v1.2 and it is enabled by default. Explicitly enabling it does not change or hurt anything.

When connecting to Azure AD, TLS v1.0 is used by default. This can be changed to start using TLS v1.2 instead. Azure AD by default supports this.

The Azure AD MFA server depends on .NET Framework 4 or later. Whichever version you have installed, you need to install a patch for it, unless you are already running it on W2K16 or higher. If you are running W2K8R2, W2K12 or W2K12R2 you need to install a patch. Which patch you need can be found in Microsoft Security Advisory 2960358.

In addition, configure the server to disable/enable (whichever is applicable) the following ciphers, hashes and protocols:

Disabling Weak Ciphers/Hashes/Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Enabling Strong Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

.NET is hardcoded to use TLS v1.0 by default. After installing the required patch (W2K12R2 and lower only) you need to tell .NET to use the stronger protocols. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

ADFS In General

From a federation perspective, if a target ADFS server does not support the weaker protocols when updating the metadata from the target ADFS server, you will most likely see an error equal or at least similar to the one below. Now please be aware that testing the protocols by reading the target metadata in a browser compared to reading the target metadata in the ADFS management console use a different configuration. If the browser, as a client, does support the stronger protocols you will/may not see an error. However, doing the same in the ADFS management console might return the following error

image

Figure 1: Connection Being Closed By Remote ADFS Server Because Local ADFS Server Does Not Support/Use Stronger Protocols

In this setup I will have a secured ADFS server (ADFS v3.0 or ADFS v4.0) which will be configured to only support stronger protocols and no weak protocols. I will have other remote ADFS servers, clients, applications, etc. with which the secured ADFS server needs to communicate with in any form (e.g. read metadata through URL from remote ADFS servers and/or applications). The other way around the remote ADFS servers, WAP Server, clients, applications, etc. need to communicate with the secured ADFS server to read its metadata/configuration or deliver or get a security token. In the case the secured ADFS server needs to communicate with SQL server, than if above in the section “SQL Server”. The idea here is also to configure remote servers/clients to be able to use TLS v1.1 and TLS v1.2 against the secured ADFS/WAP servers, but NOT to disable TLS v1.0 on them. This is about what you need to do at least on other systems if you secure one specific ADFS/WAP farm.

Secured ADFS/WAP To Only Support Stronger Protocols And Disable Weaker Protocols

ADFS/WAP v3.0 is based on W2K12R2, ADFS/WAP v4.0 is based on W2K16. W2K12R2 and W2K16 both already supports TLS v1.1 and TLS v1.2 and it is also already enabled. Again, explicitly enabling it does not change or hurt anything. See commands below to disable/enable stuff

.NET is hardcoded to use TLS v1.0 by default. For W2K12R2 and W2K16 you need to tell .NET to use the stronger protocols. That is done by executing the commands below to set the required registry settings. However, for W2K12R2 you must install some patches first to be able to tell .NET to use the stronger protocols in use by the OS. For that see Microsoft Security Advisory 2960358 (probably MS-KB2898847 and MS-KB2898850). For W2K16 you do not need to install the patches. You only need to configure the registry settings .

Configure the server to disable/enable (whichever is applicable) the following ciphers, hashes and protocols:

Disabling Weak Ciphers/Hashes/Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Enabling Strong Protocols (not really needed for W2K12R2/W2K16 as these are already enabled by default in the OS)

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

.NET is hardcoded to use TLS v1.0 by default. To tell .NET to use the stronger protocols. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

Looking at all this from the the IISCRYPTO tool it will look like

image

Figure 2: Settings Viewed/Configured From The IISCRYPTO Tool

You might also think in disabling weak(er) cipher suites on both ADFS/WAP. For that you can configure a GPO to target the specific servers, or use the local GPO to do so. Nevertheless, you can configure this as follows:

image

Figure 3: Setting To Disable Weaker Cipher Suites

Enable that setting and specify the following Cipher Suites that are allowed (for readability I put everything on one line, but it must be a comma-separated list):

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA

After configuring all this, DO NOT forget to reboot the ADFS/WAP servers!

If you have configured this on all your WAP server and you have those scanned through SSL Labs (URL:  https://www.ssllabs.com/ssltest/analyze.html) you will see a rating similar to

image

Figure 4: Qualys SSL Labs Report For WAP Configured With Settings Listed Above (Part 1)

image

Figure 5: Qualys SSL Labs Report For WAP Configured With Settings Listed Above (Part 2)

image

image

image

Figure 6: Qualys SSL Labs Report For WAP Configured With Settings Listed Above (Part 3)

Browsers Communicating With Secured ADFS

Internet Explorer must be configured to support TLS v1.1 and TLS v1.2 if not already enabled by default.

Open Internet Explorer –> Internet Options –> Advanced TAB –> Scroll down to the end

image

Figure 7: Internet Explorer Settings For TLS Support

Firefox must be configured to support TLS v1.1 and TLS v1.2 if not already enabled by default.

Open Firefox –> As URL enter “about:config” –> Accept warning –> In the search box enter “security.tls.version.max” –> This tells you the highest TLS version supported

1 means TLS 1.0; 2 means TLS 1.1; 3 means TLS 1.2; 4 means TLS 1.3;

image

Figure 8: Firefox Settings For TLS Support

Chrome must be configured to support TLS v1.1 and TLS v1.2 if not already enabled by default.

Open Chrome –> As URL enter “chrome://settings”" –> Click on Settings on the left –> Scroll down to Network –> Click on Change Proxy Settings –> Advanced TAB –> Scroll down to the end

Yes, you guessed it correctly. Chrome inherits these settings from IE!

Remote ADFS On W2K8R2 (ADFS v2.0) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v2.0 on W2K8R2” and “ADFS v2.0 on W2K8R2 reading metadata from Secured ADFS”

W2K8R2 by default supports TLS v1.1 and TLS v1.2, but it is disabled by default. Therefore you need to enable it. You can use the following commands to do so.

Enabling Strong Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

Looking at all this from the the IISCRYPTO tool it will look like

image

Figure 9: Settings Viewed/Configured From The IISCRYPTO Tool On W2K8R2 With ADFS v2.0

Applies To Direction –> “ADFS v2.0 on W2K8R2 reading metadata from Secured ADFS”

Install the hotfix listed in Support for TLS System Default Versions included in the .NET Framework 3.5.1 on Windows 7 SP1 and Server 2008 R2 SP1

Tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v2.0 servers!

Remote ADFS On W2K12 (ADFS v2.1) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v2.1 on W2K12” and “ADFS v2.1 on W2K12 reading metadata from Secured ADFS”

W2K12 by default supports TLS v1.1 and TLS v1.2 and it is also enabled by default. Nothing to do for that.

Applies To Direction –> “ADFS v2.1 on W2K12 reading metadata from Secured ADFS”

I think you do need to install the hotfixes listed in Microsoft Security Advisory 2960358 (probably MS-KB2898845 and MS-KB2898849).

However, you still need to tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings.

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v2.1 servers!

Remote ADFS On W2K12R2 (ADFS v3.0) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v3.0 on W2K12R2” and “ADFS v3.0 on W2K12R2 reading metadata from Secured ADFS”

W2K12R2 by default supports TLS v1.1 and TLS v1.2 and it is also enabled by default. Nothing to do for that.

Applies To Direction –> “ADFS v3.0 on W2K12R2 reading metadata from Secured ADFS”

In this case I would expect to have to install the hotfixes listed in Microsoft Security Advisory 2960358 (probably MS-KB2898847 and MS-KB2898850). However, funny enough it was not needed

However, I still needed to tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings.

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v3.0 servers!

Remote ADFS On W2K16 (ADFS v4.0) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v4.0 on W2K16” and “ADFS v4.0 on W2K16 reading metadata from Secured ADFS”

W2K16 by default supports TLS v1.1 and TLS v1.2 and it is also enabled by default. Nothing to do for that.

Applies To Direction –> “ADFS v4.0 on W2K16 reading metadata from Secured ADFS”

No need to install patches for this.

However, I still needed to tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v4.0 servers!

Remote Applications/Federation Systems (On-premises Or Cloud) To Be Able To Communicate With Secured ADFS

Applies To Direction –> “Secured ADFS reading metadata from remote Application/Federation System”

Just make sure the connected application/federation system supports TLS v1.1 and TLS v1.2 as a server. You may need to contact system owners and/or vendors and ask if their system supports TLS v1.1 and/or TLS v1.2. You can also setup a separate secured ADFS server and try to read its metadata from the application/federation system. If it succeeds it most likely does support TLS v1.1 and/or TLS v1.2.

Or….

Use the PowerShell script from Vadims Podans to check if the target server supports TLS v1.1/1.2 as a server: Test web server SSL/TLS protocol support with PowerShell

Applies To Direction –> “Remote Application/Federation System reading metadata from Secured ADFS”

Just make sure the connected application/federation system supports TLS v1.1 and TLS v1.2 as a client. You may need to contact system owners and/or vendors and ask if their system supports TLS v1.1 and/or TLS v1.2. By performing the previous test, you may be able to assume (not sure of course) that it will also support TLS v1.1 and TLS v1.2 as a client if it supports TLS v1.1 and TLS v1.2 as a server

Additional Findings:

  • At the time of writing, it looks like Azure AD Connect Health DOES NOT support TLSv1.1/v1.2 only. It appears to need TLSv1.0

Troubleshooting

If you find a error like the following one in the System Event Log:

"A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 70. The Windows SChannel error state is 105."

Check the underlined error code, a.k.a. the fatal error code, and look it up in SSL/TLS Alert Protocol & the Alert Codes. In this case “fatal error code 70 ” means: “The protocol version the client attempted to negotiate is recognized, but not supported. For example, old protocol versions might be avoided for security reasons. This message is always fatal.”

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

Posted in Active Directory Federation Services (ADFS), Azure AD Connect, Hardening, Web Application Proxy | 3 Comments »

(2017-01-11) Azure AD Connect v1.1.380.0 Has Been Released

Posted by Jorge on 2017-01-11


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

Released: 2016 December

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New features:

  • N.A. 

Fixed issues:

  • Fixed the issue where the issuerid claim rule for ADFS is missing in this build

Known issues:

  • N.A. 

Improvements:

  • N.A.

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

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

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

(2016-12-19) Azure AD Connect Delta Import Run Profile Throws “Stopped-Server-Down”

Posted by Jorge on 2016-12-19


You may notice that the “Delta Import” Run Profile for the AAD connector in Azure AD Connect throws a “Stopped-Server-Down” after running for about 20 or so minutes. Other connectors and other profiles execute without any problem!

In the application event log, you may see the following information and error events.

clip_image002

Figure 1: Informational Event In The Application Event Log

The underlying connection was closed: The connection was closed unexpectedly.

clip_image004

Figure 2: Informational Event In The Application Event Log

ProvisioningServiceAdapter::ExecuteWithRetry: Action: Import, Attempt: 0.

Live token has expired and it will be renewed automatically.

clip_image006

Figure 3: Error Event In The Application Event Log

Failure while prefetching import data.

clip_image008

Figure 4: Error Event In The Application Event Log

Failure while importing entries from Windows Azure Active Directory. Exception: Microsoft.MetadirectoryServices.ServerDownException: Failed even after 5 retries. Action: Import, Network error occurrences = 5. Exception: Unable to communicate with the Windows Azure Active Directory service. Tracking ID: b1796718-1719-4014-aa4a-80e73c5f8087 See the event log for more details.. —> Microsoft.Online.Coexistence.ProvisionRetryException: Unable to communicate with the Windows Azure Active Directory service. Tracking ID: b1796718-1719-4014-aa4a-80e73c5f8087 See the event log for more details. —> System.ServiceModel.CommunicationException: The underlying connection was closed: The connection was closed unexpectedly. —> System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly.

   at System.Net.HttpWebRequest.GetResponse()

   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

   — End of inner exception stack trace —

Server stack trace:

   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)

   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:

   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

   at Microsoft.Online.Coexistence.Schema.IProvisioningWebService.ReadBackAzureADSyncObjects(Byte[] inputCookie, Boolean isFullSync)

   at Microsoft.Online.Coexistence.ProvisionHelper.InvokeAwsAPI[T](Func`1 awsOperation, String opsLabel)

   — End of inner exception stack trace —

   at Microsoft.Online.Coexistence.ProvisionHelper.CommunicationExceptionHandler(CommunicationException ex)

   at Microsoft.Online.Coexistence.ProvisionHelper.InvokeAwsAPI[T](Func`1 awsOperation, String opsLabel)

   at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.<>c__DisplayClass7.<Import>b__6()

   at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.ExecuteWithRetry(String actionName, Action action)

   — End of inner exception stack trace —

   at Microsoft.Azure.ActiveDirectory.Connector.GetImportEntriesTask.GetNextBatch()

   at Microsoft.Azure.ActiveDirectory.Connector.AADConnector.GetImportEntriesCore()

   at Microsoft.Azure.ActiveDirectory.Connector.AADConnector.GetImportEntries(GetImportEntriesRunStep getImportEntriesRunStep).

clip_image010

Figure 5: Error Event In The Application Event Log

The management agent "XXXXXXXXXXXXXXXX.onmicrosoft.com – AAD" failed on run profile "Delta Import" because the server encountered errors.

The solution? Believe it or not, but it worked for me!

Set-ADSyncScheduler -SyncCycleEnabled $FALSE

Start-ADSyncSyncCycle -PolicyType Initial

Start-ADSyncSyncCycle -PolicyType Delta

Set-ADSyncScheduler -SyncCycleEnabled $TRUE

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

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

(2016-12-12) Azure AD Connect Upgrade Displays Error While Executing “Configure AAD Sync Task”

Posted by Jorge on 2016-12-12


During the Azure AD Connect upgrade, you may end up with the error below:

Configure AAD Sync

An error occurred executing Configure AAD Sync task: The given key was not present in the dictionary

image

Figure 1: Error During The Upgrade Of Azure AD Connect

The log file does not really give you a hint

The solution? Just click [Retry]

When googling on the internet you may find the following blog post:

The errors you see there are related to connectivity to Azure AD, either directly or through a proxy.

If you do not use a proxy, but rather have a direct connection to the internet, you do not need to configure the machine.config file.

If you do use a proxy make sure to configure the machine.config file as recommended in Prerequisites for Azure AD Connect

I know of an Azure AD Connect installations that:

  • Connect to Azure AD directly and without any adjustment in the “machine.config” file
  • Connect to Azure AD through a proxy and with any adjustment in the “machine.config” file

…that show the error in figure 1

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

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

(2016-12-11) Azure AD Connect v1.1.371.0 Has Been Released

Posted by Jorge on 2016-12-11


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

Released: 2016 December

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New features:

  • Pass-through Authentication (Preview)

Known issue:

  • The issuerid claim rule for ADFS is missing in this build. The issuerid claim rule is required if you are federating multiple domains with Azure AD. If you are using Azure AD Connect to manage your on-premises ADFS deployment, upgrading to this build will remove the existing issuerid claim rule from your ADFS configuration. You can work around the issue by adding the issuerid claim rule after install/upgrade. For details on adding issuerid claim rule, please refer to this article on Multiple Domain Support for Federating with Azure AD.

Fixed issues:

  • Azure AD Connect installation or upgrade fails if Port 9090 is not opened for outbound connection.

Improvements:

  • N.A.

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

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

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

(2016-11-20) Azure AD Connect v1.1.343.0 Has Been Released

Posted by Jorge on 2016-11-20


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

Released: 2016 November

New features:

  • N.A.

Fixed issues:

  • Sometimes, installing Azure AD Connect fails because it is unable to create a local service account whose password meets the level of complexity specified by the organization’s password policy.
  • Fixed an issue where join rules are not re-evaluated when an object in the connector space simultaneously becomes out-of-scope for one join rule and become in-scope for another. This can happen if you have two or more join rules whose join conditions are mutually exclusive.
  • Fixed an issue where inbound synchronization rules (from Azure AD) which do not contain join rules are not processed if they have lower precedence values than those containing join rules.

Improvements:

  • Added support for installing Azure AD Connect on Windows Server 2016 standard or better.
  • Added support for using SQL Server 2016 as the remote database for Azure AD Connect.
  • Added support for managing AD FS 2016 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 yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

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

(2016-09-16) Azure AD Connect v1.1.281.0 Has Been Released

Posted by Jorge on 2016-09-16


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.1.281.0

Released: 2016 August

New features:

  • N.A.

Fixed issues:

  • Changes to sync interval does not take place until after next sync cycle completes.
  • Azure AD Connect wizard does not accept Azure AD account whose username starts with an underscore (_).
  • Azure AD Connect wizard fails to authenticate Azure AD account provided if account password contains too many special characters. Error message "Unable to validate credentials. An unexpected error has occurred." is returned.
  • Uninstalling staging server disables password synchronization in Azure AD tenant and causes password synchronization to fail with active server.
  • Password synchronization fails in uncommon cases when there is no password hash stored on the user.
  • When Azure AD Connect server is enabled for staging mode, password writeback is not temporarily disabled.
  • Azure AD Connect wizard does not show the actual password synchronization and password writeback configuration when server is in staging mode. It always shows them as disabled.
  • Configuration changes to password synchronization and password writeback are not persisted by Azure AD Connect wizard when server is in staging mode.

Improvements:

  • Updated Start-ADSyncSyncCycle cmdlet to indicate whether it is able to successfully start a new sync cycle or not.
  • Added Stop-ADSyncSyncCycle cmdlet to terminate sync cycle and operation which are currently in progress.
  • Updated Stop-ADSyncScheduler cmdlet to terminate sync cycle and operation which are currently in progress.
  • When configuring Directory Extensions in Azure AD Connect wizard, AD attribute of type "Teletex string" can now be selected.

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

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

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

(2016-06-09) Azure AD Connect v1.1.189.0 Has Been Released

Posted by Jorge on 2016-06-09


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

Released: 2016 June

New features:

  • N.A.

Fixed issues and improvements:

  • Azure AD Connect can now be installed on a FIPS compliant server.
  • Fixed an issue where a NetBIOS name could not be resolved to the FQDN in the Active Directory Connector.

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

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

 
%d bloggers like this: