fbpx

Que peut-on faire pour vous aider aujourd'hui?

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

Tu es là:
< Retour

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.

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.

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.

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 faire confiance à l'ordinateur serveur MyWorkDrive comme étant autorisé à déléguer :

$ImpersonatingAccount = Get-ADComputer -Identity
Set-ADUser -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.