![](\"http:\/\/www.radians.com.ar\/Articulos\/Images2017\/d31146738d70_10F94\/z33.png\")
Hola, hoy vamos a seguir hablando sobre Azure Active Directory, su anatomia y sus protocolos. <\/p>\nHola, hoy vamos a seguir hablando sobre Azure Active Directory, su anatomia y sus protocolos. <\/p>\n
Como la mayor\u00eda de la gente sabe, el bosque en WSAD representa el l\u00edmite 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\u00f3gicamente independiente de otros directorios que administre. No existe una relaci\u00f3n padre-hijo entre directorios.<\/p>\n
Esta independencia entre directorios incluye:
\u2022 Independencia de recursos. Si creamos o eliminamos un recurso en un directorio, no tiene ning\u00fan impacto en ning\u00fan recurso de otro directorio, con la excepci\u00f3n parcial de los usuarios externos. Adem\u00e1s, si utilizamos un dominio verificado personalizado "fabrikam.com" con un directorio, no puede utilizarse con ning\u00fan otro directorio.<\/p>\n
\u2022 Independencia administrativa. Si, por ejemplo, agregamos o eliminamos una funci\u00f3n de administrador de un directorio, esto no afecta a los privilegios de administraci\u00f3n de ning\u00fan otro directorio.<\/p>\n
\u2022 Independencia de la sincronizaci\u00f3n. Podemos configurar cada directorio independientemente para extender su infraestructura de identidad local con este directorio y obtener datos sincronizados.<\/p>\n
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.<\/p>\n
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\u00f3n de tareas administrativas y creaci\u00f3n de pol\u00edticas en una gran organizaci\u00f3n. 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.<\/p>\n
Las unidades administrativas (actualmente en vista preliminar p\u00fablica a partir de esta escritura) son una caracter\u00edstica de la edici\u00f3n Azure AD Premium. Por el momento, podemos crear y administrarlos a trav\u00e9s de cmdlets dedicados de Windows PowerShell. Azure AD permite a los administradores administrar la informaci\u00f3n en \u00e9l a trav\u00e9s de:<\/p>\n
\u2022 El uso de la interfaz gr\u00e1fica de usuario gracias al portal de gesti\u00f3n de Azure u otros portales.<\/p>\n
\u2022 Un conjunto de cmdlets de Windows PowerShell, que permite realizar scripts de operaciones frecuentes: el M\u00f3dulo Active Directory de Azure para Windows PowerShell.<\/p>\n
\u2022 Herramientas de administraci\u00f3n in situ que se utilizan para administrar la informaci\u00f3n en un directorio local y luego se sincronizan en Azure AD con la sincronizaci\u00f3n de directorios.<\/p>\n
Como se mencion\u00f3 anteriormente, Azure AD proporciona soporte para autenticaci\u00f3n (federada), inicio de sesi\u00f3n \u00fanico y autorizaci\u00f3n. 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\u00ed 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.<\/p>\n
El modelo de seguridad b\u00e1sico consta de dominios de inquilino. Existe un mapeo 1: 1 entre un dominio de inquilino de STS y un inquilino de directorio. La noci\u00f3n 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 \u00fanico, inmutable, globalmente \u00fanico y renombrado, y uno o m\u00e1s nombres de nombres DNS verificados que act\u00faan 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.<\/p>\n
Los directores tienen uno o m\u00e1s nombres (como nombre principal de usuario para un usuario o varios nombres principales de servicio para una aplicaci\u00f3n) y un identificador de seguridad, que es globalmente \u00fanico, inmutable y no reutilizable.<\/p>\n
Los directores pueden tener una o m\u00e1s credenciales (como contrase\u00f1a, 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\u00f3n en el local). Un director que tiene este tipo de configuraci\u00f3n de asignaci\u00f3n tambi\u00e9n 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).<\/p>\n
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\u00e1n empaquetadas en fichas de seguridad y est\u00e1n firmadas por el STS. Los testigos de seguridad consisten en una colecci\u00f3n de reclamaciones, que son declaraciones hechas sobre los usuarios, por ejemplo, nombre, id, correo electr\u00f3nico, grupo, rol, etc., utilizados para fines de autenticaci\u00f3n y decisi\u00f3n de autorizaci\u00f3n. Los testigos de seguridad normalmente siguen un m\u00e9todo seguro y estandarizado de empaquetar los reclamos para el transporte.<\/p>\n
Los Tenant realms pueden configurar la federaci\u00f3n con otros dominios, es decir, con una infraestructura de identidad local existente, tal como un entorno corporativo de Active Directory.<\/p>\n
Los mecanismos de autenticaci\u00f3n 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\u00e1quinas virtuales debajo no son dominio-se unieron en todos.<\/p>\n
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.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Sin embargo, esto deber\u00eda verse m\u00e1s espec\u00edficamente como rutas de "migraci\u00f3n" de IaaS que la situaci\u00f3n general para las cargas de trabajo en la nube. Lo es a\u00fan m\u00e1s con la movilidad y la tendencia "Bring Your Own Device" (BYOD), donde los usuarios tambi\u00e9n se considerar\u00e1n a menudo fuera del per\u00edmetro de la infraestructura de la organizaci\u00f3n. Adem\u00e1s, las soluciones de nube pueden por naturaleza abarcar m\u00faltiples \u00e1mbitos de seguridad.<\/p>\n
En consecuencia, los protocolos de federaci\u00f3n de identidad de Internet constituyen una forma mucho m\u00e1s escalable y eficiente de implementar la autenticaci\u00f3n en dicho contexto. Adem\u00e1s, los protocolos de federaci\u00f3n de identidad de Internet tambi\u00e9n pueden responder de manera relevante a otras preocupaciones como el inicio de sesi\u00f3n \u00fanico entre las aplicaciones en la nube que residen en el mismo de diferentes nubes, as\u00ed como la emisi\u00f3n de reclamaciones con la capacidad de procesamiento y transformaci\u00f3n de los tokens de seguridad en t\u00e9rminos de tipo de confianza, Formato de token, sem\u00e1ntica y (valores de) reclamaciones para "adaptaci\u00f3n de impedancia".<\/p>\n
Azure AD opta por tales protocolos para la integraci\u00f3n de aplicaciones y, adem\u00e1s, sistem\u00e1ticamente apunta a ser est\u00e1ndares 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<\/a> <\/p>\n Como hemos visto anteriormente, Azure AD soporta varios de los protocolos de autenticaci\u00f3n y autorizaci\u00f3n m\u00e1s ampliamente utilizados a trav\u00e9s de un STS. En un pasado reciente, este STS fue implementado por una combinaci\u00f3n de dos STS:
1. El servicio de inicio de sesi\u00f3n login.microsoftonline.com.
2. Y login.windows.net, que era la fachada de facto para aplicaciones empresariales modernas.<\/p>\n
![\"www.radians.com.ar\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2017\/a4e6f1b84ab8_EB74\/aa1_thumb.png\" "\\"www.radians.com.ar\\"")
<\/a><\/p>\n