By Fredrik Brattstig @virtualbrat
20 November 2024
What better to do mid-Microsoft Ignite than to announce and show how IGEL OS 12 upcoming Intune App will provide conditional access to Azure Virtual Desktop and Windows 365. Conditional access also works with Microsoft EDGE, already released in the IGEL App Portal.
The upcoming Intune agent was first announced at IGEL Disrupt in Miami spring -24 and has since then been hard working to integrate the app in IGEL OS. IGEL are now very close to release the app for general availability.
Of course, I have created a video of the user experience, let’s check it out first before we dig into the techie deep stuff:
Microsoft Intune together with Microsoft EDGE makes sure that any SaaS app can be protected to only be accessed by a IGEL OS endpoint that is owned. The same apply to IGEL Azure Virtual Desktop App. There are multiple things needed before this will be in a productive state, but all the pieces are falling in place as I write this. The components to fulfill the requirements and get the experience as shown in the video is:
- IGEL OS 12.5.1 or higher (GA released)
- IGEL Intune App (Soon to be GA released)
- IGEL AVD App 1.3.0 or higher, for AVD or Windows 365 workloads (Soon to be GA released)
- Optionally: for SaaS workloads, you will need Microsoft EDGE (GA released)
The endless compliance opportunities – tech area!
The tight integration between IGEL OS, Microsoft Intune, IGEL AVD App and Microsoft Authentication Library (MSAL) ensures control of your IGEL OS devices using the IGEL Universal Management Suite (UMS), while letting Microsoft Entra and Intune custom compliance scripts to validate that the IGEL OS device that are used to access is actually managed by your organization. Just look at this:
As an example, you can create a compliance script that checks the devices assigned UMS certificate has a certain sha256 fingerprint, here is how that can look:
#!/bin/sh
logger "Starting compliance discovery script"
logger " - Checking UMS fingerprint"
estcacertfile="/wfs/ca-certs/tls/ums_ca.pem"
ums_fingerprint_sha256=$(openssl x509 -in ${estcacertfile} -noout -fingerprint -sha256 | cut -d '=' -f2)
printf '{"ums_fingerprint_sha256":"%s"}\n' "$ums_fingerprint_sha256"
logger "Ending compliance script"What the above script does when being executed on the device by Microsoft Intune, is to set a variable estcacertfile pointing at the UMS Certificate, then it creates a new variable, ums_fingerprint_sha256 that will have the value of the openssl command result when checking the sha265 fingerprint of the certificate
And this is how the Compliance policy – Compliance setting in Intune admin portal looks:
{
"Rules":[
{
"SettingName":"ums_fingerprint_sha256",
"Operator":"IsEquals",
"DataType":"String",
"Operand":"80:20:EF:F6:61:DA:7E:54:23:FE:FF:74:CC:41:66:47:62:6E:E3:4C:36:14:17:4A:1B:17:81:AF:6D:81:BF:20",
"MoreInfoUrl":"https://www.igel.com",
"RemediationStrings":[
{
"Language": "en_US",
"Title": "Enrolled to a wrong UMS",
"Description": "Please ensure that your IGEL OS is managed by the correct UMS."
},
{
"Language": "de_DE",
"Title": "Von einer falschen UMS verwaltet",
"Description": "Bitte stellen Sie sicher, dass Ihr IGEL-Betriebssystem von der richtigen UMS verwaltet wird."
}
]
}
]
}
The script that rus on IGEL OS, will report back ums_fingerprint_sha256 which is the result of the script, and Intune will then validate that ums_fingerprint_sha256 matches the sha256 fingerprint of the actual known certificate: -80:20:EF:F6:61:DA:7E:54:23:FE:FF:74:CC:41:66:47:62:6E:E3:4C:36:14:17:4A:1B:17:81:AF:6D:81:BF:20
This means that we know that:
1. Device has to be enrolled in the company Intune (A trusted user needs to enroll the device)
2. The device has to be managed by the company UMS (We determine that it is not a random Intune enrolled device, it is a device that is managed by the company UMS)
So, what can we do more with compliance scripts? As you probably understand now, is that the command we run on IGEL OS to get the sha256 fingerprint, is a local binary openssl. We can take results of any command, or multiple commands, for instance we can use the IGEL OS get command to read out ANY configuration of the IGEL OS device, as an example get sessions.xlock0.options.autolock would result in true if use of the IGEL OS screensaver is activated. We can check for system variables and can check if certain processes are running with pgrep, or not etc. Endless possibilities on what to look for to define as a compliant IGEL OS endpoint!
The compliance policy scripts extend the very limited built in compliance evaluations with Microsoft Intune for Linux.
That’s it for today, hope you liked this blog! If so, please re-share or like my Linked-In post HERE! A big thank you in advance!
/Fred
VirtualBrat 