Add SSO Support for Chrome Browser with ADFS 3

Posted on by Scott Shelton

By default, ADFS 3 (Windows Server 2012R2) only supports the seamless Single Sign-on (SSO) that we all expect with Internet Explorer browsers.  Chrome can be enabled though by following these steps:

1.  Login to your on-premises ADFS server and launch PowerShell as administrator.

2.  Run the following command to see the current set of supported browsers:

If you have the default configuration, it will return the following:

3.  Run the following command to add Chrome support to the list:

4.  Confirm your change running the same get command from step 2.  You should have the following output:

5.  Restart the ADFS service to apply changes:

All done!

High CPU Usage from microsoft.online.reporting.monitoringagent.startup

Posted on by Scott Shelton

After installing the the Windows Updates for July 2018, my Azure AD Connect servers started maxing out their CPU.  Upon looking into it I came across the “microsoft.online.reporting.monitoringagent.startup” process, otherwise known as the “Azure AD Connect Health Sync Monitor” service, eating up nearly all of the machines CPU.

I came across this Microsoft support article that acknowledged the issue and places the blame on the June 2018 .NET updates.  Not 100% true for my situation as I never had issues with the June 2018 updates just the July 2018 updates, but I’ll take it.  It may also be worth noting that I was running version 1.1.654.0 when experiencing this issue.

The solution is to simply update to the most recent version of Azure AD Connect, which in turn will update the problematic Azure AD Connect Health Agent.  This is a pretty simple process but I’ll detail it below quick.

1. Download the most recent Azure AD Connect installer

2. Run the MSI on the machine you have Azure AD Connect installed

 

3. Select the Upgrade option on the Upgrade Azure Active Directory Connect window

 

4. You will see a “Upgrading the synchronization engine” status.  This can take some time.

5. Enter your GLOBAL ADMINISTRATOR Azure AD credentials as prompted

 

6. Input your DOMAIN ADMINISTRATOR AD DS credentials as prompted

 

7. On the Ready to configure window select Upgrade

 

8. After some time you will see the following success message.  By default it will start a full sync after the upgrade unless you cleared the check box in the previous step.

Enabling Extranet Lockout in AD FS 3.0

Posted on by Scott Shelton

Brute force attacks can be quite the nuisance for users, especially if they manage to start hitting your AD FS portal with authentication attempts.  The Extranet Lockout feature can help alleviate these pains by preventing the users local AD account from being locked out, but it is by no means a complete solution.  Please see this post from TechNet for reference on initial setup, and this post also from TechNet for reference on logging/troubleshooting.  Without further ado, let’s dig in.

So what does the Extranet Lockout feature actually do?  Well, it is quite simple really.  Every time AD FS receives an authentication request it will check that AD users badPwdCount attribute before trying to actually authenticate the users against AD.  If that value is greater than or equal to the threshold you set it will no longer allow any authentication requests through AD FS for that user for X amount of time,which naturally you configure, preventing it from locking out the AD account.  Now just to be clear, this provides zero value if you set the thresholds to higher values than your domain policies.  Seems like common sense I know, but you should see some of the comments on these blog sites.

So let’s get into enabling the feature.  This is not very involved, just note that this must be done on the AD FS server, not the WAP.  Before we get into the PowerShell, let’s define the three settings that we are going to concern ourselves with:

  1. ExtranetLockoutEnabled: Enables or Disables the Extranet Lockout feature.  Pretty straightforward.
  2. ExtranetLockoutThreshold: Defines the maximum number of bad password attempts allowed before lockout takes effect.  Remember, it will be looking at the badPwdCount attribute on the AD user account for this so you will want this to be lower than your domain lockout threshold.
  3. ExtranetObservationWindow: Defines the amount of time AD FS will not attempt to authenticate against AD.  Again, everything works off of AD badPwdCount attribute so you want this to be longer than your domain password attempt count reset threshold.

So now that we know what the settings we are configuring do, let’s configure it!

Great now we have it configured!  Now we have to know how to navigate our way through the logs should it become a persistent issue that we need to troubleshoot.  By default a lot of the logging is not going to be configured yet which brings us to our next section of this post, setting up all of the logging so you can troubleshoot with your new and shiny feature!

First thing we need to do is tell AD FS to log success and failure events to the event log.  You do this by opening up AD FS Management on your AD FS server and opening Federation Service Properties.  Select the Events tab and check the Success audits and Failure audits options.  You don’t need success audits, but I think they’re nice to have.

Next we need to configure the AD FS server to audit properties generated by applications.  You do this with GPO (local or domain, dealers choice), as seen below.

We’re all set for logging now!  But what did that time and effort buy you?  Well really it comes in three forms of Event IDs in the security log of the AD FS server: 403, 411, and 516.

  • Event ID 403: This is most useful for figuring out the User Agent that is making the request.  The User Agent is the application being used so think of things like Chrome, Mozilla, a native phone app, etc.  This will also give you the Client IP, but if you have this behind a WAP as is Microsoft’s recommendation you will only see your WAP’s IP.
  • Event ID 411: These are your failed token validation attempts, aka your failed authentication attempts.  These logs provide the actual Client’s IP which is quite useful when trying to source the device.
  • Event ID 516: These are your Extranet Lockout events, your bread and butter.  This tells you the Bad Password Count AD FS saw, the Last Bad Password Attempt, and the actual Client IP like 411 does.

Now I’ll be frank, Event ID 516 is the one you’ll be looking at the most so I’ll put a screenshot of that one below.

I would like to talk about 516 a little more in depth.  You will notice that all of these errors will have a Activity ID which can be matched to each other.  This will allow you to match them up to aggregate the different information you get from each Event ID.  I bring this up because you will, and I meant to use the word will, come across events where the Activity ID is going to be 00000000-0000-0000-0000-000000000000 as you see above.  After much heartache to figure this out, this means that the request came from a legacy application such as a native phone email application or Thunderbird.  With these you will get TWO IP addresses.  One of these will be a Microsoft IP address and the other will be the IP address where the request came from.  This is significant because the request is actually coming from the Microsoft IP address as Exchange Online processes the credentials and forwards them on to your AD FS server.  I’m sure you’re already seeing how this makes blocking the requests difficult, as you can’t control Microsoft’s perimeter network.  I’ll leave dealing with that for another post.

Error signing into authentication app when activating Office 2016

Posted on by Scott Shelton

When users were trying to authenticate through Office 2016 to activate the product, they were receiving the following error message upon being redirected to their AD FS login page while on the internal network.

An error occurred

An error occurred. Contact your administrator for more information.

Error details
Activity ID: 00000000-0000-0000-c32d-00800000005e
Relying party: Microsoft Office 365 Identity Platform
Error time: <Date> <Time>
Cookie: enabled
User agent string: Mozilla/5.0 (Windows NT 6.3;WOW64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/38.0.2125.111 Safari/537.36

I did some Googling and came across this Microsoft Support article which details the following steps.  Note that this pertains to Server 2012 R2 for me.

  1. Login to your AD FS server and open AD FS Management
  2. Select Authentication Policies
  3. Select Edit in the Primary Authentication -> Global Settings section
  4. Check Forms Authentication in the Intranet section and select OK or Apply

Exchange Online Missing Mandatory Parameters: ArchiveGuid

Posted on by Scott Shelton

I’ve been working with hybrid Office 365 environments for quite some time now and liked to think that I had come across most of the weird errors, but of course just when you think that there has to be another random msExch attribute to come along and muck things up.  I came across just such a case today, presenting itself with the following error in Office 365:

Exchange: Cannot process command because of one or more missing mandatory parameters: ArchiveGuid.

I did a little digging and came across this blog post that found the msExchRemoteReceipeintType attribute to be the culprit.  I cleared the value, kicked off a full dirsync and wha-lah!  Problem solved.

Adding Additional Azure AD Domain to AD FS with Azure AD Connect

Posted on by Scott Shelton

As time continues to drag on, companies may add domains that they wish to federate with the same tenant.  This such situation happens quite frequently in my business, so I figure it makes good content for a post.  This is going to be a pretty short and quick one, so I am going to assume that your new domain is already added to the O365 tenant and as a UPN suffix in AD.

As you can likely tell by now, I do a lot of work with hybrid environments using Azure AD Connect.  That being said, we’ll start today by opening Azure AD Connect and selecting the “Add an additional Azure AD domain” from the options presented.

The rest is pretty simple.  Throw in your O365 Global Admin creds, then your Domain Admin creds, and select the domain you wish to add.  It’ll take a second and wha-lah you are 50% done.

Now open up your AD FS Management console on your AD FS server.  Expand Trust Relationships, select Relying Party Trusts, right click Microsoft Office 365 Identity Platform, and select Edit Claim Rules.

Under Issuance Transform Rules, select Issue issuerid when it is not a computer account and select the Edit Rule option.

In the Custom rule section you will see something similar to the following:

Find your domain section, and simply follow the convention to add an additional domain (domain3 in the following example):

Click your way out and you are all set!  Do note that if you do not add the domain to the rule as described above, users will receive an error similar to:

AADSTS50107: Requested federation realm object ‘user@domain.com’ does not exist.

ADFS User Sign-In Customization

Posted on by Scott Shelton

I’m not going to lie to you, like most of my posts this is just a reference for myself but hey maybe one of you stalkers of the interwebs didn’t know how to do this.  Anywho there is a whole bunch of customizations that you can make to the ADFS sign-in page with simple PowerShell one liners, all of which can be found at this page (and its linked pages).  Me, I’m just going to highlight the few that I do.

Change the Company Logo:

Change the Illustration (the wallpaper-like image on the left side):

Customize the Update Password Page Description:

Add Help Desk Link:

There are many other things you can customize by following the link at the beginning of the post, but these are the ones I like to set.  That’s it for this one!

Enabling Password Change in ADFS 3.0

Posted on by Scott Shelton

I would like to start this off the same way that many posts on this topic do by defining the difference between password change and password reset.  Looking at the two terms they seem like the same thing, but in the wonderful nerdy world that we call our home they are two very different things.

Password Change, the topic of this post, is the ability for an Active Directory user to change their password when they know what their password currently is.  Password Reset is when an Active Directory user does not know their password and must provide alternate recovery methods, for example a phone number or security questions.  While Password Reset functionality is cool and completely possible with ADFS (psst Password Writeback), that will have to wait for another post.  Today we are focused on Password Change with ADFS, introduced in 3.0 to my knowledge, which is most commonly used for resetting expired passwords/newly setup accounts.  Without further ado, let’s dig into it.

1.  Start by logging into your ADFS server and opening AD FS Management.

2.  Expand out Service, select Endpoints, and scroll down to the Other section where you will find /adfs/portal/updatepassword/.

3.  Right click on it and choose Enable.  Restart the ADFS service and Password Change is now available on the corporate network!

4.  Chances are that you want to enable this for users on external networks (where it’s most useful).  Do this by right clicking the /adfs/portal/updatepassword/ endpoint again and selecting Enable on Proxy.  Restart the ADFS service again and Password Change will be fully enabled!

Convert Federated Domain to Standard with PowerShell

Posted on by Scott Shelton

This is a rather unique scenario that I found myself in recently.  I must admit, tearing down domain federation is infinitely easier than getting it set up!  Anywho, the following details the steps involved in converting a federated Office 365 domain to a managed domain and removing DirSync from Office 365.

1.) Open a PowerShell window as Administrator on a box with the msol cmdlets and connect to your Office 365 tenant

2.) Run the following command to convert the domain to a standard domain

3.) Run the following command to remove DirSync from Office 365

 

Step-By-Step Installation of Active Directory Federation Services (ADFS) using Azure AD Connect

Posted on by Scott Shelton

ADFS setup can be nothing but a headache to set up when you are new to it.  You know it.  I know it.  We all know it.  So this is my step-by-step guide for setting up a basic ADFS configuration.  Now, this is going to detail a successful installation without any errors (which does happen once in a blue moon).  To see resolutions to the errors that I have encountered in the past, please reference this post.  I will try to keep adding things as I come across them, but no guarantees.

As with anything that needs to be configured, setting up your prerequisites is key to your success.  Often not setting up your prerequisites properly will become your greatest frustration.  For reference see the Microsoft Official Post, but I will also be going through them now.  For port requirements, see this post.

Prerequisites:

1.   Download Azure AD Connect and copying that to the internal box you will be installing the ADFS role on to be installed later.

2.  Enable TLS 1.2 (Server 2008R2 and later) and configure .Net to use it by adding the following registry values and restarting the machine (I do this on both the ADFS and the WAP box).

3.  Create a Forward Lookup Zone for the domain you are federating in your local DNS.  Add an A record (Host) for adfs pointing at your ADFS server.  This will have internal requests resolve directly to the ADFS server.  In your internal domains forward lookup zone, create an A record for your web application proxy (WAP).

4.  Modify the host file on your web application proxy (WAP) to resolve adfs.domain.com to your internal ADFS server.  Public DNS should resolve adfs.domain.com to the WAP Public IP.

5.  Run the following command on both the ADFS and WAP box to enable Windows Remote Management (WinRM):

6.  On the ADFS box, add the WAP box to you WinRM Trusted Host list with the following:

7.  Confirm WinRM is functional by running the following from the ADFS box:

8.  Obtain a valid SSL certificate for the ADFS subdomain of your federated domain (ex. adfs.domain.com).  See this post about creating a custom csr with an exportable private key from your web application proxy (WAP).  Make sure you use the Legacy key template.  Export that to a PFX with its private key and copy it to your ADFS server.

9.  Add the domain name you plan to federate to your domains UPN Suffixes via Active Directory Domains and Trusts.

10.  Download Microsoft Exchange Server (Current version is 2016 found here).  Copy that to the Domain Controller that holds the Schema Master role, open a command prompt window in that directory and run the following command:

11.  Create a Group on the domain you plan to federate to specify which user accounts will be synced.  This is optional as you can choose to sync all user accounts if you wish.

12.  Create a service account on the domain that you plan to federate and add it to the Domain Admins and Enterprise Admins groups.  You can split this into two accounts if you wish.

13. Pro-Tip: Check the time and date on your servers.

Installation:

1.  Run the Azure AD Connect .msi to install it and agree to the license terms when prompted and select next.

2.  Select Customize

3.  Select the “Use existing service account” option and input the service account credentials you set up during prerequisites and select Install.

4.  After a little while you will be brought to a User sign-in window.  Select the “Federation with AD FS and select Next.

5.  Insert Global Administrator credentials for your Azure AD/Office 365 and select Next.

6.  Add the local domain you wish to federate and select Next.

7.  Confirm the domain you wish to federate with is verified, that userPrincipalName is selected and select Next.  If your domain you wish federate with is not present/says Not Added you need to verify it in your Azure AD/Office 365 tenant.

8.  Confirm the options are selected as below and select Next.

9.  Select “Synchronize selected” option, add the DN of the your local AD group, confirm it resolves, and select Next.

10.  Leave everything unchecked and select Next.

11.  Upload your Certificate .pfx, confirm the appropriate Subject Names appear, and select Next.

12.  Input the FQDN of your ADFS server, select Add, and select Next.

13.  Add the FQDN of your WAP. select Add, and select Next.

14.  Input your service account credentials and select Next.

15.  If prompted, input your service account credentials again and select Next.

16.  Select the appropriate Azure AD domain to federate with and select Next (typically there is only one available).

17.  Select te “Start the synchronization process when configuration completes.” option and select Install.

Phew.  At this point go grab a cup of coffee, and maybe start praying a little bit.  Assuming everything was configured correctly, you will get a success message and be prompted to verify your DNS configuration.  Once that all checks out you’re off to the races!