Configuration de la délégation pour les serveurs ADFS/SAML, de fichiers et DFS dans Active Directory

Les instructions de cet article s'appliquent uniquement aux installations MyWorkDrive utilisant Active Directory pour l'identité utilisateur et les partages de fichiers SMB. La délégation n'est pas requise lors de l'utilisation d'Entra ID comme répertoire d'utilisateurs.

 

 

Aperçu

Cet article décrit les étapes de configuration de la délégation pour que ADFS/SAML fonctionne correctement avec tous les serveurs de fichiers et DFS principaux dans Active Directory. Lorsque les partages de fichiers sont situés sur un serveur différent du serveur MyWorkDrive (MWD), seront atteints via DFS, ou les utilisateurs seront authentifiés à l'aide d'ADFS/SAML, pour transmettre correctement les jetons utilisateur aux partages de fichiers principaux, il est nécessaire que le serveur MyWorkDrive est approuvé par tous les serveurs de fichiers et serveurs DFS pour la délégation.

Types de délégation

Il existe deux types de délégation que vous pouvez choisir d'utiliser avec MyWorkDrive.

• Délégation contrainte / Délégation Kerberos contrainte ou KCD
• Délégation Kerberos contrainte basée sur les ressources (RBKCD)

La délégation contrainte ou la délégation contrainte Kerberos (KCD) peuvent être définies via l'interface utilisateur ADUC ou via Powershell. C'est le type le plus courant, utilisé dans les cas où vous avez un seul domaine sans approbations externes.
Avec la délégation contrainte, vous limitez l'accès à un service spécifique (dans le cas de MyWorkDrive, CIFS)
Avec la délégation Kerberos contrainte (KCD), vous limitez le type d'authentification à Kerberos et le service à CIFS.

La délégation contrainte Kerberos basée sur les ressources ne peut être définie que via Powershell. Avec RBKCD, vous spécifiez en outre quels serveurs (ressources) autoriseront les demandes d'accès.
Il est le plus souvent utilisé lorsqu'une approbation externe est utilisée (c'est-à-dire qu'il existe des ressources sur deux domaines différents auxquels vous accédez, comme un serveur MyWorkDrive et des utilisateurs sur Domain1, avec des partages de fichiers sur Domain2.). Avec une approbation, les ressources doivent être spécifiquement informées d'où accepter les demandes d'autorisation, elles n'acceptent pas les demandes d'autorisation inter-domaines à moins d'être spécifiquement autorisées. En savoir plus sur la configuration de Trust dans Cet article.

Vous pouvez en savoir plus sur les différents types de délégation dans ces articles
Présentation de la délégation Kerberos contrainte
Faire le deuxième saut dans PowerShell Remoting, qui donne un bon aperçu des cas d'utilisation de KCD et RBKCD
Délégation Kerberos, Une bonne discussion sur la mise en œuvre de KCD/RBKCD

Ces articles mentionnent d'autres formes d'authentification, telles que credSSP et JEA, qui ne sont pas utilisées avec MyWorkDrive, et la délégation sans contrainte, que nous ne recommandons pas en raison des implications en matière de sécurité.

Activer via MyWorkDrive

À partir du serveur MyWorkDrive 6.3, les scripts intégrés vérifient si la délégation contrainte est activée et proposent de définir la délégation pour vous directement à partir de MyWorkDrive.

Cet audit et cette offre de correction sont disponibles à la fois dans l'onglet partages et dans le nouveau Tableau de bord santé (également une nouvelle fonctionnalité de 6.3)
Cette fonctionnalité fonctionne avec la délégation contrainte, le plus souvent définie via le paramètre de délégation de l'interface graphique basée sur ADUC. Il ne détecte pas KCD/RBKCD et les avertissements peuvent être ignorés en toute sécurité dans ces cas.

Sur la liste des partages, vous pouvez remarquer une icône d'avertissement indiquant que la délégation est requise, mais qui n'est pas correctement définie pour un ou plusieurs partages donnés.

 

Cliquer pour modifier le partage affichera à la fois un avertissement de délégation ET un bouton vous invitant à ajouter une délégation.

Cliquer sur le bouton "Ajouter une délégation" affichera un message sur les exigences du compte - vous devez être connecté à MyWorkDrive en tant qu'administrateur de domaine pour utiliser la fonction de délégation automatisée. Si le compte avec lequel vous administrez MyWorkDrive n'est pas un administrateur de domaine, vous pouvez continuer à activer la délégation en suivant l'une des étapes décrites ci-dessous.

 

Les scripts intégrés qui auditent pour voir si la délégation est activée et proposent de définir la délégation pour vous directement dans MyWorkDrive apparaissent également dans le nouveau Tableau de bord santé avec la même offre pour définir la fonction de délégation.

Notez que la méthode automatisée peut ne pas fonctionner pour tous les environnements, en particulier ceux qui nécessitent une forme de délégation spécifique telle que KCD. Si la méthode automatisée ne fonctionne pas pour vous, veuillez consulter les options supplémentaires ci-dessous pour la méthode la plus appropriée pour votre environnement.

Délégation contrainte

Définition de la délégation contrainte via les utilisateurs et les ordinateurs Active Directory de l'interface utilisateur ADUC

La méthode la plus courante de configuration de la délégation consiste à utiliser les propriétés du serveur MyWorkDrive dans les utilisateurs et ordinateurs Active Directory. Configurez la délégation Active Directory sur l'objet ordinateur MyWorkDrive Server pour ajouter des serveurs de fichiers et des serveurs DFS dans votre organisation.

– À partir d'un contrôleur de domaine – Gestionnaire de serveur – Outils – Utilisateurs et ordinateurs Active Directory – Ordinateurs – {sélectionner l'ordinateur sur lequel MWD est installé} – Propriétés – Délégation – Faire confiance à cet ordinateur pour la délégation aux services spécifiés uniquement – Utiliser n'importe quel protocole d'authentification – Ajouter – Utilisateurs ou Ordinateurs – {sélectionnez le ou les ordinateurs contenant les partages réseau requis et le ou les ordinateurs avec le rôle DFS installé} – OK – Services disponibles – sélectionnez cifs – OK

Nous fortement Je vous recommande NE PAS CHOISIR l'option qui dit "Faire confiance à cet ordinateur pour la délégation à tous les serveurs (Kerberos uniquement)." (délégation sans contrainte) Nous fortement préconisez que vous adoptiez une approche d'accès le moins privilégié en spécifiant les serveurs et les services comme décrit ci-dessus (délégation contrainte). Vous pouvez en savoir plus sur la sécurisation de votre annuaire actif et les risques de délégation sur Pétri.com et ADSecurity.org

Exemple de configuration pour permettre à MWD d'approuver la délégation via File-Server1 et DFS-Server1 : – MWD installé sur l'ordinateur MYWORKDRIVE-SERVER1 – Network File Share Server : FILE-SERVER1 – DFS Server : DFS-SERVER1

Avec Powershell

Il est également possible d'attribuer une délégation contrainte à CIFS via Powershell, mais l'utilisation de la méthode GUI via ADUC est recommandée.

Cet exemple de script créera un tableau de tous les FileServers et permettra la délégation à ces serveurs de fichiers spécifiques sur le protocole CIFS au(x) serveur(s) MyWorkDrive

—

# Importer le module ActiveDirectory
Module d'importation ActiveDirectory

# Créez un tableau et affectez-le à une variable. Dans le composant @, ajoutez les noms de vos serveurs de fichiers ou
1Serveurs hôtes TP5TDFS.
$TargetComputers = @("FileShare1", "DFSshare1")

# Boucle à travers chaque élément du tableau et configuration de la délégation
PourChaque ($Computer dans $TargetComputers) {

# Connectez-vous au serveur MyWorkDrive - remplacez la phrase "MWDServer" par le nom netbios de votre
1Serveur TP5TMYWorkDrive. Si vous en avez plusieurs, vous exécuterez ce script entier plus d'une fois.
Get-ADComputer -Identity MWDServer

# Ajoutez le SPN CIFS de l'ordinateur actuel à la liste des services auxquels FileServer peut déléguer
Set-ADComputer -Identity MWDServer -Add @{'msDS-AllowedToDelegateTo'= "cifs/$Computer"}
}

—

Essai

Pour tester quelle délégation existe à l'aide de Powershell, cette commande vous donnera une liste des serveurs de fichiers qui font confiance à votre serveur MyWorkDrive pour la délégation. Dans le script ci-dessous, remplacez "MWDServer" par le nom netbios de votre serveur MyWorkDrive.

—

Get-ADComputer MWDSERVER -Propriétés msDS-AllowedToDelegateTo,Displayname | sélectionnez Displayname -ExpandProperty msDS-AllowedToDelegateTo | format-liste

—

*Notez qu'il faut au moins 15 minutes pour recycler les tickets Kerberos et potentiellement plus longtemps pour qu'Active Directory propage les modifications - Attendez au moins 15 minutes avant de commencer à tester l'accès.

Vous pourrez peut-être utiliser les arguments « purge » et « -li 0x3e7 » avec klist commande sur les serveurs de fichiers et les serveurs MyWorkDrive pour accélérer la partie recyclage, mais nous ne l'avons pas trouvé particulièrement efficace.

Délégation Kerberos contrainte basée sur les ressources

Certains environnements peuvent nécessiter la méthode de configuration alternative, la délégation contrainte Kerberos basée sur les ressources (RBKCD) .

Pour les clients avec plusieurs domaines (approbations de domaine) ou ceux qui hébergent leur Active Directory dans les services de domaine Azure AD (ce n'est pas la même chose qu'Azure AD), la délégation doit être activée à l'aide de la délégation contrainte basée sur les ressources dans PowerShell. RBKCD est requis pour les domaines approuvés car il s'agit de la seule méthode de délégation sécurisée qui prend en charge l'authentification à double saut. Plus de détails sont disponibles dans ce Article Microsoft. Certains clients dans des environnements à haute sécurité ou lorsqu'ils utilisent des appliances de service de fichiers peuvent également avoir besoin d'une délégation contrainte basée sur les ressources.

Les étapes de configuration de Powershell pour les domaines Server 2012 ou supérieur se trouvent dans l'article de Microsoft sur la façon d'activer la délégation contrainte Kerberos (KCD) sur un domaine géré et Comment configurer la délégation d'ordinateur avec powershell.

Voici un exemple de commande MyWorkDrive Server pour un serveur de fichiers et un serveur MyWorkDrive :

 

Domaine unique :

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

 

Plusieurs domaines où MyWorkDrive Server, les utilisateurs ou les ressources se trouvent dans différents domaines :

À partir du serveur Windows qui héberge les partages de fichiers réels, qui feront confiance au serveur MyWorkDrive, exécutez l'un des ensembles de commandes powershell suivantes : où $MyWorkDriveServer est le nom du serveur MyWorkDrive et $FileServer est le nom du serveur de fichiers entrant votre domaine où le Le serveur MyWorkDrive est situé dans votre requête dans la base de recherche ou en utilisant le contrôleur de domaine spécifié dont le serveur MyWorkDrive est membre :

Contrôleur de domaine spécifié :

$MyWorkDriveServer= Get-ADComputer -Identity MYWORKDRIVE-SERVER -server mwf-dc.mwf.local

$FileServer= Get-ADComputer -Identity "FILE-SERVER" -server mwf-dc.mwf.local

$FileServer2= GetADComputer – Identifier « FILE-SERVER2 » – serveur mwf2.dc.mwf2.local

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

Base de recherche :

$MyWorkDriveServer= Get-ADComputer -Filter {Name -eq "MYWORKDRIVE-SERVER"} -SearchBase "DC=MWF,DC=local" -Server "mwf.local"

$FileServer= Get-ADComputer -Filter {Name -eq "FILE-SERVER"} -SearchBase "DC=MWF,DC=local" -Server "mwf.local"

Set-ADComputer $FileServer -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer

 

Contrôleurs de domaine multiples/de confiance et plusieurs serveurs MyWorkDrive :

Il est important de noter que l'exécution de la commande Set-ADComputer dans PowerShell effacer toutes les entrées de délégation existantes et remplacer les avec vos nouvelles entrées. Si vous avez déjà configuré la délégation pour les services existants, cela peut avoir des conséquences indésirables. À l'aide de l'exemple de script PowerShell, vous rechercherez d'abord les paramètres de délégation existants et inclurez ces serveurs dans l'entrée de délégation, en préservant les paramètres de délégation existants tout en en ajoutant de nouveaux pour votre serveur MyWorkDrive.

Vous pouvez télécharger un fichier zip de ce script PS1 ici.

Compte utilisateur de stockage des services de domaine Entra ID

Pour activer la délégation avec les services de domaine Entra ID et un compte d'utilisateur de stockage, nous devons utiliser la commande PowerShell ci-dessous pour définir le compte d'utilisateur de stockage de manière à approuver l'ordinateur serveur MyWorkDrive comme étant autorisé à déléguer à l'aide de KCD. Nous devons également déplacer le compte d'ordinateur serveur MyWorkDrive et le ou les comptes d'utilisateur pour les partages de fichiers Azure des unités d'organisation par défaut vers une unité d'organisation personnalisée. Les détails sont disponibles dans cet article Microsoft. La délégation ne fonctionnera pas si les comptes dans Active Directory ne sont pas déplacés hors des UO par défaut.

UO
Les comptes de l'ordinateur serveur MyWorkDrive et des utilisateurs Azure File Shares doivent se trouver dans une unité d'organisation personnalisée où vous disposez des autorisations nécessaires pour configurer le KCD basé sur les ressources. Vous ne pouvez pas configurer le KCD basé sur les ressources pour un compte d'ordinateur dans le conteneur AAD DC Computers intégré.

Commandes PowerShell
$ImpersonatingAccount = Get-ADComputer -Identity
Set-ADUser -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Notez que pour le StorageUserAccount, vous devrez peut-être utiliser le nom du compte SAM, et non le nom/nom commun. Recherchez le nom du compte SAM en tant que nom pré-Windows 2000 dans l'onglet du compte des éléments dans ADUC ou avec Get-ADUser dans Powershell

Exemple Powershell

MWD01 – nom du serveur MyWorkDrive
SA_81e0bcb563 – SAMAccountName du partage de fichiers Azure

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

 

Essai

Pour vérifier la délégation, exécutez la commande PowerShell suivante :

Get-ADComputer $MyWorkDriveServer -Propriétés * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity

Ou

À partir de MyWorkDrive Server 5.4 ou supérieur, vous pouvez choisir d'exécuter les tests dans le panneau d'administration de MyWorkDrive Server sur chaque partage à l'aide de notre Partager l'outil de test, au lieu de se connecter à un client en tant qu'utilisateur.

Cas particuliers – DFS et AzureFiles

DFS

Lorsque vous utilisez DFS avec SSO et MyWorkDrive, vous devez configurer la délégation pour le serveur MyWorkDrive pour les ordinateurs/hôtes DFS ET les serveurs de partage de fichiers.

IE, si vous avez les serveurs suivants

DFS1 DFS2

Configuré pour partager des fichiers à partir des serveurs de fichiers suivants (périphériques de stockage joints Windows ou AD) FileShareSanJose FileShareHouston FileShareNewYork

Ensuite, les cinq membres AD doivent apparaître comme approuvés pour déléguer via CIFS dans l'onglet Délégation AD du serveur MyWorkDrive.

Fichiers Azure

Lorsque vous avez terminé avec succès notre guide de configuration pour utiliser Azure Files avec MyWorkDrive, votre compte de stockage de fichiers Azure sera un membre de domaine. Ce membre de domaine doit être ajouté à la délégation pour le serveur MyWorkDrive afin que SSO présente correctement ce lecteur en tant que partage aux utilisateurs.

Dépannage

Si vos partages s'affichent vides lorsque les utilisateurs se connectent via SSO, il est probable que la délégation ne soit pas configurée correctement. Si vous pensez avoir correctement configuré la délégation via KCD ou Active Directory, vous pouvez utiliser Powershell pour tester si le serveur/appliance de partage de fichiers accepte correctement la délégation. Cela vous indiquera si l'utilisateur connecté peut accéder aux fichiers et dossiers sur le partage de fichiers délégué.

Vous pouvez utiliser un script Powershell très simple pour tester si la délégation est correctement définie, en utilisant une technique connue sous le nom de "Double Hop". Des informations supplémentaires sur ce test sont disponibles sur https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/ Pour effectuer ce test, vous aurez besoin de 3 machines sur votre répertoire actif

• Client - il peut s'agir de n'importe quelle machine jointe à un domaine ; comme un poste de travail Windows 10. Vous exécuterez la commande Powershell à partir de la machine.
• MyWorkDrive Server - le serveur qui devrait pouvoir accéder au partage via la délégation
• Serveur de fichiers – le serveur défini pour la délégation sur le serveur MyWorkDrive.

Vous aurez également besoin de connaître le chemin de partage d'un partage sur le serveur de fichiers contenant des fichiers, auquel l'utilisateur connecté peut accéder. La commande powershell est Invoke-Command -ComputerName $MyWorkDriveServerName -ScriptBlock {Get-ChildItem -Path \\$FileServer\ShareName } Vous remplacerez $MyWorkDriveServerName par le nom de réseau de votre serveur MyWorkDrive. Vous remplacerez $FileServer\ShareName par le serveur de fichiers et le partage que vous souhaitez tester. Le partage doit contenir des fichiers auxquels vous vous attendez à ce que l'utilisateur ait accès. Et lancez la commande depuis le poste Client Exemple Dans notre exemple, nous testons la délégation à un partage Linux Samba à partir de deux serveurs MyWorkDrive différents. Un serveur MyWorkDrive a un jeu de délégation, l'autre non. Nous testons depuis un client Windows 10 sur le domaine. Délégation non configurée Dans ce test, nous allons tester la délégation sur un serveur sur lequel nous n'avons intentionnellement pas configuré la délégation et attendons une erreur.

• Serveur MyWorkDrive : mwf-scott6
• Serveur de fichiers : ubuntu-samba
• Partager : tout le monde

Exécutez Powershell sur le membre de domaine Windows 10 et exécutez la commande suivante Invoke-Command -ComputerName mwf-scott6 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } Les résultats que nous obtenons sont : Une erreur indiquant que le chemin du fichier n'existe pas. La délégation n'a pas fonctionné et notre utilisateur n'a pas pu accéder au partage. Dans ce scénario, le partage s'affichera vide lorsque l'utilisateur se connecte à MyWorkDrive via SSO. C'est le résultat attendu car nous n'avons pas configuré la délégation. Cela peut également indiquer que votre serveur de fichiers/appareil n'accepte pas la délégation, s'il est correctement configuré. Configuration de la délégation Dans ce test, nous allons tester la délégation sur un serveur où la délégation est configurée correctement

• Serveur MyWorkDrive : mwf-scott5
• Serveur de fichiers : ubuntu-samba
• Partager : tout le monde

Exécutez Powershell sur le membre de domaine Windows 10 et exécutez la commande suivante Invoke-Command -ComputerName mwf-scott5 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } Les résultats que nous obtenons sont : Une liste de fichiers et de dossiers dans le répertoire. La délégation a fonctionné et notre utilisateur a pu accéder au partage.

Mise à jour Windows de novembre 2021

Les correctifs publiés par Microsoft lors du Patch Tuesday du 9 novembre 2021 provoquent des partages vides lors de la connexion avec SSO de la même manière que l'activation incorrecte de la délégation. Le problème a été résolu avec des correctifs fin novembre, et finalement résolu dans les roll ups de décembre et janvier.

À partir de la mi-2022, aucun autre cas de ce genre ne devrait se présenter, car ces mises à jour ne sont plus pertinentes.

Nous incluons ces informations à des fins d'archivage

Si les connexions apparaissent soudainement vides sur une installation MyWorkDrive existante qui fonctionnait correctement auparavant, vous devez corriger le correctif défectueux, voir cet article pour les détails.

Si vous configurez SSO pour la première fois sur votre serveur MyWorkDrive, veuillez consulter l'article pour plus de détails sur l'application du correctif à vos contrôleurs de domaine, en plus de configurer la délégation comme décrit ci-dessous.
Le correctif du correctif fourni via Windows Update doit être appliqué manuellement. Sans ajouter le correctif pour le correctif Windows Update, les connexions entraîneront des partages vides.