ToolBox Guide to
I love the Out of Box Experience (OOBE) combined with Azure AD (AAD) on Windows 10. It gives you AAD join from anywhere and automatically enrolls the device into MDM (in my case AirWatch WorkspaceONE). This is what modern management is all about - cloud, cloud, cloud. However, most organizations still have a lot of on-prem resources that they will need to access from that client such as web sites, CIFS File Shares, printers, LDAP applications, and others. Windows Hello for Business enables this by using a certificate deployed to the client via an on-prem Microsoft CA. Without this cert, your on-prem AD has no way to validate your identity on the client. There are two ways to implement this. One is "key-trust" and the other is "cert-trust". Key trust uses a certificate deployed directly from Azure and syncs in back to your on-prem AD as a user attribute (ms-DS-KeyCredentialLink) and your domain controllers are able to use this for kerberos validation. This is a much simpler process to setup, but it requires your devices to be "hybrid" meaning on-prem AD joined + Azure AD registered. Here's a decent article on setting up key-trust. For "cloud only" AAD joined machines (like ones that have gone through OOBE), you must use cert-trust method. This is the method I'm using. In part 1, I will be detailing how to setup:
I will also not be using ADFS, but instead use WorkspaceONE for identify and federation. WS1 will also be used to deploy the certificate to client. Pre-ReqsThe full list of pre-reqs are here. We'll be using the "hybrid deployment" even though the client itself is cloud only joined. The hybrid term refers to the architecture setup, meaning you are syncing your on-prem AD data into information into Azure AD.
In my setup, I'm using 2016 versions of everything to make it unified across the board. Prep WorkGiven the requirements above, there is a fair bit of prep-work involved that I won't be detailing in this blog.
Once you've done those things, then you can start with Step 1 below. Step 1 - Setup VMware Enterprise Systems ConnectorIf you are using WorkpaceONE for anything you probably already have a VMware Enterprise Systems Connector setup and working. This connector lives inside your network and acts as a bridge to sync in AD data as well as giving WS1 a way to request and deploy certs from your on-prem MS CA. In case you don't have set it up in a test environment, here are the basic steps: 1. Login to the AirWatch WorkspaceOne console. At the Organization Group you are have setup your AD directory services connection in the WS1 console, click on All Settings --> System --> Enterprise Integration --> VMware Enterprise Systems Connector. 2. Click Override, and ensure both check boxes are checked. 3. Click on Download VMware Enterprise Systems Connector Installer. Enter a password and then click download. NOTE this download is uniquely tied to this Organization Group and will only talk to it. It won't talk to any other OGs unless they are inheriting from this one. 4. Take this installer file and install on any server internal to your network that can talk to your AD and MS CA. NOTE there is no user interface for this on the server side, but you will see "AirWatch Cloud Connector and AirWatch Diagnostic Service (ACC)" services running. 5. Once complete, reboot server and then click on Test Connection from console. Step 2 - Setup Certificate Templates on the CABefore beginning this step, you will need to setup up a service account in AD to be used to enroll the cert on behalf of users. This is required as the end users themselves may or many not have direct access to the internal network when the cert is being deployed. AirWatch will be the one doing the cert delivery. Once complete, you can then proceed with the following steps. NOTE: These are taken directly from MS's documentation. I've just cleaned it up a bit and added screenshots. Create Domain Controller Kerberos Certificate Template First, we need new Domain Controller Kerberos Certificate templates created for your DC's. These new templates enable the Key Distribution Center (KDC) and provide clients a root of trust external to the domain. 1. Login to your CA server and launch certsrv.msc 2. Right click Certificate Templates and click Manage 3. In the Certificate Template Console, right-click the Kerberos Authentication template in the details pane and click Duplicate Template. 4. On the Compatibility tab, clear the Show resulting changes check box. - Select Windows Server 2012 or Windows Server 2012 R2 from the Certification Authority list. - Select Windows Server 2012 or Windows Server 2012 R2 from the Certification Recipient list 5. On the General tab, type Domain Controller Authentication (Kerberos) in Template display name. Adjust the validity and renewal period to meet your enterprise's needs. 6. On the Subject tab. - Select the Build from this Active Directory information button if it is not already selected. - Select None from the Subject name format list. - Select DNS name from the Include this information in alternate subject list. Clear all other items. 7. On the Cryptography tab, - Select Key Storage Provider from the Provider Category list. - Select RSA from the Algorithm name list. Type 2048 in the Minimum key size text box. - Select SHA256 from the Request hash list. Click OK. 8. Click OK and this new template should show up in the list Configure Certificate Superceding for the Domain Controller Authentication (Kerberos) Certificate Template Now we basically need to tell the domain controllers to use this new template for Kerberos authentication. You'll notice it has the "KDC Authentication" added to the template whereas the previous domain controller template did not. Again, following MS steps here: 1. Double-click the Domain Controller Authentication (Kerberos) template you just created and go to Superceded Templates tab. 2. Click Add and select Domain Controller template and click OK. 3. Repeat for Domain Controller Authentication and Kerberos Authentication templates. 4. Add any others that were previously configured for domain controllers 5. Click OK when finished. 6. This is not yet active until we "Publish" this new template. To do this, right click Certificate Templates in certsrv.msc. CLick new and then Certificate Template to Issue. 7. Select the newly created Domain Controller Authentication (Kerberos) template. 8. As best practice, it is good to delete those old templates that have been superceded. Select Domain Controller, Domain Controller Authentication, and Kerberos Authentication from the list and click delete. Note you are only delete these as published templates, not the actual templates themselves. 9. When prompted with "Are you sure you want to disable" message, click Yes. Deploy new Domain Controller Certs In order for your DC's to get these new certs, you will either have to manually request them or setup a GPO so that they automatically request new ones. It's best to manually request them for now to test and validate and then setup the GPO once its ready to go live. I'm assuming you're doing this in a staging environment first :) To manually request the new cert, 1. Login to the DC 2. Load certlm.msc and browse to Local Computer\Personal\Certificates 3. Right click in the blank space, and click All Tasks, Request new certificate. 4. Select Active Diretory Enrollment Policy and click Next. 5. Select your newly created Domain Controller Authentication (Kerberos) from the list and click Enroll. 6. It should show Succeeded. Then click Finish. 7. You might still have your old certs in the personal store, so go ahead and delete those out. In my case I have two old ones. Setup Windows Hello for Business Template Head back over to your CA and to the list of templates. Following again the steps from MS with some slight modification 1. Right click Smartcard Logon and click Duplicate Template 2. On the Compatibility tab, clear the Show resulting changes check box. - Select Windows Server 2012 or Windows Server 2012 R2 from the Certification Authority list. - Select Windows Server 2012 or Windows Server 2012 R2 from the Certification Recipient list 3. On the General tab, type WHFB Authentication in Template display name. Adjust the validity and renewal period to meet your enterprise's needs. 4. On the Cryptography tab, select Key Storage Provider from the Provider Category list. Select RSA from the Algorithm name list. Type 2048 in the Minimum key size text box. Select SHA256 from the Request hash list. 5. On the Extensions tab, verify the Application Policies extension includes Smart Card Logon. 6. On the Issuance Requirements tab, leave everything blank. This is where we will differ from the MS documentation as we are not using ADFS. 7. On the Subject Name tab, select Supply in the Request and check the box. This is also different from MS as we aren't using ADFS. This setting allows WS1 to supply the CA the user information from the AW console (enrolled user). 8. On the Request Handling tab, ensure Signature and Encryption and the Renew with same key check box are selected. Also ensure the Enroll Subject without requiring any user input is also selected. 9. On the Security tab, add your service account here and ensure that Read, Enroll, and AutoEnroll are selected. Remove the Enroll and AutoEnroll from all other objects here. 10. Click ok to save the template. 11. Back in certsrv mmc, right click Certificate Templates, then New, then Certificate Template to Issue and select WHFB Authentication to publish this template. You should then see it in the Certifcate templates list. Next in Part 2, I'll go over how to setup an HTTP url and then get everything ready on the WS1 console side to be able to deploy the cert automatically to client.
Comments
Update 4/17/18: This process does NOT require the end user to be local admin as I orginally thought. You can deploy via SCCM in the system context.
AirWatch 9.3 brings a number of new features to the WorkspaceONE UEM platform on Windows 10 including improved silent enrollment features. This will greatly simplify enrollment over the previous method. The new 9.3 agent brings the following updates to silent enrollment:
Use Cases
The primary use cases for this process are:
Pre-Reqs
This blog post will detail how to automatically enroll a Windows 10 system into AirWatch WorkspaceONE that has been newly imaged with MDT. This solution will work with though any imaging solution as well as in-place upgrades task sequences.
Requirements:
Prep
First, enable REST API in the AirWatch console and setup an API user per the steps in this post. I recommend creating an API admin role that is locked down to only a few functions so it reduces the risk of anything happening if the credentials get discovered somehow.
Setup MDT
Update March 2018
AirWatch has the ability to silently enroll Windows 10 systems using command line parameters on the AirWatch Agent msi. You can use SCCM to deploy the AirWatch msi to your Windows 10 systems to automatically enroll them into AirWatch without any user interaction. Pre-Reqs
The Process
1 - Setup Staging OG and Staging AccountIf you have SAML enabled you will need to do a couple extra steps to setup a staging OG and staging account. This is because the staging account can't use SAML for authentication and instead must use a simple username/password. Follow the detailed steps outlined in my other blog on how to setup these things. Note: If you look at the dropdown by "Single User Devices" setting, it might make sense to change it to "Advanced", but this actually needs to stay as "Standard". I'm not 100% why on this but this is what the Product team has told me.
4. Click save and this account is ready to go. If you use lgpo.exe to deploy a local group policy "pack" to your client machines, you've definitely run into the need to make changes later. You can certainly makes changes to your reference machine, take a new backup, and re-deploy the whole thing to your client machines but that means you are re-deploying every setting you have configured. This makes it a little more impactful to the client due to the number of changes you are re-configuring as well as the fact that older versions of Windows 10 are not compatible with lgpo backups made on newer versions. Here is a way to simply change one or two changes to your client machines without having to re-deploy the entire LGPO pack. The Process1. Ensure you have downloaded lgpo.exe from MS's website here 2. Copy to a folder. I'll use C:\Temp 3. Open cmd prompt as administrator and change directory to c:\Temp 4 Make any changes to local group policy via gpedit.msc 5. Take a backup by running this command: lgpo.exe /b C:\Temp /n "Backup" 6. This exports the LGPO into a folder with a GUID. I would recommend re-naming to something easier. Example, "LGPO_Backup"
7. Now you are going to want to parse this backup into a text file. LGPO.exe /parse /m C:\Temp\LGPO_Backup\DomainSysvol\GPO\Machine\registry.pol >> C:\Temp\lgpo.txt Windows 10 version 1703 (Creator's Update) brings the addition of the Office CSP for easy deployment of Office 365. Here's are the steps on how to deploy it to your AirWatch managed Windows 10 system. Thanks to @josuenegron for providing the foundation for this here. Go to the Office XML creator tool and create your deployment XML. Here's what my XML looks like: <Configuration> <Add OfficeClientEdition="64" Channel="Broad"> <Product ID="O365ProPlusRetail"> <Language ID="en-us" /> <ExcludeApp ID="Groove" /> <ExcludeApp ID="Project" /> <ExcludeApp ID="Visio" /> </Product> </Add> <Updates Enabled="TRUE" Channel="Broad" /> <Display Level="Full" AcceptEULA="TRUE" /> <Logging Level="Standard" Path="C:\VMware_IT\Logs\Office365logs" /> </Configuration> Now you will need to take this XML and "serialize" it so that it can be read by the Office CSP. You can go to this free web page to do so. Simply copy/paste your XML in the top box to get the serialized output. Create a basic AirWatch profile and add a new "custom settings" section. Take this XML structure and add your serialized office XML in between the "Data" tags. <Exec> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/Office/Installation/0AA79349-F334-4859-96E8-B4AB43E9FEA0/install</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> </Meta> <Data>pasteyourxmlhere</Data> </Item> </Exec> So with everything added, it will look like this: <Exec> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/Office/Installation/0AA79349-F334-4859-96E8-B4AB43E9FEA0/install</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> </Meta> <Data><Configuration> <Add OfficeClientEdition="64" Channel="Broad"> <Product ID="O365ProPlusRetail"> <Language ID="en-us" /> <ExcludeApp ID="Groove" /> <ExcludeApp ID="Project" /> <ExcludeApp ID="Visio" /> </Product> </Add> <Updates Enabled="TRUE" Channel="Broad" /> <Display Level="Full" AcceptEULA="TRUE" /> <Logging Level="Standard" Path="C:\VMware_IT\Logs\Office365logs" /> </Configuration></Data> </Item> </Exec> Take that and paste it into the custom settings area of your AirWatch profile. Click save and publish. After a short time you should see the Office install window popup. I would highly recommend you make the display level "Full" so you can see whats happening as well as specific a log path so you can easily troubleshoot installation issue.
In this blog post, I will outline how to forcefully but elegantly upgrade remote systems to Windows 10 using SCCM task sequences. I will be using 3 task sequences working together to accomplish this. This process can also be used for clients on the LAN as well as for win10 feature upgrades. The main benefits of this process are as follows: - All content gets pre-downloaded silently in the background - Win10 assessment is run silently before hand and sends email based on pass/fail - If it passes, a reg key will be created with which an SCCM compliance rule can be queried. Systems with the reg key can get automatically placed into a "Win10 Ready" collection. - The real upgrade Task Sequence can be deployed manually or automatically to systems in the "Win10 Ready" collection - A nice window will popup on the real upgrade TS which allows users to defer the upgrade up to 5 times before it will run automatically - Model specific drivers are pre-downloaded as well Pre-Reqs - Clients must be on a reliable VPN connection in order for this to work well. We have an "always on VPN" that connects so remote clients are always on the VPN unless the user manually disconnects. - Because this is a lot of content going over your VPN, be mindful of the bandwidth impact. We use Adaptiva for content distribution and it takes care of all of the bandwidth management automatically for us so there is no load placed on our VPN gateways. - While you CAN include the MBR2GPT process to this, I would recommend against it. This is simply because if there are any issues you're gonna get a system that won't boot. Troubleshooting that remotely is a huge pain and a poor experience. Just flip them to UEFI once they visit a real office. Downloads ![]()
Intro
In my previous post I detailed how you could use an SQL query on the SCCM database to pre-register airwatch devices into the console. While this works, it has several drawbacks:
My script has the following features:
Requirements
Managing encryption on Windows 10 devices in the new mobile-cloud era should be simple and effortless. AirWatch 9.1 gives us a slew of features for advanced BitLocker management on your Windows 10 devices that makes it easy and flexible. I’ll highlight some of the new features introduced in 9.1 and then do a walk-through of how to set it up. (taken from official AirWatch post)
Now, let's get to creating your profile in the AirWatch console. First, login to your AirWatch admin console On the left hand pane, click on Devices --> Profiles & Resources --> Profiles --> Add --> Add Profile Then Windows--> Windows Desktop Then select Device Profile In the Profile screen fill out the first section -- "General" Name - Name it something appropriate, such as "Win10 - BitLocker" Description - Optional, but a good idea to type a bit of a description on what this profile is going to do. Deployment - "Managed" Assignment Type - "Auto" Allow Removal - Recommend you set this to "Never" Managed by - You should be able to leave this default, but be sure you are at the right org level here Assignment Groups - Add the appropriate group here. If you haven't created a Smart Group yet you can do so here. Just click in the box and select "Create Assignment Group" at the bottom. In my case I've created a smart group for all Windows 10 Clients Exclusions - You can add exclusions here if you want Additional Assignment Criteria - Leave default Removal Date - Recommend you don't enable this You can see mine here: Once you have configured your "General" page, click down to the "Encryption" section on the left. Then click "configure". Here there are numerous different options you can set. I'll walk through each one although many are self explanatory. Section 1 Encrypted Volume - Select "Complete Hard Disk" or "System Partition". System Partition means just the OS partition, so it won't encrypt any other disk or partitions. Recommend you set this to "Complete Hard Disk". Only Encrypt Used Space During Initial Encryption - This will speed up the initial encryption process and not hit the disk as long. Recommend you turn this on. Custom URL for Recovery Screen - This is where you put your unique URL that will direct users to go to on the blue BitLocker recovery screen. I recommend you set this to your organization's Airwatch self service portal. Section 2 - BitLocker Authentication Settings Authentication Mode - TPM or Password (aka PIN). TPM is definitely the way to go here. Enforce Encryption Pin on Login - Check this box if you want to add a PIN in addition to TPM. This is not really necessary in my opinion, but it does give you the option if your organization requires it. Use Password if TPM not Present - As mentioned in the beginning of the article, this really helps ensure that every system is encrypted even ones that don't have a TPM chip either because they didn't ship with one, it hasn't been properly enabled, or there are country specific laws preventing TPM chips altogether. Recommend you turn this on otherwise Bitlocker will fail if TPM isn't there and activated. Minimum Password length - Self explanatory. Minimum 8 characters. Section 3 - BitLocker Static Recovery Key Settings Create Static BitLocker Recovery Key - This is also a new feature with 9.1 where it will add a secondary admin recovery key that is synchronized across your devices for easier recovery. This still keeps the unique key that is set, but it just adds a second one. You can also set the rotation period and grace period here too. Section 4 - BitLocker Suspend Enable BitLocker Suspend - If you check this box, it will automatically suspend BitLocker during scheduled maintenance or patching periods so that the system won't automatically go into recovery mode such as updating the BIOS. Most of the time, this would probably be used on Kiosk or desktop systems where you have very predictable maintenance periods and where there is a risk of BitLocker going into recovery mode. Recommend you leave this off unless you have a specific use case. You can always turn on for a time, and then turn off once you are done updating your systems. Once you are complete and ready to deploy click "Save & Publish". The next screen will show you all the devices it will go to based on your Smart Group. If it looks good, click "Publish" to send out to your devices. Once you have deployed this out to your devices, obtaining the recovery key is very easy. Simply search for and find the device either by user or device name.
On the summary page, click on "View Recovery Key". That's it! |
Follow Me
AuthorI'm Brooks Peppin and I love God, my family, AirWatch, VMware, EUC products, all things systems management, Windows 10, Powershell, and operating system deployment. Archives
March 2018
Categories
All
|