Directorio activo hybrido en Azure: ImmutableID / sourceAnchor

Ambos nombres son equivalentes, describen un atributo que no cambia durante la vida de un objecto. Se trata de identificar de forma única en un entorno local y en Azure AD.

Por defecto se calcula codificando en Base 64 la propiedad objectGUID del servidor local, por ejemplo:

$Usuario = Get-ADuser nombreDeUsuario -Properties * -server localhost
$ImmutableID = [system.convert]::ToBase64String(([GUID]($Usuario.ObjectGUID)).tobytearray())

Realmente no debería cambiarse, pero en ocasiones nos encontramos en la necesidad de hacerlo, bien por una migración de directorio, eliminación de usuarios, replicación con errores... Si en lugar de utilizar el objectGUID utilizariamos un atributo personalizado no tendríamos este problema pero conllevaría la gestión y administración del mismo, si dentro de la empresa cada uno tiene un identificador único personal podría utilizarse para calcular el sourceAnchor.

Esta propiedad se establece durante la instalación inicial, solo si se desinstala correctamente se puede volver a establecer con un valor personalizado, desde la versión 1.1.524.0 se facilita el atributo ms-DS-ConsistencyGuidcomo atributo de los usuarios a utilizar como sourceAnchor.

Podemos visualizar la propiedad actual desde PowerShell:

Import-Module AzureAD
$O365Cred = Get-Credential
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Connect-AzureAD -Credential $O365Cred
Get-AzureADUser -ObjectId nombreUsuario@midominio.com | Select objectID, UserPrincipalName, ImmutableID

Si bien, en la documentación aparece, la posibilidad de establecer el valor en nulo para desvincular las cuentas creadas localmente de la nube mediante powershell:

Set-AzureADUser -ObjectId nombreUsuario@midominio.com -ImmutableID $null

No genera ningún resultado ni modificación del objeto, por lo menos a fecha de hoy.

Como alternativa, podemos crear un usuario temporal en nuestro directorio, sincronizar e intercambiar sourceAnchor, asignando otro incorrecto al usuario a eliminar posteriormente.

 

 


Modern Backup Storage, DPM, NTFS y ReFS

A partir de System Center Data Protection Manager (DPM) 2016 se introdujo este nuevo sistema de "almacenamiento moderno de copias de seguridad" en su traducción literal, con el objetivo de simplificar, optimizar y gestionar de forma más rápida copias de seguridad locales consumiendo menos espacio.

En la práctica y de manera sencilla, se utiliza un volumen formateado en ReFS y ficheros/discos VHDX que se provisionan para la copia. La combinación de ambas permite sacar mayor rendimiento en el sistema de ficheros:

  • Clonación de bloques (Block cloning) permite transformar la copia de ficheros en copia de metadatos, es decir, si tenemos un Fichero A dividido en nuestro disco en 100 partes y lo copiamos en un Fichero B, este último hará referencia a las 100 partes iguales de su origen, enlaza el contenido. Si se produce una modificación de una parte del fichero, en ese momento se realiza una copia de la parte afectada (se desenlaza de A y se enlaza el nuevo bloque a B)
  • VDL disperso (Sparse Valid Data Length) agiliza la escritura de ceros en ficheros grandes, permite eliminar ficheros, y crear archivos de tamaño fijo VHDX de manera rápida.
  • Paridad acelerada por reflejos (Mirror accelerated Parity) se realiza la escritura de entrada espejada para después calcular la paridad y almacenarse en su ubicación final.

En el momento de "Agregar almacenamiento en disco" se formatea automáticamente el contenido de la unidad en ReFS.

Si bien este sistema de ficheros no sustituye todavía a NTFS, permite grandes ventajas en entornos de almacenamiento y virtualización.

Ahora bien, en el momento que intentamos localmente "Agregar DPM Externo" de Azure nos encontramos:

Error 100070: El destino de recuperación seleccionado para recuperar una o más archivos no es válido.
Acción recomendad: Asegúrese de que el destino de recuperación se encuentra en un volumen NTFS montado localmente

Durante la configuración no se advierte ni comprueba. En el momento de intentar agregarlo si ¿Por qué este requisito? ¿No se puede restaurar ficheros desde Azure sobre un destino ReFS?

 

Referencia de errores: Codigo de error de Data Protection Manager
Versión: Azure Backup Server v3 13.0.415.0

 

Descargar archivos grandes desde Azure Storage con Firmas de acceso compartido (SAS)

El almacenamiento de datos en cloud debe conllevar una política de acceso y control adecuada al tipo de información. Dentro de Azure podemos utilizar direcciones de enlace temporales para operaciones con ficheros en diversos escenarios. En nuestro caso utilizaremos SAS (Shared Acces Signature) para la descarga directa de archivos de gran volumen, de esta forma además de un mayor control tambien descargaremos de operaciones de entrada/salida a nuestro servidor, permitiendo mayor rapidez de acceso.

La dirección que se genera es del tipo:

https://miespacio.blob.core.windows.net/MiContenedor/MiFichero.zip?sv=2016-05-31&sr=b&sig=Kasdf8mqcgh4NMjQcRaZMTA1bSpXJrajsy404ZkDipE%3D&se=2018-08-27T12%3A10%3A33Z&sp=r

Donde distinguimos a continuación de la dirección URI del recurso un Token formado por:

  • sv: versión de API para ejecutar
  • sr: especificamos B para un blob y C para container
  • se: fecha limite a partir de la cual el enlace expira
  • sp: permisos asociados, en este caso R solo de lectura

Para ver más parametros adicionales y otras opciones tienes disponible la documentación completa aquí.

CloudStorageAccount cuentaAlmacen = new CloudStorageAccount(new StorageCredentials("miespacio", "clave"), true);
        var blobClient = cuentaAlmacen.CreateCloudBlobClient();
		
        var container = blobClient.GetContainerReference("MiContenedor");
        var blob = container.GetBlockBlobReference("MiFichero.zip");
		
        var token = blob.GetSharedAccessSignature(new SharedAccessBlobPolicy()
            {
                Permissions = SharedAccessBlobPermissions.Read,
                SharedAccessExpiryTime = DateTime.UtcNow.AddMinutes(60),
            }, new SharedAccessBlobHeaders()
            {
                ContentDisposition = "attachment; filename="+nombreFichero
            });

        var url = string.Format("{0}{1}", blob.Uri, token);
        Response.Redirect(url, true);

 

Autenticación doble en aplicaciones Office 365 y Outlook.com

La autenticación de doble factor añade una seguridad adicional a nuestra cuentas siempre conectadas. No es infalible pero si necesaria para datos/operaciones críticas, el juego del gato y el ratón en seguridad es continuo, como Hesperbot.

Actualmente podemos:

La opción más ágil es a traves de la aplicación Microsoft Authenticator, despues del baile de nombres que ha sufrido la app, esta disponible para Android, Windows y iPhone nos mostrará un código o un mensaje de aceptación según prefiramos.

En el caso de las cuentas de Microsoft, es necesario diferenciar las de Office 365 empresarial y las de Outlook/Live el proceso de configuración y creación de contraseñas para aplicaciones no compatibles es diferente a día de hoy:

Office 365 -> Configuración -> Seguridad y Privacidad -> "Actualice los número de teléfono que usa para la seguridad de la cuenta"

No es una opción muy destacada en la configuración, debería tener su propia sección o aparecer más claramente pero bueno...

En la parte superior aparecerá la opción "Contraseñas de aplicación" donde podemos dar un nombre para identificar donde hemos usado la contraseña. Una vez creada no es posible volver a verla, solo podremos eliminarla y volver a crear otra:

NOTA: En el caso de realizar la configuración de la app por primera vez, deberemos seguir el asistente inicial desde el botón "Configurar"

Con Office 365 nos permite dar nombre a las contraseñas:

 

URL para Office 365: https://account.activedirectory.windowsazure.com/AppPasswords.aspx

URL para Outlook/live: https://account.live.com/proofs/AppPassword

 

 

Forzar sincronización Azure AD Connect

El tiempo mínimo programable para la sincronización entre un entorno local y cloud dentro de las capacidades actuales de Azure Active Directory Connect es de 30 minutos, en ocasiones necesitaremos replicar de manera urgente cambios antes de este tiempo.

Nos aseguraremos de tener el modulo de sincronización con el comando: "Import-Module ADSync" y consultamos la configuracióna actual "Get-ADSyncScheduler".

El comando "Start-ADSyncSyncCycle Delta" fuerza la sincronización entre el AD local y el Azure AD, realiza la comparación de ambos y solo realiza la actualización de los cambios (DELTA)

Es posible realizar una sincronización completa (FULL) con el comando: 

Start-ADSyncSyncCycle -PolicyType Initial

lo que en algunos escenarios puede llegar a demorarse dependiendo del número de objetos.