Configurazioni per il supporto della blindatura Kerberos

Attenzione!

Perché la blindatura Kerberos venga utilizzata, gli account di amministratore devono essere inseriti nel gruppo Protected Users.
Ciò impone l'utilizzo del protocollo di autenticazione Kerberos al posto di NTLM. L'Edge Gateway deve essere previamente configurato per supportare l'autenticazione Kerberos.

Configurare l'Edge Gateway per supportare l'autenticazione Kerberos con account inseriti in Protected Users

La blindatura Kerberos fornisce una cifratura aggiuntiva per gli scambi iniziali tra il client e il KDC (Kerberos Domain Controller), a partire da informazioni collegate a un account computer.

CyberElements viene eseguito preferibilmente su macchine Debian non collegate a un dominio AD, il che significa che non dispone di alcuna informazione di account computer nell'AD.
La configurazione necessaria per supportare la blindatura Kerberos si compone di due passaggi:

• La creazione di un account computer di servizio nell'AD
• La configurazione della blindatura Kerberos sull'Edge Gateway a partire dall'account creato in precedenza

Creare un account computer di servizio

Informazioni

Questa pagina utilizza come esempio un account di servizio denominato svc_cyberelements. Adattare i comandi seguenti al nome del proprio account di servizio.

Attenzione!

Per utilizzare postazioni di lavoro PAW, collocare questo account di servizio nello stesso silo delle postazioni di lavoro PAW di destinazione.

Dal controller di dominio, iniziare creando un account computer con una password utilizzata per generare i ticket Kerberos.

Per creare questo account è possibile utilizzare il comando Powershell seguente da un controller di dominio (adattare il nome dell'account di servizio, svc_cyberelements nell'esempio, e l'OU desiderata, OU=Service_accounts,DC=domain,DC=local nell'esempio, per creare l'account di servizio):

New-ADComputer -Name svc_cyberelements -SAMAccountName 'svc_cyberelements$' -AccountPassword $Null -Path 'OU=Service_accounts,DC=domain,DC=local'-KerberosEncryptionType AES256 -PasswordNeverExpires $True -Enabled $True

Utilizzare il comando seguente per verificare che l'account computer sia stato creato (sostituire svc_cyberelements con il nome dell'account creato in precedenza):

Get-ADComputer -Identity svc_cyberelements -Properties Enabled

Utilizzare poi lo strumento ktpass di Windows per esportare un file keytab che conterrà le chiavi di cifratura che consentiranno al gateway di recuperare il TGT.

Esempio

Esempio di creazione di un file svc_cyberelements.keytab con l'account computer:

ktpass /princ 'svc_cyberelements$@DOMAIN.LOCAL' /mapuser 'svc_cyberelements$@DOMAIN.LOCAL' +rndPass /out svc_cyberelements.keytab /crypto AES256-SHA1 /ptype KRB5_NT_SRV_HST /mapop set

Non dimenticare di includere i simboli $ alla fine dei nomi degli account e di scrivere il nome del dominio in maiuscolo (obbligatorio).

Accettare le eventuali richieste di conferma immettendo y.

Reimpostare quindi il valore dell'attributo UserPrincipalName con il comando PowerShell seguente:

Set-ADComputer 'svc_cyberelements$' -UserPrincipalName 'svc_cyberelements$@DOMAIN.LOCAL'

Configurare la blindatura Kerberos sull'Edge Gateway

Recuperare il file keytab generato in precedenza e copiarlo sul server Edge Gateway.
In un contesto in cui sono stati generati più file keytab che devono essere utilizzati sullo stesso Edge Gateway, combinare i file keytab in un unico file.

Attenzione

Il file keytab contiene chiavi di cifratura. Se un attaccante se ne impossessa, può impersonare l'account computer associato, riducendo così la sicurezza dell'infrastruttura.
Questo file non deve pertanto essere conservato in un luogo diverso dall'Edge Gateway.

Collocare il file nella directory /etc/ipdiva/cleanroom/.

Modificare i proprietari del file keytab impostando ipdivacareuser per l'utente e carerecord per il gruppo, quindi modificare le autorizzazioni del file (adattare il nome del file keytab al proprio):

chown ipdivacareuser:carerecord /etc/ipdiva/cleanroom/svc_cyberelements.keytab
chmod 640 /etc/ipdiva/cleanroom/svc_cyberelements.keytab

Modificare il file di configurazione /etc/ipdiva/cleanroom/xrdprecord.ini dell'Edge Gateway per indicare, tramite il parametro keytab=, il percorso del file keytab preparato in precedenza.

Esempio

keytab=/etc/ipdiva/cleanroom/svc_cyberelements.keytab

A questo punto, la connessione alle applicazioni RDP privilegiate in modalità senza agente (HTML5 o non) dovrebbe funzionare con account utente appartenenti a Protected Users e che richiedono quindi un'autenticazione forte Kerberos. La configurazione dell'applicazione RDP deve soddisfare determinati prerequisiti.

Testare la configurazione Kerberos

Debug

I comandi kinit seguenti possono fornire più log dopo l'esecuzione del comando seguente (valido fino alla disconnessione della sessione SSH o da console):

export KRB5_TRACE=/dev/stdout

Iniziare recuperando un ticket Kerberos con un comando simile al seguente:

kinit -k -t /etc/ipdiva/cleanroom/svc_cyberelements.keytab 'svc_cyberelements$@DOMAIN.LOCAL' -c /tmp/test_kerberos

Non dimenticare di sostituire la posizione del file keytab, il nome dell'account di servizio creato e il dominio associato.

Se il recupero del ticket Kerberos è andato a buon fine, il comando seguente dovrebbe indicare l'esistenza di un ticket per l'account di servizio:

klist -c /tmp/test_kerberos

Se il recupero va a buon fine, occorre tentare di recuperare un ticket per un utente con un comando simile al seguente:

kinit -T /tmp/test_kerberos user@DOMAIN.LOCAL

Sostituire user@DOMAIN.LOCAL con un utente che potrebbe connettersi tramite RDP e blindatura Kerberos. Si noti che verrà richiesta la password di tale utente.
Se il recupero del ticket va a buon fine, il comando seguente lo visualizza:

klist -c

Se viene visualizzato l'errore KDC policy rejects request while getting initial credentials, significa che il KDC ha rifiutato la richiesta di ticket. Possibili cause:

• kinit non ha potuto utilizzare il ticket /tmp/test_kerberos (se kinit non può utilizzarlo, prosegue senza messaggio di errore con una richiesta di ticket di base)
• L'account di servizio non è presente nel silo dell'utente testato. Ciò si verifica quando l'AD è compartimentato e richiede di collocare l'account computer di servizio nel silo appropriato.

Informazioni aggiuntive sono disponibili nei log eventi Security del controller di dominio (KDC) utilizzato.

Dopo i test, si raccomanda di eliminare i ticket generati:

kdestroy
kdestroy -c /tmp/test_kerberos

Combinare più file keytab in un unico file

Se l'architettura CyberElements si basa su un unico Edge Gateway che darà accesso a più terze parti, è necessario unire in un solo file keytab tutti i file keytab generati per i diversi account di servizio.

Nota

In questa sezione si parte dai file keytab seguenti: /root/t0.keytab, /root/t1.keytab e /root/t2.keytab. Questi file devono essere stati inviati all'Edge Gateway.

Per unire i file keytab, connettersi all'Edge Gateway come root e utilizzare i comandi seguenti:

ktutil
rkt /root/t0.keytab
rkt /root/t1.keytab
rkt /root/t2.keytab
wkt /root/unified.keytab

I comandi rkt consentono di caricare tutti i file keytab necessari, mentre il comando wkt genera un nuovo file keytab.
Adattare i percorsi dei file a quelli in proprio possesso.

Premere il tasto q per uscire dall'utility ktutil.

Recuperare il file unified.keytab e seguire la sezione Configurare la blindatura Kerberos sull'Edge Gateway.