Domande frequenti sul proxy dell'applicazione Microsoft Entra

No, gli elementi di configurazione seguenti vengono usati dal proxy dell'app e non devono essere modificati o eliminati:

• Abilitare/disabilitare "Consenti flussi di client pubblici".
• CWAP_AuthSecret (segreti client).
• Autorizzazioni API. La modifica di uno degli elementi di configurazione precedenti nella pagina Registrazione app interrompe la preautenticazione per il proxy dell'applicazione Microsoft Entra.

No, è necessario eliminare un'app proxy dell'applicazione dall'area Applicazioni aziendali dell'interfaccia di amministrazione di Microsoft Entra. Se si elimina l'app proxy dell'applicazione dall'area Registrazioni app dell'interfaccia di amministrazione di Microsoft Entra, è possibile riscontrare problemi.

Per usare il proxy dell'applicazione Microsoft Entra, è necessario disporre di una licenza Microsoft Entra ID P1 o P2. Per altre informazioni sulle licenze, vedere Prezzi di Microsoft Entra

Se la licenza scade, il proxy dell'applicazione viene disabilitato automaticamente. Le informazioni sull'applicazione vengono salvate per un massimo di un anno.

Assicurarsi di disporre almeno di una licenza Microsoft Entra ID P1 o P2 e di un connettore di rete privata Microsoft Entra installato. Dopo aver installato correttamente il primo connettore, il servizio proxy dell'applicazione Microsoft Entra viene abilitato automaticamente.

Sì, il connettore di rete privata Microsoft Entra viene usato sia dal proxy dell'applicazione che dal Accesso privato Microsoft Entra. Per altre informazioni sul connettore, vedere Connettore di rete privata Microsoft Entra. Per risolvere i problemi di configurazione del connettore, vedere Risolvere i problemi relativi ai connettori.

Anche se questi suffissi vengono visualizzati nell'elenco dei suffissi, non è consigliabile usarli. Questi suffissi di dominio non devono essere usati con il proxy dell'applicazione Microsoft Entra. Se si usano questi suffissi di dominio, l'applicazione proxy dell'applicazione applicazione Microsoft Entra creata non funzionerà. È possibile usare il suffisso msappproxy.net di dominio standard o un dominio personalizzato.

Microsoft Entra ID ha un servizio proxy di applicazione che consente agli utenti di accedere alle applicazioni locali accedendo con il proprio account Microsoft Entra. Se sono stati installati connettori in aree diverse, è possibile ottimizzare il traffico selezionando l'area del servizio cloud proxy di applicazione più vicina da usare con ogni gruppo di connettori, vedere Ottimizzare il flusso di traffico con il proxy dell'applicazione Microsoft Entra.

Dopo aver caricato il certificato SSL, nel portale viene visualizzato un messaggio simile a "Certificato non valido. Possibile password errata".

Ecco alcuni suggerimenti per la risoluzione di questo errore:

• Verificare la presenza di problemi relativi al certificato. Installare il certificato nel computer locale. Se non si verificano problemi, il certificato è valido.
• Assicurarsi che la password non contenga caratteri speciali. La password deve contenere solo i caratteri 0-9, A-Z e a-z.
• Se il certificato è stato creato con il provider di archiviazione chiavi del software Microsoft, è necessario usare l'algoritmo RSA.

La durata predefinita è 85 secondi. L'impostazione "estesa" è 180 secondi. Il limite del timeout non può essere esteso.

No, attualmente non è supportata.

Il segreto client, detto anche CWAP_AuthSecret, viene aggiunto automaticamente all'oggetto applicazione (registrazione dell'app) quando viene creata l'app proxy dell'applicazione Microsoft Entra.

Il segreto client è valido per un anno. Un nuovo segreto client della durata di un anno viene creato automaticamente prima della scadenza del segreto client valido corrente. Tre CWAP_AuthSecret segreti client vengono sempre mantenuti nell'oggetto applicazione.

No, è necessario usare il dominio di fallback originale.

Articolo menzionato in questione: Aggiungere e sostituire il dominio di fallback onmicrosoft.com in Microsoft 365

Nella pagina Registrazioni applicazioni è possibile modificare l'URL della home page con l'URL esterno desiderato della pagina di destinazione. La pagina specificata viene caricata quando l'applicazione viene avviata da App personali o dal portale di Office 365. Per i passaggi di configurazione, vedere Impostare una home page personalizzata per le app pubblicate usando il proxy dell'applicazione Microsoft Entra

Se la preautenticazione di Microsoft Entra è configurata e l'URL dell'applicazione contiene un carattere "#" quando si tenta di accedere all'applicazione per la prima volta, si viene reindirizzati all'ID Microsoft Entra (login.microsoftonline.com) per l'autenticazione. Dopo aver completato l'autenticazione, si viene reindirizzati alla parte URL prima del carattere "#" e tutto ciò che viene dopo "#" sembra essere ignorato/rimosso. Ad esempio, se l'URL è https://www.contoso.com/#/home/index.html, una volta eseguita l'autenticazione di Microsoft Entra, l'utente viene reindirizzato a https://www.contoso.com/. Questo comportamento è previsto dalla progettazione a causa del modo in cui il carattere "#" viene gestito dal browser.

Possibili soluzioni/alternative:

• Configurare un reindirizzamento da https://www.contoso.com a https://contoso.com/#/home/index.html. L'utente deve prima accedere a https://www.contoso.com.
• L'URL usato per il primo tentativo di accesso deve includere il carattere "#" nel formato codificato (%23). Il server pubblicato potrebbe non accettarlo.
• Configurare il tipo di preautenticazione pass-through (non consigliato).

No, non è necessario IIS per le applicazioni pubblicate. È possibile pubblicare applicazioni Web in esecuzione in server diversi da Windows Server. Tuttavia, potrebbe non essere possibile usare la preautenticazione con un server non Windows, a seconda che il server Web supporti Negotiate (autenticazione Kerberos). IIS non è necessario nel server in cui è installato il connettore.

Il proxy di applicazione non aggiunge automaticamente l'intestazione HTTP Strict-Transport-Security alle risposte HTTPS, ma mantiene l'intestazione se si trova nella risposta originale inviata dall'applicazione pubblicata. È in programma la dimostrazione di un'impostazione per abilitare questa funzionalità.

No, se il protocollo http è configurato nell'URL esterno, l'endpoint proxy dell'applicazione Microsoft Entra accetta la richiesta in ingresso sulla porta TCP 80, se il protocollo https sulla porta TCP 443.

Sì, alcuni esempi di URL interni, tra cui porte: http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/.

Alcune risposte inviate dalle applicazioni Web pubblicate potrebbero contenere URL hardcoded. In questo caso, è necessario assicurarsi di usare una soluzione di conversione dei collegamenti che il client usa sempre l'URL corretto. Le soluzioni di traduzione dei collegamenti potrebbero essere complesse e potrebbero non funzionare in tutti gli scenari. Le soluzioni documentate per la traduzione dei collegamenti sono disponibili qui .

Come procedura consigliata, è consigliabile usare URL esterni e interni identici. Gli URL esterni e interni sono considerati identici, se in entrambi gli protocol://hostname:port/path/ URL sono identici.

A tale scopo, è possibile usare la funzionalità Domini personalizzati.

Esempi:

Identici:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Non identico:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

Rendere identici gli URL esterni e interni non è possibile, se l'URL interno contiene una porta non standard (diversa da TCP 80 / 443).

In alcuni scenari è necessario apportare modifiche nella configurazione dell'app Web.

Il metodo PrincipalsAllowedToDelegateToAccount viene usato quando i server del connettore si trovano in un dominio diverso dall'account del servizio dell'applicazione Web. Richiede l'uso della delega vincolata basata su risorse. Se i server del connettore e l'account del servizio dell'applicazione Web si trovano nello stesso dominio, è possibile usare Utenti e computer di Active Directory per configurare le impostazioni di delega in ogni account computer del connettore, consentendo loro di delegare al nome dell'entità servizio di destinazione.

Se i server del connettore e l'account del servizio dell'applicazione Web si trovano in domini diversi, viene usata la delega basata su risorse. Le autorizzazioni di delega vengono configurate nel server Web di destinazione e nell'account del servizio dell'applicazione Web. Questo metodo di delega vincolata è relativamente nuovo. Il metodo è stato introdotto in Windows Server 2012, che supporta la delega tra domini consentendo al proprietario della risorsa (servizio Web) di controllare quali account del computer e del servizio possono effettuare la delega. Non esiste un'interfaccia utente per facilitare questa configurazione, quindi è necessario usare PowerShell. Per altre informazioni, vedere il white paper Understanding Kerberos Constrained Delegation with application proxy .For more information, see the white paper Understanding Kerberos Constrained Delegation with application proxy.

L'autenticazione NTLM non può essere usata come metodo di preautenticazione o Single Sign-On. L'autenticazione integrata di Windows può essere usata solo quando può essere negoziata direttamente tra il client e l'applicazione Web pubblicata. L'uso dell'autenticazione integrata di Windows determina in genere la visualizzazione di una richiesta di accesso nel browser.

No, questo non funzionerà, perché un utente guest in Microsoft Entra ID non ha l'attributo richiesto da nessuna delle identità di accesso indicate in precedenza.

In questo caso è presente un fallback a "Nome entità utente". Per altre informazioni sullo scenario B2B, vedere Concedere agli utenti B2B in Microsoft Entra ID l'accesso alle applicazioni locali.

I criteri di accesso condizionale vengono applicati solo per gli utenti preautenticati correttamente in Microsoft Entra ID. L'autenticazione pass-through non attiva l'autenticazione di Microsoft Entra, quindi i criteri di accesso condizionale non possono essere applicati. Con l'autenticazione pass-through, i criteri MFA devono essere implementati nel server locale, se possibile o abilitando la preautenticazione con il proxy dell'applicazione Microsoft Entra.

No, questo scenario non è supportato perché il proxy dell'applicazione termina il traffico TLS.

Fare riferimento a Publish Remote Desktop with Microsoft Entra application proxy (Pubblica Desktop remoto con il proxy dell'applicazione Microsoft Entra).

No, questo scenario non è supportato.

Sì, è previsto. Lo scenario di preautenticazione richiede un controllo ActiveX, che non è supportato nei browser di terze parti.

Sì, questo scenario è attualmente disponibile in anteprima pubblica. Fare riferimento a Publish Remote Desktop with Microsoft Entra application proxy (Pubblica Desktop remoto con il proxy dell'applicazione Microsoft Entra).

Sì, è previsto. Se il computer dell'utente è aggiunto a Microsoft Entra, l'utente accede automaticamente all'ID Microsoft Entra. L'utente deve fornire le proprie credenziali solo nel modulo di accesso di RDWeb.

Questa opzione consente all'utente di scaricare il file rdp e usarlo da un altro client RDP (all'esterno del client Web Desktop remoto). In genere, un altro client RDP (ad esempio il client Desktop remoto Microsoft) non può gestire la preautenticazione in modo nativo. Ecco perché lo scenario non funziona.

Vedere Abilitare l'accesso remoto a SharePoint con il proxy dell'applicazione Microsoft Entra.

L'app sharePoint per dispositivi mobili non supporta attualmente la preautenticazione di Microsoft Entra.

No, microsoft Entra application proxy è progettato per funzionare con Microsoft Entra ID e non soddisfa i requisiti per fungere da proxy AD FS.

No, questo non è supportato.

Le applicazioni che usano il protocollo WebSocket, ad esempio QlikSense e Client Web Desktop remoto (HTML5), sono ora supportate. Di seguito sono riportate le limitazioni note:

• Il proxy di applicazione rimuove il cookie impostato nella risposta del server durante l'apertura della connessione WebSocket.
• Non esiste alcun accesso Single Sign-On applicato alla richiesta WebSocket.
• Le funzionalità (Eventlogs, PowerShell e Remote Desktop Services) in Windows Amministrazione Center (WAC) non funzionano tramite il proxy dell'applicazione Microsoft Entra.

L'applicazione WebSocket non ha requisiti di pubblicazione univoci e può essere pubblicata allo stesso modo di tutte le altre applicazioni proxy dell'applicazione.

Sì. La conversione dei collegamenti influisce sulle prestazioni. Il servizio proxy dell'applicazione analizza l'applicazione per individuare i collegamenti hardcoded e li sostituisce con i rispettivi URL esterni pubblicati prima di presentarli all'utente.

Per prestazioni ottimali, è consigliabile usare URL interni ed esterni identici configurando domini personalizzati. Se non è possibile usare domini personalizzati, è possibile migliorare le prestazioni di conversione dei collegamenti usando l'estensione per l'accesso sicuro alle app personali o il browser Microsoft Edge per dispositivi mobili. Vedere Reindirizzare i collegamenti hardcoded per le app pubblicate con il proxy dell'applicazione Microsoft Entra.

Questo scenario non è supportato direttamente. Le opzioni disponibili per questo scenario sono le seguenti:

1. Pubblicare entrambi gli URL HTTP e HTTPS come applicazioni separate con un carattere jolly, ma assegnare a ognuno un dominio personalizzato diverso. Questa configurazione funziona perché hanno URL esterni diversi.

2. Pubblicare l'URL HTTPS tramite un'applicazione con caratteri jolly. Pubblicare le applicazioni HTTP separatamente usando questi cmdlet di PowerShell per il proxy di applicazione:

   • Gestione delle applicazioni proxy di applicazione
   • gestione del connettore di rete privata