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!

(2019-05-31) Cloud-Based Azure AD MFA Notifications Not Working While You Already Registered

Posted by Jorge on 2019-05-31


After registering your security info in Azure AD, it may look like or be similar to:

REMARK: the security page looks like this because I have converged experience for MFA and SSPR enabled in AAD

image

Figure 1: Security Information In AAD To Be Able To Use MFA And SSPR (Converged Experience)

Now after navigating to an ADFS connected application and choosing the cloud-based Azure AD MFA on the MFA choice screen in ADFS, you may see a screen telling you the method is not available. In my ADFS it looks like displayed below.

REMARK: this has been customized by me. In a future blog post I will show how

image

Figure 2: (Custom) Error In ADFS Saying That The Account Is Not Registered For The Chosen MFA Method

The weird thing here is that you can see in figure 1 that the account is registered, but for some reason it is still failing as shown in figure 2. I know what the problem is and how to solve it, but do not understand why or when it happens. Although I have the Microsoft Authenticator app registered, you can also see the default sign-in method is set to “Phone – Text”. THAT may work when using SSPR, but in my case it will not work for MFA because I have “Text message to phone” disabled in the Multi-Factor Authentication service settings as displayed below.

image

Figure 3: The Configured Multi-Factor Authentication Service Settings In My AAD Tenant

To cut a long story and a long time of searching for a solution short, you can do the following to solve this.

  1. Navigate to https://aka.ms/setupsecurityinfo
  2. If on the right of the Default Sign-In Method you see a link called “Change”, then click that and skip steps 3 and 4 and 5
  3. If on the right of the Default Sign-In Method you DO NOT see a link called “Change”, then click on “Change” next to “Delete” for the Phone registration
  4. Just reregister the exact same (mobile) phone number. For confirmation you will receive a text message and you need to enter the code received to complete the process
  5. If on the right of the Default Sign-In Method you see a link called “Change”, then click that. If you do not, the go to step 7
  6. Change the default sign-in method to “Authenticator App – Notifications” (assumes you have a registration for the Microsoft Authenticator App)
  7. If MFA still does not work, then navigate to https://aka.ms/setupsecurityinfo and re-register the Microsoft Authenticator app with the account you used to log into AAD. There is no need to remove any existing registration in AAD or the account from the Microsoft Authenticator app. Any new registration will overwrite the existing registration.
  8. If on the right of the Default Sign-In Method you see a link called “Change”, then click that and choose the “Microsoft Authenticator App – Notification” method as the default sign-in method
  9. Try MFA again. It should work now.

The security information should look like or be similar to

image

Figure 4: Security Information In AAD To Be Able To Use MFA And SSPR (Converged Experience)

What I have seen is that after people register the Microsoft Authenticator app in the Security Information page in AAD, for many of them the default sign-in method is automatically changed to “Microsoft Authenticator App – Notifications”, but for some it remains with “Phone – Text”

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 Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2019-05-28) Windows Hello For Business – Certificate Template For DCs

Posted by Jorge on 2019-05-28


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.

clip_image002

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.

 clip_image004

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

image

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

image

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

Posted in Active Directory Certificate Services (ADCS), Active Directory Domain Services (ADDS), Certificate Templates, Certificates, WH4B, Windows Client | Leave a Comment »

(2019-05-27) (Un)Constrained Kerberos Delegation

Posted by Jorge on 2019-05-26


Within Windows Server Kerberos Delegation can be used to, for example, access data in a SQL database by a front-end service on behalf of the user accessing the front-end service.

The flow then looks like: USER (U)  —— access—-> FRONT-END SERVICE (FE) —— access on behalf of “U”—-> DATA (D).

While U accesses FE, FE then needs to access D on behalf of U. The “on behalf of” part is achieved through Kerberos Delegation.

When looking at Kerberos Delegation there are three flavors that can be used

  1. Unconstrained Kerberos Delegation
  2. Constrained Kerberos Delegation
  3. Resource-Based Kerberos Delegation

[ad.1] Unconstrained Kerberos Delegation

This is available in since Windows Server 2000 up to the latest and greatest version of Windows available today. It is VERY INSECURE, therefore avoid this if possible! Why is it insecure? Well, with UNconstrained Kerberos Delegation, the FE, when configured for Unconstrained Kerberos Delegation, is allowed to access ANY service without restrictions, and not just D. You could also call this “Account-Based Unconstrained Kerberos Delegation”

Imagine a bank vault (the “D”) and many other bank vaults and a bank clerk (the “FE”). The bank clerk is configured to access any access any bank vault on behalf of clients, but the bank clerk should really only access one specific bank vault (“D”) on behalf of clients. Yeah right! Better yet, the owner of the bank vaults do not have anything to say about this. Just shut up and allow access!

Read more about it:

[ad.2] Constrained Kerberos Delegation

This is available in since Windows Server 2003 (with FFL W2K3) up to the latest and greatest version of Windows available today. It is a better option than the previous option, so if you cannot implement the next option, then at least try this option! With Constrained Kerberos Delegation, the FE, when configured for Constrained Kerberos Delegation, is ONLY allowed to access specific services (e.g. only “D”) for which it has been configured to do so and not any service. You could also call this “Account-Based Constrained Kerberos Delegation”

Imagine a bank vault (the “D”) and many other bank vaults and a bank clerk (the “FE”). The bank clerk is configured to access only the specific bank vault (“D”) on behalf of clients. Other bank vaults cannot be accessed on behalf of clients. Sounds better, but the owner of that specific bank vaults still does not have anything to say about this. Just shut up and allow access!

Read more about it:

[ad.3] Resource-Based Kerberos Delegation

This is available in since Windows Server 2012 up to the latest and greatest version of Windows available today. This is the best option when compared to the previous 2 options. This does require the complete service chain (FE, D, AD domain for FE, AD domain for D and any domain in between) to run at least Windows Server 2012. With regards to AD domains, at least one Windows Server 2012 DC is needed and there are no dependencies on DFLs/FFLs. Guess what?! This is by default constrained, therefore no need to mention the word “Constrained”, otherwise it is the same as saying “wet water”! With “Resource-Based Kerberos Delegation”, the D, when configured for Resource-Based Kerberos Delegation, is ONLY allowing access by specific services (e.g. only “FE”).

Imagine a bank vault (the “D”) and many other bank vaults and a bank clerk (the “FE”). A specific bank vault (“D”) is configured by its owner to only allow access by the bank clerk (the “FE”) on behalf of clients. Sounds even better!

Read more about it:

With both “Unconstrained Kerberos Delegation” and “Constrained Kerberos Delegation”, delegation is configured at delegated account level (hence: “Account-Based (Un)Constrained Kerberos Delegation”), and not at resource level, which is weird! Looking at ACLs in all kinds of services (file, sql, AD, etc.), permissions are configured at resource level, as it should be! This changes in “Resource-Based Constrained Delegation”, which is my preferred way of delegation!

Additional Reading:

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

Posted in Active Directory Domain Services (ADDS), Delegation, Kerberos AuthN | Leave a Comment »

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

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

(2019-05-22) Some Basic Steps For Troubleshooting PRTs

Posted by Jorge on 2019-05-22


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

Posted in Active Directory Federation Services (ADFS), Azure AD PRT, Enterprise PRT, Windows Azure Active Directory | Leave a Comment »

(2019-05-16) Azure AD Connect v1.3.21.0 Has Been Released

Posted by Jorge on 2019-05-16


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

IMPORTANT

There is a known issue with upgrading Azure AD Connect from an earlier version to 1.3.21.0 where the O365 portal (https://admin.microsoft.com/AdminPortal/Home#/dirsyncmanagement) does not reflect the updated version even though Azure AD Connect upgraded successfully.

To resolve this you need to import the AdSync module and then run the Set-ADSyncDirSyncConfiguration powershell cmdlet on the Azure AD Connect server. You can use the following steps:

  1. Open Powershell in administator mode
  2. Run Import-Module "ADSync"
  3. Run Set-ADSyncDirSyncConfiguration -AnchorAttribute ""

REMARK: Below you can see the last directory sync and the last password sync occurred a few days ago and it is issuing a warning. The reason for that is that I turned my VMs off as I was not using them for a few days

image

Figure 1: Dir Sync Status In The Office Portal

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.3.21.0

Released: 05/14/2019

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements

  • N.A.

Fixed issues

  • Fixed an elevation of privilege vulnerability that exists in Microsoft Azure Active Directory Connect build 1.3.20.0. This vulnerability, under certain conditions, may allow an attacker to execute two powershell cmdlets in the context of a privileged account, and perform privileged actions. This security update addresses the issue by disabling these cmdlets. For more information see security update.

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

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 Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2019-04-30) Azure AD Connect v1.3.20.0 Has Been Released

Posted by Jorge on 2019-04-30


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

IMPORTANT: I upgraded from Azure AD Connect 1.2.70.0. As mentioned below in the “New Features And Improvements” section it upgrades a group sync rule to include additional transformations (flows). To be more specific it updates the sync rule called “In from AD – Group Common”. If you have this rule enabled it will most likely perform a full sync for at least the AD connector the next time it syncs after the AAD Connect upgrade. If you have this rule enabled disabled, that means you have a cloned version of it that requires updating if you need those additional transformations (flows) to support group claims in AAD. If you do update that cloned version, then it will most likely perform a full sync for both the AD connector the next time it syncs after the AAD Connect upgrade. Since that may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

However, to my surprise it did not trigger the expected full sync for the AD connector. That was weird, because when sync rules are updated all data needs to be reevaluated, whether or not it has changed. In my case I triggered the full sync myself by running the Run Profiles manually for both the AD Connector and the AAD Connector. The order was: Disable Sync Scheduler, Delta Import for AD Connector, Full Sync for AD Connector, Export for AAD Connector, Delta Import for AAD Connector, Delta Sync for AAD Connector, Export for AD Connector and Re-enable Sync Scheduler.

Azure AD Connect: Version Release History

1.3.20.0

Released: 04/24/2019

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements

  • Add support for Domain Refresh
  • Exchange Mail Public Folders feature goes GA
  • Improve wizard error handling for service failures
  • Added warning link for old UI on connector properties page.
  • The Unified Groups Writeback feature is now GA
  • Improved SSPR error message when the DC is missing an LDAP control
  • Added diagnostics for DCOM registry errors during install
  • Improved tracing of PHS RPC errors
  • Allow EA creds from a child domain
  • Allow database name to be entered during install (default name ADSync)
  • Upgrade to ADAL 3.19.8 to pick up a WS-Trust fix for Ping and add support for new Azure instances
  • Modify Group Sync Rules to flow samAccountName, DomainNetbios and DomainFQDN to cloud – needed for claims
  • Modified Default Sync Rule Handling – read more here.
  • Added a new agent running as a windows service. This agent, named “Admin Agent”, enables deeper remote diagnostics of the Azure AD Connect server to help Microsoft Engineers troubleshoot when you open a support case. This agent is not installed and enabled by default. For more information on how to install and enable the agent see What is the Azure AD Connect Admin Agent?.
  • Updated the End User License Agreement (EULA)
  • Added auto upgrade support for deployments that use AD FS as their login type. This also removed the requirement of updating the AD FS Azure AD Relying Party Trust as part of the upgrade process.
  • Added an Azure AD trust management task that provides two options: analyze/update trust and reset trust.
  • Changed the AD FS Azure AD Relying Party trust behavior so that it always uses the -SupportMultipleDomain switch (includes trust and Azure AD domain updates).
  • Changed the install new AD FS farm behavior so that it requires a .pfx certificate by removing the option of using a pre-installed certificate.
  • Updated the install new AD FS farm workflow so that it only allows deploying 1 AD FS and 1 WAP server. All additional servers will be done after initial installation.

Fixed issues

  • Fix the SQL reconnect logic for ADSync serviceFix to allow clean Install using an empty SQL AOA DB
  • Fix PS Permissions script to refine GWB permissions
  • Fix VSS Errors with LocalDB
  • Fix misleading error message when object type is not in scope
  • Corrected an issue where installation of Azure AD PowerShell on a server could potentially cause an assembly conflict with Azure AD Connect.
  • Fixed PHS bug on Staging Server when Connector Credentials are updated in the old UI.
  • Fixed some memory leaks
  • Miscellaneous Autoupgrade fixes
  • Miscellaneous fixes to Export and Unconfirmed Import Processing
  • Fixed a bug with handling a backslash in Domain and OU filtering
  • Fixed an issue where ADSync service takes more than 2 minutes to stop and causes a problem at upgrade time.

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

…And just to get ahead of things when needed I also installed the Azure AD Connect Admin Agent in a disabled state. By the way, as mentioned in the documentation, you will be prompted multiple times (about 5x or so) for credentials. So, don’t freak out thinking it is not working.

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 Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2019-03-06) Will WAP v3.0 Work With ADFS v4.0 Or Later?

Posted by Jorge on 2019-03-06


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.   

image

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’.

image

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.

image

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

image

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

Posted in Active Directory Federation Services (ADFS), Migration, Web Application Proxy | 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 | Leave a Comment »

 
%d bloggers like this: