AAD Connect and Pass Through Auth Possible Gotcha

Hello again everyone!

Been awhile!

I want to make a quick post about an issue I ran into out in the field in regards to AAD Connect, Pass-Thru Auth, and log on restrictions in local AD. 

**Spoiler Alert** Read your documentation thoroughly and you can avoid stupid mistakes like this one!

Lets start off with a brief explanation on what Pass-Thru Auth is. This method of auth/ssso is similar to ADFS. When you attempt to auth against O365/Azure AD it will send the request back on premise to an agent that is installed on a member server. 

There are certain requirements that this member server needs that we wont go into in this post, such as line of sight to a DC, multiple agents for HA, etc, etc.

Now onto what the issue was.

At a client we recently had a group of users, well maybe 'users' is not the correct word for it, nor is 'service accounts'. It was a handful of user objects in AD that the security team used to log into a very specific set of workflows on premise and into a couple services in the cloud. 

They just stopped authenticating one day. 

When trying to auth against a cloud service they would receive this error 'Service is currently unavailable, please contact support for further help'

When we looked at the sign in logs inside of Azure AD this is what we saw.

We tinkered with the idea that AAD Connect was not syncing the password so we took a look at the health monitor. Everything looked good but thats when I saw they were using Pass-Thru Auth. 

We dug a little deeper and found out that this user account had a log on restriction on it in local AD that was just implemented.

(this photo from my lab, hence not sanitized. I dont care if you try to compromise Zangief, the red cyclone will pile drive you)

Well there is our culprit. When using Pass-Thru Auth and you are doing log on locally restrictions you need to add whatever server the agent is on into the log on restrictions

Once the agent servers are added you should no longer be barred from accessing any other services. If you need to lock down your cloud services for these accounts that is where Conditional Access come into play. 

Moral of the story? Check your documentation when you make a change. This is laid out in the Pass-Thru Auth doc, although it is tucked away under the 'troubleshooting' doc and not the main concept or implementation document.

Hope this helps someone else out before they waste a few hours trying to figure out what the issue is.

Until next time everyone!

Azure AD Hybrid Join and the UserCertificate Attribute

Hello Everyone, 

Today I want to talk about an issue I ran into recently with trying to setup Hybrid Azure AD Join. 

First lets do a little background on the process. Microsoft has a decent guide on how to do it which can be found here.

https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup

The exact situation I ran into, or at least that I thought I ran into, was the fact that the device object was not syncing into Azure AD. 

In order for a Hybrid Join to occur you have to sync the device object with AAD Connect. Inside of AAD Connect there are certain sync rules and settings. One of those rules states if the userCertificate attribute on a machine is $null then do not sync it.

Now you technically can brute force a fix by either manually putting in literally anything for that attribute (I tried, it accepts a junk value) or changing the rule in AAD Connect to sync the object anyways. Either way I would not recommend as something else is most likely the actual root issue and wont fix the problem.

For awhile I chased down the idea that this attribute was generated upon domain join (due to a tip from an MS rep), spoiler alert, this is not when the attribute is generated on the Active Directory Object. This attribute is generated AFTER the Win10 device probes the SCP you setup in your AD and actually finds something. 

So, at a basic level, this meant that my issue was one of communication. For whatever reason my device was not communicating with Azure AD. This issue was solved two different ways for me when I ran into it across a few customers. 

1.) ADFS. If you have ADFS in place you need to place the claims rules in ADFS correctly. In my specific case the users UPN and the domain that they had federated with O365 was user@domainA.com but the real domain name on prem and the name that all the devices used was computer.domainB.com. The fix in this scenario was to federate domainB.com with ADFS as well and include domainB in our claims rules. 

2.) Scheduled Task. At two of my clients we ran into this without ADFS being in the mix. We were using AAD Connect with SSSO. The fix in this situation came in the form of enabling the scheduled task built into Win10 devices that attempts to do the Hybrid Join. This task can be found at Microsoft>Windows>WorkPlace Join. For some reason this was disabled, it should be enabled by default. I suspect something to do with SCCM but can not verify.

Once this was actually enabled the device was able to probe the Azure AD Join service, generate its specific userCertificate attribute and then complete its join after a login or two. If this does not happen for you this task can also be controlled by a GPO that can block the device enrollment. As a test I would move a device into an OU with no policies on it and work off it from there.

So, to recap, usually not having a value in the userCertificate attribute is not the actual issue. Something is stopping the communication between your machine and Azure AD. 

Event Viewer is also pretty helpful in tracking down some of these issues as well. You can view the logs at Microsoft>Windows>User Device Registration. If the above does not help you I would check here for further info. 

Hope this can help some of you, see ya around.

Intune, Outlook App, and the Legacy Conditional Access Changes

Howdy howdy howdy

Sorry, been watching a lot of Toy Story.

In today's post I want to spell out some of the changes that have been made to Conditional Access and the depreciation of the legacy policies, specifically around enforcing the Outlook App through Intune.

Before you were able to use a simple drop down box to enable this option

Apparently this method of blocking access to non approved apps is considered "legacy" now and the functionality has changed

On the back end this blocked Exchange Active-Sync as well as other client apps with just a flip of the switch. That appears to no longer be the case, at least in my own personal tenant and in a couple customer tenants I've had recently. Moving forward you should use the new condition of "Require approved client app"

Not to much of a change so far. The main thing I want to stress here is that you now need to create two policies with this conditional grant, one for EAS and one for all other protocols. This is done by creating one policy with the targeting condition of "Browser" and "Mobile apps and desktop clients" under the "Client Apps" setting

Then another with the "Client App" setting of Exchange Active-Sync. We also want to make sure the box for applying the policy only to supported platforms is NOT checked. We want this to apply to all platforms ideally, that way no sneaky Blackberrys can find their way in. I also ran into an issue where if this box was checked this rule would not filter down to Android For Work, not sure why on that one but no biggie in the grand scheme of things (I love comparing things to the "Grand Scheme" being everything, no matter how important just seems small! Its like a get outta consulting free card!)

Once this is set users will receive a message in their mailbox explaining that they now need to use the Outlook App moving forward.

Hope this helps someone out there.

I feel like I should have a sign off phrase, but I don't. Maybe that is it though

"I feel like I should have a sign off phrase, but I don't".

Exchange Online Certificate Based Authentication

Hey guys!


Today I want to build upon the last post surrounding Intune and certificate services. Once we get the certificates onto the devices the next step is to configure our services to accept certs as a form of authentication. 

I want to talk about configuring Exchange Online in this post and some caveats when setting that up. 

Per usual I dont want to spell out a guide for everyone. Those can be found in a multitude of places. There is a good one here.

https://blogs.technet.microsoft.com/messagingblogs/2017/02/16/certificate-based-authentication-o365/

What I do want to talk about are some of the gaps that this guide didnt cover. 

First thing is the intermediary. In a best practice PKI deployment you should have a Root and an Int certificate. I would publish both certificates and CRLs to Azure AD using the guide above. When you deploy the Int cert be sure you change the powershell from this

Get-AzureADTrustedCertificateAuthority

$Cert=Get-Content -Encoding byte "Location of Root CA CER file"

$New_CA=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation

$New_CA.AuthorityType=0

$New_CA.TrustedCertificate=$Cert

$New_CA.crlDistributionPoint="CRL Distribution URL"

New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $New_CA


To this "$New_CA.AuthorityType=1" this will specify the cert we upload as the Int.

I reccomend putting the Int cert on the devices we deploy as well as accepting it for authentication in AzureAD

The next little gotcha they don't mention is that ADFS certificate based auth goes over a different port. It goes over port 49443 so make sure you aren't blocking that port coming into the WAPS.

And last but not least make sure that you configure ADFS to accept cert based auth. In ADFS 2016 its a little checkbox under authentication types.

Lets Talk About Azure AD Conditional Access and Automatic Device Registration

Let's talk about Azure AD Conditional Access for a second. 

Its deceiving, like rob you in the night after you thought you were friends deceiving. I say this for two reasons. 

1. In the rules for Conditional Access there is an option that is labeled 'domain joined'. This is misleading. What this is really checking against is if the device is registered within Azure AD and domain joined. If the device is domain joined but not registered then it won't honor the conditional access controls. Registration can happen automatically for domain joined devices once some configuration is done on prem (more on that later).

2. Conditional Access only supports applications that use modern auth. This wouldn't be so big a deal if when you enabled Conditional Access it disabled legacy authentication methods. It doesn't. What this means is all your fancy layered rules can be defeated by someone in China firing up Outlook 2010 and using a compromised account. Don't believe me? Take a look here. 

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-supported-apps

Microsoft's suggested fix is to stand up ADFS and use claims rules to block legacy auth....not much of a fix in my opinion.

I want to circle back around to point number 1 and talk about how to do automatic registration of domain joined devices. 

Its not my style to just rehash all the steps in another article unless I had some sort of gotcha moment during it. The steps to enabling this feature can be found here 

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup

What I do want to touch on is some scenarios I had thought about when doing this. First some background info on how the registration works. Windows 10 devices have the logic to join Azure AD baked into the OS. You configure your SCP point and configure ADFS if you have it and you're off to the races. 

A little caveat that I found out is that my devices would not sync unless I was also syncing their Computer Account Object. I believe this is due to Windows 10 machines not being tied to a user account when they sync (more on that later). I did some testing and what I saw when I stopped syncing the Computer Objects was that it also removed my registered devices out of Azure AD. That is gotcha #1

Windows 7 devices are a little different. They require a small MSI package to be ran to force a registration since they do not have the baked in logic. What I found when testing these guys is that they are tied to a user, whatever user's login triggers the join gets the device put in their name. This means that only users that are being synced into Azure AD can register. Gotcha #2. If a non synced user tries it will fail silently. 

What is interesting though is that if a synced users stops syncing or gets removed from Azure AD the device will remain and not be associated to any user, like the Windows 10 devices.

So huge wall of text. Here's a picture of my devices and the output of dsregcmd /status on a successfully joined Windows 10 machine to make it all better.

See ya later!

Adding Additional OUs to AAD Connect Sync Filter

Hello again internet. Had a quick post I wanted to write up on changing or adding new OUs to your AAD Connect sync filter. 

First lets start off with a little background information. After you install AAD Connect by default it runs what is called a 'Delta' sync every 30 minutes. This sync only syncs changes made to objects since the last sync. 

The inverse of this is an 'Initial' sync and runs a full sync against all objects regardless if they have been changed or not. This feature is useful for 2 reason. 

1. Running an Initial sync is like giving AAD Connect the old turn it off and back on. Doing this can actually alleviate certain sync errors. I don't actually believe this is an intended use or feature of the Initial sync but what works in the field isn't always what works on paper.

2. Running an Initial sync will pick up any changes to your object filtering, such as adding or changing what OUs you are syncing. A regular Delta will not do this. 

------------------------------------------------------------------------------

Now that we have that out of the way lets get into how to actually change what OUs you are syncing. The easiest and best way to do this is through the 'Synchronization Service' GUI. If you ever messed with AAD Connects predecessor, Dirsync, then this will look familiar. 

Once you are greeted with the console above you want to go to the Connector button across the top ribbon. When you arrive at this page you want to right click the connector with your local domain name and choose properties. 

Once inside of the properties you want to drop down to Configure Directory Partitions and then choose the Containers button.

You will then be greeted with a login prompt. Enter admin credentials with the proper permissions, which could vary depending on if you used express or custom setup. Once inside you will see a GUI with your AD layout. A simple check of the box, just like what you did during setup, can remove or add any OU. 

Once you have done this you will want to run an Initial sync. You can kick these off from the GUI but its messy. I reccomend using powershell. You can use the command

start-adsyncsynccycle -policytype Initial

Yes that is the word sync in there twice. You can also use this command to do a -policytype Delta switch for those times you want to manually kick off a sync. 

Once you run this Initial sync all the objects in your new OUs should start syncing!

If anyone stumbles upon this hope it helps you out some.

AAD Connect Error, Encryption Keys Could Not Be Accessed

Hello again,

This installment I have a write up on an error a co-worker encountered in AAD Connect. All credit for write up goes to an engineer by the name Cody Rowe, reposted here with permission. Thanks Cody!

Fixing AAD Connect Service Account Issues

Friday, February 10, 2017

12:58

Issue: Server had not been restarted for a very long time.  Customer needed to install updated VMWare tools for their backup solution.  On reboot, the ad sync service could not start and gave off this error.

Resolution:

That led me to a few thoughts after doing some searching. 

·         An update was installed after reboot.  Maybe this broke the service.

·         The local service account used to start the ad sync service was affected by the reboot.

After coming up empty with repairing, reinstalling and looking over event viewer longer, I decided to proceed with the assumption that the local service account had its password reset.  I reset the password to the local service account :

Added the service account to local administrators to be able to log into the machine with said account.  Logged out and logged in as the service account.  Make sure you update the password associated with the service

Now I went through the process of abandoning the previous encryption key and adding in a new one.  Run miiskmu.exe located in the Bin folder for the ad sync directory with elevated permissions.

You'll want to select Abandon key set, then provide the credentials for the local service account.

When the operation is complete, stop the ad sync service since it will automatically start and attempt to create new encryption keys.  Go back to the key management utility and select add new key to key set.  I opted to select re-encrypt as well.

When that finishes start the service and open powershell.  Run the following.

Import-module adsync

Start-adsyncsyncCycle -policytype delta

After this ran I was getting some errors I did not expect to happen when it was healthy.

Specifically the stopped-extension-dll-exception is what I'm concerned about.  Going to event viewer it appeared that I was getting password issues with the service accounts.

I reset passwords for all the service accounts (AD for both forests, Cloud service account for machine) and added the updated passwords to the connection credentials for all 3 connectors.

After that I ran another delta sync, and everything came back clean.

Editors Note, From another colleague

To add to that, when you abandon the key, all of the data inside the sync database that was encrypted with the old key is invalid.  This includes the passwords for the accounts used by each connector.  This is why the last step was required

Deleting an old AAD Connect Service account

Just a little tidbit that had me confused for a second. You can not delete an AAD Connect service account from the tenant portal, you have to do it from within Azure AD. Im sure there is also a method to do this from the shell as well. 

A normal AAD Connect service account will look like this



You can tell which one is the new one because the account is always made with the server name after the Sync_ in this case this account is tied to DC01 from within my org.

You also can no longer disable AAD Connect from the new portal from within the GUI. The new portal requires you to connect via Powershell and run

Set-MsolDirSyncEnabled –EnableDirSync $false