Diretivas

Diretivas de Segurança
Guia do Revisor do Windows Server “Longhorn” Beta 3

Sobre o documento
ESTE DOCUMENTO NÃO É UMA ESPECIFICAÇÃO DE PRODUTO.
Este documento suporta a versão Beta 3 do Windows Server® “Longhorn.” As informações

contidas no mesmo representam a visão atual da Microsoft Corporation sobre os assuntos
discutidos até a data da publicação. A Microsoft deve reagir às constantes alterações nas
condições do mercado, e sendo assim este documento não deve ser interpretado como
um compromisso por parte Microsoft, e a Microsoft não pode garantir a precisão de
qualquer informação aqui. Este documento tem propósito exclusivamente informativo. A
MICROSOFT NÃO OFERECE GARANTIAS, EXPRESSAS, IMPLÍCITAS OU REGULAMENTARES
ACERCA DAS INFORMAÇÕES CONTIDAS NESTE DOCUMENTO.
As informações contidas neste documento, incluindo URL e outras referências a sites da
Internet, estão sujeitas a alterações a qualquer momento. Salvo disposição em contrário, os
exemplos de empresas, organizações, produtos, nomes de domínio, endereços de e-mail,
logotipos, pessoas, lugares e eventos aqui descritos são fictícios e não têm relação alguma
com qualquer empresa, organização, produto, nome de domínio, endereço de e-mail,
logotipo, pessoa, lugar ou evento real. É de responsabilidade do usuário o respeito a toda
a legislação de copyright aplicável. A Microsoft concede o direito de reprodução deste guia,
no todo ou em parte.
A Microsoft pode deter as patentes, as solicitações de patentes, as marcas comerciais, os
direitos autorais ou outras propriedades intelectuais pertinentes ao objeto deste
documento. Salvo expressamente disposto em qualquer contrato de licença escrito da
Microsoft, o fornecimento deste documento não confere a você qualquer licença em
relação a essas patentes, marcas comerciais, direitos autorais ou outras propriedades
intelectuais.
© 2007 Microsoft Corp. Todos os direitos reservados.
Microsoft, Windows Server, o logo do Windows, Windows, Active Directory, Windows Vista,
BitLocker, Internet Explorer, Windows Server System, Windows NT, Windows Mobile,
Windows Media, Aero, ClearType, RemoteApp, SharePoint, ActiveX, Outlook, Authenticode,
Visual Basic, Win32, WinFX, Windows PowerShell e MSDN são marcas comerciais da
Microsoft.
Os nomes das empresas e dos produtos mencionados aqui podem ser marcas comerciais
de seus respectivos proprietários.

88
5.01 Introdução à Aplicação de Diretivas e Segurança
O foco deste cenário é a conformidade aprimorada de segurança e gerenciamento que se

torna possível por meio dos recursos de acesso voltados às diretivas para as organizações
que implantaram o Windows Server® “Longhorn” com Windows Vista™, Windows® XP SP2
e o Windows Server 2003 R2.
Esse cenário também inclui o conjunto completo de serviços de identidade e acesso de
que os clientes precisam para fornecer o gerenciamento d de usuários, a consolidação de
diretórios, o logon único, a autenticação forte e a proteção e federação de informações.
Proposta de Valor para os Cenários

O reforço de diretivas e de segurança permite:
• Determinar a integridade e o status de laptops e computadores domésticos não-
gerenciados (desktop e laptop), verificar a conformidade e reforçar a remediação
de dispositivos não-conformes. Simplificar tarefas administrativas, como
atualizações de sistema e instalações de aplicativos.
• Determinar a integridade de laptops visitantes e reforçar a inspeção de dados de
camada de aplicativos, verificando a existência de malware. Simplificar tarefas
administrativas, como atualizações de sistema e instalações de aplicativos.
• Utilizar a qualidade de serviço baseada em diretivas para priorizar e gerenciar a
taxa de envio do tráfego de rede contínuo e a filtragem do tráfego de entrada e
saída.
• Aprimorar o acesso sem fio à rede, dando suporte a redes que utilizam switches
de autenticação, mecanismos aprimorados de criptografia e a integração com o
NAP (Network Access Protection) para diretivas específicas sem fio que dão
suporte à autenticação 802.1x.
• Ajudar a estender, de forma segura, as informações e os aplicativos aos parceiros
de negócios, como também dar proteção a eles.
• Reduzir o risco de acesso não-autorizado por meio da autenticação forte.
• Reduzir o número de contas de usuário e repositórios que precisam de
gerenciamento.
• Ajudar no gerenciamento seguro das contas e informações de usuário fora do
datacenter.
• Ativar a troca flexível de informações dentro e fora da organização, enquanto o
controle de acesso granular é mantido.
Requisitos Especiais de Hardware

Os requisitos de hardware adicionais são estes:
• Os smart cards são exigidos para clientes que desejam implantar uma solução de
autenticação forte e, dessa forma, reduzir o risco de acesso sem autorização.
• Placas de acesso sem fio e pontos de acesso são exigidos para o acesso seguro
sem fio.

89

90
5.02 Serviços de Acesso e Diretiva de Rede
Os Serviços de Acesso e Diretiva de Rede (Network Policy and Access Services) fornecem
uma variedade de métodos para oferecer conectividade de rede remota e local aos
usuários, para conectar segmentos de rede e permitir que os administradores de rede
gerenciem, de forma centralizada, o acesso à rede e as diretivas de integridade do cliente.
Com os Serviços de Acesso à Rede (Network Access Services), é possível implantar
servidores VPN e de discagem, roteadores e o acesso sem fio protegido pela autenticação
802.11. Você também pode implantar servidores e proxies RADIUS e utilizar o Connection
Manager Administration Kit para criar perfis de acesso remoto os quais permitam que os
computadores cliente conectem-se a sua rede.
Os Serviços de Acesso e Diretiva de Rede fornecem as seguintes soluções de conectividade
de rede:
• Proteção Contra Acesso à Rede. A Proteção Contra Acesso à Rede, ou NAP
(Network Access Protection), é uma criação de diretiva de integridade de cliente,
uma tecnologia de reforço e remediação incluída nos sistemas operacionais
Windows Vista Business, Enterprise e Ultimate, como também no Windows Server
“Longhorn”. Com o NAP, os administradores de sistema podem estabelecer e,
automaticamente, forçar diretivas de integridade, as quais podem incluir
requisitos de software, de atualização de rede, configurações exigidas de
computador, além de outras configurações. Computadores cliente que não
estiverem de acordo com a diretiva de integridade podem ter o acesso de rede
restringido até que suas configurações sejam atualizadas, fazendo com que
estejam de acordo com a diretiva. Dependendo da forma com que implantar o
NAP, os clientes não-conformes serão automaticamente atualizados, de forma
que os usuários possam rapidamente obter novamente o acesso completo à rede,
sem a necessidade de atualizar ou reconfigurar manualmente seus computadores.
• Proteção contra Acesso com e sem fio. Ao implantar pontos de acesso sem fio
802.1X, o acesso seguro sem fio fornece aos usuários um método de autenticação
baseado em senhas e com segurança aprimorada fácil de ser implantado. Ao
implantar switches de autenticação 802.1X, o acesso com fio permite que você
assegure sua rede, garantindo que os usuários da intranet sejam autenticados
antes que possam conectar-se à rede ou obter um endereço IP utilizando o DHCP.
• Soluções de acesso remoto. Com as soluções de acesso remoto, você pode
fornecer aos usuários o acesso discado e VPN à rede da organização. Além disso,
é possível conectar os escritórios de filiais a sua rede por meio de soluções VPN,
implantar roteadores de software com diversos recursos em sua rede, como
também compartilhar conexões da Internet pela intranet.
• Gerenciamento central de diretivas de rede com o servidor e o proxy
RADIUS. Em vez de configurar diretivas de acesso à rede em cada servidor de
acesso à rede, como pontos de acesso sem fio, switches de autenticação,
servidores VPN e servidores de discagem, você poderá criar diretivas em um único
local que especifique todos os aspectos das solicitações de conexão à rede,
incluindo quem tem permissão para conectar-se, quando a conexão poderá ser
feita e o nível de segurança que deve ser utilizado para conectar-se a sua rede.
Serviços de Função para Serviços de Acesso e Diretiva de Rede

91
Ao instalar os Serviços de Acesso e Diretiva de Rede, os seguintes serviços de função

estarão disponíveis:
• Network Policy Server. O NPS é a implementação da Microsoft® de um servidor
e proxy RADIUS. Ele pode ser utilizado para gerenciar, de forma centralizada, o
acesso à rede por meio de uma variedade de servidores de acesso à rede,
incluindo pontos de acesso sem fio, servidores VPN (virtual private networking)
servidores de discagem e switches de autenticação 802.1X. Além disso, você pode
utilizar o NPS para implantar a autenticação segura de senhas com o protocolo
PEAP (Protected Extensible Authentication Protocol)-MS-CHAP v2 para conexões
sem fio. O NPS também contém componentes principais para a implantação do
NAP na rede.
As seguintes tecnologias podem ser implantadas após a instalação do serviço de
função NPS:
o Servidor de diretiva NAP. Quando você configura o NPS como um
servidor de diretiva NAP, o NPS avalia o SoH (statements of health)
enviado pelos computadores clientes ativados para o NAP que desejam
conectar-se à rede. Você pode configurar diretivas NAP no NPS que
permitam que os computadores cliente atualizem suas configurações de
forma que estejam de acordo com a diretiva de rede de sua organização.
o IEEE 802.11 Sem fio. Com a utilização do snap-in do MMC (Microsoft
Management Console) NPS, você pode configurar diretivas de solicitação
de conexão baseadas na autenticação 802.1X para o acesso à rede cliente
sem fio IEEE 802.11. Além disso, você pode configurar pontos de acesso
sem fio como clientes RADIUS (Remote Authentication Dial-In User
Service) no NPS e utilizar o NPS como um servidor RADIUS para processar
solicitações de conexão, bem como realizar a autenticação, autorização e
registro de conexões sem fio 802.11. É possível integrar totalmente o
acesso sem fio IEEE 802.11 com o NAP durante a implantação de uma
infra-estrutura de autenticação sem fio 802.1X para que o status de
integridade dos clientes sem fio seja verificado diante da diretiva de
integridade antes que os clientes tenham permissão para conectar-se à
rede.
o IEEE 802.3 Com fio. Com a utilização do snap-in do MMC NPS, você
pode configurar diretivas de solicitação de conexão baseadas na
autenticação 802,1X para o acesso à rede Ethernet com fio IEEE 802.3.
Você pode configurar switches em conformidade com o 802.1X como
clientes RADIUS no NPS e utilizar o NPS como um servidor RADIUS para
processar solicitações de conexão, bem como realizar autenticação,
autorização e registro de conexões Ethernet 802.3. É possível integrar
totalmente o acesso cliente com fio IEEE 802.3 com o NAP durante a
implantação de uma infra-estrutura de autenticação com fio 802.1X.
o Servidor RADIUS. O NPS realiza a autenticação de conexão centralizada,
a autorização e o registro de conexões VPN, discadas de acesso remoto e
de switch de autenticação. - Dúvida Ao utilizar o NPS como um servidor
RADIUS, você configura servidores de acesso à rede, tais como pontos de
acesso sem fio e servidores VPN, como clientes RADIUS no NPS. Você
também pode configurar diretivas de rede utilizadas pelo NPS para
autorizar solicitações de conexão, além de poder configurar o registro
RADIUS para que os logs do NPS registrem informações nos arquivos de
92
log no disco rígido local ou em um banco de dados do Microsoft SQL

Server™.
o Proxy RADIUS. Ao utilizar o NPS como um proxy RADIUS, você poderá
configurar diretivas de solicitação de conexão que informem o servidor
NPS quais solicitações de conexão devem ser encaminhadas a outros
servidores RADIUS e para quais servidores RADIUS você deseja
encaminhar solicitações de conexão. O NPS também pode ser
configurado para encaminhar dados de registro a serem gravados por um
ou mais computadores em um grupo de servidores RADIUS remotos.
• Roteamento e Acesso Remoto. Com o Roteamento e Acesso Remoto, você pode
implantar serviços de acesso remoto, serviços de roteamento NAT de rede e
multiprotocolos LAN-to-LAN e LAN-to-WAN. (Dúvida)
As seguintes tecnologias podem ser implantadas durante a instalação do serviço de
função de Roteamento e Acesso Remoto:
o Serviço de Acesso Remoto. Com o Roteamento e Acesso Remoto, você
pode implantar o PPTP (Point-to-Point Tunneling Protocol) ou o L2TP
(Layer Two Tunneling Protocol) com conexões VPN IPsec (Internet
Protocol security) a fim de fornecer aos usuários finais o acesso remoto à
rede de sua organização. Você também pode criar uma conexão VPN de
site para site entre dois servidores em diferentes locais. Cada servidor é
configurado com o Roteamento e Acesso Remoto para enviar dados
particulares de forma segura. A conexão entre os dois servidores pode ser
persistente (sempre ativada) ou sob demanda (discagem sob demanda).
O Acesso Remoto também fornece acesso remoto tradicional para dar
suporte a usuários móveis ou domésticos que se conectam a intranets de
uma organização. O equipamento dial-up instalado no servidor que
executa o Roteamento e Acesso Remoto responde solicitações de
conexões de entrada a partir de clientes de rede dial-up. O servidor de
acesso remoto responde à chamada, autentica e autoriza o chamador e
transfere os dados entre o cliente de rede dial-up e a intranet da
organização.
o Roteamento. O roteamento fornece um roteador de software com
diversos recursos e uma plataforma aberta para o roteamento e o uso da
Internet. Além disso, ele oferece serviços de roteamento aos negócios em
ambientes LAN (local area network) e WAN (wide area network).
Ao implantar o NAT, o servidor que executa o Roteamento e Acesso
Remoto é configurado para compartilhar uma conexão da Internet com
os computadores de uma rede privada e traduzir o tráfego entre seu
endereço público e a rede privada. Utilizando o NAT, os computadores na
rede privada obtêm alguma medida de proteção, pois o roteador com o
NAT configurado não encaminha o tráfego a partir da Internet para a
rede privada, a menos que um cliente de rede privada tenha solicitado ou
que o tráfego esteja explicitamente permitido.
Ao implantar a VPN e o NAT, o servidor que executa o Roteamento e
Acesso Remoto é configurado para fornecer o NAT para a rede privada e
para aceitar conexões VPN. Os computadores na Internet não poderão
determinar os endereços IP dos computadores na rede privada.

93
Entretanto, os clientes VPN poderão conectar-se aos computadores na

rede privada, como se estivessem fisicamente ligados à mesma rede.
• Health Registration Authority (HRA). O HRA é um componente NAP que emite
certificados de integridade a clientes que passam pela verificação de diretiva de
integridade realizada pelo NPS utilizando o SoH cliente. O HRA é utilizado
somente quando o método de reforço NAP é um reforço do IPsec.
• Host Credential Authorization Protocol (HCAP). O HCAP permite que você
integre sua solução Microsoft NAP ao Cisco Network Access Control Server. Ao
implantar o HCAP com o NPS e o NAP, o NPS pode realizar a avaliação de
integridade do cliente e a autorização dos clientes de aceso Cisco 802.1X.
Gerenciando a Função de Network Policy Server and Access

Services
As seguintes ferramentas são fornecidas para gerenciar a função de Network Policy Server
and Access Services:
• Snap-in MMC NPS Utilize o MMC NPS MMC para configurar um servidor
RADIUS, um proxy RADIUS ou uma tecnologia NAP.
• Comandos Netsh para o NPS. Os comandos Netsh para o NPS fornecem um
conjunto de comandos equivalentes a todas as configurações disponíveis por
meio do snap-in MMC NPS. Os comandos Netsh podem ser executados
manualmente no prompt Netsh ou em scripts do administrador.
• Snap-in MMC HRA Utilize o MMC HRA para designar a CA (certification
authority - autoridade de certificação) utilizada pelo HRA para obter certificados
de integridade para computadores cliente e para definir o servidor NPS ao qual o
HRA enviará SoHs cliente para verificação mediante a diretiva de integridade.
• Comandos Netsh para o HRA. Os comandos Netsh para o HRA fornecem um
conjunto de comandos equivalentes a todas as configurações disponíveis por
meio do snap-in MMC HRA. Os comandos Netsh podem ser executados
manualmente no prompt Netsh ou em scripts autorizados pelo administrador.
• Snap-in MMC NAP Client Management. Você pode utilizar o snap-in NAP
Client Management para definir configurações de segurança e de interface de
usuário em computadores cliente com suporte para a arquitetura NAP.
• Comandos Netsh para definir configurações de cliente NAP. Os comandos
Netsh para as configurações de cliente NAP fornecem um conjunto de comandos
equivalentes a todas as configurações disponíveis por meio do snap-in MMC NAP.
Os comandos Netsh podem ser executados manualmente no prompt Netsh ou
em scripts autorizados pelo administrador.
• Snap-in MMC Routing and Remote Access. Utilize este snap-in MMC para
configurar um servidor VPN, um servidor de rede dial-up, um roteador, um
conexão site-site VPN, VPN e NAT ou NAT.
• Comandos Netsh para acesso remoto (RAS). Os comandos Netsh para o acesso
remoto fornecem um conjunto de comandos equivalentes a todas as
configurações de acesso remoto disponíveis por meio do snap-in Roteamento e
Acesso Remoto. Os comandos Netsh podem ser executados manualmente no
prompt Netsh ou em scripts do administrador.

94
• Comandos Netsh para roteamento. Os comandos Netsh para o roteamento

fornecem um conjunto de comandos equivalentes a todas as configurações de
acesso remoto disponíveis por meio do snap-in de Roteamento e Acesso Remoto.
Os comandos Netsh podem ser executados manualmente no prompt Netsh ou
em scripts do administrador.
• Wireless Network (IEEE 802.11) Policies – snap-in (MMC) Group Policy
Object Editor. A extensão Wireless Network (IEEE 802.11) Policies automatiza a
definição das configurações de rede sem fio em computadores com unidades de
adaptador de rede sem fio com suporte ao WLAN Autoconfig Service (Wireless
LAN Autoconfiguration Service - serviço de configuração automática de LAN sem
fio). Você pode utilizar a extensão Wireless Network (IEEE 802.11) Policies no
Group Policy Object Editor para especificar as configurações para clientes sem fio
Windows XP e Windows Vista. As extensões Wireless Network (IEEE 802.11)
Policies Group Policy incluem configurações globais sem fio, a lista de redes
preferidas, as configurações WPA (Wi-Fi Protected Access), além das
configurações IEEE 802.1X.
Quando essas configurações são definidas, o download delas é feito para os
clientes sem fio do Windows que são membros do domínio. As configurações
sem fio definidas por essa diretiva fazem parte da Computer Configuration Group
Policy (Diretiva de Grupo de Configuração de Computador. Por padrão, a
extensão Wireless Network (IEEE 802,11) Policies não é configurada ou ativada.
• Comandos Netsh para WLAN (LAN Sem Fio). O Netsh WLAN é uma alternativa
para utilizar a Diretiva de Grupo para configurar a conectividade sem fio e as
configurações de segurança do Windows Vista. Você pode utilizar os comandos
Netsh wlan para configurar o computador local ou para configurar múltiplos
computadores que utilizem um script de logon. Além disso, é possível utilizar os
comandos Netsh wlan para visualizar as configurações de Diretiva de Grupo e
administrar as configurações do WISP (Wireless Internet Service Provider) e as
configurações sem fio de usuário.
A interface Netsh sem fio fornece os seguintes benefícios:
o Suporte para o modo misto. Isso permite que os administradores
configurem clientes para dar suporte às múltiplas opções de segurança.
Por exemplo, um cliente pode ser configurado para os padrões de
autenticação WPA2 e WPA. Isso permite que o cliente utilize o WPA2
para conectar-se às redes com suporte ao WPA2 e utilize o WPA para
conectar-se às redes com suporte apenas ao WPA.
o Bloqueio de redes não desejadas. Os administradores podem bloquear
e ocultar o acesso às redes sem fio não-corporativas, adicionando redes
ou tipos de redes à lista de redes negadas. De forma semelhante, é
possível permitir o acesso às redes sem fio corporativas.
• Wireless Network (IEEE 802.3) Policies – snap-in (MMC) Group Policy Object
Editor. Você pode utilizar o Wired Network (IEEE 802.3) Policies para especificar
e modificar as configurações para os clientes do Windows Vista que possuem
adaptadores e unidades de rede com suporte ao Wired AutoConfig Service. As
extensões Wireless Network (IEEE 802.11) Policies Group Policy incluem
configurações globais com fio e IEEE 802.1X. Essas configurações incluem o
conjunto completo de itens de configuração com fio associados às guias Geral e
Segurança.

95
Quando essas configurações são definidas, o download delas é feito para os

clientes sem fio do Windows que são membros do domínio. As configurações sem
fio definidas por essa diretiva fazem parte da Computer Configuration Group
Policy. Por padrão, a extensão Wired Network (IEEE 802.3) Policies não é
configurada ou ativada.
• Comandos Netsh para a LAN. A interface Netsh LAN é uma alternativa para
utilizar a Diretiva de Grupo no Windows Server “Longhorn” a fim de configurar as
configurações de segurança e a conectividade com fio do Windows Vista. Você
pode utilizar a linha de comando Netsh LAN para configurar o computador local
ou utilizar os comandos em scripts de logon para configurar múltiplos
computadores. Além disso, é possível utilizar os comandos Netsh LAN para
visualizar a Wired Network (IEEE 802.3) Policies e administrar as configurações 1x
com fio do cliente.
Recursos Adicionais
Para saber mais sobre os Serviços de Acesso e Diretiva de Rede, abra um dos seguintes
snap-ins MMC e depois pressione F1 a fim de exibir a Ajuda:
• Snap-in MMC NPS
• Snap-in MMC Routing and Remote Access.
• Snap-in MMC HRA
• Snap-in MMC Group Policy Object Editor
5.03 Proteção contra Acesso à Rede
Um dos maiores desafios encontrados nos negócios dos dias de hoje é a exposição crescente
dos dispositivos de clientes a softwares maliciosos, como vírus e worms. Esses programas
podem obter a entrada a sistemas de host configurados de forma incorreta ou sistemas
desprotegidos e podem utilizar esses sistemas como um ponto inicial para se propagarem
em outros dispositivos na rede corporativa. Os administradores de rede podem utilizar a
plataforma NAP para melhor proteger suas redes, ajudando a garantir que os sistemas
cliente mantenham as atualizações de software e as configurações de sistema apropriadas
para protegê-los contra softwares maliciosos.
O NAP (Network Access Protection) é um novo conjunto de componentes de sistema
operacional incluído no Windows Server “Longhorn” e no Windows Vista que fornece uma
plataforma que ajuda a garantir que os computadores clientes em uma rede corporativa
atendam aos requisitos quanto à integridade do sistema definidos pelo administrador. As
diretivas NAP definem a configuração e o status de atualização exigidos para o sistema
operacional e o software principal do computador de um cliente. Por exemplo, pode ser
exigido que os computadores possuam um software antivírus com as mais recentes
assinaturas instaladas, com as atualizações instaladas no sistema operacional atual e com um
firewall baseado em host ativado. Reforçando o cumprimento desses requisitos de
integridade, o NAP pode ajudar os administradores de rede na diminuição de alguns riscos
causados por computadores cliente configurados de forma imprópria que podem ser
expostos a vírus e a outros softwares maliciosos.

96
O NAP reforça os requisitos de integridade, monitorando e avaliando o funcionamento dos

computadores cliente quando estes tentam conectar-se à rede ou comunicar-se com ela.
Caso seja determinado que os computadores cliente não estejam em conformidade com os
requisitos de integridade, eles poderão ser colocados em uma rede restrita que contenha os
recursos para dar assistência na remediação de sistemas de clientes de forma que eles
possam estar em conformidade com as diretivas de integridade.
Os administradores de sistemas e de rede que desejam reforçar os requisitos de integridade
do sistema para computadores cliente que se conectam às redes suportadas por eles terão
interesse em utilizar o NAP. Com o NAP, os administradores de rede poderão:
• Garantir a integridade dos computadores desktop na LAN, ou que estão
configurados para o DHCP, ou que se conectam por meio de dispositivos de
autenticação 802.1X, ou ainda que possuam diretivas IPsec NAP aplicadas em suas
comunicações.
• Reforçar os requisitos de integridade para laptops móveis quando estes forem
conectados novamente na rede da empresa.
• Verificar a integridade e a conformidade de diretivas dos computadores domésticos
não-gerenciados que se conectam à rede da empresa por meio de um servidor VPN
que executa o Roteamento e Acesso Remoto.
• Determinar a integridade e restringir o acesso dos laptops trazidos para uma
organização pelos visitantes e parceiros.
Dependendo de suas necessidades, os administradores podem configurar uma solução para
lidar com qualquer um desses cenários.
O NAP também inclui um conjunto API para desenvolvedores e fornecedores para que estes
possam criar seus próprios componentes para validação de diretivas de rede, para a
conformidade contínua e o isolamento de rede.
As implantações do NAP exigem servidores que executem o Windows Server “Longhorn”.
Além disso, são exigidos computadores cliente que executem o Windows Vista, o Windows
Server “Longhorn” ou o Windows XP com SP2 e o Network Access Protection Client para
Windows XP. O servidor central que realiza a análise de determinação da integridade para o
NAP é um computador que executa o Windows Server “Longhorn” e o NPS. O NPS é a
implementação do Windows de um servidor e proxy RADIUS. O NPS é o substituto do IAS
(Internet Authentication Service) no Windows Server 2003. Os dispositivos de acesso e os
servidores NAP atuam como clientes RADIUS para um servidor RADIUS baseado no NPS. O
NPS efetua a autenticação e a autorização de uma tentativa de conexão à rede e, com base
nas diretivas de integridade do sistema, determina a conformidade da integridade do
computador e também como limitar o acesso à rede de um computador que não está em
conformidade com as diretivas.
A plataforma NAP é uma nova tecnologia de reforço e validação de integridade do cliente
incluída nos sistemas operacionais Windows Server “Longhorn” e Windows Vista.
Nota
O framework do NAP não é o mesmo do Network Access Quarantine Control, o qual é um
recurso fornecido com o Windows Server 2003 e o ISA Server 2004. O Network Access
Quarantine Control pode fornecer proteção adicional para conexões de acesso remoto (dial-
up e VPN). Para mais informações sobre o Network Access Quarantine Control no Windows
Server 2003, veja Network Access Quarantine Control no Windows Server 2003
(http://go.microsoft.com/fwlink/?LinkId=56447). Para mais informações sobre esse recurso no

97
ISA Server 2004, veja Clientes Móveis VPN e Quarantine Control no ISA Server 2004
Enterprise Edition (http://go.microsoft.com/fwlink/?LinkId=56449).
Principais Processos do NAP

Diversos processos importantes são exigidos para que o NAP funcione de forma apropriada:
a validação de diretivas, o reforço NAP e a restrição de rede, a remediação e o
monitoramento contínuo para garantir a conformidade.
Validação de Diretivas
Os SHVs (System health validators – validadores de integridade do sistema) são utilizados
pelo NPS para analisar o status de integridade dos computadores cliente. OS SHVs são
incorporados às diretivas de rede que determinam as ações a serem realizadas com base
no status da integridade do cliente, como conceder acesso total à rede ou restringir o
acesso à rede. O status da integridade é monitorado pelos componentes NAP do lado do
cliente, chamados de SHAs (system health agents – agentes de integridade do sistema). O
NAP utiliza os SHAs e os SHVs para monitorar, reforçar e remediar configurações de
computadores cliente.
O Windows Security Health Agent e o Windows Security Health Validator estão incluídos nos
sistemas operacionais Windows Server “Longhorn” e Windows Vista e reforçam as seguintes
configurações para computadores ativados para o NAP:
• O computador cliente deve possuir software de firewall instalado e ativado.
• O computador cliente deve possuir software antivírus instalado e em execução.
• O computador cliente deve possuir atualizações de antivírus atuais instaladas.
• O computador cliente deve possuir software anti-spyware instalado e em execução.
• O computador cliente deve possuir atualizações de anti-spywares atuais instaladas.
• O Microsoft Update Services deve estar ativado no computador cliente.
Além disso, se computadores clientes ativados para o NAP estiverem executando o Windows
Update Agent e estiverem registrados com um servidor WSUS (Windows Server Update
Service), o NAP poderá verificar se a maioria das atualizações de segurança de software está
instalada, com base em um dos quatro valores possíveis que correspondem à classificação
de severidade de segurança do MSRC(Microsoft Security Response Center).
Reforço do NAP e Restrição de Rede

O NAP pode ser configurado para negar o acesso à rede para computadores cliente em
não-conformidade e permitir que esses computadores acessem somente uma rede restrita.
Uma rede restrita deve conter os serviços NAP principais, como os servidores HRA e os
servidores de remediação, para que clientes NAP em não-conformidade possam atualizar
suas configurações e estar em conformidade com os requisitos de integridade.
As configurações de reforço NAP permitem que você limite o acesso à rede de clientes em
não-conformidade ou apenas observe e registre o status de integridade de computadores
cliente ativados para o NAP.
98
Você pode optar por restringir o acesso, adiar a restrição de acesso ou ainda permitir o
acesso por meio da utilização das seguintes configurações:
• Do not enforce (Não aplicar). Esta é a configuração padrão. Os clientes que
atendem às condições de diretiva são considerados como estando em
conformidade com os requisitos de integridade de rede e a eles é concedido acesso
irrestrito à rede caso a solicitação de conexão seja autenticada e autorizada. O
status de conformidade de integridade dos computadores cliente ativados para o
NAP é registrado.
• Enforce (Aplicar). Os computadores cliente que atendem às condições de diretivas
são considerados como não estando em conformidade com os requisitos de
integridade de rede. Esses computadores são colocados na rede restrita.
• Defer enforcement (Adiar aplicação). Os clientes que atendem às condições de
diretivas recebem, temporariamente, acesso irrestrito. O NAP é adiado até a data e
o horário especificados.
Remediação
Os computadores cliente não-conformes que são colocados em uma rede restrita podem ser
submetidos à remediação. Remediação é o processo de atualizar um computador cliente de
forma que ele passe a atender aos requisitos atuais de integridade. Por exemplo, uma rede
restrita pode conter um servidor FTP (File Transfer Protocol) que fornece assinaturas atuais
de vírus de forma que os computadores cliente em não-conformidade possam atualizar suas
assinaturas.
É possível utilizar as configurações do NAP nas diretivas de integridade NPS para configurar
a remediação automática, de forma que os componentes do cliente NAP tentem,
automaticamente, atualizar o computador cliente quando este estiver em não-conformidade
com os requisitos de integridade de rede. Você pode utilizar a seguinte configuração de
diretiva para configurar a remediação automática:
• Atualizações de computador. Se a opção Update noncompliant computers
automatically estiver selecionada, a remediação automática estará ativada, e os
computadores ativados para o que não estiverem em conformidade com os
requisitos de integridade tentarão, automaticamente, fazer a atualização.
Monitoramento Contínuo para Garantir a Conformidade

O NAP pode reforçar a conformidade da integridade em computadores cliente em
conformidade que já estejam conectados à rede. Esta funcionalidade é muito útil para
garantir que uma rede esteja protegida em uma base continua conforme vão ocorrendo
mudanças nas diretivas de integridade e nos computadores cliente. Por exemplo, se a
diretiva de integridade exigir que o Windows Firewall esteja ativado, e um usuário,
inadvertidamente, desabilitá-lo, o NAP poderá determinar se o computador cliente está em
um estado de não-conformidade. O NAP irá então colocar o computador cliente na rede
restrita até que o Windows Firewall seja ativado novamente.
Se a remediação automática estiver ativada, os componentes do cliente NAP poderão
ativar automaticamente o Firewall do Windows sem a intervenção do usuário.
Métodos de Reforço NAP

Baseado no estado de funcionamento de um computador cliente, o NAP pode permitir o
acesso total à rede, limitar o acesso a uma rede restrita ou negar o acesso à rede. Os
99
computadores cliente que são determinados como estando em não-conformidade com as

diretivas de integridade também podem ser automaticamente atualizados a fim de atender
a esses requisitos. A forma com que o NAP é reforçado depende no método de reforço
escolhido. O NAP reforça as diretivas de integridade para:
• O tráfego protegido pelo IPsec
• O controle de acesso à rede com e sem fio baseado na porta 802.1X
• A VPN com o Routing and Remote Access
• O lease e a renovação de endereços IPv4 DHCP
As seções a seguir descrevem esses métodos de reforço.
Reforço NAP para Comunicações IPsec

O reforço NAP para o tráfego protegido pelo IPsec é implantado com um servidor de
certificado de integridade, um servidor HRA, um servidor NPS e um cliente de reforço IPsec.
O servidor de certificado de integridade emite certificados X.509 aos clientes NAP quando é
determinado que esses clientes estão em conformidade com os requisitos de integridade de
rede. Então, esses certificados são utilizados para autenticar clientes NAP quando estes
iniciam comunicações protegidas pelo IPsec com outros clientes NAP em uma intranet.
O reforço IPsec limita a comunicação em sua rede aos clientes em conformidade e fornece a
forma mais forte do reforço NAP. Como esse método de reforço utiliza o IPsec, é possível
definir requisitos para comunicações protegidas em uma base por endereço IP ou por
número de porta TCP/UDP.
Reforço NAP para 802.1X

O reforço NAP para o controle de acesso à rede baseado na porta 802.1X é implantado com
um servidor NPS e um componente cliente de reforço EAPHost. Com o reforço baseado na
porta 802.1X, um servidor NPS ordena que um switch de autenticação 802.1X ou um ponto
de acesso sem fio em conformidade com o 802.1X coloque clientes 802.1X em não-
conformidade em uma rede restrita. O servidor NPS limita o acesso à rede do cliente à rede
restrita, ordenando que o ponto de acesso aplique filtros IP ou um identificador de LAN à
conexão. O reforço 802.1X fornece forte restrição de rede para todos os computadores que
acessam a rede por meio de dispositivos de acesso à rede ativados para 802.1X.
Reforço NAP para VPN

O reforço NAP para VPN é implantado com um componente de servidor de reforço VPN e
um componente cliente de reforço VPN. Com o reforço NAP para VPN, os servidores VPN
poderão reforçar a diretiva de integridade quando computadores clientes tentarem
conectar-se à rede utilizando uma conexão VPN de acesso remoto. O reforço VPN fornece
forte acesso limitado à rede para todos os computadores que acessam a rede por meio de
uma conexão VPN de acesso remoto.
Reforço NAP para DHCP

O reforço DHCP é implantado com um componente de servidor de reforço NAP DHCP, um
componente cliente de reforço DHCP e o NPS. Utilizando o reforço DHCP, os servidores
DHCP e o NPS poderão reforçar a diretiva de integridade quando um computador tentar
obter ou renovar um endereço IPv4. O servidor NPS limita o acesso à rede do cliente à rede
restrita, ordenando que o servidor DHCP atribua uma configuração limitada de endereço IP.

100
Entretanto, se os computadores cliente estiverem configurados para tirar vantagem

(circumvent) da configuração de endereço IP, o DHCP não será eficiente.
Abordagens Combinadas
Cada um desses métodos de reforço NAP possui diferentes vantagens. Combinando os
métodos de reforço, será possível combinar as vantagens desses métodos. Entretanto, ao
implantar múltiplos métodos de reforço NAP, você poderá fazer com que sua
implementação NAP seja mais complexa de ser gerenciada.
O framework do NAP também fornece um conjunto de APIs que permite que outras
empresas que não sejam a Microsoft integrem seus softwares com a NAP. Utilizando as APIs
do NAP, fornecedores e desenvolvedores de software poderão fornecer soluções de fim a
fim que validem o funcionamento e façam a remediação de clientes em não-conformidade.
Implantação
Os preparativos necessários para a implantação do NAP dependem do método (ou
métodos) de reforço escolhido e dos requisitos de integridade que se pretende reforçar
quando os computadores cliente tentam conectar-se à rede ou comunicar-se com ela.
Se você for um administrador de sistemas ou de rede, será possível implantar o NAP com o
Windows Security Health Agent e o Windows Security Health Validator. Você também
poderá verificar com outros fornecedores de software se eles possuem SHAs e SHVs para
seus produtos. Por exemplo, se um fornecedor de software antivírus desejar criar uma
solução NAP que inclua um SHA e um SHV personalizado, ele poderá utilizar um conjunto
de APIs para criar esses componentes, os quais poderão ser integrados com as soluções NAP
implantadas pelos clientes desse fornecedor.
Além dos SHAs e SHVs, a plataforma NAP utilize múltiplos componentes de servidor e
cliente para detectar e monitorar o status da integridade do sistema dos computadores
cliente quando estes tentam conectar-se à rede ou comunicar-se com ela. Na figura abaixo,
são ilustrados alguns componentes comuns utilizados na implantação do NAP:

101

102
Componentes do Cliente NAP

Um cliente ativado para o NAP é um computador que possui os componentes NAP
instalados e que pode verificar seu estado de funcionamento, enviando uma lista de SoH
(statements of health) ao NPS. A seguir, estão os componentes do cliente NAP comuns:
Agente de integridade do sistema. Um SHA monitora e relata o estado de funcionamento
do computador cliente de forma que o NPS possa determinar se as configurações
monitoradas pelo SHA estão atualizadas e configuradas corretamente. Por exemplo, o
Microsoft SHA pode monitorar o Firewall do Windows; se um software antivírus estiver
instalado, ativado e atualizado; se há softwares anti-spyware instalado, ativado e atualizado
e se o Microsoft Update Services está ativado e o computador possui suas mais recentes
atualizações. Também pode haver SHAs disponíveis em outras empresas que fornecem
funcionalidades adicionais.
NAP Agent (Agente NAP). O agente NAP coleta e gerencia informações de
funcionamento. O agente NAP também processa o SoH a partir dos SHAs e relata o
funcionamento do cliente aos clientes de reforço instalados. Para indicar o estado completo
de um cliente NAP, o agente NAP utiliza uma lista de SoH.
NAP EC (NAP enforcement client). Para utilizar o NAP, pelo menos um NAP EC (NAP
enforcement client) deve estar instalado e ativado nos computadores cliente. NAP EC
individuais são específicos ao método, conforme descrito anteriormente. Os clientes de
reforço NAP integram-se com tecnologias de acesso à rede, como IPsec, o controle de
acesso à rede com e sem fio baseado em porta 802.1X, VPN com o Roteamento e Acesso
Remoto e o DHCP. O cliente de reforço NAP solicita acesso à rede, informa o status do
funcionamento de um computador cliente ao servidor NPS e informa o status restrito do
computador cliente aos outros componentes da arquitetura NAP.
SoH (Statement of health). Um SoH é uma declaração de um SHA que afirma seu status
de funcionamento. Os SHAs criam SoHs, os quais são enviados ao agente NAP.
Componentes de Servidor NAP

A seguir, estão os componentes de servidor NAP comuns:
Diretivas de funcionamento. As diretivas NPS definem os requisitos de integridade e as
configurações de reforço para os computadores cliente que solicitam acesso à rede. O NPS
processa as mensagens de Solicitação de Acesso RADIUS (RADIUS Access-Request) que
contêm a lista de SoH enviada pelo NAP EC e passa essas mensagens para o servidor de
administração NAP.
Servidor de administração NAP. O componente de servidor de administração NAP
fornece uma função de processamento parecida com o agente NAP no lado do cliente. Ele
recebe a lista de SoH do servidor de reforço NAP por meio do NPS e distribui cada SoH para
o SHV apropriado. Depois, ele coleta as Respostas SoH resultantes dos SHVs e envia essas
respostas ao NPS para que este faça uma avaliação.
SHVs (System health validators - validadores de integridade do sistema). Os SHVs são
cópias de software de servidor para os SHAs. Cada SHA no cliente possui um SHV
correspondente no NPS. Os SHVs verificam o SoH feito por seu SHA correspondente no
computador cliente.
Os SHAs e os SHVs são associados um ao outro, juntamente com um servidor de diretivas
correspondente (se exigido) e, talvez, a um servidor de remediação.

103
Um SHV também pode detectar que nenhum SoH foi recebido (por exemplo, se o SHA
nunca tiver sido instalado, se tiver sido danificado ou removido). Se o SoH atender ou não à
diretiva definida, o SHV enviará uma mensagem SoHR (statement of health response -
declaração de resposta de integridade) para o servidor de administração NAP.
Uma rede pode possuir mais de um tipo de SHV. Se isso ocorrer, o servidor NPS deverá
coordenar a saída de todos os SHVs e determinar se deve ser limitado o acesso de um
computador em não-conformidade. Isso exige um planejamento cuidadoso ao definir
diretivas de integridade para o seu ambiente e avaliar na diferente forma com que os SHVs
interagem.
NAP enforcement server (servidor de reforço NAP). O NAP ES é associado a um NAP EC
correspondente para o método de reforço NAP que estiver sendo utilizado. Ele recebe a lista
de SoHs do NAP EC, passando-os para que o NPS faça uma avaliação. Com base na
resposta, é fornecido acesso limitado ou ilimitado à rede para o cliente ativado para o NAP.
Dependendo do tipo de reforço NAP, o NAP ES pode ser uma autoridade de certificação
(reforço IPsec), um switch de autenticação ou um ponto de acesso sem fio (reforço 802.1x),
um servidor Roteamento e Acesso Remoto(reforço VPN) ou um servidor DHCP (reforço
DHCP).
Servidor de diretivas. Um servidor de diretivas é um componente de software que se
comunica com um SHV a fim de fornecer as informações utilizadas na avaliação dos
requisitos para a integridade do sistema. Por exemplo, um servidor de diretivas, como um
servidor de assinaturas antivírus, pode fornecer a versão do arquivo atual de assinaturas para
a validação de um SoH antivírus cliente. Os servidores de diretivas são associados aos SHVs,
mas nem todos os SHVs exigem um servidor de diretivas. Por exemplo, um SHV pode
simplesmente ordenar que clientes ativados para o NAP verifiquem as configurações locais
de sistema a fim de assegurar que um firewall baseado em host esteja ativado.
Servidor de remediação. Um servidor de remediação hospeda as atualizações que podem
ser utilizadas pelos SHAs para fazer com que computadores cliente em não-conformidade
passem a estar em conformidade. Por exemplo, um servidor de remediação pode hospedar
atualizações de software. Se a diretiva de integridade exigir que os computadores cliente
NAP possuam as mais recentes atualizações de software instaladas, o NAP EC irá restringir o
acesso à rede dos clientes que não possuírem essas atualizações. Os servidores de
remediação devem estar acessíveis aos clientes com acesso restrito à rede para que os
clientes obtenham as atualizações exigidas para que estejam em conformidade com as
diretivas de integridade.
SoHR (Statement of health response). Depois que o SoH cliente for avaliado mediante a
diretiva de integridade pelo SHV apropriado, um SoHR será gerado, contendo os resultados
da avaliação. O SoHR inverte o caminho do SoH e é enviado de volta ao SHA do
computador cliente. Se o computador cliente for considerado como estando em não-
conformidade, o SoHR irá conter as instruções de remediação utilizadas pelo SHA para fazer
com que a configuração do computador cliente esteja em conformidade com os requisitos
de integridade.
Assim como cada tipo de SoH contém diferentes tipos de informações sobre o status do
funcionamento do sistema, cada mensagem SoHR contém as informações sobre como estar
em conformidade com os requisitos de integridade.
Informações Adicionais

104
Para mais informações sobre o NAP, acesse o site sobre Network Access Protection em
(http://go.microsoft.com/fwlink/?LinkId=56443).

105
5.04 Protocolos TCP/IP e Componentes de Rede de

Última Geração
A rede e as comunicações são muito importantes para que as organizações consigam

superar o desafio da grande competição no mercado global. Os funcionários precisam
conectar-se à rede onde quer que eles estejam e a partir de qualquer dispositivo.
Parceiros, fornecedores e outras pessoas fora da rede precisam interagir, de forma
eficiente, com os recursos principais. Além disso, segurança é um fator mais importante do
que nunca.
A seguir, teremos uma visão geral técnica sobre as melhorias de comunicação e rede
TCP/IP encontradas no Microsoft Windows Server “Longhorn” e Windows Vista para lidar
com questões de conectividade, facilidade de uso, gerenciamento, confiabilidade e
segurança. Com o Windows Server “Longhorn” e o Windows Vista, os administradores de
TI possuem mais opções flexíveis para gerenciar a infra-estrutura de rede, rotear o tráfego
de rede de forma eficiente e implantar cenários de tráfego protegido.
O Windows Server “Longhorn” e o Windows Vista incluem muitas alterações e melhorias
para os seguintes protocolos e componentes centrais de rede:
• Pilha TCP/IP de última geração
• Melhorias no IPv6
• QoS (Quality of Service) baseada em diretivas para redes corporativas.
Pilha TCP/IP de Última Geração

O Windows Server “Longhorn” e o Windows Vista incluem uma nova implementação da
pilha do protocolo TCP/IP, conhecida como a Pilha TCP/IP de última geração. A Pilha
TCP/IP de última geração é um design completamente reformulado da funcionalidade do
TCP/IP tanto para o IPv4 (Internet Protocol version 4) quanto para o IPv6 (Internet
Protocol version 6) que atende às necessidades de desempenho e conectividade dos
diversos ambientes e tecnologias de rede dos dias de hoje.
Os seguintes recursos são novos ou aprimorados:
• Receive Window Auto-Tuning
• Compound TCP
• Melhorias para ambientes de alto índice de perda
• Neighbor Un-reach-ability Detection for IPv4
• Alterações na detecção de gateways inativos
• Alterações na detecção de roteadores de buraco negro PMTU
• Compartimentos de Roteamento
• Suporte ao Network Diagnostics Framework
• Windows Filtering Platform
• Explicit Congestion Notification
Receive Window Auto-Tuning

106
O tamanho da janela de recebimento TCP (TCP receive window size) é a quantidade de

bytes em um buffer de memória em um host de recebimento utilizada para armazenar
dados de entrada em uma conexão TCP. Para determinar corretamente o valor do
tamanho máximo da janela de recebimento para uma conexão com base nas condições
atuais da rede, a Pilha TCP/IP de última geração dá suporte ao Receive Window Auto-
Tuning. O Receive Window Auto-Tuning determina o tamanho da janela de recebimento
ideal por conexão, calculando o produto do atraso da largura de banda (a largura de
banda multiplicada pela latência da conexão) e o índice de recuperação do aplicativo.
Depois, o tamanho máximo da janela de recebimento é ajustado em uma base regular.
Com maior velocidade do processamento entre os pontos TCP, a utilização da largura de
banda de rede aumenta durante a transferência de dados. Se todos os aplicativos forem
otimizados para receber dados TCP, a utilização total da rede poderá aumentar de forma
significativa.
Compound TCP
Considerando que o Receive Window Auto-Tuning otimiza a velocidade do
processamento do receptor, o CTCP (Compound TCP) na Pilha TCP/IP de última geração
otimiza a velocidade do processamento do emissor. Trabalhando juntos, eles podem
aumentar a utilização de links e produzir ganhos substanciais de desempenho para
grandes conexões de produto de atraso de largura de banda.
O CTCP é utilizado para conexões TCP com um grande tamanho de janela de recebimento
e um grande produto de atraso de largura de banda (a largura de banda de uma conexão
multiplicada pelo seu atraso). Ele aumenta, de forma significativa, a quantidade de dados
enviados por vez e ajuda a garantir que seu comportamento não cause impactos
negativos em outras conexões TCP.
Por exemplo, em testes realizados internamente na Microsoft, os horários de backup para
arquivos extensos foram reduzidos em quase metade para uma conexão de 1 gigabit por
segundo com um RTT (round-trip time) de 50 milésimos de segundo. Conexões com um
produto de atraso de largura de banda maior podem ter um melhor desempenho.
Melhorias para Ambientes de Alto Índice de Perda

A Pilha TCP/IP de última geração tem suporte para as seguintes RFCs (Request for
Comments) a fim de otimizar a velocidade do processamento em ambientes alto índice de
perda:
• RFC 2582: Modificação NewReno para o Algoritmo de Recuperação Rápida
do TCP
Quando múltiplos segmentos em uma janela de dados forem perdidos, e o emissor
receber uma confirmação parcial informando que os dados foram recebidos, o
algoritmo NewReno fornecerá uma maior velocidade do processamento, alterando a
forma com que um emissor pode aumentar sua taxa de envio.
• RFC 2883: Uma Extensão à Opção SACK (Selective Acknowledgement) para
TCP
O SACK, definido na RFC 2018, permite que um receptor indique até quatro blocos
não-contíguos de dados recebidos. A RFC 2883 define uma utilização adicional da
opção SACK TCP para reconhecer pacotes duplicados. Isso permite que o receptor do
segmento TCP que contém a opção SACK determine quando um segmento foi
retransmitido desnecessariamente e ajuste o comportamento para evitar futuras
107
retransmissões. Reduzir o número de retransmissões enviadas melhora a velocidade

do processamento.
• RFC 3517: Um Algoritmo de Recuperação de Perdas Baseado no SACK
(Selective Acknowledgment) Conservador para TCP
Considerando que o Windows Server 2003 e o Windows XP utilizam as informações
do SACK somente para determinar quais segmentos TCP não chegaram no destino, a
RFC 3517 define um método de utilizar as informações do SACK para realizar a
recuperação de perda quando confirmações duplicadas tiverem sido recebidas e
substitui o algoritmo de recuperação rápida quando o SACK estiver ativado em uma
conexão. A Pilha TCP/IP de última geração controla as informações do SACK em uma
base por conexão e monitora as confirmações de entrada a fim fazer a recuperação
mais rapidamente quando segmentos não forem recebidos no destino.
• RFC 4138: Recuperação F-RTO (Forward RTO): Um Algoritmo para a
Detecção de Falsos Timeouts de Retransmissão com o TCP e o SCTP (Stream
Control Transmission Protocol)
O algoritmo F-RTO (Forward-Retransmission Timeout) evita a retransmissão
desnecessária de segmentos TCP. Retransmissões desnecessárias de segmentos TCP
podem ocorrer quando houver um aumento repentino ou temporário no RTT (round-
trip time). O resultado do algoritmo F-RTO é indicado para ambientes com aumentos
repentinos ou temporários no RTT, como quando um cliente sem fio passa de um
ponto de acesso sem fio (AP - access point) para outro. O F-RTO evita a retransmissão
desnecessária de segmentos e retorna mais rapidamente a sua taxa de envio normal.
Neighbor Un-reach-ability Detection for IPv4

O Neighbor Un-reach-ability Detection é um recurso do IPv6 no qual um nó mantém o
status informando se um nó vizinho pode ser alcançado, fornecendo melhor detecção e
recuperação de erros quando os nós, repentinamente, ficarem indisponíveis. A Pilha
TCP/IP de última geração também dá suporte ao tráfego do Neighbor Un-reach-ability
Detection for IPv4, por meio do controle do estado alcançável dos nós IPv4 no cache de
rota do IPv4. O Neighbor Un-reach-ability Detection for IPv4 determina a capacidade de
alcance por meio de uma troca de mensagens ARP Reply e ARP (Address Resolution
Protocol) Request ou por meio da relação de confiança em protocolos de camada
superior, como o TCP.
Alterações na detecção de gateways inativos

A detecção de gateways inativos no TCP/IP para o Windows Server 2003 e o Windows XP
fornece uma função de failover, mas não uma função de failback, na qual um gateway
inativo é testado novamente a fim de determinar se ele se tornou disponível. A Pilha
TCP/IP de última geração fornece failback para gateways inativos, tentando
periodicamente enviar o tráfego TCP, utilizando o gateway inativo detectado
anteriormente. Se o tráfego IP enviado por meio do gateway inativo obtiver sucesso, a
Pilha TCP/IP de última geração irá alternar do gateway padrão para o gateway inativo
detectado anteriormente. O suporte ao failback para os gateways padrão primários pode
fornecer maior velocidade de processamento, enviando o tráfego com a utilização do
gateway padrão primário na sub-rede.
Alterações na Detecção de Roteadores de Buraco Negro PMTU

108
A descoberta PMTU (Path maximum transmission unit), definida na RFC 1191, confia no
recebimento de mensagens ICMP (Internet Control Message Protocol) Destination
Unreachable-Fragmentation Needed e DF (Don’t Fragment) Set dos roteadores que
contêm o MTU do próximo link. Entretanto, em alguns casos, roteadores intermediários
descartam pacotes que não podem ser fragmentados. Esses tipos de roteadores são
conhecidos como roteadores PMTU de buraco negro. Além disso, os roteadores
intermediários podem bloquear mensagens ICMP devido às regras de firewall. Devido aos
roteadores PMTU de buraco negro, as conexões TCP podem falhar e serem encerradas.
A detecção de roteadores de buraco negro PMTU faz sentido quando extensos segmentos
TCP estão sendo retransmitidos; o PMTU é automaticamente ajustado para a conexão, em
vez de confiar no recibo das mensagens de erro ICMP. No Windows Server 2003 e no
Windows XP, a detecção de roteadores de buraco negro PMTU é desabilitada por padrão,
pois estando ativada, o número máximo de transmissões executadas para um segmento
de rede específico aumenta.
Por padrão, a Pilha TCP/IP de última geração ativa a detecção de roteadores de buraco
negro PMTU a fim de evitar o encerramento das conexões TCP.
Compartimentos de Roteamento
Para evitar que o encaminhamento indesejado do tráfego entre interfaces para
configurações VPN, a Pilha TCP/IP de última geração dá suporte aos compartimentos de
roteamento. Um compartimento de roteamento é a combinação de um conjunto de
interfaces com uma sessão de login que possui suas próprias tabelas de roteamento IP.
Um computador pode possuir múltiplos compartimentos de roteamento isolados uns dos
outros. Cada interface pode pertencer somente a um único compartimento.
Por exemplo, quando um usuário inicia uma conexão VPN pela Internet com a
implementação TCP/IP no Windows XP, o computador do usuário terá conectividade
parcial tanto para a Internet quanto para a intranet particular, manipulando entradas na
tabela de roteamento IPv4. Em algumas situações, é possível que o tráfego da Internet
seja encaminhado pela conexão VPN para a intranet particular. Para clientes VPN com
suporte para compartimentos de roteamento, a Pilha TCP/IP de última geração isola a
conectividade da Internet da conectividade da intranet particular por meio de tabelas de
roteamento IP separadas.
Suporte ao Network Diagnostics Framework

O Network Diagnostics Framework é uma arquitetura extensível que ajuda os usuários na
recuperação e resolução de problemas com conexões de rede. Para a comunicação
baseada em TCP/IP, o Network Diagnostics Framework exibe ao usuário diversas opções
para eliminar as possíveis causas até que a causa do problema seja identificada ou que
todas as possibilidades sejam eliminadas. Estes são os problemas específicos relacionados
ao TCP/IP que podem ser diagnosticados pelo Network Diagnostics Framework:
• Endereço IP incorreto
• O gateway padrão (roteador) não está disponível
• Gateway padrão incorreto
• Falha de resolução de nomes NetBT (NetBIOS over TCP/IP)
• Configurações de DNS incorretas
• A porta local já está sendo utilizada

109
• O serviço DHCP Client não está sendo executado

• Não há escuta remota
• A mídia está desconectada
• A porta local está bloqueada
• Pouca memória
• Suporte ESTATS (extended statistics)
A Pilha TCP/IP de última geração dá suporte ao esboço do IETF (Internet Engineering Task
Force) “TCP Extended Statistics MIB”, o qual define as estatísticas de desempenho
estendidas para o TCP. Analisando o ESTATS em uma conexão, é possível determinar se o
gargalo de desempenho para uma conexão é o aplicativo de envio, de recepção ou se é a
rede. Por padrão, o ESTATS é desabilitado e pode ser ativado por conexão. Com o ESTATS,
os ISVs (independent software vendors) que não são da Microsoft podem criar
diagnósticos eficientes e aplicativos de análise de velocidade de processamento de rede.
Windows Filtering Platform

O WFP (Windows Filtering Platform - Plataforma de Filtragem Windows) é uma nova
arquitetura na Nova Geração da pilha TCP/IP que fornece APIs para que os ISVs não-
Microsoft possam fazer a filtragem em diversas camadas na pilha do protocolo TCP/IP e
por todo o sistema operacional.
O WFP também integra e fornece suporte para a nova geração de recursos de firewall,
como a comunicação autenticada e a configuração de firewall dinâmica baseadas na
utilização de um aplicativo do Windows Sockets API. Os ISVs podem criar firewalls,
softwares antivírus, além de outros tipos de aplicativos e serviços. O Windows Firewall e o
IPsec no Windows Server “Longhorn” e no Windows Vista utilizam o WFP API.
Explicit Congestion Notification

Quando um segmento TCP é perdido, o TCP supõe que o segmento foi perdido devido ao
congestionamento em um roteador e executa o controle de congestionamento, o que
diminui, de forma drástica, a taxa de transmissão do emissor TCP. Com o suporte ECN
(Explicit Congestion Notification - Notificação Explícita de Congestionamento) nos pontos
TCP e na infra-estrutura de roteamento, os roteadores que estão vivenciando o
congestionamento marcam os pacotes como se estivessem encaminhando-os. Os pontos
TCP que recebem os pacotes marcados diminuem sua taxa de transmissão a fim facilitar o
congestionamento e evitar a perda de segmentos. Detectar o congestionamento antes das
perdas de pacotes aumenta a velocidade de processamento entre os pontos TCP. O ECN
não é ativado por padrão.
Melhorias no IPv6
A Pilha TCP/IP de última geração dá suporte às seguintes melhorias no IPv6:
• IPv6 ativado por padrão
• Pilha IP dupla
• Configuração baseada em GUI
• Melhorias no Teredo
• Suporte IPsec integrado
110
• Multicast Listener Discovery versão 2

• Link-Local Multicast Name Resolution
• IPv6 pelo PPP
• IDs aleatórios de interface para endereços IPv6
• Suporte DHCPv6
IPv6 Ativado por Padrão

No Windows Server “Longhorn” e no Windows Vista, o IPv6 é instalado e ativado por
padrão. É possível definir as configurações do IPv6 por meio das propriedades do
componente TCP/IPv6 (Internet Protocol version 6) e também pelos comandos no
contexto IPv6 da interface.
O IPv6 no Windows Server “Longhorn” e no Windows Vista não pode ser desinstalado,
mas pode ser desabilitado.
Pilha IP Dupla
A Pilha TCP/IP de última geração dá suporte à arquitetura de camadas IP dupla, na qual as
implementações do IPv4 e IPv6 compartilham camadas comuns de frame e transporte
(TCP e UDP). A Pilha TCP/IP de última geração possui o IPv4 e o IPv6 ativados por padrão.
Não é necessário instalar um componente separado para obter o suporte ao IPv6.
Configuração Baseada em GUI

No Windows Server “Longhorn” e no Windows Vista, você pode definir manualmente as
configurações do IPv6, utilizando um conjunto de caixas de diálogo na pasta Conexões de
Rede, semelhante ao processo de definir manualmente as configurações do IPv4.
Melhorias no Teredo
O Teredo fornece conectividade aprimorada para aplicativos ativados para o IPv6,
fornecendo globalmente o endereçamento IPv6 exclusivo e permitindo o tráfego IPv6
para atravessar os NATs. Com o Teredo, os aplicativos ativados para o IPv6 que exigem o
tráfego de entrada não solicitado e o endereçamento global, como aplicativos entre
iguais, funcionarão pelo NAT. Esses mesmos tipos de aplicativos, se utilizassem o tráfego
IPv4, ou exigiriam a configuração manual do NAT, ou não funcionariam sem a
modificação do protocolo do aplicativo de rede.
O Teredo pode agora funcionar se houver um cliente Teredo atrás de um ou mais NATs
simétricos. Um NAT simétrico mapeia o mesmo endereço (privado) e o mesmo número de
porta internos para diferentes endereços e portas (públicos) externos, dependendo do
endereço externo de destino (para o tráfego de saída). Este novo comportamento permite
que o Teredo funcione entre um conjunto maior de hosts conectados à Internet.
No Windows Vista, o componente Teredo estará ativado, mas inativo por padrão. Para
ativá-lo, um usuário deve instalar um aplicativo que precise utilizar o Teredo ou optar por
alterar as configurações de firewall a fim de permitir que um aplicativo utilize o Teredo.
Suporte IPsec Integrado

No Windows Server “Longhorn” e no Windows Vista, o suporte IPsec para o tráfego IPv6 é
o mesmo existente para o IPv4, incluindo o suporte para o IKE (Internet Key Exchange) e a

111
criptografia de dados. Os snap-ins Windows Firewall with Advanced Security e IP Security

Policies agora possuem suporte para a configuração de diretivas IPsec para o tráfego IPv6,
igual ao que ocorre com o tráfego IPv4. Por exemplo, quando você configurar um filtro IP
como parte de uma lista de filtros IP no snap-in IP Security Policies, será possível
especificar endereços IPv6 e prefixos de endereços nos campos IP Address ou Subnet ao
determinar um endereço IP específico de origem ou destino.
Multicast Listener Discovery Versão 2

O MLDv2 (Multicast Listener Discovery versão 2), especificado na RFC 3810, fornece
suporte para o tráfego multicast específico à origem. O MLDv2 equivale ao IGMPv3
(Internet Group Management Protocol version 3) para IPv4.
Link-Local Multicast Name Resolution

O LLMNR (Link-Local Multicast Name Resolution) permite que hosts IPv6 em uma única
sub-rede sem um servidor de DNS resolvam os nomes uns dos outros. Essa capacidade é
muito útil para redes domésticas de única sub-rede e redes sem fio ad hoc.
IPv6 Pelo PPP

O acesso remoto agora suporta o IPv6 pelo PPP (Point-to-Point Protocol), conforme
definido na RFC 2472. O tráfego IPv6 pode agora ser enviado por conexões baseadas em
PPP. Por exemplo, o suporte IPv6 pelo PPP permite que você se conecte a um ISP (Internet
service provider) baseado no IPv6 por meio de conexões dial-up ou baseadas no PPPoE
(PPP over Ethernet) que podem ser utilizadas para o acesso de banda larga à Internet.
IDs Aleatórios de Interface para Endereços IPv6

Por padrão, com o intuito de evitar a varredura de endereços IPv6 baseados nos IDs
conhecidos da empresa dos fabricantes de adaptadores de rede, o Windows Server
“Longhorn” e o Windows Vista geram IDs aleatórios de interface para endereços IPv6
estáticos autoconfigurados, incluindo endereços públicos e locais de link.
Suporte DHCPv6
O Windows Server “Longhorn” e o Windows Vista incluem um cliente DHCP ativado para
o DHCPv6 (Dynamic Host Configuration Protocol version 6) que efetua a configuração
automática de endereços com monitoramento de estado com um servidor DHCP. O
Windows Server “Longhorn” inclui um serviço DHCP Server ativado para o DHCPv6.
Quality of Service (Qualidade de Serviço)

No Windows Server 2003 e no Windows XP, a funcionalidade QoS (Quality of Service) está
disponível para os aplicativos por meio das APIs GQoS (Generic QoS). Os aplicativos que
utilizavam as APIs GQoS acessavam funções priorizadas de entrega. No Windows Server
“Longhorn” e no Windows Vista, existem novos recursos para gerenciar o tráfego de rede
corporativa e doméstica.
QoS Baseado em Diretivas para Redes Corporativas

As diretivas de QoS no Windows Server “Longhorn” e no Windows Vista permitem que os
profissionais de TI dêem prioridade à taxa de envio para o tráfego de rede de saída ou
gerenciem essa taxa. O profissional de TI pode restringir as configurações a nomes
112
específicos de aplicativos, a endereços IP de origem e destino específicos e a portas UDP

ou TCP de origem e destino.
As configurações de diretivas de QoS fazem parte da Diretiva de Grupo user configuration
(configuração de usuário) ou computer configuration (configuração de computador) e são
configuradas com a utilização do Group Policy Object Editor. Elas são vinculadas aos
containeres dos Serviços de Domínio do Active Directory (domínios, sites e OUs - unidades
organizacionais), por meio da utilização do Group Policy Management Console (Console
de Gerenciamento de Diretivas de Grupo).
Para gerenciar a utilização de largura de banda, você pode configurar uma diretiva de
QoS com uma taxa de aceleração para o tráfego de saída. Utilizando a otimização, uma
diretiva de QoS pode limitar o tráfego de rede de saída agregado para uma taxa
específica. Para especificar a entrega priorizada, o tráfego é marcado com um valor DSCP
(Differentiated Services Code Point). Os roteadores ou os pontos de acesso sem fio na
infra-estrutura de rede podem colocar pacotes marcados com o DSCP em filas diferentes
para uma entrega diferenciada. A marcação com o DSCP e a otimização podem ser
utilizados em conjunto para gerenciar o tráfego de forma eficiente. Como os processos de
otimização e de marcação de prioridade são aplicados na camada de rede, não é preciso
modificar os aplicativos.

113
5.05 Firewall do Windows com Segurança Avançada
Começando com o Windows Vista e o Windows Server “Longhorn”, a configuração do

Firewall do Windows e do IPsec é combinada em uma única ferramenta, o snap-in MMC
Windows Firewall with Advanced Security.
O snap-in MMC Windows Firewall with Advanced Security substitui ambas as versões
anteriores dos snap-ins do IPsec, o IP Security Policies e o IP Security Monitor, para a
configuração de computadores que executam o Windows Server 2003, o Windows XP ou
o Windows 2000. Embora os computadores que executam o Windows Vista e o Windows
Server “Longhorn” também possam ser configurados e monitorados por meio da
utilização dos snap-ins anteriores do IPsec, não é possível utilizar as ferramentas mais
antigas para configurar os diversos novos recursos e opções de segurança apresentados
no Windows Vista e no Windows Server “Longhorn”. Para obter as vantagens desses novos
recursos, você deve definir as configurações, utilizando o snap-in Windows Firewall with
Advanced Security ou os comandos no contexto advfirewall da ferramenta Netsh.
O Windows Firewall with Advanced Security fornece diversas funções em um computador
que executa o Windows Vista ou o Windows Server “Longhorn”:
• Filtragem de todo o tráfego do IPv6 e do IPv4 que entra no computador ou sai
dele. Por padrão, todo o tráfego de entrada é bloqueado, a menos que ele seja
uma resposta a uma solicitação de saída anterior do computador (tráfego
solicitado) ou que ele seja especificamente permitido por uma regra criada para
permitir esse tráfego. Por padrão, todo o tráfego de saída é permitido, exceto
para regras de fortalecimento de serviço que evita a comunicação de serviços
padrão de formas inesperadas. É possível optar por permitir o tráfego baseado em
números de portas, em endereços do IPv4 ou IPv6, no caminho e nome de um
aplicativo ou no nome de um serviço executado no computador ou, ainda, em
outros critérios.
• Proteção do tráfego de rede que entra no computador ou sai dele, utilizando o
protocolo IPsec a fim de verificar a integridade do tráfego de rede, autenticar a
identidade dos computadores ou usuários de envio e recepção e, opcionalmente,
criptografar o tráfego a fim de fornecer confidencialidade.
Começando com o Windows XP Service Pack 2, o Firewall do Windows foi ativado por
padrão nos sistemas operacionais da Microsoft. O Windows Server “Longhorn” é o
primeiro sistema operacional de servidor da Microsoft a ter o Firewall do Windows ativado
por padrão. Pelo fato de o Firewall do Windows estar ativado por padrão, todo
administrador de um servidor que executa o Windows Server “Longhorn” deve estar
atento a esse recurso e entender como o firewall deve ser configurado a fim de permitir o
tráfego de rede exigido.
O console Windows Firewall with Advanced Security pode ser completamente configurado,
utilizando o snap-in MMC Windows Firewall with Advanced Security ou os comandos
disponíveis no contexto advfirewall da ferramenta de linha de comando Netsh. Tanto as
ferramentas gráficas quanto as de linha de comando dão suporte ao gerenciamento do
Windows Firewall with Advanced Security no computador local ou em um computador
remoto que executa o Windows Server “Longhorn” ou Windows Vista que esteja na rede.

114
As configurações criadas com a utilização dessas ferramentas podem ser implantadas nos
computadores vinculados à rede, utilizando a Diretiva de Grupo.
Será preciso rever esta seção sobre o Windows Firewall with Advanced Security se você
fizer parte de um dos seguintes grupos:
• Planejadores e analistas de TI que estão avaliando tecnicamente o produto.
• Planejadores e designers corporativos de TI.
• Profissionais de TI que implantam ou administram soluções de segurança de rede
em uma organização.
O Windows Firewall with Advanced Security consolida duas funções que eram gerenciadas
separadamente em versões anteriores do Windows. Além disso, a principal funcionalidade
dos componentes do IPsec e de firewall do Windows Firewall with Advanced Security foi
aprimorada de forma significativa no Windows Vista e Windows Server “Longhorn”.
Se você criar um software projetado para ser instalado no Windows Vista ou no Windows
Server “Longhorn”, será preciso ter a certeza de que o firewall é configurado corretamente
pela sua ferramenta de instalação, criando ou ativando regras que permitam que o tráfego
de rede do programa passe pelo firewall. O seu programa deverá reconhecer os diferentes
tipos de locais de rede reconhecidos pelo Windows, domínio, privado e público, e
responder corretamente a uma alteração no tipo de local de rede. É importante lembrar
que uma alteração no tipo de local de rede poderá resultar em diferentes regras de
firewall sendo aplicadas no computador. Por exemplo, se você quiser que seu aplicativo
seja executado somente em um ambiente seguro, como um domínio ou uma rede
privada, as regras de firewall deverão evitar que o seu aplicativo envie o tráfego de rede
quando o computador estiver em uma rede pública. Se o tipo de local de rede for
alterado de forma inesperada durante a execução de seu aplicativo, ele deverá lidar muito
bem com essa situação.
O Firewall do Windows é Ativado Por Padrão

O Firewall do Windows vem ativado por padrão nos sistemas operacionais cliente
Windows desde o Windows XP Service Pack 2, mas, o Windows Server “Longhorn” é a
primeira versão de servidor do sistema operacional Windows que possui o Firewall do
Windows ativado por padrão. Isso causa conseqüências sempre que um aplicativo ou
serviço é instalado e deve ter permissão para receber o tráfego de entrada não-solicitado
pela rede. Muitos aplicativos antigos não são projetados para funcionar com um firewall
baseado em host e podem não operar de forma correta, a menos que sejam definidas
regras que permitam que o aplicativo aceite o tráfego de entrada de rede não-solicitado.
Ao instalar uma função ou recurso de servidor incluído no Windows Server “Longhorn”, o
instalador irá ativar ou criar regras para garantir que a função ou recurso de servidor
funcione corretamente. Para determinar quais configurações de firewall devem ser
definidas para um aplicativo, entre em contato com o fornecedor do aplicativo. As
configurações de firewall são sempre publicadas no site de suporte do fornecedor.
Nota
Um computador que executa o Windows Server 2003 e é atualizado para o
Windows Server “Longhorn” mantém o mesmo estado operacional do firewall que
tinha antes da atualização. Se o firewall for desabilitado antes da atualização, ele
permanecerá nesse estado após a atualização. Recomendamos que você ative o

115
firewall assim que houver a confirmação de que os aplicativos na rede funcionam

com o firewall conforme configurado ou assim que as regras de firewall
apropriadas forem configuradas para os aplicativos executados em seu
computador.
O Gerenciamento da Diretiva IPsec é Simplificado

Em versões anteriores do Windows, as implementações de isolamento de domínio ou
servidor exigiam a criação de um grande número de regras IPsec para garantir que o
tráfego de rede exigido estava protegido de forma apropriada, fazendo com que o
tráfego de rede exigido não pudesse ser assegurado com o IPsec.
A necessidade de um conjunto grande e complexo de regras IPsec é reduzida devido a um
novo comportamento padrão para a negociação IPsec que solicita , mas não exige a
proteção IPsec. Ao utilizar essa configuração, o IPsec envia uma tentativa de negociação
IPsec e, ao mesmo tempo, envia pacotes de texto plano para o computador de destino. Se
o computador de destino responder à negociação e concluí-la com sucesso, a
comunicação de texto plano será interrompida, e a comunicação subseqüente será
protegida pelo IPsec. Entretanto, se o computador de destino não responder à negociação
IPsec, a tentativa de texto plano terá permissão para prosseguir. Em versões anteriores do
Windows, era preciso aguardar três segundos após a tentativa de negociação IPsec antes
de tentar a comunicação utilizando o texto plano. Isso resultava em grandes atrasos no
desempenho do tráfego, que não podia ser protegido e tinha de ser testado novamente
em texto plano. Para evitar esse atraso de desempenho, um administrador precisava criar
múltiplas regras IPsec para lidar com os diferentes requisitos de cada tipo de tráfego de
rede.
Esse novo comportamento permite solicitar, mas não exigir, que a proteção IPsec realize o
tráfego desprotegido, uma vez que o atraso de três segundos não é mais exigido. isso
permite que você proteja o tráfego onde quer que ele seja exigido, sem a necessidade de
criar regras que permitam explicitamente as exceções necessárias. Isso resulta em um
ambiente mais seguro, menos complexo e que facilita a solução de problemas.
Suporte para IP Autenticado

Em versões anteriores do Windows, o IPsec dava suporte somente ao protocolo IKE
(Internet Key Exchange) para negociar SAs (security association) do IPsec. O Windows Vista
e o Windows Server “Longhorn” dão suporte a uma extensão ao IKE conhecida como
AuthIP (Authenticated IP). O AuthIP fornece capacidades adicionais de autenticação. São
elas:
• Suporte para os novos tipos de credenciais que não estão disponíveis no IKE
isoladamente. Isso inclui: certificados de integridade fornecidos por um Health
Certificate Server, o qual faz parte de uma implantação NAP (Network Access
Protection; certificados baseados em usuários; credenciais de usuário Kerberos e
credenciais de computador ou de usuário NTLM versão 2. Essas credenciais são
adicionais para os tipos de credenciais suportados pelo IKE, como certificados
baseados em computador, credenciais Kerberos para a conta de computador ou
simplesmente chaves pré-compartilhadas.

116
• Suporte para autenticação, utilizando múltiplas credenciais. Por exemplo, o IPsec

pode ser configurado para exigir que tanto as credenciais do usuário quanto as
do computador sejam processadas com sucesso antes que o tráfego seja
permitido. Isso aumenta a segurança da rede, reduzindo a chance de um
computador confiável ser utilizado por um usuário não-confiável.
Suporte para Proteger um Membro de Domínio para o Tráfego de

Controlador de Domínio Utilizando o IPsec
Versões anteriores do Windows não suportam a utilização do IPsec para proteger o
tráfego entre controladores de domínio e computadores membro de domínio. O Windows
Vista e o Windows Server “Longhorn” são suporte à proteção do tráfego de rede entre
computadores membro de domínio e controladores de domínio, utilizando o IPsec,
enquanto permitem que um computador que não é membro de domínio passem a fazer
parte de um domínio por meio da utilização do controlador de domínio protegido pelo
IPsec.
Suporte Aprimorado para Criptografia

A implementação do IPsec no Windows Vista e no Windows Server “Longhorn” dá suporte
a algoritmos adicionais para a negociação de modo principal de SAs:
• Curva Elíptica Diffie-Hellman P-256 (Elliptic Curve Diffie-Hellman P-256), um
algoritmo de curva elíptica que utiliza um grupo de curva aleatória de 256 bits
• Curva Elíptica Diffie-Hellman P-384 (Elliptic Curve Diffie-Hellman P-384), um
algoritmo de curva elíptica que utiliza um grupo de curva aleatória de 384 bits
Além disso, os seguintes métodos de criptografia que utilizam o AES (Advanced
Encryption Standard) são suportados:
• AES com CBC (cipher block chaining) e um tamanho de chave de 128 bits (AES
128)
• AES com CBC e um tamanho de chave de 192 bits (AES 192)
• AES com CBC e um tamanho de chave de 256 bits (AES 256)
As Configurações Podem Ser Alteradas Dinamicamente Com Base no

Tipo de Local de Rede
O Windows Vista e o Windows Server “Longhorn” podem notificar aplicativos, ativados
para a rede, como o Windows Firewall, quanto às alterações nos tipos de local de rede
disponíveis por meio de adaptadores de rede anexados, conexões VPN e assim por diante.
O Windows dá suporte a três tipos de local de rede, e os programas podem utilizar esses
tipos para aplicar automaticamente o conjunto apropriado de opções de configuração. Os
aplicativos devem ser criados de forma que possam obter a vantagem desse recurso e
receber notificações de alterações feitas nos tipos de local de rede. O Windows Firewall
with Advanced Security no Windows Vista e no Windows Server “Longhorn” pode fornecer
diferentes níveis de proteção com base no tipo de local de rede ao qual o computador
está ligado.
Estes são os tipos de locais de rede:

117
• Domínio. Este tipo de local de rede será selecionado quando computador for
membro de um domínio, e o Windows irá determinar que o computador está
atualmente ligado à rede que hospeda o domínio. Essa seleção é baseada na
autenticação bem-sucedida com um controlador de domínio na rede.
• Privado. Este tipo de local de rede pode ser selecionado para redes confiáveis
pelo usuário, como uma rede doméstica ou uma rede de um pequeno escritório,
por exemplo. As configurações atribuídas a este tipo de local são mais restritivas
do que uma rede de domínio, pois não se espera que uma rede doméstica seja
tão ativamente gerenciada quanto uma rede de domínio. Uma rede recém
detectada nunca será automaticamente atribuída ao tipo de local Privado. Um
usuário deve optar explicitamente por atribuir a rede ao tipo de local Privado.
• Público. Este tipo de local de rede é atribuído por padrão a todas as redes recém
detectadas. As configurações atribuídas a este tipo de local são muito mais
restritivas, devido aos riscos de segurança existentes em uma rede pública.
Nota
O recurso que permite definir o tipo de local de rede é muito útil em computadores
cliente, principalmente em computadores portáteis, os quais são movidos de uma rede
para outra. Não se espera que um servidor seja móvel. Por esse motivo, uma estratégia
sugerida para um computador típico que executa o Windows Server “Longhorn” é
configurar esses três perfis da mesma forma.
Integração do Firewall do Windows e do IPsec Management em uma

Única Interface de Usuário
No Windows Vista e no Windows Server “Longhorn”, a interface de usuário para os
componentes de firewall e do IPsec é agora combinada no snap-in MMC Windows
Firewall with Advanced Security e em comandos no contexto advfirewall da ferramenta
de linha de comando Netsh. As ferramentas utilizadas no Windows XP, Windows Server
2003 e na família Windows 2000 — o modelo administrativo Windows Firewall, as
configurações de Diretiva de Grupo, o IP Security Policy, os snap-ins MMC do IP
Security Monitor e os contextos ipsec e firewall do comando Netsh — ainda estão
disponíveis, mas não dão suporte aos mais novos recursos incluídos no Windows Vista e
no Windows Server “Longhorn”. O ícone do Windows Firewall no Painel de Controle
também ainda está presente, mas é uma interface de usuário final para gerenciar as
funcionalidades básicas do firewall e não apresenta as opções avançadas exigidas por um
administrador.
Utilizando as diversas ferramentas para o firewall e o IPsec em versões anteriores do
Windows, aos administradores podem criar, acidentalmente, configurações conflitantes,
como uma regra IPsec que faz com que um tipo específico de pacote de rede seja
interrompido, mesmo que exista uma regra de firewall para permitir que o mesmo tipo de
pacote de rede esteja presente. Isso pode resultar em cenários com problemas difíceis de
serem solucionados. Combinar as duas funções reduz a possibilidade de criar regras
conflitantes e ajuda a garantir que o tráfego que você deseja proteger seja manipulado
corretamente.
Suporte Total para a Proteção de Tráfego de Rede IPv4 e IPv6

118
Todos os recursos de firewall e do IPsec disponíveis no Windows Vista e no Windows

Server “Longhorn” são utilizados para proteger o tráfego de rede IPv4 e IPv6.
Referências Adicionais
Os recursos a seguir fornecem informações adicionais sobre o Windows Firewall with
Advanced Security e o IPsec:
• Para mais informações sobre o Windows Firewall with Advanced Security, veja
“Windows Firewall” (http://go.microsoft.com/fwlink/?LinkID=84639) no site da Web
Microsoft TechNet.
• Para mais informações sobre o IPsec, veja IPsec
(http://go.microsoft.com/fwlink/?LinkID=84638) no site da Web Microsoft TechNet.
• Para mais informações sobre os cenários de isolamento de servidor e domínio, veja
Isolamento de Domínio e Servidor (http://go.microsoft.com/fwlink/?LinkID=79430) no
site da Web Microsoft TechNet.
• Para mais informações sobre o Network Access Protection, veja Network Access
Protection (http://go.microsoft.com/fwlink/?LinkID=84637) no site da Web Microsoft
TechNet.
• Para mais informações sobre como criar aplicativos que estejam cientes dos tipos de
local de rede, consulte o Network Awareness no Windows Vista
(http://go.microsoft.com/fwlink/?LinkId=85491) e Network Location Awareness Service
Provider (http://go.microsoft.com/fwlink/?LinkId=85492) no site da Web Microsoft
MSDN®.

119
5.06 Cryptography Next Generation
O CNG (Cryptography Next Generation – Criptografia de Última Geração) fornece uma

plataforma de desenvolvimento criptográfico flexível que permite que profissionais de TI
criem, atualizem e utilizem algoritmos de criptografia personalizados em aplicativos
relacionados à criptografia, como o Active Directory® Certificate Services, o SSL e o IPsec.
O CNG implementa os algoritmos de criptografia Suite B do governo dos E.U.A , os quais
incluem algoritmos para criptografia, assinaturas digitais, troca de chaves e hashing.
Além disso, o CNG fornece um conjunto de APIs utilizadas para:
• Realizar operações básicas de criptografia, como a criação de hashes e a
criptografia e descriptografia de dados.
• Criar, armazenar e recuperar chaves de criptografia.
• Instalar e utilizar provedores adicionais de criptografia.
O CNG possui as seguintes capacidades:
• O CNG permite que os clientes utilizem seus próprios algoritmos de criptografia
ou implementações de algoritmos padrão de criptografia. É possível adicionar
novos algoritmos.
• O CNG dá suporte à criptografia no modo kernel. A mesma API é utilizada no
modo kernel e no modo usuário para dar suporte total aos recursos de
criptografia. O SSL/TLS e o IPsec, além dos processos de inicialização que utilizam
o CNG, operam no modo kernel.
• O plano para o CNG inclui a aquisição da certificação FIPS (Federal Information
Processing Standards) 140-2 nível 2 juntamente com as avaliações de Critérios
Comuns (Common Criteria).
• O CNG atende aos requisitos do Common Criteria, utilizando e armazenando
chaves de longa duração em um processo seguro.
• O CNG dá suporte ao conjunto atual de algoritmos CryptoAPI 1.0.
• O CNG fornece suporte aos algoritmos ECC (elliptic curve cryptography -
criptografia de curva elíptica). Um grande número de algoritmos ECC é exigido
pelo Suite B do governo dos Estados Unidos.
• Qualquer computador com um TPM (Trusted Platform Module - módulo de
plataforma confiável) poderá fornecer isolamento e armazenamento de chave no
TPM.
O CNG aplica à PKI (public key infrastructure) implantações que exigem a utilização dos
algoritmos Suite B e que não precisam estar integrados às CAs (certification authorities)
que não dão suporte aos algoritmos Suite B, como as CAs instaladas em servidores que
executam o Windows Server 2003 e o Windows 2000 Server.
Para utilizar os novos algoritmos de criptografia, a CA e os aplicativos deverão dar suporte
ao ECC (ou a qualquer outro novo algoritmo implementado no CNG). Embora a CA
precise emitir e gerenciar estes novos tipos de certificado, os aplicativos devem ser
capazes de lidar com a validação da cadeia de certificados e utilizar as chaves geradas
com os algoritmos Suite B.

120
Os algoritmos Suite B, como o ECC, são suportados somente no Windows Vista e no

Windows Server “Longhorn”. Isso significa que não é possível utilizar esses certificados em
versões anteriores do Windows, como Windows XP ou Windows Server 2003. Entretanto, é
possível utilizar os algoritmos clássicos, como o RSA (Rivest-Shamir-Adleman) mesmo se as
chaves tiverem sido gerada com um provedor de chaves CNG.
Os clientes que executam o Windows Vista ou o Windows Server “Longhorn” podem
utilizar tanto o CryptoAPI 1.0 quanto a nova API CNG, pois ambas as APIs podem ser
executadas lado a lado. No entanto, aplicativos, como o SSL, IPsec, S/MIME
(Secure/Multipurpose Internet Mail Extensions) e o Kerberos, devem ser atualizados a fim
de utilizar os algoritmos Suite B.
Implantação
Não implante certificados com algoritmos Suite B antes de verificar os seguintes requisitos:
• Antes de emitir certificados que utilizem algoritmos, tais como o ECC, verifique se
suas CAs e seu sistema operacional dão suporte a esses algoritmos.
• Verifique se os aplicativos ativados para a PKI de sua organização podem utilizar
certificados que confiam em provedores de criptografia CNG.
• Caso sua organização utilize certificados para suportar o logon de smart card,
entre em contato com o fornecedor de seu smart card e veja se os smart cards
que ele fornece podem lidar com algoritmos CNG.
No Windows Vista e no Windows Server “Longhorn”, os seguintes aplicativos ativados para
certificados podem lidar com certificados que utilizam algoritmos de criptografia
registrados no provedor CNG.
Aplicativos Ativados para Certificados

Nome do Aplicativo Verifica uma cadeia de Utiliza algoritmos que não são suportados pelo
certificados que CryptoAPI
contém certificados
com algoritmos
registrados em um
provedor CNG
EFS (Sistema de Sim Não

Arquivos
Criptografado)
IPsec Sim Sim
Kerberos Não Não
S/MIME Outlook® 2003: não Outlook 2003: não

Outlook 2007: sim Outlook 2007: sim

121
Nome do Aplicativo Verifica uma cadeia de Utiliza algoritmos que não são suportados pelo
certificados que CryptoAPI
contém certificados
com algoritmos
registrados em um
provedor CNG
logon via cartão Não Não

inteligente
SSL Sim Sim
Sem fio Sim Sim
Para utilizar os algoritmos para as operações de criptografia, primeiro, você precisa de

uma CA baseada no Windows Server “Longhorn” para emitir certificados ativados para o
Suite B.
Caso você ainda não possua uma PKI, será possível configurar uma CA baseada no
Windows Server “Longhorn” em que os certificados da CA e os certificados da entidade
final utilizem algoritmos Suite B. Entretanto, ainda será preciso verificar se todos os seus
aplicativos estão preparados para os algoritmos Suite B e se podem dar suporte a esses
certificados.
Caso você já possua uma PKI com CAs sendo executadas no Windows Server 2003 ou na
qual algoritmos clássicos estão sendo utilizados para dar suporte aos aplicativos existentes,
será possível adicionar uma CA subordinada em um servidor que executa o Windows
Server “Longhorn”. No entanto, você deverá continuar utilizando os algoritmos clássicos.
Para inserir os algoritmos Suite B em um ambiente existente, no qual são utilizados os
algoritmos clássicos, será preciso considerar a inserção de uma PKI secundária e a
realização de uma certificação cruzada entre as duas hierarquias de CA.
Para mais informações sobre o CNG, veja API de Criptografia: Última Geração
(http://go.microsoft.com/fwlink/?LinkID=74141).
Para mais informações sobre o Suite B, veja Criptografia Suite B NSA (NSA Suite B
Cryptography Fact Sheet) (http://go.microsoft.com/fwlink/?LinkId=76618).

122
5.07 Serviços de Certificado do Active Directory
Os Serviços de Certificado do Active Directory fornece serviços personalizáveis para criar e

gerenciar certificados de chave pública utilizados em sistemas de segurança de software
que utilizam tecnologias de chave pública. As organizações podem utilizar os Serviços de
Certificado do Active Directory para aprimorar a segurança, unindo a identidade de uma
pessoa, dispositivo ou serviço a uma chave privada correspondente. Os Serviços de
Certificado do Active Directory também inclui recursos que permitem gerenciar o registro
e a revogação de certificados em diversos ambientes escalonáveis.
Os seguintes tópicos descrevem as alterações na funcionalidade dos Serviços de
Certificado do Active Directory disponível neste lançamento:
• Serviços de Certificado do Active Directory: Registro Web
• Serviços de Certificado do Active Directory: Configurações de Diretivas
• Serviços de Certificado do Active Directory: Serviço de Registro de Dispositivo de
Rede
• Serviços de Certificado do Active Directory: PKI Corporativo(PKIView)
• Serviços de Certificado do Active Directory: Suporte ao Protocolo de Status de
Certificado Online
Serviços de Certificado do Active Directory: Registro Web

Um grande número de alterações foi feito ao suporte de registro Web de certificados no
Windows Server “Longhorn”. Essas alterações resultam da exclusão do controle anterior de
registro ActiveX® do Windows Vista e do Windows Server “Longhorn”e sua substituição
pelo controle de registros COM. As seções a seguir descrevem essas alterações e suas
respectivas implicações.
O registro Web de certificados está disponível desde sua inclusão nos sistemas
operacionais Windows 2000. Ele é projetado para fornecer um mecanismo de ambiente
para as organizações que precisam emitir e renovar certificados para usuários e
computadores que não fazem parte de um domínio ou que não está conectados
diretamente à rede e para usuários de sistemas operacionais não-Microsoft. Em vez de
confiar no mecanismo de registro automático de uma CA ou utilizar o Certificate Request
Wizard, o suporte de registro Web fornecido por uma CA baseada no em Windows
permite que esses usuários solicitem e obtenham certificados novos e renovados por uma
conexão da Internet ou da intranet.
Esse recurso é indicado para organizações que possuem PKIs com uma ou mais CAs que
executam o Windows Server “Longhorn” e clientes que executam o Windows Vista e que
desejam fornecer aos usuários a capacidade de obter novos certificados ou renovar os
existentes, utilizando páginas da Web.
Adicionar suporte para páginas de registro Web pode aprimorar, de forma significativa, a
flexibilidade e a escalabilidade da PKI de uma organização; portanto, esse recursos será de
interesse de:
• Arquitetos de PKI
• Planejadores de PKI
• Administradores de PKI
123
O controle de registro anterior, o XEnroll.dll, foi removido do Windows Vista e do

Windows Server “Longhorn”, e um novo controle de registro, o CertEnroll.dll, foi inserido.
Embora o processo de registro Web ocorra essencialmente como para o Windows 2000,
Windows XP e Windows Server 2003, essa alteração nos controles de registro poderá
impactar na compatibilidade quando usuários e computadores que executam o Windows
Vista ou o Windows Server “Longhorn” tentarem solicitar um certificado, utilizando
páginas de registro Web instaladas nessas versões anteriores do Windows.
O XEnroll.dll está sendo retirado pelas seguintes razões:
• O XEnroll.dll é um controle de legado criado há alguns anos e não é considerado
tão seguro quanto os controles criados recentemente.
• O XEnroll.dll possui uma interface monolítica que expõe diversos conjuntos de
funcionalidades. Ele possui mais de 100 métodos e propriedades. Esses métodos e
propriedades foram inseridos com o passar dos anos, e chamar uma função pode
alterar o comportamento de outra função, o que dificulta os processos de teste e
manutenção.
Nota
O XEnroll.dll pode continuar a ser utilizado para o registro Web em computadores
que executam o Windows 2000, Windows XP e Windows Server 2003. Por outro
lado, o CertEnroll.dll foi criado para ser mais seguro, mais fácil de ser preparado e
atualizado do que o XEnroll.dll.
As CAs do Windows Server “Longhorn” continuarão a dar suporte às solicitações de
registro Web de certificados a provenientes de usuários em clientes Windows XP e
Windows Server 2003. Se você registra certificados por meio das páginas de registro Web
do Windows Server “Longhorn” a partir de um computador baseado no Windows XP,
Windows Server 2003 ou Windows 2000, as páginas de registro Web irão detectar esse
fato e utilizarão o controle Xenroll.dll instalado localmente no cliente. Entretanto, alguns
comportamentos do cliente serão diferentes daqueles das versões anteriores do Windows.
São eles:
• A capacidade de agente de registro (também conhecida como a estação de
registro de smart card) foi removida do registro Web no Windows Server
“Longhorn”, pois o Windows Vista fornece sua própria capacidade de agente de
registro. Se houver a necessidade de efetuar o registro em nome de outro cliente
com um registro Web do Windows Server “Longhorn”, você deverá utilizar
computadores que executem o Windows Vista como estações de registro. De
forma alternativa, você poderá utilizar um servidor baseado no Windows Server
2003 com o registro Web instalado e utilizar o servidor como um agente de
registro a fim de registrar certificados por meio de uma CA do Windows Server
“Longhorn”.
• Somente os usuários do Internet Explorer® versão 6.x ou Netscape 8.1 Browser
poderão enviar solicitações de certificado diretamente por meio das páginas de
registro Web. Usuários de outros navegadores da Web ainda poderão enviar
solicitações de registro, utilizando as páginas de registro Web, mas,
primeiramente, deverão gerar previamente uma solicitação PKCS#10 para ser
enviada por meio das páginas de registro Web.
• O registro de Web de certificados não pode ser utilizado com os templates de
certificado versão 3,0 (os quais estão sendo apresentados no Windows Server

124
“Longhorn” para o suporte à emissão de certificados em conformidade com o

Suite B).
• O Internet Explorer não pode ser utilizado no contexto de segurança de
computadores locais; portanto, os usuários não podem mais solicitar certificados
de computador com a utilização do registro Web.
• No Windows Server “Longhorn” Beta 2, o suporte de registro Web está disponível
somente nas edições dos idiomas alemão e inglês dos EUA O suporte de registro
Web estará disponível em todas as versões de idiomas do produto final do
Windows Server “Longhorn”.
A configuração que deve ser feita para o suporte de registro Web de certificados é,
simplesmente, adicionar o serviço de função à função de servidor.
Se o suporte de registro Web estiver instalado no mesmo computador que a CA, não será
exigida nenhuma configuração adicional.
Se o serviço de função de registro Web e a CA estiverem instalados em computadores
diferentes,será preciso identificar a CA como parte da instalação do registro Web.
Após a instalação do serviço de função de registro Web, um novo site chamado “CertSrv”
estará disponível por meio do IIS.
Nota
No Windows Server “Longhorn” Beta 2, o arquivo utilizado pelo suporte de
registro Web para encontrar a CA está localizado no diretório de linguagem
específica, como %SYSTEMROOT%\system32\certsrv\[language]\certdat.inc. Esse
arquivo passará a ser um arquivo de configuração global que define a
configuração para todos os pacotes de idioma instalados para o registro Web. Se
você possuir diversos pacotes de idioma instalados em um servidor IIS, todos os
arquivos certdat.inc nos subdiretórios de linguagem específica deverão ser
idênticos.
As páginas de registro Web não-Microsoft sofrerão um grande impacto, pois o controle
XEnroll.dll não está disponível no Windows Server “Longhorn” e no Windows Vista. Os
administradores dessas CAs terão de criar soluções alternativas para o suporte à emissão
de certificados e a renovação para clientes que utilizam o Windows Server “Longhorn” e o
Windows Vista, enquanto continuam utilizando o Xenroll.dll para versões anteriores do
Windows.
Os administradores também precisam planejar a configuração apropriada de seus
servidores que executam o IIS. O IIS pode ser executado somente nos modos de 64 ou 32
bits. Se você instalar o IIS em um servidor que executa a versão de 64 bits do Windows
Server “Longhorn”, você não deverá instalar nenhum aplicativo Web de 32 bits, como o
WSUS, nesse computador. Caso contrário, instalação do serviço de função de registro irá
falhar.
Serviços de Certificado do Active Directory: Configurações de

Diretivas
As configurações de certificado na Diretiva de Grupo do Windows Server “Longhorn”
permitem que os administradores gerenciem configurações de validação de certificado de
acordo com as necessidades de segurança da organização.

125
As configurações de certificado na Diretiva de Grupo permite que os administradores

gerenciem as configurações de certificado em todos os computadores do domínio a partir
de um local central. Definir as configurações utilizando a Diretiva de Grupo poderá causar
alterações em todo o domínio.
Por exemplo, em situações em que determinados certificados de CA expiram e os clientes
não conseguem recuperar automaticamente um novo certificado, os administradores
poderão implantar esses certificados para os computadores cliente por meio da Diretiva
de Grupo.
Outro cenário é quando os administradores desejam garantir que os usuários nunca irão
instalar aplicativos assinados com certificados de publicação não aprovada. Eles poderão
configurar timeouts de rede para um melhor controle dos timeouts de construção em
cadeia para grandes CRLs (certification revocation lists - listas de revogação de
certificação). Além disso, os administradores poderão utilizar as configurações de
revogação para estender os tempos de expiração das CRLs caso um atraso na publicação
de uma nova CRL afete os aplicativos.
Esse recurso aplica-se às organizações que possuem PKIs com uma ou mais CAs baseadas
no Windows e utilizam Diretiva de Grupo para gerenciar computadores cliente.
Utilizar as configurações de validação de certificado na Diretiva de Grupo poderá
aprimorar, de forma significativa, a capacidade de:
• Arquitetos de segurança aprimorarem a utilização da relação de confiança
baseada em certificados.
• Administradores de segurança gerenciarem aplicativos ativados para a PKI em
seus ambientes.
Pelo fato de as infra-estruturas de chave pública X.509 terem se tornado mais amplamente
utilizadas como uma base de confiança, muitas organizações precisam de mais opções
para gerenciar a descoberta de caminho de certificados e a validação de caminhos.
Versões anteriores dos sistemas operacionais Windows possuíam poucas configurações
para implementar esse tipo de controle.
As configurações de Diretiva de Grupo relacionadas a certificados podem ser encontradas
no Group Policy Object Editor, em Configuração do Computador\Configurações do
Windows\Configurações de Segurança\Diretivas de Chave Pública. As seguintes
opções de diretiva podem ser gerenciadas em guias separadas na página de propriedades
Certificate Path Validation Settings:
• Stores (Armazenamentos)
• Trusted Publishers (Editores Confiáveis)
• Network Retrieval (Recuperação de Rede)
• Revocation (Revogação)
Além disso, quatro novos armazenamentos de diretiva foram adicionados em Diretivas de
Chave Pública (Public Key Policies) para serem utilizados na distribuição de diferentes
tipos de certificados para os clientes:
• Intermediate Certification Authorities (Autoridades Intermediárias de Certificação)
• Trusted Publishers (Editores Confiáveis)
• Untrusted Certificates (Certificados Não-Confiáveis)
• Trusted People (Pessoas Confiáveis)
126
Esses novos armazenamentos são uma adição aos armazenamentos Enterprise Trust
(Relação de confiança Corporativa) e Trusted Root Certification Authorities (Autoridades
de Certificação de Raiz Confiável) disponíveis no Windows Server 2003.
Essas configurações de validação de caminho e armazenamentos de certificados podem
ser utilizadas para realizar as seguintes tarefas:
• Gerenciar armazenamentos de certificado peer trust e trusted root.
• Gerenciar editores confiáveis.
• Bloquear certificados que não sejam confiáveis de acordo com a diretiva.
• Gerenciar a recuperação de dados relacionados a certificados.
• Gerenciar períodos de expiração para CRLs e respostas OCSP (online certificate
status protocol).
• Implantar certificados.
Gerenciar Armazenamentos de Certificado Peer Trust e Trusted Root

Utilizando a guia Stores na caixa de diálogo Certificate Path Validation Settings, os
administradores podem regular a capacidade de os usuários gerenciarem seus próprios
certificados trusted root e peer trust. Este controle pode ser implementado para que os
usuários não tenham permissão para tomar quaisquer decisões quanto à relação de
confianças de ponto ou raiz (root or peer trust). Além disso, ele pode ser utilizado para
controlar quantos propósitos de certificado específicos, como assinatura e criptografia, os
usuários podem gerenciar por relação de confiança entre iguais (peer trust).
A guia Stores também permite que os administradores especifiquem se os usuários em
um computador ligado a um domínio poderão confiar somente em CAs de raiz
corporativa ou em CAs de raiz não-Microsoft de raiz corporativa.
Se, por um lado, um administrador precisa distribuir certificados selecionados de raiz
confiável, para computadores no domínio, esses certificados serão propagados para o
armazenamento de certificado apropriado na próxima vez em que a diretiva de domínio
for restaurada.
Devido à crescente variedade de certificados em uso nos dias de hoje e à grande
importância das decisões a serem tomadas quanto ao fato de reconhecer ou não esses
certificados, algumas organizações podem desejar gerenciar a relação de confiança de
certificados e evitar que os usuários no domínio configurem seu próprio conjunto de
certificados de raiz confiável.
Utilizar as configurações de Diretiva de Grupo relacionadas à relação de confiança de
certificados exige um planejamento cuidadoso a fim de determinar as necessidades de
certificado de usuários e computadores em sua organização, além de terminar como esses
certificados deverão ser controlados. Você pode conseguir fornecer as usuários maior
tolerância se combinar a utilização dessas configurações com um treinamento claro e
eficiente de forma que os usuários entendam a importância dos certificados, os riscos de
um mau gerenciamento de certificados e como eles devem gerenciar seus certificados
com responsabilidade.
Gerenciar Editores Confiáveis

127
As opções de diretiva encontradas na guia Trusted Publishers da caixa de diálogo

Configurações de Validação de Caminho permitem que os administradores controlem
quais certificados podem ser aceitos quando vierem de um editor confiável.
A assinatura de software tem sido utilizada por um número crescente de editores de
software e desenvolvedores de aplicativos a fim de verificar se seus aplicativos são
provenientes de uma fonte confiável. No entanto, muitos usuários não compreendem os
certificados de assinatura associados aos aplicativos que instalam ou sequer dão atenção a
esse fato.
Especificar opções de diretiva de publicação confiáveis por toda a organização permite
que as organizações decidam de os certificados Authenticode® podem ser gerenciados
pelos usuários e administradores ou se apenas pelos administradores corporativos.
Além disso, esta seção da diretiva de validação de caminho pode exigir que as verificações
de revogação adicional e o time stamp sejam realizados antes que um certificado de
publicação confiável seja aceito.
certificado de usuários e computadores em sua organização, além de determinar como
esses certificados deverão ser controlados. Você pode conseguir fornecer aos usuários
maior tolerância se combinar a utilização dessas configurações com um treinamento claro
e eficiente de forma que os usuários entendam a importância dos certificados, os riscos de
Bloquear Certificados Que Não Sejam Confiáveis de Acordo Com a

Diretiva.
É possível evitar que determinados certificados sejam utilizados em sua organização,
adicionando-os no armazenamento Untrusted Certificates (Certificados Não-Confiáveis).
Pelo fato de os administradores serem responsáveis pela prevenção da entrada de vírus e
outros softwares maliciosos em seus ambientes, no futuro, eles poderão desejar bloquear
a utilização de determinados certificados. Um certificado emitido por sua própria CA pode
ser revogado, sendo adicionado a uma lista de revogação de certificados. Não é possível
revogar certificados emitidos por CAs externas. Entretanto, é possível proibir esses
certificados não-confiáveis, adicionando-os no armazenamento Untrusted Certificates.
Esses certificados serão copiados para o armazenamento Untrusted Certificates de cada
computador cliente no domínio na próxima vez em que a Diretiva de Grupo for
restaurada.
certificado de usuários e computadores em sua organização, além de terminar como esses
certificados deverão ser controlados. Você pode conseguir fornecer aos usuários maior
tolerância se combinar a utilização dessas configurações com um treinamento claro e
eficiente de forma que os usuários entendam a importância dos certificados, os riscos de
Gerenciar a Recuperação de Dados Relacionados a Certificados.

128
As CRLs podem tornar-se muito grandes e, conseqüentemente, falharem no processo de

download, pois o processo é mais demorado do que o timeout padrão de 15 segundos. As
opções encontradas na guia Network Retrieval da caixa de diálogo Configurações de
Validação de Caminho permitem que os administradores modifiquem os timeouts de
recuperação padrão a fim de resolver esse problema.
Além disso, as configurações de validação de caminho e de recuperação de rede
permitem que os administradores:
• Atualizem certificados automaticamente no Microsoft Root Certificate Program.
• Configurem valores de timeout de recuperação para as CRLS e a validação de
caminho (valores padrão maiores poderão ser úteis se as condições de rede não
forem ótimas).
• Ativem a recuperação de certificados do emissor durante a validação de caminho.
• Definam a freqüência de realização do download de certificados cruzados.
Para melhor eficiência, dados relacionados aos certificados, como certificados de raiz
confiável e listas de revogação de certificados, deverão ser atualizados adequadamente.
No entanto, as condições de rede nem sempre são ótimas, como para usuários remotos
ou escritórios de filiais. Essas configurações de Diretiva de Grupo permitem que você
garanta que os dados relacionados aos certificados sejam atualizados mesmo quando as
condições de rede forem inferiores ao estado otimizado.
Ao preparar-se para esta alteração, determine se as condições de rede impactam nos
tempos de download das CRLs.
Gerenciar Períodos de Expiração para CRLs e Respostas OCSP

A revogação de um certificado anula um certificado como uma credencial de segurança
confiável antes da expiração natural de seu período de validade. Um PKI depende da
verificação distribuída das credenciais, em que não há necessidade de comunicação direta
com a entidade confiável principal que atesta as credenciais.
Para o suporte eficiente da revogação de certificados, o cliente deve determinar se o
certificado é válido ou se ele foi revogado. Para dar suporte a uma variedade de cenários,
os Serviços de Certificado do Active Directory tem suporte para os métodos de padrão
industrial de revogação de certificados.
Isso inclui a publicação de CRLs e CRLs em diversos locais para serem acessadas pelos
clientes, incluindo os Serviços de Domínio do Active Directory, servidores Web e
compartilhamentos de arquivos de rede. No Windows, os dados de revogação podem ser
disponibilizados em diversas configurações por meio das respostas OCSP.
As condições de rede podem evitar que as CRLs mais recentes sejam publicadas, o que
poderá fazer com que todos as validações da cadeia de certificados falhem. Estender o
tempo de expiração da CRL existente e da resposta OCSP pode prevenir que isso ocorra.
Utilizar configurações de Diretiva de Grupo relacionadas aos dados de revogação de
certificados exige um planejamento cuidadoso para determinar o equilíbrio apropriado
entre a adesão rigorosa ao cronograma de publicação de CRL padrão e as conseqüências
potenciais de estender o período de validade da CRL caso uma CRL atualizada não esteja
disponível.

129
Implantando Certificados
Os certificados de usuário e computador podem ser implantados, usando-se diversos
mecanismos, incluindo o registro automático, o Assistente para Requisição de Certificado
e o registro na Web. Mas implantar outros tipos de certificados em uma grande
quantidade de computadores pode ser algo desafiador. No Windows Server 2003, era
possível distribuir um certificado CA de raiz confiável e certificados corporativos de
confiança usando a Diretiva de Grupo. No Windows Server “Longhorn”, todos os tipos de
certificados que seguem podem ser distribuídos, quando são armazenados
adequadamente na Diretiva de Grupo:
• Certificados CA de raiz confiáveis
• Certificados corporativos de confiança
• Certificados CA Intermediários
• Certificados confiáveis do editor
• Certificados não-confiáveis
• Pessoas confiáveis (para os certificados de confiança)
A variedade crescente dos certificados e a sua utilização exige que os administradores
tenham meios eficientes para distribuí-los a usuários e computadores em suas
organizações.
Usar configurações de Diretiva de Grupo relacionadas à relação de confiança requer um
planejamento cauteloso para determinar as necessidades de usuários e computadores em
sua organização, além da quantidade de controle que eles devem ter sobre esses
certificados. Você deve ter a capacidade de fornecer o livre arbítrio aos usuários, se
combinar o uso dessas configurações com um treinamento claro e efetivo, a fim de que os
usuários entendam a importância dos certificados, os riscos de um gerenciamento fraco de
certificados e a maneira de gerenciá-los de forma responsável.
Você deve ser membro do grupo de Administradores de Domínio para configurar a
Diretiva de Grupo neste domínio.
Serviços de Certificado do Active Directory: Network Device

Enrollment Service
O Network Device Enrollment Service (NDES) é a implementação da Microsoft para o
certificado Enrollment Protocol (SCEP), um protocolo de comunicação que possibilita que
o software seja executado em dispositivos de rede, como roteadores e alternadores, que,
por sua vez, não podem ser autenticados na rede, para registrar certificados de x509 a
partir do CA.
O NDES opera como um filtro da Interface de Programação de Aplicação para o Servidor
da Internet (ISAPI) no IIS que desempenha as seguintes funções:
• Gerar e fornecer senhas únicas de registro aos administradores
• Receber e processar requisições de registro SCEP em nome de softwares
executados nos dispositivos de rede
• Recuperar requisições pendentes do CA.

130
Este recurso aplica-se às organizações que têm PKIs com um ou mais CAs do Windows
Server “Longhorn” CAs e que desejam aprimorar a segurança das comunicações, usando o
IPsec com dispositivos de rede, como os roteadores e alternadores.
Adicionar suporte ao NDES pode aprimorar, de forma significativa, a flexibilidade e
escalabilidade do PKI de uma organização; portanto, este recurso pode interessar os
arquitetos de PKI, planejadores e administradores.
As organizações e os profissionais interessados nos NDES podem querer saber mais sobre
as especificações de SCEP em que ele se baseia.
O SCEP foi desenvolvido pela Cisco Systems Inc. como extensão aos já existentes HTTP,
PKCS #10, PKCS #7, RFC 2459 e outros padrões, para permitir o registro de dispositivo de
rede e certificado da aplicação com os CAs.
No Windows Server 2003, o Microsoft SCEP (MSCEP) era um suplemento do Windows
Server 2003 Resource Kit que precisava ser instalado no mesmo computador que o CA. No
Windows Server “Longhorn,” o suporte do MSCEP foi renomeado para NDES e faz parte
do sistema operacional, podendo ser instalado em um computador diferente do CA.
A extensão do NDES ao IIS utiliza o registro para armazenar configurações de
configurações. Todas as configurações são armazenadas sob a chave do Registro:
HKEY_LOCAL_ROOT\Software\Microsoft\Cryptography\MSCEP
A tabela que segue define as chaves de registro usadas para configurar o MSCEP:
Chaves do Registro em MSCEP

Nome da Configuração Opcional Valor Valores Possíveis
Padrão
Atualização Não 7 Quantidade de dias em que as requisições

pendentes são mantidas no banco de dados
NDESP.
Aplicar Senha Não 1 Define se as senhas são exigidas para requisições

de registro. O valor 1 significa que o NDES requer
uma senha para requisições de registro. O valor 0
(zero) significa as senhas não requeridas.
PasswordMax Não 5 Quantidade máxima de senhas disponíveis que

podem ser armazenadas.
Nota:
Nas versões anteriores, o padrão era 1.000.
PasswordValidity Não 60 Quantidade de minutos em que uma senha é

válida.
PasswordVDir Sim O nome do diretório virtual pode ser usado para as

requisições de senha. Se definido, o NDES aceita
requisições de senha apenas do diretório virtual
estabelecido. Se o valor está vazio ou não
configurado, o NDES aceita as requisições de
senha de qualquer diretório virtual.
CacheRequest Não 20 Quantidade de minutos em que os certificados

emitidos são mantidos no banco de dados SCEP.
CAType Não Baseado na Identifica o tipo de CA ao qual o NDES está ligado.

configuraçã O valor 1 significa que é um CA corporativa; o
o valor 0 significa que é um CA autônomo.
SigningTemplate Sim Não Se a chave estiver definida, o NDES usa um valor,

131
definido como o nome modelo do certificado, quando os

clientes se cadastram para assinar o certificado.
EncryptionTemplate Sim Não Se a chave estiver definida, o NDES usa um valor,

clientes se cadastram para um certificado de
criptografia.
SigningAndEncryptionTemplate Sim Não Se a chave estiver definida, o NDES usa um valor,

clientes se cadastram para assinar e criptografar
um certificado, ou quando a requisição não inclui
uma utilização estendida da chave.
Antes de instalar o NDES, decida o seguinte:

• Se usar uma conta de usuário dedicada para o serviço ou usar a conta do Network
Service
• O nome da autoridade de registro (RA) do NDES e qual país/região usar. As
informações são incluídas em qualquer certificado MSCEP emitido
• O provedor de serviço criptográfico (CSP) para usar na chave de assinatura usada
para criptografar a comunicação entre o CA e a RA
• O CSP a ser usado para a chave de criptografia usada para criptografar a
comunicação entre a RA e o dispositivo de rede
• A extensão de cada chave
Além disso, você precisa criar e configurar modelos de certificado usados juntamente com
o NDES.
Instalar o NDES em um computador cria uma nova RA e exclui quaisquer certificados RA
pré-existentes no computador. Portanto, se você planeja instalar o NDES em um
computador em que outra RA tenha sido configurada, quaisquer requisições pendentes de
certificado devem ser processadas e todos os certificados não declarados devem ser antes
de o NDES ser instalado.
Serviços de Certificado do Active Directory: PKI Corporativo

Monitorar e ajustar a integridade de múltiplos CAs para a hierarquia de PKI corporativo,
nos Serviços de Certificado do Active Directory, são tarefas administrativas essenciais
simplificadas pelo PKI Corporativo (PKIView). Originalmente parte do Microsoft Windows
Server 2003 Resource Kit, chamado de ferramenta PKI Health, o PKIView é agora um snap-
in de MMC do Windows Server “Longhorn.” Como ele faz parte do sistema operacional
núcleo do Windows Server “Longhorn,” você pode usá-lo depois da instalação do servidor,
apenas adicionando-o ao MMC. Ele então se torna disponível para analisar o estado de
integridade dos CAs e para ver detalhes dos certificados de CA publicados nos Serviços de
Certificados do Active Directory.
O PKIView fornece uma visualização do status do seu ambiente PKI da rede. Ter uma visão
de todos os CAs e de seus estados permite que os administradores gerenciem as
hierarquias de CA e solucionem problemas de possíveis erros, de forma fácil e efetiva. Mais
especificamente, o PKIView indica a validade ou acessibilidade dos locais de acesso às
informações de autoridade (AIA) e dos pontos de distribuição de CRL (CDP).

132
Para cada CA selecionado, o PKIView indica o estado de integridade do CA em árvore,

como segue:
Estados de integridade do CA
Indicador Estado do CA
Ponto de Interrogação Avaliação do estado de integridade do CA
Indicador verde CA sem nenhum problema
Indicador amarelo CA com problema não-crítico
Indicador vermelho CA com problema crítico
Cruz vermelha sobre o ícone do CA está offline

CA
Ao adicionar um snap-in do PKIView ao MMC, você vê três painéis:

• Árvore. Este painel exibe uma representação em árvore da sua hierarquia de PKI
corporativo. Cada nó abaixo de Enterprise PKI representa um CA com outros CAs
atuando como nós filhos.
• Resultados. Para o CA selecionado na árvore, este painel exibe uma lista de CAs
subordinados, certificados de CA, pontos de distribuição CRL (CDPs) e locais AIA.
Se a raiz do console for selecionada na árvore, o painel de resultados exibe todos
os CAs da raiz. Há três colunas no painel de resultados:
o Nome. Se o nó Enterprise PKI é selecionado, os nomes dos CAs raiz,
abaixo do primeiro, são exibidos. Se um CA ou um CA filho for
selecionado, então os nomes dos certificados de CA, locais AIA e CDPs são
exibidos.
o Status. Breve descrição do status do CA (também indicado na árvore pelo
ícone associado ao CA selecionado) ou o status dos Certificados de CA,
locais AIA ou CDPs (indicado pelas descrições em texto do status,
exemplos dos quais são OK e Não é possível fazer o Download).
o Local. Os locais AIA e os CDPs (protocolo e caminho) para cada
certificado. Alguns exemplos são file://, HTTP:// e LDAP://.
• Ações. Este painel fornece a mesma funcionalidade encontrada nos menus Ações,
Exibir e Ajuda.
Dependendo do item selecionado tanto na árvore como no painel de resultados, você
pode visualizar mais detalhes sobre os CAs e certificados de CA, incluindo informações de
AIA e CRL no painel de ações. Você também pode gerenciar a estrutura do PKI
corporativo e fazer correções ou alterações nos certificados de CA ou CRLs.
Você pode usar o PKIView em uma rede corporativa que utilize os Serviços de Certificado
do Active Directory e contenha um ou mais CAs, geralmente com mais de uma hierarquia
de PKI.
Os usuários mais avançados de PKIView incluem administradores e profissionais de TI
familiarizados com o monitoramento da integridade do CA e a resolução de problemas no
ambiente de rede dos Serviços de Certificado do Active Directory.
Você pode usar o PKIView apenas no ambiente dos Serviços de Certificado do Active
Directory.
133
O PKIView agora suporta a codificação de caracteres Unicode.
Suporte a Caracteres Unicode

O PKIView fornece suporte completo para caracteres Unicode, juntamente com a
codificação do PrintableString. Usar a codificação de caracteres Unicode permite que você
apresente textos e símbolos de todos os idiomas. A codificação Unicode usa um esquema
de Formato de Transformação Unicode (UTF-8) que atribui dois bytes para cada caractere.
É possível um total de 65.536 combinações. Em contrapartida, a codificação
PrintableString permite que você use apenas um simples sub-conjunto de caracteres
ASCII. Esses caracteres são de A-Z a-z 0-9 (espaço) ' () + , . / : = ?.
Serviços de Certificado do Active Directory: Suporte ao

Protocolo de Status do Certificado Online
Cancelar um certificado é uma parte necessária do processo de gerenciar certificados
emitidos por CAs. Os meios mais comuns de comunicar um status do certificado é
distribuindo CRLs. Nas infra-estruturas de chave pública do Windows Server “Longhorn”,
em que o uso de CRLs convencionais não é a melhor solução, um Online Responder,
baseado no OCSP, pode ser usado para gerenciar e distribuir as informações de status da
revogação.
O uso dos Online Responders que distribuem respostas de OCSP, junto com o uso dos
CRLs, é um dos dois métodos mais comuns para transmitir informações sobre a validade
dos certificados. Diferente dos CRLs, distribuídos periodicamente, com informações sobre
todos os certificados que foram cancelados ou suspensos, um Online Responder recebe e
responde apenas as requisições de clientes que pedem informações sobre o status de um
único certificado. A quantidade de dados recuperados por requisição permanece
constante, independente de quantos certificados cancelados possam haver.
Em muitos casos, os Online Responders podem processar requisições de status do
certificado de forma mais eficiente do que usando listas de revogação de certificado.
• Os clientes se conectam remotamente à rede e não precisam, ou não têm,
conexões de alta velocidade para o download de grandes CRLs.
• Uma rede precisa controlar altos picos de atividade de verificação de revogação,
como quando grande número de usuários efetua login ou envia um e-mail
assinado ao mesmo tempo.
• Uma organização precisa de meios eficientes para distribuir os dados de
revogação para certificados emitidos por um CA que não seja Microsoft.
• Uma organização deseja fornecer apenas os dados de revogação necessários para
verificar as requisições individuais do status do certificado, e não só tornar
disponíveis as informações sobre todos os certificados cancelados ou suspensos.
Este recurso aplica-se a organizações que têm PKIs com um ou mais CAs do Windows.
Adicionar um ou mais Online Responders pode aprimorar, de forma significativa, a
flexibilidade e escalabilidade do PKI de uma organização; portanto, este recurso pode
interessar os arquitetos de PKI, planejadores e administradores.
Para instalar um Online Responder, você deve ser administrador do computador em que
ele está instalado.
Os Online Responders, no Windows Server “Longhorn”, incluem os seguintes recursos.
134
• Caching do proxy da Web. O armazenamento do proxy da Web do Online

Responder é a interface de serviços para o Online Responder. Ele é implementado
como uma extensão ISAPI hospedada pelo IIS.
• Suporte a requisições únicas ou contínuas. As opções de configuração para
requisição única ou contínua podem ser usadas para prevenir ataques freqüentes
de respostas do Online Responder.
• Integração de configuração do Windows. Um Online Responder pode ser
configurado, usando-se a Ferramenta de Gerenciamento de Funções do Windows
Server.
• Suporte avançado à criptografia. Um Online Responder pode ser configurado
para usar uma criptografia de curva elíptica (ECC) e SHA-256 para operações
criptográficas.
• Modelos pré-configurados de certificados de assinatura OCSP. A implantação
de um Online Responder é simplificado pelo uso de um modelo de certificado de
assinatura OCSP, disponível no Windows Server “Longhorn.”
• Integração do protocolo Kerberos. As requisições e respostas do Online
Responder podem ser processadas junto com a autenticação de senha do para
uma validação imediata dos certificados de servidor ao efetuar login.
Os Microsoft Online Responders são baseados no RFC 2560 para OCSP e estão em
conformidade com eles. Por essa razão, as respostas quanto ao status do certificado dos
Online Responders são geralmente referidas como respostas OCSP. Para mais
informações sobre o RFC 2560, visite o site do Internet Engineering Task Force em
Dois novos conjuntos de funcionalidades podem ser originados do serviço Online
Responder:
• Online Responders. A funcionalidade básica do Online Responder fornecida por
um único computador em que seu Serviço está instalado.
• Matrizes do Responder. Diversos computadores ligados que hospedam o Online
Responders e processam as requisições de status do certificado.
Online Responder
Um Online Responder é um computador em que o serviço do Online Responder é
executado. Um computador que hospeda um CA também pode ser configurado como um
Online Responder, mas recomenda-se manter os CAs e os Online Responders em
computadores separados. Um único Online Responder pode fornecer informações de
status de revogação para certificados emitidos por um único CA ou diversos. As
informações de revogação de CA podem ser distribuídas usando mais de um Online
Responder.
As aplicações que dependem de certificados X.509, como S/MIME, SSL, EFS e smart cards
precisam validar o status dos certificados sempre que são usados para realizar
autenticação, assinatura ou criptografia. A verificação de revogação e status do certificado
analisa a validade dos certificados com base em:
• Tempo. Os certificados são emitidos em um período de tempo fixo e considerado
válido, contanto que não se atinja a data de vencimento do certificado e que ele
não seja cancelado antes da data.

135
• Status da revogação. Os certificados podem ser cancelados antes da sua data de

vencimento, por uma série de motivos, como a suspensão ou comprometimento
da chave.
As listas de revogação do certificado contêm os números de série de todos os certificados
emitidos por um CA que tenha sido cancelado. Para um cliente verificar o status de
revogação de um certificado, ele deve fazer o download de um CRL que contenha
informações sobre todos os certificados que tenham sido cancelados pelo CA.
Há duas principais desvantagens nisso: Com o tempo, os CRLs podem se tornar
extremamente grandes, o que pode exigir recursos significativos de rede e
armazenamento para o CA, além da parte componente. Isso pode resultar em
compensações entre uma distribuição mais freqüente de CRLs atualizados e o tempo e
largura de banda da rede para distribuí-los. Se os CRLs forem publicados com menor
freqüência, os clientes deverão contar com informações sobre a revogação menos
precisas.
Já houve inúmeras tentativas de resolver o tamanho do CRL por meio da introdução de
CRLs particionados, CRLs delta e CRLs indiretos. Todas essas abordagens acrescentaram
complexidade e custo ao sistema, sem fornecer uma solução.
Quando você utiliza o Online Responders, em vez de contar com os clientes, eles recebem
todos os dados de revogação do certificado. Uma parte confiável envia uma requisição de
status sobre um certificado individual para um Online Responder, que retorna uma
resposta definitiva e digitalmente assinada, indicando o status apenas do certificado
solicitado. A quantidade de dados recuperados por requisição é constante, independente
de quantos certificados cancelados existam no banco de dados, dentro do CA. Os Online
Responders podem ser instalados em computadores que executam o Windows Server
“Longhorn”. Eles devem ser instalados depois dos CAs, mas antes que os certificados
clientes sejam emitidos. Os dados de revogação do certificado são derivados de um CRL
publicado que pode vir de um CA em um computador que execute o Windows Server
“Longhorn,” um que execute o Windows Server 2003, ou de um CA não-Microsoft.
Antes de configurar um CA para suportar o serviço Online Responder, deve-se apresentar
o seguinte:
• O IIS deve estar instalado no computador, antes que o Online Responder possa
ser instalado. A configuração correta do IIS para o Online Responder é instalada
automaticamente quando você instala um Online Responder.
• Um modelo de certificado de assinatura OCSP deve ser configurado no CA, além
do registro automático usado para emitir um certificado de assinatura OCSP para
o computador em que o Online Responder será instalado.
• A URL do Online Responder deve ser incluída na extensão AIA dos certificados
emitidos pelo CA. Essa URL é usada pelo cliente Online Responder para validar o
status do certificado.
Depois que um Online Responder foi instalado, você também precisa criar uma
configuração de revogação para cada CA e certificado CA atendido por um Online
Responder.
Uma configuração de revogação inclui todas as configurações necessárias para responder
às requisições de status quanto aos certificados que foram emitidos usando uma chave
específica de CA. Essas configurações de configuração incluem o seguinte:

136
• certificado CA. Este certificado pode ser encontrado em um controlador de

domínio, em seu armazenamento local ou importado de um arquivo.
• Assinando um certificado para o Online Responder. Este certificado pode ser
selecionado automaticamente para você, manualmente (que envolve uma
instrução separada de importação depois que você concluir o procedimento
regular de configuração da revogação), ou você pode usar o certificado CA
selecionado.
• Provedor de revogação que irá fornecer os dados de revogação usados por
essa configuração. Essas informações são inseridas na forma de um ou mais
URLs, em que uma base válida e CRLs delta podem ser obtidos.
Importante
Antes de começar a adicionar uma nova configuração de revogação, verifique se
possui essas informações disponíveis.
Matrizes do Responder
Múltiplos Online Responders podem ser ligados a uma Matriz do Online Responder. Os
Online Responders, em uma Matriz, são referidos como membros da Matriz. Um membro
da Matriz pode ser designado o Controlador da Matriz. Embora cada Online Responder
em uma Matriz possa ser configurado de forma independente, no caso de conflitos, as
informações de configuração do Controlador da Matriz irão superar as opções definidas
em outros membros da Matriz.
Uma Matriz de Online Responder pode ser criada e outros Online Responders podem ser
adicionados por uma série de razões, incluindo tolerância a falhas no caso de um Online
Responder individual se tornar indisponível, por considerações geográficas, escalabilidade
ou estrutura da rede.
Por exemplo, as filiais remotas podem não ter conexões consistentes com suas matrizes,
onde o CA está localizado. Portanto, nem sempre é possível contatar o CA ou um Online
Responder remoto para processar uma requisição do status de revogação.
Como os membros de uma Matriz do Online Responder podem ser remotos e estar
sujeitos a condições de rede insatisfatórias, cada membro da matriz pode ser monitorado
e gerenciado de forma independente.
Configurar uma Matriz do Online Responder requer bons conhecimentos de
planejamento baseado em:
• Número e local dos CAs que estão sendo atendidos pela matriz
• Número de clientes que irão solicitar certificados a partir dos CAs e seus locais
• Conectividade de rede entre clientes, CAs e Online Responders potenciais
• Volume de registros de certificado, revogações e requisições de status que a infra-
estrutura da chave pública da organização controla
• Necessidade de redundância no caso de os Online Responders se tornarem
disponíveis
Depois que a Matriz do Online Responder foi planejada, configurar uma Matriz envolve
uma quantidade de procedimentos que devem ser coordenados.
Diretiva de Grupo
137
Diversas configurações da Diretiva de Grupo foram adicionadas para aprimorar o

gerenciamento do OCSP e uso dos dados do CRL. Por exemplo, os CRLs possuem datas de
vencimento, como os certificados, e, se essa data passar antes de uma atualização ser
publicada ou disponibilizada, a validação da cadeia de certificados pode falhar, mesmo
com a presença de um Online Responder. Isso acontece, pois o Online Responder conta
com os dados de uma CRL expirada. Em situações em que as condições de rede podem
atrasar a publicação adequada e o recebimento das CRLs atualizadas, os administradores
podem usar essas configurações da Diretiva de Grupo para estender o tempo de validade
de um CRL existente ou resposta do OCSP.
Você pode estender o período dos CRLs e respostas do OCSP, indo à guia revogação nas
configurações de Validação (Configuração do Computador, Configurações do
Windows, Configurações de Segurança e Diretivas da Chave Pública). Para configurar
essas opções, faça o seguinte:
• Clique em Definir essas configurações de segurança.
• Clique em Permitir que todos os CRLs e respostas do OCSP sejam válidas por
mais tempo.
• Selecione Tempo padrão em que o período de validade pode ser estendido, e
informe o valor desejado de tempo (em horas).
Uma opção separada da guia revogação permite que você sobrescreva as respostas do
OCSP com informações contidas nos CRLs. Assim, um certificado que tenha sido
cancelado, adicionando-o a um CRL local, pode ser verificado como válido, se um cliente
tiver um CRL que não inclua seu status de revogação. Embora esta opção não seja
recomendada, pode ser útil em casos em que as alterações de revogação feitas por um
administrador local não sejam finais até que um administrador de CA verifique a mudança.
Essas configurações estão localizadas em Configuração do Computador, Configurações
do Windows, Configurações de Segurança e Diretivas da Chave Pública.
Importante
As credenciais administrativas são necessárias para modificar as configurações da
Diretiva de Grupo.
Implantação
Como os Online Responders são feitos para atender requisições individuais de status do
certificado, uma Matriz de Online Responder geralmente requer múltiplos Online
Responders, geograficamente dispersos, para equilibrar a carga. Como cada resposta do
status é assinada, cada Online Responder deve ser instalado em um servidor confiável.
Os Online Responders do Windows Server “Longhorn” podem ser instalados nas seguintes
configurações matrizes:
• Online Responder Único para múltiplos CAs. O Online Responder requer uma
chave e um certificado assinado para cada CA suportado. Um Online Responder
deve ser emitido com um certificado assinado a partir do CA emitido. Um Online
Responder não pode fornecer o status de um certificado maior na cadeia do que
um CA que tenha emitido o certificado assinado.
• Online Responders Múltiplos para um Único CA. Cada Online Responder
possui uma chave de assinatura e certificado a partir do CA suportado. Esse
suporte vem por meio de clustering. A lógica do clustering se responsabiliza por
conduzir o cliente a requisições de um Online Responder específico.
138
• Múltiplos Online Responders para múltiplos CAs. Cada Online Responder

possui uma chave de assinatura e certificado a partir do CA suportado.
Você pode se preparar para implantar o Online Responders fazendo o seguinte:
• Avaliar os benefícios potenciais de suplementar CRLs usando Online Responders
para gerenciar a verificação de revogação na sua organização
• Identificar os locais possíveis onde o Online Responders possa ser útil
• Dependendo do número de CAs e locais que você está suportando, o volume de
requisições de validação do certificado que você antecipar e as condições de rede
entre os CAs e os locais, identificar a configuração da instalação a partir de uma
lista precedente que melhor se adapte à sua organização
• Identificar os locais para cada Online Responder e a forma como eles devem ser
gerenciados
• Testar o Online Responder e a configuração do PKI em um ambiente de
laboratório para validar o modelo de PKI e identificar as opções de configuração
para cada Online Responder e configuração de revogação
• Instalar e configurar cada Online Responder

139
5.08 Serviços de Domínio do Active Directory
Os Serviços de Domínio do Active Directory armazena informações sobre usuários,

computadores e outros dispositivos na rede. Os Serviços de Domínio do Active Directory
ajuda os administradores a gerenciar, de forma segura, essas informações e facilita o
compartilhamento de recursos e colaboração entre os usuários. Exige-se também que ele
seja instalado na rede para instalar as aplicações ativadas pelo diretório, como o Microsoft
Exchange Server, e para aplicar outras tecnologias do Windows Server, como a Diretiva de
Grupo.
Os tópicos que seguem descrevem alterações na funcionalidade dos Serviços de Domínio
do Active Directory disponível nesta versão:
• Serviços de Domínio do Active Directory: Auditoria
• Serviços de Domínio do Active Directory: Diretivas de Senha Granuladas
• Serviços de Domínio do Active Directory: Controladores de Domínio de Somente
Leitura
• Serviços de Domínio do Active Directory: Serviços de Domínio do Active Directory
Reinicializáveis
• Serviços de Domínio do Active Directory: Exibição em Telas
• Serviços de Domínio do Active Directory: Melhorias na Interface de Usuário
Serviços de Domínio do Active Directory: Auditoria

No Windows Server “Longhorn,” você agora pode configurar a auditoria dos Serviços de
Domínio do Active Directory por uma nova sub-categoria da diretiva de auditoria
(Alterações no Serviço de Diretório) para registrar valores novos e antigos quando
houver alterações nos objetos dos Serviços de Domínio do Active Directory e seus
atributos.
Nota
Este novo recurso de auditoria também se aplica ao Active Directory Lightweight
Directory Services. No entanto, a discussão refere-se apenas aos Serviços de
Domínio do Active Directory.
A diretiva global de auditoria, Auditoria do acesso ao serviço de diretório, controla se a
auditoria para os eventos do serviço de diretório esta ativada ou não. Essa configuração de
segurança determina se os eventos estão registrados no log de Segurança, quando certas
operações são realizadas em objetos do diretório. Você pode controlar quais operações
auditar, modificando a lista de controle de acesso ao sistema (SACL) em um objeto. No
Windows Server “Longhorn,” esta diretiva está ativada por padrão.
Se você definir a configuração da diretiva (modificando a Diretiva padrão dos
Controladores de Domínio), pode especificar auditar os sucessos, falhas ou então não
auditar nada. As auditorias de sucesso geram uma entrada sempre que um usuário acessa,
com sucesso, um objeto dos Serviços de Domínio do Active Directory que tenha um SACL
especificado. As auditorias de falha geram uma entrada sempre que um usuário acessa,
sem sucesso, um objeto dos Serviços de Domínio do Active Directory que tenha um SACL
especificado.

140
Você pode definir um SACL em um objeto dos Serviços de Domínio do Active Directory na
guia Segurança, na caixa de diálogo de propriedades do objeto. A Auditoria de acesso
ao serviço de diretório é aplicada da mesma forma como na Auditoria de acesso ao
objeto; no entanto, ela se aplica apenas aos objetos dos Serviços de Domínio do Active
Directory e não aos objetos do sistema de arquivo e do registro.
Esse recurso aplica-se aos administradores de Serviços de Domínio do Active Directory,
responsáveis por configurar a auditoria no diretório. Os administradores definem SACLs
apropriados para fazer a auditoria.
Em geral, as permissões para modificar SACLs e visualizar o log de Segurança são
atribuídos apenas a membros dos grupos de Administradores, incluindo de Domínio
Domain, Builtin\Administradores e de Empresa.
O Windows Server “Longhorn” está incluindo a capacidade de a auditoria dos Serviços de
Domínio do Active Directory registrar valores novos e antigos de um atributo quando uma
alteração bem sucedida é feita nele. Antes, a auditoria dos Serviços de Domínio do Active
Directory registrava apenas o nome do atributo que era alterado; e não seus valores
antigos e atuais.
Auditoria de Acesso aos Serviços de Domínio do Active Directory

No Windows 2000 Server e Windows Server 2003, havia uma diretiva de auditoria, o Audit
Directory Service Access, que controlava se a auditoria dos eventos de serviço de diretório
era ativada ou não. No Windows Server “Longhorn,” essa diretiva é dividida em quatro
sub-categorias:
• Directory Service Access
• Directory Service Changes
• Directory Service Replication
• Detailed Directory Service Replication
A capacidade de auditar alterações nos objetos dos Serviços de Domínio do Active
Directory é ativada com a nova sub-categoria de auditoria, o Directory Service Changes.
Os tipos de alterações que você pode auditar são criar, modificar, mover e não excluir
operações feitas em um objeto. Os eventos que são gerados por essas operações
aparecem no log de Segurança.
Essa nova sub-categoria da diretiva adiciona as seguintes capacidades aos Serviços de
Domínio do Active Directory:
• Quando uma operação bem sucedida de modificação é realizada em um atributo
de um objeto, os Serviços de Domínio do Active Directory registra seus valores
novos e atuais. Se o atributo possuir mais de um valor, apenas os valores que
mudam, como resultado da operação de modificação, são registrados.
• Caso um novo objeto seja criado, os valores dos atributos populados no momento
da criação são registrados. Se os atributos são adicionados durante a operação de
criação, esses novos valores são registrados. Na maioria dos casos, os Serviços de
Domínio do Active Directory atribui valores padrões aos atributos (como o
sAMAccountName). Os valores desses atributos do sistema não são registrados.
• Se um objeto é movido dentro de um domínio, o local novo e o anterior (na
forma de nome diferente) é registrado. Quando um objeto é movido para um
domínio diferente, um evento de criação é gerado no controlador de domínio do
domínio alvo.
141
• Se um objeto não é excluído, o local para o qual ele foi movido é registrado. Além
disso, se os atributos forem adicionados, modificados ou excluídos durante uma
operação de não-exclusão, seus valores não serão registrados.
Nota
Caso um objeto seja excluído, não são gerados eventos de auditoria de alteração.
No entanto, um evento de auditoria é gerado caso a sub-categoria do Directory
Service Access seja ativado.
Depois que o Directory Service Changes é ativado, os Serviços de Domínio do Active
Directory registra eventos no log de Segurança, quando são feitas alterações aos objetos
que um administrador configurou para auditoria. A tabela que segue descreve esses
eventos.
Alterações no Directory Service — Eventos dos Serviços de Domínio do Active

Directory
ID do Evento Tipo de Evento Descrição do Evento
5136 Modificar O evento é registrado quando uma

modificação bem sucedida é feita a um
atributo no diretório.
5137 Criar Este evento é registrado quando um novo

objeto é criado no diretório.
5138 Não excluir Este evento é registrado quando um objeto

não é excluído do diretório.
5139 Mover Este evento é registrado quando um objeto é

movido dentro do domínio.
A capacidade de identificar como os atributos do objeto mudam torna os logs de eventos

mais úteis como um mecanismo de acompanhamento a alterações que ocorrem por toda
a duração de um projeto.
No Windows Server “Longhorn,” você implementa um novo recurso de auditoria, usando
os seguintes controles:
• Diretiva de auditoria global
• SACL
• Esquema
Diretiva de auditoria global

Ativar a diretiva de auditoria global, Auditoria do acesso ao serviço de diretório, ativa
todas as sub-categorias da diretiva do serviço de diretório. Você pode definir essa diretiva
global na Diretiva de Grupo dos Controladores de Domínio Padrão (abaixo de
Configurações de Segurança\Diretivas Locais\Diretiva de Auditoria). No Windows Server
“Longhorn,” esta diretiva está ativada por padrão. Portanto, a sub-categoria Directory
Service Changes também está ativada por padrão. Esta sub-categoria está definida
apenas para os eventos de sucesso.
No Windows 2000 Server e Windows Server 2003, a diretiva Auditoria do acesso ao
serviço de diretório era o único controle disponível para o Active Directory. Os eventos
que eram gerados por esse controle não mostravam os valores novos e antigos de
nenhuma modificação. Essa configuração gerava eventos de auditoria no log de
142
Segurança, com o número de ID 566. No Windows Server “Longhorn,” a sub-categoria

Directory Service Access ainda gera os mesmos eventos, mas seu número de ID é
alterado para 4662.
Com a nova sub-categoria Directory Service Changes, alterações bem sucedidas são
registradas junto com os valores novos e antigos do atributo. As configurações para
Directory Service Access e Directory Service Changes estão armazenadas no banco de
dados da Autoridade de Segurança Local (LSA). Elas podem ser consultadas com novos
LSA APIs.
As duas sub-categorias de auditoria são independentes uma da outra. Você pode
desabilitar Directory Service Access e ainda ser capaz de ver eventos de alteração
gerados caso a sub-categoria Directory Service Changes esteja ativada. Da mesma
forma, se você desabilitar Directory Service Changes e ativar Directory Service Access,
pode ver os eventos do log de Segurança com o número de ID 4662.
Você pode usar a ferramenta Auditpol.exe da linha de comando ou definir sub-categorias
da diretiva de auditoria. Não existe uma ferramenta de interface do Windows disponível
no Windows Server “Longhorn” Beta 2 para visualizar ou definir sub-categorias da diretiva
de auditoria.
SACL
O SACL é a parte de um descritor de segurança do objeto que especifica as operações a
serem auditadas para princípio de segurança. O SACL do objeto ainda é a autoridade
principal para determinar se uma verificação de acesso deve ou não ser auditada.
O conteúdo do SACL é controlado pelos administradores de segurança do sistema local.
Os administradores de segurança são usuários atribuídos aos privilégio de Gerenciar Log
de Auditoria e Segurança (SeSecurityPrivilege). Por padrão, esse privilégio é atribuído
ao grupo de Administradores integrado.
Se não houver entrada de controle de acesso (ACE) no SACL que requer o registro das
modificações do atributo, mesmo que a sub-categoria de Directory Service Changes
esteja ativada, nenhum evento de auditoria de alteração é registrado. Por exemplo, se não
houver ACE no SACL que requer acesso à Propriedade de Escrita no atributo do número
de telefone de um objeto de usuário a ser auditado, nenhum evento de auditoria é
gerado quando esse atributo é modificado, mesmo que a sub-categoria Directory Service
Changes esteja ativada.
Esquema
Para evitar a possibilidade de um número excessivo de eventos que estão sendo gerados,
existe um controle adicional no esquema, que pode ser usado para criar exceções ao que
é auditado.
Por exemplo, se você deseja ver alterações a todas as modificações de atributo em um
objeto de usuário — exceto a um ou dois atributos — você pode definir uma indicação no
esquema para atributos que não deseja auditar. A propriedade searchFlags de cada
atributo define se ele é indexado, replicado ao catálogo global ou algum outro tipo de
comportamento. Existem sete bits atualmente definidos para a propriedade searchFlags.
Se o bit 9 (valor 256) for definido para um atributo, os Serviços de Domínio do Active
Directory não registrará eventos de alteração quando as modificações forem feitas. Isso se
aplica a todos os objetos que contêm aquele atributo.

143
Configurações do Registro
Os seguintes valores de chave do registro são usados para configurar a auditoria dos
Serviços de Domínio do Active Directory.
Valores de Chave do Registro — Auditoria dos Serviços de Domínio do Active

Directory
Nome da Configuração Local Valores Possíveis
MaximumStringBytesToAudit HKEY_LOCAL_MACHINE\ • Valor mínimo do registro: 0

System\CurrentControlSet\ • Valor máximo do registro: 64000
Services\NTDS\Parameters • Valor padrão: 1000
5137 Criar Este evento é registrado quando um

novo objeto é criado no diretório.
5138 Não excluir Este evento é registrado quando um

objeto não é excluído do diretório.
5139 Mover Este evento é registrado quando um

objeto é movido dentro do domínio.
Configurações da Diretiva de Grupo

Você não pode visualizar as sub-categorias da diretiva de auditoria com o Editor de
Objeto da Diretiva de Grupo (GPedit.msc). Você pode apenas visualizá-las com a
ferramenta Auditpol.exe de linha de comando. O comando auditpol do exemplo que
segue ativa a sub-categoria Directory Service Changes:
auditpol /set /subcategory:"directory service changes" /success:enable
Serviços de Domínio do Active Directory: Diretivas de Senhas

Detalhadas
O Windows Server “Longhorn” fornece às organizações uma forma de definir diretivas
diferentes de senha e bloqueio de conta para diferentes grupos de usuários em um
domínio. Nos domínios do Windows 2000 e Windows Server 2003 Active Directory,
apenas uma diretiva de senha e bloqueio de conta pode ser aplicada a todos os usuários
no domínio. Essas diretivas foram especificadas na Diretiva de Domínio Padrão do
domínio. Como resultado, as organizações que desejavam configurações diferentes de
senha e bloqueio de conta, para grupos diferentes de usuários, precisavam tanto criar um
filtro para senha como implantar múltiplos domínios. As duas opções têm alto custo, por
diversas razões.
Você pode usar diretivas de senhas granuladas para especificar múltiplas diretivas dentro
de um único domínio. Pode usá-las também para aplicar diferentes restrições a senhas e
diretivas de bloqueio de conta para diferentes grupos de usuários em um domínio.
Por exemplo, você pode aplicar configurações mais rigorosas às contas privilegiadas e
outras menos rigorosas às contas de outros usuários. Em outros casos, você pode aplicar
uma diretiva de senha especial a contas cujas senhas são sincronizadas com outras fontes
de dados.
Os seguintes indivíduos devem verificar essas informações sobre diretivas de senhas
granuladas:

144
• Planejadores e analistas de TI que avaliam tecnicamente o produto

• Planejadores corporativos de TI e designers de organizações
• Administradores ou gerentes responsáveis pela segurança da TI
Essas diretivas aplicam-se apenas a objetos do usuário (ou objetos inetOrgPerson caso
sejam usados no lugar de objetos do usuário) e grupos de segurança global. Por padrão,
apenas membros do grupo de Administradores do Domínio podem definir diretivas de
senhas granuladas. No entanto, você também pode delegar a habilidade de definir essas
diretivas a outros usuários. O nível funcional do domínio deve ser Windows Server
“Longhorn.”
Essas diretivas de senhas granuladas não interferem nos filtros regulares que você deve
usar no mesmo domínio. As organizações que têm filtros de senha implantados em
controladores de domínio que executam o Windows 2000 ou Windows Server 2003
podem continuar usando esses filtros para reforçar restrições adicionais de senhas.
Armazenando Diretivas de Senhas Detalhadas

Para armazenar essas diretivas de senhas detalhadas, o Windows Server “Longhorn” inclui
duas novas classes de objetos no esquema dos Serviços de Domínio do Active Directory:
• Container de Configuração de Senha
• Configurações de Senha
O Container de Configuração de Senha é criado por padrão, abaixo do container
Sistema, no domínio. Ele armazena os objetos de Configuração de Senha (PSOs) para esse
domínio. Você não pode renomear, mover ou excluir esse container.
Um PSO possui atributos para todas as configurações que podem ser definidas na Diretiva
de Domínio Padrão (exceto as configurações Kerberos). Essas configurações incluem
atributos para as seguintes configurações de senha:
• Reforçar o histórico de senha
• Tempo máximo da senha
• Tempo mínimo da senha
• Extensão mínima da senha
• As senhas devem suprir os requisitos de complexidade
• Armazenar senhas usando criptografia reversível
Essas configurações também incluem atributos para as seguintes configurações de
bloqueio de conta:
• Duração do bloqueio da conta
• Limite de bloqueio da conta
• Redefinição de bloqueio da conta após
Além disso, um PSO possui os dois seguintes novos atributos:
• PSO link. Este é um atributo multivalorizado, ligado a usuários e/ou objetos de
grupo.
• Precedência. Este é um valor inteiro usado para resolver conflitos, se muitos PSOs
são aplicados a um usuário ou objeto de grupo.

145
Estes nove atributos são do tipo mustHave. Isso significa que você deve definir um valor a
cada um. As configurações de múltiplos PSOs não podem ser mescladas.
Definindo o Escopo das Diretivas de Senhas Detalhadas

Um PSO pode ser vinculado a um usuário (ou inetOrgPerson) ou objeto de grupo que
esteja no mesmo domínio que o PSO.
• Um PSO possui um atributo chamado PSOAppliesTo que contém um link de
encaminhamento a somente usuário ou objetos do grupo. O atributo
PSOAppliesTo é multivalorizado, o que quer dizer que você pode aplicar um PSO
a múltiplos usuários ou grupos. Você pode criar uma diretiva de senha e aplicá-la
a diferentes conjuntos de usuários ou grupos.
• Um novo atributo chamado PSOApplied foi adicionado ao usuário e objetos de
grupo no Windows Server “Longhorn.” O atributo PSOApplied contém um link de
retorno ao PSO. Como o atributo PSOApplied possui um link de retorno, um
usuário ou grupo pode ter diversos PSOs aplicados a ele. Nesse caso, as
configurações aplicadas são calculadas pelo Conjunto Resultante da Diretiva
(RSOP). Para mais informações, confira o “RSOP”, mais adiante, neste tópico.
Você pode vincular um PSO a outros tipos de grupos, além dos grupos globais de
segurança. Mas quando um conjunto resultante de diretivas é determinado a um usuário
ou grupo, apenas os PSOs vinculados a grupos globais de segurança ou objetos de
usuários são considerados. Os PSOs vinculados a grupos de distribuição ou outros tipos de
grupos de segurança são ignorados.
RSOP
Um usuário ou objeto de grupo pode ter múltiplos PSOs vinculados a ele, tanto porque os
membros, em múltiplos grupos, têm, cada um, PSOs diferentes vinculados a eles, como
porque múltiplos PSOs são aplicados diretamente ao objeto. No entanto, apenas um PSO
pode ser aplicado como diretiva efetiva de senha. Apenas as configurações daquele PSO
podem afetar o usuário ou grupo. As configurações de outros PSOs, que estão ligados ao
usuário ou grupo, não podem ser mescladas de maneira alguma.
O RSOP pode apenas ser calculado para um objeto do usuário. O PSO pode ser aplicado
ao objeto de usuário nas duas maneiras que seguem:
• Diretamente. O PSO é vinculado ao usuário
• Indiretamente. O PSO é vinculado ao grupo(s) do qual o usuário é membro
Cada PSO possui um atributo adicional chamado precedência, que ajuda no cálculo do
RSOP. O atributo precedência possui um valor inteiro de 1 ou mais. Um valor mais baixo
para o atributo precedência indica que o PSO tem uma classificação maior, ou maior
prioridade, do que outros PSOs. Por exemplo, suponha que um objeto tenha dois PSOs
vinculados a ele. Um PSO possui valor de precedência 2 e o outro tenha um valor 4. Neste
caso, o PSO que possui o valor de precedência 2 tem maior classificação e, portanto, é
aplicado ao objeto.
Se múltiplos PSOs são vinculados a um usuário ou grupo, o PSO resultante aplicado é
determinado conforme o seguinte:
• Um PSO que seja vinculado diretamente ao objeto de usuário é o PSO resultante.
Se mais de um PSO for diretamente vinculado ao objeto de usuário, uma
mensagem de aviso será registrada no log de evento, e o PSO com o menor valor
de precedência será o PSO resultante.
146
• Se não houver um PSO vinculado ao objeto de usuário, os membros do grupo

global de segurança do usuário, e todos os PSOs que são aplicáveis ao usuário
com base nos membros do grupo global, são comparados. O PSO com o valor de
precedência mais baixo é o PSO resultante.
• Se nenhum PSO for obtido a partir das condições (1) e (2), A Diretiva de Domínio
Padrão será aplicada.
Recomendamos que você atribua um valor de precedência único para cada PSO que você
criar. No entanto, você pode criar múltiplos PSOs com o mesmo valor. Se múltiplos PSOs
com o mesmo valor de precedência são obtidos para um usuário, o primeiro PSO obtido
será aplicado.
Outro novo atributo chamado ResultantPSO foi adicionado ao objeto de usuário. Um
administrador pode consultar este atributo para recuperar o nome distinto do PSO, que é
aplicado àquele usuário (baseado nas regras listadas anteriormente). Se não houver um
objeto de PSO que se aplique ao usuário, tanto direta quanto virtualmente dos membros
do grupo, a consulta retorna o nome distinto do domínio.
Ao aplicar um PSO que seja diretamente ligado a um usuário ou grupo, antes de outros
PSOs, você pode criar exceções para certos usuários de um grupo. Você pode atribuir um
PSO a um grupo de usuários, mas atribuir uma diretiva diferente a alguns dos membros.
Em vez de ter de criar uma nova diretiva e reorganizar a precedência de todas as diretivas
anteriores para um usuário em particular, você pode criar uma diretiva com qualquer
precedência. Quando você aplica a diretiva diretamente ao usuário, ela é aplicada
primeiro.
O objeto de usuário possui três bits, que podem ser definidos no atributo
userAccountControl do objeto de usuário que pode sobrescrever as configurações
presentes no PSO resultante (muitos desses bits sobrescrevem as configurações da Diretiva
de Domínio Padrão, no Windows 2000 e Windows Server 2003). Esses bits incluem o
seguinte:
• Criptografia de senha reversível exigida
• Senha não exigida
• Senha não expira
Esses bits continuam a superar as configurações no PSO resultante que é aplicado ao
objeto de usuário.
Segurança e Delegação
Por padrão, apenas membros do grupo de Administradores de Domínio podem criar
PSOs. Apenas membros deste grupo possuem as permissões Criar Filho e Excluir Filho, no
objeto Password Settings Container. Além disso, apenas membros do grupo de
Administradores de Domínio têm permissões de Propriedade de Escrita no PSO, por
padrão. Portanto, apenas membros deste grupo podem aplicar um PSO a um grupo ou
usuário. Você pode delegar essa permissão a outros grupos ou usuários.
Você não precisa de permissões sobre o objeto do grupo ou usuário para poder aplicar
um PSO a ele. Ter permissões de Escrita no usuário ou objeto de grupo não fornece a você
a capacidade de vincular um PSO a um usuário ou grupo. O proprietário de um grupo não
possui permissões de vincular um PSO ao grupo, pois o link de encaminhamento está no
PSO. O poder de vincular um PSO ao grupo ou usuário é dado ao proprietário do PSO.

147
As configurações no PSO podem ser consideradas confidenciais; portanto, por padrão, os

Usuários Autenticados não têm permissões de Propriedade de Leitura para um PSO. Por
padrão, apenas membros do grupo de Administradores de Domínio possuem permissões
da Propriedade de Leitura no descritor de segurança padrão do objeto PSO no esquema.
Você pode delegar essas permissões a qualquer grupo (como o help desk ou aplicação de
gerenciamento) no domínio ou floresta. Isso também pode prevenir um usuário de ver
suas configurações de senha no diretório. O usuário pode ler os atributos ResultantPSO
ou PSOApplied, mas eles exibem apenas o nome distinto do PSO que se aplica ao
usuário. O usuário não pode ver as configurações dentro do PSO.
Antes de adicionar um controlador de domínio que execute no Windows Server
“Longhorn” a um domínio existente do Active Directory, você deve executar o adprep
/domainprep. Ao executar o adprep /domainprep, o esquema do Active Directory é
estendido para incluir novas classes de objetos que as diretivas de senhas granuladas
requerem.
Caso você não crie essas diretivas para diferentes grupos de usuários, as configurações da
Diretiva de Domínio Padrão aplicam-se a todos os usuários no domínio, assim como no
Windows 2000 e Windows Server 2003.
Serviços de Domínio do Active Directory: Controladores de

Para saber Domínio de Somente Leitura
mais, recorra à
Um controlador de domínio de somente leitura (RODC) é um novo tipo de controlador no
seção 4.02
sistema operacional do Windows Server “Longhorn”. Com o RODC, as organizações são
Controlador
capazes de implantar, facilmente, um controlador de domínio em locais onde a segurança
de Domínio física não é garantida. Um RODC hospeda partições de somente-leitura dos Serviços de
de Somente Domínio do Active Directory.
Leitura na
página 85. Para mais informações sobre os Controladores de Domínio de Somente Leitura, recorra à
seção 4.02 Controlador de Domínio de Somente Leitura, na página 85.
Serviços de Domínio do Active Directory: Serviços de Domínio

do Active Directory Reinicializáveis
Os administradores podem parar e reiniciar os Serviços de Domínio do Active Directory no
Windows Server “Longhorn”, usando os snap-ins do MMC ou a linha de comando.
Os Serviços de Domínio do Active Directory Reinicializável reduz o tempo requerido para
realizar certas operações. Os Serviços de Domínio do Active Directory pode ser parado
para que as atualizações possam ser aplicadas a um controlador de domínio; e também,
eles podem parar os Serviços de Domínio do Active Directory para realizar tarefas, como a
desfragmentação offline do banco de dados do Active Directory, sem reiniciar o
controlador de domínio. Outros serviços que estão sendo executados no servidor e que
não dependem dos Serviços de Domínio do Active Directory para funcionar, como o
Dynamic Host Configuration Protocol (DHCP), permanecem disponíveis para satisfazer as
requisições de clientes, enquanto os Serviços de Domínio do Active Directory é parado.
Os Serviços de Domínio do Active Directory Reinicializável fornece benefícios para o
seguinte:
• Planejadores e administradores da atualização da segurança
• Equipes de gerenciamento dos Serviços de Domínio do Active Directory

148
• Administradores dos Serviços de Domínio do Active Directory

Os Serviços de Domínio do Active Directory Reinicializável é disponível por padrão em
todos os controladores de domínio que executam o Windows Server “Longhorn.” Não
existem requisitos funcionais, ou outros pré-requisitos, para usar esse recurso.
No Active Directory do sistema operacional Microsoft Windows 2000 Server e Windows
Server 2003, a desfragmentação offline do banco de dados exigia uma reinicialização do
controlador de domínio no Modo de Recuperação do Directory Services. Aplicar as
atualizações de segurança geralmente requer uma reinicialização do controlador de
domínio.
No Windows Server “Longhorn,“ no entanto, os administradores podem parar e reiniciar
os Serviços de Domínio do Active Directory. Isso torna possível desempenhar as operações
offline dos Serviços de Domínio do Active Directory de forma mais rápida.
Os Serviços de Domínio do Active Directory Reinicializável adiciona as menores alterações
aos snap-ins do MMC. Um controlador de domínio que executa o Windows Server
“Longhorn” Active Directory Domain Services exibe o Controlador de Domínio no nó
Serviços (Local) do snap-in Serviços de Componente e do Gerenciamento do
Computador. Usando qualquer um deles, um administrador pode facilmente parar e
reiniciar os Serviços de Domínio do Active Directory da mesma forma como com qualquer
outro serviço que esteja sendo executado localmente no servidor.
Embora parar os Serviços de Domínio do Active Directory seja como efetuar logon no
Modo de Recuperação do Directory Services, o Active Directory Domain Services
reinicializável fornece um estado único para um controlador de domínio que execute o
Windows Server “Longhorn.” Esse estado é conhecido como Active Directory Domain
Services Stopped.
Os três estados possíveis para um controlador de domínio que execute o Windows Server
“Longhorn” são os seguintes:
• Active Directory Domain Services Started. Neste estado, os Serviços de
Domínio do Active Directory é iniciado. Para os clientes e outros serviços
executados no servidor, um controlador de domínio do Windows Server
“Longhorn” executado neste estado é o mesmo que o controlador executado no
Windows 2000 Server ou Windows Server 2003.
• Active Directory Domain Services Stopped. Neste estado, os Serviços de
Domínio do Active Directory é parado. Embora este modo seja exclusivo, o
servidor possui algumas características tanto de controlador de domínio no Modo
de Recuperação do Directory Services quanto como um servidor membro ligado
ao domínio.
Assim como no Modo de Recuperação do Directory Services, o banco de dados
do Active Directory (Ntds.dit) está offline. Além disso, a senha do Modo de
Recuperação do Directory Services pode ser usada para um login local, caso outro
controlador de domínio não possa ser contatado.
Assim como com um servidor membro, o servidor é ligado ao domínio. Além
disso, os usuários podem efetuar logon de forma interativa, ou pela rede, usando
outro controlador de domínio para o logon. No entanto, um controlador de
domínio não deve permanecer neste estado por um longo período de tempo,
pois ele não consegue atender as requisições de logon ou replicar com outros
controladores de domínio.

149
• Modo de Recuperação do Directory Services. Este modo (ou estado) é

inalterável a partir do Windows Server 2003.
O seguinte fluxograma apresenta como um controlador de domínio que executa o
Windows Server “Longhorn” pode fazer a transição entre esses três estados possíveis.
Serviços de Domínio do Active

Directory: Exibição em Instantâneo
A Exibição em Telas dos Serviços de Domínio do
Active Directory é um novo recurso do Windows
Server “Longhorn.” Ele o ajuda a identificar objetos
que foram acidentalmente excluídos ao expor
informações sobre os objetos, em imagens
(instantâneos) dos Serviços de Domínio do Active
Directory obtidas com o tempo. Esses instantâneos
podem ser visualizados em um controlador de
domínio, sem iniciar o controlador de domínio no
Modo de Restauração do Directory Services.
Comparando os diversos estados dos objetos assim
que eles aparecem nos instantâneos, será possível
decidir mais facilmente qual backup dos Serviços de
Domínio do Active Directory utilizar para restaurar os
objetos excluídos.
Ao usar a Exposição de Telas dos Serviços de Domínio do Active Directory, você pode
examinar todas as alterações feitas aos dados armazenados nos Serviços de Domínio do
Active Directory. Por exemplo, se um objeto da Diretiva de Grupo é acidentalmente
modificado, você pode usar a Exposição de Telas dos Serviços de Domínio do Active
Directory para examinar as alterações e ajudar a decidir como corrigi-las, se necessário.
Embora a Exposição de Telas dos Serviços de Domínio do Active Directory não recupere
objetos excluídos, ele ajuda a dinamizar o processo de recuperação de objetos que
tenham sido acidentalmente excluídos. Antes do Windows Server “Longhorn,” quando os
objetos ou unidades organizacionais (OUs) foram acidentalmente excluídas, a única forma
de determinar exatamente quais objetos haviam sido excluídos era restaurando os dados a
partir de backups. Mas isso trazia duas desvantagens:

150
• O Active Directory precisava ser reiniciado no Modo de Recuperação do Directory

Services para desempenhar uma restauração autorizada.
• Um administrador não podia comparar os dados nos backups que eram obtidos
em momentos diferentes (a menos que os backups fossem restaurados a vários
controladores de domínio; um processo que não é viável).
A finalidade do recurso de Exposição de Telas dos Serviços de Domínio do Active
Directory é expor os dados dos Serviços de Domínio do Active Directory armazenados nas
imagens de forma online. Os administradores podem então comparar os dados das
imagens obtidas em diferentes momentos, que, por sua vez, ajudam a decidir sobre os
dados a serem restaurados, sem acabar em uma parada de serviço.
Os seguintes indivíduos devem ver essas informações sobre a Exposição de Telas do
Active Directory Domain Services:
• Planejadores e analistas de TI que avaliam tecnicamente o produto
• Planejadores corporativos de TI e designers de organizações
• Administradores, operadores e gerentes responsáveis pelas operações de TI,
incluindo a recuperação de dados excluídos dos Serviços de Domínio do Active
Directory
Há dois aspectos para o problema de se recuperar dados excluídos:
• Preservar os dados excluídos para que eles possam ser recuperados
• Recuperar os dados excluídos recentemente quando solicitado
A Exposição de Telas dos Serviços de Domínio do Active Directory torna possível para os
dados excluídos dos Serviços de Domínio do Active Directory serem preservados em forma
de imagens dos Serviços de Domínio do Active Directory, obtidas pelo Serviço de Cópia de
Sombra do Volume. A Exposição de Telas dos Serviços de Domínio do Active Directory
Snapshot, na verdade, não recupera objetos e containeres excluídos. O administrador deve
desempenhar a recuperação como um passo subseqüente.
Você pode usar a ferramenta LDAP, como o Ldp.exe, que é uma ferramenta integrada no
Windows Server “Longhorn,” para ver os dados expostos nas imagens. Esses dados são de
somente leitura. Por padrão, apenas os membros dos grupos de Administradores de
Domínio e Corporativos podem visualizar as imagens, pois elas contêm dados sensíveis
dos Serviços de Domínio do Active Directory.
Proteja as imagens dos Serviços de Domínio do Active Directory contra acesso não-
autorizado, assim como você o faz com backups dos Serviços de Domínio do Active
Directory. Um usuário malicioso que tenha acesso às imagens pode usá-las para revelar
dados sensíveis que possam estar armazenados nos Serviços de Domínio do Active
Directory. Por exemplo, um usuário malicioso pode copiar as imagens dos Serviços de
Domínio do Active Directory de uma floresta A para B e depois usar as credenciais de
Administrador do Domínio ou Corporativo da floresta B para examinar os dados. Use a
criptografia ou outras precauções de segurança dos dados com as imagens do Active
Directory Domain Services a fim de ajudar a reduzir a chance de acesso não-autorizado às
imagens dos Serviços de Domínio do Active Directory.
O processo de uso da Exposição de Telas dos Serviços de Domínio do Active Directory
inclui os seguintes passos:

151
1. Programe uma tarefa que regularmente execute o Ntdsutil.exe para obter

imagens do volume que contém o banco de dados dos Serviços de Domínio do
Active Directory.
2. Execute o Ntdsutil.exe para listar as imagens disponíveis e monte a imagem que
deseja visualizar.
3. Execute o Dsamain.exe para expor o volume de imagens como um servidor LDAP.
O Dsamain.exe tem os seguintes argumentos:
• Caminho do banco de dados dos Serviços de Domínio do Active
Directory (NTDS.dit). Por padrão, esse caminho é aberto somente
como leitura, mas ele deve estar em ASCII.
• Caminho do Log. Esse pode ser um caminho temporário, mas você
deve ter acesso de escrita.
• Quatro números de portas para LDAP, LDAP-SSL, Global Catalog e
Global Catalog–SSL.
Você pode parar o Dsamain, pressionando CTRL+C ou definindo o atributo
stopservice no objeto rootDSE.
4. Execute e anexe o Ldp.exe à porta LDAP da imagem que você especificou quando
expôs a imagem como um servidor LDAP, no passo anterior.
5. Navegue pela imagem como faria com qualquer controlador de domínio
dinâmico.
Caso você tenha idéia de qual OU ou objetos foram excluídos, pode procurar nos objetos
excluídos, nas imagens, e gravar os atributos e links de retorno que pertenciam aos
objetos excluídos. Reanime esses objetos, usando o recurso de reanimação em ícones.
Depois, alimente manualmente esses objetos com os atributos e links de retorno, assim
que identificados nas imagens.
No entanto, você não pode realimentar os atributos apenas do sistema, que foram
divididos quando os objetos foram excluídos. Embora você deva recriar manualmente os
atributos e links de retorno, o navegador de imagens torna possível recriar os objetos
excluídos e seus links sem precisar reiniciar o controlador de domínio no Modo de
Recuperação do Directory Services. Além disso, você pode usar o navegador de imagens
para analisar configurações anteriores dos Serviços de Domínio do Active Directory,
incluindo as permissões e a Diretiva de Grupo.
Serviços de Domínio do Active Directory: Melhorias na Interface

de Usuário
Para aprimorar a instalação e o gerenciamento dos Serviços de Domínio do Active
Directory, o Windows Server “Longhorn” inclui um Assistente de Instalação atualizado para
o Active Directory Domain Services. O Windows Server “Longhorn” também inclui
alterações nas funções de snap-in do MMC que gerenciam os Serviços de Domínio do
Active Directory.
As melhorias na UI dos Serviços de Domínio do Active Directory fornecem novas opções
de instalação para os controladores de domínio. Além disso, o Assistente de Instalação
atualizado dinamiza e simplifica a instalação dos Serviços de Domínio do Active Directory.

152
As melhorias na UI dos Serviços de Domínio do Active Directory também fornecem novas

opções de gerenciamento para os recursos dos Serviços de Domínio do Active Directory,
como os controladores de domínio de somente leitura (RODCs). Alterações adicionais às
ferramentas de gerenciamento fornecem a capacidade de encontrar os controladores de
domínio por toda a empresa. Eles também fornecem controles importantes para novos
recursos, como a Diretiva de Replicação de Senha para RODCs.
As melhorias da UI dos Serviços de Domínio do Active Directory são importantes para os
seguintes usuários:
• Administradores dos Serviços de Domínio do Active Directory responsáveis por
gerenciar controladores de domínio em locais centrais e data centers
• Administradores de filiais
• Desenvolvedores de sistema que realizam instalações e desautorizam servidores
As melhorias na UI dos Serviços de Domínio do Active Directory não requerem
considerações especiais. As melhorias ao Assistente de Instalação também estão todas
disponíveis por padrão. No entanto, algumas páginas do assistente aparecem apenas se a
caixa de verificação de Usar instalação no modo avançado estiver selecionada na página
de Boas Vindas do assistente.
O modo de instalação avançado fornece aos usuários mais experientes um controle maior
sobre o processo de instalação, sem confundir os usuários mais novos quanto às opções
de configuração que podem não ser familiares. Para os usuários que não selecionam a
caixa Usar instalação no modo avançado, o assistente utiliza opções padrões que se
aplicam à maior parte das configurações.
As melhorias na UI dos Serviços de Domínio do Active Directory fornecem novas
funcionalidades para o Assistente de Instalação dos Serviços de Domínio do Active
Directory e funções de snap-in do MMC.
Novo Assistente de Instalação dos Serviços de Domínio do Active

Directory
Para adicionar a função de servidor dos Serviços de Domínio do Active Directory de forma
interativa, você pode acessar o Assistente de Instalação nas seguintes maneiras:
• Você pode clicar em Adicionar Funções, nas Tarefas Iniciais de Configuração,
que aparece quando você instala o sistema pela primeira vez.
• Você pode clicar em Adicionar Funções no Gerenciador do Servidor. O
Gerenciador do Servidor está disponível no menu Ferramentas Administrativas,
ou por meio de um ícone na área de notificação.
• Você pode clicar em Iniciar, clicar em Executar e depois digitar dcpromo. Uma
alternativa é digitar dcpromo no prompt de comando, como nas versões
anteriores do sistema operacional do Microsoft Windows Server.
Nota
Embora não seja uma melhoria de UI, novas opções para executar instalações
falhas dos Serviços de Domínio do Active Directory estão disponíveis no Windows
Server “Longhorn.” Diferente de uma instalação falha no Windows Server 2003,
uma instalação falha no Windows Server “Longhorn” nunca requer uma resposta a
um prompt da UI, como aquele que reinicia o controlador de domínio. Isso é
necessário para instalar os Serviços de Domínio do Active Directory no Núcleo do

153
Servidor do Windows Server “Longhorn,” uma nova opção de instalação do

Windows Server “Longhorn” que não fornece opções de UI, como um Assistente
de Instalação interativo dos Serviços de Domínio do Active Directory.
• Você pode iniciar uma instalação RODC, usando o snap-in do MMC Active
Directory Users and Computers. Você pode tanto clicar com o botão direito em
Controladores de Domínio como clicar em Controladores de Domínio e
depois em Pré-criar uma conta Somente-leitura de Controlador de Domínio.
Este método instala o RODC em dois estágios. Durante o estágio seguinte da
instalação, você executa o Assistente dos Serviços de Domínio do Active Directory
no servidor que deseja anexar à conta do RODC.
O Assistente de Instalação dos Serviços de Domínio do Active Directory contém uma nova
opção na página de Boas Vindas para ativar o modo avançado como uma alternativa
para executar o Dcpromo com a chave /adv (por exemplo, o dcpromo /adv). O modo
avançado exibe opções adicionais que permitem configurações mais avançadas e
fornecem aos usuários mais experientes um controle maior sobre a operação. As opções
adicionais do modo avançado incluem o seguinte:
• Criar uma nova árvore de domínio
• Usar uma mídia de backup a partir de um controlador de domínio existente no
mesmo domínio, a fim de reduzir o tráfego de rede que está associado com a
replicação inicial
• Selecionar o controlador de domínio de origem para a instalação
• Modificar o nome do NetBIOS que o assistente gera por padrão
• Definir a diretiva de replicação de senha para um RODC
Além dessas alterações, o Assistente de Instalação dos Serviços de Domínio do Active
Directory possui novas páginas, que são descritas na tabela que segue.
Assistente de Instalação dos Serviços de Domínio do Active Directory

Nova Página do Assistente Descrição
Opções Adicionais Especifica que, durante a instalação do controlador de domínio,

ele também será configurado para ser um DNS server, servidor do
catálogo global ou RODC.
Seleção de local Especifica o local onde o controlador de domínio deve ser

instalado.
Definição de níveis de função Define o domínio e o nível funcional da floresta durante a

instalação do novo domínio ou floresta.
Diretiva de Replicação de Senha Especifica quais senhas de contas são permitidas ou negadas de
serem armazenadas no RODC. Essa página aparece apenas
quando a caixa Usar instalação no modo avançado está
selecionada.
Criação de delegação do DNS Fornece uma opção padrão para criar uma delegação DNS no
tipo de instalação do controlador de domínio (conforme
especificado na página Escolha uma Configuração de
Implantação) e o ambiente DNS.
Outras melhorias reduzem as chances de erro durante a instalação dos Serviços de

Domínio do Active Directory. Por exemplo, se você está instalando um controlador de

154
domínio adicional, pode selecionar o nome do domínio a partir de uma árvore de

domínio, em vez de digitá-la.
Para assegurar que um DNS server recém-instalado esteja operando corretamente, o DNS
é automaticamente configurado para as configurações do cliente DNS, encaminhadores e
dicas de raiz, se necessário, com base nas opções de instalação que são selecionadas.
Instalação em Fases para o RODCs

Você pode realizar uma instalação em fases de um RODC, em que a instalação é concluída
em duas fases, por diferentes pessoas. Você pode usar o Assistente de Instalação dos
Serviços de Domínio do Active Directory para concluir cada fase da instalação.
A primeira fase cria uma conta para o RODC nos Serviços de Domínio do Active Directory.
A segunda fase anexa o servidor atual, que será o RODC, à conta que foi anteriormente
criada para isso.
Durante a primeira fase, o assistente grava todos os dados sobre o RODC que serão
armazenados no banco de dados distribuído do Active Directory, assim como seu nome
da conta do controlador de domínio e o local em que serão colocados. Essa fase deve ser
realizada por um membro do grupo de Administradores de Domínio.
O usuário que cria a conta RODC também pode especificar, naquele momento, quais
usuários ou grupos podem concluir o próximo passo da instalação. A próxima fase pode
ser realizada na filial, por qualquer usuário ou grupo a quem tenha sido delegado o
direito de concluir a instalação quando a conta foi criada. A fase não requer membros nos
grupos integrados, como o grupo de Administradores do Domínio. Se o usuário que cria a
conta RODC não especificar qualquer delegação para concluir a instalação (e administrar o
RODC), apenas um membro dos Administradores de Domínio ou Corporativo pode
concluir a instalação.
A segunda fase instala os Serviços de Domínio do Active Directory no servidor que se
tornará o RODC. Essa fase ocorre, basicamente, na filial onde o RODC é implantado.
Durante essa fase, todos os dados dos Serviços de Domínio do Active Directory que
residem localmente, arquivos de log e etc, são criados no próprio RODC. Os arquivos de
origem da instalação podem ser replicados para o RODC a partir de um controlador de
domínio sobre a rede, ou então você pode usar a instalação do recurso de mídia (IFM).
Para usar o IFM, use o Ntdsutil.exe para criar a mídia de instalação.
O servidor que se tornará o RODC não deve ser ligado ao domínio antes de você tentar
anexá-lo à conta do RODC. Como parte da instalação, o assistente detecta,
automaticamente, se o nome do servidor associa-se aos nomes de qualquer conta do
RODC que tenha sido criada antes para o domínio. Quando o assistente encontra um
nome associado da conta, ele alerta o usuário para usar aquela conta para concluir a
instalação do RODC.
Melhorias Adicionais no Assistente

O novo Assistente de Instalação dos Serviços de Domínio do Active Directory também
inclui as seguintes melhorias:
• Por padrão, o assistente agora utiliza as credenciais do usuário que está
conectado no momento. Você é alertado sobre as credenciais adicionais, caso elas
sejam necessárias.
• Ao criar um controlador de domínio adicional em um domínio filho, o assistente
detecta se o papel principal da infra-estrutura está hospedado em um servidor de
155
catálogo global naquele domínio, alertando-o para transferir essa infra-estrutura

para o controlador de domínio que você está criando. Isso ajuda a prevenir uma
má colocação do papel principal da infra-estrutura.
• Na página Sumário do assistente, você pode exportar as configurações que
selecionou para um arquivo de respostas correspondente que pode usar para
operações subseqüentes (instalações ou desinstalações).
• Você agora pode omitir a senha do seu administrador a partir do arquivo de
respostas. Em vez disso, digite senha=* no arquivo de respostas, para garantir que
o usuário está avisado sobre as credenciais da conta.
• Você pode pré-alimentar o assistente, especificando alguns parâmetros na linha
de comando, reduzindo a quantidade de interação de usuário que é exigida com
o assistente.
• Você agora pode forçar o rebaixamento de um controlador de domínio iniciado
no Modo de Recuperação do Directory Services).
Novas Funções de Snap-In do MMC

O snap-in do Active Directory Sites and Services no Windows Server “Longhorn” inclui um
comando Localizar, na barra de ferramentas e no menu Ação. Esse comando facilita
encontrar o local onde o controlador de domínio está, o que pode ajudar na solução de
problemas de replicações. Antes, o Active Directory Sites and Services não indicavam
facilmente onde certo controlador de domínio estava localizado. Isso aumentava o tempo
requerido para solucionar problemas, como os de replicação.
Para ajudar a gerenciar os RODCs, agora existe uma guia de Diretiva de Replicação de
Senha na página de Propriedades do controlador de domínio. Clicando no botão
Avançado, nesta guia,um administrador pode ver o seguinte:
• Quais senhas foram enviadas ao RODC
• Quais senhas estão atualmente armazenadas no RODC
• Quais contas foram autenticadas para o RODC, incluindo contas não definidas
nos grupos de segurança, que têm a replicação permitida ou negada. Como
resultado, o administrador pode ver quem está usando o RODC e determinar se
permite ou nega a replicação da senha.

156
5.09 Serviços Federados do Active Directory
Os Serviços Federados do Active Directory é uma função de servidor no Windows Server

"Longhorn" que pode ser utilizado para criar uma solução de acesso de identidade segura
e escalonável com a Internet, altamente extensível que opere por diversas plataformas,
incluindo ambientes Windows e não-Windows. As seções que seguem fornecem
informações sobre os Serviços Federados do Active Directory no Windows Server
“Longhorn,” incluindo informações sobre as funcionalidades adicionais dos Serviços
Federados do Active Directory no Windows Server “Longhorn” comparadas com a versão
dos Serviços Federados do Active Directory no Windows Server 2003 R2.
Os Serviços Federados do Active Directory é uma solução de acesso à identidade que
fornece aos clientes baseados em navegadores (internos ou externos à rede) um acesso
dinâmico e único a aplicações mais protegidas quanto à Internet, mesmo quando as
contas e aplicações estão localizadas em redes completamente diferentes ou
organizações.
Quando uma aplicação está em uma rede e as contas de usuário em outra rede, é
importante que os usuários estejam avisados sobre as credenciais secundárias quando
tentarem acessar a aplicação. Essas credenciais secundárias representam a identidade dos
usuários no local em que a aplicação reside. O Web server que hospeda a aplicação
geralmente requer essas credenciais para que possa tomar a decisão mais apropriada.
Os Serviços Federados do Active Directory torna as contas secundárias desnecessárias,
fornecendo relações de confiança que você pode usar para projetar uma identidade
digital do usuário e acessar direitos dos parceiros confiáveis. Em um ambiente federado,
cada organização continua a gerenciar suas próprias identidades, mas cada uma pode
projetar de forma mais segura e aceitar identidades de outras organizações.
Além disso, você pode implantar os servidores de federação em múltiplas organizações,
para facilitar as transações de business-to-business (B2B) entre as organizações de
parceiros confiáveis. As parcerias federadas de B2B identificam os parceiros de negócios
como um dos seguintes tipos de organização:
• Organização de Recursos As organizações que possuem e gerenciam recursos
acessíveis a partir da Internet podem implantar os servidores de federação dos
Serviços Federados do Active Directory e os servidores da Web baseados nos
Serviços Federados do Active Directory que gerenciam o acesso aos recursos
protegidos de parceiros confiáveis. Esses parceiros podem incluir partes internas e
externas ou outros departamentos ou subsidiárias na mesma organização.
• Organização da Conta As organizações que possuem e gerenciam as contas de
usuário podem implantar os Serviços Federados do Active Directory que
autenticam usuários locais e criam tokens que, mais adiante, são usados na
organização de recurso para tomar decisões quanto à autorização.
O processo de autenticação de uma rede enquanto se acessam recursos em outra rede —
sem o incômodo de ações repetidas de login pelos usuários — é conhecido como longo
único (SSO). Os Serviços Federados do Active Directory fornece uma solução baseada na
Web, de SSO, que autentica os usuários em múltiplas aplicações da Web pela duração de
uma simples sessão de navegação.

157
Os Serviços Federados do Active Directory é designado para ser implantado em

organizações de médio a grande porte, que possuem o seguinte:
• No mínimo, um serviço de diretório: tanto o Active Directory Domain Services ou
Active Directory Lightweight Directory Services (antes conhecido como Active
Directory Application Mode)
• Computadores executados em diversas plataformas de sistemas operacionais
• Computadores ligados a um domínio
• Computadores conectados à Internet
• Uma ou mais aplicações baseadas na Web
Veja essas informações, juntamente com a documentação adicional sobre os Serviços
Federados do Active Directory, se você faz parte de um dos seguintes grupos:
• Profissional de TI responsável pelo suporte de uma infra-estrutura existente dos
Serviços Federados do Active Directory
• Planejador de TI, analista ou arquiteto em fase de avaliação dos produtos de
federação da identidade
Se você tem uma infra-estrutura existente dos Serviços Federados do Active Directory,
existem algumas considerações especiais a saber antes de você começar a atualizar os
servidores de federação, proxies e servidores da Web ativados pelos Serviços Federados do
Active Directory que executam o Windows Server 2003 R2 para o Windows Server
“Longhorn.” Essas considerações aplicam-se apenas quando você tem servidores dos
Serviços Federados do Active Directory que tenham sido manualmente configurados para
usar contas exclusivas do serviço.
Os Serviços Federados do Active Directory usa a conta do Network Service como padrão
para os Serviços Federados do Active Directory Web Agent Authentication Service e a
identidade do pool de aplicação do ADFSAppPool. Se você configurou manualmente um
ou mais servidores dos Serviços Federados do Active Directory em sua implantação
existente dos Serviços Federados do Active Directory para usar uma conta de serviço que
não seja a conta padrão do Network Service, verifique qual dos servidores dos Serviços
Federados do Active Directory utiliza essas contas de serviço e grave o nome de usuário e
a senha de cada conta.
Quando você atualiza um servidor para o Windows Server “Longhorn,” o processo
recupera, automaticamente, todas as contas de serviço para seus valores padrões originais.
Portanto, você deve fornecer as informações da conta do serviço novamente,
manualmente, para cada servidor aplicável depois que o Windows Server “Longhorn” está
completamente instalado.
Para o Windows Server “Longhorn,” os Serviços Federados do Active Directory inclui novas
funcionalidades que não estão disponíveis no Windows Server 2003 R2. Essas novas
funcionalidades são feitas para facilitar a sobrecarga administrativa e para estender ainda
mais o suporte às principais aplicações:
• Instalação Aprimorada. Os Serviços Federados do Active Directory está incluído
no Windows Server “Longhorn” como uma função de servidor, havendo ainda
novas verificações de validação do servidor no assistente de instalação.

158
• Suporte aprimorado da aplicação. Os Serviços Federados do Active Directory é

mais integrado com o Microsoft Office SharePoint Services 2007 e os Serviços de
Gerenciamento de Direitos do Active Directory.
• Melhor experiência administrativa ao estabelecer relação de confiança
federada. A funcionalidade aprimorada de importar e exportar uma diretiva de
relação de confiança ajuda a minimizar os problemas de configuração baseados
nos parceiros, geralmente associados com o estabelecimento de uma relação de
confiança federada.
Instalação Aprimorada.
Os Serviços Federados do Active Directory no Windows Server “Longhorn” traz diversas
melhorias à experiência de instalação. Para instalar os Serviços Federados do Active
Directory no Windows Server 2003 R2, você deve ir até Adicionar/Remover Programas
para encontrar e instalar o componente dos Serviços Federados do Active Directory. No
entanto, no Windows Server “Longhorn,” você pode instalar os Serviços Federados do
Active Directory como uma função de servidor que utiliza o Server Manager.
Você pode usar o assistente de configuração aprimorado dos Serviços Federados do
Active Directory para realizar as verificações de validação do servidor antes de continuar
com a instalação dos Serviços Federados do Active Directory. Além disso, o Server
Manager automaticamente lista e instala todos os serviços dos quais os Serviços Federados
do Active Directory depende durante a instalação dos Serviços Federados do Active
Directory. Esses serviços incluem o Microsoft ASP.NET 2.0 e outros serviços que fazem
parte da função de servidor do Web Server (IIS).
Suporte Aprimorado da Aplicação.

Os Serviços Federados do Active Directory no Windows Server “Longhorn” inclui melhorias
que aumentam a capacidade de integração com outras aplicações, como o Office
SharePoint Services 2007 e os Serviços de Gerenciamento de Direitos do Active Directory.
Integração com o Office SharePoint Services 2007
O Office SharePoint® Services 2007 tira o máximo proveito das capacidades do SSO que
são integradas nesta versão dos Serviços Federados do Active Directory. Os Serviços
Federados do Active Directory no Windows Server “Longhorn” inclui funcionalidades para
suportar os membros do Office SharePoint Services 2007 e os provedores de funções. Isso
significa que você pode, de forma efetiva, configurar o Office SharePoint Services 2007
como uma aplicação consciente dos Serviços Federados do Active Directory, podendo
ainda administrar quaisquer sites do Office SharePoint Services 2007, usando os membros
e controle de acesso baseado em função. Os membros e os provedores de funções
incluídos nesta versão dos Serviços Federados do Active Directory servem para consumo
apenas pelo Office SharePoint Services 2007.
Integração com o Active Directory Rights Management Server
Os Serviços de Gerenciamento de Direitos do Active Directory e os Serviços Federados do
Active Directory podem ser integrados de forma que as organizações possam obter
vantagens das relações confiáveis federadas existentes, a fim de colaborar com parceiros
externos e compartilhar conteúdos protegidos pelos direitos. Por exemplo, uma
organização que tenha implantado os Serviços de Gerenciamento de Direitos do Active

159
Directory pode configurar uma federação com uma organização externa, usando os
Serviços Federados do Active Directory. A organização pode então usar essa relação para
compartilhar conteúdo protegido por meio de duas organizações, sem exigir uma
implantação dos Serviços de Gerenciamento de Direitos do Active Directory nas duas
organizações.
Melhor Experiência Administrativa ao Estabelecer Relações de Confiança

Federadas
Tanto no Windows Server 2003 R2 como no Windows Server “Longhorn,“ os
administradores dos Serviços Federados do Active Directory podem criar uma relação de
confiança federada entre duas organizações, usando tanto um processo de importar e
exportar arquivos de diretivas como um processo manual que envolva uma troca mútua
entre os valores dos parceiros, como o Uniform Resource Indicators (URIs), tipos de
declaração, mapeamento de declaração, exibição de nomes etc. O processo manual
requer que o administrador, que recebe esses dados, digite todos os dados recebidos nas
páginas apropriadas do Assistente para Adicionar Parceiro, o que pode resultar em erros
tipográficos. Além disso, o processo manual exige que o administrador parceiro da conta
envie uma cópia do certificado de verificação para o servidor de federação, a fim de que o
certificado possa ser adicionado pelo assistente.
Embora a capacidade de importar e exportar arquivos da diretiva fosse disponível no
Windows Server 2003 R2, criar relações de confiança federadas entre as organizações dos
parceiros é mais fácil no Windows Server “Longhorn”, como um resultado da
funcionalidade de importar e exportar baseada na diretiva. Essas melhorias foram feitas
para aprimorar a experiência administrativa, permitindo mais flexibilidade para a
funcionalidade de importação no Assistente para Adicionar Parceiro. Por exemplo, quando
uma diretiva de parceiro é importada, o administrador pode usar esse Assistente para
modificar todos os valores que foram importados antes de o processo do assistente ser
concluído. Isso inclui a capacidade de especificar um certificado diferente de verificação
da conta do parceiro e a de mapear as declarações de entrada e saída entre os parceiros.
Usando os recursos de importar e exportar, incluídos nos Serviços Federados do Active
Directory no Windows Server “Longhorn,” os administradores podem apenas exportar suas
configurações da diretiva de relação de confiança para um arquivo .xml e então enviar o
arquivo ao administrador parceiro. Essa troca de arquivos de diretiva de parceiros fornece
todas as URIs, tipos de declaração, mapeamentos de declaração e outros valores e
certificados de verificação necessários para criar uma relação de confiança federada entre
duas organizações parceiras.
A ilustração que segue e as instruções que acompanham mostram como uma troca bem
sucedida de diretivas entre os parceiros — neste caso, iniciada pelo administrador da
organização parceira da conta — pode ajudar a dinamizar o processo de estabelecer uma
relação de confiança federada entre duas organizações fictícias: A. Datum Corp. e Trey
Research.
O seguinte fluxograma apresenta como um controlador de domínio que executa o
Windows Server “Longhorn” pode fazer a transição entre esses três estados possíveis.

160
1. O administrador parceiro da conta especifica a opção Exportar Diretiva Parceira

Básica, clicando com o botão direito na pasta Diretiva Confiável, e exporta um
arquivo de diretiva parceira que contém a URL, o nome de exibição, a URL do
proxy do servidor da federação e o certificado de verificação da A. Datum Corp. O
administrador parceiro da conta então envia o arquivo da diretiva parceira (por e-
mail ou outros meios) ao administrador parceiro do recurso.
2. Esse administrador cria um novo parceiro de conta usando o Assistente para
Adicionar Parceiro de Conta e seleciona a opção para importar um arquivo de

161
diretiva parceira da conta. O administrador parceiro do recurso continua a

especificar o local e o arquivo de diretiva parceira e a verificar se todos os valores
apresentados em cada página do assistente — que são pré-alimentados como
resultado da importação da diretiva — são precisos. O administrador então
conclui o assistente.
3. O administrador parceiro do recurso agora pode configurar declarações adicionais
ou configurações da diretiva de relação de confiança para aquele parceiro da
conta. Após concluir essa configuração,o administrador especifica a opção
Exportar Diretiva, clicando com o botão direito no parceiro de conta de A.
Datum Corp. O administrador parceiro do recurso exporta um arquivo da diretiva
do parceiro que contém valores, como a URL, a URL do proxy do servidor de
federação, o nome de exibição, tipos de declaração e mapeamentos de
declaração para a organização Trey Research. O administrador parceiro do recurso
então envia o arquivo da diretiva parceira ao administrador parceiro da conta.
4. Esse administrador cria um novo parceiro de recurso usando o Assistente para
Adicionar Parceiro de Conta e seleciona a opção para importar um arquivo de
diretiva parceira do recurso. O administrador parceiro da conta continua a
especificar o local e o arquivo de diretiva parceira do recurso e a verificar se todos
os valores apresentados em cada página do assistente — que são pré-alimentados
como resultado da importação da diretiva — são precisos. O administrador então
conclui o assistente.
Quando este processo está concluído, uma relação de confiança bem sucedida da
federação entre os parceiros é estabelecida. Os administradores parceiros de recursos
também podem iniciar um processo de diretiva para importar e exportar, embora o
processo não seja descrito aqui.
Novas Configurações
Você configura as configurações do Web Agent baseado no token do Windows NT com o
snap-in do IIS Manager. Para suportar as novas funcionalidades fornecidas com o IIS 7.0,
os Serviços Federados do Active Directory do Windows Server “Longhorn” inclui
atualizações na UI para o serviço de função do Web Agent dos Serviços Federados do
Active Directory. A tabela que segue lista os diferentes locais no IIS Manager para o IIS 6.0
ou IIS 7.0 para cada uma das páginas de propriedades do Web Agent do Active Directory
Federation, dependendo da versão do IIS que está sendo usada.
Páginas de Propriedades do Web Agent dos Serviços Federados do Active

Directory
Página de Local Antigo IIS 7.0 Novo Local
Propriedades do IIS Propriedade
6.0
Página
Guia de Serviços <COMPUTERNAME>\Web URL do Federation <COMPUTERNAME> (na seção

Federados do Active Sites Service Outros do painel central)
Directory Web Agent
Guia de Serviços <COMPUTERNAME>\Web Web Agent dos Serviços <COMPUTERNAME>\Web

Federados do Active Sites\<Site ou Virtual Federados do Active Sites\<Site ou Virtual Directory>
Directory Web Agent Directory> Directory (na seção IIS\Authentication do
painel centra)

162
Nota
Não existem diferenças significativas de UI entre o snap-in dos Serviços Federados
do Active Directory no Windows Server “Longhorn” e o dos Serviços Federados do
Active Directory no Windows Server 2003 R2.

163
5.10 Active Directory Lightweight Directory Services
A função do servidor do Active Directory Lightweight Directory Services é um serviço de

diretório do LDAP. Ele fornece armazenamento e recuperação de dados para as aplicações
ativadas pelo diretório, sem as dependências requeridas para os Serviços de Domínio do
Active Directory.
O Active Directory Lightweight Directory Services no Windows Server “Longhorn” abrange
as funcionalidades fornecidas pelo Modo de Aplicação do Active Directory, que estão
disponíveis no Microsoft Windows XP Professional e Windows Server 2003.
O Active Directory Lightweight Directory Services fornece às organizações um suporte
flexível às aplicações ativadas pelo diretório. Uma aplicação ativada pelo diretório usa um
diretório — em vez de um banco de dados, arquivo ou outra estrutura para armazenar
dados — para manter seus dados. Os serviços de diretório (como o Active Directory
Lightweight Directory Services) e os bancos de dados relacionais fornecem o
armazenamento e recuperação dos dados, mas eles diferem na otimização. Os serviços de
diretório são otimizados para o processamento da leitura, enquanto os bancos de dados
relacionais são para o processamento de transação. Muitas aplicações personalizadas e
outras regulares utilizam um design ativado para diretório. Enter esses exemplos estão:
• Aplicações de gerenciamento da relação com clientes (CRM)
• Aplicações de recursos humanos (HR)
• Aplicações de catálogo de endereços global
O Active Directory Lightweight Directory Services fornece muitas das mesmas
funcionalidades dos Serviços de Domínio do Active Directory (e, na verdade, ambos são
construídos sob a mesma base de código), mas ele não requer a implantação de domínios
ou controladores de domínio.
Você pode executar múltiplas instâncias do Active Directory Lightweight Directory Services
ao mesmo tempo em um único computador, com um esquema independentemente
gerenciado para cada instância ou configuração do Active Directory Lightweight Directory
Services (caso a instância faça parte do conjunto de configurações). Os servidores
membros, controladores de domínio e servidores autônomos podem ser configurados
para executar o Active Directory Lightweight Directory Services.
O Active Directory Lightweight Directory Services é semelhante aos Serviços de Domínio
do Active Directory ao fornecer o seguinte:
• Replicação Multimaster
• Suporte à API de Interfaces do Active Directory Service
• Partições do diretório da aplicação
• LDAP sobre o SSL
O Active Directory Lightweight Directory Services se difere dos Serviços de Domínio do
Active Directory principalmente no que se refere a não armazenar os princípios de
segurança do Windows. Embora o Active Directory Lightweight Directory Services possa
usar os princípios de segurança do Windows (como os usuários do domínio) nos ACLs que
controlam o acesso aos objetos no Active Directory Lightweight Directory Services, o
Windows não pode autenticar os usuários armazenados no Active Directory Lightweight
164
Directory Services ou utilizar os usuários do Active Directory Lightweight Directory Services

em seus ACLs. Além disso, o Active Directory Lightweight Directory Services não suporta
domínios e florestas, Diretiva de Grupo ou catálogos globais.
As organizações que têm os seguintes requisitos irão considerar o Active Directory
Lightweight Directory Services particularmente útil:
• Diretórios específicos da aplicação que usam esquemas personalizados ou que
dependem de um gerenciamento descentralizado de diretório
Diretórios do Active Directory Lightweight Directory Services que sejam separados
da infra-estrutura de domínio dos Serviços de Domínio do Active Directory. Como
resultado, eles podem suportar aplicações que dependam das extensões de
esquemas não desejáveis no diretório do Active Directory Domain Services —
como as que são úteis a uma única aplicação. Além disso, o administrador do
servidor local pode gerenciar os diretórios do Active Directory Lightweight
Directory Services; os administradores de domínio não precisam fornecer suporte
administrativo.
• Desenvolvimento da aplicação ativada pelo diretório e os ambientes de protótipo
separados da estrutura de domínio da empresa
Os desenvolvedores de aplicação que estão criando aplicações ativadas pelo
diretório podem instalar a função do Active Directory Lightweight Directory
Services em qualquer servidor, mesmo nos autônomos. Como resultado, os
desenvolvedores podem controlar e modificar o diretório em seu ambiente de
desenvolvimento, sem interferir na infra-estrutura de Active Directory Domain
Services da organização. Essas aplicações podem ser implantadas de forma
subseqüente, tanto com o Active Directory Lightweight Directory Services como
com os Serviços de Domínio do Active Directory como serviço de diretório da
aplicação, conforme apropriado.
Os administradores de rede podem usar o Active Directory Lightweight Directory
Services como ambiente protótipo ou piloto para aplicações que, eventualmente,
serão implantadas com os Serviços de Domínio do Active Directory como seu
armazenamento de diretório, contanto que a aplicação não dependa de recursos
específicos dos Serviços de Domínio do Active Directory.
• Gerenciamento de acesso de computadores de clientes externos aos recursos da
rede
Empresas que precisam autenticar computadores, como os de Web client ou
visitantes, podem usar o Active Directory Lightweight Directory Services como
local de diretório para autenticação. Isso ajuda as empresas a evitarem precisar
manter informações de clientes externos no diretório de domínio da empresa.
• Ativando computadores clientes LDAP em um ambiente heterogêneo para
autenticar os Serviços de Domínio do Active Directory
Quando as organizações se fundem, geralmente há uma necessidade de integrar
os computadores clientes LDAP que executam diferentes sistemas operacionais de
servidores em uma única infra-estrutura de rede. Nesses casos, em vez de
atualizar imediatamente os computadores clientes que executam aplicações em
LDAP ou modificar o esquema dos Serviços de Domínio do Active Directory para
funcionar com os clientes existentes, os administradores de rede podem instalar o
Active Directory Lightweight Directory Services em um ou mais servidores. A
165
função de servidor do Active Directory Lightweight Directory Services age como

um diretório intermediário que usa um esquema existente até que os
computadores clientes possam ser atualizados para usar os Serviços de Domínio
do Active Directory, de forma nativa, para acesso LDAP e autenticação.
Como o Active Directory Lightweight Directory Services é feito para ser um serviço de
diretório para aplicações, espera-se que elas criem, gerenciem e removam objetos de
diretório. Como serviço de diretório de propósito geral, o Active Directory Lightweight
Directory Services não é suportado por ferramentas orientadas a domínio, como estas:
• Domínios e Relações de Confiança do Active Directory
• Usuários e Computadores do Active Directory
• Locais e Serviços do Active Directory
No entanto, os administradores podem gerenciar os diretórios do Active Directory
Lightweight Directory Services, usando as ferramentas de diretório, como as seguintes:
• ADSI Edit (para visualizar, modificar, criar e excluir qualquer objeto do Active
Directory Lightweight Directory Services)
• Ldp.exe (para administração geral em LDAP)
• Outros utilitários do gerenciamento de esquema
As aplicações que foram designadas para trabalhar no Modo de Aplicação do Active
Directory não exigem alterações para funcionar com o Active Directory Lightweight
Directory Services.

166
5.11 Serviços de Gerenciamento de Direitos do Active

Directory
Para o Windows Server “Longhorn,” os Serviços de Gerenciamento de Direitos do Active

Directory inclui diversos recursos novos que não estavam disponíveis no Microsoft
Windows Rights Management Services (RMS). Esses novos recursos foram feitos para
facilitar a sobrecarga administrativa dos Serviços de Gerenciamento de Direitos do Active
Directory e para estender seu uso para foram da sua organização. Entre os novos recursos,
estão:
• Inclusão dos Serviços de Gerenciamento de Direitos do Active Directory no

Windows Server “Longhorn” como função de servidor
• Administração por meio de um MMC
• Integração com os Serviços Federados do Active Directory
• Registro automático dos servidores dos Serviços de Gerenciamento de Direitos do
Active Directory
• Habilidade de delegar responsabilidades por meio de novas funções
administrativas dos Serviços de Gerenciamento de Direitos do Active Directory
Nota
Este tópico concentra-se nos recursos específicos dos Serviços de Gerenciamento de
Direitos do Active Directory que estão sendo lançados com o Windows Server
“Longhorn.” As versões anteriores do RMS estão disponíveis em um download
separado. Para mais informações sobre os recursos que eram disponíveis no RMS,
confira o Windows Server 2003 Rights Management Services (RMS)
Os Serviços de Gerenciamento de Direitos do Active Directory, uma tecnologia agnóstica
de formato e aplicação, fornece serviços que ativam a criação de soluções de proteção às
informações. Ele funcionará com qualquer aplicação ativada pelos Serviços de
Gerenciamento de Direitos do Active Directory a fim de fornecer diretivas persistentes de
utilização de informações sensíveis. O conteúdo pode ser protegido, usando os Serviços
de Gerenciamento de Direitos do Active Directory, que inclui sites da intranet, mensagens
de e-mail e documentos. Os Serviços de Gerenciamento de Direitos do Active Directory
inclui uma série de funções centrais que permitem aos desenvolvedores adicionar
proteção às informações nas funcionalidades de aplicações existentes.
Um sistema dos Serviços de Gerenciamento de Direitos do Active Directory, que inclui
componentes de cliente e servidor, realiza os seguintes processos:
• Licenciamento de informações protegidas por direitos. Um sistema dos
Serviços de Gerenciamento de Direitos do Active Directory emite certificados de
contas de direitos, que identificam as entidades confiáveis (como usuários, grupos
e serviços) que possam publicar o conteúdo protegido por direito. Uma vez que a
relação de confiança é estabelecida, os usuários podem atribuir direitos e
condições de utilização ao conteúdo que desejam proteger. Esses direitos
especificam quem pode acessar o conteúdo protegido e o que a pessoa deseja
fazer com ele. Quando o conteúdo é protegido, uma licença de publicação é

167
criada para ele. Essa licença vincula os direitos específicos de utilização a certa
parte do conteúdo, para que o conteúdo possa ser distribuído. Por exemplo, os
usuários podem enviar documentos protegidos a outros usuários, dentro ou fora
da organização, sem que o conteúdo perca sua proteção.
• Adquirindo licenças para descriptografar o conteúdo protegido por direito e
aplicar diretivas de utilização. Os usuários que receberam um certificado de
conta dos direitos podem acessar o conteúdo protegido, usando uma aplicação
ativada pelos Serviços de Gerenciamento de Direitos do Active Directory que
permite que eles vejam o conteúdo e trabalhem com ele. Quando os usuários
tentam acessar um conteúdo protegido, são enviadas requisições aos Serviços de
Gerenciamento de Direitos do Active Directory para que eles acessem ou usem o
conteúdo. Quando um usuário tenta usar o conteúdo protegido, o serviço de
licenciamento dos Serviços de Gerenciamento de Direitos do Active Directory, no
cluster dos Serviços de Gerenciamento de Direitos do Active Directory, emite uma
licença única de utilização que lê, interpreta e aplica os direitos e condições
especificados nas licenças de publicação. Os direitos e condições de utilização são
aplicados de forma persistente e automática a qualquer lugar a que o conteúdo
possa ir.
• Criando arquivos e modelos protegidos por direitos. Os usuários que são
entidades confiáveis no sistema dos Serviços de Gerenciamento de Direitos do
Active Directory podem criar e gerenciar arquivos aprimorados pela proteção,
usando ferramentas conhecidas de autoria de uma aplicação ativada pelos
Serviços de Gerenciamento de Direitos do Active Directory, que incorpora os
recursos de tecnologia dos Serviços de Gerenciamento de Direitos do Active
Directory. Além disso, as aplicações ativadas pelos Serviços de Gerenciamento de
Direitos do Active Directory podem usar modelos de utilização centralmente
definidos e oficialmente autorizados para ajudar os usuários a aplicar,
efetivamente, uma série pré-definida de diretivas de utilização.
Os Serviços de Gerenciamento de Direitos do Active Directory é feito para ajudar a tornar
o conteúdo mais seguro, independente de para onde ele tenha sido movido.
Os seguintes grupos de profissionais devem analisar esta seção dos Serviços de
Gerenciamento de Direitos do Active Directory:
• Planejadores e analistas de TI que avaliam os produtos de gerenciamento de
direitos na empresa
• Profissionais de TI responsáveis por suportar uma infra-estrutura existente de RMS
• Arquitetos de segurança em TI interessados em implantar uma tecnologia de
proteção às informações que forneça proteção a todos os tipos de dados
Os Serviços de Gerenciamento de Direitos do Active Directory conta como Active
Directory Domain Services para verificar se o usuário que tenta usar o conteúdo protegido
está autorizado para fazer isso. Ao registrar um ponto de conexão do serviço (SCP) dos
Serviços de Gerenciamento de Direitos do Active Directory durante a instalação, o usuário
deve ter acesso de Escrita ao container Services nos Serviços de Domínio do Active
Directory.
Por fim, todas as informações de configuração e registro são armazenadas no Banco de
Dados de Registro dos Serviços de Gerenciamento de Direitos do Active Directory. Em um

168
ambiente de teste, você pode usar o Banco de Dados Interno do Windows, mas, em um
ambiente de produção, recomenda-se usar um servidor de banco de dados separado.
Os Serviços de Gerenciamento de Direitos do Active Directory inclui uma série de
melhorias quanto às versões anteriores do RMS. Essas melhorias incluem o seguinte:
• Instalação aprimorada e experiência em administração. Os Serviços de
Gerenciamento de Direitos do Active Directory está incluído no Windows Server
“Longhorn”, sendo instalado como uma função de servidor. Além disso, a
administração dos Serviços de Gerenciamento de Direitos do Active Directory é
feita por um MMC, ao contrário da administração do Web site apresentada nas
versões anteriores.
• Registro automático do cluster dos Serviços de Gerenciamento de Direitos
do Active Directory O cluster dos Serviços de Gerenciamento de Direitos do
Active Directory pode ser registrado sem uma conexão com o Microsoft
Enrollment Service. Pelo uso de um certificado de registro automático do servidor,
o processo de registro é feito totalmente em um computador local.
• Integração com os Serviços Federados do Active Directory Os Serviços de
Gerenciamento de Direitos do Active Directory e os Serviços Federados do Active
Directory foram integrados para que as empresas possam alavancar relações
federadas existentes para colaborar com os parceiros externos.
• Novas funções administrativas dos Serviços de Gerenciamento de Direitos
do Active Directory. A capacidade de delegar tarefas dos Serviços de
Gerenciamento de Direitos do Active Directory a diferentes administradores para
diferentes administradores é necessária em qualquer ambiente corporativo com
esta versão dos Serviços de Gerenciamento de Direitos do Active Directory. Três
funções administrativas foram criadas: Administradores Corporativos de Serviços
de Gerenciamento de Direitos do Active Directory, Administradores de Modelos
de Serviços de Gerenciamento de Direitos do Active Directory e Auditores de
Serviços de Gerenciamento de Direitos do Active Directory.
Instalação Aprimorada e Experiência em Administração.

Os Serviços de Gerenciamento de Direitos do Active Directory no Windows Server
“Longhorn” traz diversas melhorias para a experiência de instalação e de administração.
Nas versões anteriores do RMS, um pacote separado de instalação precisava de download
para depois ser instalado, mas, nesta versão, os Serviços de Gerenciamento de Direitos do
Active Directory foi integrado no sistema operacional e instalado como função de servidor
pelo Server Manager. A configuração e fornecimento são encontrados pela instalação da
função do servidor. Além disso, o Server Manager lista e instala, automaticamente, todos
os serviços dos quais os Serviços de Gerenciamento de Direitos do Active Directory é
dependente, como o Message Queuing e o Web Server (IIS), durante a instalação da
função de servidor dos Serviços de Gerenciamento de Direitos do Active Directory.
Durante a instalação, se você não especificar um banco de dados remoto como os
Serviços de Gerenciamento de Direitos do Active Directory Configuration e Logging, os
Serviços de Gerenciamento de Direitos do Active Directory instala e configura,
automaticamente, o Banco de Dados Interno do Windows para usar com os Serviços de
Nas versões anteriores do RMS, a administração era feita por uma interface da Web. Nos
Serviços de Gerenciamento de Direitos do Active Directory, a interface administrativa foi
169
migrada para um console snap-in do MMC. O console dos Serviços de Gerenciamento de

Direitos do Active Directory fornece a você todas as funcionalidades disponíveis, com a
versão anterior do RMS, mas com uma interface muito mais fácil de usar.
Oferecer os Serviços de Gerenciamento de Direitos do Active Directory como função de
servidor incluída com o Windows Server “Longhorn” torna o processo de instalação menos
incômodo, por não exigir que você faça o download dos Serviços de Gerenciamento de
Direitos do Active Directory separadamente, antes de instalá-lo.
Usar o console dos Serviços de Gerenciamento de Direitos do Active Directory para a
administração, em vez de uma interface de navegador, torna as opções mais disponíveis
para aprimorar a interface de usuário. O console dos Serviços de Gerenciamento de
Direitos do Active Directory emprega os elementos da interface de usuário que são
consistentes pelo Windows Server “Longhorn,” sendo mais fácil de seguir e de navegar.
Além disso, com o inclusão das funções administrativas dos Serviços de Gerenciamento de
Direitos do Active Directory, o console dos Serviços de Gerenciamento de Direitos do
Active Directory exibe apenas as partes que o usuário pode acessar. Por exemplo, um
usuário que está usando a função de administração dos Serviços de Gerenciamento de
Direitos do Active Directory Template Administrators está restrito a tarefas que são
específicas aos modelos dos Serviços de Gerenciamento de Direitos do Active Directory.
Todas as outras tarefas administrativas não estão disponíveis no console dos Serviços de
Registro automático dos Serviços de Gerenciamento de Direitos do

Active Directory Server
O registro do servidor nos Serviços de Gerenciamento de Direitos do Active Directory é o
processo de criação e assinatura de um certificado de licenciamento de servidor (SLC) que
garante ao servidor dos Serviços de Gerenciamento de Direitos do Active Directory o
direito de emitir certificados e licenças. Nas versões anteriores do RMS, o SLC tinha de ser
assinado por um Serviço de Registro da Microsoft por meio de uma conexão à Internet.
Isso exigia que o servidor do RMS tivesse conectividade com a Internet para fazer o
registro online no Serviço de Registro da Microsoft ou fosse capaz de se conectar a outro
computador com acesso à Internet que pudesse fazer o registro offline no servidor.
Nos Serviços de Gerenciamento de Direitos do Active Directory com o Windows Server
“Longhorn,” o requisito de o servidor dos Serviços de Gerenciamento de Direitos do Active
Directory contatar-se diretamente com o Serviço de Registro da Microsoft foi removido.
Em vez disso, um certificado
de registro automático do servidor é incluído com o Windows Server “Longhorn”, que
assina o SLC do servidor dos Serviços de Gerenciamento de Direitos do Active Directory.
Exigir que o SLC seja assinado pelo Serviço de Registro da Microsoft mostrou uma
dependência operacional, que muitos clientes não queriam em seu ambiente. O Serviço
de Registro da Microsoft não é mais requerido para assinar o SLC.
Em vez disso, para assinar o SLC do servidor dos Serviços de Gerenciamento de Direitos do
Active Directory server, o certificado de registro automático, incluído com o Windows
Server “Longhorn,” pode assinar o SLC localmente. Esse certificado permite que os Serviços
de Gerenciamento de Direitos do Active Directory opere em uma rede que seja
inteiramente isolada da Internet.

170
Ao atualizar do RMS com SP1 ou superior, o cluster raiz deve ser atualizado antes do
cluster de licenciamento apenas. Isso é exigido para que o cluster de licenciamento apenas
receba o SLC recém-registrado do cluster raiz.
Integração com os Serviços Federados do Active Directory

As empresas vêm continuamente sentindo a necessidade de colaborar fora dos seus
limites corporativos, procurando a federação como uma solução possível. O suporte da
federação com os Serviços de Gerenciamento de Direitos do Active Directory irá permitir
que as empresas alavanquem suas relações federadas já estabelecidas para permitir a
colaboração com entidades externas. Por exemplo, uma organização que tenha
implantado os Serviços de Gerenciamento de Direitos do Active Directory pode definir
uma federação com uma entidade externa, usando os Serviços Federados do Active
Directory, alavancando sua relação para compartilhar conteúdos protegidos entre duas
organizações, sem exigir uma implantação dos Serviços de Gerenciamento de Direitos do
Active Directory nos dois locais.
Nas versões anteriores do RMS, as opções para colaboração externa de conteúdo
protegido eram limitadas ao Microsoft Passport. Integrar os Serviços Federados do Active
Directory com os Serviços de Gerenciamento de Direitos do Active Directory fornece a
capacidade de estabelecer identidades federadas entre as organizações e compartilhar
conteúdos protegidos por direitos.
Se você está interessado em usar os Serviços Federados do Active Directory com os
Serviços de Gerenciamento de Direitos do Active Directory, deve ter uma relação de
confiança federada entre a sua organização e os parceiros externos com quem gostaria de
colaborar antes de os Serviços de Gerenciamento de Direitos do Active Directory ser
instalado. Além disso, você deve usar o cliente dos Serviços de Gerenciamento de Direitos
do Active Directory, incluído com o Windows Vista ou o RMS Client com SP2 para tirar
proveito da integração dos Serviços Federados do Active Directory com os Serviços de
Gerenciamento de Direitos do Active Directory. Os clientes do RMS anteriores ao RMS
Client com SP2 não irão suportar a colaboração dos Serviços Federados do Active
Directory.
Novas funções administrativas dos Serviços de Gerenciamento de

Direitos do Active Directory.
Para delegar um maior controle sobre o seu ambiente dos Serviços de Gerenciamento de
Direitos do Active Directory, foram criadas novas funções administrativas. Essas funções
são grupos de segurança locais criadas quando os Serviços de Gerenciamento de Direitos
do Active Directory está instalado. Cada uma dessas funções possui níveis diferentes de
acesso aos Serviços de Gerenciamento de Direitos do Active Directory associado a elas. As
novas funções são: Grupo de Serviços de Gerenciamento de Direitos do Active Directory,
Administradores Corporativos de Serviços de Gerenciamento de Direitos do Active
Directory, Administradores de Modelos de Serviços de Gerenciamento de Direitos do
Active Directory e Auditores Serviços de Gerenciamento de Direitos do Active Directory.
O Grupo Serviços de Gerenciamento de Direitos do Active Directory mantém a conta do
serviço dos Serviços de Gerenciamento de Direitos do Active Directory. Quando a função
dos Serviços de Gerenciamento de Direitos do Active Directory é adicionada, a conta de
serviço configurada durante a instalação é adicionada automaticamente à função
administrativa.

171
A função dos Administradores Corporativos de Serviços de Gerenciamento de Direitos do

Active Directory permite que os membros deste grupo gerenciem todas as diretivas e
configurações dos Serviços de Gerenciamento de Direitos do Active Directory. Durante o
fornecimento dos Serviços de Gerenciamento de Direitos do Active Directory, a conta de
usuário que instala a função dos Serviços de Gerenciamento de Direitos do Active
Directory e o grupo de administradores locais são adicionados à função dos
Administradores Corporativos de Serviços de Gerenciamento de Direitos do Active
Directory. Como uma melhor prática, os membros deste grupo devem ser restringidos a
apenas contas de usuários que precisam de controle administrativo total sobre os Serviços
de Gerenciamento de Direitos do Active Directory.
Os Administradores de Modelos de Serviços de Gerenciamento de Direitos do Active
Directory permitem que os membros deste grupo gerenciem os modelos de diretiva de
direitos. Especificamente, os Administradores de Modelos de Serviços de Gerenciamento
de Direitos do Active Directory podem ler as informações do cluster, listar modelos de
diretivas, criar novos modelos de diretivas, modificar um modelo existente e exportar esses
modelos.
A função dos Auditores de Serviços de Gerenciamento de Direitos do Active Directory
permite que os membros deste grupo gerenciem logs e relatórios. Essa é uma função de
somente leitura que é limitada a ler informações do cluster, ler as configurações de
logging e executar relatórios disponíveis no cluster dos Serviços de Gerenciamento de
As funções administrativas do novos Serviços de Gerenciamento de Direitos do Active
Directory fornecem a oportunidade de delegar tarefas dos Serviços de Gerenciamento de
Direitos do Active Directory sem fornecer controle total sobre todo o cluster desses
serviços.
Os clientes que querem implantar os Serviços de Gerenciamento de Direitos do Active
Directory em sua organização não precisam fazer nada para se preparar para essa
mudança. De forma opcional, recomenda-se criar grupos de segurança do Active
Directory para cada uma dessas funções administrativas e adicioná-los aos grupos de
segurança locais. Isso dará a você a capacidade de escalar a sua implantação dos Serviços
de Gerenciamento de Direitos do Active Directory por meio de diversos servidores, sem
precisar adicionar contas de usuário a cada servidor dos Serviços de Gerenciamento de

Diretivas

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Diretivas

Încărcat de

Drepturi de autor:

Formate disponibile

Diretivas de Segurança

Guia do Revisor do Windows Server “Longhorn” Beta 3

ESTE DOCUMENTO NÃO É UMA ESPECIFICAÇÃO DE PRODUTO.

Este documento suporta a versão Beta 3 do Windows Server® “Longhorn.” As informações

Guia do Revisor do Windows Server “Longhorn” Beta 3

5.01 Introdução à Aplicação de Diretivas e Segurança

O foco deste cenário é a conformidade aprimorada de segurança e gerenciamento que se

Proposta de Valor para os Cenários

Requisitos Especiais de Hardware

Guia do Revisor do Windows Server “Longhorn” Beta 3

Guia do Revisor do Windows Server “Longhorn” Beta 3

5.02 Serviços de Acesso e Diretiva de Rede

Serviços de Função para Serviços de Acesso e Diretiva de Rede

Ao instalar os Serviços de Acesso e Diretiva de Rede, os seguintes serviços de função

log no disco rígido local ou em um banco de dados do Microsoft SQL

Guia do Revisor do Windows Server “Longhorn” Beta 3

Entretanto, os clientes VPN poderão conectar-se aos computadores na

Gerenciando a Função de Network Policy Server and Access

Guia do Revisor do Windows Server “Longhorn” Beta 3

• Comandos Netsh para roteamento. Os comandos Netsh para o roteamento

Guia do Revisor do Windows Server “Longhorn” Beta 3

Quando essas configurações são definidas, o download delas é feito para os

5.03 Proteção contra Acesso à Rede

Guia do Revisor do Windows Server “Longhorn” Beta 3

O NAP reforça os requisitos de integridade, monitorando e avaliando o funcionamento dos

Guia do Revisor do Windows Server “Longhorn” Beta 3

Principais Processos do NAP

Reforço do NAP e Restrição de Rede

Monitoramento Contínuo para Garantir a Conformidade

Métodos de Reforço NAP

computadores cliente que são determinados como estando em não-conformidade com as

Reforço NAP para Comunicações IPsec

Reforço NAP para 802.1X

Reforço NAP para VPN

Reforço NAP para DHCP

Guia do Revisor do Windows Server “Longhorn” Beta 3

Entretanto, se os computadores cliente estiverem configurados para tirar vantagem

Guia do Revisor do Windows Server “Longhorn” Beta 3

Guia do Revisor do Windows Server “Longhorn” Beta 3

Componentes do Cliente NAP

Componentes de Servidor NAP

Guia do Revisor do Windows Server “Longhorn” Beta 3

Guia do Revisor do Windows Server “Longhorn” Beta 3

Guia do Revisor do Windows Server “Longhorn” Beta 3

5.04 Protocolos TCP/IP e Componentes de Rede de

A rede e as comunicações são muito importantes para que as organizações consigam

Pilha TCP/IP de Última Geração

Receive Window Auto-Tuning

O tamanho da janela de recebimento TCP (TCP receive window size) é a quantidade de

Melhorias para Ambientes de Alto Índice de Perda

retransmissões. Reduzir o número de retransmissões enviadas melhora a velocidade

Neighbor Un-reach-ability Detection for IPv4

Alterações na detecção de gateways inativos

Alterações na Detecção de Roteadores de Buraco Negro PMTU

Guia do Revisor do Windows Server “Longhorn” Beta 3

Suporte ao Network Diagnostics Framework

Guia do Revisor do Windows Server “Longhorn” Beta 3

• O serviço DHCP Client não está sendo executado

Windows Filtering Platform

Explicit Congestion Notification

• Multicast Listener Discovery versão 2

IPv6 Ativado por Padrão

Configuração Baseada em GUI