Que peut-on faire pour vous aider aujourd'hui?
Dépannage des échecs de connexion/des partages manquants pour les utilisateurs
Lors de la connexion, MyWorkDrive effectue une recherche en temps réel dans Active Directory pour l'appartenance à un groupe d'un utilisateur et la fait correspondre à la configuration dans les partages afin qu'un utilisateur soit connecté avec succès.
Contenu
Exigences du processus de recherche
Pour qu'un utilisateur puisse se connecter avec succès, les éléments suivants doivent tous être vrais
- Les groupes AD sont configurés sur les partages dans MyWorkDrive
- Les groupes configurés sur les partages bénéficient d'autorisations en NTFS
- L'utilisateur qui se connecte est membre du ou des groupes configurés sur les partages dans MyWorkDrive.
- Le partage dispose d'autorisations NTFS et d'autorisations Windows, qui n'entrent pas en conflit
- Le compte d'ordinateur ou le compte d'utilisateur MyWorkDrive installé a le droit d'interroger les utilisateurs et les groupes sur AD.
Erreurs que vous pouvez rencontrer
Ce sont les erreurs typiques qu'un utilisateur peut rencontrer lors de la connexion si le processus de connexion échoue en raison de problèmes de partage/d'autorisation.
- Un message d'avertissement indiquant que l'administrateur n'a provisionné aucun partage pour votre compte
- Actions manquantes (certaines présentes, d'autres non)
- Actions vides/vierges.
Ces erreurs peuvent ne pas affecter tous les utilisateurs. En fonction de votre configuration, certains utilisateurs peuvent être impactés, d'autres non. Vous pouvez trouver des points communs autour des adhésions à des groupes : « Les administrateurs peuvent se connecter, les utilisateurs ne peuvent pas » ou les utilisateurs qui obtiennent des partages « La comptabilité fonctionne, mais pas les finances », « Les nouveaux utilisateurs ne peuvent pas accéder au partage, mais les utilisateurs existants vont bien ».
Dépannage
Si vos utilisateurs rencontrent l'un de ces problèmes, vous pouvez utiliser une combinaison d'outils intégrés à MyWorkDrive ainsi que des outils dans AD pour vous aider à résoudre le problème.
le outil de test de partage de fichiers vous permettra de simuler une connexion en tant que compte utilisateur pour un partage de fichiers donné, avec un e-mail (sso) ou un nom d'utilisateur/mot de passe.
L'outil de test de partage de fichiers signalera les erreurs avec la délégation (Délégation est requis si vous utilisez SSO). Il indiquera également les groupes dont un utilisateur est membre (que vous pouvez utiliser pour valider que MyWorkDrive renvoie le groupe attendu) et s'il a l'autorisation d'accéder au partage (les autorisations NTFS sont correctes).
Tableau de bord santé
le Tableau de bord santé vous donnera un aperçu rapide de si la délégation est correctement configurée et si nos requêtes sur AD réussissent.
Accès efficace
Pas un outil dans MyWorkDrive, mais Accès efficace est le moyen le plus efficace de déterminer si un utilisateur dispose d'autorisations sur un partage ou s'il est bloqué/refusé pour une raison quelconque (partage Windows, refus hérités, autorisation non héritée).
Problèmes courants/solutions
Il existe six problèmes courants qui entraînent des partages vides, des partages manquants ou des échecs de connexion.
1. Délégation (sso)
Si un utilisateur a accès à un partage via User/Pass (en utilisant le Outil de test de partage de fichiers, ou en désactivant temporairement le SSO sur le serveur), mais pas via SSO, manquant délégation en est presque certainement la cause.
La délégation manquante peut être résolue en activant la délégation sur le serveur MyWorkDrive vers les serveurs de fichiers appropriés (et serveurs DFS, si DFS est utilisé). Une erreur courante consiste à ajouter ou à modifier des serveurs de fichiers ou à ajouter de nouveaux serveurs DFS et à ne pas activer la délégation sur le serveur MyWorkDrive. Si vous disposez d'un environnement de travail dans lequel il manque soudainement des partages ou des partages manquants par intermittence, recherchez de nouvelles ressources dans l'environnement qui pourraient devoir être mises à jour sur le compte d'ordinateur MyWorkDrive.
Notez que différents scénarios peuvent nécessiter différentes méthodes de configuration de la délégation – via l'interface utilisateur, via Powershell, ou en utilisant KCD via PowerShell, ou sur un Compte utilisateur pour AzureFiles avec les services de domaine Azure AD. Les différentes méthodes sont toutes couvertes dans notre Article de délégation
Propagation
Une dernière note sur la délégation.
Le recyclage des tickets Kerberos prend au moins 15 minutes, et potentiellement plus longtemps pour qu'Active Directory propage les modifications, en particulier dans les domaines plus grands/distribués. Attendez au moins 15 minutes avant de répéter vos tests. Une attente d'une heure n'est pas anormale.
Il n'est pas rare que des groupes soient manquants ou non configurés sur les partages, car les modifications des autorisations NTFS doivent également être apportées dans MyWorkDrive (MyWorkDrive ne se synchronise pas automatiquement avec les autorisations NTFS car il est conçu pour que les administrateurs puissent fournir moins d'accès via MyWorkDrive. qu'un utilisateur aurait localement. Vérifiez la configuration du partage ou utilisez le Outil de test pour valider la configuration, y compris l'appartenance au groupe d'utilisateurs.
Si vous ajoutez manuellement l'utilisateur au partage et que le partage apparaît avec du contenu lors de la connexion de l'utilisateur, il est probable que l'utilisateur ne soit pas membre des groupes définis sur le partage.
Si vous ajoutez manuellement l'utilisateur au partage et que le partage apparaît vide lors de la connexion de l'utilisateur, alors l'utilisateur n'a probablement pas l'autorisation d'accéder au partage.
Les détails sur la configuration du partage sont disponibles dans Cet article.
Comme indiqué dans la configuration du partage, vous pouvez utiliser le outil de test pour valider si l'utilisateur a l'autorisation d'accéder au partage. L'outil de test vous montrera également à quels groupes l'utilisateur est membre.
Si l'outil indique que l'utilisateur n'a pas l'autorisation d'accéder au partage, vérifiez son appartenance au groupe et ses autorisations NTFS.
L'accès aux partages n'est accordé que lorsque l'utilisateur dispose d'un accès à la fois par le partage Windows ET les autorisations NTFS.
Accorder l'accès d'une manière où l'accès est limité via le partage Windows ou NTFS entraînera des partages manquants, des dossiers manquants, des partages inattendus en lecture seule ou vides.
Comme décrit dans notre Guide de partage de fichiers Windows, nous vous recommandons d'accorder à chacun un contrôle total via le partage Windows et d'utiliser NTFS pour appliquer des autorisations granulaires.
Vous verrez cela si vous utilisez Effective Access et notez que les autorisations telles que Créer des fichiers ou Créer des dossiers sont bloquées par partage.
Vous pouvez en savoir plus sur les tests avec Accès efficace dans notre article sur l'outil de test.
5. Adhésion d'utilisateur/groupe (utilisateur non membre du groupe)
MyWorkDrive utilise Active Directory et NTFS pour l'authentification et les autorisations. Si un utilisateur ne fait pas partie des bons groupes Active Directory ou si les bons groupes ne disposent pas des autorisations appropriées sur les partages/dossiers/fichiers, l'utilisateur n'aura pas plus d'accès via MyWorkDrive que via SMB. En utilisant une combinaison de Partager l'outil de test et Accès efficace en testant, vous pouvez déterminer si l’un ou l’autre pose problème.
6. Synchronisation AD
MyWorkDrive effectue toutes les requêtes sur le domaine et SMB via le compte ordinateur du serveur sur lequel il est installé. L'ordinateur et AD négocient le contrôleur de domaine utilisé, et ce n'est souvent pas celui sur lequel les modifications ont été apportées dans les grands environnements. Les changements immédiats peuvent ne pas être reflétés, notamment changements de mot de passe, nouveaux utilisateurs, modifications d'appartenance à un groupe d'utilisateurs, etc. Attendez au moins 15 minutes pour que les modifications se propagent. Vérifiez à nouveau quel serveur de connexion l'ordinateur hébergeant MyWorkDrive utilise et vérifiez vos modifications ici. Si la réplication pose un problème, dépanner la réplication.
Autorisations de recherche AD
Bien que plutôt rares, les modifications AD qui empêchent le serveur MyWorkDrive de rechercher des informations utilisateur sur AD peuvent être très frustrantes à résoudre, car AD ne fournit pas de bons retours pour les requêtes LDAP refusées/bloquées.
La modification la plus courante apportée à AD qui empêche les connexions des utilisateurs consiste à supprimer/désactiver le groupe pré-Windows 2000 sans le remplacer par le groupe d'utilisateurs authentifiés. Bien que les utilisateurs puissent généralement toujours se connecter, car ils peuvent toujours lire leurs propres attributs dans le contexte de l'utilisateur, l'appartenance au groupe ne peut pas être recherchée, ce qui entraîne une authentification réussie, mais un échec de connexion car l'utilisateur n'est pas associé aux partages.
MyWorkDrive utilise Microsoft Active Directory comme source d'identité externe pour valider l'appartenance des utilisateurs et des groupes de recherche.
L'authentification des utilisateurs et des machines dans Active Directory autorise l'accès au réseau uniquement aux utilisateurs et aux appareils répertoriés dans Active Directory.
MyWorkDrive est installé sur un serveur Windows appartenant à un domaine. En tant que compte d'ordinateur sur Active Directory, Windows Server est membre du groupe Utilisateurs authentifiés.
Le groupe Utilisateurs authentifiés est membre par défaut du groupe Pre-Windows 2000.
Si vous désactivez le groupe Pre-Windows 2000 ou supprimez les utilisateurs authentifiés du groupe Pre-Windows 2000, des échecs d'authentification et de recherche de groupe se produisent.
Nous vous recommandons de ne pas désactiver le groupe Pre-windows 2000. Toutefois, si vous devez désactiver ce groupe pour une raison quelconque, accordez l'autorisation Lire les informations d'accès à distance au compte d'ordinateur pour le(s) serveur(s) Windows sur lequel MyWorkDrive est installé dans AD pour les utilisateurs/groupes d'utilisateurs/unités d'organisation concernés.
Pour vérifier si les utilisateurs authentifiés du groupe compatible avec les versions antérieures à Windows 2000 sont à l'origine du problème, exécutez la commande PowerShell suivante :
Get-ADGroupMember -Identity « accès compatible pré-Windows 2000 »
Nous nous attendons à ce que les utilisateurs authentifiés soient renvoyés dans le résultat
Le serveur MyWorkDrive peut ou non être nommé ici, l'appartenance à un groupe hérité (groupe dans un groupe) n'est pas affichée avec cette commande.
Si le retour n'inclut pas les utilisateurs authentifiés, il est probable qu'il ait été supprimé intentionnellement. Vous devrez peut-être consulter votre équipe de sécurité pour voir si vous pouvez le restaurer.
Si vous avez supprimé des groupes hérités et devez ajouter l’objet ordinateur MyWorkDrive au groupe d’accès compatible pré-Windows 2000, PowerShell peut être utilisé.
Add-ADGroupMember -Identity « Accès compatible pré-Windows 2000 » -Members « MWDServer$ »
Dans notre exemple, nous avons utilisé un serveur nommé mwf-scott3, puis exécuté une commande Get-ADGroupMember pour valider qu'il avait été ajouté correctement.
Le « Groupe d'accès d'autorisation Windows » peut être utilisé comme alternative. Il peut également être ajouté et interrogé à l'aide de Powershell.
Add-ADGroupMember -Identity « Groupe d'accès d'autorisation Windows » - Membres « MWDServer$ »
Ici, nous ajoutons mwf-scott3 et effectuons une requête avec Get-ADGroupMember pour valider qu'il a été ajouté correctement
L'ajout d'utilisateurs authentifiés au groupe d'accès d'autorisation Windows est mieux géré via l'interface utilisateur des utilisateurs et ordinateurs Active Directory
