8410
Comment:
|
12864
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
== Configurazione di Samba 4 come Domain Controller Active Directory == Questi sono appunti preliminari, scritti purtroppo senza avere chiaro come funziona ogni singolo pezzo. Il punto di partenza e` l'howto dal sito di Samba, qui: https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO === Prerequisiti === |
= Configurazione di Samba 4 come Domain Controller Active Directory = Configurazione di Samba 4 su Debian 9 e 10 / Devuan Ascii e Beowulf Il punto di partenza e` l'howto dal sito di Samba, qui: https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO == Prerequisiti == |
Line 9: | Line 12: |
* Non ci deve essere un DNS server sulla macchina che fa da AD, perche` lo fa Samba (o almeno e` cosi` di default) | * Non ci deve essere un DNS server sulla macchina che fa da AD, perche` lo fa Samba e non si puo` fare diversamente. Per impostare correttamente il DNS in modo da non avere problemi, se necessario, verificare prima come gestire dnsmasq con samba per non farli cozzare. E` importante avere il DNS di Samba funzionante senza che cozzi con altri programmi per l'uso della porta 53 perche` altrimenti poi anche il provisioning sembra funzionare ma fallisce, e i test non passeranno, a partire dal primo. Fare riferimento anche a: [[../IntegrazioneSambaDnsmasq]] * I client che saranno joinati al dominio dovranno usare come DNS server quello contenuto in Samba (oppure un DNS che sappia appoggiarsi a quello contenuto in Samba). Fare riferimento anche a: [[../IntegrazioneSambaDnsmasq]] |
Line 13: | Line 17: |
=== Installazione di Samba in Debian === Ho usato Samba 4 dai backport di Debian Wheezy in questa installazione. Dopo aver configurato il repo da backports.debian.org, occorre installare Samba: {{{ aptitude update aptitude -t wheezy-backports install samba smbclient aptitude install acl }}} Ragionevolmente se usate Debian Jessie (spero per voi senza systemd) allora non serve usare i backports. Questa installazione, allo stato attuale delle cose, fornisce Samba 4.1.17, che pero` ha qualche limite. In alternativa, si puo` installare Samba da Sernet. === Installazione di Samba da Sernet === * Vai su https://portal.enterprisesamba.com/ e segui le istruzioni per installare samba piu` moderno (al momento 4.2.x) * Installa il pacchetto {{{sernet-samba-ad}}} che si porta dietro le dipendenze richieste * Modifica il file /etc/default/sernet-samba per impostare {{{SAMBA_START_MODE="ad"}}} * Ricorda che gli script di init si chiamano sernet-samba-qualcosa, e che quello che ti interessa usare e` {{{/etc/init.d/sernet-samba-ad}}} Il vantaggio di usare Samba 4.2.x e` che si puo` fare un file server facilmente sul DC, cosa che e` sconsigliatissima prima della 4.2. Per poter vedere correttamente gli utenti di Samba dal sistema (sulla macchina stessa del DC AD), usando samba 4.2 o superiore, e` sufficiente verificare che winbindd stia girando (ps ax) e poi modificare il file {{{/etc/nsswitch.conf}}} come segue: {{{ passwd: compat winbind group: compat winbind }}} === Configurazione di NTP === Ntp deve essere installato sul DC (e l'abbiamo gia` detto). Pero` deve anche essere configurato. Occorre che NTPD legga un socket messo a disposizione da Samba (per la quale cosa faremo apposita configurazione), che supporti ntptd_signd (Quello di Debian 7 e` a posto), e ovviamente che sia accessibile dai client del dominio sulla LAN. Per ottenre questo risultato, dobbiamo: * Installare NTP dal pacchetto Debian * Verificare i permessi della directory {{{/var/lib/samba/ntp_signd}}}, la quale deve poter essere letta dal server NTP, che gira con user e gruppo "ntp". Modifichiamo i permessi come segue: {{{ chgrp ntp /var/lib/samba/ntp_signd chmod 750 /var/lib/samba/ntp_signd }}} * Modificare {{{/etc/ntp.conf}}} per leggere questo socket, aggiungendo solo questa riga: {{{ ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/ }}} * Riavviare ntp === Provisioning del dominio === Prima di partire, occorre ricordare che il dominio AD funziona con il DNS, ergo e` esigente e invadente al riguardo. Occorre controllare che l'hostname fully qualified (con anche il dominio) del server dove stiamo installando Samba sia congruente con quello che sara` il nome del dominio AD, e sia risolvibile correttamente sia dal server stesso che dai client che poi aggiungeremo, sia a dritto che a rovescio. Qui le best practice sono tante e non tutte concordano, ma il senso importante e` che il nome del dominio AD '''NON SI CAMBIA MAI PIU`''' dopo averlo impostato. Molti suggeriscono di usare un subdomain di un nome di dominio ufficiale e registrato (tipo ad esempio dominiosamba.pippo.it) ma io nell'unica prova che ho fatto ho preferito usare un dominio non registrato pubblicamente, tipo "nomeazienda.locale". Badate bene di NON usare ".local" che e` stato "rubato" da Avahi (Bonjour) e quindi ci sarebbero problemi nella risoluzione dei nomi. Se si prevede di avere una "foresta" (come la chiama MS) di domini correlati, allora occorre considerare bene la scelta dei nomi, ma questo va oltre lo scopo attuale del sottoscritto, che e` di avere un dominio AD e basta. Essendo una nuova installazione, partiamo da zero. |
== Installazione di Samba == * Installare normalmente i pacchetti di Samba "ufficiali" più alcuni pacchetti di contorno: {{{ apt install acl attr samba samba-dsdb-modules samba-vfs-modules winbind libpam-winbind libnss-winbind libpam-krb5 krb5-config krb5-user dnsutils smbclient }}} * ignorare le domande relative alla config di Kerberos, che tanto dovremo rifarla dopo. * '''ATTENZIONE:''' installando libpam-winbind si autorizzano di default gli utenti di Samba ad accedere in ssh. Questo potrebbe essere molto pericoloso. Se non volete che succeda, usate il comando {{{pam-auth-update}}} (dopo aver installato i pacchetti) e disattivate l'opzione di usare Samba come fonte di autenticazione per PAM == Provisioning del dominio == Prima di partire, occorre ricordare che il dominio AD funziona con il DNS, ergo e` esigente e invadente al riguardo. Occorre controllare che l'hostname fully qualified (con anche il dominio) del server dove stiamo installando Samba sia congruente con quello che sara` il nome del dominio AD (per esempio, "server01.dominio.locale"), e sia risolvibile correttamente sia dal server stesso che dai client che poi aggiungeremo, sia a dritto che a rovescio. Qui le best practice sono tante e non tutte concordano, ma la cosa importante e` che il nome del dominio AD '''NON SI CAMBIA MAI PIU`''' dopo averlo impostato. Molti suggeriscono di usare un subdomain di un nome di dominio ufficiale e registrato (tipo ad esempio dominiosamba.example.com) ma io preferisco usare un dominio non registrato pubblicamente, tipo "nomeazienda.locale". Badate bene di NON usare ".local" che e` stato "rubato" da Avahi (Bonjour) e quindi ci sarebbero problemi nella risoluzione dei nomi. Se si prevede di avere una "foresta" (come la chiama MS) di domini correlati, allora occorre considerare bene la scelta dei nomi, ma questo va oltre lo scopo attuale del sottoscritto, che e` di avere un dominio AD e basta. Essendo una nuova installazione, partiamo da zero con il provisioning di un dominio "vergine". Prima di farlo, mi assicuro di non avere configurazioni pregresse o di default che non mi siano gradite. |
Line 73: | Line 37: |
* Cancellare o rinominare /etc/smb.conf * Effettuare il provisioning del dominio con il comando samba-tool {{{ samba-tool domain provision --use-rfc2307 --interactive |
* Cancellare o rinominare il file {{{/etc/samba/smb.conf}}} * Se ci sono, cancellare tutti i files tdb e ldb. Un metodo per trovarli è questo: {{{ smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR" }}} * Cancellare o rinominare, se c'è, il file {{{/etc/krb5.conf}}} * Effettuare il provisioning del dominio con il comando samba-tool (Se il server ha piu` di una NIC, scegliere quella giusta per Samba a mezzo delle due option relative alle interfacce. Se ne ha una sola non e` necessario) {{{ samba-tool domain provision --use-rfc2307 --interactive --option="interfaces=lo eth0" --option="bind interfaces only=yes" |
Line 80: | Line 49: |
Se tutto ha funzionato senza errori, si puo` riavviare Samba. |
|
Line 83: | Line 50: |
* un file /etc/smb.conf (guardateci dentro) | * un file /etc/samba/smb.conf (guardateci dentro) |
Line 90: | Line 57: |
=== Test === | == Reimpostare il resolver DNS == Samba vuole risolvere i suoi nomi interni per funzionare, ergo se il server dove e` installato samba usa come DNS un altro DNS che non sia se` stesso, o che non sia in qualche modo configurato per richiedere a Samba i nomi giusti, allora Samba quando si avvia dara` errori nel log (e non so poi se possa funzionare bene). Il bello di Samba in versione AD e` che e` semplice (attenzione: questo è sarcasmo). Quindi, la cosa piu` facile da fare e` impostare sul nostro domain controller in {{{/etc/resolv.conf}}} il dns per essere localhost (127.0.0.1) oppure l'ip della nostra interfaccia alla quale abbiamo bindato Samba {{{ # file /etc/resolv.conf search <il mio dominio>.locale nameserver <il mio ip> (oppure 127.0.0.1) }}} Di default il DNS interno di Samba non conterrà una zona reverse per gli ip della mia lan. Questo non è necessariamente un problema, se ne può fare a meno e comunque se si usa una integrazione con Dnsmasq la zona reverse può essere gestita da Dnsmasq stesso, sia staticamente che tramite le assegnazioni del DHCP. Attenzione, però : la reverse zone per la nostra LAN, se locale su Samba, non risolverà nulla che non sia dentro di essa stessa. In altri termini, non credo proprio che Samba, se un lookup locale fallisce, passi la palla a Dnsmasq. Del comportamento opposto non sono sicuro, invece. Devo indagare. == Configurazione di Kerberos == Samba usa kerberos internamente per autenticare utenti, macchine, ecc. (Sono ignorante per cui non so esattamente come, quando, e perché. Tuttavia, è opportuno che kerberos funzioni localmente, quindi provvediamo a copiare (non symlinkare, ma copiare!) la configurazione autogenerata da Samba durante il provisioning dentro a /etc, come segue) {{{ cp /var/lib/samba/private/krb5.conf /etc/krb5.conf }}} == Configurazione di NTP == Ntp deve essere installato sul DC (e l'abbiamo gia` detto). Pero` deve anche essere configurato. Occorre che NTPD legga un socket messo a disposizione da Samba (per la quale cosa faremo apposita configurazione), che supporti ntptd_signd, e ovviamente che sia accessibile dai client del dominio sulla LAN. Per ottenre questo risultato, dobbiamo: * Installare NTP dal pacchetto Debian * Creare la directory {{{/var/lib/samba/ntp_signd}}}, la quale deve poter essere letta dal server NTP, che gira con user e gruppo "ntp". * Se questa directory esiste già, vuole dire che abbiamo già lanciato Samba almeno una volta. Non è un problema, basta mettere a posto i permessi. {{{ mkdir /var/lib/samba/ntp_signd chgrp ntp /var/lib/samba/ntp_signd chmod 750 /var/lib/samba/ntp_signd }}} * Modificare {{{/etc/ntp.conf}}} per leggere questo socket: {{{ # aggungere queste righe: ntpsigndsocket /var/lib/samba/ntp_signd tinker panic 0 # modificare queste righe (mssntp aggiunto in fondo a tutte e due) restrict -4 default kod notrap nomodify nopeer noquery mssntp restrict -6 default kod notrap nomodify nopeer noquery mssntp }}} * Riavviare ntp * Verificare nel syslog che NTP riporti questo messaggio: {{{ntpd[xxxxx]: MS-SNTP signd operations currently block ntpd degrading service to all clients.}}} * Nel dubbio riavviare Samba * Per verificare se un client joinato al dominio legge correttamente NTP, eseguire un CMD come amministratore e usare il comando {{{ w32tm /resync }}} == Configurare nnswitch == Per poter vedere correttamente gli utenti di Samba dal sistema (sulla macchina stessa del DC AD), usando samba 4.2 o superiore, e` sufficiente verificare che winbindd stia girando (ps ax) e poi modificare il file {{{/etc/nsswitch.conf}}} come segue: (potrebbe essere che troviate "compat" al posto di "files", in quel caso mettete "compat winbind") {{{ passwd: files winbind group: files winbind }}} (occorre che le librerie libnss-winbind libpam-winbind siano installate) == Avviare Samba == * Assicuratevi che non ci siano smbd in esecuzione da prima. (killateli nel caso) * Eseguite {{{/etc/init.d/samba-ad-dc start}}} == Test == |
Line 142: | Line 186: |
Nell' HOWTO si parla anche di un test con Kerberos, senza pero` dire nulla di piu`. A quanto ho capito io non e` necessario installare il client Kerberos sul server AD, se non per il test. Magari ho capito male. In ogni caso, la procedura per installare il client Kerberos e`: {{{ aptitude -t wheezy-backports install heimdal-clients cd /etc/ mv krb5.conf krb5.conf.originale ln -s /var/lib/samba/private/krb5.conf /etc/krb5.conf }}} |
Test di Kerberos: |
Line 156: | Line 192: |
Notare che il dominio deve essere in maiuscolo! | Notare che il dominio deve essere in maiuscolo (e credo possa essere omesso, dovrebbe risolverlo da solo) |
Line 173: | Line 209: |
=== Test dell'integrazione con il sistema (solo per samba 4.2.x o superiore) === * Verificare se Winbind legge correttamente i dati da Samba (devi vedere i gruppi e gli utenti di Samba come output) |
== Test dell'integrazione con il sistema == * Verificare se Winbind vede il domain controller: {{{ wbinfo --ping-dc }}} * Verificare se Winbind legge correttamente i dati da Samba (devi vedere i gruppi e gli utenti di Samba come output). Nelle versioni più recenti di Samba si possono trovare ulteriori gruppi oltre quelli elencati qui. |
Line 178: | Line 219: |
administrator krbtgt guest |
|
Line 179: | Line 226: |
enterprise read-only domain controllers domain admins domain users domain guests domain computers domain controllers schema admins enterprise admins group policy creator owners read-only domain controllers dnsupdateproxy |
|
Line 183: | Line 243: |
uid=0(root) gid=0(root) groups=0(root) id guest uid=3000011(guest) gid=3000012(domain guests) groups=3000012(domain guests),3000011(guest),3000015(BUILTIN\guests) |
|
Line 184: | Line 251: |
}}} | getfacl: Removing leading '/' from absolute path names # file: var/lib/samba/sysvol # owner: root # group: BUILTIN\134administrators user::rwx user:root:rwx user:BUILTIN\134administrators:rwx group::rwx group:BUILTIN\134administrators:rwx group:BUILTIN\134server\040operators:r-x group:3000002:rwx group:3000003:r-x mask::rwx other::--- default:user::rwx default:user:root:rwx default:user:BUILTIN\134administrators:rwx default:group::--- default:group:BUILTIN\134administrators:rwx default:group:BUILTIN\134server\040operators:r-x default:group:3000002:rwx default:group:3000003:r-x default:mask::rwx default:other::--- }}} |
Configurazione di Samba 4 come Domain Controller Active Directory
Configurazione di Samba 4 su Debian 9 e 10 / Devuan Ascii e Beowulf
Il punto di partenza e` l'howto dal sito di Samba, qui: https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO
Prerequisiti
- Samba richiede l'uso delle ACL Posix e degli attributi estesi sul file system. Occorre quindi usare ext4 (che li supporta di default) oppure abilitarli sul file system che volete usare.
Non ci deve essere un DNS server sulla macchina che fa da AD, perche` lo fa Samba e non si puo` fare diversamente. Per impostare correttamente il DNS in modo da non avere problemi, se necessario, verificare prima come gestire dnsmasq con samba per non farli cozzare. E` importante avere il DNS di Samba funzionante senza che cozzi con altri programmi per l'uso della porta 53 perche` altrimenti poi anche il provisioning sembra funzionare ma fallisce, e i test non passeranno, a partire dal primo. Fare riferimento anche a: ../IntegrazioneSambaDnsmasq
I client che saranno joinati al dominio dovranno usare come DNS server quello contenuto in Samba (oppure un DNS che sappia appoggiarsi a quello contenuto in Samba). Fare riferimento anche a: ../IntegrazioneSambaDnsmasq
- Usare NTP perche` la sincronizzazione dell'ora e` importante (anche nei member server. Sui client windows si arrangia a chiedere NTP al DC)
Installazione di Samba
- Installare normalmente i pacchetti di Samba "ufficiali" più alcuni pacchetti di contorno:
apt install acl attr samba samba-dsdb-modules samba-vfs-modules winbind libpam-winbind libnss-winbind libpam-krb5 krb5-config krb5-user dnsutils smbclient
- ignorare le domande relative alla config di Kerberos, che tanto dovremo rifarla dopo.
ATTENZIONE: installando libpam-winbind si autorizzano di default gli utenti di Samba ad accedere in ssh. Questo potrebbe essere molto pericoloso. Se non volete che succeda, usate il comando pam-auth-update (dopo aver installato i pacchetti) e disattivate l'opzione di usare Samba come fonte di autenticazione per PAM
Provisioning del dominio
Prima di partire, occorre ricordare che il dominio AD funziona con il DNS, ergo e` esigente e invadente al riguardo. Occorre controllare che l'hostname fully qualified (con anche il dominio) del server dove stiamo installando Samba sia congruente con quello che sara` il nome del dominio AD (per esempio, "server01.dominio.locale"), e sia risolvibile correttamente sia dal server stesso che dai client che poi aggiungeremo, sia a dritto che a rovescio. Qui le best practice sono tante e non tutte concordano, ma la cosa importante e` che il nome del dominio AD NON SI CAMBIA MAI PIU` dopo averlo impostato. Molti suggeriscono di usare un subdomain di un nome di dominio ufficiale e registrato (tipo ad esempio dominiosamba.example.com) ma io preferisco usare un dominio non registrato pubblicamente, tipo "nomeazienda.locale". Badate bene di NON usare ".local" che e` stato "rubato" da Avahi (Bonjour) e quindi ci sarebbero problemi nella risoluzione dei nomi. Se si prevede di avere una "foresta" (come la chiama MS) di domini correlati, allora occorre considerare bene la scelta dei nomi, ma questo va oltre lo scopo attuale del sottoscritto, che e` di avere un dominio AD e basta.
Essendo una nuova installazione, partiamo da zero con il provisioning di un dominio "vergine". Prima di farlo, mi assicuro di non avere configurazioni pregresse o di default che non mi siano gradite.
- Fermare samba
Cancellare o rinominare il file /etc/samba/smb.conf
- Se ci sono, cancellare tutti i files tdb e ldb. Un metodo per trovarli è questo:
smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"
Cancellare o rinominare, se c'è, il file /etc/krb5.conf
- Effettuare il provisioning del dominio con il comando samba-tool (Se il server ha piu` di una NIC, scegliere quella giusta per Samba a mezzo delle due option relative alle interfacce. Se ne ha una sola non e` necessario)
samba-tool domain provision --use-rfc2307 --interactive --option="interfaces=lo eth0" --option="bind interfaces only=yes"
- Rispondere alle domande (e ricordarsi la password impostata per administrator). Attenzione alla policy di default per la password: almeno 8 caratteri con almeno un simbolo o un numero e una maiuscola e una minuscola se ricordo bene.
Il tool di provisioning avra` creato una serie di cose:
- un file /etc/samba/smb.conf (guardateci dentro)
- due share di sistema necessari (indicati in smb.conf), che come potete vedere hanno gia` impostati attributi estesi, ACL posix, e appartengono a un gruppo che non esiste nel sistema. Questo e` normale per Samba 4 in modo AD che a differenza di samba 3 non usa utenti e gruppi locali.
- un database LDAP dentro al suo personale server LDAP (io odio fortissimamente LDAP, ma qui e` necessario)
- Tre utenti in Samba: administrator, krbtgt e nobody.
- Un server DNS locale (integrato in Samba) che risolve i nomi buffi necessari per il funzionamento del dominio AD. Vedremo poi come usarlo.
Reimpostare il resolver DNS
Samba vuole risolvere i suoi nomi interni per funzionare, ergo se il server dove e` installato samba usa come DNS un altro DNS che non sia se` stesso, o che non sia in qualche modo configurato per richiedere a Samba i nomi giusti, allora Samba quando si avvia dara` errori nel log (e non so poi se possa funzionare bene).
Il bello di Samba in versione AD e` che e` semplice (attenzione: questo è sarcasmo).
Quindi, la cosa piu` facile da fare e` impostare sul nostro domain controller in /etc/resolv.conf il dns per essere localhost (127.0.0.1) oppure l'ip della nostra interfaccia alla quale abbiamo bindato Samba
# file /etc/resolv.conf search <il mio dominio>.locale nameserver <il mio ip> (oppure 127.0.0.1)
Di default il DNS interno di Samba non conterrà una zona reverse per gli ip della mia lan. Questo non è necessariamente un problema, se ne può fare a meno e comunque se si usa una integrazione con Dnsmasq la zona reverse può essere gestita da Dnsmasq stesso, sia staticamente che tramite le assegnazioni del DHCP. Attenzione, però : la reverse zone per la nostra LAN, se locale su Samba, non risolverà nulla che non sia dentro di essa stessa. In altri termini, non credo proprio che Samba, se un lookup locale fallisce, passi la palla a Dnsmasq. Del comportamento opposto non sono sicuro, invece. Devo indagare.
Configurazione di Kerberos
Samba usa kerberos internamente per autenticare utenti, macchine, ecc. (Sono ignorante per cui non so esattamente come, quando, e perché. Tuttavia, è opportuno che kerberos funzioni localmente, quindi provvediamo a copiare (non symlinkare, ma copiare!) la configurazione autogenerata da Samba durante il provisioning dentro a /etc, come segue)
cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
Configurazione di NTP
Ntp deve essere installato sul DC (e l'abbiamo gia` detto). Pero` deve anche essere configurato. Occorre che NTPD legga un socket messo a disposizione da Samba (per la quale cosa faremo apposita configurazione), che supporti ntptd_signd, e ovviamente che sia accessibile dai client del dominio sulla LAN.
Per ottenre questo risultato, dobbiamo:
- Installare NTP dal pacchetto Debian
Creare la directory /var/lib/samba/ntp_signd, la quale deve poter essere letta dal server NTP, che gira con user e gruppo "ntp".
- Se questa directory esiste già, vuole dire che abbiamo già lanciato Samba almeno una volta. Non è un problema, basta mettere a posto i permessi.
mkdir /var/lib/samba/ntp_signd chgrp ntp /var/lib/samba/ntp_signd chmod 750 /var/lib/samba/ntp_signd
Modificare /etc/ntp.conf per leggere questo socket:
# aggungere queste righe: ntpsigndsocket /var/lib/samba/ntp_signd tinker panic 0 # modificare queste righe (mssntp aggiunto in fondo a tutte e due) restrict -4 default kod notrap nomodify nopeer noquery mssntp restrict -6 default kod notrap nomodify nopeer noquery mssntp
- Riavviare ntp
Verificare nel syslog che NTP riporti questo messaggio: ntpd[xxxxx]: MS-SNTP signd operations currently block ntpd degrading service to all clients.
- Nel dubbio riavviare Samba
- Per verificare se un client joinato al dominio legge correttamente NTP, eseguire un CMD come amministratore e usare il comando
w32tm /resync
Configurare nnswitch
Per poter vedere correttamente gli utenti di Samba dal sistema (sulla macchina stessa del DC AD), usando samba 4.2 o superiore, e` sufficiente verificare che winbindd stia girando (ps ax) e poi modificare il file /etc/nsswitch.conf come segue: (potrebbe essere che troviate "compat" al posto di "files", in quel caso mettete "compat winbind")
passwd: files winbind group: files winbind
(occorre che le librerie libnss-winbind libpam-winbind siano installate)
Avviare Samba
- Assicuratevi che non ci siano smbd in esecuzione da prima. (killateli nel caso)
Eseguite /etc/init.d/samba-ad-dc start
Test
I test minimali li ho presi direttamente dall' HOWTO.
Prima di tutto il test con smbclient, che si fa cosi`:
smbclient -L localhost -U%
L'output e` tipo questo:
Domain=[SAMDOM] OS=[Unix] Server=[Samba 4.x.y] Sharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.x.y) Domain=[SAMDOM] OS=[Unix] Server=[Samba 4.x.y] Server Comment --------- ------- Workgroup Master --------- -------
Poi l'accesso a uno share:
smbclient //localhost/netlogon -UAdministrator -c 'ls'
L'output e` tipo questo:
Enter Administrator's password: passw0rd Domain=[SAMDOM] OS=[Unix] Server=[Samba 4.x.y] . D 0 Sat Jul 5 08:40:00 2014 .. D 0 Sat Jul 5 08:40:00 2014 49386 blocks of size 524288. 42093 blocks available
Passo successivo il test del DNS. Queste query devono dare tutte risposte sensate e mai un not found.
host -t SRV _ldap._tcp.<dominio.tld>. host -t SRV _kerberos._udp.<dominio.tld>. host -t A <hostname FQDN del domain controller>
Test di Kerberos:
La procedura di test per Kerberos richiede due comandi, kinit e klist:
kinit administrator@DOMAIN.LOCALE
Notare che il dominio deve essere in maiuscolo (e credo possa essere omesso, dovrebbe risolverlo da solo) Viene chiesta la password di administrator.
klist
Viene mostrato un output tipo questo:
Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administrator@SAMDOM.EXAMPLE.COM Valid starting Expires Service principal 07/05/14 23:20:17 07/06/14 09:20:17 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM renew until 07/06/14 23:20:15
Test dell'integrazione con il sistema
- Verificare se Winbind vede il domain controller:
wbinfo --ping-dc
- Verificare se Winbind legge correttamente i dati da Samba (devi vedere i gruppi e gli utenti di Samba come output). Nelle versioni più recenti di Samba si possono trovare ulteriori gruppi oltre quelli elencati qui.
wbinfo -u administrator krbtgt guest wbinfo -g enterprise read-only domain controllers domain admins domain users domain guests domain computers domain controllers schema admins enterprise admins group policy creator owners read-only domain controllers dnsupdateproxy
- Verificare se NSS vede utenti e gruppi di Samba
id administrator uid=0(root) gid=0(root) groups=0(root) id guest uid=3000011(guest) gid=3000012(domain guests) groups=3000012(domain guests),3000011(guest),3000015(BUILTIN\guests) getfacl /var/lib/samba/sysvol getfacl: Removing leading '/' from absolute path names # file: var/lib/samba/sysvol # owner: root # group: BUILTIN\134administrators user::rwx user:root:rwx user:BUILTIN\134administrators:rwx group::rwx group:BUILTIN\134administrators:rwx group:BUILTIN\134server\040operators:r-x group:3000002:rwx group:3000003:r-x mask::rwx other::--- default:user::rwx default:user:root:rwx default:user:BUILTIN\134administrators:rwx default:group::--- default:group:BUILTIN\134administrators:rwx default:group:BUILTIN\134server\040operators:r-x default:group:3000002:rwx default:group:3000003:r-x default:mask::rwx default:other::---