DCOM-Sicherheitsverbesserungen in Windows XP Service Pack 2 und Windows Server 2003 Service Pack 1
Windows Server XP Service Pack 2 (SP2) und Windows Server 2003 Service Pack 1 (SP1) führen erweiterte Standardsicherheitseinstellungen für das Distributed Component Object Model (DCOM) ein. Insbesondere werden differenziertere Rechte eingeführt, die es einem Administrator ermöglichen, unabhängige Kontrolle über lokale und Remoteberechtigungen für das Starten, Aktivieren und Zugreifen auf COM-Server zu haben.
Was macht DCOM?
Das Microsoft Component Object Model (COM) ist ein plattformunabhängiges, verteiltes, objektorientiertes System zum Erstellen von binären Softwarekomponenten, die interagieren können. Mit dem Distributed Component Object Model (DCOM) können Anwendungen an Standorten verteilt werden, die für Sie und die Anwendung am sinnvollsten sind. Das DCOM-Kabelprotokoll unterstützt transparent die zuverlässige, sichere und effiziente Kommunikation zwischen COM-Komponenten.
An welche Benutzer richtet sich Distributed Transaction Coordinator?
Wenn Sie COM nur für prozessinterne COM-Komponenten verwenden, gilt dieses Feature nicht für Sie.
Dieses Feature gilt für Sie, wenn Sie über eine COM-Serveranwendung verfügen, die eines der folgenden Kriterien erfüllt:
- Die Zugriffsberechtigung für die Anwendung ist weniger streng als die Startberechtigung, die zum Ausführen der Anwendung erforderlich ist.
- Die Anwendung wird in der Regel von einem COM-Remoteclient aktiviert, ohne ein Administratorkonto zu verwenden.
- Die Anwendung soll nur lokal verwendet werden. Dies bedeutet, dass Sie Ihre COM-Serveranwendung einschränken können, sodass sie nicht remote zugänglich ist.
Welche neuen Funktionen werden diesem Feature in Windows XP Service Pack 2 und Windows Server 2003 Service Pack 1 hinzugefügt?
Computerweite Einschränkungen
In COM wurde eine Änderung vorgenommen, um computerweite Zugriffssteuerungen bereitzustellen, die den Zugriff auf alle Aufruf-, Aktivierungs- oder Startanforderungen auf dem Computer steuern. Die einfachste Möglichkeit, diese Zugriffssteuerungen zu betrachten, ist ein zusätzlicher AccessCheck-Aufruf , der bei jedem Aufruf, jeder Aktivierung oder dem Start eines beliebigen COM-Servers auf dem Computer für eine computerweite Zugriffssteuerungsliste (ACL) ausgeführt wird. Wenn der AccessCheck fehlschlägt, wird der Aufruf, die Aktivierung oder die Startanforderung abgelehnt. Dies ist zusätzlich zu allen AccessChecks , die für die serverspezifischen ACLs ausgeführt wird. Tatsächlich bietet es einen Mindestautorisierungsstandard, der für den Zugriff auf jeden COM-Server auf dem Computer übergeben werden muss. Es gibt eine computerweite ACL für Startberechtigungen zum Abdecken von Aktivierungs- und Startrechten sowie eine computerweite ACL für Zugriffsberechtigungen zum Abdecken von Anrufrechten. Diese können über die Microsoft Management Console (MMC) der Komponentendienste konfiguriert werden.
Diese computerweiten ACLs bieten eine Möglichkeit, schwache Sicherheitseinstellungen, die von einer bestimmten Anwendung über CoInitializeSecurity oder anwendungsspezifische Sicherheitseinstellungen angegeben werden, zu überschreiben. Dadurch wird ein Mindestsicherheitsstandard bereitgestellt, der unabhängig von den Einstellungen des jeweiligen Servers bestanden werden muss.
Diese ACLs werden überprüft, wenn auf die von RPCSS verfügbar gemachten Schnittstellen zugegriffen wird. Dies bietet eine Methode zum Steuern des Zugriffs auf diesen Systemdienst.
Diese ACLs bieten einen zentralen Speicherort, an dem ein Administrator eine allgemeine Autorisierungsrichtlinie festlegen kann, die für alle COM-Server auf dem Computer gilt.
Hinweis
Das Ändern der computerweiten Sicherheitseinstellungen wirkt sich auf alle COM-Serveranwendungen aus und verhindert, dass sie ordnungsgemäß funktionieren. Wenn COM-Serveranwendungen einschränkungen aufweisen, die weniger streng als die computerweiten Einschränkungen sind, kann die Reduzierung der computerweiten Einschränkungen diese Anwendungen unerwünschtem Zugriff aussetzen. Wenn Sie dagegen die computerweiten Einschränkungen erhöhen, sind einige COM-Serveranwendungen möglicherweise nicht mehr durch Aufrufen von Anwendungen zugänglich.
Standardmäßig sind die Windows XP SP2-Computereinschränkungseinstellungen:
Berechtigung | Administrator | Jeder | Anonym |
---|---|---|---|
Starten |
Lokaler Start Lokale Aktivierung Remotestart Remoteaktivierung |
Lokaler Start Lokale Aktivierung |
|
Access |
Lokaler Zugriff Remotezugriff |
Lokaler Zugriff |
Standardmäßig sind die Windows Server 2003 SP 1-Computereinschränkungseinstellungen wie folgt.
Berechtigung | Administrator | Verteilte COM-Benutzer (integrierte Gruppe) | Jeder | Anonym |
---|---|---|---|---|
Starten |
Lokaler Start Lokale Aktivierung Remotestart Remoteaktivierung |
Lokaler Start Lokale Aktivierung Remotestart Remoteaktivierung |
Lokaler Start Lokale Aktivierung |
– |
Access |
– |
Lokaler Zugriff Remotezugriff |
Lokaler Zugriff Remotezugriff |
Lokaler Zugriff Remotezugriff |
Hinweis
Verteilte COM-Benutzer ist eine neue integrierte Gruppe, die in Windows Server 2003 SP1 enthalten ist, um das Hinzufügen von Benutzern zu den DCOM-Computereinschränkungseinstellungen zu beschleunigen. Diese Gruppe ist Teil der ACL, die von den Einstellungen MachineAccessRestriction und MachineLaunchRestriction verwendet wird. Daher wirkt sich das Entfernen von Benutzern aus dieser Gruppe auf diese Einstellungen aus.
Warum ist diese Änderung so wichtig? Welche Bedrohungen werden damit gemindert?
Viele COM-Anwendungen enthalten sicherheitsspezifischen Code (z. B. Aufrufen von CoInitializeSecurity), verwenden jedoch schwache Einstellungen, die häufig nicht authentifizierten Zugriff auf den Prozess ermöglichen. Es gibt derzeit keine Möglichkeit für einen Administrator, diese Einstellungen zu überschreiben, um eine höhere Sicherheit in früheren Versionen von Windows zu erzwingen.
Die COM-Infrastruktur umfasst die RPCSS, einen Systemdienst, der während des Systemstarts ausgeführt wird und immer danach ausgeführt wird. Es verwaltet die Aktivierung von COM-Objekten und der ausgeführten Objekttabelle und stellt Hilfsdienste für DCOM-Remoting bereit. Er macht RPC-Schnittstellen verfügbar, die remote aufgerufen werden können. Da einige COM-Server nicht authentifizierten Remotezugriff zulassen, können diese Schnittstellen von jedem aufgerufen werden, einschließlich nicht authentifizierter Benutzer. Daher kann RPCSS von böswilligen Benutzern auf nicht authentifizierten Remotecomputern angegriffen werden.
In früheren Versionen von Windows gab es für einen Administrator keine Möglichkeit, die Expositionsebene der COM-Server auf einem Computer zu verstehen. Ein Administrator hat eine Vorstellung von der Expositionsstufe erhalten, indem er die konfigurierten Sicherheitseinstellungen für alle registrierten COM-Anwendungen auf dem Computer systematisch überprüfte, aber angesichts der Tatsache, dass in einer Standardinstallation von Windows etwa 150 COM-Server vorhanden sind, war diese Aufgabe entmutigend. Es gab keine Möglichkeit, die Einstellungen für einen Server anzuzeigen, der Sicherheit in die Software integriert, abzusehen, ohne den Quellcode für diese Software zu überprüfen.
Computerweite DCOM-Einschränkungen verringern diese drei Probleme. Außerdem kann ein Administrator eingehende DCOM-Aktivierung, -Start und -Aufrufe deaktivieren.
Worin bestehen die Unterschiede?
Standardmäßig werden der Gruppe Jeder lokale Startberechtigungen, lokale Aktivierung und lokale Zugriffsanrufberechtigungen gewährt. Dadurch können alle lokalen Szenarien ohne Änderungen an der Software oder dem Betriebssystem funktionieren.
Standardmäßig werden in Windows XP SP2 der Gruppe Jeder Remotezugriffsaufrufberechtigungen gewährt. In Windows Server 2003 SP1 erhalten die Gruppen Jeder und Anonym Remotezugriffsberechtigungen. Dies ermöglicht die meisten COM-Clientszenarien, einschließlich des häufigen Falles, in dem ein COM-Client einen lokalen Verweis auf einen Remoteserver übergibt, um den Client in einen Server zu verwandeln. In Windows XP SP2 können dadurch Szenarien deaktiviert werden, die nicht authentifizierte Remotezugriffsaufrufe erfordern.
Außerdem erhalten standardmäßig nur Mitglieder der Gruppe Administratoren Remoteaktivierungs- und Startberechtigungen. Dadurch werden Remoteaktivierungen von Nichtadministratoren für installierte COM-Server deaktiviert.
Gewusst wie diese Probleme beheben?
Wenn Sie einen COM-Server implementieren und erwarten, dass die Remoteaktivierung durch einen nicht administrativen COM-Client unterstützt wird, sollten Sie überlegen, ob das Risiko, das mit der Aktivierung dieses Prozesses verbunden ist, akzeptabel ist oder ob Sie Ihre Implementierung so ändern sollten, dass keine Remoteaktivierung durch einen nicht administrativen COM-Client oder nicht authentifizierte Remoteaufrufe erforderlich ist.
Wenn das Risiko akzeptabel ist und Sie die Remoteaktivierung durch einen nicht administrativen COM-Client oder nicht authentifizierte Remoteaufrufe aktivieren möchten, müssen Sie die Standardkonfiguration für dieses Feature ändern.
Hinweis
Das Ändern der computerweiten Sicherheitseinstellungen wirkt sich auf alle COM-Serveranwendungen aus und verhindert möglicherweise, dass sie ordnungsgemäß funktionieren. Wenn ES COM-Serveranwendungen gibt, die weniger strenge Einschränkungen aufweisen als die computerweiten Einschränkungen, kann die Reduzierung der computerweiten Einschränkungen diese Anwendungen für unerwünschten Zugriff aussetzen. Wenn Sie dagegen die computerweiten Einschränkungen erhöhen, kann auf einige COM-Serveranwendungen möglicherweise nicht mehr durch aufrufende Anwendungen zugegriffen werden.
Sie können die Konfigurationseinstellungen entweder über die Microsoft Management Console (MMC) oder die Windows-Registrierung ändern.
Wenn Sie das MMC-Snap-In Komponentendienste verwenden, können diese Einstellungen auf der Registerkarte COM-Sicherheit des Dialogfelds Eigenschaften für den computer konfiguriert werden, den Sie verwalten. Der Bereich Zugriffsberechtigungen wurde so geändert, dass Sie zusätzlich zu den Standardeinstellungen für COM-Server computerweite Grenzwerte festlegen können. Darüber hinaus können Sie separate ACL-Einstellungen für den lokalen und Remotezugriff unter Grenzwerten und Standardwerten bereitstellen.
Im Bereich Start- und Aktivierungsberechtigungen können Sie die lokalen und Remoteberechtigungen sowie die computerweiten Grenzwerte und Die Standardwerte steuern. Sie können sowohl lokale als auch Remoteaktivierungs- und Startberechtigungen unabhängig angeben.
Alternativ können Sie diese ACL-Einstellungen mithilfe der Registrierung konfigurieren.
Diese ACLs werden in der Registrierung an den folgenden Speicherorten gespeichert:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction=ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction=ACL
Dies sind benannte Werte vom Typ REG_BINARY, die Daten enthalten, die die ACL der Prinzipale beschreiben, die auf jede COM-Klasse oder jedes COM-Objekt auf dem Computer zugreifen können. Die Zugriffsrechte in der ACL sind:
COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16
Diese ACLs können mit normalen Sicherheitsfunktionen erstellt werden.
Hinweis
Um Abwärtskompatibilität zu gewährleisten, kann eine ACL in dem Format vorhanden sein, das vor Windows XP SP2 und Windows Server 2003 SP1 verwendet wurde, wobei nur das Zugriffsrecht COM_RIGHTS_EXECUTE verwendet wird, oder sie kann im neuen Format vorhanden sein, das in Windows XP SP2 und Windows Server 2003 SP1 verwendet wird, wobei COM_RIGHTS_EXECUTE zusammen mit einer Kombination aus COM_RIGHTS_EXECUTE_LOCAL verwendet wird. COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL und COM_RIGHTS_ACTIVATE_REMOTE. Beachten Sie, dass COM_RIGHTS_EXECUTE> immer vorhanden sein muss. Das Fehlen dieses Rechts erzeugt einen ungültigen Sicherheitsdeskriptor. Beachten Sie außerdem, dass Sie das alte Format und das neue Format nicht innerhalb einer einzelnen ACL kombinieren dürfen. Entweder müssen alle Zugriffssteuerungseinträge (Access Control Entries, ACEs) nur das COM_RIGHTS_EXECUTE-Zugriffsrecht gewähren, oder alle müssen COM_RIGHTS_EXECUTE zusammen mit einer Kombination aus COM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL und COM_RIGHTS_ACTIVATE_REMOTE gewähren.
Hinweis
Nur Benutzer mit Administratorrechten können diese Einstellungen ändern.
Welche vorhandenen Funktionen ändern sich in Windows XP Service Pack 2 und Windows Server 2003 Service Pack 1?
RPCSS wird als Netzwerkdienst ausgeführt
RPCSS ist ein wichtiger Dienst für die RPC-Endpunktzuordnung und DCOM-Infrastruktur. Dieser Dienst wurde in früheren Versionen von Windows als lokales System ausgeführt. Um die Angriffsfläche von Windows zu verringern und eine umfassende Verteidigung bereitzustellen, wurde die RPCSS-Dienstfunktionalität in zwei Dienste aufgeteilt. Der RPCSS-Dienst mit allen ursprünglichen Funktionen, für die keine Lokalen Systemberechtigungen erforderlich waren, wird jetzt unter dem Netzwerkdienstkonto ausgeführt. Ein neuer DCOMLaunch-Dienst, der Funktionen enthält, die lokale Systemberechtigungen erfordern, wird unter dem Lokalen Systemkonto ausgeführt.
Warum ist diese Änderung so wichtig?
Durch diese Änderung wird die Angriffsfläche reduziert und der RPCSS-Dienst tief greifend geschützt, da eine Rechteerweiterung im RPCSS-Dienst jetzt auf die Netzwerkdienstberechtigung beschränkt ist.
Worin bestehen die Unterschiede?
Diese Änderung sollte für Benutzer transparent sein, da die Kombination der RPCSS- und DCOMLaunch-Dienste dem vorherigen RPCSS-Dienst entspricht, der in früheren Versionen von Windows bereitgestellt wurde.
Spezifischere COM-Berechtigungen
COM-Serveranwendungen verfügen über zwei Arten von Berechtigungen: Startberechtigungen und Zugriffsberechtigungen. Starten Sie die Berechtigungssteuerungsautorisierung, um einen COM-Server während der COM-Aktivierung zu starten, wenn der Server noch nicht ausgeführt wird. Diese Berechtigungen werden als Sicherheitsbeschreibungen definiert, die in Registrierungseinstellungen angegeben werden. Zugriffsberechtigungen steuern die Autorisierung, um einen ausgeführten COM-Server aufzurufen. Diese Berechtigungen werden als Sicherheitsbeschreibungen definiert, die der COM-Infrastruktur über die CoInitializeSecurity-API oder mithilfe von Registrierungseinstellungen bereitgestellt werden. Sowohl Start- als auch Zugriffsberechtigungen erlauben oder verweigern den Zugriff basierend auf Prinzipalen, und es wird nicht unterschieden, ob der Aufrufer lokal auf dem Server oder remote ist.
Die erste Änderung unterscheidet die COM-Zugriffsrechte basierend auf der Entfernung. Die beiden definierten Entfernungen sind Lokal und Remote. Eine lokale COM-Nachricht wird über das LRPC-Protokoll (Local Remote Procedure Call) empfangen, während eine Remote-COM-Nachricht über ein RPC-Hostprotokoll (Remote Procedure Call) wie tcp (Transmission Control Protocol) eingeht.
Com-Aktivierung ist das Abrufen eines COM-Schnittstellenproxys auf einem Client durch Aufrufen von CoCreateInstance oder einer seiner Varianten. Als Nebeneffekt dieses Aktivierungsprozesses muss manchmal ein COM-Server gestartet werden, um die Anforderung des Clients zu erfüllen. Eine Startberechtigungs-ACL gibt an, wer einen COM-Server starten darf. Eine Zugriffsberechtigungs-ACL gibt an, wer ein COM-Objekt aktivieren oder aufrufen darf, sobald der COM-Server bereits ausgeführt wird.
Die zweite Änderung besteht darin, dass die Aufruf- und Aktivierungsrechte getrennt werden, um zwei verschiedene Vorgänge widerzuspiegeln und das Aktivierungsrecht von der Zugriffsberechtigungs-ACL in die Startberechtigungs-ACL zu verschieben. Da die Aktivierung und der Start beide mit dem Abrufen eines Schnittstellenzeigers zusammenhängen, gehören Aktivierungs- und Startzugriffsrechte logisch in einer ACL zusammen. Und da Sie Startberechtigungen immer über die Konfiguration angeben (im Vergleich zu Zugriffsberechtigungen, die häufig programmgesteuert angegeben werden), erhält der Administrator durch das Festlegen der Aktivierungsrechte in der Startberechtigungs-ACL die Kontrolle über die Aktivierung.
Die Zugriffssteuerungseinträge (AcEs) der Startberechtigung sind in vier Zugriffsrechte unterteilt:
- Lokaler Start (LL)
- Remotestart (RL)
- Lokale Aktivierung (LA)
- Remote Activate (RA)
Der Zugriffsberechtigungs-Sicherheitsdeskriptor ist in zwei Zugriffsrechte unterteilt:
- Lokale Zugriffsaufrufe (LC)
- Remotezugriffsaufrufe (RC)
Dadurch kann der Administrator sehr spezifische Sicherheitskonfigurationen anwenden. Sie können beispielsweise einen COM-Server so konfigurieren, dass er lokale Zugriffsaufrufe von allen Personen akzeptiert, während er nur Remotezugriffsaufrufe von Administratoren akzeptiert. Diese Unterscheidungen können durch Änderungen an den COM-Berechtigungs-Sicherheitsdeskriptoren angegeben werden.
Warum ist diese Änderung so wichtig? Welche Bedrohungen werden damit gemindert?
Frühere Versionen der COM-Serveranwendung haben keine Möglichkeit, eine Anwendung so einzuschränken, dass sie nur lokal verwendet werden kann, ohne die Anwendung über DCOM im Netzwerk verfügbar zu machen. Wenn ein Benutzer Zugriff auf eine COM-Serveranwendung hat, hat er Zugriff sowohl für die lokale als auch für die Remoteverwendung.
Eine COM-Serveranwendung kann sich selbst für nicht authentifizierte Benutzer verfügbar machen, um ein COM-Rückrufszenario zu implementieren. In diesem Szenario muss die Anwendung ihre Aktivierung auch für nicht authentifizierte Benutzer verfügbar machen, was möglicherweise nicht wünschenswert ist.
Präzise COM-Berechtigungen bieten dem Administrator flexibilität, die COM-Berechtigungsrichtlinie eines Computers zu steuern. Diese Berechtigungen ermöglichen die Sicherheit für die beschriebenen Szenarien.
Worin bestehen die Unterschiede? Gibt es Abhängigkeiten?
Um Abwärtskompatibilität zu gewährleisten, werden vorhandene COM-Sicherheitsbeschreibungen so interpretiert, dass der lokale Zugriff und der Remotezugriff gleichzeitig zugelassen oder verweigert werden. Das heißt, ein Zugriffssteuerungseintrag (Access Control Entry, ACE) lässt entweder sowohl lokal als auch remote zu oder verweigert sowohl lokal als auch remote.
Es gibt keine Abwärtskompatibilitätsprobleme bei Anruf- oder Startrechten. Es liegt jedoch ein Problem mit der Kompatibilität von Aktivierungsrechten vor. Wenn in den vorhandenen Sicherheitsbeschreibungen für einen COM-Server die konfigurierten Startberechtigungen restriktiver als die Zugriffsberechtigungen sind und restriktiver sind als bei Clientaktivierungsszenarien minimal erforderlich, muss die Startberechtigungs-ACL geändert werden, um den autorisierten Clients die entsprechenden Aktivierungsberechtigungen zu erteilen.
Für COM-Anwendungen, die die Standardsicherheitseinstellungen verwenden, gibt es keine Kompatibilitätsprobleme. Bei Anwendungen, die dynamisch mit der COM-Aktivierung gestartet werden, weisen die meisten keine Kompatibilitätsprobleme auf, da die Startberechtigungen bereits jeden einschließen müssen, der ein Objekt aktivieren kann. Andernfalls generieren solche Anwendungen Aktivierungsfehler, bevor Windows XP SP2 oder Windows Server 2003 SP1 angewendet wird, wenn Aufrufer ohne Startberechtigung versuchen, ein Objekt zu aktivieren und der COM-Server nicht bereits ausgeführt wird.
Die anwendungen, die bei Kompatibilitätsproblemen am wichtigsten sind, sind COM-Anwendungen, die bereits von einem anderen Mechanismus wie Windows Explorer oder Dienststeuerungs-Manager gestartet werden. Sie können diese Anwendungen auch durch eine vorherige COM-Aktivierung starten, die die Standardzugriffs- und Startberechtigungen außer Kraft setzt und Startberechtigungen angibt, die restriktiver als die Aufrufberechtigungen sind. Weitere Informationen zum Beheben dieses Kompatibilitätsproblems finden Sie unter "Gewusst wie diese Probleme beheben?" im nächsten Abschnitt.
Wenn für ein System, das auf Windows XP SP2 oder Windows Server 2003 SP1 aktualisiert wird, ein Rollback auf einen früheren Zustand durchgeführt wird, wird jeder ACE, der so bearbeitet wurde, dass lokaler Zugriff, Remotezugriff oder beides zugelassen wird, sowohl lokalen als auch Remotezugriff ermöglicht wird. Jeder ACE, der so bearbeitet wurde, dass lokaler Zugriff, Remotezugriff oder beides verweigert wird, wird interpretiert, um sowohl lokalen als auch Remotezugriff zu verweigern. Wenn Sie ein Service Pack deinstallieren, sollten Sie sicherstellen, dass keine neu festgelegten ACEs dazu führen, dass Anwendungen nicht mehr funktionieren.
Gewusst wie diese Probleme beheben?
Wenn Sie einen COM-Server implementieren und die Standardsicherheitseinstellungen außer Kraft setzen, vergewissern Sie sich, dass die anwendungsspezifische Startberechtigungen-ACL den entsprechenden Benutzern aktivierungsberechtigungen erteilt. Wenn dies nicht der Fall ist, müssen Sie ihre anwendungsspezifische Startberechtigungs-ACL ändern, um den entsprechenden Benutzern Aktivierungsrechte zu gewähren, damit Anwendungen und Windows-Komponenten, die DCOM verwenden, nicht fehlschlagen. Diese anwendungsspezifischen Startberechtigungen werden in der Registrierung gespeichert.
Die COM-ACLs können mit normalen Sicherheitsfunktionen erstellt oder geändert werden.
Welche Einstellungen werden in Windows XP Service Pack 2 hinzugefügt oder geändert?
Achtung
Eine unsachgemäße Verwendung dieser Einstellungen kann dazu führen, dass Anwendungen und Windows-Komponenten, die DCOM verwenden, fehlschlagen.
In der folgenden Tabelle werden diese Abkürzungen verwendet:
LL – Lokaler Start
LA – Lokale Aktivierung
RL – Remotestart
RA – Remoteaktivierung
LC – Lokale Zugriffsaufrufe
RC – Remotezugriffsaufrufe
ACL – Access Control Liste
Einstellungsname | Standort | Vorheriger Standardwert | Standardwert | Mögliche Werte |
---|---|---|---|---|
MachineLaunchRestriction |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Jeder - LL, LA, RL, RA Anonym- LL, LA, RL, RA (Dies ist ein neuer Registrierungsschlüssel. Basierend auf vorhandenem Verhalten sind dies die effektiven Werte.) |
Administrator: LL, LA, RL, RA |
ACL |
MachineAccessRestriction |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Jeder – LC, RC Anonym – LC, RC (Dies ist ein neuer Registrierungsschlüssel. Basierend auf vorhandenem Verhalten sind dies die effektiven Werte.) |
Alle: LC, RC Anonym: LC |
ACL |
CallFailureLoggingLevel |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Nicht zutreffend |
Dieser Registrierungsschlüssel ist nicht vorhanden. Ein fehlender Schlüssel oder Wert wird jedoch als 2 interpretiert. Dieses Ereignis wird standardmäßig nicht protokolliert. Wenn Sie diesen Wert in 1 ändern, um mit der Protokollierung dieser Informationen zu beginnen, um ein Problem zu beheben, achten Sie darauf, die Größe Ihres Ereignisprotokolls zu überwachen, da es sich um ein Ereignis handelt, das eine große Anzahl von Einträgen generieren kann. |
1: Protokollieren Sie immer Ereignisprotokollfehler während eines Aufrufs im COM Server-Prozess. 2 : Protokollieren Sie nie Ereignisprotokollfehler während eines Anrufs im Anrufserverprozess. |
InvalidSecurityDescriptorLoggingLevel |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Nicht zutreffend |
Dieser Registrierungsschlüssel ist nicht vorhanden. Ein fehlender Schlüssel oder Wert wird jedoch als 1 interpretiert. Dieses Ereignis wird standardmäßig protokolliert. Es sollte selten auftreten. |
1 : Protokollieren Sie immer Ereignisprotokollfehler, wenn die COM-Infrastruktur einen ungültigen Sicherheitsdeskriptor findet. 2 : Protokollieren Sie nie Ereignisprotokollfehler, wenn die COM-Infrastruktur eine ungültige Sicherheitsbeschreibung findet. |
DCOM:Machine Launch Restrictions in Security Descriptor Definition Language (SDDL)-Syntax |
(Gruppenrichtlinie-Objekt) Computerkonfiguration \Windows-Einstellungen\Lokale Richtlinien \Sicherheitsoptionen |
Nicht zutreffend |
Nicht definiert |
Zugriffssteuerungsliste im SDDL-Format. Wenn diese Richtlinie vorhanden ist, werden werte in MachineLaunchRestriction zuvor außer Kraft gesetzt. |
DCOM:Machine Access Restrictions in Security Descriptor Definition Language (SDDL)-Syntax |
(Gruppenrichtlinie-Objekt) Computerkonfiguration \Windows-Einstellungen \Lokale Richtlinien \Sicherheitsoptionen |
Nicht zutreffend |
Nicht definiert |
Zugriffssteuerungsliste im SDDL-Format. Wenn diese Richtlinie vorhanden ist, werden werte in MachineAccessRestriction zuvor außer Kraft gesetzt. |
Welche Einstellungen werden in Windows Server 2003 Service Pack 1 hinzugefügt oder geändert?
Hinweis
Eine unsachgemäße Verwendung dieser Einstellungen kann dazu führen, dass Anwendungen und Windows-Komponenten, die DCOM verwenden, fehlschlagen.
In der folgenden Tabelle werden diese Abkürzungen verwendet:
LL – Lokaler Start
LA – Lokale Aktivierung
RL – Remotestart
RA – Remoteaktivierung
LC – Lokale Zugriffsaufrufe
RC – Remotezugriffsaufrufe
ACL – Access Control Liste
Einstellungsname | Standort | Vorheriger Standardwert | Standardwert | Mögliche Werte |
---|---|---|---|---|
MachineLaunchRestriction |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Alle: LL, LA, RL, RA Anonym: LL, LA, RL, RA (Dies ist ein neuer Registrierungsschlüssel. Basierend auf vorhandenem Verhalten wären dies die effektiven Werte.) |
Administrator: LL, LA, RL, RA Alle: LL, LA Verteilte COM-Benutzer: LL, LA, RL, RA |
ACL |
MachineAccessRestriction |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Alle: LC, RC Anonym: LC, RC (Dies ist ein neuer Registrierungsschlüssel. Basierend auf vorhandenem Verhalten wären dies die effektiven Werte.) |
Alle: LC, RC Anonym: LC, RC |
ACL |
CallFailureLoggingLevel |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Nicht zutreffend |
Dieser Registrierungsschlüssel ist nicht vorhanden. Ein fehlender Schlüssel oder Wert wird jedoch als 2 interpretiert. Dieses Ereignis wird standardmäßig nicht protokolliert. Wenn Sie diesen Wert in 1 ändern, um mit der Protokollierung dieser Informationen zu beginnen, um ein Problem zu beheben, achten Sie darauf, die Größe Ihres Ereignisprotokolls zu überwachen, da es sich um ein Ereignis handelt, das eine große Anzahl von Einträgen generieren kann. |
1 : Protokollieren Sie immer Ereignisprotokollfehler, wenn die COM-Infrastruktur einen ungültigen Sicherheitsdeskriptor findet. 2 : Protokollieren Sie nie Ereignisprotokollfehler, wenn die COM-Infrastruktur eine ungültige Sicherheitsbeschreibung findet. |
InvalidSecurityDescriptorLoggingLevel |
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole |
Nicht zutreffend |
Dieser Registrierungsschlüssel ist nicht vorhanden. Ein fehlender Schlüssel oder Wert wird jedoch als 1 interpretiert. Dieses Ereignis wird standardmäßig protokolliert. Es sollte selten vorkommen. |
1: Protokollieren Sie immer Ereignisprotokollfehler, wenn die COM-Infrastruktur einen ungültigen Sicherheitsdeskriptor findet. 2 : Protokollieren Sie nie Ereignisprotokollfehler, wenn die COM-Infrastruktur einen ungültigen Sicherheitsdeskriptor findet. |
DCOM:Machine Launch Restrictions in Security Descriptor Definition Language (SDDL)-Syntax |
(Gruppenrichtlinie-Objekt) Computerkonfiguration \Windows-Einstellungen \Lokale Richtlinien \Sicherheitsoptionen |
Nicht zutreffend |
Nicht definiert. |
Zugriffssteuerungsliste im SDDL-Format. Das Vorhandensein dieser Richtlinie überschreibt Werte in MachineLaunchRestriction( zuvor). |
DCOM:Machine Access Restrictions in Security Descriptor Definition Language (SDDL)-Syntax |
(Gruppenrichtlinie-Objekt) Computerkonfiguration \Windows-Einstellungen \Lokale Richtlinien \Sicherheitsoptionen |
Nicht zutreffend |
Nicht definiert. |
Zugriffssteuerungsliste im SDDL-Format. Das Vorhandensein dieser Richtlinie überschreibt Werte in MachineAccessRestriction( zuvor). |