Home
About
Archives
Contactenos
Ayuda | Help

28  03 2017

Azure Active Directory: Sincronizacion de nuestro directorio con los directorios locales

azureADEn el mes de Azure Active Directory vamos a seguir hablando del tema, y hoy vamos a hablar de la sincronizacion de nuestro directorio con los directorios locales, y como se hace. Dicho esto comenzamos:

Si nuestra organización utiliza un servicio de directorio local, podemos sincronizarlo con nuestro Azure AD para simplificar las tareas administrativas basadas en la nube e incluso proporcionarle a nuestros usuarios una mejor experiencia de inicio de sesión.

En términos generales, el aprovisionamiento de identidad y la sincronización es un espacio complejo. Esto ha generado en el pasado una cierta carga para que las organizaciones mantengan en sincronización todos sus silos de las identidades que resultan del deployment de varias soluciones de la línea de negocio (LOB).

La sincronización de directorios es la primera capacidad de integración que ofrece Azure AD con nuestras instalaciones. Como una oferta de IdMaaS, Azure AD proporciona, como cualquiera puede imaginar, muchas opciones, para soportar configuraciones de clientes -desde las más sencillas hasta las más complejas-. Azure AD habilita de hecho el soporte de ambientes mono y multi-forest de Windows Server Active Directory (WSAD) on-premises, así como entornos de directorios que no son de Active Directory. Por lo tanto, disponemos de múltiples opciones técnicas para acomodar mejor los entornos locales existentes y para mantener adecuadamente el posterior aprovisionamiento y sincronización de identidad:

  • Herramienta de sincronización de directorios (DirSync)
  • Herramienta Azure de sincronización de Active Directory (Azure AD Sync)
  • Motor de sincronización de Microsoft Forefront Identity Manager (FIM) (hotfix 4.1.3493.0 o posterior) con el Azure AD Connector (obsoleto)
  • Módulo Azure Active Directory para Windows PowerShell (consulte anteriormente en este documento)
  • API de gráfico de Azure AD

El Azure Active Connect Connect (Azure AD Connect), nos proporciona un asistente único y unificado que agiliza y automatiza el proceso de integración global para la sincronización de directorios con entornos locales mono-forestal y multi-forestal de AD (incluida la contraseña Hash)) y el inicio de sesión único si lo deseamos.

az1

El aprovisionamiento de directorios se refiere a la creación y gestión de entradas de directorio. En el contexto de Azure AD, el aprovisionamiento de directorios es diferente de la sincronización de directorios, ya que los objetos que se aprovisionan se dominan en el AD de Azure y se pueden editar en línea. El aprovisionamiento de directorios puede realizarse a través de las interfaces de administración o programación de Azure AD, como el portal de administración de Azure, la carga masiva mediante archivos .csv, los cmdlets Azure AD Module para Windows PowerShell o Azure AD Graph API.

Aunque se puede implementar alguna forma de sincronización de directorios utilizando estas interfaces, esto sigue siendo diferente de la sincronización de directorio de Azure AD donde los objetos se dominan localmente y el objeto en línea es una copia del objeto local y no se puede editar en línea.

Sincronizar nuestro directorio con Active Directory on-premises

Herramienta DirSync
Es la forma mas sencilla de hacerlo, Azure AD (y Office 365) llegaron inicialmente con un motor de sincronización de identidad pre-empaquetado llamado DirSync, basado en el producto FIM y personalizado para un único escenario que permite la sincronización con un directorio activo Entorno mono-forestal: era y puede ser utilizado para replicar cuentas de usuario WSAD (y otros objetos de Active Directory).

A diferencia de las cuentas creadas manualmente, las cuentas creadas por la herramienta DirSync se llenan completamente con información de cuentas de usuario de Active Directory. Esto permite a los administradores de servicio mantener actualizados los objetos AD de Azure con los cambios realizados en el WSAD local.

Además, a partir de la versión 1.0.6385.0012 de DirSync, se puede proporcionar una sincronización de contraseña (hash of hash). La sincronización de directorios no es algo nuevo para Azure AD. La herramienta DirSync está construida sobre la FIM. La configuración de la sincronización de directorios se ha simplificado para el entorno Azure AD. No hay ninguna configuración manual que tengamos que realizar, todo se hace mediante asistentes y son todos bastante simples.

Algunos clientes pueden tener en este contexto un requisito para determinar qué objetos se sincronizan desde el Active Directory local a Azure AD directory, como ser:

  • La capacidad de excluir un dominio de Active Directory del ámbito,
  • La capacidad de excluir una unidad organizativa (OU) del ámbito de aplicación,
  • La capacidad de excluir objetos específicos del ámbito, basados ​​en el filtrado a nivel de atributo.

El scope de sincronización de directorios través de la herramienta DirSync en los siguientes niveles:

  • Dominio. para administrar las propiedades del agente de administración de AD de origen (conector) en la herramienta DirSync. Este tipo nos permite seleccionar qué dominios pueden sincronizarse con la nube.
  • Unidad de organización: para administrar las propiedades del agente de administración de AD de origen (conector) en la herramienta DirSync. Este tipo de filtrado nos permite seleccionar qué OUs pueden sincronizar con la nube.
  • Atributos de Usuario: para especificar filtros basados ​​en atributos para objetos de usuario (y sólo para objetos de usuario). Esto nos permite controlar qué objetos no deben sincronizarse con la nube.

Mañana estaremos viendo como utilizar la herramienta:  Azure AD Connect tool.

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


27  03 2017

Resumen Semanal!

calendario2017Buenos días, estoy publicando el resumen de las notas de la semana pasada. Para aquellos que no entran diariamente; el calendario semanal seria, los días lunes un resumen de la semana y los viernes un laboratorio o nota de mayor interés.

Quería contarles que estoy subiendo videos de los ScreenCast en YouTube en el canal del blog, hay muchos sobre Windows Server 10 TP, Windows 10 TP, Windows Server 2012 R2 y sobre Windows 8.1. Les paso el link para que los vean; he tenido varios problemas con la cuenta vieja ya que como era una cuenta youtube no se podía linkear al nuevo formato desde que fue adquirida por google; funciono bastante bien durante un tiempo pero últimamente traía muchos problemas por lo que fue migrada a :

http://www.youtube.com/user/radilello
https://www.youtube.com/channel/UCdOZP-ULQ19HnKlVr9jqWMQ

Como siempre estaré contestando todos y cada uno de ellos! GRACIAS por la paciencia. Esta semana estaré retornando a escribir la nota importante los viernes, ya que en el ultimo tiempo estuve muy, muy complicado. Gracias por todo!

Saludos, Roberto Di Lello.

Resumen Semanal


24  03 2017

Azure Active Directory: Administrando los dominios de Internet

azureADHoy vamos a ver como administrar nuestros dominios de Internet en nuestro Azure Active Directory.

Después de inscribirse en Azure AD (o para un servicio de Microsoft como Office 365, Dynamics CRM Online y otros), el único dominio asociado con nuestra cuenta de suscripción y creado con el directorio tennant, es el dominio .onmicrosoft.com elegido durante el registro, por ejemplo corpfabrikam.onmicrosoft.com.

Este es el dominio predeterminado. Cuando creamos un nuevo usuario, el nombre de inicio de sesión y la dirección de correo electrónico del usuario se asignan a este dominio predeterminado.

Por supuesto, podemos agregar uno o más dominios de Internet a un directorio en lugar de conservar el dominio onmicrosoft.com y, a continuación, asignar a los usuarios iniciar sesión con cualquiera de los dominios validados.

Podemos registrar varios nombres de dominio de Internet para un directorio, por ejemplo fabrikam.com, además del dominio predeterminado inicial, por ejemplo, corpfabrikam.onmicrosoft.com. Un directorio nos permite registrar un dominio de Internet sólo después de demostrar que nuestra organización es propietaria del espacio de nombres DNS en el DNS de Internet pública. A partir de esta escritura, podemos alojar hasta 600 dominios de Internet registrados en su directorio, cada uno representado por un espacio de nombres DNS diferente.

Un dominio puede ser un dominio de nube (estándar) o un dominio federado (de inicio de sesión único), lo que significa que todos los usuarios de un dominio DEBEN utilizar el mismo sistema de identidad: la identidad de la nube o la identidad federada como se ha cubierto anteriormente.

Por ejemplo, podriamos tener un grupo de usuarios que sólo necesita una identidad de la nube porque no tiene una cuenta en el establecimiento y / o acceso a sistemas locales y otro grupo de usuarios que tiene una cuenta en el establecimiento y/o utilizar aplicaciones en la nube y sistemas locales. Se podría utilizar agregar dos dominios al directorio, como contractors.fabrikam.com y ftes.fabrikam.com, y sólo configuraría la federación para uno de ellos.

Un dominio se puede convertir de nube a federado para sostener identidades federadas en lugar de identidades de nube o de federado a nube.

Para registrar un dominio de Internet, debemos seguir los siguientes pasos:

1. Abrimos una sesión de navegación, vamos al portal de administración de Azure y accedemos como administrador del directorio para configurarlo.

2. Hacemos clic en ACTIVE DIRECTORY y, a continuación, hacemos clic en el nombre del directorio de la organización para el que se debe agregar un dominio de Internet.

qw1

3. Hacemos clic en ADD A CUSTOM DOMAIN si no se ha agregado ningún dominio de Internet hasta ahora o ADD en la parte inferior y aparecerá un cuadro de dialogo ADD DOMAIN.

qw2

4. En la página Specify a domain name, escribimos el nombre de dominio que deseamos agregar. I plan to configure this domain for single sign-on with my local Active Directory debe estar activado para preparar la configuración como un dominio de Internet federado. Por el momento, no marquemos esta opción.

5. Hacemos clic en añadir.

qw3

6. Hacemos clic en el icono de flecha en la parte inferior derecha.

qw4

8. Una vez que se haya agregado el registro TXT a su registrador de dominio DNS, hacemos clic en Verificar para completar el registro.

9. Si el dominio se ha verificado correctamente, hacemos clic en la marca de verificación situada en la parte inferior derecha para cerrar el cuadro de diálogo.

Como ilustración de los cmdlets de módulo de Azure AD mencionados anteriormente, veamos cómo agregar y verificar un dominio de Internet personalizado con Windows PowerShell.

Al igual que para los pasos anteriores 4 a 6, el cmdlet New-MsolDomain nos permite agregar un dominio de Internet estándar (en la nube). Después de ejecutar este comando, debe probar que su organización posee el espacio de nombres DNS en el DNS de Internet pública.

Para ello, y para verificar el nombre de dominio DNS, debemos utilizar el cmdlet Get-MsolDomainVerificationDns para obtener la información de registro DNS necesaria para crear el nuevo dominio de nube.

Una vez que se agrega el registro TXT dado en su registro de dominio DNS, finalmente debemos probar nuestro control del espacio de nombres DNS ejecutando el cmdlet Confirm-MsolDomain.

Del mismo modo, puede utilizar el cmdlet New-MsolFederatedDomain para crear el dominio personalizado federado (inicio de sesión único) en su directorio. Por último, el cmdlet Set-MsolDomainAuthentication permite convertir un dominio estándar en un solo signo en el dominio.

Cuando un dominio está federado, ya no tendremos la opción de agregar el sufijo de dominio a las cuentas de usuario. Los usuarios tendrán que ser creados en las instalaciones para que tengan el nombre de dominio federado disponible para ellos. Todavía podemos crear cuentas directamente en la nube, pero no podemos asignarle el nombre de dominio federado a menos que se creen en el local. Recordemos el escenario de integración de directorios Sincronización de directorios con inicio de sesión único que hablamos anteriormente.

Además, y como era de esperar, cuando el usuario inicia sesión en Azure AD con su cuenta federada, se le invita a autenticarse en la infraestructura de identidad local. Si el inicio de sesión único está configurado correctamente, de hecho notará que el usuario ni siquiera puede escribir una contraseña en la página web de inicio de sesión del servicio de inicio de sesión de Azure AD. La contraseña estará realmente sombreada. El usuario será redireccionado al proveedor de identidad local declarado.

Espero que les sea de interés y utilidad. Saludos, Roberto Di Lello.


23  03 2017

Azure Active Directory: Administrando la configuración del directorio

azureADAzure AD nos permite comenzar a usar las características IdMaaS sin nada on-premise. En consecuencia, Azure AD proporciona identidades alojadas (en la nube) en las que los clientes pueden crear usuarios, grupos y otros directores para su organización. Las identidades de nube se dominan directamente en un inquilino de directorio de Azure AD.

Con las identidades de nube, los usuarios reciben, por firmar en Azure AD y cualquier aplicación basada en la nube que esté integrada en Azure AD, las credenciales de nube (que están separadas de otras credenciales de escritorio o corporativas, si las hubiera).

De esta manera, muchos clientes empresariales desean extender su infraestructura de identidad local para sincronizar perfectamente las identidades locales existentes con la nube y así establecer una plataforma de identidad corporativa híbrida. Este enfoque (también soportado por Azure AD) es más sofisticado.

Ampliación de su infraestructura de identidad local con Azure

Si nuestra organización utiliza una infraestructura de identidad local (basada en AD o en otros directorios basados ​​en LDAP), Azure AD nos permite ampliarlo para simplificar nuestras tareas administrativas basadas en la nube e incluso proporcionar a nuestros usuarios un proceso de sign-in más simplificado.

Azure AD soporta los siguientes tres escenarios de integración de directorios:

1. Sincronización de directorios. Este escenario permite sincronizar objetos de directorio locales (usuarios, grupos, contactos, etc.) con la nube para ayudar a reducir la sobrecarga administrativa. Una vez configurada la sincronización de directorios, los administradores podemos administrar objetos de directorio desde la infraestructura de identidad local de nuestra organización y esos cambios se sincronizarán con el directorio relacionado.

2. Sincronización de directorios con sincronización de contraseñas. Este escenario se utiliza cuando deseamos habilitar a nuestros usuarios para iniciar sesión en Azure AD y otras aplicaciones basadas en la nube utilizando el mismo nombre de usuario y la misma contraseña que utilizan para iniciar sesión en su red corporativa local. Este escenario está disponible para entornos Active Directory on-premises mono-forest o multi-forest.

Dicha capacidad proporciona una experiencia de "inicio de sesión único", en la que los usuarios se conectan a su máquina corporativa y Azure AD / Office 365 con las mismas credenciales.

Con la capacidad de sincronización de contraseñas, este escenario de integración proporciona una experiencia de usuario de inicio de sesión sin interrupciones al tiempo que requiere una inversión mínima desde una perspectiva administrativa. Con tal compensación, constituye la opción preferida para la mayoría de las organizaciones que esperan una experiencia de inicio de sesión perfecta.

3. Sincronización de directorios con inicio de sesión único. Este escenario permite proporcionar a los usuarios la experiencia de autenticación más transparente a medida que acceden a los servicios en la nube de Microsoft y/o a otras aplicaciones SaaS basadas en la nube mientras están conectados a la red corporativa.

La identidad del usuario se domina localmente en la infraestructura de identidad y se sincroniza con el AD de Azure en forma de una identidad federada.

Para configurar el inicio de sesión único, las organizaciones deben implementar Servicios de federación de Active Directory (AD FS) en sitio u otros servicios de token de seguridad de terceros (STS) para federar entre los directorios locales y en la nube. Una vez que se ha configurado un STS compatible, los usuarios pueden utilizar sus credenciales corporativas locales (nombre de usuario y contraseña y / o cualquier factor de autenticación adicional) para acceder a los servicios de la nube ya sus recursos existentes en las instalaciones.

aa1

aa2

Espero les sea de interes. Saludos. Roberto Di Lello


21  03 2017

Azure Active Directory: utilizando un directorio existente

azureAD_thumb[1]Hoy vamos a seguir hablando de Active Directory en la nueve, y como hacemos para eliminar un directorio especifico en Azure AD.

Cualquier directorio que ya no se utilice puede eliminarse con la garantía de que no eliminará accidentalmente un directorio que controla el acceso a recursos importantes o se basa en suscripciones.

Para eliminar un directorio existente, debemos seguir los siguientes pasos:

1. Abrimos una sesión de navegación, y vamos al portal de administración de Azure y accedemos con las credenciales de nuestra cuenta de Microsoft.

2. En el portal de administración, hacemos clic en ACTIVE DIRECTORY, seleccionamos el directorio que deseamos eliminar y, a continuación, hacemos clic en DELETE. Aparecerá un cuadro de diálogo con el mensaje Delete directory.

q1_thumb[1]

Para proteger y evitar que elimine accidentalmente un directorio importante, Azure AD requiere que solo haya un usuario en el directorio, que no haya aplicaciones en el directorio, que no haya suscripciones a Azure, Office 365 u otros servicios de Microsoft Online para organizaciones que dependen de ESTE directorio, etc.

q2_thumb[1]

3. Marcamos la casilla de verificación para confirmar que deseamos eliminar ese directorio y, a continuación, hacemos clic en el icono de marca de verificación situado en la parte inferior derecha del cuadro de diálogo.

Espero les sea de interes. Saludos. Roberto Di Lello


20  03 2017

Azure Active Directory: utilizando un directorio existente

azureADHoy vamos a seguir hablando de Active Directory en la nueve, y como hacemos para utilizar un directorio ya existente. Si accedemos al portal de administración de Azure con una cuenta de Microsoft, podemos configurar nuestra cuenta de Microsoft para administrar un Active Directory existente de Azure que se utilice para Office 365 u otro servicio, incluso si nuestra cuenta de Microsoft ya administra un inquilino de directorio de Azure AD.

Para configurar una cuenta de Microsoft para administrar un directorio existente, debemos hacer los pasos siguientes:

1. Abrimos una sesión de navegación, navegamos hasta el portal de administración clásico de Azure e iniciamos sesión con las credenciales de nuestra cuenta de Microsoft.

2. En el portal de gestión, hacemos clic en NEW en la bandeja de la parte inferior y, a continuación, seleccionamos APP SERVICES, ACTIVE DIRECTORY, DIRECTORY y luego CUSTOM CREATE. Aparecerá un cuadro de diálogo que dice Add Directory.

a1

3. En el cuadro de diálogo Add Directory, cambiamos la lista desplegable DIRECTORY desde la opción predeterminada Create new directory a Use existing directory.

4. Hacemos clic en I am ready to be signed out now.

a2

6. Hacemos clic en el icono de marca de verificación situado en la parte inferior derecha del cuadro de diálogo para continuar.

7. Al salir, veremos la pantalla de inicio de Azure AD. Ingresamos nuestro nombre de usuario y contraseña para la cuenta de administrador global en el inquilino del directorio AD de Azure que deseamos administrar usando nuestra cuenta de Microsoft.

8. Una vez que hayamos iniciado sesión, veremos el diálogo a continuación.
a3

Hacemos clic en continuar para agregar nuestra cuenta de Microsoft como administrador global del directorio existente.

9. Una vez que se haya completado, hacemos clic en el enlace para salir de nuestra cuenta de organización. A continuación, podemos iniciar sesión en el portal de administración de Azure con nuestro usuario de cuenta de Microsoft y podemos administrar el directorio al que agregamos la cuenta de Microsoft. Podemos administrar este inquilino de directorio como otros directorios para los que somos administradores globales.

Espero les sea de interes. Saludos. Roberto Di Lello


17  03 2017

Nacimiento de Tobias

Hola queria compartir con ustedes la noticia y el motivo por el cual no he actualizado el blog en los ultimos dias.

Ha nacido mi hijo Tobias, gracias a Dios se encuentra bien, sin inconvenientes. Tanto el como la mama.

Saludos y gracias a todos, ya estare normalizando las publicaciones. Roberto Di Lello

WP_20170316_07_40_42_Pro


03 2017

Por que amar Windows Server 2016: Active Directory e Identity

Este es el segundo post en la serie de videos "Diez Razones para Amar a Windows Server 2016" de Matt McSpirit, Evangelista Técnico de Microsoft.
Hoy nos presenta a Samuel Devasahayam, Gerente de Programa del Grupo Principal en el equipo de Microsoft Identity.

La identidad es el nuevo plano de control para asegurar el acceso a los recursos locales y de nube. Centraliza su capacidad de controlar los privilegios de usuario y administrativos, ambos muy importantes cuando se trata de proteger sus datos y aplicaciones de ataques maliciosos. Al mismo tiempo, nuestros usuarios son más móviles que nunca y necesitan acceso a recursos informáticos desde cualquier lugar.

Si utiliza Active Directory hoy, querrá escuchar a Samuel hablar sobre las nuevas características que vienen en Windows Server 2016.

 

Windows Server 2016 agrega nuevas funciones que le ayudarán a:

  • Establecer nuevos controles para la gestión de acceso privilegiado
  • Algunas organizaciones tienen literalmente cientos de administradores, lo que representa una gran vulnerabilidad y superficie de ataque. Tus administradores tienen las llaves del reino. Pero, ¿necesitan todas las claves, o deberían limitarse a la clave de un área o aplicación particular, o durante un período de tiempo – conocido como administración "justo a tiempo"?
  • Los clientes también tienen la opción de tener un bosque de administración independiente basado en Windows Server 2016 y proyectar las pertenencias de administradores a bosques existentes. Esto ayuda a reducir el impacto en la infraestructura y las aplicaciones existentes
    Establecer nuevos controles para aplicaciones sensibles
    No todas las aplicaciones son iguales. Ahora puede establecer un control más estricto sobre el acceso de los usuarios o dispositivos a las aplicaciones sensibles que contienen datos personales de los clientes o empleados
    La autenticación multi-factor proporciona una segunda capa de seguridad que ayuda a proteger el acceso a datos y aplicaciones
    Proporcionar acceso de usuario seguro a los recursos corporativos, tanto locales como en la nube
    Capacidad de autenticación contra Azure AD Join
    Active Directory admite la autenticación mediante métodos modernos y más seguros, como Microsoft Passport y Windows Hello
    Eliminar la necesidad de exponer credenciales de contraseña a Internet
    Habilitar control de seguridad y acceso para aplicaciones móviles y servicios RESTful
    Posibilidad de autenticar y autorizar el acceso a aplicaciones con OAuth & OpenID Connect
    Proporcionar un mayor acceso de los usuarios empresariales a los recursos corporativos, tanto en el local como en la nube
    Posibilidad de autenticar usuarios en cualquier directorio compatible con LDAP v3 incluyendo directorios virtuales

Espero les sea de interes. Saludos. Roberto Di Lello


20  02 2017

Resumen Semanal!

Buenos días, estoy publicando el resumen de las notas de la semana pasada. Para aquellos que no entran diariamente; el calendario semanal seria, los días lunes un resumen de la semana y los viernes un laboratorio o nota de mayor interés.

Quería contarles que estoy subiendo videos de los ScreenCast en YouTube en el canal del blog, hay muchos sobre Windows Server 10 TP, Windows 10 TP, Windows Server 2012 R2 y sobre Windows 8.1. Les paso el link para que los vean; he tenido varios problemas con la cuenta vieja ya que como era una cuenta youtube no se podía linkear al nuevo formato desde que fue adquirida por google; funciono bastante bien durante un tiempo pero últimamente traía muchos problemas por lo que fue migrada a :

http://www.youtube.com/user/radilello
https://www.youtube.com/channel/UCdOZP-ULQ19HnKlVr9jqWMQ

Como siempre estaré contestando todos y cada uno de ellos! GRACIAS por la paciencia. Esta semana estaré retornando a escribir la nota importante los viernes, ya que en el ultimo tiempo estuve muy, muy complicado. Gracias por todo!

Saludos, Roberto Di Lello.

Resumen Semanal


17  02 2017

Creando Multiples Directorios en Azure AD

Tal como venimos hablando de Azure AD, hoy vamos a ver como crear múltiples directorios en Azure AD. Como servicio de IdMaaS, Azure AD nos permite crear varios directorios que podemos utilizar para realizar pruebas u otro uso no relacionado con nuestro ambiente de producción, o para gestionar datos sincronizados desde varios directorios de identidad locales, etc. El portal de gestión clásica de Azure nos permite añadir Directorios y gestionar los ya existentes. A continuación, podemos administrar todos nuestros directorios desde el portal: https://manage.windowsazure.com

www.radians.com.ar © 2017

Estos directorios son recursos totalmente independientes. En otras palabras, como se hemos dicho antes, cada directorio es un peer, con todas las funciones y lógicamente independiente de otros directorios que administremos. No existe una relación padre-hijo entre directorios.

Para agregar un directorio, demos realizar los pasos siguientes:
1. Abrimos el portal de gestión de Azure en https://manage.windowsazure.com
2. Iniciamos sesión en el portal de administración de Azure con las credenciales de nuestra cuenta de Microsoft.
3. En el portal de gestión, hacemos clic en NEW en la bandeja de la parte inferior y, a continuación, seleccionamos APP SERVICES, ACTIVE DIRECTORY, DIRECTORY, y luego CUSTOM CREATE. Aparecerá un cuadro de diálogo Add Directory.

www.radians.com.ar © 2017

4. En el cuadro de diálogo Add directory , configuramos las propiedades básicas de nuestro nuevo directorio, es decir, su nombre, nombre de dominio predeterminado y el país o región de la siguiente manera:
a. En Nombre, escribimos un nombre para el directorio que nos ayudará a distinguirlo de nuestros otros directorios en nuestra suscripción de Azure, por ejemplo "Fabrikam Corporation".
b.. En Nombre de dominio, escribimos un nombre de dominio predeterminado que puede utilizar para inicializar el uso de este directorio, por ejemplo "corpfabrikam.onmicrosoft.com".
c. En País o región, elejimos un país o una región para nuestro directorio. Esta configuración es utilizada por Azure AD para determinar la (s) región (es) del centro de datos para nuestro directorio. No se puede cambiar más tarde.
d. Dejemos sin tildar la opcion: This is a B2C directory.

5. A continuación, hacemos clic en el icono de marca de verificación en la parte inferior derecha del cuadro de diálogo y, en pocos segundos, veremos que nuestro nuevo directorio se ha creado y está disponible para usarse.

Nuestra cuenta de usuario se incluye en ese nuevo directorio y está asignada a la función de administrador global. Esto nos permite administrar el directorio que creó sin iniciar sesión como un usuario diferente de ese directorio. Como administrador de un directorio, también podemos agregar usuarios de otro directorio del que sea miembro. Esto es útil, por ejemplo, cuando hay usuarios en su directorio de producción que necesitarán colaborar en una aplicación que se está desarrollando o probando en un entorno que no sea de producción. Un usuario puede ser un miembro de hasta 20 directorios.

Espero les sea de interes y utilidad. Saludos. Roberto Di Lelloa


15  02 2017

Azure Active Directory [Teoria]–parte2-

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.

www.radians.com.ar

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


10  02 2017

Azure Active Directory [Teoria]

z33Hola, hoy vamos a seguir hablando sobre Azure Active Directory, principalmente vamos a hablar de tu anatomia, sus componentes core, sus token de seguridad y algunas caracteristicas extras.

En el nivel más simple, Azure AD es una infraestructura de directorio escalable que proporciona almacenamiento, acceso a datos, replicación y sincronización, registro de dispositivos y servicios de testigos de seguridad (STS). A continuación se muestra un diagrama conceptual que muestra las interfaces públicas y la superficie de gestión:

www.radians.com.ar

Core Directory Service

El servicio de directorio básico representa el corazón de Azure AD. Como servicio de directorio en la nube y con el objetivo de eliminar la necesidad de un almacén específico de aplicaciones para información de identidad, Azure AD tiene como objetivo apoyar – dentro de los inquilinos propiedad de la organización – datos de interés común en las aplicaciones de gran mayoría, Son aplicaciones de nube, SaaS, móviles, etc., así como las posibles relaciones entre esos datos.

Modelo y esquema de datos

Los usuarios y los grupos suelen ser buenos ejemplos en los que las organizaciones desean crearlos una sola vez y reutilizarlos en sus aplicaciones o en aquellos para los que compran una suscripción. La información del servicio de directorio principal debe tener generalmente las siguientes características:

• Público en el sentido de algo que es útil compartir en toda la organización, y no algo privado como el atributo de salario de un objeto de usuario,

• Sobre todo estática durante el tiempo, y no cambiada a menudo,

• Pequeño, generalmente punteros a la información contra la información sí mismo.

No es sorprendente que Azure AD siga el modelo de datos de WSAD con los cambios adecuados para el uso de la nube. El modelo de datos es el siguiente:

• El servicio de directorio principal se divide en contextos de directorio, uno o varios por inquilino más un contexto del sistema. Cada contexto de directorio tiene un identificador de valor GUID no modificable, único, no reutilizable, un identificador de contexto, y contiene un conjunto de entidades (o objetos) y asociaciones (o enlaces) entre las entidades. Cada objeto o enlace pertenece exactamente a un contexto.

• Cada objeto tiene una clase o tipo de objeto (ObjectType): TenantDetail, Usuario, Contacto, Grupo, Dispositivo, Application, ServicePrincipal, etc. y un identificador de valor GUID no reemplazable, globalmente único y no exclusivo, es decir, un ID de objeto (ObjectId ).

• Un objeto contiene un conjunto de propiedades: DisplayName, UserPrincipalName, JobTitle, Department, TelephoneNumber, etc. Cada propiedad tiene un nombre y, si se establece, contiene un valor o un conjunto de valores. La clase de objeto determina qué propiedades pueden aparecer en el objeto y la propiedad determina el tipo (cadena, binario, entero, estructura, etc.) y la multiplicidad de los valores.

• Un objeto puede contener un conjunto de propiedades de navegación que cada una corresponde a un enlace (o asociación). Un enlace es una relación direccional, mecanografiada de un objeto a otro objeto, todo en el mismo contexto. El tipo de enlace es su clase de enlace: Manager, DirectReports, MemberOf, Members, etc. Los enlaces contribuyen significativamente a establecer un gráfico social de empresa tal como se discute en el blog de John Shewchuk. Los vínculos mantienen la integridad referencial: al eliminar el objeto de origen o de destino de la relación se suprime implícitamente el vínculo.

• Las instancias de objeto (respectivamente enlace) pueden ser grupo en conjunto de

Nota Para obtener información adicional, consulte el artículo de Microsoft MSDN ENTITY REFERENCE.
El esquema de directorio de Azure AD define las propiedades, las clases de objeto y las clases de enlace; Gran parte de ella es un subconjunto de los esquemas estándar LDAP v3 (y WSAD).

Sin embargo, difiere de los directorios LDAP de las siguientes maneras:

• A diferencia de las entradas de un directorio LDAP, los objetos no tienen nombres distinguidos y no están dispuestos en una jerarquía multinivel distinguida. Los objetos pueden ser interpretados como teniendo varias relaciones jerárquicas basadas en enlaces y valores de propiedad.

• El directorio no admite la herencia de clase de objeto. En WSAD, esta capacidad se utilizó de manera muy limitada, pero añadió una complejidad significativa al sistema.

El esquema de directorio de Azure AD se define por versión específica. Puede evolucionar como fue el caso para el esquema del directorio de WSAD sobre el tiempo desde su primera introducción a principios de 2000. En general, las aplicaciones que consumen información de directorio -y que, por lo tanto, se instancian como un objeto Application en el directorio- tienden a caer en las tres clases siguientes con respecto a los requisitos de extensibilidad de directorio:

1. Una primera clase de aplicación que corresponde a la gran mayoría no necesita extender el directorio y no tiene requisitos de extensibilidad a la dirección.

2. Una segunda clase de aplicaciones tiene necesidades de extensibilidad muy simples donde necesitan publicar alguna información sobre una entidad de directorio, como un usuario, a otras aplicaciones. Hasta la fecha, un mecanismo de extensibilidad integrado aborda este tipo de requisitos de extensibilidad en el contexto específico e histórico de los servicios de Microsoft, como Office 365.

3. La clase final de aplicaciones es la que sin ninguna sorpresa que tiene necesidades de extensibilidad adicionales o extensas. Pueden mantener información importante sobre usuarios y otros objetos, y también pueden tener necesidades complejas de consulta basadas en propiedades y enlaces. Estas consultas pueden estar en la ruta principal de alto volumen de la aplicación.

El uso de un almacén local específico de la aplicación para la extensibilidad podría ser una opción en este caso. Con la llegada de la nube, las capacidades de almacenamiento están ampliamente disponibles a través de servicios como el almacenamiento Azure y la base de datos Azure SQL. Una aplicación que cae en este modelo puede mantener sus propias tablas en un servicio de almacenamiento. Un modelo típico podría ser que las filas de la tabla representen entidades de directorio Azure AD sobre las que la aplicación mantiene su información. Una de las columnas de la tabla sería una clave que identifica la entidad en el directorio (es decir, la clave de combinación). Las otras columnas representan información específica de la aplicación. La aplicación puede utilizar la capacidad de consulta diferencial soportada por el directorio para gestionar el ciclo de vida de las filas en sus tablas utilizando la clave de combinación.

Dicho esto, Azure AD proporciona capacidad de extensibilidad de esquema personalizado (actualmente en vista previa pública) en Azure AD Graph API que permite aumentar la entidad existente con atributos personalizados adicionales sin necesidad de un almacén de datos externo. Un ejemplo común puede consistir en almacenar un número de nómina para el usuario.

A partir de esta escritura, las entidades mencionadas de Usuario, Grupo, TenantDetail, Dispositivo, Aplicación y ServicePrincipal pueden ampliarse con atributos de un solo valor de tipo "String" o "Binario". Azure AD Graph API proporciona para ello fines interfaces REST para una aplicación para registrar, anular el registro, enumerar, leer, escribir y filtrar por propiedades de extensión. Las propiedades de extensión se registran en el objeto Aplicación que corresponde a la aplicación dentro del directorio. La aplicación debe tener acceso de escritura para registrar una propiedad de extensión. 100 propiedades de extensión (a través de TODOS los tipos y TODAS las aplicaciones) se pueden escribir en cualquier objeto individual.

Las aplicaciones multi-tenant que registran propiedades de extensión en el directorio son referenciadas de todos los inquilinos que consienten a esa aplicación. Una vez que un inquilino del cliente ha consentido a una aplicación (incluso para leer) las propiedades de la extensión registradas en esa aplicación están disponibles en el inquilino que consiente para leer / escribir por cualquier aplicación que tenga el acceso apropiado.

Para mas informacion pueden ver los siguientes documentos en el sitio de Microsoft: Extend Azure Active Directory Schema using Graph API (http://blogs.msdn.com/b/aadgraphteam/archive/2014/03/06/extend-azure-active-directory-schema-using-graph-api-preview.aspx) y tambien Extending the Azure Graph Using the Azure Graph Store (http://msdn.microsoft.com/en-us/library/azure/dn720459.aspx).

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


02 2017

Ediciones de Azure Active Directory {HowTo} Como probarlo?

Hoy vamos a seguir hablando de Azure Active Directory o Azure AD, empecemos por las distintas versiones. Actualmente tenemos disponible en tres ediciones diferentes para elegir:
1. Azure Active Directory (Libre). Con la edición gratuita de Azure AD, puede administrar cuentas de usuario, sincronizarse con directorios locales y obtener inicio de sesión único a través de Azure, Office 365 y miles de aplicaciones SaaS populares.

Nota Esta es una edición gratuita que se utiliza en las suscripciones anteriores de Microsoft Online Services. Si ya nos hemos suscrito a una suscripción de Office 365, podemos beneficiarnos de una suscripción de Azure $ 0 que podemos utilizar para acceder al portal de administración de Azure con nuestra suscripción existente de Office 365 con el fin de gestionar directamente el Azure AD tenant relacionado con Gestión de accesos y funciones de seguridad y así habilitar nuestra suscripción a Office 365. Por ejemplo, las mencionadas mejoras de acceso a aplicaciones para Azure AD sólo se pueden administrar hoy accediendo al directorio a través del portal de administración de Azure. Podemos registrarnos para esta suscripción de $ 0 en https://account.windowsazure.com/PremiumOffer/Index?offer=MS-AZR-0110P&whr=azure.com

Nota Independientemente de cualquier suscripción a Microsoft Online Services, podemos suscribirnos a nuestro Azure AD gratuito y probar la cuenta Azure en https://account.windowsazure.com/PremiumOffer/Index?offer=MS-AZR-0110P&whr=azure.com

www.radians.com.ar

2. Azure Active Directory Basic. Azure AD Basic proporciona los requisitos de acceso a la aplicación y gestión de identidades de autoservicio de los trabajadores con las primeras necesidades de la nube. Con la edición básica de Azure AD, obtiene todas las capacidades que Azure AD Free ofrece, además de la gestión de acceso basada en grupos, el restablecimiento de contraseña de autoservicio para aplicaciones en la nube, un entorno personalizable para el lanzamiento de aplicaciones cloud empresariales y de consumidores y una empresa De nivel de servicio de 99,9 por ciento de tiempo de actividad.

Un administrador con la edición básica de Azure AD puede activar una prueba de Azure AD Premium.

3. Azure Active Directory Premium. Con la edición Premium de Azure AD, obtiene todas las capacidades que Azure AD Free y Azure AD Basic tienen para ofrecer, además de capacidades adicionales de administración de identidades a nivel de empresa.

Para inscribirse hoy para las funciones Azure Active Directory Premium

Para probarlo debemos hacer lo siguiente:

  • Iniciamos sesión en el portal de administración clásico de Azure como administrador global del directorio que deseamos personalizar.
  • Hacemos clic en Active Directory y, a continuación, seleccionamos el directorio al que desea asignar licencias.
  • Seleccionamos Licenses

www.radians.com.ar

Hacemos clic en TRY AZURE ACTIVE DIRECTORY PREMIUM NOW

www.radians.com.ar

  • Hacemos clic en el icono activate the trial.

a4

  • Una vez activada, podemos empezar a asignar las licensias premium a nuestros usuarios

a5

  • Luego hacemos click en ASSIGN

www.radians.com.ar

7. En el cuadro de diálogo Asignar licencias para Azure Active Directory Premium, seleccionamos los usuarios a los que deseamos asignar licencias y, a continuación, hacemos clic en el icono de marca de verificación para guardar los cambios.

También podemos establecer el filtro de vista en grupo (todos los grupos) en SHOW y, a continuación, seleccionamos los grupos que desea asignar. Confirmamos la selección haciendo clic en el icono de marca de verificación para guardar los cambios.

La edición premium de azure AD proporciona un panel de control para el directorio, que es el único lugar para administrar todos nuestros servicios. También facilita el mantenimiento de las nuevas funciones y eventos.

www.radians.com.ar

El resto de esta sección describe las características principales de Azure AD (independientemente del "sabor", es decir, la edición) que las organizaciones y aplicaciones basadas en la nube podemos aprovechar, así como las funcionalidades básicas que Azure AD proporciona a los usuarios de estas aplicaciones Y para que los desarrolladores de estas aplicaciones tengan éxito.

En términos de escenarios clave, Azure AD puede:
• Ser un repositorio centralizado de "propiedad de la organización" para todas las identidades y aplicaciones alojadas en la nube.
• Proporcionar una consola completa para que el administrador pueda administrar las identidades, la sincronización con los servicios de directorio locales y asignar (o eliminar) el acceso a la aplicación.
• Supervisar y proteger el acceso a muchas aplicaciones utilizando funciones de seguridad incorporadas, como la autenticación de múltiples factores Azure (MFA) basada en la nube y los informes de seguridad y auditoría.
• Capacitar a los trabajadores de la información con auténtico inicio de sesión único para sus aplicaciones SaaS empresariales desde una única página web, es decir, el Panel de Acceso de Azure AD.

Pasado mañana hablaremos de la anatomia de Azure Active Directory, y seguiremos hablando sobre esta nueva funcionalidad. Saludos, Roberto Di Lello


25  01 2017

Azure Active Directory, que es?

Azure Active Directory (AD) es la opcion de Microsoft para proporcionar capacidades de IdMaaS en una nube pública. El acercamiento de Microsoft a IdMaaS está profundamente basado en los conceptos probados de Active Directory (AD) local.

Active Directory (AD) es una marca de Microsoft para capacidades relacionadas con la identidad. En el mundo local, Windows Server Active Directory (WSAD o simplemente AD) proporciona un conjunto de capacidades y servicios de identidad y es enormemente popular (88% de Fortune 1000 y 95% de empresas utilizan AD).

El concepto fundacional de AD local es que el contenido del directorio es propiedad de la organización que lo despliega y el acceso y uso de ese contenido está completamente bajo el control de la organización. Este es también el concepto fundamental detrás de Azure AD.

Azure AD no es un directorio monolítico de información perteneciente a Microsoft, sino más bien, en el momento de escribir, más de cuatro millones de directorios diferentes pertenecientes y completamente controlados por diferentes organizaciones.

Esta arquitectura y compromiso se llama "multi-tenant" y se ha prestado gran cuidado para aislar a los inquilinos (organizaciones) entre sí y de su operador de servicios – Microsoft. De hecho, se ha re-diseñado AD, para soportar la escala masiva, los dispositivos basados ​​en cualquier sistema operativo o arquitectura, aplicaciones de negocios modernos, protocolos modernos, alta disponibilidad y recuperación integrada de desastres.

Desde su introducción, Azure AD "ha manejado 400 mil millones de autenticaciones de identidad en Azure AD". "Tenemos 350 millones de usuarios Azure Active Directory. […] En realidad procesamos 4 mil millones, con una B, autenticaciones cada semana con Azure Active Directory". Este es un verdadero testimonio del nivel de escala que se puede manejar. "A un nivel alto, Azure AD es un servicio en nube de alta disponibilidad, georeferenciado, multiteniente y multinivel que ha proporcionado 99.99% de tiempo de actividad durante más de un año. Se ha ejecutado a través de 28 datacenters en todo el mundo. Azure AD tiene puertas de enlace sin estado, servidores front-end, servidores de aplicaciones y servidores de sincronización en todos esos centros de datos. Azure AD también tiene un nivel de datos distribuido que está en el corazón de nuestra estrategia de alta disponibilidad. Nuestro nivel de datos contiene más de 500 millones de objetos y se ejecuta en 13 centros de datos ".

www.radians.com.ar

Desde que hablamos por primera vez en noviembre de 2011, y con estos números arriba en mente, Azure AD ha demostrado ser un servicio robusto de gestión de identidad y acceso para los servicios en la nube de Microsoft. Ningún otro directorio en la nube ofrece este nivel de fiabilidad empresarial o escala comprobada. Citando el informe KUPPINGERCOLE LEADERSHIP COMPASS CLOUD USUARIO Y GESTIÓN DE ACCESO: "Al mirar el gráfico de Market Leadership, vemos a Microsoft como el líder claro. Esto se basa en el hecho de que Azure Active Directory por un lado muestra una buena aceptación directa y en la Otro construye la base para el ampliamente utilizado Microsoft Office 365. Además, Microsoft tiene un ecosistema de socios excepcionalmente fuerte ".

Además, el año pasado, Gartner en su Cuadrante Mágico (MQ) para Gestión de Identidad como Servicio (IDaaS) [Gartner, junio de 2015] ha puesto a Azure AD después de su único primer año de disponibilidad en el MQ "Visionaries".

A partir de este momento, Gartner acaba de lanzar su MQ para IDaaS para el 2016 [Gartner Junio ​​2016] y Azure AD Premium ha sido colocado en el cuadrante "Leaders", y se posicionó muy fuerte para nuestra completa visión.

Como dice Alex Simons, Director de Gestión de Programas de la División de Servicios de Identidad y Seguridad de Microsoft, "estamos encantados con el resultado. Realmente valida nuestra visión de proporcionar una solución completa para la identidad híbrida y el acceso para apoyar a los empleados, socios y clientes, todos respaldados por la seguridad de clase mundial basada en el gráfico de seguridad inteligente de Microsoft. Este resultado nos dice mucho sobre nuestro compromiso en el espacio de gestión de identidad y acceso, pero lo más importante sobre nuestros clientes, socios de implementación y socios ISV que han trabajado juntos con nosotros. Han sido impresionantes compartir su tiempo y energía todos los días, para asegurarse de que los productos y servicios que construimos satisfacer sus necesidades y les están ayudando a posicionar sus empresas para prosperar en el emergente mundo de la nube y los dispositivos.

Podría sorprenderse de saber que Microsoft también es el único proveedor en el cuadrante de Leader en los Cuadrantes Mágicos de Gartner para IDaaS, Cloud Infrastructure as a Service (IaaS), Virtualización de Servidores, Plataforma de Aplicación como Servicio, Cloud Storage Services y como líder A través de la plataforma de datos y servicios de productividad. Esto realmente le muestra por qué los clientes están eligiendo a Microsoft en todo el espectro de la computación en nube: nuestros servicios están bien integrados y también están entre los mejores disponibles en sus categorías individuales ".

Alex Simons añade: "nuestro esfuerzo no se detiene aquí. Tenemos mucho trabajo por delante y estamos planeando ofrecer capacidades más innovadoras para mejorar aún más nuestra posición en el cuadrante de "líderes".

Dicho esto, un número de personas (todavía) se sorprendió al descubrir que cada cliente de Office 365 ya tiene un directorio de Azure AD. Azure AD es el directorio detrás de las suscripciones de Microsoft Online Services como Office 365, Dynamics CRM Online, Intune, etc. y se utiliza para almacenar identidades de usuario y otras propiedades de inquilino. Al igual que el AD local, almacena la información de Exchange, SharePoint, Lync y sus aplicaciones LOB personalizadas, Azure AD almacena la información para Exchange Online, SharePoint Online, Lync Online y cualquier aplicación personalizada creada en la nube de Microsoft Otra nube).

www.radians.com.ar

Es posible extender el uso de estos inquilinos de directorio a otras aplicaciones basadas en LOB que esté desarrollando y / oa miles de aplicaciones SaaS pre-integradas en la nube como ADP, Concur, Google Apps, Salesforce.com y otras, independientemente del público. Nube en la que están alojados. Las aplicaciones SaaS pre-integradas se preconfiguran a través de una galería de aplicaciones con todos los parámetros necesarios para proporcionar al menos una experiencia de inicio de sesión sin problemas con ellos, gracias a las Mejoras de acceso a aplicaciones de Azure AD (ver más adelante en este documento).

Mañana estaremos viendo las distintas ediciones de Azure AD que tenemos disponibles, y como registrarnos para poder probarlo.

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


16  01 2017

Resumen Semanal!

www.radians.com.arBuenos días, estoy publicando el resumen de las notas de la semana pasada. Para aquellos que no entran diariamente; el calendario semanal seria, los días lunes un resumen de la semana y los viernes un laboratorio o nota de mayor interés.

Quería contarles que estoy subiendo videos de los ScreenCast en YouTube en el canal del blog, hay muchos sobre Windows Server 10 TP, Windows 10 TP, Windows Server 2012 R2 y sobre Windows 8.1. Les paso el link para que los vean; he tenido varios problemas con la cuenta vieja ya que como era una cuenta youtube no se podía linkear al nuevo formato desde que fue adquirida por google; funciono bastante bien durante un tiempo pero últimamente traía muchos problemas por lo que fue migrada a :

http://www.youtube.com/user/radilello
https://www.youtube.com/channel/UCdOZP-ULQ19HnKlVr9jqWMQ

Como siempre estaré contestando todos y cada uno de ellos! GRACIAS por la paciencia. Esta semana estaré retornando a escribir la nota importante los viernes, ya que en el ultimo tiempo estuve muy, muy complicado. Gracias por todo!

Saludos, Roberto Di Lello.

Resumen Semanal


« Previous PageNext Page »