10.12 Sierra Cacher un compte utilisateur

Flickta

Membre confirmé
7 Juillet 2011
85
16
Bonsoir,

Dans le passé, il était possible de cacher un compte utilisateur à l'écran de login qui présente les comptes en local.

Question :

1/ est-il encore possible le faire ?
2/ est-il possible de masquer le répertoire de connexion situé dans /Users ?

Merci :)
 
Je confirme que la procédure exposée dans la fiche Apple est entièrement fonctionnelle.

Conséquence pour ce qui est du login -->

  • si l'option d'affichage par "nom et mot-de-passe" est choisie (at: Préférences Système > Utilisateurs et groupes > Options) => il suffit de renseigner le nomdecompte et le mot-de-passe dans les 2 cases vides superposées à l'écran ;

  • si l'option d'affichage par "liste d'utilisateurs" est choisie => il suffit de sélectionner l'icône Autre > ce qui ramène un affichage par "nom et mot-de-passe" comme ci-dessus => il convient alors de renseigner le nomdecompte et le mot-de-passe dans les 2 cases vides superposées à l'écran.

  • En cas d'activation de «FileVault» (at: Préférences Système > Sécurité et confidentialité > FileVault) => l'utilisateur masqué ne se trouve pas affiché dans la liste des utilisateurs activables au privilège de déverrouiller par leur mot-de-passe de session le Volume Logique Chiffré à l'écran initial de déverrouillage. Conséquence : dans le cas de figure d'une activation de «FileVault» > l'utilisateur masqué ne peut pas se logger à l'écran initial --> il ne peut donc ni déverrouiller le Volume Logique Chiffré > ni ouvrir sa session de ce fait. Il faut qu'un utilisateur non-masqué ait déverrouillé le Volume Logique > ouvert sa session > puis se soit déloggé > pour que > le Volume Logique toujours déverrouillé > l'écran de login classique (LoginWindow) offre la possibilité de se logger à l'utilisateur masqué.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Flickta
Bonsoir,

Dans le passé, il était possible de cacher un compte utilisateur à l'écran de login qui présente les comptes en local.

Question :

1/ est-il encore possible le faire ?
2/ est-il possible de masquer le répertoire de connexion situé dans /Users ?

Merci :)
Je suppose que tu veux masquer le dossier aux autres utilisateurs.
Il te suffirait de mettre ce dossier ailleurs. Donc tu crées le compte comme d'habitude puis tu déplaces son dossier dans un autre dossier suivant la méthode ad hoc. Si, vraiment tu ne souhaites pas qu'on le voit, tu mets ce dossier dans un dossier dont les autres ne peuvent pas voir le contenu.

[Une méthode simple pour modifier le dossier maison d'un utilisateur (que je cite de mémoire...) :
  1. on commence par s'assurer d'avoir un compte administrateur de secours au cas où ça se passe mal ;
  2. on crée le compte, disons Brol (nom court : brol)
  3. on se délogge de ce compte et on se logge dans le compte administrateur disponible
  4. dans Terminal, on déplace le dossier vers ousque l'on veut qu'il soit ; par exemple dans /usr/local/pasvupaspris :
    1. sudo mkdir -p /usr/local/pasvupaspris
    2. sudo mv /Users/brol /usr/local/pasvupaspris/brol
    3. sudo chmod 755 /usr/local/pasvupaspris
  5. On ouvre les Préférences Systèmes puis l'onglet Comptes
  6. Là on fait un clic droit sur le compte "Brol" et on choisit l'unique item du menu (son libellé m'échappe)
  7. Dans la fenêtre qui s'affiche, on indique le nouveau chemin de la maisonnette de Brol.
  8. On valide.
  9. On peut alors tenter une connexion à Brol.
Notes :
a) l'exemple de chemin que j'ai pris (/usr/local/) ne marchera peut-être pas en raison des contraintes de sécurité du système, inutilement casse-nougats (le pénible SIP). Si tu veux modifier un dossier contrôlé, tu dois d'abord désactiver SIP, faire tes petites manipulations puis réactiver SIP illico.
b) tu peux aussi utiliser une astuce : au lieu de déplacer le dossier ailleurs, te contenter de faire un

mv /Users/brol /Users/.brol
tout en faisant les reste des manipulations. Comme ça, ppar défaut, le dossier ne sera pas visible, sauf à afficher les éléments invisibles dans le Finder. Je n'ai jamais essayé et il est possible qu'il y ait des effets de bord : autant essayer pour se faire une idée.
]
 
  • J’aime
Réactions: Flickta
b) tu peux aussi utiliser une astuce : au lieu de déplacer le dossier ailleurs, te contenter de faire un
mv /Users/brol /Users/.brol

Une commande :
Bloc de code:
chflags hidden /Users/brol
masquerait également le dossier de compte brol (sans affecter l'intitulé).​
 
Je l'oublie toujours, ce chflags.
 
Merci pour vos réponses. Et pour répondre à vos questions : oui je cherche à cacher le compte d'admin de l'écran de login (et ne laisser que les utilisateurs "normaux") mais aussi le cacher du dossier /Users.

Je mets de côté vos retours pour tests !
 
Suppose que le nomdecompte de l'utilisateur (ou utilisatrice) soit brol.

Le plus simple de loin serait alors de passer les 2 commandes :
Bloc de code:
sudo dscl . create /Users/brol IsHidden 1
sudo chflags hidden /Users/brol

(en remplaçant chaque fois brol par le nomdecompte exact de l'utilisateur)

  • la 1ère commande va masquer l'utilisateur à l'écran d'ouverture de session (LoginWindow)
  • la 2è > va rendre invisible (à l'affichage graphique par le Finder) le dossier de l'utilisateur dans le répertoire des Utilisateurs (sans le déplacer > et donc sans changer le chemin à ce dossier de départ de session pour l'utilisateur)
 
Merci macomaniac,

Cette méthode est effectivement extrêmement plus simple que celle décrite par Bompi (;-)), voire Apple elle-même qui indique devoir déplacer le ~ dans /var plutôt que de servir de la commande chflags... pourquoi compliquer les choses ainsi ?

A l'époque de Snow Leopard il fallait taper ceci :

sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array nomducompte

Et ensuite, cacher le ~ en mettant un point devant le nom du répertoire de connexion avec la commande mv.

Je crois que c'était tout pour Snow Leopard...
 
La commande :
Bloc de code:
sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array nomducompte
opère une édition du fichier de préférence com.apple.loginwindow.plist (localisé dans le sous-dossier Preferences de la Bibliothèque Générale de l'OS = /Library).

Le LoginWindow est le processus gestionnaire de l'écran de connexion (login ou ouverture de session). Cet écran est affiché (lorsque le chiffrement «FileVault» n'est pas activé) tout à la fin du chargement du Système. En vue de l'affichage de cet écran de connexion > le processus LoginWindow consulte son fichier de préférences et hop ! doit masquer l'utilisateur s'il y a en a un de mentionné comme devant être masqué.

Tu noteras que dans ta commande --> c'est l'utilitaire defaults qui est appelé (c'est l'utilitaire en charge de l'édition des fichiers de préférences de type .plist) > avec le verbe write (écrire = éditer une préférence) > l'adresse du fichier-cible (com.apple.loginwindow ici) > et le paramétrage à inscrire.

Dans un fichier de type plist > un paramétrage déterminé se compose d'une paire rédigée en mode superposé = clé > chaîne.

  • une clé (= key) désigne le type de paramètre par son nom agglutiné --> dans ton exemple, la clé = HiddenUsersList (liste des Utilisateurs Cachés)

  • une chaîne (= string) est la valeur associée au paramètre de la clé --> dans ton exemple, la valeur de la chaîne est le nomdecompte de l'utilisateur bénéficiaire du masquage, brol dans mon exemple.

Mais (vas-tu me dire) --> je lis -array comme désignation pour la valeur associée à la clé > au lieu de -string. La raison en est la petite complication suivante --> il arrive que pour un paramètre donné (clé) > une cascade de valeurs de chaînes puisse être associée (par exemple ici plusieurs nomsdecomptes d'utilisateurs à masquer). Dans un pareil cas de figure > la cascade des chaînes de valeurs associées à une clé > se trouve encadrée dans un tableau (= array).

La syntaxe d'un tel paramètre dans le fichier com.apple.loginwindow.plist correspond donc à ceci :
Bloc de code:
<key>HiddenUsersList</key>
    <array>
        <string>brol</string>
    </array>

où tu discernes que la ligne supérieure de la clé s'écrit toujours ainsi -->
<key>-----</key>
(le titre du paramètre encadré par <key> (en ouverture) et </key> (en fermeture) ;

que
<array>
-----
</array>

constituent les indicateurs d'ouverture (<array>) et de fermeture (</array>) du tableau des chaînes de valeurs associées à la clé

que
<string>brol</string>
constitue ici la seule chaîne de valeur incluse dans le tableau --> le nomdecompte brol se trouvant encadré par <string> (en ouverture) et </string> (en fermeture).

=> si tu as compris cette logique d'écriture > tu as compris la syntaxe universelle valable pour tout fichier plist dans macOS. Il faut noter que la moindre erreur (la plus minuscule erreur) d'écriture, par exemple écrire </string en fermeture d'une chaîne en oubliant le > final --> invalide instantanément le fichier plist entier > et par là plante le processus qui s'y réfère. Pas forcément instantanément (car le processus peut se référer à une mise en cache de la préférence) > mais nécessairement au reloggement de session après déloggement ou encore au re-démarrage.

C'est pourquoi il est hautement déconseillé d'éditer à la main un fichier plist > mais qu'il vaut mieux passer des commandes dans le «Terminal» utilisant les 2 utilitaires spécialisés à cette fin : defaults et PlistBuddy (qui est un utilitaire d'édition plus pointu que defaults qui est en somme l'éditeur générique).

----------

La commande que je t'ai passée :
Bloc de code:
sudo dscl . create /Users/brol IsHidden 1
opère la même action de masquage d'utilisateur à l'écran de connexion > mais n'édite pas le fichier de préférences du LoginWindow > mais ce qu'on peut appeler la Carte-d'Identité de l'utilisateur.

Un utilisateur dans l'OS est l'association d'une Identité Logique et d'un dossier de compte. L'Identité Logique est consignée dans un fichier de type brol.plist à l'adresse précise suivante : /private/var/db/dslocal/nodes/Default/users/ brol.plist (le sous-dossier users en bout de chemin est la base de données des utilisateurs dans l'OS). Cette base de données est gérée par le Service d'Annuaire (dit : Open Directory). Pour éditer les paramètres d'une Carte-d'Identité d'utilisateur (un fichier de type brol.plist) > l'utilitaire conseillé (disons) est dscl (directory_service_command_line _utility : utilitaire du service d'annuaire exécutable en ligne de commande).

La syntaxe de l'utilitaire dscl est analogue à celle de defaults. Dans l'exemple de commande > tu vois que dscl est appelé > avec un . chargé d'indiquer qu'il s'agit du domaine d'hôte local > le verbe create (équivalent de write pour defaults) > l'adresse super-abrégée au fichier carte d'identité = /Users/brol (abrégé de : /private/var/db/dslocal/nodes/ Default/users/brol.plist qu'il ne faut surtout pas confondre avec l'adresse au dossier de compte /Users/brol dont il n'est absolument pas question ici malgré les apparences) > la mention de la clé = IsHidden > et la valeur de chaîne associée = 1 (synonyme de TRUE = VRAI).

Voici le dispositif syntaxique :
Bloc de code:
<key>isHidden</key>
    <array>
        <string>1</string>
    </array>

=> tu noteras qu'il est strictement conforme à la syntaxe : clé > [tableau] chaîne d'un fichier plist. Bien sûr > on pourrait utiliser defaults ou PlistBuddy pour éditer ce type de fichier plist > mais "ça craint" un maximum pour un fichier "Carte d'Identité" d'utilisateur si on se loupe. C'est pourquoi dscl est plutôt conseillé dans ce cas > mais son usage est assez obscur (il faut bien le dire).

En cas donc d'édition intrinsèque du fichier Carte-d'Identité d'utilisateur > le processus LoginWindow tient compte du paramètrage interne à la Carte-d'Identité d'utilisateur > au lieu de prendre le paramétrage externe (qui est son propre fichier de préférence de service).

[Pour avoir un aperçu du fichier Carte-d'Identité d'un utilisateur > et modifier des valeurs de paramètres en mode graphique > voici le truc : tu ouvres le panneau Utilisateurs et groupes des Préférences Système > tu déverrouilles le panneau > tu cliques le nom d'un utilisateur dans la colonne de gauche tout en pressant la touche ctrl (control) > ce qui affiche un bouton Options avancées... à côté du nom de l'utilisateur cible => presser ce bouton affiche un panneau qui est une vue abrégée du fichier Carte-d'Identité (brol.plist dans mon exemple) sans la complexité syntaxique des clés > tableaux > chaînes.]

----------

Pour ce qui est de cacher le dossier de compte (sans le déplacer) > mettre un . devant le nom du dossier de départ dans le répertoire des Utilisateurs (ce qui donnerait dans mon exemple un chemin : /Users/.brol) est une manière de cacher ce dossier. Mais l'objection que je ferais pour un dossier de compte d'utilisateur est que l'intitulé est intrinsèquement modifié par l'ajout du . qui fait désormais partie du nom du dossier. Si tu n'édites pas > dans le fichier Carte-d'Identité brol.plist le paramètre du chemin au dossier de départ qui est au départ ceci :
Bloc de code:
<key>home</key>
    <array>
        <string>/Users/brol</string>
    </array>
de la manière suivante :
Bloc de code:
<key>home</key>
    <array>
        <string>/Users/.brol</string>
    </array>

le chemin au dossier de départ est cassé.

C'est pourquoi je trouve plus avantageuse l'autre manière de masquer le dossier de départ > par la commande chflags (change_flags = modifier les attributs fixés aux objets) et la mention hidden (caché) qui fixe l'attribut (ou flag) "hidden" sur l'objet-cible.

Ce flag est adressé au Finder qui, en le lisant sur l'objet > n'affiche pas ce dernier graphiquement. L'avantage > c'est que l'intitulé de l'objet n'est pas modifié > donc le chemin au dossier de départ n'a pas à être édité dans le fichier Carte-d'Identité brol.plist.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Flickta
macomaniac,

Wouah... Merci pour ce cours sur la différence entre la méthode de Snow Leorpard (et l'utilisation de l'utilitaire : defaults sur les fichiers .plist) et la méthode de la commande dscl qui interfère sur la carte d'identité du compte à modifier.

Je comprends qu'on peut (dans ce cas précis) obtenir le même résultat mais en agissant à des endroits différents. La méthode via la commande dscl et la commande chflags me semble éminemment plus "propre".

D'ailleurs, chflags servirait également à masquer un dossier lambda du Finder.

chflags hidden ~/Bureau/dossieracacher

Plutôt que :

mv ~/Bureau/dossiersecret .dossiersecret

j'ai bon ?
 
Oui. Mettre un '.' devant un nom de fichier ne le rend pas complètement caché du Finder (il suffit de passer en mode "affichage des fichiers cachés"). Tandis que le changement d'attribut rend le fichier invisible quel que soit le mode du Finder et que son nom commence, ou pas, par un '.'.

Reste que le fichier n'est pas invisible pour autant puisqu'on le verra par d'autres moyens aisément (shell, autres explorateurs de fichiers).
 
Dernière édition:
defaults est une commande pratique qui te permet de modifier tout fichier de préférences conforme aux normes d'Apple (grosso modo un fichier XML, directement lisible ou compressé).
Elle permet ainsi d'éviter de manipuler les fichiers et d'en corrompre la structure. Pour autant, cela permet aussi de modifier des paramètres qu'il vaut mieux ne pas trop tripoter...

dscl est la commande qui permet d'effectuer des modifications dans l'annuaire du système. On peut l'employer comme ci-dessus ou en mode interactif (on la lance sans commande et on obtient une invite : on peut ensuite se balader dans l'arborescence et modifier ce que l'on souhaite). Pratique mais, pour le coup, il faut y aller en douceur car on peut vraiment faire des dégâts, en mode administrateur (sudo).

Dans le temps on pouvait utiliser le Workgroup Manager, mais il ne semble plus mis à jour depuis 10.9 : il permet de réaliser ces manipulations en mode graphique, ce qui est parfois plus commode. Je l'ai encore utilisé sous El Capitan mais je ne l'ai pas testé avec Sierra.
 
  • J’aime
Réactions: Flickta
Accessoirement : pour quelle raison souhaites-tu cacher cet utilisateur ?
 
D'ailleurs, chflags servirait également à masquer un dossier lambda du Finder.
chflags hidden ~/Bureau/dossieracacher
Plutôt que :
mv ~/Bureau/dossiersecret .dossiersecret
j'ai bon ?

Presque. Disons : tout à fait dans l'esprit > et pas tout à fait dans la lettre.

Dans les 2 commandes chflags et mv --> tu dois désigner le Bureau dans la langue du Système = Anglais => Desktop [et il en va de même pour tous les autres objets de l'OS que tu peux désigner comme cibles dans une commande. Exemples : le sous-dossier Musique devient Music > un dossier Bibliothèque devient Library etc.]. Si tu ne sais pas l'intitulé-Système de tel objet > tu en fais un glisser-déposer direct dans la fenêtre du «Terminal» et hop ! tu le vois automatiquement inscrit dans l'intitulé adéquat. Tout ça > parce que le Finder affiche les intitulés-Système dans la langue de préférence de session (ici le Français).

Dans la 2è commande (mv) --> tu as bien séparé le segment "intitulé de départ" du segment "intitulé final" par un espace > mais tu as oublié de remettre avant l'intitulé final .dossiersecret le répertoire qui le contient = le Bureau. Ce qui fait que la commande ne va pas se contenter de modifier le nom du dossiersecret sans le déplacer > mais va renommer l'objet .dossiersecret tout en le déplaçant...

... où çà ? Hé ! dans l'espace-racine de ton dossier de compte au lieu de ton Bureau. Pourquoi cela ? - car quand tu ouvres une fenêtre du «Terminal» > tu es loggée par défaut en tant qu'opératrice directement dans l'espace-racine de ton dossier de compte. Ce qui se marque par le fait que ton nomdecompte est précédé par un tilde ~ > lequel désigne en abrégé (par convention) l'espace-racine du dossier de compte de l'utilisateur connecté. C'est un peu comme si une commande était passée en coulisses qui serait :
Bloc de code:
cd /Users/brol
(cd = change_directory --> changer le dossier de localisation de l'opérateur) dont le produit serait une invite de commande du type :
Bloc de code:
MacBook Pro:~ brol$

Donc si tu passes une commande (corrigée pour Bureau) :
Bloc de code:
mv ~/Desktop/dossiersecret .dossiersecret
--> le .dossiersecret non précédé d'aucun chemin va être interprété comme : objet localisé dans l'espace-racine du compte de l'utilisateur connecté (et pas objet localisé dans le sous-espace du Bureau).

Pour rendre invisible le dossier sans le déplacer > tu devrais passer la commande :
Bloc de code:
mv ~/Desktop/dossiersecret ~/Desktop/.dossiersecret

Et puisque je t'ai dit que tu étais loggée par défaut dans ~ (l'espace-racine de ton dossier de compte d'utilisatrice connectée) > tu peux donc benner ~/ en départ de chemin (car = redondance du défaut implicite ~) et désigner directement Desktop (qui sera compris comme : trouver l'objet Desktop dans ~ (l'espace-racine du dossier de compte de Mzelle Flickta connectée).

En résumé --> les commandes à la fois rectifiées et abrégées dans les chemins deviennent :
Bloc de code:
chflags hidden Desktop/dossiersecret
mv Desktop/dossiersecret Desktop/.dossiersecret

----------

NB. Pour démasquer un dossier rendu invisible par le flag "hidden" > tu utilises le paramètre inverse nohidden. Dans l'exemple précédent --> commande :
Bloc de code:
chflags nohidden Desktop/dossiersecret

Et si tu voulais que l'utilisateur masqué à l'écran de connexion LoginWindow soit de nouveau démasqué > alors il faut utiliser la valeur de chaîne 0 (= FALSE = FAUX) dans la commande dscl > ce qui donnerait pour l'utilisateur brol :
Bloc de code:
sudo dscl . create /Users/brol IsHidden 0

[Note personnelle : il faut quand même faire un peu gaffe avec ces personnalisations par des commandes assez techniques --> c'est qu'à force d'empiler des personnalisations > on risque de s'emmêler les pinceaux ou simplement de ne plus se souvenir du tableau d'ensemble des modifications introduites. Ni se rappeler les commandes permettant d'annuler les changements. Bref : le panorama logique devient compliqué et on risque de perdre le contrôle de la situation...]
 
@bompi : merci à toi aussi pour ces explications. Je prends un vrai cours du Terminal avec vous tous.

Pour répondre à ta question : je me dis que si l'iMac devait être volé ET que si la personne connait la manipulation pour réinitialiser le mot de passe d'un compte qu'elle verrait à la loginwindow pour désactiver iCloud et la fonction Localiser, il y aurait des chances pour qu'elle connecte l'iMac sur Internet et que pour le coup, la fonction Localiser du compte admin caché fasse son boulot.

Mais je me dis aussi que c'est trop simple pour que l'on puisse neutraliser la fonction Localiser comme ca... Donc, je dois me prendre la tête pour pas grand chose finalement :)

@macomaniac : d'accord avec ta note personnelle sur les personnalisations comme ca à outrance.
 
Dans le cas d'un vol, la seule vraie protection de tes données passerait par Filevault et le mot de passe du firmware (ce genre de choses, quoi).
C'est-à-dire :
  • le chiffrement du disque interne (Filevault) : même si l'ôte du Mac, on ne pourra rien en faire ;
  • l'accès contrôlé au Mac (firmware) : même en changeant son disque interne, le mot de passe du firmware empêchera son utilisation.
 
La fonction Localiser mon Mac, s'active et se désactive pour le Mac (et pas pour une session en particulier) en demandant la saisie de l'identifiant et mot de passe du compte iCloud depuis n'importe quelle session administrateur.
Donc pour que ta tactique fonctionne, en supposant que ton compte icloud et ton mot de passe soient connus du voleur, il faudrait masquer toutes les sessions admin et empêcher d'en recréer une (et d'activer le compte Root)