Usando DsAddSidHistory

A funçãoDsAddSidHistory obtém o identificador de segurança de conta primária (SID) de uma entidade de segurança de um domínio (o domínio de origem) e o adiciona ao atributo sIDHistory de uma entidade de segurança em outro domínio (de destino) em uma floresta diferente. Quando o domínio de origem está no modo nativo do Windows 2000, essa função também recupera os valores de sIDHistory da entidade de origem e os adiciona ao sIDHistoryda entidade de destino.

Adicionar SIDs ao sIDHistory de uma entidade de segurança é uma operação sensível à segurança que efetivamente concede à entidade de destino acesso a todos os recursos acessíveis à entidade de origem, desde que existam relações de confiança dos domínios de recursos aplicáveis para o domínio de destino.

Em um domínio nativo do Windows 2000, um logon de usuário cria um token de acesso que contém o SID da conta primária do usuário e os SIDs de grupo, bem como o sIDHistory do do usuário e o sIDHistory dos grupos dos quais o usuário é membro. A inclusão desses SIDs anteriores (valores de sIDHistory) no token do usuário concede ao usuário acesso a recursos protegidos por listas de controle de acesso (ACLs) contendo os SIDs anteriores.

Essa operação facilita determinados cenários de implantação do Windows 2000. Em particular, ele oferece suporte a um cenário no qual contas em uma nova floresta do Windows 2000 são criadas para usuários e grupos que já existem em um ambiente de produção do Windows NT 4.0. Ao colocar o SID da conta do Windows NT 4.0 na conta do Windows 2000 sIDHistory, o acesso aos recursos de rede é preservado para o utilizador iniciar sessão na sua nova conta do Windows 2000.

DsAddSidHistory também oferece suporte à migração de controladores de domínio de backup (BDCs) do Windows NT 4.0 servindo como servidores de recursos (ou DCs e servidores membros num domínio nativo do Windows 2000) para um domínio do Windows 2000 como servidores membros. Essa migração requer a criação, no domínio de destino do Windows 2000, de grupos locais de domínio que contenham, em seus sIDHistory, os SIDs primários dos grupos locais definidos no BDC (ou grupos locais de domínio referenciados em ACLs nos servidores Windows 2000) no domínio de origem. Ao criar um grupo local de destino contendo o sIDHistory e todos os membros do grupo local de origem, o acesso aos recursos do servidor migrado, protegido por ACLs que fazem referência ao grupo local de origem, é mantido para todos os membros.

Observação

O uso de DsAddSidHistory requer uma compreensão de suas implicações administrativas e de segurança mais amplas nesses e em outros cenários. Para obter mais informações, consulte o white paper "Planning Migration from Windows NT to Microsoft Windows 2000", fornecido como Dommig.doc nas ferramentas de suporte do Windows 2000. Esta documentação também pode ser encontrada no CD do produto em \support\tools.

Requisitos de autorização

DsAddSidHistory requer privilégios de administrador nos domínios de origem e destino. Especificamente, o chamador dessa API deve ser membro do grupo Administradores de Domínio no domínio de destino. Uma verificação codificada para essa associação é executada. Além disso, a conta fornecida no parâmetro SrcDomainCreds deve ser membro do grupo dos Administradores ou dos Administradores de Domínio no domínio de origem. Se for passado NULL em SrcDomainCreds, o utilizador da API deve ser membro do grupo Administradores ou do grupo Administradores de Domínio no domínio de origem.

Requisitos de domínio e confiança

DsAddSidHistory requer que o domínio de destino esteja no modo nativo do Windows 2000 ou posterior, porque apenas este tipo de domínio suporta o atributo sIDHistory. O domínio de origem pode ser Windows NT 4.0 ou Windows 2000, modo misto ou nativo. Os domínios de origem e de destino não devem estar na mesma floresta. Os domínios do Windows NT 4.0 não estão, por definição, em uma floresta. Essa restrição entre florestas garante que SIDs duplicados, quer apareçam como SIDs primários ou valores de sIDHistory, não sejam criados na mesma floresta.

DsAddSidHistory requer uma relação de confiança externa do domínio de origem para o domínio de destino nos casos listados na tabela a seguir.

Caso	Descrição
O domínio de origem é o Windows 2000.	O atributo de origem sIDHistory, disponível apenas em domínios de origem do Windows 2000, pode ser lido somente usando LDAP, o que requer essa confiança para proteção de integridade.
O domínio de origem é o Windows NT 4.0 e SrcDomainCreds é NULL.	A representação, necessária para dar suporte a operações de domínio de origem usando as credenciais do chamador, depende dessa confiança. A representação também requer que o controlador de domínio de destino tenha "Confiável para delegação" habilitado por padrão nos controladores de domínio.

No entanto, não há confiança necessária entre os domínios de origem e de destino se o domínio de origem for Windows NT 4.0 e SrcDomainCreds não estiver NULL .

Requisitos do controlador de domínio de origem

DsAddSidHistory requer que o controlador de domínio, selecionado como destino para operações no domínio de origem, seja o PDC em domínios do Windows NT 4.0 ou o emulador de PDC em domínios do Windows 2000. A auditoria de domínio de origem é gerada por meio de operações de gravação, portanto, o PDC é necessário em domínios de origem do Windows NT 4.0 e a restrição somente PDC garante que auditorias de DsAddSidHistory sejam geradas em um único computador. Isso reduz a necessidade de revisar os logs de auditoria de todos os DCs para monitorar o uso dessa operação.

Observação

Nos domínios de origem do Windows NT 4.0, o PDC (destino das operações no domínio de origem) deve estar executando o Service Pack 4 (SP4) e posterior para garantir o suporte adequado à auditoria.

O seguinte valor do Registro deve ser criado como um valor REG_DWORD e definido como 1 no controlador de domínio de origem para DCs de origem do Windows NT 4.0 e Windows 2000.

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            Lsa
               TcpipClientSupport

A definição desse valor permite chamadas RPC sobre o transporte TCP. Por padrão, isso é necessário porque as interfaces SAMRPC são apenas remotáveis em pipes nomeados. O uso de pipes nomeados resulta em um sistema de gerenciamento de credenciais adequado para usuários conectados interativamente que fazem chamadas em rede, mas não é flexível para um processo do sistema que faz chamadas de rede com credenciais fornecidas pelo usuário. RPC sobre TCP é mais adequado para essa finalidade. Definir esse valor não diminui a segurança do sistema. Se esse valor for criado ou alterado, o controlador de domínio de origem deverá ser reiniciado para que essa configuração entre em vigor.

Um novo grupo local, "<SrcDomainName>$$$", deve ser criado no domínio de origem para fins de auditoria.

Auditoria

operações de DsAddSidHistory são auditadas para garantir que os administradores de domínio de origem e de destino sejam capazes de detetar quando essa função foi executada. A auditoria é obrigatória nos domínios de origem e de destino. DsAddSidHistory verifica se o Modo de Auditoria está ativado em cada domínio e se a auditoria de Gerenciamento de Contas para eventos de Sucesso/Falha está ativada. No domínio de destino, é gerado um evento de auditoria exclusivo "Add Sid History" para cada operação DsAddSidHistory bem-sucedida ou falhada.

Eventos de auditoria exclusivos "Add Sid History" não estão disponíveis em sistemas Windows NT 4.0. Para gerar eventos de auditoria que reflitam inequivocamente o uso de DsAddSidHistory em relação ao domínio de origem, ele executa operações em um grupo especial cujo nome é o identificador exclusivo no log de auditoria. Um grupo local, "<SrcDomainName>$$$", cujo nome é composto pelo nome NetBIOS do domínio de origem anexado com três cifrões ($) (código ASCII = 0x24 e Unicode = U+0024), deve ser criado no controlador de domínio de origem antes de chamar DsAddSidHistory. Cada utilizador de origem e grupo global que é o alvo desta operação é adicionado e, em seguida, removido como membro desse grupo. Isso gera eventos de auditoria de Adição de Membro e Remoção de Membro no domínio de origem, que podem ser monitorados ao pesquisar eventos que façam referência ao nome do grupo.

Observação

operações de DsAddSidHistory em grupos locais num domínio de origem em modo misto do Windows NT 4.0 ou Windows 2000 não podem ser auditadas porque os grupos locais não podem tornar-se membros de outro grupo local e, assim, não podem ser adicionados ao grupo local especial "<SrcDomainName>$$$". Essa falta de auditoria não apresenta um problema de segurança para o domínio de origem, porque o acesso aos recursos do domínio de origem não é afetado por essa operação. Adicionar o SID de um grupo local de origem a um grupo local de destino não concede acesso aos recursos de origem, protegidos por esse grupo local, a nenhum usuário adicional. Adicionar membros ao grupo local de destino não lhes concede acesso aos recursos de origem. Os membros adicionados recebem acesso apenas aos servidores no domínio de destino migrados do domínio de origem, que podem ter recursos protegidos pelo SID do grupo local de origem.

Segurança da transmissão de dados

DsAddSidHistory impõe as seguintes medidas de segurança:

• Chamado a partir de uma estação de trabalho Windows 2000, as credenciais do utilizador são usadas para autenticar e assegurar a privacidade da chamada RPC para o controlador de domínio de destino. Se SrcDomainCreds não estiver NULL, tanto a estação de trabalho como o controlador de domínio de destino deverão oferecer suporte à criptografia de 128 bits para proteger as credenciais. Se a criptografia de 128 bits não estiver disponível e as credenciais de domínio de origem forem fornecidas, a chamada deverá ser feita no DC de destino.
• O controlador de domínio de destino comunica-se com o controlador de domínio de origem usando SrcDomainCreds ou as credenciais do chamador para a autenticação mútua e proteção de integridade da leitura do SID da conta de origem (usando uma consulta SAM) e sIDHistory (usando uma consulta LDAP).

Modelos de ameaça

A tabela a seguir lista as potenciais ameaças associadas à chamada DsAddSidHistory de e aborda as medidas de segurança pertinentes a cada uma dessas ameaças.

Ameaça potencial	Medida de segurança
Ataque do Homem do Meio Um utilizador não autorizado interceta o SID de pesquisa da chamada de retorno do objeto de origem, substituindo o SID do objeto de origem por um SID arbitrário para inserção no histórico de SIDs do objeto de destino.	O SID de consulta do objeto de origem é um RPC autenticado, utilizando as credenciais de administrador do chamador, com proteção de integridade de mensagens de pacote. Isso garante que a chamada de retorno não possa ser modificada sem deteção. O controlador de domínio de destino cria um evento de auditoria exclusivo "Adicionar histórico de SID" que reflete o SID adicionado à conta de destino sIDHistory.
Domínio de origem do Trojan Um usuário não autorizado cria um domínio de origem "Cavalo de Troia" em uma rede privada que tem o mesmo SID de domínio e alguns dos mesmos SIDs de conta que o domínio de origem legítimo. Em seguida, o usuário não autorizado tenta executar DsAddSidHistory em um domínio de destino para obter o SID de uma conta de origem. Isso é feito sem a necessidade das credenciais reais do Administrador de Domínio de origem e sem deixar uma trilha de auditoria no domínio de origem real. O método do usuário não autorizado para criar o domínio de origem do Cavalo de Troia pode ser um dos seguintes: Obtenha uma cópia (backup BDC) do SAM do domínio de origem. Crie um novo domínio, alterando o SID do domínio no disco para corresponder ao SID legítimo do domínio de origem e, em seguida, crie usuários suficientes para instanciar uma conta com o SID desejado. Crie uma réplica BDC. Isso requer credenciais de administrador do domínio de origem. Em seguida, o usuário não autorizado leva a réplica para uma rede privada para implementar o ataque.	Embora existam muitas maneiras de um utilizador não autorizado recuperar ou criar um SID de objeto de origem desejado, o utilizador não autorizado não pode usá-lo para atualizar o sIDHistory de de uma conta sem ser membro do grupo Administradores de Domínio de destino. Como a verificação, no controlador de domínio de destino, da associação de Administrador de Domínio é codificada, no DC de destino, não há nenhum método para fazer uma modificação de disco para alterar os dados de controle de acesso que protegem essa função. Uma tentativa de clonar uma conta de origem Trojan Horse é verificada no domínio de destino. Esse ataque é atenuado reservando a associação ao grupo Administradores de Domínio apenas para indivíduos altamente confiáveis.
Modificação em disco do histórico do SID Um usuário não autorizado sofisticado, com credenciais de Administrador de Domínio e com acesso físico a um DC no domínio de destino, pode modificar uma conta valor de sIDHistory no disco.	Essa tentativa não é habilitada pelo uso de DsAddSidHistory. Esse ataque é atenuado impedindo o acesso físico aos controladores de domínio para todos, exceto administradores altamente confiáveis.
Código fraudulento usado para remover proteções Um usuário não autorizado ou administrador não autorizado com acesso físico ao código do Serviço de Diretório pode criar um código não autorizado que: Remove a verificação de associação no grupo Administradores de Domínio no código. Altera as chamadas do controlador de domínio de origem que apontam o SID para um LookupSidFromName não auditado. Remova chamadas de log de auditoria.	Alguém com acesso físico ao código DS e conhecedor o suficiente para criar código fraudulento tem a capacidade de modificar arbitrariamente o sIDHistory atributo de uma conta. O DsAddSidHistory API não aumenta esse risco de segurança.
Recursos vulneráveis a SIDs roubados Se um usuário não autorizado tiver conseguido usar um dos métodos descritos aqui para modificar uma conta sIDHistory, e se os domínios de recursos de interesse confiarem no domínio da conta de usuário não autorizada, o usuário não autorizado poderá obter acesso não autorizado aos recursos do SID roubado, potencialmente sem deixar uma trilha de auditoria no domínio da conta da qual o SID foi roubado.	Os administradores de domínio de recursos protegem seus recursos configurando apenas as relações de confiança que fazem sentido do ponto de vista da segurança. O uso de DsAddSidHistory é restrito, no domínio de destino confiável, aos membros do grupo Administradores de Domínio que já têm permissões amplas dentro do escopo de suas responsabilidades.
Domínio alvo fraudulento Um usuário não autorizado cria um domínio do Windows 2000 com uma conta cujo sIDHistory contém um SID que foi roubado de um domínio de origem. O usuário não autorizado usa essa conta para acesso não autorizado a recursos.	O usuário não autorizado requer credenciais de administrador para o domínio de origem para usar DsAddSidHistorye deixa uma trilha de auditoria no controlador de domínio de origem. O domínio de destino não autorizado obtém acesso não autorizado apenas em outros domínios que confiam no domínio não autorizado, o que requer privilégios de Administrador nesses domínios de recurso.

Restrições operacionais

Esta seção descreve as restrições operacionais do uso da funçãoDsAddSidHistory.

O SID de SrcPrincipal ainda não deve existir na floresta de destino, seja como um SID de conta primária ou no sIDHistory de uma conta. A exceção é que DsAddSidHistory não gera um erro ao tentar adicionar um SID a um sIDHistory que contém um SID idêntico. Esse comportamento permite que DsAddSidHistory sejam executados várias vezes com entrada idêntica, resultando em sucesso e um estado final consistente, para facilitar o uso do desenvolvedor de ferramentas.

Observação

A latência de replicação do Catálogo Global pode fornecer uma janela durante a qual os SIDs duplicados podem ser criados. No entanto, SIDs duplicados podem ser facilmente excluídos por um administrador.

SrcPrincipal e DstPrincipal devem ser de um dos seguintes tipos:

• Utilizador

• Grupo habilitado para segurança, incluindo:

  Grupo local Grupo global Grupo local de domínio (apenas no modo nativo do Windows 2000) Grupo universal (apenas no modo nativo do Windows 2000)

Os tipos de objeto de SrcPrincipal e DstPrincipal devem corresponder.

• Se SrcPrincipal for um Utilizador, DstPrincipal tem de ser um Utilizador.
• Se SrcPrincipal for um Grupo Local ou um Grupo Local de Domínio, DstPrincipal deverá ser um Grupo Local de Domínio.
• Se SrcPrincipal for um Grupo Global ou Universal, DstPrincipal deverá ser um Grupo Global ou Universal.

SrcPrincipal e DstPrincipal não podem ser de um dos seguintes tipos: (DsAddSidHistory falha com um erro nesses casos)

• Computador (estação de trabalho ou controlador de domínio)

• Confiança entre domínios

• Conta duplicada temporária (recurso praticamente não utilizado, um legado do LANman)

• Contas com SIDs bem conhecidos. SIDs bem conhecidos são idênticos em todos os domínios; assim, adicioná-los a um sIDHistory violaria o requisito de exclusividade do SID de uma floresta do Windows 2000. As contas com SIDs bem conhecidos incluem os seguintes grupos locais:

  Operadores de conta Administradores Operadores de backup Convidados Operadores de impressão Operadores do servidor replicador Usuários

Se SrcPrincipal tiver um identificador relativo (RID) bem conhecido e um prefixo específico do domínio, ou seja, Administradores de Domínio, Usuários de Domínio e Computadores de Domínio, DstPrincipal deverá possuir o mesmo RID conhecido para que DsAddSidHistory tenha êxito. Contas com RIDs conhecidos incluem os seguintes usuários e grupos globais:

• Administrador
• Convidado
• Administradores de domínio
• Convidados do domínio
• Utilizadores do domínio

Definindo o valor do Registro

O procedimento a seguir mostra como definir o valor do Registro TcpipClientSupport.

para definir o valor do Registro TcpipClientSupport

1. Crie o seguinte valor do Registro como um valor REG_DWORD no controlador de domínio de origem e defina seu valor como 1.

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

2. Em seguida, reinicie o controlador de domínio de origem. Esse valor do Registro faz com que o SAM escute no TCP/IP. DsAddSidHistory falhará se esse valor não estiver definido no controlador de domínio de origem.

Habilitando a auditoria de eventos de gerenciamento de usuários/grupos

O procedimento a seguir mostra como habilitar a auditoria de eventos de gerenciamento de usuário/grupo em um domínio de origem ou destino do Windows 2000 ou Windows Server 2003.

Para habilitar a auditoria de eventos de gerenciamento de usuário/grupo em um domínio de origem ou destino do Windows 2000 ou Windows Server 2003

1. No snap-in MMC de Utilizadores e Computadores do Active Directory, selecione o contentor Controladores de Domínio do domínio de destino.
2. Clique com o botão direito do mouse Controladores de Domínio e escolha Propriedades.
3. Clique na guia Diretiva de Grupo.
4. Selecione a Política de Controladores de Domínio Padrão e clique em Editar.
5. Em Configuração Computador\Configurações do Windows\Configurações de Segurança\Diretivas Locais\Política de Auditoria, clique duas vezes em Gerenciamento de Contas de Auditoria .
6. Na janela Gestão de Contas de Auditoria, selecione tanto a auditoria de Sucesso como a de Falha. As atualizações de política entram em vigor após uma reinicialização ou após a ocorrência de uma atualização.
7. Verifique se a auditoria está habilitada através da exibição da política de auditoria efetiva no snap-in MMC da Política de Grupo.

O procedimento a seguir mostra como habilitar a auditoria de eventos de gerenciamento de usuário/grupo em um domínio do Windows NT 4.0.

Para habilitar a auditoria de eventos de gerenciamento de usuário/grupo em um domínio do Windows NT 4.0

1. Em Gerenciador de usuários para domínios, clique no menu Políticas de e selecione de auditoria .
2. Selecione Auditar Esses Eventos.
3. Para Gestão de Utilizadores e Grupos, consulte Sucesso e Falha.

O procedimento a seguir mostra como habilitar a auditoria de eventos de gerenciamento de usuário/grupo em um domínio de origem do Windows NT 4.0, Windows 2000 ou Windows Server 2003.

Para habilitar a auditoria de eventos de gerenciamento de usuário/grupo em um domínio de origem do Windows NT 4.0, Windows 2000 ou Windows Server 2003

1. Em Gestor de Utilizadores para Domínios, clique no menu Utilizador e selecione Novo Grupo Local.
2. Insira um nome de grupo composto pelo nome NetBIOS do domínio de origem anexado com três cifrões ($), por exemplo, FABRIKAM$$$. O campo de descrição deve indicar que esse grupo é usado para auditar o uso de DsAddSidHistory ou operações de clonagem. Certifique-se de que não há membros no grupo. Clique OK.

A operação DsAddSidHistory falhará se a auditoria de origem e destino não estiver habilitada conforme descrito aqui.

Configurar a Confiança, se necessário

Se uma das seguintes opções for verdadeira, uma relação de confiança deverá ser estabelecida do domínio de origem para o domínio de destino (isso deve ocorrer em uma floresta diferente):

• O domínio de origem é o Windows Server 2003.
• O domínio de origem é o Windows NT 4.0 e o SrcDomainCreds é NULL.