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 Azure 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

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

Hasta la próxima!,

Juan Manuel Herrera Ocheita

Cómo sincronizar los usuario y contraseñas locales con Azure AD para una instancia nueva de SharePoint 2013

El escenario es el siguiente:

Se desea crear una instancia nueva de una granja de SharePoint 2013 en la nube de Azure para reducir los costos de operación e inversión, el cliente solicita que los usuarios de su red interna puedan autenticarse con sus mismas credenciales en Azure y con la mínima configuración posible.

Cuales son los requerimientos básicos entonces para este escenario:

1) Contar con una suscripción en Azure

2) Contar con una Directorio Activo Local

3) Realizar una Conexión VPN Sitio a Sitio desde el portal de Azuren

4) Una Virtual con Windows Server y AD DirSync para sincronizar los usuarios de la red interna con el Directorio Activo de Azure

5) Dos Virtuales conectadas al dominio local por medio de la VPN para SQL Server y SharePoint 2015

6) Configurar la Aplicación Web en SharePoint para utilizar el Directorio Activo de Azure como proveedor de autenticación

NOTA: Este escenario es valido si no se esta migrando contenido de SharePoint de la red interna a la nube de Azure, ya que a nivel de permisos en SharePoint el usuario de Windows la red interna se registra de otra forma distinta a la del proveedor de Azure.  El formato tradicional de usuario de red en SharePoint se registra de la siguiente forma: [dominio]/[nombre usuario] (Ej: midominio\elusuario) y los usuarios del Directorio de Azure son reconocidos con el siguiente formato [Proveedor Azure]:[Nombre de Usuario en formato upn] (Ej.: [Proveedor Azure]miusuario@midominio.com).  Además los usuarios de red utilizan el siguiente prefijo en el formato i:0#.w y los usuarios autenticados por el Directorio de Azure con el siguiente prefijo: i:0e.t .  (Dando a entender que el primero es Windows y el segundo externo).

Que beneficios nos provee Azure como plataforma.  Pues son muchos pero entre los que más se agradece son los siguientes:

1) Azure solo cobra por uso, es decir si tengo reservado un espacio de almacenamiento no me cobra por ello solo el  que ocupo.  No me cobra por la VM mientras este apagado por ejemplo.  O la VPN solo cuando este trasfiriendo paquetes de un lado a otro.

2) Se cuenta con IP públicas por cada máquina virtual y nombres públicos accesibles desde el internet

3) Una vez familiarizado con el portal y sus opciones, es relativamente fácil la configuración del ambiente y la seguridad, como por ejemplo habilitar o deshabilitar el acceso a las virtuales por Escritorio Remoto, HTTP, IMAP, etc.

4) Contar con Servicio de Directorio Activo disponible de forma inmediata, para utilizar como proveedor de autenticación en una granja de SharePoint.

Resumen del procedimiento

1) Adquirir una suscripción en Azure http://azure.microsoft.com/en-us/pricing/free-trial/

2) Establecer una VPN sitio a sitio https://msdn.microsoft.com/es-es/library/azure/dn636917.aspx

La idea fundamental de la VPN este establecer un tunel privado en Internet para conectar las dos redes (local/nube).   Para ellos es necesario de lado del cliente contar con un Equipo de enrutamiento de Red o Router. Es necesario para configurarlo asignar IPs de lado de Azure que no colisionen con el rango de IPs de la red interna y que el rango asignado de ambos lados sea el mismo.  Es muy importante en esta configuración manejar la misma máscara supongamos que en el ejemplo de arriba estamos usando al configuración 192.168.1.0/24 eso define una máscara de IP por lo que de lado de Azure debemos manejar la misma máscara es decir 192.168.2.0/24.  El rango de IP locales configuradas deberán contener las IPS donde están los servidores DC y DNS ya que más tarde se utilizaran para conectar las virtuales a ese dominio.  Para configurar la VPN Ambos tienen que conocer las puertas de enlaces, rangos de IPs y la llave Pre-Shared, y la información de ambas fases.  Por ejemplo: 

Puerta de enlace intranet es en el ejemplo de arriba 192.168.1.11 y de lado de Azure es  192.168.2.11.

Fase I

authentication:  pre-share

encryption: aes-256

hashing: hash sha

Key group: Deffi

lifetime: 28800

Fase II – Configuración IPSEC

esp-aes-256 esp-sha-hmac

lifetime seconds 3600

lifetime kilobytes 102400000

La información de las fases es extraída del script generado para los dispositivos como CISCO en el siguiente enlace:

Si es exitosa veras una imagen similar a la de abajo.

3) Establecer un grupo de afinidad geográfico para asociar máquinas virtuales.  Esto es importante para reducir el tiempo de retraso por la ubicación geográfica y para que las maquines se puedan ver entre ellas.

4) Una Virtual con Windows Server y AD DirSync para sincronizar los usuarios de la red interna con el Directorio Activo de Azure

Importante en este procedimiento es crear una cuenta de servicio en Azure AD y asignarle el permiso de Global Admin. Eso lo hacemos en la edición del perfil del usuario dentro del Active Directory de Azure como se muestra en la imagen de abajo.

Para revisar los prerrequisitos de Azure Dir Sync el siguiente enlace:

https://msdn.microsoft.com/en-us/library/azure/jj151831.aspx?f=255&MSPPError=-2147217396

 

5) Crear las máquinas virtuales  http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-tutorial/

Para crear las máquinas virtuales tenemos dos opciones de la galeria de Azure o bien de una imagen que hayamos subido.   En mi caso fue de una imagen que subimos ya que el cliente tenía su licencia de Windows.  Para ello fue necesario crear la virtual en Hyper-V instalar el sistema operativo del cliente y ejecutar la utileria sysprep para poder subir el archivo vhd, el resto del software lo podemos descargar vía suscripción desde el internet disponible en Azure luego de leventar la virtual.  El procedimiento para subir la vitual es la siguiente:

http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-upload-vhd-windows-server/

6) Configurar la Aplicación Web en SharePoint para utilizar el Directorio Activo de Azure como proveedor de autenticación

Para realizar esta configuración los dejo con tres enlaces que los ayudarán.  Lean los detenidamente y que no se les pase ningún detalle.  Mucho ojo con los FQDN y URL que deberán indicar ya que allí pueden tener problemas, puede eliminar y crear de nuevo las reglas de grupo el Proveedor de Identidad WS-Federation o el certificado, sin problema, solo asegúrense de hacerlo bien.

Oficial de Microsoft:

https://technet.microsoft.com/en-us/library/dn635311(v=office.15).aspx

Artículo de Fuse Collaboraton services

http://www.fusecollaboration.com/fuseblog/Lists/Posts/Post.aspx?List=178d823a-3196-48e8-bb8f-743bfee59281&ID=74&Web=8df942bb-1ca5-4306-9004-53a7757edbb8

Y de Patterns & practices

https://msdn.microsoft.com/en-us/practices/dn635311(v=office.14)

En este artículo vimos como configurar un pequeña granja de SharePoint pero en la nube de Azure, una tendencia cada vez más común dentro de las organizaciones.

Hasta la próxima,

Juan Manuel Herrera Ocheita

SharePoint Server 2016 para el segundo semestre de este año

El anuncio a dejado una esperanza para mejora y sorpresa al mismo tiempo.  Ya que InfoPath continua vigente para esta próxima versión y será totalmente soportado en  SPO o SharePoint Online.

Dos aspectos sobresalientes del anuncio son prometen más poder a la comunidad de desarrolladores que es de 3 millones de personas.   A través de las APIs ya disponibles y otras nuevas que serán presentadas.  El modelo de Apps continua contrario a lo que algunos piensan.

Y el tema Ambientes híbridos que es la mejor forma de acoger la idea de la nube y del software como servicio.

 

También parece ser que las características de seguridad mejoraran finalmente esperemos un tablero que facilite la seguridad y revisión de los permisos para apoyar la administración de SharePoint.  Esperemos ver asistentes de configuración como las nuevas herramientas de Azure que ayudan la instalación de escenarios más rápida y fácilmente, como lo es AAD Connect http://connect.microsoft.com/site1164/program8612.

Quieres leer más al respecto aquí enlaces:

http://blogs.office.com/2015/02/02/evolution-sharepoint/

http://redmondmag.com/blogs/the-schwartz-report/2015/02/on-premises-sharepoint-2016.aspx

Hasta la próxima!,

 

Juan Manuel Herrera Ocheita