PowerShell Utilities Series: DMCredential o cómo no escribir credenciales en PowerShell

Como administradores de sistemas que somos, si nos encontramos bajo Windows es evidente que PowerShell es una de nuestras más potentes y versátiles herramientas de trabajo. Gracias a sus capacidades de Remoting, con PowerShell podemos conectarnos a otros sistemas para llevar a cabo tareas de mantenimiento y administración en ellos. En mi día a día no es raro tener que entrar varias veces a Office 365, Exchange Online y controladores de dominio desde PowerShell. Sin embargo, esto requiere que nos autentiquemos.

Cualquier administrador de sistemas que use PowerShell estará más que familiarizado con esta línea de comando:

De forma que tendremos que escribir nuestro nombre de usuario y contraseña que se almacenará en la variable $cred, de tipo System.Management.Automation.PSCredential.

En este otro artículo Antonio ya nos contó que podemos automatizar el proceso de inicio de sesión en otra máquina a través de PowerShell, escritura de credenciales incluidas; ya que podemos almacenarlas cifradas en nuestro script. Si somos capaces de hacer esto en un script que conecta con Exchange, ¿no podríamos hacerlo también de forma más genérica y utilizarlo para conectarnos a cualquier sistema? David Moravec, escritor de la PowerShell Magazine llegó a conclusiones similares allá por 2012.

David creó un sencillo módulo que nos permite almacenar las credenciales que necesitemos en un archivo, estando estas perfectamente cifradas de igual forma que las de Antonio. El código del módulo puede verse á continuación:

Básicamente se compone de tres cmdlets:

  • New-DMCredential. Crea un nuevo archivo cifrado que contiene las credenciales que especifiquemos. Por defecto estas se almacenarán en $env:userprofile.
  • Get-DMCrednetial. Lee un archivo que contenga credenciales almacenadas con New-DMCredential y las carga en una variable global. Para que este cmdlet funcione correctamente la máquina sobre la que se ejecuta New-DMCredential y Get-DMCredential debe ser la misma.
  • Show-DMCredential. Muestra la contraseña cifrada contenida en un archivo en texto plano. De igual forma que Get-DMCredential, es necesario que las credenciales hayan sido almacenadas en la misma máquinas desde la que son leídas.

De esta forma, crear un nuevo archivo es tan sencillo como:

Este cmdlet nos pedirá que introduzcamos unas credenciales y acto seguido generará un nuevo archivo llamado o365cred que las contiene. Dichas credenciales pueden ser recuperadas así:

Esto creará la variable $global:o365cred y almacenará las credenciales en ella. Fijaos que el nombre del archivo y el de la variable coinciden y que el cmdlet en sí no devuelve nada salvo por el parámetro Alias. Como la variable es global, la tenemos disponible para usar en cualquier ventana o runspace del sistema.

Útil y sencillo de usar ¿verdad? Pero aquí no acaba la cosa. Viendo el bien trabajo que Moravec hizo, se me ocurrió darle una vuelta de tuerca más y hacer que esta variable con credenciales se cargase en memoria cada vez que hacía el simple gesto de abrir una consola de PowerShell, al igual que ya hacía con el módulo de ls a color.

Conseguir esto es una cuestión tan sencilla como agregar el contenido adecuado a nuestro archivo de $profile. A mí me bastó con estas líneas:

De esta forma cuando abra una ventana de PowerShell:

pscred

Mis credenciales se encontrarán automáticamente disponibles en la variable $global:pscred y no tendré que escribirlas. Ni que decir tiene que en este caso nuestro equipo debe bloquearse siempre (Windows + L) siempre que lo dejemos desatendido por razones obvias.

¡Happy Powershelling!

Enlace relacionado: #PSTip Storing of credentials

Azure Backup

En el mundo empresarial se tiene más conciencia que en el mundo personal de la necesidad de las copias de seguridad para no perder los datos, pero lo normal es realizarlo en soportes físicos (como puede ser un disco duro externo). Gracias a Azure, la plataforma en la nube de Microsoft, podemos guardar estas copias en un espacio de internet reservado para ello, sin tener que preocuparnos de él.

Configurar la copia de seguridad

Para empezar, debemos crear un nuevo elemento en Azure que guarde la copia de seguridad. Para ello, en el Portal de administración, pulsamos sobre New, Data Services, Recovery Services, y elegimos Backup Vault. Haremos una Creación rápida en la que pondremos el nombre y la región donde estarán nuestros datos.

1

Una vez haya terminado de crearse, la podremos encontrar en la sección Recovery Services.

Tendremos que descargarnos, en la dashboard del backup, las credenciales de almacén (Vault credentials), ya que nos serán necesarias en un futuro, y Microsoft Azure Backup Agent, que será el programa encargado de las copias de seguridad en nuestro ordenador.

clip_image002

Instalar Microsoft Azure Backup Agent

El siguiente paso es instalar el  programa que nos permitirá conectarnos con Azure para realizar la copia de seguridad. El proceso es bastante simple, y una vez acabado, tendremos que configurar algunos parámetros.

clip_image003

El primero de ellos es las credenciales de almacén. Buscaremos el archivo con ellas, que descargamos al finalizar de configurar el backup en Azure, y pondremos su ruta al programa.

clip_image004

Lo siguiente son los ajustes de cifrado. Aquí generaremos una contraseña (o pondemos una que nosotros queramos), y la guardaremos en nuestro PC o periférico (recomendable esta segunda opción).

clip_image005

El siguiente paso es registrar el servidor. Cuando acabe de hacerlo, nos mostrará un mensaje, y a partir de ese momento aparecerá en la pestaña Servers del Backup en Azure.

clip_image006

Programar la copia de seguridad y recuperar datos

El programa se instalará con el nombre de Microsoft Azure Backup. En él podremos realizar diferentes acciones seleccionándolas en el panel de la derecha. Entre ellas podremos encontrar las opciones de programar las copias de seguridad para que se realicen automáticamente y recuperar nuestros datos alojados en Azure.

clip_image007

Todos los procesos son guiados con un asistente que nos pedirá los datos necesarios en cada paso.

En el caso de la programación, nos pedirá los siguientes datos:

  • Elementos de los que se hará la copia de seguridad.
  • Programación.
  • Política de retención de las copias, para borrar las antiguas.
  • Copia inicial.

clip_image008

Una vez creada la primera copia, nos aparece una nueva opción en el panel de la derecha (Back Up Now), que nos permitirá crear una copia de seguridad en el momento.

clip_image009

Desde el momento que realicemos la primera copia de seguridad, nos aparecerá un nuevo item en la pestaña Protected Items del Backup en Azure.

El proceso de restauración es similar. Únicamente tenemos que introducir los datos que nos pide el asistente:

  • Servidor en el que se creó el backup.
  • Buscar o seleccionar los ficheros a recuperar.
  • Seleccionar el volumen y la fecha.
  • Otras opciones de recuperación.

Como veis, es una forma muy sencilla de mantener una copia de nuestros datos en la nube, despreocupándonos de ellos.

Para más información, tenéis una sección dentro de la web de Microsoft Azure.

ADFS 3.0 y SSL Bindings

¡Hola a todos! Hoy vamos a hablar de una de nuestras especialidades: ADFS. Con una pizca de PowerShell. Y una dosis de misterio.

Una de las partes más importantes en un despliegue de ADFS es el certificado de la máquina, que la identifica de forma unívoca y nos permite realizar el proceso de autenticación de forma segura. Pero como todo certificado tiene fecha de caducidad, debe ser renovado periódicamente.

En este artículo no vamos a entrar en cómo renovar el certificado de ADFS, sino en uno de los problemas que pueden aparecer cuando por cualquier motivo el certificado no se renueva correctamente.

En este caso de estudio, se dispone de un despliegue con varios servidores de ADFS con balanceo de carga para dar un servicio robusto de autenticación. El servicio está funcionando correctamente durante meses, y finalmente llega el día de la renovación: Los certificados se renuevan en cada máquina de la granja, quedando instalados en Cert:\LocalMachineMy y configurados en el servicio ADFS. Todo ha sido correctamente actualizado, los usuarios pueden iniciar sesión correctamente, y todo parece funcionar a la perfección.

Días después, empiezan a llegar avisos de que algunas personas no pueden iniciar sesión en Office 365 desde sus máquinas. ¡Algo está pasando!

Síntomas:

Hay un problema, que afecta a máquinas aleatorias. Todo el que intenta iniciar sesión en Office 365 desde esas máquinas no puede acceder a la página de inicio de sesión de ADFS. Cuando esos usuarios usan otras máquinas, todo funciona correctamente. El resto de usuarios no experimentan problema alguno desde sus equipos.

httpError

En principio, podemos pensar que tenemos un problema de red que está afectando específicamente a algunas máquinas de la red. Pero el Firewall, routers y todo parece estar funcionando bien, y sus configuraciones son correctas. Otra apuesta puede ser que haya un fallo relacionado con el sistema de balanceo de carga de los servidores ADFS. Pero después de hacer las comprobaciones oportunas y verificar que el balanceador funciona correctamente, el problema sigue apareciendo.

 

¿Qué más podemos hacer?

Comprobar el estado de las máquinas de la granja de ADFS. Una de las comprobaciones más importantes que podemos hacer es revisar el estado del registro de eventos del sistema. Y efectivamente, en una única máquina de la granja nos encontramos con una serie de eventos HTTP que apuntan a la causa del problema.

HTTPEvent Error

Errores con la configuración del endpoint de ADFS. Como el balanceador hace pruebas sobre el endpoint y puede conectar, no se elimina la máquina del grupo de balanceo. Pero como el problema está en el certificado SSL del Endpoint, la conexión se interrumpe y no se genera la página de inicio de sesión.

Este problema aparece cuando actualizando los certificados de ADFS, los certificados del servicio se actualizan pero los certificados del endpoint no se han actualizado. Esto provoca que aunque el registro de eventos de ADFS aparezca completamente libre de errores y problemas, el servicio en sí es completamente inalcanzable.

Es momento de comprobar el estado de los certificados. Esto se puede hacer fácilmente con PowerShell. Se puede observar que en la máquina afectada se ha instalado un certificado cuyo Hash (Thumbprint) empieza por 991EB2. :

certificates

A continuación, hay que comprobar si este certificado es el mismo que está utilizando el servicio de ADFS. En la siguiente captura de pantalla vemos que efectivamente, el certificado instalado en la máquina de la granja es el mismo que se utiliza en el servicio de ADFS (991EB2….), luego el error no está en que se haya realizado mal el proceso de actualización.

Esto se puede ver gracias al cmdlet Get-AdfsCertificate que se debe ejecutar en el servidor primario de la granja.

adfsCert

El siguiente paso, es comprobar el estado de los certificados de comunicaciones.

¡Eureka! ¡Aquí está el problema! Aunque se haya realizado correctamente el procedimiento para actualizar los certificados de ADFS, no se han actualizado los certificados de los endpoint de comunicaciones. Puesto que el certificado “antiguo” ya había sido eliminado del sistema, cuando se intenta realizar una conexión a los puertos 443 o 49443 de la máquina, se intenta realizar una validación de certificados… de un certificado inexistente (Con el hash 0CC244…). Ésta es la raíz de la situación que está provocando el error de conexión. Al hacerse referencia a un certificado inexistente, no se puede establecer el canal de comunicación, produciendo como resultado la pantalla de error que nos dice que la página de autenticación no se puede mostrar.

badSSLCert

El proceso de corrección es bastante sencillo en este caso: Simplemente hay que eliminar los endpoint no válidos, y crearlos nuevamente, pero ahora especificando el certificado correcto. Es muy importante conservar la información completa de los endpoints originales, porque se necesita para recrearlos. Se puede copiar la salida de “netsh http show sslcert” en un notepad, o ejecutarlo en una shell diferente de donde se va a hacer la operación de actualización. Nota: Es necesario lanzar la PowerShell en modo Administrador para poder modificar los endpoints.

Una vez abierta la Shell de Administrador, se lanzan los siguientes comandos:

Remove SSL Cert

Con esto, se han eliminado todos los endpoints que utilizaban el certificado antiguo. A continuación, hay que volver a crear los endpoints. Para ello se lanza el comando “netsh http”, y una vez dentro de netsh, escribir lo siguiente

Add SSL Cert

Con esto, se han añadido nuevamente los endpoints al sistema, con el certificado con hash que empieza por 991EB2. Comprobamos con “netsh http show sslcert” que efectivamente todo está correcto ahora.

GoodSSLCert

¡Y eso es todo! Una vez corregido el problema con el certificado, los errores de conexión dejaron de producirse, todas las máquinas de la red podían acceder a los servicios de Office 365, y finalmente se resolvió el misterio. Parafraseando a Sherlock Holmes… “Cuando todo aquello que es imposible ha sido eliminado, lo que quede, por muy improbable que parezca, es la verdad”

Paget_holmes

Desayuno de Infraestructura con Plain Concepts

Desayuno Infraestructura

Los que nos conocéis ya sabéis que no paramos quietos y escribo este post para invitaros a todos a nuestro Desayuno de Infraestructura que tendrá lugar el próximo jueves 26 de febrero en las oficinas de Microsoft Ibérica de Madrid. Vamos a estar todo el equipo al completo, incluidas nuestras recientes incorporaciones, así que tendréis la oportunidad de hablar con nosotros de todos los temas que os interesen.

Los temas que vamos a tratar son los siguientes:

  • Identidad: los misterios del metaverso con Forefront Identity Manager.
  • Single Sign On e IdPs: Active Directory Federation Services (ADFS)
  • Identidad híbrida con Azure Active Directory.
  • Cross-premises: integrando redes e infraestructura con Microsoft Azure

¡La asistencia es totalmente gratuita! ¡Os esperamos el día 26 en las oficinas de Microsoft!

REGISTRO

INFORMACIÓN DETALLADA – SITIO WEB DEL EVENTO

Network Monitor (2/2)

¡Hola de nuevo!

¿Echabais de menos a Network Monitor? ¿Os supo a poco el anterior artículo donde hacíamos una introducción al producto?

Continuando con algunas curiosidades que podemos hacer con la herramienta de análisis de red de Microsoft, hoy vamos a conocer aquellas un poco más avanzadas:

Ejecución de la captura desde la línea de comandos:

Aquí tenéis la referencia general, donde podemos ver cosas tan interesantes como la posibilidad de especificar la red donde queremos capturar, o el tamaño máximo de la captura.

Managing Network Monitor from the command line: http://technet.microsoft.com/en-us/library/cc782726(v=ws.10).aspx

 

Trazas circulares:

Una de las cosas que más nos puede ayudar en el troubleshooting de un problema que no podemos reproducir en cualquier momento, es tener una captura que se mantenga en el tiempo, que el tamaño no se haga inmanejable, y que podamos pararla en el momento en el que el problema surja de nuevo.

La línea de comandos de Network Monitor nos permite hacerlo a través de las trazas circulares, pudiendo establecer un tamaño máximo de la traza, una hora de inicio o de fin, etc.

En el siguiente ejemplo, cuando se alcance el tamaño de la traza especificado, se creará un nuevo fichero de la cadena y se seguirá capturando, del modo que quedarían de la forma test(1).chn, test(2).chn, etc.

 

Fusionar trozos de capturas en una más grande:

Imaginaros que en ejemplo anterior, debido al tamaño de cada trozo o de la cantidad de datos que estamos capturando, tenemos que estar cambiando continuamente de trozo para analizar un problema. ¿No sería genial localizar la conversación que queremos en un grupo de trozos, y combinarlos en una traza única?

Network monitor también nos permite hacerlo con la siguiente sentencia:

 

Arrancar una captura con Windows:

Aunque Network Monitor permite capturar durante el arranque del Sistema Operativo, interesante sobre todo para escenarios de “slow logon”, la verdad es que no es el procedimiento más sencillo del mundo:

Capturing a trace at boot up: http://blogs.technet.com/b/netmon/archive/2010/01/04/capturing-a-trace-a-boot-up.aspx

Desde luego, no estamos vendidos sin opciones, y en este caso acude al rescate la herramienta de linea de comandos incorporada con el propio Windows para todos los temas de Networking: netsh

Simplemente tenemos que añadir la opción de persistent, y la herramienta seguirá capturando, incluso durante el arranque del sistema operativo:

clip_image002

No nos tenemos que olvidar de parar la captura:

Luego con Network Monitor podemos abrir sin problema este tipo de ficheros .etl cuando se trata de trazas de red.

clip_image004

 

Asociar la parada de la captura a un Evento:

Imaginaros que tenemos localizado un problema porque cuando ocurre aparece un evento en el Event Viewer, y nos gustaría analizar a nivel de red qué ocurre justo antes, de cara a determinar que propicia la aparición del problema. Con Network Monitor también podemos hacerlo, os dejamos las instrucciones en el siguiente enlace:

EventMon: Stopping a Capture Based on an EventLog Event: http://blogs.technet.com/b/netmon/archive/2007/02/22/eventmon-stopping-a-capture-based-on-an-eventlog-event.aspx

 

Microsoft Message Analyzer:

Hace un par de años que Microsoft sacó la evolución de Network Monitor, llamado Message Analyzer.

La verdad que personalmente no lo he usado mucho. No sé si porque ya estoy acostumbrado a Network Monitor, o por comodidad con los menús, pero tiene sus mejoras, como la posibilidad de cargar nuevos parsers, ver en un formato legible documentos, fotos o videos directamente seleccionando el grupo de trazas que lo forman, etc.

Os dejo el último artículo que ha presentado el grupo que lo lleva para que os hagáis una idea de lo potente que puede ser:

Troubleshooting Microsoft Azure Storage with Message Analyzer: http://azure.microsoft.com/blog/2015/01/27/troubleshooting-microsoft-azure-storage-with-message-analyzer

 

Y con esto acabamos la serie de artículos sobre Network Monitor. Esperamos que os hayan gustado.

¡Happy networking!