Guide de l'administrateur informatique (MDM)

Déploiement via MDM#

Network Share Mounter peut être entièrement configuré à l’aide d’un profil de configuration macOS standard. Tous les paramètres sont lus depuis le domaine de préférences de.fau.rrze.NetworkShareMounter.

Pour simplifier la création de profils, nous fournissons un schéma de manifeste JSON pour Jamf Pro et un manifeste pour iMazing Profile Editor.

Pour la distribution via AutoPKG, des recettes sont disponibles sur de.fau.rrze.pkg.networkShareMounter.

1. Partages gérés (managedNetworkShares)#

Le tableau managedNetworkShares définit les partages réseau déployés centralement pour les utilisateurs. Chaque entrée est un dictionnaire contenant les clés suivantes :

Exemple de payload :

<key>managedNetworkShares</key>
<array>
    <!-- Partage Kerberos, monté automatiquement, gestion externe des tickets -->
    <dict>
        <key>networkShare</key>
        <string>smb://fileserver.example.com/global</string>
        <key>authType</key>
        <string>krb</string>
        <key>externalKerberosManagement</key>
        <string>true</string>
    </dict>
    <!-- Partage par mot de passe, répertoire personnel par utilisateur, montage manuel uniquement -->
    <dict>
        <key>networkShare</key>
        <string>smb://home.example.com/%USERNAME%</string>
        <key>authType</key>
        <string>pwd</string>
        <key>mountPoint</key>
        <string>My Home Drive</string>
        <key>autoMount</key>
        <string>false</string>
    </dict>
</array>

Remarque : le tableau networkShares hérité de la version 2 est encore accepté pour la compatibilité ascendante, mais ne doit pas être utilisé dans les nouveaux profils.

2. Authentification et Kerberos#

Ces clés configurent la manière dont NSM gère les tickets Kerberos et l’identité des utilisateurs.

Gestion de l’expiration des mots de passe#

Lorsque NSM se connecte lui-même à Kerberos (kerberosRealm est configuré et les partages n’utilisent pas externalKerberosManagement), il peut avertir les utilisateurs avant l’expiration de leur mot de passe AD. Les avertissements sont activés par défaut : les deux seuils sont de 14 jours, ils apparaissent donc sans aucune configuration. Les comptes dont le mot de passe n’expire jamais ne reçoivent aucun avertissement.

Configurations courantes :

3. Démarrage automatique et cycle de vie de l’application#

Ces clés contrôlent si l’application démarre automatiquement à la connexion et comment elle se comporte à la fermeture.

Fonctionnement de l’application du démarrage automatique (macOS 13+)#

NSM utilise l’API SMAppService d’Apple pour s’enregistrer comme élément de connexion. macOS gère cela comme un LaunchAgent dans /Library/LaunchAgents/de.fau.rrze.NetworkShareMounter.plist (propriété root). Il s’agit du comportement macOS standard, avec les implications suivantes pour les administrateurs MDM :

• La commande osascript tell application "System Events" to delete login item "…" ne fonctionne pas pour les éléments enregistrés avec SMAppService. System Events ne gère que les éléments de connexion utilisateur à l’ancienne.
• Lorsque autostart = false est appliqué via une clé MDM verrouillée, NSM appelle SMAppService.unregister() à chaque démarrage et macOS supprime automatiquement le fichier LaunchAgent.
• Si vous gérez le démarrage automatique via votre propre LaunchAgent ou payload d’éléments de connexion, définissez autostart = false comme clé verrouillée pour empêcher NSM d’enregistrer un élément en conflit.

Empêcher les utilisateurs de désactiver le démarrage automatique#

macOS 13 (Ventura) et les versions ultérieures permettent aux utilisateurs de désactiver librement les applications en arrière-plan via les Préférences Système. Pour forcer le démarrage automatique et empêcher les utilisateurs de désactiver NSM, déployez un payload Managed Login Items avec votre profil de configuration :

• Rule Type: Bundle Identifier
• Rule Value: de.fau.rrze.NetworkShareMounter

Déclencher le démarrage automatique initial#

En raison de la conception de sécurité de macOS, une application doit être lancée au moins une fois avant que l’enregistrement de l’élément de connexion prenne effet. Pour un déploiement silencieux sans interaction de l’utilisateur, configurez votre MDM pour lancer NSM une fois immédiatement après l’installation ou à la première connexion.

Exemple de politique Jamf :

• Trigger: Login
• Frequency: Once per user per computer
• Command: sudo -u $(stat -f%Su /dev/console) open -a "/Applications/Network Share Mounter.app"

4. Interface utilisateur#

Ces clés contrôlent l’emplacement de montage, l’apparence de la barre de menus et les éléments de menu accessibles aux utilisateurs.

Personnalisation des éléments du menu#

Vous pouvez afficher, masquer ou désactiver les éléments individuels de la barre de menus à l’aide des clés suivantes. Définissez la valeur sur hidden pour supprimer complètement l’élément, ou sur disabled pour le griser sans le supprimer. Si une clé n’est pas définie, l’élément s’affiche normalement.

Exemple — masquer Préférences et Mises à jour aux utilisateurs :

<key>menuSettings</key>
<string>hidden</string>
<key>menuCheckUpdates</key>
<string>hidden</string>

5. Gestion des mises à jour logicielles#

NSM utilise le framework Sparkle pour les mises à jour automatiques. Dans les environnements gérés, il est généralement préférable de le désactiver et de gérer les mises à jour via MDM.

Remarque : la clé héritée enableAutoUpdater (logique inversée) est encore acceptée et migrée automatiquement au premier démarrage. Utiliser disableAutoUpdateFramework dans tous les nouveaux profils.

6. Scripting et automatisation#

NSM répond aux signaux UNIX, ce qui permet à des scripts externes de déclencher des opérations de montage et de démontage sans utiliser l’interface de l’application. Cela est utile pour les flux de travail de portails en libre-service permettant aux utilisateurs de « réparer » les lecteurs réseau.

Exemple :

# Obtenir le PID
NSM_PID=$(pgrep -x "Network Share Mounter")

# Démonter tous les partages
kill -SIGUSR1 "$NSM_PID"

# Monter tous les partages
kill -SIGUSR2 "$NSM_PID"

7. Problèmes connus et compatibilité#

Jamf Pro : la collecte d’inventaire (recon) se bloque

Lorsque les partages sont montés dans le répertoire personnel de l’utilisateur (comportement par défaut), le processus d’inventaire Jamf Pro (recon) peut se bloquer indéfiniment. Cela se produit parce que Jamf tente de calculer la taille totale du répertoire personnel, ce qui l’amène à parcourir tous les partages réseau montés.

Solution : Dans Jamf Pro, accédez à Settings > Computer Management - Management Framework > Inventory Collection et désactivez Include home directory sizes. Vous pouvez également définir la clé location sur un chemin en dehors du répertoire personnel, comme /Volumes.

Espaces de noms DFS basés sur le domaine (smb://example.com/share)

Les partages Kerberos qui pointent vers le nom de domaine au lieu d’un serveur de fichiers peuvent échouer avec “invalid credentials” alors que l’utilisateur dispose d’un ticket Kerberos valide. Active Directory n’a généralement pas de service principal pour le nom de domaine lui-même (cifs/example.com). Un nom de serveur comme smb://fileserver.example.com/share fonctionne, mais lie les utilisateurs à un seul serveur.

Solution : À partir de macOS 26.5, les Mac non liés à Active Directory peuvent résoudre les espaces de noms DFS via les contrôleurs de domaine. Déployez /etc/nsmb.conf avec le contenu suivant, par exemple sous forme de script ou de paquet via votre MDM, et conservez l’URL basée sur le domaine dans managedNetworkShares :

[default]
srv_lookup_enabled=yes

Pour plus de détails sur ce réglage, consultez la documentation d’Apple : https://support.apple.com/en-mz/guide/deployment/depd1a7cad1f/web

Platform SSO avec un Active Directory local

Avec Platform SSO (Microsoft Entra ID), un Mac ne reçoit par défaut qu’un ticket Kerberos pour le cloud (tgt_cloud). Il ne peut pas être utilisé pour les serveurs de fichiers locaux : les partages Kerberos échouent alors avec “invalid credentials” alors qu’un ticket est présent.

Solution : Activez Microsoft Entra Kerberos pour que Platform SSO fournisse aussi un ticket pour le domaine local (tgt_ad), et activez Use TGT from Platform SSO for Kerberos requests dans le payload de l’extension Kerberos SSO. Marquez les partages avec externalKerberosManagement afin que NSM utilise ces tickets. Vous pouvez vérifier la présence des deux tickets avec app-sso platform -s dans le Terminal (section “User Configuration”).

Network Share Mounter v3#

Si vous utilisez encore le Network Share Mounter hérité (v3/v2), la documentation est disponible dans notre dépôt.