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 sssd
le backend AD avec Kerberos TGT qui fonctionne?
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 sssd
le backend AD avec Kerberos TGT qui fonctionne?
Réponses:
Il y a quelques considérations délicates pour que tout fonctionne hors de la boîte. FreeBSD ne prend en charge que la sssd
version 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 sssd
ne peut pas gérer ce cas.
Ainsi, dans la version actuelle, sssd
vous ê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:
username@example.com sAMAccountName: username
Sachant cela, nous pouvons décrire les étapes pour authentifier avec succès les utilisateurs d'AD dans FreeBSD.
Créez le fichier /etc/krb5.conf
avec le contenu suivant:
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = yes
Installez Samba 4.1:
$ pkg install samba41
Créez le fichier /usr/local/etc/smb4.conf
avec 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/server-hostname.example.com@EXAMPLE.COM -k
$ net ads keytab create -k
Installez les packages requis:
$ pkg install sssd cyrus-sasl-gssapi
Modifiez le fichier /usr/local/etc/sssd/sssd.conf
pour 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 = SERVER-HOSTNAME$@EXAMPLE.COM
Modifiez le fichier /etc/nsswitch.conf
pour qu'il corresponde à ces paramètres:
group: files sss
passwd: files sss
Installez des packages facultatifs pour la création du répertoire personnel:
$ pkg install pam_mkhomedir
Modifiez les PAM
domaines 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
$ pkg remove -f openldap-client
$ pkg install openldap-sasl-client
$ 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
Installation (et les problèmes amusants d'emballage et de dépendance)
/usr/bin
et 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
sssd
nécessite le MIT Kerberos, même si nous avons Heimdal comme package de baseadcli
veut openldap-sasl-client
, mais d'autres paquets (y compris les sous-dépendances de sssd
) openldap-client
arrivent, 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.Au moment de la rédaction de ce document, le paquetage binaire pour SSSD pour FreeBSD n'inclut pas le support AD dans SSSD
SMB
adcli
existe, mais à ce jour, cela ne fonctionne pas.
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.
GSSAPI_MIT
openldap-sasl-client
est requis pour la fonctionnalité, mais SSSD souhaite intégrer la version non SASL d'Openldap.
openldap-sasl-client
avec l' GSSAPI
option sélectionnée ( make config
) dans les ports.pkg remove –f openldap-client
openldap-client
sans effectuer de suppression automatique des autres packages (comme SSSD) et permettra l'installation de la version SASLopenldap-sasl-client
pkg remove –f sssd
(Facultatif) Une fois que tout fonctionne et est vérifié, vous pouvez utiliser pkg create
pour 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
pkg add
les autres packages (pas installer, ajouter), en enregistrant le package openldap pour la dernière.openldap-sasl-client
faites unpkg remove –f openldap-client
pkg add openldap-sasl-client-2.4.44.txz
pkg create
pour remplacer la dépendance sur openldap-client
avec openldap-sasl-client
pour supprimer la nécessité de procéder à cette suppression / réinstallation. Je n'ai pas eu le temps de chercher à faire ça.
openldap-client
, vous devrez donc les corriger également.Configuration Kerberos:
[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
[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
/etc/pam.d
fichiers 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)
system.dist
est une copie du /etc/pam.d/system
fichier de stock . Il est inclus dans le /etc/pam.d/su
fichier ci-dessus pour éviter les problèmes avec la commande su.su
AD les comptes en tant que root, car une fois root, il su
n'est pas nécessaire de s'authentifier et les informations de compte sont extraites via le commutateur de service de noms via SSSD.sudo
pour des raisons de sécurité uniquementksu
et cela fonctionne pour passer de l'utilisateur A à l'utilisateur B
ksu
(in /usr/bin
) n'a pas SUID défini par défaut
ksu
fonctionner Heimdal ,chmod u+s /usr/bin/ksu
krb5
package installé dans /usr/local/bin
) est SUID à l'installation/usr/local/bin
soit avant /usr/bin
, etc.ksu
demandera à l'utilisateur le mot de passe AD / Kerberos de l'utilisateur ciblepasswd
ne fonctionnera pas pour changer votre mot de passe AD / Kerberos même si vous ajoutez pam_sss.so
au fichier passwd PAM. Le passwd
binaire prend uniquement en charge l'utilisation locale et NIS kpasswd
pour modifier votre mot de passe sur le ou les serveurs AD / Kerberos.Commutateur de service de noms:
/etc/nsswitch.conf
fichier doit être configuré pour utiliser le service sss pour passwd et les groupes. Exemple:
group: files sss
passwd: files sss
Rejoindre un domaine:
adcli
kinit
avant de l'utiliser, il le fait pour vous en fonction des crédits fournis.
adcli join -D mydomain.net -U Administrator--show-details –v
adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
net
Utilitaire
Sambanet
utilitaire fait partie de la suite Samba.smb.conf
fichier de configuration, ce qui le rend plus difficile et peu pratique à utiliser, en particulier de manière non interactive.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:
/etc/ssh/sshd_config
GSSAPIAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
lorsque vous utilisez cette option./bin/passwd
, qui ne prend en charge que NIS et le fichier passwd local.GSSAPICleanupCredentials yes
kdestroy
déconnexionGSSAPIStrictAcceptorCheck no
host/<FQDN>@REALM
pour 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.keytab
fichier, ce qui inclut le bonhost/<FQDN>@REALM
ssh -K <ip>
fonctionnent sans demander de mot de passe (en supposant que vous avez déjà fait un `` kinit '', bien sûr).