Pubblicazione delle applicazioni con SharePoint, Exchange e RDG
Questo contenuto è relativo alla versione locale del Proxy applicazione Web. Per abilitare l'accesso protetto alle applicazioni locali tramite il cloud, vedere le informazioni sul proxy dell’applicazione Microsoft Entra.
Questo argomento descrive le attività necessarie per la pubblicazione di SharePoint Server, Exchange Server o Gateway Desktop remoto tramite Proxy applicazione Web.
Nota
Queste informazioni vengono fornite così come sono. Servizi Desktop remoto supporta e consiglia di usare Proxy app di Azure per fornire accesso remoto sicuro alle applicazioni locali.
Pubblicare SharePoint Server
È possibile pubblicare un sito di SharePoint tramite il Proxy applicazione Web se il sito è configurato per l'autenticazione basata su attestazioni o l'autenticazione integrata di Windows. Se si vuole usare Active Directory Federation Services (AD FS) per la preautenticazione, è necessario configurare una relying party usando una delle procedure guidate.
Se il sito di SharePoint usa l'autenticazione basata sulle attestazioni, è necessario usare l'Aggiunta guidata attendibilità componente per configurare l'attendibilità della relying party per l'applicazione.
Se il sito di SharePoint usa l'autenticazione integrata di Windows, è necessario usare la procedura di aggiunta guidata attendibilità della relying party non basata sulle attestazioni per configurare l'attendibilità della relying party per l'applicazione. È possibile usare l'autenticazione integrata di Windows con un'applicazione Web basata sulle attestazioni, a condizione che venga configurato un servizio KDC.
Per consentire agli utenti di eseguire l'autenticazione tramite l'autenticazione integrata di Windows, il server Proxy applicazione Web deve essere aggiunto a un dominio.
È necessario configurare l'applicazione in modo da supportare la delega vincolata Kerberos. È possibile eseguire questa operazione nel controller di dominio per ogni applicazione È anche possibile configurare l'applicazione direttamente nel server back-end se è in esecuzione in Windows Server 2012 R2 o Windows Server 2012. Per altre informazioni, vedere Novità dell'autenticazione Kerberos. È inoltre necessario assicurarsi che i server di Proxy applicazione Web siano configurati per la delega ai nomi dell'entità servizio dei server back-end. Per la procedura dettagliata che illustra come configurare Proxy applicazione Web per pubblicare un'applicazione usando l'autenticazione integrata di Windows, vedere Configurare un sito per l'uso dell'autenticazione integrata di Windows.
Se il sito di SharePoint è configurato per l'uso di mapping di accesso alternativo o raccolte siti con nome host, per pubblicare l'applicazione è possibile usare URL diversi per il server back-end e il server esterno. Se, tuttavia, non si configura il sito di SharePoint usando il mapping di accesso alternativo o le raccolte siti con nome host, è necessario usare gli stessi URL per il server back-end e il server esterno.
Pubblicare Exchange Server
La tabella seguente descrive i servizi di Exchange che è possibile pubblicare tramite Proxy applicazione Web e la preautenticazione supportata per questi servizi:
| Servizio Exchange | Preautenticazione | Note |
|---|---|---|
| Outlook Web App | - AD FS con autenticazione non basata sulle attestazioni - Pass-through - AD FS con autenticazione basata sulle attestazioni per Exchange 2013 Service Pack 1 (SP1) locale |
Per altre informazioni, vedere: Uso dell'autenticazione basata sulle attestazioni di AD FS con Outlook Web App ed EAC |
| Pannello di controllo di Exchange | Pass-through | |
| Outlook via Internet | Pass-through | Per il corretto funzionamento di Outlook via Internet, è necessario pubblicare ulteriori URL: - L'URL di individuazione automatica, EWS e OAB (in caso di modalità cache di Outlook). |
| Exchange ActiveSync | Pass-through AD FS tramite il protocollo di autorizzazione di base HTTP |
|
| Servizi Web Exchange | Pass-through | |
| Individuazione automatica | Pass-through | |
| Rubrica offline | Pass-through |
Per pubblicare Outlook Web App con l'autenticazione integrata di Windows, è necessario usare la procedura di aggiunta guidata attendibilità della relying party non basata sulle attestazioni per configurare l'attendibilità della relying party per l'applicazione.
Per consentire agli utenti di eseguire l'autenticazione tramite la delega vincolata Kerberos, il server Proxy applicazione Web deve essere aggiunto a un dominio.
È necessario configurare l'applicazione in modo da supportare l'autenticazione Kerberos. È inoltre necessario registrare un nome dell'entità servizio (SPN) nell'account in cui è in esecuzione il servizio Web. È possibile eseguire questa operazione nel controller di dominio o nei server di back-end. In un ambiente Exchange con carico bilanciato, è necessario usare l'account del servizio alternativo. Vedere Configurazione dell'autenticazione Kerberos per i server accesso client con carico bilanciato
È anche possibile configurare l'applicazione direttamente nel server back-end se è in esecuzione in Windows Server 2012 R2 o Windows Server 2012. Per altre informazioni, vedere Novità dell'autenticazione Kerberos. È inoltre necessario assicurarsi che i server di Proxy applicazione Web siano configurati per la delega ai nomi dell'entità servizio dei server back-end.
Pubblicazione di Gateway Desktop remoto tramite Proxy applicazione Web
Se si vuole limitare l'accesso al gateway di accesso remoto e aggiungere la preautenticazione per l'accesso remoto, è possibile implementarla tramite Proxy applicazione Web. Si tratta di un ottimo modo per assicurarsi di disporre di preautenticazione avanzata per RDG, inclusa l'autenticazione a più fattori. Un'altra opzione è la pubblicazione senza preautenticazione, che fornisce un singolo punto di ingresso nei sistemi.
Come pubblicare un'applicazione in RDG usando l'autenticazione pass-through di Proxy applicazione Web
L'installazione sarà diversa a seconda che i ruoli Accesso Web Desktop remoto (/rdweb) e Gateway Desktop remoto (rpc) si trovino nello stesso server o in server diversi.
Se i ruoli Accesso Web Desktop remoto e Gateway Desktop remoto sono ospitati nello stesso server RDG, è sufficiente pubblicare l'FQDN radice nel Proxy applicazione Web, ad esempio https://rdg.contoso.com/.
È anche possibile pubblicare le due directory virtuali singolarmente, ad esempio https://rdg.contoso.com/rdweb/ e https://rdg.contoso.com/rpc/.
Se Accesso Web Desktop remoto e Gateway Desktop remoto sono ospitati in server RDG separati, è necessario pubblicare singolarmente le due directory virtuali. È possibile usare lo stesso FQDN esterno o uno diverso, ad esempio https://rdweb.contoso.com/rdweb/ e https://gateway.contoso.com/rpc/.
Se l'FQDN esterno e quello interno sono diversi, non disabilitare la conversione dell'intestazione della richiesta nella regola di pubblicazione RDWeb. Questa operazione può essere effettuata eseguendo lo script di PowerShell seguente nel server Proxy applicazione Web, ma deve essere abilitato per impostazione predefinita.
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$falseNota
Se è necessario supportare client avanzati, ad esempio Connessioni RemoteApp e desktop o connessioni Desktop remoto iOS, questi non supportano la preautenticazione, quindi è necessario pubblicare RDG usando l'autenticazione pass-through.
Come pubblicare un'applicazione in RDG usando Proxy applicazione Web con preautenticazione
La preautenticazione di Proxy applicazione Web con RDG funziona passando il cookie di preautenticazione ottenuto da Internet Explorer passato al client connessione Desktop remoto (mstsc.exe). Viene quindi usato dal client connessione Desktop remoto (mstsc.exe). Viene quindi usato dal client connessione Desktop remoto come prova di autenticazione.
La procedura seguente indica al server di raccolta di includere le proprietà RDP personalizzate necessarie nei file RDP dell'app remota inviati ai client. Questi indicano al client che è necessaria la pre-autenticazione e di passare i cookie per l'indirizzo del server di preautenticazione al client connessione Desktop remoto (mstsc.exe). In combinazione con la disabilitazione della funzionalità HttpOnly nell'applicazione Proxy applicazione Web, ciò consente al client connessione Desktop remoto (mstsc.exe) di utilizzare il cookie proxy applicazione Web ottenuto tramite il browser.
L'autenticazione per il server Accesso Web Desktop remoto userà comunque l'accesso al modulo Accesso Web Desktop remoto. In questo modo viene fornito il minor numero di richieste di autenticazione utente quando il modulo Accesso Web Desktop remoto crea un archivio credenziali lato client che può quindi essere usato dal client connessione Desktop remoto (mstsc.exe) per qualsiasi avvio successivo dell'app remota.
Creare prima di tutto un trust manuale della relying party in AD FS come se si pubblicasse un'app che riconosce le attestazioni. Ciò significa che è necessario creare un trust fittizio della relying party che sia presente per applicare la preautenticazione, in modo da ottenere la preautenticazione senza delega vincolata Kerberos al server pubblicato. Dopo l'autenticazione di un utente, tutto il resto viene passato.
Avviso
Potrebbe sembrare che l'uso della delega sia preferibile, ma ciò non risolve completamente i requisiti SSO di mstsc e si verificano problemi durante la delega alla directory /rpc perché il client prevede di gestire l'autenticazione del gateway Desktop remoto stesso.
Per creare un trust della relying party manuale, seguire la procedura descritta nella Console di gestione di AD FS:
Seguire la procedura guidata Aggiungi trust della relying party
Selezionare Immetti manualmente i dati sulla relying party
Accettare tutte le impostazioni predefinite.
Per l'identificatore del trust della relying party immettere l'FQDN esterno che verrà usato per l'accesso RDG, ad esempio https://rdg.contoso.com/.
Si tratta del trust della relying party che verrà usata durante la pubblicazione dell'app in Proxy applicazione Web.
Pubblicare la radice del sito (ad esempio, https://rdg.contoso.com/) in Proxy applicazione Web. Impostare la preautenticazione su AD FS e usare il trust della relying party creato in precedenza. Ciò consentirà a /rdweb e /rpc di usare lo stesso cookie di autenticazione Proxy applicazione Web.
È possibile pubblicare /rdweb e /rpc come applicazioni separate e anche usare server pubblicati diversi. È sufficiente pubblicare entrambi usando lo stesso trust della relying party come token Proxy dell'applicazione Web per il trust della relying party; in questo modo, è valido in tutte le applicazioni pubblicate con lo stesso trust della relying party.
Se l'FQDN esterno e quello interno sono diversi, non disabilitare la conversione dell'intestazione della richiesta nella regola di pubblicazione RDWeb. Questa operazione può essere effettuata eseguendo lo script di PowerShell seguente nel server Proxy applicazione Web, ma deve essere abilitato per impostazione predefinita:
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$trueDisabilitare la proprietà del cookie HttpOnly nel Proxy applicazione Web nell'applicazione pubblicata RDG. Per consentire l'accesso al cookie di autenticazione Proxy applicazione Web da parte del controllo ActiveX RDG, è necessario disabilitare la proprietà HttpOnly nel cookie Proxy applicazione Web.
È necessario installare l'aggiornamento cumulativo di novembre 2014 per Windows RT 8.1, Windows 8.1 e Windows Server 2012 R2 (KB3000850).
Dopo aver installato l'hotfix, eseguire lo script di PowerShell seguente nel server Proxy applicazione Web specificando il nome dell'applicazione pertinente:
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableHttpOnlyCookieProtection:$trueLa disabilitazione di HttpOnly consente al RDG ActiveX di controllare l'accesso al cookie di autenticazione Proxy applicazione Web.
Configurare la raccolta RDG pertinente nel server di raccolta per informare il client connessione Desktop remoto (mstsc.exe) che è necessaria la preautenticazione nel file rdp.
In Windows Server 2012 e Windows Server 2012 R2 questa operazione può essere eseguita eseguendo il cmdlet di PowerShell seguente nel server di raccolta RDG:
Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-authentication server address:s: <https://externalfqdn/rdweb/>`nrequire pre-authentication:i:1"Assicurarsi di rimuovere le parentesi < e > quando si sostituisce con i propri valori, ad esempio:
Set-RDSessionCollectionConfiguration -CollectionName "MyAppCollection" -CustomRdpProperty "pre-authentication server address:s: https://rdg.contoso.com/rdweb/`nrequire pre-authentication:i:1"In Windows Server 2008 R2:
Accedere al Terminal Server con un account con privilegi di amministratore.
Passare a Avvia>Strumenti di amministrazione> Servizi terminal>TS RemoteApp Manager.
Nel riquadro Panoramica di TS RemoteApp Manager, accanto a Impostazioni RDP, fare clic su Cambia.
Nella scheda Impostazioni RDP personalizzate, digitare le impostazioni RDP seguenti nella casella Impostazioni RDP personalizzate:
pre-authentication server address: s: https://externalfqdn/rdweb/require pre-authentication:i:1Al termine, fare clic su Applica.
Ciò indica al server di raccolta di includere le proprietà RDP personalizzate nei file RDP inviati ai client. Questi indicano al client che è necessaria la pre-autenticazione e di passare i cookie per l'indirizzo del server di preautenticazione al client connessione Desktop remoto (mstsc.exe). Ciò, in combinazione con la disabilitazione di HttpOnly nell'applicazione Proxy applicazione Web, ciò consente al client connessione Desktop remoto (mstsc.exe) di utilizzare il cookie di autenticazione Proxy applicazione Web ottenuto tramite il browser.
Per altre informazioni su RDP, vedere Configurazione dello scenario OTP del gateway TS.