Category: Windows 10

Intune MDM Azure Portal Explained

Intune MDM Azure Portal Explained

MS Intune

Managing Windows 10 with Intune MDM

I am hoping this helps with the understanding of Intune (Azure Portal) and MDM.

 

There are 3 types of configurations for devices when connected to Intune (Azure Portal):

Intro:

Azure AD Registered devices: this allows a device to come into the realm of MDM. This is focused on BYOD. End users can bring their devices and Register them with Azure where they can be managed by adding a work/school account. Admins can push out policies. But nevertheless the end user can remove themselves from the MDM management, because this is their personal device.

Types of Azure AD Domain Joins:

Azure AD joined devices: this allows a device to join a Azure AD domain. Targeted for workplace devices that do not have an on-premise AD infrastructure or a cloud first/only approach. Benefits include:

  • Single-Sign-On (SSO) to your Azure managed SaaS apps and services. Your users don’t see additional authentication prompts when accessing work resources. The SSO functionality is even when they are not connected to the domain network available.
  • Enterprise compliant roaming of user settings across joined devices. Users don’t need to connect a Microsoft account (for example, Hotmail) to see settings across devices.
  • Access to Windows Store for Business using AD account. Your users can choose from an inventory of applications pre-selected by the organization.
  • Windows Hello support for secure and convenient access to work resources.
  • Restriction of access to apps from only devices that meet compliance policy.

 

Hybrid Azure AD Joined devices: this is for organisation who also have a on-premise footprint as well as cloud. Devices are joined to a local AD. These organisation would require the need for group policies or imaging devices or NTLM/Kerberos hence why they are not fully in Azure.

Rule of thumb:

A rule of a thumb, you should use:

  • Azure AD registered devices:
    • For personal devices
    • To manually register devices with Azure AD
  • Azure AD joined devices:
    • For devices that are owned by your organization
    • For devices that are not joined to an on-premises AD
    • To manually register devices with Azure AD
    • To change the local state of a device
  • Hybrid Azure AD joined devices for devices that are joined to an on-premises AD
    • For devices that are owned by your organization
    • For devices that are joined to an on-premises AD
    • To automatically register devices with Azure AD
    • To change the local state of a device

 

So what does this mean:

Well in a nutshell, you don’t need to use the old classic Intune portal!!! We can configure a on-premise domain joined machine to be managed by Azure Intune MDM (agentless MDM). The trouble you will find is that there is no clear documentation on how to configure this. My next post will discuss how to configure local AD domain joined device to be managed via Intune MDM using the Hybrid Azure AD Domain Join option.

DISM Injecting Windows 10 1709 Updates into a WIM Image

DISM Injecting Windows 10 1709 Updates into a WIM Image

Image File

Injecting Windows 10 1709 Updates into a WIM

 

The following guide outlines how to inject Windows Updates into a WIM file using DISM. This process can help ensure newly built machines are patched before being handed out to end users. In addition this can also speed up the process of building Windows 10 1709 as the Windows Update process during your task sequence will be relatively shortened.

  • Create a WIM file directory
Md C:\wim
  • Copy your original WIM to c:\wim
  • Create a Mount directory
md C:\mount
  • Create a temp directory
md C:\temp
  •     Create a update directory
md C:\msu
  • Find what index the Windows 10 Enterprise SKU is within the WIM File:
Dism /Get-ImageInfo /imagefile:C:\wim\install.wim
WIM index
WIM index
  • Mount the WIM file using the required Index number, I am using Index 3 Windows 10 Enterprise:
Dism /Mount-Image /ImageFile:"C:\wim\install.wim" /Index:3 /MountDir:C:\mount
Mount Windows 10 Image
Mount Windows 10 Image

You will notice the mount directory has all the extracted windows files/folders

  • Download the latest Windows 10 update package from Microsoft’s website and place it in the update folder C:\msu. I will be downloading the 4088776 update https://support.microsoft.com/en-us/help/4043454
  • Run the below code to inject your update

 

Dism /Add-Package /Image:C:\mount /PackagePath:C:\MSU\windows10.0-kb4088776-x64_55756340f1e2c2090f94de6d256eafd75e1cee9c.msu /LogPath:AddPackage.log

Inject Update into WIM File
Inject Update into WIM File
  • Lock in the Updates so they are restored during a recovery:
DISM /Cleanup-Image /Image:"C:\mount" /StartComponentCleanup /ResetBase /ScratchDir:C:\Temp
Lock Injected Updates into WIM File
Lock Injected Updates into WIM File
  • Unmount the image and commit the changes:
Dism /Unmount-Image /MountDir:"C:\mount" /Commit
Unmount WIM Image
Unmount WIM Image
  • Now upload your WIM to SCCM or MDT, deploy and test.
Always On VPN Device Tunnel with Windows 10 1709

Always On VPN Device Tunnel with Windows 10 1709

Always On VPN Device Tunnel with Windows 10 1709

Update 22/11/2017: Microsoft’s official guidance on Device Tunnel configuration is now available at https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config

A long awaited feature with the DirectAccess successor Always On VPN (Auto VPN) is the ability for clients to initiate an infrastructure tunnel to the corporate network without the user logging on. This feature named Device Pre-Logon is available in Windows 10 1709 update.

Over the last several years Microsoft’s VPN or remote connectivity solution has primarily been DirectAccess. Whilst DirectAccess provided seamless always on remote connectivity, it did however come with a few drawbacks. Originally released with Server 2008 it only supported IPv6 and utilised UAG. With Server 2012, 2012R2 Microsoft removed the need to utilise UAG and streamlined the installation and configuration. Still available in Server 2016 DirectAccess is not a technology that is obsolete but far from it with many organisation using it to provide users with remote connectivity. Once configured DIrectAccess…just works. For at least the short term DirectAccess is proven to be reliable and the remote connectivity solution of choice, as long as you can overcome single stack IPv6,  but if you want the latest and greatest then Always On VPN is the future.

However DirectAccess is a dark art and the solution can be difficult to install and configure to the novice professional. Always On VPN on the other hand has all the missing features and more that DirectAccess should have had. This not to to be taken lightly, as Always On VPN is also not a walk in the park to implement, away with the GUI, Always On VPN utilises configuration service provider (CSP’s) in order for implementation.

Always On VPN is the new kid on the block, released in Windows 10, the major benefit of a Device Pre-Logon tunnel has been released with 1709 Creators Update for Windows 10. This allows administrators to always have the ability to manage Windows 10 devices once they leave the corporate environment. When a device is connected to a known network, it will automatically initiate a VPN connection back to corporate environment where it can be managed. For example this can group policies, windows update or even configmgr.

The official statement from Microsoft is to deploy Always On VPN instead of DirectAccess, but many organisations would be very reluctant to deploy a solution which has just arrived on the market. The below outlines the benefits and drawbacks of DirectAccess:

DirectAccess

Benefits:

  1. Always On
  2. Seamless
  3. Infrastructure Tunnel for device management in addition to the User Tunnel
  4. Built into Windows 10 no additional clients needed
  5. Uses IPHTTPS tunneling protocol
  6. GUI for easy configuration
  7. Still supported and available in Server 2016

Drawbacks

  1. IPv6 only solution. Applications installed on the client must support IPv6, certain exception are made for example Office Communication Server 2007 does not work with DirectAccess
  2. No granular control
  3. Manage-Out not supported when more than 1 DirectAccess server is present in a configuration ( although it is possible to get Manage-Out working with multiple servers using a solution by Richard Hick’s)
  4. Limited access to End to End encryption to application servers
  5. No support for VPN gateways
  6. NAT64, DNS64 componets are utilised to transverse IPv6 to IPv4
  7. Teredo and 6to4 are not supported behind a NAT/Firewall
  8. Only Windows Domain joined devices are supported
  9. Network Access Protection deprecated in 2012R2

 

Always On VPN

Benefits:

  1. Uses industry standard IKEv2 tunneling protocol with the ability to fall back to SSTP when behind firewalls or proxy’s
  2. Dual stack support for IPv4 and IPv6
  3. Granular control for End to End encryption to application servers using policies
  4. Granular control over routing, specifically control routing behavior to define which traffic should only ever traverse the VPN and not go over the physical network interface
  5. Name based triggering allow specific domain name queries to trigger the VPN
  6. Application Triggering, when specified desktop and/or universal windows apps are, the VPN will automatically trigger
  7. Supports VPN gateways behind a NAT or edge device in addition Remote Access servers can be used
  8. No requirement for Active Directory or Windows domain joined devices, nor a requirement on an Enterprise version of Windows 10
  9. Application specific routing is supported (Managed tunnel)
  10. No requirement for Network Location Servers in order to determine if a client is within the corporate boundary or outside. Trusted Network Assessment is ustilised which assesses  the connection-specific DNS suffix assigned to network interfaces
  11. Ability to integrate with Azure Conditional Access Platform to enforce Device Compliance and/or multi-factor authentication
    1. Multi-factor authentication includes the ability to use Windows Hello for Business Certificate
  12. Support of RSA and ECC to meet specific cryptography requirements such as those set by the National Cyber Security Centre in the United Kingdom or other government/corporate organisations.

Drawbacks

  1. Can be difficult to configure using PowerShell, Intune, ConfigMgr or Windows Configuration Designer have to be used to configure Always On VPN
  2. Remediation’s or quarantining is not supported using Azure Conditional Access Platform
  3. New kid on the block and may require maturing, potential to have unknown bugs

 

DirectAccess and Null Cipher Suites

DirectAccess and Null Cipher Suites

Are Null Cipher Suites Safe to Use

ssllabsYou may at some-point you may be questioned about the security protocols used by DirectAccess. If you have a pen test performed they may flag the following two cipher suites:

  1. TLS_WITH_RSA_NULL_SHA256
  2. TLS_EITH_RSA_NULL_SHA

Within a typical solution Null ciphers would be disabled, however DirectAccess is special in the way it works. NULL cipher suites are enabled by deafult. DirectAccess is an IPv6 only solution. In order to transport IPv6 data over the public IPv4 internet the traffic must be encapsulated within an IPv6 tunnelling technology. Now there are 3 technologies that can be used:

  1. IPHTTPS (preferred when using Windows 8 onwards)
  2. Teredo
  3. 6to4

DirectAccess servers must be domain joined in order to function. Teredo and 6to4 tunnelling protocols require that the servers/clients be publicly accessible without a firewall placed in front. This of course is dependant on an organisations risk appetite, where possible security will dictate that the servers be placed behind a firewall. In addition the National Cyber Security Centre (NCSC) provide Commercial Product Assurance scripts in order to harden the DirectAccess cryptography which cannot be applied to 6to4. The IPHTTPS tunnelling protocol allows the servers and clients to be placed behind a firewall and uses 443 which is commonly opened on the majority of routers whether corporate or private and is therefore is the more preferred IPv6 tunnelling method. Moreover IPHTTPS tunnelling aligns with the NCSC wall gardened approach with firewalls placed in front and behind the DirectAccess servers.

Previously Teredo was considered the preferred tunnelling protocol to use for DirectAccess as IPHTTPS resulted in the traffic being double encrypted, as Windows 7 did not support Null Cipher suites. This increased the overhead processing on the DirectAccess servers and resulted in poor performance for users. With the introduction of Windows 8 onwards. Microsoft enabled support for Null Cipher suites removing the need for double encryption with IPHTTPS. Thus IPHTTPS is now considered the preferred tunnelling protocol. IPHTTPS should only be viewed as a transport mechanism for IPv6 data over the public IPv4 internet. The data within the IPHTTPS is still IPsec encrypted.

DirectAccess Tunnels

DirectAccess clients initiate two tunnels. These tunnels are broken down into:

  1. Infrastructure Tunnel – The client device (Windows 10 for example) will know when it is outside the corporate network and as long as it has an internet connection it will initiate a connection back into the corporate network. This allows the device to be managed without the user initiating the connection. The computer certificate and NTLMv2 are used for authentication.
  2. Intranet Tunnel – Once the user logs onto the client device, the user tunnel in then created. The computer certificate and Kerberos are used for authentication.

These tunnels are encrypted with IPsec using the computer certificate in order to provide a secure and encrypted communication channel between the DirectAccess Servers and Clients.

An IPHTTPS tunnel is the outer tunnel for the transportation of IPv6 over the IPv4 internet. The inner tunnel consists of the IPsec tunnels of the encrypted IPv6 data.

In regards to SSL 3.0, RC4 ciphers, a hacker would not be able to access the DirectAccess traffic as the data is still IPsec encrypted. But these can be disabled on the DirectAccess servers if requested. SSL 3.0 should be disabled on all systems.

Limit the Cipher Suites

In order to limit the Ciphers used by a system, you can use Nartac which provides a user friendly GUI in addition to the following features:

Nartac

  • Single click to secure your website using best practices
  • Create custom templates that can be saved and run on multiple servers
  • Stop DROWN, logjam, FREAK, POODLE and BEAST attacks
  • Disable weak protocols and ciphers such as SSL 2.0, 3.0 and MD5
  • Enable TLS 1.1 and 1.2
  • Enable forward secrecy
  • Reorder cipher suites
  • Built in Best Practices, PCI, PCI 3.1 and FIPS 140-2 templates
  • Site scanner to test your configuration
  • Command line version

 

Nartac provides some best practice templates, when using these templates ensure you check the below two Null cipher suites as they are deselected by default:

  • TLS_WITH_RSA_NULL_SHA256
  • TLS_EITH_RSA_NULL_SHA

Nartac can be downloaded here 

In addition my friend Richard Hicks has a great article on applying a scaled down version of Cipher Suites using Group Policy.

You can test what Ciphers are being presented using SSL Labs, You should see the below output once applied. Rememebr your rating for DirectAccess will be capped at F as we have Null Ciphers enabled.

ssllabs