Search This Blog

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}. 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}
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 work 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++, I believe these policies are also case sensitive but am not 100% sure, 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!

Tuesday, January 30, 2018

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".

Monday, December 18, 2017

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.



Friday, December 8, 2017

Using a Public Certificate For Intune Certificates

Hello Everyone, long time no talk!

Today I want to go over an experience I had with a client setting up Certificate Based Authentication (CBA) to Exchange Online. 

To give a brief rundown of how this is accomplished I will put a couple bullett points below

1. Have an Internal PKI

2. Add and NDES Server to your PKI

3. Configure templates

4. Configure cert profiles in Intune

A great guide on how to accomplish this can be found here

https://www.scconfigmgr.com/2016/04/12/prepare-your-environment-for-scep-certificate-enrollment-with-microsoft-intune/

The issue I ran into comes from the use of a trusted public certificate to secure the IIS server and Intune Certificate Connector instead of one from your internal PKI as in the steps Nickolaj provided in his blog. 

By default the NDES Server places its own DNS name in certain registry values that it expects the certificate to have. When using a public cert we need to change those values in the registry. 

The keys that need to be changed can be found at



The values that hold the server name should be changed to the namespace on the public cert. See example below. Client information has been removed but you get the idea.


After this change was made our SCEP certificates were getting to the devices. 

Hope this helps someone out there that may be hung up on this issue.

Until next time.

Tuesday, August 1, 2017

Exchange upgrades and forgotten servers

Hello Everyone! 

Got a guest post from a colleague of mine today. Erick Purkins is a Microsoft consultant out of the Houston Texas area and he did a write up of a recent issue he saw. Enjoy.

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


I just wanted to share an experience and issue with everyone this morning.

I am currently working with a customer to upgrade their Exchange 2010 infrastructure to Exchange 2016. During our discussions, we talked about correct service pack levels and OS’s required, etc. One thing I didn’t think to talk about was “FAILED EXCHANGE SERVERS”. Just curious if anyone brings this up?

This is important because during the installation of their first 2016 server I received a rather odd error.



It was the “Update-RmsSharedIdentity -ServerName $RoIeNetBIOSName was run: "Microsoft.ExchangeData.DataVaIidationException: Database is mandatory on UserMaiIbox.” That led me to the issue.

Apparently at one time or another they had an Exchange server go belly up. Instead of fixing the issue they turned it off and forgot about it, eventually having someone go in and remove the server through ADSI.

Now normally this wouldn’t have been much cause for alarm, but after reviewing the error message and a little google-fu I realized they had no arbitration mailboxes and this was what the error referred to.




  • So How did I fix this issue?

First, I reviewed how to recreate Arbitration mailboxes. Something I have done before but not in a while.

  • OK seems easy, right? Wrong.

Since I had previously run the Exchange 2016 setup it had ran /prepareAD and updated the schema. So I could not run the Exchange 2010 SP3 with /PrepareAD to recreate the mailboxes.

  • Where to next? I guess I’ll have to use the Exchange 2016 Media.

I hope you’ll never have to do this but with Setup.exe there is a /mode switch which you can use to remove a failed Exchange install. This is the only way, you cannot remove the install through add/remove programs. The command looks like this “Setup.exe /mode:uninstall /iacceptexchangeserverlicenseterms”  


After successfully removing the Exchange installation I removed the AD objects associated with Arbitration mailboxes and re-run Setup.exe /prepareAD. All the correct mailboxes were recreated in the Default Users container as they are supposed to.

  • Now it’s time to enable those mailboxes…

After recreating the mailboxes with the Exchange 2016 Media I followed what I would normally do and re-enable them through the shell. Okay new error, WTH? You mean to tell me I can only do this through the Exchange 2016 Shell, but I haven’t gotten a server even installed yet. Now we have a Chicken or the egg situation.




  • Do we try and install Exchange 2016 again? You Feeling Lucky?

That was the only thing I could think of to do and the internet was no help with that question. So I ran setup again and prayed to the Microsoft gods while crossing everything and holding every lucky charm I could find.

Must have been the lucky rabbits foot, because this time around we were successful at installing Exchange 2016.










After rebooting the server all arbitration mailboxes appear on the new Exchange server.  





  • Moral of the story


Talk to your customers about failed or improperly decommissioned servers. Double check your arbitration mailboxes prior to any upgrade. It may just save you a few hours of Google-fu. Also, always keep a lucky rabbits foot close at hand. 

Wednesday, July 19, 2017

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!






Friday, July 7, 2017

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.