none
EFS - è possibile fare in modo che la chiave pubblica venga pubblicata in AD RRS feed

  • Domanda

  • Forse mi sfugge qualcosa...

    nel momento in cui un utente cripta un file ottiene un certificato dalla CA interna.
    Noto che se l'utente cripta un file sul proprio PC ottiene un certificato che finisce nei certificati personali dell'utente in locale sulla macchina.

    Se invece l'utente deve criptare un file che risiede su una cartella condivisa(ho dovuto abilitare la delega kerberos per il file server altrimenti non funzionava), vedo che l'identificativo del certificato è diverso, ma in locale sulla macchina dell'utente non trovo nessun nuovo certificato.

    Il problema mi si pone perché mi hanno chiesto di creare una cartella criptata sul file server, alla quale potessero accedere più utenti. Io non trovo nessun certificato EFS pubblicato in AD e se provo a pubblicare manualmente i certificato EFS che trovo negli archivi personali locali dei PC non riesco a decriptare nulla perché, come dicevo prima, sembra che il file server utilizzi un certificato diverso per criptare (ottenuto in delega???)

    il dominio è 2008 r2 (dominio e foresta a livello funzionale 2008r2) e il file server sempre 2008 r2

    qualsiasi chiarimento è gradito


    lunedì 31 agosto 2015 14:48

Risposte

  • Ciao,

    il file server crea un "miniprofilo" per l'utente che crypta il file e richiede un ceritifcato in sua vece.

    Puoi garantire l'accesso ai file criptati editando le proprietá avanzate del file e aggiungendo gli utenti che vuoi fare accedere.

    Maggiori informazioni qui


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    lunedì 31 agosto 2015 16:19

Tutte le risposte

  • Ciao,

    il file server crea un "miniprofilo" per l'utente che crypta il file e richiede un ceritifcato in sua vece.

    Puoi garantire l'accesso ai file criptati editando le proprietá avanzate del file e aggiungendo gli utenti che vuoi fare accedere.

    Maggiori informazioni qui


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    lunedì 31 agosto 2015 16:19
  • pienamente d'accordo.

    mi manca comunque un passaggio importante in una situazione come la mia in cui i file criptati sono su una share remota. Il certificato viene creato per ogni utente, non in locale, ma in un miniprofilo sul file server.
    Peraltro ero convinto che le chiavi pubbliche dei certificati EFS di dominio andassero automaticamente in active directory, invece nel link che mi hai mandato non se ne fa menzione.

    Quando io però provo ad aggiungere altri utenti con il metodo da te suggerito, mi si presenta la scelta di utenti su active directory. In active directory però non c'è nessuna chiave pubblica relativa ai certificati presenti nei miniprofili del file server.

    Credo di avere letto attentamente il link che mi hai fornito, e certamente la prox volta andrò di WebDAV o userò i roaming profiles, ma nella situazione in cui sono, quale è il metodo più semplice per popolare la condivisione di un file con i vari certificati pubblici presenti a questo punto solo sul file server?

    grazie

    lunedì 31 agosto 2015 20:31
  • Sinceramente non mi sono mai trovato in una situzione del genere, per quello che ho capito devi aggiungere i permessi per i singoli utenti ad ogni file criptato. Piú di cosí non saprei che dire, vediamo se qualcuno puó aggiungere qualcosa


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    lunedì 31 agosto 2015 22:02
  • scusa ma a me pare abbastanza ben descritto il processo:

    In a remote decryption scenario, then, EFS determines whether the computer has been trusted for delegation. If not, the decryption process fails.

    The user account must also not be designated as a sensitive account that cannot be delegated. Domain administrator accounts, for example, are flagged as nonforwardable (identity cannot be delegated). Any account that cannot be delegated cannot use EFS remotely.

    If the computer is trusted for delegation and the user account that EFS needs to impersonate can be delegated, EFS can next locate the user’s profile. The process is similar to that used after a new key pair has been generated and the private key needs storage. EFS looks for a local profile and a roaming profile, and it uses the roaming profile if it exists. If the user does not have a local or a roaming profile, the decryption process fails. EFS cannot create a user profile in this situation because it needs the existing private key (and thus the profile in which it is stored) to decrypt the FEK.

    If a user profile is located, EFS looks for a private key to match the public key used to encrypt the FEK. If found, the private key is used to decrypt the FEK and file decryption can begin. If the private key is not found, the decryption process fails.

    When the FEK is decrypted and used to decrypt the file, the data is ready to be transmitted in plaintext across the network.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 1 settembre 2015 12:13
    Moderatore