Buen día,% username%!
En cualquier empresa grande (y no solo en una grande), las personas desean tener acceso a la información corporativa (correo de trabajo, calendario, recursos internos) en cualquier momento y de la manera más simple posible. Se han creado soluciones separadas llamadas Mobile Device Management para proporcionar y administrar estos accesos.
Históricamente, hemos utilizado diferentes soluciones para administrar dispositivos móviles en nuestra empresa. Al principio, era una solución diseñada para un fabricante específico, luego cambiamos a otro producto que nos permitía admitir dispositivos iOS y Android. Posteriormente, se decidió cambiar a una solución de Microsoft.
Microsoft Intune
En el momento de analizar la funcionalidad de la solución, la versión en la nube proporcionaba una lista bastante pequeña de características, por lo que se decidió utilizar Intune Hybrid.
¿Qué es un híbrido Intune?
Este es el viejo y bueno System Center Configuration Manager, integrado con Microsoft Intune. Esta solución tiene sus propias características:
- Toda la administración de dispositivos móviles se realiza a través de SCCM.
- Todas las políticas y configuraciones de seguridad se crean y administran a través de SCCM.
En general, la administración de dispositivos móviles no se ha diferenciado de la administración de estaciones de trabajo. La parte de la nube se usa solo para la comunicación entre dispositivos y SCCM.
Junto con la decisión de cambiar a MS Intune, se hizo necesario transferir a todos los usuarios a la nueva plataforma. Desafortunadamente, solo teníamos 5 meses para migrar y 28,000 usuarios en todo el mundo.
Para empezar, se utilizó el enfoque menos destructivo para la migración y se aconsejó a los usuarios que reconfiguraran los dispositivos para trabajar con el nuevo servicio.
Este enfoque dejó de funcionar en un momento determinado, y los usuarios comenzaron a verse obligados a desconectarse del servicio anterior con un bloqueo paralelo de la capacidad de configurar el dispositivo. Esto creó ciertas dificultades y una carga adicional en el servicio de escritorio. El gráfico de incidentes abiertos en el servicio de dispositivos móviles muestra claramente el período de la migración más activa.
Afortunadamente, la transición fue exitosa, a tiempo y sin problemas inesperados.
¿Cómo es la vida en Marte con Microsoft Intune?
Durante la migración, fue bastante difícil para todos los equipos de soporte adaptarse, ya que la funcionalidad para administrar dispositivos móviles era mucho más amplia y más conveniente que en SCCM. Pero al sacrificar cierta cantidad de funcionalidad, obtuvimos una estabilidad significativamente mayor del servicio y menos incidentes en general. A modo de comparación, con la solución anterior para 28,000 usuarios, tuvimos alrededor de 700 incidentes por mes, pero ahora el nivel se mantiene en ± 350 incidentes.
Con los nuevos lanzamientos de SCCM, Microsoft está agregando nuevas funcionalidades y espero que continúen invirtiendo en una solución híbrida.
¿Qué hay de nuevo?La migración al nuevo producto también proporcionó nuevas funciones de control de acceso, ya que Intune es solo una parte del servicio Enterprise Mobility + Security. Las características más importantes e interesantes para nosotros son el
acceso condicional y
la administración de aplicaciones móviles .
El acceso condicional es una política de control de acceso al servicio. Digamos que un usuario quiere conectarse desde un teléfono personal a Exchange Online. La política de acceso requiere que su dispositivo esté ejecutando Microsoft Intune para acceder a EXO. Si este usuario intenta configurar el buzón a través de la aplicación de correo estándar en iOS, verá solo un mensaje: "El administrador requiere que el dispositivo se controle a través de Microsoft Intune". Del mismo modo, puede controlar el acceso a cualquier aplicación registrada en Azure AD.
Mobile Application Management es la gestión de datos corporativos dentro de la aplicación. Es esta configuración la que determina si es posible guardar documentos de trabajo en la memoria del teléfono, copiarlos en aplicaciones de terceros, etc.
Ambas funciones permiten una configuración flexible e indolora del usuario de la configuración de seguridad.
Migración a Intune Standalone
Después de interesarnos por las nuevas soluciones de Microsoft, en particular la gestión conjunta y el piloto automático, nos dimos cuenta de que era necesario cambiar a una solución totalmente basada en la nube (la llamada Intune Standalone).
En el momento de la decisión, Microsoft ya había publicado instrucciones paso a paso sobre la migración de usuarios de SCCM a Intune Standalone:
- Exporte configuraciones de SCCM e impórtelas a Intune.
- Migración de usuarios de prueba.
- Migración de todos los usuarios.
- Cambie MDM Authority de SCCM a Intune.
En la etapa de exportación / importación,
se utilizó una
solución de Microsoft . Desafortunadamente, la importación no fue muy bien y no solo se migraron aplicaciones específicas de SCCM, sino todos los tipos de implementación, creando aplicaciones separadas en Intune.
Se parecía a esto:
Además, por alguna razón, la versión de la aplicación tampoco se importó correctamente y debido a esto, fue necesario publicar todas las aplicaciones manualmente. Con esta configuración y las políticas se migraron sin ningún problema.
Prueba de migración grupalInicialmente, el grupo de prueba estaba formado por mis colegas y yo. Temíamos que los usuarios pudieran notar que estaban migrando. Esto podría provocar una ola de llamadas al servicio de escritorio. Pero las pruebas mostraron que, en ausencia de una diferencia en las configuraciones y aplicaciones publicadas, los usuarios no notan nada.
¿Cuál fue el mecanismo de migración? El usuario requerido se eliminó de la colección SCCM, que se utilizó en la configuración de suscripción de Intune. Esto se hizo a través de una colección exclusiva, que, a su vez, estaba vinculada a un grupo en Active Directory. En consecuencia, para migrar al usuario, solo necesita agregarlo al grupo AD necesario.
Pero inesperadamente, hubo problemas al proporcionar acceso a la mesa de servicio para administrar los dispositivos migrados. Creé un papel especial, que solo tenía los derechos necesarios para sus tareas. El rol se asignó al grupo necesario, pero el acceso para algunas personas no apareció. Se verificaron las licencias de analista y sus cuentas, pero todo fue en vano. La comprobación de los roles efectivos a través de Graph API mostró que existe un rol, pero la persona aún no tenía acceso. Después de una larga investigación, junto con el soporte de Microsoft, se descubrió que era necesario una licencia (Intune en EMS E3 o EMS E5) para los analistas. Y también, los analistas, a su vez, necesitan ser migrados a Intune Standalone. La necesidad no estaba documentada y tardó un par de semanas en resolverse.
Al mismo tiempo, atraje a un grupo de representantes de ventas de un país europeo a la migración que utilizan activamente el servicio VPN en su trabajo diario y corren alrededor de la migración en sí, así como el
servidor configurado por separado para NDE independiente de Intune. Fue en este paso que la migración casi se canceló con el regreso de todos los usuarios.
Para que el usuario pueda utilizar el servicio VPN, se le entrega un perfil que configura el cliente VPN utilizando el certificado SCEP especificado, que se refiere a la CA raíz. En consecuencia, un par de certificados deben estar presentes para la operación.
Solo teníamos un certificado (Root CA).
Lo más simple es asumir que el problema está en el servidor NDES. Pero funcionó a la perfección y ni siquiera recibió solicitudes de certificados. Al examinar los registros de los propios dispositivos, descubrí que el dispositivo ni siquiera recibió la configuración necesaria para solicitar un certificado SCEP. Microsoft amplió este problema a los desarrolladores de Intune que descubrieron la importancia de tener no solo todos los certificados, sino también la necesidad de entregar todos los certificados y configuraciones a los mismos grupos de usuarios y dispositivos. En nuestro caso, Root CA se entregó a todos los dispositivos y SCEP solo a ciertos dispositivos.
Y así, comenzamos la migración de aumentar de 1000 a 4000 usuarios en una ola. El proceso tomó 4 semanas. Estábamos listos para cualquier cosa (todos sabemos que muy raramente todo sale según lo planeado). Pero todo salió bien sin un aumento en las llamadas al servicio de escritorio.
Dispositivos obsoletos
De acuerdo con nuestros estándares, nos esforzamos por las versiones mínimas del sistema operativo móvil:
· T-1 para iOS.
· T-2 para Android.
* T es la última versión en este momento.
En menor medida, esto se aplica a iOS, ya que Apple ha apoyado durante mucho tiempo sus dispositivos. Esto es más cierto para dispositivos Android. Por ejemplo, las personas aún usan Android 4.4.2 en dispositivos que tienen más de 4 años.
En este caso, estamos llevando a cabo un diálogo con el equipo local de TI para determinar el momento de la sustitución de dispositivos, ya que es necesario encontrar un equilibrio entre la seguridad y el dinero gastado en actualizarlos.
Que sigue
El cambio de decisión ha llevado a cambios internos. Por ejemplo, había scripts para limpiar SCCM de dispositivos obsoletos escritos en PowerShell, que ahora no son posibles de usar. En todas sus nuevas soluciones, Microsoft está promoviendo la API Graph, que debe ser dominada.
Hasta hace poco, la creación de informes se basaba en SSRS; ahora utilizaremos Power BI + oData Feed con datos del almacén de datos de Intune.
Anteriormente mencioné el acceso convencional y la gestión de aplicaciones móviles. La primera solución ya se ha implementado; ahora estamos trabajando en la segunda. También estamos probando Azure Application Proxy como reemplazo de VPN en dispositivos móviles. Si es interesante, con gusto lo contaré en nuevos artículos.