Entre el Cloud y el Infierno

Continuamos dando guerra con Office 365… Bueno, más bien con ADFS.

Con la finalidad de mejorar la integración entre nuestra infraestructura «On-Premise» y los servicios que podamos tener alojados en la nube, tales como Azure y/o Office 365, Microsoft dispone del producto Active Directory Federation Services (ADFS) ya en la versión 2.0. ADFS nos permite federar nuestro Active Directory con nuestro tenant en el cloud, de forma que los usuarios accederán a servicios externos, autenticandose previamente «en casa».

Gracias a esto se obtienen mayores ventajas y funcionalidades, tales como:

– Single Sign-On (SSO)
– Customización de la web de login
– Seguridad

No voy a hacer especial énfasis en su instalación y configuración, ya que esta bastante bien documentado en Technet
http://technet.microsoft.com/es-us/library/jj151794.aspx

ADFS puede llegar a integrarse con otros productos (Exchange 2010, Sharepoint…) y otros no Microsoft. En los siguientes enlaces se especifican estos productos, así como los procedimientos de implementación.

http://technet.microsoft.com/es-es/library/adfs2-step-by-step-guides%28WS.10%29.aspx
http://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-2-0-content-map.aspx

Concretamente en la  implementación de ADFS con Office 365, también es necesario DirSync, basado en MIIS,  para la sincronización de identidades con el Cloud (no sincroniza el password). De forma opcional, y en caso de que sea necesario, ADFS Proxy 2.0 (el rol de este servicio puede ser asumido por TMG) para el acceso a la autenticación desde fuera de la organización.

Pues bien, una vez configurada la federación, accederemos al servicio a través de la URL configurada.

En el siguiente enlace se explica de forma muy detallada, como modificar esta página de login para darle un aspecto más «corporativo»

http://blogs.technet.com/b/stevenha/archive/2012/11/12/customizing-the-adfs-forms-based-login-page.aspx

Finalmente, y haciendo referencia la titulo del post, una vez se ha accedido al servicio correspondiente y hacer Logout, por defecto, el usuario será redirigido a la web de https://portal.microsoftonline.com en lugar de a la web de ADFS… 🙁

Para modificar este comportamiento, y redirigir la acción de logout a la web de ADFS:

1. Localilizar la página de logout (por defecto en C:\inetpub\adfs\ls\SignOut.aspx)

2. Editar el fichero SignOut.aspx para insertar el siguiente código, justo antes de la etiqueta de cierre </asp:Content> (casi al final del fichero), introduciendo la URL de la web que queremos que aparezca al hacer Logout (en este caso la propia del adfs)

3. Ejecutar iisreset desde cmd.

Salut!! 😛

En determinadas ocasiones puede surgir la necesidad de ejecutar tareas de forma periódica en nuestro tenant de Office 365, tales como la asignación de licencias, operaciones sobre buzones/usuarios, etc…

El principal inconveniente que nos podemos encontrar, es poder tener la capacidad de autenticarnos de forma segura en Office 365. Si os habéis encontrado en esta tesitura, espero que esta entrada os ayude en algo 😉

La idea es crear un fichero (cifrado) con el password del usuario que utilizaremos para validarnos, y posteriormente utilizarlo en un script para conectarnos sin necesidad de introducir ninguna validación.

Para crear este fichero, utilizaremos el siguiente comando.

read-host -assecurestring | convertfrom-securestring | out-file C:\securestring.txt

Al ejecutarlo, se deberá introducir el password del usuario.

-convert-securestring: convierte un SecureString (System.Security.SecureString) en un EncryptedStandardString (System.String) y nos permite almacenarlo en un fichero para su posterior uso.

Si accedemos al contenido del fichero…

Posteriormente utilizaremos este fichero para validarnos en Office 365.

A continuación, creamos un script en PowerShell con el siguiente contenido (p.e o365.ps1)

Este script esta disponible en el siguiente repositorio de GitHub (aún me estoy familiarizando con esto del blog y no he conseguido pegarlo como tal… 🙁 )

(https://github.com/Tokiota/AutologonO365/blob/master/o365.ps1)

Finalmente, creamos un acceso directo con la siguiente ruta, o programamos una Schedule Task
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit -Command «. ‘o365.ps1′»

El script que se ejecuta (GetMsolUserReport.ps1) forma parte de un repositorio de scripts facilitados por Microsoft para la ayuda en la gestión de Office 365. (Office 365 Helper Scripts – http://www.microsoft.com/en-us/download/confirmation.aspx?id=29568 ).

Existen algunos interesantes:

– GetMsolUserReport: se obtiene información tanto a nivel de usuario, como de buzón (licencia, tamaño del buzón…)
– AssignLicenseByDG: utilizado para asignar licencias. Útil cuando se migran buzones desde Exchange OnPremise, ya que al buzón no se le asigna ninguna licencia de forma automática en Office 365 🙁

Por último, comentar que de momento no se permite la gestión de Sharepoint Online/Lync Online a través de PowerShell. Sí que existe «Sharepoint Online Management Shell» pero solo soportado para Office 365 Preview (espero poder dedicarle una entrada un día de estos)

http://www.microsoft.com/en-us/download/details.aspx?id=30359

Saludetes!! 😀

Buenos días a todos!!

Este primer post lo voy a dedicar a indagar un poco en las posibles configuraciones para la NO activación de una Lagged Copy en Exchange 2010.

Exchange 2010 dispone de la funcionalidad de copias de bases de datos retardadas (Lagged Copy). Con la finalidad de contingencia, este tipo de copia permite recuperar la base de datos en un momento concreto con hasta 14 días de antelación.

Su funcionamiento se basa en almacenar los ficheros .log de hasta 14 días anteriores, de forma que si es necesario realizar una recuperación de la base de datos, se pueden aplicar los .log que se quieran hasta el momento determinado (intentaré hablar más de este tema en otra entrada). Por tanto esta base de datos no se debería activar nunca, ya que en caso de que esto sucediera se aplicarían todos los .log pendientes a la base de datos antes de activarse, con lo cual:

– Se pierden todos los logs, y por tanto, la capacidad de recuperar esa BD en un estado anterior.
– El tiempo en aplicar los logs pendientes sobre la base de datos puede llegar a ser muy extenso (se queda en estado Mounting) y por tanto, los usuarios con buzones en esa base de datos no podrán acceder hasta que se hayan terminado de aplicar.

Para evitar este hecho, existen dos posibles configuraciones

– Evitar una base de datos concreta se pueda llegar a activar (configuración a nivel de base de datos)
– Evitar que un servidor pueda levantar ninguna base de datos (configuración a nivel de Mailbox Server)

La primera opción se realiza a través del siguiente comando (la BD no cambia a estado Suspended, cambia el parámetro ActivationSuspended de False a True)

Suspend-MailboxDatabaseCopy -Identity DB3\MBX2 -ActivationOnly

La segunda opción se realizar a través de este otro (cambia el parámetro de DatabaseCopyAutoActivationPolicy  de Unrestricted a Blocked)

Set-MailboxServer –Identity MBX2 –DatabaseCopyAutoActivationPolicy Blocked

A tener en cuenta:

Como ventaja – la primera opción nos permite mayor granularidad en la configuración de nuestras copias, ya que no es necesario que todas las Lagged se encuentren en el mismo servidor. Mediante la segunda opción, es necesario disponer de un servidor para que únicamente mantenga todas las copias Lagged.

Como inconvenientes – con la primera opción, si se realiza un Resume-MailboxDatabaseCopy o un Update-MailboxDatabaseCopy (porque el estado de la copia quede en Disconnected, Failed… el ContentIndex no sea correcto, etc.) se pierde la configuración de este parámetro, teniéndolo que volver a configurar. Así que es necesario e importante tenerlo monitorizado. Es más, incluso si en algún momento existe una caída de alguno de los nodos miembros del DAG (o cortes intermitentes de comunicación), Exchange puede llegar a intentar ejecutar un Reseed (Update-MailboxDatabaseCopy) provocando la pérdida del parámetro ActivationOnly.

Este último hecho no sucede con la segunda opción.

Cada parámetro tienes sus pros y sus contras, por lo que es importante tenerlo en cuenta para su configuración.

En caso de que os suceda que una Lagged Copy se intenta Activar (se quedará en estado Mounting), recomendaría detener el nodo a nivel de «Failover Cluster Manager» o reiniciarlo directamente, para forzar un balanceo de las bases de datos que se están intentando montar a uno de los servidores que mantenga una copia pasiva.

Espero que os sea de ayuda!!!

Hola a todos y bienvenidos!

Antes de empezar a meterle chicha a este Blog, me presento…

Mi nombre es Pedro, y llevo ya unos años en consultoría TI, básicamente en la parte de gestión e implantación de proyectos de infraestructura.
Han sido muchas cosas las que me han sucedido en este mundo, y muchas «ostias» dadas con prácticamente todo lo que se me ha puesto por delante. Lo bueno, es que al final de todas de todas se aprende! 😀

Esta es básicamente la finalidad, compartir estas experiencias con todos vosotros, y esperar a que os puedan ayudar en algun momento!

Espero que lo disfrutéis! 😉