- Adicione a role “Network Policy and Access Services” via Server Manager;
Habilite os seguintes roles services na instalação
 Remote Access Service
 Routing

- Adicione um novo Radius Client no NPS
NPS > Radius Client And Services > Radius Clients > Add New Clients
Insira um nome, o endereço do cliente Radius (equipamento/software que vai fazer a autenticação)  e uma senha (Shared Secret) que deverá ser inserido nas configurações Radius do cliente.

- Adicione uma política
NPS (Local) -> Policies -> Right-click Network Policies -> Add new.
Inserir um nome e deixar Type of network access server em branco.
Adicione uma condição. É neste momento que se define o grupo em que os usuários que farão logon via Radius estão.
Marcar “Access Granted”.
Avançar até o fim. Não é necessário mais nenhuma configuração.

- Configure o Radius Client
Neste momento, passamos à configuração do cliente. No caso de um switch ou roteador, por exemplo, basta desabilitar a autenticação local e colocar o endereço do servidor Radius. Independente do cliente, será necessário informar a Shared Secret criada no NPS.

O evento é fechado: o convite é condicionado à participação ativa em eventos técnicos, fóruns, webcast e blog. Tenho a honra de ser convidado pela terceira vez seguida. Bom saber que minhas pequenas contribuições em forma de artigos e palestras têm ajudado alguém por aí

Para quem for, até lá. E para quem não for, aguardem muitas novidades aqui pelo blog.

Boas práticas para redirecionamentos DNS
Forwarders
Recomenda-se configurar pelo menos dois Forwarders em servidores DNS que “saiam” para a Internet, por motivos de redundância. Recomenda-se também elaborar um procedimento para checar regularmente se os Forwarders definidos estão respondendo e ativos.

Root Hints
Para servidores DNS que não saem diretamente para a Internet, é recomendável desligar Root Hints. O timeout padrão para uma query repassada aos Forwarders é de 5 segundos. Se não houver retorno nesse tempo, um Root Hint é consultado e a query é resolvida recursivamente. Desligar os Root Hints força o fluxo a passar pelos Forwarders. Se os Forwarders pararem de responder logo será percebido.

Round Robin vs. Netmask Ordering
Na especificação original do DNS, previu-se que para o caso em que existam vários IPs cadastrados para um mesmo hostname o servidor retornaria um dos IP’s aleatoriamente seguindo o algoritmo Round Robin. O uso do Round Robin fornece aleatoriamente uma das várias entradas de IP para determinado nome, a cada requisição.

Na verdade, todas as entradas são retornadas a cada requisição e o DNS Client trata a lista recebida. O que o algoritmo faz é ordenar os resultados aleatoriamente. Este cenário é muito interessante para balanceamento de carga, por exemplo. O Round Robin pode ser indesejável, entretando, num cenário em que os servidores estejam dispersos geograficamente e sejam interligados por links de longa distância.

Visando em especial atender a estes cenários foi incluído a partir do Windows 2000 a funcionalidade Netmask Ordering no DNS. O Netmask Ordering faz um cálculo (cálculo explicado aqui) para determinar a distância dos servidores DNS disponíveis ao DNS Client requisitante. Desta forma a lista de IPs devolvida é encabeçada pelo servidor provavelmente “mais próximo” (na mesma subrede ou em subrede próxima) ao solicitante. Este comportamento é extremamente desejado em cenários de branch office, por exemplo.

Netmask Ordering e Round Robin podem coexistir. Este cenário é, inclusive, a configuração padrão. Desta forma os registros estarão organizados tanto por subrede quanto balanceados por aleatoriedade. Caso algum dos dois comportamentos não seja desejado é possível desabilitá-los.

Limpeza de registros DNS
Registros em um servidor DNS podem ser estáticos ou dinâmicos. Registros estáticos são os criados manualmente, via console MMC/Server Manager, utilitário dnscmd ou provider Powershell. Registros dinâmicos são geralmente criados ao se receber um endereço via servidor DHCP, por exemplo.

Em cenários complexos, os registros dinâmicos geram uma grande carga administrativa. Em geral, há problemas tanto de vários hostnames apontando para um mesmo IP quanto o inverso, vários IPs apontando para o mesmo hostname. O primeiro sinal de que problemas desta ordem estão acontecendo é que serviços que se utilizam de resolução de nomes começam a falhar sem causa aparente.

Felizmente, há procedimentos que automatizam a limpeza de registros dinâmicos que não sejam mais válidos (e apenas destes!). Em especial, a limpeza destes registros é feita combinando-se duas funcionalidades. O Aging define para os registros uma data de criação e é também responsável por fazer o controle desses “timestamps”. O Scavenging promove um ciclo de limpeza de registros. Apenas registros datados (que sofreram Aging) serão contemplados por uma thread de Scavenging.

Para habilitar os procedimentos de limpeza, são necessárias ações em três níveis: no servidor DNS, na zona em que se deseja habilitar o procedimento e nos registros em si. No servidor, deve-se permitir que o Scavenging seja executado. Na configuração padrão, o Scavenging é executado a cada 7 dias. Para definir esta configuração devemos acessar o console MMC do DNS, Server Manager ou RSAT. Botão direito no servidor DNS > Properties > Aba “Advanced” > Habilitar a opção “Enable automatic scavenging of stale records”.

O processo de Aging/Scavenging só atua sobre registros dinâmicos. Pode-se facilmente observar quais registros DNS são dinâmicos através do console de gerenciamento do DNS a partir do Windows Server 2008.

Quanto à zona, deve-se certificar que a zona em que se deseja habilitar os procedimentos de manutenção automática seja primária. Deve-se ainda definir o Aging para a zona para garantir que seu registros criados sejam datados automaticamente. Para habilitar a opção de Aging, botão direito na zona > “Properties” > “Aging” > marcar “Scavenge stale resource records” e definir “No-refresh interval” e “Refresh interval”.

A definição dos intervalos “Refresh” e “No-refresh” é muito importante para o sucesso do procedimento de limpeza. O intervalo de “No-refresh” está relacionado com a manutenção constante do registro e define o período em que o registro permanece na base de dados do DNS sem renovar o timestamp. Outras alterações no registro são permitidas. O objetivo deste intervalo é diminuir tráfego de replicação por renovação de timestamp.

O valor “Refresh” refere-se ao período de tempo em que os timestamp dos registros pode ser renovado. Quando da atualização do timestamp registro, o período de “No-refresh” é novamente iniciado. Automaticamente é feita a replicação do registro para outros servidores para a zona. Se o registro não for atualizado pelo DNS Client durante o “Refresh Interval” o registro é considerado como marcado para deleção pelo Scavenging.

Definindo intervalos e verificando funcionamento
O processo de Scavenging é configurado, como dito anteriormente, no nível de servidor DNS. A cada ciclo, a thread de Scavenging verifica quais zonas são primárias para o servidor. Dentre as zonas primárias, o processo será executado apenas nas zonas com Aging habilitado. Nessas zonas, o procedimento vai verificar quais registros dinâmicos expiraram. Para um registro ser considerado expirado ele deve ter seu timestamp maior que a soma dos intervalos de “No-refresh” e “Refresh. Isto significa que o registro foi criado e não foi renovado pelo DNS Client que o criou e, provavelmente, refere-se a um computador que obteve um novo endereço IP via DHCP, por exemplo.

Como registros dinâmicos são em geral criados por concessões de endereço IP obtidas via DHCP, uma boa prática é definir os intervalos de Aging associados à duração do lease DHCP. Desta forma, a soma dos intervalos de “No-refresh” e “Refresh” deve ser menor que a duração do lease DHCP. Assim, a limpeza provavelmente ocorrerá logo antes da expiração do lease. Se o lease do servidor DHCP tiver duração de 8 dias, por exemplo, é razoável definir o “No-refresh” para 4 dias e “Refresh” para 3 dias (4+3 = 7, menor que 8).

Dois eventos descrevem o correto funcionamento dos processos de limpeza. O evento 2501 descreve que o processo de Scavenging ocorreu corretamente. O evento 2502 reporta que, apesar do Scavenging ter sido executado, provavelmente nenhuma zona estava configurada para remoção automática de registros.

Outra recomendação relevante é tomar alguns cuidados na implementação. O Scavenging deve ser definido em servidores de sites centrais. Isto evita deleções acidentais. Deve ainda se tomar cuidado com a duração dos intervalos, definindo-os com uma margem de segurança.

*Contribuiu Luis Roberto Tognini – Premium Field Engineer, Microsoft

Tipos de consultas DNS

Como sabemos, a função principal de um servidor DNS é prover tradução de endereços IP em nomes de fácil memorização. Desta forma ao invés de decorar o endereço IP de cada servidor da rede pode-se apenas memorizar um mnemônico que remeta ao serviço que oferecido pelo servidor. Para executar esta função o DNS tem uma arquitetura cliente-servidor. Os clientes DNS enviam aos servidores requisições de vários tipos, entre eles: 

- Host (A)
DNS Client envia um FQDN* na requisição e o servidor DNS retorna um endereço IP formato IPv4.

* FQDN: Fully-Qualified Domain Name, nome que descreve completamente um host na estrutura DNS. Por exemplo, se o nome do host é “desktop” e o domínio “robertobraga.net”, o FQDN será “desktop.robertobraga.net” 

- Host (AAAA)
DNS Client envia um FQDN na requisição e o servidor DNS retorna um endereço IP formato IPv6. Os registros do tipo AAAA tem suporte tanto no Windows 2000 Server, Windows Server 2003 e Windows Server 2008. O transporte DNS é possível, entretanto, apenas a partir do Windows Server 2003 e a funcionalidade não vem habilitada por padrão. A partir do Windows Server 2008 o suporte a IPv6 é nativo.

- Alias (CNAME)
Em uma requisição do tipo CNAME (Canonical Name), traduz-se um FQDN em outro FQDN. É utlizado para a criação de alias em servidores DNS.

- Pointer (PTR)
Registros do tipo Pointer (PTR) fazem consultas reversas no DNS. O DNS Client envia na requisição um endereço IPv4 ou IPv6 e recebe um FQDN como resposta.

- Service Location (SRV)
Em uma requisição deste tipo, o requisitante envia um serviço e respectivo protocolo e recebe como resposta uma Porta e um FQDN. É utlizado em protocolos recentes, como SIP e XMPP. É também utilizado no processo de descoberta de Domain Controllers em um domínio Active Directory. 

- Mail Exchanger (MX)
A requisição passa um FQDN de nome de domínio e recebe como resposta um FQDN de servidor de correio para aquele domínio.

Zonas em um servidor DNS
O DNS utiliza-se da estrutura em forma de zonas para executar suas funções. Uma zona armazena nomes para determinado domínio. Desta forma, um mesmo servidor DNS pode ter várias zonas, cada uma correspondendo a um domínio: contoso.com, microsoft.com, robertobraga.net, por exemplo. As entradas DNS – cada uma associada a um dos tipos – estão dentro de cada zona. Importante notar que as informações são armazenadas por zona (e não por servidor).

Replicação em servidores DNS
Quanto ao tipo, as zonas podem ser Zonas de Pesquisa Direta (Forward Lookup Zones), que traduzem nomes e serviços DNS ou Zonas de Pesquisa Inversas (Reverse Lookup Zones),  que traduzem IPs em nomes DNS. As zonas DNS são ainda definidas pelo tipo de replicação que estão submetidas. Quanto a este critério, uma zona pode ser Integrada ao AD, Primária (Master), Secundária (Slave) ou Stub.

O serviço DNS é tipicamente distribuído.  Desta forma, obtêm-se redundância através de bases de dados para resolução de nomes disponível em vários servidores. Esta disponibilidade é permitida pela funcionalidade de replicação do serviço.

A maneira tradicional (especificada originalmente na RFC 1035) em que a replicação acontece é na direção Master -> Slave. O banco de dados em formato texto (arquivo .dns) é armazenado em um servidor DNS primário, como cópia read/write. Os outros servidores – secundários – armazenam cópias deste arquivo (read-only).

Com o Active Directory implantado no Windows 2000 e seu intenso uso do serviço DNS, um novo tipo de zona foi implementado. As Zonas Integradas do Active Directory (ou apenas Zonas Integradas) tem algumas diferenças em comparação com zonas DNS tradicionais. Em especial, as zonas se tornam objetos do Active Directory e são replicadas junto com o restante do banco de dados do AD. Outra diferença essencial é que não existem cópias secundárias da zona. Todas as cópias passam a ser read/write. E essas cópias, por sua vez, podem estar apenas em servidores DNS que sejam também Domain Controllers (DCs).

Uma Zona Stub é uma cópia de uma zona que tem a função de apenas informar quais são os servidores DNS autoritativos para a zona. Geralmente é usada para interligar infraestruturas de DNS distintas.

Funcionamento das consultas DNS
Zonas Integradas, Primárias e Secundárias são autoritativas. Isto significa que caso um servidor DNS da zona receba uma query de um DNS Client ele saberá a responder sem ter que consultar outros servidores DNS – se a consulta for para uma zona que ele é autoritativo. Desta forma se o servidor srv-dc1 é autoritativo para a zona robertobraga.net ele saberá responder uma consulta tipo A para desktop.robertobraga.net com o IP correspondente.

Se a consulta for para uma zona em que o servidor DNS não seja autoritativo (www.brasildotnet.net, host www para o domínio brasildotnet.net, por exemplo) há algumas possibilidades para a resolução correta do nome acontecer. São elas:

• Repassar a query a um forwarder, servidor DNS um nível acima;
• Repassar a query a um root hint, que são os servidores DNS raiz;
• Repassar a query a um servidor delegado para aquele namespace (caso possível apenas caso esteja sendo utilizado uma estrutura com sub-zonas)

O funcionamento de uma consulta DNS e repasse em um cenário de rede local com forwarders e com root hints desabilitados é mostrado no vídeo abaixo.

Este fato acontece devido a uma incompatibilidade entre o hypervisor da Citrix e o Hyper-V. O problema é resolvido com a execução do seguinte comando:

$ xe vm-param-set uuid=<vmuuid> platform:viridian=false

Para descobrir o vmuuid (identificador único de cada VM), executar no console do XenServer:

$ xe vm-list name-label=<Nome da VM>

Para preencher o nome da VM, digitar apenas os primeiros caracteres e pressionar Tab para autocompletar.

Após a instalação do sistema operacional é importante instalar o XenServer Tools para que tudo funcione a contento. Este problema foi resolvido a partir da versão 5.5 do XenServer.

a) Registros Netbios comuns a WINS e DNS.
b) Falha na integração com Active Directory.
c) Servidor autoritativo para um domínio.
d) Aguardando resposta do servidor raiz.
e) Transferência de zona incremental.

Em um serviço de resolução de nomes (Domain Name System – Sistema de Nomes de Domínios, ou apenas DNS) é possível dividir em zonas as informações a serem fornecidas pelos servidores. Uma zona armazena informações sobre um ou mais domínios (esses últimos denominados subdomínios). Os subdomínios criados em uma zona podem ser tanto administrados pelo próprio servidor DNS que criou a zona originalmente quanto delegados a um outro servidor. Além da delegação, a zona pode ser completamente replicada a um servidor secundário para fins de redundância e alta disponibilidade.

A partir do momento em que uma zona é criada em um servidor secundário para redundância (zona secundária) ela é automaticamente replicada com o servidor principal. Para coordenar esta sincronização os servidores mantém um número de versão para a zona. Caso a versão do servidor solicitante seja inferior à versão do servidor principal é iniciada uma transferência de zona. Nas primeiras implementações DNS esta replicação enviava informações completas da zona (transferência do tipo AXFR) . A partir da RFC 1995 foi proposto o IXFR (opção correta para a questão do concurso), transferência que envia apenas as mudanças para o servidor secundário, de maneira incremental. Os acrônimos AXFR e IXFR representam os opcodes das transferências.

O serviço DNS passou por revisões recentes e teve adicionado características interessantes visando aprimorar segurança e flexibilidade, dentre elas:

• Serviço de notificação sobre mudanças em zonas, disponível a partir do Windows 2000;
• DNSSEC,  extensões que mitigam ataques do tipo spoofing e man-in-the-middle que está disponível nativamente no Windows Server 2008 R2 e Windows 7 (mais informações no DNSSEC Deployment Guide). O DNSSEC ganhou popularidade por evitar a vulnerabilidade exposta na descoberta do famoso bug na especificação original do DNS em 2008 (em breve artigo sobre DNSSEC aqui!);
• Suporte a IPv6, a partir do Windows Server 2008.

- um recurso compartilhado (um disco mapeado, por exemplo) tenta fazer o acesso com uma senha antiga após uma mudança de senha;
- uma tarefa agendada ou serviço é executado com uma senha antiga após uma mudança de senha;
- um vírus ou malware está tentando uma ataque de dicionário ou força bruta.

Caso contas estejam sendo travadas em seu AD, desconfie e investigue! Algumas linhas interessantes para a investigação:

1) Verifique na Default Domain Policy qual a política padrão para travamento de conta por tentativas sucessivas incorretas de senha. Para acessar as configurações da Default Domain Policy, Start > Administrative Tools > Default Domain Policy. Dentro da tela de edição de Default Domain Policy, verificar o seguinte nó:

As três configurações desta política são:

Account lockout duration – quanto tempo (minutos) uma conta travada permanece travada (vai de 1 até 99.999 minutos);
Account lockout threshold – quanto logons falhos levará até uma conta ser travada (vai de 1 até 99.999 tentativas de logon);
Reset account lockout counter after – quantos minutos levará após uma tentativa falha de logon até que o contador de logons inválidos seja zerado.

Notar ainda os seguintes casos especiais:

- Account lockout duration = 0 significa que a conta permanecerá travada até que o administrador a desbloqueie;
- Account lockout threshold = 0 significa que as contas não serão nunca travadas por tentativas de logon incorretas.

Configurações incorretas de política podem ser a causa do problema e devem ser o primeiro foco de investigação.

2) Verifique o histórico de travamento da conta, visando identificar de onde partem as tentativas incorretas de acesso a recursos. A Microsoft fornece um pacote de ferramentas que ajuda nesta investigação. O pacote se chama Account Lockout Tools (http://www.microsoft.com/downloads/details.aspx?FamilyID=7af2e69c-91f3-4e63-8629-b999adde0b9e&displaylang=en)

3) Verfique os eventos em seus DCs. Muitas ocorrências do Evento 675 provavelmente indicam presença de vírus como o Conficker. É comum que esse tipo de ameaça tente se apropriar de contas do domínio para intensificar ataques. Garanta que as atualizações do Microsoft Update estão instaladas.

4) Execute um sniffer de rede como o Microsoft Network Monitor (http://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en) e busque por pacotes “estranhos” que não se refiram a tráfego normal de rede. Geralmente a maior parte do tráfego está relacionado com tráfego HTTP, tráfego SMB (compartilhamentos de arquivos) e requisições de logon. Desconfie de  tráfego que fuja muito deste perfil.

Foi disponibilizado gratuitamente o Windows 7 Product Guide. Este documento provê uma visão geral do novo sistema operacional, focando nas novidades em relação a Windows Vista e Windows XP, em especial. O guia é dividido em:

• Windows 7 Simplifies Everyday Tasks;
• Windows 7 Works the Way You Want;
• Windows 7 Makes New Things Possible.

É uma leitura leve e que ajuda também quem pleiteia fazer alguma prova de certificação que cobre conteúdo Windows 7.

a) cada usuário criado em D será armazenado em um controlador de domínio utilizando uma política de round-robin.
Errado. Todos os objetos do Active Directory são armazenados em todos os controladores de domínio do domínio. Não confundir com o RODC (Read-Only Domain Controller), possibilidade disponibilizada a partir do Windows Server 2008. O RODC se encaixa em cenários de escritório remoto em que é necessária uma cópia apenas leitura do domínio por razões de segurança.

b) cada BDC (Backup Domain Controller) sincroniza sua hora local com o relógio do PDC (Primary Domain Controller) desse domínio.
Errado. O conceito de Backup Domain Controller existia no Windows NT 4 e não é utilizado no Windows Server 2003. De qualquer maneira cabe ainda ao PDC Emulator a missão de sincronizar horário. Recomenda-se que ele seja sincronizado com um servidor NTP externo. PDC Emulator sincroniza os DCs e os DCs sincronizam as estações e outros servidores da rede.

Mais em How Windows Time Service Works.
�
c) o nível de funcionalidade de domínio Windows Server 2003 pode ser habilitado, permitindo que o domínio seja renomeado.
Correto. O nível funcional da floresta em Windows Server 2003 traz várias melhorias ao Active Directory. Dentre elas, renomear o domínio. Para a elevação de nível é necessário que todos os controladores de domínio estejam executando Windows Server 2003.

Mais informações em New features for Active Directory e Raise the forest functional level

d) o número máximo de grupos permitido em D é 65536 (n x 16384), onde n é o número de controladores de domínio.
Errado. Não há relação entre número de controladores de domínio e quantidade máxima de objetos (dentre eles, grupos). Vale a pena uma lida no artigo Active Directory Maximum Limits – Scalability.

e) uma estação Windows XP não pode participar de D como cliente.
Errado. O Windows XP está entre os clientes suportados por um domínio nível funcional 2000, 2003 ou 2008. Para Windows 95, Windows 98 e Windows NT faz-se necessário instalação do cliente Active Directory.