Configuración de delegación para ADFS/SAML, archivos y servidores DFS en Active Directory

 

Descripción general

Este artículo describe los pasos de configuración de la delegación para que ADFS/SAML funcione correctamente con cualquier servidor de archivos y DFS de back-end en Active Directory. Cuando los recursos compartidos de archivos se encuentran en un servidor diferente al servidor MyWorkDrive (MWD), se alcanzará a través de DFS, o los usuarios se autenticarán mediante ADFS/SAML, para pasar correctamente los tokens de usuario a los recursos compartidos de archivos back-end, se requiere que el servidor MyWorkDrive es de confianza para todos los servidores de archivos y servidores DFS para la delegación.

Tipos de delegación

Hay dos tipos de Delegación que puede elegir usar con MyWorkDrive.

• Delegación restringida/Delegación restringida de Kerberos o KCD
• Delegación limitada de Kerberos basada en recursos (RBKCD)

La delegación restringida o la delegación restringida de Kerberos (KCD) se pueden configurar a través de la interfaz de usuario de ADUC o a través de Powershell. Es el tipo más común, utilizado en los casos en los que tiene un único dominio sin fideicomisos externos.
Con la delegación restringida, está limitando el acceso a un servicio específico (en el caso de MyWorkDrive, CIFS)
Con la delegación restringida de Kerberos (KCD), está limitando el tipo de autenticación a Kerberos y el servicio a CIFS.

La delegación restringida de Kerberos basada en recursos solo se puede configurar a través de Powershell. Con RBKCD, también está especificando qué servidores (recursos) permitirán las solicitudes de acceso.
Se usa más comúnmente cuando se usa una confianza externa (es decir, hay recursos en dos dominios diferentes a los que está accediendo, como un servidor MyWorkDrive y usuarios en el Dominio1, con archivos compartidos en el Dominio2). Con un fideicomiso, se debe indicar específicamente a los recursos de dónde aceptar solicitudes de autorización, no aceptan solicitudes de autorización entre dominios a menos que estén específicamente autorizados. Obtenga más información sobre la configuración de confianza en Este artículo.

Puede obtener más información sobre los tipos de delegación diferentes en estos artículos.
Descripción general de la delegación restringida de Kerberos
Haciendo el segundo salto en PowerShell Remoting, que tiene una buena descripción general de los casos de uso de KCD y RBKCD
Delegación Kerberos, Una buena discusión sobre la implementación de KCD/RBKCD

Estos artículos mencionan otras formas de autenticación, como credSSP y JEA, que no se usan con MyWorkDrive, y Delegación sin restricciones, que no recomendamos debido a las implicaciones de seguridad.

Habilitar a través de MyWorkDrive

A partir del servidor MyWorkDrive 6.3, las secuencias de comandos incorporadas auditarán para ver si la delegación restringida está habilitada y le ofrecerán configurar la delegación directamente desde MyWorkDrive.

Esta auditoría y oferta de corrección está disponible tanto en la pestaña de recursos compartidos como en la nueva Panel de salud (también una nueva característica de 6.3)
Esta función funciona con la delegación restringida, que se establece con mayor frecuencia a través de la configuración de delegación de la GUI basada en ADUC. No detecta KCD/RBKCD y las advertencias pueden ignorarse con seguridad en esos casos.

En la lista de recursos compartidos, puede observar un icono de advertencia que indica que se requiere delegación, pero que no está configurado correctamente para un recurso compartido o recursos compartidos determinados.

 

Al hacer clic para editar el recurso compartido, se mostrará una advertencia de delegación Y un botón que le pedirá Agregar delegación.

Al hacer clic en el botón "Agregar delegación", aparecerá un mensaje sobre los requisitos de la cuenta: debe iniciar sesión en MyWorkDrive como administrador de dominio para usar la función de delegación automatizada. Si la cuenta con la que administra MyWorkDrive no es un administrador de dominio, puede continuar habilitando la delegación con uno de los pasos que se describen a continuación.

 

Los scripts integrados que auditan para ver si la delegación está habilitada y ofrecen configurar la delegación para usted directamente en MyWorkDrive también aparecen en el nuevo Panel de salud con la misma oferta para configurar la función de delegación.

Tenga en cuenta que es posible que el método automatizado no funcione en todos los entornos, especialmente en aquellos que requieren una forma específica de delegación, como KCD. Si el método automatizado no funciona para usted, revise las opciones adicionales a continuación para encontrar el método más apropiado para su entorno.

Delegación restringida

Configuración de la delegación restringida a través de usuarios y equipos de Active Directory de la interfaz de usuario de ADUC

El método más común para configurar la Delegación es a través de las propiedades del servidor MyWorkDrive en Usuarios y Equipos de Active Directory. Configure la delegación de Active Directory en el objeto de equipo del servidor MyWorkDrive para agregar servidores de archivos y servidores DFS en su organización.

– Desde un controlador de dominio – Administrador del servidor – Herramientas – Usuarios y equipos de Active Directory – Equipos – {seleccione el equipo en el que está instalado MWD} – Propiedades – Delegación – Confiar en este equipo para la delegación solo a servicios específicos – Usar cualquier protocolo de autenticación – Agregar – Usuarios o Computadoras: {seleccione la(s) computadora(s) que contiene(n) los recursos compartidos de red requeridos y la(s) computadora(s) con la función DFS instalada} - Aceptar - Servicios disponibles - seleccione cifs - Aceptar

Nosotros fuertemente recomendarte NO SELECCIONAR la opción que dice "Confiar en esta computadora para la delegación a cualquier servidor (solo Kerberos)". (delegación sin restricciones) Nosotros fuertemente le recomendamos que adopte un enfoque de acceso con privilegios mínimos especificando los servidores y servicios como se describe anteriormente (delegación restringida). Puede leer más sobre cómo proteger su directorio activo y los riesgos de delegación en petri.com y ADSecurity.org

Ejemplo de configuración para permitir que MWD confíe en la delegación a través de File-Server1 y DFS-Server1: – MWD instalado en la computadora MYWORKDRIVE-SERVER1 – Network File Share Server: FILE-SERVER1 – DFS Server: DFS-SERVER1

Con Powershell

También es posible asignar una delegación restringida a CIFS a través de Powershell; sin embargo, se recomienda usar el método GUI a través de ADUC.

Este ejemplo de secuencia de comandos creará una matriz de todos los servidores de archivos y permitirá la delegación a esos servidores de archivos específicos en el protocolo CIFS a los servidores MyWorkDrive.

—

# Importar el módulo ActiveDirectory
Módulo de importación de Active Directory

# Crear una matriz y asignarla a una variable. En el componente @, agregue los nombres de sus servidores de archivos o
Servidores host #DFS.
$TorgetComputers = @(“FileShare1”, “DFSshare1”)

# Recorra cada elemento de la matriz y configure la delegación
ForEach ($Computer en $TorgetComputers) {

# Conéctese al servidor MyWorkDrive: reemplace la frase “MWDServer” con el nombre netbios de su
Servidor #MYWorkDrive. Si tiene más de 1, ejecutará este script completo más de una vez.
Get-ADComputer -Identidad MWDServer

# Agregue el CIFS SPN de la computadora actual a la lista de servicios que FileServer puede delegar a
Set-ADComputer -Identity MWDServer -Add @{'msDS-AllowedToDelegateTo'= “cifs/$Computer”}
}

—

Pruebas

Para probar qué delegación existe usando Powershell, este comando le dará una lista de los servidores de archivos que confían en su servidor MyWorkDrive para la delegación. En el siguiente script, reemplace "MWDServer" con el nombre netbios de su servidor MyWorkDrive.

—

Get-ADComputer MWDSERVER -Properties msDS-AllowedToDelegateTo,Displayname | seleccione Displayname -ExpandProperty msDS-AllowedToDelegateTo | lista de formato

—

*Tenga en cuenta que los vales de Kerberos tardan al menos 15 minutos en reciclarse y, posiblemente, más tiempo para que Active Directory propague los cambios: espere al menos 15 minutos antes de comenzar a probar el acceso.

Es posible que pueda usar los argumentos “purgar” y “–li 0x3e7” con el klist Comando en los servidores de archivos y servidores MyWorkDrive para acelerar la parte de reciclaje, pero no hemos encontrado que sea particularmente efectivo.

Delegación restringida de Kerberos basada en recursos

Algunos entornos pueden requerir el método de configuración alternativo, Delegación limitada de Kerberos basada en recursos (RBKCD).

Para clientes con varios dominios (fideicomisos de dominio) o aquellos que hospedan su Active Directory en Azure AD Domain Services (esto no es lo mismo que Azure AD), la delegación debe estar habilitada mediante la delegación restringida basada en recursos en powershell. Se requiere RBKCD para dominios de confianza, ya que es el único método de delegación seguro que admite la autenticación de doble salto. Más detalles están disponibles en este Artículo de Microsoft. Algunos clientes en entornos de alta seguridad o cuando utilizan dispositivos de servidor de archivos también pueden requerir una delegación restringida basada en recursos.

Los pasos de configuración de Powershell para dominios de Server 2012 o superior se encuentran en el artículo de Microsoft sobre cómo habilitar la delegación restringida de Kerberos (KCD) en un dominio administrado y Cómo configurar la delegación de la computadora con powershell.

Un ejemplo de comando del servidor MyWorkDrive para un servidor de archivos y un servidor MyWorkDrive es el siguiente:

 

Dominio único:

Establecer-ADComputer MyWorkDriveServer -PrincipalsAllowedToDelegateToAccount (Get-ADComputer FileServer)

 

Múltiples dominios donde el servidor, los usuarios o los recursos de MyWorkDrive se encuentran en diferentes dominios:

Desde el servidor de Windows que aloja los archivos compartidos reales, que confiarán en el servidor MyWorkDrive, ejecute cualquiera de los siguientes comandos de PowerShell: donde $MyWorkDriveServer es el nombre del servidor MyWorkDrive y $FileServer es el nombre del servidor de archivos ingresando su Dominio donde el El servidor MyWorkDrive se encuentra en su consulta en la base de búsqueda o mediante el controlador de dominio especificado donde el servidor MyWorkDrive es miembro:

 

Controladores de dominio múltiples/de confianza y servidores MyWorkDrive múltiples:

Es importante tener en cuenta que ejecutar el comando Set-ADComputer en powershell borrar cualquier entrada de delegación existente y reemplazar ellos con sus nuevas entradas. Si ya tiene delegación de configuración para los servicios existentes, esto puede tener consecuencias no deseadas. Usando el método recomendado, primero buscará la configuración de delegación existente e incluirá esos servidores en la entrada de delegación, conservando la configuración de delegación existente mientras agrega otras nuevas para su servidor MyWorkDrive.

Puede descargar un archivo zip de este script de PS1 aquí.

Aquí está el contenido del guión:

—

1TP5NOTA IMPORTANTE: Este script sobrescribirá cualquier configuración de delegación basada en recursos existente en los equipos de destino.
#Ejecute el siguiente comando para ver cualquier configuración de delegación existente y agréguela a la lista de servidores $MWD:
Get-ADComputer -Identidad $Computer -servidor $dominio -Propiedades PrincipalsAllowedToDelegateToAccount

#La lista puede usar SID si es de un dominio confiable. Si se le proporciona un SID, use el siguiente comando para traducir el SID de
#el dominio de confianza:
Get-ADComputer –Filtro * | Where-Object {$_.SID –como “*1111”} | Seleccionar objeto: nombre de propiedad, SID
#replace “1111” con los últimos 4 dígitos del SID

# Importar el módulo ActiveDirectory
Módulo de importación de Active Directory

# Crear un array y asignarlo a una variable
#TargetComputers es para la lista de servidores de archivos y recursos compartidos DFS en el entorno.
1TP5Reemplace "FileShare1", "DFSSHare1" con los nombres de netbios de sus recursos compartidos de archivos y hosts DFS.
#Agregue tantos como sea necesario.
#Domain es su nombre de dominio en formato URL, es decir, dominio.local
$TorgetComputers = @(“FileShare1”, “DFSShare1”)
$Domain = “dominio.tld”

$Delegación actual
$MWDServer1 = (Obtener-ADComputer -Identidad MWDServer1)
$MWDServer2 = (Obtener ADComputer -Identidad MWDServer2)

# Recorra cada archivo/servidor DFS configure la delegación para el servidor MyWorkDrive
ForEach ($Computer en $TorgetComputers) {

# Agregar el recurso de la computadora actual a la lista de servicios que FileServer puede delegar a
# los “-server domain.tld” pueden eliminarse si todos los servidores/computadoras están contenidos dentro del mismo dominio; de lo contrario, especifique el dominio.
Conjunto-ADComputer -Identidad $Computer -servidor $dominio -PrincipalsAllowedToDelegateToAccount $MWDServer1, $MWDServer2

# Verifique que el valor del atributo incluya el servidor MyWorkDrive. Si es de un dominio de confianza, se mostrará como un SID.
Get-ADComputer -Identidad $Computer -servidor $dominio -Propiedades PrincipalsAllowedToDelegateToAccount
} Base de búsqueda:
$MyWorkDriveServer= Get-ADComputer -Filter {Name -eq “MYWORKDRIVE-SERVER”} -SearchBase “DC=MWF,DC=local” -Servidor “mwf.local”
$FileServer= Get-ADComputer -Filter {Name -eq “FILE-SERVER”} -SearchBase “DC=MWF,DC=local” -Servidor “mwf.local”
Set-ADComputer $FileServer -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer

—

Pruebas

Para probar que sus cambios fueron exitosos, ejecute el comando para ver la configuración de delegación del paso 1 de este proceso.
#Get-ADComputer -Identidad $Computer -servidor $dominio -Propiedades PrincipalsAllowedToDelegateToAccount

Ahora debería ver las entradas preexistentes junto con los nuevos recursos que agregó.

*Como se indicó anteriormente en este artículo, los tickets de Kerberos tardan al menos 15 minutos en reciclarse y, posiblemente, más tiempo para que Active Directory propague los cambios. Espere al menos 15 minutos antes de comenzar a probar el acceso.

Es posible que pueda usar los argumentos “purgar” y “–li 0x3e7” con el klist Comando en los servidores de archivos y servidores MyWorkDrive para acelerar la parte de reciclaje, pero no hemos encontrado que sea particularmente efectivo.

 

Cuenta de usuario de almacenamiento de Azure AD Domain Services

Para habilitar la delegación con Azure AD Domain Services y una cuenta de usuario de almacenamiento, debemos usar el siguiente comando de PowerShell para configurar la cuenta de usuario de almacenamiento para que confíe en la computadora del servidor MyWorkDrive con permiso para delegar usando KCD. También debemos mover la cuenta de la computadora del servidor MyWorkDrive y la(s) cuenta(s) de usuario para los recursos compartidos de archivos de Azure fuera de las unidades organizativas predeterminadas a una unidad organizativa personalizada. Los detalles están disponibles en este artículo de Microsoft. La delegación no funcionará si las cuentas en Active Directory no se mueven fuera de las unidades organizativas predeterminadas.

UNED
Las cuentas para el equipo del servidor MyWorkDrive y los usuarios de Azure File Shares deben estar en una unidad organizativa personalizada en la que tenga permisos para configurar KCD basado en recursos. No puede configurar KCD basado en recursos para una cuenta de equipo en el contenedor de equipos integrado de AAD DC.

Comandos Powersell
$ImpersonatingAccount = Get-ADComputer -Identidad
Establecer-ADUser -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Tenga en cuenta que para StorageUserAccount, es posible que deba usar el nombre de la cuenta SAM, no el nombre/nombre común. Busque el nombre de la cuenta SAM como el nombre anterior a Windows 2000 en la pestaña de la cuenta de elementos en ADUC o con Get-ADUser en Powershell

Ejemplo PowerShell

MWD01: nombre del servidor MyWorkDrive
SA_81e0bcb563: SAMAccountName del recurso compartido de archivos de Azure

$ImpersonatingAccount = Get-ADComputer -Identidad MWD01
Set-ADUser SA_81e0bcb563 - PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

 

Pruebas

Para verificar la delegación, ejecute el siguiente comando de PowerShell:

Get-ADComputer $MyWorkDriveServer -Propiedades * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity

O

A partir de MyWorkDrive Server 5.4 o superior, puede optar por ejecutar las pruebas en el panel de administración de MyWorkDrive Server en cada recurso compartido utilizando nuestro Compartir herramienta de prueba, en lugar de iniciar sesión en un cliente como usuario.

Casos especiales: DFS y AzureFiles

SFD

Cuando utiliza DFS con SSO y MyWorkDrive, debe configurar la Delegación para el servidor MyWorkDrive para las computadoras/hosts DFS Y los servidores de archivos compartidos.

IE, si tiene los siguientes servidores

DFS1 DFS2

Configurado para compartir archivos desde los siguientes servidores de archivos (dispositivos de almacenamiento unidos a Windows o AD) FileShareSanJose FileShareHouston FileShareNewYork

Luego, los cinco miembros de AD deben aparecer como aprobados para delegar a través de CIFS en la pestaña Delegación de AD del servidor MyWorkDrive.

Archivos de Azure

Cuando haya completado con éxito nuestro guía de configuración para usar Azure Files con MyWorkDrive, su cuenta de Azure Files Storage será un miembro del dominio. Ese miembro de dominio debe agregarse a Delegación para el servidor MyWorkDrive para que SSO presente correctamente esa unidad como un recurso compartido a los usuarios.

Solución de problemas

Si sus recursos compartidos aparecen en blanco cuando los usuarios inician sesión a través de SSO, es probable que la Delegación no esté configurada correctamente. Si cree que configuró correctamente la delegación a través de KCD o Active Directory, puede usar Powershell para probar si el dispositivo/servidor de recursos compartidos de archivos acepta correctamente la delegación. Esto le indicará si el usuario que inició sesión puede acceder a los archivos y carpetas en el recurso compartido de archivos delegado.

Puede usar un script de Powershell muy simple para probar si la Delegación está configurada correctamente, usando una técnica conocida como "Double Hop". Puede encontrar información adicional sobre esta prueba en https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/ Para realizar esta prueba, necesitará 3 máquinas en su directorio activo

• Cliente: puede ser cualquier máquina unida a un dominio; como una estación de trabajo con Windows 10. Ejecutará el comando Powershell desde la máquina.
• MyWorkDrive Server: el servidor que debería poder acceder al recurso compartido a través de la delegación
• Servidor de archivos: el servidor que está configurado para delegación en el servidor MyWorkDrive.

También necesitará saber la ruta compartida de un recurso compartido en el servidor de archivos que tiene archivos, a los que puede acceder el usuario que ha iniciado sesión. El comando powershell es Invoke-Command -ComputerName $MMyWorkDriveServerName -ScriptBlock {Get-ChildItem -Path \\$FileServer\ShareName } Reemplazará $MyWorkDriveServerName con el nombre de red de su servidor MyWorkDrive. Reemplazará $FileServer\ShareName con el servidor de archivos y el recurso compartido que desea probar. El recurso compartido debe contener archivos a los que espera que el usuario tenga acceso. Y ejecute el comando desde la estación de trabajo del Cliente Ejemplo En nuestro ejemplo, estamos probando la delegación a un Linux Samba Share desde dos servidores MyWorkDrive diferentes. Un servidor MyWorkDrive tiene establecida la delegación, el otro no. Estamos probando desde un cliente de Windows 10 en el dominio. Delegación no configurada En esta prueba, probaremos la delegación en un servidor donde intencionalmente no configuramos la delegación y esperamos un error.

• Servidor MyWorkDrive: mwf-scott6
• Servidor de archivos: ubuntu-samba
• Compartir: todos

Ejecute Powershell en el miembro del dominio de Windows 10 y ejecute el siguiente comando Invoke-Command -ComputerName mwf-scott6 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\todos} Los resultados que obtenemos son: Un error de que la ruta del archivo no existe. La delegación no funcionó y nuestro usuario no pudo acceder al recurso compartido. En este escenario, el recurso compartido aparecerá en blanco cuando el usuario inicie sesión en MyWorkDrive a través de SSO. Este es el resultado esperado ya que no configuramos la delegación. También puede indicar que su servidor de archivos/dispositivo no acepta la delegación, si está configurado correctamente. Configuración de la delegación En esta prueba, probaremos la delegación en un servidor donde la delegación esté configurada correctamente

• Servidor MyWorkDrive: mwf-scott5
• Servidor de archivos: ubuntu-samba
• Compartir: todos

Ejecute Powershell en el miembro del dominio de Windows 10 y ejecute el siguiente comando Invoke-Command -ComputerName mwf-scott5 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone} Los resultados que obtenemos son: Una lista de archivos y carpetas en el directorio. La delegación funcionó y nuestro usuario pudo acceder al recurso compartido.

Actualización de Windows de noviembre de 2021

Los parches publicados por Microsoft durante el martes de parches de noviembre de 2021 el 9 de noviembre provocan acciones en blanco al iniciar sesión con SSO de manera similar a no habilitar correctamente la delegación. El problema se resolvió con parches a fines de noviembre y finalmente se solucionó en los Roll Ups de diciembre y enero.

A partir de mediados de 2022, no deberían presentarse más casos de esto, ya que esas actualizaciones ya no son relevantes.

Incluimos esta información con fines de archivo.

Si los inicios de sesión aparecen repentinamente en blanco en una instalación existente de MyWorkDrive que anteriormente funcionaba bien, debe reparar el parche defectuoso. ver este artículo para más detalles.

Si está configurando SSO por primera vez en su servidor MyWorkDrive, consulte el artículo para obtener detalles sobre cómo aplicar la corrección a sus controladores de dominio, además de configurar la delegación como se describe a continuación.
La solución para el parche proporcionado a través de Windows Update debe aplicarse manualmente. Sin agregar la solución para el parche de Windows Update, los inicios de sesión darán como resultado recursos compartidos en blanco.