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.

Habilitar a través de MyWorkDrive

¡Nuevo! A partir del servidor MyWorkDrive 6.3, los scripts incorporados auditarán para ver si la delegación está habilitada y le ofrecerán establecer la delegación directamente desde MyWorkDrive.

Esta auditoría y oferta de reparació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)

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.

Directorio Activo

Directorio activo de usuarios y computadoras

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)". Nosotros fuertemente le recomendamos que adopte un enfoque de acceso con privilegios mínimos especificando los servidores y servicios como se describe anteriormente. 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.

Para hacerlo a través de Powershell, debe especificar una lista de nombres principales de servicio (SPN) de FILESERVER en las cuentas de MyWorkDrive Server(s).

En el siguiente ejemplo, reemplazará "SERVIDOR DE ARCHIVOS" con el nombre netbios de su servidor de archivos y "MWDSERVER" con el nombre netbios de su servidor MyWorkDrive.

Para obtener la lista de SPN, puede usar el cmdlet Get-ADComputer y mostrar la propiedad servicePrincipalName del FILESERVER

Get-ADComputer FILESERVER -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName |formato-lista

obtendrá una lista que incluye entradas como
host/SERVIDOR DE ARCHIVOS
host/SERVIDOR DE ARCHIVOS.dominio.tld

Luego debe usar el cmdlet Set-ADComputer con el parámetro msDS-AllowedToDelegate reemplazando los valores de la sección msDS-AllowedToDelegateTo con los SPN del FILESERVER

Get-ADComputer -Identidad MWDSERVER | Set-ADAccountControl -TrustedToAuthForDelegation $true
Set-ADComputer -Identity MWDSERVER -Add @{'msDS-AllowedToDelegateTo'=@('cifs/FILESERVER','cifs/FILESERVER.domain.tld')}

Si tiene más de un servidor de archivos, puede continuar agregando spns para todos los servidores de archivos usando la misma sintaxis.
Si tiene más de un servidor MyWorkDrive, deberá ejecutar el conjunto de comandos para cada servidor MyWorkDrive.

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.

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

* Tenga en cuenta que Active Directory tarda al menos 15 minutos en aplicar estos cambios a su base de datos y replicar: espere al menos 15 minutos antes de comenzar a probar el acceso.

Delegación restringida de Kerberos

Algunos entornos pueden requerir el método de configuración alternativo, Delegación restringida de Kerberos (KCD).

Para los clientes con varios dominios 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. 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 recursos compartidos de archivos 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 servidor MyWorkDrive se encuentra en su consulta en la base de búsqueda o utilizando el controlador de dominio especificado donde el servidor MyWorkDrive es miembro:

Controlador de dominio especificado:

$MyWorkDriveServer= Get-ADComputer -Identidad MYWORKDRIVE-SERVER -servidor mwf-dc.mwf.local

$FileServer= Get-ADComputer -Identity “FILE-SERVER” -servidor mwf-dc.mwf.local

$FileServer2= GetADComputer – Identificar “FILE-SERVER2” – servidor mwf2.dc.mwf2.local

Set-ADComputer ($FileServer),($FileServer2) -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer

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

 

Cuenta de usuario de almacenamiento de Azure AD Domain Services

Para habilitar la delegación, debemos usar el comando PowerShell a continuación para configurar la cuenta de usuario de almacenamiento para que confíe en la computadora del servidor MyWorkDrive para delegar el uso de 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

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.

Configuración de 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, ejecute las pruebas en el panel de administración de MyWorkDrive Server en cada recurso compartido con nuestra herramienta de prueba integrada.

Casos especiales: DFS y AzureFiles

SFD

Cuando utiliza DFS con SSO y MyWorkDrive, debe configurar la Delegación para el servidor MyWorkDrive tanto para las computadoras DFS como para 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 servidor/dispositivo compartido 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 "doble salto". 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.