Perché una richiesta proxy chiede la password mentre Kerberos funziona per le altre
Trovate la regola di criterio che assegna a una richiesta un realm di autenticazione proxy inatteso, anche quando altre richieste usano Kerberos con successo.
Diverse richieste usano Kerberos con successo attraverso il proxy aziendale. Una richiesta genera una richiesta di password. Prima di sostituire un keytab, verificate quale criterio di autenticazione ha selezionato quella specifica richiesta.
Un gateway può scegliere un realm e gli schemi supportati tramite criteri. Due transazioni che raggiungono lo stesso proxy dallo stesso browser non devono necessariamente ricevere gli stessi requisiti di autenticazione.
Considerate questa traccia ipotetica:
| Transazione | Prima regola corrispondente | Autenticazione disponibile |
|---|---|---|
| Documento principale | Regola di navigazione gestita | Negotiate |
| Script da un altro host | Eccezione di destinazione precedente | Basic o NTLM |
Il primo scambio riuscito dimostra che un percorso selezionato funziona. Non dimostra che la seconda transazione abbia raggiunto quel percorso. Una credenziale può essere valida mentre la regola che sceglie il suo meccanismo di autenticazione è sbagliata.
Esaminate la regola selezionata e il suo ordine
Correlate la destinazione e l'ora della richiesta contestata con la traccia dei criteri del gateway. Identificate il realm, le scelte di schema e la modalità di autenticazione prodotte dalla prima regola applicabile. Confrontate quei valori con una richiesta riuscita dello stesso client.
Un criterio basato su un'identità associata a un IP può comportarsi diversamente da uno che richiede l'autenticazione sulla connessione. Non presumete che l'assenza di un nuovo handshake significhi che sia stato scelto lo stesso realm.
Se la risorsa è finita in un'eccezione indesiderata, correggete quella regola o la sua portata ed esaminate la traccia risultante. Ampliare i metodi di autenticazione consentiti ovunque può nascondere la discrepanza, ma cambia il comportamento di accesso per traffico non correlato.
Se viene scelto il realm previsto e lo scambio atteso fallisce, passate alle prove sull'account e su Kerberos. È allora che il ticket, il nome del servizio o la diagnostica del backend diventano rilevanti.