Rutas en Windows

Hoy voy a tratar un tema relacionado con redes: las rutas de red en Windows. Nuestro sistema operativo conforme a la información que obtiene de la interfaz de red establece de forma automática una serie de rutas o reglas que van a permitir la conectividad en la red. Esto lo podemos ver gráficamente con el comando route print.

route0.1

En la salida de este comando, podemos diferenciar varias partes, así en la parte superior aparece un listado de las interfaces que tiene reconocidas. A continuación figura la tabla de enrutamiento para ipv4 (esta va a ser sobre todo la parte que nos interese) y sus respectivas rutas persistentes (si las hubiera). Por último aparece también otra tabla de enrutamiento para el protocolo ipv6.

Nos vamos a centrar en la tabla de enrutamiento para ipv4.. En las rutas activas que están establecidas encontramos una red de destino , la red en la que nos encontramos, la puerta de enlace, la ip que se le ha asignado a esa interfaz y la métrica. La métrica es un valor número que establece la prioridad de esa ruta respecto a otras. Conforme a esta tabla de enrutamiento, Windows sabe a qué red debe dirigir los datos.

Las tablas de enrutamiento se establecen de forma dinámica, si añadimos una ruta a nuestra tabla, al reinicar el sistema operativo dicha desaparecerá. En ocasiones nos va a interesar crear rutas que permanezcan de manera fija y no desaparezcan (esto es rutas persistentes). Este puede ser el caso de un equipo disponga de 2 adaptadores en el que se quiera que, de forma predeterminada se redirija el tráfico por otro adaptador diferente del predeterminado.

Así, por ejemplo partimos de un ordenador con la tabla de rutas anteriormente mostrada. Tiene 2 interfaces cuyas ips son 10.2.1.133 y 172.16.16.11

route2

Si queremos enrutar todo el tráfico que pertenezca a la red 172.0.0.0 a través de la interfaz 172.16.16.162 tenemos que crear una ruta estática, ya que por defecto nos lo enrutará por la otra interfaz que tiene una métrica inferior. Así con el comando:

route add red-destino mask máscaraSubred puertaEnlace metric métrica if interfaz

route add –p 172.0.0.0 mask 255.0.0.0 172.16.15.162 metric 1 if 17

image

En nuestro caso añadimos –p para que la ruta sea persistente y se mantenga pese a los reinicios.

Estas rutas estáticas se guardan a nivel de registro en la ruta:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersPersistentRoutes

route3

Una vez ejecutado el comando anterior, procedemos a verificar si la ruta figura en rutas permanentes con route print. A partir de este momento, todo el tráfico que vaya a la red 172.0.0.0 será redirigido por la puerta de enlace 172.16.15.162.

route5

Y hasta aquí el post de hoy. Disfrutad de las fiestas y nos vemos el próximo año.

Enlazar suscripción de Azure con Azure Active Directory (u Office 365, Intune, etc…)

La administración de Azure Active Directory y como esta se relaciona con las instancias de Azure AD que ya tenemos en servicios como Office 365 o Intune puede llegar a ser realmente confusa, así que en esta semana navideña me ha parecido muy oportuno dedicar un post a aclarar todo este tema.

 ¿Qué es Azure Active Directory?

Azure Active Directory (AAD) es una plataforma de identidad en la nube gestionada y hospedada por Microsoft. Un buen rango de servicios de Microsoft se apoyan directamente en Azure Active Directory como su base de usuarios y autenticación. Es por ello que si disponemos de un tenant de Office 365, Intune o CRM Online, ya estamos usando Azure Active Directory aunque no tuviéramos una constancia de ello.

Por tanto podríamos decir que todo los servicios que usen Azure Active Directory comparten la misma base de datos de usurios y el mismo proceso de autenticación, obteniéndose el consiguiente Single Sign On entre ellos.

A continuación podéis ver un esquema de cómo distintos servicios se valen de Azure Active Directory para gestionar su identidad:

image

Es importante reseñar que NO es lo mismo Azure Active Directory que Active Directory en Azure. El segundo se refiere a llevar controladores de dominio de nuestra infraestructura a máquinas virtuales de Azure para así poder desplegar servicios dependientes de los mismos en la nube, tema que nos dará para un artículo en otra ocasión.

Los siguientes servicios usan Azure Active Directory:

  • Office 365
  • Intune
  • Dynamics CRM Online
  • Azure Rights Managements System

¿Como integro el Azure Active Directory de Office 365 con mi suscripción de Azure?

A pesar de que el nombre induzca a confusión, Azure Active Directory y una suscripción de Azure son entidades separadas. Esto quiere decir que tener AAD no implica tener una suscripción de Azure, por lo que existe un procedimiento para integrarlo con tu suscripción.

  1. Iniciamos la sesión en nuestra suscripción de Azure.
  2. Vamos a New –> Active Directory –> Directory –> Custom Create
    image
  3. Seleccionamos Use existing directory.
    image
  4. El asistente nos pedirá iniciar sesión con nuestras credenciales del tenant de Azure Active Directory (que pueden ser las de nuestro administrador global de Office 365).
  5. Nuestro Azure Active Directory queda enlazado con nuestra suscripción de Azure.

Como resultado deberíamos ver algo así:

image

Directorio por defecto

Después de hacer el enlace, si este es el único directorio que tenemos, quedará establecido automáticamente como directorio por defecto. Si tuviésemos más directorios bajo administración de la misma cuenta de usuario, podríamos seleccionar cuál de ellos es el directorio por defecto de nuestra suscripción de Azure. Este concepto indica en qué directorio nuestra suscripción de Azure va a confiar para poder realizar autenticación y aprovisionar usuarios. Gráficamente se puede ver en este esquema de la Microsoft Technet:

image

Es importante también reseñar que distintas suscripción de Azure pueden confiar en el mismo AAD, pero una suscripción de Azure sólo puede confiar en un único AAD. Por tanto, en nuestra suscripción el directorio por defecto es único. Los usuarios de este directorio serán los habilitados para poder autenticar con distintos servicios SaaS de Azure, como RemoteApp.

A la vista de lo explicado, podemos entender que tampoco sería posible integrar los directorios de dos tenants distintos de Office 365 bajo una única suscripción de Azure.

Ahora puedo ver mi Azure Active Directory con cualquier suscripción de Azure, ¿está enlazado a todas?

Esta es la parte truculenta de la historia. Cuando iniciamos la sesión en manage.windowsazure.com y vemos entre la lista el servicio de Active Directory, no se nos están mostrando los AAD enlazados con la suscripción, sino aquellos para los que el usuario con el que nos hemos validado al entrar en manage.windowsazure.com tiene permiso para administrar. De esta forma, si vemos:

image

Esto viene a significar que nuestro usuario tiene permiso para administrar 2 AAD distintos que no necesariamente están enlazados con nuestra suscripción de Azure. Deberemos establecer un directorio por defecto (e insisto, sólo uno) para que pueda pasar a ser utilizado.

Espero que el articulo haya servido para aclarar dudas sobre la administración de AAD, donde la interfaz puede inducir a bastante confusión.

Enlace relacionado: How Azure subscriptions are associated with Azure AD – Microsoft Technet

FIM 2010R2: Pasar de Evaluacion a Version Completa

Hay productos complejos por un lado y hay productos muy complejos como FIM 2010 R2. Y hay ocasiones en las que antes de comprar un software complejo, se decide descargar una versión de evaluación para probarla y ver si se adecúa a las necesidades de la empresa. Por supuesto, una vez montado el piloto, resulta que funciona tan bien, que la empresa decide pasar de la versión de pruebas a una licencia completa… pero invirtiendo la menor cantidad posible de tiempo en el proceso de cambio.

En algunas ocasiones, pasar de versión de pruebas a licencia completa significa escribir un número de serie. En otras ocasiones, el proceso es más complejo y se tienen que seguir otros pasos. ¿Cuáles?

El primer impulso de un administrador de sistemas avispado sería acudir a la ventana de “Acerca de” del servicio de Sincronización de FIM y ver si hay algún lugar en el que introducir una clave de registro… pero nos encontramos en su lugar con una cuenta atrás que nos recuerda que nos quedan sólo 175 días de demostración. Ningún sitio para introducir registros ni botones de activación de licencia por Internet, ni nada similar.

isDemo

Es en éste momento en el que nos toca pasar a la Primera Fase del proceso de actualización:

Primera fase: Exportar clave de cifrado.

Dado que para instalar la versión completa hay que desinstalar la actual versión de FIM, es necesario hacer una copia de seguridad de la clave de cifrado de la Base de Datos. Para ello se tiene que abrir el “Synchronization Service Key Management” y proceder a exportar la clave de cifrado. Tener una copia de esta clave es fundamental, ya que garantiza la seguridad de la Base de Datos del servicio de Sincronización de FIM, y en caso de pérdida, los datos serían irrecuperables.

key-mgmt

Export-keyset

Para exportar la clave de cifrado, necesitamos las credenciales de la cuenta de Servicio de FIM que hemos utilizado durante la instalación.

Export-keyset1

Proseguimos con el asistente, eligiendo dónde guardar la clave, y ¡listo! Ya tenemos la copia de la clave. Ahora se puede pasar a la fase dos.

Segunda Fase: Desinstalación de FIM.

Este paso no tiene ningún misterio: Teniendo a mano el CD de instalación de FIM, se lanza el instalador de “FIM Synchronization Service”, y aparece este diálogo:

ReminderDemo

En resumidas cuentas, esta ventana indica que estamos utilizando una versión de demostración de FIM. Se cierra y ya sí aparecen las típicas opciones de “reparar instalación” y “desinstalar”. En este caso se elige desinstalar, lo que elimina la instalación de FIM y con ella la Clave de cifrado, pero mantiene la Base de Datos en su lugar. Afortunadamente, ya se hizo una copia de seguridad de la clave en la fase uno.

Tercera fase: Instalación.

Se procede a Instalar FIM normalmente, siguiendo el asistente. Es fundamental especificar en el instalador la misma base de datos que se estaba utilizando en la versión de demostración. Una vez completados los pasos de configuración, el programa empieza a instalar y muestra el siguiente diálogo:

useExistingDB

Buenas noticias, en este caso se desea restaurar la configuración con la misma base de datos, así que toca elegir “Yes”. De haber sido descuidados, puede ser que el producto licenciado que estamos instalando tenga un número de versión inferior. En tal caso, el instalador es lo suficientemente inteligente como para detectarlo, y darnos la opción de cancelar el proceso, o en caso de proseguir, recordar que es necesario pasar a la última versión una vez se haya terminado de instalar el producto.

useExistingDB_versionConflict

Si por el contrario, se está instalando exactamente la misma versión de FIM, el siguiente paso es importar la clave de cifrado. Es el mismo archivo que fue exportado durante la fase uno. Se le proporciona el archivo con la clave al instalador, y él se encarga de realizar las operaciones necesarias para que una vez esté todo instalado, FIM pueda desencriptar la Base de Datos y trabajar con total normalidad.

provideEncriptionKeys

 

Conclusión

Una vez se ha terminado de instalar, y para asegurarse de que todo ha funcionado correctamente, se puede volver a abrir el cuadro de diálogo “Acerca de…”, donde se puede comprobar que en efecto, ya no aparece una terrorífica cuenta atrás recordando que la instalación de FIM dejará de funcionar en algún momento del futuro. Todo lo demás (Metaverso, Agentes, etc) debería seguir funcionando exactamente igual que antes de la actualización.

notDemo

 

¡Y eso es todo de momento!

Elección del adaptador de red en equipos Windows

¿Os habéis fijado que cuando estamos conectados por wifi y conectamos el cable de red, automáticamente cambia el flujo de red? ¿Sabéis como establece Windows el adaptador adecuado para llegar a un recurso de red?

Hay dos factores que influyen principalmente en la elección de una conexión por parte de un equipo Windows:

  1. Si las IPs de los adaptadores pertenecen a diferentes subredes, lo primero que evalúa es la proximidad del recurso al que se desea conectar, haciendo matching con las máscaras de subred. Por tanto, si deseamos forzar a utilizar una conexión distinta de la que evalúa por defecto, deberemos eliminar la ruta que va a utilizar (la que considera más próxima), y asegurarnos que a través de que la ruta que existe para el adaptador deseado, se consigue llegar al recurso igualmente.
  2. Si las IPs de los adaptadores pertenecen a la misma subred, a partir de Windows XP, el valor que se evalúa para elegir una conexión u otra es la Métrica. Ésta se calcula automáticamente para cada tarjeta de red en función de su velocidad.

Cualquier cambio manual, debe ser seguido de un reinicio de los adaptadores de red.

Dado que este valor es teórico, a menudo sucede que una red inalámbrica “N” con velocidad nominal de 300Mbps tiene asignada una métrica 10, considerándose más rápida que una conexión Ethernet con 100Mbps y asignada una métrica 20 (cuánto más pequeño, mejor).

Sin embargo, se puede asignar manualmente los valores de la métrica en las tarjetas de red para obligar a su orden de preferencia.

Es necesario que el número elegido sea entre 5 y 50. Por defecto los valores que calcula son:

Link Speed Metric
Greater than or equal to 2 GB 5
Greater than 200 Mb 10
Greater than 20 Mb, and less than or equal to 200 Mb 20
Greater than 4 Mb, and less than or equal to 20 Mb 30
Greater than 500 kilobits (Kb), and less than or equal to 4 Mb 40
Less than or equal to 500 Kb 50

Si el valor de la métrica es el mismo para varios adaptadores, el orden de preferencia es el indicado en el “Binding Order”.

Podemos visualizar los valores de métrica establecidos mediante el comando:

 

O con el cmdlet de PowerShell:

 

Podemos modificar su valor a través de la interfaz gráfica:

clip_image002

O también mediante consola de comandos, ejecutando:

 

O mediante el cmdlet de PowerShell:

 

Esperamos que os haya parecido interesante y nos vemos la próxima semana.

Happy networking!

Problemas con actualizaciones automáticas

Esta semana voy a abordar un tema que me he encontrado recurrentemente en muchos equipos: el problema con las actualizaciones automáticas. Algunas veces, después de que se nos instalen una serie de actualizaciones, nos encontramos que al reiniciar nuestro equipo deja de funcionar correctamente. ¿Qué podemos hacer? Este tema depende del error que nos esté dando.

Puede darse el caso que al reiniciar el equipo, éste intente terminar de configurar las actualizaciones y nunca acabe con lo que nos encontremos en un bucle infinito de reinicios y configuraciones. Este problema puede surgir porque cuando nuestro equipo se haya apagado de repente o algún parche esté dando problema. Cuando esto sucede, en nuestro equipo se crea un archivo llamado pending.xml en la carpeta C:WindowsWinsxs que indica al sistema la actualización que debe terminar de configurar. Si queremos acabar con este comportamiento, debemos acceder a nuestro disco duro mediante una consola; así podemos iniciar nuestro ordenador con un cd o pendrive con una instalación de Windows o DART (http://technet.microsoft.com/en-us/windows/hh826071.aspx). Accedemos a la consola cmd y una vez allí procedemos a renombrar el archivo pending.xml por pendingxml.old con el comando rename. Una vez realizados estos cambios, salimos del cmd y procedemos a reiniciar nuestro equipo con normalidad.

En otras ocasiones, si bien se han podido instalar vemos que hay alguna actualización crítica fundamental para la seguridad de nuestro sistema nos está  dando error continuamente y no nos permite instalarla. En este caso, una de las primeras actuaciones que deberíamos realizar es comprobar la integridad de los archivos de sistema.  Abrimos un cmd con permisos de administrador y desde allí ejecutamos el comando sfc /scannow (System File Checker)

sfc1

Una vez ejecutado este comando, sale un aviso indicando que este proceso puede tardar un tiempo y un porcentaje del proceso total.

sfc2

Cuando ha terminado, nos ofrece el resultado pudiendo ser éste: que no encuentre ningún problema (la integridad de los archivos está bien), que haya encontrado incoherencias y las ha reparado (normalmente requiere un reinicio) o por último las ha encontrado pero ha sido incapaz de repararlas. Cuando esto sucede podemos revisar el archivo CBS.log que se encuentra en C:WindowsCBScbs.log. Dentro de este fichero debemos localizar aquellas entradas que tenga la marca [SR] y que nos indicará dónde ha encontrado la incoherencia y así obtener más información.

Podemos intentar reparar estos errores restaurando la imagen de windows, así, podremos ejecutar el comando Dism /Online /Cleanup-Image /RestoreHealth dese un cmd también con permisos de administrador.

Y, por último, me despido indicando que debemos de tener en cuenta que cada caso que nos encontremos puede ser distinto y no siempre vamos a poder proceder de la misma forma, por ello, a la hora de encontrarnos con problemas de este tipo no debemos olvidar todas esas herramientas que nos puedan dar información: visor de eventos, administrador de tareas, monitor de rendimiento, sin olvidar las herramientas de sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb545021.aspx)