Risolvere gli errori Kerberos in Internet Explorer
Questo articolo consente di isolare e correggere le cause di vari errori quando si accede ai siti Web configurati per l'uso dell'autenticazione Kerberos in Internet Explorer. Il numero di potenziali problemi è quasi pari al numero di strumenti disponibili per risolverli.
Sintomo comune quando Kerberos ha esito negativo
Si tenta di accedere a un sito Web in cui Windows Integrated Authenticated è stato configurato e si prevede di usare il protocollo di autenticazione Kerberos. In questo caso, il browser richiede immediatamente le credenziali, come indicato di seguito:
Anche se si immettono un nome utente e una password validi, viene richiesto di nuovo (totale di tre richieste). Viene quindi visualizzata una schermata che indica che non è consentito accedere alla risorsa desiderata. Nella schermata viene visualizzato un codice di stato HTTP 401 simile all'errore seguente:
Non autorizzato
Errore HTTP 401. La risorsa richiesta richiede l'autenticazione utente.
Nel server Microsoft Internet Information Services (IIS), i log del sito Web contengono richieste che terminano con un codice di stato 401.2, ad esempio il log seguente:
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8
In alternativa, nella schermata viene visualizzato un codice di stato 401.1, ad esempio il log seguente:
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18
Determinare se viene usato Kerberos
Quando si risolve l'errore di autenticazione Kerberos, è consigliabile semplificare al minimo la configurazione. Ovvero, un client, un server e un sito IIS in esecuzione sulla porta predefinita. Inoltre, è possibile seguire alcuni passaggi di base per la risoluzione dei problemi. Ad esempio, usare una pagina di test per verificare il metodo di autenticazione usato. Se si usa ASP.NET, è possibile creare questa pagina di test di autenticazione ASP.NET.
Se si usa ASP classico, è possibile usare la pagina di Testkerb.asp seguente:
<%
authType=UCase(Request.ServerVariables("AUTH_TYPE"))
authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
response.write " Authentication Method : " & authType & "<BR>"
LenAuthHeader = len(authHeader)
response.write " Protocol : "
if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write "NTLM"
%>
È anche possibile usare gli strumenti seguenti per determinare se viene usato Kerberos:
- Fiddler
- HttpWatch
- Network Monitor
- Gli strumenti di sviluppo nel browser
Per altre informazioni su come generare tali tracce, vedere Traccia sul lato client.
Quando si usa Kerberos, la richiesta inviata dal client è di grandi dimensioni (più di 2.000 byte), perché l'intestazione HTTP_AUTHORIZATION include il ticket Kerberos. La richiesta seguente riguarda una pagina che usa l'autenticazione di Windows basata su Kerberos per autenticare gli utenti in ingresso. La dimensione della richiesta GET è superiore a 4.000 byte.
Se viene usato l'handshake NTLM, la richiesta sarà molto più piccola. L'acquisizione sul lato client seguente mostra una richiesta di autenticazione NTLM. La richiesta GET è molto più piccola (meno di 1.400 byte).
Dopo aver stabilito che l'autenticazione Kerberos ha esito negativo, controllare ognuno degli elementi seguenti nell'ordine specificato.
Elementi da controllare se l'autenticazione Kerberos non riesce
Le sezioni seguenti descrivono gli elementi che è possibile usare per verificare se l'autenticazione Kerberos ha esito negativo.
Il client e il server si trovano nello stesso dominio
L'uso di Kerberos richiede un dominio, perché un ticket Kerberos viene recapitato dal controller di dominio . Sono anche possibili scenari avanzati in cui:
- Il client e il server non sono nello stesso dominio, ma in due domini della stessa foresta.
- Il client e il server si trovano in due foreste diverse.
Questi scenari possibili sono illustrati nella sezione Perché la delega Kerberos non riesce tra le due foreste, sebbene sia stata usata per funzionare in questo articolo.
IIS configurato per l'uso dell'autenticazione integrata
L'autenticazione integrata è abilitata in Internet Explorer
L'URL usato viene risolto in un'area di sicurezza per cui è possibile inviare le credenziali
Eseguire sempre questo controllo per i siti seguenti:
- Siti corrispondenti all'area Intranet locale del browser.
- Siti nell'area Siti attendibili.
È possibile controllare quale zona il browser decide di includere il sito. A tale scopo, aprire il menu File di Internet Explorer e quindi selezionare Proprietà. Nella finestra Proprietà verrà visualizzata la zona in cui il browser ha deciso di includere il sito a cui si sta accedendo.
È possibile controllare se la zona in cui è incluso il sito consente l'accesso automatico. A tale scopo, aprire il menu Opzioni Internet di Internet Explorer e selezionare la scheda Sicurezza . Dopo aver selezionato la zona desiderata, selezionare il pulsante Livello personalizzato per visualizzare le impostazioni e assicurarsi che l'opzione Accesso automatico sia selezionata. Questa funzionalità è in genere attivata per impostazione predefinita per le aree Intranet e Siti attendibili.
Nota
Anche attraverso questa configurazione non è comune (perché richiede al client di avere accesso a un controller di dominio), Kerberos può essere usato per un URL nell'area Internet. In questo caso, a meno che non vengano modificate le impostazioni predefinite, il browser richiederà sempre all'utente le credenziali. La delega Kerberos non funzionerà nell'area Internet. Questo perché Internet Explorer consente la delega Kerberos solo per un URL nelle zone Intranet e Siti attendibili.
Server IIS configurato per l'invio dell'intestazione WWW-Authenticate: Negotiate
Se IIS non invia questa intestazione, usare la console di Gestione IIS per impostare l'intestazione Negotiate tramite la proprietà di configurazione NTAuthenticationProviders . Per altre informazioni, vedere Provider> di autenticazione di <Windows. È possibile accedere alla console tramite l'impostazione Provider dei dettagli dell'autenticazione di Windows in Gestione IIS.
Nota
Per impostazione predefinita, la proprietà NTAuthenticationProviders non è impostata. In questo modo IIS invia le intestazioni Negotiate e Windows NT LAN Manager (NTLM).
Il client e il server sono installati nello stesso computer
Per impostazione predefinita, Kerberos non è abilitato in questa configurazione. Per modificare questo comportamento, è necessario impostare la chiave del DisableLoopBackCheck Registro di sistema. Per altre informazioni, vedere KB 926642.
Il client può ottenere un ticket Kerberos
È possibile usare lo strumento Elenco Kerberos (KLIST) per verificare che il computer client possa ottenere un ticket Kerberos per un nome di entità servizio specificato. In questo esempio, il nome dell'entità servizio (SPN) è http/web-server.
Nota
KLIST è uno strumento nativo di Windows a partire da Windows Server 2008 per i sistemi operativi sul lato server e Windows 7 Service Pack 1 per i sistemi operativi sul lato client.
Quando la richiesta di ticket Kerberos ha esito negativo, l'autenticazione Kerberos non viene usata. Il fallback NTLM può verificarsi perché il nome SPN richiesto è sconosciuto al controller di dominio. Se il controller di dominio non è raggiungibile, non si verifica alcun fallback NTLM.
Per dichiarare un nome SPN, vedere l'articolo seguente:
Il server Web usa una porta diversa da quella predefinita (80)
Per impostazione predefinita, Internet Explorer non include le informazioni sul numero di porta nel nome SPN usato per richiedere un ticket Kerberos. Può essere un problema se si usa IIS per ospitare più siti in porte e identità diverse. In questa configurazione l'autenticazione Kerberos può funzionare solo per siti specifici, anche se tutti i nomi SPN sono stati dichiarati correttamente in Active Directory. Per risolvere questo problema, è necessario impostare il valore del FEATURE_INCLUDE_PORT_IN_SPN_KB908209 Registro di sistema. Per informazioni su come dichiarare la chiave, vedere la sezione Chiavi funzionalità di Internet Explorer . Questa impostazione impone a Internet Explorer di includere il numero di porta nel nome SPN usato per richiedere il ticket Kerberos.
Internet Explorer usa il nome SPN previsto
Se si accede a un sito Web usando un nome alias (CNAME), Internet Explorer usa innanzitutto la risoluzione DNS per risolvere il nome alias in un nome computer (ANAME). Il nome del computer viene quindi usato per compilare il nome SPN e richiedere un ticket Kerberos. Anche se l'URL immesso nella barra degli indirizzi di Internet Explorer è http://MYWEBSITE, Internet Explorer richiede un NOME SPN per HTTP/MYSERVER se MYWEBSITE è un alias (CNAME) di MYSERVER (ANAME). È possibile modificare questo comportamento usando la chiave del FEATURE_USE_CNAME_FOR_SPN_KB911149 Registro di sistema. Per informazioni su come dichiarare la chiave, vedere le chiavi delle funzionalità di Internet Explorer .
Una traccia di Monitoraggio di rete è un buon metodo per controllare il nome SPN associato al ticket Kerberos, come nell'esempio seguente:
- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
Command: GET
- URI: /whoami.aspx
Location: /whoami.aspx
ProtocolVersion: HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: en-US,en;q=0.5
UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate
Host: web-server
Connection: Keep-Alive
- Authorization: Negotiate
- Authorization: Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
WhiteSpace:
- NegotiateAuthorization:
Scheme: Negotiate
- GssAPI: 0x1
- InitialContextToken:
+ ApplicationHeader:
+ ThisMech: SpnegoToken (1.3.6.1.5.5.2)
- InnerContextToken: 0x1
- SpnegoToken: 0x1
+ ChoiceTag:
- NegTokenInit:
+ SequenceHeader:
+ Tag0:
+ MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
+ Tag2:
+ OctetStringHeader:
- MechToken: 0x1
- MsKerberosToken: 0x1
- KerberosInitToken:
+ ApplicationHeader:
+ ThisMech: KerberosToken (1.2.840.113554.1.2.2)
- InnerContextToken: 0x1
- KerberosToken: 0x1
TokId: Krb5ApReq (0x100)
- ApReq: KRB_AP_REQ (14)
+ ApplicationTag:
+ SequenceHeader:
+ Tag0:
+ PvNo: 5
+ Tag1:
+ MsgType: KRB_AP_REQ (14)
+ Tag2: 0x1
+ ApOptions:
+ Tag3:
- Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
+ ApplicationTag:
+ SequenceHeader:
+ Tag0:
+ TktVno: 5
+ Tag1:
+ Realm: ODESSY.LOCAL
+ Tag2: 0x1
+ Sname: HTTP/web-server.odessy.local
+ Tag3: 0x1
+ EncPart:
+ Tag4:
L'identità del pool di applicazioni corrisponde all'account associato a SPN
Quando un ticket Kerberos viene inviato da Internet Explorer a un server IIS, il ticket viene crittografato tramite una chiave privata. La chiave privata è un hash della password usata per l'account utente associato al nome SPN. Pertanto, solo un'applicazione in esecuzione con questo account può decodificare il ticket.
La procedura seguente è un riepilogo dell'algoritmo di autenticazione Kerberos:
Internet Explorer determina un nome SPN usando l'URL immesso nella barra degli indirizzi.
L'SPN viene passato tramite un'API SSPI (Security Support Provider Interface) (InitializeSecurityContext) al componente di sistema responsabile della sicurezza di Windows (il processo LSASS (Local Security Authority Subsystem Service). In questa fase è possibile notare che il codice di Internet Explorer non implementa codice per costruire il ticket Kerberos. Internet Explorer chiama solo LE API SSPI.
LSASS usa il nome SPN passato per richiedere un ticket Kerberos a un controller di dominio. Se il controller di dominio può gestire la richiesta (SPN noto), crea un ticket Kerberos. Crittografa quindi il ticket usando una chiave costruita dall'hash della password dell'account utente per l'account associato al nome SPN. LSASS invia quindi il ticket al client. Per quanto riguarda Internet Explorer, il ticket è un BLOB opaco.
Internet Explorer incapsula il ticket Kerberos fornito da LSASS nell'intestazione
Authorization: Negotiatee quindi invia il ticket al server IIS.IIS gestisce la richiesta e la indirizza al pool di applicazioni corretto usando l'intestazione host specificata.
Il pool di applicazioni tenta di decrittografare il ticket usando le API SSPI/LSASS e seguendo queste condizioni:
Se il ticket può essere decrittografato, l'autenticazione Kerberos ha esito positivo. Tutti i servizi associati al ticket (rappresentazione, delega se il ticket lo consente e così via) sono disponibili.
Se il ticket non può essere decrittografato, viene restituito un errore Kerberos (KRB_AP_ERR_MODIFIED). Questo errore è un errore generico che indica che il ticket è stato modificato in qualche modo durante il trasporto. Non è quindi possibile decrittografare il ticket. Questo errore viene registrato anche nei registri eventi di Windows.
Se non si dichiara in modo esplicito un nome SPN, l'autenticazione Kerberos funziona solo in una delle identità del pool di applicazioni seguenti:
- Servizio di rete
- ApplicationPoolIdentity
- Un altro account di sistema, ad esempio LOCALSYSTEM o LOCALSERVICE
Ma queste identità non sono consigliate, perché rappresentano un rischio per la sicurezza. In questo caso, il ticket Kerberos viene compilato usando un nome SPN predefinito creato in Active Directory quando un computer (in questo caso, il server in cui è in esecuzione IIS) viene aggiunto al dominio. Questo nome SPN predefinito è associato all'account computer. In IIS l'account computer esegue il mapping al servizio di rete o applicationpoolIdentity.
Se il pool di applicazioni deve usare un'identità diversa dalle identità elencate, dichiarare un nome SPN (tramite SETSPN). Associarlo quindi all'account usato per l'identità del pool di applicazioni. Un errore comune consiste nel creare nomi SPN simili con account diversi. Ad esempio:
- SETSPN http/mywebsite UserAppPool1
- SETSPN http/mywebsite UserAppPool2
Questa configurazione non funziona perché non esiste un modo deterministico per sapere se il ticket Kerberos per il nome SPN http/mywebsite verrà crittografato usando la password UserAppPool1 o UserAppPool2. Questa configurazione genera in genere errori di KRB_AP_ERR_MODIFIED. Per determinare se si è in questo scenario di nomi SPN duplicati non validi, usare gli strumenti documentati nell'articolo seguente:
Perché è ancora possibile avere nomi SPN duplicati in AD 2012 R2 e AD 2016
Da Windows Server 2008 in poi, è anche possibile usare una versione aggiornata di SETSPN per Windows che consente il rilevamento di nomi SPN duplicati usando il setspn –X comando quando si dichiara un nuovo NOME SPN per l'account di destinazione. Per altre informazioni, vedere Setspn.
È anche consigliabile esaminare gli articoli seguenti:
Problemi di autenticazione Kerberos - Problemi relativi al nome dell'entità servizio (SPN) - Parte 1
Problemi di autenticazione Kerberos - Problemi relativi al nome dell'entità servizio (SPN) - Parte 2
Problemi di autenticazione Kerberos - Problemi relativi al nome dell'entità servizio (SPN) - Parte 3
L'autenticazione Kerberos non riesce in IIS 7 e versioni successive anche se funziona in IIS 6
L'autenticazione in modalità kernel è una funzionalità introdotta in IIS 7. Offre i vantaggi seguenti:
- Le prestazioni sono aumentate, perché le transizioni da modalità kernel a utente non vengono più eseguite.
- La decodifica dei ticket Kerberos viene eseguita usando l'account computer e non l'identità del pool di applicazioni. Questa modifica consente di avere più pool di applicazioni in esecuzione con identità diverse senza dover dichiarare i nomi SPN.
Avviso
Se un nome SPN è stato dichiarato per un account utente specifico (usato anche come identità del pool di applicazioni), l'autenticazione in modalità kernel non può decrittografare il ticket Kerberos perché usa l'account computer. Questo problema è tipico negli scenari di web farm. Questo scenario dichiara in genere un nome SPN per il nome host bilanciamento carico di rete (virtuale). Per evitare questo problema, usare uno dei metodi seguenti:
- Disabilitare l'autenticazione in modalità kernel. Non è consigliabile dal punto di vista delle prestazioni.
- Impostare useAppPoolCredentialssu true. In questo modo viene mantenuto il vantaggio in fatto di prestazioni dell'autenticazione in modalità kernel, consentendo al tempo stesso la decodifica del ticket Kerberos nell'identità del pool di applicazioni. Per altre informazioni, vedere Autenticazione della <sicurezza.>
Perché la delega non riesce anche se l'autenticazione Kerberos funziona
In questo scenario controllare gli elementi seguenti:
Area internet explorer usata per l'URL. La delega Kerberos è consentita solo per le aree Intranet e Siti attendibili. In altre parole, Internet Explorer imposta il
ISC_REQ_DELEGATEflag quando chiama InitializeSecurityContext solo se la zona determinata è Intranet o Siti attendibili.L'account utente per il pool di applicazioni IIS che ospita il sito deve avere il flag Trusted for delegation impostato all'interno di Active Directory.
Se la delega continua a non riuscire, provare a usare l'Configuration Manager Kerberos per IIS. Questo strumento consente di diagnosticare e correggere le configurazioni IIS per l'autenticazione Kerberos e per i nomi SPN associati negli account di destinazione. Per altre informazioni, vedere il README.md. È possibile scaricare lo strumento da qui.
Perché si ottengono prestazioni negative quando si usa l'autenticazione Kerberos
Kerberos è un protocollo di autenticazione basato su richiesta nelle versioni precedenti di Windows Server, ad esempio Windows Server 2008 SP2 e Windows Server 2008 R2. Ciò significa che il client deve inviare il ticket Kerberos (che può essere un BLOB di grandi dimensioni) con ogni richiesta effettuata al server. È contrario ai metodi di autenticazione che si basano su NTLM. Per impostazione predefinita, NTLM è basato su sessione. Significa che il browser autentica solo una richiesta quando apre la connessione TCP al server. Ogni richiesta successiva sulla stessa connessione TCP non richiederà più l'autenticazione per l'accettazione della richiesta. Nelle versioni più recenti di IIS, a partire da Windows 2012 R2, Kerberos è anche basato su sessione. Solo la prima richiesta in una nuova connessione TCP deve essere autenticata dal server. Le richieste successive non devono includere un ticket Kerberos.
È possibile modificare questo comportamento usando la proprietà authPersistNonNTLM se si esegue IIS 7 e versioni successive. Se la proprietà è impostata su true, Kerberos diventerà basato su sessione. In caso contrario, sarà basato su richiesta. Le prestazioni saranno peggiori perché è necessario includere una quantità maggiore di dati da inviare al server ogni volta. Per altre informazioni, vedere Request based versus Session based Kerberos Authentication (o il parametro AuthPersistNonNTLM).
Nota
Potrebbe non essere consigliabile usare ciecamente l'autenticazione Kerberos su tutti gli oggetti. L'uso dell'autenticazione Kerberos per recuperare centinaia di immagini usando richieste GET condizionali che generano probabilmente risposte 304 non modificate è come tentare di eliminare un volo usando un martello. Tale metodo inoltre non fornirà ovvi vantaggi in termini di sicurezza.
Perché la delega Kerberos non riesce tra le due foreste anche se funzionava
Considerare lo scenario descritto di seguito:
- Gli utenti dell'applicazione si trovano in un dominio all'interno della foresta A.
- L'applicazione si trova in un dominio all'interno della foresta B.
- Si ha una relazione di trust tra le foreste.
In questo scenario, la delega Kerberos potrebbe smettere di funzionare, anche se funzionava in precedenza e non è stata apportata alcuna modifica alle foreste o ai domini. L'autenticazione Kerberos funziona ancora in questo scenario. Solo la delega ha esito negativo.
Questo problema potrebbe verificarsi a causa degli aggiornamenti della sicurezza a Windows Server rilasciati da Microsoft a marzo 2019 e luglio 2019. Questi aggiornamenti hanno disabilitato la delega Kerberos non vincolata (la possibilità di delegare un token Kerberos da un'applicazione a un servizio back-end) oltre i limiti della foresta per tutti i trust nuovi ed esistenti. Per altre informazioni, vedere Aggiornamenti alla delega TGT tra trust in ingresso in Windows Server.
Chiavi delle funzionalità di Internet Explorer
Queste chiavi sono chiavi del Registro di sistema che attivano o disattivano alcune funzionalità del browser. Le chiavi si trovano nei percorsi del Registro di sistema seguenti:
HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl: se definito a livello di utenteHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\- se definito a livello di computer
Le chiavi di funzionalità devono essere create in una di queste posizioni, a seconda che si voglia attivare o disattivare la funzionalità:
- per tutti gli utenti nel computer
- solo per un account specifico
Queste chiavi devono essere create nel rispettivo percorso. All'interno della chiave, deve essere dichiarato un valore DWORD denominato iexplorer.exe . Il valore predefinito di ogni chiave deve essere true o false, a seconda dell'impostazione desiderata della funzionalità. Per impostazione predefinita, il valore di entrambe le chiavi di funzionalità, FEATURE_INCLUDE_PORT_IN_SPN_KB908209 e FEATURE_USE_CNAME_FOR_SPN_KB911149, è false. Per completezza, ecco un esempio di esportazione del Registro di sistema impostando la chiave della funzionalità per includere i numeri di porta nel ticket Kerberos su true:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001
Ulteriori informazioni
Pagine di diagnostica per la risoluzione dei problemi dell'autenticazione integrata di Windows
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per