Usando DsAddSidHistory
A função DsAddSidHistory obtém o identificador de segurança de conta (SID) primário 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 (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 sIDHistory da entidade de origem e os adiciona ao sIDHistory da 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 de domínios de recursos aplicáveis ao domínio de destino.
Em um domínio do Windows 2000 de modo nativo, 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 usuário e o sIDHistory dos grupos dos quais o usuário é membro. Ter esses SIDs anteriores (valores 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. Colocando o SID de conta do Windows NT 4.0 na conta do Windows 2000 sIDHistory, o acesso aos recursos de rede é preservado para o usuário que faz logon em 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, servidores de recursos (ou DCs e servidores membros em um domínio do Windows 2000 de modo nativo) 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 seu 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, protegidos 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 "Planejando a migração do Windows NT para o Microsoft Windows 2000", entregue 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 de 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 Administradores ou Administradores de Domínio no domínio de origem. Se NULL for passado em SrcDomainCreds, o chamador da API deverá ser membro do grupo Administradores ou 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 somente esse tipo de domínio oferece suporte ao 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. Domínios do Windows NT 4.0 por definição não estão em uma floresta. Essa restrição entre florestas garante que SIDs duplicados, sejam eles exibidos como SIDs primários ou valores 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.
| Caixa | Descrição |
|---|---|
| O domínio de origem é o Windows 2000. |
O atributo sIDHistory de origem, disponível somente em domínios de origem do Windows 2000, pode ser lido somente usando LDAP, 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 em controladores de domínio. |
No entanto, não há nenhuma confiança necessária entre os domínios de origem e de destino se o domínio de origem for o Windows NT 4.0 e SrcDomainCreds não for NULL.
Requisitos do controlador de domínio de origem
DsAddSidHistory requer que o controlador de domínio, selecionado como o destino para operações no domínio de origem, seja o PDC em domínios do Windows NT 4.0 ou o emulador 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 as auditorias 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
Em domínios de origem do Windows NT 4.0, o PDC (destino de operações no domínio de origem) deve estar executando o Service Pack 4 (SP4) e posterior para garantir o suporte de auditoria adequado.
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 os DCs de origem do Windows NT 4.0 e Windows 2000.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Control
Lsa
TcpipClientSupport
A definição desse valor habilita chamadas RPC sobre o transporte TCP. Isso é necessário porque, por padrão, as interfaces SAMRPC são remotas somente 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. A definição desse 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
As operações DsAddSidHistory são auditadas para garantir que os administradores de domínio de origem e de destino possam detectar 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 eventos de Êxito/Falha do Gerenciamento de Contas está ativada. No domínio de destino, um evento de auditoria exclusivo "Adicionar Histórico de Sid" é gerado para cada operação DsAddSidHistory bem-sucedida ou com falha.
Eventos de auditoria exclusivos "Adicionar histórico de Sid" não estão disponíveis em sistemas Windows NT 4.0. Para gerar eventos de auditoria que refletem inequivocamente o uso de DsAddSidHistory no 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 usuário de origem e grupo global que é um destino desta operação é adicionado e removido da associação deste grupo. Isso gera eventos de auditoria Adicionar Membro e Excluir Membro no domínio de origem, que podem ser monitorados pesquisando eventos que fazem referência ao nome do grupo.
Observação
As operações DsAddSidHistory em grupos locais em um domínio de origem de modo misto do Windows NT 4.0 ou Windows 2000 não podem ser auditadas porque os grupos locais não podem ser tornados membros de outro grupo local e, portanto, 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 ao recurso 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 somente 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 de Transmissão de Dados
DsAddSidHistory impõe as seguintes medidas de segurança:
- Chamadas de uma estação de trabalho Windows 2000, as credenciais do chamador são usadas para autenticar e proteger a privacidade da chamada RPC para o controlador de domínio de destino. Se SrcDomainCreds não for NULL, a estação de trabalho e o DC de destino deverão oferecer suporte à criptografia de 128 bits para proteger as credenciais com privacidade. Se a criptografia de 128 bits não estiver disponível e SrcDomainCreds forem fornecidos, a chamada deverá ser feita no DC de destino.
- O controlador de domínio de destino se comunica com o controlador de domínio de origem usando SrcDomainCreds ou as credenciais do chamador para autenticar mutuamente e proteger a integridade da leitura do SID da conta de origem (usando uma pesquisa SAM) e sIDHistory (usando uma leitura LDAP).
Modelos de ameaças
A tabela a seguir lista as ameaças potenciais associadas à chamada DsAddSidHistory e aborda as medidas de segurança pertinentes à ameaça específica.
| Ameaça potencial | Medida de segurança |
|---|---|
| Ataque Man-in-the-Middle Um usuário não autorizado intercepta 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 em um SIDhistory do objeto de destino. |
O SID de pesquisa do objeto de origem é um RPC autenticado, usando as credenciais de administrador do chamador, com proteção de mensagem de integridade de pacote. Isso garante que a chamada de retorno não possa ser modificada sem detecçã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 cavalo de Tróia Um usuário não autorizado cria um domínio de origem "Cavalo de Tróia" 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. O usuário não autorizado, em seguida, 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 de 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 Tróia pode ser um dos seguintes:
|
Embora haja muitas maneiras de um usuário não autorizado recuperar ou criar um SID de objeto de origem desejado, o usuário não autorizado não pode usá-lo para atualizar o sIDHistory 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 do Cavalo de Tróia é auditada 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 sofisticado não autorizado, com credenciais de Administrador de Domínio e com acesso físico a um controlador de domínio no domínio de destino, poderia modificar um valor de sIDHistory de conta no disco. |
Essa tentativa não é habilitada pelo uso de DsAddSidHistory. Esse ataque é atenuado impedindo o acesso físico a controladores de domínio a todos, exceto administradores altamente confiáveis. |
| Código desonesto 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 código não autorizado que:
|
Alguém com acesso físico ao código DS e experiente o suficiente para criar código desonesto tem a capacidade de modificar arbitrariamente o atributo sIDHistory de uma conta. A API DsAddSidHistory 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 um sIDHistory de conta e se os domínios de recurso de interesse confiarem no domínio de conta de usuário não autorizado, 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 do 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 de uma perspectiva de 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 amplas permissões dentro do escopo de suas responsabilidades. |
| Domínio de destino não autorizado 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 DsAddSidHistory e 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 somente 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ção DsAddSidHistory.
O SID de SrcPrincipal 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 seja executado 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 SIDs duplicados podem ser criados. No entanto, SIDs duplicados podem ser facilmente excluídos por um administrador.
SrcPrincipal e DstPrincipal devem ser um dos seguintes tipos:
Usuário
Grupo de Segurança Habilitada, incluindo:
- Grupo local Grupo global Grupo local de domínio (somente modo nativo do Windows 2000) Grupo universal (somente modo nativo do Windows 2000)
Os tipos de objeto de SrcPrincipal e DstPrincipal devem corresponder.
- Se SrcPrincipal for um Usuário, DstPrincipal deverá ser um Usuário.
- Se SrcPrincipal for um Grupo Local ou 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 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; portanto, adicioná-los a um sIDHistory violaria o requisito de exclusividade do SID de uma floresta do Windows 2000. As contas com SIDs conhecidos incluem os seguintes grupos locais:
- Operadores de conta Administradores Operadores de backup Convidados Operadores de impressão Replicador Operadores de servidor Usuários
Se SrcPrincipal tiver um identificador relativo conhecido (RID) e um prefixo específico de 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. As contas com RIDs conhecidos incluem os seguintes usuários e grupos globais:
- Administrador
- Convidado
- Administradores de domínio
- Convidados do domínio
- Usuários de 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
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
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ário/grupo
O procedimento a seguir mostra como habilitar a auditoria de eventos de gerenciamento de usuário/grupo em um domínio de origem ou de 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 de destino do Windows 2000 ou Windows Server 2003
- No Snap-in MMC Usuários e Computadores do Active Directory, selecione o contêiner Controladores de Domínio do domínio de destino.
- Clique com o botão direito do mouse em Controladores de Domínio e escolha Propriedades.
- Clique na guia Diretiva de Grupo .
- Selecione a Diretiva de Controladores de Domínio Padrão e clique em Editar.
- Em Configuração do Computador\Configurações do Windows\Configurações de Segurança\Diretivas Locais\Diretiva de Auditoria, clique duas vezes em Gerenciamento de Contas de Auditoria.
- Na janela Gerenciamento de Contas de Auditoria, selecione Auditoria de Êxito e 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.
- Verifique se a auditoria está habilitada exibindo a diretiva de auditoria efetiva no Snap-in MMC da Diretiva 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
- No Gerenciador de Usuários para Domínios, clique no menu Políticas e selecione Auditoria.
- Selecione Auditar esses eventos.
- Para Gerenciamento de Usuários e Grupos, marque Êxito 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
- No Gerenciador de Usuários para Domínios, clique no menu Usuário e selecione Novo Grupo Local.
- 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 em OK.
A operação DsAddSidHistory falhará se a auditoria de origem e destino não estiver habilitada conforme descrito aqui.
Configurar 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 SrcDomainCreds é NULL.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de