In this post we will do some digging on Win32 app state messages and look at the compliance state and enforcement state messages stored in the local registry for win32 app policies processed by the client. We will also take the state values and convert them into a readable format to help you understand if a Win32 app was processed successfully

Where are Win32 app policy results stored on the client?

Great question. When the Intune Management Extension (IME) processes the policy for Win32 apps targeted to the logged on user or device, it stores the policy evaluation results in the local registry under the key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps

The sub key 00000000-0000-0000-0000-000000000000 includes policy targeted to the device. Any sub key that is a GUID (highlighted in green below) includes policy targeted to the user. The GUID is the Object ID of the user in Entra ID

Under each user(and device) sub key are other keys for the applications targeted. The name of the key will be the appid of the Win32 app in Intune

Compliance State Messages

If the policy has been evaluated by the IME, the results of the policy evaluation is stored, in JSON format, in the ComplianceStateMessage sub key as seen below

Enforcement State Messages

If the policy has been processed by the IME, the results of the policy enforcement is stored, in JSON format, in the EnforcementStateMessage sub key as seen below

Understanding State Messages

My friend @jankeskanke first brought these JSON results to my attention. Cool hey? We can use PowerShell to pull that data out to be viewed in a more friendly view. Fire up vscode!

$ComplianceState = Get-ItemProperty -Path 'HKLM:SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\ddc3cf6e-3b3b-461c-a823-53196902d067\e316127d-a9a4-4193-8f04-b07c37d1130f_1\ComplianceStateMessage' -Name 'ComplianceStateMessage' | Select-Object -ExpandProperty ComplianceStateMessage
$ComplianceState | ConvertFrom-Json

Great, but what do those status codes mean?

You can use your favorite .NET decompiler to view the source code of the IME, cool right! I am using DotPeek by JetBrains in the example below

We can see that a ComplianceState of 2 means this app is NotInstalled

Doing the same with Applicability, we can see that Applicability of 0 means this app is Applicable

Great, but this might get slightly tedious when trying to interpret all the state message values in the JSON in the registry when troubleshooting apps on the client. Before we do some magic, let’s list out the state messages and their values for reference in the next chapter

The Microsoft source code lists the message and the corresponding value and error code. I want to put these pairs into a hash table (for the purpose of magic) so I’ll list them as you would see them in a hash table. Chat GPT was awesome converting these btw!

Applicability

$stateMessageApplicability = @{
    0    = "Applicable"
    1    = "RequirementsNotMet"
    3    = "HostPlatformNotApplicable"
    1000 = "ProcessorArchitectureNotApplicable"
    1001 = "MinimumDiskSpaceNotMet"
    1002 = "MinimumOSVersionNotMet"
    1003 = "MinimumPhysicalMemoryNotMet"
    1004 = "MinimumLogicalProcessorCountNotMet"
    1005 = "MinimumCPUSpeedNotMet"
    1006 = "FileSystemRequirementRuleNotMet"
    1007 = "RegistryRequirementRuleNotMet"
    1008 = "ScriptRequirementRuleNotMet"
    1009 = "NotTargetedAndSupersedingAppsNotApplicable"
    1010 = "AssignmentFiltersCriteriaNotMet"
    1011 = "AppUnsupportedDueToUnknownReason"
    1012 = "UserContextAppNotSupportedDuringDeviceOnlyCheckin"
    2000 = "COSUMinimumApiLevelNotMet"
    2001 = "COSUManagementMode"
    2002 = "COSUUnsupported"
    2003 = "COSUAppIncompatible"
}

ComplianceState

$stateMessageComplianceState = @{
    1   = "Installed"
    2   = "NotInstalled"
    4   = "Error"
    5   = "Unknown"
    100 = "Cleanup"
}

DesiredState

$stateMessageDesiredState = @{
    0 = "None"
    1 = "Not Present"
    2 = "Present"
    3 = "Unknown"
    4 = "Available"
}

TargetingMethod

$stateMessageTargetingMethod = @{
    0 = "EgatTargetedApplication"
    1 = "DependencyOfEgatTargetedApplication"
}

InstallContext

$stateMessageInstallContext = @{
    1 = "User"
    2 = "System"
}

TargetType

$stateMessageTargetType = @{
    0 = "None"
    1 = "User"
    2 = "Device"
    3 = "Both Device and User"
}

EnforcementState

$stateMessageEnforcementState = @{
    1000 = "Success"
    1003 = "SuccessFastNotify"
    1004 = "SuccessButDependencyFailedToInstall"
    1005 = "SuccessButDependencyWithRequirementsNotMet"
    1006 = "SuccessButDependencyPendingReboot"
    1007 = "SuccessButDependencyWithAutoInstallOff"
    1008 = "SuccessButIOSAppStoreUpdateFailedToInstall"
    1009 = "SuccessVPPAppHasUpdateAvailable"
    1010 = "SuccessButUserRejectedUpdate"
    1011 = "SuccessUninstallPendingReboot"
    1012 = "SuccessSupersededAppUninstallFailed"
    1013 = "SuccessSupersededAppUninstallPendingReboot"
    1014 = "SuccessSupersedingAppsDetected"
    1015 = "SuccessSupersededAppsDetected"
    1016 = "SuccessAppRemovedBySupersedence"
    1017 = "SuccessButDependencyBlockedByManagedInstallerPolicy"
    1018 = "SuccessUninstallingSupersededApps"
    2000 = "InProgress"
    2007 = "InProgressDependencyInstalling"
    2008 = "InProgressPendingReboot"
    2009 = "InProgressDownloadCompleted"
    2010 = "InProgressPendingUninstallOfSupersededApps"
    2011 = "InProgressUninstallPendingReboot"
    2012 = "InProgressPendingManagedInstaller"
    3000 = "RequirementsNotMet"
    4000 = "Unknown"
    5000 = "Error"
    5003 = "ErrorDownloadingContent"
    5006 = "ErrorConflictsPreventInstallation"
    5015 = "ErrorManagedInstallerAppLockerPolicyNotApplied"
    5999 = "ErrorWithImmeadiateRetry"
    6000 = "NotAttempted"
    6001 = "NotAttemptedDependencyWithFailure"
    6002 = "NotAttemptedPendingReboot"
    6003 = "NotAttemptedDependencyWithRequirementsNotMet"
    6004 = "NotAttemptedAutoInstallOff"
    6005 = "NotAttemptedDependencyWithAutoInstallOff"
    6006 = "NotAttemptedWithManagedAppNoLongerPresent"
    6007 = "NotAttemptedBecauseUserRejectedInstall"
    6008 = "NotAttemptedBecauseUserIsNotLoggedIntoAppStore"
    6009 = "NotAttemptedSupersededAppUninstallFailed"
    6010 = "NotAttemptedSupersededAppUninstallPendingReboot"
    6011 = "NotAttemptedUntargetedSupersedingAppsDetected"
    6012 = "NotAttemptedDependencyBlockedByManagedInstallerPolicy"
    6013 = "NotAttemptedUnsupportedOrIndeterminateSupersededApp"
}

PowerShell – Diving Deeper

I thought it would be cool if we can collect all the state messages, for all the Win32 apps processed by the client AND translate the state message values into “plain English”. This would make troubleshooting so much easier

Get-Win32AppResults.ps1

Head over to my GitHub Repo and grab the script

MEM/Get-Win32AppResults.ps1 at main · byteben/MEM (github.com)

By default, the script will iterate through all the Win32 app policy results and display the translated state codes in an array. Let’s take a look at a dummy run

Digging in to the last result, we can make the translation easier to understand

$stateMessages | Where-Object { $_.AppID -eq 'fe38a779-a875-4c0f-a9ff-46ded4e79753' } | Select-Object -ExpandProperty ComplianceStateMessage

Practical Usage for the Service Desk

Here are some common examples on how to use the script

Find Apps that are applicable, required, but not installed

$stateMessages | where-Object {$_.complianceStateMessage.Applicability -eq 'Applicable' -and $_.complianceStateMessage.ComplianceState -eq 'NotInstalled' -and $_.complianceStateMessage.DesiredState -eq 'Present'}

Find apps that are required but have an Enforcement Error Code

$stateMessages | where-Object {$_.complianceStateMessage.DesiredState -eq 'Present' -and $_.enforcementStateMessage.Errorcode}

Summary

In this post we covered state message briefly and discussed how difficult they are to read when troubleshooting a users device. We also used a script to iterate through the state messages and return the results in an easy to read way.

In the next version of the script, we will convert the appid’s into the respective app name in Intune and pass more switches for common scenarios. We will also look at building a workbook in Log Analytics so you can make comparisons between “data from the client” and “data in Intune”. Finally, we will iterate through the GRS schedule to understand when the failed apps are next scheduled for evaluation.

(0)

The post Win32 app State Messages Demystified appeared first on MSEndpointMgr.

For those of you not already aware, there is a nice reporting feature hidden away within the Microsoft 365 Apps admin center which provides reports on the health of your client OneDrive sync agents. Using this report, you can also identify issues with processes such as known folder move, something that is vital to determine if your OneDrive migration is going as planned.

I have been using this reporting feature with clients for quite some time now, and until very recently everything appeared to be working as normal, until it wasn’t. Logging into the portal to check device health with a client, resulted in the below information;

This of course took me somewhat by surprise, and this blog post covers the change that is required within your client configuration, along with the reporting feature itself for those not already using or aware of it.

Prerequisite Configuration

In order to enable this feature there are two components, the backend configuration, and the configuration going down to your devices. Logging onto the Microsoft 365 Apps admin center (https://config.office.com), you will see a sign in button, which for the most part has been overlooked in favour of the “Create a new configuration” button used to generate Microsoft 365 App configuration for deployment;

Signing into this site with an account with sufficient role membership rights (global admin / office apps admin – Overview of the Microsoft 365 Apps admin center – Deploy Office | Microsoft Learn), we can configure something called a “Tenant Association Key”. The first time you click on the setup page, it will generate this key, and you will have a page similar to the one below;

After a “cloud minute” and a refresh of the page, you will end up with a tenant association key, something that if you have already enabled the reporting feature, you should be familiar with;

With the backend enablement done, it is only a matter of pushing OneDrive configuration to your clients to enable reporting, and within 24-72 hours you should have very useful data.

Client Configuration.. and Important Changes

At this point the blog post title will start to make sense. To enable the client devices to report in their health information, you had to deploy OneDrive configuration to your clients containing the Tenant Association Key.

Previously if you had enabled this feature, you would have configured your OneDrive client settings similar to the configuration below;

This is a similar process to how Windows Update reports required commercial ID key configuration to be pushed to your client, and just like that, this is something which has now changed.

Looking at the Microsoft documentation on OneDrive Sync Reports (OneDrive sync reports in the Apps Admin Center – SharePoint in Microsoft 365 | Microsoft Learn) there is a section highlighted, as below;

Given that the documentation was updated on April 10th 2023, this would then result in the setting being deprecated on July 3rd. This is something that caught me out, as unless you were looking at the docs, the message could go unnoticed.

In the Microsoft documentation it advises you to set the configuration through a Group Policy Object (something I have a pull request in for to rectify), but essentially if you are working in a “modern” way, you would more than likely be deploying the setting through an Intune profile.

The below section deals with fixing this issue.

Behold – The New Setting

Going back to our Intune OneDrive profile and editing it (I assume you are using the settings catalog for this.. If not, please do), we can dig in and find the new setting;

• Edit your OneDrive settings catalog profile
• Click on “Add setting” to open the settings picker;

• Scroll down until you see the following setting;

• Add the setting to your profile, and then scroll down and remove the following setting;

• Closing the settings picker, now flick the toggle switch on the new setting to enabled;

Viola.. Reporting is ALIVE

Once that setting has been consumed by your clients, within 24 hours you should start to see clients reporting back in, and finally you have useful OneDrive sync agent reports.

The report is accessible by;

• Logging onto the Microsoft 365 Apps admin center (with sufficient role rights)
• Clicking “Health”
• Clicking “OneDrive Sync”

At this point you would have a screen similar to the one below;

Drilling into the devices section we can also see information such as the OneDrive sync agent version, which folders have been moved (Known Folder Move), along with the last sync / status time from those agents;

Conclusion

The OneDrive health reports are something that every admin should enable, as it provides great oversight into what is actually happening on your clients. Hopefully those of you who previously enabled this will find the post useful to update your configuration, as a blank report, is not a good report.

Thanks for reading!

(5)

The post The curious case of the missing OneDrive sync app health reports appeared first on MSEndpointMgr.

The long waited for Endpoint Privilege Management is finally in public preview! This post is about my first look at this feature, so not a deep dive post. If you need more details on EPM, please read more from the official doc Learn about using Endpoint Privilege Management with Microsoft Intune | Microsoft Learn

I was curious about the feature, how to configure all the settings in Intune, and how it looks and works on users’ devices. But before we go into details, let’s talk about what is Endpoint Privilege Management, short for EPM.

I remember attending one of the security talks presented by the famous security expert Laiho Sami , he said “Remove all admin rights from your device!“ I totally agreed he is 200% correct, we shouldn’t have admin rights in our devices, it’s a security risk. I believe many organizations understand the risk, but again why are we still giving admin rights? Hm…Because “Our developers need to install many applications”, “Some old and bad applications only work when running as elevated admin rights”, and “We don’t have enough IT to handle this kind of request”… Anyway, we know we always have some reasons, good or bad.

For a very long time, we wish we can have a “Just in time” method to allow standard users to install or run approved applications with elevated access without giving user administrator privileges. Finally dreams come true! This is Endpoint Privilege Management (EPM)!

Let’s watch this short video. I tried to run powershell.exe as administrator, and my standard user account got UAC prompt as expected. Then I run powershell.exe with EPM elevated access, and I was allowed to run powershell.exe with elevated access. I am NOT saying should let standard users run PowerShell as admin, I just want to test it as an example, because it is kind of cool

EPM supports Azure AD joined devices and Hybrid Azure AD joined devices. I have tested both scenarios with Windows 11 22H2 March pathed virtual machines.

Okay, let’s go to the configuration. Just a note, this is still in preview at the moment, if you read this post later and see some icons or UI aren’t the same as this post, those are expected changes. At this moment, there are three tabs in the EPM blade:

• Report – There are two built-in reports. Elevation report and Managed elevation report. But these two reports are not ready yet when I was doing my test, I saw no data, maybe I have to wait a little longer.
• Policies – There are two policies. Elevation settings policy and Elevation rules policy. I will break down the details.
• Reusable settings (preview) – This allows you to import the application’s certificate, and reuse the certificate in elevation rule policies.

Elevation settings policy

This is where I started in my first step. The elevation settings policy contains three settings:

• Enable Endpoint Privilege Management. You need to set this to “Enable” for enabling EPM
• Default elevation response. This default response applies to all applications (EXE files), when users right-click on an EXE file, and choose Run with elevated access. There are three options:
  • Deny all requests. This will automatically deny all elevated access request
  • Require user confirmation. You can select validation methods “Business justification” and/or “Windows Authentication”.
    “Business justification” is where users can input information about why they need to run this app.
    “Windows Authentication” will require users to use Ctrl+Alt+Del and then input their password again to authenticate.
• Sent data to Microsoft. Choose if you want to send diagnostic data and/or elevation data to Microsoft. Diagnostic data will be sent to Microsoft. Elevation data is for reporting purposes, elevation data is s staying in your Intune tenant. See details in the official doc Review the data that Endpoint Privilege Management collects when used with Microsoft Intune | Microsoft Learn

After my test devices have applied the Elevation settings policy, I waited about 30 minutes, and I saw the EPM Agent is installed. Two folders are interesting to me. One is the EpmTools, there are instructions on how to use PowerShell commands to get more information on the EPM client in the device. Another one is the Logs folder. There are so many logs, I have look into them yet.

Elevation rules policy

You don’t have to use the elevation rule policy if you don’t need to specify different rules for individual applications. But if for example, you use the Elevation setting policy to deny all elevation responses, and want to allow just some applications to run on some devices, in this case, you will need to create an Elevation rules policy.

There are two key matters in the Elevation rule policy:

• Elevation conditions. This allows us to configure elevation type, automatically approve users’ requests, or require user confirmation with “Business justification” and/or “Windows Authentication”
• File information. This is where we can configure individual EXE file information using file hash or certificate. File hash or certificate are required information.

For getting file hash, I use this PowerShell command

Get-FileHash "your exe file path here" | select-object Hash

For exporting the file certificate:

Get-AuthenticodeSignature "your exe file path here" | Select-Object -ExpandProperty SignerCertificate | Export-Certificate -Type CERT -FilePath "c:\temp\YourExeFileCert.cer"

Reusable settings (preview)

As the name of the setting, it’s reusable. In this setting, you can import the EXE file certificate, and reuse this setting in the Elevation rule policy. For example, I have exported the powershell.exe certificate and added it to the Reusable settings

In my Elevation rule policy, I don’t have to upload a new certificate, I can choose to use a certificate file in reusable settings. Then I can choose if I want to use certificate type with Publisher or Certificate authority. The result of this configuration is in the above video.

During my test, Certificate authority didn’t work, so I changed to Publisher.
Update: After this post is published, thanks to Anton Varshavskiy and Chew Hung Pong from Microsoft reaching out to me. Apparently, I was using the “Issuing CA” (intermediate CA), and this is a known issue mentioned already in Microsoft Documentation, which will be fixed in the coming build. More details in Deployment considerations for Endpoint Privilege Management | Microsoft Learn

NOTE: If using the “Root CA“, it should work with the Certificate authority, but it doesn’t mean you should use “Root CA”, because root CA has too wide scope for many applications, you properly don’t want to do that. Ok, please don’t do that.

Results

As in my examples, I have configured rules for 7-Zip and PowerShell. Here are some screenshots of what it looks like.

Final thoughts

In some of the Microsoft demo videos, I saw it should allow users to send requests, and admins can approve the request inside Intune portal, looking forward to this functionality coming in the summertime. Because making rules per EXE file is not as convenient to “approve only once, as the real just-in-time”.

Currently, EPM only supports EXE files, not MSI files. Microsoft Intune team said it will support MSI files in the coming future.

The “Run with elevation access” is under the “classic menu”, so had to click on “Show more options”, which is a bummer. But the Microsoft Intune team is actively working on this to make it available in the modern context menu.

Anyway, the first test of Endpoint Privilege Management is satisfying and promising, I am very happy after trying out this feature. So give it a try, and I believe you will like it. In the meanwhile, I am looking forward to seeing what the reporting looks like.

(4089)

The post Intune Suite – Endpoint Privilege Management (EPM) first look appeared first on MSEndpointMgr.

In this blog post I will be showing you how to get started with certificate based authentication for Azure applications.

The story so far

The world has gone cloud crazy. But this is a good thing! Thinking back to my old admin days, any script I wrote would be deployed using GPO’s, Scheduled Tasks, RMM tools, ConfigMgr, Login Scripts and more. As we now focus our automation efforts on cloud services, the good old days of “dropping a script somewhere and running it” are coming to an end. Whether you are running scripts interactively to get data from Graph API or using Azure Functions to automate that task for you – you would have to authenticate at some point to prove you have the permissions to make that API call.

Thinking back to the old days, I would typically authenticate myself against Active Directory to prove I had the necessary permissions to perform a task. In the modern world, its a similar model and I now authenticate against Azure Active Directory to obtain the token I need to perform a particular function or call to the Graph API.

App Registrations

When I think about automation, I instinctively get drawn to Microsoft Graph. The API’s are rich and expose a wealth of information about my Microsoft Services. I can jump over to Graph Explorer aka.ms/ge and this is a great tool to familiarize yourself with queries to the Microsoft Graph but at some point you are going to want to use other programming logic to build your query that will get posted to the Microsoft Graph. To make calls to the Graph we need need to have an access token and to get that access token we need to authenticate to Azure Active Directory.

Now, typically you are going to use an Azure App Registration (a service principal) to get the token. The service principal is granted the necessary permissions it requires for your automation to do its thing. These permissions are explicitly granted on the service principal (see below) For example, if I wanted to read and write Win32apps in Intune, my app registration must be granted permission DeviceManagementApps.ReadWriteAll

Client Secrets

You will see A LOT of blogs and automation examples on the internet where the admin will use a very easy method to authenticate the Service Principal. A basic password – otherwise known as a Client Secret. Client secrets are quick and easy to use but they come at a price.

If we look at the Certificates and secrets blade on the app registration, you will see there are 3 ways to authenticate.

• Certificates
• Application Secrets
• Federated Credentials

The client secret is a short/long lived password. When we authenticate to the Microsoft Graph with our service principal, we need to present 3 pieces of information.

• Tenant ID (which tenant are we authenticating against)
• Application ID (same concept as a username)
• Client Secret (same concept as a password)

We don’t have the option of creating a secret that lasts forever, but a secret can be configured to be valid for up to 2 years

Would you let your users create a password that was valid for 2 years? Yuk – no way.

Once you create a client secret, it is only visible in the portal temporarily. When you navigate away from the blade the client secret is obfuscated

Authenticating with a client secret is considered basic authentication. Anyone with the Tenant Name/ID, Application ID and Client Secret can authenticate with the service principal in your tenant. Yeah its probably OK for testing with the minimum value of a client secret set to 90 days but will you go in and clear down your client secrets after performing your tests? The likelihood is no.

Where do I see Client secrets used badly? Hard coded in PowerShell scripts Please, for the sake of all things great and small, do not do this! If you insist on using Client Secrets, at least store them in a key vault but never hard code them in your scripts.

Jan wrote a really good article on using Client Secrets in conjunction with Azure Key vault at Securing Intune Enhanced Inventory with Azure Function – MSEndpointMgr

The IntuneManagementExtension.log will display the script body of a script pushed from Intune. If you hard coded a client secret in your script it will be visible to anyone who opens that log file.

You could mitigate some malicious abuse of your app registration if these credentials are leaked, perhaps by using Conditional Access, but I would argue its better to use a stronger form of authentication if you can. Think about what this Service Principal is allowed to do – create Win32 apps in your tenant! A malicious actor would love to create and deploy a Win32 app that dropped malware on your devices if they got hold of those credentials.

Certificates

Remember back to your basic training around authentication. Passwords are bad, strong authentication methods are good. When we think about Multi Factor Authentication we have something that others do not. A Certificate is something that I have, it is not a credential that can be used by anyone, which effectively makes it a stronger form of authentication than a client secret.

When I authenticate my Service Principal to get a token, I can use a certificate – but how does this work? A high level view of certificate based authentication:-

1. Create a certificate or obtain one from a trusted public authority
2. Upload the public key to the Azure app registration
3. The private key is used from the local device or uploaded and used from Azure automation
4. Authentication is successful
5. A token is returned which can be used to make calls to Graph

Create a Self Signed Certificate

Authentication with a certificate, from the perspective of automation at least, is quite simple. We often only need the private key on the local device performing the calls to Graph, normally the admin or developer, or it needs to be in Azure automation. We don’t need to send the certificate to all our clients which means its OK to create a self signed certificate for this function. A few caveats to consider when deciding to use a self signed certificate or one from a Public CA are:

1. Weaker Cipher suites may be used when self signed certificates are generated.
2. Outdated hashes may be used when self signed certificates are generated (Did you use SHA-1).
3. Only you have the private key – what if Dave want’s to use the same one or you leave the company and forgot to tell someone where you saved the private key.
4. You forget the password for your private key so cannot export it anymore

In summary, for production I would recommend consideration for certificates from a Public Certificate Authority but for testing, at the very least, self signed certificates are absolutely fine.

Certificate Requirements

There are many flavours of certificate that we can create. What should the cryptographic algorithm, validity period, key length be? Microsoft have a great article calling these out and I’ll list them below.

• A 2048-bit key length. While longer values are supported, the 2048-bit size is highly recommended for the best combination of security and performance.
• Uses the RSA cryptographic algorithm. Azure AD currently supports only RSA.
• The certificate is signed with the SHA256 hash algorithm. Azure AD also supports certificates signed with SHA384 and SHA512 hash algorithms.
• The certificate is valid for only one year.
• The certificate is supported for use for both client and server authentication

https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-create-self-signed-certificate

So that begs the question, “How do we create a self signed certificate”?

The “New-SelfSignedCertificate” PowerShell Cmdlet

The New-SelfSignedCertificate PowerShell cmdlet allows us to create a self signed certificate for the purpose of certificate based authentication to Azure AD.

If we just run the cmdlet and pass the Subject parameter, lets see what happens

New-SelfSignedCertificate -Subject "AzureCertIntuneTesting"

What happened then. It looks like a certificate was created somewhere. Let’s take a peek.

Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object { $_.Thumbprint -eq "24994e6e4a404978ea05476d940f6f88dd43d13c" }

certlm.msc show us some magic.

We can see the default properties of the certificate that was created. Information like the private key is exportable (useful if we need to export it for Azure Automation) and the default validity period is 12 months.

The default characteristics of the certificate, without passing any other parameters are:-

• A 2048-bit key length *
• Uses the RSA cryptographic algorithm (Azure AD currently supports only RSA)
• The certificate is signed with the SHA256 hash algorithm **
• The certificate is valid for only one year
• The certificate is supported for use for both client and server authentication

* While longer values are supported, the 2048-bit size is highly recommended for the best combination of security and performance.
** Azure AD also supports certificates signed with SHA384 and SHA512 hash algorithms.

Can we have a little more control? This snippet is useful to help you quickly create a self-signed certificate by splatting some params to the cmdlet.

$subjectName = "AzureCertIntuneTesting2"
$certStore = "LocalMachine"
$validityPeriod = 24

$newCert = @{
    Subject = "CN=$($subjectName)"
    CertStoreLocation = "Cert:\$($certStore)\My"
    KeyExportPolicy = "Exportable"
    KeySpec = "Signature"
    NotAfter = (Get-Date).AddMonths($($validityPeriod))
}
$Cert = New-SelfSignedCertificate @newCert

https://learn.microsoft.com/en-us/powershell/module/pki/new-selfsignedcertificate?view=windowsserver2022-ps

Export the Public Portion for use in Azure

Use the following snippet to export the public portion of the certificate as a .cer file which you can upload and use for your Service Principal (App Registration) authentication.

$certFolder = "C:\temp\certs"
$certExport = @{
Cert = $Cert
FilePath = "$($certFolder)\$($subjectName).cer"
}
Export-Certificate @certExport

Export the Private Portion for use in Azure Automation

Use the following snippet to export the private portion of the certificate as a .pfx file which you can upload and use when authenticating with the Service Principal (App Registration).

$certFolder = "C:\temp\certs"
$certThumbprint = $Cert.Thumbprint
$certPassword = Read-Host -Prompt "Enter password for your certificate: " -AsSecureString
$pfxExport = @{
    Cert         = "Cert:\$($certStore)\My\$($certThumbprint)"
    FilePath     = "$($certFolder)\$($subjectName).pfx"
    ChainOption  = "EndEntityCertOnly"
    NoProperties = $null
    Password     = $certPassword
}
Export-PfxCertificate @pfxExport

Create and Export the Public and Private Keys

We can take the examples above and run the following script block to generate a certificate and export the public and private keys – ready to be used for authentication.

$subjectName = "AzureCertIntuneTesting"
$certStore = "LocalMachine"
$validityPeriod = 24

$newCert = @{
    Subject           = "CN=$($subjectName)"
    CertStoreLocation = "Cert:\$($certStore)\My"
    KeyExportPolicy   = "Exportable"
    KeySpec           = "Signature"
    NotAfter          = (Get-Date).AddMonths($($validityPeriod))
}
$Cert = New-SelfSignedCertificate @newCert

#export public key only
$certFolder = "C:\temp\certs"
$certExport = @{
    Cert     = $Cert
    FilePath = "$($certFolder)\$($subjectName).cer"
}
Export-Certificate @certExport

#export with private key
$certFolder = "C:\temp\certs"
$certThumbprint = $Cert.Thumbprint
$certPassword = Read-Host -Prompt "Enter password for your certificate: " -AsSecureString
$pfxExport = @{
    Cert         = "Cert:\$($certStore)\My\$($certThumbprint)"
    FilePath     = "$($certFolder)\$($subjectName).pfx"
    ChainOption  = "EndEntityCertOnly"
    NoProperties = $null
    Password     = $certPassword
}
Export-PfxCertificate @pfxExport

We should end up with 2 files in our output directory as illustrated below.

The certificate, including the private key, will also be in the certificate store of the local machine as we saw earlier.

Configure Certificate Authentication for an App Registration

At the beginning of this post, we viewed the “Certificate & secret” blade on our app registrations. I will revisit that again now and show you how to add the certificate in readiness for certificate based authentication.

Navigate to Certificates & secrets blade and select Upload Certificate

Browse the the .cer file we created earlier and click Add

Great, the public portion of the certificate is right where we need it to be.

Authenticate to Azure AD using the application and the Private Key

If you are connecting from a Windows device, you may already have the certificate in your certificate store if you generated the self signed certificate from the same computer. If the certificate is not in certificate store, you can still generate JSON Web Token (JWT) for authorization. A great thread and code example can be found here. In this example I will assume you have the .pfx and want to make the authorization attempt from another location, like Azure Automation.

<#
.SYNOPSIS
    Authenicate using an Azure application and a certificate to obtain a token
.DESCRIPTION
    After generating a self signed certificate, use the pfx to authenticate to AzureAD to obtain a token
.EXAMPLE
    Get-CBAToken.ps1 -tenantId "0cebf1f4-e0c4-46d4-8c5a-0fc80bed6b2c" -applicationId "47727b19-7b3f-472a-8057-704affed1815" -pfxFile "C:\temp\certs\AzureCertIntuneTesting.pfx" -pfxPassword "123"
.NOTES
    
#>
[CmdletBinding()]
param (
    [Parameter(Mandatory = $true)]
    [string]$pfxFile,
    [string]$tenantId,
    [string]$applicationId,
    [string]$pfxPassword
)

$Scope = "https://graph.microsoft.com/.default"

If (-not $pfxPassword) {
    $pfxPassword = Read-Host -Prompt "Enter password for your certificate: " -AsSecureString
}
else {
    $pfxPassword = ConvertTo-SecureString -String $pfxPassword -AsPlainText -Force
}

#get certificate hash and create base64 string
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import($pfxFile, $certPassword, 'DefaultKeySet')
$cert64Hash = [System.Convert]::ToBase64String($cert.GetCertHash())  

function Get-Token {
    #create JWT timestamp for expiration 
    $startDate = (Get-Date "1970-01-01T00:00:00Z" ).ToUniversalTime()  
    $jwtExpireTimeSpan = (New-TimeSpan -Start $startDate -End (Get-Date).ToUniversalTime().AddMinutes(2)).TotalSeconds  
    $jwtExpiration = [math]::Round($jwtExpireTimeSpan, 0)  
  
    #create JWT validity start timestamp  
    $notBeforeExpireTimeSpan = (New-TimeSpan -Start $StartDate -End ((Get-Date).ToUniversalTime())).TotalSeconds  
    $notBefore = [math]::Round($notBeforeExpireTimeSpan, 0)  
  
    #create JWT header  
    $jwtHeader = @{  
        alg = "RS256"  
        typ = "JWT"  
        x5t = $cert64Hash -replace '\+', '-' -replace '/', '_' -replace '='  
    }  
  
    #create JWT payload  
    $jwtPayLoad = @{  
        aud = "https://login.microsoftonline.com/$tenantId/oauth2/token"  
        exp = $jwtExpiration   
        iss = $applicationId  
        jti = [guid]::NewGuid()   
        nbf = $notBefore  
        sub = $applicationId  
    }  
  
    #convert header and payload to base64  
    $jwtHeaderToByte = [System.Text.Encoding]::UTF8.GetBytes(($jwtHeader | ConvertTo-Json))  
    $encodedHeader = [System.Convert]::ToBase64String($jwtHeaderToByte)  
  
    $jwtPayLoadToByte = [System.Text.Encoding]::UTF8.GetBytes(($jwtPayLoad | ConvertTo-Json))  
    $encodedPayload = [System.Convert]::ToBase64String($jwtPayLoadToByte)  
  
    #join header and Payload with "." to create a valid (unsigned) JWT  
    $jwt = $encodedHeader + "." + $encodedPayload  
  
    #get the private key object of your certificate  
    $privateKey = ([System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAprivateKey($cert))  
  
    #define RSA signature and hashing algorithm  
    $rsaPadding = [Security.Cryptography.RSASignaturePadding]::Pkcs1  
    $hashAlgorithm = [Security.Cryptography.HashAlgorithmName]::SHA256  
  
    #create a signature of the JWT  
    $signature = [Convert]::ToBase64String(  
        $privateKey.SignData([System.Text.Encoding]::UTF8.GetBytes($jwt), $hashAlgorithm, $rsaPadding)  
    ) -replace '\+', '-' -replace '/', '_' -replace '='  
  
    #join the signature to the JWT with "."  
    $jwt = $jwt + "." + $signature  
  
    #create a hash with body parameters  
    $body = @{  
        client_id             = $applicationId  
        client_assertion      = $jwt  
        client_assertion_type = "urn:ietf:params:oauth:client-assertion-type:jwt-bearer"  
        scope                 = $scope  
        grant_type            = "client_credentials"  
  
    }  
  
    $url = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"  
  
    #use the self-generated JWT as Authorization  
    $header = @{  
        Authorization = "Bearer $jwt"  
    }  
  
    #splat the parameters for Invoke-Restmethod for cleaner code  
    $postSplat = @{  
        ContentType = 'application/x-www-form-urlencoded'  
        Method      = 'POST'  
        Body        = $body  
        Uri         = $url  
        Headers     = $header  
    }  
  
    $request = Invoke-RestMethod @postSplat  

    #view access_token  
    $request
}

Get-Token -tenantId $tenantId -applicationId $applicationId -scope $scope -cert $cert -certBase64Hash $cert64Hash

When we execute the script, we get a token!

And the Azure AD sign-in log shows the success authorization

Example: Authenticate with a certificate and make a Graph call to Intune

We can simplify things now. Lets use the access token to make a call to Microsoft Graph

$authToken = .\Get-CBAToken.ps1 -pfxFile "C:\temp\certs\AzureCertIntuneTesting.pfx" -tenantId "0cebf1f4-e0c4-46d4-8c5a-0fc80bed6b2c" -applicationId "47727b19-7b3f-472a-8057-704affed1815" -pfxPassword "123" 
Invoke-RestMethod -Headers @{Authorization = "Bearer $($authToken.access_token)"} -Method GET -Uri "https://graph.microsoft.com/beta/deviceAppManagement/mobileApps?$filter=(isof('microsoft.graph.win32LobApp'))"

Summary

In this post we looked at creating a self signed certificate for the purpose of authentication to Azure AD using a Service Principal. Certificates are a much better way to authenticate than client secrets. We created a JWT for authentication using the private key and made a simple call to Graph to prove it works. I feel part 2 might be in the works. We spoke about using Azure Automation with Certificate Base Authentication and I would like to give some examples of how that can be achieved when we store the .pfx in Azure Key Vault.

(4)

The post An easy way to get started with Certificate Based Authentication for Azure apps appeared first on MSEndpointMgr.

Over recent times we have seen Microsoft introduce a range of security hardening configuration options as the world continues to adopt to the fact that their internal infrastructure is no longer the main threat surface. In this post we will look at the latest of which (due to be enforced in January 2024).

The new Authentication Methods configuration is something which brings a welcome change, retiring per user based MFA configuration managed through the Microsoft admin portal, along with separate configuration methods for Azure AD Self Service Password Reset. This is welcomed change, especially for the legacy per user MFA configuration, which if you are still using it, please stop.

Bye Bye Per User MFA Configuration

Per user based MFA configuration has been around since “Office 365” was launched, providing the ability to enforce multi-factor authentication requirement for users. Management takes place within the Microsoft Admin portal (https://admin.microsoft.com), and by default resulted in users being provided with an “app password” which was used to sign into Microsoft Office applications, providing in effect an “MFA bypass” for those trusted applications due to the fact they had a defined password which was different to the user’s actual password.

The experience IMO was, shall we say.. terrible. This methods is also classed as legacy authentication and thus app passwords do not work with accounts which are required to use modern auth.

Since then thankfully the world has moved on quite a bit, and today, if you are using the legacy MFA configuration portal to enforce MFA, you are simply doing things wrong. Multi-factor challenge requirements should be all handled via conditional access, and identity protection policies, depending of course upon your Azure AD Premium licensing model.

Supporting Microsoft Learn Documentation
Enable per-user Multi-Factor Authentication – Azure Active Directory – Microsoft Entra | Microsoft Learn
What is Conditional Access in Azure Active Directory? – Microsoft Entra | Microsoft Learn
What is Azure Active Directory Identity Protection? – Microsoft Entra | Microsoft Learn

Authentication Configuration

As many of you might have spotted either in the Azure Active Directory blade, or within the new Microsoft Entra portal (https://entra.microsoft.com), authentication methods provides you the ability to enable and configure multiple authentication types which can be used within your Azure tenant.

If you haven’t spotted this, then you are also missing out on the fact that MFA app based challenges where due to be changed for all tenants on February 27th 2023, although this has been pushed back to May 8th 2023 when you read the documentation;

If that has come as a surprise to you, then I suggest you review the changes (Protecting authentication methods in Azure Active Directory – Microsoft Entra | Microsoft Learn) and issue communications to your user base as to avoid your helpdesk staff having to deal with “did you change something? I have to enter a number now” type questions.

Pre-Migration Considerations

Before you go ahead and make the jump to the new way of doing things, it is important you consider how removal of MFA enforcement will impact the security of your tenant. For example, if you have been using this method for your admins, you either need to enable security defaults (which brings limitations), or ensure / create conditional access policies are configured to cater for the different authentication scenarios.

Privileged Role Accounts

As an absolute minimum baseline, protecting your privileged role members can be undertaken through using the CA policy templates;

As always when creating conditional access policies, ensure you have a break glass / emergency admin account created, with a complex password, and excluded from the conditional access policy (just in case something goes bump in the night with the MFA service) – Manage emergency access admin accounts – Azure AD – Microsoft Entra | Microsoft Learn.

General User Access

I’m not covering conditional access policies for all scenarios in this post, as it is a large topic by itself. I would suggest that you take a persona based approach to your CA configuration however, and recommend that you read the Microsoft learn docs in relation to this – Conditional Access architecture and personas – Azure Architecture Center | Microsoft Learn

Security Questions

Within the migration to the new authentication methods configuration, the ability to use security questions for Azure Self Service Password Reset is retired. This in my opinion is only a good thing, as typically the answers to questions are either forgotten or the same answer is used for all questions.

The Migration Process

The process of moving from the old legacy portal to the new authentication methods configuration is quite simple, so let us step through this.

• In the Authentication Methods configuration (in either Azure portal Active Directory Authentication Methods or Entra portal Authentication methods) you will see a notice about the “Manage migration (Preview)” feature;

• Clicking on the “Manage migration (Preview)” link, clicking this will display the following slide in:

• When switching to the authentication methods configuration, the first thing that we need to is to set the tenant into a “Migration in Progress” state. What this does under the hood is to allow us to uncheck the supported MFA methods in both the legacy per user multifactor, and Azure AD Self Service Password Reset configuration pages
  

• With the tenant now in the new state, we can start with reviewing and removing the existing supported methods
• Going into the legacy MFA portal (Multi-factor authentication (windowsazure.com)), first of all you should review which methods are currently enabled;
  

• Going into the Azure AD Self-Service Password Reset configuration, again let’s review the existing methods here also;

• In this example we have then decided that I am going to retire SMS and Phone calls, moving to a model that uses the Authenticator app and Temporary Access Pass methods.
  
  I would recommend where possible retiring SMS and Phone call authentication as they are the weakest options, however, you could take a phased approach where these methods are phased out.
  
• Before we make changes, we need to disable the legacy MFA enforcement for all enforced users in the legacy MFA portal:

• Now going back to the Authentication methods configuration, we configure the required methods;

• In the configuration options for the Authenticator method, we can also specify to enforce number code matching before it is pushed by Microsoft to all tenants, and also include the options to display the location and application signing in, all of which are important information to present to the end user;

• The temporary access pass configuration is then also configured;
  

• With the new configuration set, in both the legacy MFA portal and AD SSPR configuration we then remove all methods;

• If you receive the following error, try refreshing the portal as the configuration has not been updated to allow you to have no methods specified (try refreshing / signing out and back in );

• Testing the updated configuration, we should receive an authenticator prompt with the additional number matching and location information displayed;

• At this point with all configuration items done, we can go and set the tenant state to “Migrated” in the Authentication Methods configuration;

• You should now receive a visual confirmation that the setting has been applied;

Closing Thoughts

Migrating to the authentication methods configuration is a straight forward process, resulting in a single configuration page for your auth methods.

So my suggestion is to plan your migration today, and not leave it up to January 2024 to be in a panic situation, especially when it comes to your conditional access policy configurations.

(186)

The post Migrating to Authentication Methods Policies – Happy days! appeared first on MSEndpointMgr.

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. in this Trilogy you can expect to learn the what, the how and the wow!

The story so far

We continue our mini series on Windows Hello for Business Cloud Kerberos Trust. In part 2 we walked through the configuration of Cloud Kerberos Trust for both on-premise infrastructure and clients.

If you missed part 1 of our series, your journey into “Cloud Kerberos Trust” should start here: Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 1

We love the elegance and simplicity of Cloud Kerberos Trust but in this final post of the mini series we will dive a little deeper and look at some of the mechanics and moving parts to help you understand and troubleshoot your way out of a hole- if you need to.

Hold tight and get your engineer brain engaged as we equip you with the tools you need to succeed!

Pick-up your engineering toolkit and come down the rabbit hole

Migrating from other Trust Models

This question often comes up, naturally. What if you are using hybrid key trust and you want to begin kicking the tires on cloud kerberos trust? The answer is simpler than you might think.

Migrating from a hybrid key trust model is very simple. For Azure AD and Hybrid Azure AD joined devices, simply deploy the Intune configuration to enable cloud kerberos trust and the user will switch to cloud kerberos trust. The extra requirement for Hybrid Azure AD joined devices is the device requires line-of-sight to a DC at first logon or it will fall back to using key trust.

Migrating from certificate trust has more moving parts. You must disable the existing certificate trust policy, deploy the Intune configuration to enable cloud kerberos trust, delete the existing hello credential and sign back in to the device.

Use the following command to delete the existing hello credential

certutil.exe -DeleteHelloContainer

The “Key” thing to understand, (see what I did there?) is that a policy that defines neither: “Use certificate for on-premises authentication (*1)” or “Use cloud trust for on-premises authentication (*2)” is considered as using the “Key Trust” model for authentication.

Privileged Accounts

Highly privileged accounts are not granted, by default, to use FIDO2 security keys and/or cloud kerberos trust to login to a device. The local security policy forbids it.

The msDS-NeverRevealGroup property is used to define which AD objects forbidden to have their passwords cached on the Kerberos RODC.

To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>).

Caution should be used when relaxing any local security policy. Understand the impact, if any, of what you are about to do

Next Generation Credential (NGC)

The Next Generation Credential (NGC) is important. Verify the NGC has been set on client devices correctly by using dsregcmd (in the user context) command. NgcSet: YES means that a hello key has been set for the current user

dsregcmd /status

Verify the NGC has been saved to the user object in AzureAD using Graph Explorer. Examine the deviceKeys attribute for the NGC assigned to the device the user logged on to using WHfB.

The NGC is present as a result of the normal WHfB authentication process – it is not specific to us enabling AzureAD Kerberos but it will be important when we look at other moving parts later in this blog.

The NGC contains the base64-encoded public portion of the asymmetric key pair used for WHfB authentication.

You can also see in the Windows event log that the NGC was created and written to the user object in Azure AD

In Graph Explorer, we can also see some other cool metadata that will be useful when we deep dive later!

Cloud Kerberos Trust under the Microscope

Before we dial in our microscopes it is best we define what the high level components are in a Windows Hello for Business Cloud Kerberos Trust relationship as this will help us sort through the finer details.

• AzureADKerberos
• Windows 10/11
• Windows Server 2016 or newer DC
• User account synced from On-Premise

Yes, it is basically just those few things, no PKI is explicitly required! And now we have that sorted, on to nitty gritty.

AzureADKerberos

In Part 2, we provisioned the Azure AD Kerberos Read-Only Domain Controller (RODC) object into the “Domain Controllers” OU of our local Active Directory domain.

So what happens when the object is created? It creates a server object that can issue Ticket Granting Tickets (TGTs) for Kerberos in your domain. The encryption key is then securely published to Azure AD, which allows it to issue a partial TGT as part of the magic behind Cloud Kerberos Trust. This partial TGT is received by the user via the Primary Refresh Token when they authenticate with Azure AD. The TGT includes only the user’s SID, and no authorization data.

This is a one-time operation, and for each on-premises domain, an object will represent it in Azure AD. No background processes are enabled to keep things in sync. It’s all very secure!

If you have more than one on-premises domain, each one will have a key in Azure AD that corresponds to the on-premises domain. Thus, if you have multiple domains, this is not an issue. However, if you have a single domain and multiple tenants, the issue becomes more complicated, as there is no option to just publish the encryption key of the current Azure AD Kerberos RODC object into another tenant.

It’s important to know that, since the encryption key (kbrtgt) is not synced after the initial publishing into Azure AD, it’s imperative to only use the Azure AD Kerberos PowerShell module to rotate the kbrtgt of the Azure AD Kerberos RODC object.

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userprincipalname -RotateServerKey

There is more of on the official Microsoft Learn site: Passwordless security key sign-in to on-premises resources – Azure Active Directory – Microsoft Entra | Microsoft Learn

Windows 10/11

ICYMI: Windows is required for Windows Hello for Business to function. But not just any version of Windows. Windows 10 21H2 and later are recommended because the Cloud Kerberos Trust feature was introduced with this build.

So what happens during sign-in, since it is important to have an updated version of Windows? Well it depends on what join-type your device is using – Hybrid Join or Azure AD Join. Let’s start with the most common “Hybrid Join”.

Hybrid Joined

There are many roads to Rome, and this one takes the longest of them all!

Azure AD Joined

Be prepared to be amazed at the simplicity of being in an Azure AD Joined state and doing SSO to your on-prem resources:

If you wanna get deeper into it and follow these awesome diagram flows from Microsoft, there is the official documentation at Microsoft Learn: How Windows Hello for Business works – Authentication | Microsoft Learn

Kerberos is King

Meet Michael, Ben and Fluffy the dog. Cerberos is the mythical creature that guards hades, the gates of hell. Fluffy is the watchdog of the underworld etc. In previous roles he was guarding Windows Vista and was born in the 80’s when no one cared what shampoo you used.

Kerberos has 3 parts/heads (Michael = User, Fluffy = KDC, Ben = Service)

So what is Kerberos and how does it help us when we are looking to SSO to our domain resources? Here are some Kerberos basics

• “Kerberos” is just a cryptographic ticketing system
• In order to request tickets to domain resources, the Kerberos protocol needs to know where the “Ticket Master” is
• The “Ticket Master” is called the Key Distribution Centre (KDC)
• The KDC in a Windows Domain is a Domain Controller

Basically I need to get a ticket from the domain controller, or KDC, to prove who I am to the service e.g. file server

Finding a KDC

Azure AD joined devices are not aware of your domain, so how do they find the KDC to get tickets? Thats easy and takes us back to the 80’s again. DCLOCATOR is a process used by Windows systems to locate the closest available Domain Controller

First my client needs to find the KDC, how does it do this when the client knows nothing about the domain? Ah-ha, remember we have some synced attributes that come down with our Primary Refresh Token at logon. DCLocator needs a domain hint, which it gets from the <onpremisedomainname> attribute that came down with this PRT. A Domain Controller (KDC) is returned to the client as a result of, effectively, a DNS query.

We can simulate what DCLocator does by running the nltest on a device and passing the domain name

nltest /dsgetdc:byteben.com

If on-premises DNS is broken or the client is not configured correctly for DNS. This query might/will fail. Its always DNS right?

Tickets Please

Now we know where the KDC is, lets go into a bit more detail on how Kerberos ticket issuance works and helps us to access domain resources.

1. The partial TGT we obtained from AzureAD is sent to the KDC.
2. The KDC validates the partial TGT.
3. The KDC then issues a “Golden” ticket to the user. The golden tickets, or Full TGT is proof the user authenticated. Authentication has a lot of overhead so we don’t want to keep doing it.
4. The user then sends that TGT (proof that they can come into the nightclub) along with another request to access a service, like CIFS (fileshare)
5. The KDC sees the user has a valid TGT (BTW, only the KDC can decrypt the TGT) and issues a “Service Ticket”. The service ticket contains things like group membership and service requested.

We can see the AS-REQ for a ticket come into the KDC (You can filter Wireshark using the KRB5 protocol to see this cool stuff)

When we try to access a file share, we see the client send a request to the KDC.

When we try to access a file share, we see the client send a request to the KDC. The request contains our TGT which validates who we are

The KDC then issues us a service ticket for the resource we just tried to access. In this example we accessed a file share on bb-app1.byteben.com

Klist

Klist displays all the service tickets we have been granted. Here is the service ticket we requested to access the file share on bb-app1.byteben.com

Klist also has another cool command when working with Cloud Kerberos Trust

klist /cloud_debug

Summary

Hopefully this 3 part mini series has been useful. Its always difficult to know how deep to go and keep the content engaging. If you would like any more info, please reach out!

Bookmark this page, because there is no way you will remember all of this stuff, and don’t forget that Ben and Michael work for likes and follows on Twitter and LinkedIn. Fluffy takes bones, peanut butter and cinema ticket stubs as donations.

(6)

The post Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 3 appeared first on MSEndpointMgr.

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. in this Trilogy you can expect to learn the what, the how and the wow!

The story so far

We continue our mini series on Windows Hello for Business Cloud Kerberos Trust. In part 1 we introduced the concept of Cloud Kerberos Trust and spoke to some of the challenges it can help organisations overcome. One of the things that we love is the simplicity of configuration – both for green field tenants and for organisations already using a different trust method with Windows Hello for Business (WHfB).

Simplicity is elegance

In this post, we will show you how to configure Cloud Kerberos Trust for your on-premises infrastructure and how to create a configuration policy for your client devices.

Enabling Azure AD Kerberos for Cloud Kerberos Trust

This is so easy. Honestly, put one hand behind you back, juggle some wet frogs and sing “I will always love you”, all at the same time, and you will still be able to configure Azure AD Kerberos too.

Enabling Azure AD Kerberos creates an “Azure AD Kerberos” server object in the domain.

This server object:

• Appears as a Read Only Domain Controller (RODC) object, but isn’t associated with any physical servers.
• Is only used by Azure AD to generate partial TGTs for the Active Directory domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object.

We will configure Azure AD Kerberos in our lab. Full prerequisites can be found here and the code samples are taken from the Microsoft docs here

1. Download and install the Azure AD Kerberos PowerShell module

from the PowerShell Gallery. This can be done directly on the Domain Controller or from a computer that can access the Domain Controller.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

TLS 1.2 is required to access the PowerShell Gallery. Run the following command if it is not enabled.

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

2. Run the following

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

3. Verify that the Kerberos server RODC object was created successfully.

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

4. Also verify that the krbtgt user account was created (it is intentionally disabled)

Configure Cloud Key Trust using Intune

We can either use a GPO or push a configuration from Intune. If you are interested in using a GPO, read more here. In this post we will push the configuration from Intune (this is the way).

Ensure the client devices are a minimum of Windows 10 21H2 / Windows 11 Pro or Enterprise SKU. Perhaps consider using an Intune Filter for targetting.

1. Create a configuration profile

Navigate to https://endpoint.microsoft.com and create a new Device Configuration Profile of type

Windows 10 and later > Templates > Custom

2. OMA-URI for Cloud Kerberos Trust enablement

Add the following settings

Name: UseCloudTrustForOnPremAuth
OMA-URI: 
./Device/Vendor/MSFT/PassportForWork/<tenant-id-guid>/Policies/UseCloudTrustForOnPremAuth
Data type: Boolean
Value: True

Tenant ID in the OMA-URI must be replaced with the tenant ID for your Azure AD tenant

3. Assignments

Assign the profile to your desired group. You can target either users or devices.

4. Test the policy worked

At this stage, after a synced user logs in using WHfB, verify that a partial TGT has been issued using the command:-

klist cloud_debug

You can also be verify in the event log if the policy has been set successfully on the client.

Summary

In part 2 of this mini series we looked at how to configure Cloud Kerberos Trust. In Part 3 we will dive a little deeper into some of the moving parts and help with some troubleshooting tips. Stay tuned for more fun!

(11)

The post Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 2 appeared first on MSEndpointMgr.

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. In this Trilogy you can expect to learn the what, the how and the wow!

The story so far

Windows Hello for Business Cloud Kerberos Trust – Every silver lining begins with a journey through pain, non optimal circumstance and wisdom gained through grit and determination. The trust model story has never been simple..

In this 3-part mini series, we will talk about concepts, strategies, configurations and pain points that we commonly come across when configuring Windows Hello for Business and why Cloud Kerberos Trust is the future.

What is Windows Hello for Business?

We won’t spend too much time peeling apart what Windows Hello for Business (WHfB) is but let’s remind ourselves of some key points.

• WHfB is a password-less authentication mechanism. Think of it as a type of user credential which is uniquely tied to a device – secured with a PIN or biometric
• WHfB is not the same same as Windows Hello. Windows Hello “convenience PIN” is targeted for the home market and is, essentially, like a password vault. A PIN or biometric is used to reveal the password(s) in that vault.
• WHfB key trust uses an asymmetric key pair, a password is never hashed and sent across “the wire” which is what makes it particularly secure. The private key is secured, normally, using the Trusted Platform Module (TPM). The private key never leaves the device and is unique for every device. An alternative to WHfB key trust is WHfB certificate-based authentication.

Why Windows Hello for Business?

Passwords are weak. Full stop. In a world where Identity theft is on the rise and password lists can be purchased from the dark web for the price of a McDonalds coffee we need to do more to secure the identity of our workforce. Passwords are transmitted over the wire and are susceptible to many man in the middle and eaves dropping practices.

This leads to the question…

Why does WHfB address the weak password conundrum?

WHfB is considered a “Strong” authentication type. The Biometric and PIN are unique to a user on a specific device where as passwords can normally be used to validate a user from any device.

WHfB differs because the “Password” or “Private Key” never leaves the device. For WHfB key trust, a cryptographic key pair is bound to the TPM or in Software (less secure). WHfB policy dictates where the key is generated. The Identity Provider (IDP) has the public portion of the key that is mapped to the user account during the registration process. Even when a token is generated by the Identity Provider (IDP) it is bound to that specific device.

Unlike some Multi-Factor (MFA) methods, WHfB is considered “Phish Resistant”. This means that strong authentication cannot be phished, unlike “One Time Passwords” and “Push Notifications”.

When we talk about WHfB, many orgs think about key trust but certificate trust is also another valid way to ensure a strong logon to a device. Certificate trust is used by orgs leveraging ADFS.

WHfB is great, and a much stronger alternative to passwords, but there are still scenarios where some might consider the PIN is weak compared with a password. If you deploy a WHfB policy and require a 4 digit PIN, will most users use the day and month of their birthday for the PIN – or perhaps a phone number? This information can be easily phished through social engineering.

Also consider if a laptop is stolen on a train and the PIN is shoulder surfed – an attacker has access to the device*

We are not saying don’t use WHfB because of these scenarios but you should be aware of them when deciding on your WHfB PIN policy and Conditional Access design.

* TPM anti-hammering can prevent an attacker guessing the PIN incorrectly too many times.

Key Trust

Many organizations have already deployed WHfB key trust. If you are still requiring your devices to access on-premise resources, the single biggest pitfall is during initial deployment.

A synced user identity is required in a hybrid environment. Image you have a shiny, internet born device, enrolled in Azure AD and managed by Intune but you want the user to still access resources within your domain. We spoke about this scenario and the requirements in our SSO mega series.

SSO to domain resources from Azure AD Joined Devices – The MEGA Series – Part 1 – Overview – MSEndpointMgr

During the provisioning of WHfB, there is a delay while the Next Generation Credential (NGC) is written back to the Active Directory User object – specifically the msDS-KeyCredentialLink attribute.

Below is a high level flow for a typical first logon in a hybrid scenario when the user is prompted to setup WHfB.

1. User signs in and is prompted to setup WHfB
2. PIN is set and Biometric (if applicable) is chosen
3. NGC written to Azure AD user object
4. ADConnect, by default every 30m, synchronizers the NGC to the Active Directory User object.

Until that AD Sync happens, the user cannot authenticate to on-premise resources with WHfB. This results in a poor first-run experience where users would setup WHfB and then be told by IT they need to sign back in with their password or “go and have some pie and wait an hour before trying again”.

Key Trust Pain Points

• Requires a Certificate Authority and a valid trust chain from the device to a 2016 DC.
• In order for SSO to function on an Azure AD joined device you need to publish a CRL. This can be challenging to configure and debug if you are not comfortable with Enterprise PKI.
• SSO will not work until the NGC is synced back to Active Directory

Certificate Trust

The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience of WHfB.

Companies using ADFS only had the option to use certificate trust. We still found, in our experience, that most companies used the key trust type for WHfB. Did anybody who configured certificate trust live to tell the tale even? Who knows!

Our thoughts on certificate trust are few, so we won’t dwell on it in this post.

Certificate Trust Pain Points

• Requires a Federated domain. AD federation with AAD. (Who else vomited a little in their mouth when they read ADFS?)
• Requires a PKI for SSO to on-premises resources. Users are issued certificates during enrollment to WHfB.
• Certificate requirements are complex – no one got no time for legacy PKI design.

What is Cloud Kerberos Trust?

WHfB hybrid key and certificate trust always had a lot of moving parts. AD Connect, Device Registration, PKI, sync wait times and more. There was often misunderstanding on configurations, timings and almost every blog post or Microsoft doc you looked at never quite explained the setup for your specific scenario.

Microsoft knew this complexity was a roadblock to many and they really wanted to help organisations improve their authentication posture – moving away from insecure passwords was an itch everyone was eager to satisfy.

The big challenge they had to solve was the reliance on the credential sync and complex configuration of many moving parts. Along came Azure AD Kerberos.

Azure AD Kerberos was first brought in to enable FIDO2 authentication on HAADJ devices. Azure AD Kerberos facilitates kerberos ticket issuance by Azure AD instead of on-premises Domain Controllers. Because a DC was not critical to the ticket issuance, neither was the wait for AD Connect to sync when a user first setup their WHfB credential. Azure AD Kerberos allows AzureAD to issue TGT’s that came down with the PRT – amazing stuff.

Onto a winner:-

• No need to deploy a public key infrastructure (PKI) or to change an existing PKI
• No need to synchronize public keys between Azure AD and Active Directory for users to access on-premises resources. This means that there isn’t delay between the user’s WHFB provisioning and being able to authenticate to Active Directory
• Passwordless security key sign-in can be deployed with minimal extra setup

At a high-level, “Cloud Trust” means, that we establish a chain of trust directly with Azure Active Directory. Instead of a triangle of trusts that involve our local AD, PKI, the device TPM storage things become incredibly simple, incredibly quickly.

The big game changer with Cloud Key Trust is WHfB works immediately after enrolment for SSO to domain resources

There is no need to wait for Azure AD Connect to sync some public key material to establish the trust, or anything like that. It. Just works. So, that’s the first problem Cloud Kerberos Trust solves – the users waiting for sync and the issues that arise from trouble with the msDS-KeyCredentialLink in AD.

The Second problem Cloud Kerberos Trust solves – no more PKI requirements or CRL over http required for hybrid devices.

A third problem Cloud Kerberos Trust solves, limited normally to large organisations, is the added CPU overhead for KDC Authentication when using key trust. In some instances those organisations had to spin up extra domain controllers to handle the extra processing load.

Can I get rid of the PIN requirement now?

“Silly rabbit! Trix are for kids” And tricks like removing the PIN code is not a thing.
You need the PIN as a fallback for your. biometrics, just like with any passwordless solution out there, we need a way for the user to recover in case their biometrics fail, or if there simply are no biometrics available.

Remember fundamental principles of multi-factor authentication.

• Something the user has: Any physical object in the possession of the user, such as a security token (USB stick), authenticator app, their device, etc.
• Something the user knows: Certain knowledge only known to the user, such as a password, PIN, etc.
• Something the user is: Some physical characteristic of the user (biometrics), such as a fingerprint, etc.

So if your argument is that the PIN seems insecure compared to a password, think again – it ONLY relates to the unlocking of your access token in the TPM for use in Windows Hello for Business. The password on the other hand will let you in from a remote location, which is ideal for a hacker or any bad actor.

But of course, protecting the PIN is still important, so here are a few strategies to consider if you feel that the PIN is a security risk (These are notes from the field and not necessarily to be considered recommendations).

1. Teach users to only use Biometrics, and have a policy of only using the PIN in a secure way (e.g. never in the open Office, and always looking over their shoulder while wearing a tin fil hat!)
2. IT can be a part of the WHfB provision process, and choose the unique PIN for the users. This PIN could be kept with IT, and never disclosed to the user unless required. If you choose this option, remember to disable PIN recovery for the users, and have a policy of never using the same PIN on multiple devices. Using this strategy is not recommended, as you are essentially creating a treasure chest for any bad actor to abuse (i.e. insider risk)
3. Make the PIN more complex but avoid making it possible for the user to replicate their actual password (if you are still providing them with such a relic). This could be achieved by adding a requirement for the use of lower case letters (not upper case) besides just the digits.

As a final word of advice – consider your very own smartphone. How do you login to that?
Face? Fingerprint? PIN? – Regardless of your answer, consider that you are holding on to that device 24/7 like a crack addict. And just put things into perspective, when you say that PIN seems less secure than a password.

How does authentication work to on-premise resources?

After Cloud Kerberos Trust s is enabled for the user (see the next post in our mini series), we can observe the following authentication flow when we attempt to access domain resources – after all, the main purpose of enabling Cloud Trust with WHfB is for SSO authentication to domain resources.

• There is still a requirement for the user to be synchronized from Active Directory. This is how we discover the domain name associated with the user in order to request tickets from the KDC. Authentication to Active Directory from an Azure AD joined device begins when the user first attempts to use a resource that needs Kerberos authentication.
• The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user’s domain.
• Using the hint, the provider uses the DClocator service to locate a 2016 domain controller.
• DCLocator needs a domain hint, which it gets from the onpremisedomainname that came down with the PRT.
• A Domain Controller (KDC) is then returned to the client to continue normal service ticket issuance.

Note If DNS is broken this lookup will fail – it’s always DNS when things fail
_{(except when it’s routing)}

• After locating an active 2016 domain controller, the Kerberos provider sends a partial TGT that it received from Azure AD from a previous Azure AD authentication with the domain controller.
• The partial TGT contains only the user SID and is signed by Azure AD Kerberos.
• The domain controller will verify that the partial TGT is valid.
• On success, the KDC returns a full TGT to the client so the client can begin requesting service tickets.

In summary, Azure AD Kerberos issues a partial TGT to the user. The partial TGT is then exchanged for a full TGT from the KDC and normal service ticket issuance continues when the user tries to access domain resources

TIP

DNS hit and miss in your place? You can test if DCLocator is able to return a list of valid DC’s by running the nltest command

nltest /dsgetdc:contoso.local

Summary

In part 1 of this mini series we introduced the concept of Cloud Kerberos Trust. Being able to receive partial TGT’s from Azure AD is a game changer in terms of speed to SSO logon for on-premises resources AND for simplicity of configuration for admins.

In Part 2 we will look at how to configure Cloud Kerberos Trust. Stay tuned for more fun!

(15)

The post Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 1 appeared first on MSEndpointMgr.

Finding Devices in need of Replacement

To start the device refresh process, endpoint managers first need to identify endpoints for replacement this year. Many organizations go about this in their own ad hoc way. For instance, some try to incorporate information about the machine purchase date into their naming convention. This too often leads to confusion if not executed properly.  

Another common device replacement strategy is to identify the machines that either already have their warranty expired or are up for expiration this year. Depending on the organization’s hardware inventory tracking system, this can be a very tedious task. IT teams must manually gather service tags and then go out and check them against the OEM’s warranty checking utility on their individual websites. This process can become a black hole for the team’s time, especially in organizations that have device counts in the thousands or tens of thousands.  

Identifying devices for replacement is the crucial first step. Only then can the team start to formulate a new hardware budget for the year.  

Device Warranty Information Reporting

Endpoint Insights from Recast Software, also the creator of Right Click Tools, reduces this friction with its warranty information reporting. Endpoint Insights gathers information about the devices (make, model, serial number, etc) and then sends it over to Recast where that information is normalized and passed over to the OEMs (over 100 supported) via an API. The warranty information is then returned right to your ConfigMgr database. This allows IT teams to cut out the manual process of checking different OEM’s websites to get the warranty information on the devices. This is especially useful after the pandemic caused supply shortages that forced many organizations to buy any hardware available. This often included hardware outside of the company’s norm. Endpoint Insights handles all of this for you and makes the information readily available for all your devices with reports that find the warranty information for a single computer or all devices via device collections to ensure you have a clear and complete view of your warranty statuses.  

Additionally, Endpoint Insights features a report that is specifically built to both identify devices needing replacement and assist in building a budget. The Computer Replacement Costs Calculator powerfully pulls all your device warranty information into one place and helps you build out a custom budget based upon your specific circumstances. The report gives you a clear picture of all devices currently out of expiration, as well as devices coming up for expiration in the next few years. This adds clarity and accuracy to your budget forecasts and planning. Furthermore, you can input your own data regarding how much you spend per device type (desktop, laptop, server, etc), as well as how long you typically keep each device. With your company-specific data entered, IT teams get a customized budget estimate. No need to pull together your own spreadsheets to gather a rough estimate. 

More Thorough Device Replacements

During the execution of a device refresh, there are a few scenarios that often result in additional follow-up appointments for the IT team. Case in point: arriving at the replacement appointment with missing components. This could include missing software, missing printers, or the wrong cables for the current monitor. These tedious issues cause headaches for both the IT staff and the end user, who is now missing hardware or software they need to continue working. More broadly, this issue agitates both the IT staff and end user, reducing confidence and trust in the institution. 

Here too Endpoint Insights can assist. In addition to warranty data, Endpoint Insights pulls in supplementary datapoints that provide a more detailed view of your endpoints than ConfigMgr offers natively. These additional data points include monitor information (yes, even the connection type), mapped printers, mapped drives, installed software (including user installed), docking stations, and more. With these pieces of information pulled into ConfigMgr, IT teams can ensure that their end users receive the best possible experience when transitioning to their new devices. The last thing you want to do when making the trek to replace a device is to have to return later because you brought the wrong display cables. It feels terrible reconnecting the old machine, then returning back to the home office without the task completed.  

Utilizing these additional Endpoint Insights data points and reports makes it easier to confidently show up to device replacements knowing you have all you need. The All-in-One Computer View report functions as a solid starting point for the computer needing replacement. This report provides valuable information including the monitors connected to the device, any docking station connected, as well as the applications installed on the device. To access this report within ConfigMgr, right click on the device, hover over Right Click Tools, then over Endpoint Insights, and finally select the All-in-One Computer View.  

Installing Mapped Drives and Printers on new Devices

To ensure that all the mapped drives and printers are added, Endpoint Insights offers other reports to assist. In ConfigMgr reports, accessible within the ConfigMgr console or in the web portal, all Endpoint Insights reports are stored in the namesake folder. Mapped printers and mapped drives reports are in the “Users” folder, for example. To get a list of all mapped drives on a device check the “Computer Mapped Drive Details” and select the specific computer. This provides a detailed list of all the drives on the device, including the drive letter and the UNC path for the mapped drive.  

Similarly, for the mapped printers check the “Computer Mapped Printer Details” report to get a list of all the printers on the device. This will detail the port the printer is installed on, as well as the server and share names if it is being hosted on a print server.  

Streamline Hardware Inventory Planning and Device Refreshes

Check out this Endpoint Insights page to learn more about the powerful hardware and software data and reports added to your ConfigMgr instance by Endpoint Insights. You can also request more information, including a custom quote here.  

Additionally, watch our recent five-part webinar series on Endpoint Insights. Garth Jones and the team dig into many of the core features in this multi-part webinar. 

(1)

The post Device Refreshes Simplified with Endpoint Insights appeared first on MSEndpointMgr.

In this post I will revisit Co-management workloads, capabilities and take a walk down memory lane.

Background

Ok, let’s expand on what “Moving to the Cloud” means to us – and that varies, a lot, depending on who you speak to. Quite often our journey to the cloud is complex. We don’t have a magic button that shifts everything from on-premises to the Cloud and then cuts our operational bill in half – that kind of thinking belongs with an eccentric wizard and his hobbit friends. More often the path is much more complex.

I remember being an admin when “The Cloud” burst onto the scene. Technologies were being born and new concepts like “Its a journey, not a destination” were being spread like wild fire. I had a feeling of urgency that I had to move our organisation with the times and current trends but it was more than that. There was a sense that the old days of baby sitting the Exchange server in the corner were coming to an end and this new, cloud first, world needed learning, chasing and embracing.

The biggest challenge that I remember churning through my over analytical brain was “How does this all come together and look at its conclusion”. I didn’t really have an overall picture of how this puzzle would look when it was complete. What part of my infrastructure would remain on premises and what would be in the cloud. It was very much a case of take baby steps and trust in the process. Cloud strategies hadn’t matured and many of us felt like early pioneers in the “Moving to the Cloud” gold rush. This was exactly how Ernest Shackleton must have felt on that fateful journey to Antarctica…our cloud journey was bound to end in disaster but we all crossed our fingers and trusted in the marketing headlines.

Configuration Manager “The steady ship”

Like me, many admins had managed a steady ship for years. She was the pride of the fleet. Maturing from year to year with no end in sight to her prowess. Configuration Manager was/is a master piece. We got a sense that the white fluffy things (clouds) were on the hymn sheets in Microsoft HQ when we saw technologies like IBCM and Cloud DP come into the portfolio.

Organisations started asking us if we could manage mobile devices with Configuration Manager, which was an interesting chapter in many of our lives, and we started to get a taste of something on the horizon. Intune was afoot…

https://learn.microsoft.com/en-us/mem/intune/fundamentals/ui-changes

Intune “The Cloud”

Intune burst onto the scene and felt like this bold, new, idea that would help us navigate seamlessly to the cloud. I and many others were wondering how and when to embrace the Cloud, Microsoft too were stepping into a new era with a stronger focus on the fluffy white stuff.

Intune matured, slowly at first but then more rapidly when released from the shackles of Silverlight. We could see how promising cloud management could be and like kiddies in a candy shop, we had no patience. We wanted ALL the features and control that we were used to in Configuration Manger and we wanted it now.

Intune, for all it promised to be, actually presented us with some difficult conundrums. We wanted to embrace the cloud but there wasn’t a simple “Do it” switch. Microsoft still hadn’t worked that part out. Instead, we were faced with challenges like hybrid identities, ADFS (painful memories), the advent of AD Sync, moving mobile device management from ConfigMgr to the Intune, ensuring GPO’s didn’t conflict with Intune policy. It was a hot spaghetti mess that would trip you up if you didn’t navigate the pot holes like a cautious badger on stilts.

Co-management “The Bridge”

Enter Co-management. This was hands-down the most promising technology yet to help us transition smoothly to device management from the Cloud. Co-management finally allowed us to move different workloads to Intune, at our own pace. We had options. It was no longer the choice of “do nothing” vs “big bang cutover”.

Fast forward to today. Co-management has matured – a lot. She still has a little way to go and the story isn’t complete but golly are admins faced with much easier migration challenges today than we were 10 years ago.

Workloads

I wanted to focus this post on something I have been looking at recently

Workloads is a concept that allows us to move individual “workloads” from Configuration Manager to Intune. What are the workloads we can move? The options have changed over recent years, today we have the following:-

• Compliance Policies
• Resource Access Policies
• Device Configuration
• Windows Update Policies
• Client Apps
• Office Click-2-Run Apps
• Endpoint Protection

Microsoft have a great doc explaining what moving each of the these workloads means, I won’t duplicate that information in this post. Go check out Co-management workloads – Configuration Manager | Microsoft Learn

The great thing about workloads is that you can move them, individually, at a pace that suits you and your adoption of the Cloud.

I wanted to focus this post on something I have been looking at recently and that is workload capabilities.

Capabilities

Capabilities have fascinated me since I blogged on them back in 2019

• Co-management Series “Merging the Perimeter” – Part 7: Co-management Capabilities (byteben.com)
• SCCM 1906 Co-management Capabilities Matrix (byteben.com)

Every workload has an associated numerical value. We refer to this as the capability number. You can very easily see the capability value assigned to the client in the ConfigMgr control panel applet and CoManagementHandler.log

Up until recently we grew familiar with the capability values. Enter ConfigMgr 2111 – enter crazy values.

We should remind ourselves what these values are and what they represent. Each workload has a corresponding value. Before ConfigMgr 2111, they looked like this:-

Now, they look like this

When we start to move workloads to our to Intune, the capabilities value reflects the combined workloads.

For example, moving client workloads for Compliance Polices and Client Apps used to give the client a Co-management capability of 67. But how do we get to this number? 67

Co-Management Enabled (1) + Compliance Policies (2) + Client Apps (64) = 67

Bitwise Operations

That looks fairly straight forward right? Well yes, we could calculate the value previously by doing a basic math sum, but capabilities are more complex when you dive a bit deeper. What we should actually be doing is a bitwise operation on the binary value of the capability number.

Lets look at the capability value binary representation.

We can perform a bitwise operation on multiple capability values to get a new capability value. What happens when we have “Co-management Enabled” (8193) and the “Compliance” (2) workload moved to Intune?

10000000000001 -bor 00000000000010 = 10000000000011

If we look at the bitwise calculation below, we are actually returning 1 when either one or both bits, in each corresponding column, equals 1

10000000000001
00000000000010
10000000000011 = 8195

PowerShell

My colleague Cody Mathis (brilliant brain) had previously written some neat code to work out the combined capability values using bitwise operations. Combining capabilities with the -bor operator and comparing them with the -band operator to convert Co-management workloads from and to their text representations. Take a look at his work script at CM-Ramblings/Convert-CoManagementWorkload.ps1 at master · CodyMathis123/CM-Ramblings · GitHub

What prompted me to re-think capabilities again was when I saw a tweet from Loan Popovici @MEM.Zone on Twitter

I had not considered using flags with enum definitions before with PowerShell. It actually makes the PowerShell much simpler. Lets take a look

[flags()] Enum workloads {
        CoMgmt_Enabled = 8193
        Compliance_Policies = 2
        Resource_Access_Policies = 4
        Device_Configuration = 8
        Windows_Update_Policies = 16
        Client_Apps = 64
        Office_Click2Run_Apps = 128
        Endpoint_Protection = 4128
    }

And we throw a capability value in

[workloads]8195

This is cool.

Functions

I put together a function that allows you to pass single or multiple capability values to see the workloads

Function Get-Workload {
    [CmdletBinding()]
    Param(
        [Parameter(Position = 0, Mandatory = $true)]
        [ValidateRange(1,12543)]
        [Int32[]]$capability
    )

    #Create enumurator for workload flags // ConfigMgr 2111+
    [flags()] Enum workloads {
        CoMgmt_Enabled = 8193
        Compliance_Policies = 2
        Resource_Access_Policies = 4
        Device_Configuration = 8
        Windows_Update_Policies = 16
        Client_Apps = 64
        Office_Click2Run_Apps = 128
        Endpoint_Protection = 4128
    }

    #Create an ordered hash table to capture all capabilities
    $allCapabilities = [Ordered]@{}

    ForEach ($capNum in $capability) {

        #Evaluate capabilities 
        If ($capNum -eq 1) {
            $capResult = @("CoMgmt_Disabled")

            #Build hash table of results
            $allCapabilities.Add([string]$capNum, $capResult)
        }
        elseIf ($capNum -eq 8193) {
            $capResult = @("CoMgmt_Enabled_NoWorkloads")

            #Build hash table of results
            $allCapabilities.Add([string]$capNum, $capResult)
        }
        elseIf ($capNum -lt 8193) {
            $capResult = @("Invalid_Workload_Value")

            #Build hash table of results
            $allCapabilities.Add([string]$capNum, $capResult)
        }
        else {
            Try {
                $workload = [workloads]$capNum

                #Build data if a valid flag is matched
                If ($workload -like "*_*") {
              
                    #Filter out CoMgmt_Enabled value - we assume it is enabled if we have a workload match
                    $capabilities = $workload -split ', ' -notmatch 'CoMgmt_Enabled'

                    #Tidy up and export capabilities sorted to an array
                    $capabilities = $capabilities | Sort-Object
                    $capResult = @($capabilities)

                    #Build hash table of results
                    $allCapabilities.Add([string]$capNum, $capResult)
                }
            }
            Catch {
                #Do Nothing, ignore invalid values
            }
        }
    }
    Return $allCapabilities
}

With the values sorted as an array in the hash table, we can throw this out as a JSON for giggle

It got me thinking. Thinking big. Lets use a similar function to generate ALL the possible workloads combinations.

ConfigMgr 2111+ Capability Values

A similar function will export all possible workloads

Function Get-AllWorkloads {
    
    #Create enumurator for workload flags // ConfigMgr 2111+
    [flags()] Enum allWorkloads {
        CoMgmt_Enabled = 8193
        Compliance_Policies = 2
        Resource_Access_Policies = 4
        Device_Configuration = 8
        Windows_Update_Policies = 16
        Client_Apps = 64
        Office_Click2Run_Apps = 128
        Endpoint_Protection = 4128
    }

    #Create an ordered hash table to capture all capabilities
    $allCapabilities = [Ordered]@{}

    8195..12543 | Foreach-Object {

        $capNum = [string]$_

        #Evaluate capabilities s
        Try {
            $workload = [allWorkloads]$capNum

            #Build data if a valid flag is matched
            If ($workload -like "*_*") {
              
                #Filter out CoMgmt_Enabled value - we assume it is enabled if we have a workload match
                $capabilities = $workload -split ', ' -notmatch 'CoMgmt_Enabled'

                #Tidy up and export capabilities sorted to an array
                $capabilities = $capabilities | Sort-Object
                $capResult = @($capabilities)

                #Build hash table of results
                $allCapabilities.Add($capNum, $capResult)
            }
        }
        Catch {
            #Do Nothing, ignore invalid values
        }
    }
    Return $allCapabilities
}

This is cool. Let’s throw that into a JSON

{
  "8195": [
    "Compliance_Policies"
  ],
  "8197": [
    "Resource_Access_Policies"
  ],
  "8199": [
    "Compliance_Policies",
    "Resource_Access_Policies"
  ],
  "8201": [
    "Device_Configuration"
  ],
  "8203": [
    "Compliance_Policies",
    "Device_Configuration"
  ],
  "8205": [
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8207": [
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8209": [
    "Windows_Update_Policies"
  ],
  "8211": [
    "Compliance_Policies",
    "Windows_Update_Policies"
  ],
  "8213": [
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8215": [
    "Compliance_Policies",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8217": [
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8219": [
    "Compliance_Policies",
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8221": [
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8223": [
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8257": [
    "Client_Apps"
  ],
  "8259": [
    "Client_Apps",
    "Compliance_Policies"
  ],
  "8261": [
    "Client_Apps",
    "Resource_Access_Policies"
  ],
  "8263": [
    "Client_Apps",
    "Compliance_Policies",
    "Resource_Access_Policies"
  ],
  "8265": [
    "Client_Apps",
    "Device_Configuration"
  ],
  "8267": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration"
  ],
  "8269": [
    "Client_Apps",
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8271": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8273": [
    "Client_Apps",
    "Windows_Update_Policies"
  ],
  "8275": [
    "Client_Apps",
    "Compliance_Policies",
    "Windows_Update_Policies"
  ],
  "8277": [
    "Client_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8279": [
    "Client_Apps",
    "Compliance_Policies",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8281": [
    "Client_Apps",
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8283": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8285": [
    "Client_Apps",
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8287": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8321": [
    "Office_Click2Run_Apps"
  ],
  "8323": [
    "Compliance_Policies",
    "Office_Click2Run_Apps"
  ],
  "8325": [
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8327": [
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8329": [
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8331": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8333": [
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8335": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8337": [
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8339": [
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8341": [
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8343": [
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8345": [
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8347": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8349": [
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8351": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8385": [
    "Client_Apps",
    "Office_Click2Run_Apps"
  ],
  "8387": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps"
  ],
  "8389": [
    "Client_Apps",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8391": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8393": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8395": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8397": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8399": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8401": [
    "Client_Apps",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8403": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8405": [
    "Client_Apps",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8407": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8409": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8411": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8413": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8415": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12321": [
    "Endpoint_Protection"
  ],
  "12323": [
    "Compliance_Policies",
    "Endpoint_Protection"
  ],
  "12325": [
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12327": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12329": [
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12331": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12333": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12335": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12337": [
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12339": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12341": [
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12343": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12345": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12347": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12349": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12351": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12385": [
    "Client_Apps",
    "Endpoint_Protection"
  ],
  "12387": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection"
  ],
  "12389": [
    "Client_Apps",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12391": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12393": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12395": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12397": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12399": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12401": [
    "Client_Apps",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12403": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12405": [
    "Client_Apps",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12407": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12409": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12411": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12413": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12415": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12449": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12451": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12453": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12455": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12457": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12459": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12461": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12463": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12465": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12467": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12469": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12471": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12473": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12475": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12477": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12479": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12513": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12515": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12517": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12519": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12521": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12523": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12525": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12527": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12529": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12531": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12533": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12535": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12537": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12539": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12541": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12543": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ]
}

What Next?

The reason I created functions for this is because I am playing. I have never built my own API before and this dataset gives me the perfect excuse to go learn API’s. Over the coming weeks/months I intend to blog on my journey to create an API so we can display the workloads in a browser using a simple URL GET method. Fun times ahead

Summary

In this post I reminisced the journey from on-premises to the cloud and re-visited a favorite topic of mine – Co-management. I always wanted to re-create a table of the new Co-management capabilities like i did back in 2019 but instead of building a table – we automated it.

I hope the JSON is useful

Special thanks and credit to Loan Popovici for the inspiration and my colleague Adam Cook for helping with hash tables

(10)

The post Moving to the Cloud. Co-management workloads and capabilities (revisited) appeared first on MSEndpointMgr.

As the world becomes increasingly digital, the need for secure access to online accounts and systems becomes more critical than ever. One of the most effective ways to protect against unauthorised access is through the use of multi-factor authentication (MFA). In this article, we will explore the importance of MFA in the Microsoft Cloud and how it can help protect your organisations sensitive data and systems.

Introduction

Outline: For those who are unfamiliar with what a phishing attack is, it is where an attacker attempts to fraudulently obtain sensitive information from a user by posing as someone or something that the person/organisation trusts. Phishing attacks target passwords and usernames via various methods including email, pop-up windows, instant message, text messages, and social network sites. It ruins lives and cost companies millions of dollars each month. One of the best ways to protect against phishing attacks is through the use of MFA.

Takeaway: Use MFA or Passwordless. And do not click on links in unexpected emails from people you do or do not know. Always be suspicious of any link that requests you to enter your login credentials for an unknown site and be sure that a familiar sign-in page is using the right domain name in the address bar.

Disclaimer: There are a plethora of ways to put together MFA now a days, and not all scenarios or methods are covered in this article for the sake of readability.

What is multi-factor authentication?

Multi-factor authentication (MFA) is a process of verifying your identity by using more than one form of identification. It can be as simple or as complicated as you want it to be, but the goal is always the same: to make sure that only you can access your account.

There are three main types of MFA: SMS-based, app-based and hardware-based. Each type has its own advantages and disadvantages when compared with other methods, so let’s take a look at each one individually:

SMS-based MFA

This is the most basic form of two-factor authentication. When you enable it, you’ll receive a text message with a PIN code every time you log in to your account. You must enter this PIN into the site or app before gaining access to your account.

The benefit of SMS-based MFA is that it’s very easy to set up. You don’t need any special hardware or software, just a phone number and access to your email account. The downside is that there are often security issues with SMS messages—they can be intercepted by hackers or spoofed by scam artists who want to take over your account. If this happens, you’ll have no way to prove who you are without resetting all of your passwords.

App-based MFA

App-based MFA is similar to SMS-based MFA, but instead of receiving a code via text message, you receive it through an app on your phone. For Microsoft 365 users the best app is the Microsoft Authenticator, which can be downloaded for free from the Apple App Store or Google Play Store. Once you install it, all you need to do is scan a QR code using the app and then enter the six-digit code into the set up wizard. The benefit of app-based MFA is that it’s more secure than SMS-based MFA because the authentication process is tied to your physical device and not sent unencrypted over the airwaves.

The downside is that it’s more difficult to set up. You need to install an app on your phone and then scan a QR code using that app, which can be tricky if you’re not tech savvy.

Hardware-based MFA

The most secure way to set up Multi-factor authentication is with a hardware token. This device can look like a USB flash drive, but instead of containing files, it contains a secure chip that generates one-time passwords (OTPs). When you install the software on your computer and plug in the hardware token, you’ll be prompted to enter your username and password before it will generate any codes for you. This is a solution often used in companies where employees don’t have access to a phone, and hence they are unable to use SMS or App.

The benefit of hardware-based MFA is that it’s more secure than any other method of two-factor MFA authentication. The downside is that it’s more expensive and difficult to set up. You need to purchase the device and then install software on your computer that works with the token—something most people don’t have the time or inclination to do.

Again, why is multi-factor authentication so important?

Multi-factor authentication is a way to protect your accounts from being hacked by using more than one method of verification. It’s important to have this on all of your accounts because it works as an extra layer of security that prevents unauthorised access to your account and prevents identity theft.

Being passive about this type of security can actually leave you open to lawsuits. If your identity and the trust that others have in it, is used to commit fraud against others, then you are most likely going to be liable for the damages. These lawsuits have already happened and they are not in your favour if you as a person or as a company have been passive.

What has MFA done for the world?

MFA has reduced the amount of fraudulent sign-ins on accounts since its inception. In fact, MFA provides an added layer of security that gives users (and admins) peace of mind when it comes to their corporate/personal information and financial data.

MFA has:

• Reduced risk of account takeover
• Reduced risk of phishing attacks and identity theft
• Reduced risks associated with password reuse by requiring two-factor authentication every time you log in (even if you’re using a password manager)

Remember to thank your MFA device when you use it.

What is better than MFA?

A concept that is quickly gaining in popularity is the Passwordless sign-in. Which is the next step in authentication evolution. It is basically a method to login without a password, and thus prevents anyone from stealing it in the first place!

Microsoft offers easy on-boarding to Passwordless with their Authenticator Phone sign-in feature and for the Windows desktop they have Windows Hello for Business as an excellent offering.

Passwordless technologies aim to address some of the weaknesses of MFA. But, remember that any MFA solutions is better than no MFA solution!

But, I digress, this article was only meant to be about Multi-factor authentication (MFA). So, Follow along here on the blog for an article on passwordless in the near future!

In the mean time you can enjoy learning how to enable Passwordless using the Microsoft Authenticator, in this article on Microsoft Learn.

Conclusion

Multi-factor authentication is an essential tool for protecting against unauthorised access to online accounts and systems. By using a combination of something you know, something you have, and something you are, MFA provides an extra layer of security that makes it much more difficult for cybercriminals to gain access to your sensitive data and systems.

If you want to learn more about how MFA can protect your business, check out the article on Microsoft Learn that shows how you can get started on this important first step on your journey towards Zero-Trust and a Passwordless future!

(6)

The post 2FA/MFA – Why multi-factor authentication is important appeared first on MSEndpointMgr.

Importance of BitLocker

While we often speak of cyber security in terms of access to privileged accounts and our organization’s systems, there is another piece of the security puzzle that is just as important. Keeping physical devices safe deserves the same level of attention. Important company data is often stored on users’ laptops (whether it should be or not). With the amount of work travel that takes place, some devices are bound to get lost or stolen. The last thing any organization wants is the CEO’s laptop out in the wild unencrypted with confidential data ready for the taking. Enter Bitlocker, a tool that exists to keep that data safe when a device gets lost or stolen.

In a blog series on this site, Maurice Daly covered the topic of migrating away from standalone MBAM (Microsoft BitLocker Administration and Monitoring) to ConfigMgr BitLocker Management. Thankfully, Bitlocker management within ConfigMgr can be greatly simplified by using Right Click Tools. Whether you need a web-based report to pass over to security, a full view of how many of your devices are encrypted, or a simple way to retrieve a recovery key to get your end user back up and running, Right Click Tools streamlines your Bitlocker management within ConfigMgr.  

How Right Click Tools Helps

Whether you are just getting started with your BitLocker rollout or have Bitlocker fully implemented and only need to ensure all your devices are remaining properly encrypted, Right Click Tools can assist. The BitLocker Compliance Dashboard within Right Click Tools serves as a great resource to understand where your environment is sitting in terms of encryption. The dashboard gives you graphical overviews of recovery key storage (AD, CM BLM, MBAM, all locations, or the dreaded no keys stored), as well as unified compliance. You can click into any piece of the pie to see the endpoints that fall under that category. This will also uncover some more information about the devices including the encryption method used on the device. Knowing all this information is great, but the fully actionable dashboard makes it powerful. If you find any gaps, you can quickly act right away without needing to leave your ConfigMgr console.

The BitLocker Compliance Dashboard isn’t the only way Right Click Tools helps with BitLocker in your ConfigMgr console. If you need to quickly pull a BitLocker recovery key for a device, you can easily right click a device to access Right Click Tools, open security tools, and retrieve that device’s recovery key.

If you are looking to check up on the BitLocker compliance of a specific device, the Remote Windows Security Tool is the perfect place to get all the information you need in one place. From Remote Windows Security, users can gain insight into the drive with information on its protection status, the encryption method currently in use, and the key protectors currently active for that drive. Users can also take action right from within this tool. So, if organizations happen to find that the drive is not currently encrypted, they can take care of it right away.

As alluded to previously, the Right Click Tools Bitlocker Compliance Dashboard can also generate web-based reports to send over to security or management. Anybody who needs to see the compliance levels without accessing the ConfigMgr environment will find these reports helpful. Running a Recast Management Server (RMS), which is included with your Right Click Tools Enterprise License, gives users the ability to pass along web-based reports (including BitLocker compliance). Organizations can then keep the appropriate people up to date on compliance levels without having to worry about them entering directly into the ConfigMgr environment.

Bitlocker Streamlined

The BitLocker Compliance Tool dashboard is designed to get users quick information about BitLocker in their environment. It also enables users to quickly take action to remediate issues that they may find.

Let Recast know if you have any questions, or if you think the BitLocker Compliance Tool dashboard could help you. Reach out here.

(1)

The post How to Streamline BitLocker Management in ConfigMgr appeared first on MSEndpointMgr.

Introducing the MSEndpoingmgr Intune Audit Dashboard, a KQL workbook to make your life a little bit easier when it comes to auditing events in your Intune environment.

Auditing Events You Say…

Auditing, love it or hate it, provides an integral part of your infrastructure when it comes to the who, where, and why of what is going on. I’m sure many of you will have examples over the years where a colleague or an external consultant has changed something in your environment, resulting in something, somewhere going bang. On the flip side I know I have used these logs to prove it wasn’t me, so they can be your saving grace right when you need them.

Intune Audit Logs

Traditionally though audit logs are often overlooked, or when you go to use them, you might find that they appear to be difficult to work with. When it comes to Intune, we find the audit logs in the “Tenant administration” blade, and when we start to filter the actions, we can quickly see that for some admins the poses a challenge.

Which event should I search for? Which object ID was targeted? Unless you are using these logs regularly it came be less than intuitive at times to find that smoking gun. This is the kind of feedback we hear, and we wanted to do something about it.

First things first though..

Diagnostic Settings / Log Analytics

When setting up a tenant, the first thing I would always do is enable the diagnostic settings. The reason for this is simple, I want to have the logs available in a format that I can interrogate easily, and also control the retention of data within.

If you are not sure of where this is done, it is simple (please note you do need an Azure subscription and at least contributor rights to a log analytics workspace);

• Log into the Intune Admin Portal (yes, I am just calling it this from here on!) – https://endpoint.microsoft.com
• Click on “Tenant administration”
• Click on “Diagnostic settings”
• Clik on “Edit Settings”
• Select the logs you wish to send to Log Analytics;

• Click on “Send to Log Analytics workspace”
• Select the Subscription and Log Analytics workspace
• Click on “Save”

Once this is done you will start to see entries forming in the following Log Analytics workspace tables;

• IntuneDevices
• IntuneOperational Logs
• IntuneDeviceComplianceOrg
• IntuneAuditLogs

For the next part of this post, we are going to focus just on the IntuneAuditLogs and IntuneDevices tables, as they will be used to generate a reporting dashboard.

KQL FTW (Yes, Again)

You probably know that we are big fans of KQL, so I won’t bore you with the selling you the why, how, or where, but what I will do is to tell you, you need to start using this. Think of KQL as the new PowerShell, it helps you find and report on data quickly and efficiently.

Looking into the IntuneAudtLogs, we have a wealth of information, where we can quickly search and start to build up a picture about admin actions. This is great if you are familiar with KQL and writing queries, but we wanted to make this easy for you.

This is exactly what we have done, in the form of a KQL workbook that you can drop into your environment. Let us take a look at the latest in our workbook line;

Intune Audit Dashboard

The dashboard is broken up into several key areas;

• Summary
  The summary page gives you information such as the split of tasks and methods being undertaken by your admins, along with useful stats and trends
  

• Device Targeted Actions
  This page provides you with an overview of actions impacting on devices, such as wipe, reset, delete etc. Scrolling down you also see the following details;
  • Time Generated
  • Actioned By
  • Operation
  • Device Name
  • Device Id
  • Result
  • Management Type
  • OS
  • OS Version

• Target Actions
  On this page you will allow you to select actioned based on changes to policies, configurations etc

• Admin Actions
  Filter based on the actions of a particular admin

• Application Actions
  Filter based on the actions of a delegated application

• Detailed Audit Log
  The full detail of everything

More Details Please

Within the “Target Actions” and “Admin Actions” pages you will also see links to display additional information about the change event, such as in the example below;

Where audit events contain changes to profiles for example, the slide in workbook will also display the change details, comparing old against new values;

Workbook Source & Installation

The JSON source code for the main Intune Audit is available on our GitHub repo. During installation of the workbook, you will need to update elements within the JSON, or via the UI editor to display your information.

Intune Audit Dashboard – Main JSON – Reporting/IntuneAuditDashboard.json at main · MSEndpointMgr/Reporting (github.com)

• At lines 781 and 1801 where you see “%YourDomainHere%” replace that with your domain, i.e. MSEndpointMgr.
• At line 174 replace “%YourLogAnalyticsWorkspaceHere%” with the name of your Log Analytics workspace
• At line 7 replace the “%YourURLHere%” with the URL of your company logo

Intune Audit Details Dashboard – Details JSON – Reporting/IntuneAuditEventDetails.json at main · MSEndpointMgr/Reporting (github.com)

Conclusion

Through the use of Log Analytics and KQL, auditing doesn’t have to be a pain anymore, and if you have any suggestions on how we could extend this workbook, please let us know!

Please note that we will also be creating a solutions page soon with links to all of our KQL workbooks! Keep a lookout in the solutions section of the site.

(10)

The post MSEndpointMgr Intune Audit Dashboard appeared first on MSEndpointMgr.

Hi there! I am new to the MSEndpointMgr team and thrilled to be here!

In this blog post, we will look into Logic Apps and how we can achieve a governance-free model to how we can utilize this kind of low/no code technology and get the results that we want.
I have blogged about the subject earlier – how to e.g. get configuration changes made to Microsoft Intune. If you are interested you can read about that here.

What more is there to write? Well for starters Logic Apps are easy to work with if you use the built-in functionality, but what if you would like to be creative and draw outside the lines? You then enter a state where stuff can be complex and not very user-friendly as low/no code was built to be.

In this blog post, we will draw outside the lines. Why you may ask? Because Logic apps and their object typically have connectors into different services. These connectors either use your credentials or a service principle. Nothing wrong with that, but what if the user who build it, is no longer in your company? Yes, then the connectors used by your colleague will at some point not work anymore.
Your result will look like this and be published daily on your Teams channel.

How to get started

First we need to create a logic app. I will not demonstrate it here. It is straight forward and also demonstrated in the link provided in the top.

Go to your logic app and find Identity. Switch the tab to On and save it. A minute or two later a managed identity will be available to be used within the azure environment.

We will use our managed identity to access data in log analytics, so what we need is to assign the managed identity as a reader on the specific log analytics workspace where your Intune audit data is located. If you haven’t set up your Intune audit data yet, then follow this post on how to do so.

I am assuming you know how to locate your log analytics, and where to click to get started setting permissions on it.

Then we need to copy our code to the Logic App we created. Open your logic app

If you haven’t setup a Teams hook already, then here is a guide to do that.

1. copy the code from here
2. Paste it into the logic app
3. Replace in line 112 where it says a32a07c5-739b-40ce-9b3f-185733d5c0d0 and add your own Log Analytics workspace ID
4. Replace in line 225 where it says https://memtipsandtricks.webhook.office.com/webhookb2/d20c5efe-2f76-4897-8c90-2de8c0f76397@47a13e20-6415-4467-bfd3-b2acf62a3ed2/IncomingWebhook/ and add your own Teams hook
5. Save it

You will never ever have any surprises of changes in your Intune environment and neither will your colleagues.

(12)

The post Running logic apps without the need of governance appeared first on MSEndpointMgr.

If you have ever having issues with Autopilot or Enrollment Status page failing or timing out due to issues with Office installation, this blog post is for you. Over the years working in this area, the Office CSP has caused countless issues and deployments to fail. The Office CSP, commonly knows as the the built-in “Microsoft 365 Apps for Windows 10 and later” is actually not an app distribution in Intune. It is just a configuration policy. That means we are missing out on some of the normal app distribution features like requirements, dependencies and detection rules. The configuration policy tells Windows to download the Office Deployment Toolkit (ODT) and starts setup.exe with the configuration you provided either as XML or in the user interface.

With that in mind, I started looking into using Win32Apps in Intune for deploying the M365 Apps in a more controlled matter. Downloaded the ODT manually, created and XML file before finally packaged everything up as a Win32App and tested deployment. The Win32App package or IntuneWim file contained the content of ODT together with an XML file. This worked out really nice. The Office applications installed really fast and it was RELIABLE.

The issue with the “full” package”

Even though the metode above is a valid option, it is not dynamic enough. As there is a dependency between the ODT and the version of Office being deployed, the Win32App needs to be maintained over time by downloading a fresh ODT from time to time and update the package manually. There was also a request from customers using this to have some additional logging related to the installation for troubleshooting. So how can this be made super-dynamic and self-updating? In comes PowerShell.

The scripted way

All the issues with the “full” package could be solved using PowerShell as a wrapper to the installation. The install PowerShell script is doing the following:

1. A logging function takes care of the additional logging to a local file.
2. The script downloads the latest ODT direct from Microsoft every time
3. ODT is extracted to a temporary setup folder
4. The config.xml file is written to the same setup folder
5. Starting setup.exe with the config file to download and install according to your XML file.

In addition to this there is the detection scripts. This allows us to detect that whatever Office version or App we are installing is detected on the machine when installation is completed. Currently the provided script is checking if “any” x64 bit version is installed. This is to avoid issues with preinstalled M365 Apps on the machine or existing environments where office has been deployed the traditional way before. Updates of these apps should be handled by policies by Intune and not by deploying a newer version.

What is provided

In the Github repository containing this solution you willl find scripts and configurations files to handle the following:

• Installing M365 Apps
• Installing Visio
• Installing Project
• Installing or Uninstalling Proofing tools

The recommendation is to install only M365 Apps with a single language as required and then have these other options as available apps. If users needs Visio or a different proofing language, they should find then in Company Portal and install them,

You can find all the scripts and a more information on how to use this on GitHub: https://github.com/MSEndpointMgr/M365Apps

(2)

The post Installing M365 Apps as Win32 App in Intune appeared first on MSEndpointMgr.

Back in July last year we released a community version of our Windows Update Compliance dashboard, a KQL driven workbook that helped you visualise Microsoft Update Compliance data. Since then there have been a number of improvements both in the type of data and a version 2 schema update.

The good news is we have a new workbook for you, but some light reading first as to some of the changes at Microsoft’s end;

Microsoft Update Compliance Onboarding Change

Back on August 17th Microsoft also made a change to the onboarding process for Update Compliance, moving the onboarding out to the Microsoft 365 Administrative Center. The new onboarding process is straight forward, where we simply select the Azure subscription and log analytics workspace to be used for storage of your UC logs;

Personally I’m not quite convinced by the location of this onboarding experience at present, as I would prefer to see this in the Endpoint Manager Admin Center

This new onboarding process removes the requirement to push out a commercial ID, something which many admins have had frustration over due to the fact they still need to publish this value through OMA-URI in order to support Windows Pro licensed machines. This was due to the ADMX backed settings catalog policy only being applicable to Enterprise and Education editions.

Microsoft’s Own Native Workbook

Something that we also saw appear with the new onboarding experience, was an Update Compliance workbook from Microsoft. Located in the Monitor | Workbooks section of the Azure portal UI, the workbook offers quick oversights as to the health of your devices;

Its great to see Microsoft is committing to this format of report delivery, as this can only serve to benefit everyone in the community!

Windows Update Compliance Dashboard V8.0

Taking onboard all of the changes since our last community edition, along with elements that we have been adding working with clients, @jankeskanke, @sandy_tsang, and I are proud to release version 8.0 of the Windows Update Compliance Dashboard.

The dashboard has been massively overhauled to display items such as;

• Trending update compliance over time
• Windows Update for Business issues
• Feature update trends
• Delivery optimization details
• Windows 11 readiness
• Third-party application information

Below I am going to step through the individual tabs and elements of the dashboard, please note that in some cases some of the reports are not only dependent on the Update Compliance logs, but also leverage the Intune diagnostic logs, and custom hardware and application inventory logs gathered through PowerShell / ingested through a function app (Securing Intune Enhanced Inventory with Azure Function – MSEndpointMgr).

Please Note: Hardware and application inventory scripts are not provided as part of the community solution. Reporting UI elements requiring those features will be hidden where the logs are not present in your tenant. If you wish to avail of these additional enhancements, please contact CloudWay for more details.

Summary Page

The summary page is designed to offer you a at a glance overview of your entire environment. At the top right of the page the Microsoft log timestamps are displayed, Logs older than 3 days old will be highlighted with a service issue alert, otherwise they are considered to be up to date;

The quality update patch trend shows you devices which are fully patched, pending patches, or missing multiple patches. As you can see from the screenshot below, the trend will show a decline in compliance once per month (patch Tuesday) and an improvement in compliance as per your defined update rings;

The next graph shows compliance against particular KB updates over time, where you will see declining KB installations over time due to CU rollouts and supersedence;

The next set of graphs show you items such as patch installation states, compliance states, client activity, current Windows builds, and target builds;

On the left side of the summary tab you can see key information about devices showing in the UC logs, issues being reported from Windows Update for Business for those devices, and optionally information on restart activity from those devices.

Quality Update History

The quality update history tab provides you with a 0-30, 60-90, 90+ day approach to reporting on induvial KB compliance. This tab has been updated to now include links to the individual KB’s, so anyone reviewing the dashboard can get a quick overview of the security issues being resolved;

Quality Update Deployment – By Device

On this tab, the admin can get a full overview of updates being applied to specific devices, by default though it will show all devices;

Quality Update Deployment – By Update

On this tab, just like you had the ability to filter based on a specific device on the previous tab, here you can filter based on the individual updates, selecting multiple, one or all;

Update Issues

On this tab all blocking issues, including information such as updates pending restarts, compatibility issues, and safeguard holds are displayed;

Delivery Optimization

Knowing if your clients are using DO correctly is vital, on this tab you can see an overview of your DO state, with a ranked notification advising you if your DO states are Optimal, Good, Poor, or Bad. For those of you with custom hardware logs, you can also see DO traffic per subnet;

Feature Updates

On the feature update tab, you can see wealth of information showing the progress of your devices moving to new builds, overall counts per build, and with custom hardware reports available you can also see a breakdown of manufacturers and models per Windows build;

Windows 11 Readiness

This self explanatory tab provides you with an overview on how many devices in your estate are capable of running Microsoft’s latest client OS;

Microsoft Office, Edge & Third Party

Finally on the last tab we have information on applications within your environment. Please note that information on this tab requires custom application collection.

We are currently looking to integrate this tab with third party solution feeds from vendors such as Patch My PC and Scappman.

The Workbook

Want to use this workbook in your environment? No problem. Its available on our GitHub here – Reporting/UpdateComplianceV8.json at main · MSEndpointMgr/Reporting (github.com)

Conclusion

One of the main complaints from those coming from a Configuration Manager background is around reporting. Its a fair point, however, utilising several sources such as Intune, Update Compliance, and going custom, you can provide high quality dashboards. More to come on the blog soon…

(15)

The post Windows Update Compliance Dashboard V8.0 appeared first on MSEndpointMgr.

Manage Windows Hello for Business (WHfB) with Intune is very “easy”, you have so many options:

• At device enrollment: Tenant-wide policy
• After device enrollment, at least four methods:
  • Endpoint Security > Account protection (Preview)
  • Configuration profiles > Identity protection
  • Settings catalog
  • Custom OMA-URI

So which methods should we use? What if you have different scenarios that have additional requirements?

For example:

• Multiple users use the same device, but only some users should be using WHfB
• Only allow WHfB for some devices
• Different WHfB requirements for users

I hope you can find your answers after reading this post.

At device enrollment – Tenant-wide policy

Tenant-wide policy targets your entire organization and supports Windows Autopilot. This should be the perfect choice if you plan to enable or disable WHfB for your entire organization with the same WHfB configuration. The tenant-wide policy applied at device enrollment, it applied to the device for each user who login.

The tenant-wide policy has three options:

• Enabled. Select this setting if you want to configure Windows Hello for Business settings. When you select Enabled, other settings for Windows Hello are visible and can be configured for devices.
• Disabled. If you don’t want to enable Windows Hello for Business during device enrollment, select this option. When disabled, users can’t provision Windows Hello for Business. When set to Disabled, you can still configure the subsequent settings for Windows Hello for Business even though this policy won’t enable Windows Hello for Business.
• Not configured. Select this setting if you don’t want to use Intune to control Windows Hello for Business settings. Any existing Windows Hello for Business settings on 10/11 devices isn’t changed. All other settings on the pane are unavailable.

Which one should you use?

• If you have decided entire organization will use WHfB with the same configuration, choose “Enabled”
• If you have decided the entire organization will NOT use WHfB, choose “Disabled”.
  NOTE: When you use the “Disabled”, all other WHfB configurations will still apply, like Minimum PIN length is 4, Maximum PIN length 127, it just won’t allow you to enable Hello. So if you deploy another WHfB policy to devices, and if you configure different requirements example Minimum PIN length is 6, Maximum PIN length is 16, it will cause conflict and you will have unexpected behaviors, sometimes WHfB is unavailable, sometimes works.

• If you have multiple scenarios and usage cases of WHfB, choose “Not configured”

After device enrollment

Let’s assume you have configured tenant-wide policy as “Not configured” because you have multiple scenarios that require different WHfB configurations. As I mentioned before, at least four Intune methods allow you to manage WHfB. In my opinion, Account protection (Preview) and Settings catalog both are good options. Both have nice UI and allow you to configure all the necessary settings.

Account protection (Preview)

You will find Account protection (Preview) under Endpoint security

The policy itself worked as expected. I have tested assigning one policy to a device group and another policy to a user group.

• When policy is assigned to a device group, all users get prompt to configure WHfB at first-time log on to the device
• When policy is assigned to a user group (without policy assigned to the device), the targeted user didn’t get WHfB prompt at first log on, which is expected. After WHfB policy is synced, the targeted user gets WHfB prompt when log on to the device. Untargeted user will never get or allow to configure WHfB, if there is no other WHfB policy assigned to the device.

WHfB configuration worked, but however, reporting is missing some devices when the policy is assigned to users group.

My user account sandy@smsboot.com is logined to three devices, MVP24-001, MVP24-002 and MVP006, I confirmed WHfB is applied to all these three virtual machines for my user account. But as you can see in the report, it only shows all the devices that have sandy@smsboot.com as the primary user, but not the other two devices with different primary users or without a primary user.

Settings catalog

Settings catalog allows you to configure WHfB settings for devices or/and users. See details in PassportForWork CSP – Windows Client Management | Microsoft Docs

I configured a few settings with the settings catalog and deployed them to a user group. The result is good. WHfB settings are applied to my targeted user who login to those three virtual machines. I confirmed it from all those three virtual machines.

Let’s take a look at the settings catalog reports.

Device assignment status report. Same issue as Account Protection (preview). It only shows all the devices that have sandy@smsboot.com as the primary user, but not the other two devices with different primary users or without a primary user.

Per setting status report. This looks better, and it did show three records per setting name.

The device and user check-in status report looks good, it also shows 3 Succeeded, and the real-time report (View report) shows all the devices I was looking for. I am happy with this report.

Summarize

After all these tests, as for this moment, I will use the following:

• Tenant-wide policy set to “Not configured”
• Create a device group to allow WHfB
• Use the settings catalog to deploy the WHfB device configuration to the device group
• Create a user group to allow WHfB (if needed)
• Use settings catalog to deploy WHfB user configuration to the user group (if needed)

Device configuration will be my first choice because it applies to all users’ devices. Users will be prompted to set up WHfB immediately when they first-time log on to the device, doesn’t need to wait for the user policy to sync and then log on again. But of course, if you have scenarios that require different settings for different users, then you will need to use WHfB user configuration, be patient, allow policy sync, and apply user policy.

Hope this post will help your password-less journey.

Feature image is from Hello Greeting on Brown Board · Free Stock Photo (pexels.com)

(21)

The post Manage Windows Hello for Business (WHfB) with Intune appeared first on MSEndpointMgr.

In this blog post we cover the unusual characteristics of the Intel Optane drive, and how we need to approach task sequence builds to ensure we do not hit an unforeseen issue when it comes to in-place upgrades later in the device lifecycle.

Intel Optane Technology

Unveiled back in 2017, Intel’s Optane solution is a memory module that provides a burst of high speed data throughput using a new memory technology called 3D XPoint. Using built-in intelligent algorithms the solution works by keeping the data you use most frequently in the higher speed cache, reducing loading time and improving overall system performance.

More information on the specifics can be found on Intel’s site – Information about the Intel® Optane Memory M Series

Cache Disk Configuration

The cache disk is typically delivered in one of two flavours, these being a 16GB and 32GB, and this is where we can start to run into issues. The issue stems from the fact you need to run a utility to enable the cache association prior to running through your standard formatting and OS deployment, without doing this, the drive will be seen by your OS and this sets the scene for something very strange.

The utility in question is the Intel RST Configuration Utility (RstCliPro.exe) and this is where OEM instructions on the use of this tool, and the required versions, get a little bit blurred. For example, HP have their own post on how you should use the RST utility as part of your task sequence (HP PCs – How to Configure an OSD Task Sequence to Deploy Intel Optane in SCCM | HP® Customer Support), but in my testing I found that the sequence of events contained within and the versioning of their tools / WinPE drivers also fall short of providing an optimal working task sequence.

In-Place Upgrade Issues

Whilst working on an in-place upgrade task sequence upgrade for a client, I found in this instance that the documentation from HP in this instance was used, exactly as described, with one key failure however.

During an in-place upgrade from 1909 to 21H2, something happened which I had not seen before. During the task sequence when a restart step was run post OS upgrade, the device would fail the task sequence. When looking at the SMSTS log and status messages, it stated the following;

When I started to investigate this issue, I started to look at the disk partitioning, and it suddenly became evident as to why this was the case. The cache drive was still seen to the OS and was seen as Disk 0

In the below screenshot you can see that the drive is visible to the OS;

Given that the cache drive was being seen as disk 0, this caused the unexpected behaviour. If the Intel RST configuration was successfully run during the initial build, the disk would not be visible to the OS.

Root Cause Issue

Following the documentation, the first thing we need to ensure is that we have two key components available in order to image a machine with this drive, these being;

• Intel RST WinPE Driver
• Intel RST Configuration Utility

Taking a HP Dragonfly Max for example, the documentation by that vendor states the following;

1. Go to the HP Software and Drivers page for your computer or download HP Image Assistant to obtain the Intel RST driver softpaq.
2. Extract and save RSTCLI64.exe to the SPXXXXX\bin\src\Tools\WinPE folder.
3. Copy the RSTCLI64.exe utility to a shared location on the SCCM server to use as a source folder for the package.

Doing this verbatim, we end up with the following file;

Packaging up this tool however is only the first step. We need to ensure that the tool is supported by the Intel RST controller driver in WinPE, otherwise we end up with a failure like the one pictured below;

When this occurs, the association is not completed, and the cache partition is not configured correctly. In this instance the continue on error flag was enabled and it resulted in the machine being deployed in an incorrect state, resulting in the task sequence upgrade failure pictured above.

Documentation Variations

As the OEM’s instructions were used in this instance, I started to look over Intel’s own documentation and found discrepancies in the guidelines being offered.

In HP’s documentation, the task sequence flows as per the below screenshot;

At the start of the TS where the Optane disk is detected, the following WMI filters are suggested;

Intel Optane Cache Drive
SELECT * FROM Win32_DiskDrive Where Index = “0” AND Size < 34359738368

Intel Non-Optane Drive
SELECT * FROM Win32_DiskDrive Where Index = “0” AND Size > 34359738368

In comparison to Intel’s documentation (Intel® Optane Memory System Acceleration Corporate Re-imaging Guide), the difference is that they are also filtering based on the model;

Intel Optane Cache Drive
SELECT * FROM Win32_DiskDrive Where Index = “0” AND Size < 300000000000 AND Model LIKE ‘%intel%’

SELECT * FROM Win32_DiskDrive Where Index = “1” AND Size < 300000000000 AND Model LIKE ‘%intel%’

In Intel’s own documentation it covers if the drive is detected both as disk 0 and disk 1, but it also refers to the Intel RST tool as RSTCliPro.exe, which HP’s documentation referencing at the start but changes to RSTCLI64.exe later in their post.

The sequence of enabling the Intel association also is different, ensuring that the OS is only layered down to the OS disk once the association has been completed. I much prefer this approach as it ensures that your pre-requisites are met before you format your disks in preparation for the OS being installed.

Putting It Together – Task Sequence Deployment

Intel RST Configuration Tool

In order to ensure that you have the most update to date configuration utility, you should use the latest version from your chosen vendor, alternatively you can download it direct from Intel’s website – Intel® Rapid Storage Technology Driver Installation Software with Intel® Optane Memory (10th and 11th Gen Platforms)

After you have extracted the RST tool, package it up in Configuration Manager, and distribute it to your imaging DPs

WinPE Drivers

The next step is to ensure you have the latest WinPE storage drivers in your boot image. Below are a list of common OEMs and their associated WinPE driver site;

Extract, import, and update your boot image;

Task Sequence Flow

With the pre-requisites in place, you should now edit your task sequence to use the Intel WMI filters as referenced above. My recommendation is to create a child task sequence for this element of your task sequence, as part of a pre-OS deployment phase;

Note in the above screenshot, I am using the latest version from Intel, but you can substitute the tool naming from your OEM.

WMI Filters Applied:

Running the tool interactively to ensure it is working, we should see something like the below;

Post Deployment

Post OS deployment you should no longer see the cache drive in disk manager;

At this point the Intel Optane cache drive is working as intended and you should have no longer have any issues during your in-place upgrade task sequence.

Conclusion

Intel Optane’s disk configuration is something that might catch you out, so if you have deployed these devices and did not perform the association, update your task sequences accordingly and re-image those devices.

I hope this post helps you!

(2)

The post Task Sequence Basics – Intel Optane Drives appeared first on MSEndpointMgr.

In this quick post we will be removing built-in Windows 11 apps, for all users, and optionally showing you how to leverage a “Cloud-Source” as a reference file to select apps for removal.

Introduction

Appx Provisioned Packages – the evolution

There are many great examples of how to remove built-in Windows apps. I have been using a script from my friend @nickolaja for a while and have modified it to reflect the additional built-in apps that appear in subsequent Windows 10 feature updates and also Windows 11.

Microsoft often include additional apps in each release of Windows, meaning admins need to update their appx removal scripts frequently. This is normally fine, but in environments that require all scripts to be signed – this can (and does) lead to frustration. “I can’t sign off this dev ticket today boss until Jessica returns from the Maldives next week”. It is unlikely that pending doom is invoked because Jessica was on leave, but you get my point.

Take me to the Maldives, I don’t care about script signing

A different way to introduce variables

I was chatting with @mauriced and @jankeskanke about this scenario and they, as always, had an interesting idea and perspective. What if we could change our script variables without having to re-sign the scripts each time…

Great Idea! In this post I will include a script to remove built-in apps from Windows 11, with the apps defined as an array within the script (the old fashioned way if you like). I will also share a version of the script where I will use a reference file hosted on GitHub to dynamically build the array of apps to remove. Your reference file could be hosted on Azure Blob or any other cloud storage provider. The reference file, a text file in this example, will allow me to dynamically update the list of apps I want to remove from my devices. Change my mind on what apps I want remove? I simply update the .txt file on GitHub – no need to re-sign or redistribute the script!

“Text file….Heresy! Use a JSON or XML!” I hear you cry. Well yes, fair point. You will see why I choose to use a .txt file later. It is really quick and simple to differentiate between which apps I want to remove and the apps I want to keep.

Scripts

Windows 11 App Removal Script

This script will remove built-in Windows 11 apps without using a Cloud source reference file. Instead, the apps to remove are explicitly defined in an array in the script.

Simply modify the $BlackListedApps array list to include the appx provisioned packages you want to remove from the device. The full list of packages can be found in the comment block at the beginning of the script.

Windows/Remove-Appx-AllUsers.ps1 at master · MSEndpointMgr/Windows (github.com)

Windows 11 App Removal Script (Using Cloud Sourced reference file)

This script will remove built-in Windows 11 apps with a Cloud source reference file. If the app has a # prefixed in the reference file then we remove that built-in app.

The script will reference the blacklist_w11.txt file in GitHub. Change this line to reflect the location of your reference file

Windows/Remove-Appx-AllUsers-CloudSourceList.ps1 at master · MSEndpointMgr/Windows (github.com)

Windows/blacklist_w11.txt at master · MSEndpointMgr/Windows (github.com)

Script Overview

When either of the scripts above are distributed and run, the apps are removed from the device for all users. If you run the script(s) interactively, you will see the progress of the app removal.

If you re-run the script after changing the reference file, the additional apps selected will be removed

The script(s) can either packaged as Win32apps and distributed to devices. Win32apps are great because you can leverage Filters to accurately target your different device builds quickly. Remember to run the script in the System context so all users on the device are targeted. The script can also be distributed using the Intune scripts feature – but you still need to rely on Dynamic Groups for targeting.

A log is generated under the system temp folder.

Care should be taken when removing appx provisioned packages – it is not as easy to restore them as it is to remove them

Summary

Remember, Appx Packages are installed in the User profile. Appx Provisioned Packages are installed in the Windows image and are used to provision appx packages, to the user profile, for each new user logging on to the device.

Restoring the appx provisioned packages, after removing them from Windows, is not an easy process so care should be taken when choosing which packages to remove.

I shared two scripted examples. The first had the appx provisioned packages, to remove, explicitly defined within the script body. The second referenced a .txt file, stored in GitHub, to remove the appx provisioned packages from Windows.

In environments, that require scripts to be signed, using a reference file for script variables is interesting. Obviously in our example we didn’t have any sensitive information that shouldn’t be seen by the public, so GitHub was fine to store the reference file.

If you want to start to get creative with reference files that include sensitive data we can look to store the file in Azure Blob storage and use a Shared Access Token or managed identity to access that file securely – and that gives me an idea for a future blog post.

(4)

The post Remove Built-in Windows 11 apps leveraging a Cloud-Sourced reference file appeared first on MSEndpointMgr.

We recently shared the top 10 most-used Community Right Click Tools. This post will highlight the top 10 most-used Right Click Tools within the Enterprise Edition. See what Right Click Tools customers are using, along with an honorable mention below. We’ll cover each tool’s capabilities as well as some examples of basic ways you can utilize the tools in your environment.  

1. System Information  

The System Information tool is a great way to view and take action on all aspects of a machine. From the tool, you can see info about the OS, hardware, applications, updates, services, drivers, user profiles, user sessions, local group members, and batteries. The best part about having all of this info in one place is you can also make changes. Whether you need to start/stop a service or delete an old user profile that is taking up too much space, this is the place to go. If this leaves you wanting more, look into Endpoint Insights to broaden the scope of machine information and reporting. 

2. Remote Software Center  

If you’re sick of having to ask a user to install updates or an application, you will love this tool. Remote Software Center gives you the ability to access all of the functions of Software Center as if you were remoted in or sitting right at the machine. From Remote Software Center, you can install applications, run updates, kick-off task sequences, and run compliance policies.  

3. Remote Windows Security  

Remote Windows Security gives you access to the Windows security settings. With this tool, you can view and take action on BitLocker, TPM, Firmware, Defender, and Windows firewall settings. Need to add a Defender file exclusion, Windows Firewall rule, or just kick off a scan? Remote windows security gives you the ability to quickly act on a single device or a collection without ever needing to leave ConfigMgr. 

4. Software Updates Deployment Status  

The Software Updates Deployment Status dashboard is a great place to get a full picture of how up to date the endpoints across your environment are. From the dashboard, you can view how compliant your devices are and which categories of updates are missing. The real power of this tool is customizability- you can break your view down by collection and limit which types of updates you are concerned with (i.e. critical, security, etc.). Your security team will love this one.  

5. Active Directory Cleanup Tool  

The Active Directory Cleanup Tool gives you insight into devices that are found in AD but are not being managed by ConfigMgr and vice versa. This tool can be very helpful during an AD audit as it helps to find devices that need to be removed from ConfigMgr or that have fallen off the domain. You can even take right click actions within the dashboard. If you need to delete the device from AD you can do it right from the dashboard. Rather than sending your help desk employees on a wild goose chase comparing AD to what you have in ConfigMgr, give this dashboard a shot! 

6. Client Information  

Client Information gives you quite a few useful pieces of information on a ConfigMgr client all in one place. You can view data like cache info, applications, ConfigMgr client info, boundaries, and execution history from this tool. Much like our other tools, you can take action right from this view as well. From the application tab, you can even install or uninstall software. 

7. BitLocker Compliance Tool  

The Bitlocker Compliance Tool dashboard is a great way to view and take action on all things Bitlocker. The dashboard generates graphs representing key storage status and unified compliance status (MBAM, CM, or Both). You can choose to drill this down to a specific OU or pick a Collection. No matter which graph section you click into you can see information about the device taken from both graphs.  

8. AD LAPS Password  

The AD LAPS (Active Directory Local Admin Password Solution) Password tool gives you all of the information you would find using the LAPS UI without ever needing to leave your ConfigMgr console. You can check the current LAPS password for a machine. Worried about someone writing that password down and leaving it somewhere they shouldn’t? This tool allows you to set your own expiration time so it resets as soon as you want it to. No waiting for the next cycle! 

9. Content Distribution Monitor  

The content distribution dashboard gives you info about your distribution points in one centralized location. This dashboard gives you a graphical representation of successful, errored, and in-progress content across all of your DPs. The best part? Right from the graph you can either redistribute failed content to all DPs or drill down individually and view the status, redistribute, remove, or validate the content.  

  10. Send Notification‍ 

The name says it all with this tool. This can be used to send a custom notification to a device or collection. Need to give your users in accounting a warning that the accounting systems will be patched tonight? This is just the tool for the job. By default, this tool will try using a “Recast Toast” which allows you to add a custom image. I suggest adding your company logo so your users don’t get freaked out by the random pop-up! 

Honorable Mention  

LAPS Dashboard 

The LAPS Dashboard was too close to the top 10 not to give it a mention. The LAPS Dashboard provides you with a compliance overview of LAPS in your environment. You can break this down by selecting a specific Domain and OU. The interactive graphs give you the status of computers that do/don’t have a LAPS password in AD and that do/don’t have the LAPS client installed. Clicking into any section provides you with the computers that make up that portion of the graph.  

 
What’s your favorite Right Click Tool? Please let us know @RecastSoftware.  

Get started with our free Community Edition to immediately boost productivity. See the difference between the features included in the Community Edition versus the Enterprise Edition. Interested in learning more about the Enterprise Edition? Request a quote today! 

(4)

The post Top 10 Most Used Enterprise Right Click Tools  appeared first on MSEndpointMgr.