Do czego służą konta IUSR i IWAM w IIS?


23

Szukam dobrego wyjaśnienia kont IUSR i IWAM używanych przez IIS, aby pomóc mi lepiej skonfigurować nasze środowisko hostingowe:

  • Dlaczego oni tam są?
  • Jaka jest różnica między nimi?
  • Czy nazwy oznaczają coś znaczącego?
  • Czy są jakieś zmiany najlepszych praktyk, które powinienem wprowadzić?
  • Usługi IIS dają mi również opcje uruchamiania pul aplikacji jako usługi sieciowej, usługi lokalnej lub systemu lokalnego. Czy powinienem?
  • Mój serwer internetowy jest częścią domeny, jak to się zmienia?

Wydaje się, że tworzenie własnych wersji tych kont jest powszechne podczas wdrażania wielu witryn na serwerze, co rodzi dodatkowe pytania:

  • Kiedy mogę utworzyć własne konto IUSR i IWAM?
  • Jak mam utworzyć te dodatkowe konta, aby miały odpowiednie uprawnienia?

Używam zarówno IIS 6, jak i IIS 7 z większością domyślnych konfiguracji.

Odpowiedzi:


33

IUSR i IWAM pochodzą z bardzo wczesnych dni IIS, kiedy był instalowany osobno (nie jako komponent systemu operacyjnego). Domyślnie, jeśli witryna internetowa pozwala na anonimowe uwierzytelnianie, konto IUSR jest używane w odniesieniu do uprawnień w systemie operacyjnym. Można to zmienić od domyślnego. Istnieją pewne zalecenia bezpieczeństwa dotyczące przynajmniej zmiany nazwy konta, więc nie jest to „znane” konto, podobnie jak zalecenie zmiany nazwy konta administratora na serwerze. Możesz dowiedzieć się więcej o IUSR i uwierzytelnianiu w MSDN .

IWAM został zaprojektowany dla wszystkich aplikacji poza procesem i jest używany tylko w IIS 6.0, gdy jesteś w trybie izolacji IIS 5.0. Zwykle widziałeś to z obiektami COM / DCOM.

W odniesieniu do tożsamości puli aplikacji domyślnie działa jako usługa sieciowa. Nie należy uruchamiać systemu lokalnego, ponieważ to konto ma uprawnienia większe niż uprawnienia administratora. To zasadniczo pozostawia cię do usługi sieciowej, usługi lokalnej lub konta lokalnego / domeny innego niż te dwa.

To, co robić, zależy. Jedną z zalet pozostawienia go jako usługi sieciowej jest to, że jest to konto z ograniczonymi uprawnieniami na serwerze. Jednak gdy uzyskuje dostęp do zasobów w sieci, pojawia się jako Domena \ nazwa_komputera $, co oznacza, że ​​możesz przypisać uprawnienia, które zezwalają kontu usługi sieciowej na dostęp do zasobów, takich jak SQL Server działający w innym polu. Ponadto, ponieważ pojawia się jako konto komputera, jeśli włączysz uwierzytelnianie Kerberos, nazwa SPN będzie już dostępna, jeśli uzyskujesz dostęp do strony internetowej przy użyciu nazwy serwera.

Przypadek, w którym należy rozważyć zmianę puli aplikacji na określone konto domeny Windows, jeśli chcesz, aby określone konto uzyskiwało dostęp do zasobów sieciowych, takich jak konto usługi uzyskujące dostęp do programu SQL Server dla aplikacji internetowej. Istnieją inne opcje w ASP.NET, aby to zrobić bez zmiany tożsamości puli aplikacji, więc nie jest to już absolutnie konieczne. Innym powodem, dla którego warto rozważyć użycie konta użytkownika domeny, jest uwierzytelnianie Kerberos i posiadanie wielu serwerów WWW obsługujących aplikację internetową. Dobrym przykładem jest, jeśli masz dwa lub więcej serwerów WWW obsługujących SQL Server Reporting Services. Interfejs będzie prawdopodobnie prowadził do ogólnego adresu URL, takiego jak reports.mydomain.com lub report.mydomain.com. W takim przypadku SPN można zastosować tylko do jednego konta w AD. Jeśli masz pule aplikacji uruchomione w ramach Usługi sieciowej na każdym serwerze, to nie będzie działać, ponieważ kiedy opuszczają serwery, pojawiają się one jako Domena \ NazwaKomputera $, co oznacza, że ​​masz tyle kont, ile serwerów obsługujących app. Rozwiązaniem jest utworzenie konta domeny, ustawienie tożsamości puli aplikacji na wszystkich serwerach na to samo konto użytkownika domeny i utworzenie jednej nazwy SPN, umożliwiając w ten sposób uwierzytelnianie Kerberos. W przypadku aplikacji takiej jak SSRS, w której możesz chcieć przekazać poświadczenia użytkownika do serwera bazy danych zaplecza, uwierzytelnienie Kerberos jest koniecznością, ponieważ wtedy będziesz musiał skonfigurować delegację Kerberos. d masz tyle kont, ile serwerów obsługujących aplikację. Rozwiązaniem jest utworzenie konta domeny, ustawienie tożsamości puli aplikacji na wszystkich serwerach na to samo konto użytkownika domeny i utworzenie jednej nazwy SPN, umożliwiając w ten sposób uwierzytelnianie Kerberos. W przypadku aplikacji takiej jak SSRS, w której możesz chcieć przekazać poświadczenia użytkownika do serwera bazy danych zaplecza, uwierzytelnienie Kerberos jest koniecznością, ponieważ wtedy będziesz musiał skonfigurować delegację Kerberos. d masz tyle kont, ile serwerów obsługujących aplikację. Rozwiązaniem jest utworzenie konta domeny, ustawienie tożsamości puli aplikacji na wszystkich serwerach na to samo konto użytkownika domeny i utworzenie jednej nazwy SPN, umożliwiając w ten sposób uwierzytelnianie Kerberos. W przypadku aplikacji takiej jak SSRS, w której możesz chcieć przekazać poświadczenia użytkownika do serwera bazy danych zaplecza, uwierzytelnienie Kerberos jest koniecznością, ponieważ wtedy będziesz musiał skonfigurować delegację Kerberos.

Wiem, że to dużo do zrobienia, ale krótka odpowiedź brzmi, z wyjątkiem systemu lokalnego, to zależy.


Warto zauważyć, że zalecenia dotyczące zmiany nazwy tych kont nie pochodzą od firmy Microsoft. Konta systemowe mają statyczne i dobrze udokumentowane identyfikatory SID i można je łatwo zhakować niezależnie od wyświetlanej nazwy.
Thomas,

9

IUSR = użytkownik Internetu, tzn. Każdy anonimowy, nieuwierzytelniony użytkownik Twojej witryny (tzn. Prawie wszyscy)

IWAM = Internetowy menedżer aplikacji internetowych, tzn. Wszystkie aplikacje ASP i .NET będą działać na tym koncie

Zasadniczo IUSR i IWAM powinny mieć TYLKO dostęp do dokładnie tego, czego potrzebują. Nigdy nie powinny mieć dostępu do niczego innego, na wypadek gdyby te konta zostały naruszone, nie mogą uzyskać dostępu do niczego krytycznego.

To wszystko, na co mogę pomóc z twojej listy pytań, inni z większym doświadczeniem w administrowaniu IIS mogą ci pomóc!


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.