4
Windows XP SP2 - DCOM Werte gehen nach Neustart verloren
Hi Leute,
ich hab einen Fehler, den selbst ein Rechenzentrum nicht mehr lösen kann ;)
Folgendes:
Wir haben eine Anwendung die DCOM Komponente anlegt. Diese wiederrum bedürfen eines Benutzers (mit entsprechenden Rechten). In der DCOM-Komponente gibt man dann Benutzer + Passwort ein.
Nach einem Neustart funktioniert die Anwendung nicht. Der Administrator muss sich jedes Mal neu anmelden und dort das Passwort erneut eintragen. Manchmal kommt es sogar vor, dass im laufenden Betrieb der Wert verloren geht.
Getestet wurden:
- komplette Neuinstallation
- anderer Rechner (um den Fehler auszuschließen)
- Die Benutzer die die Anwendung benutzen bekommen lokale Admin-Rechte
- Auf die Benutzer wird keine Gruppenrichtlinie angewandt.
Habt ihr noch eine Idee, wo man ansetzen kann?
ich hab einen Fehler, den selbst ein Rechenzentrum nicht mehr lösen kann ;)
Folgendes:
Wir haben eine Anwendung die DCOM Komponente anlegt. Diese wiederrum bedürfen eines Benutzers (mit entsprechenden Rechten). In der DCOM-Komponente gibt man dann Benutzer + Passwort ein.
Nach einem Neustart funktioniert die Anwendung nicht. Der Administrator muss sich jedes Mal neu anmelden und dort das Passwort erneut eintragen. Manchmal kommt es sogar vor, dass im laufenden Betrieb der Wert verloren geht.
Getestet wurden:
- komplette Neuinstallation
- anderer Rechner (um den Fehler auszuschließen)
- Die Benutzer die die Anwendung benutzen bekommen lokale Admin-Rechte
- Auf die Benutzer wird keine Gruppenrichtlinie angewandt.
Habt ihr noch eine Idee, wo man ansetzen kann?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 27192
Url: https://administrator.de/forum/windows-xp-sp2-dcom-werte-gehen-nach-neustart-verloren-27192.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
4 Kommentare
Neuester Kommentar
Was ich mir vorstellen könnte, ist, dass die Anwendung nicht an den vom Programmierer vorgesehenen Standard-Pfad installiert wurde. Die Anwendung sucht sich deshalb das Config-File am falschen Ort, und weil dort eben keins vorhanden ist, ist auch dein User nicht mehr eingetragen.
Schau doch mal, ob du irgendwie rausfindest, wo die Config-Files gesucht werden.
Mehr fällt mir leider auch nicht ein..
grz - radioman
Schau doch mal, ob du irgendwie rausfindest, wo die Config-Files gesucht werden.
Mehr fällt mir leider auch nicht ein..
grz - radioman
Meldet sich die Applikation an einer Domäne an, die nicht im selben Forrest von AD ist?
Oder gar an einer Windows - NT domäne, für welche der DC des lokalen Rechners keine Vertrauensstellung hat?
Oder an einem Samba-3 Server an dem der Rechner / User keine Anmeldung machen darf /kann- die Applikation aber schon?
Windows XP schliesst dann die gültigen Credentials, um sich in der andern Domäne einzuloggen.
Dies wurde glaub ich gemacht, damit bei Verwendung z.B. von Terminalsessions oder VPN's keine Backdoors entstehen.
Vielleicht gibts da Policyeinstellungen um dieses Verhalten auszuschalten.
Oder gar an einer Windows - NT domäne, für welche der DC des lokalen Rechners keine Vertrauensstellung hat?
Oder an einem Samba-3 Server an dem der Rechner / User keine Anmeldung machen darf /kann- die Applikation aber schon?
Windows XP schliesst dann die gültigen Credentials, um sich in der andern Domäne einzuloggen.
Dies wurde glaub ich gemacht, damit bei Verwendung z.B. von Terminalsessions oder VPN's keine Backdoors entstehen.
Vielleicht gibts da Policyeinstellungen um dieses Verhalten auszuschalten.
Wir sind mit unserem Latein inzwischen am Ende. Wir haben mit 3 Admins minimal 3 Monate verbracht und nach jedem Strohhalm gegriffen.
Folgendes konnten wir feststellen:
Wird der Rechner LOKAL betrieben klappt der Zugriff. Ist er in der Domäne funktioniert es nicht mehr.
Der Standardpfad wurde übrigens beibehalten. Wo kann ich noch ansätzen?
Folgendes konnten wir feststellen:
Wird der Rechner LOKAL betrieben klappt der Zugriff. Ist er in der Domäne funktioniert es nicht mehr.
Der Standardpfad wurde übrigens beibehalten. Wo kann ich noch ansätzen?
P.S. Jeder freut sich über Lorbeeren oder Medalien. Admins freuen sich über Bewertungen!
Na dann mal los:
1)
Zunächst solltest Du mal alle fehlermeldungen im Eventlog unter APPS, SEC und SYS posten, welche mit DCOM oder Authentication zu tun haben (im fraglichen Zeitbereich).
2)
Dann interessiert, ob Du ein Verzeichnis %Windir%\System32\wbem\logs hast. Schau dort nach, ob die DCOM-Instanz oder der WMI dort seine Logs ablegt und checke sie durch.
Hinweise zu den Loggs im Technet und das:
The WMI logs might have a file name extension of .lo_. This is the previous version of the log. When the logs grow to a specific size, the log is renamed with the .lo_ file name extension and a new log is created for new entries. Any previous log with the .lo_ file name extension is overwritten.
3) Du solltest dann so meldungen wie (bei mir..)
(Wed Mar 22 19:25:28 2006.319968) : CAdapThread::RealEntry() for RemoteAccess failed: 80041009.
finden. Die kann man im Kontext mit deinem Problem analysieren.
4) Geh mal den Artikel "Troubleshooting DCOM" von MS durch:
http://www.microsoft.com/technet/archive/winntas/support/trdcom.mspx?mf ...
5) hast Du im mmc.exe unter DCOM-Konfiguration schon deine Komponente überprüft?
Du hast Dort mit Rechtsklick -> Eigenschaften->Sicherheit immer drei Einstellebenen von Zugriffsrechten pro Komponente:
- Start and Activation
- Access Control
- Configuration Rights
Die Rechte überprüfen. Dabei müssen die User entweder lokal sein oder aber sowohl dem aufrufenden wie dem Wirtsystem gleichermassen bekannt sein (im selben ADS-Tree oder in derselben NT-Domain)
6) Microsoft hat das Sycherheitssystem für Komponentendienste seit SP2 geändert. Installieren bitte auf allen deinen Vergleichs-PC das SP2 von XP nach, um sicherzustellen, dass Du Gleiches mit Gleichem vergleichst.
Hier noch ein Ausschnitt aus dem Hilfesystem betr. Komponentendienste des mmc.exe
--snip--
Neues (D)COM-Sicherheitssystem
In Windows XP SP2 ist ein neues Sicherheitssystem für (D)COM-Anwendungen enthalten. Mit diesem System kann der Zugriff auf COM-Anwendungen durch nicht autorisierte Benutzer reduziert werden.
Zusätzlich zu den bereits bestehenden Zugriffs-und Startberechtigungen für COM-Anwendungen ist in dem neuen System eine eigene Aktivierungsberechtigung vorhanden. Benutzer mit einer Aktivierungsberechtigung für eine COM-Anwendung, die jedoch nicht über eine Startberechtigung verfügen, können nur dann einen Clientproxy für die Anwendung erstellen, wenn die Anwendung bereits auf dem Server ausgeführt wird. Die Zugriffsberechtigung ist nach wie vor für die Verwendung des Proxys notwendig. Deshalb sollten alle Benutzer mit Aktivierungsberechtigung auch Zugriffsberechtigung erhalten.
Zugriffs-, Start- und Aktivierungsberechtigungen sind nun in unterschiedliche lokale und Remoteberechtigungen unterteilt. Benutzer mit lokalen Berechtigungen für eine COM-Anwendung können die erlaubten Aktionen nur auf dem lokalen Computer ausführen (der Computer, auf dem die Anwendung ausgeführt wird). Wenn die Aktion von einem anderen Computer innerhalb eines Netzwerks ausgeführt werden soll, muss der Benutzer über Remoteberechtigungen verfügen.
Zu dem neuen Sicherheitssystem gehört auch eine neue computerweite Einschränkungsrichtlinie. Mihilfe dieser Richtlinie werden die Berechtigungen begrenzt, die in die verschiedenen Richtungen gewährt werden können (einschlie�lich der Verwendung der CoInitializeSecurity-API). So kann beispielsweise der Remotezugriff auf alle COM-Anwendungen nicht zugelassen werden, indem in der computerweiten Einschränkungsrichtlinie allen Benutzern die Remotezugriffs-, Start und Aktivierungsberechtigungen verweigert werden.
In der folgenden Tabelle sind die standardmä�igen computerweiten Einschränkungsrichtlinien zusammengefasst.
Berechtigung Administratoren Jeder Anonym
Zugriff Lokal, Remote Lokal, Remote Lokal
Aktivierung Lokal, Remote Lokal Keine Berechtigungen
Start Lokal, Remote Lokal Keine Berechtigungen
Dabei ist zu beachten, dass der anonyme Benutzer über keine Remoteberechtigungen verfügt. Ebenso verfügen Benutzer, die keine Administratoren sind, nicht über Remotestart- oder Aktivierungsberechtigungen. Durch diese Standardberechtigungen besteht die Möglichkeit, dass bestehende Szenarien nicht mehr funktionieren. Zusätzliche Informationen finden Sie unter DCOM auf MSDN.
Weitere Informationen über das neue COM-Sicherheitssystem, einschlie�lich spezifischer Anweisungen zum Festlegen von Berechtigungen, finden Sie unter Zugriffsberechtigungen und Start- und Aktivierungsberechtigungen.
--snip--
Na dann mal los:
1)
Zunächst solltest Du mal alle fehlermeldungen im Eventlog unter APPS, SEC und SYS posten, welche mit DCOM oder Authentication zu tun haben (im fraglichen Zeitbereich).
2)
Dann interessiert, ob Du ein Verzeichnis %Windir%\System32\wbem\logs hast. Schau dort nach, ob die DCOM-Instanz oder der WMI dort seine Logs ablegt und checke sie durch.
Hinweise zu den Loggs im Technet und das:
The WMI logs might have a file name extension of .lo_. This is the previous version of the log. When the logs grow to a specific size, the log is renamed with the .lo_ file name extension and a new log is created for new entries. Any previous log with the .lo_ file name extension is overwritten.
3) Du solltest dann so meldungen wie (bei mir..)
(Wed Mar 22 19:25:28 2006.319968) : CAdapThread::RealEntry() for RemoteAccess failed: 80041009.
finden. Die kann man im Kontext mit deinem Problem analysieren.
4) Geh mal den Artikel "Troubleshooting DCOM" von MS durch:
http://www.microsoft.com/technet/archive/winntas/support/trdcom.mspx?mf ...
5) hast Du im mmc.exe unter DCOM-Konfiguration schon deine Komponente überprüft?
Du hast Dort mit Rechtsklick -> Eigenschaften->Sicherheit immer drei Einstellebenen von Zugriffsrechten pro Komponente:
- Start and Activation
- Access Control
- Configuration Rights
Die Rechte überprüfen. Dabei müssen die User entweder lokal sein oder aber sowohl dem aufrufenden wie dem Wirtsystem gleichermassen bekannt sein (im selben ADS-Tree oder in derselben NT-Domain)
6) Microsoft hat das Sycherheitssystem für Komponentendienste seit SP2 geändert. Installieren bitte auf allen deinen Vergleichs-PC das SP2 von XP nach, um sicherzustellen, dass Du Gleiches mit Gleichem vergleichst.
Hier noch ein Ausschnitt aus dem Hilfesystem betr. Komponentendienste des mmc.exe
--snip--
Neues (D)COM-Sicherheitssystem
In Windows XP SP2 ist ein neues Sicherheitssystem für (D)COM-Anwendungen enthalten. Mit diesem System kann der Zugriff auf COM-Anwendungen durch nicht autorisierte Benutzer reduziert werden.
Zusätzlich zu den bereits bestehenden Zugriffs-und Startberechtigungen für COM-Anwendungen ist in dem neuen System eine eigene Aktivierungsberechtigung vorhanden. Benutzer mit einer Aktivierungsberechtigung für eine COM-Anwendung, die jedoch nicht über eine Startberechtigung verfügen, können nur dann einen Clientproxy für die Anwendung erstellen, wenn die Anwendung bereits auf dem Server ausgeführt wird. Die Zugriffsberechtigung ist nach wie vor für die Verwendung des Proxys notwendig. Deshalb sollten alle Benutzer mit Aktivierungsberechtigung auch Zugriffsberechtigung erhalten.
Zugriffs-, Start- und Aktivierungsberechtigungen sind nun in unterschiedliche lokale und Remoteberechtigungen unterteilt. Benutzer mit lokalen Berechtigungen für eine COM-Anwendung können die erlaubten Aktionen nur auf dem lokalen Computer ausführen (der Computer, auf dem die Anwendung ausgeführt wird). Wenn die Aktion von einem anderen Computer innerhalb eines Netzwerks ausgeführt werden soll, muss der Benutzer über Remoteberechtigungen verfügen.
Zu dem neuen Sicherheitssystem gehört auch eine neue computerweite Einschränkungsrichtlinie. Mihilfe dieser Richtlinie werden die Berechtigungen begrenzt, die in die verschiedenen Richtungen gewährt werden können (einschlie�lich der Verwendung der CoInitializeSecurity-API). So kann beispielsweise der Remotezugriff auf alle COM-Anwendungen nicht zugelassen werden, indem in der computerweiten Einschränkungsrichtlinie allen Benutzern die Remotezugriffs-, Start und Aktivierungsberechtigungen verweigert werden.
In der folgenden Tabelle sind die standardmä�igen computerweiten Einschränkungsrichtlinien zusammengefasst.
Berechtigung Administratoren Jeder Anonym
Zugriff Lokal, Remote Lokal, Remote Lokal
Aktivierung Lokal, Remote Lokal Keine Berechtigungen
Start Lokal, Remote Lokal Keine Berechtigungen
Dabei ist zu beachten, dass der anonyme Benutzer über keine Remoteberechtigungen verfügt. Ebenso verfügen Benutzer, die keine Administratoren sind, nicht über Remotestart- oder Aktivierungsberechtigungen. Durch diese Standardberechtigungen besteht die Möglichkeit, dass bestehende Szenarien nicht mehr funktionieren. Zusätzliche Informationen finden Sie unter DCOM auf MSDN.
Weitere Informationen über das neue COM-Sicherheitssystem, einschlie�lich spezifischer Anweisungen zum Festlegen von Berechtigungen, finden Sie unter Zugriffsberechtigungen und Start- und Aktivierungsberechtigungen.
--snip--
