Announcement

**Andreas Kosch** · 19.02.2003, 07:53

Hallo,

tritt das Problem auch bei der folgenden Web.config auf?
<pre>
<configuration>
<system.web>
<authentication mode="Windows" />
<identity impersonate="true" />
<authorization>
<allow users="*">
<deny users="?" />
</authorization>
</system.web>
</configuration>
</pre>
Wenn ja, was liefert die folgende Pr�fung zur�ck, wenn der Anwender die Seite aufruft?
<pre>
private void Page_Load(object sender, System.EventArgs e)
{
if (User.Identity.IsAuthenticated)
{
this.Label3.Text = "Authenticated: " + User.Identity.Name;
}
else
{
this.Label3.Text = "Nicht Authenticated";
}
}
</pre>
Geh�ren die Rechner f�r den Web-Server (ASP.NET) und den SQL-Server zur gleichen Dom�ne, an der auch die User angemeldet sind

**Thomas Hempeler** · 19.02.2003, 12:52

Hallo,

meine Web-Config Datei sieht genau so aus wie oben beschrieben. Mit der Methode User.Identity.Name bekomme ich auch die richtige UserID angezeigt.

Das Durchreichen der UserID klappt ja auch, wenn beider Server auf einer Maschine installiert sind. Das Problem muss also beim weiterreichen der UserID an den entfernten Server durch die ASP-Engine liegen. Bei einer Windows-Forms funktionert es �brigens auch wunderbar.

Beide Server sind in der selben Dom�ne angemeldet

**Andreas Kosch** · 20.02.2003, 08:40

Hallo,

in der Theorie sollte das im Idealfall eigentlich auch funktionieren: Wenn der IIS einen Request-Aufruf auf eine Ressource erh�lt, die f�r ASP.NET registriert ist (wie zum Beispiel im Fall einer ASPX-Datei), so wird dieser Aufruf an die ISAPI-DLL aspnet_isapi.dll weitergeleitet. Diese DLL l�uft im gleichen Prozess wie der IIS selbst (also in inetinfo.exe). Eine ASP.NET-Anwendung des IIS 5.x (der neue 6.0 arbeitet anders!) wird jedoch in einem separaten Prozess (aspnet_wp.exe) ausgef�hrt, daher muss die ISAPI-DLL den Aufruf �ber eine Namep Pipe an den ASP.NET-Prozess weiterleiten, wobei diese Instanz des Workerprozesses vorher �ber LogonUser und CreateProcessAsUser unter dem festgelegten Benutzerkonto ausgef�hrt wird, das in der Konfigurationsdatei machine.config (Framework-Unterverzeichnis von Windows) vom Eintrag processModel festgelegt wird. Innerhalb des ASP.NET-Prozesses schotten verschiedene Application Domains (AppDomain) die ASP.NET-Anwendungen voneinerander ab. Wenn aspnet_isapi.dll den Request-Aufruf an aspnet_wp.exe weiterleitet, �bertr�gt es auch den vom IIS erhaltenen Access Token an ASP.NET. Dieser Access Token sieht je nach Konfiguration unterschiedlich aus: 
a) Anonymer Zugriff im IIS erlaubt: ISUR_machinename 
b) Authentifizierter Zugriff im IIS erzwungen: Benutzername 
Bevor ASP.NET diesen Request-Aufruf weiterverarbeitet, wird zuerst gepr�ft, ob das erhaltene Access Token f�r die angeforderte Ressource die ACL Authorization (Zugriffspr�fung durch das NTFS-Dateisystem) besteht. ASP.NET arbeitet diese Pr�fung in jedem Fall ab, auch wenn die ASP.NET-Anwendung die Impersonation aktiviert hat. War diese Pr�fung erfolgreich, so wird das Access Token der ASP.NET-Anwendung zur Verf�gung gestellt, so dass die Anwendung �ber die Impersonation eine benutzerabh�ngige Zugriffsberechtigung nutzen kann.

Um die Ursache f�r dieses Problem einzukreisen, k�nnte man den folgenden Test machen: Eine ASP.NET-Seite (ohne Impersonation) arbeitet die Schritte in eigener Regie ab, indem sie selbst LogonUser aufruft und das Ergebnis �ber 5 Label-Instanzen im Web Form zur�ckliefert: Die Anzeige sollte dabei von Rechnername\ASPNET auf Rechnername\NeuerBenutzername wechseln. Allerdings wird auch das letztendlich auch nicht so wie anfangs geplant funktionieren (Grund daf�r siehe unten):<pre>
Imports System.Security.Principal
Imports System.Runtime.InteropServices
Imports System.Data.SqlClient
..
<DllImport("advapi32.dll")> _
Public Shared Function LogonUser(ByVal lpszUsername As String, ByVal lpszDomain As String, ByVal lpszPassword As String, _
ByVal dwLogonType As Integer, ByVal dwLogonProvider As Integer, ByRef phToken As Integer) As Boolean
End Function

<DllImport("Kernel32.dll")> _
Public Shared Function GetLastError() As Integer
End Function

Private sNewUserName As String = "Benutzername"
Private sNewUserDomain As String = "Servername"
Private sNewUserPasswd As String = "Benutzerpasswort"

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
' Default-Zustand anzeigen: Rechnername\ASPNET
Me.Label1.Text = System.Security.Principal.WindowsIdentity.GetCurre nt().Name
' LogonUser = anderers Benutzerkonto aktivieren
Dim iLUToken As Integer
Dim bLoggedOn As Boolean = LogonUser(sNewUserName, sNewUserDomain, sNewUserPasswd, 3, 0, iLUToken)
Dim iLastError As Integer = GetLastError()
If ((iLastError <> 0) AndAlso (iLastError <> 126)) Then
Me.Label2.Text = iLastError.ToString()
Else
Me.Label2.Text = "Logon User war erfolgreich: " + bLoggedOn.ToString()
End If
' Impersonate
Dim aWIToken As IntPtr = New IntPtr(iLUToken)
Dim aNewWI As WindowsIdentity = New WindowsIdentity(aWIToken)
Dim aNewWIC As WindowsImpersonationContext = aNewWI.Impersonate()
' Erfolg anzeigen: Rechnername\NeuerBenutzername
Me.Label3.Text = System.Security.Principal.WindowsIdentity.GetCurre nt().Name
'
Dim strConn As String = "data source=ServerName;initial catalog=Northwind;integrated security=SSPI;"
Dim aCon As New SqlConnection(strConn)
Dim aCmd As New SqlCommand("SELECT CompanyName FROM Customers WHERE CustomerID = 'FRANK'", aCon)
Dim aDR As SqlDataReader
aCon.Open()
Try
aDR = aCmd.ExecuteReader()
aDR.Read()
Me.Label5.Text = aDR(0).ToString()
Finally
aDR.Close()
aCon.Close()
End Try
' Impersonate r�ckg�ngig machen
aNewWIC.Undo()
' Erfolg anzeigen: Rechnername\ASPNET
Me.Label4.Text = System.Security.Principal.WindowsIdentity.GetCurre nt().Name
End Sub
</pre>
Wenn dieser Test des direkten Logons auch nicht zum Ziel f�hrt, m�ssen wir vermutlich das Kleingedruckte nochmals gr�ndlicher durcharbeiten. Auf der Hilfeseite IIS Authentication der .NET Framework-Hilfe ist der folgende Satz zu finden: "When used in conjunction with Kerberos v5 authentication, IIS can delegate security credentials among computers running Windows 2000 and later that are trusted for delegation. Delegation enables remote access of resources on behalf of the delegated user. ". Bisher habe ich selbst auf die Impersonation f�r den MS SQL Server verzichtet, das dies zum einen Rechnenzeit kostet und zum anderen auch den automatischen Datenbankverbindungs-Pool ausbremst.

Im dem �ber die URL http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/authaspdotnet.asp verf�gbaren Microsoft-Papier ist die folgende Einschr�nkung f�r Integrated Windows Authentication zu finden: "The NTLM protocol does not support delegation. After the client's credentials are passed to the IIS server, they cannot be passed to a back-end server for authentication. However, Kerberos supports delegation, which allows the client credentials to be delegated to other processes on multiple downstream computers. For example, you can use Kerberos to present a Web user's credentials to a COM+ middle tier and through to a Microsoft SQL Server� database, configured with Windows Integrated Security. Kerberos authentication is not enabled in a default Active Directory configuration. You must ensure your environment will support Kerberos before depending on it as a delegation solution.".

Fazit: Die Theorie funktioniert anscheinend erst dann in der Praxis, wenn man den Weg der Standardkonfiguration des IIS 5 verl�sst und zu Kerberos wechselt.

&#10

**Thomas Hempeler** · 27.02.2003, 19:36

Leider komme ich immer noch nicht klar. Wie aktiviere ich denn Kerberos? Kann ich das f�r meinen Server machen oder muss das auf dem Dom�nenserver aktiviert werden? Leider kenne ich mich mit dem NT-Berechtigungskonzept zu wenig aus :-(

**Andreas Kosch** · 28.02.2003, 08:02

>Wie aktiviere ich denn Kerberos?

Im Kleingedruckten steht, dass im Fall von NTLM die Rechte nicht auf einen dritten Rechner delegiert werden k�nnen. Um das zu nutzen, m�ssen alle beteiligten Rechner anstelle von NTLM zu Kerberos welchseln. In der Voreinstellung probieren alle Windows 2000-Clients bereits die Authentifizierung beim AD �ber Kerberos - antwortet das Active Directory darauf jedoch nicht, machen die Windows 2000-Clients einen Fallback zu NTLM. Werden Windows 9x-/Me-/NT4-Client eingesetzt, steht Kerberos nicht zur Verf�gung.

Wird auf einem Windows 2000 Server ein Active Directory installiert, so kommt automatisch auch ein Kerberos Key Distribution Center (KDC) auf den Server. Der KDC muss dann nur noch aktiviert werden (Default Domain Policy | Computer Configuration | Windows Settings | Security Settings | Kerberos Policy) und die jeweiligen Benutzerkonten muss als "Vertrauensw�rdig" markiert werden (Properties | Account | Account ist trusted for delegation)

**Tino Richter** · 24.05.2003, 19:01

Hallo Herr Hempeler,
ich habe das gleiche Problem unter NT.
Haben Sie eine L�sung gefunden?
Wenn ja, w�re ich sehr dankbar wenn Sie mir weiterhelfen k�nnen.

Wenn ich mich direkt am IIS Server mit einem auf dem SQl Server eingetragenen User Account anmelde, kann ich von anderen Clients eine bestimmte Zeit lang die Datenbank abfragen.
Nach ca. zwei Minuten ist dies nicht mehr m�glich

**Thomas Hempeler** · 03.07.2003, 21:50

Leider bis heute noch nicht. Ich bin jetzt komplett auf SQL-Server Logins umgestiegen und pr�fe ggf. Berechtigungen im Quellcode

Announcement

Problem mit ASP und SQL-Server und Trusted Connection

Problem mit ASP und SQL-Server und Trusted Connection

Comment

Comment

Comment

Comment

Comment

Comment

Comment