Quali sono i passaggi necessari per autenticare gli utenti da una Active Directory in esecuzione su Windows Server 2012 R2 in FreeBSD 10.0 usando sssdcon il back-end di AD con Kerberos TGT funzionante?

Ci sono alcune considerazioni complicate per rendere tutto pronto per l'uso. In sssdquesto momento FreeBSD supporta solo la versione 1.9.6. Quindi non c'è supporto per Enterprise Principal Names.

Se hai un dominio con UPN non corrispondenti non riuscirà ad accedere, poiché l'autenticazione Kerberos fallirà durante il processo, anche con FreeBSD che supporta i nomi principali aziendali con Kerberos, sssdnon è possibile gestire questo caso.

Pertanto, nella versione effettiva di sssdte è limitato il nome principale utente all'interno dello stesso nome dominio, ad esempio:

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

Sapendo questo, possiamo descrivere i passaggi per autenticare con successo gli utenti da AD in FreeBSD.

1. Configurare Kerberos

Creare il file /etc/krb5.confcon il seguente contenuto:

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

2. Installa Samba 4.1 e configuralo per unirti al dominio

Installa Samba 4.1:

$ pkg install samba41

Creare il file /usr/local/etc/smb4.confcon il seguente contenuto:

[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

Richiedi un biglietto per amministratore Kerberos:

$ kinit Administrator

Quindi unisciti al dominio e crea un keytab

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

3. Installare il pacchetto sssd e Cyrus SASL con supporto Kerberos

Installa i pacchetti richiesti:

$ pkg install sssd cyrus-sasl-gssapi

Modifica il file /usr/local/etc/sssd/sssd.confin modo che corrisponda a queste impostazioni:

[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. Aggiungi il supporto sssd a nsswitch.conf

Modifica il file /etc/nsswitch.confin modo che corrisponda a queste impostazioni:

group: files sss
passwd: files sss

5. Configurare PAM per consentire l'autenticazione sssd e gestire la creazione della directory home

Installa i pacchetti opzionali per la creazione della home directory:

$ pkg install pam_mkhomedir

Modifica i PAMregni necessari per abbinare queste impostazioni:

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. Passare al client OpenLDAP abilitato SASL

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

7. Infine, conferma che tutto funziona

$ getent passwd <username>

Quale Kerberos stai usando qui? Quello incorporato o security / krb5 del MIT?

Quando installi sssd, richiede che sia installato security / krb5 che in questo momento è ancora considerato sperimentale in FreeBSD. Quindi questa domanda.

Non ho fortuna ad ottenere gli utenti / gruppi di AD durante l'esecuzione dei comandi "getent". potrebbe essere dovuto al fatto che il nome NETBIOS differisce dal nome di dominio -ie nel mio caso, il nome di dominio è dawnsign.com e il nome NETBIOS è DSP.

Ho configurato solo il modulo di accesso pam.d. Quali altri moduli pam devono essere modificati per consentire un'autenticazione corretta?

Ogni ulteriore informazione sarebbe molto apprezzata!

Ricompilare samba4 dalle porte è possibile usare l'autenticazione winbind come linux anche senza sssd. Basta ricompilare samba4 dalle porte dopo aver abilitato 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

Questo ricompilerà samba con tutto il supporto necessario (gssapi, ldap, kerberos) quindi modifica nsswitch.conf in questo modo

passwd: files winbind
group: files winbind

Ciao,

Questo è un piccolo aggiornamento sull'uso di sssd v1.11.7

Se stai utilizzando "id_provider = ad" e visualizzi il seguente errore nel file di 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]

È possibile utilizzare la seguente procedura per risolvere questo problema e far funzionare correttamente l'integrazione AD. Ora compilate sssd v1.11.7 con il supporto di Samba, è necessario compilare da src sssd quindi è collegato a 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

Ecco la mia guida sull'integrazione AD tramite SSSD con queste versioni di FreeBSD, al momento in cui scrivo (6/2017)

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

• Installazione (e divertenti problemi di imballaggio e dipendenza)

  • I pacchetti richiesti non sembrano essere compatibili con Heimdal Kerberos, quindi le cose devono essere installate e compilate con i flag MIT Kerberos abilitati. Questo è probabilmente più un problema di dipendenza dal packaging che un vero problema di compatibilità.
  • Heimdal è installato con il sistema di base, quindi questo ti lascia con due set di comandi Kerberos se installi MIT Kerberos, uno impostato /usr/bine l'altro interno /usr/local/bin. Poiché nessuno dei file di sistema di base sembra essere contenuto in un pacchetto, non è possibile semplicemente rimuovere il materiale Heimdal KRB. Qualcosa di cui essere consapevoli.

  • Dipendenze forward dei vari pacchetti (deps interessanti in deps in grassetto e in conflitto in corsivo grassetto):

    • 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

  • Dipendenze inverse dei vari pacchetti:

    • net/openldap24-sasl-client: sysutils/msktutil
    • net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
    • net/openldap24-sasl-client: net-mgmt/adcli
      • Come vediamo sssd, richiede il MIT Kerberos, anche se abbiamo Heimdal come pacchetto base
      • adclivuole openldap-sasl-client, ma altri pacchetti (comprese le sotto-dipendenze di sssd) openldap-clientvengono inseriti, che è mutex con il client sasl (per qualsiasi motivo sciocco). Questo rende l'installazione un po 'problematica, anche con un set minimo di pacchetti binari.
      • Queste dipendenze sono presenti sia per i pacchetti di repository binari, sia se i pacchetti sono creati nell'albero delle porte. Ciò richiede un metodo di installazione particolare fastidioso per ottenere tutto ciò di cui abbiamo bisogno (coperto di seguito).

  • Al momento della stesura di questo documento, il pacchetto binario per SSSD per FreeBSD non include il supporto AD in SSSD

    • La versione delle porte di SSSD doveva essere costruita con le opzioni appropriate (make config) abilitate:
      • SMB
    • SSSD vuole anche inserire openldap-client, quando ha davvero bisogno di openldap-sasl-client per funzionare correttamente.
  • La versione binaria di pkg adcliesiste, ma al momento della stesura di questo documento, non funziona.
    • Ancora una volta, la versione delle porte è stata compilata con le opzioni appropriate abilitate:
      • GSSAPI_MIT
  • cyrus-sasl-gssapi è obbligatorio, ma la versione binaria di pkg non funziona e presenta strani problemi di dipendenza che causano la rimozione di SSSD.
    • Costruiscilo dalle porte con l'opzione MIT-KRB5 abilitata:
      • GSSAPI_MIT
  • openldap-sasl-client è richiesto per funzionalità ma SSSD vuole inserire la versione non SASL di openldap.
    • Per farlo funzionare
      • configurare openldap-sasl-clientcon l' GSSAPIopzione selezionata ( make config) nelle porte.
      • Esegui il make in porti per costruirlo
      • Prima di effettuare l'installazione, eseguire un pkg remove –f openldap-client
        • Ciò rimuoverà openldap-clientsenza eseguire alcun movimento degli altri pacchetti (come SSSD) e consentirà l'installazione della versione SASL
      • Fai una installazione per il openldap-sasl-client
        • Questo lo installerà sul sistema
  • Ciò fornirà ciò che è necessario per un SSSD funzionale con funzionalità AD.
  • Si noti che se si compila SSSD dalle porte, si otterranno MOLTE dipendenze, il che le farà costruire e richiederà la selezione delle opzioni di configurazione.
    • Si consiglia di installare prima il pacchetto binario con pkg install sssd, quindi rimuoverlo con pkg remove –f sssd
      • Questo causerà il pull dei pacchetti binari per la maggior parte delle cose di cui SSSD ha bisogno e rimuoverà la necessità di compilare tutto ciò dipende dalle porte, il che richiede un po 'di tempo.
    • Una volta rimosso, reinstallare SSSD dalle porte con le opzioni sopra menzionate abilitate e dovrai solo ricostruire i quattro pacchetti sopra menzionati per ottenere una configurazione funzionante.

  • (Facoltativo) Una volta che tutto funziona e viene verificato, è possibile utilizzare pkg createper creare pacchetti binari dei quattro pacchetti con le opzioni appropriate abilitate e utilizzare quelli invece di crearli nelle porte su ogni sistema. L'installazione del file binario segue un modello simile al processo di generazione delle porte:

    • pkg install sssd-1.11.7_8.txz
      • La tua versione potrebbe essere diversa ovviamente
      • Questo installerà il pacchetto binario per SSSD ed estrarrà tutto ciò di cui ha bisogno dal repository FreeBSD.
    • pkg add gli altri pacchetti (non installare, aggiungere), salvando il pacchetto openldap per ultimo.
    • Prima di aggiungere openldap-sasl-clientfai apkg remove –f openldap-client
      • Questo elimina la versione non SASL e consente l'installazione della nostra versione
    • pkg add openldap-sasl-client-2.4.44.txz
      • Ancora una volta, la tua versione potrebbe essere diversa
    • Dovresti finire con i pacchetti richiesti installati.
    • Esso può essere possibile modificare i metadati per il binario SSSD prima di fare il pkg createper sostituire la dipendenza openldap-clientcon openldap-sasl-clientper eliminare la necessità di fare questo rimuovere / reinstallazione. Non ho avuto il tempo di esaminare questo.
      • Inoltre, ci sono anche delle dipendenze secondarie di SSSD, che openldap-clientdovresti risolvere anche quelle.
    • Si noti che tutte queste note sono a partire dalle versioni di questi pacchetti attualmente nella struttura dei porti al momento della stesura di questo documento , e dalle dipendenze che hanno associato ad essi. Tutto ciò può cambiare quando FreeBSD aggiorna l'albero dei port e i binari. Forse un giorno avremo una versione binaria di tutto ciò che estrae tutte le giuste dipendenze con le opzioni appropriate configurate per la funzionalità AD immediatamente.

  • Configurazione Kerberos:

    • Esempio di file /etc/krb5.conf:

[libdefaults]
   default_realm = MYDOMAIN.NET
   forwardable = true
# Normalmente tutto ciò che serve in un ambiente AD, poiché i record DNS SRV
# identificherà i server / servizi AD / KRB. Commenta se tu
# desidera puntare manualmente al tuo server AD
dns_lookup_kdc = true
[regni]
   MYDOMAIN.NET = {
# Se stai indicando manualmente un server AD diverso da quello che c'è nel DNS
# admin_server = adserver.mydomain.net
# kdc = adserver.mydomain.net
   }
[Domain_realm]
   mydomain.net = MYDOMAIN.NET
   .mydomain.net = MYDOMAIN.NET

• (Trattino)
  • Configurazione SSSD:
    • Questo esempio presuppone attributi POSIX in AD per utenti e gruppi, generalmente richiesti per quando si sostituisce un ambiente esistente che ha già stabilito UID e GID.
    • Esempio di file /usr/local/etc/sssd/sssd.conf:

[SSSD]
config_file_version = 2
domains = MYDOMAIN.NET
servizi = nss, pam, pac
fallback_homedir = / home /% u

[Dominio / MYDOMAIN.NET]
id_provider = annuncio
access_provider = annuncio
auth_provider = annuncio
chpass_provider = annuncio
# usa gli attributi di POSIX AD, commenta se stai usando generato automaticamente
# UID e GID.
ldap_id_mapping = Falso
cache_credentials = true
ad_server = adserver.mydomain.net
# se non hai bash o qualsiasi altra cosa sia nella loginShell dell'account AD
# attributo installato
override_shell = / bin / tcsh

• (Trattino)
  • Configurazione PAM:
    • La configurazione di PAM su FreeBSD è un po 'complicata a causa del modo in cui OpenPAM funziona. Non entrerò nei dettagli, ma per usare pam_sss per SSSD e farlo funzionare, e anche far funzionare gli accessi passwd, è necessario inserire due volte pam_unix nel file. Da quello che ho capito, questo ha a che fare con un controllo secondario che viene eseguito "dietro le quinte" che richiede il passaggio del secondo modulo pam_unix.
      • Ecco la lista dei /etc/pam.dfile che ho dovuto modificare per far funzionare SSSD con FreeBSD:

/etc/pam.d/sshd:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / sshd 197769 2009-10-05 09: 28: 54Z des $
#
# Configurazione PAM per il servizio "sshd"
#

# auth
auth sufficienti pam_opie.so no_warn no_fake_prompts
autenticazione richiesta pam_opieaccess.so no_warn allow_local
#auth sufficienti pam_krb5.so no_warn try_first_pass
#auth sufficienti pam_ssh.so no_warn try_first_pass
auth sufficienti pam_unix.so no_warn try_first_pass nullok
auth sufficienti pam_sss.so use_first_pass
autenticazione obbligatoria pam_unix.so no_warn use_first_pass

# account
account richiesto pam_nologin.so
#account richiesto pam_krb5.so
account richiesto pam_login_access.so
account richiesto pam_unix.so
account pam_sss.so sufficiente

# sessione
#session opzionale pam_ssh.so want_agent
sessione opzionale pam_sss.so
sessione richiesta pam_mkhomedir.so mode = 0700
sessione richiesta pam_permit.so

# parola d'ordine
#password sufficiente pam_krb5.so no_warn try_first_pass
#password sufficiente pam_unix.so try_first_pass use_authtok nullok
password sufficiente pam_unix.so try_first_pass use_authtok
password sufficiente 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 $
#
# Impostazioni predefinite a livello di sistema
#

# auth
auth sufficienti pam_opie.so no_warn no_fake_prompts
autenticazione richiesta pam_opieaccess.so no_warn allow_local
#auth sufficienti pam_krb5.so no_warn try_first_pass
#auth sufficienti pam_ssh.so no_warn try_first_pass
#auth richiesto pam_unix.so no_warn try_first_pass nullok
auth sufficienti pam_unix.so no_warn try_first_pass
auth sufficienti pam_sss.so use_first_pass
autenticazione obbligatoria pam_deny.so

# account
#account richiesto pam_krb5.so
account richiesto pam_login_access.so
account richiesto pam_unix.so
account pam_sss.so sufficiente

# sessione
#session opzionale pam_ssh.so want_agent
sessione richiesta pam_lastlog.so no_fail
sessione opzionale pam_sss.so
sessione richiesta pam_mkhomedir.so mode = 0700

# parola d'ordine
#password sufficiente pam_krb5.so no_warn try_first_pass
#password richiesto pam_unix.so no_warn try_first_pass
password sufficiente pam_unix.so no_warn try_first_pass nullok use_authtok
password sufficiente pam_sss.so use_authtok
#password richiesto pam_deny.so

/etc/pam.d/su:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / su 219663 2011-03-15 10: 13: 35Z des $
#
# Configurazione PAM per il servizio "su"
#

# auth
autenticazione sufficiente pam_rootok.so no_warn
auth sufficienti pam_self.so no_warn
pam_group.so no_warn group = ruota root_only fail_safe ruser
auth include system.dist

# account
l'account include system.dist

# sessione
sessione richiesta pam_permit.so

• (Trattino)

  • Appunti:
    • system.distè una copia del /etc/pam.d/systemfile di scorta . È incluso nel /etc/pam.d/sufile sopra per evitare problemi con il comando su.
    • Uno è ancora in grado di suAD account come root, poiché una volta root, sunon è necessario autenticarsi e le informazioni sull'account vengono estratte tramite l'interruttore del servizio nomi tramite SSSD.
    • Se vuoi davvero passare da un utente (non root) a un altro utente, dovresti usarlo solo sudoper motivi di sicurezza
    • Puoi anche usare ksue funziona per passare dall'utente A all'utente B
      • Heimdal ksu(in /usr/bin) non ha SUID impostato di default
        • Per far ksufunzionare Heimdal ,chmod u+s /usr/bin/ksu
      • MIT Kerberos ( krb5pacchetto installato in /usr/local/bin) è SUID all'installazione
    • Poiché Heimdal fa parte del pacchetto base, avrai entrambi i set di binari Kerberos.
      • Potresti voler regolare i percorsi predefiniti in modo che /usr/local/binsia prima /usr/bin, ecc
    • ksu richiederà all'utente la password AD / Kerberos dell'utente di destinazione
    • passwdnon funzionerà per modificare la password di AD / Kerberos anche se si aggiunge pam_sss.soal file PAM passwd. Il passwdbinario supporta solo l'uso locale e NIS kpasswdper modificare la password sui server AD / Kerberos.

  • Interruttore servizio nome:

    • Il /etc/nsswitch.conffile deve essere configurato per utilizzare il servizio sss per passwd e gruppi. Esempio:
      • group: files sss
      • passwd: files sss

  • Iscrizione a un dominio:

    • Ci sono due strumenti principali su * nix per unire la tua scatola di Linux
      • adcli
        • Questo è il mio strumento preferito. Funziona molto bene e tutto può essere fatto su una singola riga di comando. Le credenziali possono essere fornite in modo non interattivo (tramite stdin, ecc.)
        • Non richiede di fare un kinitprima dell'uso, lo fa per te in base ai crediti forniti.
          • Esempio:
            • adcli join -D mydomain.net -U Administrator--show-details –v
            • adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
              • Questo modulo è consigliato poiché l'utilità non riesce sempre a capire correttamente l'FQDN. Quando si fornisce il nome FQDN che corrisponde sia al DNS forward sia a quello reverse per l'host, i principi vengono creati correttamente. Se l'utilità utilizza un nome host errato (escluso il dominio DNS, ad esempio), alcune entità del servizio non verranno create e cose come SSH nell'host potrebbero non riuscire.
      • netUtilità Samba
        • L' netutilità fa parte della suite Samba.
        • Questa utility richiede che i dettagli del dominio siano impostati nel smb.conffile di configurazione, il che rende più difficile e scomodo da usare, soprattutto in modo non interattivo.
        • Questo strumento richiede anche che tu ottenga un ticket Kerberos prima di usarlo usando kinit. Ancora una volta, questo è più scomodo e rende un po 'più difficile l'uso in modo non interattivo in uno script, poiché ci sono due passaggi anziché uno.
          

  • Considerazioni su SSHD:

    • Far funzionare SSHD con AD e SSSD è in genere abbastanza semplice
    • È necessario aggiungere le seguenti opzioni /etc/ssh/sshd_config
      • GSSAPIAuthentication yes
        • Attiva l'autenticazione API GSS per SSHD. Ciò causerà l'autenticazione di SSHD rispetto al KDC AD
      • PasswordAuthentication yes
        • Consenti agli utenti di accedere con password. Richiesto se si desidera che un utente ottenga un ticket KRB5 al momento dell'accesso. Senza questo abilitato, il sistema non può decodificare il TGT inviato dal KDC.
      • ChallengeResponseAuthentication yes
        • Per FreeBSD, questo metodo sembra funzionare meglio.
          • Assicurati di configurare PasswordAuthentication noquando usi questa opzione.
          • Questo è l'unico metodo che ho trovato per FreeBSD che funziona per cambiare una password scaduta al momento dell'accesso. Se usi l'altro, chiama /bin/passwd, che non supporta nient'altro che NIS e file passwd locale.
      • GSSAPICleanupCredentials yes
        • (facoltativo) eseguirà un kdestroylogout
      • GSSAPIStrictAcceptorCheck no
        • (facoltativo) Questa opzione è spesso richiesta se SSHD è confuso riguardo al proprio nome host, è multihomed, ecc. o utilizza in altro modo un'entità servizio diversa per comunicare con il KDC. Normalmente SSHD utilizzerà l'entità servizio host/<FQDN>@REALMper parlare con il KDC, ma a volte lo sbaglia (ad esempio, se il nome host non corrisponde al nome DNS del server SSH). Questa opzione consente a SSHD di utilizzare qualsiasi entità nel /etc/krb5.keytabfile, che include quella correttahost/<FQDN>@REALM
    • A seconda della combinazione di opzioni utilizzate, potrebbe essere necessario o meno aggiungere entità host al KDC affinché gli indirizzi IPv4 e IPv6 dell'host ssh -K <ip>funzionino senza richiedere una password (supponendo che abbiate già fatto un "parent"), ovviamente).