Tenemos servidores AIX y Linux ejecutándose con autenticación de contraseña básica contra un AD de Windows usando Kerberos, por lo que son usuarios locales con un nombre de usuario idéntico a su sAMAccountName en el AD y todo lo que se hace es verificar la contraseña.
Ambos sistemas operativos utilizan un krb5.conf simple
[libdefaults]
default_realm = COMPANYA.COM
[realms]
COMPANYA.COM {
kdc = ad.companya.com:88
admin_server = ad.companya.com:749
}
[domain_realm]
.companya.com = COMPANYA.COM
companya.com = COMPANYA.COM
Esto funciona bien en ambos sistemas operativos.
Ahora nos encontramos en la situación de que habrá una empresa B y, por tanto, también una segunda AD. Un usuario nunca estará disponible en ambos AD, solo en cualquiera de ellos.
Entonces comencé con AIX porque pensé que sería lo más difícil de hacer funcionar.
Se actualizó krb5.conf.
[libdefaults]
default_realm = COMPANYA.COM
[realms]
COMPANYA.COM {
kdc = ad.companya.com:88
admin_server = ad.companya.com:749
}
COMPANYB.COM {
kdc = ad.companyb.com:88
admin_server = ad.companyb.com:749
}
[domain_realm]
.companya.com = COMPANYA.COM
companya.com = COMPANYA.COM
.companyb.com = COMPANYB.COM
companyb.com = COMPANYB.COM
Después de investigar un poco, parecía que todo lo que tenía que hacer era
chuser auth_domain=COMPANYB.COM <user>
esto actualiza el archivo /etc/security/user y validará la contraseña contra el AD de la Compañía B. Así que me sorprendió gratamente lo fácil que fue.
Luego vino Linux (cajas Ubuntu). Hice lo mismo krb5.conf pero lamentablemente no puedo encontrar el comando equivalente para chuser en Ubuntu para señalar a ese usuario específico al otro AD.
Lo que puedo encontrar son páginas sobre el uso de sssd y cómo unirse al reino (Linux SSSD con dos dominios ADy/ohttps://ubuntu.com/server/docs/service-sssd-ad) pero todo esto es más que necesario (unirse a los reinos).
Lo que descubrí hasta ahora usando tcpdump y kinit es lo siguiente:
kinit [email protected]
<password>
kinit: KDC reply did not match expectations while getting initial credentials
kinit [email protected]
<password>
<no error>
login [email protected]
<password>
access denied
login [email protected]
<password>
access denied
Dado que kinit con mayúsculas completas funcionaba, sospechaba que el inicio de sesión funcionaría, lamentablemente no fue así.
actualización: iniciar sesión[correo electrónico protegido]funciona si el usuario se crea en el cuadro de Linux como[correo electrónico protegido], todavía no estoy muy contento con eso
(olvidando el hecho de que no es realista pedir a los usuarios que escriban su dominio en mayúsculas)
En pocas palabras, cómo señalar a usuarios específicos a otro AD distinto al predeterminado en el archivo krb5.conf.
Saludos,
Respuesta1
Bueno, avancé un poco más la semana pasada y esto parece funcionar. Aunque todavía estoy investigando los detalles exactos de cómo funciona PAM.
actualizó/cambió el /etc/pam.d/common-auth
original
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
nueva versión
auth sufficient pam_krb5.so minimum_uid=1000 realm=COMPANYA.COM
auth sufficient pam_krb5.so minimum_uid=1000 realm=COMPANYB.COM
auth sufficient pam_unix.so nullok try_first_pass
al iniciar sesión como usuario de la empresa A, verifica el AD de la empresa A y, dado que el usuario existe allí, se verifica la contraseña. al iniciar sesión como usuario de la empresa B, verifica el AD de la empresa A, el usuario no existe allí y luego va a verificar la empresa B y, como el usuario existe allí, se verifica la contraseña.
No es tan agradable como lo hace AIX, pero de todos modos funciona.
Saludos,