Hola, hoy vamos a seguir hablando sobre Azure Active Directory, su anatomia y sus protocolos.

Directorios

Como la mayoría de la gente sabe, el bosque en WSAD representa el límite administrativo y de seguridad. Del mismo modo, cada directorio en Azure AD es como un recurso totalmente independiente. En otras palabras, cada directorio es un peer, con todas las funciones y lógicamente independiente de otros directorios que administre. No existe una relación padre-hijo entre directorios.

Esta independencia entre directorios incluye:
• Independencia de recursos. Si creamos o eliminamos un recurso en un directorio, no tiene ningún impacto en ningún recurso de otro directorio, con la excepción parcial de los usuarios externos. Además, si utilizamos un dominio verificado personalizado "fabrikam.com" con un directorio, no puede utilizarse con ningún otro directorio.

• Independencia administrativa. Si, por ejemplo, agregamos o eliminamos una función de administrador de un directorio, esto no afecta a los privilegios de administración de ningún otro directorio.

• Independencia de la sincronización. Podemos configurar cada directorio independientemente para extender su infraestructura de identidad local con este directorio y obtener datos sincronizados.

Como un bosque contiene uno o varios dominios, un directorio contiene uno o varios dominios. Para ello, como podemos declarar administrador (es) de la empresa para el bosque, hay administradores de directorio similarmente similares.

Unidades administrativas

Las unidades administrativas (AUs) en Azure AD son como OUs en WSAD modernizadas para la nube. Le permiten subdividir su directorio Azure AD, permitiendo la separación de tareas administrativas y creación de políticas en una gran organización. Representan un nuevo contenedor Azure AD de recursos que se pueden utilizar para delegar permisos administrativos sobre subconjuntos de usuarios y aplicar directivas a un subconjunto de usuarios.

Las unidades administrativas (actualmente en vista preliminar pública a partir de esta escritura) son una característica de la edición Azure AD Premium. Por el momento, podemos crear y administrarlos a través de cmdlets dedicados de Windows PowerShell. Azure AD permite a los administradores administrar la información en él a través de:

• El uso de la interfaz gráfica de usuario gracias al portal de gestión de Azure u otros portales.

• Un conjunto de cmdlets de Windows PowerShell, que permite realizar scripts de operaciones frecuentes: el Módulo Active Directory de Azure para Windows PowerShell.

• Herramientas de administración in situ que se utilizan para administrar la información en un directorio local y luego se sincronizan en Azure AD con la sincronización de directorios.

Servicios de Token de Seguridad (STS)

Como se mencionó anteriormente, Azure AD proporciona soporte para autenticación (federada), inicio de sesión único y autorización. Existen sabores de este soporte para los navegadores y para los clientes enriquecidos, y para las identidades alojadas en la nube (identidades de nube), así como los proveedores de identidad federados (identidades federadas). Estas capacidades son proporcionadas por el Servicio de Token de Seguridad (STS) en Azure AD. El STS en Azure AD es un STS multi-inquilino.

Modelo de seguridad principal

El modelo de seguridad básico consta de dominios de inquilino. Existe un mapeo 1: 1 entre un dominio de inquilino de STS y un inquilino de directorio. La noción de un reino es un concepto bien conocido en la seguridad; Y el dominio de inquilino en el STS es el equivalente de un dominio Kerberos o un dominio de WSAD. Los dominios de inquilinos tienen un identificador de seguridad único, inmutable, globalmente único y renombrado, y uno o más nombres de nombres DNS verificados que actúan como alias amistosos. Los dominios de inquilinos contienen principios, que representan a usuarios, servicios, etc. Un director es un objeto del tipo correspondiente en el directorio.

Los directores tienen uno o más nombres (como nombre principal de usuario para un usuario o varios nombres principales de servicio para una aplicación) y un identificador de seguridad, que es globalmente único, inmutable y no reutilizable.

Los directores pueden tener una o más credenciales (como contraseña, certificado y claves) que se pueden usar para autenticar el principal. Alternativamente, el principal puede ser autenticado por un identificador de un proveedor de identidad externo (tal como un ID inmutable de un testigo de seguridad emitido por el proveedor de identidad de la organización en el local). Un director que tiene este tipo de configuración de asignación también se conoce como un principal federado, ya que el principal representa conceptualmente un usuario de un sistema federado (como un usuario corporativo de la infraestructura de identidad local).

Los directores pueden solicitar y aceptar fichas de seguridad, normalmente del dominio del inquilino en el que residen. Los reinos de arrendatario son apoyados por el STS que autentica a los solicitantes y hace declaraciones autoritativas sobre esos solicitantes, generalmente en el contexto del objetivo de la solicitud. Estas declaraciones autoritativas están empaquetadas en fichas de seguridad y están firmadas por el STS. Los testigos de seguridad consisten en una colección de reclamaciones, que son declaraciones hechas sobre los usuarios, por ejemplo, nombre, id, correo electrónico, grupo, rol, etc., utilizados para fines de autenticación y decisión de autorización. Los testigos de seguridad normalmente siguen un método seguro y estandarizado de empaquetar los reclamos para el transporte.

Los Tenant realms pueden configurar la federación con otros dominios, es decir, con una infraestructura de identidad local existente, tal como un entorno corporativo de Active Directory.

Protocolos (modernos) compatibles

Los mecanismos de autenticación locales habituales como Kerberos y NTLM ya no se aplican de forma general en el espacio de la nube, ya que las aplicaciones en la nube no tienen la mayor parte del tiempo conectividad a un controlador de dominio (DC) de Windows Server Active Directory (WSAD) Las máquinas virtuales debajo no son dominio-se unieron en todos.

Azure Virtual Machines y Azure Virtual Network ciertamente proporcionan estas capacidades con la capacidad de instanciar un DC independiente en la nube o de aprovechar la conectividad segura de sitio a sitio de nuevo a la infraestructura local.

Sin embargo, esto debería verse más específicamente como rutas de "migración" de IaaS que la situación general para las cargas de trabajo en la nube. Lo es aún más con la movilidad y la tendencia "Bring Your Own Device" (BYOD), donde los usuarios también se considerarán a menudo fuera del perímetro de la infraestructura de la organización. Además, las soluciones de nube pueden por naturaleza abarcar múltiples ámbitos de seguridad.

En consecuencia, los protocolos de federación de identidad de Internet constituyen una forma mucho más escalable y eficiente de implementar la autenticación en dicho contexto. Además, los protocolos de federación de identidad de Internet también pueden responder de manera relevante a otras preocupaciones como el inicio de sesión único entre las aplicaciones en la nube que residen en el mismo de diferentes nubes, así como la emisión de reclamaciones con la capacidad de procesamiento y transformación de los tokens de seguridad en términos de tipo de confianza, Formato de token, semántica y (valores de) reclamaciones para "adaptación de impedancia".

Azure AD opta por tales protocolos para la integración de aplicaciones y, además, sistemáticamente apunta a ser estándares abiertos siempre que sea posible. Les recomiendo ver mas sobre el tema en Azure Active Directory Authentication Protocols: http://msdn.microsoft.com/library/azure/dn151124.aspx

Como hemos visto anteriormente, Azure AD soporta varios de los protocolos de autenticación y autorización más ampliamente utilizados a través de un STS. En un pasado reciente, este STS fue implementado por una combinación de dos STS:
1. El servicio de inicio de sesión login.microsoftonline.com.
2. Y login.windows.net, que era la fachada de facto para aplicaciones empresariales modernas.

En esta configuración de servicio anterior, el servicio de inicio de sesión login.microsoftonline.com era (y sigue siendo hoy) el encargado de gestionar el paso de autenticación del usuario, es decir, nombre de usuario / contraseña, con una segunda forma opcional de autenticación (por ejemplo, un teléfono móvil , Una llamada telefónica automatizada o un mensaje de mensaje de texto) a través del soporte nativo de Azure Multi-Factor Authentication en Azure AD- y login.windows.net los pasos de generación de políticas y reivindicaciones para la aplicación moderna. La autenticación de la aplicación se trataba así directamente por login.windows.net. Login.windows.net actuaba como un proveedor de federación, que confiaba en una única autoridad: el servicio de inicio de sesión login.microsoftonline.com.

A partir de hoy, todas las solicitudes de autenticación ahora pueden ser servidas directamente por el login.microsoftonline.com STS de extremo a extremo. Si bien la mayoría de las veces se aplica completamente a una aplicación existente, si la aplicación hace ciertas suposiciones sobre nuestra implementación subyacente, puede requerir cambios. Esta evolución ofrece varios beneficios:

• Los usuarios disfrutan de una experiencia de inicio de sesión más rápida, sin saltos adicionales.

• La experiencia de usuario de inicio de sesión incluye varias características nuevas, por ejemplo, la capacidad de mantener múltiples usuarios activamente conectados y una interfaz de usuario más receptiva que se comporta adecuadamente en más dispositivos y pantallas.

• Desde una perspectiva de ingeniería, esto también conduce a un servicio aún más fiable gracias a una serie de características que esto permite en la implementación subyacente del STS.

Login.microsoftonline.com es autoritario para organizaciones y principios de seguridad. La información de pertenencia a grupos puede incluirse en los testigos de seguridad que reducen la fricción cuando una aplicación / servicio está realizando una autorización.

Espero que les sea de interes y utilidad. Saludos. Roberto Di Lello