Contexte
J'essaie de glaner une meilleure compréhension du processus de connexion OS X, afin de décider de la meilleure façon de réaliser l' authentification unique VPN .
Veuillez me corriger si je me trompe, mais je crois que ...
launchd(8)
appellegettyent(3)
et détermine ainsi dettys(5)
à exécuterloginwindow.app
pour/dev/console
.loginwindow.app
tente d'acquérir lesystem.login.console
droit d'autorisation, pour lequel la base de données d'autorisation spécifie les mécanismes suivants (répertoriés avec ma compréhension de leur fonction); ceux qui sont privilégiés s'exécutent dans leauthd
processus (en tant que root), tandis que ceux qui ne sont pas privilégiés s'exécutent dans leSecurityAgent
processus (en tant que _securityagent):builtin:policy-banner
(affiche la bannière de la fenêtre de connexion , si définie).loginwindow:login
(demande des informations d'identification).builtin:login-begin
builtin:reset-password,privileged
(effectue la réinitialisation du mot de passe à l'aide de l'identifiant Apple ).builtin:forward-login,privileged
(transmet les informations d'identification d'EFI au démarrage).builtin:auto-login,privileged
(applique les informations d'identification de connexion automatique au démarrage).builtin:authenticate,privileged
(invoquepam_authenticate(3)
pour leauthorization
service; définit la valeur de contexte "uid").PKINITMechanism:auth,privileged
(initialise Kerberos en obtenant un TGT).builtin:login-success
loginwindow:success
(protège la session de connexion d'un accès distant non autorisé; enregistre la connexion dans les bases de données utmp et utmpx du système; définit le propriétaire et les autorisations pour le terminal de console).HomeDirMechanism:login,privileged
(monte le répertoire personnel de l'utilisateur).HomeDirMechanism:status
(affiche la progression du montage du répertoire personnel).MCXMechanism:login
(applique les profils de configuration).loginwindow:done
(réinitialise les préférences de l'utilisateur pour inclure les paramètres système par défaut; configure la souris, le clavier et le son du système à l'aide des préférences de l'utilisateur; définit les autorisations de groupe de l'utilisateur; récupère l'enregistrement utilisateur à partir des services d'annuaire et applique ces informations à la session; charge l'informatique de l'utilisateur environnement - y compris les préférences, les variables d'environnement, les autorisations de périphérique et de fichier, l'accès au trousseau, etc.; lance le Dock, le Finder et SystemUIServer; lance les éléments de connexion pour l'utilisateur).
Des questions
Je tiens à confirmer ma compréhension de la fonction de chaque mécanisme:
Leur code source est-il ouvertement disponible? Je sais que les non-
builtin
mécanismes sont définis par des plugins qui peuvent être trouvés sous/System/Library/CoreServices/SecurityAgentPlugins
, mais je ne trouve pas la source à partir de laquelle ils ont été construits. Je ne peux pas non plus trouver où lesbuiltin
mécanismes sont définis.Si la source n'est pas disponible, les mécanismes sont-ils documentés quelque part?
Observations
Comment peut-on
loginwindow:login
demander des informations d'identification si elle est invoquée avantbuiltin:forward-login
etbuiltin:auto-login
, l'une ou l'autre provoquant le contournement de l'interface graphique? Inspecte-t-il le contexte pour de telles informations d'identification et saute-t-il si elles sont présentes? Semble étrange.En outre, comme décrit dans le livre blanc technique sur l'authentification 802.1X d'Apple :
Lorsque le mode de fenêtre de connexion est configuré et qu'un utilisateur saisit un nom d'utilisateur et un mot de passe dans la fenêtre de connexion, deux choses se produisent. Tout d'abord, la fenêtre de connexion authentifiera l'ordinateur via 802.1X auprès du réseau en utilisant le nom d'utilisateur et le mot de passe que l'utilisateur a entrés. Une fois l'authentification 802.1X réussie, la fenêtre de connexion authentifiera le même nom d'utilisateur et le même mot de passe dans le répertoire externe.
Puisque la deuxième étape de cette authentification est gérée par le
pam_opendirectory.so
module et dépend de la présence du réseau, la première étape (authentification via 802.1X auprès du réseau) doit nécessairement avoir lieu avant cela. Autrement dit, il doit se produire avant lebuiltin:authenticate
mécanisme.D'après une inspection occasionnelle du
loginwindow
binaire du plugin, il semble qu'il gère une telle authentification 802.1X - mais le seul mécanisme invoqué dans ce plugin avantbuiltin:authenticate
estloginwindow:login
. Ai-je raison de penser que ce mécanisme affiche non seulement l'invite de connexion, mais tente également l'authentification 802.1X? (Si c'est le cas, cela semble non seulement un peu bâclé à mon humble avis, mais suggère également que les informations d'identification d'EFI / connexion automatique ne peuvent pas être utilisées pour l'authentification de la fenêtre de connexion 802.1X.)