AD FS update Password Page – Add a Captcha

On AD FS, a specific Endpoint called /adfs/ls/updatepassword is present and disable by default, this endpoint allows you to provide a page for your users to update their password.

You can choose to provide this page only for Internal users, but if you choose to enable this endpoint on Proxy, it becomes publicly accessible from the Internet.
And so, attackers can try to do brute force on it.

One way to guard against this is to set up a captcha feature.

Create a new AD FS Web Theme

To be able to customize some scripts used by AD FS, we first need to create a new dedicated Web Theme.

Open PowerShell with administrator rights, and type the following commands:

New-AdfsWebTheme –Name custom –SourceName default

This command create a new theme named custom based on the default theme.

Export-AdfsWebTheme –Name default –DirectoryPath c:\ADFStheme

This command export theme elements for default theme to your selected path.

Edit onload.js file

Go to the exported folder path, in our example C:\ADFStheme\ and go to script folder.
Edit the onload.js file with the following code:

if(window.location.href.indexOf("adfs/portal/updatepassword") != -1) {
var updatePasswordFormElement = document.getElementById("updatePasswordForm");
var headerElement = document.getElementById("header");
var introductionElement = document.getElementById("introduction");
if (updatePasswordFormElement){ = "none";
if (introductionElement) {
	var iDiv = "<br /><br /><br /><div id='captchaForm' class='captchaForm'><form name='review' ACTON='#' METHOD='GET' onsubmit=\"return checkform(this);\"><font color='#000000'>For security reasons please retype this code <br /><br />Enter code: </font><span id='txtCaptchaDiv'style='background-color:#0000ab;color:#FFF;padding:5px;margin:10px'></span><input type='hidden' id='txtCaptcha' /><input type='text' name='txtInput' id='txtInput' size='6'/><span id='txtCaptchaDiv' style='margin:10px'></span><input type='submit' value='Submit'/></form></div>";
		introductionElement.innerHTML += iDiv;
	if ( == "goodCaptcha"){
		var captchaFormElement = document.getElementById("captchaForm");
		var updatePasswordFormElement = document.getElementById("updatePasswordForm"); = "none"; = "block";
	//Generates the captcha function
	var a = Math.ceil(Math.random() * 9)+ '';
	var b = Math.ceil(Math.random() * 9)+ '';
	var c = Math.ceil(Math.random() * 9)+ '';
	var d = Math.ceil(Math.random() * 9)+ '';
	var e = Math.ceil(Math.random() * 9)+ '';
	var f = Math.ceil(Math.random() * 9)+ '';
	var code = a + b + c + d + e + f;
	document.getElementById("txtCaptcha").value = code;
	document.getElementById("txtCaptchaDiv").innerHTML = code;

function checkform(theform){
var why = "";
if(theform.txtInput.value == ""){
	why += "Security code should not be empty.\n";
if(theform.txtInput.value != ""){
	if(ValidCaptcha(theform.txtInput.value) == false){
	why += "Security code did not match.\n";
if(why != ""){
	return false;
} = "goodCaptcha"

// Validate the Entered input aganist the generated security code function
function ValidCaptcha(){
	var str1 = removeSpaces(document.getElementById('txtCaptcha').value);
	var str2 = removeSpaces(document.getElementById('txtInput').value);
	if (str1 == str2){
		return true;
			return false;

// Remove the spaces from the entered and generated code
function removeSpaces(string){
return string.split(' ').join('');

This is just an example of what you can do with script integration, but you can develop your own code or directly called the Captcha API.
My example is just based on 6 numeric characters, we can of course do much more complex.

Apply the our custom js to our custom AD FS Web Theme

Open PowerShell with administrator rights, and type the following commands:

Set-AdfsWebTheme -TargetName custom -OnLoadScriptPath "c:\ADFStheme\script\onload.js"

This command apply our new onload.js to our custom theme named custom

Set-AdfsWebConfig -ActiveThemeName custom 

This command will apply our new theme named custom a Active Theme on AD FS

Check the result

Open a browser session on go to the update password page of your federation service

Users now need to enter the displayed Security code, before being allowed to change their password.

Demystifying Password Hash Sync

During my several mission, I have often eared that:
“We don’t want to use Password Hash Sync, because we don’t want to send our passwords on the cloud !”
And so we entering in a long conversion to explain in depth what is exactly P#S, and especially what is not P#S.

PHS What it is not ?

  • PHS doesn’t sync actual passwords
  • It syncs the hashes of passwords
    • which have all undergone a per-user salt and 1,000 iterations of the HMAC-SHA256 key hashing algorithm, before being sent to Azure Active Directory
  • The SHA256 hash cannot be decrypted
    • so the plain-text version of the password is never and can never be exposed to Microsoft

PHS – AAD Connect deep dive

With PHS

  • With PHS your Identity Management provider is moved from your current provider to Azure AD
  • Move from on-premises Identity Management provider to a platform-as-a-service (PaaS) provider
  • Denial of Service (DoS) and/or Password Spray attack on Microsoft side, Microsoft will take the brunt of that traffic
  • Utilize Microsoft’s telemetry that gives organizations the power of Microsoft’s intelligence

PHS – Security Advantages

  • Smart Lockout
    • Assists in blocking bad actors who are attempting to brute force passwords.
    • By default, Smart Lockout locks the account from sign-in attempts for one minute after ten failed attempts.
    • Smart Lockout tracks the last three bad password hashes to avoid re-incrementing the lockout counter.
  • IP Lockout
    • Works by analyzing those billions of sign-ins to assess the quality of traffic from each IP address hitting Microsoft’s systems.
    • With that analysis, IP Lockout finds IP addresses acting maliciously, such as an IP that is password spraying the tenant, and blocks those sign-ins in real-time, while allowing the real user to continue to successfully sign in.
  • Microsoft Leaked Credentials Service
    • Acquires username/password pairs by monitoring public web sites and the Dark Web and by working with:
      • Researchers
      • Law enforcement
      • Microsoft Security teams
      • Other trusted sources
    • When the service acquires username/password pairs, the passwords are sent through the same hashing algorithm and are checked against Azure AD users’ password hashes.

Choose Hybrid Identity solution with Azure AD

Once the decision to go on Azure is done, an important question is how to manage the Identity between on-premises and the Cloud, so Azure Active Directory.

There are different Identity Models available to deal with it.
Let’s take a little bit of time to present these models.

Identity Models

Cloud Identity

  • Cloud Identity mode means that only Azure AD directory is available, there is no Active Directory Domain Services present.
  • All accounts are stored and created on Azure AD
  • Manual account creation
    • Azure Portal (Azure, Intune, Office 365, etc…)
    • PowerShell
    • API
  • CSV file import, for multiple account creation

Synchronized Identity

  • Directory & Password synchronization mode means that a synchronization process was made to:
    • Copy an account created On-Premise to Azure AD
    • Synchronize password
    • Easy Provisioning
    • No manual action (Azure AD Connect)

Federated Identity

  • Federated Identity mode means that a synchronization process was made and a Federation trust was made between Azure AD and On-Premise Active Directory Domain Services:
    • Copy an account created On-Premise to Azure AD
    • Synchronize password
    • Easy Provisioning
    • No manual action (Azure AD Connect)
    • Federation between On-Premise AD DS and Azure AD

Once an Identity Model is chosen,  it is necessary to choose which tools and solutions to implement.

Decision Tree

Microsoft has made a Decision Tree to help customer to select the right solution within customer context.

Now let’s go depth in each solution.

Azure AD Connect

Azure AD Connect Timeline

Azure AD Connect is an old and robust tool developed by Microsoft to synchronize identity between on-premises directory and cloud directory.

Azure AD Connect components

Azure AD Connect is made up of three primary components: the synchronization services, the optional Active Directory Federation Services component, and the monitoring component named Azure AD Connect Health.

Azure AD Connect Sync Process


The code modules that are used to communicate with a connected directory are called connectors (formerly known as management agents (MAs))

Attribute flow

Attribute flow is the process of copying or transforming data from one system to another and all attribute flows (inbound or outbound).

Attribute flow occurs between the connector space and the metaverse bi-directionally when synchronization (full or delta) operations are scheduled to run.

Connector space

Each connected data source is represented as a filtered subset of the objects and attributes in the connector space.


The metaverse is the consolidated view of all joined identities from neighboring connector spaces.



  • SSO via on-premises AD credentials
  • Seamlessly authenticate to AD FS when the client is attached to the corporate network
  • Passwords remain on-premises
  • On-premises authentication policies
  • On-premises authentication methods (multi-factor)
  • Conditional access via AD FS policies
  • Require public certificates
  • Authentification using certificates
    • Certificates
    • Smart cards
    • Windows Hello
  • Complex and expansive architecture
  • Protection again on-premise account lockout

Password # Sync

Key Security Capabilities:

  • Isolation of sign-in requests between tenants
  • Standard ports (80 and 443) are used for outbound communication from the Authentication Agents to Azure AD
    • Port 443 is used for all authenticated outbound communication
    • Port 80 is used only for downloading the Certificate Revocation Lists (CRLs) to ensure that none of the certificates used by this feature have been revoked
  • High security encryption of password hashes


  • On-premises password complexity applies to synchronised users
    • If an administrator changes the cloud password using PowerShell, the Azure AD password policy applies
  • An expired/disabled on-premises account can still be active in the cloud
    • The cloud password for a PHS user is set to never expire
  • Synchronisation of a new password will have no impact on a user signed into Azure AD
  • Password synchronisation can be used in addition to federation and used as a fall-back

Pass-Through Authentication

Big Picture

Key Security Capabilities:

  • Isolation of sign-in requests between tenants
  • On-premises passwords are never stored in the cloud in any form
  • On-premises Authentication Agents that listen for, and respond to, password validation requests only make outbound connections from within your network. NO DMZ need
  • Standard ports (80 and 443) are used for outbound communication from the Authentication Agents to Azure AD
    • Port 443 is used for all authenticated outbound communication
    • Port 80 is used only for downloading the Certificate Revocation Lists (CRLs) to ensure that none of the certificates used by this feature have been revoked
  • Passwords that users provide during sign-in are encrypted in the cloud before the on-premises Authentication Agents accept them for validation against Active Directory
  • The HTTPS channel between Azure AD and the on-premises Authentication Agent is secured by using mutual authentication
  • Integrates with Azure AD cloud-protection capabilities, such as conditional access policies (including Azure Multi-Factor Authentication), identity protection, and Smart Lockout

Pass-Through Authentication – Authentication Agent

  • Getting an Authentication Agent working involves three main phases:

1.Authentication Agent installation

2.Authentication Agent registration

3.Authentication Agent initialization

  • Authentication Agent uses 2 different services/applications:
    • The Authentication Agent application itself:
      • application runs with NetworkService privileges
    • The Updater application that’s used to auto-update the Authentication Agent
      • application runs with LocalSystem privileges

Authentication Agent registration

Authentication Agent initialization

request

Security of Authentication Agents


  • No on-premises passwords/hashes in the cloud
  • All on-premises password policies operational
  • Password changes are immediately in effect
  • Account expired/disabled operational
  • Works with Conditional Access Policy
  • No DMZ requirements
  • Does not support on-premises MFA
    • Azure AD MFA supported
  • Works with Alternate ID
  • Does not provide SSO for on-premises credentials
    • Requires Seamless SSO in addition
  • Requires high-availability for the company’s Internet connection
    • Remote workers will not be able to authenticate to Azure AD If the link is down

Seamless SSO

Big Picture

on a web browser

on native client


  • Works with Password Hash Sync (P#S) or Pass-through Authentication (PTA)
  • Users only need to type their name to authenticate to Azure AD
    • It is possible for applications to pass a login_hint for seamless SSO
  • Supports Windows 7 and above
    • Windows 10 Edge not currently supported
  • Machine must be domain joined and have access to a DC
    • On corporate network or via remote access technology
  • Authenticates to Azure AD with a Kerberos token
  • Available with all versions of Azure AD
  • Supports Alternate ID
  • Support for multiple browsers and Oss
    • Including Safari and Mac

Comparison Matrix

Infrastructure & Operations




Experience

Password expiry notification and change

Devices & Access Control

To conclude, my recommendations

  • If you are new customers:
    • Use cloud authentication (P#S or PTA)
    • Leverage conditional access and Azure AD MFA
    • If AD FS is deployed to support on-premises applications, consider managing authentication for those apps via Azure AD
  • Enable Seamless SSO if you’re using P#S or PTA
    • Simple to deploy
    • Immediately enhances the sign-in experience for your users
    • Implement domain_hint
  • If you are already in Federated Identity mode with AD FS
    • Simplify Identity architecture and gain in server number
    • Consider migration to PTA if with your AD FS you don’t use:
      • On-premise MFA server (MS or third parties)
      • Certificate Authentication
      • Windows Hello