Filtering Event ID 4624 by Logon Type

Let me paint a picture for you:  High level exec walks in and says someone has been on his computer.  “I want to know every time someone has logged into my computer in the last month!”

Okay, not so bad.  Get into the event viewer of the machine either locally or remotely, go to your Security log, and filter by Event ID 4624.  Should be pretty simple to determine from there right?  Well, if only that were so.  I’m going to lean very heavily on the Microsoft doc for this event found here.  As it states in the mentioned doc, Event ID 4624:

This event generates when a logon session is created (on destination machine). It generates on the computer that was accessed, where the session was created.

This includes service account, network services, SYSTEM services…all of it.  There is a lot of junk to get through!!!  So as you dig further into the information given by the event, you will notice a row titled “Logon Type.”  Ah Microsoft didn’t leave us out to dry!  This allows us to filter down to only the logon types we care about, but what ones are those exactly?  Well that will depend on your situation.  See below for the different types:

Now in my case I was interested in Logon types 2, 3, 7, and 10.  So how do you filter down?  It’s not like the Event Viewer filter lets you specify certain data beyond an Event ID.  Well actually it does, it’s just a bit trickier.  Here’s how I did it:

1. In Event Viewer, right click on Custom Views and select Create Custom View

2. In the “Event logs” section to the right of “By log” select the Security Windows log

3. Input 4624 in the “<All Event IDs>” box

4. Select the “XML” tab

5. Select the “Edit query manually” on the bottom

6. You will get an Event Viewer warning.  Select Yes to continue.

7. Change the Select Path line to the following, subbing in/out what Login Types  you want to filter by changing the number after Data= (Source)

 

Click OK and you are all set!  You can filter by as many or little as you like, just follow the syntax convention above.

Enabling Password Change for RDS 2012R2/2016

The ability for a user to change their password when it has expired via the Remote Desktop Services webpage is disabled by default.  Enabling the feature is quite simple, but with anything take a moment to consider the security implications and make sure that your organization is okay with the risk.

Connect to the server that hosts the RD Web Access role and launch IIS.  Navigate to Sites\Default Web Site\RDWeb\Pages and select Application Settings.

Locate the “PasswordChangeEnabled” setting, open it up and change the Value to “true”.

Click OK and you’re off to the races.

Resetting Default Domain Policy & Replacing EFS Certificate

I have inherited some pretty messy domains over the last couple years when it comes to GPO’s, and knowing the short and sweet way to reset the Default Domain and Default Domain Controller policies has come in handy.  As I hope you know, Microsoft only suggests only making changes to these policies for account, account lockout, password, and Kerberos policies.  I agree that it should stay clean, there is no reason not to break things out into different GPO’s in this day and age.  But alas let’s move on before this becomes a rant.

To reset either of the default GPO’s, you use the dcgpofix utility.  The syntax is quite simple, just take a backup of the GPO you’re resetting before you do it as I’m sure you already know.

Reset the Default Domain Policy:

Reset the Default Domain Controller Policy:

Reset both the Default Domain Controller and Default Domain Policy:

Wha-Lah you are done.  Go and set you account/account lockout/password/Kerberos settings as dictated by your organization.  You may run into an issue where the utility is unable to recreate the EFS certificate as seen below:

This is pretty simple, you will just have to create a new certificate for EFS and add it to the policy manually.  Now you can accomplish this in a number of different ways, but I’m going to show you the simplest (in my opinion) in which you create a self-signed certificate that will out live you.  Open up a PowerShell or Command Prompt as Administrator and move to the directory that you would want to save the certificate.  Once there run the following, where “CertName” is whatever you would like to name the certificate:

This will generate your self-signed certificate in whatever directory you’re sitting in.  Now you need to import it into your Default Domain Policy to be used for EFS.  Open your Group Policy Management Editor and navigate to “Computer Configuration\Policies\Security Settings\Public Key Policies\Encrypting File System”.  Once there right click EFS and select the “Add Data Recovery Agent…” option.

Move through the wizard selecting the “Browse Folders…” option to select your certificate.  You will likely get a pop-up saying “Windows cannot determine if this certificate has been revoked”.  This is just because it is a self-signed certificate, so select Yes when prompted to install the certificate.  Next your way through the rest of the wizard and you are all set.

Create Exchange Online IP Blacklist

You may have gotten the hint over the last few posts that I had some brute force issues from a particular set of IPs (a couple /24’s to be exact).  Well after much heartache I found the solution.  Thinking about it now this is probably a pretty common on-prem Exchange configuration option, but alas I have very little Exchange experience so I’m always just figuring it out as I go.

Start by connecting to Exchange Online:

The cmdlet that we will be working with is the Set-OrganizationConfig cmdlet.  As you can see by going to the Microsoft doc linked, there is a whole lot that you can configure for your tenant with this single cmdlet.  For this particular post though, I just needed to make a blacklist to stop the brute force attempts.  To do so I configured the IPListBlocked option:

If you do not currently have any IPListBlocked, you will not need the “add=” portion, but it doesn’t hurt.  All it does is tell it to append to the current array.  Give it about four hours as the warning you’ll see describes and then you should start seeing the desired result.  As always, review the Microsoft docs for syntax and whatnot before.

Configuring Exchange Online Client Access Rules

Client Access Rules give you a lot of control over who can access Exchange Online from where.  Microsoft gives a pretty good definition so I’ll just throw that at you because I’m lazy:

Client Access Rules help you control access to your Exchange Online organization based on client properties or client access requests. Client Access Rules are like mail flow rules (also known as transport rules) for client connections to your Exchange Online organization. You can prevent clients from connecting to Exchange Online based on their IP address, authentication type, and user property values, and the protocol, application, service, or resource that they’re using to connect.

The most common use case I have seen for this is restricting access to just the corporate/company networks.  While this is cool, you can also use these rules to not allow specific networks as well should have the need, as well as a bunch of other situations.  Use your imagination, these things are pretty cool.

One thing to note is that these do not help with brute force attacks.  The user first authenticates and then Exchange Online will evaluate the Client Access Rules like an ACL, going down the priority list and stopping when it finds a match.  Anyhow, to get them set up we need to start by connecting to Exchange Online.  Open up an administrative PowerShell session and run the following:

Great, now we’re connected to Exchange Online with PowerShell.  First things first, we need to make sure we can always do that.  You will find this plastered all over the Microsoft documentation and any other guides on the interwebs, make your Priority 1 Client Access Rule preserve your access to Exchange Online with PowerShell.  Do this with the follow line:

Just do it.  You don’t wanna be the guy who has to call Microsoft because you locked yourself out of your Exchange Online tenant.

Now you have a lot of options with where you go from here.  Most examples are going to show you how to deny everything accept for X network, I will show you the opposite.  The following will create a rule that will allow any network except for X networks (replace 10 networks with public ranges, or drop the CIDR notation and do particular IP):

You can test this with the following:

And you can modify by:

Like I said earlier, play with the options/settings and use your imagination.  This configuration option isn’t for every org, but it does have a surprising amount of use cases.

In my next post I’ll describe how to handle brute force attacks from malicious IP ranges hitting your AD FS portal.

Sources:
Connect to Exchange Online

Client Access Rules Information

Client Access Rules Procedures

New-ClientAccessRule Microsoft Doc

Enabling Extranet Lockout in AD FS 3.0

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

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

Export Licensed Office 365 Users Using PowerShell AzureAD 2.0 Module

I figured it was time to bite the bullet and start converting all of my scripts from using the MSOnline V1 module to the new and shiny AzureAD 2.0 module.  Since I was finding few to no posts on pulling licensed users using the new module out there on the interwebs, I figured I’d share my findings.  You can get the AzureAd module quite easily from the PowerShell gallery by using the command:

Once you have that, you are ready to rock and roll.  The following script will connect to multiple AzureAD tenants, snag all AzureAD users, determine if they have a license assigned to them, and if they do export their UPN to a custom PowerShell object with the property name of Email Address.  I only did this because this is for marketing, and that’s what they wanted (they didn’t want to have to edit the export file at all).  But that’s enough explanation, let’s get to the good stuff.

 

Loosely based off of some of the examples found in this blog post.

Create a “Dynamic” AD Group using PowerShell

I had a request come to me today for an AD group that will always contain all of the users in a particular OU.  If you have come across my little place on the internet before, you are likely familiar that I do a lot of work with AD FS.  Keeping that in mind, I wanted to make sure only users that were synced with Azure AD/O365 from this OU were added to the group.  Additionally, if that user were no longer synced with Azure AD/O365 I wanted to remove them from the group to keep it tidy.  And thus I came up with the following script that I have run every hour:

 

Exchange Online Missing Mandatory Parameters: ArchiveGuid

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.