Uso di DsAddSidHistory

La funzione DsAddSidHistory ottiene l'identificatore di sicurezza dell'account primario (SID) di un'entità di sicurezza da un dominio (dominio di origine) e lo aggiunge all'attributo sIDHistory di un'entità di sicurezza in un altro dominio (destinazione) in una foresta diversa. Quando il dominio di origine è in modalità nativa di Windows 2000, questa funzione recupera anche i valori sIDHistory dell'entità di origine e li aggiunge al sIDHistory dell'entità di destinazione.

L'aggiunta di SID a sIDHistory di un'entità di sicurezza è un'operazione sensibile alla sicurezza che concede in modo efficace all'entità di destinazione l'accesso a tutte le risorse accessibili all'entità di origine, purché esistano trust da domini di risorse applicabili al dominio di destinazione.

In una modalità nativa di Windows 2000 un dominio di accesso utente crea un token di accesso che contiene il SID dell'account primario utente e i SID del gruppo, nonché lo sIDHistory dell'utente e lo sIDHistory dei gruppi di cui l'utente è membro. La presenza di questi SID precedenti (valori sIDHistory ) nel token dell'utente concede all'utente l'accesso alle risorse protette da elenchi di controllo di accesso (ACL) contenenti i SID precedenti.

Questa operazione facilita alcuni scenari di distribuzione di Windows 2000. In particolare, supporta uno scenario in cui gli account in una nuova foresta di Windows 2000 vengono creati per utenti e gruppi già esistenti in un ambiente di produzione Windows NT 4.0. Inserendo il SID dell'account Windows NT 4.0 nello sIDHistory dell'account di Windows 2000, l'accesso alle risorse di rete viene mantenuto per l'utente che accede al suo nuovo account Di Windows 2000.

DsAddSidHistory supporta anche la migrazione dei server di risorse dei controller di dominio di backup di Windows NT 4.0 (o controller di dominio) o controller di dominio (o controller di dominio e server membri in un dominio windows 2000 in modalità nativa) a un dominio di Windows 2000 come server membri. Questa migrazione richiede la creazione, nel dominio Windows 2000 di destinazione, di gruppi locali di dominio che contengono, nel relativo sIDHistory, i SID primari dei gruppi locali definiti nel cluster BDC (o i gruppi locali di dominio a cui si fa riferimento negli ACL nei server Windows 2000) nel dominio di origine. Creando un gruppo locale di destinazione contenente sIDHistory e tutti i membri del gruppo locale di origine, l'accesso alle risorse del server migrato, protetto dagli ACL che fanno riferimento al gruppo locale di origine, viene mantenuto per tutti i membri.

Nota

L'uso di DsAddSidHistory richiede una conoscenza delle implicazioni amministrative e di sicurezza più ampie in questi e altri scenari. Per altre informazioni, vedere il white paper "Planning Migration from Windows NT to Microsoft Windows 2000" (Pianificazione della migrazione da Windows NT a Microsoft Windows 2000), fornito come Dommig.doc negli strumenti di supporto di Windows 2000. Questa documentazione è disponibile anche nel CD del prodotto in \support\tools.

Requisiti di autorizzazione

DsAddSidHistory richiede privilegi di amministratore nei domini di origine e di destinazione. In particolare, il chiamante di questa API deve essere membro del gruppo Domain Amministrazione istrators nel dominio di destinazione. Viene eseguita una verifica hardcoded per l'appartenenza. Inoltre, l'account fornito nel parametro SrcDomainCreds deve essere membro del gruppo Amministrazione istrators o Domain Amministrazione istrators nel dominio di origine. Se NULL viene passato in SrcDomainCreds, il chiamante dell'API deve essere membro del gruppo Amministrazione istrators o Domain Amministrazione istrators nel dominio di origine.

Requisiti di dominio e attendibilità

DsAddSidHistory richiede che il dominio di destinazione sia in modalità nativa Windows 2000 o versione successiva, perché solo questo tipo di dominio supporta l'attributo sIDHistory . Il dominio di origine può essere Windows NT 4.0 o Windows 2000, modalità mista o nativa. I domini di origine e di destinazione non devono trovarsi nella stessa foresta. I domini di Windows NT 4.0 sono per definizione non in una foresta. Questo vincolo tra foreste garantisce che i SID duplicati, che vengano visualizzati come SID primari o valori sIDHistory , non vengano creati nella stessa foresta.

DsAddSidHistory richiede un trust esterno dal dominio di origine al dominio di destinazione nei casi elencati nella tabella seguente.

Case	Descrizione
Il dominio di origine è Windows 2000.	L'attributo sIDHistory di origine, disponibile solo nei domini di origine di Windows 2000, può essere letto solo usando LDAP, che richiede questa attendibilità per la protezione dell'integrità.
Il dominio di origine è Windows NT 4.0 e SrcDomainCreds è NULL.	La rappresentazione, necessaria per supportare le operazioni del dominio di origine usando le credenziali del chiamante, dipende da questa relazione di trust. La rappresentazione richiede anche che il controller di dominio di destinazione disponga di "Trusted for Delegation" abilitato per impostazione predefinita nei controller di dominio.

Tuttavia, non è necessario alcun trust tra i domini di origine e di destinazione se il dominio di origine è Windows NT 4.0 e SrcDomainCreds non è NULL.

Requisiti del controller di dominio di origine

DsAddSidHistory richiede che il controller di dominio, selezionato come destinazione per le operazioni nel dominio di origine, sia il PDC nei domini windows NT 4.0 o l'emulatore PDC nei domini di Windows 2000. Il controllo del dominio di origine viene generato tramite operazioni di scrittura, pertanto il PDC è necessario nei domini di origine di Windows NT 4.0 e la restrizione pdC-only garantisce che i controlli DsAddSidHistory vengano generati in un singolo computer. In questo modo si riduce la necessità di esaminare i log di controllo di tutti i controller di dominio per monitorare l'uso di questa operazione.

Nota

Nei domini di origine di Windows NT 4.0, il PDC (destinazione delle operazioni nel dominio di origine) deve eseguire Service Pack 4 (SP4) e versioni successive per garantire il corretto supporto del controllo.

Il valore del Registro di sistema seguente deve essere creato come valore REG_DWORD e impostato su 1 nel controller di dominio di origine sia per i controller di dominio di origine di Windows NT 4.0 che per Windows 2000.

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            Lsa
               TcpipClientSupport

L'impostazione di questo valore abilita le chiamate RPC sul trasporto TCP. Questa operazione è necessaria perché, per impostazione predefinita, le interfacce SAMRPC sono remotabili solo sulle named pipe. L'uso di named pipe comporta un sistema di gestione delle credenziali adatto per gli utenti connessi in modo interattivo che effettuano chiamate in rete, ma non è flessibile per un processo di sistema che effettua chiamate di rete con credenziali fornite dall'utente. RPC su TCP è più adatto a tale scopo. L'impostazione di questo valore non riduce la sicurezza del sistema. Se questo valore viene creato o modificato, per rendere effettiva questa impostazione è necessario riavviare il controller di dominio di origine.

È necessario creare un nuovo gruppo locale "<SrcDomainName>$$$$" nel dominio di origine a scopo di controllo.

Controllo

Le operazioni DsAddSidHistory vengono controllate per garantire che gli amministratori del dominio di origine e di destinazione siano in grado di rilevare quando questa funzione è stata eseguita. Il controllo è obbligatorio sia nei domini di origine che di destinazione. DsAddSidHistory verifica che la modalità di controllo sia attiva in ogni dominio e che il controllo di Gestione account degli eventi Success/Failure sia attivo. Nel dominio di destinazione viene generato un evento di controllo "Add Sid History" univoco per ogni operazione DsAddSidHistory riuscita o non riuscita.

Gli eventi di controllo "Aggiungi cronologia sid" univoci non sono disponibili nei sistemi Windows NT 4.0. Per generare eventi di controllo che riflettono in modo non ambiguo l'uso di DsAddSidHistory sul dominio di origine, esegue operazioni su un gruppo speciale il cui nome è l'identificatore univoco nel log di controllo. Un gruppo locale, "<SrcDomainName>$$$$", il cui nome è composto dal nome NetBIOS del dominio di origine aggiunto con tre segni di dollaro ($) (codice ASCII = 0x24 e Unicode = U+0024), deve essere creato nel controller di dominio di origine prima di chiamare DsAddSidHistory. Ogni utente di origine e gruppo globale che è una destinazione di questa operazione viene aggiunto e quindi rimosso dall'appartenenza di questo gruppo. In questo modo vengono generati gli eventi di controllo Add Member e Delete Member nel dominio di origine, che possono essere monitorati cercando gli eventi che fanno riferimento al nome del gruppo.

Nota

Non è possibile controllare le operazioni DsAddSidHistory su gruppi locali in un dominio di origine windows NT 4.0 o Windows 2000 in modalità mista perché i gruppi locali non possono essere creati membri di un altro gruppo locale e pertanto non possono essere aggiunti al gruppo locale speciale "<SrcDomainName>$$$$". Questa mancanza di controllo non presenta un problema di sicurezza per il dominio di origine, perché l'accesso alle risorse del dominio di origine non è interessato da questa operazione. L'aggiunta del SID di un gruppo locale di origine a un gruppo locale di destinazione non concede l'accesso alle risorse di origine, protette da tale gruppo locale, ad altri utenti. L'aggiunta di membri al gruppo locale di destinazione non concede loro l'accesso alle risorse di origine. Ai membri aggiunti viene concesso l'accesso solo ai server nel dominio di destinazione migrato dal dominio di origine, che può avere risorse protette dal SID del gruppo locale di origine.

Sicurezza della trasmissione dei dati

DsAddSidHistory applica le misure di sicurezza seguenti:

• Chiamato da una workstation Windows 2000, le credenziali del chiamante vengono usate per autenticare e proteggere la chiamata RPC al controller di dominio di destinazione. Se SrcDomainCreds non è NULL, sia la workstation che il controller di dominio di destinazione devono supportare la crittografia a 128 bit per proteggere la privacy delle credenziali. Se la crittografia a 128 bit non è disponibile e vengono forniti SrcDomainCreds , la chiamata deve essere effettuata nel controller di dominio di destinazione.
• Il controller di dominio di destinazione comunica con il controller di dominio di origine usando SrcDomainCreds o le credenziali del chiamante per autenticare e proteggere reciprocamente la lettura del SID dell'account di origine (usando una ricerca SAM) e sIDHistory (usando una lettura LDAP).

Modelli di minaccia

La tabella seguente elenca le potenziali minacce associate alla chiamata DsAddSidHistory e risolve le misure di sicurezza pertinenti alla minaccia specifica.

Potenziale minaccia	Misura di sicurezza
Attacco man-in-the-middle Un utente non autorizzato intercetta il SID di ricerca della chiamata restituita dell'oggetto di origine, sostituendo il SID dell'oggetto di origine con un SID arbitrario per l'inserimento in un SIDhistory dell'oggetto di destinazione.	Il SID di ricerca dell'oggetto di origine è un RPC autenticato, usando le credenziali di amministratore del chiamante, con protezione dei messaggi di integrità dei pacchetti. Ciò garantisce che la chiamata restituita non possa essere modificata senza rilevamento. Il controller di dominio di destinazione crea un evento di controllo univoco "Aggiungi cronologia SID" che riflette il SID aggiunto all'account di destinazione sIDHistory.
Dominio di origine Trojan Un utente non autorizzato crea un dominio di origine "Trojan Horse" in una rete privata con lo stesso SID di dominio e alcuni degli stessi SID account del dominio di origine legittimo. L'utente non autorizzato tenta quindi di eseguire DsAddSidHistory in un dominio di destinazione per ottenere il SID di un account di origine. Questa operazione viene eseguita senza la necessità delle credenziali del dominio di origine reale Amministrazione istrator e senza uscire da un audit trail nel dominio di origine reale. Il metodo dell'utente non autorizzato per la creazione del dominio di origine Trojan Horse potrebbe essere uno dei seguenti: Ottenere una copia (backup BDC) del dominio di origine SAM. Creare un nuovo dominio, modificando il SID del dominio su disco in modo che corrisponda al SID del dominio di origine legittimo, quindi creare un'istanza sufficiente di utenti per creare un'istanza di un account con il SID desiderato. Creare una replica BDC. Ciò richiede le credenziali del dominio di origine Amministrazione istrator. L'utente non autorizzato quindi porta la replica in una rete privata per implementare l'attacco.	Anche se esistono molti modi per consentire a un utente non autorizzato di recuperare o creare un SID dell'oggetto di origine desiderato, l'utente non autorizzato non può usarlo per aggiornare il file sIDHistory di un account senza essere membro del gruppo domain Amministrazione istrators di destinazione. Poiché il controllo, nel controller di dominio di destinazione, per l'appartenenza a Domain Amministrazione istrator è hardcoded, nel controller di dominio di destinazione non esiste alcun metodo per eseguire una modifica del disco per modificare i dati di controllo di accesso che proteggono questa funzione. Un tentativo di clonare un account di origine Trojan Horse viene controllato nel dominio di destinazione. Questo attacco viene mitigato riservando l'appartenenza al gruppo Domain Amministrazione istrators solo per utenti altamente attendibili.
Modifica su disco della cronologia SID Un utente sofisticato non autorizzato, con credenziali di domain Amministrazione istrator e con accesso fisico a un controller di dominio nel dominio di destinazione, potrebbe modificare un valore sIDHistory dell'account su disco.	Questo tentativo non è abilitato tramite DsAddSidHistory. Questo attacco viene mitigato impedendo l'accesso fisico ai controller di dominio a tutti tranne gli amministratori altamente attendibili.
Codice non autorizzato usato per rimuovere le protezioni Un utente non autorizzato o un amministratore non autorizzato con accesso fisico al codice del servizio directory potrebbe creare codice non autorizzato che: Rimuove il controllo dell'appartenenza al gruppo Domain Amministrazione istrators nel codice. Modifica le chiamate sul controller di dominio di origine che punta il SID a un LookupSidFromName non controllato. Rimuove le chiamate al log di controllo.	Qualcuno con accesso fisico al codice DS e abbastanza esperto per creare codice non autorizzato ha la possibilità di modificare arbitrariamente l'attributo sIDHistory di un account. L'API DsAddSidHistory non aumenta questo rischio per la sicurezza.
Risorse vulnerabili ai SID rubati Se un utente non autorizzato ha avuto esito positivo usando uno dei metodi descritti qui per modificare un account sIDHistory e se i domini di risorse di interesse considerano attendibile il dominio dell'account utente non autorizzato, l'utente non autorizzato può ottenere l'accesso non autorizzato alle risorse del SID rubato, potenzialmente senza lasciare un audit trail nel dominio account da cui è stato rubato il SID.	Gli amministratori del dominio delle risorse proteggono le risorse configurando solo le relazioni di trust che hanno senso dal punto di vista della sicurezza. L'uso di DsAddSidHistory è limitato, nel dominio di destinazione attendibile, ai membri del gruppo Domain Amministrazione istrators che dispongono già di autorizzazioni generali nell'ambito delle proprie responsabilità.
Dominio di destinazione non autorizzato Un utente non autorizzato crea un dominio di Windows 2000 con un account il cui sIDHistory contiene un SID rubato da un dominio di origine. L'utente non autorizzato usa questo account per l'accesso non autorizzato alle risorse.	L'utente non autorizzato richiede le credenziali Amministrazione istrator per il dominio di origine per usare DsAddSidHistory e lascia un audit trail nel controller di dominio di origine. Il dominio di destinazione non autorizzato ottiene accesso non autorizzato solo in altri domini che considerano attendibile il dominio non autorizzato, che richiede privilegi Amministrazione istrator in tali domini di risorse.

Vincoli operativi

In questa sezione vengono descritti i vincoli operativi dell'uso della funzione DsAddSidHistory.

Il SID di SrcPrincipal non deve esistere già nella foresta di destinazione, come SID dell'account primario o nello sIDHistory di un account. L'eccezione è che DsAddSidHistory non genera un errore quando si tenta di aggiungere un SID a un sIDHistory che contiene un SID identico. Questo comportamento consente l'esecuzione di DsAddSidHistory più volte con input identico, con conseguente esito positivo e coerente dello stato finale, per facilitare l'uso dello strumento.

Nota

La latenza di replica del catalogo globale può fornire una finestra durante la quale è possibile creare SID duplicati. Tuttavia, i SID duplicati possono essere facilmente eliminati da un amministratore.

SrcPrincipal e DstPrincipal devono essere uno dei tipi seguenti:

• User

• Gruppo con abilitazione della sicurezza, tra cui:

  Gruppo globale Gruppo locale Gruppo globale Gruppo locale (solo modalità nativa di Windows 2000) Gruppo universale (solo modalità nativa di Windows 2000)

I tipi di oggetto di SrcPrincipal e DstPrincipal devono corrispondere.

• Se SrcPrincipal è un utente, DstPrincipal deve essere un utente.
• Se SrcPrincipal è un gruppo locale o locale di dominio, DstPrincipal deve essere un gruppo locale di dominio.
• Se SrcPrincipal è un gruppo globale o universale, DstPrincipal deve essere un gruppo globale o universale.

SrcPrincipal e DstPrincipal non possono essere uno dei tipi seguenti: (DsAddSidHistory ha esito negativo con un errore in questi casi)

• Computer (workstation o controller di dominio)

• Trust tra domini

• Account duplicato temporaneo (funzionalità virtualmente inutilizzata, legacy di LANman)

• Account con SID noti. I SID noti sono identici in ogni dominio; aggiungendoli quindi a uno sIDHistory violare il requisito di univocità SID di una foresta di Windows 2000. Gli account con SID noti includono i gruppi locali seguenti:

  Operatori account Amministrazione istrators Operatori di backup Operatori di stampa Guest Operatori di stampa Server Replicator Users

Se SrcPrincipal ha un identificatore relativo noto (RID) e un prefisso specifico del dominio, ovvero Domain Amministrazione istrators, Domain Users e Domain Computers, DstPrincipal deve possedere lo stesso RID noto affinché DsAddSidHistory abbia esito positivo. Gli account con RID noti includono gli utenti e i gruppi globali seguenti:

• Amministratore
• Ospite
• Amministratori di dominio
• Utenti guest del dominio
• Utenti del dominio

Impostazione del valore del Registro di sistema

La procedura seguente illustra come impostare il valore del Registro di sistema TcpipClientSupport.

Per impostare il valore del Registro di sistema TcpipClientSupport

1. Creare il valore del Registro di sistema seguente come valore REG_DWORD nel controller di dominio di origine e impostarne il valore su 1.

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

2. Riavviare quindi il controller di dominio di origine. Questo valore del Registro di sistema fa sì che SAM sia in ascolto su TCP/IP. DsAddSidHistory avrà esito negativo se questo valore non è impostato nel controller di dominio di origine.

Abilitazione del controllo degli eventi di gestione utenti/gruppi

La procedura seguente illustra come abilitare il controllo degli eventi di gestione di utenti/gruppi in un dominio di origine o destinazione di Windows Server 2000 o Windows Server 2003.

Per abilitare il controllo degli eventi di gestione di utenti/gruppi in un dominio di origine o destinazione di Windows 2000 o Windows Server 2003

1. Nello snap-in UTENTI E COMPUTER DI ACTIVE DIRECTORY MMC selezionare il contenitore controller di dominio di destinazione.
2. Fare clic con il pulsante destro del mouse su Controller di dominio e scegliere Proprietà.
3. Fare clic sulla scheda Criteri di gruppo.
4. Selezionare i criteri dei controller di dominio predefiniti e fare clic su Modifica.
5. In Configurazione computer\Windows Impostazioni\Sicurezza Impostazioni\Criteri locali\Criteri di controllo fare doppio clic su Controlla gestione account.
6. Nella finestra Audit Account Management (Controlla gestione account) selezionare sia Success (Operazione riuscita) che Failure auditing (Controllo errori). Gli aggiornamenti dei criteri diventano effettivi dopo un riavvio o dopo un aggiornamento.
7. Verificare che il controllo sia abilitato visualizzando i criteri di controllo effettivi nello snap-in MMC di Criteri di gruppo.

La procedura seguente illustra come abilitare il controllo degli eventi di gestione di utenti/gruppi in un dominio di Windows NT 4.0.

Per abilitare il controllo degli eventi di gestione di utenti/gruppi in un dominio di Windows NT 4.0

1. In User Manager for Domains (Gestione utenti per domini) fare clic sul menu Criteri e selezionare Audit (Controlla).
2. Selezionare Controlla questi eventi.
3. Per Gestione utenti e gruppi, selezionare Operazione riuscita e errore.

La procedura seguente illustra come abilitare il controllo degli eventi di gestione di utenti/gruppi in un dominio di origine di Windows NT 4.0, Windows 2000 o Windows Server 2003.

Per abilitare il controllo degli eventi di gestione di utenti/gruppi in un dominio di origine di Windows NT 4.0, Windows 2000 o Windows Server 2003

1. In User Manager for Domains (Gestione utenti per domini) fare clic sul menu User (Utente ) e selezionare New Local Group ( Nuovo gruppo locale).
2. Immettere un nome di gruppo composto dal nome NetBIOS del dominio di origine aggiunto con tre segni di dollaro ($), ad esempio FABRIKAM$$$$. Il campo description deve indicare che questo gruppo viene usato per controllare l'uso di operazioni DsAddSidHistory o clonazione. Assicurarsi che nel gruppo non siano presenti membri. Fare clic su OK.

L'operazione DsAddSidHistory ha esito negativo se il controllo di origine e destinazione non è abilitato come descritto qui.

Configurare l'attendibilità se necessario

Se una delle condizioni seguenti è vera, è necessario stabilire un trust dal dominio di origine al dominio di destinazione (questo deve verificarsi in una foresta diversa):

• Il dominio di origine è Windows Server 2003.
• Il dominio di origine è Windows NT 4.0 e SrcDomainCreds è NULL.