↓ Skip to main content

Posts

2020

Ensuring regular Defender Quick scans with Microsoft Endpoint Manager proactive remediations

·2 mins
While looking into the new Microsoft Defender Antivirus report available in MEM (Intune) I discovered some machines which did not report any recent Defender antimalware scans, despite configured via configuration profile. Of course, AV scans are kinda old-fashioned against rapidly evolving threats but a regular quick scan won’t hurt anyone. Instead of having a look at every single machine affected, I decided to try out the new proactive remediations feature which went globally available last week and let endpoint analytics do the detection and remediation work for me. As a reference, I used the Tutorial: Proactive remediations from Microsoft which covers the process quite well. PowerShell scrips # For Endpoint analytics / Proactive remediations we need two PowerShell scripts. The first script is used as a detection script and determines whether remediation is necessary based on the exit code. Exit code 0 indicates a healthy status and exit code 1 indicates remediation necessary. Remediation occurs with a second PowerShell script. To detect the most recent Defender scan I used the Windows Eventlog. Event ID’s are documented here. Detection script # Remediation script # The remediation script is just about a one-liner to trigger a quick scan. You can extend this based on your requirements and respective to your Intune settings. E.g. triggering a signature update for a scan or adding additional steps.

Discover the Microsoft Graph API with the Microsoft Endpoint Manager Portal

·2 mins
You always wanted to automate a specific action within Intune / the Microsoft Endpoint Manager Portal (MEM) but were afraid of the complexity? The Microsoft Graph API docs deliver you more questions instead of answers? Automating tasks within the MEM portal could be very easy, couldn’t it? I promise it will be much simpler with this magician trick. Microsoft Endpoint Manager Portal # The MEM Portal UI relies on the Microsoft Graph API. This means that the UI where you create new settings and policies and the Intune backend are encapsulated with different layers. Communication between the UI and the backend happens with the Microsoft Graph API. With the developer tools we can trace network traffic and discover the request URLs and request body payload which are required to interact with the API. {: .align-center} Example about how to capture URLs and build a PowerShell script # Original request body:

Access has been blocked by Conditional Access policies when using device code flow

·3 mins
When using device code authentication for PowerShell modules with conditional access you might receive prompts like: “Access has been blocked by Conditional Access policies. The access policy does not allow token issuance” or “AADSTS50097: Device authentication is required”. But what’s the reason for this error and is there a solution available? Examples from the field # Device code flow is quite a convenient way to sign-in for an app within the web browser - at least if it works. If not you have to consider other options and that’s probably the reason why you’re reading this blog article. Az PowerShell Running the Az PowerShell module on PowerShell 7 uses device code flow to authenticate against your Azure tenant and might fail: Connect-AzAccount: AADSTS50097: Device authentication is required. Timestamp: 2020-08-17 13:36:31Z: Response status code does not indicate success: 401 (Unauthorized). The sign-in to Azure is tied to the “Microsoft Azure Management” app that you can select within Conditional Access. Microsoft Graph PowerShell The same applies for the new Microsoft.Graph PowerShell modules - but here we receive a more detailed error message: Connect-Graph: AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Timestamp: 2020-08-17 13:37:12Z The sign-in to the new Microsoft Graph Modules is tied to the “Microsoft Graph PowerShell (Preview)” app and some more apps I couldn’t determine.

Bulk create Intune mobile app deployment groups and assignments

·1 min
Creating assignments and software deployment groups for Intune mobile apps is quite a repetitive and manual task. Because of that, I want to share a PowerShell script with you which allows you to automatically create software deployment groups in Azure AD and the assignments for various intents. The script allows you to: Create Azure AD groups (install uninstall purpose) Pick existing groups based on displayName Assign Intune mobile apps (tested for Win32 and MSI LOB apps) You can find the script on my techblog GitHub repository. Because of the configurable group prefixes the script helps you to keep your Intune environment clean and implement a standard app assignment configuration. The script uses the Microsoft Graph API and the following resources https://graph.microsoft.com/beta/deviceAppmanagement/mobileApps https://graph.microsoft.com/beta/deviceAppmanagement/mobileApps/{AppID}/Assignments https://graph.microsoft.com/beta/groups It uses the preregistered app “Microsoft Intune PowerShell” which exists by default in all tenants. If you want to run the Script with PowerShell 7 you need to create an adjust the MSAL token section with the -DeviceCode parameter. You can bulk select the apps you want to create the assignment and AAD deployment groups: Hope this saves you some time.

Add PowerShell modules to Azure functions

·3 mins
Azure functions for PowerShell natively ship without additional cmdlets or PowerShell modules. In this post, I will show you how to add both public modules from the PowerShell gallery with automatic dependency management and custom modules. For both options, we use the Kudu tools to adjust the configuration of our function app. You can launch them from the “Advanced Tools” section of your function app: Afterwards, launch the PowerShell debug console and navigate to the wwwroot folder of your app: Option 1: Automatic dependency management # Note: Installing modules which require license acceptance (e.g. the MSAL.PS module) currently cannot be installed with automatic dependency management. You can track the issue status here and here. {: .notice–warning} Azure function apps running PowerShell come with a nice feature called managed dependencies. You can specify the modules you want to import from the PowerShell Gallery and the function app host will automatically process the dependencies. In the requirements.psd1 add the module details: # This file enables modules to be automatically managed by the Functions service. # See https://aka.ms/functionsmanageddependency for additional information. # @{ # For latest supported version, go to 'https://www.powershellgallery.com/packages/Az'. 'Az' = '4.*' 'Microsoft.Graph.Authentication' = '0.*' } You can either specify an exact version available from the PowerShell Gallery or specify the major version with a wildcard. With the wildcard option it will use the latest version available.

Playing around with the Office 365 Service Communications API

The Office 365 Service Communications API provides information about Microsoft 365 service status for your tenant including service messages. I built a little PowerShell module to access the API with PowerShell cmdlets. In this post I want to show you some examples which help you to use the API. PowerShell Module # I built a PowerShell module to access Microsoft 365 service status details natively with PowerShell. The PowerShell module and documentation is available on the PowerShell Gallery and on GitHub. Before using the module an app registration is required. Setup instructions are also provided on GitHub. CI/CD # By leveraging Azure DevOps I created a build and release pipeline which automatically builds the PowerShell module with Plaster. Builds are only created if the commit on GitHub includes a version tag. This version tag gets automatically populated to the module manifest. The build artifact gets then automatically published to the PowerShell Gallery as a new version. Furthermore, a new GitHub release including the module artifact is added to the project. This process fully automates the publishing and build process for the module. For local development and maintenance, the module can also be built with Invoke-Build.

Intune scope tags and role-based access control explained

·7 mins
For larger Intune environments a solid role-based access implementation becomes crucial to ensure a secure administration. But how does Intune role-based access control (RBAC) work in combination with scope tags and how to get started? This post gets you covered with explanations and practical examples. Role-based access control within the Microsoft 365 ecosystem # Within the Microsoft 365 ecosystem, Microsoft provides Azure AD administrative roles to administrate services like Exchange (Exchange administrator), SharePoint (SharePoint administrator), Intune (Intune administrator) and so on. As you can see Azure AD provides (usually) only one role which grants full administrative access over a service. You can configure more fine-grained controls within the service itself - that’s where the RBAC controls of the respective service kick in. To give you another example: You might have a 1st or 2nd level support department which needs permissions to perform remote actions on Intune managed devices. Instead of assigning them the Azure AD Intune Administrator role, it’s more convenient to assign them a fine-grained Intune RBAC role which delegates exactly the permissions needed. As the name already indicates Intune related roles only live within the Intune tenant and cannot be managed from AAD and vice-versa:

Who invited this Azure AD guest user?

·1 min
Who invited this Azure AD guest user? Examining who invited a specific a guest account can be quite a challenging question if you don’t have a log analytics workspace in place with Azure AD Audit log forwarding configured. Kusto queries for your log analytics workspace # The following queries help you to identify who invited a guest. If you haven’t set-up Azure AD audit log forwarding it’s the right time to do it now as described in one of my previous blogs. To find all guest invitations: AuditLogs | where OperationName == 'Invite external user' and Result == 'success' To find all accepted invitations: AuditLogs | where OperationName == 'Invite external user' and Result == 'success' | extend InvitationId = tostring(AdditionalDetails[0].value) | join ( AuditLogs | where OperationName in('Redeem external user invite') | parse kind=regex TargetResources[0].displayName with * "InvitationId: " InvitationId:string "," ) on $left.InvitationId == $right.InvitationId Improving your guest user governance # To simplify the guest user review and management process I developed a solution which fully automates this process. Additionally the solution populates the user who invited a guest as the guest’s manager which allows you to easily examine the question “Who invited this Azure AD Guest Account?”. Azure AD guest user review solution

Azure AD guest user review solution

Azure Active Directory guest users really simplify the process to collaborate with external users. Although keeping a good governance on guest accounts can become quite a challenge. The two biggest challenges I often observe are: “Who invited that guest user?” and “Does this guest user still need access to our infrastructure?”. Inspired by a recent post of Thomas Kurth regarding Azure AD Guest Account - Governance and Cleanup I also developed a solution which comes quite close to an “Azure AD Access review” like user experience. Notable features # The ‘Manager’ attribute of your guest users get’s automatically populated with the identity of the inviter All Azure AD app registration information is stored in Azure Key Vault Almost zero touch deployment with ARM templates You can integrate existing guest users into this solution by populating the manager attribute in Azure AD You can configure the approval frequency for guest accounts Approval frequency respects last approval date for each guest account Architecture # The solution leverages function of: Azure Logic App

Remove Azure AD direct License Assignments with PowerShell

Who doesn’t love a clean and tidy environment, do you? This also applies for your license assignments in Office 365 and Azure AD. As time passess it is likely to have users with direct license assignments or users which still have old trial licenses assigned. To get rid of those assignments I created a PowerShell script with removal and reporting functionality. Direct link to the script. Identify direct license assignments # In the Azure Portal we recognize direct license assignments on a user account by viewing the “Assignment Paths”: With the MSOnline PowerShell module we can view the Licenses property of a user and retrieve a nested property called: GroupsAssigningLicense. The GroupsAssigningLicense property contains either: An empty array if the license was not inherited from a group -> direct assignment An array with objectId’s If the array contains the user’s objectId -> direct assignment Example 1: User with objectId 36c9b091-fe88-4dc2-a9e1-2662020b4bab has group based license assignment and direct assignment: AccountSkuId : nicolasuter:SPE_E5 GroupsAssigningLicense : {0a918505-d0d5-4078-9891-0e8bec67cb65, 36c9b091-fe88-4dc2-a9e1-2662020b4bab} Example 2: User has no inherited licenses from a group: AccountSkuId : nicolasuter:SPE_E5 GroupsAssigningLicense : {} PowerShell Script # You find the PowerShell script on my techblog GitHub repository.