Exportar (0) Imprimir
Expandir Tudo

Novidades nos Serviços de Domínio Active Directory (AD DS)

Publicado: fevereiro de 2012

Atualizado: abril de 2014

Aplica-se a: Windows Server 2012

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Você pode usar o AD DS (Serviços de Domínio Active Directory) no Windows Server 2012 para implantar de forma mais rápida e fácil os controladores de domínio (tanto no local quanto na nuvem), aumentar a flexibilidade ao auditar e autorizar o acesso a arquivos e realizar tarefas administrativas mais facilmente em escala, local ou remotamente, por meio de experiências consistentes de gerenciamento gráfico e por script. As melhorias do AD DS no Windows Server 2012 incluem:

  • Virtualização que realmente funciona

    O Windows Server 2012 oferece um suporte mais abrangente para os recursos de nuvens públicas e privadas por meio das tecnologias seguras de virtualização e para a rápida implantação de controladores de domínio virtuais usando clonagem

  • Implantação simplificada e preparação para atualização

    Os processos de atualização e preparação (dcpromo e adprep) foram substituídos por um novo assistente simples de promoção de controlador de domínio, que foi integrado ao Gerenciador do Servidor e compilado no Windows PowerShell. Ele valida pré-requisitos, automatiza a preparação de floresta e domínio, exige apenas um conjunto de credenciais de logon e pode instalar remotamente o AD DS em um servidor de destino.

  • Gerenciamento simplificado

    Exemplos de gerenciamento simplificado incluem a integração de autorização baseada em declarações no AD DS e na plataforma Windows, dois componentes essenciais de um recurso mais amplo conhecido como DAC (Controle de Acesso Dinâmico). O DAC abrange políticas centrais de acesso, atributos de diretório, o mecanismo de classificação de arquivos do Windows e identidades compostas que combinam, em uma só, a identidade do usuário e a identidade do computador. Além disso, o ADAC (Centro Administrativo do Active Directory) agora permite a execução de tarefas gráficas que geram, automaticamente, os comandos equivalentes do Windows PowerShell. Os comandos podem ser facilmente copiados e colados em um script, simplificando a automação de ações administrativas repetitivas.

  • Alterações da plataforma do AD DS

    A plataforma do AD DS contém a funcionalidade principal, incluindo os comportamentos “secretos” que regem os componentes nos quais o restante do serviço de diretório está compilado. As atualizações para a plataforma do AD DS incluem alocação melhorada e escala de RIDs (identificadores relativos), criação de índice adiada, vários aperfeiçoamentos de Kerberos e suporte para declarações Kerberos (veja Controle de Acesso Dinâmico) no AD FS.

O Active Directory e o AD DS estão no centro da infraestrutura de TI há mais de 10 anos, e seus recursos, adoção e valor agregado aos negócios têm crescido a cada versão. Hoje, a maior parte dessa infraestrutura do Active Directory permanece no local, mas há uma tendência emergente pela computação em nuvem. A adoção da computação em nuvem, porém, não vai ocorrer da noite para o dia e a migração adequada de cargas de trabalho ou aplicativos locais é uma tarefa gradativa e de longo prazo. Novas infraestruturas híbridas vão surgir e é essencial que o AD DS dê suporte às necessidades desses novos e exclusivos modelos de implantação, que incluem serviços totalmente hospedados na nuvem, serviços que contêm componentes locais e na nuvem e serviços que permanecem exclusivamente no local. Esses novos modelos híbridos aumentarão ainda mais a importância, a visibilidade e a ênfase em termos de segurança e conformidade e vão compor a já complexa e demorada tarefa de assegurar que o acesso aos dados e serviços corporativos seja devidamente auditado e expresse com precisão as intenções comerciais.

As seções a seguir descrevem como o AD DS do Windows Server 2012 lida com essas necessidades emergentes.

Para obter mais informações sobre a instalação do AD DS, consulte os artigos sobre implantação do AD DS (Serviços de Domínio Active Directory) em sua empresa e atualização de controladores de domínio no Windows Server 2012.

O AD DS do Windows Server 2012 permite a implantação de réplicas de controladores de domínio virtuais por meio da "clonagem" dos controladores existentes. Você pode promover um único controlador de domínio virtual usando a interface de promoção de controlador de domínio do Gerenciador do Servidor e, depois, implantar rapidamente mais controladores de domínio virtuais no mesmo controlador, por meio de clonagem.

O processo de clonagem envolve a criação de uma cópia de um controlador de domínio virtual existente, autorizando o controlador de domínio de origem a ser clonado no AD DS, e a execução de cmdlets do Windows PowerShell para criar um arquivo de configuração contendo instruções detalhadas de promoção (nome, endereço IP, servidores DNS (Sistema de Nomes de Domínio) etc.). Ou você pode deixar vazio o arquivo de configuração, permitindo que o sistema o preencha automaticamente com as informações. A clonagem reduz o número de etapas e o tempo necessários, pois elimina as tarefas repetitivas de implantação, e isso permite a implantação completa de controladores de domínio adicionais, os quais são autorizados e configurados para clonagem pelo administrador de domínio do Active Directory.

Para saber mais detalhes sobre a clonagem de controlador de domínio virtualizado, veja Virtualização do AD DS (Serviços de Domínio Active Directory).

O AD DS foi virtualizado durante anos, mas os recursos presentes na maioria dos hipervisores podem invalidar concepções sólidas feitas pelos algoritmos de replicação do Active Directory. Primeiramente, os relógios lógicos, que são usados pelos controladores de domínio para determinar os níveis relativos de convergência, apenas avançam no tempo. No Windows Server 2012, um controlador de domínio virtual usa um identificador exclusivo, que é exposto pelo hipervisor. Isso é chamado de GenerationID da máquina virtual. A GenerationID da máquina virtual é alterada sempre que a máquina virtual passa por um evento que afeta sua posição no tempo. A GenerationID da máquina virtual é exposta no espaço de endereços da máquina virtual, no respectivo BIOS, e é disponibilizada para o sistema operacional e para os aplicativos por meio de um driver no Windows Server 2012.

Durante a inicialização e antes da conclusão de qualquer transação, um controlador de domínio virtual em execução no Windows Server 2012 compara o valor atual da GenerationID da máquina virtual com o valor armazenado no diretório. Qualquer incompatibilidade é interpretada como um evento de "reversão" e o controlador de domínio usa as proteções do AD DS, que são novas no Windows Server 2012. Essas proteções permitem que o controlador de domínio virtual faça convergência com outros controladores de domínio e impedem que o controlador de domínio virtual crie entidades de segurança duplicadas. Para que os controladores de domínio virtual do Windows Server 2012 consigam esse nível extra de proteção, o controlador de domínio virtual deve ser hospedado em um hipervisor capaz de reconhecer a GenerationID da máquina virtual; por exemplo, Windows Server 2012 com a função Hyper-V.

Para saber mais detalhes sobre o recurso de tecnologia segura de virtualização, veja Virtualização do AD DS (Serviços de Domínio Active Directory).

A implantação do AD DS no Windows Server 2012 integra todas as etapas necessárias para implantar novos controladores de domínio em uma única interface gráfica. Ela exige apenas uma credencial de nível corporativo e pode preparar a floresta ou o domínio direcionando remotamente as devidas funções de mestre de operações. O novo processo de implantação realiza testes extensos de validação de pré-requisitos, o que minimiza a possibilidade de erros que, de outra forma, poderiam bloquear ou desacelerar a instalação. O processo de instalação do AD DS se baseia no Windows PowerShell, é integrado ao Gerenciador do Servidor e capaz de lidar com vários servidores e implantar remotamente controladores de domínio, o que resulta em uma experiência de implantação mais simples, mais consistente e menos demorada. A figura a seguir mostra o Assistente de Configuração do AD DS do Windows Server 2012.

Figura 1   Assistente de Configuração do AD DS

A instalação do AD DS inclui os seguintes recursos:

  • Integração do Adprep.exe no processo de instalação do AD DS. Isso reduz o tempo necessário para instalar o AD DS e diminui a possibilidade de erros que, de outra forma, bloqueariam a promoção do controlador de domínio.

  • A instalação da função de servidor do AD DS, que se baseia no Windows PowerShell e pode ser executada remotamente em vários servidores. Reduz a probabilidade de erros administrativos e o tempo global necessário à instalação, especialmente quando você faz a implantação de vários controladores de domínio em regiões e domínios globais.

  • Validação de pré-requisitos no Assistente de Configuração do AD DS. Identifica erros potenciais antes do início da instalação. Você pode corrigir antecipadamente as condições de erro, sem a preocupação resultante de uma atualização concluída parcialmente.

  • Páginas de configuração agrupadas em uma sequência que espelha os requisitos das opções de promoção mais comuns, com as opções relacionadas agrupadas em menos páginas do assistente. Fornece um contexto melhor para as escolhas de instalação e reduz o número de etapas e o tempo necessários para concluir a instalação do controlador de domínio.

  • Um assistente que exporta um script do Windows PowerShell contendo todas as opções especificadas durante a instalação gráfica. Simplifica o processo automatizando instalações subsequentes do AD DS por meio de scripts do Windows PowerShell gerados automaticamente.

Para saber detalhes sobre a integração do AD DS com o Gerenciador do Servidor, veja Implantar o AD DS (Serviços de Domínio Active Directory) na sua empresa.

Muitas áreas foram cuidadas com o objetivo de simplificar a experiência de gerenciamento do AD DS. Essas áreas incluem:

Atualmente, é difícil traduzir a intenção da empresa usando o modelo de autorização existente. Os recursos existentes de ACEs (entradas de controle de acesso) dificultam ou impossibilitam exprimir completamente os requisitos. Além disso, não há recursos de administração central. E o cenário atual só faz crescer os requisitos de regulamentação e empresariais em termos de cumprimento, o que intensifica o problema.

Para lidar com esses desafios, o AD DS do Windows Server 2012 introduz:

  • Uma nova plataforma de autorização baseada em declarações que, em vez de substituir, aprimora o modelo existente, o que inclui:

    • Declarações do usuário e declarações do dispositivo

    • Declarações de usuário + dispositivo (também conhecidas como identidade composta)

  • Novo modelo CAP (políticas de acesso central)

  • Utilização de informações de classificação de arquivos nas decisões de autorização

  • Experiência de correção de acesso negado mais fácil

  • As políticas de acesso e de auditoria podem ser definidas de forma flexível e simples:

    • IF resource.Confidentiality = high THEN audit.Success WHEN user.EmployeeType = vendor

Requisitos

  • Um ou mais controladores de domínio do Windows Server 2012

  • Servidor de arquivos do Windows Server 2012

  • Habilitar a política baseada em declarações na Política de Controladores de Domínio Padrão

  • Centro Administrativo do Active Directory do Windows Server 2012

  • Para declarações baseadas em dispositivo, a ID composta deve ser ativada na conta de serviço de destino por meio da Política de Grupo ou edição direta do objeto.

Para saber mais sobre o Controle de Acesso Dinâmico, veja a seção Controle de Acesso Dinâmico da biblioteca técnica.

O recurso de associação offline de domínio, que foi adicionado ao AD DS no Windows Server 2008 R2, permite efetivamente que os computadores clientes ingressem em um domínio sem a exigência de conectividade de rede em um controlador de domínio, mas o computador cliente não pode ser pré-configurado para DirectAccess como parte do ingresso em domínio.

O AD DS do Windows Server 2012 fornece estas melhorias:

  • Estende a associação offline de domínio permitindo que o blob acomode os pré-requisitos do DirectAccess

    • Certificados

    • Políticas de Grupo

  • O que isso significa?

    • Um computador agora pode ingressar no domínio via Internet, desde que o domínio tenha o DirectAccess habilitado

    • A obtenção de blob para o computador que não ingressou no domínio é um processo offline e responsabilidade do administrador

Requisitos

  • Controladores de domínio do Windows Server 2012

Para obter mais informações, consulte o artigo sobre ingresso em domínio offline do DirectAccess.

O AD FS v2.0 é fornecido de maneira independente da versão do Windows Server No Windows Server 2012, o AD FS (v2.1) é fornecido de maneira integrada como uma função de servidor. Isso proporciona:

  • Gerenciamento simplificado da configuração de confiança ou da confiança automática

  • Suporte ao protocolo SAML

  • Repositório de atributos extensível

  • Permite que as declarações tenham origem em qualquer lugar na empresa

  • AD LDS (Active Directory Lightweight Directory Service) e provedores de repositório de atributos SQL não incluídos no fornecimento

Requisitos

  • Windows Server 2012

Para saber detalhes sobre o AD FS do Windows Server 2012, veja AD FS.

O Windows PowerShell é uma tecnologia importante na criação de uma experiência consistente entre a linha de comando e a interface gráfica do usuário. O Windows PowerShell aumenta a produtividade, mas também exige investimentos para aprender a usá-lo.

Para minimizar o investimento em aprendizagem, o Windows Server 2012 inclui o Visualizador de Histórico do Windows PowerShell. Os benefícios incluem:

  • Permite que os administradores exibam os comandos do Windows PowerShell executados ao usar o Centro Administrativo do Active Directory. Por exemplo:

    • O administrador adiciona um usuário a um grupo

    • A interface do usuário exibe o comando equivalente do Windows PowerShell para Active Directory

    • O administrador copia a sintaxe resultante e a integra a um script

    • Reduz a curva de aprendizado do Windows PowerShell

    • Aumenta a confiabilidade do script

    • Melhora ainda mais a capacidade de detecção do Windows PowerShell

Requisitos

  • Centro Administrativo do Active Directory do Windows Server 2012

Para saber mais sobre o Visualizador de Histórico do Windows PowerShell, veja Aperfeiçoamentos do Centro Administrativo do Active Directory.

O recurso Lixeira do Active Directory, que foi incluído no Windows Server® 2008 R2, fornece uma arquitetura que permite a completa recuperação de objetos. Cenários que exijam recuperação de objetos usando a Lixeira do Active Directory são, em geral, de alta prioridade; por exemplo, recuperação de exclusões acidentais resultantes de logons malsucedidos ou interrupções de trabalhos. Mas a falta de uma sofisticada interface gráfica do usuário complicou seu uso e retardou a recuperação.

Para enfrentar esse desafio, o AD DS do Windows Server 2012 tem uma interface do usuário para a Lixeira do Active Directory que fornece as seguintes vantagens:

  • Simplifica a recuperação de objetos por meio da inclusão de um nó de Objetos Excluídos no ADAC (Centro Administrativo do Active Directory)

    • Os objetos excluídos agora podem ser recuperados na interface gráfica do usuário

  • Reduz o tempo de recuperação fornecendo um modo de exibição consistente e detectável do objeto excluído

Requisitos

  • Os requisitos da Lixeira devem ser atendidos:

    • Nível funcional de floresta do Windows Server 2008 R2

    • O recurso opcional Lixeira deve estar habilitado

  • Centro Administrativo do Active Directory do Windows Server 2012

  • É preciso que os objetos necessitando de recuperação tenham sido excluídos no DOL (Tempo de Vida do Objeto Excluído)

    • Por padrão, o DOL está configurado para 180 dias

Para saber mais sobre a interface do usuário para Lixeira do Active Directory, veja Aperfeiçoamentos do Centro Administrativo do Active Directory.

O recurso Política de Senha Refinada (FGPP) introduzido com o Windows Server 2008 forneceu um gerenciamento mais preciso das políticas de senha. Para otimizar o recurso, os administradores tinham que criar manualmente os PSOs (Objetos Configuração de Senha). Isso tornava difícil garantir que os valores de política definidos manualmente tinham o comportamento desejado, o que resultava em demora, avaliação e administração de erros.

No Windows Server 2012:

  • A criação, edição e atribuição de PSOs agora são gerenciadas pelo Centro Administrativo do Active Directory

  • Simplificação substancial do gerenciamento de objetos Configuração de Senha

Requisitos

  • Os requisitos da FGPP devem ser atendidos:

    • Nível funcional de domínio do Windows Server® 2008

  • Centro Administrativo do Active Directory do Windows Server 2012

Para saber mais sobre a interface do usuário para políticas de senha refinada, veja Aperfeiçoamentos do Centro Administrativo do Active Directory.

Os administradores precisam de várias ferramentas para gerenciar a topologia do site do Active Directory

  • repadmin

  • ntdsutil

  • Serviços e sites do Active Directory

O uso de várias ferramentas pode acarretar uma experiência inconsistente e difícil de automatizar.

Com o AD DS do Windows Server 2012, os administradores podem:

  • Gerenciar a replicação e a topologia do site usando o Windows PowerShell

    • Criar e gerenciar sites, links de sites, pontes de link de site, sub-redes e conexões

    • Replicar objetos entre controladores de domínio

    • Exibir os metadados de replicação em atributos de objeto

    • Exibir as falhas de replicação

  • Fornecer uma experiência consistente e de script fácil

  • Compatível e interoperável com outros cmdlets do Windows PowerShell

Requisitos

  • Serviço Web do Active Directory (também conhecido como Gateway de Gerenciamento do Active Directory para Windows Server 2003 ou Windows Server 2008)

  • Controlador de domínio do Windows Server 2012 ou Windows Server 2012 com RSAT (Ferramentas de Administração de Funções) para AD DS e AD LDS instalado

Para saber mais sobre os cmdlets do Windows PowerShell para gerenciamento de topologia e replicação do Active Directory, veja Gerenciamento de replicação e topologia do Active Directory usando Windows PowerShell.

Atualmente, o Licenciamento por Volume do Windows e do Office exige servidores KMS (Serviço de Gerenciamento de Chaves). Essa solução exige um treinamento mínimo e é uma solução turnkey que abrange cerca de 90% de implantações.

Entretanto, há complexidade causada pela falta de um console gráfico de administração. A solução exige tráfego RPC na rede, o que complica tudo, e ela não dá suporte para qualquer tipo de autenticação. O EULA (contrato de licença de usuário final) proíbe o cliente de conectar o servidor KMS a qualquer rede externa. Por exemplo, somente conectividade ao serviço equivale a ativado.

No Windows Server 2012, a ativação baseada no Active Directory fornece estas melhorias:

  • Usa a sua infraestrutura existente do Active Directory para ativar seus clientes

    • Nenhuma máquina adicional é necessária

    • Nenhum requisito de RPC; usa exclusivamente o LDAP

    • Inclui RODCs

  • Além dos requisitos específicos à instalação e ao serviço, nenhum dado é regravado no diretório

    • A ativação de CSVLK (chave de licença de volume específica do cliente) inicial exige:

      • Contato único com os Serviços de Ativação da Microsoft pela Internet (idêntico à ativação no varejo)

      • Chave inserida usando a função de servidor de ativação por volume ou usando a linha de comando.

      • Repete o processo de ativação para florestas adicionais até seis vezes, por padrão

  • Objeto de ativação mantido na partição de configuração

    • Representa o comprovante de compra

    • Os computadores podem ser membros de qualquer domínio na floresta

  • Todos os computadores do Windows 8 serão ativados automaticamente

Requisitos

  • Somente os computadores com Windows 8 podem tirar proveito do AD BA

  • O KMS e o AD BA podem coexistir

    • O KMS ainda será necessário se você exigir licenciamento de volume no nível inferior

  • Exige o esquema do Active Directory do Windows Server 2012, e não controladores de domínio do Windows Server 2012

Para saber mais sobre o AD BA, veja o seguinte:

As MSAs (Contas de Serviço Gerenciado) foram introduzidas com o Windows Server 2008 R2. Não havia suporte para serviços clusterizados ou com balanceamento de carga que precisavam compartilhar uma única entidade de segurança. Consequentemente, as MSAs não podiam ser usadas em muitos dos cenários desejados.

O Windows Server 2012 inclui estas alterações:

  • Introduz um novo tipo de entidade de segurança, conhecido como gMSA

  • Os serviços em execução em vários hosts podem ser executados sob a mesma conta gMSA

  • Um ou mais controladores de domínio do Windows Server 2012 são necessários

    • As gMSAs podem ser autenticadas com base em qualquer controlador de domínio que execute qualquer versão do Windows Server

    • Senhas computadas pelo GKDS (Serviço de Distribuição de Chave de Grupo) em execução em todos os controladores de domínio do Windows Server 2012

  • Hosts do Windows Server 2012 usando gMSAs obtêm senha e atualizações de senha do GKDS

    • Recuperação de senha limitada aos computadores autorizados

  • Intervalo de alteração de senha definido na criação da conta gMSA (30 dias, por padrão)

  • Assim como as MSAs, as gMSAs só têm suporte no SCM (Gerenciador de Controle de Serviço) do Windows e nos pools de aplicativos do IIS

Requisitos

  • Esquema do Active Directory do Windows Server 2012 atualizado nas florestas que contêm as gMSAs

  • Um ou mais controladores de domínio do Windows Server 2012 fornecem computação de senha e recuperação

  • Somente os serviços em execução no Windows Server 2012 podem usar gMSAs

Para saber mais sobre contas de serviço gerenciado de grupo, veja Contas de serviço gerenciado.

Muitas alterações de plataforma foram feitas em termos de escalabilidade, limitação e segurança. Essas áreas incluem:

O AD FS v2.0 é capaz de gerar declarações do usuário diretamente de tokens do Windows NT. O AD FS v2.0 também podia expandir as declarações baseadas em atributos do AD DS e em outros repositórios de atributos.

No Windows Server 2012, os tíquetes Kerberos podem ser populados com os atributos de usuário e dispositivo atuando como declarações. O AD FS 2.0 não pode ler declarações de tíquetes Kerberos. Portanto, é preciso fazer uma chamada LDAP separada ao Active Directory para dar origem às declarações de atributo de usuário; o AD FS 2.0 não pode otimizar declarações de atributo de dispositivo.

O AD FS v2.1 do Windows Server 2012 também pode popular tokens SAML com declarações de usuário e dispositivo diretamente no tíquete Kerberos.

Requisitos

  • Controle de Acesso Dinâmico habilitado e configurado

  • A ID composta deve ser ativada para a conta de serviço do AD FS

  • AD FS v2.1 do Windows Server 2012

Para saber mais detalhes sobre o AD FS do Windows Server 2012, veja AD FS.

As seguintes melhorias do RID no Windows Server 2012 fornecem maior capacidade de reagir a qualquer esgotamento potencial do espaço de pool do RID global:

  • Aviso periódico de consumo do RID

    • Quando o espaço global restante for de 10%, o sistema registrará em log o evento informativo

      • O primeiro evento quando 100.000.000 de RIDs forem usados, o segundo evento será registrado em log em 10% do restante

        • Restante = 900.000.000

        • 10% do restante = 90.000.000

      • Segundo evento registrado em log em 190.000.000

        • Consumo existente de RID somado a 10% do restante

    • Os eventos se tornam mais frequentes à medida que o espaço global se esgota

  • Mecanismo de proteção de limite artificial do Gerenciador de RID

    • Um limite de software de 90% do espaço de RID global; não é configurável

    • O limite de software é considerado como "atingido" quando um pool RID que contém 90% de RID é emitido

    • Bloqueia as alocações posteriores de pools RID

      • Quando o limite é atingido, o sistema define o atributo msDS-RIDPoolAllocationEnabled do objeto RID Manager$ como FALSE. Um administrador deve reconfigurá-lo como TRUE para fazer a substituição.

    • Log de evento indicando que o limite foi atingido

      • Um aviso inicial é registrado em log quando os espaços de RID globais atingem 80%

    • O atributo só pode ser definido como FALSE pelo SYSTEM e é controlado pelo mestre de RID (por exemplo, grave-o no mestre de RID)

      • O administrador de domínio pode redefini-lo como TRUE

        noteNote
        Está definido como TRUE, por padrão

  • Aumente o espaço de RID global por domínio, dobrando o número de entidades de segurança que podem ser criadas em todo o tempo de vida de um domínio, de 1 bilhão para 2 bilhões.

Requisitos

  • Mestre de RID do Windows Server 2012

  • Controladores de domínio do Windows Server 2012

Para saber mais sobre as melhorias do RID, veja Managing RID Issuance.

No passado, a criação de índice podia impactar negativamente o desempenho do controlador de domínio. O Windows Server 2012 introduz um novo recurso que permite, aos administradores de florestas, adiar a criação de índices para o momento que preferirem. Por padrão, os controladores de domínio criam índices quando recebem a alteração adequada de esquema via replicação. No Windows Server 2012, um novo DSheuristic foi incluído para controlar se os controladores de domínio devem ou não adiar a criação de índice. Aqui estão os detalhes:

  • A configuração do 19o byte como 1 faz com que qualquer controlador de domínio do Windows Server 2012 (controladores de domínio que executavam sistemas operacionais anteriores irão ignorar a configuração) adie a criação de índices até:

    • Receber UpdateSchemaNow rootDSE mod (aciona a recriação do cache do esquema)

    • Ser reiniciado (o que exige a recriação do cache do esquema e, por sua vez, os índices adiados)

  • Qualquer atributo que estiver em um estado de índice adiado ser registrado no Log de Evento a cada 24 horas

    • 2944: Índice adiado – registrado uma vez

    • 2945: Índice ainda pendente – registrado a cada 24 horas

    • 1137: Índice criado – registrado uma vez (não é evento novo)

Requisitos

  • Controladores de domínio do Windows Server 2012

A KCD (Delegação Restrita de Kerberos) foi introduzida com o Windows Server 2003. A KCD permite que uma conta de serviço (front-end) aja em nome de usuários em aplicativos de várias camadas para um conjunto limitado de serviços back-end. Por exemplo:

  1. O usuário acessa o site como user1

  2. O usuário solicita informações do site (front-end), o que exige que o servidor Web consulte um banco de dados SQL (back-end)

  3. O acesso aos dados é autorizado de acordo com a pessoa que acessou o front-end

  4. Nesse caso, o serviço Web deve representar o user1 durante a realização da solicitação ao SQL

O front-end precisa ser configurado com os serviços (por SPN) que podem representar usuários. A instalação e a administração exigem credenciais de Administrador de Domínio. A delegação KCD só funciona para os serviços back-end no mesmo domínio das contas de serviço front-end.

A KCD do Windows Server 2012 move a decisão de autorização para os proprietários de recursos, fornecendo estas vantagens:

  • Permite ao back-end autorizar quais contas de serviço front-end podem representar usuários nos recursos

  • Dá suporte em cenários de domínios e florestas

  • Não exige mais os privilégios de Administrador de Domínio

    • Exige apenas a permissão administrativa para a conta de serviço back-end

Requisitos

  • Clientes executando o Windows XP ou posterior

  • Controladores de domínio do cliente executando Windows Server 2003 ou posterior

  • Servidor front-end executando o Windows Server 2012

  • Um ou mais controladores de domínio no domínio front-end executando o Windows Server 2012

  • Um ou mais controladores de domínio no domínio back-end executando o Windows Server 2012

  • Conta do servidor back-end configurada com as contas autorizadas para representação

    • Não é exposto pelo Centro Administrativo do Active Directory

    • Configurado por meio do Windows PowerShell:

      • New/Set-ADComputer [-name] <string> [-PrincipalsAllowedToDelegateToAccount <ADPrincipal[]>]

      • New/Set-ADServiceAccount [-name] <string> [-PrincipalsAllowedToDelegateToAccount <ADPrincipal[]>]

  • Atualização de esquema do Windows Server 2012 na floresta do servidor back-end:

  • Servidor de aplicativos back-end executando o Windows Server 2003 ou posterior

Para saber mais sobre delegação restrita de Kerberos, veja a seção Kerberos da biblioteca técnica.

Atualmente, é possível um ataque de dicionário offline nos logons baseados em senha. Há uma preocupação relativamente bem conhecida sobre os erros de Kerberos serem falsificados. Os clientes podem:

  • Executar fallback para protocolos herdados menos seguros

  • Enfraquecer a chave criptográfica e/ou as criptografias

O Kerberos no Windows Server 2012 oferece suporte a FAST (Encapsulamento Seguro de Autenticação Flexível)

  • Definido por RFC 6113

  • Às vezes, conhecido como proteção Kerberos

  • Fornece um canal protegido entre um cliente ingressado no domínio e o controlador de domínio

    • Protege os dados antes da autenticação para AS_REQs do usuário

      • Usa a LSK (chave de sessão de logon) do TGT do computador como um segredo compartilhado

      • Observe que a autenticação do computador NÃO é protegida

    • Permite que os controladores de domínio retornem erros autenticados do Kerberos, protegendo-os contra falsificação

  • Quando todos os clientes Kerberos e controladores de domínio derem suporte ao FAST (decisão a ser tomada pelo administrador)

    • O domínio poderá ser configurado para exigir proteção Kerberos ou para usá-la quando necessária

      • É preciso primeiro garantir que todos os controladores de domínio ou um número suficiente deles estejam executando o Windows Server 2012

      • Habilitar a política apropriada

        • “Suporte CBAC e proteção Kerberos”

        • “Todos os controladores de domínio podem dar suporte CBAC e exigir proteção Kerberos”

Requisitos

  • Servidores Windows Server 2012

  • Todos os domínios usados pelo cliente, incluindo os domínios de referência transitados, devem:

    • Habilitar a política "Suporte CBAC e proteção Kerberos" em todos os controladores de domínio do Windows Server 2012

    • Ter um número suficiente de controladores de domínio do Windows Server 2012 para dar suporte a FAST

  • Habilitar a política “Exigir FAST” em clientes compatíveis

  • A interoperabilidade FAST em conformidade com RFC requer nível funcional de domínio do Windows Server 2012

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários

Contribuições da comunidade

A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft