Zintegrowane uwierzytelnianie systemu Windows nie działa na komputerze podłączonym do sieci AD



Tło:

  • Serwer sieciowy stosu LAMP
  • Serwer sieciowy ma tunel VPN do sieci AD w centrali
  • Wiele sieci AD na całym świecie z tunelami VPN i zaufanymi sieciami HQ
  • Uwierzytelnianie Kerberos jest skonfigurowane na serwerze WWW i działa we wszystkich sieciach korzystających z plików kluczy.
  • Jestem administratorem sieci Web, ale nie mam dostępu do żadnej konfiguracji sieci AD.

Mamy problem z jedną siecią AD, która pojawia się tylko w IE lub Chrome, gdzie komputer używany do uzyskiwania dostępu do naszego serwera internetowego jest powiązany z daną AD. Token nie został przekazany i w dziennikach serwera nie ma wpisów zgodnych z tokenem. Jeśli korzystamy z Firefoksa i włączamy opcje network.negotiate-auth, użytkownik może zalogować się bez problemu, jednak podczas korzystania z IE dostaje komunikat o błędzie autoryzacji. Witryna znajduje się w strefie intranetu, a IWA jest walidowana (jest to kontrolowane przez GPO)
Jeśli użytkownicy spróbują uzyskać dostęp do witryny za pomocą przeglądarki IE lub Chrome spoza AD, otrzymają oczekiwany monit o uwierzytelnienie logowania, a następnie token zostanie wysłany poprawnie.
Rozmawiałem z administratorami sieci i są prawie pewni, że AD nie potrzebuje żadnej specjalnej konfiguracji, aby uruchomić uwierzytelnianie Kerberos, ale nie mogę dowiedzieć się, dlaczego uwierzytelnianie działa w pozostałych sześciu sieciach AD i nie działa w tym 1, chyba że jest przed samą konfiguracją AD.
Czy coś mi brakuje? Jak możesz wytłumaczyć odmowę negocjacji tokena?
[Uwaga - nie jest to pilne, a ponieważ wychodzę z biura, w poniedziałek odpowiem na wszelkie pytania o szczegóły]
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Problem polegał na tym, że token był wysyłany i podjęto próbę automatycznej negocjacji w sieci AD, ale zawsze kończyło się to niepowodzeniem z powodu szyfrowania używanego podczas tworzenia keytab.
Pierwotnie używaliśmy

-crypto DES-CBC-CRC

ale gdy tylko przeszliśmy na używanie

-crypto RC4-HMAC-NT

problem zniknął.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Nie jestem ekspertem w tej dziedzinie, ale wydaje mi się, że jeśli tokeny negocjacji nie są wymieniane, problem może polegać na tym, że aplikacja nie ma zarejestrowanej nazwy SPN z nazwą użytkownika powiązaną z tablicą kluczy.
Jeśli tak, poniższe polecenie, uruchom na serwerze AD, może to naprawić:
setspn –a HTTP/(yourhostname) (keytabusername)
na przykład setspn -a http/intranetappsrv.mycompany.com jbossaccount

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się