Atualizações de componentes dos Serviços de Diretório
Autor: Justin Turner, engenheiro sênior de escalonamento de suporte com o grupo do Windows
Observação
Este documento foi criado por um engenheiro de atendimento ao cliente da Microsoft e é destinado a administradores e arquitetos de sistemas experientes que procuram explicações técnicas mais profundas para recursos e soluções no Windows Server 2012 R2 do que aquelas geralmente oferecidas em tópicos do TechNet. No entanto, ele não passou pelas mesmas etapas de edição que eles, por isso a linguagem pode parecer que menos refinada do que a geralmente encontrada no TechNet.
Esta lição explica as atualizações de componentes dos Serviços de Diretório no Windows Server 2012 R2.
O que você vai aprender
Explique as seguintes novas atualizações de componentes dos Serviços de Diretório:
Explique as seguintes novas atualizações de componentes dos Serviços de Diretório:
Níveis funcionais de domínio e de floresta
Visão geral
A seção fornece uma breve introdução às alterações no nível funcional de domínio e de floresta.
Novo DFL e FFL
Com a versão, há novos níveis funcionais de domínio e de floresta:
Nível funcional de floresta: Windows Server 2012 R2
Nível funcional de domínio: Windows Server 2012 R2
O nível funcional de domínio do Windows Server 2012 R2 habilita o suporte para o seguinte:
Proteções no lado do controlador de domínio para usuários protegidos
Os usuários protegidos que se autenticam em um domínio do Windows Server 2012 R2 não podem mais:
Autenticar-se com a autenticação NTLM
Usar pacotes de criptografia DES ou RC4 na pré-autenticação Kerberos
Ser delegados com delegação restrita ou irrestrita
Renovar tíquetes de usuário (TGTs) além do tempo de vida inicial de quatro horas
Políticas de autenticação
Novas políticas do Active Directory baseadas em floresta que podem ser aplicadas às contas em domínios do Windows Server 2012 R2 para controlar em quais hosts uma conta pode se conectar e aplicar condições de controle de acesso para autenticação em serviços em execução como uma conta
Silos de política de autenticação
Novo objeto do Active Directory baseado em floresta que pode criar uma relação entre usuário, serviço gerenciado e contas de computador a serem usadas para classificar contas para políticas de autenticação ou para isolamento de autenticação.
Confira Como configurar contas protegidas para obter mais informações.
Além dos recursos acima, o nível funcional de domínio do Windows Server 2012 R2 garante que qualquer controlador de domínio no domínio execute o Windows Server 2012 R2. O nível funcional de floresta do Windows Server 2012 R2 não fornece novos recursos, mas garante que todo domínio criado na floresta opere automaticamente no nível funcional de domínio do Windows Server 2012 R2.
DFL mínimo imposto na criação de um domínio
O DFL do Windows Server 2008 é o nível funcional mínimo com suporte na criação de um domínio.
Observação
A substituição do FRS é feita com a remoção da capacidade de instalar um novo domínio com um nível funcional de domínio inferior ao Windows Server 2008 com o Gerenciador do Servidor ou por meio do Windows PowerShell.
Como reduzir os níveis funcionais de floresta e de domínio
Os níveis funcionais de floresta e de domínio são definidos como o Windows Server 2012 R2 por padrão na criação de domínios e florestas, mas podem ser reduzidos usando o Windows PowerShell.
Para elevar ou diminuir o nível funcional de floresta usando o Windows PowerShell, use o cmdlet Set-ADForestMode.
Para definir o FFL de contoso.com para o modo do Windows Server 2008:
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
Para aumentar ou diminuir o nível funcional de domínio usando o Windows PowerShell, use o cmdlet Set-ADDomainMode.
Para definir o DFL de contoso.com para o modo do Windows Server 2008:
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
A promoção de um controlador de domínio que executa o Windows Server 2012 R2 como uma réplica adicional em um domínio existente que executa a DFL 2003 funciona.
Criação de domínio em uma floresta existente
ADPREP
Não há novas operações de floresta ou de domínio nesta versão.
Esses arquivos .ldf contêm alterações de esquema para o Serviço de Registro de Dispositivo.
Sch59
Sch61
Sch62
Sch63
Sch64
Sch65
Sch67
Pastas de Trabalho:
- Sch66
MSODS:
- Sch60
Políticas e silos de autenticação
Sch68
Sch69
NTFRS preterido
Visão geral
O FRS foi preterido no Windows Server 2012 R2. A reprovação do FRS é realizada pela imposição de um DFL (nível funcional de domínio) mínimo do Windows Server 2008. Essa imposição estará presente somente se o novo domínio for criado por meio do Gerenciador do Servidor ou do Windows PowerShell.
Use o parâmetro -DomainMode com os cmdlets Install-ADDSForest ou Install-ADDSDomain para especificar o nível funcional de domínio. Os valores com suporte nesse parâmetro podem ser um inteiro válido ou um valor de cadeia de caracteres enumerado correspondente. Por exemplo, para definir o nível do modo de domínio como o Windows Server 2008 R2, você pode especificar um valor igual a 4 ou "Win2008R2". Ao executar esses cmdlets no Server 2012 R2, os valores válidos incluem aqueles para o Windows Server 2008 (3, Win2008), o Windows Server 2008 R2 (4, Win2008R2), o Windows Server 2012 (5, Win2012) e o Windows Server 2012 R2 (6, Win2012R2). O nível de domínio funcional não pode ser inferior ao nível funcional da floresta, mas pode ser superior. Como o FRS foi preterido nesta versão, o Windows Server 2003 (2, Win2003) não é um parâmetro reconhecido com esses cmdlets quando executado no Windows Server 2012 R2.
Alterações do otimizador de consultas LDAP
Visão geral
O algoritmo do otimizador de consulta LDAP foi reavaliado e otimizado ainda mais. O resultado é o aprimoramento de desempenho na eficiência da pesquisa LDAP e no tempo da pesquisa LDAP de consultas complexas.
Observação
Do desenvolvedor: aprimoramentos no desempenho de pesquisas por meio de aprimoramentos no mapeamento da consulta LDAP para a consulta ESE. Os filtros LDAP, além de determinado nível de complexidade, impedem a seleção otimizada de índice, resultando em um desempenho drasticamente reduzido (1.000x ou mais). Esta alteração muda a maneira como selecionamos índices para consultas LDAP a fim de evitar esse problema.
Observação
Uma revisão completa do algoritmo de otimizador de consulta LDAP, resultando em:
- Tempos de pesquisa mais rápidos
- Os ganhos de eficiência permitem que os controladores de domínio façam mais
- Menos chamadas de suporte em relação a problemas de desempenho do AD
- Portado novamente para o Windows Server 2008 R2 (KB 2862304)
Tela de fundo
A capacidade de pesquisar o Active Directory é um serviço principal fornecido pelos controladores de domínio. Outros serviços e aplicativos de linha de negócios dependem das pesquisas do Active Directory. As operações de negócios poderão ser interrompidas se esse recurso não estiver disponível. Como um serviço principal e muito usado, é fundamental que os controladores de domínio lidem com o tráfego de pesquisa LDAP de maneira eficiente. O algoritmo de otimizador de consulta LDAP tenta tornar as pesquisas LDAP as mais eficientes possíveis mapeando os filtros de pesquisa LDAP para um conjunto de resultados que pode ser atendido por meio de registros já indexados no banco de dados. Esse algoritmo foi reavaliado e otimizado ainda mais. O resultado é o aprimoramento de desempenho na eficiência da pesquisa LDAP e no tempo da pesquisa LDAP de consultas complexas.
Detalhes da alteração
Uma pesquisa LDAP contém:
Um local (cabeçalho de NC, UO, Objeto) dentro da hierarquia para iniciar a pesquisa
Um filtro de pesquisa
Uma lista de atributos a serem retornados
Esse processo de pesquisa pode ser resumido da seguinte forma:
Simplifique o filtro de pesquisa, se possível.
Selecione um conjunto de chaves de índice que retornará o menor conjunto coberto.
Execute uma ou mais interseções de chaves de índice para reduzir o conjunto coberto.
Para cada registro no conjunto coberto, avalie a expressão de filtro, bem como a segurança. Se o filtro for avaliado como TRUE e o acesso for permitido, retorne esse registro ao cliente.
O trabalho de otimização de consulta LDAP modifica as etapas 2 e 3, a fim de reduzir o tamanho do conjunto coberto. Mais especificamente, a implementação atual seleciona chaves de índice duplicadas e executa interseções redundantes.
Comparação entre o algoritmo antigo e o novo
O destino da pesquisa LDAP ineficiente neste exemplo é um controlador de domínio do Windows Server 2012. A pesquisa é concluída em aproximadamente 44 segundos como resultado da falha na localização de um índice mais eficiente.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt
Using server: WINSRV-DC1.blue.contoso.com:389
<removed search results>
Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
DNT_index:516615:N
Pages Referenced : 4619650
Pages Read From Disk : 973
Pages Pre-read From Disk : 180898
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Exemplos de resultados usando o novo algoritmo
Este exemplo repete exatamente a mesma pesquisa acima, mas é direcionado a um controlador de domínio do Windows Server 2012 R2. A mesma pesquisa é concluída em menos de um segundo devido aos aprimoramentos no algoritmo de otimizador de consulta LDAP.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt
Using server: winblueDC1.blue.contoso.com:389
.<removed search results>
Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
idx_userPrincipalName:648:N
idx_postalCode:323:N
idx_cn:1:N
Pages Referenced : 15350
Pages Read From Disk : 176
Pages Pre-read From Disk : 2
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Se não for possível otimizar a árvore:
Por exemplo: uma expressão na árvore estava sobre uma coluna não indexada
Registrar uma lista de índices que impedem a otimização
Exposto por meio do rastreamento ETW e da ID de evento 1644
Para habilitar o controle Stats no LDP
Abra o LDP.exe e conecte-se e associe-o a um controlador de domínio.
No menu Opções, selecione Controles.
Na caixa de diálogo Controles, expanda o menu suspenso Carregar Predefinido, selecione Estatísticas de Pesquisa e selecione OK.
No menu Procurar, selecione Pesquisar
Na caixa de diálogo Pesquisar, selecione o botão Opções.
Verifique se a caixa de seleção Estendido está selecionada na caixa de diálogo Opções de Pesquisa e selecione OK.
Experimente isso: usar o LDP para retornar as estatísticas de consulta
Realize as etapas a seguir em um controlador de domínio ou em um cliente ou um servidor ingressado no domínio que tenha as ferramentas do AD DS instaladas. Repita a etapa a seguir direcionando-a ao controlador de domínio do Windows Server 2012 e ao controlador de domínio do Windows Server 2012 R2.
Leia o artigo "Como criar aplicativos habilitados para o Microsoft AD mais eficientes" e consulte-o conforme necessário.
Usando o LDP, habilite as estatísticas de pesquisa (confira Para habilitar o controle Stats no LDP)
Realize várias pesquisas LDAP e observe as informações estatísticas na parte superior dos resultados. Você repetirá a mesma pesquisa em outras atividades para documentá-las em um arquivo de texto do bloco de notas.
Executar uma pesquisa LDAP que o otimizador de consulta deve conseguir otimizar devido aos índices de atributos
Tente construir uma pesquisa que leva muito tempo para ser concluída (o ideal é aumentar a opção Limite de tempo para que a pesquisa não tenha um tempo limite).
Recursos adicionais
O que são pesquisas do Active Directory?
Como funcionam as pesquisas do Active Directory
Como criar aplicativos habilitados para o Microsoft Active Directory mais eficientes
951581 As consultas LDAP são executadas mais lentamente do que o esperado no serviço de diretório do AD ou do LDS/ADAM e a ID de Evento 1644 poderá ser registrada em log
Melhorias no evento 1644
Visão geral
Esta atualização adiciona estatísticas extras de resultado da pesquisa LDAP à ID de evento 1644 para ajudar na solução de problemas. Além disso, há um novo valor do Registro que pode ser usado para habilitar o log em um limite baseado em tempo. Esses aprimoramentos foram disponibilizados no Windows Server 2012 e no Windows Server 2008 R2 SP1 por meio da KB 2800945 e serão disponibilizados para o Windows Server 2008 SP2.
Observação
- Estatísticas de pesquisa LDAP adicionais são incluídas na ID de evento 1644 para ajudar na solução de problemas de pesquisas LDAP ineficientes ou caras
- Agora você pode especificar um Limite de Tempo de Pesquisa (por exemplo, Evento de log 1644 para pesquisas que demoram mais de 100 ms) em vez de especificar os valores de limite de resultado de pesquisa cara e ineficiente
Tela de fundo
Ao solucionar problemas de desempenho do Active Directory, fica evidente que a atividade de pesquisa LDAP pode contribuir para o problema. Você decide habilitar o log para que ver as consultas LDAP caras ou ineficientes processadas pelo controlador de domínio. Para habilitar o log, você precisa definir o valor de diagnóstico de Engenharia de Campo e, opcionalmente, pode especificar os valores de limite de resultados da pesquisa caros/ineficientes. Ao habilitar o nível de registros em log de Engenharia de Campo para o valor 5, qualquer pesquisa que atenda a esses critérios é registrada no log de eventos dos Serviços de Diretório com a ID de evento 1644.
O evento contém:
IP e porta do cliente
Nó inicial
Filtrar
Escopo da pesquisa
Seleção de atributos
Controles de servidor
Entradas acessadas
Entradas retornadas
No entanto, os dados principais estão ausentes do evento, como o tempo gasto na operação de pesquisa e o índice (se houver) usado.
Estatísticas de pesquisa adicionais incluídas no evento 1644
Índices usados
Páginas referenciadas
Páginas lidas do disco
Páginas lidas previamente do disco
Páginas limpas modificadas
Páginas sujas modificadas
Tempo de pesquisa
Atributos que impedem a otimização
Novo valor do registro de limite baseado em tempo para o log do evento 1644
Em vez de especificar os valores de limite de resultado de pesquisa Cara e Ineficiente, você pode especificar Limite de Tempo de Pesquisa. Se você quiser registrar todos os resultados da pesquisa que levaram 50 ms ou mais, especifique 50 decimais / 32 hexa (além de definir o valor de Engenharia de Campo).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032
Comparação da ID de evento 1644 antiga e nova
OLD
NEW
Experimente isso: usar o log de eventos para retornar as estatísticas de consulta
Repita a etapa a seguir direcionando-a ao controlador de domínio do Windows Server 2012 e ao controlador de domínio do Windows Server 2012 R2. Observe a ID de evento 1644s em ambos os controladores de domínio após cada pesquisa.
Usando o REGEDIT, habilite o log da ID de evento 1644 usando um limite baseado em tempo no controlador de domínio do Windows Server 2012 R2 e no método antigo no controlador de domínio do Windows Server 2012.
Realize várias pesquisas LDAP que excedem o limite e observe as informações estatísticas na parte superior dos resultados. Use as consultas LDAP documentadas anteriormente e repita as pesquisas.
Execute uma pesquisa LDAP que o otimizador de consulta não seja capaz de otimizar devido a um ou mais atributos não estarem indexados.
Melhoria da taxa de transferência de replicação do Active Directory
Visão geral
A replicação do AD usa a RPC para o transporte de replicação. Por padrão, o RPC usa um buffer de transmissão de 8K e um tamanho de pacote igual a 5K. Isso apresenta o resultado final em que a instância de envio transmitirá três pacotes (aproximadamente 15 mil em dados) e precisará aguardar uma viagem de ida e volta de rede antes de enviar mais. Supondo um tempo de viagem de ida e volta de 3ms, a maior taxa de transferência será de cerca de 40 Mbps, mesmo em redes de 1 Gbps ou 10 Gbps.
Observação
Esta atualização ajusta a taxa de transferência máxima de replicação do AD de 40 Mbps para cerca de 600 Mbps.
- Ela aumenta o tamanho do buffer de envio de RPC, o que reduz o número de viagens de ida e volta de rede
O efeito será mais perceptível em uma rede de alta velocidade e alta latência.
Esta atualização aumenta a taxa de transferência máxima para cerca de 600 Mbps alterando o tamanho do buffer de envio de RPC de 8K para 256 KB. Esta alteração permite que o tamanho da janela do TCP cresça além de 8K, reduzindo o número de viagens de ida e volta de rede.
Observação
Não há configurações que podem ser definidas para modificar esse comportamento.