Seguro que muchos de vosotros estáis trabajando con Intune, por lo que, vamos a ver una configuración muy importante para las organizaciones que es la de Protección de Aplicaciones. Esta configuración nos permite definir si los usuarios pueden compartir documentos, copiar-pegar, abrir documentos desde aplicaciones externas, etc..

En este artículo voy a mostrar una configuración muy sencilla, a la vez que potente: permitir que los usuarios únicamente accedan a la documentación que está ubicada en Teams y si la descargan no puedan utilizarla. Esto  nos permitirá controlar que la información no se pueda trabajar fuera del entorno corporativo, de esta forma, evitamos que los usuarios puedan llevarse información confidencial de la empresa.

La configuración es muy sencilla, pero se puede complicar todo lo que queramos, pero para este artículo haremos algo muy sencillo…

Con el crecimiento de los ataques a nuestras cuentas de usuario, debemos buscar soluciones en el mercado que nos permitan securizar el acceso de nuestros inicios de sesión en diferentes plataformas. Es por ello que, llevemos años implementando soluciones de doble factor de autenticación y con MSFT concretamente tenemos varias opciones para iniciar sesión sin contraseña:

• Windows Hello para empresas
• Aplicación Microsoft Authenticator
• Claves de seguridad FIDO2

Los métodos de autenticación sin contraseña resultan más cómodos, ya que la contraseña se quita y se reemplaza por algo que se tiene (llave) más algo que se sabe (PIN). En el artículo de hoy, voy a mostraros como podemos implementar FIDO2 (Fast IDentity Online) para iniciar sesión en O365 + Azure + Windows 10 (Azure ADJoin).  Aquí os dejo un enlace sobre FIDO2 en el que MSFT hablar con más nivel de detalle: https://docs.microsoft.com/es-es/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys.

En este caso, yo voy a utilizar una Security Key NFC (Security Key NFC by Yubico | Two Factor Security Key | USB-A & NFC) para configurar FIDO2 en Azure para mi usuario y que pueda ser utilizada en iniciar sesión en Office 365 y mi Windows 10 unido al dominio de Azure AD …

Otra pasito más hacia la “independencia de nuestro Active Directory Domain Services” o, por lo menos, para que nuestros usuarios no tengan la necesidad de estar conectados vía VPN para recibir configuraciones centralizadas desde IT. Aunque  en este artículo, vamos a ver como podemos emitir certificados para nuestros equipos unidos al Azure AD para conectarnos a la VPN de Azure (Point-to-Site) y acceder a los ficheros compartidos en Azure Files mediante Private Link.

Como os he comentado anteriormente, la idea es ir llevando todos los servicios al Cloud aprovechándonos de nuestro maravilloso AzureAD, pero también es cierto que debemos ir poco a poco migrando diferentes servicios y convivir con ellos en un entorno “híbrido”. En este caso, la idea es mostraros como podemos conectar nuestra PKI privada (integrada en nuestro ADDS) y que los equipos unidos al dominio de AzureAD y manejados con Intune puedan solicitar un certificado de equipo o usuario.  Esto nos permitirá configurar vía profile de Intune:

• Conexiones VPN autenticando con certificados digitales
• Redes Wi-Fi autenticando con certificados digitales
• Servicios que soliciten autenticación por certificados
• Etc..

Seguro que muchos de vosotros habéis desplegado  802.1x para vuestras redes Wifi y, sino es así, por favor, cuanto antes que es un proceso muy sencillo y os da un plus importante de seguridad:

• GPO: Autenticación 802.1x WLAN
• NPS: Autenticación 802.1X Red Cableada
• NPS: Autenticación 802.1x para nuestra red inalámbrica

Para estos despliegues, además de dispositivos que soporten este tipo de autenticación, también debemos contar con una PKI Privada (por ahorro de costes y gestión): Instalar la entidad de certificación. No voy a poder entrar en todos los detalles, porque sería un artículo enorme, pero iré publicando diferentes URL donde podéis ir encontrando la información suficiente para ir completando todo el proceso …

Hoy voy a mostraros un pequeño script (mejorable) que nos va a permitir gestionar el apagado he iniciado de nuestros hosts de sesión, de forma sencilla. En otra ocasión había publicado otro artículo sobre esto mismo pero desde utilizando Webhooks y PowerShell: Microsoft Azure: Ahorro de Costes en WVD [Detener Equipos Sin Sesiones], pero hoy vamos a configurar un script que nos permite conocer las sesiones activas en los hosts de sesión de nuestros host pool.

La idea es la siguiente:

• Si tenemos hosts de sesión sin sesiones activas, apagaremos dichos hosts de sesión
• Si tenemos un hosts de sesión con un número de sesiones N, entonces iniciaremos un nuevo hosts de sesión

Esto nos permite siempre mantener un número de hosts de sesión óptimo en nuestro entorno, sin incurrir en costes innecesarios al tener hosts de sesión iniciados sin o con pocas sesiones activas. Al final todos sabemos que el coste se va en la cantidad de equipos iniciados que tengamos, por lo menos como valor referencial.

Para implementar esta solución, lo haremos con un runbook y un script de PowerShell, algo simple y que luego cada uno puede mejorar sin lugar a dudas (no es mi fuerte los scripts de PowerShell).