18 feb 2009

Browsing di Active Directory tramite Recordset

Esistono molte utility per effettuare il browsing di Active Directory, e che permettono di esportare i risultati di una interrograzione in svariati formati, tra cui testo, CSV, Excel, etc.
Spesso ho bisogno di fare delle elaborazioni particolarmente approfondite sui dati estratti, ed allora mi risulta molto comodo lavorare direttamente con Microsoft Access. La lettura di Active Directory tramite l'utilizzo di un Recordset pertanto è l'ideale!
Function LeggiAD()
    Dim adoConnection As New ADODB.Connection
    Dim adoCommand As New ADODB.Command
    Dim adoRecordset As New ADODB.Recordset
    Dim objRootDSE As Object
    Dim strDNSDomain As String

    Set adoConnection = New ADODB.Connection
    adoConnection.Provider = "ADsDSOOBject"
    adoConnection.Open ("Active Directory Provider")
    Set adoCommand.ActiveConnection = adoConnection

    Set objRootDSE = GetObject("<ldap://RootDSE/>">
    strDNSDomain = objRootDSE.Get("defaultNamingContext")
    adoCommand.CommandText = "<ldap://" & strDNSDomain & >;" & _
                             "(&(objectCategory=person)" & _
                             "(objectClass=user));" & _
                             sAMAccountName,cn;subtree"

    adoCommand.Properties("Page Size") = 100
    adoCommand.Properties("Timeout") = 30

    adoCommand.Properties("Cache Results") = False
    Set adoRecordset = adoCommand.Execute
    Do Until adoRecordset.EOF
        rem fai qualcosa con adoRecordset("sAMAccountName").Value
        rem fai qualcosa con adoRecordset("cn").Value

        adoRecordset.MoveNext
    Loop
    adoRecordset.Close
    adoConnection.Close

    Set adoConnection = Nothing
    Set adoCommand = Nothing
    Set objRootDSE = Nothing
    Set adoRecordset = Nothing
End Function
Questo codice scorre tutti gli utenti presenti in Active Directory (filtrati da objectCategory=person e da objectClass=user) ed estrae i campi sAMAccountName e cn: i dati restituiti potrebbero poi essere inseriti in un altra tabella, o potrebbero essere elaborati in altro modo. In genere utilizzo questo codice come base di partenza, e lo personalizzo a seconda delle necessità!

12 feb 2009

Modifica ACL tramite script

Spesso mi capita di dover mantenere una struttura di cartelle di Windows che hanno delle ACL personalizzate con un livello di dettaglio molto elevato. Quando i permessi cominciano a diventare complessi lo strumento standard di Windows diventa scomodo ed è facile commettere degli errori.

L'utility Xcacls.exe, che si scarica dal sito della Microsoft, può essere di grande aiuto in tutti questi casi. Ho preparato uno script batch che richiama questa utility, leggendo da un file di testo con l'elenco delle cartelle e delle relative ACL da impostare ad ognuna di esse:

esempio di elencoacl.txt:
"c:\sede\ced";"DOMAIN\user1:C" "DOMAIN\user2:R"
"c:\sede\personale";"DOMAIN\user3:C" "DOMAIN\user4:R"
"c:\sede\personale\dirigenza";"DOMAIN\user3:C"
"c:\sede\personale\pub";"DOMAIN\Everyone:R"
"c:\sede\tecnico";"DOMAIN\user4:C" "DOMAIN\user5:C"
"c:\sede\tecnico\progetti";"DOMAIN\user4:R"
"c:\sede\tecnico\lavori";"DOMAIN\user5:R"
etc...
con il seguente impostaacl.cmd:
set LETTURA="DOMAIN\leggi:R"
set SCRITTURA="DOMAIN\fede:C"
set FULL="BUILTIN\Administrators:F" "NT AUTHORITY\SYSTEM:F"

for /F "tokens=1,2 delims=;" %%a in (elencoacl.txt) do (
  xcacls %%a /T /G %FULL% %LETTURA% %SCRITTURA% %%b /Y
  @if ERRORLEVEL 1 (
    echo Errore set ACL directory %%a
    pause
  )
)
Questo script batch legge in sequenza tutte le righe del file elencoacl.txt, ed imposta ricorsivamente ad ogni cartella i permessi associati. Fare attenzione alle cartelle innestate: questo script non è molto "furbo" e ripete le impostazioni più volte. Verificare che l'ordine delle cartelle sia corretto!

2 feb 2009

Firma Digitale

La firma digitale è un procedimento che, a partire da un documento informatico e da alcune informazioni associate ad una persona, produce un nuovo oggetto informatico firmato che attesta la volontà della persona di sottoscrivere il documento originario.
Il procedimento che viene applicato al documento da firmare si basa sulla crittografia a chiave asimmetrica, e per avere valore legale equivalente alla firma autografa deve soddisfare dei particolari requisiti.

Crittografia

La crittografia è nata per trasmettere messaggi tra un mittente ed un destinatario in modo sicuro, utilizzando però un canale di trasmissione non sicuro. Un sistema di crittografia serve ad offuscare i messaggi e renderli illeggibili da chiunque non disponga della chiave per decifrarli.
Nella crittografia a chiave simmetrica la chiave che si utilizza per cifrare i messaggi è la stessa chiave che serve a decifrarli.
Naturalmente mittente e destinatario hanno la necessità di scambiarsi in qualche modo la chiave, e per farlo devono utilizzare un canale di trasmissione sicuro; ma se dispongono di un canale sicuro, per quale motivo non utilizzano esclusivamente questo canale anche per i messaggi? Perché il canale sicuro potrebbe essere molto costoso, oppure potrebbe essere disponibile solamente in intervalli di tempo limitati (ad es. a volte ci si deve trovare di persona per scambiarsi le chiavi).

Quando mittenti e destinatari cominciano a diventare numerosi, oppure quando non si conoscono di persona, la crittografia a chiave simmetrica comincia a mostrare i suoi limiti.

Crittografia Asimmetrica

La crittografia a chiave asimmetrica utilizza invece due chiavi diverse per le operazioni di cifratura e decifratura, permettendo di semplificare il compito di distribuzione delle chiavi. Queste due chiavi sono associate tra di loro e dispongono di una proprietà che le rende molto utili: tutti i messaggi cifrati con una chiave possono essere decifrati soltanto con l'altra chiave, e viceversa. Dal punto di vista logico, queste chiavi funzionano in modo simmetrico. Asimmetrico è l'utilizzo che se ne fa: poiché da una chiave non è possibile ricavare la sua chiave associata, è possibile rilasciare pubblicamente una chiave, la quale prende il nome di chiave pubblica, mentre l'altra chiave, che viene mantenuta segreta, prende il nome di chiave privata.

Per inviare un messaggio sicuro ad un determinato destinatario, è necessario ottenere la sua chiave pubblica e cifrare il messaggio con tale chiave: solamente il destinatario legittimo è in grado di decifrarlo, poiché è l'unico che possiede la sua chiave privata.

ma tutto questo che cosa c'entra con la firma?

Cifrando un messaggio con la chiave pubblica, solamente il destinatario che dispone della chiave privata è in grado di decifrare il messaggio. Questo è utile per spedire dei messaggi offuscati ad un destinatario, ma che cosa c'entra tutto questo con la firma?
Applicando lo stesso ragionamento al contrario, se un messaggio è decifrabile tramite una chiave pubblica abbiamo la garanzia che esso sia stato cifrato dalla persona a cui è associata tale chiave, poiché è l'unica che possiede la relativa chiave privata.

Certificati

Tutto così semplice? Naturalmente no!
Per scrivere un messaggio sicuro ad un destinatario devo per prima cosa ottenere la sua chiave pubblica; ma come faccio ad essere certo: 1. che il destinatario sia proprio chi mi dice di essere, e 2. che la chiave pubblica, sia proprio la sua?
Lo stesso discorso naturalmente vale per il procedimento inverso: per essere certo che un messaggio sia stato cifrato da un utente utilizzando la sua chiave privata, devo essere sicuro di disporre esattamente della sua chiave pubblica.
Scopo dei certificati digitali è proprio di garantire che una chiave pubblico sia associato alla vera identità del soggetto che la rivendica come propria. Un certificato digitale è un documento, firmato elettronicamente da un'autorità di certificazione fidata, che associa una chiave pubblica con un'identità.
Ovviamente per verificare se il certificato digitale è valido, è necessario disporre della chiave pubblica del certificatore: ma gli enti certificatori fidati sono pochi, e le loro chiavi pubblice possono essere distribuite agevolmente tramite canali sicuri (es. generalmente vengono installate con il sistema operativo).

Dispositivi sicuri

Affinché il sistema della cifratura o della firma funzioni correttamente, è indispensabile garantire che la chiave privata sia mantenuta davvero privata. Se la chiave è memorizzata su di un file su disco o su di una memoria di massa, c'è sempre il rischio che venga in mano a terzi non autorizzati al suo utilizzo. Per evitare questo rischio è necessario utilizzare dei dispositivi di firma sicuri, dei dispositivi cioè che dispongono di una chiave privata la quale, una volta generata, non può essere esportata all'esterno.
Una smart card è un dispositivo di questo tipo: al suo interno contiene infatti una chiave privata che non può essere esportata, e dispone di un chip che effettua le operazioni crittografiche utilizzando la chiave memorizzata all'interno.

Requisiti per la firma digitale

In base alla normativa vigente, la firma forte è l'unica firma che attribuisce al documento informatico una valenza probatoria, e prevede la presenza di una Certification Authority iscritta all'albo dell'AIPA e l'utilizzo di un dispositivo di firma sicuro. La firma digitale è un tipo di firma forte.
Una firma che non possiede i requisiti precedenti è detta firma debole: la valenza probatoria del documento firmato tramite firma debole è soggetta alla discrezionalità del giudice.

Impronta del documento

L'impronta è un processo tramite il quale è possibile ottenere da un oggetto informatico di dimensione qualsiasi una sequenza di bit a lunghezza fissa (es. 128 o 160 bit). Visto che l'impronta ha lunghezza fissa mentre l'oggetto di origine può avere qualsiasi lunghezza, è naturalmente possibile ottenere delle collisioni, ovvero più oggetti diversi possono avere la stessa firma. Un algoritmo che calcola le impronte dei documenti è sicuro se non permette di ottenere facilmente, data un'impronta, un oggetto che possa generarla.
Ridurre documenti di qualsiasi dimensione ad una stringa di bit molto corta permette di effettuare calcoli molto più veloci rispetto a quelli necessari nel caso in cui l'operazione dovesse effettuarsi sul documento intero.

Procedura di generazione di un documento firmato

Il titolare di una coppia di chiavi può firmare digitalmente un documento adottando la seguente procedura:
  • calcola l'impronta del documento
  • esegue la cifratura dell'impronta utilizzando la sua chiave privata
  • allega il documento in chiaro
  • allega l'impronta cifrata del documento
  • allega il certificato rilasciato dall'autorità di certificazione
tutti gli allegati vengono inseriti in una busta formato standard PKCS#7 che viene spedita al destinatario. Il destinatario per essere certo dell'autenticità e dell'integrità del messaggio arrivato, effettua la seguente procedura di verifica:
  • accede al certificato del mittente, contenuto nella busta
  • verifica tramite l'autorità di certificazione che il certificato non sia stato revocato o sospeso
  • decifra l'impronta del documento con la chiave pubblica del mittente
  • calcola l'impronta del documento ricevuto
se l'impronta calcolata equivale all'impronta decifrata, il documento non è stato manomesso ed è corrispondente a quello che il mittente ha firmato.

Vulnerabilità

Un dispositivo di firma quale la smart card è un dispositivo sicuro. Il PC che calcola l'impronta del documento invece è potenzialmente insicuro: come si può essere certi che l'impronta firmata dalla smart card sia esattamente l'impronta del documento visualizzato ed effettivamente scelto dall'utente?

Altri problemi potrebbero riguardare documenti non statici che contengono istruzioni o codici eseguibili, ma tali documenti sono esclusi dalla validità della firma secondo la normativa vigente.

Infine è possibile, almeno teoricamente, creare documenti ambigui che sono validi in più formati. Si suppone però che anche questi documenti siano esclusi dalla validità della firma.

Installazione remota di .msi tramite PsExec

Per effettuare l'installazione da remoto di un pacchetto .msi è possibile utilizzare il comando psexec con la seguente sintassi:
psexec -u username -p password \\target -s -d msiexec /i "\\percorso_del_pacchetto.msi" /qb
Naturalmente bisogna assicurarsi che l'utente username disponga dei privilegi di installazione software nella macchina target (tipicamente deve essere un amministratore). Inoltre se il pacchetto da installare si trova in un percorso di rete, l'utente username deve avere accesso alle risorse di rete, pertanto un amministratore locale della macchina potrebbe non bastare. Un amministratore di dominio invece dovrebbe funzionare sempre, ma in alternativa è possibile copiare il pacchetto nella macchina target, ed utilizzare il percorso locale.