Sicherheit, Kommunikation und Konfiguration

Veröffentlicht: 15. Sep 2000 | Aktualisiert: 17. Jun 2004

Hacker sind clever, zahlreich und haben nur Eines im Sinn: in Ihren Server einzudringen. Sie können überall sein - intern oder extern, Einzelne oder Gruppen. Sie verfügen über viele intelligente Tools, aber ihre wirksamste Waffe ist ihre Hartnäckigkeit. Daher ist Vorsicht geboten.

Dies hört sich vielleicht etwas übertrieben an, doch in Umgebungen, in denen vertrauliche Daten und Anwendungen geändert werden, ist die richtige Planung für interne und externe Sicherheit von großer Bedeutung. Wenn Sie Ihre Systeme korrekt eingestellt und konfiguriert haben, können Sie Probleme vermeiden.

Sie müssen in Ihren Sicherheitsrichtlinien geeignete Kompromisse schließen zwischen einer Umgebung mit strengen Zugriffsüberprüfungen und detaillierten Überwachungen, bei denen fast keine Ressourcen freigegeben werden können, und einer ressourcen- oder taskorientierten Umgebung, in der als Ausgleich für mehr Möglichkeiten für Ressourcenfreigabe und -Pooling eine gröbere Granularität für die Kennung möglich sein kann. Beachten Sie: Wenn Sie keine Sicherheitsrichtlinien festlegen, verfügen Ihre Systeme und Anwendungen über keinerlei Sicherheit. In jeder Implementierung muss vom ersten Tag an die Sicherheit beachtet werden.

Referenzmaterial

Security in COM+ (in Englisch)
Deciding Where To Enforce Security (in Englisch)
Using Distributed COM with Firewalls (in Englisch)

Auf dieser Seite

 Ändern Sie die Standardkennwörter
 Überprüfen Sie die Sicherheit am Einstiegspunkt
 Verwenden Sie Rollen zum Einstellen der Sicherheit für Ihre Anwendung
 Wählen Sie die richtige Sicherheitsgranularität
 Verwenden Sie für integrierte Anmeldungen bei der Sicherheitsdatenbank keine Delegierung
 Verteilen Sie Active Directory- und Anwendungsserverfunktionen
 Stellen Sie sicher, dass bei Bedarf Authentifizierung möglich ist
 Legen Sie das Timeout Ihrer Anwendung fest
 Installieren Sie Ihre Komponenten in COM+ (anstatt sie zu importieren)
 Stellen Sie sicher, dass zwischen dem COM+-Computer und dem SQL Server-Computer eine hinreichende RPC-Konnektivität besteht
 Verwenden Sie Terminaldienste als Remoteverwaltungstool
 Verwenden Sie für die Verbindung mit SQL Server Named Pipes anstelle von TCP/IP

Ändern Sie die Standardkennwörter

Aus dem Internet wird eine unglaublich große Menge an vertraulichen Daten (finanzielle und persönliche Daten ebenso wie Marketingdaten) gestohlen - nicht nur aufgrund ungenügender Sicherheitsarchitekturen, sondern auch, weil die Standardinstallationskennwörter von Datenbanken und Systemen unverantwortlicherweise beibehalten wurden. Wenn dies in Ihrem System nicht vorkommen soll, müssen Sie auf jeden Fall die Standardanmeldekennwörter für bekannte Benutzer im RDBMS, auf Windows NT-Computern und anderen Ressourcen ändern.

Dies ist keine Checkliste für die Sicherheit Ihres Systems, sondern eher eine Erinnerung daran, dass Sie etwas für die Sicherheit des Systems tun müssen:

• Ändern Sie das SQL Server-Benutzerkennwort sa, lassen Sie das Feld jedoch nicht leer. Verwenden Sie keinen Dummywert wie kennwort, sa, geheim o.Ä.

• Verwenden Sie für Benutzernamen oder Kennwörter auf ASP-Seiten keine Festcodierung. Diese Seiten könnten an Grafiker, Lokalisierungs-Engineers, Übersetzer usw. weitergegeben werden.

• Speichern Sie Sicherheitsinformationen in sicheren Datenspeichern, z.B. der Registrierung und dem Dateisystem. Stellen Sie sicher, dass Ihre Anwendung Kennwörter in Laufzeit aus der Registrierung oder dem Dateisystem lädt.

Wenn Hacker versuchen, sich von außen bei internen Ressourcen anzumelden, müssen Sie Ihre Firewall- und Netzwerkarchitektur neu konfigurieren. Wenn Sie das Kennwort ändern, haben Sie zwar einen ersten Schritt getan, die Angriffe werden jedoch fortgesetzt und irgendwann erfolgreich sein. Sie sollten in Betracht ziehen, fehlgeschlagene Anmeldungen zu überwachen.

Referenzmaterial

SQL Server 7.0 Security (in Englisch)
Connecting to SQL Server Over the Internet (in Englisch)
PRB: Cannot Change SA Password in Enterprise Manager (Q218172) (in Englisch)

Weitere hilfreiche Hyperlinks finden Sie im Abschnitt "Verwenden Sie UDL-Dateien für dauerhafte Verbindungszeichenfolgen".

 

Überprüfen Sie die Sicherheit am Einstiegspunkt

Sicherheitsüberprüfungen können auf viele verschiedene Arten und an vielen Stellen durchgeführt werden. Ein Verfahren ist jedoch weit verbreitet: die Sicherheitsüberprüfung beim erstmöglichen Einstiegspunkt. Durch diese Methode wird die Verwaltung vereinfacht, die Verbindung Ihrer Anwendung zu den verwendeten Ressourcen getrennt und die Skalierbarkeit verbessert, indem das System keine Zeit für Vorgänge aufwenden muss, die später fehlschlagen.

Weitere Informationen

Sie können die Sicherheit überprüfen und Hindernisse entweder am Einstiegspunkt (Beschränkung der Benutzer, die Komponenten aufrufen können) oder auf Ressourcenebene einfügen (Beschränkung der Benutzer, die eine Tabelle aktualisieren können). Auf den ersten Blick genügt es zwar, die Sicherheit auf Ressourcenebene zu überprüfen, dadurch werden jedoch die Möglichkeiten für Wachstum und Flexibilität verringert.

Sie müssen sicherstellen, dass Sie eine Sicherheitsüberprüfung der Geschäftslogik nicht in der Datenschicht durchführen. So möchten Sie z.B. Ihre Anwendung nicht so konfigurieren, dass die Berechtigung zum Hinzufügen eines Kunden durch das Zulassen oder Verweigern von EINFÜGUNGEN in der Tabelle eines Kunden erzwungen wird. Die Ausführung dieser Methode könnte fehlschlagen, wenn Ihre Anwendung wächst. Was geschieht z.B., wenn Sie dem Kunden eine E-Mail senden müssen?

Dadurch werden Schichten vermischt, und die Sicherheit der Komponenten wird an die Verwaltung und Implementierung der verwendeten Back-End-Ressourcen gebunden.

Vorgehensweise

Legen Sie die Sicherheit unter Verwendung von Rollen für Ihre Objekte fest. Gruppieren Sie die Methoden Ihrer Front-Line-Objekte, damit die Klassen taskorientiert anstatt entityorientiert sind (z.B. Transfer-Klassen anstelle von Checking- und Saving-Klassen). Dadurch wird die Verwaltung vereinfacht, und Sie können die Berechtigung auf Objekt- bzw. Schnittstellenebene anstatt auf Methodenebene festlegen.

Referenzmaterial

Assigning Roles to Components, Interfaces, or Methods (in Englisch)
Security Boundaries (in Englisch)
Deciding Where To Enforce Security (in Englisch)

 

Verwenden Sie Rollen zum Einstellen der Sicherheit für Ihre Anwendung

Rollen wurden eingeführt, um den Sicherheitsnamespace der Anwendung vom Netzwerk- oder Domänennamespace zu abstrahieren wird und es Ihren Codeanwendungen zu ermöglichen, auf die Verwendung durch verschiedene Anwendungsactors anstelle von spezifischen Benutzern zu reagieren. Diese Actors können für Gruppen (Manager) oder Anwendungen (Bankingkomponenten) stehen.

Sie können Rollen innerhalb Ihres Geschäftslogikcodes deklarativ (wie beim Einstellen von Berechtigungen in einer Datei) oder programmtechnisch verwenden.

Weitere Informationen

Festcodierte Benutzer-IDs, Gruppennamen oder andere in Ihren Codeanweisungen enthaltene Domänen- oder Netzwerkinformationen verbinden Ihre Anwendung mit Ihren Sicherheitsmechanismen und Netzwerknamespaces sowie mit dem Netzwerkadministrator. Ihre Anwendung wird u.U. beschädigt, wenn Ihre Verwaltungsprozeduren geändert werden oder wenn die Sicherheit neu organisiert wird. Wenn Sie als primäre Sicherheitsmethode Rollen verwenden, sorgen Sie für zukünftige Interoperabilität und eine einfachere Verwaltung.

Die Rollendefinition muss beim ersten Entwurf der Anwendung, nicht bei der endgültigen Bereitstellung, berücksichtigt werden. Wenn Sie Geschäftslogikcode schreiben und Rollen nicht berücksichtigt haben, riskieren Sie, größere Teile der Anwendung später neu entwickeln zu müssen. Nehmen Sie sich im Voraus die Zeit, und überdenken Sie Ihre Geschäftslösung mit Hinblick auf Rollen und deren Verwendung durch die Implementierung.

Wenn Sie Ihren Rollen geeignete Sicherheitskonten zuordnen, können Sie die Sicherheit in Ihrer Anwendung steuern, während sie entsteht. Dies kann deklarativ erfolgen, indem Sie Berechtigungen für Objekte, Schnittstellen oder Methoden festlegen, oder programmtechnisch, indem Sie die enthaltene Codelogik je nach Benutzer ändern.

Vorgehensweise

Sie erstellen Rollen für eine gegebene COM+-Anwendung, indem Sie sie dem Ordner Roles im MMC-Snap-In für Komponentendienste hinzufügen. Dann ist es genauso einfach, den Rollen Netzwerkgruppen und Benutzer hinzuzufügen, wie einer Datei Berechtigungen hinzuzufügen.

Sobald Sie die Rollen bestimmt haben, weisen Sie ihnen NT-Gruppen (und Benutzer) zu. Dann fügen Sie Rollen den entsprechenden Objekten, Schnittstellen und Methoden hinzu bzw. entfernen sie aus diesen. Wenn für ein Objekt, eine Schnittstelle oder eine Methode eine Rolle existiert, bedeutet dies, dass der Zugriff für alle NT-Gruppen und Benutzer, die zu dieser Rolle gehören, möglich ist. Beachten Sie Folgendes: Wenn mit einem Objekt bestimmte Rollen verknüpft sind, erben seine Schnittstellen und Methoden automatisch diese Rollen. Wenn eine Manager-Rolle auf das MoneyTransfer-Objekt zugreifen kann, hat die Manager-Rolle automatisch Zugriff auf die Schnittstellen und Rollen im Objekt.

Sie können auch die ObjectContext-Funktion IsCallerInRole verwenden, um programmtechnisch auf die Benutzer-ID zu reagieren. So können Sie z.B. Überweisungen von mehr als 20.000 DM für Benutzer aufhalten, die nicht Mitglied einer "Senior Account Managers"-Rolle sind.

Referenzmaterial

Designing Roles Effectively (in Englisch)
Role-Based Security (in Englisch)
Authorizing Clients Using Roles (in Englisch)
Configuring Role-based Security (in Englisch)

 

Wählen Sie die richtige Sicherheitsgranularität

Ein typisches Problem der Skalierbarkeit tritt auf, wenn die Identitätsgranularität zu klein ist. Muss z.B. jeder einzelne Endbenutzer in Ihrer Datenbank registriert sein (als Beispiel für eine sichere Ressource) oder reicht es aus, die spezifische Rolle oder den funktionalen Bereich zu kennen, zu denen dieser Vorgang gehört?

Vom Back-End aus gesehen wird eine Ressource in vielen Fällen eher von einer Anwendung als von einem spezifischen Benutzer verwendet. Eine gröbere Sicherheitsgranularität hat die folgenden Vorteile:

• Einfachere Verwaltung - Die Ressource verwaltet lediglich einige Benutzeranwendungen.

• Größere Skalierbarkeit - Komponenten, die Aktivitäten für verschiedene Anwender ausführen, können Verbindungen freigeben oder Verbindungs-Pooling nutzen.

Dadurch ist jedoch die Überwachung weniger feinkörnig. Dies hört sich zwar nach einem großen Nachteil an, Sie sollten jedoch hinsichtlich Ihrer Überwachungspläne und -prozesse realistisch sein.

Verwenden Sie möglichst keine separaten SQL Server-Anmeldungen für alle Benutzer einer Anwendung. Verwenden Sie für verschiedene Rollen verschiedene Anmeldungen. Statt also Benutzer A, B und C zu beschränken oder zu überwachen, stellen Sie für Ihre Rollen (Manager, Angestellte, Account Manager usw.) Datenbankberechtigungen ein. Sie erreichen dies, indem Sie verschiedene Verbindungszeichenfolgen verwenden, abhängig von den Rollen, mit denen der aktuelle Benutzer verknüpft ist.

Mit der folgenden Funktion können Sie diesen Task durchführen. Diese Codeanweisung geht von einigen einfachen Annahmen aus:

• Einige Rollen verfügen über spezifische SQL Server-Anmeldungen, die erzwungen werden müssen.

• Einige Rollen haben Vorrang vor anderen. Wenn ein Benutzer z.B. gleichzeitig Mitarbeiter und Manager ist, möchten Sie die Datenbank u.U. mit der Datenbank mit Manager-Zugriff verbinden.

• Die Komponente hat ein Array, das u.U. vom Konstruktor des Objekts mit einer Liste der Rollen in der entsprechenden Rangfolge abgerufen wurde. Das letzte Element in der Liste ist die Standardverbindung.

• Es gibt eine Gruppe von UDLs, deren Namen mit denen der Rollen auf demselben Pfad wie die DLL übereinstimmen.

Public Function GetRoleConnectionString(RoleList As Variant) As String 
    Dim i As Integer 
    Dim oCtx As ObjectContext 
    Set oCtx = GetObjectContext 
    For i = LBound(RoleList) To UBound(RoleList) - 1 
        If oCtx.IsCallerInRole(RoleList(i)) Then Exit For 
    Next i 
    'Wir erstellen aus dem UDL-Namen eine Verbindungszeichenfolge, 
    'indem wir FILE, den Pfad und die Erweiterung hinzufügen 
    GetRoleConnectionString = "FILE Name=" & App.path  & "\" &_ 
        RoleList(i) & ".UDL" 
    Set oCtx = Nothing 
End Function 

Diese Funktion kann auf die folgende Art verwendet werden:

' Nehmen wir an, wir haben eine kommagetrennte Liste mit bestimmten 
' Rollen, z.B.: "Manager,Mitarbeiter,Helpdesk,Standardbenutzer", die  
' von der Konstruktorzeichenfolge für das Objekt abgerufen wurde… 
'Deklarieren einer Position für unser Rollenarray 
Dim vRoles As Variant   
'Beispiel: Erstellen des Arrays aus einer kommagetrennten Zeichenfolge… 
'Sie haben diese Zeichenfolge u.U. vom Objektkonstruktor oder dem SPM 
'abgerufen. Beachten Sie die Rangfolge der Rollenliste - ein Benutzer, der 
'sowohl die Manager- als auch die Helpdesk-Rolle innehat, 
'erhält die Manager-Anmeldung. 
vRoles = Split("Manager,Mitarbeiter,Helpdesk,Standardbenutzer" , ",") 
'Öffnen der Verbindung! 
oADODBConnection.Open GetRoleConnectionString(vRoles) 

 

Verwenden Sie für integrierte Anmeldungen bei der Sicherheitsdatenbank keine Delegierung

Wie im Abschnitt "Wählen Sie die richtige Sicherheitsgranularität" erwähnt wurde, ist es nicht empfehlenswert, für jeden Benutzer eine Ressourcenanmeldung anzugeben. Wenn Sie jedoch diese Steuerung benötigen, verfügt COM+ über eine neue Funktion, mit der COM+-Komponenten als ein bestimmter Benutzer ausgeführt werden, um beim Zugriff auf bestimmte Ressourcen die Identität des Benutzers anzunehmen. Dadurch wird die Komponentenlogik vereinfacht, da keine künstliche Verknüpfung zwischen einer Aufrufer-ID und einer Anmeldung hergestellt werden muss.

Alle COM+-Anwendungen verfügen über eine Einstellung für eine Ebene des Identitätswechsels. Über diese Einstellung wird bestimmt, auf welcher Ebene die Komponente als der aufrufende Benutzer agiert. Die höchste Einstellung (Delegieren) ermöglicht Ihrer Komponente den Zugriff auf Remoteressourcen, die als aktueller Aufrufer angezeigt werden. Damit können Sie die integrierte Sicherheit von SQL Server optimal nutzen, indem Sie SQL Server NT-Anmeldungen für die Benutzer Ihrer Anwendung angeben.

Der wichtigste Vorteil des Identitätswechsels mit Delegieren ist, dass die Ressource ihre eigene Sicherheit bei feiner Granularität verwalten kann. So kann die DBA die SQL Server-Sicherheit und die Überwachung auf Benutzerebene verwalten.

Ein Nachteil des Identitätswechsels mit Delegieren für die Anmeldung bei Datenbanken ist, dass die Verbindungen nicht in einem Pool zusammengefasst werden können, da sie für einen bestimmten Benutzer geöffnet wurden. Dadurch wird die Anzahl der benötigten Verbindungen erheblich erhöht, und es kommt beim Herstellen oder Trennen der Verbindung zur Datenbank zu Verzögerungen.

Wenn Sie die integrierte Sicherheit von SQL Server verwenden, sind für Sie niedrigere Ebenen des Identitätswechsels geeignet, mit denen Sie über gröbere Granularität für die Anmeldungen verfügen. Sie können das Codebeispiel im Abschnitt "Wählen Sie die richtige Sicherheitsgranularität" verwenden, um einen flexiblen Kompromiss zwischen den Möglichkeiten "ein Benutzer - eine Anmeldung" und "alle Benutzer - eine Anmeldung" zu finden.

 

Verteilen Sie Active Directory- und Anwendungsserverfunktionen

Verwenden Sie Computer, die Active Directory ausführen, nicht als Anwendungsserver. Diese Computer sind i.d.R. Domänencontroller, und es kommt zwischen den Diensten, die auf diesen Computern gehostet werden, zu Konflikten um Netzwerkressourcen. Außerdem verwendet ein Domänencontroller sehr viele Speicherressourcen und lässt für Ihre Anwendung nur wenige Ressourcen übrig.

Weitere Informationen

Anwendungsserver müssen konsistent auf variierende Benutzerlasten und Serverzustandsszenarios reagieren können. Benutzer erwarten, dass die Reaktion auf ihre Anfragen während des gesamten Arbeitstags gleich bleibt. Parallele Pflichten als Domänencontroller beeinträchtigen die konsistente Leistung des Anwendungsservers und führen dazu, dass die Endbenutzer mit Ihrer Lösung nicht zufrieden sind. Die Aufgaben eines Domänencontrollers unterscheiden sich hinreichend von denen eines Anwendungsservers, so dass sie verschiedenen dedizierten Computern zugewiesen werden sollten.

Vorgehensweise

Versuchen Sie, die Ressourcennutzung zu isolieren und die gemeinsamen Fehlerpunkte zwischen Ihren Diensten zu minimieren. Wenn Sie zwei anspruchsvolle und wichtige Tasks auf demselben Computer ausführen, können Sie die gewünschte Verfügbarkeit, Zuverlässigkeit, Verwaltbarkeit und Fehlerisolierung nicht erzielen.

 

Stellen Sie sicher, dass bei Bedarf Authentifizierung möglich ist

Authentifizierung ist ein Vorgang, bei dem der Benutzer aufgrund der bei den Authentifizierungsstellen angegebenen Anmeldeinformationen eindeutig identifiziert wird. Auf dem Server geschieht dies, indem eine Verbindung zum Domänencontroller hergestellt und eine Bestätigung der aufrufenden ID angefordert wird. Es gibt viele Ebenen der DCOM-Authentifizierung. Sie reichen von Keine (der Server versucht nicht, den aufrufenden Benutzer zu überprüfen) bis Vertraulich (die Netzwerkpakete sind verschlüsselt und die Datenintegrität und Vertraulichkeit garantiert).

Die Authentifizierungsebene einer Kommunikation wird zwischen dem Client- und dem Servercomputer ausgehandelt. Die höhere Einstellung wird verwendet. Der Server versucht also, die strengere Einstellung zu verwenden, wenn die Einstellung des Client- und des Servercomputers unterschiedlich sind.

Weitere Informationen

Wenn bei einem Server ein Aufruf oder eine Objekterstellungsanforderung für eine DCOM-Einstellung eingeht und die Authentifizierungsebene höher als Keine ist, muss der Server bei einem Domänencontroller die Identität des Aufrufers überprüfen. Wenn jedoch keine Domänencontroller vorhanden sind oder der Aufruf aus einer nichtvertrauenswürdigen Domäne kommt, kann dieser Vorgang nicht durchgeführt werden, und der Aufruf schlägt fehl. Dabei wird eine Meldung zurückgegeben, dass der Zugriff verweigert wurde.

In diesem Fall müssen Sie entweder die Netzwerk- oder Vertrauenskonfiguration ändern oder die Authentifizierungsebene herabsetzen. An einem bestimmten Punkt können Sie die Authentifizierungsebene so herabsetzen, dass Anmeldeinformationen vom Dienstkontroll-Manager akzeptiert werden.

Vorgehensweise

Wenn Sie die Authentifizierungsebene auf dem Server einstellen möchten, öffnen Sie das COM+-Anwendungseigenschaftenblatt und wählen auf der Registerkarte Sicherheit die Option Authentifizierungsebene für Aufrufe. Schließen Sie danach Ihr Paket, damit die neue Einstellung übernommen wird.

Beim Client ist die Authentifizierungsebene auf Anwendungs- und Computerebene eingestellt. Auf einem typischen Windows NT 4.0- oder Windows 9x-Computer müssen Sie DCOMCNFG öffnen und die Standardauthentifizierungsebene sowie die Authentifizierungsebene der Anwendung ändern. Beachten Sie, dass es sich bei der effektiven, vom Server erzwungenen Ebene um die höhere handeln muss.

Wenn Sie Ihre Anwendung auf einem Windows 9x-Client verwenden, der nicht bei der Domäne angemeldet ist, müssen Sie die Authentifizierungsebene für den Clientcomputer und die COM+-Anwendung des Servers auf Keine stellen. Diese Einstellung können Sie auf der Registerkarte Sicherheit der Anwendungseigenschaften vornehmen.

Referenzmaterial

Setting Authentication (in Englisch)

 

Legen Sie das Timeout Ihrer Anwendung fest

COM+-Serveranwendungen verfügen über eine Timeouteinstellung, mit der Sie festlegen, wie lange die Anwendung inaktiv gewesen sein muss, bevor sie beendet wird. Jede COM+-Serveranwendung wird auf einem Computer als separater DLLHOST.EXE-Prozess ausgeführt. Jedem Prozess sind bestimmte Ressourcen zugewiesen. Häufig fragmentieren Anwendungsprozesse ihre privaten Speicherheaps oder verlieren sogar Speicherplatz, wenn sie Bibliotheken oder Komponenten verwenden, die nicht für die Ausführung auf Servern bestimmt sind.

Wenn der Prozess beendet wird, wird dieser Speicherpool an das Betriebssystem zurückgegeben, damit er einem anderen Prozess zugewiesen werden kann. Ihre Anwendung kann einen neuen Speicherpool verwenden, wenn sie neu gestartet wird. Bei den meisten Sites ist das automatische Beenden aufgrund häufiger Zugriffe nicht möglich. Wenn Sie jedoch die Wahl haben, sollten Sie diese proaktive Wartungsaktion durchführen.

Die Nutzungsfrequenz ist an Wochenenden, nachts oder zu anderen Zeiten für gewöhnlich niedriger. Stellen Sie das Timeout so ein, dass es zu einem Zeitpunkt mit geringer Auslastung eintritt.

Weitere Informationen

Einige Probleme hinsichtlich der Serveranwendungen, z.B. Speicherverlust, Handleverlust, Ablauf des Status usw., werden beim Beenden der Prozesse beseitigt. Obwohl Ihre Probleme dadurch nicht gelöst werden und unverzüglich behandelt werden sollten, können Sie u.U. die stärksten Symptome der Ressourcenauslastung umgehen, indem Sie ein proaktives Beenden der Anwendung zu einem Zeitpunkt festlegen, an dem dies nur geringe Auswirkungen hat.

Die einzige spürbare Beeinträchtigung ist, dass Ihr Datenbankverbindungs-Pool zurückgesetzt wird und der erste Benutzer, der die Anwendung nach dem Beenden verwendet, aufgrund des Zeitaufwands für das erneute Starten des Prozesses eine leichte Verzögerung bemerkt.

Vorgehensweise

Um den Timeoutwert einzustellen, öffnen Sie in der Verwaltung das Snap-In Komponentendienste, öffnen dann das COM+-Anwendungseigenschaftenblatt und klicken auf die Registerkarte Erweitert. Stellen Sie den Wert dann so wie in Abbildung 7 gezeigt ein.

Abbildung 7. Einstellen eines Anwendungstimeouts

Beachten Sie: Wenn ein Client auf ein Serverobjekt zugreift, ohne es zu verwenden, wird die Anwendung u.U. trotzdem beendet. Der Client muss dann die Verbindung erneut herstellen.

Die Anwendung muss auf dem Server aktiviert werden. Bibliotheksanwendungen verfügen über keinen Timeout, da sie über keinen eigenen Prozess verfügen.

Referenzmaterial

Types of COM+ Applications (in Englisch)

 

Installieren Sie Ihre Komponenten in COM+ (anstatt sie zu importieren)

Wenn Sie einer COM+-Anwendung mit Hilfe des MMC-Snap-Ins Komponentendienste Komponenten hinzufügen, stehen Ihnen zwei Möglichkeiten zur Verfügung:

1. Ziehen Sie die DLL-Datei per Drag & Drop in die Komponentenliste.

2. Klicken Sie mit der rechten Maustaste im Komponentenordner auf das Paket, wählen Sie Neu, und importieren Sie bereits registrierte Objekte, oder installieren Sie neue Komponenten.

Wenn Sie die zweite Methode verwenden, installieren Sie die Anwendung wie in Abbildung 8 angegeben.

Abbildung 8. Dialogfeld für die Komponenteninstallation

Weitere Informationen

Wenn Sie eine Komponente installieren, fragt MTS spezifische Informationen über Objekte, Schnittstellen und deren Attribute aus der DLL ab. Außerdem konfiguriert MTS die Komponente unter Berücksichtigung dieser Informationen.

Beim Importieren ändert MTS jedoch nur die lokalen Registrierungsinformationen, so dass sie auf MTS verweisen, damit die Objekte darin instantiiert werden. Dabei wird jedoch nicht überprüft, ob die Komponente tatsächlich in MTS installiert werden kann (trifft für Visual Basic nicht zu). Ein noch wichtigerer Aspekt ist, dass die DLL nicht mehr nach allen Attributen der Klassen abgefragt wird. Wenn also ein Klassenmodul so markiert war, dass es in Visual Basic Transaktionen benötigt, wird nach dem Import in MTS angezeigt, dass dieses Modul keine Transaktionen unterstützt.

Außerdem wird durch die Aktualisierung Ihres MTS-Servers auf Windows 2000 und COM+ die Migration von MTS-Paketen in COM+-Anwendungen erheblich vereinfacht, wenn die Komponenten installiert und nicht importiert werden.

Vorgehensweise

Wählen Sie im Assistenten zum Hinzufügen von Komponenten die Option Installieren, und wählen Sie die DLL, oder ziehen Sie die DLL vom Windows-Explorer in den Komponentenordner des Pakets.

Referenzmaterial

Installing New Components (in Englisch)
Importing Components (in Englisch)

 

Stellen Sie sicher, dass zwischen dem COM+-Computer und dem SQL Server-Computer eine hinreichende RPC-Konnektivität besteht

Wenn in einem Netzwerk separate Anwendungs- und Datenbankservercomputer verbunden sind, werden alle Transaktionen von den DTC-Diensten (Distributed Transaction Coordinator) auf beiden Computern koordiniert. Für die Kommunikation untereinander benötigen diese DTC-Dienste in einem verbindungsorientiertem Protokoll RPC (Remote Procedure Call). Dies kann ncacn_ip_tcp, ncacn_spx oder ncacn_nb_nb sein. Da die DTC-Dienste für Verweise aufeinander Hostnamen anstelle von IP-Adressen verwenden, müssen Sie sicherstellen, dass die Namensauflösung in beide Richtungen funktioniert.

Weitere Informationen

Die DTCs auf verschiedenen Computern koordinieren Transaktionen untereinander und in ihren jeweiligen lokalen Ressourcen-Managern. Für die Kommunikation benötigen sie eine RPC-Konnektivität. Dies setzt Folgendes voraus:

• Korrekte Anschlüsse sind für RPC verfügbar (wenn sich dazwischen ein Firewall befindet).

• Die korrekte Namensauflösung funktioniert in beide Richtungen.

Da der DTC eine zuverlässige Kommunikation benötigt, ist ein verbindungsorientiertes Transportprotokoll erforderlich. Beispiel: UDP/IP reicht nicht aus, aber TCP/IP. Diese sind durch das Präfix ncacn_ vor RPC-Transporten gekennzeichnet.

Vorgehensweise

Sie müssen sicherstellen, dass sich beide Computer über Ping nach Name abfragen können. Wenn Sie über einen Firewall verfügen, lesen Sie vorher die Dokumentation für RPC und den Firewall sorgfältig durch. Sie müssen die Anschlüsse 135 plus einen bestimmten Bereich (z.B. 1100 bis 1130) in beide Richtungen öffnen und Ihre Computer für die Verwendung dieses Bereichs konfigurieren.

Für die Diagnose von Kommunikationsproblemen können Sie das Dienstprogramm RPCPing verwenden, mit dem Sie die RPC-Konnektivität testen können. Wenn Sie RPCPing verwenden, stellen Sie sicher, dass Sie nach den oben aufgeführten Transporten suchen, indem Sie auf der Clientseite der mit Ping abgefragten Anwendung die Endpunktsuche wählen. Beachten Sie jedoch, dass das Dienstprogramm zum Testen der Konnektivität einen bestimmten Anschluss verwendet, der DTC-Verhalten nicht allzu zuverlässig wiedergibt. Dennoch handelt es sich hierbei um einen wichtigen Test.

Weitere Tools werden in der Microsoft Knowledge Base bereitgestellt, sobald sie verfügbar sind und entsprechend getestet wurden.

Referenzmaterial

XCLN: How to use RPCPing to Test RPC Communication (Q167260) (in Englisch)

 

Verwenden Sie Terminaldienste als Remoteverwaltungstool

Sie können Microsoft Terminal Server auf einem Windows 2000-Server so konfigurieren, dass die Remoteverwaltung vereinfacht wird. Terminal Server kann außerdem speziell für diese Aufgabe konfiguriert werden, so dass die Terminalverwaltung die Qualität des Serverdienstes nicht beeinträchtigt. Außerdem können die Terminaldienste auch für die Steuerung der Sitzung eines anderen Benutzers verwendet werden, wobei die gemeinsame Verwaltung und Helpdeskszenarios aktiviert werden.

Using Terminal Services for Remote Administration of the Windows 2000 Server Family (in Englisch)
How to Use the Terminal Services Remote Control Feature (Q232792) (in Englisch)

 

Verwenden Sie für die Verbindung mit SQL Server Named Pipes anstelle von TCP/IP

Es gibt mehrere Möglichkeiten, eine Verbindung mit SQL Server herzustellen, z.B. TCP/IP, Named Pipes und Multiprotokoll-RPC.

Weitere Informationen

Wenn Sie TCP/IP für die Verbindung mit SQL Server verwenden, können Sie die folgenden Vorteile nutzen:

• Einfachere Konnektivitätskonfiguration, selbst über einen Firewall.

• Sie haben nicht die Sicherheitsauswirkungen, die bei der Verwendung von Named Pipes im Netzwerk auftreten (zusätzliche Sicherheitsprobleme neben der SQL Server-Zugriffssteuerung).

• Bei einem höheren Datenvolumen erhalten Sie eine bessere Leistung und größere Skalierbarkeit.

Sie möchten u.U. in naher Zukunft XML in HTTP als Datenbankprotokoll verwenden. Dies ist ab SQL Server 2000 verfügbar, diese Anwendung ist derzeit jedoch nur als Betaversion vorhanden. Wenn weitere Informationen und erfolgreiche Implementierungen verfügbar werden, wird dieses Dokument entsprechend erweitert.

Vorgehensweise

Sie können das Protokoll im SQL Server-Clientkonfigurationsprogramm wählen oder das gewünschte Protokoll in der Verbindungszeichenfolge angeben. Da SQL Server 7.0 Named Pipes als Standard vorgibt, könnte es sein, dass Sie diese Konfiguration nach der Installation überprüfen müssen.

Referenzmaterial

How to Configure a Client to Use TCP/IP (Client Network Utility) (in Englisch)
Using the SQL Server Client Network Utility (in Englisch)
HOWTO: Change SQL Server Default Network Library Without Using Client Network Utility (Q250550) (in Englisch)
Parameter für Verbindungen zwischen ODBC und SQL-Server