Search This Blog

Tuesday, June 18, 2019

Intune GPO Enrollment

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 reccomend 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 doesnt 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.

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.

Friday, July 6, 2018

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.

Friday, June 22, 2018

How To Ingest A Custom .ADMX File For Modern Managment

Hello everyone!

I am breaking one of my own rules today by posting a straight up guide. I want to do this because 

A.) There are not a lot of guides out there on this topic
and
B.) I feel like I may be able to explain it in a different manner, put my own lazy admin spin on it.

Before we go to far lets talk a little but about Windows 10 and the concept of Modern Managment. 

Windows 10 has been built from the ground up to be managed as a mobile device. We are able to accomplish this with a few different protocols, which I myself and not really clear on all the details, but some of those are OMA-DM, SyncML, CSP's, and another OMA-Something,Something. 

What this boils down to is anything that is not exposed through your MDMs GUI you will have to use what is called a 'custom policy' or 'custom profile' depending on your MDM solution. These are lines of pseudo code that you can input as SyncML, which to me looks very much like XML. Dont ask me the difference, I dont know. Im just the messenger here.

So, Microsoft maintains a list of all the CSPs you can configure here

https://docs.microsoft.com/en-us/windows/client-management/mdm/configuration-service-provider-reference

Most of these will map out to existing legacy GPO settings. There are 2 types of CSPs when you boil it down. Native CSPs and Policy Backed CSPs. It is important to note this because they are constructed differently. All of the Policy CSPs are under the Policy tab in that reference. 

There is a third type of Custom Policy we can push out though, that is third party .ADMX policies. Everything in the above reference website are all first party options from Microsoft, very much built in policies. 

What happens when you want to configure something like Google Chrome or even Microsofts own Office Suite? Well that is where .ADMX Ingestion comes into play. 

Before we get into it let me tell you the basic idea of it. You start off by grabbing the actual .ADMX file for the GPOs you need. You then open up the .ADMX and copy the entire contents into a custom policy. Once this is done you can create another rule within that policy to configure the options contained within that .ADMX file. This will all become much clearer.....hopefully.



In this example we are going to modify an Outlook GPO that determines what authentication type we would use with Exchange. This is what the GPO looks like on the DC





As you can see it is not just a enabled/disabled option, it also has a drop down menu. Other GPOs may have a table, a custom value you have to put in, or any other number of options. Those are also all configured differently in our policy. This guide will show you how to do both those basic just enabled/disabled GPOs as well as drop down menu GPOs. 




So now that we know the GPO that we want to carry over into Modern Managment we can open up the actual outlook.admx file and begin. The first step is to copy THE ENTIRE .ADMX into our custom policy. 

To do this we want to go into our MDM and create a new custom policy. A custom policy can contain any number of SyncML entries. Our first entry is going to be the entire .ADMX. Lets give it the policy a name, i'm fond of just using the app name. We also need to tell it where to store this .ADMX file.


The OMA-URI should look like this ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{AdmxFileName}

OMA-URI IS ALWAYS CASE SENSITIVE!!!

In this URI the following variables should be provided:
AppName: This should be the name of the app that will be configured, but can theoretically be anything. In this example I’ll use Outlook16
SettingType: This should always be policy with ingesting ADMX-files. So, in this example I’ll use Policy
AdmxFileName: This should be the name of the ADMX-file, but can theoretically be anything. In this example I’ll use outlk16
So the completed string would look like this
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Outlook16/Policy/outlk16
You need to remember the choices you have made here in the name, as it will need to be referenced in your setting config. 
For Data type choose String and for Value copy and paste the whole .ADMX file. I like to open the .ADMX in notepad++ and then format it as XML. Then use ctrl+a to select all and ctrl+c to copy it. Then just paste it into your Intune console.

Here is a pic of my completed setting

Once this is completed we now the ability to configure any setting contained withing the ADMX file. For our setting we want to hit the blue add button in our custom policy again and give it an appropriate name and description. Now the hard part starts. For OMA-URI we have to craft a specific string that traces back the parent categories. In order to do this we need to go back into our Notepad++ and do a search for a term that would find our specific setting in this XML mess. I searched for Kerberos. In the screenshot below all of the highlighted text is our 1 policy setting we need to configure.

At the top of every .ADMX file the first section are all of the parent categories. We need to find these and write these down in notepad. We can see in our highlighted text above that for our setting its parent category is "L_Exchangesettings" if we do a ctrl+f and search the document top down we will find it in the top of the document with a reference to IT'S parent category, we then do a ctrl+f and find that one, that one may also have a parent category, so on and so forth. When you come to the final category its parent will be itself, you will know you are done with this step then. See the screenshot for more detail.


Now to create our OMA-URI string we need to create it like the following
The OMA-URI should look like this ./{User or Device}/Vendor/MSFT/Policy/Config/{AppName}~Policy~{CategoryPathFromADMX}/{SettingFromADMX}

REMEMBER CASE SENSITIVE! USE THE SAME CASE AS THE GPO USES!!!!
User or Device - Here what you would use depends on the GPO, is it a computer setting or user setting. In our example we will be using User
Appname - This is the same name from our previous ingestion file, we just need to reference where we put it, so for our example we will use Outlook16
Policy - This is literally the word Policy
CategoryPath - This is our path we copied down in notepad starting with the top level parent L_MicrosoftOfficeOutlook and going all the way down to the first "parent catagory" in the admx file which would be L_Exchangesettings with the tilda ~ between each category
SettingFromADMX -  This is our actual "policy name" from the screen shot above which is L_AuthenticationwithExchangeServer 

So, in all of its glory, for our example the OMA-URI would be (things in bold are things that are not static and things we have configured) 
./User/vendor/MSFT/Policy/Config/Outlook16~Policy~L_MicrosoftOfficeOutlook~L_ToolsAccounts~L_Exchangesettings/L_AuthenticationwithExchangeServer
So in this OMA-URI we have said where the policy is that we want to flip on and off. The next piece is changing the actual values. The next option you will see with Intune is the Data Type box, set this to String. Then in the actual value box we want to put in the following
<enabled/> <dataid="L_SelecttheauthenticationwithExchangeServer" value="9"/>

Let me explain what these are doing, the first piece is obviously turning the policy on.If this was just an on or off policy we could stop here, but this is a multi valued policy.
The second piece, well,  the best way to think of this is the name of the drop down box. This is the Enum id from the admx screenshot above. L_SelecttheauthenticationwithExchangeServer
The value="9" part is what sets the policy to allow either NTLM or Kerberos auth. We can tell this because of the display name right above it gives us a small description of what that number means. If we only wanted to say allow smart card authentication we would have done value="2147545088" 
The completed setting looks like the below image.




If you are having trouble getting this policy to apply you need to triple check your syntax. Some common things I have seen are weird quotation marks when copying and pasting from Notepad++, these policies are also case sensitive, and for this particular policy I could not get it to apply until the device actually had an Outlook profile on it.

In order to see if your policy has applied you can check 3 places. 

In the Intune console, under device configuration>policy>device status



On the machine itself under settings>account>work or school>info



You can also check the registry on that same machine. Remember we are just fundamentally setting registry keys.



I hope this can help some of you make the jump from the legacy style of management into the not as developed, but way more mobile and growing modern management style.

Thanks for stopping by! Drop a comment below if you have any questions!