Spalte "Iis Developer Support Voice"
Kerberos-Authentifizierung und Problembehandlung bei Delegierungsproblemen
Um diese Spalte an Ihre Anforderungen anzupassen, möchten wir Sie einladen, Ihre Ideen zu Themen, die Sie interessieren, und Problemen, die in zukünftigen Knowledge Base-Artikeln und Support Voice-Spalten behandelt werden sollen, zu übermitteln. Sie können Ihre Ideen und Ihr Feedback über das Formular Ask For It einreichen. Es gibt auch einen Link zum Formular unten in dieser Spalte.
Mein Name lautet <Name>, und ich bin in der Gruppe kritischer Problemauflösungen Microsoft-Internetinformationsdienste (IIS) von Microsoft. Ich war neun Jahre bei Microsoft und war alle neun Jahre beim IIS-Team. Ich habe Informationen von mehreren Speicherorten zu
http://msdn.microsoft.com und
http://www.microsoft.com zu Kerberos und zur Behandlung von Delegierungsproblemen zusammengestellt.
IIS 6.0
Im folgenden Whitepaper wird beschrieben, wie Sie die Delegierung in Microsoft Windows Server 2003 einrichten. Das Whitepaper enthält spezifische Informationen zum Netzwerklastenausgleich (Network Load Balancing, NLB), enthält jedoch hervorragende Details zum Einrichten eines delegierten Szenarios ohne NlB. Dieses Whitepaper finden Sie auf der folgenden Microsoft-Website:
http://technet.microsoft.com/en-us/library/cc757299.aspxHinweis Verwenden Sie HTTP-Dienstprinzipalnamen (SPNs), insbesondere wenn Sie NLB verwenden.
Ein weiteres beliebtes Kerberos-Problem in letzter Zeit war die Notwendigkeit, mehreren Anwendungspools die Verwendung desselben DNS-Namens zu ermöglichen. Wenn Sie Kerberos zum Delegieren von Anmeldeinformationen verwenden, können Sie leider nicht denselben Dienstprinzipalnamen (Service Principal Name, SPN) an verschiedene Anwendungspools binden. Dies ist aufgrund des Kerberos-Entwurfs nicht möglich. Das Kerberos-Protokoll erfordert mehrere gemeinsam genutzte Geheimnisse, damit das Protokoll ordnungsgemäß funktioniert. Durch die Verwendung desselben SPN für verschiedene Anwendungspools beseitigen wir eines dieser gemeinsam genutzten Geheimnisse. Der Active Directory-Verzeichnisdienst unterstützt diese Konfiguration des Kerberos-Protokolls aufgrund des Sicherheitsproblems nicht.
Wenn Sie die SPNs auf diese Weise konfigurieren, tritt bei der Kerberos-Authentifizierung ein Fehler auf. Eine mögliche Problemumgehung wäre die Verwendung des Protokollübergangs. Die anfängliche Authentifizierung zwischen dem Client und dem Server, auf dem IIS ausgeführt wird, wird mithilfe des NTLM-Authentifizierungsprotokolls verarbeitet. Kerberos würde die Authentifizierung zwischen IIS und dem Back-End-Ressourcenserver übernehmen.
Microsoft Internet Explorer 6 oder höher
Im Clientbrowser können Probleme auftreten, z. B. das Empfangen von wiederholten Anmeldeaufforderungen zur Eingabe von Anmeldeinformationen oder die Fehlermeldung "401 Zugriff verweigert" vom Server, auf dem IIS ausgeführt wird. Wir haben die folgenden zwei Probleme gefunden, die bei der Behebung dieser Probleme helfen können:
-
Vergewissern Sie sich, dass integrierte Windows-Authentifizierung aktivieren in den Eigenschaften des Browsers ausgewählt ist.
-
Wenn internet Explorer Enhanced Security Configuration unter Software aktiviert ist, müssen Sie der ListeVertrauenswürdige Sites einen Standort hinzufügen, der delegierung
verwendet. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:815141 Geändertes Browserverhalten durch die verstärkte Sicherheitskonfiguration für Internet Explorer
IIS 5.0 und IIS 6.0
Nach dem Upgrade von IIS 4.0 auf IIS 5.0 oder IIS 6.0 funktioniert die Delegierung möglicherweise nicht ordnungsgemäß, oder möglicherweise hat jemand oder eine Anwendung die Metabasiseigenschaft NTAuthenticationProviders geändert.
Ein bestimmter Problembereich kann auftreten, wenn Sie den SPN festlegen.
Ermitteln des Servernamens
Bestimmen Sie, ob Sie eine Verbindung mit der Website herstellen, indem Sie den tatsächlichen NetBIOS-Namen des Servers oder einen Aliasnamen verwenden, z. B. einen DNS-Namen (z. B. www.microsoft.com). Wenn Sie auf den Webserver mit einem anderen Namen als dem tatsächlichen Namen des Servers zugreifen, muss mit dem Setspn-Tool aus dem Windows 2000 Server Resource Kit ein neuer Dienstprinzipalname (Service Principal Name, SPN) registriert worden sein. Da der Active Directory-Verzeichnisdienst diesen Dienstnamen nicht kennt, erhalten Sie vom Ticketgewährungsdienst (TGS) kein Ticket zur Authentifizierung des Benutzers. Dieses Verhalten zwingt den Client, die nächste verfügbare Authentifizierungsmethode ( NTLM) zu verwenden, um neu zu verhandeln. Wenn der Webserver auf den DNS-Namen www.microsoft.com der Server aber webserver1.development.microsoft.com benannt ist, müssen Sie www.microsoft.com in Active Directory auf dem Server registrieren, auf dem IIS ausgeführt wird. Dazu müssen Sie das Setspn-Tool herunterladen und auf dem Server installieren, auf dem IIS ausgeführt wird.
Um zu ermitteln, ob Sie eine Verbindung mithilfe des tatsächlichen Namens herstellen, versuchen Sie, eine Verbindung mit dem Server herzustellen, indem Sie den tatsächlichen Namen des Servers anstelle des DNS-Namens verwenden. Wenn Sie keine Verbindung mit dem Server herstellen können, lesen Sie den Abschnitt "Überprüfen, ob der Computer für die Delegierung vertrauenswürdig ist".
Wenn Sie eine Verbindung mit dem Server herstellen können, führen Sie die folgenden Schritte aus, um einen SPN für den DNS-Namen festzulegen, den Sie zum Herstellen einer Verbindung mit dem Server verwenden:
-
Installieren Sie das Setspn-Tool.
-
Öffnen Sie auf dem Server, auf dem IIS ausgeführt wird, eine Eingabeaufforderung, und öffnen Sie dann den Ordner C:\Programme\Resource Kit.
-
Führen Sie den folgenden Befehl aus, um diesen neuen SPN (www.microsoft.com) dem Active Directory für den Server hinzuzufügen:
Setspn -A HTTP/www.microsoft.com webserver1Hinweis In diesem Befehl stellt webserver1 den NetBIOS-Namen des Servers dar.
Sie erhalten eine Ausgabe, die der folgenden ähnelt:
Registrieren von ServicePrincipalNames für CN=webserver1,OU=Domänencontroller,DC=microsoft,DC=com
HTTP/www.microsoft.com
Aktualisiertes Objekt
Um eine Liste der SPNs auf dem Server anzuzeigen, um diesen neuen Wert anzuzeigen, geben Sie den folgenden Befehl auf dem Server ein, auf dem IIS ausgeführt wird:
Setspn -L webservername Beachten Sie, dass Sie nicht alle Dienste registrieren müssen. Viele Diensttypen wie HTTP, W3SVC, WWW, RPC, CIFS (Dateizugriff), WINS und unterbrechungsfreie Stromversorgung (USV) werden einem Standarddiensttyp namens HOST zugeordnet. Wenn Ihre Clientsoftware beispielsweise einen SPN von HTTP/webserver1.microsoft.com verwendet, um eine HTTP-Verbindung mit dem Webserver auf dem webserver1.microsoft.com-Server herzustellen, aber dieser SPN nicht auf dem Server registriert ist, zuordnen die Windows 2000-Domänencontroller die Verbindung automatisch host/webserver1.microsoft.com. Diese Zuordnung gilt nur, wenn der Webdienst unter dem lokalen Systemkonto ausgeführt wird.
Überprüfen, ob der Computer für die Delegierung vertrauenswürdig ist
Wenn dieser Server, auf dem IIS ausgeführt wird, ein Mitglied der Domäne, aber kein Domänencontroller ist, muss der Computer vertrauenswürdig sein, damit die Delegierung von Kerberos ordnungsgemäß funktioniert. Gehen Sie dazu wie folgt vor:
-
Klicken Sie auf dem Domänencontroller auf Start, zeigen Sie auf Einstellungen, und klicken Sie dann auf Systemsteuerung.
-
Öffnen Sie in Systemsteuerung Verwaltungstools.
-
Doppelklicken Sie auf Active Directory-Benutzer und -Computer.
-
Klicken Sie unter Ihrer Domäne auf Computer.
-
Suchen Sie in der Liste den Server, auf dem IIS ausgeführt wird, klicken Sie mit der rechten Maustaste auf den Servernamen, und klicken Sie dann auf Eigenschaften.
-
Klicken Sie auf die Registerkarte Allgemein, aktivieren Sie das
KontrollkästchenVertrauenswürdig für Delegierung, und klicken Sie dann auf
OK.
Beachten Sie, dass die Delegierung nicht funktioniert, wenn mehrere Websites über dieselbe URL, aber über unterschiedliche Ports erreicht werden. Damit dies funktioniert, müssen Sie unterschiedliche Hostnamen und unterschiedliche SPNs verwenden. Wenn internet Explorer eine http://www anfordert.mywebsite.com oder http://www.mywebsite.com:81, Internet Explorer fordert ein Ticket für SPN HTTP/www.mywebsite.com an. Internet Explorer fügt der SPN-Anforderung weder den Port noch den Vdir hinzu. Dieses Verhalten ist für http://www identisch.mywebsite.com/app1 oder http://www.mywebsite.com/app2. In diesem Szenario fordert Internet Explorer ein Ticket für SPN-http://www an.mywebsite.com aus dem Key Distribution Center (KDC). Jeder SPN kann nur für eine Identität deklariert werden. Daher erhalten Sie auch eine KRB_DUPLICATE_SPN Fehlermeldung, wenn Sie versuchen, diesen SPN für jede Identität zu deklarieren.
Delegierung und Microsoft ASP.NET
Weitere Informationen zur Konfiguration zum Delegieren von Anmeldeinformationen bei Verwendung einer ASP.NET-Anwendung finden Sie im folgenden Artikel der Microsoft Knowledge Base:
810572 Konfigurieren einer ASP.NET-Anwendung für ein Delegierungsszenario
Identitätswechsel und Delegierung sind zwei Methoden für die Authentifizierung eines Servers im Namen des Clients. Die Entscheidung, welche dieser Methoden und deren Implementierung verwendet werden sollen, kann zu Verwirrung führen. Sie müssen den Unterschied zwischen diesen beiden Methoden überprüfen und untersuchen, welche dieser Methoden Sie für Ihre Anwendung verwenden möchten. Meine Empfehlung wäre, das folgende Whitepaper für weitere Details zu lesen:
Informationsquellen
http://technet.microsoft.com/en-us/library/cc757299.aspxhttp://msdn.microsoft.com/msdnmag/issues/05/09/SecurityBriefs/default.aspx
262177 Aktivieren der Kerberos-Ereignisprotokollierung
Behandeln von Kerberos-Fehlern in Internet Explorer
Wie immer können Sie Ideen zu Themen einreichen, die Sie in zukünftigen Spalten oder in der Wissensdatenbank behandeln möchten, indem Sie das Formular Fragen verwenden.
