|Zintegrowane uwierzytelnianie przez serwer proxy: konta usług i podszywanie się
|Zbadaj kontekst zabezpieczeń stojący za zintegrowanym uwierzytelnianiem przez serwer proxy, gdy ta sama aplikacja działa interaktywnie, ale zawodzi jako usługa sieciowa lub proces zaplanowany.
„Użyj moich poświadczeń Windows” wymaga podmiotu. W programie biurkowym może to być osoba, która go uruchamia. W usłudze może to być konto usługi. W aplikacji sieciowej udane zalogowanie odwiedzającego nie zastępuje automatycznie kontekstu zabezpieczeń żądania wychodzącego.
To wyjaśnia, dlaczego przeglądarka i kod po stronie serwera na tej samej maszynie mogą otrzymywać różne wyniki od serwera proxy z uwierzytelnianiem zintegrowanym. Być może przedstawiają różne tożsamości.
Nazwij tożsamości, zanim zmienisz kod
- Osoba zalogowana w przeglądarce biurkowej.
- Konto hostujące proces aplikacji.
- Każda podszyta tożsamość aktywna dla operacji wychodzącej.
- Konto, które serwer proxy faktycznie zaakceptował lub odrzucił.
Na ścieżkach uwierzytelniania zintegrowanego obsługiwanych przez .NET DefaultCredentials dotyczy bieżącego kontekstu zabezpieczeń. Nie jest globalnym aliasem dla każdego, kto otworzył stronę na innej maszynie.
Jeśli produkt celowo działa jako użytkownik, podszywanie się i wszelkie wymagania dotyczące delegowania sieciowego wymagają własnego obsługiwanego projektu. Włączenie ogólnego przełącznika używania poświadczeń domyślnych nie ustanawia tego projektu. Odwrotnie, zadanie w tle przeznaczone do działania jako tożsamość usługi nie powinno zależeć od tego, że ktoś najpierw otworzy przeglądarkę.
Porównaj uruchomienie interaktywne i wdrożone po usunięciu wpisów tajnych: kontekst konta, punkt końcowy serwera proxy, ogłoszoną metodę i odrzuconą tożsamość. Unikaj kopiowania hasła biurkowego do aplikacji tylko dlatego, że dzięki temu jedno jednorazowe żądanie się powiodło. Skonfiguruj konto, którego aplikacja powinna używać, a następnie utrzymuj tę własność widoczną w zapisie wdrożenia.