☝︎
Il en veut "toujours plus"...
Théorie
Je suppose que le compte
eleves dans l'OS de ton Mac est une sorte d'identité collective, sous l'emprunt de laquelle un certain nombre de "
bons_petits" (terme consacré) peuvent se connecter à partir de leur ordinateur personnel, de manière à avoir accès à un dossier que tu as dédié en partage à cet utilisateur collectif dans le volume de ton OS.
Et comme lesdits "
bons_petits" sont en fait d'inqualifiables gredins en herbe, rien ne leur fait davantage plaisir que de changer le mot de passe de cet utilisateur collectif
eleves avec l'idée d'empêcher les autres, et surtout le maître, d'ouvrir cette session et de s'en réserver l'usage à eux seuls. Ce qui n'a d'autre effet que de faire perdre du temps à tout le monde, les autres ayant la même possibilité de modifier le mot-de-passe de l'utilisateur collectif
eleves, et le maître lui-même, en mode
admin, depuis le panneau des
Utilisateurs et groupes de son Mac.
Comme ces
bons_à_rien "
bon_petits" , sur leur ordinateur personnel, ont un statut
admin, il semble qu'ils aient alors, depuis leur ordinateur, le pouvoir de modifier le mot de passe de : «
eleves » dans le panneau de connexion du serveur, en surclassant par là le contrôle parental établi dans le panneau des
Utilisateurs et groupes de l'OS Hôte - exactement comme toi-même, en tant qu'
admin, tu gardes le pouvoir de modifier le mot-de-passe de : «
eleves » en surclassant le contrôle parental. Bref : le serveur leur accorde, sur leur ordinateur personnel, l'équivalent d'un statut de «
parent admin » à l'égard du compte «
eleves » en ce qui concerne le mot-de-passe, à l'égal de toi-même.
Je préfère te l'avouer tout de suite : je ne me suis jamais intéressé aux questions d'administration en mode «
serveur » pour me cantonner à des points d'administration en mode «
local ». Par suite, je ne connais rien aux astuces et aux finesses qui s'y rapportent.
Je n'ai donc à t'offrir qu'une parade en mode «
local » capable de
verrouiller l'identité d'utilisateur du compte
eleves > c'est de fixer un
flag d'immmutabilité (dit: le
flag: uchg comme
un_change) sur le fichier paradigme de l'identité de l'utilisateur
eleves : le fichier
eleves.plist. Sachant qu'aucun mot-de-passe d'utilisateur ne peut être changé, si le fichier "carte d'identité " de l'utilisateur est
verrouillé et rejette l'enregistrement de cette édition, quand bien même l'intervenant est-il
admin, et serait-il même
root (à part de passer en ligne de commande en
root pour recourir à un utilitaire spécialisé de déverrouillage) > l'état des lieux devrait être alors bloqué pour le compte
eleves (sans que ça empêche bien entendu des actions dans la session).
Bien sûr, il serait dommageable de verrouiller le fichier
untel.plist de la base de données des
users de l'
Open Directory, en ce qui concerne un utilisateur à plein titre de l'OS qui ne pourrait pas modifier son profil d'utilisateur > mais tel ne me semble pas le cas du compe
eleves, destiné à servir simplement de porte d'entrée de connexion collective pour l'accès simple à un dossier partagé. Cela veut dire que ceux qui endosseront cette identité dans ton OS n'auront aucun pouvoir d'agir sur l'identité de l'utilisateur
eleves, qui sera fixée une fois pour toutes.
À présent, lorsque une
préférence spéciale de
contrôle parental est établie dans le fichier
untel.plist de la base de données de l'
Open Directory, ce paramètre se trouve exporté sous forme de fichier
.plist détaché à l'adresse :
/Library/Managed\ Preferences/untel/com.apple.[mcxDomain].plist. Ainsi, la préférence établie dans
eleves.plist [composée d'une clé :
com.apple.preference.myaccount, d'un statut :
always et d'une valeur:
( ChangePassword ) ] ressortissant du domaine du contrôle parental:
com.apple.systempreferences > tu devrais avoir le fichier exporté suivant :
/Library/Managed\ Preferences/eleves/com.apple.systempreferences.plist > dont le contenu d'écriture, si tu l'ouvres, doit être:
Bloc de code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.preference.myaccount</key>
<array>
<string>ChangePassword</string>
</array>
</dict>
</plist>
=> tu me vois venir ? > autant le verrouiller
itou en lui imposant le
flag: uchg d'immutabilité ciblé utilisateur, car il doit avoir une fonction pour la constitution d'un
cache.
--------------------
Pratique
Tu n'as qu'à passer, l'une après l'autre (séparément) les 2 commandes que je te liste en une seule fenêtre de code (fais des copier-coller) :
Bloc de code:
sudo chflags uchg /private/var/db/dslocal/nodes/Default/users/eleve.plist
sudo chflags uchg /Library/Managed\ Preferences/eleves/com.apple.systempreferences.plist
(dans les 5' suivant une première authentification par mot-de-passe
admin pour un
sudo, une nouvelle authentification n'est pas requise pour la réitération du même type de commande) => tes 2 fichiers sont désormais verrouillés et immuables contre des actions d'utilisateur.
Au cas où tu voudrais suspendre le
flag: uchg (ne serait-ce que pour modifier graphiquement des paramètres de l'identité - voire du contrôle parental - de l'utilisateur collectif
eleves dans le panneau des
Utilisateurs et groupes, en qualité d'
admin) > alors il faudrait d'abord que tu passes les 2 commandes inverses suivantes dans le «
Terminal» :
Bloc de code:
sudo chflags nouchg /private/var/db/dslocal/nodes/Default/users/eleve.plist
sudo chflags nouchg /Library/Managed\ Preferences/eleves/com.apple.systempreferences.plist
(tu remarqueras que l'utilitaire
chflags <
change_flags> est appelé ici avec l'option
nouchg :
no_un_change dans lequelle tu admireras la résilence d'une figure de double négation) > cela fait, tu peux manipuler graphiquement les options du compte
eleves - sans changement pour l'interdiction locale de modifier le mot-de-passe > et ensuite tu repasses ma première paire de commandes, laquelle ré-impose le
flag_uchg d'immutabilité d'utilisateur.
Tu peux faire un essai en mode
local, en tant qu'
admin > la possibilité de modifier le mot-de-passe du compte
eleves doit se trouver
apparemment préservée > mais lorsque tu presseras le bouton d'
enregistrement de ton mot-de-passe modifié > le Système doit te retourner un
message d'erreur et rejeter ton appel (parce que le fichier de destination de l'édition
eleve.plist est
verrouillé contre toute action d'utilisateur dans le Système > par suite le fichier rejeton ne changera pas non plus).
Je conjecture que la même erreur à l'édition du mot-de-passe du compte
eleve devrait être retournée en cas d'action à partir d'un ordinateur distant et connexion via le serveur > car je ne vois pas comment une action d'utilisateur via le serveur pourrait surclasser le
flag_uchg sur le fichier de destination
local de l'écriture.
Cette "solution" est totalement dépourvue d'élégance et de raffinement : elle équivaut à opposer le bouclier intransperçable d'
Achille (forgé par
Héphaïstos soi-même) aux pointes de bronze vaines des lances des
bons_petits Troyens...
--------------------
PS. Est-ce que, dans des OS antérieurs à «El Capitan», une possibilité graphique était donnée à un admin local pour désactiver, dans l'interface de connexion du serveur, le possibilité de modifier le mot-de-passe du compte d'utilisateur servant de porte d'entrée à des utilisateurs distants ?