Todas las entradas de: Elena Sebastián Peña

Proceso de sincronización. Resolviendo InvalidSoftMatch en ADConnect

El objetivo que me he planteado para este artículo, es explicar a alto nivel el proceso de sincronización, y, una vez establecido el contexto, ver algunos de los errores que podríamos tener, en concreto el tipificado como InvalidSoftMatch. Pero antes de entrar en materia, me gustaría poner un poco de contexto.

¿Qué es ADConnect?

ADConnect es un elemento fundamental en implementaciones de identidad sincronizada o federada con Azure AD (AAD). Nos sirve para poder emplear las credenciales de nuestro directorio local, en servicios proporcionados por Azure AD, y, así, tener una mayor experiencia de integración.

En el core de las aplicaciones que instala, se encuentra el servicio de sincronización. Sin entrar en mucho detalle, esta herramienta, mediante el empleo de ciclos de sincronización regulares, divididos en distintas etapas (Import, Sync y Export), va a realizar una “comparativa” de los elementos que hay en local, con los de Azure, y, realizará las acciones necesarias: creación, actualización, eliminación. Esta “comparativa” la hace empleando los parámetros configurados durante la instalación de ADConnect.

¿Cómo funciona la sincronización?

El proceso de sincronización, permite  establecer una correspondencia entre los elementos que existen en local y los de Azure.  Son necesarios 2 atributos del directorio local para ello :  un atributo para el inicio de sesión, y otro, para identificarlo de forma única o ImmutableId (que permanecerá inalterable a lo largo de la vida del objeto). Los valores empleados  por defecto (aunque no los únicos), son respectivamente el UserPrincipalName y el ObjectGuid.

Durante la sincronización, los objetos son importados , convertidos a un formato  apropiado, y por último provisionados o actualizados en el destino (si hubiera modificaciones).  El objectGUID del usuario de origen es convertido a base 64 y pasará a ser el atributo ImmutableId en AzureAD.

Errores de sincronización

Si bien, en un entorno perfectamente controlado los errores de sincronización no suelen ser frecuentes, puede darse situaciones, en las que nuestro ADConnect reporte algún error al realizar alguna exportación.  Éstos podrán visualizarse en la pantalla de operaciones del administrador de sincronización, y para poder analizarlos y solventarlos, tendremos que acceder a cada uno de ellos.

Entre los errores que podemos encontrar figuran: ObjectTypeMismatch, AttributeMustBeUnique, InvalidSoftMach entre otros. Nos centraremos en el error InvalidSoftMatch.

Error InvalidSoftMatch

Este error aparece porque hay una incoherencia en el atributo ImmutableId. Si un usuario está correctamente sincronizado su UserPrincipalName y su inmutableId (en AD y AAD) deben ser el mismo. En este caso, el UserprincipalName coincide, pero no el ImmutableId, y,  por tanto, no se puede realizar una correspondencia con ese usuario. Este error puede producirse cuando un objecto de ADD ya está sincronizado, y, en el directorio de origen se elimina ese objeto y se crea otro con las mismas propiedades.  Al crear un nuevo objecto, se generará un nuevo GUID, que no coincidirá con el de AAD.

Para poder solucionar este error, debemos hacer un “Hard Match” o macheo manual, que consiste en cambiar el ImmutableId del  usuario de AAD, por el correcto del directorio local.  Previamente nos tenemos que conectar a O365 con usuario administrador global del tenant.

Como último comentario, indicar,  que si nuestro dominio está federado, necesitaremos previamente cambiar el UPN por el de un dominio no federado para machearlo, y a continuación establecer el upn correcto.

¡Hasta el próximo post! 🙂

 

MDT. Fases de una Standard Task Sequence

MDT (Microsoft Deployment Toolkit) es una herramienta muy útil en el entorno empresarial para el despliegue de sistemas operativos y aplicaciones. Nos permite centralizar la distribución de imágenes desde un entorno controlado. Su gestión se basa en “Deployments Share” o carpetas compartidas, con una estructura predefinida y, que contiene todos los recursos a implementar. Una de estas subcarpetas dentro de la aplicación es “Task Sequences”, en la que se definen todas las acciones a ejecutar. Las tareas más empleadas (entre otras), son la instalación de sistemas operativos (“Standard Client Task Sequence”), instalación de aplicaciones (“Custom Task Sequence”) y la captura de una  imagen generalizada (“Sysprep and Capture”)

Internamente, cada “Task Sequence” se compone de una serie de pasos ordenados, que permiten el desarrollo de la tarea. Cada tipo de “Task Sequence” tiene  predefinidos una serie de pasos. Podemos decir que este elemento (las “Task Sequences”), son el “core” de nuestra implementación y, por tanto es muy importante saber cómo funcionan  si queremos añadir personalizaciones de forma apropiada. Es por ello, que esta semana voy a comentar este punto, poniendo como referencia la tarea de implementación de sistemas operativos.

Standard Task Sequence

Cuando instalamos un Sistema operativo, nuestro sistema pasa por 7 fases bien delimitadas: inicialización, validación, captura de estado, preinstalación, instalación, post instalación y estado de restauración. En MDT, detras de cada tarea predefinida, suele estar (en la mayoría de los casos), un script ubicado en la carpeta Scripts de la implementación.

001

Fases

La tarea de instalación de un Sistema operativo se compone de las etapas que se describen a continuación:

  • Inicialización: En esta fase realiza una recopilación de información del equipo y, toma las reglas definidas en customSettings.ini, para ello hace una llamada al script ZTIGather (script que se ejecutará también para obtener información en las fases de preinstalación y restauración)
003
  • Validación:  Se establecen los requisitos de memoria y de sistema operativo, chequea la BIOS (ZTIBIOSCheck.wsf), y si todo está correcto, pasa a la siguiente fase.

004

  • Captura de estado: En caso de  haber seleccionado la opción para migrar los datos del usuario, lo realiza aquí.
005
  • Preinstall: Realiza la validación de los requisitos previamente establecidos, formatea y particiona nuestro disco duro, y carga los drivers.
006

 

  • Install: Efectúa la instalación del sistema operativo.

007

  • Post Instalación: Instala los drivers previamente cargados, copia los scripts necesarios para la consecución de tareas necesarias en la carpeta y añade los archivos a la partición de recuperación.

008

  • Estado de restauración: es en esta parte donde podremos realizar la mayoría de personalizaciones, como instalar features, agregar scripts de configuración de software, etc. También es aquí donde se instalan las aplicaciones y se añade el equipo a dominio. Como subfase dentro de PostInstall, está la realización de una imagen .wim, en esta parte se copiarían al equipo los archivos necesarios para ejecutar sysprep y para posteriormente capturar la imagen del sistema.009

En este post, me he enfocado en la tarea de instalación de un sistema operativo, pero cada tipo de tarea tiene sus propios pasos que debemos entender; y, con este pequeño apunte me despido.. ¡Hasta el próximo post! ¡Feliz despliegue! 🙂

StorSimple Virtual Array, un nuevo miembro en la familia

Esta semana me gustaría hablar de otra solución dentro de la familia StorSimple, que Microsoft nos presentó a mediados del mes de Diciembre del año pasado. Se trata del StorSimple Virtual Array. De momento está en preview, y el servicio sólo figura en dos DataCenters. Veamos en qué consiste y qué nos ofrece.

StorSimple Virtual Array (Storsimple VA 1200), supone otra manera de proporcionarnos storage híbrido. Esta vez la solución no viene de la mano de un dispositivo físico , sino que se trata de una máquina virtual  que descargaremos desde el portal clásico de Azure, y  alojaremos en un Hypervisor de nuestro Datacenter. Gracias a ella podremos expandir nuestra capacidad de almacenamiento a la nube, así como  plantear escenarios de backup y  disaster recovery.

Requisitos mínimos del Virtual Array

Para poder desplegarlo debemos reservar una serie de recursos , y asociarlos a la máquina virtual:

  • Número de procesadores: 4
  • Memoria RAM : 8 GB
  • Tamaño disco: para sistema : 80GB y para datos: 500GB
  • Una interfaz de red virtual

Los Hypervisores soportados como host deben ser Windows 2008 R2 SP1 o superior y VMware ESXi 5.5 o superior.

Características

El dispositivo permite  2 modos de funcionamiento: como  File Server empleando SMB o como dispositivo iSCSI. Los volúmenes pueden estar alojados únicamente en local o puede emplearse  un almacenamiento en dos niveles (local y en la nube), en el que para provisionarlo, se deberá disponer en local de al menos un 10% del espacio total.  Para poder gestionar y configurar  el virtual Array tenemos a disposición varias herramientas :

– Interfaz web local: es un portal web al que accederemos introduciendo la ip de nuestra VM. Permite administrar gran parte de las características: el modo, los volúmenes, etc.

– StorSimple Manager: se trata del panel de Azure desde el que controlaremos los dispositivos StorSimple.

– Command Line Interface:una interfaz de comandos en Powershel para poder interactuar con el Virtual Array,

Limitaciones de almacenamiento

En cuanto al almacenamiento encontramos las siguientes:

– Capacidad máxima: cada Virtual Array puede gestionar como máximo 64 TB (entre la nube y local) o 6,4TB si se trata de almacenamiento local.

– Volúmenes: para almacenamiento local y en la nube un máximo de 20TB y, para local 2TB.

Asímismo el espacio va a estar siempre condicionado al que tengamos disponible en nuestra infraestructura.

Backup y disaster recovery

Es aquí donde podemos ver las posibilidades que ofrece,  permitiendo hacer cloud snapshots, backups incrementales y bajo demanda.  Estos backups se registrarán en un catálogo, que  podremos seleccionar posteriormente, ofreciéndonos a su ver la posibilidad de restaurar los archivos en otra ubicación. Gracias a la característica de Item Level Recovery, implementada en su modo de funcionamiento como File Server, los usuarios podrán restaurar ellos mismos elementos eliminados,

En cuando a los escenarios de disaster recovery, podremos hacer failover de un virtual array,  y restaurarlo en otro que tengamos previamente activo en nuestro StorSimple Manager.

Architecture

Después de tener una visión general del producto, podemos decir que es una herramienta bastante completa para pequeña empresa, combinando soluciones de almacenamiento y backup en un solo elemento. Y con esta conclusión me despido hasta el próximo post.

Microsoft Arr como proxy Inverso

Esta semana me gustaría hablar de una herramienta bastante completa como es Microsoft ARR.

¿Qué es Microsoft ARR?

Microsoft Application Request Routing  (ARR) es una extensión de IIS basada en los módulos en URL Rewrite, Web Farm Framework  y External Cache,  que  permite ampliar las funcionalidades de nuestro IIS, convirtiéndolo en un elemento multipropósito. Entre las tareas que puede desempleñar destacan las siguientes:

    • Balanceador de carga: permite distribuir la carga entre varios servidores de una misma granja.
    • Servidor de caché: mejora el rendimiento de los servidores CDN estableciendo una caché de disco intermedia.
    • Proxy inverso: redirige las peticiones desde Internet hasta el servidor correcto en una red privada.

Para poder emplearlo, debemos instalarlo en nuestro IIS, bien de forma manual (instalando previamente sus requisitos) o de manera más automática y sencilla a través de Web Platform Installer.

Arr como proxy inverso

En este artículo nos vamos a centrar en este aspecto. Como proxy inverso permite redirigir las peticiones recibidas a través de Internet a un servidor en concreto de nuestra red interna. El proceso sería el siguiente:

  1. El usuario abre su explorador de Internet y escribe una url.
  2. Esta url es resuelta por el proveedor DNS correspondiente en Internet y redirigida a una Ip.
  3. El firewall de esa red (conforme a lo que esté establecido en él) redirige el tráfico al ARR.
  4. El ARR examina la cabecera http  recibida y revisa el conjunto de reglas que tiene establecidas en su módulo URL Rewrite
  5. Si la condición se cumple, realiza una acción, en este caso redirije esa petición al servidor destino.
  6. La url es servida al usuario.

image

Reglas de enrutamiento

Las reglas de enrutado son la base del funcionamiento del ARR. Cada regla consta de varias partes :

  • Match Url: se pueden emplear una serie de patrones a aplicar a la url solicitada. Asímismo,  definimos si vamos a emplear comodines, expresiones regulares o la url exacta.

image

  • Condiciones: Se establecen las premisas que se deben cumplir para que se aplique la regla.

image

  • Acciones: la aplicación de la regla tendrá como consecuencia la ejecución de una acción. De entre ellas destacamos las que aplicarían en nuestro caso: Rewrite que reenvia la petición a una url interna, y Route to Server Farm que redirigiría esa url a uno de los servidores que tuviéramos definidos dentro de la granja del ARR.

image

Una vez configurados los parámetros indicados con anterioridad dispondríamos de un proxy inverso listo para enrutar las conexiones que definamos a nuestra red local.

¿Por qué emplearlo?

Las principales ventajas que obtenemos al emplear ARR como proxy inverso son las siguientes:

  • Seguridad: Nuestros servidores no se encuentran expuestos directamente a a Internet por lo que están más protegidos frente a ataques externos. En nuestro firewall sólo tendremos que abrir una regla por cada puerto que redirgir al ARR.
  •  Administración centralizada: gestionamos la redirección a varios servidores a través de las reglas definidas en un único IIS.  No necesitamos varias ip’s públicas, ya que con una podemos reenviar las peticiones al servidor adecuado.

Como habéis podido observar  debido a las aplicaciones que ofrece resulta bastante atractivo a la hora de emplearlo. Y con esto, me despido, ¡hasta la próxima!

Problemas federando dominio con Azure ADConnect

Desde hace ya algún tiempo Azure ADConnect ha pasado de ser un producto preview , a sustituir definitivamente a DirSync, como instrumento para integrar y sincronizar identidades onpremise con Azure AD. Aunque ambas aplicaciones (DirSync y ADConnect), se basan en FIM 2010, esta última no sólo se ha dedicado a la sincronización de directorios (ampliándola con más opciones ), sino que ha incrementado su potencia añadiendo otros componentes.  Quizá, debido a esta complejidad derivada de ser una herramienta multipropósito, puede ser más difícil acotar y depurar errores.

Para poder emplear ADConnect -una vez realizados los pasos previos necesarios en Azure- debemos descargarla e instalarla en una de las máquinas pertenecientes a nuestro dominio. El instalable es un asistente que nos guiará en todo momento. Todo esto nos facilita mucho el trabajo, convirtiéndolo en una mera sucesión de pantallas, en las que únicamente tendremos que pulsar el botón siguiente y completar los datos. Pero, ¿qué pasa si el programa falla o nos da error?

Dependiendo del punto donde esto suceda, el asistente nos ofrecerá una serie de recomendaciones. Si el fallo no se subsana, es posible que nos aconseje la desinstalación total del producto, y proceder a instalarlo nuevamente. Pero, esto no nos garantiza que el fallo vuelva a aparecer en la siguiente ejecución. Por todo ello, quizá antes de prender fuego a todo y volver a empezar de cero, es bueno que nos paremos un momento y recapacitemos.

CASO PRÁCTICO

Dicho todo esto vamos a poner un caso práctico: tenemos un dominio con nuestro DC,  ADFS, etc que queremos federar con Azure;  para hacerlo empleamos Azure ADConnect. Lanzamos el ejecutable y casi al final de la configuración nos falla con el error que podemos ver en pantalla:

000AD-Connect

Hemos revisado toda la configuración y parece que todo está correcto. Así que procedemos a reintentar la ejecución, pero sigue fallando. Nos fijamos en qué hay un log en el que podemos revisar todos y cada uno de los pasos realizados. Examinando el log en detalle, observamos que lo que hay detrás son comandos de PowerShell. En concreto, vemos que aunque el asistente ha validado los DNS no ha terminado de verificarlos, con lo que no es posible validar correctamente el dominio. Para solventarlo, abrimos una consola de Powershell Azure AD, nos conectamos a nuestra suscripción y ejecutamos:

Comprobamos que las entradas DNS son las correctas, pulsamos “Retry”, y voilà la configuración se puede completar correctamente.

Como conclusión después de todo lo anterior, es que para poder diagnosticar de forma adecuada es importante conocer su mecánica de funcionamiento. ¡Un saludo y hasta la próxima! Smile

Firmando código con signtool

Siguiendo la estela de los últimos post que publiqué sobre certificados, esta semana también voy a hablar sobre ellos, aunque esta vez sobre cómo emplear los certificados de firma de código. Estos certificados son un tipo especial que  permiten marcar digitalmente la autoría nuestro software.

Para la generación de este certificado (al igual que con otros) tendremos que elaborar un request a una CA verificada que procesará la petición. Una vez expedido el certificado y exportado a pfx podremos firmar digitalmente nuestros ejecutables. Para firmarlo usamos la herramienta Signtool. Se trata de una  herramienta de línea de comandos, que viene incluida dentro de las herramientas SDK de Microsoft.  Entre las acciones principales disponibles destacan entre otras las siguientes: sign: que va a permitir firmar, verity: verificamos el binario y remove: podremos eliminar los certificados del ejecutable. Para nuestro caso concreto emplearemos la opción sign, así pues la sintaxis sería la siguiente:

signtool sign /f “fichero_pfx” /p “contraseña_pfx” /t “timestamp_server” “aplicacion.exe”

El servidor timestamp que pongamos nos va a permitir establecer una marca de tiempo que determinará la fecha en la que se firmó. Con esta opción (/t) agregamos la url de una Time Stamp Authority (ej:  http://tsa.starfieldtech.com;  http://timestamp.globalsign.com/scripts/timstamp.dll; http://timestamp.comodoca.com/authenticode; http://www.startssl.com/timestamp; http://timestamp.verisign.com/scripts/timstamp.dll; etc) . Una vez firmada la aplicación si accedemos a las propiedades del ejecutable (o si lo ejecutamos), podremos ver el autor.

image

Por último, cabe destacar que además de esta herramienta para gestionar certificados, con el SDK de Microsoft  dispondremos de makecert, certmgr, cert2spc y pvkpfx que suponen un amplio abanico de utilidades para administrarlos. Y con esto, me despido de momento ¡Nos vemos en el siguiente post!

Migración de certificados SHA-1 a SHA-2

Los certificados electrónicos permiten asegurar y acreditar webs, aplicaciones y servicios informáticos. Gracias a ellos, muchas de las transacciones electrónicas que realizamos a diario son seguras . Para la creación de dicho, se emplea una fórmula matemática o hash que determina su huella electrónica. Es por ello, que es muy importante que este código sea robusto y resistente frente a ataques que puedan vulnerarlo y suplantarlo.

Desde 1995 el algoritmo más empleado para la generaciónde certificados era el SHA-1. Dicha firma se consideraba inquebrantable con la tecnología vigente, pero hace un tiempo se comprobó que no era tan inexpugnable . Esto, junto con la bajada de los precios en el cloud computing  (que permite emplear  grandes recursos computacionales para el cálculo de combinaciones) ha agilizado la obsolencia de esta firma; y, empresas como Microsoft y Google, han establecido una serie de plazos para realizar la migración a SHA-2. Así pues,  esta semana me gustaría explicar cómo poder migrar nuestro certificado SHA-1 a SHA-2.

Antes de realizar ninguna acción debemos comprobar que  la infraestructura, servicios o aplicaciones afectadas por este cambio sean compatibles con SHA-2.  Una  vez verificada esta premisa, podríamos generar el certificado. La mayoría de las entidades certificadoras (symantect, digicert, etc) nos van a permitir generar uno nuevo SHA-2 sin coste adicional.

Creación del certificado SHA-2

Para realizar la solicitud de dicho de manera sencilla utilizaremos la librería criptográfica OpenSSL.  Esta herramienta es propia de las distribuciones de Linux, si queremos emplearla desde Windows tendremos que usar algún software como por ejemplo Win32_SSL.

Generación del archivo CSR

Desde una consola de Windows nos ubicamos en el directorio donde se encuentre la instalación de OpenSSL y generamos la solicitud csr , creando una clave de 2048.

image

El fichero csr que se generará será  similar al de la imagen inferior, el cual copiaremos integramente e introduciremos en la página de la CA correspondiente a nuestro certificado.

image

Una vez realizada la solicitud, la entidad certificadora se encargará de generar el crt correspondiente.

Exportación de crt

Descargaremos el archivo crt  generado por la CA a nuestro equipo . Con la clave anteriormente generada (clave.key) y el fichero .crt podremos exportar nuestro certificado a  formato pfx, empleando también la consola de OpenSSL; e indicando a continuación una contraseña para el archivo. Así:

image

Una vez exportado ya podremos instalarlo en nuestros sistemas.

Como cuestiones a tener en cuenta: debemos identificar los sistemas dependientes de los certificados y prestar especial atención a la generación del fichero crt por parte de la CA, ya que una vez generado, el antiguo certificado SHA-1 quedará revocado, y, los sistemas en los que esté instalado podrían dejar de funcionar.  Y con este pequeño apunte me despido. ¡Hasta la próxima!

Actualizar reglas del firewall de SQL Azure desde Powershell

Para acceder a determinados servicios de Azure, como puede ser una Base datos  Azure SQL es necesario que la ip remota  esté englobada dentro de los rangos permitidos por el firewall de la  suscripción . En ocasiones, encontramos la problemática de querer acceder desde una IP dinámica lo que implica cambiar continuamente las reglas establecidas en el firewall para esa IP.  Así pues, esta semana voy a hablar sobre cómo actualizar de forma automática  las reglas que tenemos creadas en el Firewall de Azure por medio de un script en PowerShell.

Autenticación en Azure

La forma en la que nos vamos a autenticar a través de PowerShell será gracias al fichero PublishSettings. Se trata de un archivo en formato XML que podemos descargar desde nuestra cuenta de Azure  y que contiene información relativa a la suscripción así como un certificado asociado.  Para descargar el fichero PublishSettings únicamente tenemos que ejecutar desde PowerShell el siguiente comando:

Este comando automatiza la apertura de la web de descarga del fichero. Nos logamos en el explorador web con una cuenta que tenga permisos sobre la suscripción, descargamos el archivo y a continuación lo importamos:

001-mod

Una vez realizado esto, tendremos instalado un certificado el cual podremos emplear para conectarnos a Azure, dicho certificado se guarda automáticamente en el almacén personal del usuario. Una vez empleado el fichero publishSettings  por motivos de seguridad es conveniente eliminarlo.

Script de actualización

Realizados los pasos  anteriores podremos automatizar el proceso de actualización de la IP en el firewall. Partimos de la situación  y el script realizados por Carlos Milán en un post anterior, que completaremos añadiendo nuestro código a continuación . Empleamos la IP obtenida por la resolución DNS como dato a añadir en el firewall. Los pasos serían los siguientes:

  1. Establecemos la suscripción sobre la que nos conectaremos por medio del certificado.
  2. Obtenemos los servidores de esa suscripción.
  3. Por cada servidor obtenemos las reglas que hay en cada uno y lo comparamos con el nombre de la regla de Sevilla.
  4. Si el valor no es nulo y la IP que tenemos es diferente cambiamos el rango de IP.
El script tendría la siguiente forma.

Y hasta aquí el tema de hoy¡Nos vemos en el próximo post!

Creación de buzones compartidos en entornos híbridos: Exchange y Office 365

Esta semana me gustaría hablar de cómo crear buzones compartidos cuando nos encontramos en un entorno híbrido formado por un Exchange 2010 onpremise y Office 365, pero antes de nada veamos en qué consiste este tipo de buzón. Un buzón compartido es un buzón especial en el que a varios usuarios se les concede acceso sobre el mismo. Este recurso se crea en AD como un usuario deshabilitado que carece de contraseña y no tiene asociado ningún tipo de licenciamiento, sí lo tendrán los usuarios que accedan a él. Por tanto, se trata de una herramienta colaborativa bastante versátil.

Cuando nos encontramos en un entorno híbrido (por ejemplo una infractuctura con Exchange onpremise y Office 365) la creación del buzón no es directa, hay algunos parámetros asociados que si intentamos crear el buzón en Office 365 no van a aparecer. Así, el proceso tendrá varias fases: creación del buzón compartido on premise, añadir permisos sobre él y migrar el buzón a Office 365.

Creación del buzón en Exchange onpremise

Para crear el buzón debemos ir al servidor donde tengamos alojado el servicio de Exchange y darlo de alta a través de la shell de Exchange, ya que la creación de buzones de tipo compartido está deshabilitado en la interfaz gráfica.

En este ejemplo, solamente se han empleado solamente el nombre y el UPN pero podremos encontrar más parámetros para personalizarlo correctamente como la unidad organizativa donde ubicarlo, la base de datos, etc.

Asignación de permisos

Una vez creado, comprobaríamos que nos aparece en la EMC como shared Mailbox y podríamos agregarle los permisos apropiados a los usuarios.

 

Mover buzón a la nube

Después de realizar los pasos anteriores debemos esperar el tiempo necesario para que se repliquen los cambios; iniciamos sesión en nuestro Tenant de Office 365, ya que todo el movimiento se tiene que realizar desde allí. (Si intentaramos realizar el proceso desde la EMC no recibiríamos ningún tipo de feedback del proceso, tanto si se hubiera realizado como sino).

Realizamos el movimiento del buzón con el comando new-moverequest.

Una vez completado podremos observar que nos figurará en Office 365 y podremos emplearlo.

Errores que nos podemos encontrar

A la hora de realizar el movimiento del buzón nos podremos encontrar con varios errores, aquí voy a mencionar 2:

El destino tiene ya este mailbox primario. Esto se produce porque estamos ejecutando el comando desde el entorno on premise y no desde Office 365.

mail02

El buzón no puede ser encontrado. Este error puede producirse por algún error con dirsync. Entre otros: que no haya pasado el tiempo necesario de replicación, que nuestro buzón esté ubicada en una OU no sincronizada o un posible fallo en la sincronización.

mail102

Y hasta aquí el post de hoy. Un saludo y , ¡¡hasta el próximo !!!

VPN Split Tunneling con CMAK

Esta semana me gustaría hablaros sobre cómo crear nuestro cliente vpn para Windows haciendo split tunneling . Pero antes de nada vamos a ver en qué consiste esto del split tunneling.

SPLIT TUNNELING, ¿QUÉ ES?

Cuando establecemos un túnel VPN todo el tráfico es enrutado a través del mismo sin diferenciar el destino. Así por ejemplo, para alcanzar una página web cualquiera ubicada en Internet, esa conexión se enrutaría a la red de la oficina y desde allí iría a Internet. Esto puede ocasionar que el tiempo de latencia sea alto, ya que esa página web o servicio ha tardado más de lo necesario.  Si tratamos con aplicaciones de videoconferencia, que tienen una mayor carga de tráfico la situación se agrava. Aparte del consumo de ancho de banda que supondrá a la red corporativa que se verá sobrecargada a su vez.image

Es por ello, que a veces nos interesa optimizar este resultado. Esto lo podemos lograr por medio del split tunneling. Se trata de una técnica que permite dividir (“split”) el tráfico por medio de unas tablas de enrutamiento que establecemos en el cliente. De esta forma, se discrimina el tráfico, y sólo aquel que va destinado a la red corporativa es dirigido a través del túnel vpn, el resto íría por nuestra conexión normal a Internet.  image

Ventajas

Con este tipo de técnicas conseguimos lo siguiente:

  • Red más eficiente y rápida: sólo redirige el tráfico necesario, reduciendo el número de saltos para alcanzar el destino.
  • Privacidad: debido a que no todo el tráfico es redirigido a nuestra oficina, éste no deja rastro en los dispositivos que pudiera atravesar en la red corporativa.
  • Mayor ancho de banda: la red corporativa no se ve tan sobre cargada debido a que no todas las conexiones no son redirigidas hacia su infraestructura

Inconvenientes

Pero claro, este método puede no sernos útil en todos los casos. Hay ocasiones en las cuales tenemos que seguir empleando nuestra vpn de la forma habitual, ya que tiene sus desventajas:

  • Si la red de origen tiene el mismo direccionamiento no podremos emplearlo, a menos que lo cambiemos, debido a que sería incapaz de enrutarlo correctamente.
  • Aplicaciones vinculadas a ip’s o geolocalizadas: en otras situaciones simplemente es necesario que nuestro tráfico de Internet tenga que salir forzosamente por la red de la oficina.
  • Pérdida de seguridad: debido a que las conexiones que no van por el túnel vpn no está monitorizadas (al no se redirigidas a la propia infraestructura) se pierde control sobre ellas.

INSTALACIÓN DE CMAK Y CREACIÓN DE EJECUTABLE

Connection Manager Administration Kit (CMAK)

Se trata de una herramienta que se emplea para la personalización de conexiones de red remotas, permitiendo crear perfiles personalizados mediante un asistente.

Esta herramienta viene embebida dentro de las características de Windows, pero para poder usarla antes debemos habilitarla. Para ello vamos a “Programas y características”, y seleccionamos el tick de la característica.

Creación de perfiles de conexión

Una vez agregada la característica, podremos empezar a crear perfiles personalizados de conexión.  Ejecutamos la aplicación, que mostrará un asistente que guiará la creación del perfil. Hacemos clic en siguiente, y seleccionamos el sistema operativo en el que se va a instalar.image

Con CMAK también podemos modificar perfiles ya creados con anterioridad, pero para este ejemplo vamos a crear un nuevo, indicando el nombre que queremos que aparezca en las conexiones de red, así como el nombre que tendrá el ejecutable e introducimos el servidor vpn al que nos vamos a conectar.

image

Podemos modificar múltiples parámetros de la conexión como pueden ser los servidores DNS, los sufijos de conexión , así como la estrategia VPN, y la autenticación. image

A continuación y uno de los pasos más importantes (sino el que más) es agregar tablas de enrutamiento, agregándolas mediante un fichero de texto que importamos desde nuestro equipo. Los datos a añadir en nuestro fichero de texto serían los siguientes: primero eliminar la puerta de enlace predeterminada y a continuación añadir cada una de las rutas de nuestra red privada virtual.

REMOVE_GATEWAY
ADD ruta MASK mascara puerta_enlace METRIC default IF default

image

Según sigamos el asistente nos va a permitir realizar gran número de personalizaciones como  agregar la configuración proxy de Internet ,scripts, acciones personalizadas, imágenes, icono de programa, etc.

image

Por último pulsamos finalizar y nos generará un exe con todas las configuraciones que hemos establecido.

image

El ejecutable se encontrará en una subcarpeta con el nombre que le hayamos dado al perfil . Este ejecutable  lo vamos a poder distribuir  masivamente por medio de GPO’s, System Center, etc.

Como comentario final me gustaría indicar que CMAK es una herramienta muy útil para la creación de clientes vpn ya que nos permite crear un ejecutable bastante personalizable y profesional, con la opción, entre otras, de realizar split tunneling.  ¡¡¡Hasta la próxima!!!