(2019-12-12) Delivered Session About “Moving Towards Passwordless Concept”

Delivered session @DetronICT, invited by @ThierryVos about "Moving Towards Passwordless Concept" (preso and demos). About 30 tech enthusiasts listened until bitter end. Thanks for the invitation, and until a next time! Reward afterwards? Enjoying some beers together!

Figure 1: Initial Slide – Title/SubTitle

–

Figure 2: Introducing Me

–

Figure 3: The Agenda

–

Figure 4: The Agenda With Demos

– Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

–

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

• Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
• Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
• Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
• To generate password you can use for example: https://passwordsgenerator.net/ which supports pre-configured URLs such as
• Generate Pwd (010 – No Symbols)
• Generate Pwd (015 – No Symbols)
• Generate Pwd (016 – No Symbols)
• Generate Pwd (016 – With Symbols)
• Generate Pwd (020 – No Symbols)
• Generate Pwd (020 – With Symbols)
• Generate Pwd (030 – No Symbols)
• Generate Pwd (030 – With Symbols)
• Generate Pwd (064 – No Symbols)
• Generate Pwd (064 – With Symbols)
• Generate Pwd (128 – No Symbols)
• Generate Pwd (128 – With Symbols)
• Generate Pwd (256 – No Symbols)
• Generate Pwd (256 – With Symbols)
• Move service accounts in AD from regular service accounts to:
• Group Managed Service Accounts if possible
• …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
• …and if that’s not possible keep using regular service accounts with long and unique passwords
• If possible, increase the password length to a minimum of 15 characters for users
• Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
• Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
• Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
• Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
• When using ADFS, implement extranet lockout policy
• Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
• Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
• Decrease the use of passwords as much as possible by:

• Implementing SSO
• Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
• Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

–

Additional Resources:

• What is password-less?
• Password-less Strategy
• Password-less Protection (White Paper)
• A world without passwords with Azure Active Directory
• Enable password-less security key sign in for Azure AD
• Enable password-less sign-in with the Microsoft Authenticator app
• Windows Hello for Business

–

Hope this helps you!

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2018-04-20) Azure AD MFA Server v8.0.0.3 Has Been Released

Azure Multi-Factor Authentication Server provides a way to secure resources with MFA capabilities

–

Download "Azure Multi-Factor Authentication Server"

–

Azure Multi-Factor Authentication Server

8.0.0.3

Released: 4/9/2018

–

Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

–

Version 8.0.0.3 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

• Registration experience improvements on mobile
• Improved interaction with AD Sync
• Support for TLS 1.2 for LDAP, User Portal to Web Service SDK, and SChannel replication
• Compliance with General Data Protection Regulation
• Accessibility improvements to User Portal, MFA Server management, and installation
• Fixed issue with fallback to security questions
• Fixed issue with security questions appearing multiple times
• Miscellaneous bug fixes and improvements
• NOT MENTIONED IN RELEASE NOTES: It now DOES install on Server Core!

–

Known Issues:

• Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

–

Upgrade Considerations:

• Must upgrade MFA Server and Web Service SDK before upgrading User Portal And AD FS adapter
• All other features and components are backwards-compatible with all previous versions
• Installation of the mobile app web service is not necessary for v8.0 or higher. Complete only the steps under Configure the mobile app. After the upgrade you may want to uninstall the previous mobile app web service, remove the virtual directory and application pool from IIS. If you have published the mobile app web service, then that is not required anymore

–

More information about Azure AD MFA Server can be found here.

–

Upgrade steps can be found here, but also take the following info into account

–

For this version of the MFA server:

• you need to have MS-KB2919355 installed on the MFA server before starting the installation (check with Get-HotFix KB2919355)
• you need to have the following installed on any server with any MFA server component: The Visual C++ 2017 Redistribution packages (a.k.a. Visual C++ "14" Runtime Libraries) are also available from here
• you need to have the at least following version installed on any server with any MFA server component: .NET Framework 4.6.2 is available from here.

–

Before upgrading/installing the new ADFS adapter, you need to unselect and unregister the previous ADFS adapter

• Using WID?: Execute the commands below on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish
• Using SQL?: Execute the commands below on any ADFS server

# Unselecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders
$listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")  # Use THIS line if the old version is v6.3.0 or lower
$listOfNewMFAProviders.Remove("AzureMfaServerAuthentication")  # Use THIS line if the old version is v7.0.0.9 or higher
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Unregistering The Azure AD MFA Adapter Within ADFS
Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication  # Use THIS line if the old version is v6.3.0 or lower
Unregister-AdfsAuthenticationProvider -Name AzureMfaServerAuthentication  # Use THIS line if the old version is v7.0.0.9 or higher

–

After installing the new ADFS adapter, you need to configure it, register it and configure it within ADFS

• Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards
• Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards

FILE: MultiFactorAuthenticationAdfsAdapter.config

<ConfigurationData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <UseWebServiceSdk><true OR false></UseWebServiceSdk>

    <WebServiceSdkUrl><URL to the MFA Web Service SDK></WebServiceSdkUrl>

    <WebServiceSdkUsername><the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config></WebServiceSdkUsername>

    <WebServiceSdkPassword><the password of the account above the user portal is also using in its web.config></WebServiceSdkPassword>

    <WebServiceSdkCertificateThumbprint><thumbprint of certificate of web service sdk></WebServiceSdkCertificateThumbprint>

    <AutomaticallyTriggerUserDefaultMethod><true OR false></AutomaticallyTriggerUserDefaultMethod>

    <TestMode><true OR false></TestMode>

</ConfigurationData>

–

Now we need to register and configure the new ADFS adapter within ADFS

# Registering The Azure AD MFA Adapter Within ADFS

$typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=8.0.0.3, Culture=neutral, PublicKeyToken=f300afd708cefcd3"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication –ConfigurationFilePath "<Provide Path To MultiFactorAuthenticationAdfsAdapter.config>"

# Selecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Configuring Custom Display Name And Custom Description
Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "<Provide Custom DisplayName>" -Description "<Provide Custom Description>"

–

I upgraded from the previous version without any issues!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-06-15) Displaying The Welcome Message On The MFA Page In ADFS 2016

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

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

–

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

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

–

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

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

[Step 1]

Clone the current active ADFS web theme to a new ADFS web theme

First determine the current web theme

Get-ADFSWebConfig

Clone the current active web theme to a new web theme

New-AdfsWebTheme -Name <New Web Theme Name> -SourceName <Active Web Theme Name>

–

[Step 2]

Export the cloned web theme to a folder on the file system

Export-AdfsWebTheme -Name <New Web Theme Name> -DirectoryPath <Some Folder On The File System>

–

[Step 3]

Edit the file “onload.js” in the folder “<Some Folder On The File System>\Script” and add the following piece of code to the end of the file to show the welcome message again

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

–

[Step 4]

Import the new edited “onload.js” file

Set-AdfsWebTheme -TargetName <New Web Theme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Some Folder On The File System>\script\onload.js"}

–

[Step 5]

Activate the new web theme

Set-AdfsWebConfig -ActiveThemeName <New Web Theme Name>

–

[Step 6]

Reconfigure the explanation text if required

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

–

Now access an application through ADFS for which MFA is required

–

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

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

–

–

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

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

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

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

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

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

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

–

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

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

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

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

–

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

–

[Catch 1]

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

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

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

–

[Catch 2]

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

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

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

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

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

–

[Catch 3]

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

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

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

–

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

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

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

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

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

–

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

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

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

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

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

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

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

–

–

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-05-17) Azure AD MFA Server v7.3.0.3 Has Been Released

Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

–

Release notes: https://pfweb.phonefactor.net/install/7.3.0.3/release_notes.txt

Version 7.3.0.3 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

• AD FS adapter performance improvements
• Tags performance improvements
• Log request IDs to allow correlation with backend logs
• Modified AD sync service to clear phone numbers that are cleared in the directory
• Fix for RADIUS one-way text message fallback to OATH token
• Fix for passwords that contain leading or trailing spaces
• Fix AD FS adapter to handle cultures that aren’t associated with a locale ID
• Change mobile app references from Azure Authenticator to Microsoft Authenticator

–

Known Issues:

• Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

–

Upgrade Considerations:

• Must upgrade MFA Server and Web Service SDK before upgrading AD FS adapter
• All other features and components are backwards-compatible with all previous versions

–

More information about Azure AD MFA Server can be found here.

–

Upgrade steps can be found here, but also take the following info into account

–

For this version of the MFA server:

• you need to have MS-KB2919355 installed on the MFA server before starting the installation (check with Get-HotFix KB2919355)
• you need to have the following installed on any server with any MFA server component: The Visual C++ 2015 Update 3 Redistribution packages are also available (x86, x64),

–

Before upgrading/installing the new ADFS adapter, you need to unselect and unregister the previous ADFS adapter

• Using WID?: Execute the commands below on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish
• Using SQL?: Execute the commands below on any ADFS server

# Unselecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders
$listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")  # Use THIS line if the old version is v6.3.0 or lower
$listOfNewMFAProviders.Remove("AzureMfaServerAuthentication")  # Use THIS line if the old version is v7.0.0.9 or higher
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Unregistering The Azure AD MFA Adapter Within ADFS
Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication  # Use THIS line if the old version is v6.3.0 or lower
Unregister-AdfsAuthenticationProvider -Name AzureMfaServerAuthentication  # Use THIS line if the old version is v7.0.0.9 or higher

–

After installing the new ADFS adapter, you need to configure it, register it and configure it within ADFS

• Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards
• Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards

FILE: MultiFactorAuthenticationAdfsAdapter.config

<ConfigurationData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <UseWebServiceSdk><true OR false></UseWebServiceSdk>

    <WebServiceSdkUrl><URL to the MFA Web Service SDK></WebServiceSdkUrl>

    <WebServiceSdkUsername><the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config></WebServiceSdkUsername>

    <WebServiceSdkPassword><the password of the account above the user portal is also using in its web.config></WebServiceSdkPassword>

    <WebServiceSdkCertificateThumbprint><thumbprint of certificate of web service sdk></WebServiceSdkCertificateThumbprint>

    <AutomaticallyTriggerUserDefaultMethod><true OR false></AutomaticallyTriggerUserDefaultMethod>

    <TestMode><true OR false></TestMode>

</ConfigurationData>

–

Now we need to register and configure the new ADFS adapter within ADFS

# Registering The Azure AD MFA Adapter Within ADFS

$typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=7.3.0.3, Culture=neutral, PublicKeyToken=f300afd708cefcd3"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication –ConfigurationFilePath "<Provide Path To MultiFactorAuthenticationAdfsAdapter.config>"

# Selecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Configuring Custom Display Name And Custom Description
Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "<Provide Custom DisplayName>" -Description "<Provide Custom Description>"

–

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

(2016-05-12) Upgrading The MFA Server Components From v6.3.0 To v7.0.0

Microsoft released a newer version (v7.0.0.0) of the on-premises Azure AD MFA server a while back. If you are currently using v6.3.0, then this blog post will help you upgrade from v6.3.0 to v7.0.0.

–

First download the latest version of the Azure MFA Server installation program “MultiFactorAuthenticationServerSetup.exe”

1. Navigate to https://manage.windows.azure.com/ and login with your administrator credentials
2. On the navigation bar on left click on “All Items”
3. On the main screen click on the directory item
4. At the top of the screen click on the item called “Configure”
5. Scroll to the section called “Multi-Factor Authentication”
6. Within that section click on “Manage Service Settings” (a new tab opens)
7. At the bottom of the screen click on “Go To The Portal” (a new tab opens)
8. Somewhere in the middle of the screen click on “Downloads”
9. Somewhere in the middle of the screen click on “Download” to download the latest version of the Azure MFA Server installation program

REMARK: If this would be a first time installation, you would also need the activation credentials by clicking on “Generate Activation Credentials”. During the upgrade the Activation Credentials are not needed.

–

Move the downloaded file to the servers already running the Azure AD MFA Server bits.

Execute the following actions on every Azure AD MFA server you have. Start with the primary/master server, and when fully finished, move to the next secondary Azure AD MFA server. By the way, this does assume all Azure AD MFA server components (MFA server, Web Service SDK, User Portal and Mobile App Service) are installed on the same server, whether you have just one server or multiple servers.

Start the MFA admin console. Then click on the Status icon on the left at the top to see which servers exist. Write down the list of MFA servers

Figure 1: The MFA Admin Console Showing The Status Of Every MFA Server

–

Execute the following actions on every MFA server, but do it one at a time in the order explained below!

–

Hotfix Pre-Requisite

Make sure the hotfix MS-KBQ2919355 has been installed already. If not installed it first!

To check if the hotfix is already installed or not, execute:

Get-HotFix -Id KB2919355

Figure 2: Checking If The Hotfix MSKB-Q2919355 Is Installed

–

Installing The MFA Server Bits

Double-click on “MultiFactorAuthenticationServerSetup.exe”

You will see the warning regarding the hotfix MS-KBQ2919355.

Click [OK] to continue

Figure 3: Warning Regarding The Hotfix MSKB-Q2919355 Requirement

–

If “Visual C++ Redistributable for Visual Studio 2015 Update 1” is not installed you will see the following screen.

If your MFA servers are only allowed to connect to Azure AD for the Azure AD MFA service and you cannot connect to other URLs, download the “Visual C++ Redistributable for Visual Studio 2015 Update 1” (both x86 and x64!) yourself from https://www.microsoft.com/en-us/download/details.aspx?id=49984.

Click [Install].

Figure 4: Warning About The Pre-Requisite Installation Of “Visual C++ Redistributable For Visual Studio 2015 Update 1”

–

Check “I Agree To The License Terms And Conditions”

Click [Install].

Figure 5: Warning About The Pre-Requisite Installation Of “Visual C++ Redistributable For Visual Studio 2015 Update 1” (x64)

–

Click [Close].

Figure 6: Finishing The Installation Of “Visual C++ Redistributable For Visual Studio 2015 Update 1” (x64)

–

Check “I Agree To The License Terms And Conditions”

Click [Install].

Figure 7: Warning About The Pre-Requisite Installation Of “Visual C++ Redistributable For Visual Studio 2015 Update 1” (x86)

–

Click [Close].

Figure 8: Finishing The Installation Of “Visual C++ Redistributable For Visual Studio 2015 Update 1” (x86)

–

Click [Next >].

Figure 9: Starting The Install Of The Azure AD MFA Server Bits

–

Click [Finish].

Figure 10: Finishing The Install Of The Azure AD MFA Server Bits

–

The MFA Admin Console will start and show the following message If the user portal is installed

Click [No].

Figure 11: Notification About A Newer Version Of The User Portal

–

…and show the following message If the web service SDK is installed

Click [No].

Figure 12: Notification About A Newer Version Of The Web Service SDK

–

Close the MFA admin console

–

Updating The Web Service SDK

Navigate to the folder “C:\Program Files\Multi-Factor Authentication Server” (=default location) and double-click on “MultiFactorAuthenticationWebServiceSdkSetup64.msi”

Make sure to select the correct web site, the correct virtual directory and the correct application pool. If you are uncertain, Open up IIS Manager, select the correct virtual directory/application and through the advanced settings check the correct settings FIRST!!!

Click [Next>]

Figure 13: Configuring The Web Service SDK Installation

–

Click [Close]

Figure 14: Finishing The Installation Of The Web Service SDK

–

Update the User Portal

Navigate to the folder “C:\Program Files\Multi-Factor Authentication Server” (=default location) and double-click on “MultiFactorAuthenticationUserPortalSetup64.msi”

Make sure to select the correct web site, the correct virtual directory and the correct application pool. If you are uncertain, Open up IIS Manager, select the correct virtual directory/application and through the advanced settings check the correct settings FIRST!!!

Click [Next>]

Figure 15: Configuring The User Portal Installation

–

Click [Close]

Figure 16: Finishing The Installation Of The User Portal

–

Update the Mobile App Web Service

Navigate to the folder “C:\Program Files\Multi-Factor Authentication Server” (=default location) and double-click on “Double-click on MultiFactorAuthenticationMobileAppWebServiceSetup64.msi”

Make sure to select the correct web site, the correct virtual directory and the correct application pool. If you are uncertain, Open up IIS Manager, select the correct virtual directory/application and through the advanced settings check the correct settings FIRST!!!

Click [Next>]

Figure 17: Configuring The Mobile Web App Web Service

–

Click [Close]

Figure 18: Finishing The Installation Of The Mobile Web App Web Service

–

Configuring Applications Pools

After the installation when you open IIS manager and check the application pools, you will see the following new application pools (or similar) with the same account as the previous application pools:

• ASP.NET v4.0 MultiFactorAuthWebServiceSdk
• ASP.NET v4.0 MultiFactorAuthUserPortal
• ASP.NET v4.0 MultiFactorAuthPhoneAppWebService

–

Select the virtual directory/application “MultiFactorAuthWebServiceSdk”, click Advanced Settings on the right. Click on “Application Pool” at the top and select the application pool “ASP.NET v4.0 MultiFactorAuthWebServiceSdk”

Select the virtual directory/application “MultiFactorAuthUserPortal”, click Advanced Settings on the right. Click on “Application Pool” at the top and select the application pool “ASP.NET v4.0 MultiFactorAuthUserPortal”

Select the virtual directory/application “MultiFactorAuthPhoneAppWebService”, click Advanced Settings on the right. Click on “Application Pool” at the top and select the application pool “ASP.NET v4.0 MultiFactorAuthPhoneAppWebService”

–

Restart the “Default Web Site”.

–

Now update all other MFA servers, one at a time and in the same order as explained above!

–

Updating The ADFS Adapter

On one of the Azure AD MFA servers, navigate to the folder “C:\Program Files\Multi-Factor Authentication Server” (=default location) and copy the files “MultiFactorAuthenticationAdfsAdapterSetup64.msi” and“MultiFactorAuthenticationAdfsAdapter.config” to all ADFS servers!

–

The following actions will have a negative impact on the Azure AD MFA Provider within ADFS. It will not impact ADFS itself, but any application configured to enforce MFA whereas the users must use Azure AD MFA is not possible until everything has finished!!! THEREFORE PLAN THIS ACCORDINGLY!!!

REMARK: you may have seen the suggestion on other blog posts to remove the ADFS server from the farm to lower the impact. Do not do that! That will impact ADFS itself, and it you only have one ADFS server your farm will die!

–

First you need to understand if you are using WID or SQL. And if you are using WID, you need to find the primary ADFS server.

To understand if you are using WID or SQL see: (2014-03-17) Gathering Architectural Details From Your ADFS Infrastructure – ADFS Config DB On WID Or SQL

When using WID, to find your primary server see: (2014-03-19) Gathering Architectural Details From Your ADFS Infrastructure – WID Primary Computer Or Not

–

We need to unselect and unregister the previous ADFS adapter

Using WID?: Execute on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish

Using SQL?: Execute on any ADFS server

# Unselecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders
$listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Unregistering The Azure AD MFA Adapter Within ADFS
Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication

–

DO NOT restart the ADFS service as requested!

–

Again, execute the following on every ADFS server, starting with the primary if you are using WID, and if you are using SQL just pick a first ADFS server. After that, repeat on every other ADFS server.

–

If “Visual C++ Redistributable for Visual Studio 2015 Update 1” is not installed you will need to install it first before continuing. Unlike the Azure AD MFA server bits, the ADFS adapter v7.0.0 does not perform a pre-requisite check and does not offer to install the pre-requisites. Without it, the complete installation will succeed. However, as soon as you restart the ADFS service, the ADFS Admin logs will have errors while loading the new MFA provider due to files not found.

Navigate to https://www.microsoft.com/en-us/download/details.aspx?id=49984 and download the “Visual C++ Redistributable for Visual Studio 2015 Update 1” (both x86 and x64!). Move both files to every ADFS server you have.

–

Navigate to the folder you moved the “Visual C++ Redistributable for Visual Studio 2015 Update 1” (both x86 and x64!) to, and double-click on “VC_redist.x64.exe”. You will see the same screens as figure 5 and 6.

Navigate to the folder you moved the “Visual C++ Redistributable for Visual Studio 2015 Update 1” (both x86 and x64!) to, and double-click on “VC_redist.x86.exe”. You will see the same screens as figure 7 and 8.

–

Navigate to the folder you moved the “MultiFactorAuthenticationAdfsAdapterSetup64.msi” to, and double-click on “MultiFactorAuthenticationAdfsAdapterSetup64.msi”. This will replace the pervious adapter files and that’s OK. If you receive a notification the files are in use by the “Active Directory Federation Service”, then click continue.

Click [Next >]

Figure 19: Starting The Installation Of The ADFS Adapter For Azure AD MFA

–

Click [Close]

Figure 20: Finishing The Installation Of The ADFS Adapter For Azure AD MFA

–

Now update all other ADFS servers, one at a time and in the same order as explained above!

–

Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server

Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server

On the first yellow marked line, configure as true

On the second yellow marked line, configure the URL to the Azure AD MFA Web Service SDK

On the third yellow marked line, configure the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config

On the fourth yellow marked line, configure the password of the account above the user portal is also using in its web.config

Save the file

Figure 21: Editing The file “MultiFactorAuthenticationAdfsAdapter.config”

–

Now we need to register the new ADFS adapter

# Registering The Azure AD MFA Adapter Within ADFS
$typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=7.0.0.9, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication  -ConfigurationFilePath "MultiFactorAuthenticationAdfsAdapter.config"

DO NOT restart the ADFS service as requested!

–

If you previously configured a custom display name and a description for the Azure AD MFA adapter then do that also now. Replace the yellow marked text below with what you need/want

Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "Azure AD MFA AuthN" -Description "Phone Call, SMS, Software Based OTP Or Push Message Verified Authentication By Azure AD"

–

Now we need to select the new ADFS adapter

# Selecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

–

If you are using WID, wait first at least 5 minutes and then execute the command below (this allows WID replication to have taken place)

If you are using SQL, execute the following on any ADFS server (no need to wait as with WID)

–

Restart The ADFS Service

Restart-Service ADFSSRV -Force

–

Check the ADFS Admin Event for any error (when using WID you can expect to see an error regarding the unavailability of Artifact Resolution)

–

When everything is OK, you should be able to use the Azure AD MFA Adapter in ADFS

–

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