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 di registrazione dell'app interrompe la preautenticazione per Microsoft Entra Application Proxy.

No, è necessario eliminare un'app Application Proxy dall'area Applicazioni Enterprise dell'interfaccia di amministrazione di Microsoft Entra. Se si elimina l'app Application Proxy dall'area Registrazioni app dell'interfaccia di amministrazione di Microsoft Entra, potrebbero verificarsi problemi.

Per utilizzare Microsoft Entra Application Proxy è necessario avere una licenza Microsoft Entra ID P1 o P2. Per altre informazioni sulle licenze, consultare i prezzi di Microsoft Entra

Se la licenza scade, Application Proxy verrà disabilitato automaticamente. Le informazioni sull'applicazione verranno salvate al massimo per 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 verrà abilitato automaticamente.

L'uso di un'utilità di analisi delle porte negli endpoint pubblici del proxy dell'applicazione (msappproxy.net o personalizzato) può indicare che le porte TCP 10200 e 10201 sono aperte, oltre alle porte 80 e/o 443. Queste porte vengono usate per scopi di monitoraggio dell'integrità dei servizi interni. Nessun dato dei clienti è accessibile su queste porte e i servizi dietro di essi non elaborano alcuna informazione; rispondono semplicemente con "OK".

Sì, il connettore di rete privata di Microsoft Entra viene utilizzato sia dal proxy dell'applicazione di Microsoft Entra che da Microsoft Entra Private Access. Per ulteriori informazioni sui connettori, vedere Connettore di rete privata di 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 Microsoft Entra creata non funzionerà. È possibile usare il suffisso msappproxy.net di dominio standard o un dominio personalizzato.

Microsoft Entra ID contiene un servizio proxy di applicazione che consente agli utenti di accedere alle applicazioni locali effettuando l'accesso con il proprio account Microsoft Entra. Se si installano connettori in aree diverse, è consigliabile ottimizzare il traffico selezionando l'area del servizio cloud del proxy dell'applicazione più vicina con ogni gruppo di connettori; vedere Ottimizzare il flusso del 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, definito anche CWAP_AuthSecret, viene aggiunto automaticamente all'oggetto applicazione (registrazione dell'app) durante la creazione dell'app Microsoft Entra Application Proxy.

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 segreti client CWAP_AuthSecret sono sempre presenti 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 verrà caricata all'avvio dell'applicazione da MyApps o dal portale di Office 365. Per la procedura di configurazione vedere Impostare una home page personalizzata per le app pubblicate con Microsoft Entra Application Proxy

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 a Microsoft Entra ID (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. Per 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 modulo 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. Potrebbe però risultare impossibile usare la pre-autenticazione con un server non Windows, a seconda che il server Web supporti o meno la negoziazione (autenticazione Kerberos). IIS non è necessario nel server in cui è installato il connettore.

Application Proxy non aggiunge automaticamente l'intestazione HTTP Strict-Transport-Security alle risposte HTTPS, ma manterrà l'intestazione se è presente 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 di Microsoft Entra Application Proxy 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 le 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, usando una soluzione di conversione dei collegamenti, che il client usi 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 conversione dei collegamenti sono disponibili qui.

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

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

Esempi:

Identico:

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 è disponibile alcuna interfaccia utente per facilitare questa configurazione ed è quindi necessario usare PowerShell. Per altre informazioni, consultare il white paper Understanding Kerberos Constrained Delegation with application proxy (Riconoscimento della delega vincolata di Kerberos con Application Proxy).

L'autenticazione NTML non è utilizzabile come metodo di pre-autenticazione 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, non funziona, perché un utente guest in Microsoft Entra ID non dispone dell'attributo richiesto dalle identità di accesso indicate in precedenza.

In questo caso, si verificherà un fallback a "Nome dell'entità utente". Per altri dettagli sullo scenario B2B, consultare Concedere agli utenti B2B in Microsoft Entra ID l'accesso alle applicazioni locali.

I criteri di accesso condizionale vengono applicati solo per gli utenti pre-autenticati correttamente in Microsoft Entra ID. La pre-autenticazione pass-through non attiva l'autenticazione di Microsoft Entra, quindi i criteri di accesso condizionale non sono applicabili. Con la pre-autenticazione pass-through, i criteri MFA devono essere implementati nel server locale, se possibile, oppure abilitando la pre-autenticazione di Microsoft Entra con Microsoft Entra Application Proxy.

No, questo scenario non è supportato, perché Application Proxy terminerà il traffico TLS.

Fare riferimento a Pubblicare Desktop remoto con Microsoft Entra Application Proxy.

No, questo scenario non è supportato.

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

Sì, questo scenario è attualmente disponibile in anteprima pubblica. Fare riferimento a Pubblicare Desktop remoto con Microsoft Entra Application Proxy.

Sì, è previsto. Se il computer dell'utente è aggiunto a Microsoft Entra, l'utente accede automaticamente a Microsoft Entra ID. 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.

Fare riferimento ad Abilitare l'accesso remoto a SharePoint con Microsoft Entra Application Proxy.

L'app per dispositivi mobili SharePoint 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 agire da proxy di AD FS.

No, questa operazione non è supportata.

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

• Application proxy rimuove il cookie impostato nella risposta del server durante l'apertura della connessione WebSocket.
• Non esiste alcun accesso SSO applicato alla richiesta WebSocket.
• Le funzionalità (Eventlog, PowerShell e Servizi Desktop remoto) di Windows Admin Center (WAC) non funzionano in Microsoft Entra Application Proxy.

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

Sì. La conversione dei collegamenti influisce sulle prestazioni. Il servizio Application Proxy analizza l'applicazione alla ricerca di 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 Microsoft Entra Application Proxy.

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 funzionerà perché hanno URL esterni diversi.

2. Pubblicare l'URL HTTPS tramite un'applicazione con caratteri jolly. Pubblicare separatamente le applicazioni HTTP usando i cmdlet di PowerShell per Application Proxy seguenti:

   • Gestione dell'applicazione di Application Proxy
   • gestione del connettore di rete privata