(2022-12-19) Ransomware And The Impact On Your Hybrid Identity Environment

For many years, organizations have been using Active Directory (AD) as their central on-premises identity directory service. Throughout those years many system and/or identity related configurations have been made to support different requirements. About just more than a decade ago Azure Active Directory (AAD) was officially released. For those organizations adopting AAD, something was needed to enable the so called hybrid identity environment consisting of AD on-premises and AAD in the cloud, in terms of authentication and identity provisioning and deprovisioning.

To support identity provisioning and deprovisioning in AAD using AD as the authoritative source, Microsoft offered the Windows Azure Active Directory connector for Forefront Identity Manager (FIM) and Microsoft Identity Manager (MIM). In addition DirSync was also offered, which was later replaced by Azure AD Sync, which was also replaced by Azure AD Connect (AADC). Today AADC is the tool to provision, and deprovision, users, groups and computers sourced from AD in AAD.

Not taking into account the order of offering, today to authenticate against AAD when having an hybrid identity environment, the following options exist, and can therefore be used:

1. Federated SSO
2. Pass-Through Authentication (PTA), with or without Seamless Sign-On
3. Password Hash Synchronization (PHS), with or without Seamless Sign-On

Now, the way to configure any of the available authentication mechanism, is through AADC wizard. The first option “Federated SSO” can be configured by yourself if you know what to do (which is not really difficult), or you can use the AADC wizard. For the last 2 options you must use the AADC wizard. The choice of an authentication method is done during the initial installation/configuration of AADC. Afterwards it is also possible to change the authentication method, and that can be done through the AADC wizard and changing the user sign-in.

Figure 1: Configuring The Authentication Mechanism, A.k.a. The User Sign-In, Through The AAD Connect Wizard For Azure AD

[AD.1] Federated SSO

When choosing Federated SSO, currently the AADC Wizard supports the configuration option to federate with either ADFS (Federation with ADFS), or Ping Federate (Federation with PingFederate). In both cases, you can also choose “Do not configure”, but then you have to configure all by yourself in the corresponding federation system. If you know what is needed and what to do, you can do this yourself, as it is really not that difficult. The latter option “Do not configure” is for sure required when you need some serious customization in the configuration of the federation systems and the processing of the rules for the relying party, a.k.a. application.

This option is most of the time chosen when an organization already has a federation system in place. When this option is chosen, the custom domain in Azure AD is configured as a federated domain. This means that when Azure AD wants to authenticate a user, that is part of a certain custom DNS domain, it will determine the domain is federated. Due to that, it will redirect authentication to the corresponding federation system. The federation system in turn authenticates the user against the directory service the user belongs to, and the user is redirected back to Azure AD.

So, in this case, Azure AD depends on the federation system and the federation system (e.g., ADFS) depends on the directory service (e.g., AD). In the case of a ransomware attack against either or both the directory service (e.g., AD) and/or the federation system (e.g., ADFS), authentication against Azure AD for federated domains DOES NOT work anymore.

What can you do about this? Well, the initial thought could be to “fix” the directory service (e.g., AD) and/or the federation system (e.g., ADFS). Unfortunately that can take some serious time, especially if it is too complex or worse if no backups are available. The best way to have a backup authentication, when using federated SSO, is to in addition enable Password Hash Sync (PHS) through AADC. More details about PHS later. As mentioned earlier, when using federated SSO, the custom DNS domain in Azure AD is configured as a federated domain and because of that, Azure AD will always redirect authentication to the federation system. To enable Azure AD to take over authentication, the federated domain needs to be converted to a managed domain. Because Azure AD, through PHS, has the on-premises password hashes, and the domain has been converted, Azure AD will be able to authenticate users, while AD and/or e.g. ADFS are not available yet. Make you test this conversion and determine the impact!!! I have seen it happen where Identity Protection kicks in after converting the domain and the user authenticates natively against Azure AD. When all is good and up and running again, you can convert the custom DNS domain back from managed to a federated domain so that AD/ADFS take over authentication again. Please do take into account the possible impact of people changing their password against Azure AD after converting from federated to a managed domain, and before converting back. When converting back, if a password change occurred, the password known by Azure AD does not match the password known by AD. If you have recovered your AD from a backup, and therefore went back in time, that is also a separate challenge on its own!

MY RECOMMENDATION: do you have and use federated SSO, and you do not have PHS enabled? Enable PHS as soon as possible for ALL synched accounts!!! Also make sure to have a tested and automated plan ready to convert the federated domains in Azure AD to managed domains, so that Azure AD can take over authentication. This will save your and your organizations bacon with regards to the usage of online services (i.e., Azure AD) and anything connected to that if you are ransomwared!

[AD.2] Pass-Through Authentication (PTA), with or without Seamless Single Sign-On

When choosing for Pass-Through Authentication (PTA), with or without Seamless Single Sign-On, organizations most likely have the following situation:

• A federated system, like e.g. ADFS, is not in place
• On-premises passwords are not allowed to be stored in Azure AD in any form
• Passwords policies should also be governed by the on-premises AD and not by Azure AD

If this is the situation or are the requirements, then most likely an organization is using PTA. With PTA, custom DNS domains in Azure AD are configured as managed, but authentication is still not done by Azure AD. PTA is not exactly something like federated SSO, but it does have some similar behavior. When PTA is enabled, Azure AD knows that authentication must be redirected towards the on-premises AD. To make sure “something” on-premises knows how to handle that authentication request, a so called PTA agent is used. After enabling PTA through AADC, the AADC server hosts the first PTA agent. You can install additional PTA agents on additional servers to support the authentication redirection load from Azure AD.

So, in this case, Azure AD depends on the PTA agents and the PTA agents depend on the directory service (e.g., AD). Looks very similar to “Federated SSO” doesn’t it? In the case of a ransomware attack against the directory service (e.g., AD), authentication against Azure AD DOES NOT work anymore.

What can you do about this? Well, the initial thought could be again to “fix” the directory service (e.g., AD). Unfortunately, as before, that can take some serious time, especially if it is too complex or worse if no backups are available. OK, but is there a backup authentication like with “Federated SSO”. Well, the answer is again PHS. But wait!!! You chose PTA because you did not want to have any form of your passwords in Azure AD, and as backup you want to use PHS. First of all, that is not even possible. And if it were possible you would be using an implementation that contradicts itself. Are you also aware that ANY server with a PTA agent, must be considered as a Tier0 server? Trust me, servers with PTA agents belong in Tier0!!!

MY RECOMMENDATION: do you have and use PTA? Then get rid of it and start using PHS AS SOON AS POSSIBLE. You may not want to have your passwords in Azure AD because you think it is a risk, right? Think about the risk and impact on your users when literally not a single user would be able to authenticate, because you chose PTA! The problem with PTA is that many think about the requirements as listed earlier, but not many think about the consequences when a ransomware attack occurs. NOT using PTA, but rather PHS instead, this will save your and your organizations bacon big time with regards to the usage of online services (i.e., Azure AD) and anything connected to that if you are ransomwared!

[AD.3] Password Hash Synchronization (PHS), with or without Seamless Sign-On

So if you are or not using “Federated SSO”, and for sure not PTA, then you must be using PHS actively or have it as a backup authentication mechanism. PHS is the best option when not having a federated system and not caring about any form of passwords being stored in Azure AD. There is even a third reason why you would want to have PHS. If you want to use the leaked credential feature of Azure AD, you MUST have PHS enabled, whether or not it is being used actively.

By default with PHS, all synched (user) accounts are in scope of synching their password hash to Azure AD. Although it is possible to only scope PHS to a specific set of groups (done through scoped sync rules in AADC), I highly DO NOT recommend that when we are talking about regular users using online services in or through Azure AD. The whole idea is about being able to use online services in or through Azure AD, when your on-premises AD has been burned to the ground due to a ransomware attack. If you think it won’t happen to you, think again. Todat, it is more about “when”, then “if”.

MY RECOMMENDATION: if you are already using PHS, that means you have chosen wisely. GOOD FOR YOU! With regards to this, there is not much extra what you can do. Just make sure it scopes your complete user population, and not just a part of it.

The moral of this story therefore is:

• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• At least enable Password Hash Sync (PHS) as a backup authentication if you are actively using a federation system for federated SSO against Azure AD
• Migrate to start using Password Hash Sync (PHS) as the primary authentication

PS: make sure you update your stakeholders, management and security officers about this, and take appropriate action as needed!

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Advertisement

(2020-07-08) Federation Metadata From ADFS Adjusted To Support “Broken” Applications

In ADFS when the primary Token Signing certificate and the primary Token Encryption certificate are going to expire you MUST start the certificate change process to change the certificates in ADFS, but also in every connected system or application.

When updating the Token Signing certificate and the Token Encryption certificate the following is important to remember:

• From a connected system/application perspective:
• Downstream federation systems care about your Token Signing certificate and Token Encryption certificate
• Upstream federation systems and application only care about your Token Signing certificate
• From a certificate perspective:
• Token Signing certificate is important for both downstream federation systems and upstream federation systems and applications
• Token Encryption certificate is important for both downstream federation systems only

–

How you get the certificates to these systems and applications depends on your process, but in general:

1. The federation metadata URL from ADFS is consumed
2. The federation metadata from an XML file is consumed, after exporting it from the URL
3. The certificates, in some format, are consumed by the application

–

Let’s focus on the first and second option.

–

By default:

• ADFS publishes the federation metadata through the following URL: /federationmetadata/2007-06/federationmetadata.xml">/federationmetadata/2007-06/federationmetadata.xml">https://<Federation Service FQDN>/federationmetadata/2007-06/federationmetadata.xml
• ADFS publishes ALL configured Token Signing certificates in the federation metadata, in the order from oldest to most recent (changing from primary to secondary or vice versa DOES NOT influence the order in the federation metadata!)
• ADFS only publishes the configured primary Token Encryption certificate in the federation metadata
• ADFS signs the federation metadata with the configured primary Token Signing certificate

–

In my TEST environment I have configured my ADFS server with 5 Token Signing certificates, so that it is as clear as possible.

–

The federation metadata contains 4 sections/nodes where all the Token certificates are specified:

• The ‘RoleDescriptor’ Node For The Type Of ‘fed:ApplicationServiceType’ Containing Only The Primary Token Encryption Certificate (not displayed below, as it is not important for this scenario)
• The ‘RoleDescriptor’ Node For The Type Of ‘fed:SecurityTokenServiceType’ Containing All Token Signing Certificates (displayed in figure 1)
• The ‘SPSSODescriptor’ Node Containing All Token Signing Certificates And The Primary Token Encryption Certificate (displayed in figure 2)
• The ‘IdPSSODescriptor’ Node Containing All Token Signing Certificates And The Primary Token Encryption Certificate (displayed in figure 3)

Figure 1: The ‘RoleDescriptor’ Node For The Type Of ‘fed:SecurityTokenServiceType’ Containing All Token Signing Certificates

–

Figure 2: The ‘SPSSODescriptor’ Node Containing All Token Signing Certificates (And The Primary Token Encryption Certificate)

–

Figure 3: The ‘IdPSSODescriptor’ Node Containing All Token Signing Certificates (And The Primary Token Encryption Certificate)

–

Now the following scenarios are possible when consuming the federation metadata:

1. All Token Signing certificates are read and all are consumed by the application – The import of the federation metadata in the application can be done at ANY time!
2. All Token Signing certificates are read and and only the LAST occurrence is consumed by the application – The import of the federation metadata in the application must only be done right after the switch of the Token Signing certificates (i.e. the newest secondary Token Signing certificate becomes the new primary Token Signing certificate)
3. All Token Signing certificates are read and and only the FIRST occurrence is consumed by the application – The import of the federation metadata in the application must only be done right after the switch of the Token Signing certificates (i.e. the newest secondary Token Signing certificate becomes the new primary Token Signing certificate) AND the imported federation metadata MUST be adjusted before the import!

–

Preferably the application behaves like [1]. That is the BEST option without any issues. If that is not possible, it at least behaves like option [2], which requires somewhat more control and planning. With option [3], my opinion is that the application is by default broken and does not adhere to best practices. The person that build it, did not get it how things work.

–

As with option [3] the application only consumes the first Token Signing Certificate and ignores all others, the only way to make it read the last occurrence of the Token Signing certificate as the first one, is by removing all other occurrences. Looking at any of the pictures above, that means you need to remove all the occurrences of the section “<KeyDescriptor use="signing">…</KeyDescriptor>” before the LAST (newest) Token Signing certificate. You can do this either manually or through PowerShell

Through PowerShell, you can use the following script and command line option to remove all the Token Signing certificate occurrences, except the last occurrence, from the XML federation metadata file:

Invoke-Command -ScriptBlock {
    # Get The Date And Time
    $execDateTime = Get-Date
    $execDateTimeCustom = Get-Date $execDateTime -Format "yyyy-MM-dd_HH.mm.ss"

    # Federation Service FQDN
    $federationServiceFQDN = "<Federation Service FQDN>" # e.g. "FS.COMPANY.COM"  

    # Folder Path For The Federation Metadata XML File
    $fedMetadataXMLFolderPath = "<Folder Path For The Federation Metadata XML File>" # e.g. "C:\TEMP"

    # File Path For The Federation Metadata XML File(s)
    $fedMetadataXMLFilePath = Join-Path $fedMetadataXMLFolderPath $($federationServiceFQDN + "_FederationMetadata_" + $execDateTimeCustom + ".xml")
    $fedMetadataXMLLastTSOnlyFilePath = Join-Path $fedMetadataXMLFolderPath $($federationServiceFQDN + "_FederationMetadata_" + $execDateTimeCustom + "LastTSOnlyNoSignature.xml")

    # URL for the federation metadata: https://<Federation Service FQDN>/federationmetadata/2007-06/federationmetadata.xml
    $fedMetadataURL = "https://$federationServiceFQDN/federationmetadata/2007-06/federationmetadata.xml"

    # Download The Metadata To An XML File
    $webClient = New-Object System.Net.WebClient
    $webClient.DownloadFile($fedMetadataURL, $fedMetadataXMLFilePath)

    # Read The Downloaded XML Metadata File And Define Several Variables With Namespace Info
    $fedMetadataXMLMetadata = [xml](Get-Content $fedMetadataXMLFilePath)
    $xmlnamespace = $fedMetadataXMLMetadata.EntityDescriptor.xmlns
     $xmlds = $fedMetadataXMLMetadata.EntityDescriptor.Signature.ds
    $xmlxsi = $fedMetadataXMLMetadata.EntityDescriptor.RoleDescriptor[0].xsi
    $xmlfed = $fedMetadataXMLMetadata.EntityDescriptor.RoleDescriptor[0].fed
    $namespace = @{xmlnamespace = $xmlnamespace;xmlds = $xmlds;xmlxsi = $xmlxsi;xmlfed = $xmlfed}
    $ns = New-Object System.Xml.XmlNamespaceManager($fedMetadataXMLMetadata.NameTable)
    $ns.AddNamespace("xmlnamespace", $xmlnamespace)
    $ns.AddNamespace("xmlds", $xmlds)
    $ns.AddNamespace("xmlxsi", $xmlxsi)
    $ns.AddNamespace("xmlfed", $xmlfed)

    # Save The Original Federation Metadata File So That It Has Prettier Format
    $fedMetadataXMLMetadata.Save($fedMetadataXMLFilePath)

    # Get The Nodes For The Role Descriptor And Count The Number Of Occurences Of The Token Signing Certificate
    $roleDescriptorTSCerts = Select-Xml -Xml $fedMetadataXMLMetadata -XPath $("/xmlnamespace:EntityDescriptor/xmlnamespace:RoleDescriptor[@xmlxsi:type=’fed:SecurityTokenServiceType’]/xmlnamespace:KeyDescriptor[@use=’signing’]") -Namespace $namespace
    $roleDescriptorTSCertsCount = $roleDescriptorTSCerts.Count

    # Start And End Iteration Point
    $start = $roleDescriptorTSCertsCount – 2
    $end = 0

    # Get The Parent Node Of The Token Signing Certificate Nodes In The Role Descriptor And The Specified Token Signing Certificates
    $roleDescriptorTSCertsParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:RoleDescriptor[@xmlxsi:type=’fed:SecurityTokenServiceType’]", $ns)
    $roleDescriptorTSCertsData = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:RoleDescriptor[@xmlxsi:type=’fed:SecurityTokenServiceType’]/xmlnamespace:KeyDescriptor[@use=’signing’]", $ns)

    # Process And Delete All Ocurrences Of The Token Signing Certificate Except Last Token Signing Certificate
    For ($i = $start; $i -ge $end; $i–) {
        $roleDescriptorTSCertsParent.RemoveChild($roleDescriptorTSCertsData[$i]) | Out-Null
    }

    # Get The Parent Node Of The Token Signing Certificate Nodes In The IDP Descriptor And The Specified Token Signing Certificates
    $idpSSODescriptorTSCertsParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:IDPSSODescriptor", $ns)
    $idpSSODescriptorTSCertsData = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:IDPSSODescriptor/xmlnamespace:KeyDescriptor[@use=’signing’]", $ns)

    # Process And Delete All Ocurrences Of The Token Signing Certificate Except Last Token Signing Certificate
    For ($i = $start; $i -ge $end; $i–) {
        $idpSSODescriptorTSCertsParent.RemoveChild($idpSSODescriptorTSCertsData[$i]) | Out-Null
    }

    # Get The Parent Node Of The Token Signing Certificate Nodes In The SP Descriptor And The Specified Token Signing Certificates
    $spSSODescriptorTSCertsParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:SPSSODescriptor", $ns)
     $spSSODescriptorTSCertsData = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:SPSSODescriptor/xmlnamespace:KeyDescriptor[@use=’signing’]", $ns)

    # Process And Delete All Ocurrences Of The Token Signing Certificate Except Last Token Signing Certificate
    For ($i = $start; $i -ge $end; $i–) {
        $spSSODescriptorTSCertsParent.RemoveChild($spSSODescriptorTSCertsData[$i]) | Out-Null
    }

    # Remove The DS Signature Data From The XML Federation Metadata File
    $dsSignatureDataParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor", $ns)
    $dsSignatureData = $fedMetadataXMLMetadata.SelectSingleNode("/xmlnamespace:EntityDescriptor/xmlds:Signature", $ns)
    $dsSignatureDataParent.RemoveChild($dsSignatureData) | Out-Null

    # Save The Adjusted Federation Metadata File
    $fedMetadataXMLMetadata.Save($fedMetadataXMLLastTSOnlyFilePath)

    # Display The File Paths
    Write-Host ""
    Write-Host "Original Federation Metadata File………………: $fedMetadataXMLFilePath" -ForegroundColor Magenta
    Write-Host "Adjusted Federation Metadata File (Last TS only)…: $fedMetadataXMLLastTSOnlyFilePath" -ForegroundColor Magenta
    Write-Host ""
}

This will export the original federation metadata to a file with the XML extension.

This will also export the adjusted federation metadata, with only the last Token Signing certificate, and the signature removed to a file with the XML extension.

REMARK: as mention above, ADFS signs the federation metadata with the primary Token Signing certificate to ensure its authenticity. By removing data from the federation metadata XML file, you basically break the signature as it does not match the data in the federation metadata. If the application consuming the XML federation metadata file does not check the signature, then that is not a problem. If it does check the signature, you also need to remove the “<ds:Signature>…</ds:Signature>” section/node. If the application requires a signed XML federation metadata file, then you have a problem. ADFS will only publish the last Token Signing certificate (the newest primary) after the previous primary Token Signing certificate has been removed AFTER it has become a secondary Token Signing certificate.

–

Have fun!

–

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

(2020-04-19) It’s That Time Again, You Need To Roll-Over The Certificates In ADFS

This weekend I was involved in rolling over the ADFS Token Signing and Token Encryption certificates while a huge amount of application were connected using WS-Federation, SAML or OAuth. With regards to rolling over the certificates, only the WS-Federation and SAML based apps are impacted, not the OAuth apps.

Short answer: preparation, communication and automation are KEY!

–

This ADFS system was designed and implemented by me years ago. In the beginning, there were just a few apps and it grew gradually. After a moment it was starting to grow like crazy. More and more app devs smelled the federated SSO cool stuff and wanted that for their app(s). Why? Default globally supported protocols between organizations, apps, etc, and all based on federation. Supported by ADFS, many other on-premises federation systems and cloud based systems, such as e.g. Azure AD. The focus of this blog post is apps connected to ADFS as the federation provider, for both downstream identity providers and upstream service providers.

–

When I design this system, after the technology, I also designed the required processes to make sure the technology was used in the correct way. If you do not design the processes in addition to the technology, it becomes a mess and because certificates are used it will drop dead, exactly 1 year after installing/configuring it. Why will it drop dead after 1 year? The default Token Signing and Token Encryption certificates are ADFS managed and expire after 1 year. All apps not (being) able to consume to the federation metadata URL automatically will drop dead if no action is taken in time! And rushing with no process in place is a good cocktail for possible failure. If you have a handful of apps, you should be OK, but if you have 100+, or 200+ or even more apps connected to ADFS, you seriously need a process to get this done in time and correctly. Regarding the process, that ADFS has internally, please see: (2013-05-14) ADFS Managed Certificates Supporting Auto Certificate Rollover

–

Processes:

• Backup/Export of the complete ADFS configuration
• Provisioning of applications onto ADFS
• Recertification of any connected application, keep or deprovision
• Notification of expiring certificates in ADFS (about 3 months ahead of time)
• Certificate change in ADFS
• Validation of specified e-mail addresses against AD

–

During the onboarding of ANY application the following was recorded:

1. Does an application support automatic consumption of the federation metadata URL or does it support its consumption manually through an XML file?
2. Does an application support just 1 or 2 Token Signing certificates from an identity provider?
3. When an application supports the consumption of the federation metadata file, AND it supports only 1 Token Signing certificate, which certificate will it consume when it reads the federation metadata file as it contains multiple Token Signing certificates from the identity provider
4. E-mail addresses from at least 3 “owners”
5. E-mail address of either a functional mailbox or distribution list with a support team behind

–

[AD.1]

If it supports automatic consumption of federation metadata through a URL (for ADFS: /federationmetadata/2007-06/federationmetadata.xml">https://<federation service FQDN>/federationmetadata/2007-06/federationmetadata.xml) it processes the information automatically. If it does not, you may need to first export the federation metadata to an XML file to be able to import it into the application. Even though the federation metadata URL is used, it does not mean an application uses it automatically on a regular basis (e.g. every day). It is possible that a admin need to run a script, or push some button or whatever

–

[AD.2]

If an application supports 2 Token Signing certificates from an identity provider, a smooth certificate rollover is supported without ANY pain. If only 1 Token Signing certificate is supported it means, the certificate must be replaced at (nearly) the same time as the ADFS admin switches the primary and secondary Token Signing certificate

–

[AD.3]

This scenario should be very rare, but unfortunately some apps do it incorrectly. When the federation metadata from the identity provider is imported, and only 1 Token Signing certificate is used, and the federation metadata from the identity provider contains multiple Token Signing certificates, which is consumed (used) by the application? The first Token Signing certificate occurrence, or the last occurrence? If it is the last occurrence, then that is good, but the federation metadata XML file must only be imported at the same time when the switch is made in ADFS. If it is the first occurrence, then the app is not following best practice and it will break as soon as the switch in ADFS is done.

ADFS by default:

• Publishes ALL Token Signing certificates in the federation metadata
• The oldest Token Signing certificate is published first and the newest Token Signing certificate is published last
• Switching Token Signing certificates in ADFS DOES NOT change the order of the Token Signing certificates in the federation metadata
• Publishes only the primary (active) Token Encryption certificate in the federation metadata
• Switching Token Encryption certificates in ADFS removes the old Token Encryption certificate from the federation metadata, and adds the new Token Encryption certificate to the federation metadata
• ADFS signs the federation metadata with the primary (active) Token Signing certificate

So if the first occurrence of the Token Signing certificate is consumed, after the switch in ADFS, the only way to solve this is:

• Edit the federation metadata XML file and remove the first occurrence of the Token Signing certificate (old Token Signing certificate, marked as “use=’signing’”, appears 3 times in the federation metadata XML), and keep the last occurrence (the newest) Token Signing certificate
  OR
• Remove the oldest Token Signing certificate as a secondary from ADFS, export the federation metadata to an XML file and import it into the application

Which option you use depends on whether or not an application checks for the signing of the federation metadata. If it does not, you can use either option, but it is easier to edit and you can keep the old Token Signing certificate as secondary if for whatever unlikely reason want to rollback (not recommended when having many applications (define “many”!) as it may turn out in a logistics nightmare

–

[AD.4]

A minimum of three e-mail addresses are required to support the yearly recertification process where a decision is made to either keep or deprovision the federation trust in ADFS. A minimum of three mail addresses as people come and people go (internally or externally), and chances are very low that all three people move at the same time (unless there is a reorganization, sigh!). If any of the listed people changes roles

–

[AD.5]

The e-mail address of a functional mailbox or distribution list with people from a (technical) support team behind it. This is mainly used by the “Certificate Change in ADFS” process. The chance of failure must be brought to a minimum by not having dependency of e-mail addresses from people, but rather have e-mail address of a functional mailbox or distribution list with people behind it. The people from a (technical) support team are responsible to updating the application with the new Token Signing when ADFS changes the certificate.

–

Now having all this information, you need to be able to store it somewhere that makes it easily manageable and provides the ability to process it through scripting (automation). Within ADFS, every single trust has a notes or description field, and the field can perfectly be used to store this information. However it is a string formatted field with a maximum of 3000 characters. I thought of the idea to implement an XML structure to be able to read from and write to it as needed. Works like magic as we can script against it too. But how about using CMDB? Well, we wanted to be certain of the up-to-date-ness of the information, we wanted to be able to script against it and we wanted it as close as possible to the trust configuration in ADFS.

–

Now, the whole certificate change in ADFS looks like something similar to:

1. Define "Product Backlog Items (PBI)" on the backlog, plan into sprints and assign to people
2. Organize initial meeting with colleagues to explain process, answer any questions and discuss PBIs
3. Plan meeting with (higher) management and deliver a presentation about the certificate change, discussing what, when, why, how, current state (number of trusts), risks, impact, rollback (none!), etc.
4. Raise an RFC to change certificates in ADFS and push to achieve the highest risk/impact category possible
5. Check and fix if needed e-mail addresses from application owners and support teams
6. Request new certificates for ADFS (SSL, Token Signing and Token Encryption)
7. Install all new certificates in the personal certificate store of all ADFS servers
8. Install the new SSL certificate in the personal certificate store of all WAP servers
9. Configure the new Token Signing certificate as a secondary Token Signing certificate
10. Configure the new Token Encryption certificate as a secondary Token Encryption certificate
11. Configure the new Svc Comm/SSL Certificate on all ADFS servers and WAP servers
12. Recheck and fix if needed e-mail addresses from application owners and support teams
13. Send the "First Notification" to all support teams and application owners
14. Notify the global service committee about the upcoming change, provide information and request to chase teams/owners
15. Send the "Reminder Notification" to all support teams and application owners
16. Switch the Token Signing/Encryption Certificate in ADFS
17. Send the "Switch Executed Notification" to all support teams and application owners
18. Guide and support support teams and application owners that request or needed guidance
19. Organize a closure meeting with colleagues to discuss any feedback from support teams and application owners, colleagues involved, and if applicable possible improvements for the process
20. Process the feedback and improvements from the closure meeting for the next time

–

End Result: SUCCESS! Oops I did it again!

–

I have done this multiple times now, and even though there is nothing to it (that’s what I think!) it is always exciting due to the huge amount of applications involved! The most difficult part is explaining this to non-technical people where you have to say things like: “there is no rollback”, “there will be issues with apps”, “fix forward only”, etc. It just scare the crap out of them and I understand that. Another one not to forget is, the support team, and sometimes even the vendor or service provideers, managing the application do not have the technical knowledge regarding federation and SSO

–

But, been there, done that, got the t-shirt, all sizes and all colours!

–

–

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-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-11-24) Do You Really Need The IdP Initiated Sign On Page Enabled?

Did you know, that if you navigate to https://<Your Federation Service FQDN>/adfs/ls/idpinitiatedsignon.aspx, and you see a page similar to the one below, that you have enabled the IdP initiated Sign Web Page in ADFS?

Figure 1: IdP Initiated Sign On Web Page In ADFS – ENABLED

–

If not mistaken, the IdP Initiated Sign On web page is disabled by default. There is NO NEED to enabled that web page to use IdP Initiated Sign On. You only need to enabled that webpage if you really want to use the web page! Why is this difference so important? Having the web page enabled, discloses all the SAML based applications that are connected to ADFS and you nay not want to do that.

To enable or disable it, please see (2014-10-24) Enabling IdP Initiated Sign-On In ADFS

–

If you see te following web page….

Figure 2: IdP Initiated Sign On Web Page In ADFS – DISABLED

–

–

Figure 3: Event In The ADFS Admin Event Log Regarding The IdP Initiated Sign On Web Page In ADFS Being Used While Disabled

–

Encountered error during federation passive request.

Additional Data

Protocol Name:
 

Relying Party:
 

Exception details:
Microsoft.IdentityServer.Web.IdPInitiatedSignonPageDisabledException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
   at Microsoft.IdentityServer.Web.Protocols.Saml.IdpInitiatedSignOnRequestSerializer.ReadMessage(WrappedHttpListenerRequest httpRequest)
   at Microsoft.IdentityServer.Web.Protocols.Saml.HttpSamlMessageFactory.CreateMessage(WrappedHttpListenerRequest httpRequest)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

–

So how can you still use IdP Initiated Sign On?

You can use the following URL for IdP initiated Sign On: https://<Your Federation Service FQDN>/adfs/ls/idpinitiatedsignon.aspx?loginToRp=<Application Identifier>

Please be aware that the connected application MUST support IdP initiated Sign On for this to work. The identifier is an URI that may look like a URL or something else.

–

And here you can see IdP Initiated Sign On still works after disabling the IdP Initiated Sign On Page.

Figure 4: Using IdP Initiated Sign On Using The loginToRp Parameter

–

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

(2019-07-30) ADFS Security: Disable WS-Trust Windows Transport Endpoints On PROXYs/WAPs (Extranet)

Due to a known security vulnerability it is highly recommended that the WS-Trust Windows Transport Endpoints are disabled on the ADFS Proxies/WAPs (from the extranet). Be careful though that these endpoints are needed by Windows 10 and Windows Server 2016 and higher on the INTRANET side of ADFS to leverage Azure AD Domain Join, a.k.a. Hybrid Azure AD Domain Join (HAADJ). For more detail please see the section “ADFS Endpoints” in the blog post (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail

When enabled on the EXTRANET side, it will allow NTLM logins to be processed from the extranet. As a result, it will bypass AD FS lockout protections and allow brute force password attacks or account lockouts on the user account, which of course is something you do not want! Also check out: Best practices for securing Active Directory Federation Services – ADFS Endpoints

–

What do you need to do?

–

Check the status of the WS-Trust ‘2005’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed. You can do that through the following PowerShell commands. When using SQL you can run the commands on any ADSF server. When using WID you need to run the commands on the primary ADFS server.

Clear-Host
$adfsWSTrust2005EndpointPath = "/adfs/services/trust/2005/windowstransport"
$adfsWSTrust2005 = Get-AdfsEndpoint -AddressPath $adfsWSTrust2005EndpointPath
If ($adfsWSTrust2005.Enabled -eq $true) {
    Write-Host ""
    Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The INTRANET Is ENABLED…" -ForegroundColor Green
    If ($adfsWSTrust2005.Proxy -eq $true) {
        Write-Host ""
        Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is ENABLED…" -ForegroundColor Red
        Write-Host "Due To A Security Vulnerability It Is Highly Recommended To Disable This Endpoint On The Extranet Side Of ADFS!…" -ForegroundColor Red
        Write-Host ""
        $confirmationAdfsWSTrust2005 = Read-Host "Do You Want To Disable This Endpoint On The Extranet Side? [Yes|No]"
        If ($confirmationAdfsWSTrust2005.ToUpper() -eq "YES" -Or $confirmationAdfsWSTrust2005.ToUpper() -eq "Y") {
            Set-AdfsEndpoint -TargetAddressPath $adfsWSTrust2005EndpointPath -Proxy $false           
            Write-Host ""
            Write-Host "Action Confirmed…" -ForegroundColor Green
            Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Has Been DISABLED…" -ForegroundColor Green
            Write-Host ""
        } Else {
            Write-Host ""
            Write-Host "Action Not Confirmed…" -ForegroundColor Yellow
            Write-Host "Nothing Was Changed…" -ForegroundColor Yellow
            Write-Host ""
         }
    } Else {
        Write-Host ""
        Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is DISABLED…" -ForegroundColor Green
        Write-Host "Nothing To Do Here!…" -ForegroundColor Green
        Write-Host ""
    }
} Else {
    Write-Host ""
    Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The INTRANET Is DISABLED…" -ForegroundColor Green
    Write-Host "Therefore, WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is Also DISABLED…" -ForegroundColor Green
    Write-Host "Nothing To Do Here!…" -ForegroundColor Green
    Write-Host ""
}

Figure 1: Checking Status Of The WS-Trust ‘2005’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed

–

Check the status of the WS-Trust ‘13’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed. You can do that through the following PowerShell commands:

Clear-Host
$adfsWSTrust13EndpointPath = "/adfs/services/trust/13/windowstransport"
$adfsWSTrust13 = Get-AdfsEndpoint -AddressPath $adfsWSTrust13EndpointPath
If ($adfsWSTrust13.Enabled -eq $true) {
     Write-Host ""
     Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The INTRANET Is ENABLED…" -ForegroundColor Green
     If ($adfsWSTrust13.Proxy -eq $true) {
         Write-Host ""
         Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is ENABLED…" -ForegroundColor Red
         Write-Host "Due To A Security Vulnerability It Is Highly Recommended To Disable This Endpoint On The Extranet Side Of ADFS!…" -ForegroundColor Red
         Write-Host ""
         $confirmationAdfsWSTrust13 = Read-Host "Do You Want To Disable This Endpoint On The Extranet Side? [Yes|No]"
         If ($confirmationAdfsWSTrust13.ToUpper() -eq "YES" -Or $confirmationAdfsWSTrust13.ToUpper() -eq "Y") {
             Set-AdfsEndpoint -TargetAddressPath $adfsWSTrust13EndpointPath -Proxy $false           
             Write-Host ""
            Write-Host "Action Confirmed…" -ForegroundColor Green
             Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Has Been DISABLED…" -ForegroundColor Green
             Write-Host ""
         } Else {
             Write-Host ""
             Write-Host "Action Not Confirmed…" -ForegroundColor Yellow
             Write-Host "Nothing Was Changed…" -ForegroundColor Yellow
             Write-Host ""
        }
     } Else {
         Write-Host ""
         Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is DISABLED…" -ForegroundColor Green
         Write-Host "Nothing To Do Here!…" -ForegroundColor Green
         Write-Host ""
     }
} Else {
     Write-Host ""
     Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The INTRANET Is DISABLED…" -ForegroundColor Green
     Write-Host "Therefore, WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is Also DISABLED…" -ForegroundColor Green
     Write-Host "Nothing To Do Here!…" -ForegroundColor Green
     Write-Host ""
}

Figure 2: Checking Status Of The WS-Trust ‘13’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed

–

After doing this, you need to restart the ADFS service so that it consumes the configuration change. It is recommended to do this on one ADFS server at a time and not all at the same time. If you have a load balancer, it should determine when the ADFS service is being started, that ADFS server is (temporarily) unavailable. If you do not have a load balancer, you really need to plan this accordingly!

Restart-Services ADFSSRV

–

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

(2019-05-25) Windows Hello For Business (WH4B) Bootstrapping

A few months ago I configured and implemented Windows Hello For Business (WH4B) using the “Hybrid AAD Joined Certificate Trust”. I chose this method over the “Hybrid AAD Joined Key Trust” because we did not have W2K16 DCs yet and we did have an ADFS deployment. This choice was really easy due to the lack of W2K16 DCs, otherwise we most likely would have chosen “Hybrid AAD Joined Key Trust” over “Hybrid AAD Joined Certificate Trust”.

–

Before going all crazy, we decided to start easy and implement it on a very limited scale scoped to specific Windows 10 computers and specific users. We created a small list of users (less than 10) and that list contained users logging on through username and password and users logging on through smartcard and pin.

–

To be able to implement this, we had to satisfy the following prerequisites:

• AAD subscription
• AD

• W2K8R2 DCs or higher (+DFL/FFL)
• W2K16 AD schema
• Configuration to support Hybrid Azure AD Domain Join
• Security group to scope computers and permission computer based GPO
• Security group to scope usersand permission user based GPO

• PKI infrastructure running on W2K12 or higher as trust anchor

• Certificate Template to issue Kerberos AuthN certificate for DCs through auto enrolment (and therefore correct permissioning!)
• Certificate Template to issue Registration Authority certificate for ADFS through auto enrolment (and therefore correct permissioning!)
• Certificate Template to issue WH4B AuthN certificate for clients by ADFS through auto enrolment  (and therefore correct permissioning!)
• DCs need certificate to be trusted by clients
• Users need authentication certificates distributed through ADFS registration authority (RA)
• Certificate Templates need to be configured with at least W2K12 or higher certificate authority support to be able to configure the correct provider and algorithm in the cryptography TAB

• AAD Connect, no DirSync and no AAD Sync

• Configuration to support Hybrid Azure AD Domain Join
• Device writeback

• To writeback the values in "msDS-KeyCredentialLink" on AD user account, RP/WP permissions are needed on that attribute. That can be done in a custom manner like assigning a custom group those permissions whereas that custom group may already have other permissions to read/write, or the AD connector account is added to the "KeyAdmins" group in AD

• ADFS

• Configuration to support Hybrid Azure AD Domain Join
• ADFS 2016 or higher as a registration authority
• Device authentication enabled at global level
• Configured as registration authority with the correct certificate templates for RA and WH4B

• Enrolment through username/password AND some form of MFA (AAD MFA Cloud, ADFS with AAD MFA Cloud/On-prem, ADFS with 3rd party MFA, etc)
• Windows 10 v1703 or higher
• Win10 Devices joined to AD and AAD, a.k.a. Hybrid Azure AD Domain Joined
  

–

While everything was in place, we were good to go!

–

Users logging on with username and password should see the following screen:

Figure 1: Windows Hello For Business Initial Provisioning Screen After Logging On With Username And Password

–

Users logging on with smartcard and pin should also see the same screen right after logging on, but they did not. Damn!

Let the troubleshooting begin!

After provisioning, looking at the PRTs through DSREGCMD /STATUS

Figure 2: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = NO

–

Figure 3: NGC Prerequisite Check: No ADFS Refresh Token

–

OK, it is clear there is no ADFS PRT, which IS a requirement for WH4B, hence why it fails

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. Save the correlation ID somewhere as you will need that later!

Figure 4: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

Http request status: 401. Method: POST Endpoint Uri: https://fs.iamtec.nl/adfs/oauth2/token/ Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with no correlation ID and a small hint of where things might be wrong. Nevertheless, still not clear enough!

Figure 5: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

OAuth response error: interaction_required
Error description: MSIS9699: GlobalAuthenticationPolicy on the Server doesn’t allow this OAuth JWT Bearer request. Please contact the administrator to update the GlobalAuthenticationPolicy.
CorrelationID:

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. If you look carefully, you will see it is the same correlation ID and in figure 4. Save the correlation ID somewhere as you will need that later, if you have not done that already!

Figure 6: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

Enterprise STS Logon failure. Status: 0xC0000250 Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

–

In your face, no WH4B for you as authN against ADFS failed for some reason!

Figure 7: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log

–

Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Yes
Enterprise user logon certificate template is : Yes
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.

–

On the ADFS server you will most likely find events similar to the ones below. Look at the event with the same correlation ID. If you have multiple ADFS servers, either check all ADFS servers for events with the same correlation ID, or check some central SIEM solution, or use PowerShell to query all ADFS servers, or configure your client to point to one specific ADFS server by temporarily configuring the HOSTS file.

Figure 8: ADFS Server Side: Errors In The “Applications And Services Log\AD FS\Admin” Event Log

–

And there is the reason! Certificate Authentication is NOT enabled on the intranet for primary authN! What the heck. Did not expect this one. I would expect that Windows Authentication on the intranet as primary authN would be enough for this to work, Apparently it explicitly needs the authN method to be enabled that is being used at logon.

Figure 9: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

–

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

–

And there is the reason again! Certificate Authentication is NOT enabled on the intranet for primary authN!

Figure 10: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

–

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
   at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.Validate()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.ProcessJWTBearerRequest(OAuthJWTBearerRequestContext jwtBearerContext)

–

It will not get more explicit than this! If all error were like this!

In this case when logging on with smartcard and pin and to be able to start WH4B provisioning, Certificate Based Authentication needs to be enabled at the INTRANET level in ADFS.

For that you can use the following PowerShell commands:

Get-AdfsGlobalAuthenticationPolicy
$currentListOfProvidersForPrimaryAuthNForIntranet = (Get-AdfsGlobalAuthenticationPolicy).PrimaryIntranetAuthenticationProvider
If ($currentListOfProvidersForPrimaryAuthNForIntranet -notcontains "CertificateAuthentication") {
    $newListOfProvidersForPrimaryAuthNForIntranet = $currentListOfProvidersForPrimaryAuthNForIntranet + "CertificateAuthentication"
    Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider $newListOfProvidersForPrimaryAuthNForIntranet
}
Get-AdfsGlobalAuthenticationPolicy

Figure 11: Configuring The ADFS Global Authentication Policy – Providers For Primary Authentication For The Intranet

–

Now logging off and logging back on again, you should see the following screen:

Figure 12: Windows Hello For Business Initial Provisioning Screen After Logging On With Smartcard And PIN

–

PS: Look for differences when a user logs on with username and password!

After provisioning, looking at the PRTs through DSREGCMD /STATUS

Figure 13: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = YES

–

Figure 14: NGC Prerequisite Check: No ADFS Refresh Token

–

At PRT level, everything is looking good now!

–

Enjoy and have fun!,

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-05-22) Some Basic Steps For Troubleshooting PRTs

In Windows 10 currently there are 2 PRTs:

• The Azure AD Primary Refresh Token
• And the Enterprise Primary Refresh Token, a.k.a. the ADFS Primary Refresh Token

–

For both the following troubleshooting steps apply if you are experiencing issues somehow:

• Always check the output of: DSREGCMD.EXE /STATUS
• Event Logs to check on the client:
• “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log
• “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log
• Any correlation ID in any event related to the error experienced on the client, can most like also be found at server side in the corresponding event log. If server side is AAD, then you need Microsoft. If server side is ADFS, then you can check it yourself
• Changing or resetting the password, invalidates the current PRTs and fresh ones are retrieved/generated
• If a PRT is missing, triggering to try to retrieve a PRT can be done by either logoff/logon or lock/unlock

–

With this information you should have a good start to try troubleshooting PRT related issues, although not always easy!

Do not forget to also read Jairo’s blog post about how SSO works in Windows 10

–

Enjoy and have fun!,

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-03-06) Will WAP v3.0 Work With ADFS v4.0 Or Later?

Will it work to have WAP v3.0 (WAP in Windows Server 2012 R2) in an ADFS v4.0 Farm (ADFS in Windows Server 2016) during an upgrade/migration scenario?

Yes, it will, even if you increase the ADFS Farm Level! There is a “BUT”, and that is it will depend on what you are using!

–

Some examples

If you are just publishing applications and doing your thing as you were with the ADFS v3.0 Farm, you are OK to go.   

Figure 1: WAP v3.0 Successfully Retrieving Its Config From An ADFS v4.0 Farm

–

The federation server proxy successfully retrieved its configuration from the Federation Service ‘FS.IAMTEC.NL’.

–

Figure 2: WAP v3.0 Successfully Added/Removed The Listed Endpoints

–

The AD FS proxy service made changes to the endpoints it is listening on based on the configuration it retrieved from the Federation Service.

Endpoints added:
https://+:443/FederationMetadata/2007-06/
https://+:443/adfs/ls/
https://+:49443/adfs/ls/
https://+:443/adfs/oauth2/token/
https://+:443/adfs/oauth2/logout/
https://+:443/adfs/oauth2/authorize/
https://+:49443/adfs/oauth2/authorize/
https://+:443/adfs/oauth2/devicecode/
https://+:443/adfs/oauth2/deviceauth/
https://+:443/adfs/.well-known/openid-configuration/
https://+:443/adfs/discovery/keys/
https://+:443/EnrollmentServer/
https://+:443/adfs/portal/
https://+:49443/adfs/portal/
https://+:443/adfs/portal/updatepassword/
https://+:443/adfs/userinfo/
https://+:443/adfs/services/trust/2005/windowstransport/
https://+:443/adfs/services/trust/2005/certificatemixed/
https://+:49443/adfs/services/trust/2005/certificatetransport/
https://+:443/adfs/services/trust/2005/usernamemixed/
https://+:443/adfs/services/trust/2005/issuedtokenmixedasymmetricbasic256/
https://+:443/adfs/services/trust/2005/issuedtokenmixedsymmetricbasic256/
https://+:443/adfs/services/trust/13/certificatemixed/
https://+:443/adfs/services/trust/13/usernamemixed/
https://+:443/adfs/services/trust/13/issuedtokenmixedasymmetricbasic256/
https://+:443/adfs/services/trust/13/issuedtokenmixedsymmetricbasic256/
https://+:443/adfs/services/trust/mex/
 

Endpoints removed:

–

Remember though that ADFS v4.0 supports other endpoints. And that’s were the WAP v3.0 may not understand everything published by ADFS v4.0. For the following endpoint you will see the following error when WAP v3.0 retrieves its config from the ADFS v4.0 farm.

Figure 3: WAP v3.0 Fails To Add A Listener For A Specific Endpoint Published By ADFDS v4.0

–

AD FS proxy service failed to start a listener for the endpoint ‘Endpoint details:
     Prefix : /.well-known/webfinger
     PortType : HttpsDevicePort
     ClientCertificateQueryMode : None
     CertificateValidation : None
     AuthenticationSchemes : Anonymous
     ServicePath : /.well-known/webfinger
     ServicePortType : HttpsDevicePort
     SupportsNtlm : False
‘
Exceptiondetails:
System.Net.HttpListenerException (0x80004005): Access is denied
   at System.Net.HttpListener.AddAllPrefixes()
   at System.Net.HttpListener.Start()
   at Microsoft.IdentityServer.WebHost.HttpListenerBase.Start(UInt32 contextPoolSize)
   at Microsoft.IdentityServer.ProxyService.ProxyHttpListener.Start()
   at Microsoft.IdentityServer.ProxyService.EndpointManager.ApplyConfiguration(ProxyEndpointConfiguration proxyEndpointConfiguration)

User action: Ensure that no conflicting SSL bindings are configured for the specified endpoint.

–

Now, a good way to make sure your WAP v3.0 stops functioning in an ADFS v4.0 farm, is to enable “Alternate Host Name Binding” as explanined in (2019-03-05) Certificate Based Authentication In ADFS (Legacy And New) – The Complete Information To Get This Working

As soon as you enable “Alternate Host Name Binding” you will see the following error when WAP v3.0 tries to retrieve its config from the ADFS v4.0 farm. Also pay attention to what it suggests you should do!

Figure 4: WAP v3.0 Fails To Retrieve Its Config From The ADFS v4.0 Farm After Enabling Alternate Host Name Binding

–

Unable to retrieve proxy configuration data from the Federation Service.

Additional Data

Trust Certificate Thumbprint:
7EB5B6A48B7273468ECC5EB67E05E62DDD04D145

Status Code:
UpgradeRequired

Exception details:
System.Net.WebException: The remote server returned an error: (426) Upgrade Required.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.IdentityServer.Management.Proxy.StsConfigurationProvider.GetStsProxyConfiguration()

–

If you want to make your WAP v3.0 again in this scenario you really need to disable Alternate Host Name Binding!

–

So before enabling “Alternate Host Name Binding” make sure to upgrade your WAP v3.0 to the latest version, it deserves it!

–

To disable “Alternate Host Name Binding” and start using legacy mode again for Certificate Based AuthN, just execute the following command on one ADFS server:

Set-AdfsProperties -TlsClientPort 49443

Then restart the ADFS service on all nodes:

Restart-Service ADFSSRV

–

Now, is this a complete list of what can go wrong? Probably not, therefore be careful!

–

Have fun!

–

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