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

 

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.

Activer via MyWorkDrive

Nouveau! À partir du serveur MyWorkDrive 6.3, les scripts intégrés vérifient si la délégation 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)

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 trouver la méthode la plus appropriée à votre environnement.

Active Directory

Utilisateurs et ordinateurs Active Directory

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)." 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. 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.

Pour le faire via Powershell, vous devez spécifier une liste des noms principaux de service (SPN) du FILESERVER dans le ou les comptes du ou des serveurs MyWorkDrive.

Dans l'exemple ci-dessous, vous remplacerez "FILESERVER" par le nom netbios de votre serveur de fichiers et "MWDSERVER" par le nom netbios de votre serveur MyWorkDrive.

Pour obtenir la liste des SPN, vous pouvez utiliser l'applet de commande Get-ADComputer et afficher la propriété servicePrincipalName du FILESERVER

Get-ADComputer FILESERVER -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName |format-list

vous obtiendrez une liste qui comprend des entrées comme
hôte/FILESERVER
hôte/FILESERVER.domaine.tld

Ensuite, vous devez utiliser l'applet de commande Set-ADComputer avec le paramètre msDS-AllowedToDelegate en remplaçant les valeurs de la section msDS-AllowedToDelegateTo par les SPN du FILESERVER

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

Si vous avez plusieurs serveurs de fichiers, vous pouvez continuer à ajouter des spns pour tous les serveurs de fichiers en utilisant le même sytnax.
Si vous avez plusieurs serveurs MyWorkDrive, vous devrez exécuter le jeu de commandes pour chaque serveur MyWorkDrive.

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.

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 à Active Directory pour appliquer ces modifications à sa base de données et répliquer - Attendez au moins 15 minutes avant de commencer à tester l'accès.

Délégation Kerberos contrainte

Certains environnements peuvent nécessiter la méthode de configuration alternative, la délégation contrainte Kerberos (KCD) .

Pour les clients avec plusieurs domaines 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. 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 serveur MyWorkDrive se trouve 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 – Identifiez « 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

 

Compte d'utilisateur de stockage des services de domaine Azure AD

Pour activer la délégation, nous devons utiliser la commande powershell ci-dessous pour configurer le compte d'utilisateur de stockage pour qu'il fasse confiance à l'ordinateur serveur MyWorkDrive comme étant autorisé à déléguer à l'aide de KCD. Nous devons également déplacer le compte d'ordinateur du 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

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é.

Paramètres Powersell
$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, exécutez les tests dans le panneau d'administration de MyWorkDrive Server sur chaque partage à l'aide de notre outil de test intégré.

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 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.