Tożsamość procesu i żądania w programie ASP.NET

Tłumaczenia artykułów Tłumaczenia artykułów
Numer ID artykułu: 317012 - Zobacz jakich produktów dotyczą zawarte w tym artykule porady.
Rozwiń wszystko | Zwiń wszystko

Na tej stronie

Streszczenie

W tym artykule omówiono uprawnienia dostępu przydzielane domyślnemu kontu procesu oraz opisano niektóre sytuacje, w których te uprawnienia mogą być zbyt restrykcyjne dla niektórych zadań.

W domyślnej instalacji programu ASP.NET w systemach Microsoft Windows 2000 i Microsoft Windows XP usługa ASP.NET wykonuje kod aplikacji sieci Web w procesie roboczym. Tożsamość tego procesu korzysta domyślnie z lokalnego konta o nazwie ASPNET (pełna nazwa to konto aspnet_wp). W wersjach beta programu ASP.NET tożsamością procesu jest System, czyli wydajne konto administracyjne obejmujące wiele uprawnień dostępu na komputerze. Aby zapewnić instalacji domyślnej niższy poziom uprzywilejowania, ostateczna wersja programu ASP.NET korzysta ze słabszego konta ASPNET, które jest odpowiednie dla większości aplikacji sieci Web.

Uwaga W przypadku korzystania z Internetowych usług informacyjnych (IIS) firmy Microsoft w wersji 6.0 aplikacje sieci Web programu ASP.NET będą domyślnie uruchamiane w kontekście zabezpieczeń konta NetworkService.

Więcej informacji

Konfigurowanie tożsamości procesu

Tożsamość procesu można skonfigurować w sekcji <processModel> pliku Machine.config w podkatalogu Config katalogu instalacyjnego. Atrybuty userName i password sterują tożsamością procesu. Domyślne wartości tych atrybutów są następujące:
 <processModel  userName="machine" password="AutoGenerate" /> 				
Wartości machine i AutoGenerate instruują program ASP.NET, że ma korzystać z wbudowanego konta ASPNET oraz używać kryptograficznie silnego losowego hasła zapisanego w Lokalnym urzędzie zabezpieczeń (LSA) dla tego konta.

Jeśli trzeba korzystać z konta mającego większe uprawnienia dostępu, można nadać atrybutowi userName wartość System, co spowoduje, że proces roboczy program ASP.NET będzie działał z tą samą tożsamością, co proces Inetinfo.exe. Proces Inetinfo.exe działa domyślnie z tożsamością System. Jeśli proces roboczy programu ASP.NET zostanie skonfigurowany do działania z tożsamością System, wówczas będzie miał dostęp niemal do wszystkich zasobów lokalnego komputera. Na komputerach z systemem Windows 2000 lub Windows XP konto System ma także poświadczenia sieciowe i ma dostęp do zasobów sieciowych jako konto komputera. Aby skonfigurować proces do działania z tożsamością System, należy w następujący sposób zmienić atrybut userName w sekcji <processModel>:
 <processModel  userName="SYSTEM" password="AutoGenerate" /> 				

Domyślne uprawnienia konta ASPNET

Konto ASPNET jest tworzone jako konto lokalne w czasie instalacji programu ASP.NET. Konto ASPNET należy na tym komputerze tylko do grupy Użytkownicy. Dlatego konto ASPNET ma wszystkie uprawnienia skojarzone z grupą Użytkownicy i dostęp do wszelkich zasobów, do których grupa Użytkownicy ma uprawnienia dostępu. Konto ASPNET dziedziczy z grupy Użytkownicy następujące uprawnienia użytkownika:
  • SeChangeNotifyPrivilege
  • SeUndockPrivilege
  • SeInteractiveLogonRight
  • SeNetworkLogonRight
Oprócz tych uprawnień konto ASPNET otrzymuje domyślnie następujące dodatkowe uprawnienia:
  • SeServiceLogonRight
  • SeBatchLogonRight
  • SeDenyInteractiveLogonRight
Program ASP.NET udziela kontu ASPNET konkretne uprawnienia pełnego dostępu do następujących folderów:
  • Tymczasowe pliki ASP.NET
  • %windir%\temp
Ponadto program ASP.NET udziela uprawnienie Odczyt do katalogu instalacyjnego programowi Microsoft .NET Framework.

Poniższa lista przedstawia Listy kontroli dostępu (ACL) wymagane dla konta ASPNET. Domyślne instalacje systemu Windows 2000 i programu Microsoft .NET Framework zawierają te listy ACL.
  • Lokalizacja: %installroot%\ASP.NET Temporary Files
    Typ dostępu: Odczyt/Zapis do folderu i Wyświetlanie zawartości folderu dla folderu katalogu głównego dysku
    Konto: Konto procesu i skonfigurowane konta personifikacji
    Opis: To jest lokalizacja dynamicznej kompilacji programu ASP.NET. Poniżej tej lokalizacji jest generowany kod aplikacji, w osobnych katalogach dla poszczególnych aplikacji. Aby skonfigurować lokalizację katalogu głównego, można użyć atrybutu tempDir w sekcji <compilation>.

    Uwaga Jeśli zostanie zmieniony plik machine.config, aby tymczasowe pliki ASP.NET były zapisywane w innej lokalizacji, to konto ASPNET musi mieć typ dostępu Wyświetlanie zawartości folderu do katalogu głównego dysku.
  • Lokalizacja: %windir%\temp
    Typ dostępu: Odczyt/Zapis
    Konto: Konto procesu
    Opis: To jest lokalizacja używana przez Usługi XML (Extensible Markup Language) sieci Web do generowania serwerów proxy serializacji.
  • Lokalizacja: Katalog aplikacji
    Typ dostępu: Odczyt
    Konto: Konto procesu i skonfigurowane konta personifikacji
    Opis: To jest lokalizacja zawartości aplikacji (jedynie Odczyt jest wymagany).
    Aby uzyskać więcej informacji, odwiedź następującą witrynę firmy Microsoft w sieci Web:
    http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT01.asp
  • Lokalizacja: Katalog główny witryny sieci Web (%systemdrive%\inetpub\wwwroot lub ścieżka, na którą wskazuje domyślna witryna sieci Web)
    Typ dostępu: Odczyt
    Konto: Konto procesu i skonfigurowane konta personifikacji
    Opis: Program ASP.NET próbuje odczytać pliki konfiguracyjne i monitorować zmiany w dysk:\inetpub\wwwroot\web.config.
  • Lokalizacja: Hierarchia %installroot%
    Typ dostępu: Odczyt
    Konto: Konto procesu i skonfigurowane konta personifikacji
    Opis: Program ASP.NET musi mieć możliwość dostępu do zestawów programu .NET Framework w pliku Machine.config (w podkatalogu \Config katalogu %installroot%).
  • Lokalizacja: %windir%\assembly
    Typ dostępu: Odczyt
    Konto: Konto procesu lub skonfigurowane konta personifikacji
    Opis: To jest globalny bufor zestawów, zawierający zestawy współużytkowane.
Więcej informacji na temat domyślnych list ACL dla komputerów z systemem Windows 2000 znajduje się w dokumencie „Default Access Control Settings in Windows 2000” w sekcji MATERIAŁY REFERENCYJNE .

Uwaga Domyślnie konto ASPNET na ogół nie ma właściwych uprawnień dostępu, aby wykonać niektóre zadania opisane w tym artykule.

Dostęp do zasobów

W poniższych sekcjach opisano, jak korzystać z różnych zasobów. Dostęp do wielu spośród tych zasobów można uzyskać lokalnie, jeśli zostaną włączone personifikacje i jeśli spersonifikowane konto otrzyma uprawnienia dostępu do zasobu. Jednak personifikacje często nie działają przy próbie uzyskania dostępu do zasobów zdalnych, chyba że aplikacja używa mechanizmu uwierzytelniania, który można delegować, takiego jak Kerberos lub Uwierzytelnianie podstawowe. W celu uzyskania dostępu do zasobów można także użyć usług COM+, co jest opisane sekcji Wykonywanie kodu ze stałą tożsamością .

Korzystanie z zasobów plików

Aby aplikacji działającej na koncie ASPNET umożliwić zapis do plików, można personifikować określonego użytkownika przy użyciu kodu przed zapisywaniem do plików lub udzielić kontu ASPNET uprawnienia Zapis. Można udzielać uprawnień do zapisu poszczególnych plików lub całych hierarchii katalogów.

Ważne Po udzieleniu kontu ASPNET uprawnień do zapisu pojedynczego pliku lub hierarchii katalogów wszystkie aplikacje ASP.NET sieci Web uruchomione przy użyciu tego konta ASPNET na serwerze mogą zapisywać do tego pliku lub hierarchii katalogów. Aby uzyskać więcej informacji dotyczących personifikowania określonego użytkownika przy użyciu kodu, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
306158 How to implement impersonation in an ASP.NET application
Aby zmienić Listę kontroli dostępu dla pliku, wykonaj następujące kroki:
  1. Otwórz Eksploratora Windows.
  2. Zaznacz plik lub folder, dla którego chcesz zmienić uprawnienia.
  3. W menu Plik kliknij polecenie Właściwości.
  4. Kliknij kartę Zabezpieczenia. Kliknięciami zaznacz pola wyboru odpowiadające uprawnieniom ACL.
Do zmiany listy ACL dla pliku można także użyć skryptu lub narzędzia wiersza polecenia Cacls.exe (dołączonego do systemu Windows).

Program ASP.NET 1.1 używa do magazynowania plików procesu folderu <nazwa_dysku>\Documents and Settings\<nazwa_komputera>\ASPNET (gdzie <nazwa_dysku> to dysk, na którym jest zainstalowany program ASP.NET, a <nazwa_komputera> to nazwa danego komputera).

Włączanie personifikacji

Personifikacja pozwala użytkownikowi na działanie w kontekście zabezpieczeń jednostki zgłaszającej żądanie, jako użytkownikowi uwierzytelnionemu lub anonimowemu. W programie ASP.NET personifikacja jest opcjonalna i domyślnie nie jest włączona. Aby włączyć personifikację na poziomie komputera lub aplikacji, należy dodać następującą dyrektywę konfiguracyjną w sekcji <system.web> pliku Machine.config lub Web.config:
 <identity impersonate="true"/> 				

Korzystanie z baz danych

Aplikacje używające uwierzytelniania SQL do łączenia się z bazą danych zazwyczaj nie odczuwają przełączenia na konto ASPNET. Podobnie jest w wypadku aplikacji używających uwierzytelniania zintegrowanego oraz personifikacji. Jeśli jednak aplikacja nie jest personifikowana i używa uwierzytelniania systemu Windows, należy przydzielić kontu ASPNET uprawnienie dostępu do bazy danych.

Nie można używać konta ASPNET przy próbie uwierzytelniania w programie Microsoft SQL Server za pomocą zintegrowanego uwierzytelniania systemu Windows przez nazwane potoki. Można jednak skutecznie używać konta ASPNET i zintegrowanego uwierzytelniania systemu Windows przez sterownik transportu Transmission Control Protocol (TCP).

Jeśli aplikacja musi korzystać z bazy danych programu Microsoft Access, to konto ASPNET musi być w stanie zapisywać do pliku bazy danych. Administratorzy muszą odpowiednio dostosować uprawnienia do pliku.

Korzystanie z dziennika zdarzeń

Aplikacje, które muszą zapisywać dziennik zdarzeń aplikacji, mogą to robić, gdy działają na koncie ASPNET. Jeśli aplikacja musi utworzyć nową kategorię dziennika zdarzeń, to musi utworzyć nowy klucz rejestru w gałęzi HKEY_LOCAL_MACHINE, czego konto ASPNET nie może zrobić.

Aby utworzyć kategorię w czasie wykonywania, należy włączyć personifikację, a następnie spersonifikować konto, które ma większe uprawnienia dostępu. Kategorię może też utworzyć administrator, wówczas aplikacja będzie mogła zapisywać do tej kategorii w trakcie działania.

Jeśli aplikacja musi utworzyć nowe kategorie dziennika zdarzeń, to należy utworzyć je w trakcie instalacji. Po utworzeniu kategorii konto ASPNET będzie mogło dokonywać zapisu w dzienniku zdarzeń aplikacji.

Używanie składnika System.DirectoryServices i usługi Active Directory

Jeśli aplikacja sieci Web musi mieć dostęp do usługi Active Directory, to aplikacja może użyć personifikacji w środowisku obsługującym delegowanie. W celu uzyskania dostępu do usługi Active Directory aplikacja może też podać jawne poświadczenia konstruktorowi DirectoryEntry w obszarze nazw System.DirectoryServices. Jeśli aplikacja używa jawnych poświadczeń, to powinna je odpowiednio przechowywać, korzystając z takich technik, jak ciągi konstrukcji COM+, lub używając interfejsów programowania aplikacji (API) ochrony danych systemu Windows.

Korzystanie z liczników wydajności

Konto ASPNET ma wystarczające uprawnienia do zapisywania (ale nie odczytywania) danych liczników wydajności. Jeśli aplikacja musi odczytywać dane licznika wydajności lub tworzyć kategorie licznika wydajności, to są niezbędne uprawnienia Administratora lub Użytkownika zaawansowanego.

Jeśli aplikacja musi tworzyć kategorie licznika wydajności, to należy je utworzyć w trakcie instalacji. Po utworzeniu kategorii konto ASPNET będzie mogło zapisywać liczniki.

W trakcie korzystania z konta ASPNET można nadal używać narzędzia Monitor wydajności (Perfmon.exe) do monitorowania liczników wydajności programu ASP.NET.

W systemie Windows 2000 wykonaj następujące kroki:
  1. Uruchom Edytor rejestru.
  2. Zlokalizuj następujący klucz rejestru:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_1.1.4322\Names
  3. Kliknij kartę Zabezpieczenia.
  4. Dodaj tożsamość procesu roboczego z następującymi uprawnieniami:
    • Badanie wartości
    • Ustawianie wartości
    • Tworzenie podklucza
    • Wyliczanie podkluczy
    • Powiadamianie Kontrola odczytu
W systemie Windows Server 2003 dodaj tożsamość do grupy IIS_WPG.

Uruchamianie pozaprocesowych serwerów COM

Aplikacje, które muszą uruchamiać pozaprocesowe serwery COM w czasie działania na koncie ASPNET, mogą przydzielić kontu uprawnienia do uruchamiania za pomocą narzędzia Dcomcnfg.exe.

Zagadnienia związane z debugowaniem

Domyślnie nie można wkraczać do wywołań usług XML sieci Web z aplikacji klienckiej. Aby wkraczać do usług XML sieci Web, należy dodać konto ASPNET do grupy Debugger Users na komputerze, na którym działa usługa XML sieci Web.

Wykonywanie kodu ze stałą tożsamością

W usługach COM+ można wykonywać kod ze stałą tożsamością. Można użyć klasy ServicedComponent obszaru nazw System.EnterpriseServices, aby napisać zarządzany kod składników korzystających z usług COM+. Uprzywilejowaną funkcjonalność można opakować w klasie pochodzącej od klasy ServicedComponent, a następnie można wykonać tę klasę jako aplikację serwerową COM+ o skonfigurowanej tożsamości.

Kompilowanie plików z kodem źródłowym na udziałach UNC

W programie ASP.NET można używać kilku metod tworzenia plików aplikacji:
  • Można użyć języka HTML (Hypertext Markup Language) w pliku .aspx, a następnie zapisać kod strony we wstępnie skompilowanym zestawie w katalogu Bin. To jest model programu Microsoft Visual Studio .NET.
  • Można spakować wszystkie kody i zawartości HTML w jednym pliku źródłowym kompilowanym na żądanie.
  • Można umieścić prezentację HTML w pliku ASP.NET, a następnie dynamicznie kompilować dowolny kod skojarzony z tym plikiem, używając atrybutu src w dyrektywie <%@ Assembly %>.
Uwaga Jeśli zawartość aplikacji znajduje się w udziale sieciowym, to kompilator zostanie uruchomiony na koncie ASPNET i nie będzie miał poświadczeń sieciowych, aby uzyskać dostęp do pliku. Jeśli są używane udziały sieciowe, to nie można użyć atrybutu src, aby wskazać plik. Trzeba użyć jednej z pozostałych metod.

Korzystanie z programu ASP.NET na podstawowym lub zapasowym kontrolerze domeny


W przypadku korzystania z programu ASP.NET 1.1 na kontrolerze domeny aplikacje sieci Web programu ASP.NET będą domyślnie uruchamiane w kontekście zabezpieczeń konta IWAM_<nazwa_komputera> (gdzie <nazwa_komputera> to nazwa danego komputera).

Aby uzyskać dodatkowe informacje, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
315158 FIX: Program ASP.NET nie działa z domyślnym kontem ASPNET na kontrolerze domeny
Powrót do początku

Odczytywanie metabazy usług IIS

Konto ASPNET nie może odczytywać metabazy Internetowych usług informacyjnych firmy Microsoft (IIS). Jeśli aplikacja musi uzyskiwać dostęp do ustawień metabazy, to można bezpiecznie przydzielić uprawnienia do odczytu węzłów metabazy, korzystając z narzędzia Metaacl.exe.

Jeśli aplikacja musi korzystać z plików .disco, które bazują na możliwości odczytu metabazy usług IIS w celu zapewnienia usług wykrywania, należy przydzielić kontu ASPNET uprawnienia odczytu.

Korzystanie ze składnika System.Management i WMI

Instrumentacja zarządzania Windows to zaawansowana funkcja administracyjna, której można używać do zarządzania komputerami z systemem Windows i monitorowania ich. Jeśli jednak program ASP.NET działa na koncie ASPNET, to konto ma jedynie te same domyślne uprawnienia dostępu co Wszyscy. Uprawnienia te obejmują odczyt danych WMI, zapisywanie danych dostawców oraz wykonywanie metod dostawców na komputerze lokalnym. Więcej informacji na temat mechanizmów zabezpieczeń WMI można znaleźć w dokumentacji WMI Platform SDK w sieci MSDN.

Uwaga W systemie Windows 2000 bez dodatku Service Pack 3 (SP3) lub nowszego albo w systemie Windows XP bez dodatku Service Pack 1 (SP1) lub nowszego aplikacje sieci Web programu ASP.NET działające na koncie ASPNET mogą nie funkcjonować i może się pojawić komunikat o błędzie „Odmowa dostępu (0x80041003)”. Może się tak zdarzyć, ponieważ konto nie ma wystarczających uprawnień, aby uzyskać dostęp do niektórych obszarów nazw WMI. Aby rozwiązać ten problem, należy zainstalować dodatek Windows XP SP1 lub nowszy albo dodatek Windows 2000 SP3 lub nowszy. Aby obejść ten problem, wykonaj następujące kroki:
  1. Otwórz przystawkę zarządzania komputerem Microsoft Management Console (MMC).
  2. Rozwiń pozycję Aplikacje i usługi, a następnie zaznacz pozycję Sterowanie usługą WMI.
  3. Kliknij prawym przyciskiem myszy pozycję Sterowanie usługą WMI, a następnie kliknij polecenie Właściwości.
  4. W oknie dialogowym Właściwości: Sterowanie usługą WMI kliknij kartę Zabezpieczenia.
  5. Rozwiń pozycję Root, zaznacz pozycję CIMV2, a następnie kliknij przycisk Zabezpieczenia.
  6. W oknie dialogowym Zabezpieczenia kliknij przycisk Zaawansowane.
  7. W oknie dialogowym Ustawienia kontroli dostępu kliknij przycisk Dodaj. Zaznacz pozycję localMachineName\ASPNET, a następnie kliknij przycisk OK.
  8. W oknie dialogowym Wpis uprawnienia upewnij się, że pole Zastosuj dla zawiera wartość Ten obszar nazw i podobszary nazw.
  9. Upewnij się, że pola wyboru Zezwalaj 'Włącz konto' oraz Zezwalaj 'Włączanie zdalne' są zaznaczone.
  10. Klikaj przycisk OK w każdym oknie dialogowym, aż wrócisz do okna dialogowego Właściwości: Sterowanie usługą WMI.
  11. Powtórz kroki od 5 do 10 dla każdego obszaru nazw, do którego aplikacja będzie uzyskiwać dostęp.
  12. Uruchom ponownie usługi IIS. Aby to zrobić, uruchom polecenie IISRESET .
Domyślnie program ASP.NET generuje kryptograficznie silne hasła do konta ASPNET. Dlatego to obejście jest bezpieczne, pod warunkiem że hasło do konta ASPNET nie jest udostępniane między komputerami i że nie jest mu nadana jakaś wartość inna niż domyślna.

Interakcja z pulpitem

Gdy usługi IIS są skonfigurowane w sposób umożliwiający interakcję z pulpitem, konto ASPNET nie ma odpowiednich uprawnień, aby uzyskiwać dostęp do pulpitu, ze względu na listy DACL (Discretionary Access Control Lists) domyślnej stacji okna i pulpitu. Administratorzy mogą zmienić te listy DACL lub można uruchomić proces na koncie mającym uprawnienia dostępu do tych obiektów.

Usuwanie programu ASP.NET

Gdy jest usuwany program ASP.NET, konto ASPNET jest wyłączane i pozostaje w systemie. Można usunąć konto ASPNET, jeśli nie planuje się ponownej instalacji programu ASP.NET.

Jeśli program ASP.NET zostanie ponownie zainstalowany po usunięciu konta ASPNET, to zostanie utworzone nowe konto ASPNET z nowym identyfikatorem zabezpieczeń (SID). W efekcie wszystkie listy ACL, które odnosiły się do poprzedniego konta ASPNET, nie będą miały zastosowania do nowego konta ASPNET.

Materiały referencyjne

Więcej informacji na temat domyślnych list ACL w systemie Windows 2000 znajduje się w następującym oficjalnym dokumencie firmy Microsoft:
http://www.microsoft.com/windows2000/docs/SecDefs.doc
Aby uzyskać dodatkowe informacje, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
329290 Jak używać narzędzia programu ASP.NET do szyfrowania poświadczeń i ciągów połączenia dotyczących stanu sesji
315158 FIX: Program ASP.NET nie działa z domyślnym kontem ASPNET na kontrolerze domeny

Właściwości

Numer ID artykułu: 317012 - Ostatnia weryfikacja: 9 listopada 2005 - Weryfikacja: 12.3
Informacje zawarte w tym artykule dotyczą:
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Słowa kluczowe: 
kbconfig kbhttpruntime kbinfo kbsecurity KB317012

Przekaż opinię

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com