Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Tag Cloud

L’accesso a C$ in Windows 7 e Windows Server 2008 R2 (parte 2)

Scritto da Ivan Salvade' il 10 marzo 2011

Nella prima parte di questo articolo (http://ivansalvade.it/2011/02/24/laccesso-a-c-in-windows-7-e-windows-server-2008-r2/), ho trattato delle due casistiche generali che regolano l’accesso alla condivisione amministrativa c$ in sistemi Windows Vista, Windows 7, Windows Server 2008 e Windows Server 2008 R2.

Ora vediamo più nel dettaglio diversi scenari reali che si possono presentare.

Ipotizziamo di avere due computer, Server1 con installato Windows Server 2008 R2, e Client1 con installato Windows 7 Enterprise, e un generico dominio Active Directory Contoso.com.

SCENARIO 1 : Server1 è in Workgroup, Client1 è nel dominio Contoso.com

Esistono le seguenti utenze e password :

  • Server1\Administrator          Pa$$w0rd
  • Server1\Admin                    Pa$$w0rd    (membro del gruppo Administrators locale)
  • Client1\Administrator           Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)
  • CONTOSO\Administrator     Pa$$w0rd
  • CONTOSO\Jane                   Pa$$w0rd    (Utente Standard di dominio)

Eseguiamo ora diversi tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, possiamo avere i seguenti diversi risultati :

  1. Se su Client1 siamo loggati come CONTOSO\Administrator oppure Client1\Administrator, l’accesso è OK (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  inoltre su Server1 si trova l’utenza Server1\Administrator con la stessa password di CONTOSO\Administrator o Client1\Administrator)     clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se l’utente Server1\Admin ha la stessa password di Client1\Admin)    clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, l’accesso è OK (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali)    vedi la chiave di registro

Cambiamo ora qualche carta in tavola, per esempio alcune password:

  • Server1\Administrator          altrapassword
  • Server1\Admin                    altrapassword    (membro del gruppo Administrators locale)
  • Client1\Administrator            Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)
  • CONTOSO\Administrator     Pa$$w0rd
  • CONTOSO\Jane                   Pa$$w0rd    (Utente Standard di dominio)

Eseguiamo ora altri tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, ecco i nuovi risultati :

  1. Se su Client1 siamo loggati come CONTOSO\Administrator oppure come Client1\Administrator, viene richiesta l’autenticazione (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  ma su Server1 l’utenza Server1\Administrator ha una password diversa da quella degli account CONTOSO\Administrator o Client1\Administrator.  Una volta inserita la corretta password nella finestra di autenticazione, l’accesso è OK)    clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene sempre bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se su Server1 l’utente Admin avesse la stessa password di Client1)   clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, viene richiesta l’autenticazione (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali, ma la password di Client1\Admin è diversa da quella di Server1\Admin.  Inserendo la password corretta nella finestra di autenticazione, l’accesso è OK)   clicca qui per vedere un esempio    vedi la chiave di registro

SCENARIO 2 : Server1 e Client1 entrambi nel dominio Contoso.com

Esistono le seguenti utenze e password :

  • CONTOSO\Jane                     Pa$$w0rd    (Utente Standard di dominio, membro di Server1\Administrators)

Eseguiamo ora il tentativo di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  Sul client siamo loggati come Contoso\Jane.   L’accesso è OK!  Motivazione : in ambiente di dominio, quando dal client un utente di dominio (membro del gruppo Administrators locale del server), tenta l’accesso a \\Server1\c$,  l’utente viene connesso come Full Administrator, e le restrizioni UAC non hanno effetto.   Il comportamento è by design.

SCENARIO 3 : Server1 e Client1 entrambi in workgroup

Esistono le seguenti utenze e password :

  • Server1\Administrator          Pa$$w0rd
  • Server1\Admin                    Pa$$w0rd    (membro del gruppo Administrators locale)
  • Client1\Administrator            Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)

Eseguiamo ora diversi tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, possiamo avere i seguenti diversi risultati :

  1. Se su Client1 siamo loggati come Client1\Administrator, l’accesso è OK (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  inoltre su Server1 si trova l’utenza Server1\Administrator con la stessa password di Client1\Administrator)    clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se l’utente Server1\Admin ha la stessa password di Client1\Admin)    clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, l’accesso è OK (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali)    vedi la chiave di registro

Cambiamo ora qualche carta in tavola, per esempio alcune password:

  • Server1\Administrator          altrapassword
  • Server1\Admin                    altrapassword    (membro del gruppo Administrators locale)
  • Client1\Administrator            Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)

Eseguiamo ora altri tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, ecco i nuovi risultati :

  1. Se su Client1 siamo loggati come Client1\Administrator, viene richiesta l’autenticazione (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  ma su Server1 l’utenza Server1\Administrator ha una password diversa da quella di Client1\Administrator.  Una volta inserita la corretta password nella finestra di autenticazione, l’accesso è OK)    clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene sempre bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se su Server1 l’utente Admin avesse la stessa password di Client1)    clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, viene richiesta l’autenticazione (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali, ma la password di Client1\Admin è diversa da quella di Server1\Admin.  Inserendo la password corretta nella finestra di autenticazione, l’accesso è OK)    clicca qui per vedere un esempio    vedi la chiave di registro
  • Share/Bookmark

Pubblicato in Windows 7, Windows Server 2008 R2 | Nessun commento »

L’accesso a C$ in Windows 7 e Windows Server 2008 R2 (parte 1)

Scritto da Ivan Salvade' il 24 febbraio 2011

Il “Controllo Account Utente” (UAC) è un componente di sicurezza di Windows 7, Windows Vista e Windows Server 2008, che permette agli utenti di eseguire le loro normali operazioni quotidiane come “non-amministratori”, pur facendo parte, come spesso accade, del gruppo locale degli Amministratori.

In pratica, quando si logga un utente facente parte del gruppo Amministratori, questo viene dotato di un doppio token di accesso : uno con i completi diritti amministrativi, e l’altro con i diritti di Standard User.  E’ proprio quest’ultimo che rimane attivo per default, finchè l’utente esegue operazioni che non richiedono diritti amministrativi (es. consultare la posta, andare in Internet, ecc.).

Non appena l’utente deve eseguire un’operazione amministrativa (es. aprire “Gestione Computer”), viene attivato il suo token “amministrativo” (più o meno automaticamente, questo è configurabile), e l’utente può eseguire l’operazione con i massimi privilegi.

La tecnica UAC crea dei problemi quando si vuole accedere da remoto alle condivisioni amministrative (per esempio la tanto famosa e utile C$) presenti su Windows Vista, Windows 7 o Windows Server 2008.

Esistono due casistiche generali :

  1. Quando un utente (non di dominio), membro del gruppo Administrators locale di un computer remoto, tenta di stabilire una connessione remota amministrativa verso quel computer (per es. \\computer\c$), l’utente non viene connesso come Full Administrator, perchè UAC non eleva i privilegi per una connessione amministrativa proveniente da remoto, se fatta da un utente locale (SAM Account).  Quindi si riceve un accesso negato.
  2. Quando un utente (di dominio), che ha il suo account di dominio membro del gruppo Administrators locale di un computer remoto, stabilisce una connessione remota amministrativa verso quel computer, viene connesso come Full Administrator, e UAC non ha effetto.  Quindi la connessione avviene con successo.

Per disabilitare la restrizione del punto 1, è possibile regolare la seguente chiave di registro sul computer remoto :

Posizionarsi in :

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System

Se non esiste, creare la voce di tipo DWORD  “LocalAccountTokenFilterPolicy“, e porre il valore a 1.

Queste sono le casistiche generali.  In un successivo articolo (http://ivansalvade.it/2011/03/10/l%e2%80%99accesso-a-c-in-windows-7-e-windows-server-2008-r2-parte-2/), illustrerò in maniera dettagliata il funzionamento della suddetta tecnica in una moltitudine di scenari.

  • Share/Bookmark

Pubblicato in Windows 7, Windows Server 2008 R2 | 4 Commenti »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok