AirWatch MDM Review
Hace un tiempo comenzamos a utilizar dispositivos Android en la empresa y se hizo evidente que necesitaríamos un software para administrarlos. Desde hace varios años utilizamos BlackBerry, para lo cual contamos con BlackBerry Enterprise Server (BES). Personalmente BES siempre me pareció una cagada, tiene sus cosas buenas y fue uno de los pioneros del rubro, pero las cosas no andan bien. Los servicios de BB en general siempre me parecieron una bosta. Que algún administrador de BES me diga si al menos una vez al mes (o a la semana) algún BB deja de sincronizar los mails y encuentra otro remedio más que desvincular el equipo y volver a vincurlarlo? si, a veces se soluciona con una reiniciada, pero muchas veces no! y lo peor es que es imposible saber la causa.

Bueno, dejando mi resentimiento hacia BES, volvemos a Android. Android es una plataforma muy buena, pero creo que no tan orientada a las empresas todavía. De a poco va queriendo, pero todavía le falta bastante. El tema es que los dispositivos Android parecen estar pensados solamente para el usuario hogareño. Para poder utilizar este sistema a nivel corporativo, necesitamos una herramienta que nos brinde ciertas funcionalidades.

Veamos primero qué es lo que se necesita para poder administrar dispositivos móviles en general, y luego nos adentraremos en AirWatch en particular.


Introducción MDM para Android

Mi experiencia me permite distinguir las siguientes necesidades, a la hora de administrar dispositivos móviles Android (u otros) corporativos:
  • Uso de mail corporativo: Android soporta ActiveSync para poder utilizar un servidor de correo Exchange. La necesidad que identifico es poder administrar esta conexión desde un software centralizado.
  • Políticas de seguridad: muy pero muy importante es poder aplicar restricciones a los equipos. Como la mayoría sabe, existen miles de aplicaciones maliciosas para Android. Si permitimos a cualquier usuario instalar cualquier cosa, vamos a tener un grave problema. Las políticas de seguridad deben permitir:
    • Forzar uso de PIN o patrón para bloquear el dispositivo.
    • Bloquear la instalación y desinstalación de aplicaciones. Así como no queremos que instalen nada, también queremos que no desinstalen software básico.
    • Bloquear "reset to factory" del equipo. Si borran la configuración, después pueden hacer cualquier cosa.
    • >
    • Bloquear el cambio de ciertas capacidades estéticas, como cambio de wallpaper.
  • Instalación remota de aplicaciones: bien, no permitimos instalar aplicaciones al usuario, pero si el mismo necesita algo para sus tareas, debemos poder instalarselo. Estos usuarios puede que no estén físicamente en las instalaciones de la empresa, así que poder instalar aplicaciones desde el administrador, es un requisito.
  • Uso de encripción: dado que los equipos pueden transportar información sensible, es necesario poder activar la encripción de la tarjeta de memoria y/o memoria del equipo.
  • Bloqueo / Wipe remoto: si un dispositivo es robado o perdido, el administrador debe poder bloquearlo e incluso borrarlo para que no se accedan a los datos de la empresa.
  • Configuración centralizada: tener que configurar muchos dispositivos de a uno, no solo estresa a cualquiera, sino que es una pérdida de tiempo. La mejor alternativa es realizar la configuración una vez, y que todos los dispositivos la apliquen al conectarse.

Los programas que proveen estas funcionalidades se denominan Mobile Device Management (MDM), y hay varios dando vueltas. El mismo BES es un MDM que implementa las funcionalidades descriptas. Uno de estos MDMs es AirWatch y en él me enfocaré el resto del artículo. AirWatch, según sus propias palabras, es el MDM líder a nivel empresarial.


AirWatch

Estuve utilizándo AirWatch durante un par de semanas, haciendo varias pruebas, y quería compartir mi experiencia con esta herramienta, por si alguno de ustedes está buscando algún MDM y está indeciso. Les comentaré tanto las cosas buenas, como las cosas malas que encontré al utilizarlo.

Para empezar, me pareció muy útil que soporte múltiples sistemas operativos (Android, iOS, BlackBerry, Symbian, Windows Phone, Mac OS X, entre otros). Si el parque de dispositivos no es homogéneo, como en nuestro caso, esto es una característica importante. Es importante observar aquí que no es la panacea. Si bien el soporte de sistemas operativos existe, en muchos casos el soporte es muy limitado. Por ejemplo, no podrán reemplazar BES por AirWatch para administrar los BlackBerry, ya que las características que AirWatch soporta para BB son muy (MUY) limitadas.
En cada opción de configuración de AirWatch, podrán observar al costado, qué sistemas operativos la soportan. Incluso dependiendo la versión del sistema operativo, puede que la opción esté disponible o no (por ejemplo, algunas cosas disponibles para Android 3, no están disponibles para Android 2). A favor de AirWatch hay que decir que en muchos casos la limitación la pone el sistema operativo. Si el sistema operativo no provee una forma de evitar el uso de la cámara, el software no podrá hacerlo.
Otro punto a tener en cuenta, es que la mayoría de las opciones de configuración para Android, sólo están disponibles para dispositivos SAFE (Samsung For Enterprises). Si no adquirieron dispositivos Android que sean SAFE, casi que ni les conviene utilizar AirWatch.

AirWatch implementa todos los puntos listados en la introducción, aunque no todos para todos los sistemas operativos. Para equipos SAFE, todas las opciones están disponibles, teniendo algunas limitaciones en cuanto a la granularidad.
Algo interesante es que AirWatch permite organizar los dispositivos en unidades organizativas (por ejemplo, departamento), y a los usuarios por grupos. Luego es posible definir perfiles (que incluyen políticas de uso, certificados, bookmarks, VPN, WiFi, etc) por unidad organizativa y por grupo de usuario. Esto brinda la flexibilidad de poder definir, por ejemplo, que ciertas restricciones se apliquen a los usuarios de comercial, que se encuentren en el grupo de usuarios atención al cliente. La organización de los grupos resulta un poco confusa al principio, pero luego del uso se va afinando.

La instalación remota de aplicaciones existe, pero no es del todo directa. Es posible distribuir tanto aplicaciones públicas, como adquiridas por la empresa (llámese APK). Es posible instalar las APK sin intervención del usuario, pero si es una aplicación de la Play Store, requerirá la intervención del usuario, algo para nada conveniente. Tal vez sea algo que me falló a mi, pero luego de varias pruebas, no logré que se instale algo directamente.

Dado que muchos dispositivos incluyen aplicaciones que tal vez no deseamos (Google trae algunas que en modo usuario son imposible desinstalar... llámese Gmail, G+, etc), es posible desinstalarlas/desactivarlas mediante AirWatch. Este es un punto muy a favor del software, dado que sin rootear el dispositivo no es posible eliminar ciertas aplicaciones. Además es posible restringir la instalación de aplicaciones y no permitir que el usuario desinstale las importantes. Esto se logra con los grupos de aplicaciones Blacklisted, Whitelisted y Required. Todas las listas se arman con los IDs de las aplicaciones. Cada aplicación tiene un ID único, como com.google.android.gm para GMail.
  • Blacklisted permite listar las aplicaciones explícitamente prohibidas. Si una aplicación está en esta lista, no se podrá instalar.
  • Whitelisted, si está activa, restringe que no se instale ninguna aplicación que no se encuentre en la lista.
  • Required no permite que el usuario desinstale ninguna de las aplicaciones listadas.
Me parece importante remarcar que las aplicaciones que vienen "de fábrica" como GMail, seguirán instaladas incluso si utilizamos la Whitelist y no la incluímos. La única forma que logré de remover estas aplicaciones es listándolas explícitamente en la Blacklist.
El único aspecto negativo que encontré en esta funcionalidad, es que el sistema permite al usuario llegar hasta el último paso de la instalación antes de decirle "está prohibido instalar la aplicación". Estaría bueno que no lo permitiera de entrada.

Otro aspecto que en nuestro caso era importante, es dónde está instalado el servidor. Para empezar, AirWatch vende el servicio en la nube, es decir, está el servidor instalado en algún lugar del ciberespacio, y nosotros lo administramos remotamente. Consultando con un agente oficial, me indicaron que también es posible instalar el sistema on-site, es decir, tener nuestro propio servidor AirWatch. El requerimiento para hacerlo es contratar por lo menos 100 licencias, donde las licencias son por dispositivos... para hacer una prueba inicial no resulta muy atractivo tener que contratar 100 licencias. Como dato extra, cada licencia cuesta entre 5 y 6 dólares mensuales. No estoy para nada a favor de colocar datos de la empresa en la nube, mucho menos información de dispositivos, que incluye localización, registro de llamadas, mensajes, etc, pero en este caso, no tuvimos opción.

Algo que todavía no mencioné es que la interfaz de administración es Web. La interfaz es, a mi gusto, poco intuitiva y confusa. No es fácil familiarizarse con ella, e incluso luego de utilizarla un par de semanas, a veces no encuentro las cosas. Tal vez sea una mera impresión mia, pero conversando con mis compañeros de trabajo, les dio la misma sensación. La primer gran confución es la diferencia entre los usuarios. Existen dos tipos de usuarios, los administradores, y los "dueños" de dispositivos. Los primeros tienen permiso de administrar la aplicación, y mediante roles se puede restringir lo que pueden hacer. Los segundos se utilizan para registrar equipos. Es decir, cuando damos de alta un equipo, éste debe pertenecer a algún usuario, por lo que antes habrá que dar de alta el usuario. Cada uno de estos usuarios puede tener asignado uno o más equipos.
Otra confusión es dónde estamos parados. Como cada dispositivo pertenece a una unidad organizativa, si estamos en una de ellas, no podremos ver los dispositivos en otras (salvo que estemos en la OU raíz, donde podemos ver todos). Lo mismo sucede con los usuarios.
Un problema que encontré aquí es mover dispositivos o usuarios entre unidades organizativas... simplemente, no pude. Si el usuario tiene asignado un dispositivo que se encuentra en una dada OU, no se puede mover el usuario, y lo mismo pasa con los dispositivos.
Más allá de ser confusa, tengo para decir a favor de la interfaz que genera interesantes gráficos. El dashboard es muy visual y La información sobre los dispositivos es muy completa.

Un aspecto muy negativo, es la falta de documentación. Googlear cómo hacer algo en AirWatch es prácticamente inútil. Sólo se encuentran broshures de propaganda. Incluso en la página de AirWatch no encontrás los manuales! Tienen una sección de whitepapers que no me resultó muy útil. Por suerte, nuestro proveedor de AirWatch en la nube brindó un buen soporte a nuestras consultas, y nos entregaron un manual oficial... aunque este manual oficial no era muy completo tampoco. En fin, punto negativo en cuanto a documentación.


Agente AirWatch

La administración de los dispositivos se logra instalando un agente AirWatch en cada uno de ellos. Este agente se instala desde la Play Store de Google (en el caso de Android), y se registra en el servidor utilizando una URL de enrollment (que no es la misma que la de administración), el ID de la unidad organizativa, y un usuario del tipo "dispositivo" (no uno de administración).

Para la instalación encuentro como punto negativo que no se provea una APK. El uso de la Play Store de Google fuerza registrar una cuenta Google. Para un dispositivo corporativo, por qué la empresa debería tener cuentas Google? Parte del monopolio encubierto de Google.

Una vez que se registra el dispositivo, se aplica la configuración indicada por el servidor, la cual incluye el perfil del usuario. Acá encontré otro problema. Si bien el agente provee una forma de forzar la sincronización, la aplicación del perfil no siempre funciona. Tuve muchísimos problemas creando bookmarks desde el servidor. A veces el agente los borra, no se actualizan...

Encontré riesgoso el echo de no poder prohibir la desactivación del agente. Si bien encontré la forma de que el usuario no desinstale el agente (Required list, descripta anteriormente), no encontré la forma de que el usuario no desactive el agente. Una vez que se desactiva el agente, el usuario sigue teniendo las restricciones, pero el servidor pierde el contacto con el dispositivo.


Conclusión

AirWatch es un muy buen comienzo en la administración centralizada de dispositivos móviles. Sin embargo, creo que odavía tienen mucho camino por delante. Tal vez dependa mucho de la evolución de los sistemas operativos como Android, que seguramente tomarán un approuch cada vez más empresarial, como BB.
No utilizaría AirWatch como reemplazo de BES. Si tienen dispositivos BB, debido al limitado soporte, recomiendo seguir utilizando BES por más feo que sea :P

Como puntos a favor encuentro que:

  •  Implementa las características más importantes de un MDM.
  •  Brinda muy buena información sobre los dispositivos.
  •  Permite una buena restricción de las aplicaciones instaladas y que no se pueden desinstalar.
  •  Soporte de múltiples sistemas operativos.
  •  Aplicación de políticas por grupos de usuarios y/o dispositivos. Facilidad de generar perfiles y aplicar uno o más a cada dispositivo.

En contra, encuentro que:

  • La interfaz web de administración no es muy intuitiva.
  • La documentación casi inexistente, ya que una vez que nos vamos adentrando en el software y queremos hilar más fino, no se encuentra información al respecto.
  • El soporte de Android es principalmente para equipos SAFE, y salvo iOS, las características disponibles para el resto de los SOs es muy limitada.
  • El agente falla cada tanto y no aplica correctamente los perfiles.
  • Se requieren demasiadas licencias (al menos 100) para poder instalar el servicio on-site.
Thunderbird/Icedove como cliente de Mails, Calendario y Libreta de direcciones de Exchange
El conjunto de herramientas de Exchange utilizado en entornos Windows, es muy importante en la mayoría de las empresas. Para tener una Workstation GNU/Linux totalmente funcional con respecto a sus pares Windows, necesitamos integrar tanto mails, como calendario y libreta de direcciones, provistos por Exchange.

Por suerte, existe una excelente herramienta denominada DavMail que nos facilita la vida. Esta herramienta actúa de proxy entre el cliente de mails que utilicemos (Thunderbird/Icedoe, Evolution, etc) y el servidor Exchange. Para ello, transforma protocolos estándar (IMAP, SMTP, LDAP, etc) en solicitudes WebDav (extensión del protocolo HTTP) reconocidas por el servicio OWA de Exchange.

A continuación explicaré cómo utilizar Thunderbird/Icedove como cliente de mails, calendario y libreta de direcciones provistos por Exchange, a través de DavMail. La explicación está basada en los tutoriales provistos en la propia página de DavMail: IMAP Thunderbird mail setup, Thunderbird calendar setup y Thunderbird directory setup. Además, la explicación está basada sobre debian GNU/Linux, pero la configuración es igual para otras distribuciones e incluso Windows.


Instalación y configuración de DavMail

Descargar DavMail desde su página en sourceforge. Dirigirse al directorio de instalación y ejecutar:
  #dpkg -i davmail.deb # ver nombre real del paquete descargado, o renombrarlo
  #apt-get -f install  # instala todas las dependencias necesarias para davmail

DavMail también está disponible para Windows y Mac, dado que está programado en Java.

Una vez instalado DavMail, debe ejecutarse. Lo recomendable es linkearlo para que se ejecute al inicio de sesión del usuario, así no tenemos que ejecutarlo a mano cada vez que queramos usarlo. En la primera ejecución hay que configurarlo para que apunte al servidor Exchange.
Los campos requeridos, como base, se encuentran en la pestaña Main, y son los siguientes:
  - Exchange Protocol: elegir EWS para Exchange 2010, o WebDav para Exchange 2007.
  - OWA (Exchange URL): la URL del servidor Exchange, por ejemplo: https://miserver.com/OWA
  - Elejir los puertos locales en los que DavMail debe esperar conexiones POP, IMAP, SMTP, Caldav y LDAP. El cliente que configuremos, se conectará a estos puertos. Pueden dejar los puertos default y desactivar alguno de los protocolos si no son necesarios (POP por ejemplo).


Configuración de la cuenta de mail en Thunderbird/Icedove

Los pasos para configurar la cuenta de dominio en el cliente Thunderbird, son los siguientes:
  1- Elegir Crear una nueva cuenta de e-mail. Dependiendo de si ya tienen configurada alguna cuenta o no, los pasos pueden variar un poco al principio.
      - Si no tienen una cuenta definida, el wizzard busca para crear una cuenta con alguno de sus partners. Si este es el caso, clickear el botón "Saltear esto y usar mi correo existente".
      - Si ya tienen otra cuenta en Thunderbird, ir a "Editar -> Configuración de Cuentas...", elegir "Acciones de cuenta -> Agregar una cuenta de correo".
  2- Completar el campo de Nombre y dirección de mail en la configuración de la cuenta. Aconsejo destildar la opción recordar contraseña. Dar continuar.

  3- Al dar continuar, Thunderbird fallará en la comprobación del dominio y les solicitará que ingresen los datos manualmente. En la configuración, utilizar los siguientes valores:
Entrante/Incoming:
IMAP (pueden elegir POP, pero IMAP es más completo)
Nombre del servidor: localhost
Puerto: el puerto que configuraron en DavMail. Por defecto es 1143.
SSL: Ninguno.
Autenticación: Contraseña normal.
Saliente/Outgoing:
Nombre del servidor: localhost
Puerto: el puerto que configuraron en DavMail para SMTP. Por defecto 1025.
SSL: Ninguno.
Autenticación: Contraseña normal.
  Nombre de usuario: su nombre de usuario en el dominio, agregando el nombre del dominio: DOMINIO\usuario

Tal vez DavMail indique que el servidor Exchange provee un certificado no confiable. Esto sucede si el servidor utiliza un certificado autofirmado, o firmado por una CA local. Dar aceptar.


Calendario

Para configurar el calendario, debemos instalar la extensión iceowl-extension (extensión Lightning):
  # apt-get install iceowl-extension

Luego, desde Thunderbird/Icedove abrimos el calendario "Events and Tasks -> Calendar", y realizamos los siguientes pasos:
  1- Click derecho en el panel izquierdo (deben tener el predefinido calendario "Home") y clickeamos "New Calendar".
  2- En la ventana que aparece, elegimos "On the Network", luego "Siguiente".

  3- En la siguiente opción elegimos "CalDAV" en el formato, y utilizamos la siguiente dirección para el "Location": http://localhost:1080/users/usuario@dominio.com/calendar, donde deberán reemplazar usuario@dominio.com por su usuario y dominio.

  4- Una vez que terminen, les solicitará un nombre de calendario, color, si desean recibir recordatorios. Configurar a gusto.
  5- Para finalizar, les solicitará las credenciales de dominio. Hay que colocarlas como en el caso de los mails, utilizando el formato DOMINIO\usuario para el nombre de usuario.


Libreta global de direcciones

La libreta global de direcciones de Exchange se habilita de la siguiente manera:

  1- Ir a "Herramientas -> Libreta de direcciones".
  2- En la ventana emergente, seleccionar "Archivo -> Nuevo -> Directorio LDAP".
  3- Abre una nueva ventana, donde se nos solicitan los siguientes datos:
      Nombre: el que ustedes elijan (ej: Exchange)
      Servidor: localhost
      DN base: ou=people
      Número de puerto: 1389 (ver la configuración de DavMail para saber qué puerto usar con LDAP, por defecto es 1389)
      DN para inicio de sesión: DOMINIO\usuario

Para que Icedove autocomplete con las direcciones de la libreta global, hay que ir a "Editar -> Preferencias -> solapa Redacción". Allí tildar la opción "Servidor de directorios" y elegir la libreta recién creada.

Cuando vayan a redactar un e-mail, Thunderbird/Icedove les solicitará la contraseña del usuario de dominio.