Coordinamento di URL con mapping di accesso alternativo e DNS

Articolo originale pubblicato mercoledì 25 maggio 2011

Mark Arend, Senior Consultant, ha sollevato diverse domande interessati sul coordinamento di URL con mapping di accesso alternativo e DNS:

• Come si configurano i mapping di accesso alternativo per gli URL con nome singolo, ad esempio https://fabrikam?
• Come si coordina l'accesso con bilanciamento del carico alle applicazioni Web estese con più aree, ad esempio https://partnerweb e https://remotepartnerweb.fabrikam.com?

La configurazione dei mapping di accesso alternativo può risultare abbastanza complessa. Dopo alcune ricerche ed essermi consultata con i nostri abili tester, tra cui Troy Starr, insieme a Mark ho elaborato il grafico seguente che contiene le informazioni necessarie per creare o modificare i mapping di accesso alternativo in base alla versione di autenticazione classica dell'esempio di progettazione di architettura logica.

Come è possibile osservare, gli URL con nome singolo, ad esempio https://teams, possono essere configurati per l'accesso alla rete Intranet. Questi URL vengono risolti dal client aggiungendovi il proprio suffisso DNS, ad esempio fabrikam.com, e quindi generando una ricerca DNS del nome con il suffisso. Quando un computer client nel dominio fabrikam.com richiede, ad esempio, https://teams, il computer invia al DNS una richiesta per https://teams.fabrikam.com. 

Oltre alla configurazione dei mapping di accesso alternativo, sono necessarie alcune operazioni anche a livello di DNS, che deve essere configurato con un record A per ogni nome di dominio completo (FQDN). Il record A punta all'indirizzo IP con bilanciamento del carico per i server Web che ospitano un sito. In una distribuzione di produzione tipica i server vengono configurati con indirizzi IP assegnati staticamente, oltre che con record A assegnati staticamente nel DNS. 

Dopo aver ricevuto l'indirizzo IP virtuale del servizio di bilanciamento del carico, il browser client stabilisce la comunicazione con un server Web front-end nella farm, quindi invia una richiesta HTTP insieme all'URL con nome singolo originale, https://teams. Tale richiesta viene riconosciuta da IIS e SharePoint come una richiesta per l'area Intranet in base alle impostazioni configurate nei mapping di accesso alternativo. Se l'utente invia una richiesta per https://teams.fabrikam.com, il processo sarà lo stesso, tranne il fatto che IIS e SharePoint riceverebbero questo FQDN, riconoscendo di conseguenza la richiesta come destinata all'area predefinita.

Negli ambienti con più domini immettere i record CNAME per DNS nei domini in cui non risiedono i siti. Se l'ambiente di rete di Fabrikam include, ad esempio, un secondo dominio denominato europe.fabrikam.com, i record CNAME per questi siti vengono immessi nel dominio Europe. Per il sito Intranet Team Sites (https://teams), viene aggiunto un record CNAME denominato teams al dominio europe.fabrikam.com che punta a teams.fabrikam.com. Quando viene aggiunto un suffisso DNS del client alle richieste di ricerca DNS, una richiesta per https://teams dal dominio Europe genererà una ricerca DNS di teams.europe.fabrikam.com e verrà indirizzata dal record CNAME a teams.fabrikam.com.

Dopo aver appreso in che modo gli URL vengono risolti dal browser, mi sono resa conto che https://fabrikam non è una scelta ottimale per illustrare un URL (https://fabrikam.fabrikam.com?). Ho quindi aggiornato la versione di autenticazione classica dell'esempio di progettazione di architettura logica con l'URL https://intranet. La versione aggiornata è disponibile per il download nella pagina contenente esempi di progettazione di SharePoint Server 2010: portale aziendale con autenticazione classica o con con autenticazione basata su attestazioni (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x410).

Esiste, infine, un problema noto con alcuni client Kerberos e la risoluzione dei record CNAME. Se nel proprio ambiente è inclusa l'autenticazione Kerberos,  vedere la pagina relativa ai problemi noti di configurazione di Kerberos (SharePoint Server 2010).

Questo è un post di blog localizzato. L'articolo originale è disponibile in Coordinating URLs with AAM and DNS