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

 

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.

Enable via MyWorkDrive

New! As of MyWorkDrive server 6.3, built in scripts will audit to see if delegation is enabled and offer to set delegation for you directly from MyWorkDrive.

This audit and offer to fix is available on both the shares tab and in the new Health Dashboard (also a new feature of 6.3)

On the list of shares, you may note a warning icon that delegation is required, but that is is not correctly set for a given share or shares.

 

Clicking to edit the share will show both a delegation warning AND a button prompting you Add Delgation.

Clicking the “Add Delegation” button will display a message about account requirements – you must be logged in to MyWorkDrive as a Domain Administrator to use the automated delegation feature. If the account you administer MyWorkDrive with is not a domain administrator, you can continue enabling delegation with one of the steps outlined below.

 

The built in scripts that audit to see if delegation is enabled and offer to set delegation for you directly in MyWorkDrive also appear in the new Health Dashboard with the same offer to set delegation feature.

Note that the automated method may not work for all enviornments, particuarly those which require a specific form of delegation such as KCD. If the automated method does not work for you, please review the additional options below for the most appropriate method for your enviornment.

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

To enable delegation we need to use the powershell command below to set the Storage User account to trust the MyWorkDrive server computer as allowed to delegate to using KCD. We must also move the MyWorkDrive server computer account and the user account(s) for the Azure File Shares out of default OUs to a custom OU. Details are available in this Microsoft article

OU
The accounts for the MyWorkDrive server computer and the Azure File Shares user(s) must be in a custom OU where you have permissions to configure resource-based KCD. You can’t configure resource-based KCD for a computer account in the built-in AAD DC Computers container.

Powersell Settings
$ImpersonatingAccount = Get-ADComputer -Identity
Set-ADUser -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Note that for the StorageUserAccount, you may be required to use the SAM Account Name, not the Name/Common Name. Find the SAM Account Name as the Pre windows 2000 name on the items’ account tab in ADUC or with Get-ADUser in Powershell

Example Powershell

MWD01 – name of the MyWorkDrive server
SA_81e0bcb563 – SAMAccountName of the Azure File Share

$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

Patches released by Microsoft during November 2021’s Patch Tuesday on 9 November cause blank shares on login with SSO in a simliar way to not correctly enabling delegation. The issue was resolved with patches in late November, and finally fixed in the December and January Roll Ups.

As of mid 2022, no further cases of this should be presenting, as those updates are no longer relevant.

We include this information for archival purposes

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.