• Bonjour Visiteur. Bienvenue sur les nouveaux forums de MacGeneration. La peinture est encore fraiche, quelques boulons doivent être resserrés, plus d’informations demain !

10.11 El Capitan Désactiver changement mot de passe

Mike4444

Membre junior
16 Juillet 2006
49
0
Lausanne
Bonjour,

En tant qu'administrateur de la machine, je veux empêcher un utilisateur "standard" de changer son mot de passe. Comment faire ?
Auparavant, via le "Contrôle parental", il y avait cette option, mais, sur el Capitan, elle a disparu.
Une idée ?
D'avance, je vous remercie.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
63 102
20 317
Forêt de Fontainebleau
Bonjour Mike

Comme tu l'as effectivement constaté, lorsqu'on se rend à : Menu  > Préférences Système > Utilisateurs et groupes > untel > Ouvrir les contrôles parentaux > Autre > dans «El Capitan» => l'ancienne option : "Désactiver le changement de mot-de-passe" a disparu de la liste des préférences cochables vs décochables.

Mais les interfaces graphiques dans lesquelles un utilisateur (un admin ici) peut établir des préférences (comme les panneaux des Préférences Système) sont toujours le côté « Scène » des choses dans OS X > le côté « Coulisses » étant les commandes en mode texte exécutables dans le «Terminal».

Quelles que soient les soustractions que les ingénieurs de la  peuvent effectuer aux interfaces graphiques d'utilisateurs (l'exemple le plus scandaleux étant l'amoindrissement des fonctions de l'«Utilitaire de Disque» dans «El Capitan») > les utilitaires UNIX appelables en ligne de commande dans le «Terminal» conservent, eux, leur puissance exécutable intacte (et parfois même la voient implémentée de nouvelles fonctionnalités).

Un phénomène de ciseau (équivalant à un état d'injustice) est donc en train de se produire dans les dernières versions d'OS X entre des interfaces graphiques d'utilisateurs dont les fonctions rétrécissent et des opérations en ligne de commande dont les possibilités s'étendent [l'exemple le plus significatif encore étant la différence entre le logiciel graphique «Disk Utility.app» amputé de ses fonctions les plus pointues en comparaison de l'utilitaire UNIX diskutil qui ne cesse d'être enrichi d'options opératoires en ligne de commande de plus en plus raffinées].

Ce petit discours « théorique » (dont tu te serais peut-être bien passé) débouchant instamment sur un effet « pratique » : il est parfaitement possible, en ligne de commande, de désactiver pour un utilisateur (quelconque) la possibilité de changer son mot-de-passe d'utilisateur via le panneau des Utilisateurs et groupes des Préférences Système, en suppléant ainsi via le «Terminal» aux déficiences graphiques du Contrôle Parental.

Ce type de commande consistant à éditer, dans le fichier untel.plist qui paramètre l'identité d'un utilisateur dans le Système, la valeur d'une sous-clé dans le domaine de clés du contrôle parental, est assez délicate à manier et d'une syntaxe pointilleuse en soi. Il suffit que tu me donnes avec exactitude le nom de compte de ton utilisateur (= le "nom court" ou "nom abrégé" agglutiné, tel qu'il intitule son dossier dans le répertoire-Système des Utilisateurs) > et je te passerai la commande a exécuter dans le «Terminal» pour interdire à ce malheureux la possibilité de changer son mot-de-passe...

Comme il n'est pas non plus possible de renverser graphiquement cette préférence de détail dans le cadre d'un contrôle parental préservé > pour le cas où tu voudrais résilier ta restriction, une commande de destruction de la sous-clé avec sa valeur associée dans le fichier untel.plist concerné est évidemment disponible et je pourrai aussi te la fournir.
 
  • J’aime
Réactions: Mike4444

Mike4444

Membre junior
16 Juillet 2006
49
0
Lausanne
Bonjour,

Merci pour ta réponse, d'un style alliant efficacité et élégance (qualités rares dans un forum, donc qui méritent d'être relevées).

J'ai vainement effectué de longues recherches sur internet afin de dénicher la ligne de commande correspondant à la fonction supprimée dans le contrôle parental, c'est pourquoi je suis preneur de toute information à ce sujet. Le nom abrégé de l'utilisateur que je souhaite "bridé" est : eleves (eh oui, je suis enseignant...)

Je me permets deux autres questions connexes :
- où est stocké le fichier untel.plist ? (dans le dossier "Préférences" de la bibliothèque de l'utilisateur ?)
- est-ce que cette ligne de commande désactivera aussi la possibilité de changer de mot de passe via la fenêtre de connexion qui apparaît lorsque l'on se connecte à un dossier partagé sur un réseau local ?

D'avance, merci de ta réponse.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
63 102
20 317
Forêt de Fontainebleau
Le fichier-cible eleves.plist (comme tous les fichiers qui constituent les cartes d'identité des utilisateurs de l'OS : invité, standard, admin et root lui-même) est stocké à l'adresse suivante : /private/var/db/dslocal/nodes/Default/users/eleves.plist [le dossier terminal users est la base de données des utilisateurs pour l'Open Directory, qui est le service du répertoire dans l'OS. Attention là-dedans ! > données sensibles. Le dossier parent Default (qui contient toutes les bases de données de l'Open Directory) est en accès interdit graphiquement].

Voici la commande pour désactiver la possibilité graphique de changer le mot-de-passe pour le malheureux eleves (fais un copier-coller directo dans la fenêtre du «Terminal» at : Applications > Utilitaires) :
Bloc de code:
sudo dscl . -mcxset /Users/eleves com.apple.systempreferences com.apple.preference.myaccount 'always' '( ChangePassword )'
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-pase admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎.

Cette commande appelle l'utilitaire dscl (directory_service_command_line_utility) en droits root (sudo) > avec le . indiquant qu'il s'agit de l'espace local du Système-Hôte > avec l'extension de commande -mcxset (établir une préférence de type MCX (Management_Control_eXecution) > sur la mention abrégée du nom de l'utilisateur concerné, ici /Users/eleves --> mais c'est bien le fichier eleves.plist at: /private/var/db/dslocal/nodes/Default/users qui est ciblé par là > suivi du nom de domaine dans le fichier .plist : com.apple.systempreferences > suivi de l'intitulé de la sous-clé de ce domaine : com.apple.preference.myaccount > suivi du type de « statut » instauré : ici 'always' = toujours > suivi de la valeur associée à la sous-clé dans une chaîne : '( ChangePassword )' qui est une façon cryptique d'indiquer que la possibilité de changer de mot-de-passe est suspendue (mise entre parenthèses).

Il m'a fallu bidouiller un bon quart d'heure ce matin pour inventer une commande qui fonctionne - les extensions MCX de l'utilitaire dscl n'étant pas documentées. Enfin : j'ai testé => ça marche. Une fois l'utilisateur eleves loggé dans sa session, l'option du panneau des Utilisateurs et groupes est grisée et in-manipulable : Modifier le mot de passe.

Tu peux vérifier en ligne de commande que ta commande est bien passée et a bien édité le fichier eleves.plist comme voulu, en passant la commande (informative) suivante :
Bloc de code:
dscl . -mcxread /Users/eleves com.apple.systempreferences com.apple.preference.myaccount
=> tu devrais obtenir le retour d'affichage suivant :
Bloc de code:
State: always
Value: (
    ChangePassword
)
=> tu es alors absolument sûr que le capacité de modifier le mot-de-passe en mode graphique dans les Utilisateurs et groupes est désactivée.

[NB. Un administrateur facétieux pourrait très bien passer cette commande sur le nom d'un autre admin > le résultat ne se ferait pas attendre > l'autre admin serait viré au statut spécial : Admin, Contrôlé avec désactivation de la possibilité graphique de changer son mot-de-passe > sympa, non ?
]


Le daemon opendirectoryd qui assure le service exécutif de l'Open Directory étant constamment en train de tourner aussi longtemps que l'OS est démarré > les modifications d'écriture dans le fichier untel.plist prennent immédiatement effet pour l'utilisateur concerné.

Si tu étais saisi de remords (professoral) à l'égard du malheureux discipulus eleves > voici la commande à passer pour résilier ton magistère :
Bloc de code:
sudo dscl . -mcxdelete /Users/eleves com.apple.systempreferences com.apple.preference.myaccount 'always' '( ChangePassword )'
=> dans le domaine com.apple.systempreferences du fichier eleves.plist, la sous-clé com.apple.preference.myaccount se trouve supprimée avec le statut associé always et la restriction ( ChangePassword ) => si tu repasses la commande informative :
Bloc de code:
dscl . -mcxread /Users/eleves com.apple.systempreferences com.apple.preference.myaccount
=> tu ne devrais obtenir aucun retour d'affichage mais simplement la récupération directe de l'invite de commande à ton nom d'utilisateur.
 
Dernière édition:
  • J’aime
Réactions: Mike4444

Mike4444

Membre junior
16 Juillet 2006
49
0
Lausanne
Merci pour ce complément.
J'ai testé : grâce à cette ligne de commande, l'utilisateur ne peut plus modifier son mot de passe depuis sa session, via les "Préférences Système".
En revanche, il peut toujours le faire en se connectant, depuis un autre ordinateur, sur l'ordinateur concerné, à distance, pour accéder à un dossier partagé, via le bouton "Modifier le mot de passe..." (cf. capture d'écran).
Y a-t-il moyen de griser également ce bouton ?
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
63 102
20 317
Forêt de Fontainebleau
l'utilisateur ne peut plus modifier son mot de passe depuis sa session, via les "Préférences Système".
En revanche, il peut toujours le faire en se connectant, depuis un autre ordinateur, sur l'ordinateur concerné, à distance, pour accéder à un dossier partagé, via le bouton "Modifier le mot de passe..."
☝︎
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 ?
 
Dernière édition:
  • J’aime
Réactions: Mike4444

Mike4444

Membre junior
16 Juillet 2006
49
0
Lausanne
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.
Bien vu ! :up:

Cette dernière solution que tu proposes est certes inélégante, mais elle s'avère diablement efficace.
Testée et approuvée !
Mon problème est résolu.

Je t'adresse un grand MERCI pour ces lignes de code, mais aussi et surtout pour toutes les explications qui les accompagnaient. Ayant parcouru en vain le web pour trouver une réponse similaire, en français ou en anglais, j'imagine aisément que, grâce à toi, ce post va désormais devenir la référence en la matière, répondant de manière magistrale à la question : sous el Capitan, comment désactiver, pour un utilisateur standard, la possibilité de changer son mot de passe ?

Du coup, je vais m'instruire davantage en lisant tes autres messages sur ce forum :)

Meilleures salutations

P.S. Ne disposant que de la dernière version de OS X Server, j'ignore la réponse à ton post-scriptum.