The GuruXP Blog

En esta ocasión vamos a ver paso por paso de como recuperar el contenido de un buzón que se encuentra en un estado de «soft-deleted» o desconectado en Exchange Online.

Para ello, vamos a enumerar que situaciones pueden llevar a un buzón a un estado de «Soft-Deleted»:

• Si hemos eliminado el usuario desde el apartado de usuarios en el portal de Office365
• Si hemos quitado la licencia de Exchange Online al usuario.
• Si disponemos de un entorno sincronizado con nuestro AD local y hemos eliminado o movido el usuario a una OU que no está sincronizada con Office365.

Normalmente, si nos encontramos en las dos primeras situaciones, simplemente bastaría con restaurar el usuario desde el portal de usuarios de Office365 (en la primera situación), y asignar de nuevo la…

Continua leyendo en: http://blogs.technet.com/b/esexblog/archive/2015/06/04/recuperar-contenido-de-un-buz-243-n-eliminado-en-exchange-online.aspx

Buenas, hoy toca hablar de la funcionalidad de autenticación Multi-Factor en Office365.

Primero expliquemos que es, cuales son sus beneficios y después procederemos a explicar como habilitarlo, configurarlo y administrarlo, tanto por GUI como por PowerShell…

QUE ES Y QUE BENEFICIOS APORTA?

La funcionalidad de autenticación Multi-Factor es un sistema de validación múltiple que nos permite aumentar la seguridad a la hora de acceder a nuestro sistema, pero no solo eso, también nos permite enterarnos de accesos no deseados o intentos de acceso a nuestra cuenta de Office365 e incluso poder denunciarlos, todo esto desde una sencilla APP para nuestro teléfono, una llamada telefónica a nuestro movil o numero de la oficina, o el envío de un SMS a nuestro teléfono.

Eso significa que tendré que meter un código cada vez que acceda a mi buzón?, no exactamente, salvo que seleccionemos la opción de envío de código mediante mensaje o llamada, nuestra APP instalada en el teléfono se encargará de avisarnos que hay una solicitud de acceso y en cuanto accedamos a la notificación podremos indicar si queremos verificar o declinar el acceso.

Y que ocurre con cada aplicación en la que tengo configurada mi cuenta, tendré que autorizar cada dos por tres los accesos? no, tenemos la opción de configurar una «APP Password» única para cada aplicación y de una única activación.

Eso significa que puedo crear cuantas APP Passwords desee? No, tenemos un limite actual de 40 APP Passwords.

Que aplicaciones puedo utilizar con mi APP Password? Podemos encontrar las mas frecuentes como Microsoft Outlook, Microsoft Lync, La suite de Office 2013, pero también podemos encontrar a el cliente de Lync para movil, El cliente de correo de Windows 8 y 8.1, o la activación de suscripción de Office.

Que APP es la que puedo utilizar para autenticar los accesos? La APP se llama «Multi-Factor Auth» y esta disponible para IOS, Android y Windows Phone por supuesto, y esta disponible desde la tienda de cada plataforma.

Está disponible esta funcionalidad para todos los planes de Office365? No, únicamente para los planes MidSize, Enterprise (E1, E3 y E4) y Standalone (Exchange Online y Sharepoint Online), por lo que en pocas palabras no esta disponible ni para planes de pequeña empresa ni pequeña empresa premium…

COMO HABILITAR LA FUNCIONALIDAD POR GUI

Para disfrutar de esta funcionalidad, tan solo tenemos que acceder a nuestro portal como administrador y habilitarla para los usuarios que queramos:

• Accedemos a nuestro portal de Office365 (http://portal.microsoftonline.com) como Administrador y pinchamos en «Usuarios y Grupos» y luego en «configurar» dentro de «establecer requisitos de Multi-factor Authentication»:

•  En «View» seleccionamos el filtro de usuarios que queramos aplicar, yo en este caso dado que lo estoy habilitando para un usuario normal no administrador, he seleccionado la vista «Usuarios con inicio de sesión permitido«:

• Seleccionamos el usuario o los usuarios a habilitar y hacemos clic en «Habilitar» en el panel de la parte derecha y después le damos a «habilitar multi-factor auth» en el popup:

Una vez hecha la parte de Administrador, procedemos a realizar la parte Usuario. Esto se supone que es lo que el usuario debe hacer y sentira cuando acceda a su portal de Office365. Es Importante que el usuario acceda obligatoriamente al portal antes de hacer nada mas con su cuenta.

• Accedemos al portal de Office365 (http://portal.microsoftonline.com) con nuestros datos de usuario y nos encontramos con la siguiente pantalla, en la que pinchamos «configurar ahora«:

• Esto nos llevará a la configuración de la seguridad adicional, seleccionamos la opción que queramos y continuamos, en nuestro caso, seleccionaremos «Aplicación móvil» y luego haremos clic en «Configurar«:

• Seguimos los pasos que indica la pantalla y hacemos clic en «Listo«:

• Una vez hecho esto, nos preguntará si hacemos uso de aplicaciones como Microsoft Outlook o Lync para poder generar contraseñas de aplicación, en nuestro caso asumimos que el usuario si utiliza Microsoft Outlook, por lo que generaremos un contraseña de aplicación haciendo clic en «generar contraseña de aplicación» y luego en «Crear«:

• Asignamos un nombre a la aplicación y luego copiamos la contraseña única que deberemos pegar en nuestra aplicación (en nuestro caso Microsoft Outlook) cuando nos pida las credenciales de la cuenta. Esta contraseña no será visible nuevamente por lo que es importante copiarla y pegarla directamente:

• Si en algún momento queremos crear mas contraseñas de aplicación o «APP Passwords» o modificar el método de contacto y validación, tan solo tenemos que entrar en nuestro portal de usuario de office365 y en la parte superior derecha hacer clic en el engranaje y luego en «configuración de Office365», Seleccionamos la sección «comprobación de seguridad adicional» y pinchamos en el enlace que muestra la pantalla derecha, esto nos dará acceso a dichas configuraciones y al listado de APP Passwords:

COMO HABILITAR LA FUNCIONALIDAD POR POWERSHELL

Para poder trabajar con Autenticación Multi-Factor , deberemos seguir los siguientes pasos:

• Descargar e instalar el modulo de PowerShell para Windows Azure Active Directory
• Ejecutar las siguientes lineas:

Connect-MsolService
$MultiFactorAuth= New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$MultiFactorAuth.RelyingParty = «*»
$MultiFactorAuth = @($MultiFactorAuth)

Una vez creado el objeto requerido, procedemos a realizar las distintas opciones:

• Para habilitar la funcionalidad en un usuario:

Set-MsolUser -UserPrincipalName user@domain.com -StrongAuthenticationRequirements $MultiFactorAuth

• Para habilitar la funcionalidad en todos los usuarios:

Get-MsolUser -All | Set-MsolUser -StrongAuthenticationRequirements $MultiFactorAuth

• Listar todos los usuarios con la funcionalidad habilitada:

Get-MsolUser | Where-Object {$_.StrongAuthenticationRequirements -like «*»}  | select DisplayName,UserPrincipalName,StrongAuthenticationMethods,StrongAuthenticationRequirements

• Para deshabilitar la funcionalidad de los usuarios (especialmente útil si hay algún problema de autenticación):

$MultiFADisable = @()
Set-MsolUser -UserPrincipalName j.doe@techdaylab.onmicrosoft.com -StrongAuthenticationRequirements $MultiFADisable

Solamente hacer una observacion, si habilitamos esta funcionalidad para un administrador, no podremos utilizar esa cuenta para administrar nuestra suscripción con PowerShell dado que no esta soportada, para ello, Microsoft recomienda crear una cuenta sin licencia asignada y con una contraseña fuerte en la que no se habilite esta funcionalidad y poder utilizarla para PowerShell.

PROBANDO EL ACCESO CON LA APP:

Una vez hagamos inicio de sesión en nuestro portal, nos mostrara una notificación en nuestro móvil donde nos pide verificar o cancelar el acceso, y una vez concedido nos da el visto bueno:

A estas alturas, la gran mayoría conoce lo que Rights Management Services (RMS) puede hacer por nosotros en un entorno de AD bajo el rol de ADRMS y seguramente también estéis al tanto de que Office365 incorpora esta característica para planes empresariales.

Bien pues, hay situaciones en las que quereis activar RMS en vuestro Tenant por la via grafica (GUI) y justo al darle a activar, se queda el proceso pillado con la siguiente pantalla sin importar el tiempo que se deje (por cierto suele tardar como mucho 2 minutos):

Para todos aquellos que sufrais ese problema, teneis una solucion inmediata y es mediante PowerShell con los siguientes pasos:

• Descargar e instalar el modulo de RMS para PowerShell
• Ejecutar PowerShell como Administrador
• Importar el modulo mediante el siguiente comando:

Import-Module AADRM

• Conectarnos al servicio con credenciales de Administrador Global:

Connect-AadrmService -Verbose

• Finalmente activaremos RMS:

Enable-Aadrm

El proceso no deberia tardar mas de 2 minutos, despues podremos desconectarnos del servicio mediante el comando:

Disconnect-AadrmService

Buenas, hoy os traigo un articulo corto pero útil para organizaciones grandes. A menudo nos encontramos con peticiones de confirmaciones de lectura cuando recibimos un mensaje y muchos de los usuarios lo rechazan, para que nos sirve enviar una confirmación de lectura si luego va el destinatario y lo rechaza?, bien pues ya que no podemos controlar al destinatario fuera de nuestra organización, controlemos la parte interna.

Por supuesto que podemos irnos por la parte grafica bien por OWA o bien por Outlook, pero tenemos dos inconvenientes, uno que esos ajustes son dependientes del cliente de correo, y dos que no es operativo hacerlo uno por uno. Que pasa cuando tenemos 300 o mas usuarios? POWERSHELL!

Para ello necesitamos tener nuestro entorno correctamente configurado, y una vez hecho ejecutar el siguiente comando:

Set-MailboxMessageConfiguration -Identity user@yourdomain.com -ReadReceiptResponse NeverSend

En este caso estaremos configurando para que el usuario user@yourdomain.com nunca envíe confirmaciones de lectura, pero podemos personalizarlo sustituyendo el «NeverSend» con las siguientes opciones:

• «DoNotAutomaticallySend»  Para que pregunte antes de enviar confirmación
• «AlwaysSend» Para que siempre envíe confirmación
• «NeverSend» Para que nunca envíe confirmación

Pero como aplicamos esto a todos los usuarios? muy sencillo aplicando el pipe «|» al comando que queramos preceder, por ejemplo:

Get-User | Set-MailboxMessageConfiguration -ReadReceiptResponse AlwaysSend

Para confirmar que el valor se ha aplicado podemos ejecutar el siguiente comando:

Get-MailboxMessageConfiguration -Identity user@yourdomain.com | fl ReadReceiptResponse

Saludos.

Hace cuestión de 2 días (3/12/2013), Microsoft publicó una nueva APP llamada Microsoft Tech Companion con la finalidad de ayudar al profesional de IT en estar día a día con las ultimas noticias, artículos, blogs posts, tweets y wikis de la tecnología que nosotros queramos. Como? esta APP nos trae la posibilidad de personalizar un feed propio sobre el producto Y VERSION que nosotros queramos, en el que podremos indicar hasta los canales de información sobre el que estar al tanto, ya sean tweets, blog posts, artículos y/o noticias referentes a ese producto.

Por supuesto podremos tener más de un feed configurado y anclarlo a nuestra pantalla de inicio (en el caso de Windows Phone y Windows 8) para que aproveche la funcionalidad de Live Tile.

Por supuesto para ello hace falta estar logado con credenciales de una cuenta Microsoft (Live, Outlook, etc…).

Que no queremos tener un feed configurado? La APP nos mostrará sin filtro las últimas noticias que giran en torno a todos los productos Microsoft.

Buscamos algo en concreto?

Tenemos un buscador con historial incluido por si es algo que buscamos de forma recurrente y así evitamos tener que escribir la búsqueda nuevamente, pero para recuperar un artículo interesante siempre podremos marcarlo para leer después ;).

Esta utilidad de entrada es muy sencilla ya que se encarga de notificar al administrador de un solo vistazo el estado de salud del servicio de Office365, si hay algún incidente y si lo ha habido tener acceso a los  detalles del mismo así como echar un vistazo al informe posterior (PIR).

Actualmente esta APP esta en fase B1, y únicamente soporta el seguimiento de un solo tenant, pero para el futuro se espera que la APP pueda soportar «multi-tenancy» y poder integrar la parte de tickets de soporte para aquellos administradores que lleven mas de una suscripción ;). De momento únicamente esta disponible para Windows Phone 8, pero los planes son de sacar una versión para IOS y Android muy pronto. Como requisito único, la cuenta a utilizar por la aplicación tiene que pertenecer al rol de Office365 «Administrador de servicio» o «Administrador Global».

A continuación os pongo algunos pantallazos de la aplicación:

Como nota final, simplemente indicar que esto demuestra que hay una API con la que jugar en Office365, pero aun no esta fuera de las paredes de Microsoft ;).

Cuando eliminamos un usuario en Office365 este no se elimina del todo sino que va a parar a una papelera de reciclaje durante 30 días (Soft-Delete). Esto puede ser bueno a la hora de querer recuperarlo con absolutamente todos los permisos, contenido y detalles de este, pero que ocurre cuando el usuario John Smith deja la empresa y entra mas adelante un usuario llamado Judy Smith? Si queremos asignar el usuario nuevo siguiendo la política de la organización inicial.apellido (J.Smith) por ejemplo nos encontraremos que Office365 dira que no puede crear el usuario porque ya existe uno con el mismo nombre de usuario.

Para forzar la eliminación de este usuario de la papelera de reciclaje deberemos hacerlo mediante PowerShell.

Para ello lo primero será tener preparado nuestro entorno de PowerShell para conectar con Office365.

A continuación iniciamos sesión en nuestra suscripción de Office365 ejecutando los siguientes CmdLets:

$LiveCred = Get-Credential 

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Importamos el modulo de Online Services:

Import-Module MSOnline

Ejecutamos el siguiente CmdLet para obtener el ObjectId del usuario que queremos eliminar:

Get-MsolUser -All -ReturnDeletedUsers|select userprincipalname,objectid

Finalmente ejecutamos el purgado del usuario deseado con el ObjectId obtenido antes:

Remove-MsolUser -ObjectId «objectid» -RemoveFromRecycleBin -Force

Espero que sea de ayuda.

Cuando hacemos alguna migración de tipo cut-over, nos encontramos que después de migrar todo el contenido y configuramos un nuevo perfil en Microsoft Outlook, este se autoconfigura directamente contra el servidor de Exchange que tenemos en local.

Aparte de esto, si hacemos un ping a autodiscover.dominio.com, nos resolverá siempre la ip del servidor local en lugar del autodiscover de Office365, independientemente de si lo añadimos al fichero hosts, configuramos DNS externas o agregamos el registro en el servidor DNS local.

Eso es debido a que Exchange 2010 presenta la funcionalidad incrustada de autodiscover y para que los perfiles nuevos adquieran la nueva configuración es necesaria hacer uno de los siguientes 2 pasos:

1- Eliminar el directorio virtual de IIS Autodiscover (en el servidor de Exchange):

• Lanzamos la Exchange Management Shell
• Ejecutamos los siguientes comandos

Remove-AutodiscoverVirtualDirectory -Identity «MyServer\autodiscover(autodiscover.contoso.com)»

Set-ClientAccessServer name -AutoDiscoverServiceInternalUri $null

• Reiniciamos el IIS mediante una consola de comandos en el servidor ejecutando el comando «IISRESET»

2- Añadir entradas en el registro de la maquina cliente:

• Navegar hasta la rama si es Outlook 2007: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Autodiscover
• Navegar hasta la rama si es Outlook 2010: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Autodiscover
• Agregar las siguientes entradas:

«PreferLocalXML»
«ExcludeHttpRedirect»
«ExcludeHttpsAutodiscoverDomain»
«ExcludeHttpsRootDomain”
«ExcludeScpLookup»
«ExcludeSrvLookup»
«ExcludeSrvRecord»
«PreferLocalXML»=dword:0
«ExcludeHttpRedirect»=dword:0
«ExcludeHttpsAutodiscoverDomain»=dword:0
«ExcludeHttpsRootDomain»=dword:1
«ExcludeScpLookup»=dword:1 (forces Outlook to exclude SCP object check)
«ExcludeSrvLookup»=dword:1
«ExcludeSrvRecord»=dword:1

• Reiniciamos la maquina y creamos el perfil.

En el post de hoy, explicaremos como eliminar un dominio de una suscripción de Office365, bien porque se nos acabe una evaluación, porque queramos migrar a otra familia de planes o porque ya no vayamos a utilizar el dominio.

Lo primero que tenemos que hacer es configurar los usuarios que estén utilizando el dominio en cuestión con el dominio alternativo, ya sea el que suministra Microsoft (dominio.onmicrosoft.com) u otro que tengamos. Esto implica dos cosas a revisar: el sufijo UPN de inicio de sesión (lo que esta después del @), y las direcciones proxy (también llamados alias) asignados en la ficha de direcciones de correo de cada usuario.

Para hacerlo via GUI (interfaz grafica):

• Accedemos a nuestro portal de Office365 con credenciales de Administrador.
• Vamos a la ficha Usuarios y Grupos.
• Seleccionamos todos los usuarios afectados y le damos a editar.
• Nos vamos al apartado «Detalles«, y en «Dominio» seleccionamos uno diferente.

Para las direcciones proxy, tendremos que hacerlo uno por uno editando los detalles, pinchando en la sección «mas» y luego en «editar propiedades de exchange«, vamos a la sección de «direcciones de correo electrónico» y eliminamos las que tengan el dominio a quitar.

Para hacerlo via PowerShell:

• Lo primero será tener preparado nuestro entorno de PowerShell para conectarnos a Office365
• Nos conectamos al servicio de Office365 mediante PowerShell con los siguientes cmdlets:

$LIveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LIveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

• Ejecutamos lo siguiente para averiguar que usuarios tienen el dominio en cuestión asignado:

Get-MsolUser -DomainName [Domain] | fl UserPrincipalName

• Cambiamos los usuarios que requieran el cambio con lo siguiente:

Set-MsolUserPrincipalName -UserPrincipalName [CurrentUPN] -NewUserPrincipalName [NewUPN]

Una vez que hemos eliminado los rastros de los usuarios, tenemos que hacer lo mismo con los grupos de distribución y/o seguridad. Para ello tendremos que acceder al panel de control de Exchange Online (si disponemos de un plan de pequeña empresa hay que seguir este articulo para acceder al ECP) haciendo click en la parte superior derecha donde pone «Admin» y luego en «Exchange«, accedemos a «grupos» y editamos cada uno de ellos, pinchamos en la sección de «direcciones de correo electrónico» y eliminamos la del dominio en cuestión.

De igual forma pasa con los buzones compartidos, buzones de sitio y usuarios dados de alta en Lync Online.

Cuando ya hemos hecho y comprobado todo esto, deberemos hacer click en el nombre de la empresa dentro de la pantalla principal de nuestro portal de office365  y cambiar el dominio asociado.

Bien, ya hemos repasado que no quedan rastros en usuarios, grupos de distribución/seguridad, buzones compartidos, buzones de sitio, lync online, y a nivel de suscripción, por lo que podemos proceder a su eliminación totalmente accediendo al apartado «dominios» dentro del portal de office365, seleccionamos el dominio a quitar y lo eliminamos.

Si por el contrario queremos hacerlo con PowerShell, este es el comando a ejecutar:

Remove-MsolDomain -Domain dominio.com

Buenas os dejo el enlace a un articulo que he estado realizando sobre el secuestro de sesiones de Office365 con cookies muertas el cual permitiría a cualquier usuario malintencionado acceder a mi sesión de Office365 incluso después de haberla cerrado sin la necesidad de usuario ni contraseña.

Es un articulo publicado en el blog de Chema Alonso y en el que el le ha dado su toque inconfundible.

El enlace al articulo:

http://www.elladodelmal.com/2013/07/secuestro-de-sesiones-en-office365-con.html

Saludos.