Requirements

In this article I am going to be sharing a script to get the Entra ID PIM Role eligibility and active assignments but there are a few things we will need in order to run the script successfully. Let us list out what’s needed now.

• Graph PowerShell SDK v1.0 and beta module
• Entra ID P2 License
• Graph API Scopes:
• Directory.Read.All

–OR–

• RoleEligibilitySchedule.Read.Directory
• RoleAssignmentSchedule.Read.Directory
• RoleManagement.Read.Directory

Get Entra ID PIM Role Assignment Using Graph API

As mentioned above, we will need at least 1 Entra ID P2 license since that is what allows us to use PIM in our tenant. We should also confirm we have the Graph PowerShell SDK v1.0 and beta modules.
 

Finally, I like to use PowerShell 7+ since that is better optimized for PowerShell as opposed to the default Windows PowerShell that comes pre-installed with Windows. This is not a requirement but more of a personal preference.
 

PowerShell Script

Now let’s get to the reason why you checked this article. Below is the PowerShell script to get PIM Role assignment using Graph API.

Function Get-MgPimRoleAssignment {
<#
.SYNOPSIS
    This will check if a user is added to PIM or standing access.

.LINK
    https://thesysadminchannel.com/get-entra-id-pim-role-assignment-using-graph-api -

.NOTES
    Name: Get-MgPimRoleAssignment
    Author: Paul Contreras
    Version: 2.4
    DateCreated: 2023-Jun-15
#>

    [CmdletBinding()]
    param(
        [Parameter(
            Mandatory = $true,
            ValueFromPipeline = $true,
            ValueFromPipelineByPropertyName = $true,
            ParameterSetName = 'User',
            Position  = 0
        )]
        [Alias('UserPrincipalName')]
        [string[]]  $UserId,


        [Parameter(
            Mandatory = $false,
            ValueFromPipeline = $true,
            ValueFromPipelineByPropertyName = $true,
            ParameterSetName = 'Role',
            Position  = 1
        )]
        [Alias('DisplayName')]
        [ValidateSet(
            'Application administrator',
            'Application developer',
            'Attack payload author',
            'Attack simulation administrator',
            'Attribute assignment administrator',
            'Attribute assignment reader',
            'Attribute definition administrator',
            'Attribute definition reader',
            'Authentication administrator',
            'Authentication policy administrator',
            'Azure AD joined device local administrator',
            'Azure DevOps administrator',
            'Azure Information Protection administrator',
            'B2C IEF Keyset administrator',
            'B2C IEF Policy administrator',
            'Billing administrator',
            'Cloud App Security Administrator',
            'Cloud application administrator',
            'Cloud device administrator',
            'Compliance administrator',
            'Compliance data administrator',
            'Conditional Access administrator',
            'Customer LockBox access approver',
            'Desktop Analytics administrator',
            'Directory readers',
            'Directory writers',
            'Domain name administrator',
            'Dynamics 365 administrator',
            'Edge administrator',
            'Exchange administrator',
            'Exchange recipient administrator',
            'External ID user flow administrator',
            'External ID user flow attribute administrator',
            'External Identity Provider administrator',
            'Global administrator',
            'Global reader',
            'Groups administrator',
            'Guest inviter',
            'Helpdesk administrator',
            'Hybrid identity administrator',
            'Identity Governance Administrator',
            'Insights administrator',
            'Insights Analyst',
            'Insights business leader',
            'Intune administrator',
            'Kaizala administrator',
            'Knowledge administrator',
            'Knowledge manager',
            'License administrator',
            'Lifecycle Workflows Administrator',
            'Message center privacy reader',
            'Message center reader',
            'Network administrator',
            'Office apps administrator',
            'Password administrator',
            'Permissions Management Administrator',
            'Power BI administrator',
            'Power platform administrator',
            'Printer administrator',
            'Printer technician',
            'Privileged authentication administrator',
            'Privileged role administrator',
            'Reports reader',
            'Search administrator',
            'Search editor',
            'Security administrator',
            'Security operator',
            'Security reader',
            'Service support administrator',
            'SharePoint administrator',
            'Skype for Business administrator',
            'Teams administrator',
            'Teams communications administrator',
            'Teams Communications Support Engineer',
            'Teams Communications Support Specialist',
            'Teams devices administrator',
            'Tenant Creator',
            'Usage summary reports reader',
            'User administrator',
            'Virtual Visits Administrator',
            'Windows 365 Administrator',
            'Windows update deployment administrator',
            'Yammer Administrator'
        )]
        [string]    $RoleName,


        [Parameter(
            Mandatory = $false
        )]
        [ValidateSet(
            'Eligibile',
            'Active'
        )]
        [string]    $PimAssignment,


        [Parameter(
            Mandatory = $false
        )]
        [string]    $TenantId,


        [Parameter(
            Mandatory = $false
        )]
        [switch]    $HideActivatedRoles
    )

    BEGIN {
        $ConnectionGraph = Get-MgContext
        $ConnectionGraph.Scopes = $ConnectionGraph.Scopes -replace "write","" | select -Unique
        'RoleEligibilitySchedule.Read.Directory', 'RoleAssignmentSchedule.Read.Directory', 'RoleManagement.Read.Directory' | ForEach-Object {
            if ($ConnectionGraph.Scopes -notcontains $_) {
                Connect-Graph -Scopes RoleEligibilitySchedule.Read.Directory, RoleAssignmentSchedule.Read.Directory, RoleManagement.Read.Directory -ErrorAction Stop
                continue
            }
        }

        if (-not ($PSBoundParameters.ContainsKey('TenantId'))) {
            $TenantId = $ConnectionGraph.TenantId
        }
    }

    PROCESS {
        $RoleDefinitions = Invoke-GraphRequest -Uri 'https://graph.microsoft.com/beta/roleManagement/directory/roleDefinitions' | select -ExpandProperty value

        $RoleHash   = @{}
        $RoleDefinitions | select id, displayname | ForEach-Object {$RoleHash.Add($_.DisplayName, $_.Id) | Out-Null}
        $RoleDefinitions | select id, displayname | ForEach-Object {$RoleHash.Add($_.Id, $_.DisplayName) | Out-Null}

        if ($PSBoundParameters.ContainsKey('UserId')) {
            foreach ($User in $UserId) {
                try {
                    [System.Collections.Generic.List[Object]]$RoleMemberList = @()
                    $PropertyList = 'DisplayName', 'UserPrincipalName', 'Id', 'AccountEnabled'
                    $AzUser = Get-MgUser -UserId $User -Property $PropertyList | select $PropertyList

                    if ($PSBoundParameters.ContainsKey('PimAssignment')) { #if active or eligible is selected, no need to get other option
                        if ($PSBoundParameters.ContainsValue('Active')) {
                            $AssignmentList = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "PrincipalId eq '$($AzUser.id)'" -ExpandProperty Principal,DirectoryScope -All
                            $AssignmentList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Active" -Force -PassThru | Out-Null
                            $AssignmentList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null
                            $AssignmentList | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                        }

                        if ($PSBoundParameters.ContainsValue('Eligibile')) {
                            $EligibleList = Get-MgBetaRoleManagementDirectoryRoleEligibilitySchedule -Filter "PrincipalId eq '$($AzUser.id)'" -ExpandProperty Principal,DirectoryScope -All
                            $EligibleList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Eligibile" -Force -PassThru | Out-Null
                            $EligibleList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null
                            $EligibleList | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                        }
                    } else {
                        $AssignmentList = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "PrincipalId eq '$($AzUser.id)'" -ExpandProperty Principal,DirectoryScope -All
                        $AssignmentList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Active" -Force -PassThru | Out-Null
                        $AssignmentList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null

                        $EligibleList = Get-MgBetaRoleManagementDirectoryRoleEligibilitySchedule -Filter "PrincipalId eq '$($AzUser.id)'" -ExpandProperty Principal,DirectoryScope -All
                        $EligibleList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Eligibile" -Force -PassThru | Out-Null
                        $EligibleList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null

                        $AssignmentList | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                        $EligibleList   | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                    }

                    if ($RoleMemberList) {
                        $Output = foreach ($RoleMember in $RoleMemberList) {
                            if ($RoleMember.DirectoryScopeId -eq '/') {
                                $DirectoryScope = 'Global'
                            }
                            elseif ($RoleMember.DirectoryScopeId -match 'administrativeUnits') {
                                $DirectoryScope = $RoleMember.DirectoryScope.AdditionalProperties.displayName
                            }
                            else {
                                $DirectoryScope = 'Unknown'
                            }

                            if ($RoleMember.ScheduleInfo.Expiration.Type -eq 'noExpiration') {
                                $DurationInMonths = 'Permanent'
                                $EndDate = 'Permanent'
                            } else {
                                $Days = ($RoleMember.ScheduleInfo.Expiration.EndDateTime) - ($RoleMember.ScheduleInfo.StartDateTime) | select -ExpandProperty TotalDays
                                $DurationInMonths = $Days / 30.4167 -as [int]
                                $EndDate = (Get-Date $RoleMember.ScheduleInfo.Expiration.EndDateTime).ToLocalTime()
                            }

                            if ($RoleMember.AssignmentScope -eq 'Active' -and $RoleMember.AssignmentType -eq 'Activated') {
                                $AssignmentScope = 'PimActivated'
                            } else {
                                $AssignmentScope = $RoleMember.AssignmentScope
                            }

                            if ($RoleMember.ScheduleInfo.StartDateTime -and $RoleMember.CreatedDateTime) {
                                $StartDateTime = (Get-Date $RoleMember.ScheduleInfo.StartDateTime).ToLocalTime()
                            } else {
                                $StartDateTime = (Get-Date 1/1/1999 -Hour 0 -Minute 0 -Millisecond 0)
                            }

                            [PSCustomObject]@{
                                UserPrincipalName   = $AzUser.UserPrincipalName
                                AzureADRole         = $RoleHash[$RoleMember.RoleDefinitionId]
                                PimAssignment       = $AssignmentScope
                                EndDateTime         = $EndDate
                                AccountEnabled      = $AzUser.AccountEnabled
                                DirectoryScope      = $DirectoryScope
                                DurationInMonths    = $DurationInMonths
                                MemberType          = $RoleMember.MemberType
                                AccountType         = $RoleMember.AccountType
                                StartDateTime       = $StartDateTime
                            }
                        }

                        if ($PSBoundParameters.ContainsKey('HideActivatedRoles')) {
                            $Output | Sort-Object PimAssignment, AzureADRole | Where-Object {$_.PimAssignment -ne 'PimActivated'}
                        } else {
                            $Output | Sort-Object PimAssignment, AzureADRole
                        }
                    }

                } catch {
                    Write-Error $_.Exception.Message
                }
            }
        } #end userid parameter set

        if ($PSBoundParameters.ContainsKey('RoleName')) {
            try {
                [System.Collections.Generic.List[Object]]$RoleMemberList = @()

                if ($PSBoundParameters.ContainsKey('PimAssignment')) {
                    if ($PSBoundParameters.ContainsValue('Active')) {
                        $AssignmentList = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "RoleDefinitionId eq '$($RoleHash[$RoleName])'" -ExpandProperty Principal,DirectoryScope -All
                        $AssignmentList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Active" -Force -PassThru | Out-Null
                        $AssignmentList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null
                        $AssignmentList | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                    }

                    if ($PSBoundParameters.ContainsValue('Eligibile')) {
                        $EligibleList = Get-MgBetaRoleManagementDirectoryRoleEligibilitySchedule -Filter "RoleDefinitionId eq '$($RoleHash[$RoleName])'" -ExpandProperty Principal,DirectoryScope -All
                        $EligibleList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Eligibile" -Force -PassThru | Out-Null
                        $EligibleList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null
                        $EligibleList | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                    }
                  } else {
                    $AssignmentList = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "RoleDefinitionId eq '$($RoleHash[$RoleName])'" -ExpandProperty Principal,DirectoryScope -All
                    $AssignmentList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Active" -Force -PassThru | Out-Null
                    $AssignmentList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null

                    $EligibleList = Get-MgBetaRoleManagementDirectoryRoleEligibilitySchedule -Filter "RoleDefinitionId eq '$($RoleHash[$RoleName])'" -ExpandProperty Principal,DirectoryScope -All
                    $EligibleList | Add-Member -MemberType NoteProperty -Name AssignmentScope -Value "Eligibile" -Force -PassThru | Out-Null
                    $EligibleList | Add-Member -MemberType ScriptProperty -Name AccountType -Value {$this.Principal.AdditionalProperties."@odata.type".split('.')[2] } -Force -PassThru | Out-Null

                    $AssignmentList | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                    $EligibleList   | ForEach-Object {$RoleMemberList.Add($_) | Out-Null}
                }

                if ($RoleMemberList) {
                    $Output = foreach ($RoleMember in $RoleMemberList) {
                        if ($RoleMember.DirectoryScopeId -eq '/') {
                            $DirectoryScope = 'Global'
                        }
                        elseif ($RoleMember.DirectoryScopeId -match 'administrativeUnits') {
                            $DirectoryScope = $RoleMember.DirectoryScope.AdditionalProperties.displayName
                        }
                        else {
                            $DirectoryScope = 'Unknown'
                        }

                        if ($RoleMember.ScheduleInfo.Expiration.Type -eq 'noExpiration') {
                            $DurationInMonths = 'Permanent'
                            $EndDate = 'Permanent'
                        } else {
                            $Days = ($RoleMember.ScheduleInfo.Expiration.EndDateTime) - ($RoleMember.ScheduleInfo.StartDateTime) | select -ExpandProperty TotalDays
                            $DurationInMonths = $Days / 30.4167 -as [int]
                            $EndDate = (Get-Date $RoleMember.ScheduleInfo.Expiration.EndDateTime)#.ToString('yyyy-MM-dd')
                        }

                        if ($RoleMember.AssignmentScope -eq 'Active' -and $RoleMember.AssignmentType -eq 'Activated') {
                            $AssignmentScope = 'PimActivated'
                        } else {
                            $AssignmentScope = $RoleMember.AssignmentScope
                        }

                        if ($RoleMember.ScheduleInfo.StartDateTime -and $RoleMember.CreatedDateTime) {
                            $StartDateTime = (Get-Date $RoleMember.ScheduleInfo.StartDateTime).ToLocalTime()
                        } else {
                            $StartDateTime = (Get-Date 1/1/1999 -Hour 0 -Minute 0 -Millisecond 0)
                        }

                        switch ($RoleMember.AccountType) {

                            'User' {
                                [PSCustomObject]@{
                                    UserPrincipalName   = $RoleMember.Principal.AdditionalProperties.userPrincipalName
                                    AzureADRole         = $RoleHash[$RoleMember.RoleDefinitionId]
                                    PimAssignment       = $AssignmentScope
                                    EndDateTime         = $EndDate
                                    AccountEnabled      = $RoleMember.Principal.AdditionalProperties.accountEnabled
                                    DirectoryScope      = $DirectoryScope
                                    DurationInMonths    = $DurationInMonths
                                    MemberType          = $RoleMember.MemberType
                                    AccountType         = $RoleMember.AccountType
                                    StartDateTime       = $StartDateTime
                                }
                            }

                            'Group' {
                                $GroupMemberList = Get-MgGroupTransitiveMember -GroupId $RoleMember.PrincipalId
                                foreach ($GroupMember in $GroupMemberList) {
                                    [PSCustomObject]@{
                                        UserPrincipalName   = $GroupMember.AdditionalProperties.userPrincipalName
                                        AzureADRole         = $RoleHash[$RoleMember.RoleDefinitionId]
                                        PimAssignment       = $AssignmentScope
                                        EndDateTime         = $EndDate
                                        AccountEnabled      = $GroupMember.AdditionalProperties.accountEnabled
                                        DirectoryScope      = $DirectoryScope
                                        DurationInMonths    = $DurationInMonths
                                        MemberType          = $RoleMember.MemberType
                                        AccountType         = $GroupMember.AdditionalProperties.'@odata.type'.Split('.')[2]
                                        StartDateTime       = $StartDateTime
                                    }
                                }
                            }

                            'servicePrincipal' {
                                [PSCustomObject]@{
                                    UserPrincipalName   = $RoleMember.Principal.additionalproperties.displayName
                                    AzureADRole         = $RoleHash[$RoleMember.RoleDefinitionId]
                                    PimAssignment       = $AssignmentScope
                                    EndDateTime         = $EndDate
                                    AccountEnabled      = $RoleMember.Principal.AdditionalProperties.accountEnabled
                                    DirectoryScope      = $DirectoryScope
                                    DurationInMonths    = $DurationInMonths
                                    MemberType          = $RoleMember.MemberType
                                    AccountType         = $RoleMember.AccountType
                                    StartDateTime       = $StartDateTime
                                }
                            }
                        }
                    }

                    if ($PSBoundParameters.ContainsKey('HideActivatedRoles')) {
                        $Output | Sort-Object PimAssignment, AzureADRole | Where-Object {$_.PimAssignment -ne 'PimActivated'}
                    } else {
                        $Output | Sort-Object PimAssignment, AzureADRole
                    }
                }

            } catch {
                Write-Error $_.Exception.Message
            }
        } #end rolename parameter set
    }

    END {}

}

Script Parameters

When using this script, you can use the following parameters to customize the output. Let’s go over those now.
 

    -UserId

DataType: string
Description: Specify the UserId or UserPrincipalName of the principal you want to find active or eligible roles.
 

    -RoleName

DataType: string
Description: Specify the Entra ID Role name to get all principals that are assigned that role.
 

    -PimAssignment

DataType: string
Description: Specify either Active or Eligible to display those results..
 

    -TenantId

DataType: string
Description: Specify the tenant Id to query that specific tenant. You must be authenticated to that tenant.
 

    -HideActivatedRoles

DataType: switch
Description: When used, the results will hide all PIM activated roles.
 

Example 1: Specifying the UserId parameter

Get-MgPimRoleAssignment -UserId homer@thesysadminchannel.com

UserPrincipalName : homer@thesysadminchannel.com
AzureADRole       : Helpdesk Administrator
PimAssignment     : Eligibile
EndDateTime       : Permanent
AccountEnabled    : True
DirectoryScope    : Admin Unit
DurationInMonths  : Permanent
MemberType        : Direct
AccountType       : user
StartDateTime     : 2/19/2024 3:34:32 PM

Example 2: Specifying the RoleName parameter that are eligible

Get-MgPimRoleAssignment -RoleName 'Helpdesk administrator' -PimAssignment Eligibile

UserPrincipalName : luke@thesysadminchannel.com
AzureADRole       : Helpdesk Administrator
PimAssignment     : Eligibile
EndDateTime       : Permanent
AccountEnabled    : True
DirectoryScope    : Global
DurationInMonths  : Permanent
MemberType        : Direct
AccountType       : user
StartDateTime     : 2/19/2024 3:43:16 PM

UserPrincipalName : homer@thesysadminchannel.com
AzureADRole       : Helpdesk Administrator
PimAssignment     : Eligibile
EndDateTime       : Permanent
AccountEnabled    : True
DirectoryScope    : Admin Unit
DurationInMonths  : Permanent
MemberType        : Direct
AccountType       : user
StartDateTime     : 2/19/2024 3:34:32 PM

Conclusion

Hopefully this article was able to help you get Entra ID PIM Role Assignment Using Graph API. With this script, you should be able to get all active, eligible AND eligible assignments that have been activated.
 

The post Get Entra ID PIM Role Assignment Using Graph API appeared first on the Sysadmin Channel.

 
For the purposes of this article we will use the Azure AD Portal, not the Entra ID portal

Requirements

In order to make this work there are a few requirements/prerequisites needed so you can successfully use Azure AD as the Identity Provider. Let’s touch on those requirements now.

• VMware Administrator Role
• VMware vCenter 8.0 U2 or later
• VMware Identity Services from Azure Enterprise App Gallery
• Azure Application Administrator or Global Administrator Role
• Azure App Registration with OpenID Connect (OIDC) scope
• Publicly accessible vCenter endpoint (We will use an Azure App Proxy for this)
• A group or users to sync to vCenter

Create the Azure AD OIDC App Registration

As mentioned in the prerequisites, you will need to create an app registration in Azure AD so you can use this as the authentication endpoint. This app will need to have the openid API permission so let’s walk through setting that up now.
 

Within Azure AD:

• Navigate to App Registration → New Registration
• Direct Link: https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/CreateApplicationBlade/quickStartType~/null/isMSAApp~/false
• Name the app: vCenter 8 OIDC
• Leave the Organizational directory to Single Tenant
• Leave the Redirect URI blank for now
• Click Register to create the app

Next we’ll want to add the API permissions so we can tie this Azure app to vCenter.
Within the vCenter 8 OIDC App:

• Navigate to API Permissions
• Select Add a permission
• Choose Microsoft Graph → Delegated → enable the 4 listed below
• Grant Consent for good measure

Leave this tab open for now, we will come back to it later.

vCenter Identity Source Configuration

We’re one step closer now that we have have the OIDC app created. Next we need to configure vCenter itself so we can change the Identity Provider from the local embedded provider to Azure AD.
 

Within the vCenter Server:

• Login to vCenter 8 using administrator@vsphere.local since we won’t have any other providers available
• Navigate to Administration → single sign on → configuration → Identity Provider → Identity Sources
• Click Change Provider → Azure AD

• Next, click run prechecks
• Check the box to confirm
• Click Next

• Under Directory Name enter Azure AD
• Enter the domain(s) and click the “+” to add it
• If you have multiple UPN suffixes, add them domain names here.

• Set the token lifetime

Earlier I mentioned to keep the tabs open because we’re going to need them later. Now is that time where we are going to use need them.

• Copy the redirect URI from the vCenter wizard
• Navigate back to the vCenter 8 OIDC app → Authentication tab
• Add a platform → Select Web
• Paste the Redirect URI into the redirect URI in the Azure app
• Click configure

• Copy the AppId (ClientId) from the Azure OIDC app and paste it to the client identifier in vCenter

• Create a secret and paste it in vCenter

• In the overview page of the OIDC App
• Click on EndPoints
• Copy the OpenID Connect metadata document URL and paste it in vCenter

• Review the configuration and proceed

Setting up an Azure App Proxy

One of the requirements to use Azure AD as the Identity source is to make sure we are able to publicly access vCenter from Azure. I am NOT a fan of exposing your network and poking a hole in your firewall so we’ll use the next best thing. In order to satisfy this requirement, we will use an Azure app proxy which will publish an endpoint that sits behind Azure.
 

The idea is that we will use the app proxy’s public endpoint to route to the internal endpoint so Azure is able to talk to vCenter on-premises. An app proxy requires you to install the connector service on an on-premises server that has line of sight to your vCenter server. I would suggest you have the app proxy agent installed on 2 machines so you can have some sort of redundancy when you need to do maintenance on the servers.
 

Let’s walk through the setup now.
Within Azure AD, open a NEW tab:

• Navigate to Azure AD → Application Proxy
• Direct Link: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/AppProxy
• Download and install the connector service

The install is pretty straight forward so get it installed on 2 machines and go back into the Azure portal.
 

Once the connector is installed, you should see the hostname and public IP show up in the Azure proxy section. From here, click on configure an app.

 

Next you should be taken to the app proxy configuration settings.

• Copy the vCenter Tenant URL and paste it into the app proxy Internal URL field
• Ensure the dropdown is set to https://
• Enter in a name for your app proxy (vcenter8appproxy or something similar is fine)
• Set the domain drop to which ever makes sense for you. Leaving the default is fine
• Set the pre authentication method to passthrough
• Set the connector group accordingly. If you have multiple connector groups, make sure it is set on the App proxy blade AND the Enterprise app settings

Trusting vCenter Root Certificate on the Connector Service Machine

If you’re using a publicly trusted certificate for vCenter than you can skip this part. However, if you’re using the default certificate that comes pre-loaded with vCenter you will need to do this. An easy way to find out, is go to your vCenter URL and if you’re getting Your connection is not private then you’re not using a trusted cert.
 

Let’s go back to the machine(s) that you installed the service connector on because that’s where we will need to have the cert be trusted. These steps need to be done on EACH server that has the connector agent.

On a NEW tab:

• Navigate to https://<your vcenter url>/certs/download.zip
• Right click and save as a zip file
• Open the zip file → certs → win
• Double click on the crt file to install it on the local machine
• Install it under the local machine context
• Place it under the Trusted Root Certification Authorities

• You can verify this by opening mmc.exe on the service connector machine
• Certificates → Local machine → Trusted root certification authorities
• Seeing the CA cert there

Create the VMware Identity Service App from the Gallery

Next on the list, we’ll need to create the VMware Identity Service app from the Azure App gallery to allow us to use SCIM provisioning.

Within Azure AD on a NEW tab:

• Navigate to Enterprise Application → New Application
• Direct Link: https://portal.azure.com/#view/Microsoft_AAD_IAM/AppGalleryBladeV2
• Search for “VMware Identity” to install the VMware Identity Service
• Name it vCenter 8 SCIM Provisioning

Setup Provisioning to Sync Users to vCenter

Here is where the rubber meets the road and we can finally start syncing users from Azure AD to vCenter.

• Navigate to the Enterprise Application → vCenter 8 SCIM Provisioning → Provisioning

• Click on Provisioning and set the mode to automatic
• Copy the External URL from the Azure app proxy and paste it here under Tenant URL

• Create a secret from vCenter 8 configuration and paste it here under Secret Token
• Click Test Connection. If everything is configured correctly, it should work.
• Save the configuration

Once the setting is saved, refresh the tab so the other settings can kick in. Another option is to close out of the blade and go back into the provisioning section.

• From here within the provisioning blade → Users and groups
• Set the users and/or groups you want to sync to vCenter

Once we’re happy with the users and/or groups we want to add, we’ll need to start the provisioning cycle so the objects can sync to vCenter 8.

• Go to the overview page
• Click on start provisioning to start the sync engine

Integrating Permissions for VMware vCenter

At this point you should now have your users and/or groups syncing to VMware vCenter 8. The last step here is to actually add these users to the permissions that you want to grant. VMware has these steps pretty well documented so it’s a quick search away. However, we’ll do a quick overview to ensure we add our users to the admin role so we can manage vCenter and all its resources.
 

Within vCenter 8 UI:

• Navigate to Administration → single sign on → Users and Groups → Groups → Administrators

• Click Edit to modify the members
• Next to Add a member, click the drop down to add your domain
• Search for the group that is synced from Azure AD provisioning
• Click Save to save the keep the settings

Conclusion

So there you have it, a full step by step guide on how to setup VMware vCenter SSO Integration with Azure AD. This method is especially helpful because this allows you to have vCenter in scope of conditional access policies and phishing resistance MFA methods such as Windows Hello for Business and Fido 2 security keys.

The post VMware vCenter SSO Integration with Azure AD appeared first on the Sysadmin Channel.

Requirements

In order to query license information for your tenant, you will need the following API Scopes permitted.

• Microsoft.Graph or Microsoft.Graph.Beta PowerShell modules
• Directory.Read.All or Organization.Read.All

Get Microsoft 365 License Usage Count Using PowerShell

Before we get into the PowerShell script, I wanted to point out that the Microsoft API’s don’t show the friendly display names for these licenses. Instead, they use a SkuPartNumber to give you an idea of what the licenses is regarding. The problem here is that you also won’t find the SkuPartNumber anywhere in the portal so it’s kind of a pain to make sure the license you’re targeting in the API is in fact the license in the Azure portal.
 

Luckily, there is a Microsoft Doc that has this information but it’s not always up to date. The link to that doc is https://learn.microsoft.com/en-us/entra/identity/users/licensing-service-plan-reference. There’s about 400+ Sku’s that are shown so it’s also nice that they have provided a csv file that we can use PowerShell to be able to pull these names into our Script.

$LicenseFile = 'C:\temp\m365license.csv'
$CutoffDate = (Get-Date).AddDays(-7)

if (Test-Path $LicenseFile) {
    $LastWriteTime = Get-ChildItem -Path $LicenseFile | select -ExpandProperty LastWriteTime

    if ($CutoffDate -gt $LastWriteTime) {
        #csv file is older than a week old.  Let us get a newer version
        Invoke-WebRequest -Uri 'https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv' -OutFile C:\temp\m365license.csv
    }
} else {
    #csv file was not found so let us download it now
    Invoke-WebRequest -Uri 'https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv' -OutFile C:\temp\m365license.csv
}

$csvList = Import-Csv C:\temp\m365license.csv
$LicenseHash = @{}

$csvList | ForEach-Object {
    if (-not $LicenseHash[$_.Guid]) {
        $LicenseHash.Add($_.GUID, $_.Product_Display_Name)
    }
}

$LicenseList = Get-MgSubscribedSku

#Uncomment if you only want to display licenses that are maxed out
foreach ($License in $LicenseList) {
    if ($License.PrepaidUnits.Enabled -ge 1) {
        #if ($License.ConsumedUnits -ge $License.PrepaidUnits.Enabled) {
            [PSCustomObject]@{
                LicenseName   = $LicenseHash[$License.SkuId]
                SkuPartNumber = $License.SkuPartNumber
                SkuId         = $License.SkuId
                Remaining     = $License.PrepaidUnits.Enabled - $License.ConsumedUnits
                Enabled       = $License.PrepaidUnits.Enabled
                Used          = $License.ConsumedUnits
            }
        #}
    }
}

As you can see from above, the Identity Governance P2 Step Up license has not been updated in the downloadable csv file so the license name shows up blank.

Conclusion

Hopefully this article was able to help you get Microsoft 365 License usage count using PowerShell and Graph API. Sometimes we’re too busy to manually keep an eye on it so having this script along with an email alert would be helpful for preventing your licenses being maxed out.

The post Get Microsoft 365 License Usage Count Using PowerShell appeared first on the Sysadmin Channel.

I previously wrote a post about using the ActiveDirectory module with Get-ADUser. The idea was to find AD users using PowerShell and went over several advanced topics. Feel free to check that to get familiar with the overall commands since Get-ADGroup is going to use something similar.
 

Here, the Get-ADGroup cmdlet is going to be used to filter all groups that have no members and move them to a separate OU for further processing. Since we are a little cautious when it comes to making bulk changes like this, I would suggest moving them to a staging OU where they can be left there for 30-60 days. Since these groups are empty, chances are no one is going to be missing them but it’s a good idea to separate them first, then move forward with deleting.
 

Before we delete anything, I would strongly recommend you enable the AD recycle bin so you can recover objects without hesitation.
 

Find Empty Groups in Active Directory using PowerShell

#Get All empty groups in the entire domain. Be careful with Exchange and other built-in groups.
$AllEmptyGroupList = Get-ADGroup -Filter {Members -notlike "*" } -Properties Members, WhenChanged, WhenCreated

#Get all empty groups that have not been touched in longer than 6 months. Be careful with Exchange and other built-in groups.
$CutOffDate = (Get-Date).AddMonths(-6)
$SixMonthEmptyGroupList = Get-ADGroup -Filter {Members -notlike "*" -and WhenChanged -lt $CutOffDate} -Properties Members, WhenChanged, WhenCreated

#Get all stale groups from a specific OU (Preferred)
$EmptyGroupList = Get-ADGroup -Filter {Members -notlike "*" -and WhenChanged -lt $CutOffDate} -Properties Members, WhenChanged, WhenCreated -SearchBase 'OU=My Groups,DC=contoso,DC=com'

Hopefully, you were able to understand how to find empty groups in Active Directory using PowerShell to better manage your group lifecycle. If a group is empty and hasn’t been modified in over 6 months, it’s a pretty good sign that it is no longer needed and can be purged.
 

Again, I would highly recommend you enable the recycle bin but with this you should be able to start off slowly and decommissioning in whatever approach you feel necessary.

The post Find Empty Groups in Active Directory using PowerShell appeared first on the Sysadmin Channel.

Requirements

Before we go into the details on how to set this up, we first need to ensure that we have everything in place so everything works as expected. Here’s what is needed.

• Azure AD P1 or P2 license for conditional access
• Security Administrator, Conditional Access Administrator or Global Administrator
• SharePoint Administrator or Global Administrator
• Exchange Administrator or Global Administrator
• Microsoft.Online.SharePoint.PowerShell PowerShell Module
• ExchangeOnlineManagement PowerShell Module

To touch a bit on these requirements, we need to ensure we have an Azure AD P1 or P2 license so we can have access to use conditional access policies. This is going to be the foundation of what we’re going to use to either limit or block unmanaged devices from accessing anything in the cloud. Also as of today, Security Administrator, Conditional Access Administrator or Global Administrator are the only roles that are able to modify CA policies. So we will need at least one of those.
 

Exchange Administrator and SharePoint Administrators are needed to be able to set the respective platform policies to limited access. A bit more on that later.

What Classifies as an Unmanaged Device

An unmanaged device is typically a device that is not issued by your organization. It is often synonymous with BYOD (Bring Your Own Device) and can be anything from a personal computer or phone to a machine that you use to access emails while at grandma’s house. The point here is that it doesn’t have any policies and it is not properly governed by the IT department.
 

Limit Browser Access on Unmanaged Devices for M365 Apps

If you don’t want to put a full stop on users accessing M365 resources, you do have the ability to limit what they can do while signed in from an unmanaged device. Simply put, we can enforce policies so users can still sign in using the web only methods, however, they will be blocked from downloading anything to the local machine.
 

For most, this is a great happy medium because it still keeps your data secure to a certain extent and users can access their documents if they don’t have their company issued device around.
 

This is in fact a two-step process so we’ll target SharePoint/OneDrive and Exchange Online now. Then we will finish it off with the CA Policies.

Limited Browser Access for SharePoint Online

If you want to take this in incremental steps you definitely can. Being able to set limited access on specific sites is supported so it’s definitely recommended you take that approach first. In my opinion it will be a good test to set limited access on a few SharePoint sites as well as a few OneDrive sites.
 

Let’s connect to SharePoint Online using the Microsoft.Online.SharePoint.PowerShell PowerShell Module.

Import-Module Microsoft.Online.SharePoint.PowerShell -WarningAction SilentlyContinue
$adminURL = 'https://<tenantname>-admin.sharepoint.com'
Connect-SPOService -Url $adminURL -WarningAction SilentlyContinue

Apply on a Per-Site Basis

Next, let’s take a look at the conditional access property within the Get-SPOSite cmdlet. This is what we’ll use to be able to limit access on specific SharePoint (or OneDrive) sites before we deploy this on the tenant level. By default, this should be set to allow full access. Meaning anyone can access this SharePoint site from anywhere and there wouldn’t be any restrictions in place.

With that out of the way, let’s change the access to allow limited, web only access for this site as well as a OneDrive site. To accomplish this we’re going to use the Set-SPOSite cmdlet along with the -ConditionalAccessPolicy Parameter.
 

This parameter supports the following inputs:

• AllowFullAccess: Allows full access from desktop apps, mobile apps, and the web
• AllowLimitedAccess: Allows limited, web-only access
• BlockAccess: Blocks Access
• AuthenticationContext: Assign an Azure AD authentication context. Must add the AuthenticationContextName

$SiteURL = 'https://thesysadminchannel.sharepoint.com/sites/someproject'
$OneDriveURL = 'https://thesysadminchannel-my.sharepoint.com/personal/buzz_thesysadminchannel_com'

Set-SPOSite -Identity $SiteURL -ConditionalAccessPolicy AllowLimitedAccess
Set-SPOSite -Identity $OneDriveURL -ConditionalAccessPolicy AllowLimitedAccess

$SiteURL, $OneDriveURL | ForEach-Object {Get-SPOSite -Identity $_ | select Title, ConditionalAccessPolicy}

Title          ConditionalAccessPolicy
-----          -----------------------
SomeProject         AllowLimitedAccess
Buzz Lightyear      AllowLimitedAccess

Before you start checking the sites you set the limited access on, note that nothing is limited until we configure the CA policies. It is strongly recommended that you do thorough testing before enabling this at the tenant level. Once you’ve done that and you’re ready to set it as the default, you can do that with another cmdlet. That cmdlet is Set-SPOTenant
 

Apply at the Tenant Level

Now that you’re ready to enable this as the default on the tenant level, there is one thing we need to decide on. That one thing is whether we want to enforce these restrictions on adhoc recipients. What exactly does that mean you say?
 

When the feature is enabled, all external users are going to be in scope of the restrictions and users who are accessing SharePoint Online files with a pass code are going to be blocked.
 

Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess -ApplyAppEnforcedRestrictionsToAdHocRecipients: $false

When completed, we can also check the SharePoint Admin center to see the same thing.

 

Finally, since doing this will automatically create a conditional access policy on our behalf, I would recommend disabling that and crafting one by hand so we can fine tune it to our liking.

Limited Browser Access for Exchange Online

Much like the SharePoint Online scenario, we can also limit browser access for users who are trying to access their email when on an unmanaged device. This setting is done using the OwaMailboxPolicy and is configurable for specific mailboxes or at the tenant level. Before we take a look at each one, we need to connect to Exchange Online via PowerShell.

Connect-ExchangeOnline -UserPrincipalName user@domain.com -ShowBanner: $false

Apply on a Per-Mailbox Basis

Again, it’s always a great idea to test on a few people to ensure you’re able to get the results you want. There’s nothing worse than enabling a policy and having to revert back because of incidents that could have very well been avoided if it was properly tested.
 

To set the limited access on a few mailboxes we’re going to need to create a new OwaMailboxPolicy and then set the same conditional access parameter to readonly.
 
In case you’re interested, here is what the supported inputs are for that parameter:

• Off: No conditional access policy is applied to Outlook on the web. This is the default value
• ReadOnly: Users can’t download attachments to their local computer, and can’t enable Offline Mode on non-compliant computers. They can still view attachments in the browser
• ReadOnlyPlusAttachmentsBlocked: All restrictions from ReadOnly apply, but users can’t view attachments in the browser

$OwaPolicy = New-OwaMailboxPolicy -Name LimitAccess
Set-OwaMailboxPolicy -Identity LimitAccess -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True Off
LimitAccess                  False ReadOnly

With the OwaMailboxPolicy now created, let’s apply that policy to a few users so we can do our testing. To apply we will use the Set-CASMailbox cmdlet.

Set-CASMailbox darth -OwaMailboxPolicy LimitAccess
Get-CASMailbox darth | select DisplayName, OwaMailboxPolicy

DisplayName OwaMailboxPolicy
----------- ----------------
Darth Vader LimitAccess

Apply at the Tenant Level

After we’ve tested for a bit, we can now apply this as the default setting at the tenant level. To accomplish this, we will use the Set-OwaMailboxPolicy and and modify the “OwaMailboxPolicy-Default” to use the readonly conditional access policy.
 

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True ReadOnly
LimitAccess                  False ReadOnly

Block Unmanaged Devices Using Conditional Access

If you’re wondering why nothing has changed after setting the SharePoint or Exchange settings, it’s because your conditional access policies are the tools that are going to be enforcing these restrictions. The platform settings are the underlying scoping policies, however the conditional access policies are the overlying restriction setting. Since we ended up setting both platform restrictions at the tenant level, the users we add (and ONLY those users) in the conditional access policy should have this setting enforced. Hopefully that clears up any confusion.
 

Similar to the default SharePoint policies that were automatically created, there are 2 policies we need to create so we can block unmanaged devices as well as restrict browser access if they’re not on an IT issued device. We can use those as rough templates to get us started.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA015: Block Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: All Cloud Apps (or M365 Apps for testing)
• Exclude: None



• Under Conditions: No Changes needed (or exclude iOS and Android Devices for testing)
• Under Grant:
• Require device to be marked as compliant: Checked
• Require Hybrid Microsoft Entra joined device: Checked
• Require one of the selected controls: Is selected



• Under Sessions: No Changes needed

Restrict Browser Access on Unmanaged Devices Using Conditional Access

Earlier we setup the policies on Exchange Online and SharePoint to be able to limit browser access while using an unmanaged device. The policy on that platform is set, however, as mentioned earlier, we need to be able to enforce this using conditional access policies. Let’s do that now.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA016: Restrict Browser Access to Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: Office 365
• Exclude: None



• Under Conditions:
• Client Apps → Browser: Checked



• Under Grant: No changes needed
• Under Sessions:
• Use app enforced restrictions: Checked

Incognito Mode and Browser Extensions

One important item to call out is that your users can continue to have issues even though their device is compliant or Hybrid Azure AD Joined. This is because certain browsers don’t have the functionality built-in to send the device payload so the CA policy can properly evaluate it.
 

• Edge: Functionality is built-in so testing with Edge is always recommended
• Chrome: Windows 10 accounts extension is required for Chrome v111+
• FireFox: FireFox Windows SSO is required
• Incognito Mode: extensions should be abled for incognito mode as well

If you’re STILL having issues after ensure your device is in the proper state and you have the proper extensions installed, one thing that I’ve learned is clear the cache and cookies and that resolves most of the issues.
 

Conclusion

Hopefully this article on how to limit or restrict browser access to Microsoft 365 apps as well as block unmanaged devices using conditional access was insightful. This should help add a bit more strength to your overall security posture so that’s always a good thing.
 

This policy is very powerful so you need to make sure you do some thorough testing before enabling the policy globally. Another policy I would highly recommend is to Enable Authentication Strengths Using Conditional Access so you can set higher profile apps to use phishing resistant MFA.

The post Block Unmanaged Devices Using Conditional Access appeared first on the Sysadmin Channel.

Requirements

In order to have successful results, you will need the following.

• Exchange Administrator Permissions -or Global Administrator Permissions
• Audit Logs Enabled. Specifically Mailbox Audit logs
• Exchange Online Management PowerShell Module

Get Recipient Permissions to See Who Has Access

Before we dive deep into the logs, I always like to narrow down my search by simply seeing who has access to send as that specific account. If there are only 1-2 users who have access, this narrows things down pretty well. If there are a dozen or more, then things might get a little tricky and we’ll need to go into logs.
 

Let’s check to see who has permissions and see if we get lucky. To find this, we’re going to use the Get-RecipientPermission cmdlet from the ExchageOnlineManagement module.

Get-RecipientPermission testmailbox -AccessRights SendAs | Where-Object {$_.Trustee -ne 'NT AUTHORITY\SELF'}

Identity     Trustee                     AccessControlType AccessRights Inherited
--------     -------                     ----------------- ------------ ---------
Test Mailbox paul@thesysadminchannel.com Allow             {SendAs}     False

In some scenarios it very well may be possible that the account itself sent the email, but for the sake of this article we’re going to assume someone sent an email with the sendas permissions. Therefore we added the where clause to not include SELF.

Find Account That Sent Emails From Shared Mailbox

In the example above, we can see that only one account has access to send as the shared mailbox so it’s pretty much a no brainer in this scenario. However, as I mentioned before, some shared mailboxes (or regular mailboxes for that matter) can have multiple people with this access right.
 

In order to find the exact user, let’s look to the logs and see what they say. Logs never lie!

$SendAs = Search-MailboxAuditLog -Identity testmailbox -Operations SendAs -ShowDetails
$Sendas | select LogonUserDisplayName, ClientProcessName, ItemSubject, OperationResult, LastAccessed


LogonUserDisplayName : Paul Contreras
ClientProcessName    :
ItemSubject          : The Force
OperationResult      : Succeeded
LastAccessed         : 9/14/2023 8:37:38 PM

Conclusion

In this case the recipient permissions pretty much gave it away as I was the only one with permissions. However, being able to search in the mailbox audit logs will show us EXACTLY which was the account that sent this email. Hopefully this was informative for you and you’re able to find out who sent emails from shared mailbox.

The post Find Account That Sent Emails From Shared Mailbox using PowerShell appeared first on the Sysadmin Channel.

Requirements

In order for you to get all of the synced organizational units as well as the synced attributes, there are a few things you must have in place. First things first, you need to have a supported version of Azure AD Connect installed. Since AAD Connect should be in a tier 0 security configuration, you may need to run this locally on the machine itself.

Get Synced OU Configuration in Azure AD Connect using PowerShell

If you have an Active Directory OU structure that’s pretty dense it may be challenging to figure out what exactly is being synced and what is not. My lab is pretty simple and straight forward but here are the organizational units that are synced and what’s shown from the GUI.

 
Let’s get this same information from PowerShell. Remember you will need to be logged in to the active AAD Connect server since that’s what is actually being synced to Azure AD.

#Get Connect information for your on-premises domain.
$SyncConnector = Get-ADSyncConnector | Where-Object {$_.Name -notmatch ' - aad'}

#Get OU inclusion list
$SyncConnector.Partitions.ConnectorPartitionScope.ContainerInclusionList

#Get OU exclusion list
$SyncConnector.Partitions.ConnectorPartitionScope.ContainerExclusionList

As you can see from the images above, the only OU I am syncing to Azure AD is the “Home” OU. I do have a few sub organizational units that are excluded from sync and that’s also shown in the PowerShell image. Hopefully this will paint a pretty picture when you need to see which OUs are synced.

Get Synced Attributes using PowerShell

If you need to get what attributes are syncing, there’s a way to get that information using PowerShell as well. Not all attributes will show with an Azure AD attribute, but this is a good start to see what’s there and what’s not.
 

It is important to note that attributes syncing from your on-premises Active Directory will not show up exactly the same in Azure AD. Therefore, we will show the on-premises sync connector as well as the Azure AD sync connector. This is key if you have custom mappings or have enabled directory extension attributes to use for custom claims.

#Get attributes syncing from on-premises Active Directory
$SyncConnector = Get-ADSyncConnector | Where-Object {$_.Name -notmatch ' - aad'}
$SyncConnector.AttributeInclusionList


#Get attributes syncing to Azure Active Directory
$SyncConnector = Get-ADSyncConnector | Where-Object {$_.Name -match ' - aad'}
$SyncConnector.AttributeInclusionList

Conclusion

Hopefully this article was able to show you how to get synced OU configuration in Azure AD Connect PowerShell as well as the attributes that are currently synced. This is pretty handy because when you open up the Azure AD Connect application, sync is temporarily disabled until the wizard is closed.
 

Being able to gather this information using PowerShell helps solve that problem so you can run it at anytime. If you would like to see more sysadmin content, be sure to check out our YouTube Channel

The post Get Synced OU Configuration in Azure AD Connect PowerShell appeared first on the Sysadmin Channel.

This is great because Logic Apps can provide an endless possibility of automation workflows using built-in connectors. If you prefer to run code to handle the automation, there’s a connector for Azure Automation and even Function Apps.

Requirements

Whether you’re creating the very first custom extension or adding additional extensions to your catalog, there are a few things in place you will need so everything runs smoothly. Let’s touch on those items now.
 

First things first, you’ll need to have an Azure Resource Group created so you can host your newly created Logic Apps. It would be preferred to be an owner of that RG so you can grant permissions to the Managed Identities you will eventually create with your LA.
 

If you prefer to use Logic Apps as the conduit to other automation platforms like Azure Automation or Function Apps, the Logic App Managed Identity will need the appropriate permissions to that resource. For these use cases, I personally like to have my Logic Apps, Function Apps and automation runbooks under the same resource group.

Create The First Custom Extension

If this is the first time you’ve ever created a custom extension for an Entitlement Management access package then you’re definitely in luck. We’ll walk through the steps on exactly how to do that.
 
Within the Catalog:

• Click on Custom extensions
• Add a new custom extension

• Enter a name and description that best describes what the custom extension will be doing

• Select the option if you want to run the request workflow or pre-expiration

• Select the option if you want to launch and continue or launch and wait

• Select Yes to create a logic app
• Select the Azure subscription and resource group
• Enter a name that describes the process (I like to have the same name as the extension)
• Click create a logic app
• Click next to review and create

Importing a Custom Extension on a Different Catalog

Organizing your catalogs by processes or by teams is important for keeping everything in order, but what if you wanted to use the same workflow on a different catalog? By default there is not an “import” button that can magically create the same custom extension on a different catalog, however it is possible by simply creating a new extension on the catalog you want to run that Logic App in.
 

The steps to accomplish that are pretty much the same as above. You’ll need to create a custom extension, populate the fields just as you did before. The difference is in the details. Let’s take that a step further.

In the new catalog, under the details tab:

• Select no to create a logic app
• Select the same subscription and resource group that the Logic App is hosted in
• Under the Logic App drop down menu, select the previously created LA
• Select next to review and create

View The Logic App And Create A Workflow

Now that we know how to create and import an existing custom extension created by Entitlement Management, let’s look into accessing it so we can outline what exactly we want it to do.
 

On the custom extensions page, click on the link to the Logic App.

 

This should take you to the Logic App itself where you can modify everything as needed. We won’t cover the details of the logic app workflow here since that’s a whole another platform to discuss, however, I will note that there have been significant improvements for the overall process.
 

Not only is it much more secure (we’ll touch on that in a bit), but there are also many more properties available in the payload going to the logic app. An example of this is if you’re asking questions in the package, the answers are now available by default.

 

Regarding the security improvements, this is fantastic because it now uses an Azure AD Proof-of-Possession token that mitigates against token theft. Here is a snippet from the GitHub Page

 

If you click on the Authorization page on the left pane, you can see how it’s setup. Here’s an outline of what mine looks like. Note: This is added by default so no need to modify anything 🙂

Apply the Logic App to an Access Package

Assuming you’ve already done the work to update the logic app to your liking, we’re now in a place where we can apply the the custom extension to an access package so let’s touch on how to do that.
 

First, You’ll need to create an access package along with the assignment policy under the catalog where you’ve created/imported your logic app. At the end of the wizard you should see the option to add a custom extension.

Those specific stages are:

• Request is created
• Request is approved
• Assignment is granted
• Assignment is about to expire in 14 days
• Assignment is about to expire in 1 day
• Assignment is removed

Each stage has its purpose so you definitely have the flexibility extend a process around a specific stage. In my sample above, I set the action to run EM Cool Process to run when assignment has been granted.

Conclusion

Hopefully you now have a great understanding on how to create custom extensions in Entra Identity Governance. As someone who uses this in the real world, this is one of the features I love the most about Azure AD because it’s so versatile and allows you to implement a self service framework without the hassle of maintaining a frontend or backend. It’s built into the tool.

The post Create Custom Extensions in Entra Identity Governance appeared first on the Sysadmin Channel.

Requirements

If you’ve implemented MFA across the entire org or you’re just about to go down that path it is important to know there are tools and licenses you should have in place to make the experience a much better one. Let’s touch on those a bit now.
 

While Azure AD P2 licenses are preferred, having a P1 license will grant you access to conditional policies, Log Analytics and other Azure AD features. Technically all you need is a single P2 license to enable these features however, all users that are using the features should be licensed for it.

What NOT to do if Azure MFA Keeps Prompting

Before we go into detail on what MFA prompt frequency best practices are and what we can do suppress them, let’s take some time to discuss what we should NOT be doing. These “don’ts” are called out because of the security implications it can have on your AAD environment.
 

I see it time and time again when scrolling through Twitter, Reddit or other articles, people recommend whitelisting their office public IP addresses as a way to bypass MFA. After all, if you’re in a building that probably requires a badge to gain access, we should be good right? WRONG!
 

Tailgating does happen in the wild and if you set policies to bypass MFA for people in the office, you have effectively punched security holes into your environment. Aside from that, many office buildings have guest wi-fi networks for their visitors that someone can easily connect to. If the guest network is configured to use the same outbound public IP as the corporate network, you’ve just opened yourself up to a potential world of hurt. If that still doesn’t convince you, figuring out how to spoof a public IP address is just a Google search away so these methods should be avoided at all costs.
 

Another setting we want to avoid is to keep the “remember multi-factor authentication on trusted device” setting enabled in the legacy Azure service settings portal. While it does what it says and reduces the number of MFA prompts you will get, it is not the best approach for what we are trying to accomplish. Microsoft also calls this out on their documentation.

I should also mention that requiring an MFA prompt for every sign in, or otherwise purposely overly prompting for MFA can be just as bad. When someone is constantly getting prompted for MFA, they tend to become numb to the process and mindlessly hit approve. There are ways to mitigate MFA fatigue attacks by implementing MFA number matching but the point still stands. More MFA prompts does not equate to more security.
 

To summarize, here is what we should NOT be doing to reduce MFA prompts in Azure AD:

• Do NOT whitelist public IPs to bypass MFA
• Do NOT enable remember multi-factor authentication on trusted device
• Do NOT purposely over prompt for MFA

Authentication Prompts Analysis: See Whos Is Getting Prompted for MFA

Azure AD is a platform that can be used as a 100% cloud only solution for your users, or a hybrid solution if you’re still maintaining an On-Premises environment. With that said, it also comes equipped with its own audit logging and monitoring tools (when you have Azure AD P1/P2 licenses) so we can use Azure AD workbooks to get insights on who is actually getting prompted for MFA and what applications are prompting them.
 

Azure AD has done all of the hard work for you and conveniently created an authentication prompts analysis workbook.
To access it:

• Navigate to Azure AD → Workbooks
• Select Authentication Prompts Analysis workbook

If you have time I would highly suggest you take a look at the data. My only suggestion for the workbook would be that they remove “Windows Sign In” attempts since that can kind of skew the data. Windows Sign In is when a user signs in their Windows device so this will not require MFA. However, the workbook lays out several categories for prompts.

Those include:

• Authentication prompts by authentication method
• Authentication prompts by device
• Authentication prompts by user
• Authentication prompts by application
• Authentication prompts by process detail

How to Reduce MFA Prompts in Azure AD

Now that we’ve covered who is getting prompted for MFA and more importantly, what NOT to do, let’s focus on what we should be doing and the best practices for how to reduce MFA prompts in Azure AD. Remember, Azure AD is the Identity Provider (IdP) so this applies to all Azure AD cloud applications. If Office 365 MFA prompts every time, this will ensure the prompts are significantly lowered when implemented successfully.

Windows Hello for Business

If you’re looking for best practices to reduce MFA Prompts in Azure AD, Windows Hello for Business is by far the BEST way to securely accomplish this. With Windows Hello for Business enabled, you’re always using strong authentication and the MFA claims are satisfied automatically.
 

This is because when you sign in with WH4B, a Primary Refresh Token (PRT) gets generated at that initial sign in and is presented to all other Azure AD applications when they’re accessed. This allows for a truly seamless SSO experience and even better, it provides a fantastic user experience. If you’ve never heard of a PRT, I would highly suggest you take the time to learn more about Primary Refresh Tokens. The documentation for this is phenomenal.
 

Windows 10 Accounts Chrome extension

While Edge handles this capability natively in the browser, It strongly recommended that those hard chargers using Google Chrome have the Windows 10 Accounts Chrome extensions deployed on their machine. If you are NOT using Windows Hello for Business, you will need to MFA to that initial application which will create a PRT that can be used on any subsequent applications.
 

If you ARE using WH4B, you will still need to deploy this plugin because Chrome doesn’t natively support a Primary Refresh Token. As an optional step, you can enable this in incognito mode so users can continue to use their PRT while in private-mode. Again, Microsoft Edge handles this natively but this is good to know.
 

Finally, and probably more importantly, in order to successfully create PRT, the devices will need to be at a minimum Azure AD registered. Non registered devices will not be given a PRT so those devices will continue to be prompted.

Enterprise SSO for Apple Devices

We’ve covered what to do for Windows devices, but what is the recommendation for MacOS and iOS devices? After all, it is quite common to see an organization operate with a mix of Apple, Windows and Linux devices in their environment. The answer is Enterprise SSO for Apple devices. There a few requirements that are listed in the documentation so we’ll summarize that here.
 

An important item to note is if your primary MDM solution is not Microsoft Intune, you will need to deploy the SSO extension AND ensure your device is enrolled in Intune. It doesn’t have to be managed by Intune, but it must be enrolled so Azure can see the device.

Conclusion

Hopefully this article was able to provide useful insight on how to reduce the number of MFA prompts using secure best practices. Remember, the goal is to require strong authentication all the time, on every application. However, the trick is to use these methods listed above so MFA requirements are satisfied and you’re no longer being prompted.
 

I personally use Windows Hello for Business and I am prompted once every several months on my standard account because my MFA requirement is already satisfied by claim in the token.

The post Securely Reduce MFA Prompts in Azure AD appeared first on the Sysadmin Channel.

Requirements

In order to run this, there are a few things that need to be in place to ensure we don’t run into any errors. Let’s touch on those item now.
 

• Directory.Read.All Permissions
• Application.Read.All Permissions
• Microsoft.Graph PowerShell SDK Module

Check an App Registration for Expired Keys in Azure Portal

Before we get into the PowerShell script, let’s take a look at how to check this manually so we know exactly what to expect when looking at the results of the script.
 

Within Azure AD:

• Navigate to App Registrations
• Select an App that has a certificate or secret added

• Go to Certificates & secrets blade

Here we can see the status of the certificate for this specific application. Specifically, we’re interested in the expiration date, certificate thumbprint and Key ID (certificate ID).
 

While the portal does give you a visual of when keys are expiring, it still requires you to take time out of your day to manually check. Let’s take a look at how we can accomplish the same thing automatically using the PowerShell script I wrote.

Get Application Certificate and Secret Expiration with Graph API PowerShell

Now that we’ve gone over the manual method, let’s use PowerShell and Graph API to our advantage and show the same information in an automated fashion. Since we know how to automate Powershell Scripts With Task Scheduler, we can schedule this on a daily basis and let it alert you without any additional effort on your end.
 

Now for the PowerShell script:

Function Get-MgApplicationCertificateAndSecretExpiration {
<#
.SYNOPSIS
    This will display all Applications that have certificates or secrets expiring within a certain timeframe


.NOTES
    Name: Get-MgApplicationCertificateAndSecretExpiration
    Author: Paul Contreras
    Version: 1.3
    DateCreated: 2022-Feb-8

.LINK
    https://thesysadminchannel.com/get-application-certificate-and-secret-expiration-with-graph-api-powershell -

.EXAMPLE
    Get-MgApplicationCertificateAndSecretExpiration

.EXAMPLE
    Get-MgApplicationCertificateAndSecretExpiration -ShowExpiredKeys
#>

    [CmdletBinding(DefaultParameterSetName='Default')]
    param(
        [Parameter(
            Mandatory = $false,
            ParameterSetName = 'CertOnly'
        )]
        [switch]    $ShowOnlyCertificates,

        [Parameter(
            Mandatory = $false,
            ParameterSetName = 'SecretOnly'
        )]
        [switch]    $ShowOnlySecrets,


        [Parameter(
            Mandatory = $false
        )]
        [switch]    $ShowExpiredKeys,


        [Parameter(
            Mandatory = $false
        )]
        [ValidateRange(1,720)]
        [int]    $DaysWithinExpiration = 30,


        [Parameter(
            Mandatory = $false,
            ValueFromPipeline = $true,
            ValueFromPipelineByPropertyName = $true
        )]
        [Alias('ApplicationId', 'ClientId')]
        [string]    $AppId
    )

    BEGIN {
        $ConnectionGraph = Get-MgContext
        if (-not $ConnectionGraph) {
            Write-Error "Please connect to Microsoft Graph" -ErrorAction Stop
        }
        #Adding an extra day to account for hour differences and offsets.
        $DaysWithinExpiration++
    }

    PROCESS {
        try {
            if ($PSBoundParameters.ContainsKey('AppId')) {
                $ApplicationList = Get-MgApplication -Filter "AppId eq '$AppId'" -ErrorAction Stop
                $AppFilter = $true
            } else {
                $ApplicationList = Get-MgApplication -All -Property AppId, DisplayName, PasswordCredentials, KeyCredentials, Id -PageSize 999 -ErrorAction Stop
            }

            #If certs are selected, show certs
            if ($PSBoundParameters.ContainsKey('ShowOnlyCertificates') -or

                #If neither Certs or Secrets are selected show both.
               (-not $PSBoundParameters.ContainsKey('ShowOnlyCertificates') -and
                -not $PSBoundParameters.ContainsKey('ShowOnlySecrets'))) {

                    $CertificateApps  = $ApplicationList | Where-Object {$_.keyCredentials}

                    $CertApp = foreach ($App in $CertificateApps) {
                        foreach ($Cert in $App.keyCredentials) {
                            if ( $Cert.endDateTime -le (Get-Date).AddDays($DaysWithinExpiration) -or ($AppFilter) ) {
                                [PSCustomObject]@{
                                    AppDisplayName      = $App.DisplayName
                                    AppId               = $App.AppId
                                    KeyType             = 'Certificate'
                                    ExpirationDate      = $Cert.EndDateTime
                                    DaysUntilExpiration = (($Cert.EndDateTime) - (Get-Date) | select -ExpandProperty TotalDays) -as [int]
                                    ThumbPrint          = [System.Convert]::ToBase64String($Cert.CustomKeyIdentifier)
                                    Id                  = $App.Id
                                    KeyId               = $Cert.KeyId
                                    Description         = $Cert.DisplayName
                                }
                            }
                        }
                    }

                    if ($PSBoundParameters.ContainsKey('ShowExpiredKeys')) {
                        $CertApp | Sort-Object DaysUntilExpiration
                    } else {
                        $CertApp | Sort-Object DaysUntilExpiration | Where-Object {$_.DaysUntilExpiration -ge 0}
                    }
            }

            #If secrets are selected, show secrets
            if ($PSBoundParameters.ContainsKey('ShowOnlySecrets') -or

                #If neither Certs or Secrets are selected show both.
               (-not $PSBoundParameters.ContainsKey('ShowOnlySecrets') -and
                -not $PSBoundParameters.ContainsKey('ShowOnlyCertificates'))) {

                    $ClientSecretApps = $ApplicationList | Where-Object {$_.passwordCredentials}

                    $SecretApp = foreach ($App in $ClientSecretApps){
                        foreach ($Secret in $App.PasswordCredentials) {
                            if ( $Secret.EndDateTime -le (Get-Date).AddDays($DaysWithinExpiration) -or ($AppFilter) ) {
                                [PSCustomObject]@{
                                    AppDisplayName      = $App.DisplayName
                                    AppId               = $App.AppId
                                    KeyType             = 'ClientSecret'
                                    ExpirationDate      = $Secret.EndDateTime
                                    DaysUntilExpiration = (($Secret.EndDateTime) - (Get-Date) | select -ExpandProperty TotalDays) -as [int]
                                    ThumbPrint          = 'N/A'
                                    Id                  = $App.Id
                                    KeyId               = $Secret.KeyId
                                    Description         = $Secret.DisplayName
                                }
                            }
                        }
                    }

                    if ($PSBoundParameters.ContainsKey('ShowExpiredKeys')) {
                        $SecretApp | Sort-Object DaysUntilExpiration
                    } else {
                        $SecretApp | Sort-Object DaysUntilExpiration | Where-Object {$_.DaysUntilExpiration -ge 0}
                    }
            }
        } catch {
            Write-Error $_.Exception.Message
        }
    }

    END {}
}

Script Parameters

    No Parameters

DataType: N/A
Description: Gather all apps and display the ones that have a secret or certificate expiring within 30 days.
 

    -ShowOnlyCertificates

DataType: switch
Description: Only display certificates in the output. Expired keys and secrets will not be shown.
 

    -ShowOnlySecrets

DataType: switch
Description: Only display secrets in the output. Expired keys and certificates will not be shown.
 

    -ShowExpiredKeys

DataType: switch
Description: Display certificates or secrets are near expiration or have already expired.
 

    -DaysWithinExpiration

DataType: integer
Description: Set the time frame to include expiring keys. This is defaulted to 30 days.
 

    -AppId

DataType: string
Description: Specify an AppId (client Id) to see that specific applications keys.
 

Example 1 – Calling the script with no parameters

Since this is a function, you’ll need to dot source it to load it into memory. Assuming the file is your desktop you can run.

. $Home\Desktop\Get-MgApplicationCertificateAndSecretExpiration.ps1
Get-MgApplicationCertificateAndSecretExpiration

Using the default output, take a look at the KeyType, ExpirationDate, DaysUntilExpiration and ThumbPrint. Certificates will display a thumbprint while secrets will not.
 

Example 2 – Display Only Certificates that are expired or nearing expiration

Get-MgApplicationCertificateAndSecretExpiration -ShowOnlyCertificates -ShowExpiredKeys `
| Select-Object AppDisplayName, KeyType, ExpirationDate, DaysUntilExpiration, KeyId, ThumbPrint

If you recall Portal screenshot above, our “App Automation 1” application had an expired cert with the thumbprint starting in “2E8972E” and the Key ID (certificate ID) started with “6f395fd4”. This is the same information we can pull in PowerShell
 

Example 3 – Display Only secrets that are expiring within 5 days

Get-MgApplicationCertificateAndSecretExpiration -ShowOnlySecrets -DaysWithinExpiration 5
| Select-Object AppDisplayName, KeyType, ExpirationDate, DaysUntilExpiration

Conclusion

Hopefully this article was able to show you get an application certificate and secret expiration with Graph API. This is super useful to keep in your automation toolkit since the Azure world is now moving everything to Microsoft Graph.

The post Get Application Certificate and Secret Expiration with Graph API appeared first on the Sysadmin Channel.