Améliorations de la sécurité DCOM dans Windows XP Service Pack 2 et Windows Server 2003 Service Pack 1

Windows Server XP Service Pack 2 (SP2) et Windows Server 2003 Service Pack 1 (SP1) introduisent des paramètres de sécurité par défaut améliorés pour le modèle DCOM (Distributed Component Object Model). Plus précisément, ils introduisent des droits plus granulaires qui permettent à un administrateur d’avoir un contrôle indépendant sur les autorisations locales et distantes pour le lancement, l’activation et l’accès aux serveurs COM.

Que fait DCOM ?

Le modèle COM (Microsoft Component Object Model) est un système orienté objet indépendant de la plateforme, distribué et qui permet de créer des composants logiciels binaires qui peuvent interagir. Le modèle DCOM (Distributed Component Object Model) permet aux applications d’être distribuées entre les emplacements les plus pertinents pour vous et pour l’application. Le protocole filaire DCOM prend en charge en toute transparence une communication fiable, sécurisée et efficace entre les composants COM.

À qui cette fonctionnalité s'adresse-t-elle ?

Si vous utilisez COM uniquement pour les composants COM in-process, cette fonctionnalité ne s’applique pas à vous.

Cette fonctionnalité s’applique à vous si vous avez une application serveur COM qui répond à l’un des critères suivants :

• L’autorisation d’accès pour l’application est moins stricte que l’autorisation de lancement, qui est nécessaire pour exécuter l’application.
• L’application est généralement activée par un client COM distant sans utiliser de compte d’administration.
• L’application est destinée à être utilisée uniquement localement. Cela signifie que vous pouvez restreindre votre application serveur COM afin qu’elle ne soit pas accessible à distance.

Quelles sont les nouvelles fonctionnalités ajoutées à cette fonctionnalité dans Windows XP Service Pack 2 et Windows Server 2003 Service Pack 1 ?

Restrictions à l’échelle de l’ordinateur

Une modification a été apportée dans COM pour fournir des contrôles d’accès à l’échelle de l’ordinateur qui régissent l’accès à toutes les demandes d’appel, d’activation ou de lancement sur l’ordinateur. La façon la plus simple de penser à ces contrôles d’accès est un appel AccessCheck supplémentaire effectué sur une liste de contrôle d’accès (ACL) à l’échelle de l’ordinateur à chaque appel, activation ou lancement d’un serveur COM sur l’ordinateur. Si AccessCheck échoue, l’appel, l’activation ou la demande de lancement est refusé. Cela s’ajoute à tout Contrôle d’accès exécuté sur les listes de contrôle d’accès spécifiques au serveur. En effet, il fournit une norme d’autorisation minimale qui doit être transmise pour accéder à n’importe quel serveur COM sur l’ordinateur. Il existe une ACL à l’échelle de l’ordinateur pour les autorisations de lancement pour couvrir les droits d’activation et de lancement, et une ACL à l’échelle de l’ordinateur pour les autorisations d’accès pour couvrir les droits d’appel. Ceux-ci peuvent être configurés via la console MMC (Microsoft Management Console) des services de composants.

Ces listes de contrôle d’accès à l’échelle de l’ordinateur permettent de remplacer les paramètres de sécurité faibles spécifiés par une application spécifique via CoInitializeSecurity ou les paramètres de sécurité spécifiques à l’application. Cela fournit une norme de sécurité minimale qui doit être transmise, quels que soient les paramètres du serveur spécifique.

Ces listes de contrôle d’accès sont vérifiées lorsque les interfaces exposées par RPCSS sont consultées. Cela fournit une méthode pour contrôler l’accès à ce service système.

Ces listes de contrôle d’accès fournissent un emplacement centralisé où un administrateur peut définir une stratégie d’autorisation générale qui s’applique à tous les serveurs COM sur l’ordinateur.

Notes

La modification des paramètres de sécurité à l’échelle de l’ordinateur affecte toutes les applications serveur COM et peut les empêcher de fonctionner correctement. S’il existe des applications serveur COM qui ont des restrictions moins strictes que les restrictions à l’échelle de l’ordinateur, la réduction des restrictions à l’échelle de l’ordinateur peut exposer ces applications à des accès indésirables. À l’inverse, si vous augmentez les restrictions à l’échelle de l’ordinateur, certaines applications serveur COM peuvent ne plus être accessibles en appelant des applications.

Par défaut, les paramètres de restriction de l’ordinateur Windows XP SP2 sont les suivants :

Autorisation	Administrateur	Tout le monde	Anonyme
Lancer	Lancement local Activation locale Lancement distant Activation distante	Lancement local Activation locale
Access		Accès local Accès à distance	Accès local

Par défaut, les paramètres de restriction de l’ordinateur Windows Server 2003 SP 1 sont les suivants.

Autorisation	Administrateur	Utilisateurs COM distribués (groupe intégré)	Tout le monde	Anonyme
Lancer	Lancement local Activation locale Lancement distant Activation distante	Lancement local Activation locale Lancement distant Activation distante	Lancement local Activation locale	N/A
Access	N/A	Accès local Accès à distance	Accès local Accès à distance	Accès local Accès à distance

Notes

Utilisateurs COM distribués est un nouveau groupe intégré inclus dans Windows Server 2003 SP1 pour accélérer le processus d’ajout d’utilisateurs aux paramètres de restriction de l’ordinateur DCOM. Ce groupe fait partie de la liste de contrôle d’accès utilisée par les paramètres MachineAccessRestriction et MachineLaunchRestriction . Par conséquent, la suppression d’utilisateurs de ce groupe affecte ces paramètres.

En quoi cette modification est-elle importante ? Quelles menaces contribue-t-elle à limiter ?

De nombreuses applications COM incluent du code spécifique à la sécurité (par exemple, l’appel de CoInitializeSecurity), mais utilisent des paramètres faibles, ce qui autorise souvent l’accès non authentifié au processus. Il n’existe actuellement aucun moyen pour un administrateur de remplacer ces paramètres pour forcer une sécurité plus forte dans les versions antérieures de Windows.

L’infrastructure COM inclut le RPCSS, un service système qui s’exécute pendant le démarrage du système et qui s’exécute toujours après. Il gère l’activation des objets COM et de la table d’objets en cours d’exécution et fournit des services d’assistance pour la communication à distance DCOM. Il expose les interfaces RPC qui peuvent être appelées à distance. Étant donné que certains serveurs COM autorisent l’accès à distance non authentifié, ces interfaces peuvent être appelées par n’importe qui, y compris les utilisateurs non authentifiés. Par conséquent, RPCSS peut être attaqué par des utilisateurs malveillants sur des ordinateurs distants et non authentifiés.

Dans les versions antérieures de Windows, il n’y avait aucun moyen pour un administrateur de comprendre le niveau d’exposition des serveurs COM sur un ordinateur. Un administrateur a eu une idée du niveau d’exposition en vérifiant systématiquement les paramètres de sécurité configurés pour toutes les applications COM inscrites sur l’ordinateur, mais, étant donné qu’il y a environ 150 serveurs COM dans une installation par défaut de Windows, cette tâche était intimidante. Il n’y avait aucun moyen d’afficher les paramètres d’un serveur qui intègre la sécurité dans le logiciel, à moins de passer en revue le code source de ce logiciel.

Les restrictions DCOM à l’échelle de l’ordinateur atténuent ces trois problèmes. Il permet également à un administrateur de désactiver l’activation, le lancement et les appels DCOM entrants.

En quoi le fonctionnement est-il différent ?

Par défaut, le groupe Tout le monde bénéficie des autorisations de lancement local, d’activation locale et d’appel d’accès local. Cela permet à tous les scénarios locaux de fonctionner sans modification du logiciel ou du système d’exploitation.

Par défaut, dans Windows XP SP2, le groupe Tout le monde se voit accorder des autorisations d’appel d’accès à distance. Dans Windows Server 2003 SP1, les groupes Tout le monde et Anonyme bénéficient d’autorisations d’accès à distance. Cela permet la plupart des scénarios de client COM, y compris le cas courant où un client COM transmet une référence locale à un serveur distant, ce qui transforme le client en serveur. Dans Windows XP SP2, cela peut désactiver les scénarios qui nécessitent des appels d’accès à distance non authentifiés.

Par défaut, seuls les membres du groupe Administrateurs se voient accorder des autorisations d’activation et de lancement à distance. Cela désactive les activations à distance par des non-administrateurs sur les serveurs COM installés.

Comment faire résoudre ces problèmes ?

Si vous implémentez un serveur COM et que vous prévoyez de prendre en charge l’activation à distance par un client COM non administratif, vous devez déterminer si le risque associé à l’activation de ce processus est acceptable ou si vous devez modifier votre implémentation pour ne pas exiger l’activation à distance par un client COM non administratif ou des appels distants non authentifiés.

Si le risque est acceptable et que vous souhaitez activer l’activation à distance par un client COM non administratif ou des appels distants non authentifiés, vous devez modifier la configuration par défaut de cette fonctionnalité.

Notes

La modification des paramètres de sécurité à l’échelle de l’ordinateur affecte toutes les applications serveur COM et peut les empêcher de fonctionner correctement. S’il existe des applications serveur COM qui ont des restrictions moins strictes que les restrictions à l’échelle de l’ordinateur, la réduction des restrictions à l’échelle de l’ordinateur peut exposer ces applications à des accès indésirables. À l’inverse, si vous augmentez les restrictions à l’échelle de l’ordinateur, certaines applications serveur COM risquent de ne plus être accessibles en appelant des applications.

Vous pouvez modifier les paramètres de configuration à l’aide de la console MMC (Microsoft Management Console) des services de composants ou du Registre Windows.

Si vous utilisez le composant logiciel enfichable MMC Services de composants, ces paramètres peuvent être configurés sous l’onglet Sécurité COM de la boîte de dialogue Propriétés de l’ordinateur que vous gérez. La zone Autorisations d’accès a été modifiée pour vous permettre de définir des limites à l’échelle de l’ordinateur en plus des paramètres par défaut standard pour les serveurs COM. En outre, vous pouvez fournir des paramètres ACL distincts pour l’accès local et l’accès à distance sous les limites et les valeurs par défaut.

Dans la zone Autorisations de lancement et d’activation , vous pouvez contrôler les autorisations locales et distantes, ainsi que les limites à l’échelle de l’ordinateur et les valeurs par défaut. Vous pouvez spécifier les autorisations d’activation et de lancement locales et distantes indépendamment.

Vous pouvez également configurer ces paramètres de liste de contrôle d’accès à l’aide du Registre.

Ces listes de contrôle d’accès sont stockées dans le Registre aux emplacements suivants :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction=ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction=ACL

Il s’agit de valeurs nommées de type REG_BINARY qui contiennent des données qui décrivent la liste de contrôle d’accès des principaux qui peuvent accéder à n’importe quelle classe COM ou objet COM sur l’ordinateur. Les droits d’accès dans la liste de contrôle d’accès sont les suivants :

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

Ces listes de contrôle d’accès peuvent être créées à l’aide de fonctions de sécurité normales.

Notes

Pour assurer la compatibilité descendante, une liste de contrôle d’accès peut exister dans le format utilisé avant Windows XP SP2 et Windows Server 2003 SP1, qui utilise uniquement le droit d’accès COM_RIGHTS_EXECUTE, ou il peut exister dans le nouveau format utilisé dans Windows XP SP2 et Windows Server 2003 SP1, qui utilise COM_RIGHTS_EXECUTE avec une combinaison de COM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL et COM_RIGHTS_ACTIVATE_REMOTE. Notez que COM_RIGHTS_EXECUTE> doivent toujours être présents ; l’absence de ce droit génère un descripteur de sécurité non valide. Notez également que vous ne devez pas mélanger l’ancien format et le nouveau format au sein d’une seule liste de contrôle d’accès ; soit toutes les entrées de contrôle d’accès (ACE) doivent accorder uniquement le droit d’accès COM_RIGHTS_EXECUTE, soit accorder COM_RIGHTS_EXECUTE avec une combinaison de COM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL et COM_RIGHTS_ACTIVATE_REMOTE.

Notes

Seuls les utilisateurs disposant de droits d’administrateur peuvent modifier ces paramètres.

Quelles fonctionnalités existantes changent dans Windows XP Service Pack 2 et Windows Server 2003 Service Pack 1 ?

RPCSS s’exécute en tant que service réseau

RPCSS est un service clé pour le mappeur de point de terminaison RPC et l’infrastructure DCOM. Ce service s’exécutait en tant que système local dans les versions précédentes de Windows. Pour réduire la surface d’attaque de Windows et fournir une défense en profondeur, la fonctionnalité de service RPCSS a été divisée en deux services. Le service RPCSS avec toutes les fonctionnalités d’origine qui ne nécessitaient pas de privilèges système local s’exécute désormais sous le compte service réseau. Un nouveau service DCOMLaunch qui inclut des fonctionnalités qui nécessitent des privilèges système local s’exécute sous le compte Système local.

En quoi cette modification est-elle importante ?

Cette modification réduit la surface d’attaque et fournit une défense en profondeur pour le service RPCSS, car une élévation de privilège dans le service RPCSS est désormais limitée au privilège Service réseau.

En quoi le fonctionnement est-il différent ?

Cette modification doit être transparente pour les utilisateurs, car la combinaison des services RPCSS et DCOMLaunch est équivalente au service RPCSS précédent fourni dans les versions antérieures de Windows.

Autorisations COM plus spécifiques

Les applications serveur COM ont deux types d’autorisations : les autorisations de lancement et les autorisations d’accès. Les autorisations de lancement contrôlent l’autorisation de démarrer un serveur COM pendant l’activation COM si le serveur n’est pas déjà en cours d’exécution. Ces autorisations sont définies en tant que descripteurs de sécurité spécifiés dans les paramètres du Registre. Les autorisations d’accès contrôlent l’autorisation d’appeler un serveur COM en cours d’exécution. Ces autorisations sont définies en tant que descripteurs de sécurité fournis à l’infrastructure COM via l’API CoInitializeSecurity ou à l’aide des paramètres du Registre. Les autorisations de lancement et d’accès autorisent ou refusent l’accès en fonction des principaux, et ne font aucune distinction quant à savoir si l’appelant est local sur le serveur ou distant.

La première modification distingue les droits d’accès COM, en fonction de la distance. Les deux distances définies sont Local et Remote. Un message COM local arrive par le biais du protocole LRPC (Local Remote Procedure Call), tandis qu’un message COM distant arrive par le biais d’un protocole hôte d’appel de procédure distante (RPC) comme le protocole TCP (Transmission Control Protocol).

L’activation COM est l’action d’obtenir un proxy d’interface COM sur un client en appelant CoCreateInstance ou l’une de ses variantes. Comme effet secondaire de ce processus d’activation, un serveur COM doit parfois être démarré pour répondre à la demande du client. Une liste de contrôle d’accès des autorisations de lancement indique qui est autorisé à démarrer un serveur COM. Une liste de contrôle d’accès aux autorisations d’accès indique qui est autorisé à activer un objet COM ou à appeler cet objet une fois que le serveur COM est déjà en cours d’exécution.

La deuxième modification est que les droits d’appel et d’activation sont séparés pour refléter deux opérations distinctes et pour déplacer le droit d’activation de l’ACL d’autorisation d’accès vers l’ACL d’autorisation de lancement. Étant donné que l’activation et le lancement sont tous deux liés à l’acquisition d’un pointeur d’interface, les droits d’accès d’activation et de lancement appartiennent logiquement à une liste de contrôle d’accès. Et comme vous spécifiez toujours les autorisations de lancement par le biais de la configuration (par rapport aux autorisations d’accès, qui sont souvent spécifiées par programmation), le fait de placer les droits d’activation dans la liste de contrôle d’accès des autorisations de lancement fournit à l’administrateur un contrôle sur l’activation.

Les entrées de contrôle d’accès d’autorisation de lancement sont divisées en quatre droits d’accès :

• Lancement local (LL)
• Lancement à distance (RL)
• Activation locale (LA)
• Activation à distance (RA)

Le descripteur de sécurité des autorisations d’accès est divisé en deux droits d’accès :

• Appels d’accès locaux (LC)
• Appels d’accès à distance (RC)

Cela permet à l’administrateur d’appliquer des configurations de sécurité très spécifiques. Par exemple, vous pouvez configurer un serveur COM afin qu’il accepte les appels d’accès local de tout le monde, tout en acceptant uniquement les appels d’accès à distance des administrateurs. Ces distinctions peuvent être spécifiées par le biais de modifications apportées aux descripteurs de sécurité des autorisations COM.

En quoi cette modification est-elle importante ? Quelles menaces contribue-t-elle à limiter ?

Les versions antérieures de l’application serveur COM n’ont aucun moyen de restreindre une application afin qu’elle puisse être utilisée uniquement localement sans exposer l’application sur le réseau par le biais de DCOM. Lorsqu’un utilisateur a accès à une application serveur COM, il a accès à la fois pour une utilisation locale et distante.

Une application serveur COM peut s’exposer à des utilisateurs non authentifiés pour implémenter un scénario de rappel COM. Dans ce scénario, l’application doit également exposer son activation à des utilisateurs non authentifiés, ce qui peut ne pas être souhaitable.

Les autorisations COM précises permettent à l’administrateur de contrôler la stratégie d’autorisation COM d’un ordinateur. Ces autorisations activent la sécurité pour les scénarios décrits.

En quoi le fonctionnement est-il différent ? Existe-t-il des dépendances ?

Pour assurer la compatibilité descendante, les descripteurs de sécurité COM existants sont interprétés de manière à autoriser ou refuser simultanément l’accès local et l’accès à distance. Autrement dit, une entrée de contrôle d’accès (ACE) autorise à la fois local et distant, ou refuse à la fois le local et le distant.

Il n’existe aucun problème de compatibilité descendante pour les droits d’appel ou de lancement. Toutefois, il existe un problème de compatibilité des droits d’activation. Si, dans les descripteurs de sécurité existants pour un serveur COM, les autorisations de lancement configurées sont plus restrictives que les autorisations d’accès et sont plus restrictives que ce qui est minimalement requis pour les scénarios d’activation du client, la liste de contrôle d’accès des autorisations de lancement doit être modifiée pour donner aux clients autorisés les autorisations d’activation appropriées.

Pour les applications COM qui utilisent les paramètres de sécurité par défaut, il n’y a aucun problème de compatibilité. Pour les applications démarrées dynamiquement à l’aide de l’activation COM, la plupart n’ont aucun problème de compatibilité, car les autorisations de lancement doivent déjà inclure toute personne capable d’activer un objet. Sinon, ces applications génèrent des échecs d’activation avant même d’appliquer Windows XP SP2 ou Windows Server 2003 SP1, lorsque les appelants sans autorisation de lancement tentent d’activer un objet et que le serveur COM n’est pas déjà en cours d’exécution.

Les applications les plus préoccupantes pour les problèmes de compatibilité sont les applications COM qui sont déjà démarrées par un autre mécanisme, tel que Windows Explorer ou Service Control Manager. Vous pouvez également démarrer ces applications par une activation COM précédente, qui remplace les autorisations d’accès et de lancement par défaut et spécifie les autorisations de lancement qui sont plus restrictives que les autorisations d’appel. Pour plus d’informations sur la résolution de ce problème de compatibilité, consultez « Comment faire résoudre ces problèmes ? » dans la section suivante.

Si un système mis à niveau vers Windows XP SP2 ou Windows Server 2003 SP1 est restauré à un état antérieur, tout ace qui a été modifié pour autoriser l’accès local, l’accès à distance, ou les deux, est interprété comme autorisant l’accès local et l’accès à distance. Tout ACE qui a été modifié pour refuser l’accès local, l’accès à distance ou les deux, est interprété comme refusant l’accès local et l’accès à distance. Chaque fois que vous désinstallez un Service Pack, vous devez vous assurer qu’aucune AFC nouvellement définie ne provoque l’arrêt du fonctionnement des applications.

Comment faire résoudre ces problèmes ?

Si vous implémentez un serveur COM et que vous remplacez les paramètres de sécurité par défaut, vérifiez que la liste de contrôle d’accès des autorisations de lancement spécifiques à l’application accorde l’autorisation d’activation aux utilisateurs appropriés. Si ce n’est pas le cas, vous devez modifier votre liste de contrôle d’accès d’autorisation de lancement spécifique à l’application pour accorder aux utilisateurs les droits d’activation appropriés afin que les applications et les composants Windows qui utilisent DCOM n’échouent pas. Ces autorisations de lancement spécifiques à l’application sont stockées dans le Registre.

Les listes de contrôle d’accès COM peuvent être créées ou modifiées à l’aide de fonctions de sécurité normales.

Quels paramètres sont ajoutés ou modifiés dans Windows XP Service Pack 2 ?

Attention

Une utilisation incorrecte de ces paramètres peut entraîner l’échec des applications et des composants Windows qui utilisent DCOM.

Dans le tableau suivant, ces abréviations sont utilisées :

LL - Lancement local

LA - Activation locale

RL - Lancement à distance

RA - Activation à distance

LC - Appels d’accès local

RC - Appels d’accès à distance

ACL - liste de Access Control

Nom du paramètre	Emplacement	Valeur par défaut précédente	Valeur par défaut	Valeurs possibles
MachineLaunchRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Tout le monde - LL, LA, RL, RA Anonyme- LL, LA, RL, RA (Il s’agit d’une nouvelle clé de Registre. En fonction du comportement existant, il s’agit des valeurs effectives.)	Administrateur : LL, LA, RL, RA	ACL
MachineAccessRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Tout le monde - LC, RC Anonyme - LC, RC (Il s’agit d’une nouvelle clé de Registre. En fonction du comportement existant, il s’agit des valeurs effectives.)	Tout le monde : LC, RC Anonyme : LC	ACL
CallFailureLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Non applicable.	Cette clé de Registre n’est pas présente ; toutefois, une clé ou une valeur manquante est interprétée comme 2. Cet événement n’est pas journalisé par défaut. Si vous remplacez cette valeur par 1 pour commencer à journaliser ces informations pour vous aider à résoudre un problème, veillez à surveiller la taille de votre journal des événements, car il s’agit d’un événement qui peut générer un grand nombre d’entrées.	1 - Toujours journaliser les échecs du journal des événements pendant un appel dans le processus du serveur COM. 2 - Ne jamais consigner les échecs du journal des événements pendant un appel dans le processus du serveur d’appels.
InvalidSecurityDescriptorLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Non applicable.	Cette clé de Registre n’est pas présente ; toutefois, une clé ou une valeur manquante est interprétée comme 1. Cet événement est journalisé par défaut. Cela devrait rarement se produire.	1 - Toujours journaliser les échecs de journal des événements lorsque l’infrastructure COM trouve un descripteur de sécurité non valide. 2 - Ne jamais consigner les échecs de journal des événements lorsque l’infrastructure COM trouve un descripteur de sécurité non valide.
DCOM:Restrictions de lancement de machine dans la syntaxe SDDL (Security Descriptor Definition Language)	(objet stratégie de groupe) Configuration de l’ordinateur \Paramètres Windows\Stratégies locales \Options de sécurité	Non applicable.	Non défini	Liste de contrôle d’accès au format SDDL. L’existence de cette stratégie remplace les valeurs dans MachineLaunchRestriction, précédemment.
DCOM:Restrictions d’accès à la machine dans la syntaxe SDDL (Security Descriptor Definition Language)	(objet stratégie de groupe) Configuration ordinateur \Paramètres Windows \Stratégies locales \Options de sécurité	Non applicable.	Non défini	Liste de contrôle d’accès au format SDDL. L’existence de cette stratégie remplace les valeurs dans MachineAccessRestriction, précédemment.

Quels sont les paramètres qui ont été ajoutés ou modifiés dans Windows Server 2003 Service Pack 1 ?

Notes

Une utilisation incorrecte de ces paramètres peut entraîner l’échec des applications et des composants Windows qui utilisent DCOM.

Dans le tableau suivant, ces abréviations sont utilisées :

LL - Lancement local

LA - Activation locale

RL - Lancement à distance

RA - Activation à distance

LC - Appels d’accès local

RC - Appels d’accès à distance

ACL - liste de Access Control

Nom du paramètre	Emplacement	Valeur par défaut précédente	Valeur par défaut	Valeurs possibles
MachineLaunchRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Tout le monde : LL, LA, RL, RA Anonyme : LL, LA, RL, RA (Il s’agit d’une nouvelle clé de Registre. En fonction du comportement existant, il s’agit des valeurs effectives.)	Administrateur : LL, LA, RL, RA Tout le monde : LL, LA Utilisateurs COM distribués : LL, LA, RL, RA	ACL
MachineAccessRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Tout le monde : LC, RC Anonyme : LC, RC (Il s’agit d’une nouvelle clé de Registre. En fonction du comportement existant, il s’agit des valeurs effectives.)	Tout le monde : LC, RC Anonyme : LC, RC	ACL
CallFailureLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Non applicable.	Cette clé de Registre n’est pas présente ; toutefois, une clé ou une valeur manquante est interprétée comme 2. Cet événement n’est pas journalisé par défaut. Si vous remplacez cette valeur par 1 pour commencer à journaliser ces informations pour vous aider à résoudre un problème, veillez à surveiller la taille de votre journal des événements, car il s’agit d’un événement qui peut générer un grand nombre d’entrées.	1 - Toujours journaliser les échecs de journal des événements lorsque l’infrastructure COM trouve un descripteur de sécurité non valide. 2 - Ne jamais consigner les échecs de journal des événements lorsque l’infrastructure COM trouve un descripteur de sécurité non valide.
InvalidSecurityDescriptorLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Non applicable.	Cette clé de Registre n’est pas présente ; toutefois, une clé ou une valeur manquante est interprétée comme 1. Cet événement est journalisé par défaut. Cela devrait rarement se produire.	1 - Toujours journaliser les échecs du journal des événements lorsque l’infrastructure COM trouve un descripteur de sécurité non valide. 2 - Ne jamais consigner les échecs du journal des événements lorsque l’infrastructure COM trouve un descripteur de sécurité non valide.
DCOM:Restrictions de lancement de machine dans la syntaxe SDDL (Security Descriptor Definition Language)	(stratégie de groupe objet) Configuration ordinateur \Paramètres Windows \Stratégies locales \Options de sécurité	Non applicable.	Non défini.	Liste de contrôle d’accès au format SDDL. L’existence de cette stratégie remplace les valeurs dans MachineLaunchRestriction, précédemment.
DCOM:Machine Access Restrictions in Security Descriptor Definition Language (SDDL) Syntax	(stratégie de groupe objet) Configuration ordinateur \Paramètres Windows \Stratégies locales \Options de sécurité	Non applicable.	Non défini.	Liste de contrôle d’accès au format SDDL. L’existence de cette stratégie remplace les valeurs dans MachineAccessRestriction, précédemment.

Rubriques connexes

Sécurité dans COM