13 votos

¿Qué OS X mecanismos de autorización realmente?

De fondo

Estoy tratando de obtener una mejor comprensión de la OS X proceso de inicio de sesión, en orden a decidir la mejor manera para lograr VPN inicio De sesión Único.

Por favor me corrija si estoy equivocado, pero creo que—

  1. launchd(8) llamadas gettyent(3) y por lo tanto determina, a partir de ttys(5) de ejecución loginwindow.app para /dev/console.

  2. loginwindow.app el intento de adquirir la system.login.console autorización a la derecha, para que la autorización de la base de datos especifica los siguientes mecanismos (que aparece junto con mi comprensión de su función); los que tienen el privilegio de que se ejecute dentro de la authd proceso (como root), mientras que aquellos que no son privilegio de ejecutar dentro de la SecurityAgent proceso (como _securityagent):

    • builtin:policy-banner (muestra la Ventana de inicio de Sesión de banner, si está configurado).
    • loginwindow:login (pide las credenciales).
    • builtin:login-begin
    • builtin:reset-password,privileged (realiza de restablecimiento de contraseña utilizando el ID de Apple).
    • builtin:forward-login,privileged (adelante credenciales de EFI en el arranque).
    • builtin:auto-login,privileged (se aplica auto-credenciales de inicio de sesión en el arranque).
    • builtin:authenticate,privileged (invoca pam_authenticate(3) para authorization servicio; establece "uid" valor de contexto).
    • PKINITMechanism:auth,privileged (inicializa Kerberos mediante la obtención de un TGT).
    • builtin:login-success
    • loginwindow:success (fija el inicio de la sesión de acceso remoto no autorizado; registra el inicio de sesión en el sistema del utmp y utmpx bases de datos; establece el propietario y los permisos de la consola de terminal).
    • HomeDirMechanism:login,privileged (monta el directorio home del usuario).
    • HomeDirMechanism:status (muestra el progreso de directorio home de montaje).
    • MCXMechanism:login (se aplica perfiles de configuración).
    • loginwindow:done (restablece las preferencias del usuario para incluir los valores predeterminados del sistema; configura el ratón, el teclado y el sistema de sonido con las preferencias del usuario; establece el usuario permisos de grupo; recupera el registro de usuario de los Servicios de Directorio y aplica la información a la sesión; carga el entorno de ejecución del usuario—incluyendo preferencias, variables de entorno, el dispositivo y los permisos de archivos, acceso a llaveros, y así sucesivamente; lanza el Dock, el Finder, y SystemUIServer; lanzamientos de los elementos de inicio de sesión para el usuario).

Preguntas

Me gustaría mucho para confirmar mi comprensión de cada uno de los mecanismos de la función:

  1. Es su código fuente disponible públicamente? Yo sé que el no-builtin mecanismos definidos por los plugins que se pueden encontrar bajo /System/Library/CoreServices/SecurityAgentPlugins, pero no puedo encontrar la fuente de la que fueron construidos. No puedo encontrar donde el builtin mecanismos definidos.

  2. Si la fuente no está disponible, son los mecanismos documentados en cualquier lugar?

Observaciones

  1. ¿Cómo puede loginwindow:login pedir credenciales si se invoca antes de builtin:forward-login y builtin:auto-login, lo cual causa que la interfaz de usuario se omite? Hace inspeccionar el contexto de tales credenciales y saltar a sí mismo si están presentes? Parece extraño.

  2. Además, como se describe en Apple 802.1 X Autenticación técnico white paper:

    Cuando la Ventana de inicio de Sesión en Modo está configurado y tipos de usuario en un nombre de usuario y contraseña en la ventana de inicio de sesión, pueden suceder dos cosas. En primer lugar, la ventana de inicio de sesión va a autenticar el equipo a través de 802.1 X para la la red utilizando el nombre de usuario y contraseña introducida por el usuario. Después de la 802.1 X autenticación es correcta, la ventana de inicio de sesión para autenticar la el mismo nombre de usuario y contraseña para el directorio externo.

    Desde la segunda etapa de que la autenticación es manejado por el pam_opendirectory.so módulo y es dependiente de la red a la que se presente, la primera etapa (autenticación a través de 802.1 X para la red) necesariamente debe ocurrir antes de que. Es decir, debe producirse antes de la builtin:authenticate mecanismo.

    A partir de una inspección casual de la loginwindow plugin binario, parece que se ocupa de 802.1 X autenticación—pero el único mecanismo invocado dentro de ese plugin antes de la builtin:authenticate es loginwindow:login. Estoy en lo cierto al pensar que este mecanismo no sólo muestra el símbolo de inicio de sesión, pero luego también los intentos de 802.1 X autenticación? (Si es así, que no sólo parece un poco descuidado en mi humilde opinión, pero también sugiere que las credenciales de EFI/auto-inicio de sesión no puede ser utilizado para 802.1 X ventana de inicio de sesión de autenticación.)

1voto

Overmind Puntos 223
  1. De lo que recuerdo loginwindow:inicio de sesión se utiliza realmente en el desove de la interfaz de usuario ventana de inicio de sesión, similar a builtin:política-banner. Así que es lógico que se genera antes de que el resto de las acciones. De modo que la ventana de la GUI es la que en realidad es irrelevante/bypassable, no las credenciales a sí mismos.

  2. Lo que exactamente desea modificar y hacia qué fin ? Por ejemplo, si usted requiere la autorización plugin para ser invocada en otras situaciones, usted puede hacer que mediante la edición de auth.db.

También, builtin:autenticar a los sub-sistemas debe manejar la diferenciación entre 802.1 X y locales auth.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: