¿Cuáles son los pasos necesarios para autenticar a los usuarios de un Active Directory que se ejecuta en Windows Server 2012 R2 en FreeBSD 10.0 sssdcon el backend AD con Kerberos TGT funcionando?

Hay algunas consideraciones difíciles para que todo funcione de forma inmediata. FreeBSD solo es compatible con la sssdversión 1.9.6 en este momento. Por lo tanto, no hay soporte para Enterprise Principal Names.

Si tiene un dominio con UPN no coincidentes, no podrá iniciar sesión, ya que la autenticación Kerberos fallará durante el proceso, incluso con FreeBSD que admite nombres principales de empresa con Kerberos, sssdno puede manejar este caso.

Entonces, en la versión real de sssdusted, está limitado a tener el Nombre principal del usuario dentro del mismo Nombre de dominio, por ejemplo:

Domain Name = example.com
NetBIOS Name = EXAMPLE
User Principal Name:
username@example.com sAMAccountName: username

Sabiendo esto, podemos describir los pasos para autenticar con éxito a los usuarios de AD en FreeBSD.

1. Configurar Kerberos

Cree el archivo /etc/krb5.confcon el siguiente contenido:

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = yes

2. Instale Samba 4.1 y configúrelo para unirse al dominio

Instale Samba 4.1:

$ pkg install samba41

Cree el archivo /usr/local/etc/smb4.confcon el siguiente contenido:

[global]
    security = ads
    realm = EXAMPLE.COM
    workgroup = EXAMPLE

    kerberos method = secrets and keytab

    client signing = yes
    client use spnego = yes
    log file = /var/log/samba/%m.log

Solicite un ticket Kerberos de administrador:

$ kinit Administrator

Luego únete al dominio y crea una tabla de claves

$ net ads join createupn=host/server-hostname.example.com@EXAMPLE.COM -k
$ net ads keytab create -k

3. Instale el paquete sssd y Cyrus SASL con soporte Kerberos

Instalar paquetes requeridos:

$ pkg install sssd cyrus-sasl-gssapi

Edite el archivo /usr/local/etc/sssd/sssd.confpara que coincida con esta configuración:

[sssd]
    config_file_version = 2
    services = nss, pam
    domains = example.com

[nss]

[pam]

[domain/example.com]
    # Uncomment if you need offline logins
    #cache_credentials = true

    id_provider = ad
    auth_provider = ad
    access_provider = ad
    chpass_provider = ad

    # Comment out if the users have the shell and home dir set on the AD side
    default_shell = /bin/tcsh
    fallback_homedir = /home/%u

    # Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
    #ldap_sasl_mech = GSSAPI
    #ldap_sasl_authid = SERVER-HOSTNAME$@EXAMPLE.COM

4. Agregue soporte sssd a nsswitch.conf

Edite el archivo /etc/nsswitch.confpara que coincida con esta configuración:

group: files sss
passwd: files sss

5. Configure PAM para permitir la autenticación sssd y manejar la creación del directorio de inicio

Instale paquetes opcionales para la creación del directorio de inicio:

$ pkg install pam_mkhomedir

Modifique los PAMreinos necesarios para que coincidan con esta configuración:

auth            sufficient      /usr/local/lib/pam_sss.so
account         required        /usr/local/lib/pam_sss.so        ignore_unknown_user
session         required        /usr/local/lib/pam_mkhomedir.so  mode=0700
session         optional        /usr/local/lib/pam_sss.so
password        sufficient      /usr/local/lib/pam_sss.so        use_authtok

6. Cambie al cliente OpenLDAP habilitado para SASL

$ pkg remove -f openldap-client
$ pkg install openldap-sasl-client

7. Finalmente confirme que todo está funcionando

$ getent passwd <username>

¿Qué Kerberos estás usando aquí? ¿El incorporado o seguridad / krb5 de MIT?

Al instalar sssd, requiere que se instale security / krb5, que en este momento todavía se considera experimental en FreeBSD. De ahí esta pregunta.

No tengo suerte de obtener los usuarios / grupos de AD al ejecutar comandos 'getent'. puede deberse al hecho de que el nombre NETBIOS difiere del nombre de dominio; en mi caso, el nombre de dominio es dawnsign.com y el nombre NETBIOS es DSP.

Configuré solo el módulo de inicio de sesión pam.d. ¿Qué otros módulos de pam deben editarse para que se realice una autenticación exitosa?

Cualquier información adicional sería muy apreciada!

Es posible volver a compilar samba4 desde los puertos para usar la autenticación winbind como linux incluso sin sssd. Simplemente recompile samba4 desde los puertos después de habilitar sasl ldap

    pkg remove samba41 
    pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb 
    pkg remove -f openldap-client 
    pkg install openldap-sasl-client 
    cd /usr/ports/security/sssd && make install

Esto recompilará samba con todo el soporte necesario (gssapi, ldap, kerberos) y luego editará nsswitch.conf de esta manera

passwd: files winbind
group: files winbind

Hola

Esta es una pequeña actualización sobre el uso de sssd v1.11.7

Si está utilizando el "id_provider = ad" y ve el siguiente error en el archivo de registro sssd:

/var/log/sssd/sssd_example.com.log
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-12)[Not Supported]
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error]

Puede usar el siguiente procedimiento para resolver este problema y hacer que la integración de AD funcione correctamente. Ahora compile sssd v1.11.7 con soporte Samba, se necesita compilar desde src sssd para que esté vinculado con libsasl2

​pkg remove samba41
pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb
pkg remove -f openldap-client
pkg install openldap-sasl-client
cd /usr/ports/security/sssd && make install

Aquí está mi guía sobre la integración de AD a través de SSSD con estas versiones de FreeBSD, en el momento de escribir este artículo (6/2017)

• FreeBSD 10.3 y 11.0 (10.3-RELEASE-p18 y 11.0-RELEASE-p9)

• Instalación (y los divertidos problemas de empaque y dependencia)

  • Los paquetes requeridos no parecen ser compatibles con Heimdal Kerberos, por lo que las cosas deben instalarse y compilarse con los indicadores MIT Kerberos habilitados. Es probable que esto sea más un problema de dependencia de empaque que un problema de compatibilidad real.
  • Heimdal se instala con el sistema base, por lo que esto le deja con dos conjuntos de comandos Kerberos si instala MIT Kerberos, uno configurado /usr/biny el otro dentro /usr/local/bin. Como ninguno de los archivos del sistema base parece estar en un paquete, no puede simplemente eliminar las cosas de Heimdal KRB. Algo a tener en cuenta.

  • Dependencias directas de los diversos paquetes (deps interesantes en negrita, deps en conflicto en negrita cursiva):

    • net-mgmt/adcli:net/openldap24-sasl-client
    • security/cyrus-sasl2-gssapi: security/cyrus-sasl2
    • net/openldap24-sasl-client: security/cyrus-sasl2
    • security/sssd: security/nss
    • security/sssd:security/krb5
    • security/sssd: security/cyrus-sasl2
    • security/sssd:net/openldap24-client
    • security/sssd: lang/python27
    • security/sssd: lang/python2
    • security/sssd: dns/c-ares
    • security/sssd: devel/tevent
    • security/sssd: devel/talloc
    • security/sssd: devel/popt
    • security/sssd: devel/pcre
    • security/sssd: devel/libunistring
    • security/sssd: devel/libinotify
    • security/sssd: devel/gettext-runtime
    • security/sssd: devel/ding-libs
    • security/sssd: devel/dbus
    • security/sssd: databases/tdb
    • security/sssd: databases/ldb

  • Dependencias inversas de los diversos paquetes:

    • net/openldap24-sasl-client: sysutils/msktutil
    • net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
    • net/openldap24-sasl-client: net-mgmt/adcli
      • Como vemos sssd, requiere el Kerberos MIT, a pesar de que tenemos a Heimdal como paquete base
      • adclideseos openldap-sasl-client, pero otros paquetes (incluyendo sub-dependencias de sssd) Tirando openldap-client, que es exclusión mutua con el cliente sasl (por la razón que sea tonto). Esto hace que la instalación sea un poco difícil, incluso con un conjunto mínimo de paquetes binarios.
      • Estas dependencias están presentes tanto para los paquetes de repositorios binarios como para los paquetes que se crean en el árbol de puertos. Esto requiere un método de instalación particular y molesto para obtener todo lo que necesitamos (cubierto a continuación).

  • Al momento de escribir esto, el paquete binario para SSSD para FreeBSD no incluye soporte AD en SSSD

    • La versión de los puertos de SSSD tuvo que ser construida con las opciones apropiadas (hacer config) habilitadas:
      • SMB
    • SSSD también quiere extraer openldap-client, cuando realmente necesita openldap-sasl-client para funcionar correctamente.
  • La versión binaria de pkg adcliexiste, pero al momento de escribir esto, no funciona.
    • Nuevamente, la versión de los puertos se compiló con las opciones adecuadas habilitadas:
      • GSSAPI_MIT
  • cyrus-sasl-gssapi es obligatorio, pero la versión binaria pkg no funciona y tiene problemas de dependencia extraños que hacen que elimine SSSD.
    • Compílelo desde los puertos con la opción MIT-KRB5 habilitada:
      • GSSAPI_MIT
  • openldap-sasl-client es necesario para la funcionalidad, pero SSSD quiere incorporar la versión no SASL de openldap.
    • Para que esto funcione
      • configurar openldap-sasl-clientcon la GSSAPIopción seleccionada ( make config) en los puertos.
      • Haz el make en los puertos para construirlo
      • Antes de realizar la instalación, haga un pkg remove –f openldap-client
        • Esto se eliminará openldap-clientsin realizar ningún movimiento automático de ningún otro paquete (como SSSD) y permitirá la instalación de la versión SASL
      • Realice una instalación para openldap-sasl-client
        • Esto lo instalará en el sistema
  • Esto proporcionará lo que se necesita para un SSSD funcional con capacidades AD.
  • Tenga en cuenta que si compila SSSD desde los puertos, obtendrá MUCHAS dependencias, lo que hará que se creen y requerirá que se elijan las opciones de configuración.
    • Se sugiere instalar primero el paquete binario con pkg install sssd y luego eliminarlo con pkg remove –f sssd
      • Esto provocará que los paquetes binarios para la mayoría de las cosas en las que SSSD necesita ser introducido, y elimine la necesidad de construir todo esto depende de los puertos, lo que lleva bastante tiempo.
    • Una vez eliminado, reinstale SSSD desde los puertos con las opciones mencionadas anteriormente habilitadas y solo necesitará reconstruir los cuatro paquetes mencionados anteriormente para obtener una configuración que funcione.

  • (Opcional) Una vez que todo esté funcionando y verificado, puede usarlo pkg createpara crear paquetes binarios de los cuatro paquetes con las opciones adecuadas habilitadas y usarlas en lugar de construirlas en puertos en cada sistema. La instalación de binarios sigue un patrón similar al proceso de compilación de puertos:

    • pkg install sssd-1.11.7_8.txz
      • Su versión puede ser diferente, por supuesto.
      • Esto instalará el paquete binario para SSSD y extraerá todo lo que necesita del repositorio de FreeBSD.
    • pkg add los otros paquetes (no instalar, agregar), guardando el paquete openldap para el final.
    • Antes de agregar openldap-sasl-clienthacer unpkg remove –f openldap-client
      • Esto elimina la versión no SASL y permite instalar nuestra versión
    • pkg add openldap-sasl-client-2.4.44.txz
      • De nuevo, su versión puede ser diferente
    • Deberías terminar con los paquetes necesarios instalados.
    • Se puede ser posible cambiar los metadatos para el binario SSSD antes de hacer la pkg createde sustituir la dependencia openldap-clientcon el openldap-sasl-clientde eliminar la necesidad de hacer esto remove / reinstalación. No he tenido tiempo de mirar para hacer esto.
      • Además, hay dependencias secundarias de SSSD que también se incorporan openldap-client, por lo que también debería corregirlas.
    • Tenga en cuenta que todas estas notas corresponden a las versiones de estos paquetes que se encuentran actualmente en el árbol de puertos a partir de este escrito , y las dependencias que han asociado con ellos. Todo esto puede cambiar a medida que FreeBSD actualice el árbol de puertos y los binarios. Tal vez algún día tengamos una versión binaria de todo lo que extrae todas las dependencias correctas con las opciones adecuadas configuradas para la funcionalidad AD de inmediato.

  • Configuración de Kerberos:

    • Archivo /etc/krb5.conf de muestra:

[libdefaults]
   default_realm = MYDOMAIN.NET
   reenviable = verdadero
# Normalmente todo lo que necesita en un entorno AD, ya que DNS SRV registra
# identificará los servidores / servicios AD / KRB. Comenta si
# desea apuntar manualmente a su servidor AD
dns_lookup_kdc = verdadero
[reinos]
   MYDOMAIN.NET = {
# Si está apuntando manualmente a un servidor AD diferente al que está en DNS
# admin_server = adserver.mydomain.net
# kdc = adserver.mydomain.net
   }
[dominio_dominio]
   mydomain.net = MYDOMAIN.NET
   .midominio.net = MYDOMAIN.NET

• (sangrar)
  • Configuración SSSD:
    • Este ejemplo presupone atributos POSIX en AD para usuarios y grupos, generalmente necesarios para cuando uno está reemplazando un entorno existente que ya tiene UID y GID establecidos.
    • Archivo /usr/local/etc/sssd/sssd.conf de muestra:

[sssd]
config_file_version = 2
dominios = MYDOMAIN.NET
servicios = nss, pam, pac
fallback_homedir = / home /% u

[dominio / MYDOMAIN.NET]
id_provider = anuncio
access_provider = anuncio
auth_provider = anuncio
chpass_provider = anuncio
# use los atributos de AD POSIX, comente si está usando automáticamente
# UID y GID.
ldap_id_mapping = False
cache_credentials = true
ad_server = adserver.mydomain.net
# si no tiene bash, o lo que sea que esté en el inicio de sesión de la cuenta AD
# atributo instalado
override_shell = / bin / tcsh

• (sangrar)
  • Configuración PAM:
    • La configuración de PAM en FreeBSD es un poco complicada debido a la forma en que funciona OpenPAM. No entraré en detalles, pero para usar pam_sss para SSSD y hacer que funcione, y también para que los inicios de sesión de passwd funcionen, debe poner pam_unix en el archivo dos veces. Por lo que entiendo, esto tiene que ver con una verificación secundaria que se realiza "detrás de escena" que requiere que pase el segundo módulo pam_unix.
      • Aquí está la lista de los /etc/pam.darchivos que he tenido que modificar para que SSSD funcione con FreeBSD:

/etc/pam.d/sshd:

# #
# $ FreeBSD: releng / 11.0 / etc / pam.d / sshd 197769 05-10-2009 09: 28: 54Z des $
# #
# Configuración de PAM para el servicio "sshd"
# #

# auth
autenticación suficiente pam_opie.so no_warn no_fake_prompts
auth requisito pam_opieaccess.so no_warn allow_local
#auth suficiente pam_krb5.so no_warn try_first_pass
#auth suficiente pam_ssh.so no_warn try_first_pass
auth suficiente pam_unix.so no_warn try_first_pass nullok
auth suficiente pam_sss.so use_first_pass
se requiere autenticación pam_unix.so no_warn use_first_pass

# cuenta
cuenta requerida pam_nologin.so
#account required pam_krb5.so
cuenta requerida pam_login_access.so
cuenta requerida pam_unix.so
cuenta suficiente pam_sss.so

# sesión
#session opcional pam_ssh.so want_agent
sesión opcional pam_sss.so
se requiere sesión pam_mkhomedir.so mode = 0700
se requiere sesión pam_permit.so

# contraseña
# contraseña suficiente pam_krb5.so no_warn try_first_pass
# contraseña suficiente pam_unix.so try_first_pass use_authtok nullok
contraseña suficiente pam_unix.so try_first_pass use_authtok
contraseña suficiente pam_sss.so use_authtok

/etc/pam.d/system:

# #
# $ FreeBSD: releng / 11.0 / etc / pam.d / system 197769 05-10-2009 09: 28: 54Z des $
# #
# Valores predeterminados de todo el sistema
# #

# auth
autenticación suficiente pam_opie.so no_warn no_fake_prompts
auth requisito pam_opieaccess.so no_warn allow_local
#auth suficiente pam_krb5.so no_warn try_first_pass
#auth suficiente pam_ssh.so no_warn try_first_pass
#auth required pam_unix.so no_warn try_first_pass nullok
auth suficiente pam_unix.so no_warn try_first_pass
auth suficiente pam_sss.so use_first_pass
se requiere autenticación pam_deny.so

# cuenta
#account required pam_krb5.so
cuenta requerida pam_login_access.so
cuenta requerida pam_unix.so
cuenta suficiente pam_sss.so

# sesión
#session opcional pam_ssh.so want_agent
se requiere sesión pam_lastlog.so no_fail
sesión opcional pam_sss.so
se requiere sesión pam_mkhomedir.so mode = 0700

# contraseña
# contraseña suficiente pam_krb5.so no_warn try_first_pass
# contraseña requerida pam_unix.so no_warn try_first_pass
contraseña suficiente pam_unix.so no_warn try_first_pass nullok use_authtok
contraseña suficiente pam_sss.so use_authtok
# contraseña requerida pam_deny.so

/etc/pam.d/su:

# #
# $ FreeBSD: releng / 11.0 / etc / pam.d / su 219663 15/03/2011 10: 13: 35Z des $
# #
# Configuración de PAM para el servicio "su"
# #

# auth
auth suficiente pam_rootok.so no_warn
auth suficiente pam_self.so no_warn
auth requisito pam_group.so no_warn group = rueda root_only fail_safe ruser
auth include system.dist

# cuenta
cuenta incluye system.dist

# sesión
se requiere sesión pam_permit.so

• (sangrar)

  • Notas:
    • system.distes una copia del /etc/pam.d/systemarchivo de stock . Se incluye en el /etc/pam.d/suarchivo anterior para evitar problemas con el comando su.
    • Uno todavía puede suagregar cuentas AD como root, ya que una vez que es root, suno necesita autenticarse y la información de la cuenta se extrae mediante el cambio del servicio de nombres a través de SSSD.
    • Si realmente desea cambiar de un usuario (no root) a un usuario diferente, debe usarlo solo sudopor razones de seguridad
    • También puede usar ksuy eso funciona para cambiar del usuario A al usuario B
      • Heimdal's ksu(in /usr/bin) no tiene SUID configurado por defecto
        • Para que Heimdal ksufuncione,chmod u+s /usr/bin/ksu
      • MIT Kerberos ( krb5paquete instalado en /usr/local/bin) es SUID en la instalación
    • Como Heimdal es parte del paquete base, tendrá ambos conjuntos de binarios Kerberos.
      • Es posible que desee ajustar las rutas predeterminadas para que /usr/local/binsea ​​anterior /usr/bin, etc.
    • ksu le pedirá al usuario la contraseña AD / Kerberos del usuario objetivo
    • passwdno funcionará para cambiar su contraseña de AD / Kerberos incluso si agrega pam_sss.soal archivo PAM passwd. El passwdbinario solo admite el uso local y NIS kpasswdpara cambiar su contraseña en los servidores AD / Kerberos.

  • Interruptor de servicio de nombres:

    • El /etc/nsswitch.confarchivo debe configurarse para usar el servicio sss para passwd y grupos. Ejemplo:
      • group: files sss
      • passwd: files sss

  • Unirse a un dominio:

    • Hay dos herramientas principales en * nixs para unirse a su caja de linux
      • adcli
        • Esta es mi herramienta preferida. Funciona muy bien y todo se puede hacer en una sola línea de comando. Las credenciales se pueden proporcionar de forma no interactiva (a través de stdin, etc.)
        • No requiere hacer kinitantes de usar, lo hace por usted en función de los créditos proporcionados.
          • Ejemplo:
            • adcli join -D mydomain.net -U Administrator--show-details –v
            • adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
              • Se recomienda este formulario ya que la utilidad no siempre determina el FQDN correctamente. Cuando proporciona el FQDN que coincide con el DNS directo e inverso para el host, los principios se crean correctamente. Si la utilidad utiliza un nombre de host incorrecto (por ejemplo, sin incluir el dominio DNS), no se crearán algunos principales de servicio y pueden fallar cosas como SSH en el host.
      • netUtilidad Samba
        • La netutilidad es parte de la suite Samba.
        • Esta utilidad requiere que los detalles del dominio se configuren en el smb.confarchivo de configuración, lo que hace que su uso sea más difícil e inconveniente, especialmente de forma no interactiva.
        • Esta herramienta también requiere que obtenga un ticket de Kerberos antes de usarlo kinit. Nuevamente, esto es más inconveniente y hace que sea un poco más difícil de usar de manera no interactiva en un script, ya que hay dos pasos en lugar de uno.
          

  • Consideraciones de SSHD:

    • Hacer que SSHD funcione con AD y SSSD suele ser bastante simple
    • Las siguientes opciones deben agregarse a /etc/ssh/sshd_config
      • GSSAPIAuthentication yes
        • Active la autenticación GSS API para SSHD. Esto hará que SSHD se autentique contra AD KDC
      • PasswordAuthentication yes
        • Permitir a los usuarios iniciar sesión con contraseñas. Se requiere si desea que un usuario obtenga un ticket KRB5 al iniciar sesión. Sin esto habilitado, el sistema no puede descifrar el TGT enviado por el KDC.
      • ChallengeResponseAuthentication yes
        • Para FreeBSD, este método parece funcionar mejor.
          • Asegúrese de configurar PasswordAuthentication nocuando use esta opción.
          • Este es el único método que he encontrado para FreeBSD que funciona para cambiar una contraseña caducada al iniciar sesión. Si usa el otro, llama /bin/passwd, que no admite nada más que NIS y el archivo passwd local.
      • GSSAPICleanupCredentials yes
        • (opcional) Hará un kdestroyal cerrar sesión
      • GSSAPIStrictAcceptorCheck no
        • (opcional) Esta opción a menudo se requiere si SSHD está confundido acerca de su propio nombre de host, o es multihomed, etc., o de otra manera usa un principal de servicio diferente para comunicarse con el KDC. Normalmente, SSHD usará el principal de servicio host/<FQDN>@REALMpara hablar con el KDC, pero a veces se equivoca (por ejemplo, si el nombre de host no coincide con el nombre DNS del servidor SSH). Esta opción permite que SSHD use cualquier entidad principal en el /etc/krb5.keytabarchivo, que incluye el correctohost/<FQDN>@REALM
    • Dependiendo de la combinación de opciones que use, es posible que necesite o no agregar principales de host al KDC para que las direcciones IPv4 e IPv6 de su host ssh -K <ip>funcionen sin solicitar una contraseña (suponiendo que ya haya hecho un 'kinit', por supuesto).