10.11 El Capitan "CommCenter veut utiliser le trousseau de session"

Ma Dalton

Membre expert
4 Avril 2015
1 284
273
68
Bonjour à tous,

petit "dépannage" dans la famille aujourd'hui, pour résoudre un problème de demande incessante de mots de passe après l'ouverture de session.

Après avoir modifié le mot de passe du trousseau de session pour qu'il soit identique au mot de passe de session, le problème est réglé, à UNE exception près :

Après chaque ouverture de session, une fenêtre surgit avec le message :

"CommCenter veut utiliser le trousseau de session"

Le mot de passe est accepté sans problème, et n'est plus redemandé ensuite, jusqu'à la prochaine ouverture de session, où il demandé à nouveau.

Qu'est exactement CommCenter, et comment faire pour se débarrasser de cette demande de mot de passe ?

D'avance merci.

(Macbook Pro Retina sous 10.11.6, FileVault est activé).
 
Dernière édition:
:coucou: Ma

J'ai quelques informations concernant ta première question :
Qu'est exactement CommCenter

Après recherche > je me suis avisé que CommCenter est un fichier exécutable recelé dans le paquetage d'un framework de la bibliothèque du Système :
Bloc de code:
/System/Library/Frameworks/CoreTelephony.framework/Support/CommCenter

Cet exécutable a un comparse à la même localisation :
Bloc de code:
/System/Library/Frameworks/CoreTelephony.framework/Support/CommCenterRootHelper

Enfin > les processus correspondants sont manifestement activés au démarrage du système respectivement par un LaunchAgent :
Bloc de code:
/System/Library/LaunchAgents/com.apple.CommCenter-osx.plist
et par un LaunchDaemon :
Bloc de code:
/System/Library/LaunchDaemons/com.apple.CommCenterRootHelper.plist

Ça a donc à voir avec le téléphone - mais je n'en sais pas plus.

Je pense que ce sont ces ressources qui conduisent, à chaque ouverture de session, à la requête d'un mot-de-passe pour utiliser le trousseau. Pourquoi ? - peut-être que l'édition du mot-de-passe du Trousseau de session pour le re-synchroniser avec le mot-de-passe d'ouverture de session > n'a pas été avalée par CommCenter.

Est-ce que le trousseau des Éléments locaux est bien déverrouillé lui aussi (car synchronisé également avec le nouveau mot-de-passe ?) --> regarde si le cadenas est ouvert ou non. S'il ne l'était pas > ce serait peut-être la raison. Dans ce cas > regarde dans ce fil : ☞déverrouillage éléments locaux demandé après changement de mot de passe☜ la fine astuce de jimbo.

Si c'était seulement une affaire de trousseau de session > à part récidiver l'édition du mot-de-passe - je n'ai pas d'idée.
 
Bonjour,

merci pour vos réponses.

Pas de logiciel de téléphonie, on parle ici d'un élément qui fait partie de l'OS (comme on peut le vérifier avec EasyFind sur un OS fraîchement installé).

Le trousseau "Eléments locaux" est bien déverrouillé, mais CommCenter demande le mot de passe du trousseau de session, pas celui des éléments locaux.

La réinitialisation du trousseau est exclue pour le moment (machine pro).
 
Bonsoir,

Problème résolu. CommCenter n’était pas en cause.

Rappel du problème : après chaque démarrage de la machine, puis ouverture de la session, un fenêtre annonçait :

"CommCenter veut utiliser le trousseau VAL"

et non pas le trousseau "de session", comme annoncé à tort dans le titre du sujet.

Le dépannage se faisant à distance, je n’avais pas vu l’application Trousseaux d’accès ouverte et n’avais pas compris la situation.

Je vais essayer d’exposer clairement le problème, puis la façon de le régler, y compris les "à-côtés" (précautions prises).
Ceci pour permettre à quelqu’un confronté au même problème d’avoir une solution facile à appliquer, en toute sécurité.
Il est possible qu'une autre solution existe, mais je ne l'ai pas trouvée malgré quelques recherches.

J’ai d’abord recréé, puis résolu le problème sur une machine dédiée aux tests.

Sur la machine présentant le problème, j’ai :

- mis à jour le clone fait avec Carbon Copy Cloner
- ajouté Trousseaux d’accès aux éléments se lançant à l’ouverture de session, de façon à voir Trousseaux ouvert dès l’ouverture de session.
- placé le dossier Keychains (~/Library/Keychains) dans la barre latérale du Finder pour un accès facile.
- fait une copie de Keychains sur le bureau (très important, en cas d’embrouille par la suite)

Affichage dans Trousseaux après boot et login :

Trousseaux :
VAL (verrouillé), 900 éléments
session (déverrouillé), vide


"VAL" en gras indique que c’est le "trousseau par défaut"
Il contient tous les éléments utilisés par cette session
Il est verrouillé après l’ouverture de la session

"session" est déverrouillé après l’ouverture de la session, mais vide.

Le pop-up "CommCenter veut utiliser le trousseau VAL" surgit et demande l’ouverture du trousseau VAL.
Après saisie du mot de passe, le trousseau VAL est déverrouillé, et la machine fonctionne tout à fait normalement.

On vérifie que les deux trousseaux peuvent être verrouillés/déverrouillés avec le même mot de passe, qui est celui de la session.
(sélectionner le trousseau, fermer puis ouvrir le cadenas)

Quel est le problème ?

Lors de l’ouverture de la session après boot, seul le trousseau nommé "login" est automatiquement déverrouillé.
Comme il est vide, et que tous les process utilisent des éléments stockés dans "VAL", un premier process (CommCenter en l’occurence) demande l’ouverture du trousseau VAL.
Une fois le mot de passe saisi, le trousseau est ouvert et peut être utilisé par tous les autres process ou applications.

Il n’est pas possible (à ma connaissance, et hors solution geeky) d’obtenir automatiquement à l’ouverture de session le déverrouillage d’un autre trousseau que celui nommé "session" ("login.keychain" dans ~/Library/Keychains).

Pour régler le problème, il faut atteindre l’objectif suivant : les 900 éléments qui composent le trousseau doivent être dans le trousseau "session" et non pas dans "VAL".
On peut imaginer de glisser, ou copier coller, les 900 éléments du trousseau "VAL" vers le trousseau "session", mais on se heurte à des demandes incessantes de mot de passe, donc en pratique ce n’est pas faisable.

La solution adoptée est de renommer le trousseau "VAL" en "login" et inversement :

Dans ~/Library/Keychains :
- renommer "VAL" en "login"
- renommer "login" en "VAL"

Reboot

A l’ouverture de session, Trousseaux affiche :

Trousseaux :
VAL (verrouillé), vide
session (déverrouillé), 900 éléments


Il reste à définir "session" comme trousseau par défaut (clic droit sur le trousseau, "désigner comme trousseau par défaut").

Reboot

A l’ouverture de session, Trousseaux affiche :

Trousseaux :
VAL (verrouillé), vide
session (déverrouillé), 900 éléments


"session" est en gras donc trousseau par défaut, aucun pop-up ne surgit pour demander une ouverture de trousseau.

On peut, depuis Trousseaux d'accès, supprimer "VAL" devenu inutile (clic droit, supprimer).

Le problème est réglé.

NB : je ne connais pas le pourquoi de la situation de départ (conséquence d'une migration, copie manuelle d'un "val.keychain" dans le dossier Keychains ?)
CommCenter est un process dépendant de Messages, et concerne la communication iPhone-Mac.
Si on neutralise ce process, c'est un autre qui demandait l'ouverture du trousseau VAL, si on neutralisait cet autre, c'était un troisième, etc...
Le problème n'était pas CommCenter mais le fait que le trousseau "actif" n'était pas déverrouillé à l'ouverture de session car nommé "VAL" et non pas "login".
 
Dernière édition:
Et ce n'était pas possible d'utiliser le Menu "Fichier/Importer des éléments" pour les intégrer dans dans "session" ?
 
J'ai tenté, mais j'avais plein de demandes de mot de passe de la part de process inconnus de moi, donc je n'ai pas insisté.
 
J'ai tenté, mais j'avais plein de demandes de mot de passe de la part de process inconnus de moi, donc je n'ai pas insisté.
Ok, je pensais qu'il suffisait de sélectionner le trousseau que l'on voulait importer, mettre le MdP du trousseau et basta.

Donc, ce n'est pas aussi simple.

Merci pour la solution !
 
:coucou: Ma

Bel exposé : précis et développé (car comme disait Kant : « beaucoup d'écrits seraient beaucoup plus courts [à suivre], s'il n'étaient pas si courts [en écritu-
re] »)
. Je n'ai jamais scruté en profondeur les finesses de fonctionnement de l'application «Trousseaux d'accès.app» (Keychain Access.app) > aussi ai-je été d'autant plus intéressé par ton compte-rendu.

Donc il y avait 2 fichiers de trousseaux d'utilisateur at: ~/Library/Keychains : un login.keychain & un VAL.keychain.

Dans l'interface de l'application ouverte «Trousseaux d'accès.app» > à l'ouverture de session > le trousseau « Session » (qui était vide) apparaissait déverrouillé et affiché en corps de police normal > le trousseau « VAL » (qui était rempli) apparaissait verrouillé et affiché en gras.

Dans ce contexte > la requête d'accès à un trousseau du processus « CommCenter » > voulait seulement dire que « CommCenter » était le 1er processus à avoir besoin du trousseau VAL verrouillé qui se trouvait lancé à l'ouverture de session. La saisie du mot-de-passe ad-hoc dans la fenêtre de requête > déverrouillait le trousseau VAL pour toute la durée de la session > ce qui fait que tous les autres processus ayant besoin du trousseau VAL trouvaient donc la porte ouverte.

L'affichage d'un trousseau en gras signifie que ce trousseau est défini comme le trousseau par défaut. Le sens de cette définition est : fichier de référence automatique pour tous les processus d'applications relevant de l'utilisateur dont la session est ouverte. Le trousseau par défaut (des processus axés utilisateur) peut ainsi ne pas être le trousseau Session > mais un autre (ici : VAL).

Le trousseau « Session » est l'affichage du fichier login.keychain. Son sens exclusif est : trousseau synchronisé avec le mot-de-passe d'ouverture de session de l'utilisateur > et s'ouvrant automatiquement avec la session (d'où l'intitulé : « login »). Seul ce trousseau « Session » se déverrouille automatiquement à l'ouverture de session - quel que soit son contenu. 2 trousseaux utilisateurs ne peuvent pas se déverrouiller simultanément à l'ouverture de session - quand bien même leurs mots-de-passe seraient-ils le même que celui d'ouverture de session.

La cas de figure peu courant d'un trousseau par défaut (pour les applications) différent du trousseau de Session > càd. d'un trousseau par défaut qui ne sera pas déverrouillé automatiquement à l'ouverture de session > finalement se comprend comme un cran de sûreté supérieur pour un maniaque de la sécurité : à savoir --> ce fichier de trousseau qui recèle tel et tel mot-de-passe d'applications spécialisées > ou encore des certificats spéciaux > n'est jamais déverrouillé automatiquement > mais uniquement pour un usage sélectif en cours de session.

Le problème ici est que cette différenciation des trousseaux : « Session / par défaut » > ne faisait pas sens mais problème : c'était un accident perturbateur. Le mécanisme exact ayant conduit à cet état de choses ? - Bof ! un de ces micmacs dont les utilisateurs ont le secret et qu'il vaut mieux souvent ne pas chercher à reconstituer à tout prix dans le détail sous peine de prise de tête aggravée
361608_original.png
...

Je prends en note ton procédé (simple & drastique) de résolution du micmac : renommer le fichier de trousseau par défaut VAL.keychain > en login.keychain et hop ! passez muscades. Eh oui ! bien vu : car il suffit que dans le sous-dossier ~/Library/Keychains > un fichier de trousseau soit intitulé stricto sensu : login.keychain > pour qu'il soit identifié à : « trousseau Session à déverrouiller automatiquement à l'ouverture de session ». Pourvu qu'il n'y ait pas de carabistouille de mot-de-passe > ça passe donc comme une lettre à la poste.

[NB. Je viens de m'aviser que l'utilitaire appelable dans le «Terminal» pour manipuler les préférences de Trousseau est : security. Au cas où des manipulations expérimentales me découvriraient quelques trucs bons à savoir > je reviendrai en faire part dans ton fil.]
 
Dernière édition par un modérateur:
moi dans mon trousseau j'avais 2 session (orthographe identique), du coup j'ai copié tout de l'un à l'autre, et j'ai rentré a chaque fois mon code trousseau à la mano
puis suppression de celui que j'ai vidé et nickel mais long