[¿Bug o no?] La lista empresarial no reconocida por Microsoft Edge en Windows 10, ProcMon, ProcExp y su solución

En Windows 8.1 Update, Internet Explorer 11 introdujo una nueva característica llamada: Modo Empresa, que básicamente permite emular gran parte de Internet Explorer 8 con el fin de que las aplicaciones antiguas, que solo funcionaban en esta versión del navegador, se pudieran utilizar en IE11 y de esta forma se facilitara la migración de sistema operativo. Debido a la buena acogida y realimentación que ha tenido la característica, se integró otro modo de emulación para Internet Explorer 7 y Modos de Documentación adicionales que por supuesto ampliaba más la compatibilidad hacia atrás. Pueden ver un poco más sobre esta característica en el artículo que escribí para el blog de Tulpep

Windows 10, a parte de seguir soportando Internet Explorer 11, tiene un foco específico en su nuevo navegador llamado Microsoft Edge, desarrollado desde cero y muy enfocado al consumidor soportando los últimos estándares, mucho más rápido que otros navegadores del mercado y sobre todo fácil de utilizar:

2015-08-12_17-57-59

En el lado empresarial, Edge tiene una cantidad de Directivas de Grupo, y una de las características más interesantes es que la herramienta de Microsoft para crear la lista empresarial del Modo Empresa se ha actualizado, con el fin de indicarle a Microsoft Edge qué sitios debe abrir obligatoriamente con Internet Explorer, así se ejecuten desde el nuevo navegador. Es una característica muy prometedora, pero lamentablemente no me logró funcionar como debía, así que en vez de mostrarles cómo configurarla, resulté escribiendo este post exponer lo que hasta ahora no sé si se puede catalogar como bug o no.

*Nota: Una vez esté completamente seguro que la característica se puede configurar sin necesidad de hacer lo que expondré a continuación, intentaré sacar el tiempo para escribir un artículo paso a paso concentrándome solo en eso y no en el problema como en esta ocasión.

El problema

Básicamente, existe ahora una directiva de grupo para Microsoft Edge llamada: Permite configurar la lista de sitios empresariales; utiliza un XML creado con la herramienta de Enterprise Mode Site List Manager para generar una lista de sitios que Edge debe obligatoriamente abrir con Internet Explorer.

2015-08-12_18-08-00

La directiva está ubicada en:
Configuración de Equipo/UsuarioPlantillas AdministrativasComponentes de WindowsMicrosoft Edge.

Yo, con toda la expectativa, descargué la actualización de la herramienta Enterprise Mode Site List Manager desde el sitio de Microsoft y agregué el sitio de la empresa en que trabajo (tulpep.com) para probar la característica; lo único diferente a lo que se hacía en Internet Explorer, es que ahora se marca una casilla de Open in IE para que Edge sepa que debe pasárselo a su antecesor. Así se ve:

2015-08-12_18-16-52

Luego de esto, guardé el XML como Sitios.xml y lo guardé en C:Sitios. En la directiva debía especificar esta ruta:

image

Lo siguiente era solo actualizar las directivas (GPUPDATE), abrir Edge e ingresar el sitio para que hiciera la redirección, pero desafortunadamente nada pasó y el navegador abrió la página común y corriente:

image

Aquí empecé a preguntarme: ¿Qué pasó? ¿Por qué no abrió con IE? ¿Qué hice mal? Procedí entonces a crear otra vez el XML, actualizar la directiva a incluso reiniciar Windows, pero ningún resultado positivo. Pude también escalar el tema a un primer contacto del equipo de Microsoft Edge, pero sin solución y por ese lado todavía estoy esperando si llego a instancias más altas.

Como no quería permanecer de brazos cruzados, decidí ir un poco más allá y tratar de diagnosticar el problema yo mismo.

La causa

Para saber porqué la lista empresarial no estaba funcionando con Edge, debía tratar de entender un poco más qué estaba sucediendo por debajo, y para eso no hay otro camino más fructífero que recurrir a las herramientas de Sysinternals.

Lo que hice fue cerrar Edge, ejecutar Process Monitor, limpiar la primera traza con CTRL + X, lanzar Edge, entrar a Tulpep.com y después de que no sucediera el comportamiento esperado volví a Process Monitor para detenerlo y empezar a analizar los resultados.

Como no sabía realmente por dónde empezar, recurrí al camino más lógico y era ver qué estaba sucediendo con el archivo Sitios.xml. Esto fue lo primero que encontré:

image

Edge estaba consultando el contenido de un valor llamado SiteList y que estaba ubicado en la sub-clave:
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftMicrosoftEdgeMainEnterpriseMode

Esta sub-clave en realidad no es nueva, pues a diferencia del nombre (MicrosoftEdge), es exactamente la misma que utiliza Internet Explorer al activar el Modo Empresa. Ese valor de registro contiene la ruta al XML que debe utilizar el navegador para leer los sitios y su respectiva configuración; en otras palabras, es el reflejo de la directiva que se creó.

Para este caso, el resultado era SUCCESS, así que podía acceder a la ruta del XML:

image

Con esto pude asegurarme que la directiva se estaba creando correctamente y el navegador sí buscaba el XML… ¿por qué no usaba la configuración entonces?

Seguí buscando en Process Monitor por los resultados que arrojara el XML, pero obviando ya las operaciones sobre la sub-clave de registro mencionada, pues estaba correcta. Para mi fortuna, encontré lo que sería la clave de todo esto:

image

Como ven, el proceso de Microsoft Edge estaba tratando de realizar una operación a nivel de sistema de archivos (CreateFile) con el XML, pero el resultado era ACCESS DENIED; es decir, por alguna razón el navegador no estaba pudiendo acceder libremente al archivo.

Debido a que la operación CreateFile en Process Monitor no siempre refleja el nombre, es decir, crear un archivo, era necesario ver un poco más de detalles para entender qué intentaba hacer así que procedí a hacer doble clic en el evento para ver las propiedades:

image

La disposición era de Open, así que Edge estaba intentando abrir el archivo y recibía un acceso denegado. ¿Por qué?

Obviamente, lo primero que pensé es que mi usuario no tenía permisos NTFS para acceder al archivo, así que fui a las propiedades de la carpeta Sites que había creado y agregué explícitamente mi usuario con todo el control:

image

Lo siguiente era cerrar Edge, volverlo a ejecutar e intentarlo otra vez. Con toda la esperanza lo hice, pero desafortunadamente el navegador seguía abriendo la página en vez de enviarla a Internet Explorer.

Volví entonces a reiniciar Process Monitor y reproducir el comportamiento para saber qué resultados obtenía; para mi mala fortuna, aún era ACCESS DENIED:

image

Este fue el momento más confuso para mi, pues no podía entender cómo dándole permisos explícitos al usuario aún recibía el acceso denegado… entonces recordé algo que Windows integró desde los tiempos de Vista: ¡Los niveles de integridad!

Un nivel de integridad hace parte del mecanismo de integridad que tiene el sistema operativo, y se asigna a procesos de aplicaciones o a objetos (como archivos, carpetas, etc) para representar su confianza. Desde Windows Vista, han existido 6 niveles de integridad: Untrusted, Low, Medium, High y System; siendo Untrusted el más bajo y por supuesto System el más alto de todos.

*Nota: Normalmente interactuamos solo con: Low, Medium, High y System.

Básicamente, un proceso no podría llegar a leer o modificar un objeto que tenga un nivel de integridad superior. El caso más concreto lo tiene Internet Explorer cuando Windows tiene activado el UAC y el Modo Protegido no se ha bajado; de esta forma, el navegador siempre está ejecutándose con nivel de integridad Low, así que nunca podrá por sí solo ejecutar o guardar archivos maliciosos en directorios protegidos de Windows, sino en sus propios directorios temporales.

Es importante tener en cuenta que un proceso podría escribir sobre un objeto que tenga nivel de integridad igual o menor que él; es decir, System puede escribir en todos, pero Medium solo podría sobreponerse a un objeto que tenga el mismo nivel o que esté en Low.

Este mecanismo de seguridad no es fácilmente administrable y es el sistema operativo el que se encarga de la gestión.

*Nota: Trataré, cuando mis conocimientos me lo permitan, de escribir un post completo para explorar los mecanismos de integridad en Windows con ejemplos prácticos.

Volviendo al caso, yo supuse que Microsoft Edge estaba corriendo con un nivel de integridad Low y eso explicaría por qué no podía leer desde un directorio de Windows o de usuario que tiene Medium. Para asegurarme, ejecuté Process Explorer, habilité la columna de Integrity Level y procedí a abrir Edge para investigar para encontrarme con esto:

image

Tal como ven en la captura, el nivel de integridad (el último dato de la derecha), era nada más y nada menos que AppContainer. En principio no entendía mucho, pero después de un poco de búsqueda, encontré que las aplicaciones de interfaz moderna corren todas con este nivel de integridad especial y, al parecer, es un poco más bajo que Low.

El explorador de archivos ejecuta por su parte con un nivel de integridad Medium:

image

A pesar de que es una característica, parece que Microsoft Edge no sabe cómo lidiar con su propio dilema de seguridad, pues a diferencia de IE, no es posible desactivar el modo protegido para que el nivel de integridad sea Medium también.

En un principio pensé que estableciendo manualmente el nivel de integridad tanto de la carpeta como del archivo  Low podría hacerlo funcionar, pero al parecer debe ser explícitamente a AppContainer para que sea equivalente.

La solución

Yo no quería rendirme así, tan cerca del objetivo. Después de pensar por un buen rato, me di cuenta que naturalmente Microsoft Edge requería escribir en al menos un directorio del sistema operativo, así que esa carpeta muy seguramente tenía el mismo nivel de integridad y por ende podría leer todos los archivos que residieran ahí sin problemas.

Para encontrar el directorio, volví a Process Monitor y empecé a buscar por lo más básico que pensé, y era alguna carpeta que se llamara Temp, obviamente a nivel de sistema de archivos y que el proceso fuera MicrosoftEdge.exe. Esto fue lo que encontré:

image

Existía un directorio llamado Temp ubicado en:
C:UsersAndyAppDataLocalPackagesMicrosoft.MicrosoftEdge_8wekyb3d8bbweAC

Supe que este era el indicado, puesto que en las propiedades el Acceso Deseado (Desired Access) era Generic Read/Write, Delete, además de Create como Disposition y todo había tenido un resultado de SUCCESS. En otras palabras, Microsoft Edge tenía total libertad de leer, escribir y eliminar archivos en ese directorio.

Para ver que mi teoría era cierta, hice lo siguiente:

1. Copié el archivo Sitios.xml que le indicaba los sitios a Edge que debía mandar para que se abrieran con Internet Explorer en la ruta ya mencionada:

image

2. Acto seguido, actualicé la directiva de grupo para que apuntara al XML en la nueva ruta:

image

3. Actualicé nuevamente las directivas locales ejecutando: gpudate /force

image

4. Por último, cerré completamente Edge.

Para mi gran fortuna, cuando abrí nuevamente Edge y le introduje el sitio Tulpep.com, el milagro sucedió:

image

¡La característica esta funcionando como debía ser! Todos los sitios que estaban en el XML se abrían de forma automática con IE cuando se lanzaban desde Microsoft Edge.

Desafortunadamente con rutas de red no logré hacerlo funcionar, así que por ahora la única forma es tener el XML local en un directorio que Microsoft Edge pueda utilizar libremente.

Las preguntas para todos los que se tomen el trabajo de leer esto: ¿Qué opinan? ¿Creen que sea un bug?

¡Comentarios bienvenidos!

*Nota: Si en algún momento tengo respuesta oficial por parte de Microsoft, actualizaré la entrada para hacérselos saber.

Checho

3 comentarios en “[¿Bug o no?] La lista empresarial no reconocida por Microsoft Edge en Windows 10, ProcMon, ProcExp y su solución”

  1. Hola:

    ¿Podrías definir segura? porque una ruta de red no es, y localmente también está soportado por implementación. No lo mostré en el post, pero tampoco funcionó en una ruta por usuario y la prueba de red de igual forma la hice. Créeme, hice bastantes cosas antes de escribir el artículo.

Responder a checho Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *