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!

Alerta de Seguridad: Ejecución remota de código MS15-078

https://technet.microsoft.com/library/security/MS15-078

Esta semana se ha desplegado un parche de seguridad crítico que corrige una vulnerabilidad de ejecución de código remoto. Esta vulnerabilidad afecta a todas las ediciones de Windows. El vector de ataque se basa en la apertura de documentos diseñados específicamente a tal efecto, o la visita a páginas web que contenga tipografías OpenType incrustadas que hayan sido diseñadas para explotar el fallo.

La vulnerabilidad se produce por la forma en que la “Windows Adobe Type Manager Library” gestiona las fuentes OpenType.

Formas de explotación: Se requiere interacción por parte del usuario objetivo, que ha de abrir un documento con una fuente openType  incrustada que haya sido diseñada a tal efecto, o bien visitar una página web que contenga la tipografía OpenType.

Acciones a realizar: Toda máquina que se haya actualizado y necesite un reinicio debe ser reiniciada lo antes posible para evitar posibles infecciones que sucedan durante la navegación web en sitios de poca confianza. En las máquinas que no tengan configurado Windows Update para que descargue e instale automáticamente las actualizaciones, el sistema debe ser actualizado manualmente y reiniciado para que la actualización tenga efecto.

Actualización de Failover Clusters

En Windows Server tenemos disponibles la funcionalidad de clúster gracias a los Failover Cluster o clústeres de conmutación por error. Con ellos, cuando tenemos un fallo de uno de los host, el resto de dispositivos se encargan de gestionar sus funciones dentro del clúster, permitiéndonos tener alta disponibilidad de infraestructuras o aplicaciones.

Pero Windows necesita instalar las actualizaciones del sistema cada cierto tiempo, y gracias a la característica de Actualización compatible con clústeres podremos instalarlas de una forma fácil y sencilla. Además, permite configurar una auto-actualización basada en una programación, con lo que podremos olvidarnos (en parte) del mantenimiento de este. Para ello, ese necesario instalar el rol CAU (Cluster-Aware Updating) en el clúster.

Pero, ¿no vale con instalar las actualizaciones en un nodo, reiniciarlo y seguir en los siguientes? No, ya que de esta manera únicamente cambiaríamos los roles en cada reiniciado, pudiendo tener problemas durante la instalaciones de las actualizaciones. La sucesión de pasos que realiza la Actualización compatible con clústeres es la siguiente:

  1. Poner cada nodo en modo mantenimiento.
  2. Mover los roles del nodo que se va a actualizar.
  3. Instalar las actualizaciones en dicho nodo.
  4. Reiniciar si es necesario.
  5. Sacar el nodo de modo mantenimiento.
  6. Restaurar los roles del nodo.
  7. Repetir los pasos con el siguiente nodo.

Se podrían hacer todos estos pasos de manera manual, pero mejor hacerlo con un único clic o automatizarlo.

Para acceder a función, tenemos que acceder al Administrador de clústeres de conmutación por error y entrar a la ventana principal del clúster en cuestión. Dentro de esta, donde podemos ver es estado actual, en la parte de acciones (en la zona izquierda), seleccionamos Acciones adicionales y Actualización compatible con clústeres.

clip_image001

En la ventana de Actualización compatible con clústeres podremos ver información general del estado actual:

  • Nombre del clúster
  • Estado de los nodos
  • Estado del clúster
  • Estado de actualizaciones en curso
  • Diferentes acciones

clip_image002

Las acciones disponibles son las siguientes:

  • Aplicar actualizaciones a este clúster: permite aplicar actualizaciones en ese mismo instante en los nodos del clúster. También se puede hacer con el comando de PowerShell:
  • Vista previa de las actualizaciones para este clúster: genera una lista de las actualizaciones disponibles para todos los nodos del clúster.
  • Crear o modificar perfil de ejecución de la actualización: modificación las diferentes opciones disponibles para la actualización.
  • Generar informe sobre ejecuciones de actualización anteriores: nos muestra los informes de todas las actualizaciones llevadas a cabo.
  • Configurar opciones de auto-actualización de clúster: permite configurar la auto-actualización del clúster basada en una programación. Para ello necesitamos instalar el rol CAU (si no está ya instalado, el asistente nos ayudará). También podemos elegir instalar actualizaciones recomendadas por defecto.
  • Analizar preparación de la actualización del clúster: realiza un análisis para comprobar el estado del clúster en los parámetros necesarios para llevar a cabo las actualizaciones.

Gracias a esta característica tan sencilla, que puede pasar desapercibida, podemos mejorar el proceso de mantenimiento de nuestros servidores siempre y cuando formen un clúster entre ellos.

Integración server-side de Microsoft Dynamics CRM Online con Microsoft Exchange Server híbrido

¿Tienes en tu organización Dynamics CRM y Exchange ya sean on-premises u online? Entonces estarás al tanto de que hay una característica de integración entre ambos llamada server-side synchronization. Como bien dice la palabra, permite que se realice una sincronización de mensajes de email, citas de calendario, contactos y tareas entre Dynamics CRM y Exchange, de forma que trabajemos con los mismos elementos en ambos sistemas.

El problema

Hay una guía muy completa en Technet sobre como establecer esta sincronización, por lo que no va a ser el menester de este artículo. ¿De qué quiero hablaros entonces? Imaginad que tenemos el siguiente escenario:

  • Dynamics CRM Online
  • Exchange Server 2010 ó 2013 hibridizado con Exchange Online (Office 365), donde todos los usuarios de CRM Online tienen su buzón en Exchange Online.

Si queremos configurar esta integración, nos llevaremos un bajón cuando verifiquemos la documentación de escenarios no soportados y descubramos lo siguiente:

Server-side synchronization doesn’t support the following scenarios:

  • Hybrid deployments:
    • CRM Online with Exchange (on-premises).
    • Microsoft Dynamics CRM (on-premises) with Exchange Online.
  • Mix of Exchange/SMTP and POP3/Exchange.
  • Creation of mass email marketing campaigns.
  • Extensibility scenarios like extending EWS/POP3/SMTP protocols and creating custom email providers.
  • Exchange Server 2003 and Exchange Server 2007.
  • Server-side synchronization in CRM Online, or in a Microsoft Dynamics CRM (on premises) deployment that is configured for FIPS 140-2 compliancy, requires a POP3/SMTP email server that is also FIPS 140-2 compliant. Some email servers are not FIPS 140-2 compliant, such as MSN, Outlook.com, or Windows Live Mail.

For most situations not supported by server-side synchronization, you can use the Microsoft Dynamics CRM Email Router. More information: Choose a method for message synchronization

Efectivamente parece que si realizamos implementaciones híbridas no va a funcionar la integración. Sin embargo, y dado el detalle de que en Plain Concepts, todos los usuarios que hacen uso de Dynamics CRM Online también tienen su buzón en Exchange Online, me llevó a preguntarme si no había forma de hacerlo funcionar en nuestra casuística concreta.

Para habilitar la integración, como es habitual, tenemos que crear un nuevo Email Server Profile, tal como se muestra en la siguiente imagen:

image

Como veréis, llama la atención de que no hay ningún parametro de configuración de Exchange, por lo que parece que se retira esta configuración automáticamente mediante Autodiscover. Si intentamos continuar con la configuración de Dynamics CRM Online con nuestro entorno híbrido y utilizamos Autodiscover, la configuración fallará sin remedio.

Autodiscover es un servicio disponible desde Exchange Server 2007 en adelante que permite mediante una consulta HTTP con nombre de usuario y contraseña retirar los detalles de configuración del buzón del usuario autenticado.

En una implementación híbrida de Exchange Server, el registro de Autodiscover siempre apunta a on-premises, ya que así puede facilitar la información de configuración de buzones almacenados en nuestro Exchange local; y en caso de que el buzón se encuentre en la nube realizará una redirección HTTP 302 hacia el Autodiscover de Exchange Online. Este HTTP 302 es el que parece no estar soportado por la configuración de Dynamics CRM Online.

Como este servicio lo único que hace es facilitarnos automáticamente parámetros de configuración, ¿por qué no intentamos especificarlos manualmente? Así pues nos enfrentamos a dos problemas:

  • Usar Autodiscover no es una opción puesto que Dynamics CRM Online no parece llevarse bien con las redirecciones HTTP.
  • En el formulario de configuración no se nos dá opción a especificarla de forma manual.

La solución

Si abris la ventana de configuración de Email Server Profile y vuestra vista es lo suficientemente rápida veréis algo raro: hay opciones de configuración que están mientras carga la interfaz y que tras terminar desaparecen. ¡¡Y entre ellas está la configuración manual de la conexión con Exchange!! Por lo visto Microsoft decidió deshabilitar esta opción y forzar el uso de Autodiscover en la actualización de Dynamics CRM Online de diciembre de 2014, alegando que se evitarían errores de configuración por parte del usuario.

Más allá de valorar si esta decisión fue acertada o no… la realidad es que las opciones han sido sólo deshabilitadas a nivel de interfaz de usuario. Hablando más técnicamente, los controles HTML se encuentran en la interfaz sólo que están ocultos para que no podamos manipularlos. Si sólo están ocultos… un poquito de Javascript en la interfaz podría rehabilitarlos fácilmente. ¡Vamos a ello!

  1. En Dynamics CRM Online ve a Settings –> Email Configuration –> Email Server Profile –> New
  2. Observarás el curioso efecto que he comentado antes.
  3. Abre la consola de depuración de tu navegador, F12 en Internet Explorer.
  4. Introduce el siguiente código:

Tras ello –y si Microsoft no ha cambiado nada desde el momento de escribir estas líneas- deberíais ver las opciones de configuración ocultas:

image

Ahora sólo nos queda configurar las URLs de Exchange Web Services para que apunten directamente a Exchange Online y no se toque nuestro servidor on-premises para nada. La configuración para Office 365 sería:

Guardamos la configuración y aunque ya no introduzcamos el código podremos ver que esta queda siempre visible, pero ya no se podrá modificar. Y con esto conseguimos que todos los usuarios de Dynamics CRM Online que tengan su buzón Exchange Online disfruten de la integración aunque nuestro entorno de Exchange sea híbrido. Espero que os haya sido útil.

Happy CRMing!

Powershell Snippets: Obtener la MAC de la tarjeta WIFI de equipos en el AD

Hola a todos,

En ocasiones, hace falta obtener información específica sobre equipos del dominio. Por ejemplo, supongamos que por motivos estadísticos, es necesario sacar un listado de los equipos de una oficina que están encendidos en un momento determinado, y no sólo eso, sino que además se desea obtener la MAC de su interfaz Wi-Fi (para complicar el asunto).

En este caso, está claro que se va a utilizar el módulo de Active Directory de PowerShell, ya que hace falta obtener un listado de equipos. Y por otro lado, es necesario que haya un mecanismo que permita conectarse a las máquinas para acceder a la lista de interfaces de red, y poder leer las que nos interesen.

Afortunadamente, PowerShell dispone de todo lo necesario para llevar a cabo esta tarea. A continuación, un breve desglose con los cmdlets principales:

  • Get-ADComputer -Filter * -SearchBase “OU=Oficina,OU=Empresa,DC=Empresa,DC=com”
    Este cmdlet va a encargarse de obtener todos los equipos del dominio. Además, se especifica
  • get-wmiobject -class “Win32_NetworkAdapter” -computername $comp.DNSHostName -filter “NetConnectionID = ‘Wi-Fi’ ” -ErrorAction “Stop”
    Con este cmdlet se lanza una consulta WMI a los equipos obtenidos previamente, y se le aplica un filtro por el campo “Wi-Fi”. También se puede filtrar por “Ethernet”, o no filtrar en absoluto.
  • New-Object PSObject -prop @{Computer = $comp.DNSHostName; Adapter = $obj.Name; MAC=$obj.MACAddress}
    El último comando importante genera un objeto con los atributos “Computer”, “Adapter” y “MAC”, que se utiliza para crear un archivo CSV al final del script.

Hay una poderosa razón para que este script deba lanzarse desde la PowerShell de un usuario Administrador de Dominio: Se conecta a cada una de las máquinas para consultar su lista de interfaces y quedarnos con aquellas que tienen interfaz Wi-Fi. Si quien lo ejecuta no es administrador de dominio, no va a poder conectar con las máquinas, y por tanto, no podrá generar el listado.

Sin más dilación, aquí tenéis el código de la función.

Se puede pegar tal y como está en una consola de PowerShell e invocarla como un cmdlet cualquiera, o se puede integrar dentro de un módulo, o generar un script (copiando únicamente el código de la función). Las posibilidades son infinitas, sobre todo gracias a que se puede jugar con el cmdlet get-wmiObject para obtener una variedad de información casi ilimitada.

shell

Finalmente, y como un artículo sobre un script nunca queda completo si no incluye capturas de pantalla… aquí está una muestra del CSV resultado de la ejecución del script.

wifiMac

 

Happy Scripting!

Configurar Thunderbird para un buzón compartido de Office 365

Anteriormente,  dábamos instrucciones  en un artículo de cómo configurar el cliente de correo Thunderbird para que pudiéramos añadir una cuenta de correo de Office 365, contando así con todas las ventajas y particularidades que Exchange Online nos ofrece. Pues bien, a raíz de dicho post, muchos han sido los que nos  han preguntado si también se podían agregar cuentas de buzones compartidos de Office 365.  Ello es posible gracias a una serie de sencillos pasos que nos permitirán añadir la cuenta asociada al buzón y disfrutemos de las mismas características de una cuenta de correo convencional de Office 365.

¿Qué requisitos necesitaríamos?

  1. Mozilla Thunderbird
  2. Haber instalado los add-on tal y como indicamos en el anterior artículo relacionado
  3. Tener permisos de acceso al buzón compartido de Office 365 pues de otra forma no podremos añadir la cuenta a nuestro cliente de correo.

Nota : Pese a que la configuración la realizaremos en Windows 8.1,  volvemos a indicar  que es válida también en  Mac y Linux.

Descargado, instalado y configurado Thunderbird, procederemos a agregar y configurar la cuenta asociada al buzón compartido.  Para ello, basta con ir desde el menú de herramientas, seleccionar la opción  de Configuración de cuenta.  Dentro del menú de Operaciones sobre la cuenta , elegimos la opción de Añadir cuenta de correo para iniciar el asistente de configuración.

clip_image001

Con dicho asistente, introducimos el nombre del buzón compartido, la dirección de correo asociada y la contraseña de nuestra cuenta de Office 365.  Una vez metidos los datos,  haremos clic en Continuar  para que Thunderbird localice la cuenta. Sabiendo que este cliente de correo tiene problemas a la hora de acceder a la información de una cuenta de Exchange  , siendo imposible continuar con el proceso , deberemos optar por añadir la información manualmente haciendo clic en el botón Config. Manual, donde deberemos indicar los valores de configuración de entrada y salida.

image

Para la configuración de entrada,  debido a que los buzones compartidos no poseen acceso POP,   deberemos elegir el protocolo  IMAP e introducir los siguientes valores :

Servidor Puerto SSL Identificación
IMAP outlook.office365.com 993 SSL/TSL Autodetectar

Para la configuración de salida, rellenaremos el formulario con  los valores que vienen a continuación :

Servidor Puerto SSL Identificación
SMTP smtp.office365.com 587 STARTTLS Contraseña Normal
En  Nombre de Usuario, donde facilitamos la identificación para acceder a la cuenta,  tanto para la configuración de entrada como en la de salida deberemos escribir  nuestro identificador de login de Office 365  siguiendo el formato usuario@dominio.comaliasdelbuzóncompartido  (Ejemplo : atercero@plainconcepts.compruebasupport) .
Finalizando  el proceso, tendremos la cuenta ya agregada al cliente de correo . Como veis es un proceso similar a la configuración de una cuenta normal de Office 365 con el que lograremos que con Thunderbird podamos leer  y enviar correo de un buzón compartido de Office 365.
¡Gracias por leernos!

Conexión a Office 365 por PowerShell

Como muchos de vosotros sabéis, PowerShell es imprescindible para la administración de Office 365. Sin ir más lejos, se estima que casi un 40% de las funcionalidades no están visibles en el panel de administración web y para las cuales se requiere del uso del lenguaje de scripting de Microsoft. Es lógico pensando en mantener el portal web lo más sencillo y usable posible para la mayoría de las tareas, mientras que para temas más complejos o repetitivos, PowerShell nos sirve como extensión para configurar nuestro entorno Cloud.

A modo de resumen, estás son las 6 ventajas principales y diferenciadoras a la hora de utilizar PowerShell para administrar Office 365:

  1. PowerShell puede revelar información “oculta” no disponible en el centro de administración
  2. Office 365 tiene características que solo se pueden configurar con PowerShell
  3. PowerShell es insuperable en las operaciones masivas
  4. PowerShell es excelente en el filtrado de datos
  5. PowerShell facilita la impresión o el guardado de datos
  6. PowerShell permite la administración de “productos cruzados”

Ahora que ya sabemos lo importante que es aprender sobre PowerShell para ser unos buenos administradores de Office 365, ¿por dónde empezamos?

Lo primero que hay que saber es que en la nube cada producto que conforma Office 365 se comporta como un elemento independiente para ciertas tareas. Esto viene derivado de que el directorio de usuarios que utilizan Exchange Online o Skype for Business por ejemplo, no es directamente Azure Active Directory, sino que es un directorio propio que de manera transparente al usuario de mantiene sincronizado y federado con Azure Active Directory.

A la hora de administrar Office 365 con PowerShell este punto es importante ya que nos encontraremos con que cada servicio tiene su propio extremo o “endpoint” de conexión, tal como se puede apreciar en este dibujo:

image

Esto quiere decir que configuraciones de throttling, segmentación de usuarios, creación de grupos, o gestión de políticas, no se aplican por defecto a la vez para todos los servicios. La idea de Microsoft es simplificar este tipo de acciones para que sean uniformes y comunes a todos los sevicios, tal como estamos viendo con los nuevos Grupos.

Teniendo en cuenta el dibujo, debemos pensar a qué servicio nos queremos conectar para administrar. Vamos a ver los pasos necesarios para acceder a cada uno de ellos:

Azure Active Directory:

  1. Instalar el módulo de Windows Azure AD para Windows PowerShell

Exchange Online:

SharePoint Online:

  1. Instalar el módulo de SharePoint Online para PowerShell

Skype for Business:

  1. Instalar el módulo de Skype for Business para PowerShell

 

De esta manera, y en función de la operación que vayamos a realizar, podremos conectarnos al servicio correspondiente y hacer las operaciones que necesitemos.

Nuestra recomendación es que carguéis todo el script en vuestro perfil y de una manera rápida podáis conectaros a todos los servicios de Office 365, de cara a realizar todas las operaciones sobre cualquiera de los servicios de forma transparente, aunque no debeis perder nunca de vista sobre lo que estáis operando:

image

Happy scripting!