Iată configurația modulului Apache HTTP Kerberos în /etc/apache2/sites-available/my.server.tld.conf:
#...
<Locație />
Nume de autentificare „Autentificare SSO”
AuthType Kerberos
KrbAuthRealms MY.DOMAIN.TLD
KrbServiceName HTTP/[email protected]
Krb5Keytab /etc/apache2/kerb5.my.server.tld.ktab
KrbMethodNegotiate Activat
KrbMethodK5Passwd Activat
Necesită utilizator valid
</Locație>
#...
Și configurația Kerberos în /etc/krb5.conf:
[libdefaults]
default_realm = MY.DOMAIN.TLD
#...
[tărâmuri]
MY.DOMAIN.TLD = {
kdc = my.ad.server.1.tld
kdc = my.ad.server.2.tld
admin_server = my.ad.server.1.tld
}
#...
[domeniu_domeniu]
friendly.domain.tld = MY.DOMAIN.TLD
.friendly.domain.tld = DOMENIU.MEU.TLD
#...
Serverul web Apache HTTP este instalat pe un Debian GNU/Linux 10.
Fișierul keytab a fost generat pe serverul meu.ad.1.tld, care este un server Windows, cu ktpass comanda.
Cu această configurație, totul funcționează bine atât pe Edge, cât și pe Firefox pe mașinile Windows din TLD.MEU.DOMENUL domeniu.
Problema mea vine de la clienți care folosesc Microsoft Edge (cel nou cu motor Chromium) sau Google Chrome pe mașini Windows din afara domeniului.
La prima conexiune la serverul meu.tld, browserul primește WWW-Authenticate: negociați și WWW-Authenticate: domeniul de bază="SSO Authentication" antete.
Cu Microsoft Edge și spre deosebire de Firefox, dialogul de autentificare care apare cu WWW-Authenticate: negociați nu este cel din browser, ci un dialog de autentificare Windows și nu funcționează, orice am tastă.
După o primă încercare de conectare nereușită, browser-ul emite o a doua solicitare, iar de această dată el primește doar fișierul WWW-Authenticate: domeniul de bază="SSO Authentication" antet. Apare dialogul de autentificare a browserului și funcționează. Navigare suplimentară în interior serverul meu.tld va genera apoi o mulțime de dialog de autentificare Windows în fundal.De exemplu, dacă există o imagine pe o pagină, aceasta va afișa un dialog de autentificare pentru aceasta.
Am observat că dacă mașina Windows este conectată în rețeaua internă a TLD.MEU.DOMENUL și specificăm în mod explicit domeniul în dialogul de autentificare Windows, funcționează bine și (adică utilizatorul [email protected] ca nume de utilizator).
Cu toate cele de mai sus în minte, acum mă întreb...
- Este de fapt posibil să funcționeze cu dialogul Autentificare Windows integrată pe mașinile Windows?
- Există o modalitate de a „forța” domeniul să fie utilizat pentru autentificare, de a anula necesitatea de a-l specifica în mod explicit, cum ar fi
utilizatorul [email protected] pentru mașinile din afara TLD.MEU.DOMENUL domeniu?
Am încercat deja să adaug default_domain = my.domain.tld în interiorul configurației domeniului Kerberos sau pentru a obține un Kerberos TGT cu kinit pe serverul Debian GNU/Linux 10 fără succes.
Citirea jurnalelor Apache HTTP cu LogLevel trace8 cu fiecare situație, se pare că atâta timp cât apare un dialog de autentificare Windows, este returnat un token NTLM, ceea ce îl face să nu funcționeze corect.
Când funcționează
Oriunde cu Firefox
SAU
Cu un computer în interiorul domeniului, rețea internă (Edge sau Chrome)
SAU
Cu un computer în afara domeniului, rețea externă și utilizare [email protected] (Edge sau Chrome):
mod_authz_core.c(820): AH01626: rezultatul autorizației de Require valid-user : denied (niciun utilizator autentificat încă)
mod_authz_core.c(820): AH01626: rezultatul autorizării <RequireAny>: refuzat (niciun utilizator autentificat încă)
src/mod_auth_kerb.c(1963): kerb_authenticate_user introdus cu user (NULL) și auth_type Kerberos
src/mod_auth_kerb.c(1296): Obținerea creditelor pentru HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verificarea datelor client folosind KRB5 GSS-API
src/mod_auth_kerb.c(1735): clientul nu ne-a delegat acreditările lor
src/mod_auth_kerb.c(1754): tokenul GSS-API cu lungimea de 180 de octeți va fi trimis înapoi
mod_authz_core.c(820): AH01626: rezultatul autorizației de Require valid-user: granted
mod_authz_core.c(820): AH01626: rezultatul autorizării <RequireAny>: acordat
Când nu funcționează
Cu un computer în afara domeniului, a rețelei externe (Edge sau Chrome):
mod_authz_core.c(820): AH01626: rezultatul autorizației de Require valid-user : denied (niciun utilizator autentificat încă)
mod_authz_core.c(820): AH01626: rezultatul autorizării <RequireAny>: refuzat (niciun utilizator autentificat încă)
src/mod_auth_kerb.c(1963): kerb_authenticate_user introdus cu user (NULL) și auth_type Kerberos
src/mod_auth_kerb.c(1296): Obținerea creditelor pentru HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verificarea datelor client folosind KRB5 GSS-API
src/mod_auth_kerb.c(1735): clientul nu ne-a delegat acreditările lor
src/mod_auth_kerb.c(1763): Atenție: jetonul primit pare să fie NTLM, care nu este acceptat de modulul Kerberos. Verificați configurația dvs. IE.
src/mod_auth_kerb.c(1156): GSS-API major_status:00010000, minor_status:00000000
gss_accept_sec_context() a eșuat: a fost solicitat un mecanism neacceptat (, eroare necunoscută)
Partea enervantă a tuturor acestor lucruri este că funcționează perfect pe Firefox, dar nu și în browsere cu un motor Chromium recent. Este pentru că se întoarce la o autentificare NTLM în loc de una de bază?
