version 1.02, 30 agosto 2013
Michele Liberi, team gestione sistemi UNIXQuesto documento descrive un sistema integrato per la gestione degli utenti unix Maserati.
Lo scopo principale del progetto è quella di razionalizzare la gestione degli utenti unix e ridurre al minimo il carico gestionale legato a questa attività.
Un altro motivo importante è quello di gestire in modo unico situazioni che verrebbero altrimenti gestite in modo diverso sui vari sistemi operativi (AIX, Linux), ad esempio la scadenza della password.
L'idea di fondo è quella di concentrare tutte le informazioni degli utenti in un unico database.
Ogni inserimento o modifica al database degli utenti centralizzato fa scattare immediatamente ed automaticamente le attività di rigenerazione dei database utenti locali ai vari sistemi unix in architettura. L'azione di refresh può essere invocata anche manualmente su uno o più sistemi slave.
Tra una modifica e l'altra i sistemi unix lavorano con il database utenti locale e non hanno alcuna interazione con il database centralizzato, perciò l'architettura risulta essere molto robusta perché non dipende dalla disponibilità di un servizio di rete.
L'accesso al sistema può avvenire con applicazione web o da linea di comando.
Funzionalità e ruoli
Il cambio password
Ogni utente può cambiare la propria password alla pagina https://sharezone.maserati.com/cgi-bin/pwdchg a cui si può accedere anche dalla pagina di login di share zone.
La password di un utente può essere impostata anche dall'amministratore, in tal caso l'utente sarà obbligato a impostarne una propria prima di poter accedere ai sistemi.
Il sistema mantiene la storia delle password impostate per ogni utente, e impedisce il riutilizzo delle ultime cinque.
Se un utente cerca di fare login con una password sbagliata per cinque volte, l'utenza viene temporaneamente bloccata, per un'ora al massimo.
Per evitare confusione e/o possibili malintesi il comando standard 'passwd' deve essere disabilitato.
Gestione utenti
Tutte le altre funzione per gestire il database degli utenti sono riservate all'amministratore di sistema.
Notifiche
Le notifiche hanno un ruolo importante nell'architettura del sistema. La tabella che segue ne descrive il funzionamento:
| evento | mezzo | destinatario | contenuto |
|---|---|---|---|
| creazione utente | utente | benvenuto e link per il primo cambio password obbligatorio | |
| inserimento utente in un dominio | utente | notifica di possibilità di accesso alle macchine del dominio | |
| password set | utente | nuova password di accesso e link per il primo cambio password obbligatorio | |
| password reset | utente | nuova password di accesso e link per il primo cambio password obbligatorio |
Per ora consideriamo alcune possibili vie per accedere ai sistemi:
ed i seguenti obiettivi:
Per ognuno dei precedenti obiettivi e per ogni sistema operativo unix bisogna identificare quale sia il parametro da impostare.
A seguito dei test effettuati in ambiente AIX e Linux, i parametri rilevanti al fine del raggiungimento dei nostri obiettivi sono:
AIX
La struttura del file /etc/shadow (man shadow) è la seguente:
struct spwd {
char *sp_namp; /* user login name */
char *sp_pwdp; /* encrypted password */
long sp_lstchg; /* last password change */
int sp_min; /* days until change allowed. */
int sp_max; /* days before change required */
int sp_warn; /* days warning for expiration */
int sp_inact; /* days before account inactive */
int sp_expire; /* date when account expires */
int sp_flag; /* reserved for future use */
}
I parametri che ci interessano sono:
Il database centrale è basato su WOHA (Web Oriented Hyerarchical Archiver), tutti i dati in esso contenuti sono salvati su filesystem (woha.unix.masad.it:/woha/mum). In questo modo essi sono facilmente accessibili e reperibili dai comandi unix.
I metodi sono delle script bash, in qualche caso compilate.
Nel database ci sono diverse classi, ognuna provvista dei propri metodi per manipolare i dati:
La classe 'hosts' mantiene la lista delle macchine unix il cui database degli utenti dipende da quello centralizzato.
L'insieme delle macchine slave è ripartito in domini, ogni macchina appartiene ad uno ed un solo dominio.
Le macchine dello stesso dominio condividono lo stesso insieme di utenti.
Attributi hosts
Un meccanismo di sicurezza garantisce che nei files di configurazione sia sempre presente l'utente root, anche nel caso in cui esso non sia presente nella classe 'users'. In tal caso la password di root viene impostata a '...---...' (SOS in alfabeto morse).
Inoltre su AIX ad ogni refresh viene resettato il contatore dei login falliti (unsuccessfull_login_count nel file /etc/security/lastlog). Poiché il refresh è schedulato a crontab con cadenza oraria, il blocco dell'utenza a causa dei tentativi di login falliti è temporaneo.
Oltre alle informazioni presenti nel database, la funzione di refresh utilizza i seguenti files:
Per la gestione di alias di posta, o per indirizzi di e-mail non personali, il comando refresh utilizza inoltre il file .aliases.$domain (uno per ogni dominio).
Gli host con l'attributo hactive=false vengono ignorati dalla funzione refresh.
La funzione di refresh rigenera anche il file delle password utilizzato da sharezone, mediante chiamata al comando aix2apache su ghibli-svc.
La classe groups mantiene la lista dei gruppi di utenti.
I gruppi sono indipendenti dal dominio, una volta definiti sono validi per tutti i domini.
Attributi groups
La classe users contiene gli utenti dell'azienda, le informazioni contenute in questa classe sono indipendenti dal dominio.
Le informazioni legate all'utenza che invece dipendono dal dominio sono nella classe 'uxd'.
Attributi users
Tabella di relazione tra utenti e domini.
Contiene anche informazioni relativi all'utente che sono specifiche per il dominio.
In questo modo un utente potrebbe avere, ad esempio, gid=125 (bsp) nel dominio baanm e gid=200 (catia) nel dominio cadm.
Attributi uxd
Tabella di relazione tra utenti e gruppi
Attributi uxg
Questa classe non ha metodi.
L'interfaccia grafica
L'amministrazione degli utenti avviene accedendo, dalla intranet Maserati, alla pagina http://woha.unix.masad.it.
Dopo aver fornito le credenziali di root, si avranno a disposizione tutte le funzioni del woha che permettono, di base, di fare delle query sui dati presenti nel database, e di fare operazioni di inserimento, modifica e cancellazione di oggetti presenti nelle classi.
Le operazioni di inserimento, modifica o cancellazione fanno scattare in modo automatico, ove previsto, i metodi descritti nel capitolo precedente.
Altri metodi invece possono essere richiamati esplicitamente tramite selezione da un menu a tendina.
L'interfaccia a linea di comando
L'interfaccia a linea di comando permette di fare alcune operazioni sul database direttamente da linea di comando e quindi consente di interagire con il MUM da shell script.
Il comando da lanciare è 'mum' e funziona solo sulla macchina su cui è installato il MUM, cioè boomerang.
Lanciato con l'opzione -h produce un help dei comandi disponibili e della sintassi con la quale devono essere lanciati:
mum, written by M.Liberi, ver. 1.00, aug 2013
Maserati User Management command line interface
refresh [hostname]... (default all)
sync [domain]... (default all)
setpwd new_password username...
resetpwd username...
newgrp groupname [gid]
rmgrp groupname...
uxg+ username group...
uxg- username group...
uxd+ username {*|domain} [type] [attr=value]...
types: aix, cad, baan, ftp, ddt
attributes: default (environment):
gid 1
groups
gecos name surname
home /home/$username
shell /usr/bin/ksh
uxd- username {*|domain}...
newusr username [attr=value]...
attributes: default (environment):
uid auto generated
name
surname
cdc
email
mobile
expires
pwd random()
crypt crypt(pwd)
lastupdate now
syntax: mum [option]... command [args]
-h this help screen
-- no more options
-v verbose
Questo comando lancia il metodo refresh della classe hosts, quindi andrà a rigenerare tutti i files di configurazione dei database utenti unix partendo dalle informazioni contenute nel database del MUM.
Il refresh avverrà su tutti gli hostnames presenti nella tabella hosts, a meno che non venga specificata una ben precisa lista di hostnames.
In ogni caso gli hostname con l'attributo hactive=false non vengono toccati.
mum sync
Questo comando è molto simile al precedente, ma lavora a livello di dominio e non di singolo host.
Il refresh avverrà su tutti gli hostnames dei domini specificati.
mum setpwd
Tramite questo comando è possibile richiamare il metodo setpwd della classe users, per impostare una determinata password ad uno o più utenti.
Partirà una e-mail di notifica all'utente, che sarà obbligato a cambiare la password prima di poterla utilizzare.
mum resetpwd
Tramite questo comando è possibile richiamare il metodo resetpwd della classe users, per impostare una determinata password ad uno o più utenti.
Partirà una e-mail di notifica all'utente, che sarà obbligato a cambiare la password prima di poterla utilizzare.
mum newgrp
Tramite questo comando è possibile richiamare il metodo new della classe groups,
per creare un nuovo gruppo.
Il gid può essere specificato come argomento, fermo restando che dev'essere univico.
In caso contrario verrà allocato un gid libero maggiore o uguale a 30000.
mum rmgrp
Tramite questo comando è possibile cancellare una riga dalla tabella groups.
Automaticamente verranno rimossi gli utenti appartenenti al gruppo dalla tabella uxg.
mum uxg+
Aggiunge un utente ad uno o più gruppi, a mezzo inserimento di una o più righe nella tabella uxg.
mum uxg-
Cancella un utente da uno o più gruppi, a mezzo cancellazione di una o più righe dalla tabella uxg.
mum uxd+
Aggiunte un utente ad un dominio, a mezzo inserimento di una riga nella tabella uxd. Contestualmente l'utente può essere inserito in uno o più gruppi aggiuntivi, a mezzo inserimento di una o più righe nella tabella uxg.
Se si passa un '*' al posto del nome del dominio, l'utenza verrà creata in tutti i domini.
Tutti gli attributi della classe uxd possono essere specificati singolarmente nella riga di comando. Inoltre è previsto un parametro groups, non presente in tabella, per l'inserimento dell'utente in gruppi aggiuntivi.
Specificando un tipo utente si impostano contemporaneamente più attributi, in base al seguente schema:
| tipo | gid | primary group | groups | home | shell |
|---|---|---|---|---|---|
| aix | 1 | staff | /home/$username | /usr/bin/ksh | |
| cad | 200 | catia | printq | /export/home/$username | /usr/bin/ksh |
| baan | 125 | bsp | mqm | /home/$username | /usr/bin/ksh |
| ftp | 1 | staff | /fsftp/$username | /usr/bin/ksh | |
| ddt | 1 | staff | /fsftp/acq/ddt/$username | /usr/bin/ksh |
L'aggiunta di un utente ad un dominio implica l'invio di una e-mail di notifica all'utente.
mum uxd-
Tramite questo comando è possibile cancellare una riga dalla tabella uxd. Di fatto l'utente, pur rimanendo definito nel database MUM, non esisterà più a livello del sistema operativo.
N.B.: le home directories dell'utente non vengono cancellate.
L'amministratore provvederà, cum grano salis, a farlo se necessario.
mum newusr
Tramite questo comando è possibile inserire un record nella tabella users.
Tutti gli attributi della classe users possono essere passati come argomenti del comando.
Se manca l'uid verrà utilizzato il primo libero maggiore o uguale a 30000.
Integrazione con il vecchio sistema Ferrari/Maserati
Il MUM va a sostituire il sistema udb, comune tra Ferrari e Maserati.
Poiché il sistema udb rimane attivo in Ferrari è stato necessario apportara ad esso alcune modifiche.
Maserati ha chiesto, in sede di stesura delle specifiche, che la separazione tra Ferrari e Maserati dev'essere il più netta possibile e l'interazione tra i due sistemi ridotta al minimo indispensabile.
Quando andremo live con il Maserati User Management (MUM) tutti i domini maserati verranno tolti dalla configurazione della udb.
Il MUM potrà essere utilizzato tramite applicazione web (woha), tramite command line (comando 'mum' su boomerang) e tramite udb, che però è stata modificata in modo che si comporti diversamente in base al fatto che venga lanciata su un server Ferrari o Maserati.
Il MUM è stato progettato come sistema indipendente e non prevede interazione con la complessa e inefficiente struttura della vecchia gestione integrata degli utenti Ferrari/Maserati.
Il comando 'udb' invece deve necessariamente prevedere una integrazione dei due ambienti, con la seguente logica:
Ferrari: il gid viene generato senza tener conto del MUM, il gruppo viene creato in tutti i domini gestiti da udb (quindi solo in Ferrari)
Maserati: il gid viene generato senza tener conto dei gid Ferrari nel range da 30000 in su, il gruppo viene creato solo nel MUM
La non collisione dei gid viene garantita dal fatto che l'allocazione degli stessi avviene in range diversi, ma nulla impedisce che possano esistere nei due sistemi due gruppi con lo stesso nome e gid diversi. Ciò a mio avviso non rappresenta un problema.
Comunque il MUM prevede la possibilità di specificare un gid al momento della creazione, o di modificarlo successivamente, quindi le eccezioni possono essere gestite manualmente.
Ferrari: il gruppo viene cancellato in tutti i master di dominio
Maserati: il gruppo viene cancellato dal MUM
Ferrari: azione eseguita solo sui domini udb
Maserati: azione eseguita solo sul MUM
Ferrari: l'uid viene generato senza tener conto del MUM, l'utente viene creato solo nel dominio locale
Maserati: l'uid viene generato, senza tener conto degli uid Ferrari, nel range da 30000 in su, l'utente viene creato solo nel MUM
La non collisione degli uid viene garantita dal fatto che l'allocazione degli stessi avviene in range diversi, ma nulla impedisce che possano esistere nei due sistemi due utenti con lo stesso nome e uid diversi. Ciò a mio avviso non rappresenta un problema.
Comunque il MUM prevede la possibilità di specificare un uid al momento della creazione, o di modificarlo successivamente, quindi le eccezioni possono essere gestite manualmente.
Ferrari: l'utente viene cancellato dal dominio locale
Maserati: funzione non attiva, la cancellazione di un utente può avvenire solo (in casi eccezionali) utilizzando l'interfaccia grafica
Ferrari: il cambio avviene sui master di dominio
Maserati: il cambio avviene nel MUM
Ciò comporta che lo stesso utente potrebbe avere password diverse nelle due aziende. Ciò non rappresenta un problema.
Ferrari: la sincronizzazione avviene solo nel dominio locale
Maserati: la sincronizzazione avviene nel MUM solo per la macchina locale