martes, 24 de febrero de 2015

Alternativas para autenticarse por Windows desde una granja de SharePoint migrada en Azure

Hay muchas aclaraciones que hacer con este tema, pero seré lo más conciso posible yendo al grano y resolviendo algunos mitos o malas concepciones sobre el tema.

Primero lo primero, definir el requerimiento del cliente.  Mover  la granja de SharePoint hacia la nube de permitiendo a los usuarios de la red interna o intranet autenticarse con sus mismas credenciales de su red interna en la instancia de Azure.

En este escenario hay un componente que define las opciones que tenemos disponibles y las que no.  A continuación las opciones disponibles en Azure hoy 14 de Febrero del 2015.  Ya que Azure evoluciona tan rápido que mejor hago referencia a la fecha en como estaban las cosas en ese momento.   Para las tres opciones es necesario establecer una VPN sitio a sitio entre Azure y la red interna del cliente.  Esto nos permite ver la red interna del cliente desde las Virtuales de Azure y viceversa como que si estuviésemos en la misma ubicación geográfica.  Entonces los servidores se configuran como el resto de servidores de la red interna, y perteneciendo al dominio o bosque al que se le indique en la configuración.  Las cuentas de servicio utilizadas en la instalación son del dominio de la intranet así que gracias al tunel privado de la VPN las dos redes son una misma red.  En Azure se crearon dos Virtuales una con SQL Server y otra con SharePoint Foundation 2013.  Se montó la base de datos de contenido de la granja local al ambiente creado en Azure.

Explicado eso enumeramos las 3 opciones posibles de configuración:

1) La autenticación de Windows sucede en el DC de la intranet a través de la VPN, si por alguna razón la VPN se interrumpe, los usuarios no podrán autenticarse a los servidores que están en Azure ni desde la red interna ni desde Azure.   https://msdn.microsoft.com/en-us/library/azure/dn636917.aspx

Resultado de imagen para vpn connection azure

2) Se adiciona otra virtual donde se configura el rol de Controlador de Dominio y se utiliza el AD Directory Service para definir un sitio en Azure basado en el rango de IPS definidas en la VPN sitio a sitio.  Esto permite que los usuarios se autentiquen con el DC configurado en Azure y en caso se pierda la conexión de la VPN los usuarios que accedan desde internet puedan autenticarse al SharePoint que esta en Azure, no así los de la intranet si utilizan el descubrimiento del DNS local sino el público con un enlace de Internet.  Esto da una mayor independencia de acceso con algunos inconvenientes. http://azure.microsoft.com/en-us/documentation/articles/virtual-networks-install-replica-active-directory-domain-controller/

https://msdn.microsoft.com/library/azure/jj156090.aspx

3) Se implementa AD FS o Active Directory Federation Service en azure, para ello se requiere como mínimo para menos de 1,000 usuarios tres servidores virtuales adicionales uno para AD FS y otro para AD FS Proxy o WAP (Web Application Proxy) y otro para DirSync.  Si son más de 1,000 usuarios se recomienda redundancia en los servidores AD FS, es decir para dar un total de 5 servidores.  Para esta ultima configuración se recomienda que el o los DC´s corran por lo menos sobre Windows 2008 R2 y utilizar el asistente de configuración el Azure AD Connect que aunque este en Preview, facilita la configuración de estos servidores.   Esta última opción es una solución Single Sign On real, que permite autenticar a los usuarios tanto de la red interna como la nube aunque la VPN falle.  Solo fallará si el enlace a internet no esta disponible desde donde se este accediendo.

https://technet.microsoft.com/en-us/library/hh831502.aspx

https://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=53949

https://technet.microsoft.com/en-us/library/dn296436.aspx

http://simon-may.com/adfs-dirsync-waad-resources/

El escenario no disponible para resolver este problema es el siguiente:

Configurar un servidor virtual en Azure para sincronizar el directorio Activo local al Directorio de Azure.  Este escenario no funcionará ya que el contenido migrado tiene los permisos asignados a los usuarios de la red interna que están registrados en SharePoint con el formato tradicional de usuario de red [dominio]/[nombre usuario] y los usuarios del Directorio de Azure son reconocidos con el siguiente formato [Proveedor Azure]:[Nombre de Usuario en formato upn].  Además los usuarios de red utilizan el siguiente prefijo en el formato i:0#.w y los usuarios autenicados por el Directorio de Azure con el siguiente prefijo: i:0e.t .  (Dando a entender que el primero es Windows y el segundo externo). Este escenario esta pensado para usuarios externos que deseamos exponer información que vamos a compartir con ellos, por ejemplo proveedores, clientes o socios de negocios.

https://msdn.microsoft.com/en-us/library/azure/dn441214.aspx

https://technet.microsoft.com/en-us/library/dn635311.aspx

 

Que escenario escoger es dependiendo que tan crítico es la información almacenada en SharePoint y que tanto se desea invertir para mantener la disponibilidad del servicio todo el tiempo para los usuarios de la red de la organización para acceder dicho servicio tanto desde la red interna como del internet.

En este artículo vimos 3 escenarios para acceder la plataforma de SharePoint desde la nube pero autenticándonos con  los usuarios de la red interna lo que podemos catalogar como un ambiente híbrido. 

Les recomiendo revisen el siguiente artículo:

Planning for SharePoint 2013 on Azure Infrastructure Services

The SharePoint Server Farm feature

Hasta la próxima!,

Juan Manuel Herrera Ocheita

No hay comentarios.: