NWUI : Un utilisateur AD/LDAP qui n’est pas défini dans NetWorker peut consulter le tableau de bord.
Summary: L’authentification externe (AD/LDAP) a été intégrée à NetWorker. Des rôles NetWorker ont été intégrés aux utilisateurs ou groupes AD/LDAP. Toutefois, un utilisateur externe qui n’a reçu aucune autorisation dans NetWorker peut se connecter à NWUI et consulter le tableau de bord. ...
Symptoms
AD/LDAP a été intégré à NetWorker. L’intégration d’autorité externe NetWorker n’a pas de chemin de recherche utilisateur ou de chemin de recherche de groupe spécifié (accès en lecture global) :
Des utilisateurs ou des groupes AD/LDAP ont été ajoutés aux champs de rôles externes de Groupes d’utilisateurs de serveur>. Un utilisateur AD/LDAP n’appartient à aucun des groupes définis dans NetWorker, et il n’est défini dans aucun des groupes d’utilisateurs NSR.
L’utilisateur AD/LDAP peut se connecter à NetWorker Web User Interface (NWUI) et voir les onglets Dashboard et Monitoring :
L’utilisateur n’est pas en mesure de vérifier ou de modifier la configuration de NetWorker. Toutefois, ils peuvent accéder aux informations sur les tâches terminées ou en cours d’exécution sur le serveur NetWorker :
Cause
Ce problème a été signalé aux ingénieurs NetWorker. NetWorker fonctionne normalement. Si aucun chemin de recherche utilisateur ou chemin de recherche de groupe n’est spécifié, NetWorker authc dispose d’un accès en lecture global à l’ensemble de la structure AD/LDAP.
Cela peut également être observé si un chemin de recherche utilisateur et/ou un chemin de recherche de groupe ont été définis, mais qu’il est défini sur faible dans la structure AD/LDAP, ce qui permet à la recherche dans la sous-arborescence de récupérer les utilisateurs/groupes sous le chemin d’accès défini.
Resolution
Limitez la visibilité de NetWorker sur l’organisation AD/LDAP aux seuls utilisateurs/groupes qui doivent avoir accès à NetWorker. Pour ce faire, utilisez les champs User Search Path et Group Search Path dans la ressource d’autorité externe NetWorker.
- Dans l’environnement AD/LDAP, identifiez le nom unique (DN) du conteneur (CN) parent ou de l’unité d’organisation (OU) qui nécessite un accès à NetWorker.
Par exemple, la commande PowerShell suivante peut être utilisée pour identifier l’emplacement d’un groupe dans Microsoft AD :
Get-ADGroup -Identity "GROUP_NAME" | Select-Object -Property Name,ObjectClass,DistinguishedName
PS C:\Users\Administrator> Get-ADGroup -Identity "NetWorker_Admins" | Select-Object -Property Name,ObjectClass,DistinguishedName Name ObjectClass DistinguishedName ---- ----------- ----------------- NetWorker_Admins group CN=NetWorker_Admins,OU=DELL,DC=networker,DC=lan
Dans cet exemple, nous pouvons voir que le groupe appartient à l’unité d’organisation (OU) OU=DELL,DC=networker,DC=lan. L’OU/CN du groupe peut être utilisé comme chemin de recherche de groupe.
La commande PowerShell suivante peut être utilisée pour obtenir l’emplacement des utilisateurs Microsoft AD au sein d’un groupe AD :
Get-ADGroupMember -Identity "GROUP_NAME" | Select-Object Name, SamAccountName, ObjectClass, DistinguishedName
Exemple :
PS C:\Users\Administrator> Get-ADGroupMember -Identity "NetWorker_Admins" | Select-Object Name, SamAccountName, ObjectClass, DistinguishedName Name SamAccountName ObjectClass DistinguishedName ---- -------------- ----------- ----------------- NetWorker Engineering nwree user CN=NetWorker Engineering,OU=DELL,DC=networker,DC=lan Backup Administrator bkupadmin user CN=Backup Administrator,OU=Support_Services,OU=DELL,DC=networker,DC=lan
Remarque : Vous devez prendre en compte les ressources de sous-arborescence. Par exemple, s’il existe d’autres unités d’organisation/réseau dans le chemin sélectionné, elles sont également visibles par NetWorker. Cela peut être utilisé pour accorder des autorisations aux utilisateurs/groupes sous un chemin spécifique ; À l’inverse, il ouvre également l’accès aux groupes/ressources sous un chemin spécifié. Pour obtenir de l’aide afin d’obtenir les chemins de recherche appropriés pour les utilisateurs et les groupes, consultez votre administrateur de domaine.
- Connectez-vous à NetWorker Web User Interface (NWUI) à l’aide du compte administrateur NetWorker par défaut.
- Accédez à Authentication Server-External>Authority.
- Sélectionnez la ressource d’autorité externe, puis cliquez sur EDIT.
- Dans les propriétés de la ressource externe, accédez à l’onglet ADVANCED CONFIGURATION.
- Mettez à jour les champs Group Search Path et User Search Path pour inclure le chemin OU/CN (à l’exception des valeurs DC) à la ressource OU/CN parente à laquelle vous souhaitez que NetWorker authc ait accès en lecture.
- Accédez à l’onglet CONFIGURATION DE BASE .
- Dans le champ User DN Password, saisissez le mot de passe du compte DN de l’utilisateur.
- Cliquez sur SAVE. La ressource signale si elle a été mise à jour avec succès :
Les utilisateurs/groupes qui résident sous le chemin de recherche de groupe et le chemin de recherche d’utilisateur spécifiés pourront toujours se connecter à NWUI ; toutefois, les utilisateurs qui résident en dehors de ces chemins ne seront pas autorisés à accéder à NWUI.
Additional Information
Sur le NetWorker Server, vérifiez quels utilisateurs/groupes externes sont définis dans les groupes d’utilisateurs NetWorker :
nsradmin show name; external roles print type: nsr usergroup
Un utilisateur externe peut être trouvé par authc ; toutefois, n’est membre d’aucun des groupes définis dans les champs « NSR usergroup external roles » ; L’utilisateur n’est défini dans aucun de ces champs :
Sur le NetWorker Authentication Server, vérifiez les groupes AD/LDAP auxquels appartient un utilisateur.
authc_mgmt -u Administrator -p 'NETWORKER_ADMINISTRATOR_PASSWORD' -e query-ldap-groups-for-user -D query-tenant=TENANT_NAME -D query-domain=DOMAIN_NAME -D user-name=USER_NAME
Dans ce cas, l’utilisateur testuser2 ne fait pas partie du groupe AD NetWorker_Admins défini dans les champs NSR usergroup external roles, et le nom unique de l’utilisateur n’est pas non plus défini dans les champs external roles.