Règles scriptées

Dans cette section :

À propos des règles scriptées

Les règles scriptées permettent de créer des règles personnalisées à l'aide de scripts Windows PowerShell ou VBScript. Le succès ou l'échec du script détermine si le niveau de sécurité, les éléments autorisés et les éléments refusés figurant dans la règle s'appliquent ou non à l'utilisateur.

Les règles scriptées peuvent exploiter toutes les interfaces accessibles via PowerShell or VBScript, par exemple COM (Component Object Model).

Chaque script est évalué dans les circonstances suivantes :

  • Déploiement d'une nouvelle configuration sur l'ordinateur.
  • Connexion d'un utilisateur.

Pour créer ou modifier des scripts, accédez à l'ensemble de règles scriptées requis dans l'éditeur de configuration Contrôle des applications. Ensembles de règles > Scripté > [Nom-ensemble-de-règles]

Vous pouvez définir le moment où le script doit être exécuté, à l'aide des options de règle scriptée suivantes :

  • Exécuter le script :
    • Par session en tant qu'utilisateur - Le script est exécuté pour chaque utilisateur qui se connecte. Les paramètres ne sont appliqués que pour la durée de la session utilisateur.
    • Par session en tant que Système - Le script est exécuté avec les permissions du compte SYSTEM une seule fois pour chaque utilisateur qui se connecte. Les paramètres ne sont appliqués que pour la durée de la session utilisateur.
    • Par ordinateur en tant que Système - Le script est exécuté avec les permissions du compte SYSTEM une seule fois au démarrage de l'ordinateur. Les paramètres sont appliqués à toutes les sessions utilisateur jusqu'au redémarrage de l'ordinateur, jusqu'au redémarrage de l'agent Contrôle des applications ou jusqu'à un changement de configuration.

    Attention : L'exécution de scripts en tant qu'utilisateur Système (SYSTEM) peut provoquer de sérieux dommages sur votre ordinateur et l'opération doit être réservée aux auteurs de script expérimentés.

  • Attendre la fin de la connexion - Sélectionnez cette option pour interdire l'exécution du script jusqu'à ce que la connexion soit établie.

Scripts VBScript

Chaque script est exécuté dans un moteur de script hébergé, ce qui permet un meilleur contrôle de l'exécution des scripts, tout en assurant un haut niveau de contrôle des entrées/sorties (E/S).

  • Aucun fichier VBS n'est utilisé.
  • Aucun processus distinct n'est généré dynamiquement.

Le script doit être écrit sous forme de fonction et peut contenir de nombreuses fonctions, mais vous devez spécifier une fonction principale de démarrage. La fonction de démarrage est exécutée par l'agent Contrôle des applications et peut servir à appeler d'autres fonctions.

L'objet COM AMScriptRule est intégré au moteur de scripts et permet d'accéder aux méthodes suivantes :

  • strUsername = AMScriptRule.UserName
  • strUserdomain = AMScriptRule.UserDomain
  • strSessionid = AMScriptRule.SessionID
  • strStationname = AMScriptRule.WinStation

    Dans ce cas, la norme Microsoft veut que WinStation renvoie la valeur de nom de la session de services de terminal, qui dépend du type de la session. Les valeurs habituelles sont 'Console' ou 'RDP-Tcp#34', au lieu du nom de la station de travail Windows (généralement WinSta0).

L'objet COM AMScriptRule inclut aussi les méthodes suivantes :

  • strLog = AMScriptRule.Log "Mon instruction de journal"

    Permet de créer une sortie des chaînes de journalisation dans le fichier journal de l'agent, à utiliser avec les règles scriptées de débogage.

  • strEnvironmentvar = AMScriptRule.ExpandEnvironment ("%MyEnvironmentVariables%")

    Développe les variables d'environnement de l'utilisateur qui exécute le script.

L'utilisation du shell WScript pour développer les variables d'environnement renvoie uniquement les variables système (SYSTEM).

Scripts Windows PowerShell

Si le script se ferme avec la valeur 0, l'opération est un succès et les règles sont appliquées. Si le système envoie une valeur non nulle, le script échoue et les règles ne s'appliquent pas.

Chaque script PowerShell est exécuté dans une instance de PowerShell.exe et, par conséquent, Contrôle des applications n'applique ni n'ajoute aucune syntaxe spécifique. Toutes les instructions PowerShell au format correct fonctionnent.

PowerShell doit être installé sur tous les postes client qui vont utiliser le script.

Exemple de script

Le script VBScript suivant montre comment contrôler les applications auxquelles un utilisateur a accès.

Copier 
Function ScriptedRule()
’Name of Filter scan expected to pass
ExpectedFilter = "FWALL"
’Get Server Name
Set objNTinfo = CreateObject ("WinNTSystemInfo")
ServerName = lcase (objNTInfo.ComputerName)
’Set initial return value
ScriptedRule = False
’Create MetaFrame Session Object
Set MFSession = Createobject ("MetaFrameCOM.MetaFrameSession")
’Initialize the session filters for this session
For Each x in MFSession.SmartAccessFilters
’return true if our filter is found
If x = ExpectedFilter Then
ScriptedRule=True
AMScriptRule.Log "SmartAccessFilter match found."
End If
Next
End Function 

Vous pouvez utiliser le script VBScript suivant pour déterminer si un ordinateur se trouve dans une unité organisationnelle Ordinateur :

Copier 
Function ScriptedRule()
ScriptedRule = vbFalse
strCompName = AMScriptRule.StationName
Set oRootDSE = GetObject("LDAP://RootDSE")
strDNSDomain = oRootDSE.Get("DefaultNamingContext")
Set oOU = GetObject("LDAP://OU=TheOUyouAreSearching,OU=Parent,OU=Parent," & strDNSDomain)
oOU.GetInfo
For each member in oOU
    If UCase(strCompName) = UCase(member.CN) Then
        ScriptedRule = vbTrue
        Exit For
    End If
Next
End Function

L'exemple de script VBScript suivant montre les principaux composants d'un script et explique comment accéder aux informations concernant le nom de l'utilisateur qui se connecte au système, puis les mettre en correspondance avec un domaine et une unité organisationnelle spécifiques :

Copier 
Function MyScript()
'Get the username of the user logging in (also works when running as SYSTEM)
strUserName = AMScriptRule.UserName
'Get the domain of the user logging in (also works when running as SYSTEM)
strUserDomain = AMScriptRule.UserDomain
'Look up user environment variables (when running as SYSTEM, only SYSTEM variables are available)
strClientName = AMScriptRule.ExpandEnvironment ("%ClientName%")
'Log the output
AMScriptRule.Log strUserName & " logged in on " & strClientName
'Check if the user is a member of the domain
If strUserdomain = "MyDomain" Then
'If so, see if the user is in the MyOU OU
Set objOU = GetObject ("LDAP://ou=MyOU,dc=MyDomain,dc=com")
objOU.Filter = Array("user")
For Each objUser In objOU
'Check if there is a match with the user logging on
If objUser.sAMAccountName = strUserName Then
'if there is, then set the function to True
MyScript = True
End If
Next
End If
'Unless there is a username match, the function defaults to False
End Function

L'exemple de script Windows PowerShell suivant montre les principaux composants d'un script et explique comment accéder aux informations concernant le nom de l'utilisateur qui se connecte au système, puis les mettre en correspondance avec un domaine et une unité organisationnelle spécifiques :

Copier 
#Script checks if the current user is a member of the OU specified
# Return 0 if TRUE
# 1 otherwise
$logonuser = $env:username
$bindpt = [adsi] "LDAP://OU=TS_Users,OU=Users,OU=MyUser,OU=MyOU,DC=MyDomain,DC=com"
$users = New-Object System.DirectoryServices.DirectorySearcher $bindpt
$users.Filter = "(&(objectClass=User)(sAMAccountName=$logonuser))"
$obj = $users.FindOne()
if($obj -eq $null)
{
#" Not a Member"
exit 1
}

Rubriques connexes

Ensembles de règles

Collections de règles