Configuración automática de clases en Microsoft Teams con School Data Sync (SDS)

Ante la situación actual del Covid-19 a nivel mundial, las instituciones de educación aquí en Colombia (colegios, universidades, etc.) decidieron desde hace poco más de una semana enviar a todos los estudiantes, personal administrativo y profesores para las casas; sin embargo, aunque la medida fue, en mi opinión, oportuna, no hubo mucho tiempo para planear las clases virtuales, así que empezaron a trabajar casi sobre la marcha. Por supuesto, la primera preocupación fue el espacio en dónde tener y dar las clases, pero rápidamente muchos optaron por utilizar Microsoft Teams, ya que utilizan internamente tecnología Microsoft.

Recordemos que Microsoft Teams, cuando se utiliza en un tenant educativo, permite crear equipos especiales que tienen una configuración enfocada a clases, donde el profesor puede compartir una libreta de direcciones, hacer llamadas, crear asignaciones y exámenes fácilmente.

El problema de todo es que las instituciones pueden llegar a tener más de 2k de cursos y crear eso manualmente, incluso a través de PowerShell, sería engorroso y demorado.

School Data Sync (SDS)

Con School Data Sync (SDS), las instituciones pueden exportar toda la información referente a la entidad, estudiantes, profesores, materias y cursos e importarla a través de unos formatos en la plataforma para que se creen automáticamente todas las clases en Microsoft Teams, referenciando tanto a estudiantes como profesores:

image

Por detrás de esto, SDS está creando todos los grupos en Office 365, espacios en SharePoint, Exchange Online, configuración de Intune para Educación, etc.

Aunque la plataforma se puede llegar a tardar algunas horas en aprovisionar y es necesario tener extremo cuidado con los archivos que se suben, es bastante productiva, ya que deja listo cada curso para que el profesor empiece a modificar a su gusto.

Requerimientos

  1. Es necesario tener un tenant educativo
  2. Utilizar una cuenta con privilegios Global Admin

Métodos de despliegue

School Data Sync (SDS) cuenta con varias formas para aprovisionar las clases:

  • Archivos CSV con formato especial para SDS
  • Archivos CSV en formato Clever
  • Archivos CSV en formato OneRoster
  • API de PowerSchool
  • API de OneRoster

Para el resto del artículo nos enfocaremos en la primera opción, archivos CSV con el formato especial para School Data Sync (SDS).

Configuración de archivos CSV para SDS

En total, serán 6 archivos los que vamos a crear:

  1. school.csv
  2. section.csv
  3. student.csv
  4. studentenrollment.csv
  5. teacher.csv
  6. teacherroster.csv

A continuación, describiré el escenario que utilizaré y cómo encaja en la creación de cada uno de los archivos.

Escenario

Nombre de la institución:
Nala University

Identificador de la institución:
1901

Código inicial para estudiantes:
10100

Código inicial para profesores:
20100

Código inicial para materias:
30100

Importante:

Desde que sea numérico, no importa qué rango de identificación quieran asignar. De hecho, estos datos deberían salir de su respectivo sistema de información. La intención de este post es mantenerlo lo más simple posible para comprender el proceso, así que asigné unos que fueran fáciles para mi de referenciar.

Además de esto, es necesario saber que todos los atributos deben escribirse respetando mayúsculas y minúsculas.

school.csv

image

El primer atributo, SIS ID, hace referencia al número con el que identificaré mi institución (pueden ser varias en un mismo archivo); Name se refiere al nombre de la institución, es decir, Nala University en mi caso.

En el formato CSV, utilizando mi ejemplo, se vería así:

image

section.csv

El archivo de section.csv contiene todas las materias que se van a agregar y tiene como obligación tres atributos: SIS ID, School SIS ID y Section Name; no obstante, debemos agregar los mismos tres por cada materia. En el ejemplo, referencio tres materias.

SNAGHTML715ae7d

El primer atributo, SIS ID, no es el mismo identificador que tiene el archivo de school.csv. Aunque el nombre es igual, aquí debemos establecer el identificador pero de la materia que vayamos a agregar. El segundo atributo, School SIS ID, sí corresponde al SIS ID del archivo school.csv. En mi caso, por ejemplo, siempre será 1901, número escogido para referenciar a la universidad. El tercer atributo, Section Name, es el nombre de cada materia. Puede contener letras y números.

Siguiendo mi ejemplo, el archivo se vería así en el CSV:

image

student.csv

El archivo student.csv contiene el detalle por cada estudiante, de forma obligatoria: SIS ID, School SIS ID y Username.

SNAGHTML7127d4a

El primer atributo, SIS ID, no es el mismo identificador que tienen los archivos school.csv y section.csv, sino la referencia única a cada estudiante que existe en Office 365 (o que se va a crear). El segundo atributo, School SIS ID, sigue correspondiendo al SIS ID del archivo school.csv, es decir, al que identifica la institución: en mi caso, por ejemplo, 1901. El tercer atributo, Username, es el nombre de usuario tal cual aparece (o aparecerá) en Office 365.

En mi ejemplo, quedaría así en el CSV:

image

Noten que los números no deben ser necesariamente secuenciales, aunque es buena práctica.

studentenrollment.csv

El archivo studentenrollment.csv tiene toda la relación entre la materia que se está registrando en section.csv y los estudiantes en student.csv:

SNAGHTML73d310d

El primer atributo, Section SIS ID, como el nombre lo dice, corresponde al mismo identificador que está en section.csv y que referencia al curso/clase que se va a crear. En este ejemplo, 30100 es el identificador del curso de Colombia moderna. El segundo atributo, SIS ID, es el identificador único del estudiante que se creó en el student.csv.

El resto ya son repeticiones de estos mismos atributos obligatorios por cada materia y estudiantes asociados. Por ejemplo, los últimos 6 registros son de un mismo curso, pero registrando diferente estudiante.

En mi CSV de ejemplo, quedaría así:

image

teacher.csv

El archivo teacher.csv contiene toda la información única para cada profesor:

SNAGHTML7542f29

El primer atributo, SIS ID, no es ninguno de los identificadores de los archivos anteriores, sino el que será único para cada profesor que vamos a registrar. El segundo atributo, School SIS ID, hace referencia al identificador que se creó para la institución en el archivo school.csv. En este caso, por ejemplo, 1901. El tercer atributo, Username, es el nombre de usuario del profesor tal cual aparece en Office 365 (o que se va a crear).

En mi archivo CSV de ejemplo quedaría así:

image

teacherroster.csv

El archivo tearcherroster.csv contiene la relación entre los cursos registrados y los profesores que van a estar como propietarios de estos cursos:

SNAGHTML7670974

El primer atributo, Section SIS ID, hace referencia al SIS ID que tiene el archivo section.csv y que identifica a cada curso. En mi caso, por ejemplo, 30100 es la materia 2001 – Colombia moderna. El segundo atributo, SIS ID, es el mismo SIS ID que está para cada profesor en teacher.csv. En mi primer ejemplo, 20102, correspondería a HaderR. El resto son los mismos dos atributos obligatorios que debo repetir por cada profesor que vaya a registrar en los diferentes cursos.

Nota: todas las clases en Teams deben quedar asignadas a un profesor al menos.

En mi archivo CSV de ejemplo quedaría así:

image

Con esto culminamos la parte más difícil, ahora solo queda hacer la carga y sincronizar. Cabe aclarar que es recomendable revisar muy bien el formato de cada archivo, pues de esto depende el éxito en la creación y puede ser muy engorroso depurar después de que se sincronizan miles de cursos.

Creación y sincronización del perfil en SDS

Primero, abrimos el navegador, vamos a https://sds.microsoft.com/ e iniciamos sesión con nuestras credenciales de administrador global.

Una vez iniciados, vamos a la pestaña de Home y hacemos clic en Add profile:

image

En la página de Choose connection type, escribimos un nombre para nuestro perfil en el cuadro de texto debajo de Enter a name for your profile, escogemos Upload CSV files, luego CSV files: SDS Format y hacemos clic en Start:

image

En la página de Sync options, seleccionamos Existing users*, luego hacemos clic en el botón de Upload Files, debajo de Import data:

image

*En este artículo estamos trabajando sobre usuarios que ya existen; en un próximo artículo intentaré mostrar cómo es el proceso con usuarios nuevos.

En el cuadro de texto de Select data files to be uploaded, hacemos clic en el botón de Add Files

image

Seleccionamos únicamente los 6 archivos y los abrimos para que se carguen:

SNAGHTML9d8df62

Después de que los archivos queden agregados, hacemos clic en el botón Upload:

image

Si no hay fallos con alguno de los archivos, deben ver un cuadro de confirmación:

image

De regreso a la página de Sync options, escogemos la opción de Automatically replace unsupported special characters while syncing from source, debajo de Replace unsupported special characters. Esto es para que se cambien los caracteres no admitidos por SDS por otros soportados.

Después, debajo de When should we stop syncing this profile, escogemos la fecha en la que terminarían las clases para que SDS nos dé la opción de eliminar todas las clases asociadas.

Por último, hacemos clic en Next:

image

En el paso 2, Teacher options, debajo de Domain (optional), escogemos el dominio asociado a nuestros usuarios, dejamos las opciones de Username y userPrincipalName como están y hacemos clic en el botón Next:

image

En Student options, hacemos exactamente la misma configuración del dominio, dejamos las demás como están de forma predeterminada y clic en Next:

image

En la página de Review, revisamos todo lo que configuramos y hacemos clic en Create profile:

image

Finalmente, veremos el inicio de la sincronización de nuestro perfil:

image

De aquí en adelante, si queremos ver el progreso o los errores, debemos ir actualizando la página hasta que termine y quede todo aprovisionado:

image

image

En caso de error con alguno de los archivos, SDS va a notificar y a entregar un error descriptivo, aunque no siempre preciso:

image

Basta con depurar el archivo o hacer cambios en Office 365 y volver a subir los archivos haciendo clic en el botón de Upload Files. Sin embargo, si el error es de plataforma, habría que hacer los cambios y hacer clic en Reset Sync para que inicie nuevamente.

Al terminar la sincronización, SDS notificará para subir más actualizaciones o proceder a revisar los resultados:

image

Nota: si hay errores durante la sincronización, podría terminar en color amarillo. Es buena práctica subir los archivos de nuevo para que se haga y no se quede nada sin sincronizar.

Verificación de resultados

Desde el administrador de la plataforma

En el panel izquierdo de la plataforma de School Data Sync (SDS), hacemos clic en Groups:

SNAGHTMLa490865

Aquí vamos a ver la institución o sedes que hayamos creado, así como la pestaña de Sections (cursos) y de los grupos de seguridad:

image

Si hacemos clic sobre el nombre de la universidad, vamos a ver todos los datos que hayamos subido en los archivos y el acceso directo a estudiantes, profesores y cursos:

image

Al hacer clic en Sections, por ejemplo, SDS va a filtrar todos los cursos que estén asociados a ese SIS ID:

image

Si hacemos clic en cualquiera de las materias, vamos a ver los estudiantes asociados:

image

Hasta aquí todo bien. Lo siguiente es que cada profesor abra Teams, active sus clases y empiece a generar contenido.

Desde Microsoft Teams como profesor

Primero, por supuesto, el profesor debe de iniciar sesión en Microsoft Teams:

image

Una vez dentro de Teams, debe de ir al panel izquierdo en Teams/Equipos y buscar el que le fue asignado:

image

Dentro del equipo, en la parte superior, van a ver un botón que dice Activate/Activar. Hasta que el profesor o propietario del equipo no lo active, no será visible para los estudiantes dentro de Teams:

image

Cabe aclarar que el profesor puede modificar el equipo, pero hasta que no se active, no podrá hacer operaciones como agregar estudiantes dentro del equipo o de un canal privado:

image

Al activar el equipo, Teams notificará que no se puede devolver y dejará confirmar nuevamente:

image

image

¡Listo! ¡A dar clases! =)

Saludos,

—Checho

Construir y desplegar imagen de Windows 10 en modo S

Hace unos días, por cuestiones de trabajo, requería hacer un piloto en una empresa evaluando Windows 10 en modo S por el escenario de seguridad y rendimiento que presenta este modo. Sin embargo, tuve bastantes problemas para convertir una imagen a modo S, pues aunque existe la documentación, está incompleta y no tiene caso algunos detalles adicionales.

Para no tener que volver a pasar por esto (olvido fácilmente) y con el fin de compartir para otras personas que lo necesiten, voy a explicar el paso a paso con más detalles a continuación.

Si quieren leer algunos detalles técnicos sobre el modo S de Windows 10, pueden leer la descripción oficial en la documentación oficial de Microsoft.

Requerimientos

1. Imagen de Windows 10 en cualquier edición, ojalá 1903 en adelante

2. Crear una carpeta llamada C:\W10, y otra llamada C:\Mount

2. Tener instalado el ADK para Windows 10 y la actualización del SIM para el ADK

3. Equipo técnico en donde esté instalado el ADK para Windows 10

4. Equipo de prueba, físico o virtual, en donde se pueda probar Windows 10 en modo S

Paso 1: crear carpeta con archivos de instalación de Windows 10

Como necesitamos montar la imagen para activar el modo S, debemos copiar todos los archivos de instalación a una carpeta local. Para esto, hacemos lo siguiente:

image

Paso 2: crear archivo de respuesta con SIM

Lo siguiente será aplicarle un catálogo predeterminado a la imagen de Windows 10 Pro, con el fin de que solo pueda ejecutar aplicaciones y controladores que sean confiables para Microsoft, es decir, que vengan desde la tienda de Windows y algunas otras excepciones.

Para esto, ejecutamos el System Image Manager con privilegios elevados, nos ubicamos debajo del panel izquierdo que dice Windows image, clic derecho sobre Select a Windows image or catalog file y escogemos Select Windows image:

image

En la ventana de Select a Windows image, seleccionamos install.wim en nuestra carpeta de C:\W10\Sources y clic en Open:

image

En la ventana de Select an image, escogemos Windows 10 Pro y clic en OK:

image

Clic en el botón de Yes para crear el catálogo:

image

Una vez termine, debemos ver los nodos de componentes y paquetes:

image

A continuación, presionamos las teclas CTRL + N y veremos que en el panel superior central de Answer file, se habrá creado un nuevo archivo de respuesta sin nada:

image

Luego de tener el catálogo y el archivo de respuesta, expandimos el nodo de Components en la parte inferior izquierda, buscamos amd64_Microsoft-Windows_CodeIntegrity y hacemos clic en Add Setting to Pass 2 offlineServicing:

image

En la parte superior, hacemos clic sobre el componente agregado al archivo de respuesta y en el panel derecho cambiamos el valor de SkuPolicyRequired de 0 a 1:

image

Por último, vamos a File, Save answer file, le ponemos el nombre de Unattend.xml y lo guardamos en alguna ubicación de fácil acceso, pues necesitaremos copiarlo después a la imagen:

image

Paso 3: montar la imagen sin conexión

Una vez tengamos los archivos de instalación localmente, debemos montar la imagen en nuestra carpeta de C:\Mount con el fin de modificarla y activarle el modo S. Para esto, ejecutamos un símbolo del sistema con privilegios elevados y ejecutamos:

Dism /Mount-Image /ImageFile:C:\W10\sources\install.wim /Index:5 /MountDir:C:\Mount

image

El número del índice, es decir, 5, equivale a la imagen de Windows 10 Pro. Si quieren utilizar otra, deben hacer uso del parámetro /Get-WimInfo y consultar el índice adecuado

Podrán notar que la estructura de carpetas en Mount es muy similar a la de una instalación normal de Windows:

image

Paso 4: copiar y aplicar el archivo de respuesta a la imagen

Primero copiamos la carpeta de Panther ejecutando desde el CMD:

mkdir C:\Mount\Windows\Windows\Panther

image

Segundo, copiamos el archivo de respuesta que creamos en el paso anterior a esta carpeta:

image

<

p align=»justify»>Tercero, aplicamos el archivo de respuesta a la imagen sin conexión desde el CMD:

Dism /Image:C:\Mount /Apply-Unattend:»C:\Mount\Windows\Windows\Panther\Unattend.xml»

image

Opcionalmente, podríamos aprovechar algunas características útiles como Telnet:

image

<

p align=»justify»>Por último, desmontamos la imagen aplicando cambios:

Dism /Unmount-Image /MountDir:C:\Mount /Commit

image

¡Listo! Solo nos queda definir el método de implementación.

Paso 5: crear imagen ISO para UEFI

Ejecutamos el Deployment and Imaging Tools Environment con privilegios administrativos y luego creamos la imagen ISO corriendo:

Oscdimg -b»C:\W10\efi\microsoft\boot\efisys.bin» -pEF -u1 -udfver102 C:\W10 C:\en_win10_pro_s_mode.iso

image

Paso 6: pruebas de instalación

Finalmente, basta con realizar la instalación normal del sistema operativo y verificar que, efectivamente, el modo S quedó activado en las propiedades del sistema:

image

Cabe aclarar que Windows 10 en modo S no permite ni siquiera ejecutar varias aplicaciones integradas como CMD:

image

<

p align=»justify»>Como ven, solo permite aplicaciones que hagan parte de la tienda de Microsoft; no obstante, algunas aplicaciones como el nuevo Edge puede instalarse sin problemas. Adicionalmente, toda aplicación que se despliegue desde Intune a un equipo en modo S también se podrá instalar, pues se considera el MDM como una fuente confiable, tal cual como si fuese la tienda.

Habilitar BitLocker en Windows 10 desde Microsoft Intune

BitLocker es una tecnología de cifrado a nivel de unidad disponible desde Windows 7 Enterprise. En un principio, solo se podía activar en ediciones Enterprise y su administración era a través de directivas de grupo; sin embargo, el producto evolucionó en cuanto a características y pasó a ser parte de Pro en Windows 8/1 en adelante, además de agregar administración desde Microsoft BitLocker Administration and Monitoring (MBAM), consola que me permitía gestionar todas las operaciones de una forma mucho más productiva que simples directivas de grupo.

Con la evolución de Microsoft Intune y la nueva era de escritorio moderno, la administración de BitLocker ahora se está llevando a la nube para mayor simplicidad y aunque ya Microsoft anunció varias características interesantes que vienen pero no están listas, ya es posible aprovechar otras tantas funcionalidades desde Intune.

En este artículo vamos a configurar Intune para activar un cifrado básico en todos los equipos Windows 10 que estén registrados.

Requerimientos

  1. Tener el dispositivo Windows registrado en Microsoft Intune
  2. Licencia de EMS + Security o Intune de forma independiente
  3. Tener instalado como mínimo Windows 10, versión 1803. Recomiendo 1903

Grupo de dispositivos

Aunque la asociación de Intune suele hacerse hacia los usuarios que estén registrados, la directiva se aplica directivamente a cada dispositivo. Es por esta razón que debemos asegurarnos de tener un grupo que cumpla nuestras funciones de piloto antes de crear la directiva.

Para crear el grupo, ingresamos al portal de Azure, vamos al Azure Active Directory, luego en Groups y creamos un nuevo grupo haciendo clic en el botón superior de New group

image

En la página de New Group, le indicamos un nombre a nuestro grupo de dispositivos, descripción opcional y luego hacemos clic en Members:

image

En la página de Members, buscamos el dispositivo por su nombre, hacemos clic sobre él y luego clic en el botón Select.

Nota: aquí es donde aprovechamos a agregar todos los dispositivos que recibirán la directiva.

image

De vuelta en la página de New Group, hacemos clic en el botón de Create para que el grupo quede agregado a Azure AD.

Creación de directiva

En el portal de Azure, vamos a Intune, luego Device Configuration, Profiles y hacemos clic en el botón de Create profile en la parte superior:

image

En la página de Create Profile, indicamos un nombre, seleccionamos Windows 10 and later como Platform, Endpoint protection como Profile type, le damos clic en el botón de Settings y finalmente escogemos Windows Encryption:

image

En el nodo de Windows Encryption es donde podremos configurar todas las opciones disponibles de BitLocker para unidades de sistema operativo y externas, esto incluye: recuperación, tipos de seguridad, mensajes opcionales, etc. Adicional a esto, hay otras tantas directivas OMA-URI disponibles para BitLocker, pero no entraremos en detalle aquí.

Para este artículo, vamos a empezar por habilitar el cifrado cambiando a Require la opción de Encrypt devices en la categoría de Windows Settings:

image

En la categoría de BitLocker OS Drive Settings, activamos lo siguiente:

Additional authentication at startup: Require

OS drive recovery: Enable

Save BitLocker recovery information to Azure Active Directory: Enable

Store recovery information in Azure Active Directory before enabling BitLocker: Require

image

Lo más importante a destacar aquí es que utilizaremos TPM con alguna de las opciones adicionales como PIN o llave y guardaremos la clave de recuperación en el objeto de Azure AD.

Hacemos clic en el botón OK de Windows Encryption al final del panel, luego OK en el panel de Endpoint protection y finalmente Create en la página de Create Profile para terminar.

Asignación de directiva

Como regla general en Intune, cada directiva que se cree debe asignarse a un grupo de usuarios o dispositivos para que pueda empezar a funcionar, muy similar al las directivas de grupo tradicionales.

Para asignar la directiva, estando dentro de la política en cuestión, hacemos clic en Assigments:

image

En la página de Assignments, debajo de Include, hacemos clic en Select groups to include, buscamos nuestro grupo de dispositivos creados previamente, hacemos clic sobre él y luego clic en el botón de Select:

image

Por último, hacemos clic en el botón de Save que se habilitará luego de agregar el grupo:

image

Pruebas funcionales

Si todo sale bien, en cuestión de minutos todos los equipos que pertenecen al grupo y reciben la política deberían indicar que es necesario hacer el cifrado de máquina:

SNAGHTML5fd115ad

En caso de que el usuario cierre el mensaje haciendo clic en el botón de No, el mensaje se volverá a mostrar después de un rato o de un reinicio. Si el usuario selecciona «No volver a preguntar», el cifrado no se iniciará y tampoco volverá a aparecer el mensaje.

Infortunadamente, no he encontrado forma soportada de evitar que se pueda seleccionar esa opción o que al menos se pueda forzar a aparecer el cuadro de nuevo, la única manera fue recurriendo a Process Monitor y viendo qué hacía Windows al momento de escoger «No volver a mostrar»:

image

Como pueden ver, se crea un valor llamado UserOptedOutEncryptionNotification con un tipo de dato REG_DWORD y contenido de 1, es decir, habilitado en la sublcave:

HKEY_LOCAL_MACHINE\Software\Microsoft\BitLockercsp\UserOptions

Basta con eliminar ese valor y reiniciar o esperar un rato a que el cuadro vuelva a aparecer.

Como dato adicional, es necesario seleccionar la primera opción para iniciar el cifrado. Cuando presionemos Sí, Windows iniciará el asistente normal de cifrado de unidad de BitLocker:

image

En el primer paso normalmente conviene utilizar una contraseña personal para desbloquearla, después escogemos el método de recuperación que deseemos:

image

*Nota: sin importar cuál escojamos, desde las directivas ya estamos obligando a que la clave de recuperación se guarde en la nube, es decir, la primera opción.

En la página de Elegir qué cantidad de la unidad desea cifrar, dejamos la opción predeterminada y hacemos clic en Siguiente:

image

En la página de Elección del modo de cifrado que se usará, dejamos el de Modo de cifrado nuevo y clic en Siguiente:

image

Finalmente, en la página de ¿Está listo para cifrar esta unidad?, hacemos clic en Continuar:

image

Solo nos queda esperar hasta que el cifrado se complete:

image

En un próximo artículo explicaré el proceso de recuperación que existe actualmente en caso de que el usuario tenga problemas para ingresar en un disco cifrado.

Saludos,

—Checho

Ejecutar scripts de PowerShell desde un paquete de Advanced Installer

Aunque este fue creado principalmente para hablar de temas alrededor de Windows, me gusta compartir cosas que comparto y que me gustan con tecnologías o productos que utilizo. En esta ocasión, quiero hablar nuevamente de Advanced Installer, pues suelo utilizarlo bastante y cada vez me parece más indispensable tenerlo (junto con Snagit).

Muchas veces en los proyectos en los que estoy necesitamos realizar alguna tarea que implica hacer configuraciones, no siempre complejas, pero que sí requieren varios pasos, así que trato siempre de de automatizar todo creando un paquete de instalación con Advanced Installer, pues me permite agregar archivos, claves/valores de registro, configuración de permisos, entre muchas otras.

En este caso en particular, necesitaba instalar unos módulos de PowerShell  después de instalar algunos componentes de Microsoft, y aunque ejecutando el script de por sí es sencillo, no quería complicar a la persona que despliega con pasos manuales que requiere la ejecución de scripts, así que opté por utilizar Advanced Installer para facilitar un poco la tarea.

Cabe aclarar que en este artículo no explicaré cómo crear y configurar paquetes de Advanced Installer, solo me enfocaré en las acciones personalizadas.  

Custom Actions en Advanced Installer

Las Acciones personalizadas (Custom Actions) nos permiten ejecutar tareas o acciones que se lanzan en varias partes del proceso de instalación, casi siempre en la mitad o al final. Estas acciones son manejadas por el proceso de instalación, así que todo se mantiene en una sola ventana y la mayoría de veces permite automatización completa para que no haya demasiada interacción por parte del usuario, todo depende de qué se quiera hacer dentro de la lista disponible.

image

Hay una lista bastante grande debajo del cuadro de Add Custom Action. Cada acción tiene una leve descripción en la parte inferior del cuadro y todas están un poco más documentadas en la página oficial de Advanced Installer. Para agregar alguna basta con hacer clic en los botones de la derecha; la primera opción es la más sencilla pues se agrega al proceso natural de instalación:

image

Existen dos tareas que son particulamente útiles para el caso de este artículo:

Run PowerShell inline script: esta es una acción personalizada que me permite agregar un script completo de PowerShell dentro del ambiente de Advanced Installer, probarlo antes de compilar y agregarlo al proceso normal de instalación.

image

Run PowerShell script file: a diferencia del anterior, esta tarea me permite agregar el archivo de PowerShell completo para ser ejecutado. Puede ser desde una ubicación en disco o adjunto al paquete de instalación.

image

Ambas opciones permiten probar el script antes de compilar y guardar, así que es cuestión de qué tan completo sea el script.

En la experiencia personal, me ha funcionado mejor utilizar la primera opción y ejecutar todo el script desde el editor integrado. Para mi caso, quise instalar unos módulos de PowerShell para administración de diferentes componentes de Office 365.

Consideraciones a la hora de ejecutar scripts de PowerShell con Advanced Installer

A continuación les listaré, basados en lo que tuve que pasar, todo lo que es necesario tener en cuenta a la hora de ejecutar un script de PowerShell:

  1. Indispensable: cada línea debe de poderse ejecutar sin ninguna interacción del usuario, pues predeterminadamente la respuesta de Advanced Installer es rechazar la petición. Es muy común ver esto en algunos algunos cmdlets como Install-Module, así que siempre es necesario agregar el parámetro de –Force al final, por ejemplo:

    Install-Module -Name AzureAD –Force

  2. Es muy importante probar toda la ejecución del script aparte, pues muchas veces algún módulo, como el de AzureAD, requiere instalar previamente un Nuget y esto debemos garantizaro igualmente de forma automatizada

  3. En caso de ir a ejecutar el paquete en un equipo de 64 bits, debemos marcar la opción de 64 bit script en la parte superior derecha, pues de lo contrario el script no funcionará

SNAGHTML2315f52a

Lo que sigue de aquí es solamente compilar el paquete, desplegarlo y listo. Advanced Installer se encarga de configurar la ejecución de scripts remota (Set-ExecutionPolicy) para no tener ese tipo de problemas.

En caso de tener problemas, la mejor opción es habilitar los logs detallados del Advanced Installer y analizar la respuesta de PowerShell: https://www.advancedinstaller.com/user-guide/faq-ca.html#question98

Espero sea de utilidad.

Saludos,

—Checho

Crear directiva de cumplimiento para Windows 10 en Intune

Como indiqué en un artículo anterior, el procedimiento natural después de unir uno o múltiples dispositivos a Microsoft Intune es empezar a gestionarlos, es decir, aplicarle directivas de configuración o de seguridad, se a través de las que están preestablecidas o utilizando las que hacen parte del OMA-URI.

Ahora bien, por motivos de seguridad siempre es conveniente tener una base de cumplimiento para saber que cada dispositivo unido cumple con estándares definidos por la organización. Microsoft Intune nos permite crear algunas directivas de cumplimiento tanto para dispositivos móviles como para estaciones Windows de una forma muy sencilla, así que utilizaré el resto del artículo para describir el proceso, aunque solo me enfocaré en Windows 10 por ahora.

Requisitos

1. Es necesario contar con licencia de Intune y de Azure Active Directory Premium. Ambas están incluídas en los planes de Enterprise Mobility + Security (EMS)

2. Utilizar una plataforma soportada:

  • Android
  • iOS
  • macOS
  • Windows 8.1
  • Windows 10

3. El dispositivo tiene que estar inscrito en Microsoft Intune

4. Para Conditional Access: no están soportados los equipos unidos con la inscripción múltiple de dispositivos, tiene que ser individual

Crear directiva de cumplimiento

1. Iniciamos sesión en el portal de Azure con la cuenta administrativa: https://portal.azure.com

2. En la barra de búsqueda de arriba, digitamos Intune y seleccionamos Intune:

image

3. En la página de Microsoft Intune, seleccionamos Device Compliance en el panel izquierdo:

image

4. En la página de Device Compliance, hacemos clic en Policies y luego en Create Policy

image

5. En la página de Create Policy, indicamos un nombre, descripción y como plataforma escogemos Windows 10 and later:

image

6. Hacemos clic en Settings, luego en Device Health, activamos como Require la opción de Require BitLocker y hacemos clic en OK en la parte inferior:

image

7. En la página de Windows 10 complicance policy, hacemos clic en System Settings para expandir otras configuraciones, activamos Firewall y Antivirus y luego clic en OK:

image

En este artículo solo referencié algunas directivas, pero cada organización debe acomodarse a sus necesidades.

8. En la página de Windows 10 compliance policy, hacemos clic en OK

9. En la página de Create policy, hacemos clic en el botón de Create en la parte inferior:

image

10. En la página de la directiva creada, en mi caso Windows Compliance, hacemos clic en el botón izquierdo de Assignments, luego en el botón central de Select groups to include y agregamos el grupo al que pertenezcan los usuarios que están iniciando sesión en los dispositivos a evaluar. Después de esto, hacemos clic en el botón de Save para guardar:

image

Intune hará la evaluación cada 8 horas aproximadamente después de los primeros 30 minutos de haberlo unido al MDM. Mientras eso pasa, es probable que vean los dispositivos en la categoría de Not Evaluated:

image

Lamentablemente, el cuadro anterior es de los que más se demora para actualizarse, así que yo diría que es poco confiable, a menos que se le de el tiempo adecuado.

Si queremos ver el detalle de lo que cumple, no cumple o no aplica, basta con ir a la consola de Intune y hacemos clic en Setting compliance, debajo de la categoría de Monitor. En  el panel central veremos un desglozado de lo que aplicamos como cumplimiento y sus resultados:

image

Aunque personalmente las directivas de cumplimiento en Intune creo que les falta mucho, se pueden utilizar para hacer cosas mucho más interesantes si se unen con el Acceso condicional, pero eso será probablemente para otras entradas del blog.

Espero les sea de utilidad.

—Checho

Inscribir múltiples dispositivos Windows 10 a Microsoft Intune con un paquete de aprovisionamiento

Con la fuerte apuesta de Microsoft a la seguridad y la nube, Microsoft Intune, su plataforma de administración de dispositivos, ha tomado mucha más fuerza, al punto de entrar en el grupo que lidera el cuadrante de Gartner en temas de Unified Endpoint Management, así que se vuelve bastante conveniente empezar a profundizar en todo lo que la plataforma brinda.

Como cualquier otra plataforma de administración, es necesario registrar o inscribir el dispositivo (PC, tablet o móvil) de alguna forma, Intune no es la excepción. Hablando específicamente de Windows, se puede hacer desde el OOBE (manual o a través de Autopilot) o ya en Windows; sin embargo, con el fin de optimizar el proceso para escenarios de muchos dispositivos, es posible configurar un paquete de aprovisionamiento que sirva para unir múltiples dispositivos utilizando un solo token; es decir, sin necesidad de depender de cada cuenta de usuario.

A continuación, les mostraré, paso a paso, cómo podemos crear y desplegar el paquete de aprovisionamiento.

Requerimientos

  1. Todos los equipos deben estar en Windows 10, versión 1703 o superior
  2. Asignar licencia de Intune a la cuenta que se le asociará el token (ver más adelante)
  3. Habilitar la inscripción automática de dispositivos (ver más adelante)
  4. Instalar en un equipo técnico el ADK para Windows 10, versión 1809

Asignar licencia de Intune

Una vez creado el tenant de Intune o EMS (dependiendo del licenciamiento), navegamos hasta el portal de administración de Office 365 e iniciamos sesión con una cuenta administradora: https://portal.office.com/AdminPortal

Una vez en el portal, expandimos el nodo izquierdo de Users y luego clic en Active users

image

Hacemos clic sobre el usuario que deseamos asignarle la licencia de Intune:

image

En la página de usuario que se abre a la derecha, hacemos clic en el botón Edit que está en la parte derecha de Product licenses:

image

En la página de Product licenses, cambiamos de Off a On Intune o Enterprise Mobility + Security:

image

Por último, clic en el botón inferior de Save:

image

Clic en el botón de Close dos veces y cerramos la página de administración de Office 365.

Este mismo procedimiento lo debemos realizar para cada nuevo usuario cuyo dispositivo se vaya a conectar a Microsoft Intune.

Habilitar inscripción automática

1. Iniciamos sesión en el portal de Azure con la cuenta administrativa: https://portal.azure.com

2. Ubicamos y hacemos clic sobre Azure Active Directory en el panel izquierdo:

image

3. En la página de Azure Active Directory, seleccionamos Mobility (MDM and MAM)

image

4. Seleccionamos en el panel central Microsoft Intune

image

5. En la página de Configure, nos aseguramos de seleccionar All en MDM User scope para que todos los dispositivos de usuarios se puedan inscribir a Microsoft Intune:

image

Adicionalmente, pueden habilitar también MAM User scope para administrar los dispositivos móviles, aunque eso hace parte de otros posibles artículos.

En un escenario ideal, seleccionaríamos Some y ahí pondríamos un primer grupo de usuarios de pruebas antes de poder habilitar a toda la organización.

Con esto estamos listos para que los dispositivos con Windows 10 puedan ser administrados por Microsoft Intune.

Crear el paquete de aprovisionamiento

1. En el equipo técnico donde instalamos el ADK para Windows 10, versión 1809, ejecutamos el Windows Imaging and Configuration Designer como administradores

2. En la ventana de Windows Imaging and Configuration Designer, seleccionamos el nodo de Provision desktop devices:

image

3. En la ventana de New project, asignamos un nombre, una descripción (opcional) y hacemos clic en el botón de Finish:

image

4. En la categoría de Set up device, es obligatorio asignar un nombre de equipo. El paquete soporta un par de formatos: %SERIAL% y %RAND%. El primero pone el serial que toma del hardware de la máquina, el segundo asigna un número aleatorio según la cantidad que le demos. Para este caso, yo le pondré: INSIDO-%RAND:4%

image

Es muy importante no ir a asignar un nombre sin estas variables porque entonces todos tratarían de unirse como si fueran el mismo dispositivo y no funcionará.

5.  Hacemos clic en Account Management, seleccionamos Enroll in Azure AD y luego hacemos clic en el botón de Get Bulk Token:

image

6. Seguimos el asistente para iniciar sesión con la cuenta administrativa y obtener el token:

image

6. Si el equipo técnico no está unido a Azure AD, nos aparecerá otra página en donde debemos indicarle en la parte inferior This app only para terminar:

image

Si todo sale bien, nos debe decir «Bulk Token Fetched Successfully»:

image

7. Hacemos clic en el botón Finish y luego en Create para que el paquete compile:

image

8. Si todo sale bien, tendremos un enlace en la parte inferior para nuestro paquete similar a este:

image

Desplegar el paquete de aprovisionamiento

Aunque hay diferentes formas de implementar el paquete de aprovisionamiento, incluso de forma desatendida con PowerShell, lo haré de la forma más simple: copiar el paquete localmente a cada máquina.

1. Una vez copiado en cada equipo, hacemos doble clic sobre el paquete

2. Si nos sale la ventana del UAC, hacemos clic en el botón (Yes)

image

3. En la ventana del paquete de aprovisionamiento, confirmamos que se trate del que creamos y hacemos clic en el botón Sí, agregarlo:

image

Si todo sale bien, el equipo debería reiniciarse solo al momento de aplicarlo (1 min.):

image

4. Al reiniciar el equipo, estará conectado a Azure Active Directory e inscrito a Microsoft Intune. Cada nuevo usuario ya podrá iniciar normalmente con su cuenta profesional:

image

Como dije antes, es necesario que el usuario no tenga restricciones para iniciar sesión con su cuenta de Azure AD y que además tenga su respectiva licencia de Microsoft Intune asignada para poder recibir directivas desde la nube.

Visualizar los equipos inscritos en la consola de Intune

Para estar seguros de que todo salió bien, podemos visualizar los dispositivos inscritos directamente en la consola de Intune:

  1. Navegamos hasta https://portal.azure.com e iniciamos sesión con una cuenta de administrador

  2. En la barra de búsqueda superior, digitamos Intune y hacemos clic en Intune para abrir la consola:

image

  1. En la consola de Intune, hacemos clic en Devices en el panel izquierdo:

image

  1. En la página de Devices, hacemos clic en All devices, debajo de la categoría de Manage

image

  1. Aquí podremos ver todos los dispositivos inscritos correctamente a Intune:

image

Como pueden ver, tengo dos dispositivos con el formato de nombre que puse en el Configuration Designer al momento de crear el paquete.

De aquí en adelante ya podemos empezar a gestionar los dispositivos:  directivas, líneas base, etc. Espero compartir algo de esto en futuros artículos.

Cabe aclarar que con este método de inscripción no funciona el Acceso condicional (Conditional Access) sobre los dispositivos.

Espero sea de utilidad.

—Checho

La pantalla blanca al iniciar PES 2019, Process Explorer, Procdump, Windbg y su solución

Desde los tiempos de Winning Eleven, he sido fiel seguidor de Pro Evolution Soccer (PES), primero en la consola de Play Station y luego en el PC hasta el son de hoy. Aunque ya no lo hago todos los días, con regularidad entro en las noches para jugar un rato después de trabajo. Para mi fortuna, casi nunca tengo problemas con la plataforma de Steam, sin importar que estoy instalando todas las compilaciones que salen del programa de Windows Insider; sin embargo, ayer iba a jugar en la noche y me di cuenta de que el juego no estaba entrando, solo aparecía la pantalla blanca y se cerraba:

image

Después de revisar actualizaciones de Windows y hacer un reinicio del equipo, probé yendo a las propiedades del juego en Steam, pestaña de Local Files y utilicé la opción de Verify itegrity of ame files:

SNAGHTML12e95ca

En principio parece que iba a funcionar porque hace reparaciones si encuentra algo raro, pero la pantalla blanca solo se prolongó por unos segundos más antes de cerrarse inesperadamente otra vez. Como no estaba dispuesto a ponerme a descargar otra vez un juego tan pesado sin saber si solucionaría el inconveniente, decidí ponerme a diagnosticar para intentar encontrar la forma de volver a jugar.

Lo primero que hice fue verificar si el juego se estaba cerrando completamente, para eso abrí Process Explorer, fui al menú de Options, luego Difference Highlighting Duration y lo establecí a lo máximo, es decir, 9 segundos, para poder alcanzar a ver cuáles procesos se cerraban mientras cambiaba entre aplicaciones.

Efectivamente, me encontré con que el juego se estaba cerrando abruptamente después de que desaparecía la ventana en blanco:

image

El otro detalle importante es que también se estaba activando el reporte de errores de Windows, WerFault.exe, que me indicaba que estaba sucediendo un crash de la aplicación:

image

¿Qué estaba impidiendo la ejecución del juego? Pues bien, existen muchos motivos por los que una aplicación puede hacer crash al ejecutarse, incluso diferentes soluciones; una de las formas más productivas para encontrar la causa es obtener un volcado de memoria del proceso en el momento del fallo y proceder a analizarlo con un depurador como Windbg. No es una tarea muy sencilla por lo técnico que puede volverse, pero generalmente solo se necesitan algunos conocimientos básicos para dar con la pista del problema.

Procdump, al rescate

Procdump es una herramienta que hace parte de la suite de Sysinternals y que permite generar volcado de memoria según los parámetros que le indiquemos al proceso que debe de monitorear: excepciones, hangs, etc. Para no complicarme tanto organizando los parámetros, en parte porque no soy muy bueno con la herramienta, opté por utilizar el parámetro –i para instalar el controlador de Procdump indicando la ruta donde quería los volcados para que él mismo me escribiera uno cada que hubiese una excepción en Windows. El comando completo es:

procdump.exe –i C:\Dumps

image

La ruta final puede ser cualquiera, yo traté de mantenerlo simple.

Tan pronto intenté jugar nuevamente, la pantalla se puso blanca, la aplicación se cerró y Procdump hizo lo suyo: crear el volcado de memoria que necesitaba.

image

Windbg

Con el volcado de memoria ya creado, procedí a ejecutar Windbg, abrir el .DMP que había generado el Procdump y finalmente corrí el comando de !analyze –v para que hiciera un análisis automático:

image

Normalmente el análisis que hace Windbg se acerca mucho al controlador o módulo que ocasiona la falla, aunque puede llegar a reportar varios que no están dentro de los símbolos:

image

Lo malo de esto es que muchas veces salen falsos positivos porque indica controladores o componentes propios del sistema operativo como desconocidos.

La forma más fácil de identificar el posible causante es mostrar la pila de ejecución que había al momento del crash y empezar desde la función que le indica a Windows que debe detenerse hacia abajo hasta encontrar controladores o módulos de terceros para analizar con más detalles. En mi caso, encontré dos: NvCamera64 y nvwgf2umx.

image

Windbg permite utilizar el comando lmvm para obtener detalles de cada controlador o módulo. Al ejecutarlo con cada uno, me di cuenta de que pertenecían a NVIDIA:

image

Aunque el primero no tenía la descripción, el segundo, nvwgf2umx, indicaba que era del controlador de D3D10.

Imagino yo que no funcionaba alguna actualización de PES 2019 o la última compilación de Windows, así que mi camino fue ir al GeForce Experience y buscar a ver si existía un nuevo controlador; efectivamente, no hace mucho habían liberado otra versión:

image

Después de hacer una instalación limpia desde el asistente y reiniciar Windows, ejecuté nuevamente el juego y, para mi tranquilidad, todo había vuelto a la normalidad:

image

Una vez más, todo salvado gracias a estas maravillosas herramientas y un poco de investigación.

Saludos,

—Checho

Empaquetar una aplicación de 16 bits a 32 bits con Advanced Installer

Si alguno de ustedes trabaja con implementación masiva de sistemas operativos Windows o ha estado en algún proyecto de migración, seguramente se habrán topado con un escenario inevitable de compatibilidad de aplicaciones, pues suelen ser aplicaciones necesarias para el negocio pero demasiado viejas. Como además las migraciones se hacen a Windows en arquitectura de 64 bits por el aprovechamiento de recursos, se van a encontrar con aplicaciones que funcionan bien en 32 bits, pero que al momento de ejecutarlas en un sistema de 64 bits reciben este tipo de mensajes:

image

Como probablemente sepan, Windows en arquitectura de 32 bits puede ejecutar aplicaciones de 16 bits, pero un sistema a 64 bits solo puede llegar a ejecutar aplicaciones de 32 bits, por lo que las que estén en 16 bits no serán compatibles. Ahora, una aplicación puede tener sus binarios después de la instalación nativamente en 16 bits o bien pueden estar en 32 bits y solamente el paquete de instalación en 16 bits; en el primer caso la única solución es compilar toda la aplicación desde el código en una nueva arquitectura, aunque eso casi nunca se puede hacer por falta de tener el código original. Si es el segundo caso, el camino, como lo voy a mostrar aquí, es construir un nuevo paquete de instalación que esté en 32 bits y pueda ser ejecutado en un sistema de 64 bits con la ayuda de Advanced Installer.

Hay un proceso de mucho más nivel para hacer esto descrito por Aaron Margosis de Microsoft en este artículo, mas no lo seguiré aquí

Requerimientos

1. Tener instalado Advanced Installer en un equipo técnico

Nota: Advanced Installer es un producto licenciado, aunque tiene período de prueba.

2. Tener instalado VMWare Workstation. Se puede hacer con Hyper-V, pero la experiencia no es tan transparente, lamentablemente

3. Instalar una máquina virtual de Windows 10 a 32 bits desde Advanced Installer. Pueden ver el detalle en su página oficial

4. Crear un snapshot de la instalación de Windows de 32 bits en limpio. Si no saben hacerlo en VMWare, pueden ver el procedimiento oficial en su página

Nota: les recomiendo que antes de tomar el snapshot descarguen todas las actualizaciones, deshabiliten internet, notificaciones, antivirus, actualización de aplicaciones, notificaciones y cualquier otra interrupción en el proceso de empaquetamiento

3. Guardar el instalador de la aplicación de 16 bits en el equipo técnico

<

p align=»justify»>4. Descargar Sigcheck de Sysinternals en el equipo técnico

1.0. Instalación manual de la aplicación en equipo de 32 bits

¡Empecemos! Lo primero que tenemos que hacer es instalar la aplicación de 16 bits en el equipo virtual que creamos en el tercer requerimiento para asegurarnos de que el binario que se ejecuta en Windows es, efectivamente, de 32 bits. Como aquí la aplicación será diferente en cada escenario, no mostraré procedimiento de instalación.

1.1. Comprobación de arquitectura con Sigcheck

Una vez instalada, debemos ejecutar Sigcheck e indicarle como único parámetro la ruta completa del ejecutable. Sigcheck nos dirá el MachineType, que corresponde a la arquitectura en la que corre la aplicación:

image

En mi caso, el resultado es 32-bit, así que no es el binario el que está en 16 bits, sino el instalador, tal como lo puedo comprobar corriendo Sigheck con el nombre del instalador:

image

Noten que el MachineType es 16-bit.

Opcionalmente, pueden utilizar la función GetBinaryType de la API de Windows para obtener la misma información, por ejemplo:

SNAGHTML626df8a

Con esto confirmado, ya sabemos que simplemente debemos construir un nuevo instalador que soporte la arquitectura de 32 bits mínimamente para que funcione en ambos, 32 y 64 bits.

2.0. Empaquetamiento de la aplicación utilizando el Repackager de Advanced Installer

2.1. Sobre el Repackaging

El proceso de empaquetamiento es uno de los más interesantes de Advanced Installer: consiste básicamente en monitorear el proceso completo de instalación de una aplicación en conjunto con las configuraciones posteriores para luego empaquetar todos los cambios que hizo en el sistema operativo y, con base en eso, construir un nuevo instalador que hace las mismas operaciones.

Esta característica no está pensada necesariamente para tema de compatibilidad de aplicaciones, sino más bien para mejorar el proceso de instalación de alguna aplicación; sin embargo, sirve muy bien para el propósito de pasar de instaladores de 16 bits a 32 bits sin tener que obtener acceso al código fuente, así que me parece perfecto.

Pueden obtener más información sobre el proceso técnico del Repackager en la web oficial de Advanced Installer.

2.2. Empaquetando

Para empaquetar nuestra aplicación, realizamos los siguientes pasos:

Para poder realizar estos pasos es necesario haber cumplido los requerimientos 3 y 4

Prendemos la máquina virtual que instalamos en el requerimiento 3:

image

Ejecutamos Advanced Installer con privilegios administrativos, vamos a NewConvert y luego doble clic en Repackage Installation:

image

En la ventana de Welcome to the Repackager Wizard, clic en Next

image

En la página de Repackaging Scenario, seleccionamos la segunda opción, Repackage an application in an existing virtual machine, nos aseguramos de que la máquina virtual sea la que creamos en el requerimiento 3 y hacemos clic en Next

image

En la página de Package Information, ubicamos el instalador de nuestra aplicación en el campo de Setup Path como obligatorio y, opcionalmente, modificamos los demás campos como el nombre, versión y empresa para luego dar clic en Next

image

En la página de Customize Settings, dejamos la selección predeterminada y clic en Next para iniciar el empaquetamiento.

image

En la ventana de alerta que nos informa que estamos a punto de empezar, le damos a OK.

image

Veremos que el asistente empieza a informar de varios pasos mientras en la máquina virtual se ejecuta el asistente de instalación de la aplicación con una consola en segundo plano:

SNAGHTML652bebe

Aquí lo único que debemos de hacer es instalar manualmente la aplicación y, si es necesario, ejecutarla para que todos los componentes que debe instalar y registrarse se apliquen correctamente. A parte de eso, si requerimos hacer cambios en Windows o en la aplicación, podemos hacerlos también, pues Advanced Installer capturará casi todo.

Cuando terminemos todo, volvemos al símbolo del sistema, nos aseguramos de que la consola esté capturando nuestro teclado (poniéndola en primer plano) y presionamos INTRO para que termine:

image

Al terminar, la máquina virtual se pausará y volveremos al asistente del Repackager. Ahí hacemos clic en Next para continuar.

image

En la pagína de You have successfully completed the Repackager Wizard, hacemos clic en Finish para abrir el proyecto en Advanced Installer.

image

En la ventana de Advanced Installer de Filter Repackager result, podemos modificar todos los recursos que el asistente capturó para luego darle Import.

image

En la ventana de Repackager, dejamos la primera opción y hacemos clic en Next para poder entrar al proyecto y hacer modificaciones adicionales, si es que lo necesitamos.

image

Nota: pueden darle a Build Package si ya están seguros, pero a mi personalmente me gusta siempre revisar y agregar cosas dentro del proyecto.

image

No entraré en detalles sobre todo lo que se puede hacer dentro de la herramienta porque no es el objetivo del artículo y se haría demasiado extenso (¡más de lo que está!), pero es importante saber que aquí se pueden modificar permisos NTFS, crear accesos directos, modificar archivos y registro, agregar scripts, aplicaciones adicionales a ejecutar antes, durante o después, entre otras.

Al terminar de hacer cualquier modificación, hacemos clic en el botón de Build en el panel superior de herramientas:

image

En el cuadro que nos aparece de Guardar como, escogemos el directorio en donde deseamos que se cree nuestro instalador y clic en Save.

image

En la ventana de Build Project podremos ver el log de la compilación y el acceso directo al .MSI que predeterminadamente se crea:

image

3.0. Prueba de instalación

¡Todo listo! Lo único que nos queda es pasar el instalador a un equipo de 64 bits y proceder a probar la instalación completa de la aplicación:

image

Habrá veces en que diferentes archivos no quedaron en el paquete de instalación, así que habrá que agregarlos (si se saben cuáles son) o bien hacer el proceso nuevamente teniendo cuidado con ejecutar todo lo que se necesite. Afortunadamente, Advanced Installe hace muy bien el trabajo, así que pocas veces tendremos que realizar cambios.

Espero que sea de ayuda.

Saludos,

—Checho

Ransomware y el Acceso controlado a carpetas en Windows 10

Hace unos días escribí un artículo uno de los tipos de ataques relacionados con el robo de credenciales y cómo Windows Defender Credential Guard podía evitarlo. En esta ocasión haré el mismo ejercicio de mostrar una característica nueva de seguridad en Windows 10, pero esta vez enfocado a un tipo de peligro mucho más común: ransomware.

Windows 10 Fall Creators Update introdujo una serie de características de seguridad agrupadas en una categoría llamada Windows Defender Exploit Guard, que a su vez viene siendo el remplazo mejorado de lo que antes se conocía como EMET, pero ya integrado en Windows. Una de las categorías de Exploit Guard es Controlled Folder Access o Controla el acceso a la carpeta, como está traducido al español (algo rara esa traducción, por cierto). Cada aplicación que se ejecute es evaluada por Windows Defender; si determina que es maliciosa o no confiable, es decir, sospechosa, impide que haga modificaciones a cualquier archivo que esté dentro de las carpetas protegidas. Aunque está pensado para cualquier aplicación maliciosa que intente escribir, es especialmente útil para combatir el ransomware, pues si las aplicaciones no pueden modificar nuestros archivos, tampoco podrán, obviamente, proceder a cifrarlos para pedir recompensas.

Predeterminadamente, Controla el acceso a la carpeta agrega las carpetas más comunes en donde el usuario puede almacenar información a las carpetas protegida; estos directorios no se pueden modificar:

image

Antes de entrar en detalle sobre cómo habilitar la característica y configurar las opciones que Windows nos provee a través de directivas de grupo, hagamos una simulación sobre lo que podría pasar en las carpetas con datos importantes.

Jugando a ser ransomware: MalFile.exe

Para poder probar con calma Controla el acceso a carpeta, decidí escribir una pequeña aplicación en C utilizando algunas API de Windows para crear y cifrar archivos. El cifrado está basado en Cryptography API: Next Generation (CNG), de Microsoft, por si están interesados.

Pueden ver el código fuente y la versión 1.0 de esta aplicación en caso de que quieran hacer las mismas pruebas: https://github.com/SergioCalderonR/MalFile/releases 

Si utilizamos el parámetro –ef, la aplicación tomará un archivo de texto plano como primer argumento, leerá el contenido, cifrará el contenido y lo guardará en el archivo que indiquemos como segundo argumento con cualquier extensión. Además de esto, la aplicación eliminará el archivo fuente, así que solo quedará el que está cifrado. En otras palabras, estoy tratando de jugar a ser ransomware.

Ahora, en mi escenario tengo una carpeta llamada C:\Info y allí, un archivo Confidential.txt que tiene texto plato:

image

MalFile.exe necesita tres parámetros para cifrar: –ef, la ruta del archivo a cifrar y la ruta del archivo cifrado con cualquier extensión o bien en texto plano (.txt).

Suponiendo que la aplicación fuera un ransomware, el ataque se podría efectuar sin ningún problema, pues para hacer cifrado ni siquiera se necesitan privilegios administrativos. Yo voy a simular el ataque enviándole los parámetros y cifrando el archivo con extensión .neu, así:

MalFile.exe –ef C:\Info\Confidential.txt C:\Info\Encrypted.neu

image

Noten que la aplicación indica, paso a paso, todo lo que se hizo sobre el contenido del archivo y que elimina el archivo original (para fines de demo, pues no sería lo que haría un ransomware).

Si abrimos el archivo con un bloc de notas, vamos a ver todo el contenido cifrado y una pequeña descripción que aparecerá en texto plano:

image

El texto que no aparece cifrado es porque la función CryptProtectData de la API de Windows permite agregarlo para que viaje con el contenido, pero no lo cifra.

Siendo un verdadero ransomware, no sería un solo archivo, sino múltiples y estaríamos ya preocupados por no poder tener la información.

Protegiendo las carpetas importantes activando Controla el acceso a carpeta

Como mencioné al principio, Controla el acceso a carpeta o Controlled Folder Acces en inglés permite restringir las operaciones de escritura sobre archivos que estén en las carpetas protegidas, así que el ransomware o cualquier otro archivo malicioso no podría actuar, a menos que logre ser confiable dentro de la base de datos de Microsoft. Veamos qué pasa cuando tratamos de hacer el ataque anterior con la característica activada.

Primero, abrimos el Centro de seguridad de Windows Defender desde el menú de inicio:

image

En el Centro de seguridad de Windows, hacemos clic en Protección antivirus y contra amenazas:

image

En la página de Protección antivirus y contra amenazas, clic en Configuración de antivirus y protección contra amenazas:

image

Luego bajamos y activamos deslizando a la derecha para activar Controla el acceso a la carpeta:

image

A menos que el directorio que deseamos proteger esté en alguna ubicación predeterminada de usuario (documentos, imágenes, etc), hacemos clic en Carpetas protegidas:

image

Finalmente, hacemos clic en Agregar una carpeta protegida, navegamos hasta el directorio raíz y aceptamos para que quede dentro de la lista de Controla el acceso a la carpeta:

image

Aceptamos el UAC y listo, nuestra carpeta estará protegida.

Como dato adicional, también pueden agregar la carpeta desde PowerShell así:

Add-MpPreference –ControlledFolderAccessProtectedFolders [CarpetaProtegida]

Donde [CarpetaProtegida] hace referencia al directorio que va a protegeer Controla el acceso a la carpeta de Windows 10. En mi caso, quedaría así:

 Add-MpPreference –ControlledFolderAccessProtectedFolders C:\Info

image

De cualquiera de las dos formas deberíamos ver nuestra carpeta en la lista:

image

Aunque no lo indicaré en este artículo, también se puede habilitar la característica a través de directivas de grupo, incluso podemos usar un modo de auditoría para no afectar a las aplicaciones sin estar seguros de que todo funcionará.

¿Qué pasa ahora cuando una aplicación malitencionada intente hacer algo?

Jugando a ser ransomware: revancha

Utilizando MalFile, voy a probar dos escenarios: creación de archivos y cifrado de archivos. La diferencia es que ahora los archivos están protegidos.

Para crear un simple archivo de texto plano basta con usar el parámetro –nf junto con la ruta y extensión. Si intento crear un archivo en la carpeta C:\Info, esto es lo que pasa:

image

El manejador de errores de Windows está devolviendo un código de error 2, que es cuando no puede encontrar el archivo especificado. Esto es porque en el código estoy utilizando la función de CreateFile, que sirve para abrir o crear archivos. En un funcionamiento normal, independiente de que el archivo exista o no, debería crearlo desde cero, pues eso es lo que explícitamente le pedí cuando la escribí:

image

Ignoro por qué no devuelve un error diferente, pero puede indicar que solo permite hacer las operaciones de lectura. A parte de devolver el error y no permitir hacer la escritura, Windows Defender muestra una notificación al usuario del bloqueo similar a la siguiente:

image

Supongamos que tenemos nuestro archivo Confidential.txt con información importante y hasta ahora sano y salvo en la carpeta segura y lo intento cifrar usando de nuevo el parámetro de –ef, así:

MalFile.exe –ef C:\Info\Confidential.txt C:\Info\Encrypted.tulpep

image

La aplicación puede leer los datos, pasarlos a otro buffer para cifrarlos, pero no puede escribir en la misma carpeta otra vez, así que el archivo continuará intacto. También veremos la notificación por parte del Centro de seguridad de Windows Defender.

También podríamos suponer que dejando leer los datos, podríamos cifrarlos y luego escribirlos nuevamente, esto sería posible si como segundo parámetro le indicamos el mismo archivo fuente, así:

MalFile.exe –ef C:\Info\Confidential.txt C:\Info\Confidential.txt

Sin embargo, Controla el acceso a la carpeta también evita que un proceso no confiable pueda escribir sobre el mismo archivo:

image

Como pueden ver, Windows devuelve Acceso denegado. Interesante, ¿no?

Permitir acceso a aplicaciones manualmente

Desde que sea una aplicación comercial o esté firmada digitalmente, no deberían tener problemas para modificar archivos en la carpetas protegidas; sin embargo, habrá excepciones que encontrarán en el camino. Afortunadamente Windows Defender permite solventar esto, basta con devolvernos a la pantalla de Protección antivirus y contra amenazas y en vez de hacer clic en Carpetas protegidas, hacemos clic en Permitir que una aplicación acceda a una de las carpetas controladas:

image

Luego hacemos clic en Agregar una aplicación permitida, buscamos el ejecutable y aceptamos:

image

Después de esto, así esté habilitado Controla el acceso a carpeta permitirá la escritura sin problemas:

image

Hay un poco más de contenido sobre este tema, pero con esto es suficiente para conocer la característica y experimentarla.

Espero sea de utilidad.

Saludos,

—Checho
Follow me on Twitter

Pass-The-Hash y Windows Defender Credential Guard en Windows 10

Desde el lanzamiento de Windows 10, Microsoft ha hecho enormes esfuerzos por mejorar la seguridad de la plataforma en diferentes frentes agregando más y más características en cada compilación, trabajo que va teniendo frutos, pues se ha convertido el sistema operativo Microsoft más seguro de todos.

Como vale la pena ir conociendo cómo implementar estas nuevas características, iré escribiendo, conforme pueda y sepa, lo que aprendo por aquí por si alguien más desea hacer pruebas en sus respectivas empresas. Por supuesto, todas las correcciones serán más que bienvenidas.

Una de las nuevas características de seguridad se llama Credential Guard, que básicamente utiliza seguridad basada en virtualización para aislar secretos que puedan llevar a ataques de robo de credenciales. Los secretos se protegen y almacenan en un nuevo componente llamado Insolated LSA; la comunicación con el proceso de LSA se hace a través de RPC. Básicamente previene los ataques protegiendo los hashes de las contraseñas NTLM, Kerberos y las contraseñas de dominio almacenadas en el Credential Manager. Pueden obtener más información del sitio oficial.

Pass-The-Hash es un ataque que utiliza una técnica para obtener los hashes de las contraseñas y reutilizarlos para autenticarse a través de la red en otros equipos hasta lograr ganar privilegios con una cuenta de Active Directory.

Veamos qué tan fácil puede llegar a ejecutarse un Pass-The-Hash en Windows 10 y cómo Windows Defender Credential Guard nos puede ayudar a prevenirlo.

Ejecutando un ataque de Pass-The-Hash

Antes que nada, por si desean seguir el ataque, esto es lo que necesitamos:

1. Mimikatz. Lo pueden descargar desde aquí: https://github.com/gentilkiwi/mimikatz/releases

2. PsExec. Lo pueden descargar desde aquí:
https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

3. Entorno de directorio activo

4. Equipo cliente unido al dominio para probar

Notas:

  • Cabe aclarar que obviamente necesitaremos cuentas de dominio con diferentes privilegios para probar.
  • Es probable que deban darle permisos desde el antivirus al Mimikatz, pues normalmente lo bloquean.

Primer paso: obtener el hash NTLM de las contraseñas con Mimikatz

Para poder extraer el hash de las contraseñas de un equipo, cada cuenta de dominio tuvo que haberse conectado de alguna forma, pues al cerrar sesión ya no es posible que Mimikatz cree el hash, así que no lo mostraría en la consola.

No sé si sea diferente con otra aplicación; en mi caso, aunque pude extraer el NTLM hash después de cerrar sesión con otras cuentas, el ataque de Pass-The-Hash no funcionaba correctamente.

Ahora, para mi escenario tengo dos cuentas con las que voy a jugar: Sergio y Andy; la primera, Sergio, es una cuenta de dominio que solo es administradora en el equipo local (no estoy teniendo en cuenta aquí lo de ganar privilegios locales), mientras que la segunda, Andy, es una cuenta que tiene privilegios locales sobre todas las máquinas, incluyendo el controlador de dominio.

Si yo intento hacer conexión utilizando PsExec desde mi cuenta de Sergio, no podré hacerlo por ser una cuenta estándar, más allá de tener privilegios administrativos locales:

SNAGHTML14d1dec7

Afortunadamente, Andy está conectando al equipo, pero necesitamos obtener y reutilizar ese hash para nuestro ataque.

Desde una cuenta local o de dominio con privilegios administrativos en la máquina ejecutamos Mimikatz como administrador:

image

Lo primero es solicitar privilegios a Windows de depuración ejecutando:

privilege::debug

image

Una vez adquiridos los privilegios, es decir, que la consola responda con un OK, vamos a extraer toda la información sobre las contraseñas que están en memoria con el módulo de sekurlsa:

sekurlsa::logonpasswords

image

Inmediatamente veremos datos para todas las cuentas que estén conectadas, incluyendo el más importante para este dato que sería el hash NTLM:

image

Por supuesto, nosotros no estamos interesados el usuario de Sergio, sino en el de Andy. Mimikatz, como dije, me da también el hash de la contraseña correspondiente, siempre y cuando tenga una sesión abierta:

image

Noten que el campo de contraseña lo muestra en nulo porque la forma en que se almacenan en Windows 10 difiere de Windows 7 y anteriores, así que no la podemos ver. Si estuviésemos en un Windows 7, habríamos obtenido la contraseña sin problemas.

Como pueden ver, ya tenemos el hash NTLM y eso es todo lo que necesitamos para autenticarnos a través de la red como Andy.

Segundo paso: realizar el ataque de Pass-The-Hash con el hash obtenido

Desde Mimikatz, lanzamos nuestro ataque de Pass-The-Hash con los datos que ya tenemos:

sekurlsa::pth /user:andy /domain:winside.local /ntlm:a87f3a337d73085c45f9416be5787d86

image

Nota: obviamente los datos en usuario, dominio y NTLM van a ser diferentes en cada escenario, pero dejo el comando de forma ilustrativa.

Lo que va a pasar aquí es que Mimikatz va a lanzar el cmd con una identidad falsa, Windows va a creer que era el usuario actual, es decir, Sergio en este caso, pero va a utilizar el hash de la contraseña del usuario de Andy:

image

Nuestro último paso es simplemente utilizar la consola que se nos abrió para autenticarnos en las próximas máquinas como Andy. Por ejemplo, utilizando PsExec nuevamente sobre el controlador de dominio:

PsExec \\LEO cmd.exe

Si le doy un whoami, van a ver que estoy conectando como Andy, gracias a que reutilicé el hash de la contraseña almacenada en memoria de mi equipo:

SNAGHTML14e3f7a6

Suponiendo que logre burlar la seguridad para ejecutar Mimikatz, yo podría, por supuesto, seguir obteniendo el hash NTLM de las credenciales locales hasta llegar a un usuario que tenga realmente poderes sobre el dominio:

image

Implementando Windows Defender Credential Guard

La implementación de Credential Guard es relativamente sencilla, basta con cumplir los requerimientos en las máquinas físicas o virtuales y proceder a desplegarlo a través de una directiva de grupo, manualmente (Registro de Windows) o con un script de PowerShell liberado por Microsoft.

Para mayor claridad, crearemos la GPO para Credential Guard desde cero.

Nos conectamos a la consola de administración de directivas de grupo y creamos la GPO en la OU que corresponda:

image

Yo la llamaré Credential Guard Policies.

image

Hacemos clic derecho sobre la GPO, editamos y navegamos hasta:

Computer Configuration\Policies\Administrative Templates\System\Device Guard

Allí hacemos doble clic sobre la plantilla de Turn On Virtualization Based Security

image

En la plantilla, clic en Enabled, y debajo de Credential Guard Configuration seleccionamos la opción de Enabled with UEFI Lock, esto es para que remotamente no se pueda deshabilitar, pues está protegido por UEFI.

image

Nota: para fines de prueba pueden utilizar la de Enabled Without Lock.

Actualizamos directivas de grupo en el equipo cliente y reiniciamos.

Después de reiniciar, ejecutamos Msinfo32 y verificamos que en la parte inferior la característica de Virtualization Based Security esté en ejecución y lo demás haga referencia a Credential Guard:

image

En caso de que esté habilitado pero no en ejecución, es necesario habilitar manualmente la característica de Hyper-V Hypervisor desde Activar o desactivar características de Windows y reiniciar nuevamente:

image

Obteniendo el hash de las contraseñas con Credential Guard habilitado

Después de que Windows Defender Credential Guard esté habilitado y funcionando, podemos intentar nuevamente utilizar Mimikatz o cualquier otra herramienta que obtenga el hash NTLM de las cuentas y nos encontraremos con algo completamente diferente:

image

Como pueden ver, ya no tengo forma de obtener el hash porque ahora Windows, utilizando la tecnología de seguridad basada en virtualización, más específicamente la de Insolated User Mode, está protegiendo los secretos (credenciales) para que solo unos binarios autorizados puedan llegar a ellos. Si no tengo el hash NTLM, naturalmente, no puedo hacer el ataque de Pass-The-Hash en las máquinas.

Credential Guard está disponible solo en ediciones Enterprise y Education de Windows 10.

Espero sea de utilidad y pueda seguir compartiendo otras tecnologías nuevas de seguridad en Windows 10.

Saludos,

—Checho