Perché ho bisogno di Kerberos quando potrei semplicemente usare un nome utente e una password per accedere ai servizi?

Why doesn't the system admin just create a user account for each user on each server, so that the users can use their username and password to access whatever resources they wish to access?

Immagina di avere 50 utenti e 50 server. Per semplicità, supponiamo che tutti e 50 gli utenti debbano avere accesso a tutti e 50 i server, tutti hanno gli stessi privilegi su tutti i server e non dobbiamo mai cambiare questi privilegi. Questo è 2.500 voci di password in totale che devono essere create.

Aggiunta di un nuovo utente

Quando aggiungi un nuovo utente, l'amministratore deve passare a tutti e 50 i server e aggiungere quell'unico utente a tutti loro. Ciò richiederebbe all'amministratore di eseguire il comando create user in tutti i 50 server. Quel bit può essere automatizzato, ma la parte che non può essere automatizzata in modo sicuro è che l'utente dovrebbe inserire la propria password 50 volte, una volta per server.

Perché quest'ultimo problema? Perché i sistemi di autenticazione delle password sono progettati in modo che non conservino una copia della password , nemmeno una copia crittografata. Quindi, quando l'utente immette la nuova password sul server n. 1, quel server dimentica la password immediatamente, quindi dovranno inserirla nuovamente per il server n. 2 e n. 3, ecc.

Aggiunta di un nuovo server

Forse ora stai pensando che potresti scrivere uno script che:

1. Viene eseguito sul server X;
2. Chiede al nuovo utente di inserire la nuova password;
3. Chiede all'amministratore la propria password;
4. Accedi ai server dal n. 1 al n. 50 e crea l'account utente su ognuno di essi con la stessa password.

È un po 'rischioso, ma anche se lo fai, ti rimane ancora un altro problema più grande. Supponiamo che la tua azienda acquisti un nuovo server e ora abbiamo bisogno che i nostri 50 utenti abbiano accesso su questo server. Bene, dal momento che nessuno dei server contiene una copia delle password degli utenti, l'amministratore dovrebbe andare da ciascun utente e chiedere loro di inserire una password per il proprio account nel nuovo server. E non c'è modo di aggirare questo a meno che tu non abbia conservato copie delle password degli utenti - che di nuovo, è una pratica insicura .

Database delle password centralizzato

Per risolvere questi problemi, è necessario che il proprio database utente / password sia centralizzato in un unico posto e che tutti i server consultino quel database per autenticare nomi utente e password. Questo è davvero il minimo indispensabile per un ambiente multiutente / multiserver gestibile. Ora:

1. Quando aggiungi un nuovo utente, tutti i server lo prelevano automaticamente dal database centrale.
2. Quando aggiungi un nuovo server, preleva automaticamente tutti gli utenti dal database centrale.

C'è una varietà di meccanismi per farlo, anche se sono ancora a corto di ciò che offre Kerberos.

Kerberos

Una volta che hai un database così centralizzato, ha senso potenziarlo con più funzioni, sia per facilità di gestione che per comodità. Kerberos aggiunge la possibilità che, quando un utente ha effettuato correttamente l'accesso a un servizio, quel servizio "ricorda" il fatto ed è in grado di "dimostrare" ad altri servizi che questo utente ha effettuato correttamente l'accesso. Quindi, quegli altri servizi, presentati con tale dimostrazione, lasceranno entrare l'utente senza chiedere una password.

Questo offre un mix di comodità e sicurezza:

1. Gli utenti non ricevono la richiesta della loro password più e più volte quando l'hanno già inserita con successo una volta quel giorno.
2. Quando si dispone di programmatori che scrivono programmi che accedono a più server e tali server richiedono l'autenticazione, i programmi ora possono autenticarsi su tali server senza dover presentare una password, riutilizzando le credenziali dell'account del server su cui vengono eseguiti.

Quest'ultimo è importante perché minimizza o uccide una pratica insicura ma troppo comune: programmi automatici che richiedono di inserire copie di nomi utente e password nei file di configurazione. Ancora una volta, un'idea chiave della gestione sicura delle password è non memorizzare copie di password, nemmeno copie crittografate .

In poche parole, sarebbe un incubo amministrativo.

Kerberos consente agli amministratori di disporre di un numero qualsiasi di dipendenti che utilizzano le stesse credenziali per accedere alle risorse in tutto il loro dominio.

Diciamo che questo non esisteva in una rete semplice.

1. L'utente inserisce la password per sbloccare il suo computer.
2. L'utente vuole mappare un'unità di rete. Ora devono reinserire la password
3. L'utente vuole quindi ricevere email. Aprono Outlook e quindi devono inserire un'altra password.
4. L'utente deve quindi accedere alla intranet aziendale. Questa è un'altra password.

Hai un'idea. Non utilizzare Kerberos significa che l'utente deve mantenere le password per tutti i server che ospitano i servizi di cui hanno bisogno per accedere. Questo sarebbe un mal di testa per utenti e amministratori. La maggior parte delle politiche aziendali stabilisce che gli utenti devono cambiare la propria password ogni X giorni. Riesci a immaginare di essere un utente finale e di dover cambiare la password su 5 server ogni volta che devi farlo?

Da un punto di vista della sicurezza, l'amministratore ottiene tutti i suoi tentativi di accesso (sia riusciti che falliti) in un singolo punto invece di essere loggato su 5 server diversi. Questo aiuta a risolvere i problemi di accesso (es. Blocchi) e rende i registri di controllo molto più semplici.

Kerberos non è lì per comodità, è una misura di sicurezza potenziata. La convenienza è un vantaggio secondario.

Un'ottima spiegazione è Progettazione di un sistema di autenticazione: una finestra di dialogo in quattro scene

Fondamentalmente, invece di passare un token magico in giro (ad esempio la tua password), ottieni un "ticket", che è firmato da una fonte attendibile di verità (ad esempio, Kerberos KDC, Microsoft AD, ecc.). Il ticket indica ai servizi chi sono e a quali gruppi di diritti si appartiene. Pensa ad esso come comprare un biglietto d'ingresso in un parco di divertimenti e versare denaro ad ogni viaggio in un parco.

Per impedire escalation laterale .

La complessità amministrativa della gestione delle password può essere ridotta utilizzando un database di password centralizzato, come LDAP. Tuttavia, facendo ciò si crea il rischio di un'escalation laterale. Se un utente malintenzionato prende il controllo di un server, può rimanere silenziosamente presente, annusando le password. Queste password possono quindi essere utilizzate per compromettere altri server - escalation laterale.

Kerberos tenta di risolvere questo problema: gli utenti non inviano la propria password a ciascun server; lo inviano solo al server di autenticazione e presentano un ticket ad altri server. Negli ultimi tempi, alcuni difetti sono stati identificati che sono sfruttati da strumenti come mimikatz. Tuttavia, almeno Kerberos è progettato per prevenire l'escalation laterale; LDAP non fa nulla per fermarlo.

Il vantaggio principale di Kerberos è di abilitare la modifica dell'account e la modifica della password per la sincronizzazione immediata.

Ho a disposizione soluzioni per l'amministrazione centralizzata di account distribuiti e agenti per le password sul lato client che rispondono al 99% dei prompt delle password dopo l'accesso, ma tutti presumono che l'utente modifichi la password sia rara e che possiamo aspettare fino al il processo batch notturno per il cambio della password ha effettivamente effetto. Lo stesso vale per le modifiche ai permessi nella maggior parte dei casi; se abbiamo bisogno che le modifiche ai permessi abbiano effetto adesso, gli strumenti minori non possono farlo.

Kerberos elenca nelle sue capacità la possibilità di autenticare in modo sicuro le connessioni senza crittografarle. Ciò si dimostra meno che auspicabile nella pratica e tale abilità non dovrebbe essere invocata. Rubare i ticket Kerberos era l'essenza di un attacco a SMB di un anno fa che avrebbe fornito tutti gli accessi come utente a condizione che l'utente stesse usando qualsiasi condivisione di rete ovunque.