Jorge's Quest For Knowledge!

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

Archive for the ‘Certificate Based AuthN’ Category

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

Posted by Jorge on 2019-05-25


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:

image

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! Smile

After provisioning, looking at the PRTs through DSREGCMD /STATUS

SNAGHTML4235b5

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

image

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!

image

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!

image

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!

image

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!

image

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.

image

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.

image

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!

image

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

image

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:

image

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

image

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

image

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

Advertisements

Posted in Active Directory Federation Services (ADFS), Certificate Based AuthN, WH4B, Windows Client | Leave a Comment »

(2019-03-05) Certificate Based Authentication In ADFS (Legacy And New) – The Complete Information To Get This Working

Posted by Jorge on 2019-03-05


ADFS supports many authentication methods for primary and secondary authentication, especially ADFS 2016 and its successor provide many authentication methods. “Certificate Based AuthN (CBA)” is one of those methods. It can be used for both INtranet and EXtranet scenarios in ADFS. How CBA is implemented depends on your ADFS version and the details of the SSL certificate.

When using ADFS 2012 R2 or earlier, or ADFS 2016 or later, without alternate hostname binding enabled, CBA will use the hostname “<Federation Service FQDN>” and port 49443. You must meet the following requirements:

  • ADFS and WAP Server Side
    • DNS Record
      • Internally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the ADFS servers (DNS load balancing) or a software/hardware load balancer for the ADFS Servers
      • Externally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the WAP servers (DNS load balancing) or a software/hardware load balancer for the WAP Servers
    • Service Principal Name
      • “HOST/<Federation Service FQDN>” (e.g. HOST/FS.COMPANY.COM) on the ADFS service account
    • Certificate Binding (ADFS/WAP Servers) (To view bindings: NETSH HTTP SHOW SSLCERT)
      • One for <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443) bound to SSL certificate
      • One for <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443) bound to SSL certificate
    • SSL Certificate (ADFS/WAP Servers):
      • Enhanced Key Usage
        • Server Authentication
      • Key Usage
        • Digital Signature
        • Key Encipherment
      • Subject:
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
      • SAN:
        (REMARK: for other purposes you may need additional SANs!)
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
  • User/Client Side
    • User Certificate (software based or smartcard):
      • Enhanced Key Usage
        • Client Authentication
        • Smart Card Logon (only needed when using a Smart Card!)
      • Key Usage
        • Digital Signature
      • Subject:
        • <Common Name> (e.g. CN=jorge) OR <Distinguished Name> (e.g. CN=jorge,CN=Users,DC=COMPANY,DC=COM)
      • SAN:
        (REMARK: for other purposes you may need additional SANs!)
        • <User Principal Name> (e.g. JORGE@COMPANY.COM)
    • Local Intranet Sites OR Trusted Sites (for both IE and Chrome!)
  • Load Balancer (only when using software/hardware based load balancer) (ADFS/WAP Servers):
    • Required configuration for the binding <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443)
    • Required configuration for the binding <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443)
  • Firewalls:
    • When the client is on the INternal network
      • Port 443 between client and the ADFS servers OR Load Balancer for the ADFS Servers
      • Port 49443 between client and thje ADFS servers OR Load Balancer for the ADFS Servers
    • When the client is on the EXternal network
      • Port 443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 49443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 443 between the WAP Servers and the ADFS Servers OR the Load Balancer for the ADFS Servers
      • Port 49443 between the WAP servers  and the ADFS Servers OR the Load Balancer for the ADFS Servers

When this “legacy” mode is enabled you will see the following when running:

Get-ADFSProperties   

image

Figure 1: Legacy Mode (TlsClientPort: 49443) Enabled For Certificate Based Authentication

image

Figure 2: Hostname Binding For The ADFS Service FQDN And Port 443 For Regular Federation Service Stuff

image

Figure 3: Hostname Binding For The ADFS Service FQDN And Port 49443 For Certificate Based Authentication

SNAGHTMLc02bbc6

Figure 4: Subject/SANs Of The ADFS SSL Certificate Supporting ONLY Legacy Certificated based Authentication

Now ADFS 2016 and higher supports a new mode for TLS Client Certificates over port 443, which is called “Alternate Host Name Binding”. This is useful when you have more stringent firewall restrictions. To enable this you need to run the following PowerShell command on just one ADFS server:

Set-ADFSAlternateTlsClientBinding –Thumbprint <ADFS SSL Certificate Thumbprint>

WARNING: This command configures a new binding on every ADFS server, reconfigures the TLS Client Port to 443 and will restart the ADFS service on every node!!!

 

image

Figure 5: Enabling “Alternate Host Name Binding”

With “Alternate Host Name Binding” in ADFS 2016 or later, CBA will use the hostname “CERTAUTH.<Federation Service FQDN>” and port 443. You must meet the following requirements (compared to the above changes in red):

  • ADFS and WAP Server Side
    • DNS Record
      (REMARK: You may already have an “A” record for your <Federation Service FQDN> (e.g. FS.COMPANY.COM). To create a new “A” record for CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM), that new record is a sub record of the <Federation Service FQDN>. In Windows DNS, when creating that record, it will convert the “A” record for the <Federation Service FQDN> to a folder that contains a record for “(same as parent folder)” and a record for CERTAUTH, both pointing to the ADFS Servers or WAP Servers)
      • Internally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the ADFS servers (DNS load balancing) or a software/hardware load balancer for the ADFS Servers
      • Externally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the WAP servers (DNS load balancing) or a software/hardware load balancer for the WAP Servers
      • Internally: A record for CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM) pointing to either the ADFS servers (DNS load balancing) or a software/hardware load balancer for the ADFS Servers
      • Externally: A record for CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM) pointing to either the WAP servers (DNS load balancing) or a software/hardware load balancer for the WAP Servers
    • Service Principal Name
      • “HOST/<Federation Service FQDN>” (e.g. HOST/FS.COMPANY.COM) on the ADFS service account
    • Certificate Binding (ADFS/WAP Servers) (To view bindings: NETSH HTTP SHOW SSLCERT)
      • One for <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443) bound to SSL certificate
      • One for <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443) bound to SSL certificate (although the binding is not needed, it will remain in place when migrating to Alternate Host Name Binding. No need to remove it. It also gives you the possibility to go back if needed for whatever reason!)
      • One for CERTAUTH.<Federation Service FQDN>:443 (e.g. CERTAUTH.FS.COMPANY.COM:443) bound to SSL certificate
    • SSL Certificate (ADFS/WAP Servers):
      • Enhanced Key Usage
        • Server Authentication
      • Key Usage
        • Digital Signature
        • Key Encipherment
      • Subject:
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
      • SAN:
        (REMARK: for other purposes you may need additional SANs!)
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
        • CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM)
          (REMARK: When a wildcard certificate is used it will present the error “There is a problem with this website’s security certificate.” or “This site is not secure (Error Code: DLG_FLAGS_SEC_CERT_CN_INVALID)” (IE) or “Your connection is not private (NET::ERR_CERT_COMMON_NAME_INVALID)” (Chrome))
  • User/Client Side
  • Load Balancer (only when using software/hardware based load balancer) (ADFS/WAP Servers):
    • Required configuration for the binding <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443)
    • Required configuration for the binding <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443)
    • Required configuration for the binding CERTAUTH.<Federation Service FQDN>:443 (e.g. CERTAUTH.FS.COMPANY.COM:443)
  • Firewalls:
    • When the client is on the INternal network
      • Port 443 between client and the ADFS servers OR Load Balancer for the ADFS Servers
      • Port 49443 between client and thje ADFS servers OR Load Balancer for the ADFS Servers
    • When the client is on the EXternal network
      • Port 443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 49443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 443 between the WAP Servers and the ADFS Servers OR the Load Balancer for the ADFS Servers
      • Port 49443 between the WAP servers  and the ADFS Servers OR the Load Balancer for the ADFS Servers

When this “legacy” mode is enabled you will see the following when running:

Get-ADFSProperties

SNAGHTMLc1dbd78

Figure 6: “Alternate Host Name Binding” Mode (TlsClientPort: 443) Enabled For Certificate Based Authentication

image

Figure 7: Subject/SANs Of The ADFS SSL Certificate Supporting Both Legacy Certificated based Authentication And “Alternate Host Name Binding”

image

Figure 8: Additional Hostname Binding For The ADFS Service FQDN And Port 443 For Certificate Based Authentication When Using “Alternate Host Name Binding”

Either modes support both primary and secondary authentication in ADFS! Works perfectly!

Now on the WAP servers, first implement the new certificate in the local certificate store, then run the following command to activate the new certificate and create the new certificate binding:

Set-WebApplicationProxySslCertificate -Thumbprint <WAP SSL Certificate Thumbprint>

Restart-Service ADFSSRV

Now imagine you have issues or for whatever reason you want to revert back to the legacy mode. Well that is an easy one. Just execute the following command on one ADFS server:

Set-AdfsProperties -TlsClientPort 49443

Then restart the ADFS service on all nodes:

Restart-Service ADFSSRV

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

Posted in Active Directory Federation Services (ADFS), Certificate Based AuthN | 1 Comment »

 
%d bloggers like this: