Security Posture

Validate status of Windows 10 security settings

I’ve created a Powershell-script for detecting status of different security related device features and settings related to Windows 10. The ambition with this script is to be able to check the current setting of different features in a quick way without utilizing any portals. Currently the script detects the status of:

  • Operating System (Edition, Architecture, Version, and Buildnumber)
  • TPM
  • Bitlocker
  • UEFI
  • SecureBoot
  • Defender (Antivirus, Antispyware, Realtime Protection, Tamper Protection, IOAV Protection, Network Protection, PUAProtection)
  • CloudProtectionService (MAPS for Defender)
  • DefenderATP
  • ApplicationGuard
  • Windows Sandbox
  • Credential Guard
  • Device Guard
  • Attack Surface Reduction
  • Controlled Folder Access

The script will write entries to a log file residing at the client (C:\Windows\Temp\Client-SecurityPosture.log) which preferably is read using CMTrace or OneTrace.

Install the Script
The script itself can be found at Powershell Gallery and installed using:
Install-Script -Name SecurityPosture -force  

Or you can download it manually from my Github.

Running the Script
Security Posture has support for running individual functions (switches), let’s try and check the Operating System and the status of UEFI and Secure Boot as an example:

Next thing to try is running the script querying every function in it:

The status of more functions and features will be displayed:

As I stated in the beginning of this post. the script will write entries to a log file residing at the client at C:\Windows\Temp\Client-SecurityPosture.log which preferably is read using CMTrace or OneTrace.


More detailed information can be found in the description of the script. I’m planning on upgrading it to a module in the future with more visible help related to each function. I have a project for the script listed on my Github. Feel free to comment or DM me suggestions/ideas or errors you may encounter.

Manage authentication method (MFA in AzureAD, telephone-number)

Finally some new capabilites for us in regards to displaying, changing and turning off MFA-configurations for users. My past post regarding MFA-status can be read here which utilized Get-Msoluser. Now, Microsoft has released a new set of commands in the MSGraph api for Azure Multi-factor authentication which I’ll briefly go through in this post. Note that this is only in beta right now and more features will be added later.

First, let’s see what we can do as stated here:

“The new APIs we’ve released in this wave give you the ability to:

  • Read, add, update, and remove a user’s authentication phones.
  • Reset a user’s password.
  • Turn on and off SMS sign-in.”

Sweet, let’s try it out. We’ll start by navigating to Microsoft Graph and consent to the required permissions. For this example, be sure to use an account who is Global Administrator or Authentication Administrator.

Enter this information (change UPN to a test-user in your tenant):

Now select “Modify permissions” and be sure to consent to the permission UserAuthenticationMethod.ReadWrite.All 

Note that I’ve specified GET (fetch information) and when I press Run Query now, the result:

No value, which was expected in my case since my test-user does not have any phone number registered as authentication method for MFA. So let’s now try to POST the information instead and give the user a registered telephone number.

Change GET to POST

In the request Body, enter the following entries with your chosen values:

“phoneType”: “mobile”,
“phoneNumber”: “+46234567890”


Press Run Query again.. Success!

If you would like to verify the setting, change POST to GET again to fetch the same users Authentication Methods and now you’ll see the phone number:

The information can also be verified in AzureAD of course under Authentication Methods:

As Microsoft has stated here, more methods will be added in the future for these API-calls which will be much appreciated by many of us out there.

ABM – Invalid Profile during enrollment (Default Enrollment Restriction)

I stumbled upon a pretty dazzling error the other day where the solution wasn’t too obvious for me so I thought I would share my findings.

Prerequisites which all were in place:
– Apple Business Manager configured and Apple-devices where transmitted from reseller.
– Integration with Intune in place and devices successfully synced to my Intune-tenant.
– ABM-profile assigned to the successfully synced devices with User Affinity-setting configured.

During the provisioning of the device when the iPhone or iPad is turned on after the device has connected to cellular or WiFi, the ABM-profile is about to be downloaded to the device. But this time it only got prompted with “Invalid Profile”.

I tried deleting the device from Intune and re-synced ABM, I also tried modifying the settings for the ABM-profile and redeployed the ABM-token in Intune. I even tried resetting the whole ABM-integration between Intune and ABM but nothing solved my issue. The solution was instead, related to my Enrollment Restriction setup. You can find your enrollment restrictions in Endpoint Manager by going here and navigating to Devices/Enroll Devices and then Enrollment Restrictions.

Check out your Default restriction targeting All Users, and be sure to note the description of it:
This is the default Device Type Restriction applied with lowest priority to all users regardless of group membership.”

That’s what I had missed. I had made another Device type restriction with priority 1, that targeted my Intune Users and in that restriction iOS were allowed for enrollment. Beneath that one, in the Default restriction iOS was blocked. The result is that manual user driven Intune-enrollment for a mobile device works for users who are members of my Intune-Users group but the automatic enrollment by Apple Business Manager did not.

Conclusion: in other words, my bad! I had modified the default one way before the ABM-integration was in place and the regular iPhone-enrollments worked flawlessly. So be sure to double check your Enrollment Restrictions if you stumble upon any ABM Invalid Profile related errors.

Check MFA-Status of Users (Powershell)

Finding information about MFA on a user in Azure Active Directory can be achieved in mutiple ways. Here, I will describe an easy way of finding MFA-information (registered, and by which method) by using Powershell, the cmdlet Get-Msoluser and its related property StrongAuthenticationMethods.

Install the powershell Module MSOnline:
Install-Module MSOnline
Then, connect to the service in Powershell by:

When authenticated, query all users who have MFA activated using the following code:
Get-MsolUser -All | where {$_.StrongAuthenticationMethods -ne $null} | Select-Object -Property UserPrincipalName

Now, let’s expand the property StrongAuthenticationMethods to get more information about MFA’s state, and which MFA-method the user has configured MFA with:
Get-MsolUser -All | Where {$_.UserPrincipalName} | Select UserPrincipalName, DisplayName, @{n=”Status”; e={$_.StrongAuthenticationRequirements.State}}, @{n=”Methods”; e={($_.StrongAuthenticationMethods).MethodType}}, @{n=”Chosen Method”; e={($_.StrongAuthenticationMethods).IsDefault}} | Out-GridView

Useful result when working with Microsoft 365 and MFA. As you see above, allowed methods in my tenant is PhoneAppOTP and PhoneAppNotification (Microsoft Authenticator). The chosen method for this users MFA is PhoneAppNotification. The reason why the Status-field is empty is because this user activated MFA via a Conditional Access Policy and the MFA is not enabled/Enforced via the old MFA-portal.