Quelles sont les étapes requises pour authentifier les utilisateurs d'un Active Directory s'exécutant sur Windows Server 2012 R2 dans FreeBSD 10.0 en utilisant sssdle backend AD avec Kerberos TGT qui fonctionne?

Il y a quelques considérations délicates pour que tout fonctionne hors de la boîte. FreeBSD ne prend en charge que la sssdversion 1.9.6 pour le moment. Il n'y a donc pas de prise en charge pour les noms principaux d'entreprise.

Si vous avez un domaine avec des UPN non correspondants, il ne parviendra pas à se connecter, car l'authentification Kerberos échouera pendant le processus, même si FreeBSD prend en charge les noms principaux d'entreprise avec Kerberos, le sssdne peut pas gérer ce cas.

Ainsi, dans la version actuelle, sssdvous êtes limité à avoir le nom d'utilisateur principal dans le même nom de domaine, par exemple:

Domain Name = example.com
NetBIOS Name = EXAMPLE
User Principal Name:
[email protected] sAMAccountName: username

Sachant cela, nous pouvons décrire les étapes pour authentifier avec succès les utilisateurs d'AD dans FreeBSD.

1. Configurer Kerberos

Créez le fichier /etc/krb5.confavec le contenu suivant:

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

2. Installez Samba 4.1 et configurez-le pour rejoindre le domaine

Installez Samba 4.1:

$ pkg install samba41

Créez le fichier /usr/local/etc/smb4.confavec le contenu suivant:

[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

Demandez un ticket Kerberos administrateur:

$ kinit Administrator

Rejoignez ensuite le domaine et créez un keytab

$ net ads join createupn=host/[email protected] -k
$ net ads keytab create -k

3. Installez le package sssd et Cyrus SASL avec le support Kerberos

Installez les packages requis:

$ pkg install sssd cyrus-sasl-gssapi

Modifiez le fichier /usr/local/etc/sssd/sssd.confpour qu'il corresponde à ces paramètres:

[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 = [email protected]

4. Ajoutez le support sssd à nsswitch.conf

Modifiez le fichier /etc/nsswitch.confpour qu'il corresponde à ces paramètres:

group: files sss
passwd: files sss

5. Configurez PAM pour autoriser l'authentification sssd et gérer la création du répertoire personnel

Installez des packages facultatifs pour la création du répertoire personnel:

$ pkg install pam_mkhomedir

Modifiez les PAMdomaines nécessaires pour correspondre à ces paramètres:

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. Basculez vers le client OpenLDAP compatible SASL

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

7. Enfin, confirmez que tout fonctionne

$ getent passwd <username>

Quel Kerberos utilisez-vous ici? Celui intégré ou security / krb5 du MIT?

Lors de l'installation de sssd, il nécessite que security / krb5 soit installé, ce qui à ce moment est toujours considéré comme expérimental dans FreeBSD. D'où cette question.

Je n'ai aucune chance d'obtenir les utilisateurs / groupes AD lors de l'exécution des commandes «getent». cela peut être dû au fait que le nom NETBIOS diffère du nom de domaine -ie dans mon cas, le nom de domaine est dawnsign.com et le nom NETBIOS est DSP.

J'ai configuré uniquement le module de connexion pam.d. Quels autres modules pam doivent être modifiés pour qu'une authentification réussie ait lieu?

Toute information supplémentaire serait grandement appréciée!

La recompilation de samba4 à partir des ports est possible pour utiliser l'authentification de winbind comme linux même sans sssd. Recompilez simplement samba4 à partir des ports après avoir activé 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

Cela va recompiler samba avec tout le support nécessaire (gssapi, ldap, kerberos) puis éditer nsswitch.conf comme ceci

passwd: files winbind
group: files winbind

Bonjour

Ceci est une petite mise à jour sur l'utilisation de sssd v1.11.7

Si vous utilisez "id_provider = ad" et que vous voyez l'erreur suivante dans le fichier journal 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]

Vous pouvez utiliser la procédure suivante pour résoudre ce problème et faire fonctionner l'intégration AD correctement. Maintenant, compilez sssd v1.11.7 avec le support de Samba, la construction à partir de src sssd est nécessaire pour qu'elle soit liée à 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

Voici mon guide sur l'intégration AD via SSSD avec ces versions de FreeBSD, au moment d'écrire ces lignes (6/2017)

• FreeBSD 10.3 et 11.0 (10.3-RELEASE-p18 & 11.0-RELEASE-p9)

• Installation (et les problèmes amusants d'emballage et de dépendance)

  • Les packages requis ne semblent pas compatibles avec Heimdal Kerberos, donc les choses doivent être installées et compilées avec les drapeaux MIT Kerberos activés. Il s'agit probablement davantage d'un problème de dépendance de l'emballage que d'un problème de compatibilité réel.
  • Heimdal est installé avec le système de base, ce qui vous laisse deux ensembles de commandes Kerberos si vous installez MIT Kerberos, un ensemble dans /usr/binet l'autre dans /usr/local/bin. Étant donné qu'aucun des fichiers du système de base ne semble être dans un package, vous ne pouvez pas simplement supprimer le contenu Heimdal KRB. Quelque chose à savoir.

  • Dépendances vers l'avant des différents packages (dep intéressants en gras, dep en conflit en italique gras):

    • 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

  • Dépendances inverses des différents packages:

    • net/openldap24-sasl-client: sysutils/msktutil
    • net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
    • net/openldap24-sasl-client: net-mgmt/adcli
      • Comme nous le voyons, sssdnécessite le MIT Kerberos, même si nous avons Heimdal comme package de base
      • adcliveut openldap-sasl-client, mais d'autres paquets (y compris les sous-dépendances de sssd) openldap-clientarrivent, ce qui est mutex avec le client sasl (pour une raison stupide). Cela rend l'installation un peu pénible, même avec un ensemble minimum de packages binaires.
      • Ces dépendances sont présentes à la fois pour les packages de dépôt binaire et si les packages sont générés dans l'arborescence des ports. Cela nécessite une méthode d'installation particulièrement ennuyeuse pour obtenir tout ce dont nous avons besoin (voir ci-dessous).

  • Au moment de la rédaction de ce document, le paquetage binaire pour SSSD pour FreeBSD n'inclut pas le support AD dans SSSD

    • La version des ports de SSSD devait être construite avec les options appropriées (make config) activées:
      • SMB
    • SSSD veut également intégrer openldap-client, alors qu'il a vraiment besoin de openldap-sasl-client pour fonctionner correctement.
  • La version binaire de pkg adcliexiste, mais à ce jour, cela ne fonctionne pas.
    • Encore une fois, la version des ports a été compilée avec les options appropriées activées:
      • GSSAPI_MIT
  • cyrus-sasl-gssapi est requis, mais la version binaire de pkg ne fonctionne pas et a des problèmes de dépendance étranges qui provoquent la suppression de SSSD.
    • Créez-le à partir de ports avec l'option MIT-KRB5 activée:
      • GSSAPI_MIT
  • openldap-sasl-client est requis pour la fonctionnalité, mais SSSD souhaite intégrer la version non SASL d'Openldap.
    • Pour que cela fonctionne
      • configurer openldap-sasl-clientavec l' GSSAPIoption sélectionnée ( make config) dans les ports.
      • Faites le make dans les ports pour le construire
      • Avant d'effectuer l'installation, effectuez une pkg remove –f openldap-client
        • Cela supprimera openldap-clientsans effectuer de suppression automatique des autres packages (comme SSSD) et permettra l'installation de la version SASL
      • Faites une installation pour le openldap-sasl-client
        • Cela l'installera sur le système
  • Cela fournira ce qui est nécessaire pour un SSSD fonctionnel avec des capacités AD.
  • Veuillez noter que si vous compilez SSSD à partir de ports, il tirera BEAUCOUP de dépendances, ce qui entraînera leur construction et nécessitera le choix des options de configuration.
    • Il est suggéré d'installer d'abord le paquet binaire avec pkg install sssd puis de le supprimer avec pkg remove –f sssd
      • Cela entraînera les packages binaires pour la plupart des choses que SSSD doit être extrait, et supprimera la nécessité de construire tout cela dépend des ports, ce qui prend un certain temps.
    • Une fois supprimé, réinstallez SSSD à partir des ports avec les options mentionnées ci-dessus activées et vous n'aurez qu'à reconstruire les quatre packages mentionnés ci-dessus pour obtenir une configuration fonctionnelle.

  • (Facultatif) Une fois que tout fonctionne et est vérifié, vous pouvez utiliser pkg createpour créer des packages binaires des quatre packages avec les options appropriées activées et les utiliser au lieu de les construire dans des ports sur chaque système. L'installation de binaire suit un modèle similaire au processus de construction des ports:

    • pkg install sssd-1.11.7_8.txz
      • Votre version peut être différente bien sûr
      • Cela installera le paquet binaire pour SSSD et récupérera tout ce dont il a besoin du dépôt FreeBSD.
    • pkg add les autres packages (pas installer, ajouter), en enregistrant le package openldap pour la dernière.
    • Avant d'ajouter, openldap-sasl-clientfaites unpkg remove –f openldap-client
      • Cela supprime la version non SASL et permet à notre version d'être installée
    • pkg add openldap-sasl-client-2.4.44.txz
      • Encore une fois, votre version peut être différente
    • Vous devriez vous retrouver avec les packages requis installés.
    • Il peut être possible de modifier les métadonnées pour le binaire SSSD avant de faire pkg createpour remplacer la dépendance sur openldap-clientavec openldap-sasl-clientpour supprimer la nécessité de procéder à cette suppression / réinstallation. Je n'ai pas eu le temps de chercher à faire ça.
      • De plus, il existe des sous-dépendances de SSSD qui se déclenchent également openldap-client, vous devrez donc les corriger également.
    • Veuillez noter que toutes ces notes concernent les versions de ces packages actuellement dans l'arborescence des ports au moment de la rédaction de cet article , et les dépendances qu'ils leur ont associées. Tout cela peut changer à mesure que FreeBSD met à jour l'arborescence des ports et les binaires. Peut-être qu'un jour, nous aurons une version binaire de tout ce qui tire toutes les bonnes dépendances avec les options appropriées configurées pour la fonctionnalité AD dès la sortie de la boîte.

  • Configuration Kerberos:

    • Exemple de fichier /etc/krb5.conf:

[libdefaults]
   default_realm = MYDOMAIN.NET
   transmissible = vrai
# Normalement, tout ce dont vous avez besoin dans un environnement AD, car les enregistrements DNS SRV
# identifiera les serveurs / services AD / KRB. Commentez si vous
# souhaitez pointer manuellement vers votre serveur AD
dns_lookup_kdc = true
[royaumes]
   MYDOMAIN.NET = {
# Si vous pointez manuellement vers un serveur AD différent de celui du DNS
# admin_server = adserver.mydomain.net
# kdc = adserver.mydomain.net
   }
[domain_realm]
   mydomain.net = MYDOMAIN.NET
   .mydomain.net = MYDOMAIN.NET

• (tiret)
  • Configuration SSSD:
    • Cet exemple suppose des attributs POSIX dans AD pour les utilisateurs et les groupes, généralement requis lorsque l'on remplace un environnement existant qui a déjà établi des UID et GID.
    • Exemple de fichier /usr/local/etc/sssd/sssd.conf:

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

[domaine / MYDOMAIN.NET]
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
# utiliser les attributs AD POSIX, commenter si vous utilisez généré automatiquement
# UID et GID.
ldap_id_mapping = False
cache_credentials = true
ad_server = adserver.mydomain.net
# si vous n'avez pas bash, ou quoi que ce soit dans le loginShell du compte AD
# attribut installé
override_shell = / bin / tcsh

• (tiret)
  • Configuration PAM:
    • La configuration de PAM sur FreeBSD est un peu délicate à cause du fonctionnement d'OpenPAM. Je n'entrerai pas dans les détails, mais pour utiliser pam_sss pour SSSD et le faire fonctionner, et pour que les connexions passwd fonctionnent, vous devez mettre pam_unix dans le fichier deux fois. D'après ce que je comprends, cela a à voir avec une vérification secondaire qui se fait "en arrière-plan" qui nécessite que le deuxième module pam_unix passe.
      • Voici la liste des /etc/pam.dfichiers que j'ai dû modifier pour que SSSD fonctionne avec FreeBSD:

/etc/pam.d/sshd:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / sshd 197769 2009-10-05 09: 28: 54Z des $
#
# Configuration PAM pour le service "sshd"
#

# auth
auth suffisant pam_opie.so no_warn no_fake_prompts
auth requis pam_opieaccess.so no_warn allow_local
#auth suffisant pam_krb5.so no_warn try_first_pass
#auth suffisant pam_ssh.so no_warn try_first_pass
auth suffisant pam_unix.so no_warn try_first_pass nullok
auth suffisant pam_sss.so use_first_pass
auth requis pam_unix.so no_warn use_first_pass

# Compte
compte requis pam_nologin.so
#account requis pam_krb5.so
compte requis pam_login_access.so
compte requis pam_unix.so
compte suffisant pam_sss.so

# session
#session facultatif pam_ssh.so want_agent
session facultative pam_sss.so
session requise pam_mkhomedir.so mode = 0700
session requise pam_permit.so

# mot de passe
#password suffisant pam_krb5.so no_warn try_first_pass
#password suffisant pam_unix.so try_first_pass use_authtok nullok
mot de passe suffisant pam_unix.so try_first_pass use_authtok
mot de passe suffisant pam_sss.so use_authtok

/etc/pam.d/system:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / system 197769 2009-10-05 09: 28: 54Z des $
#
# Valeurs par défaut à l'échelle du système
#

# auth
auth suffisant pam_opie.so no_warn no_fake_prompts
auth requis pam_opieaccess.so no_warn allow_local
#auth suffisant pam_krb5.so no_warn try_first_pass
#auth suffisant pam_ssh.so no_warn try_first_pass
#auth requis pam_unix.so no_warn try_first_pass nullok
auth suffisant pam_unix.so no_warn try_first_pass
auth suffisant pam_sss.so use_first_pass
auth requis pam_deny.so

# Compte
#account requis pam_krb5.so
compte requis pam_login_access.so
compte requis pam_unix.so
compte suffisant pam_sss.so

# session
#session facultatif pam_ssh.so want_agent
session requise pam_lastlog.so no_fail
session facultative pam_sss.so
session requise pam_mkhomedir.so mode = 0700

# mot de passe
#password suffisant pam_krb5.so no_warn try_first_pass
#password requis pam_unix.so no_warn try_first_pass
mot de passe suffisant pam_unix.so no_warn try_first_pass nullok use_authtok
mot de passe suffisant pam_sss.so use_authtok
#password requis pam_deny.so

/etc/pam.d/su:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / su 219663 15/03/2011 10: 13: 35Z des $
#
# Configuration PAM pour le service "su"
#

# auth
auth suffisant pam_rootok.so no_warn
auth suffisant pam_self.so no_warn
auth requis pam_group.so no_warn group = wheel root_only fail_safe ruser
l'auth inclut system.dist

# Compte
le compte inclut system.dist

# session
session requise pam_permit.so

• (tiret)

  • Remarques:
    • system.distest une copie du /etc/pam.d/systemfichier de stock . Il est inclus dans le /etc/pam.d/sufichier ci-dessus pour éviter les problèmes avec la commande su.
    • On peut toujours suAD les comptes en tant que root, car une fois root, il sun'est pas nécessaire de s'authentifier et les informations de compte sont extraites via le commutateur de service de noms via SSSD.
    • Si vous voulez vraiment passer d'un utilisateur (pas root) à un autre utilisateur, il faut utiliser sudopour des raisons de sécurité uniquement
    • Vous pouvez également utiliser ksuet cela fonctionne pour passer de l'utilisateur A à l'utilisateur B
      • Heimdal ksu(in /usr/bin) n'a pas SUID défini par défaut
        • Pour faire ksufonctionner Heimdal ,chmod u+s /usr/bin/ksu
      • MIT Kerberos ( krb5package installé dans /usr/local/bin) est SUID à l'installation
    • Comme Heimdal fait partie du package de base, vous aurez les deux ensembles de binaires Kerberos.
      • Vous voudrez peut-être ajuster les chemins par défaut pour que ce /usr/local/binsoit avant /usr/bin, etc.
    • ksu demandera à l'utilisateur le mot de passe AD / Kerberos de l'utilisateur cible
    • passwdne fonctionnera pas pour changer votre mot de passe AD / Kerberos même si vous ajoutez pam_sss.soau fichier passwd PAM. Le passwdbinaire prend uniquement en charge l'utilisation locale et NIS kpasswdpour modifier votre mot de passe sur le ou les serveurs AD / Kerberos.

  • Commutateur de service de noms:

    • Le /etc/nsswitch.conffichier doit être configuré pour utiliser le service sss pour passwd et les groupes. Exemple:
      • group: files sss
      • passwd: files sss

  • Rejoindre un domaine:

    • Il y a deux outils principaux sur * nixs pour rejoindre votre box linux
      • adcli
        • Ceci est mon outil préféré. Cela fonctionne très bien et tout peut être fait sur une seule ligne de commande. Les informations d'identification peuvent être fournies de manière non interactive (via stdin, etc.)
        • Ne nécessite pas de faire un kinitavant de l'utiliser, il le fait pour vous en fonction des crédits fournis.
          • Exemple:
            • adcli join -D mydomain.net -U Administrator--show-details –v
            • adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
              • Ce formulaire est recommandé car l'utilitaire ne comprend pas toujours correctement le nom de domaine complet. Lorsque vous fournissez le FQDN qui correspond à la fois au DNS direct et inversé pour l'hôte, les principes sont créés correctement. Si l'utilitaire utilise un nom d'hôte incorrect (n'incluant pas le domaine DNS, par exemple), certains principaux de service ne seront pas créés et des choses comme SSH dans l'hôte peuvent échouer.
      • netUtilitaire Samba
        • L' netutilitaire fait partie de la suite Samba.
        • Cet utilitaire nécessite que les détails du domaine soient définis dans le smb.conffichier de configuration, ce qui le rend plus difficile et peu pratique à utiliser, en particulier de manière non interactive.
        • Ces outils nécessitent également que vous obteniez un ticket Kerberos avant de l'utiliser en utilisant kinit. Encore une fois, cela est plus gênant et rend un peu plus difficile à utiliser de manière non interactive dans un script, car il y a deux étapes au lieu d'une.
          

  • Considérations SSHD:

    • Faire fonctionner SSHD avec AD et SSSD est généralement assez simple
    • Les options suivantes doivent être ajoutées à /etc/ssh/sshd_config
      • GSSAPIAuthentication yes
        • Activez l'authentification GSS API pour SSHD. Cela entraînera l'authentification SSHD contre AD KDC
      • PasswordAuthentication yes
        • Autorisez les utilisateurs à se connecter avec des mots de passe. Obligatoire si vous souhaitez qu'un utilisateur obtienne un ticket KRB5 lors de la connexion. Sans cela activé, le système ne peut pas décrypter le TGT envoyé par le KDC.
      • ChallengeResponseAuthentication yes
        • Pour FreeBSD, cette méthode semble fonctionner le mieux.
          • Assurez-vous de configurer PasswordAuthentication nolorsque vous utilisez cette option.
          • C'est la seule méthode que j'ai trouvée pour FreeBSD qui fonctionne pour changer un mot de passe expiré lors de la connexion. Si vous utilisez l'autre, il appelle /bin/passwd, qui ne prend en charge que NIS et le fichier passwd local.
      • GSSAPICleanupCredentials yes
        • (facultatif) effectuera une kdestroydéconnexion
      • GSSAPIStrictAcceptorCheck no
        • (facultatif) Cette option est souvent requise si SSHD est confus au sujet de son propre nom d'hôte, ou est multi-hôte, etc., ou utilise autrement un principal de service différent pour communiquer avec le KDC. Normalement, SSHD utilise le principal de service host/<FQDN>@REALMpour parler avec le KDC, mais se trompe parfois (par exemple, si le nom d'hôte ne correspond pas au nom DNS du serveur SSH). Cette option permet à SSHD d'utiliser n'importe quel principal dans le /etc/krb5.keytabfichier, ce qui inclut le bonhost/<FQDN>@REALM
    • Selon la combinaison d'options que vous utilisez, vous pouvez ou non avoir besoin d'ajouter des principaux hôtes au KDC pour que les adresses IPv4 et IPv6 de votre hôte ssh -K <ip>fonctionnent sans demander de mot de passe (en supposant que vous avez déjà fait un `` kinit '', bien sûr).