Maîtriser PowerShell : Générer des rapports d’activité des utilisateurs Active Directory pour la gestion informatique

Points à retenir

• Rapports automatisés sur l’activité des utilisateurs AD: Le script automatise le processus de génération de rapports sur l’activité des utilisateurs Active Directory.
• Période personnalisable: Les utilisateurs peuvent spécifier le nombre de jours pour la surveillance de l’activité à l’aide du paramètre -NumberOfDays.
• Exclusion des utilisateurs désactivés: Le script comporte une option permettant d’exclure les utilisateurs désactivés du rapport afin d’obtenir des données plus précises.
• Intégration facile : Il s’intègre bien à l’infrastructure informatique existante, en particulier pour les entreprises MSP et les professionnels de l’informatique.
• Amélioration de la sécurité et de la conformité: Il fournit des données essentielles pour les audits de conformité et le contrôle de la sécurité.
• Efficacité par rapport aux méthodes manuelles: Il est bien plus efficace que les méthodes manuelles de suivi de l’activité des utilisateurs.
• Informations exploitables: Il fournit des informations exploitables sur les habitudes de connexion des utilisateurs et l’activité des comptes.
• Compatibilité avec NinjaOne: Il complète des outils tels que NinjaOne, en améliorant la gestion informatique et les capacités de reporting.
• Flexibilité du script: Offre des options de personnalisation pour divers environnements et exigences informatiques.

Introduction

Active Directory (AD) est un pilier de l’infrastructure informatique des entreprises. Il gère et authentifie les identités des utilisateurs et l’accès aux ressources du système. La compréhension de l’activité des utilisateurs dans AD est cruciale pour la sécurité et l’efficacité. Cela nous amène à l’importance des scripts PowerShell pour extraire des données significatives d’AD, et un script en particulier qui rend compte des utilisateurs actifs dans une période donnée.

Contexte

Le script en question est destiné aux professionnels de l’informatique et aux fournisseurs de services gérés (MSP) qui ont besoin d’une vue claire de l’activité des utilisateurs Active Directory. Il s’agit d’un script PowerShell, un outil puissant d’automatisation des tâches administratives de Windows. Ce script génère spécifiquement un rapport détaillant le nombre d’utilisateurs Active Directory actifs qui se sont connectés au cours d’une période donnée. Ces informations sont précieuses pour les pistes d’audit, la conformité, la surveillance de la sécurité et la gestion des comptes d’utilisateurs.

Le script :

#Requires -Version 5.1

<#
.SYNOPSIS
    Generates a report for the number of active users in active directory that have logged in the specified time frame.
.DESCRIPTION
    Generates a report for the number of active users in active directory that have logged in the specified time frame.

.EXAMPLE
    (No Parameters)
    
    Number of active users: 2
    Total users (including active and inactive): 5
    Percent Active: 40%

    SamAccountName UserPrincipalName   mail           LastLogonDate      
    -------------- -----------------   ----           -------------      
    kbohlander     [email protected]                6/5/2023 8:58:20 AM
    tuser          [email protected]      [email protected] 6/6/2023 8:30:23 AM

PARAMETER: -NumberOfDays "ReplaceWithAnumber"
    How long ago in days to report on.
.EXAMPLE
    -NumberOfDays "1" (If today was 6/7/2023)
    
    Number of active users: 2
    Total users (including active and inactive): 5
    Percent Active: 40%

    SamAccountName UserPrincipalName   mail           LastLogonDate      
    -------------- -----------------   ----           -------------      
    tuser          [email protected]      [email protected] 6/6/2023 8:30:23 AM

PARAMETER: -ExcludeDisabledUsers
    Excludes the user from the report if they're currently disabled.

PARAMETER: -CustomFieldName "ReplaceMeWithAnyMultilineCustomField"
    Name of a multiline custom field to save the results to.
.EXAMPLE
    -CustomFieldName "ReplaceMeWithAnyMultilineCustomField"
    
    Number of active users: 2
    Total users (including active and inactive): 5
    Percent Active: 40%

    SamAccountName UserPrincipalName   mail           LastLogonDate      
    -------------- -----------------   ----           -------------      
    kbohlander     [email protected]                6/5/2023 8:58:20 AM
    tuser          [email protected]      [email protected] 6/6/2023 8:30:23 AM
.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016
    Release Notes: Renamed script and added Script Variable support
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
#>

[CmdletBinding()]
param (
    [Parameter()]
    [int]$NumberOfDays = 30,
    [Parameter()]
    [String]$CustomFieldName,
    [Parameter()]
    [Switch]$ExcludeDisabledUsers = [System.Convert]::ToBoolean($env:excludeDisabledUsersFromReport)
)

begin {
    # Tests for administrative rights which is required to get the last logon date.
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        $p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
    }

    # Tests if the device the script is running on is a dmona controller.
    function Test-IsDomainController {
        return $(Get-CimInstance -ClassName Win32_OperatingSystem).ProductType -eq 2
    }

    # This function is to make it easier to set Ninja Custom Fields.
    function Set-NinjaProperty {
        [CmdletBinding()]
        Param(
            [Parameter(Mandatory = $True)]
            [String]$Name,
            [Parameter()]
            [String]$Type,
            [Parameter(Mandatory = $True, ValueFromPipeline = $True)]
            $Value,
            [Parameter()]
            [String]$DocumentName
        )

        # If we're requested to set the field value for a Ninja document we'll specify it here.
        $DocumentationParams = @{}
        if ($DocumentName) { $DocumentationParams["DocumentName"] = $DocumentName }

        # This is a list of valid fields we can set. If no type is given we'll assume the input doesn't have to be changed in any way.
        $ValidFields = "Attachment", "Checkbox", "Date", "Date or Date Time", "Decimal", "Dropdown", "Email", "Integer", "IP Address", "MultiLine", "MultiSelect", "Phone", "Secure", "Text", "Time", "URL"
        if ($Type -and $ValidFields -notcontains $Type) { Write-Warning "$Type is an invalid type! Please check here for valid types. https://ninjarmm.zendesk.com/hc/en-us/articles/16973443979789-Command-Line-Interface-CLI-Supported-Fields-and-Functionality" }

        # The below field requires additional information in order to set
        $NeedsOptions = "Dropdown"
        if ($DocumentName) {
            if ($NeedsOptions -contains $Type) {
                # We'll redirect the error output to the success stream to make it easier to error out if nothing was found or something else went wrong.
                $NinjaPropertyOptions = Ninja-Property-Docs-Options -AttributeName $Name @DocumentationParams 2>&1
            }
        }
        else {
            if ($NeedsOptions -contains $Type) {
                $NinjaPropertyOptions = Ninja-Property-Options -Name $Name 2>&1
            }
        }

        # If we received some sort of error it should have an exception property and we'll exit the function with that error information.
        if ($NinjaPropertyOptions.Exception) { throw $NinjaPropertyOptions }

        # The below type's require values not typically given in order to be set. The below code will convert whatever we're given into a format ninjarmm-cli supports.
        switch ($Type) {
            "Checkbox" {
                # While it's highly likely we were given a value like "True" or a boolean datatype it's better to be safe than sorry.
                $NinjaValue = [System.Convert]::ToBoolean($Value)
            }
            "Date or Date Time" {
                # Ninjarmm-cli is expecting the time to be representing as a Unix Epoch string. So we'll convert what we were given into that format.
                $Date = (Get-Date $Value).ToUniversalTime()
                $TimeSpan = New-TimeSpan (Get-Date "1970-01-01 00:00:00") $Date
                $NinjaValue = $TimeSpan.TotalSeconds
            }
            "Dropdown" {
                # Ninjarmm-cli is expecting the guid of the option we're trying to select. So we'll match up the value we were given with a guid.
                $Options = $NinjaPropertyOptions -replace '=', ',' | ConvertFrom-Csv -Header "GUID", "Name"
                $Selection = $Options | Where-Object { $_.Name -eq $Value } | Select-Object -ExpandProperty GUID

                if (-not $Selection) {
                    throw "Value is not present in dropdown"
                }

                $NinjaValue = $Selection
            }
            default {
                # All the other types shouldn't require additional work on the input.
                $NinjaValue = $Value
            }
        }

        # We'll need to set the field differently depending on if its a field in a Ninja Document or not.
        if ($DocumentName) {
            $CustomField = Ninja-Property-Docs-Set -AttributeName $Name -AttributeValue $NinjaValue @DocumentationParams 2>&1
        }
        else {
            $CustomField = Ninja-Property-Set -Name $Name -Value $NinjaValue 2>&1
        }

        if ($CustomField.Exception) {
            throw $CustomField
        }
    }

    # Todays date
    $Today = Get-Date

    if ($env:numberOfDaysToReportOn -and $env:numberOfDaysToReportOn -notlike "null") { $NumberOfDays = $env:numberOfDaysToReportOn }
    if ($env:customFieldName -and $env:customFieldName -notlike "null") { $CustomFieldName = $env:customFieldName }
}
process {
    # Erroring out when ran without administrator rights
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }

    # Erroring out when ran on a non-domain controller
    if (-not (Test-IsDomainController)) {
        Write-Error -Message "The script needs to be run on a domain controller!"
        exit 1
    }

    # If disabled users are to be excluded we're going to fetch different properties and Filter out disabled users
    if ($ExcludeDisabledUsers) {
        $Users = Get-ADUser -Filter * -Properties SamAccountName, UserPrincipalName, mail, LastLogonDate, Enabled | 
            Where-Object { $_.Enabled -eq $True }
        $ActiveUsers = Get-ADUser -Filter { LastLogonDate -ge 0 } -Properties SamAccountName, UserPrincipalName, mail, LastLogonDate, Enabled |
            Where-Object { (New-TimeSpan $_.LastLogonDate $Today).Days -le $NumberOfDays -and $_.Enabled -eq $True } |
            Select-Object SamAccountName, UserPrincipalName, mail, LastLogonDate
    }
    else {
        $Users = Get-ADUser -Filter * -Properties SamAccountName, UserPrincipalName, mail, LastLogonDate
        $ActiveUsers = Get-ADUser -Filter { LastLogonDate -ge 0 } -Properties SamAccountName, UserPrincipalName, mail, LastLogonDate |
            Where-Object { (New-TimeSpan $_.LastLogonDate $Today).Days -le $NumberOfDays } |
            Select-Object SamAccountName, UserPrincipalName, mail, LastLogonDate
    }

    # Creating a generic list to start assembling the report
    $Report = New-Object System.Collections.Generic.List[string]

    # Actual report assembly each section will be print on its own line
    $Report.Add("Active users: $(($ActiveUsers | Measure-Object).Count)")
    $Report.Add("Total users: $(($Users | Measure-Object).Count)")
    $Report.Add("Percent Active: $(if((($Users | Measure-Object).Count) -gt 0){[Math]::Round(($ActiveUsers | Measure-Object).Count / (($Users | Measure-Object).Count) * 100, 2)}else{0})%")

    # Set's up table to use in the report
    $Report.Add($($ActiveUsers | Format-Table | Out-String))

    if ($ActiveUsers) {
        # Exports report to activity log
        $Report | Write-Host

        if ($CustomFieldName) {
            # Saves report to custom field.
            try {
                Set-NinjaProperty -Name $CustomFieldName -Value ($Report | Out-String)
            }
            catch {
                # If we ran into some sort of error we'll output it here.
                Write-Error -Message $_.ToString() -Category InvalidOperation -Exception (New-Object System.Exception)
                exit 1
            }
        }
    }
    else {
        Write-Error "[Error] No active users found!"
        exit 1
    }
}
end {
    
    
    
}

 

Description détaillée

Le texte est structuré en plusieurs sections :

• Paramètres : Il accepte des paramètres tels que le nombre de jours de recherche pour les utilisateurs Active Directory actifs, un nom de champ personnalisé pour l’enregistrement des résultats et une option permettant d’exclure les utilisateurs désactivés.
• Préparation: Il vérifie les conditions nécessaires telles que les droits d’administrateur et la présence d’un contrôleur de domaine.
• Collecte de données sur les utilisateurs: Il utilise les cmdlets Active Directory (Get-ADUser) pour collecter des données sur les utilisateurs en fonction des paramètres spécifiés.
• Génération de rapports: Il crée un objet de liste et le remplit avec des données sur les utilisateurs, en calculant les utilisateurs actifs, le nombre total d’utilisateurs et le pourcentage d’utilisateurs actifs.
• Gestion des résultats: Le script affiche le rapport sur la console ou l’enregistre dans un champ personnalisé à l’aide de la fonction Set-NinjaProperty.

Cas d’utilisation potentiels

Imaginez un administrateur informatique d’une grande entreprise qui doit régulièrement vérifier l’activité des utilisateurs pour s’assurer de la conformité de la sécurité. Il peut programmer l’exécution mensuelle de ce script, ce qui permet d’avoir une vision claire des connexions des utilisateurs et d’identifier les comptes inactifs ou les schémas d’activité inhabituels.

Comparaisons

D’autres méthodes, comme les vérifications manuelles ou l’utilisation d’outils basés sur une interface graphique, prennent du temps et sont moins efficaces que les scripts PowerShell. Les scripts peuvent être automatisés et personnalisés, et ils traitent plus rapidement les grands ensembles de données.

FAQ

• Comment puis-je personnaliser la période de temps du rapport ?
  • Utilisez le paramètre -NumberOfDays pour définir la période souhaitée.

• Le script peut-il exclure les utilisateurs désactivés ?
  • Oui, utilisez le commutateur -ExcludeDisabledUsers.

• Est-il possible de sauvegarder le rapport à des fins de documentation ?
  • Oui, utilisez le paramètre -CustomFieldName pour enregistrer le rapport dans un champ personnalisé.

Implications

Les résultats de ce script peuvent être utiles pour identifier les risques de sécurité tels que les comptes d’utilisateurs périmés ou les schémas de connexion irréguliers. Il permet également de garantir la conformité avec les différentes politiques et réglementations informatiques.

Recommandations

• Planifiez régulièrement le script pour une surveillance constante.
• Exécutez toujours le script avec les autorisations appropriées.
• Utilisez les options de personnalisation pour adapter le rapport à vos besoins spécifiques.

Conclusion :

Dans le contexte de NinjaOne, une plateforme connue pour ses grandes capacités de gestion informatique, ce script complète ses fonctionnalités en fournissant des informations détaillées sur l’activité des utilisateurs Active Directory. C’est un exemple parfait de la façon dont les scripts PowerShell peuvent améliorer les fonctionnalités d’outils de gestion informatique complets tels que NinjaOne, en offrant des informations plus approfondies et des capacités d’automatisation.