Search This Blog

Monday, October 21, 2019

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!



Tuesday, August 13, 2019

Intune GPO Enrollment With MFA Quick Tip

When enrolling a device that is already Hybrid Joined you may run into an issue when the account that is first logging into the machine has MFA enabled on it. 

Depending on how you rolled out MFA, if you did the entire identity option in the classic portal or if you are using CA and you choose all cloud apps as your MFA target you may run into an issue that will require users to complete an MFA challenge to enroll the device into Intune. That prompt usually takes the form of a notification that reads something like 'your account needs attention', 'there is an issue with your account', or 'login to fix your account', etc...





Once you select this prompt a traditional modern auth window should pop up and ask for an MFA prompt. Once you complete this the device should then enroll after some time has elapsed. 





To remediate this either complete the prompt, move your MFA to Conditional Access, or exclude Intune Enrollment options from your MFA policy (which sometimes does not work as 'All Cloud Apps' protects some backend services that you can not exclude when included in a CA policy)

Hope this helps some of you out.

Tuesday, June 18, 2019

Intune GPO Enrollment General Info

Just a quick note on how to enroll an existing domain joined device.

If you have not yet, a prerequisite for the GPO enrollment is Azure AD Hybrid Join. You can find directions on how to accomplish this here

https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-managed-domains

You can also find some more background information on it here

https://www.amobileattempt.com/2018/07/hybrid-join-azure-ad-and.html

Once you have that completed and are running the correct version of windows, I recommend at least 1803, and have your GPO store updated as such you can create the new GPO and deploy it to your Hybrid Joined Devices. Information on that process can be found here.

https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy

What this article from Microsoft doesn't tell you is where you can find the event logs for this process or what the error codes you might find are. The location in the event viewer is 

Applications and Services Logs/Microsoft/Windows/DeviceManagement-Enterprise-Diagnostics-Provider/Admin





MS does offer additional tshooting help in some tucked away corners of their platform that I want to gather here. Use the below links as a starting point. Good luck!

https://support.microsoft.com/en-us/help/4494359/troubleshoot-intune-windows-10-group-policy-based-auto-enrollment

Tuesday, April 2, 2019

Intune App Protection Policies and iOS Exemptions

Disclaimer: While the below information should be true, I still can not seem to get the App Protection Policies to behave in an expected manner with regards to exclusions. I am beginning to suspect it is just broken.

Hello Everyone!

No amount of searching has been very helpful for me personally when trying to find iOS application identifier URLs. 

A URL identifier is a unique name that each iOS application must have. Using this name an existing application on an iOS device can call upon that app to perform actions, such as open a file. 

To my knowledge there is no list out there for such identifiers. What I would like to do is start that list here. 

My only methods to finding out this URL identifier are to either ask the developer or to take a guess and test it inside of safari. If you open safari and type the following into the address bar

guessedappname:// 

You should get a result of either app not found, or something that asks if you would like to allow an app to open the webpage. See screen shots below.

BAD GUESS


CORRECT GUESS

Without further ado here is the very short list of ones I have used in the past. If you know any additional ones leave a comment below and lets get them added to the list.


  • Salesforce - salesforce1
  • Go To Meeting - gotomeeting
  • AutoCAD DWG Viewer and Editor - autocad
  • Webex - wbx
  • Zoom Cloud Meetings - zoomus
  • Slack - slack
  • Apple Maps - maps
  • Google Maps - googlemaps

The items on this list were generated by myself and the community. I have not verified the accuracy of most of them. I am asking for the communities help in either adding to the list or for a more foolproof way of finding out the applications URL identifier.

Thanks everyone!

Tuesday, March 12, 2019

The Intune Exchange Connector Workflow and Gotchas

Hello readers!

In this post I want to talk about some of the Intune on-premise Exchange Connector gotchas and how the communication flow works. 

What is the Exchange Connector?





The Intune Exchange Connector is a piece of software that you download from the Intune portal and install on your Exchange server. Specifically the CAS role if you still have seperated roles. Installation instructions can be found here.

https://docs.microsoft.com/en-us/intune/exchange-service-connector-configure

Please note that the section on the 'Service to Service' connector should be ignored. That feature is being deprecated and was honestly never needed in the first place.

I dont want to go over installation, the Microsoft document does a decent job of that and its fairly self explanatory. I do want to touch on the communication flow. It looks something like this,

For iOS, and Knox devices there are 2 routes. Either you install the company portal first, or you try to add an EAS account first. We will go over the adding an EAS account scenario.

1. End user adds thier EAS account to their mobile device
2. After some time the Intune connector will sync the EAS record up to Intune
3. If the EAS record gets synced up and there is no corresponding MDM record the Intune Connector will set the device from allowed to blocked
4. The end user will recieve an email asking them to enroll into Intune
5. The end user enrolls the device into Intune and creates an MDM record
6. The EAS record and MDM record merge to become a EAS/MDM record in the Intune console
7. The connector will do another sync and check that the record is merged. If so it will remove the device from blocked back to allow

Where this process gets tricky though is for non-Samsung Androids. For some reason, and this may change with Android Enterprise, when a regular Android device enrolls into Intune it does not report its Active-Sync ID. They way we get around this is by using the link in the email notification we receive on the device that says we've been blocked. This link contains our EAS ID and will communicate that to the Intune Service. Without this link our EAS record will never merge with the MDM record when enrolled.

This also makes it tricky to use any type of non native email client as these clients create their own EAS record but can never create an MDM record to match to. The MDM record is always owned by the device not by the email clients on it, if that makes sense. Long story short you have to use the native mail clients when doing this or you have to create an exception for certain platforms.

I will say it again, non-Samsung Android devices have to enroll via the email notification!!! Just going to the app store and getting the company portal app will not work. Enrolling using the app before you receive the email notification will not work.

Here is where the gotchas come in to play. There are two main ones that I want to cover. 

When setting up the connector it asks you to enter a notification account. You need to enable that and MAKE SURE THAT ACCOUNT HAS A MAILBOX!







Without a mailbox the end user will never receive the email asking them to enroll with the link that contains their EAS ID. 

Second gotcha is that this service relies heavily on the Autodiscover service. Very heavily. If your Autodiscover is not healthy then this process will fail. One specific example of this when working through this in my lab was that I did not have an internal DNS record for Autodiscover.rollerlabs.com. This is because internal Outlook clients do not use the DNS record to find AutoD, they use the internal URI that is set within Exchange. I never had a need for an actual internal DNS record before. 

The connector was reliant upon that to find the Exchange server, even though you specify in the connector what your server name is, it will still look at AutoD.





Once I added the internal AutoD record I was able to receive the enroll now email.




This is just an image pulled out of a search but it lets you see the format of the expected email. Please note that the activate/enroll email with link that contains your EAS ID is not the same as the email generated by the exchange server that tells you your device has been blocked. The activate link will come from the Notification account.




Hope this is helpful to someone out there. Is anyone still using Exchange on premise anymore? Hello? Bueller?



Thursday, February 28, 2019

SSPR Note From The Field

Hello Everyone!

Today I want to talk about a little issue I found when deploying SSPR at a customer. We enabled write back in AAD Connect, used a test group to start with in Azure AD, set all of our options up, created a new test user on prem and synced it up into the group. 

Everything appeared to be working. 

When we rolled it out to the general population (without forcing enrollment so most of production never even knew something was wrong when it broke) we started seeing some weird behavior on our existing users. When they would go to reset thier password we would get this error in the portal




Except everything did meet the policy. We then traced it back using a few various logs. One place where nothing showed up was in the Synchronization Service app on the AAD Connect server. Where we did see something was in the Azure AD Audit Logs




And the Event Viewer on the AAD Connect server as well


Come to find out most existing accounts had the restriction of 'User cannot change password' set in their account options in Active Directory from some past project that the current admin was not aware of. 



If your running into a similar situation maybe take a look there. This can be fixed either manually, with PowerShell, or as luck would have it this is one of the options you can set when you select multiple user objects in ADUC.

Good luck!

Monday, October 8, 2018

Securing Traditional Domain Joins

Hello Everyone!

My bread and butter are EMS deployments and some general O365 security talks. 

A lot of my customers really like the option to limit logins to certain cloud services to only Hybrid Joined machines using Conditional Access. 

For those unaware, at a high level, the Hybrid Join process will automatically join a domain joined Windows 10 machine into Azure AD. 

When I help people with setting this up I always check to see if they have modified who is allowed to join a computer to the domain. At the time of this writing (Server 2016) the default is that any authenticaed user can join up to 10 devices to the domain.

Thats right folks, by default you do not have to be a domain admin to join a machine to your domain. Above the obvious issues like clutter in AD, duplicate objects, SID issues, etc there is also the issue that the person who joins the object to the domain becomes the owner of that object in AD and can see some sensetive attributes.

Anyways, in our case this almost invalidates the reason most companies want to do Hybrid Join, which is to prevent personal machines from accessing corporate cloud resources. If the user brings thier laptop in though and decides to join it to the local domain then were back at square one. 

The easiest way to fix this is with a GPO on your domain controllers.

The GPO is located at Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignments > Add Workstation to Domain




Once you find the GPO you can add whatever group you would like to keep it locked down.




Just a little tidbit that some people dont realize! I think were all so used to only having an admin join a machine this can slip through the cracks.

Until next time, have a good one.