![\"www.radians.com.ar\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/ActiveDirectorycontrolesdeTIparagestiona_11968\/01.jpg\" "\\"www.radians.com.ar\\"")
<\/a> <\/p>\nCon la nueva versi\u00f3n de los Servicios de federaci\u00f3n de Active Directory (AD FS) en Windows Server 2012 R2, se han a\u00f1adido una serie de features para proporcionar m\u00e1s controles de IT para satisfacer sus necesidades de gesti\u00f3n de riesgos. Para aquellos que no saben que significa o implica AD FS, se puede pensar en esto como una cabeza de autenticaci\u00f3n en la parte superior de los Servicios de dominio de Active Directory (ADDS) y se extiende el alcance de los usuarios de AD a los recursos que se encuentran en las instalaciones, en la nube u organizaciones asociadas. AD FS es una funci\u00f3n est\u00e1ndar que est\u00e1 disponible en Windows Server. <\/p>\n
- \n
- \nAutenticaci\u00f3n flexible con autenticaci\u00f3n de m\u00faltiples factores (MFA)<\/font><\/strong><\/em><\/div>\n<\/li>\n<\/ul>\n
Una parte importante de la gesti\u00f3n del riesgo est\u00e1 en c\u00f3mo el usuario se autentica en un recurso espec\u00edfico. Esto es cuando los "registros de" usuario y contrase\u00f1a, para acceder a una aplicaci\u00f3n. Diferentes aplicaciones pueden requerir diferentes formas de credenciales (que var\u00edan en su rigurosidad) sobre la base de la sensibilidad de los recursos y el contexto con el que el usuario accede a esta aplicaci\u00f3n (por ejemplo, su ubicaci\u00f3n).<\/p>\n
Siempre existi\u00f3 la necesidad de que los administradores sean capaces de diferenciar las pol\u00edticas para aplicaciones sensibles y requieren MFA basado en la ubicaci\u00f3n o en base a las caracter\u00edsticas del usuario. Por ejemplo, "requerir MFA para la aplicaci\u00f3n X cuando los usuarios acceden desde la extranet" O "requieren MFA para todos los administradores de aplicaciones para la aplicaci\u00f3n Y". <\/p>\n
La nueva versi\u00f3n de AD FS en WS2012R2 conceptualiza la autenticaci\u00f3n como un proceso de dos etapas, la etapa de autenticaci\u00f3n principal y una etapa de autenticaci\u00f3n adicional. <\/p>\n
- \n
- Autenticaci\u00f3n principal<\/font><\/em><\/strong><\/li>\n<\/ul>\n
Esta es la primera etapa de autenticaci\u00f3n que se produce en todas las aplicaciones. Aqu\u00ed es donde se ingresa la credencial principal del usuario (por ejemplo, nombre de usuario y contrase\u00f1a) y es autenticado. Esta etapa requiere autenticaci\u00f3n en nuestro Active Directory Domain Services (AD DS). La mayor\u00eda de los administradores necesitan diferenciarse y administrar la autenticaci\u00f3n en funci\u00f3n de si el usuario est\u00e1 dentro del firewall o fuera del firewall (intranet vs. extranet). Se han producido algunos cambios simples para la administraci\u00f3n para controlar este inconveniente, y es tan simple como hacer clic en una casilla en la consola de administraci\u00f3n de AD FS. Adem\u00e1s, el administrador tambi\u00e9n tiene la opci\u00f3n para habilitar la autenticaci\u00f3n de dispositivos para aumentar la credencial de usuario con certificados provisionados por el Servicio de Registro de dispositivos (DRS) a los dispositivos Workplace Joined. <\/p>\n
- \n
- Activaci\u00f3n de la autenticaci\u00f3n adicional<\/font><\/strong><\/em><\/li>\n<\/ul>\n
Esta es la pol\u00edtica que rige si la etapa adicional de autenticaci\u00f3n debe ser activada. Esto se hace s\u00f3lo despu\u00e9s de la autenticaci\u00f3n principal se haya completado con \u00e9xito. De esta manera tenemos datos sobre el usuario, el dispositivo, as\u00ed como la ubicaci\u00f3n de escribir esta pol\u00edtica en funci\u00f3n de cada aplicaci\u00f3n. Como resultado, esto proporciona una gran flexibilidad para los administradores para exigir autenticaci\u00f3n adicional en base a sus necesidades de negocio. Por ejemplo, un administrador podr\u00eda habilitar pol\u00edticas como "S\u00f3lo desencadenar autenticaci\u00f3n adicional si …"<\/p>\n
- \n
- \n"… Los usuarios acceden a los recursos de la extranet"<\/div>\n<\/li>\n
- \n
"… El usuario es parte del grupo de seguridad ‘administradores de aplicaciones’"<\/div>\n<\/li>\n- \n
"… El usuario est\u00e1 accediendo desde un no-lugar de trabajo Registrado dispositivo y acceder a los recursos de la extranet" <\/div>\n<\/li>\n- Autenticaci\u00f3n extensible adicional<\/font><\/strong><\/em><\/li>\n<\/ul>\n
La pregunta obvia que surge es "\u00bfqu\u00e9 sucede despu\u00e9s de la activaci\u00f3n de autenticaci\u00f3n adicional"? AD FS soporta certificado X509 (piense esquemas basados \u200b\u200bCSP de tarjetas inteligentes u otros que utilizan el cliente TLS) de autenticaci\u00f3n como un adicional (o secundaria), proveedor de autenticaci\u00f3n. Adem\u00e1s de la autenticaci\u00f3n X.509, existe una gran cantidad de clientes que utilizan una amplia gama de otros m\u00e9todos de autenticaci\u00f3n de m\u00faltiples factores (MFA). Estos van a trav\u00e9s de fichas duros\/blandos, One Time Password (OTP), tel\u00e9fono (voz, SMS), el correo electr\u00f3nico, as\u00ed como la seguridad Q&A. Con la nueva versi\u00f3n de AD FS en WS2012R2, se han a\u00f1adido un framework con el cual, cualquier proveedor de terceros de MFA puede integrarse directamente con AD FS. Esto se hizo con el fin de: <\/p>\n
- \n
- \nAsegurarse que el AD FS tiene conocimiento acerca de la autenticaci\u00f3n adicional<\/div>\n<\/li>\n
- \n
Proporcionar una experiencia de inicio de sesi\u00f3n consistente para el usuario final<\/div>\n<\/li>\n- \n
Proporcionar proveedores MFA la capacidad de controlar la entrada y el proceso de validaci\u00f3n de las credenciales adicionales <\/div>\n<\/li>\n<\/ul>\n<\/p>\n
- \n
- \nControl de Acceso Multi-Factor (Multi-Factor Access Control)<\/font><\/em><\/strong><\/div>\n<\/li>\n<\/ul>\n
La autorizaci\u00f3n es un aspecto clave de la concesi\u00f3n de acceso a los recursos y puede ser dictado por las pol\u00edticas de la organizaci\u00f3n, departamentales o de aplicaci\u00f3n. AD FS en Windows Server proporciona a los administradores la capacidad de aplicar pol\u00edticas de autorizaci\u00f3n que administra "\u00bfQui\u00e9n puede acceder a esta aplicaci\u00f3n espec\u00edfica" (en esencia se trata de qui\u00e9n recibe el token de seguridad para la aplicaci\u00f3n). Estas son llamadas "reglas de autorizaci\u00f3n de emisi\u00f3n" que se adjunta a cada aplicaci\u00f3n. En versiones anteriores de AD FS, se limitaron a tomar decisiones basadas en el usuario o en la autenticaci\u00f3n de datos. Mientras siga siendo \u00fatil, no era posible aplicar pol\u00edticas basadas en la ubicaci\u00f3n (por ejemplo, en funci\u00f3n de si el usuario est\u00e1 viniendo de la extranet) o basado en los dispositivos.<\/p>\n
Con la nueva versi\u00f3n de AD FS en WS2012 R2 los dispositivos se han a\u00f1adido m\u00e1s tipos de datos para la administraci\u00f3n para tomar estas decisiones. Con Workplace Join, ahora tenemos datos sobre si la solicitud se origina a partir de un dispositivo que se conoce a AD. Los administradores ahora podemos usar esto para brindar el acceso a las aplicaciones y por lo tanto limitarlo desde cualquier dispositivo desconocido. Del mismo modo, el conocimiento acerca de c\u00f3mo fue autenticado el usuario (por ejemplo, si la AM se realiz\u00f3 en la segunda etapa, como se describimos anteriormente) tambi\u00e9n puede ser utilizado para tomar una decisi\u00f3n de autorizaci\u00f3n. Tambi\u00e9n se facilito informaci\u00f3n para poder brindar el acceso en base a la ubicaci\u00f3n, con un booleano simple para la detecci\u00f3n de la extranet, as\u00ed como la direcci\u00f3n IP del cliente; y con esta informaci\u00f3n se podr\u00e1 generar las reglas de autorizaci\u00f3n necesarias. Ejemplos de tales reglas son: <\/p>\n
- \n
- \n"Permitir solamente dispositivos con Workplace Join cuando se conectan desde la extranet a la aplicaci\u00f3n de Payroll"<\/div>\n<\/li>\n
- \n
"Permitir que s\u00f3lo los usuarios que pertenecen al grupo de seguridad ‘finanzas’ utilicen su aplicaci\u00f3n cuando se conectan desde la extranet"<\/div>\n<\/li>\n<\/ul>\n<\/p>\n
- \n
- \nMitigaciones de riesgo adicionales <\/font><\/strong><\/em><\/div>\n<\/li>\n<\/ul>\n
De acuerdo a la la forma de registro de usuarios para una aplicaci\u00f3n o c\u00f3mo est\u00e1n autorizados a los usuarios para tener acceso a una aplicaci\u00f3n no son las \u00fanicas \u00e1reas que nos enfocamos para proporcionar el conjunto adecuado de controles de IT para mitigar los riesgos asociados con el acceso a los recursos. Algunos de los features adicionales que se han a\u00f1adido en Windows Server 2012 R2 son los siguientes: <\/p>\n
- \n
- \nSoft Account Lockout for Extranet Access<\/em><\/strong>: Esto nos permite establecer una pol\u00edtica de contrase\u00f1as de bloqueo de acceso que se produce desde la extranet y si se supera el umbral de malas contrase\u00f1as, el usuario ser\u00e1 bloqueado por un per\u00edodo de tiempo (‘ventana de observaci\u00f3n’) especificada por la pol\u00edtica. Esto es independiente de los mecanismos de contrase\u00f1a de bloqueo de anuncios y se pueden superponer en la parte superior de la misma. <\/div>\n<\/li>\n
- \n
Per Application Force Re-authentication<\/em><\/strong>: Esta es la habilidad para los administradores para requerir que los usuarios den un nuevo conjunto de credenciales cada vez que acceda a la aplicaci\u00f3n. Por lo general, se podr\u00eda usar esto para aplicaciones sensibles, donde siempre se le pide al usuario proporcionar un nuevo conjunto de credenciales (sin Single Sign-On) e incluso combinar esto con MFA<\/div>\n<\/li>\n- \n
Global SSO Revocation<\/em><\/strong>: Esta es la capacidad de revocar todo el estado SSO previa para todos los usuarios finales y que requieren credenciales frescas al acceder a cualquier aplicaci\u00f3n.<\/div>\n<\/li>\n- \n
Access Protection from lost devices<\/em><\/strong>: Para revocar cualquier acceso a los recursos corporativos desde un dispositivo que se pierde o es robado, Secure Anywhere Access to Corporate Resources Such as Windows Server Work Folders Using ADFS https:\/\/channel9.msdn.com\/Events\/TechEd\/NorthAmerica\/2013\/WCA-B334#fbid=tambi\u00e9n tenemos la posibilidad de que los administradores simplemente desactiven\/eliminen el dispositivo registrado (el usuario @ Dispositivo objeto en AD) y como resultado todo el acceso desde este dispositivo se revoca o se requiere que el usuario final proporcione un nuevo conjunto de credenciales o realice un workplace join nuevamente de su dispositivo para recuperar el acceso a los recursos corporativos. Adem\u00e1s, los eventos de fallo de auditor\u00eda se registrar\u00e1n y estos contienen la informaci\u00f3n del certificado de dispositivo y la direcci\u00f3n IP para que los administradores puedan realizar su seguimiento.<\/div>\n<\/li>\n<\/ul>\nRealmente todos estos cambios y estos nuevos features nos dan muchas herramientas para administrar nuestros ambientes y dominios, y tambi\u00e9n nos ayudan a enfrentar las nuevas necesidades para cumplir con los requerimientos del negocio en cuanto al acceso a las aplicaciones desde cualquier sitio, y con el concepto de BYOD (Bring your Own Device).<\/p>\n
Espero que les sea de inter\u00e9s. Saludos. Roberto Di Lello<\/p>\n
Mas informaci\u00f3n:<\/h4>\n
- \n
- Secure Anywhere Access to Corporate Resources Such as Windows Server Work Folders Using ADFS<\/a><\/li>\n
- TechEd Demo \u2013 ADFS an integration with SafeNet Authentication Service<\/a><\/li>\n
- What’s New in Active Directory in Windows Server<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Hace unos d\u00edas hemos publicado una nota sobre c\u00f3mo Active Directory y Windows Server 2012…<\/p>\n","protected":false},"author":1,"featured_media":4291,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[158,281,279,297],"tags":[217,226,230,304,234,195,243],"class_list":["post-2841","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-windows-server-2012","category-281","category-windows-10","category-windows-8","tag-ad-domain-services","tag-group-policy","tag-seguridad","tag-windows-10","tag-windows-8-1","tag-windows-server-2008-r2","tag-windows-server-2012-r2"],"_links":{"self":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2841","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2841"}],"version-history":[{"count":1,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2841\/revisions"}],"predecessor-version":[{"id":2842,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2841\/revisions\/2842"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/media\/4291"}],"wp:attachment":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2841"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2841"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2841"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- TechEd Demo \u2013 ADFS an integration with SafeNet Authentication Service<\/a><\/li>\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Activaci\u00f3n de la autenticaci\u00f3n adicional<\/font><\/strong><\/em><\/li>\n<\/ul>\n
- Autenticaci\u00f3n principal<\/font><\/em><\/strong><\/li>\n<\/ul>\n