Problème entre Filevault et mot de passe de session

Novezan

Membre actif
30 Novembre 2010
160
6
Bonjour à tous,

J'ai un problème assez troublant concernant FileVault et mon mot de passe de session, j'ai bien eu à un moment (il y a quelques mois) l'aide du support Apple (téléphone et mail) mais j'ai été abandonné depuis malgré mes relances...

Tout d'abord voici ma config :
MacBook Pro Retina 13" debut 2015

Le problème est le suivant :
J'utilise avec mon compte (admin) un mot de passe avec des caractères spéciaux (@, #, -), d'ailleurs il débute par un caractère de ce type. Le problème est que si je chiffre mon disque avec FileVault, mon mot de passe ne fonctionne pas au démarrage, je suis obligé d'utiliser la clé de secours (FileVault) pour me connecter, et je dois donc réinitialiser mon mot de passe.
Si j'utilise un mot de passe sans caractère spéciaux pas de problème.
Si j'utilise des caractères spéciaux sans FileVault aucun problème également...
J'ai même fais une clean install du système avec destruction et (re)création de la partition Macintosh HD, c'est pareil.
Le support Apple m'a même changé mon MacBook Pro (pensant à un problème avec le SSD), sans résultat...
J'ai fais des tests sur un autre MacBook Pro et iMac (ceux de ma mère) et je n'ai aucun problème si je me crée un compte avec mon mot de passe habituel et FileVault Activé...

Si quelqu'un avait un début de solution...

Merci par avance
 
Ce n'est pas un probleme de configuration de clavier qui ferait que tu crois taper le caractère spécial mais c'est un autre caractère qui est saisi?
 
Ce n'est pas un probleme de configuration de clavier qui ferait que tu crois taper le caractère spécial mais c'est un autre caractère qui est saisi?

J'y ai pensé un moment, donc j'ai pris un modèle de clavier US sur google image pour faire le test, mais sans résultat...
 
Salut

Tu peux tenter depuis le terminal un :
sudo languagesetup
Ton mot de passe sera demandé.
 
Salut

Tu peux tenter depuis le terminal un :
sudo languagesetup
Ton mot de passe sera demandé.

Ok, je viens de choisir "2" pour valider le français.
Je vais faire un reboot (préventif)

EDIT : Je précise que j'ai configurer mon Mac avec le clavier "Français-numérique" uniquement
 
Dernière édition:
Je viens de lancer le chiffrement, et malheureusement çà ne fonctionne pas. J'ai du utiliser la clé de secours...
C'est quand même un truc de fou cette histoire
 
Il ne te reste plus qu'à modifier ton mot de passe (peut être ne pas le faire commencer par des caractères spéciaux).
Essayer d'ajouter les caractères spéciaux les uns après les autres, jusqu'à trouver celui qui pose problème.
 
Je viens de créer un deuxième compte admin avec un mot de passe contenant des caractères spéciaux, et j'ai le même problème...
Le pire, c'est quand il me demande de réinitialiser mon mot de passe, j'en saisi un tout simple du type tototiti et bien au redémarrage il ne l'accepte pas, je suis de nouveau obligé de saisir la clé de secours !!!
Bilan, je désactive FileVault...
Le pire c'est que sur mon bureau juste à côté de mon Mac à 1500€, j'ai un portable à 300€, avec une Debian installée et un disque chiffré avec un mot de passe de dingue, que dis je une phrase qui n'existe dans aucune langue et ça fonctionne à merveille...
Il est vrai que je dois saisir cette phrase à chaque reboot de la Debian, mais au moins ça fonctionne !!!
Existe t'il une alternative à cette merde de FileVault ?
 
Salut Novezan

Que le cas que tu soumets soit énervant d'un point de vue pratique - je le conçois aisément. Ce qui ne l'empêche pas d'être stimulant d'un point de vue théorique, comme toute « anomalie logique » posant un problème à l'intelligence. Autant te l'avouer tout de suite : je me suis fait « coller » autant que toi-même.

J'ai d'abord tenté de reproduire en pratique ton « anomalie logique ». En sus de mon compte admin macomaniac, j'ai créé un second utilisateur admin bob, avec un mot-de-passe incluant les 3 caractères spéciaux que tu cites : @b#o-b. Cela fait, j'ai lancé «FileVault» pour chiffrer le volume de mon OS, en accréditant macomaniac et bob à pouvoir déverrouiller le Volume Chiffré par leurs mots-de-passe respectifs que j'ai renseignés pour chacun. Eh bien ! je n'ai « malheureusement » (théoriquement parlant) pas réussi à reproduire ton échec : le mot de passe @b#o-b pour l'admin bob est parfaitement reconnu à l'écran de déverrouillage inaugural.

Ce qui m'a conduit à réfléchir au mécanisme de démarrage d'un OS chiffré par «FileVault». Pour qu'il puisse y avoir chiffrement du volume entier d'un OS, la condition sine qua non sur Mac est qu'un format CoreStorage soit mis-en-place sur la partition de l'OS en préalable au chiffrement. Ce format CoreStorage est un dispositif logique qui gère 2 « disques virtuels » superposés sur l'espace de la partition : un disque virtuel primaire, dit Physical Volume (Volume Physique) qui émule un disque dur à même l'espace de la partition ; un disque virtuel secondaire, dit Logical Volume (Volume Logique) qui monte à partir du disque virtuel du Volume Physique, et qui sert d'espace d'ancrage au système de fichiers JHFS+ de l'OS.

Les 2 « disques virtuels » (Volume Physique / Volume Logique) sont des espaces logiques congruents bloc à bloc. Quand il y a chiffrement, l'espace logique de blocs du Volume Physique est chiffré ; et un logiciel de "traduction" à la volée (utilisant un algorithme de déchiffrement) transpose l'espace de blocs chiffrés du Volume Physique en espace de blocs déchiffrés du Volume Logique. Le Volume Logique, pour autant qu'il soit monté, est donc toujours déchiffré. Comme donc le système de fichiers de l'OS qui s'y ancre.

À l'extinction de l'OS, le Volume Logique est démonté : ne reste présent que le Volume Physique Chiffré, qui ne permet aucun remontage automatique du Volume Logique Déchiffré. Il y a donc verrouillage, et seul le renseignement d'un mot-de-passe accrédité peut permettre, par déverrouillage, le remontage du Volume Logique en mode Déchiffré et par suite le démarrage de l'OS.

Ce qui a une conséquence drastique : lorsque «FileVault» est activé, le Mac ne peut absolument pas démarrer sur l'OS. Il faut bien pourtant qu'il démarre, logiciellement parlant, pour qu'un écran de déverrouillage soit proposé permettant de déverrouiller et de remonter le Volume Logique de l'OS.

Pour résoudre ce paradoxe, les ingénieurs de la  ont choisi de recourir au Système auxiliaire de la «Recovery HD». Car la partition de récupération «Recovery HD» recèle un Système démarrable strictement comparable (en abrégé) à celui d'OS X. Sans être chiffré, ni donc verrouillé, celui-là. On a donc affaire à un volume qui monte automatiquement et dont les ressources de démarrage sont accessibles.

L'EFI (le Programme Interne de la Carte-Mère), lorsque le volume de l'OS est chiffré et donc verrouillé au démarrage, va donc exécuter le boot_loader (chargeur) boot.efi de la «Recovery HD» en qualité de boot_loader exclusivement réservé au pré-boot de l'OS. Normalement, lorsqu'un boot.efi est exécuté par l'EFI, il lit le fichier d'instructions de boot collatéral com.apple.Boot.plist qui lui indique le chemin du cache de démarrage prelinkedkernel à charger, et quels flags de boot passer au kernel qu'il recèle. Bon : le boot.efi de la «Recovery HD», on ne lui demande plus ici de charger le prelinkedkernel du Système de récupération, car dans ce cas... c'est la «Recovery HD» qui se trouverait démarrée. Non : ce qu'on lui demande, c'est de permettre le déverrouillage du Volume Physique Chiffré et le remontage du Volume Logique Déchiffré en premier lieu, en préalable au démarrage de l'OS.

Il faut donc que le boot.efi de la «Recovery HD» ait à sa disposition des instructions de boot alternatives. Pour ce faire, lorsque «FileVault» est activé (et exclusivement dans ce cas de figure), un dossier spécial de pré-boot se trouve copié dans l'espace de la «Recovery HD» : le com.apple.boot.R (où R = root). Ce dossier comporte un dossier cache absolument spécifique : le EFILoginLocalizations recelant 11 fichiers-caches de type .efires (efi_resources) : appleLogo.efires, battery.efires, disk_passwordUI.efires, flag_picker.efires, guest_userUI.efires, loginui.efires, Lucida13.efires, Lucida13White.efires, preferences.efires, sound.efires & unknown_userUI.efires. Aucun doute : le boot_loader boot.efi se voit passer d'entrée le contenu cryptique de ces .efires, ce qui lui fait afficher l'écran de déverrouillage du volume chiffré en guise de procédure de pré-boot.

Lucida13.efires montre que c'est la police Lucida qui est utilisée. loginui.efires (login user_id) contient manifestement les critères d'identification des utilisateurs accrédités. Je conjecture que ta foirade intervient au niveau de ce fichier.

Le dossier complet de la «Recovery HD» : com.apple.boot.R/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations est mis-à-jour par recopie à partie du dossier paradigme dans l'OS at: /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations. Lequel contient le fichier paradigme : loginui.efires contenant les critères d'identification des utilisateurs accrédités.

Alors de 2 choses l'une : le fichier paradigme loginui.efires de l'OS ne donne-t-il pas lieu à une copie valide dans l'espace de ta «Recovery HD» pour jouer son rôle lors du pré-boot ? Ou bien est-ce le mécanisme de génération du fichier paradigme loginui.efires qui plante dans ton OS, avant toute recopie à la «Recovery HD» ? - Je n'arrive pas à concevoir ici pourquoi il y aurait une telle bavure de type logique, exclusivement sur ton Mac et exclusivement en cas de caractères spéciaux dans le mot-de-passe de l'utilisateur. Faudrait-il alors imputer la raison à un problème matériel (clavier ?), ce qui serait susceptible de singulariser ton Mac de tout autre ?

☞ Je serais toi, je pense que je demanderais le remplacement complet du Mac en AppleStore : c'est la conclusion que je tirerais de l'impossibilité de rendre raison logiquement de ce problème de login exclusivement avec ce Mac (faisant valoir que le chiffrement des données d'utilisateur, avec choix d'un mot-de-passe le plus sécurisé possible, donc impliquant l'usage de caractères spéciaux, est actuellement une question des plus sensible...) ☜
361608_original.png
 
Dernière édition par un modérateur:
Merci pour cette réponse TRÈS instructive.
Je vais donc appeler le support pour signaler ce problème, mon Mac à moins d'un an...
J'ai déjà eu un échange, mais le problème est toujours là...
Je tenterai bien une nouvelle installation, avec à nouveau destruction de la partition Macintosh HD puis reconstruction, pour repartir sainement, mais je dois avouer que je ne suis pas très optimiste
 
Le support Apple ne peut plus rien faire par téléphone, il me demande de me rapprocher d'un Apple Store ou d'un revendeur agréer...


Sent from my iPhone using Forums iGeneration mobile app
 
Un petit message pour vous dire que j'ai trouvé la solution, enfin non pas vraiment LA solution mais une solution que j'espère temporaire...
Au moment de saisir le mot de passe pour ouvrir ma session, il suffit d'activer le clavier US et de connaitre la correspondance des touches (a=q, z=w, @=shift2, etc...)

Ce qui est quand même étrange, c'est que j'ai besoin du clavier US que pour cette opération. une fois la session ouverte, plus de problème, le clavier FR Numérique fonctionne (heureusement). Il en est de même pour l'utilitaire de disque au démarrage (CMD+R), le clavier fonctionne bien en FR là aussi...

Je pense qu'il doit y avoir un bug avec les MacBook Pro Retina 13" début 2015 , si quelqu'un serait en mesure de tester ça pour faire avancer le Schmilblick ;-)

j'ai testé sans aucun problème avec :
- Le MacBook Pro Retina 15" Mid2015 (SSD 256)
- L'iMac 21,5" Mid 2014 option SSD 256)
 
Au moment de saisir le mot de passe pour ouvrir ma session, il suffit d'activer le clavier US et de connaitre la correspondance des touches (a=q, z=w, @=shift2, etc...)
Voir le message #2...
 
Si, mais pourquoi ?
parce que je pense qu'à ce stade du démarrage, seule la configuration US du clavier est prise en charge
Il faut donc taper le mot de passe (dont les caractères spéciaux) comme si on avait un clavier US
 
parce que je pense qu'à ce stade du démarrage, seule la configuration US du clavier est prise en charge
Il faut donc taper le mot de passe (dont les caractères spéciaux) comme si on avait un clavier US
Il me semblait que la commande du post #4 réglait ce problème.
 
parce que je pense qu'à ce stade du démarrage, seule la configuration US du clavier est prise en charge
Il faut donc taper le mot de passe (dont les caractères spéciaux) comme si on avait un clavier US

Mais pourquoi QUE sur mon MacBook Pro 13" ?

Edit 1 : et Pourquoi pas dans le menu du Mac ou l'on trouve entre autre l'utilitaire de disque Cmd+R au démarrage ?

Edit 2 : non seulement il faut taper les caractères comme avec un clavier qwerty, mais il faut SURTOUT basculer en clavier US sinon ça ne fonctionne pas