Bonjour, je suis surpris, sous yosemite, je ne peux pas ouvrir une session invité car yosemite me demande un mot de passe, or il n'y en n'a pas. Avez-vous une idée ?
Merci, bye
Merci, bye
compte invité : demande de mot de passe
- Créateur du sujet caillebotis
- Date de début
D
Deleted member 1099514
Invité
Même pb pour moi:
quand je veux ouvrir la session "utilisateur invité" un mot de passe m'est demandé.
Que faire?
(iMac sous 10.11.4)
M
Membre supprimé 1060554
Invité
Bonjour bourdaud
Comme tu as pu le voir, ce fil créé en Juin 2015 par caillebotis n'a pas eu un grand succès public. Jean
, à l'époque, avait demandé si par hasard «Filevault» n'avait pas été activé - sans obtenir de réponse.
Il y a, en effet, deux grands cas de figure en ce qui concerne l'« Utilisateur invité » (c'est le Nom Complet), dont l'username est Guest (nom de compte) =>
Ayant brossé le contexte général, il semble que le problème initial renouvelé par bourdaud relève du second cas de figure. Je ne trouve qu'une interprétation : une absurdité logique est intervenue dans le fonctionnement du Système, associant par erreur le renseignement d'un mot-de-passe à l'identité de l'Utilisateur invité.
Essaie plusieurs fois de suite à Menu > Préférences Système > Utilisateurs et groupes de décocher la case "Autoriser les invités à se connecter à cet ordinateur" et de la recocher => cet acte graphique édite instantanément, dans la fichier d'identité /private/var/db/dslocal/nodes/Default/users/Guest.plist de l'Utilisateur invité, le couple clé-chaîne :
(= Autorisé) à :
(= Non autorisé) et vice-versa. Rester sur "Autoriser" coché in fine.
=> Re-démarrer et vérifier si la session de l'Utilisateur invité s'ouvre sans mot-de-passe. Si ce n'était toujours pas le cas (signe que le facteur responsable n'est pas le codage du fichier Guest.plist), je ne vois pas d'autre issue que de démarrer par ⌘R sur la partition de récupération «Recovery HD» et d'activer l'option : "Ré-installer OS X" à destination du volume de l'OS : le Système sera restauré (dans la préservation des comptes d'utilisateurs avec leurs données et des applications tierces ajoutées avec leurs préférences) et on peut espérer alors que le dysfonctionnement sera corrigé...
[Note : un "panachage" est susceptible d'intervenir, si «FileVault» était activé et si un Utilisateur invité était "Autorisé à se connecter à l'ordinateur" après que le volume verrouillé par le chiffrement ait été déverrouillé et démarré.
Il y aurait alors un Utilisateur invité de première instance, seulement capable de se connecter à l'écran initial de déverrouillage pour lancer «Safari» dans une session de la «Recovery HD» ; et un Utilisateur invité de seconde instance, capable de se logger dans une session d'invité de l'OS à la seule condition qu'un utilisateur habilité à déverrouiller le volume chiffré de l'OS ait opéré au préalable ce déverrouillage en ouvrant sa session, puis ait fermé sa session sans éteindre le Mac, pour rendre disponible l'écran d'ouverture de session à des invités de l'OS.
Pourrait-on imaginer alors une bourde logique issue de la combinaison des contraintes du chiffrement et de la latitude de se connecter sans mot-de-passe de l'Utilisateur invité de seconde instance dès lors que le Volume de l'OS a été déverrouillé ? - de tels paramètrages dissonants pourraient très bien occasionner des bourdes logiques...
Pour ré-installer l'OS en cas d'activation de «FileVault», lancer au préalable l'«Utilitaire de Disque» dans la «Recovery HD» > Menu: Fichier > Déverrouiller afin de remonter le volume de l'OS et le rendre accessible à la restauration.]
Comme tu as pu le voir, ce fil créé en Juin 2015 par caillebotis n'a pas eu un grand succès public. Jean
, à l'époque, avait demandé si par hasard «Filevault» n'avait pas été activé - sans obtenir de réponse.Il y a, en effet, deux grands cas de figure en ce qui concerne l'« Utilisateur invité » (c'est le Nom Complet), dont l'username est Guest (nom de compte) =>
- a) «FileVault» activé. Il s'agit de l'application responsable du chiffrement du volume complet de l'OS. Lorsque c'est le cas, le Volume de l'OS étant verrouillé par le chiffrement au démarrage du Mac, un écran s'offre d'entrée de jeu affichant d'une part les icônes des utilisateurs ayant un compte dans l'OS et accrédités à l'avance à déverrouiller le volume chiffré par leur mot-de-passe de session ; et d'autre part, par défaut, l'icône d'un Utilisateur invité.
Il serait logiquement absurde qu'un admin de l'OS ait à renseigner son mot-de-passe à cet écran afin de déverrouiller le volume chiffré de l'OS et de permettre son démarrage, tandis qu'un invité, lui, pourrait se logger sans mot-de-passe dans le même OS. Mais tel n'est pas le cas de figure. Quelqu'un qui choisit de se logger dans la session de l'Utilisateur invité à l'écran de déverrouillage du volume de l'OS chiffré par «FileVault», n'ouvre absolument pas une session dans cet OS dont le volume demeure totalement verrouillé par le chiffrement. Non : il ne peut que lancer par là le démarrage de la partition de récupération «Recovery HD», dont le Système auxiliaire n'est pas verrouillé par un chiffrement. Mais ce loggement dans une session de la «Recovery HD» est de surcroît affecté par une limitation drastique : l'Utilisateur invité dans sa session de la «Recovery HD» ne dispose en tout et pour tout que d'un utilitaire : il peut lancer «Safari» afin de naviguer sur le Net un point c'est tout.
Car il serait absurde que, se loggeant sans mot-de-passe dans une session de la «Recovery HD», il ait à sa disposition les outils d'une session de secours ordinaire, comme le «Terminal» ou l'«Utilitaire de Disque» - applications se lançant par défaut en mode root.
=> en résumé : l'Utilisateur invité lorsque «FileVault» est activé ne peut que lancer «Safari» dans une session restreinte de la «Recovery HD» collatérale au volume chiffré-verrouillé de l'OS. Il serait absurde que pour bénéficier d'une telle dérivation de boot insignifiante, l'Utilisateur invité ait à renseigner un mot-de-passe forcément inexistant - l'invité n'étant qu'un visiteur sans identité a priori, donc quelconque, n'ayant accès qu'à une aire de jeux restreinte : l'usage de «Safari» dans la «Recovery HD».
- b) «FileVault» désactivé. Le Volume de l'OS n'est pas chiffré et donc est non-verrouillé au démarrage. Il s'ensuit que le démarrage logiciel de l'OS s'effectue automatiquement jusqu'à l'affichage terminal de l'écran d'ouverture de session d'utilisateur (pour autant qu'une ouverture de session automatique au bénéfice d'un utilisateur ne soit pas activée).
Dans ce cas de figure, si un Utilisateur invité se trouve autorisé à ouvrir une session (ce qui a été opéré à l'avance par un utilisateur admin), l'espace de loggement n'est pas du tout le même que dans le cas de figure de «FileVault» activé. C'est bien dans l'OS démarré que l'Utilisateur invité va pouvoir ouvrir une session, et il ne subit pas a priori la limitation de ne pouvoir que lancer «Safari», mais il peut lancer les autres applications disponibles.
Deux sortes de filtres (permissif ou restrictif) sont susceptibles d'être appliqués supplémentairement à l'activité de session de l'Utilisateur invité => permissif : l'autorisation de se connecter à des dossiers partagés (choix opéré ou non à l'avance par un admin) ; restrictif : des limitations relevant du Contrôle Parental sont susceptibles de restreindre les opérations dans la session de l'Utilisateur invité (décision prise à l'avance encore par un admin).
Quoi qu'il en soit de ces filtres (+ ou -), l'Utilisateur invité (s'il n'a pas la connaissance d'une identité admin qui lui permettrait de s'autoriser) n'a aucun moyen d'affecter l'OS en place, et pas non plus de préserver des traces de son activité de session : documents ou fichiers de préférences. En effet, il ne bénéficie que d'un dossier de compte volatile créé ad hoc à l'ouverture de sa session dans le répertoire des /Users, et supprimé de ce répertoire à la fermeture de sa session avec tous ses contenus.
=> Comme, là encore, cet Utilisateur invité, quoique bénéficiant d'une liberté de manœuvre plus grande que l'invité dans le cas d'une activation de «FileVault», n'a aucune capacité d'intervention sur l'OS, et n'a pas non plus d'identité concrète susceptible de conservation, dans un compte qui se préserverait avec des contenus, mais n'est qu'un visiteur volatile dont les traces sont purgées après visite ; il est par conséquent logiquement absurde qu'un mot-de-passe puisse se trouver associé à cet Utilisateur en ouverture de session. Quel mot-de-passe, en effet, et comment ce n'importe qui susceptible de venir jouer les invités dans un compte d'Utilisateur invité en aurait-il a priori la connaissance ?
Il serait logiquement absurde qu'un admin de l'OS ait à renseigner son mot-de-passe à cet écran afin de déverrouiller le volume chiffré de l'OS et de permettre son démarrage, tandis qu'un invité, lui, pourrait se logger sans mot-de-passe dans le même OS. Mais tel n'est pas le cas de figure. Quelqu'un qui choisit de se logger dans la session de l'Utilisateur invité à l'écran de déverrouillage du volume de l'OS chiffré par «FileVault», n'ouvre absolument pas une session dans cet OS dont le volume demeure totalement verrouillé par le chiffrement. Non : il ne peut que lancer par là le démarrage de la partition de récupération «Recovery HD», dont le Système auxiliaire n'est pas verrouillé par un chiffrement. Mais ce loggement dans une session de la «Recovery HD» est de surcroît affecté par une limitation drastique : l'Utilisateur invité dans sa session de la «Recovery HD» ne dispose en tout et pour tout que d'un utilitaire : il peut lancer «Safari» afin de naviguer sur le Net un point c'est tout.
Car il serait absurde que, se loggeant sans mot-de-passe dans une session de la «Recovery HD», il ait à sa disposition les outils d'une session de secours ordinaire, comme le «Terminal» ou l'«Utilitaire de Disque» - applications se lançant par défaut en mode root.
=> en résumé : l'Utilisateur invité lorsque «FileVault» est activé ne peut que lancer «Safari» dans une session restreinte de la «Recovery HD» collatérale au volume chiffré-verrouillé de l'OS. Il serait absurde que pour bénéficier d'une telle dérivation de boot insignifiante, l'Utilisateur invité ait à renseigner un mot-de-passe forcément inexistant - l'invité n'étant qu'un visiteur sans identité a priori, donc quelconque, n'ayant accès qu'à une aire de jeux restreinte : l'usage de «Safari» dans la «Recovery HD».
--------------------
- b) «FileVault» désactivé. Le Volume de l'OS n'est pas chiffré et donc est non-verrouillé au démarrage. Il s'ensuit que le démarrage logiciel de l'OS s'effectue automatiquement jusqu'à l'affichage terminal de l'écran d'ouverture de session d'utilisateur (pour autant qu'une ouverture de session automatique au bénéfice d'un utilisateur ne soit pas activée).
Dans ce cas de figure, si un Utilisateur invité se trouve autorisé à ouvrir une session (ce qui a été opéré à l'avance par un utilisateur admin), l'espace de loggement n'est pas du tout le même que dans le cas de figure de «FileVault» activé. C'est bien dans l'OS démarré que l'Utilisateur invité va pouvoir ouvrir une session, et il ne subit pas a priori la limitation de ne pouvoir que lancer «Safari», mais il peut lancer les autres applications disponibles.
Deux sortes de filtres (permissif ou restrictif) sont susceptibles d'être appliqués supplémentairement à l'activité de session de l'Utilisateur invité => permissif : l'autorisation de se connecter à des dossiers partagés (choix opéré ou non à l'avance par un admin) ; restrictif : des limitations relevant du Contrôle Parental sont susceptibles de restreindre les opérations dans la session de l'Utilisateur invité (décision prise à l'avance encore par un admin).
Quoi qu'il en soit de ces filtres (+ ou -), l'Utilisateur invité (s'il n'a pas la connaissance d'une identité admin qui lui permettrait de s'autoriser) n'a aucun moyen d'affecter l'OS en place, et pas non plus de préserver des traces de son activité de session : documents ou fichiers de préférences. En effet, il ne bénéficie que d'un dossier de compte volatile créé ad hoc à l'ouverture de sa session dans le répertoire des /Users, et supprimé de ce répertoire à la fermeture de sa session avec tous ses contenus.
=> Comme, là encore, cet Utilisateur invité, quoique bénéficiant d'une liberté de manœuvre plus grande que l'invité dans le cas d'une activation de «FileVault», n'a aucune capacité d'intervention sur l'OS, et n'a pas non plus d'identité concrète susceptible de conservation, dans un compte qui se préserverait avec des contenus, mais n'est qu'un visiteur volatile dont les traces sont purgées après visite ; il est par conséquent logiquement absurde qu'un mot-de-passe puisse se trouver associé à cet Utilisateur en ouverture de session. Quel mot-de-passe, en effet, et comment ce n'importe qui susceptible de venir jouer les invités dans un compte d'Utilisateur invité en aurait-il a priori la connaissance ?
--------------------
Ayant brossé le contexte général, il semble que le problème initial renouvelé par bourdaud relève du second cas de figure. Je ne trouve qu'une interprétation : une absurdité logique est intervenue dans le fonctionnement du Système, associant par erreur le renseignement d'un mot-de-passe à l'identité de l'Utilisateur invité.
Essaie plusieurs fois de suite à Menu > Préférences Système > Utilisateurs et groupes de décocher la case "Autoriser les invités à se connecter à cet ordinateur" et de la recocher => cet acte graphique édite instantanément, dans la fichier d'identité /private/var/db/dslocal/nodes/Default/users/Guest.plist de l'Utilisateur invité, le couple clé-chaîne :
Bloc de code:
<key>passwd</key>
<array>
<string>********</string>
Bloc de code:
<key>passwd</key>
<array>
<string>*</string>=> Re-démarrer et vérifier si la session de l'Utilisateur invité s'ouvre sans mot-de-passe. Si ce n'était toujours pas le cas (signe que le facteur responsable n'est pas le codage du fichier Guest.plist), je ne vois pas d'autre issue que de démarrer par ⌘R sur la partition de récupération «Recovery HD» et d'activer l'option : "Ré-installer OS X" à destination du volume de l'OS : le Système sera restauré (dans la préservation des comptes d'utilisateurs avec leurs données et des applications tierces ajoutées avec leurs préférences) et on peut espérer alors que le dysfonctionnement sera corrigé...
[Note : un "panachage" est susceptible d'intervenir, si «FileVault» était activé et si un Utilisateur invité était "Autorisé à se connecter à l'ordinateur" après que le volume verrouillé par le chiffrement ait été déverrouillé et démarré.
Il y aurait alors un Utilisateur invité de première instance, seulement capable de se connecter à l'écran initial de déverrouillage pour lancer «Safari» dans une session de la «Recovery HD» ; et un Utilisateur invité de seconde instance, capable de se logger dans une session d'invité de l'OS à la seule condition qu'un utilisateur habilité à déverrouiller le volume chiffré de l'OS ait opéré au préalable ce déverrouillage en ouvrant sa session, puis ait fermé sa session sans éteindre le Mac, pour rendre disponible l'écran d'ouverture de session à des invités de l'OS.
Pourrait-on imaginer alors une bourde logique issue de la combinaison des contraintes du chiffrement et de la latitude de se connecter sans mot-de-passe de l'Utilisateur invité de seconde instance dès lors que le Volume de l'OS a été déverrouillé ? - de tels paramètrages dissonants pourraient très bien occasionner des bourdes logiques...
Pour ré-installer l'OS en cas d'activation de «FileVault», lancer au préalable l'«Utilitaire de Disque» dans la «Recovery HD» > Menu: Fichier > Déverrouiller afin de remonter le volume de l'OS et le rendre accessible à la restauration.]
Dernière édition par un modérateur:
Merci pour ta réponse.
Effectivement filevault n'est pas activé.
Le pb est résolu mais d'étrange façon.
J'ai désactivé l'ouverture de session automatique.
Au démarrage, en cliquant sur "invité" j'ai encore une demande de mot de passe.
Il me suffit de cliquer sur "administrateur" et de revenir sur "invité". Alors il n'y a plus de demande de mot
de passe et la session "invité" s'ouvre sans souci. Bizarre, non?
Effectivement filevault n'est pas activé.
Le pb est résolu mais d'étrange façon.
J'ai désactivé l'ouverture de session automatique.
Au démarrage, en cliquant sur "invité" j'ai encore une demande de mot de passe.
Il me suffit de cliquer sur "administrateur" et de revenir sur "invité". Alors il n'y a plus de demande de mot
de passe et la session "invité" s'ouvre sans souci. Bizarre, non?
M
Membre supprimé 1060554
Invité
Super-bizarre. Un dysfonctionnement dans le Système - peut-être réglable par une restauration (conservative des comptes).
Tu veux un autre contournement insolite ? Admise la condition paradoxale : "demande de mot-de-passe à la sélection de l'Utilisateur invité" => ton problème est que tu n'as pas à ta disposition un tel mot-de-passe à renseigner. Eh bien ! rien de plus facile que d'en créer un connu de toi pour ledit Utilisateur invité.
Va à : Applications/Utilitaires pour lancer le «Terminal». Dans la fenêtre qui s'ouvre, il te suffit de passer la commande suivante :
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ => l'utilitaire passwd (comme password en abrégé : utilitaire de mot-de-passe) est appelé, en mode root (sudo), sur la cible de l'utilisateur Guest (= nom de compte abrégé correspondant au nom complet : Utilisateur invité) => en retour, cette demande s'affiche :
=> il suffit de saisir à l'aveugle n'importe quel mot-de-passe, ne serait-ce qu'un simple appui sur la barre d'espacement, ou la lettre $ qui jouxte la touche "Entrée" pour la commodité, ou n'importe quel mot-de-passe farfelu (brol, toto etc.) et de valider => une demande de re-saisie du mot-de-passe s'affiche :
=> après saisie et validation, l'invite de commande se ré-affiche sans message de succès après une courte latence => désormais l'Utilisaeur invité a bien un mot-de-passe connu de toi pour sa session (pour autant qu'il soit activé).
Si le mot-de-passe choisi ne convenait plus, il suffit de repasser dans le «Terminal» la commande :
et de procéder da capo en choisissant un mot-de-passe modifié.
Pour se délivrer de ce mot-de-passe, il suffit dans le panneau des Préférences Système > Utilisateurs et groupes de décocher la case "Autoriser les invités à se connecter à cet ordinateur" (ce qui supprime le mot-de-passe de la fiche d'identité Guest.plist) puis de re-cocher la case pour réactiver l'Utilisateur invité => en situation régulière, aucun mot-de-passe n'est plus demandé à l'écran d'ouverture de session pour l'Utilisateur invité - dans ta situation atypique, tu devrais pouvoir récupérer ta manip : sélection de l'Administrateur > sélection de l'Utilisateur invité [à moins de que cette manipulation n'ait corrigé le dysfonctionnement]...
Tu veux un autre contournement insolite ? Admise la condition paradoxale : "demande de mot-de-passe à la sélection de l'Utilisateur invité" => ton problème est que tu n'as pas à ta disposition un tel mot-de-passe à renseigner. Eh bien ! rien de plus facile que d'en créer un connu de toi pour ledit Utilisateur invité.
Va à : Applications/Utilitaires pour lancer le «Terminal». Dans la fenêtre qui s'ouvre, il te suffit de passer la commande suivante :
Bloc de code:
sudo passwd Guest
Bloc de code:
Changing password for Guest.
New password:
Bloc de code:
Retype new password:Si le mot-de-passe choisi ne convenait plus, il suffit de repasser dans le «Terminal» la commande :
Bloc de code:
sudo passwd GuestPour se délivrer de ce mot-de-passe, il suffit dans le panneau des Préférences Système > Utilisateurs et groupes de décocher la case "Autoriser les invités à se connecter à cet ordinateur" (ce qui supprime le mot-de-passe de la fiche d'identité Guest.plist) puis de re-cocher la case pour réactiver l'Utilisateur invité => en situation régulière, aucun mot-de-passe n'est plus demandé à l'écran d'ouverture de session pour l'Utilisateur invité - dans ta situation atypique, tu devrais pouvoir récupérer ta manip : sélection de l'Administrateur > sélection de l'Utilisateur invité [à moins de que cette manipulation n'ait corrigé le dysfonctionnement]...
Sujets similaires
macOS Sonoma
Problème de mot de passe AD avec Sonoma 14.2.1
