(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-05-28) Windows Hello For Business – Certificate Template For DCs

When implementing Windows Hello for Business, either using the “Hybrid AAD Joined Certificate Trust” method or the “Hybrid AAD Joined Key Trust” a PKI infrastructure is needed to at least implement a certificate template for DCs to support WH4B. When already having a (Microsoft) PKI infrastructure you may already have a certificate template for DCs that may have a provider and algorithm (Cryptography TAB) configured as or similar to as displayed below.

Figure 1: Existing Cryptography Settings In Legacy DC Certificate Template

–

When deploying WH4B, the following cryptography settings are required. You will only be able to configure this when in the compatibility TAB the certification authority is set to at least Windows Server 2012.

 

Figure 2: Cryptography Settings In New DC Certificate Template Required By WH4B

–

Now a question may be: what is the impact on DCs when configuring a new certificate template and deploying that to the DCs to replace the existing certificate template?

A good question, might I say!

–

Important to note is that autoenrollment is configured and it is configured correctly, for this to succeed, then at least following high-lighted settings must be set and targeted against DCs in AD. See below.

You may also want to read: Troubleshooting Autoenrollment and Configuring Autoenrollment

Figure 3: Autoenrollment Settings

–

In addition, make sure to supersede the old certificate templates in the newest certificate template, as displayed below.

With regards to PKI, the WH4B documentation says the following:

By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the Kerberos Authentication certificate template a baseline to create an updated domain controller certificate template

Figure 4: Superseded Settings

–

From what I have understood, it changes the storage provider from CSP to KSP and it keeps the RSA algorithm. After doing this myself in multiple environments and asking around for experiences, the answer to the “impact” question is:

No negative impact anticipated or experienced

Nevertheless, make sure to test in your representative test environment!

–

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