Formação Administrador de Redes Multiplataforma PT2

APOSTILA DE TREINAMENTO
SS3136
FORMAÇÃO ADMINISTRADOR DE REDES
MULTIPLATAFORMA
PARTE 2
Porto Alegre
(Versão 1.3)
TÓPICOS ABORDADOS NA PARTE 1:
 Fundamentos de Redes de Computadores
 Protocolos de Rede
 Roteamento IP
 Roteadores CISCO
 Switching CISCO
 Redes Wireless
 Servidores Microsoft
TÓPICOS ABORDADOS NA PARTE 2:

 Serviços de Rede Microsoft
 Active Directory
 Active Directory Domain Services
 Segurança em Ambientes Microsoft
 Servidores Linux
 Gerenciamento de Servidores Linux
 Serviços de Rede Linux
 Segurança em Ambientes Linux
SISNEMA Informática
Rua Washington Luiz, 820 / 601
Centro – Porto Alegre – RS
CEP 90010-460
Telefone: (51) 3226-4111
Fax: (51) 3226-1219
e-mail: aluno@sisnema.com.br
sisnema.com.br
SISNEMA Informática
SS3136 - FORMAÇÃO ADMINISTRADOR DE REDES MULTIPLATAFORMA – PARTE 2
SUMÁRIO
1. MÓDULO 8 - SERVIÇOS DE REDE MICROSOFT 13

1.1. SERVIDOR DE ARQUIVOS ........................................................................................... 13
Segurança de Arquivos e Pastas .......................................................................................... 13
Tipos de permissões NTFS ................................................................................................... 14
Exemplos de Permissão NFTS .............................................................................................. 17
Regras para permissões NTFS ............................................................................................. 17
Configurar Permissões NTFS................................................................................................ 18
Pastas Compartilhadas .......................................................................................................... 18
Acesso a Pastas Compartilhadas ......................................................................................... 19
Compartilhando pasta na Rede............................................................................................. 19
Compartilhamentos Administrativos ................................................................................... 19
Permissões de pastas compartilhadas ................................................................................ 20
Conflitos de Permissão .......................................................................................................... 21
Bloqueio de Herança .............................................................................................................. 21
Restaurar de herança padrão ................................................................................................ 21
Permissões efetivas ............................................................................................................... 22
Verificar Permissões Efetivas ............................................................................................... 23
Acess-Based Enumeration .................................................................................................... 23
Cópias de sombra (shadow copy) ........................................................................................ 23
Restaurando dados de cópias de sombra ........................................................................... 25
1.2. DNS ................................................................................................................................ 37
Visão geral da função DNS .................................................................................................... 37
DNS e a Internet ...................................................................................................................... 37
DNS e o AD DS ........................................................................................................................ 38
Visão geral do Namespace .................................................................................................... 38
DNS Namespace ..................................................................................................................... 38
Integração do AD DS e do DNS ............................................................................................. 39
Integração do Active Directory ............................................................................................. 41
Componentes de uma solução DNS ..................................................................................... 42
Consultas de DNS .................................................................................................................. 43
Registros de recursos DNS ................................................................................................... 45
Root hints ................................................................................................................................ 46
Encaminhamento de DNS ...................................................................................................... 47
Cache do servidor DNS .......................................................................................................... 48
Zona DNS................................................................................................................................. 49
Tipos de zona DNS ................................................................................................................. 50
Zonas de pesquisa direta e inversa ...................................................................................... 51
Apostila para o treinamento SS3136

Versão: 1.3- Pág. 3 de 377
Transferência de zona DNS ................................................................................................... 52

Configuração da segurança de transferência de zona ....................................................... 54
1.3. DHCP.............................................................................................................................. 27
DHCP e alocação de endereços IP ....................................................................................... 27
Lease DHCP (concessão de configurações IP) ................................................................... 28
Renovação do Lease de DHCP ............................................................................................. 30
DHCP Relay Agent .................................................................................................................. 31
Autorização de servidor DHCP ............................................................................................. 32
Escopos de DHCP .................................................................................................................. 32
Reserva de DHCP ................................................................................................................... 34
Opções de DHCP .................................................................................................................... 34
1.4. SERVIDOR WEB E FTP ................................................................................................ 59
Cenários do servidor Web ..................................................................................................... 59
Criar um site estático no IIS .................................................................................................. 59
Criar um site FTP .................................................................................................................... 63
1.5. VPN (PPTP, IPSEC E SSTP) ....................................................................................... 157
Configuração do acesso à rede .......................................................................................... 157
Componentes de uma infraestrutura de serviços de acesso à rede .............................. 157
Autenticação e autorização de rede ................................................................................... 159
Métodos de autenticação ..................................................................................................... 160
Configuração do acesso à VPN .......................................................................................... 162
Conexão VPN ........................................................................................................................ 163
VPN de acesso remoto ......................................................................................................... 163
VPN site a site ....................................................................................................................... 164
Protocolos de encapsulamento .......................................................................................... 165
Reconexão VPN .................................................................................................................... 167
Requisitos de configuração ................................................................................................ 168
1.6. NPS E NAP .................................................................................................................. 169
Servidor de Políticas de Rede ............................................................................................. 170
Servidor RADIUS .................................................................................................................. 170
Proxy RADIUS ....................................................................................................................... 171
Ferramentas para configurar um Servidor de Políticas de Rede .................................... 172
Configuração de clientes e servidores RADIUS................................................................ 173
Exemplos de clientes RADIUS ............................................................................................ 174
Proxy RADIUS ....................................................................................................................... 175
Política de Solicitação de Conexão .................................................................................... 176
Política padrão de solicitação de conexão ........................................................................ 178
Configuração do processamento de solicitação de conexão ......................................... 179
Portas para RADIUS e registro em log ............................................................................... 180

Métodos de autenticação do NPS ....................................................................................... 181

Métodos de autenticação baseados em senha ................................................................. 181
Métodos de autenticação ..................................................................................................... 183
Modelos de certificado ......................................................................................................... 184
Certificados necessários para autenticação ..................................................................... 185
Implantação de certificados para PEAP e EAP ................................................................. 187
Requisitos mínimos para certificados de cliente .............................................................. 189
1.7. EXERCÍCIOS ........................................................ ERRO! INDICADOR NÃO DEFINIDO.
2. MÓDULO 9 - ACTIVE DIRECTORY 69

2.1. AD DS ............................................................................................................................. 69
Visão Geral do AD DS ............................................................................................................ 69
Domínios AD DS ..................................................................................................................... 71
Unidades Organizacionais (OUs) .......................................................................................... 72
Floresta AD DS ....................................................................................................................... 73
AD DS Schema ........................................................................................................................ 74
Visão geral de Controladores de Domínio ........................................................................... 76
Controladores de Domínio .................................................................................................... 76
Global Catalog (Catalogo Global) ......................................................................................... 78
Processo de logon do AD DS ................................................................................................ 79
Mestres de Operações ........................................................................................................... 80
Mestre de Operação de Floresta ........................................................................................... 80
Mestre de Operação de Domínio........................................................................................... 80
Instalando Controlador de Domínio pelo Server Manager ................................................. 81
Instalando um controlador de domínio em um Server Core .............................................. 84
Atualizando um Controlador de Domínio ............................................................................ 85
Atualizando para Windows Server 2012 .............................................................................. 85
Implantando controladores de domínio do Windows Server 2012 ................................... 85
3. MÓDULO 10 - ACTIVE DIRECTORY DOMAIN SERVICES 87

3.1. GERENCIAMENTO DE GRUPOS E USUÁRIOS .......................................................... 87
Gerenciando contas de usuário ............................................................................................ 87
Ferramentas de administração AD DS ................................................................................. 87
Criando contas de usuários .................................................................................................. 89
Configurando atributos de contas de usuários .................................................................. 91
Gerenciando Contas de Grupo ............................................................................................. 94
Grupos de escopos ................................................................................................................ 95
3.2. GROUP POLICY (GPO) ................................................................................................. 99
Gerenciamento de configuração........................................................................................... 99
Visão geral das Políticas de Grupo ...................................................................................... 99

Objetos de Política de Grupo .............................................................................................. 100

Administração de GPOs ...................................................................................................... 101
Ordem de processamento da Política de Grupo ............................................................... 103
Processamento de política loopback ................................................................................. 105
Identificar configurações efetivas ...................................................................................... 106
3.3. REPLICAÇÃO .............................................................................................................. 108
Partições do AD DS .............................................................................................................. 108
Como funciona a replicação do AD DS dentro de um site ............................................... 109
Como o catálogo global afeta a replicação ....................................................................... 112
Como a replicação RODC funciona .................................................................................... 112
Replicação de sites do AD DS............................................................................................. 113
Ferramentas para gerenciar e monitorar a replicação ..................................................... 114
3.4. AD LDS ......................................................................................................................... 116
O que é a função de servidor AD LDS? ............................................................................. 117
Exemplos de utilização do AD LDS .................................................................................... 117
Recursos da função de servidor AD LDS .......................................................................... 119
3.5. AD CS ........................................................................................................................... 121
Visão geral do PKI ................................................................................................................ 121
Conceitos gerais de PKI ...................................................................................................... 121
Componentes de uma solução PKI .................................................................................... 122
Autoridades de Certificação (AC) ou Certification Authority (CA) .................................. 125
ACs públicas versus ACs privadas .................................................................................... 126
Opções para a implementação de hierarquias de AC ...................................................... 127
ACs autônomas versus ACs corporativas ......................................................................... 128
Considerações para a implantação de uma AC raiz ......................................................... 129
Considerações para a implantação de uma AC subordinada ......................................... 131
Implementação da distribuição e revogação de certificados .......................................... 132
Opções de registro de certificado ...................................................................................... 132
Funcionamento do registro automático ............................................................................. 134
Revogação de certificado .................................................................................................... 135
3.6. AD RMS ........................................................................................................................ 137
AD RMS.................................................................................................................................. 137
Cenários de uso do AD RMS ............................................................................................... 138
Visão geral dos componentes do AD RMS ........................................................................ 138
Funcionamento do AD RMS ................................................................................................ 140
Cenários de implantação do AD RMS ................................................................................ 141
3.7. AD FS ........................................................................................................................... 145
Visão geral do AD FS ........................................................................................................... 145
Federação de Identidade ..................................................................................................... 145

Identidade baseada em declarações .................................................................................. 146

Sobre AD FS .......................................................................................................................... 148
Recursos do AD FS .............................................................................................................. 148
Como o AD FS habilita o SSO em uma organização única .............................................. 149
Como o AD FS habilita o SSO em uma federação B2B .................................................... 151
Como o AD FS habilita o SSO com serviços online ......................................................... 152
Componentes do AD FS ...................................................................................................... 153
Pré-requisitos do AD FS ...................................................................................................... 154
3.9. BACKUP E RECUPERAÇÃO DE DESASTRES.......................................................... 190
Identificar requisitos de recuperação de desastres ......................................................... 190
Visão geral das estratégias de recuperação de desastres de empresa ......................... 191
O que precisa ser incluído no backup ............................................................................... 193
Tipos de backup ................................................................................................................... 194
Tecnologias de backup ........................................................................................................ 194
Backup do Windows Server ................................................................................................ 196
Windows Azure Online Backup........................................................................................... 197
Data Protection Manager ..................................................................................................... 198
Opções de recuperação de servidor .................................................................................. 199
Opções de restauração de servidor ................................................................................... 200
Opções de recuperação de dados ...................................................................................... 201
Restauração com o Windows Azure Online Backup ........................................................ 201
3.10. EXERCÍCIOS ...................................................... ERRO! INDICADOR NÃO DEFINIDO.
4. MÓDULO 11 - SEGURANÇA EM AMBIENTES MICROSOFT 204

4.1. FIREWALL AVANÇADO .............................................................................................. 204
Regras de entrada e saída ................................................................................................... 204
Connection Security Rules .................................................................................................. 204
Perfis de Firewall .................................................................................................................. 205
Regras de conexão de segurança ...................................................................................... 205
4.2. CRIPTOGRAFIA E CERTIFICADO DIGITAL............................................................... 208
Criptografia de arquivos usando EFS ................................................................................ 208
Como o EFS funciona .......................................................................................................... 209
Recuperação de arquivos criptografados por EFS........................................................... 210
4.3. SECURITY POLICY ..................................................................................................... 211
Configurando Templates de Segurança ............................................................................ 211
Configuring User Rights ...................................................................................................... 212
Configurando opções de segurança .................................................................................. 213
4.4. WSUS ........................................................................................................................... 214
Definição do WSUS .............................................................................................................. 214

Requisitos de servidor do WSUS........................................................................................ 215

Configuração das Atualizações Automáticas ................................................................... 216
Administração do WSUS ..................................................................................................... 216
Controle atualizações em computadores clientes ............................................................ 217
Grupos de computadores .................................................................................................... 217
Aprovação de atualizações ................................................................................................. 218
5. MÓDULO 12 - SERVIDORES LINUX 220

5.1. KERNEL E DISTRIBUIÇÕES LINUX ........................................................................... 220
Distribuições Linux .............................................................................................................. 220
Kernel 224
Entendendo o Kernel ........................................................................................................... 224
Versão Numérica do Kernel................................................................................................. 224
Módulos do Kernel ............................................................................................................... 225
Gerenciamento de módulos do Kernel .............................................................................. 226
Compilando um Novo Kernel .............................................................................................. 228
Motivações para se recompilar o kernel do Linux ............................................................ 229
Pré-requisitos........................................................................................................................ 229
5.2. INSTALAÇÃO E CONFIGURAÇÃO INICIAL ............................................................... 236
Requisitos de Hardware ....................................................................................................... 236
Lista de Compatibilidade de Hardware .............................................................................. 237
Gerenciamento de Discos no Linux ................................................................................... 237
5.3. SHELL LINUX E SSH ................................................................................................... 239
Conceitos de SSH ................................................................................................................. 239
O OpenSSH ........................................................................................................................... 240
5.4. PRINCIPAIS COMANDOS ........................................................................................... 242
Comandos Básicos .............................................................................................................. 242
Comandos de Manipulação de Texto ................................................................................. 247
6. MÓDULO 13 - GERENCIAMENTO DE SERVIDORES LINUX 252

6.1. GERENCIAMENTO DE GRUPOS E USUÁRIOS ........................................................ 252
Adicionando novos usuários .............................................................................................. 252
Grupos no Linux ................................................................................................................... 254
Usuários: Administração Avançada ................................................................................... 255
Deleção de Usuário .............................................................................................................. 257
Administração de Grupos .................................................................................................... 257
Removendo um grupo ......................................................................................................... 258
6.2. INSTALANDO PACOTES ............................................................................................ 260

Gerenciamento de Pacotes RPM ........................................................................................ 260

Reindexando o Banco RPM ................................................................................................. 261
Ferramentas de gerenciamento de Dependências ........................................................... 262
6.3. COMPILANDO CÓDIGO FONTE ................................................................................ 263
Instalando Programas Através do Código Fonte .............................................................. 263
6.4. GERENCIANDO SERVIÇOS ....................................................................................... 266
Ferramentas Extras - Webmin ............................................................................................. 267
7. MÓDULO 14 - SERVIÇOS DE REDE LINUX 272

7.1. DNS .............................................................................................................................. 277
Como funciona o DNS .......................................................................................................... 279
Caching.................................................................................................................................. 280
Servidores de Nome Autoritários ....................................................................................... 281
Instalando um Servidor DNS ............................................................................................... 282
Tipos de Registros ............................................................................................................... 287
Os Registros MX ................................................................................................................... 288
Zonas Reversas .................................................................................................................... 288
7.2. DHCP............................................................................................................................ 272
IPs Estáticos ......................................................................................................................... 272
IPs Dinâmicos ....................................................................................................................... 273
Instalando o Servidor DHCP................................................................................................ 275
Configuração do Servidor DHCP ........................................................................................ 275
7.3. SERVIDOR WEB.......................................................................................................... 289
Configurando o Apache ....................................................................................................... 290
Diretivas Globais .................................................................................................................. 291
Servidor Principal ................................................................................................................. 292
Virtual Hosts.......................................................................................................................... 293
Configurando os logs do Apache ....................................................................................... 294
7.4. SERVIDOR FTP ........................................................................................................... 296
Instalação e Configuração de Servidor de FTP ................................................................. 296
Controle de Acesso .............................................................................................................. 301
7.5. SQUID PROXY ............................................................................................................. 302
Conceitos de Proxy ............................................................................................................ 302
Instalando e Configurando o Squid ................................................................................ 303
Configurando ACLs no Squid ............................................................................................. 305
Configurando “Black lists” .................................................................................................. 308
Autenticação de Usuários ................................................................................................... 309
O Arquivo de Log ................................................................................................................. 311
7.6. SAMBA ......................................................................................................................... 314

Introdução ao Samba e Protocolo SMB ............................................................................. 314

Como funciona a integração com ambientes Microsoft .................................................. 315
O que é o protocolo SMB..................................................................................................... 316
Instalando o Samba .............................................................................................................. 317
Configurando o Samba ........................................................................................................ 317
Conceitos de Redes Microsoft ............................................................................................ 319
Instalando o Samba como um PDC .................................................................................... 321
Serviço de Diretório LDAP................................................................................................... 323
Conceitos sobre LDAP ......................................................................................................... 323
OID (Object Identifier) .......................................................................................................... 324
Schema .................................................................................................................................. 325
Organização de uma “Árvore de Diretórios” LDAP .......................................................... 325
Implementando um Servidor OpenLDAP ........................................................................... 327
Procedimentos de Configuração ........................................................................................ 328
Gerando os Certificados SSL .............................................................................................. 332
Configurando a autenticação LDAP ................................................................................... 333
Configuração do “phpldapadmin” ...................................................................................... 336
Menu de Abertura do “phpldapadmin” .............................................................................. 338
7.7. INTEGRAÇÃO COM AMBIENTES MICROSOFT ........................................................ 341
Integração com Kerberos .................................................................................................... 341
Autenticação entre plataformas .......................................................................................... 342
Integração com AD (Active Directory) ................................................................................ 343
SSO (Single-Sign On) ........................................................................................................... 345
8. MÓDULO 15 - SEGURANÇA EM AMBIENTES LINUX 346

8.1. IPTABLES..................................................................................................................... 346
O que é um Firewall .............................................................................................................. 346
Tipos de Firewall .................................................................................................................. 346
Implementando Firewall com o iptables ............................................................................ 349
O Básico de Iptables ............................................................................................................ 352
Elaboração de um script de Firewall com o iptables ........................................................ 353
Obtendo Dados para a elaboração do “Firewall Script” .................................................. 355
Definindo a política do Firewall........................................................................................... 355
Iptables – Comandos Utilizados ......................................................................................... 358
Definindo os “sockets” (conexões) que serão permitidos .............................................. 359
NAT – Network Address Translation .................................................................................. 360
8.2. LOGS E AUDITORIAS ................................................................................................. 362
8.3. RELATÓRIOS .............................................................................................................. 365
Instalação e Configuração:.................................................................................................. 365

8.4. TESTES DE INTRUSÃO .............................................................................................. 368

Planejamento ........................................................................................................................ 368
Tipos dos testes de penetração .......................................................................................... 369
Ataques de ambiente ........................................................................................................... 370
Ataques de entrada .............................................................................................................. 370
Ataques de dados e lógica .................................................................................................. 371
Cuidados com serviços ....................................................................................................... 372
Servidores de Nomes (DNS) ................................................................................................ 372
Servidores de Senha/Chave (KDC) ..................................................................................... 373
Servidores de Autenticação/Proxy ..................................................................................... 373
Correio Eletrônico ................................................................................................................ 373
World Wide Web (WWW)...................................................................................................... 373
Transferência de Arquivo (FTP, TFTP) ............................................................................... 374
NFS 374
Firewalls ................................................................................................................................ 375
Ferramentas para testes de Intrusão ................................................................................. 377


1. MÓDULO 8 - SERVIÇOS DE REDE MICROSOFT

1.1. SERVIDOR DE ARQUIVOS
Acessar arquivos e impressoras na rede é uma das atividades mais comuns no
ambiente Windows Server.
Segurança de Arquivos e Pastas

Os arquivos e pastas que seus servidores armazenam normalmente contêm o negócio
da sua organização e dados funcionais. Proporcionar acesso adequado a esses arquivos e
pastas, normalmente através da rede, é uma parte importante da gestão de arquivo e serviços
de impressão.
Permissões NTFS
São atribuídas para arquivos de pastas de um dispositivo de armazenamento
formatado com sistema de arquivos NTFS. As permissões determinam o nível de acesso aos
arquivos e pastas
Permissões NTFS:
 São atribuídas a arquivos e pastas
 Podem permitir ou negar
 São herdadas da pasta pai
Conflito de precedência de permissão:

 Nega explicitamente
 Permite explicitamente
 Nega por herança
 Permite por herança
Os pontos seguintes descrevem os principais aspectos de permissões NTFS:

 Permissões NTFS pode ser atribuída para um arquivo ou pasta individual, ou conjuntos
de arquivos ou pastas.
 As permissões NTFS podem ser atribuídas individualmente
 As permissões NTFS são controladas negando ou permitindo tipos específicos de

acesso à pasta ou arquivo, como ler ou escrever

 Permissões NTFS podem ser herdadas da pasta pai. Por padrão, as permissões NTFS
que são atribuídos a uma pasta também são atribuídos aos arquivos dentro desta
pasta pai.
Tipos de permissões NTFS

Há duas categorias de permissões NTFS: padrão e avançadas.
Permissões padrão
Permissões padrão fornecem as configurações de permissão mais comumente usados
para arquivos e pastas. Você pode atribuir permissões padrão na janela principal atribuição
permissões NTFS.
A tabela abaixo detalha as opções de permissões padrão para arquivos e pastas

NTFS.
Permissões de arquivos Descrição
Full Control (controle total) Concede ao usuário controle total do arquivo ou

pasta, incluindo o controle de permissões.
Modify (modificar) Concede ao usuário permissão para ler, escrever ou

excluir um arquivo ou pasta, incluindo a criação de
um arquivo ou pasta.
Read and Execute (ler e executar) Concede ao usuário permissão para ler um arquivo e
iniciar programas.
Read (ler) Concede ao usuário permissão para ver o conteúdo

do arquivo ou pasta e iniciar programas.
Write (escrever) Concede ao usuário permissão para gravar em um

arquivo.
List folder contents (listar conteúdo Concede ao usuário permissão para ver uma lista de
da pasta) conteúdo da pasta.
OBS.: apenas em pastas
Nota: Conceder aos usuários permissões de controle total sobre um arquivo ou uma
pasta dá a capacidade de executar qualquer ação no objeto, bem como a capacidade para
alterar as permissões sobre o objeto. Eles também podem remover permissões de recurso
para um ou todos os usuários, incluindo o dono do arquivo ou administrador.

Permissões avançadas
Permissões avançadas podem oferecer um nível muito maior de controle sobre
arquivos e pastas NTFS. São acessíveis clicando no botão Advanced (Avançado) e, em
seguida, acessando a guia Security (Segurança) de um arquivo ou propriedades da pasta.
A tabela abaixo detalha as permissões avançadas para arquivos e pastas NTFS.
Transverse A permissão “Percorrer pasta” aplica-se somente a pastas.

Esta permissão concede ou nega a capacidade do usuário
Folder/Execute File
para navegar através de pastas para acessar outros arquivos
(percorrer pasta/ executar
ou pastas.
arquivo)
A permissão “Percorrer pasta” tem efeito apenas quando o
grupo ou usuário não é configurado para ignorar esta
condição. O direito de usuário Ignorar a verificação completa
é verificado nas Group Policy (políticas de grupo). Por
padrão, o grupo Todos (everyone) tem o direito de ignorar a
verificação do usuário.
A permissão de Executar concede ou nega permissão de
acesso a arquivos de programas que estão sendo
executados. Se você definir a permissão “Percorrer pasta”
em uma pasta, a permissão Executar arquivo não é
automaticamente ajustado em todos os arquivos na pasta.
List Folder/Read A permissão “Listar pasta” concede ao usuário permissão

para exibir nomes de arquivos e subpastas. A permissão
Data (listar pasta/ ler dados)
Listar pasta aplica-se apenas às pastas e afeta apenas o
conteúdo dessa pasta. Além disso, esta configuração não
tem efeito sobre a visualização da estrutura do arquivo a
partir de uma interface de linha de comando.
A permissão de leitura de dados concede ou nega a
permissão do usuário para exibir dados em arquivos. A
permissão de leitura de dados aplica-se somente aos
arquivos.
Read Attributes (ler Atributos de permissão de leitura concede ao usuário

atributos) permissão para ver os atributos básicos de um arquivo ou
uma pasta, tais como “somente leitura” e “oculto”. Os
atributos são definidos pelo NTFS.
Read Extended O atributo de leitura estendida concede ao usuário

permissão para ver os atributos estendidos de um arquivo ou
Attributes (ler atributos
pasta. Os atributos estendidos são definidos por aplicativos,
estendidos)
e pode variar de acordo com a aplicação.
Create Files/Write A permissão de criar arquivos se aplica apenas a pastas e

concede ao usuário permissão para criar arquivos na pasta.
Data (criar arquivos/ gravar
A permissão de gravação de dados concede ao usuário
dados)
permissão para fazer alterações no arquivo e substituir o


conteúdo existente por NTFS. A permissão de gravação de
dados aplica-se somente aos arquivos.
Create A permissão “Criar Pastas” concede ao usuário permissão
para criar pastas na pasta. A permissão criar pastas se aplica
Folders/Append
somente a pastas. A permissão de Acrescentar Dados
Data (criar pastas/ concede ao usuário permissão para fazer alterações no final
acrescentar dados) do arquivo, mas não para eliminar ou substituir os dados
existentes. A permissão de Dados Anexar aplica-se somente
aos arquivos.
Write Attributes (gravar A permissão “Gravar Atributos” concede ao usuário

atributos) permissão para alterar os atributos básicos de um arquivo ou
pasta, como somente leitura ou oculto. Os atributos são
definidos pelo NTFS.
A permissão Gravar Atributos não abrange que você possa
criar ou excluir arquivos ou pastas. Inclui apenas a
permissão para fazer alterações nos atributos de um arquivo
ou pasta.
Write Extended A permissão “Gravar Atributos estendidos” concede ao

usuário permissão para alterar os atributos estendidos de um
Attributes (gravar atributos
arquivo ou pasta. Os atributos estendidos são definidos por
estendidos)
programas e podem variar de acordo com programa.
A permissão Gravar Atributos estendidos não dá o direito do
usuário criar ou apagar arquivos ou pastas. Inclui apenas a
permissão para fazer alterações nos atributos de um arquivo
ou pasta.
Delete Subfolders and Files A permissão “Excluir as subpastas e arquivos” concede ao

(excluir subpastas e usuário permissão para excluir subpastas e arquivos, mesmo
arquivos) que a permissão Excluir não seja concedida na subpasta ou
arquivo.
Delete (excluir) A permissão “Excluir” concede ao usuário excluir o arquivo

ou pasta. Se você não tiver atribuído à permissão Excluir em
um arquivo ou pasta, você ainda pode fazê-lo se você tiver
permissões de Excluir subpastas e arquivos na pasta pai.
Read Permissions Permissão de “Ler” concede ao usuário permissão para ler

(permissões de leitura) sobre o arquivo ou pasta, como Controle total, Ler e
Escrever.
Change Permissions Permissão Alterar permite alterar as permissões do arquivo

(alterar permissões) ou pasta, como Controle total, Ler e Escrever.
Take Ownership (apropriar- A permissão “Apropriar-se” concede ao usuário permissão

se) para apropriar-se do arquivo ou pasta. O proprietário de um
arquivo ou pasta pode alterar permissões,
independentemente de quaisquer permissões existentes que
protegem o arquivo ou pasta.

Nota: Permissões padrão são combinações de várias permissões avançadas

individuais que são geralmente agrupadas em arquivo e cenários de uso de pasta.
Exemplos de Permissão NFTS

Os seguintes são exemplos básicos de atribuição de permissões NTFS.
 Para a pasta Marketing, um administrador optou por atribuir permissão de Leitura para
Luis Antonio. De acordo com o comportamento padrão de permissões NTFS, Luis
Antonio terá acesso de leitura para os arquivos e pastas que estão contidos na pasta
Marketing.
 Ao aplicar permissões NTFS, os resultados são cumulativos. Por exemplo, no exemplo

anterior, digamos que Luis Antonio também faz parte do grupo marketing. O grupo
marketing tem permissões de gravação na pasta Marketing. Quando combinamos as
permissões atribuídas à conta de usuário do Luis Antonio com as permissões
atribuídas ao grupo de Marketing, Luis teria permissões de leitura e de gravação para
a pasta Marketing.
Regras para permissões NTFS

Existem dois grupos de permissões NTFS:
 Explícito vs Herdado. Quando você aplica permissões NTFS, as permissões que são
explicitamente aplicadas a um arquivo ou uma pasta prevalecem sobre as que são
herdadas de uma pasta pai.
 Negar vs Permitir. Depois que as permissões NTFS são divididas em explicitas e
herdadas, qualquer permissão de Negar que existir irá prevalecer.
Portanto, tendo em conta estas regras, permissões NTFS aplicar na seguinte ordem:
1. Negar explicitamente
2. Permitir explicitamente
3. Negar Herdado
4. Permitir Herdado
É importante lembrar que as permissões NTFS são cumulativas, e essas regras só se

aplicam quando configurações de permissão NTFS conflitam umas com as outras.

Configurar Permissões NTFS

Você pode ver e configurar as permissões NTFS, seguindo estes passos:
1. O botão direito do mouse no arquivo ou pasta para a qual você quer atribuir permissões
e, em seguida, clique em Properties (propriedades)
2. 2. Na janela Properties (propriedades), clique na guia Security (segurança). Nesta

guia, você pode selecionar usuários ou grupos que tenham sido atribuídas permissões
para visualizar as permissões específicas.
3. Para abrir uma caixa de diálogo de permissões editável para que você pode modificar
as permissões existentes ou adicionar novos usuários ou grupos, clique no botão
Editar (edit).
Pastas Compartilhadas
As pastas compartilhadas são um componente chave para a concessão de acesso a
arquivos em no servidor. Quando você compartilha uma pasta, a pasta e todo seu conteúdo
são disponibilizados para vários usuários simultaneamente através da rede. Pastas
compartilhadas mantêm um conjunto distinto de permissões NTFS que se aplicam ao
conteúdo da pasta. Essas permissões são usadas para fornecer um nível extra de segurança
para arquivos e pastas disponibilizados na rede.
A maioria das organizações implantam servidores de arquivos dedicados para

hospedar pastas compartilhadas. Podem ser organizadas de acordo com categorias ou
funções. Por exemplo, você pode colocar os arquivos compartilhados para o departamento

de vendas no compartilhamento “vendas” e em outra pasta compartilhada chamada

“Marketing” os arquivos deste setor.
Nota: O processo de compartilhamento aplica-se apenas ao nível da pasta. Você não

pode compartilhar um arquivo individual ou um grupo de arquivos.
Acesso a Pastas Compartilhadas

Os usuários normalmente acessam uma pasta compartilhada na rede usando seu
endereço Universal Naming Convention (UNC). O endereço UNC contém o nome do
servidor no qual a pasta está hospedado, e o nome da pasta compartilhada, separados por
uma barra invertida (\) e precedido por duas barras invertidas (\\). Por exemplo, o caminho
UNC para o compartilhamento “vendas” no servidor SVR1 seria \\SRV1\vendas.
Compartilhando pasta na Rede

Existem maneiras diferentes de compartilhar uma pasta:
 Clique na unidade apropriada e, em seguida, na seção Files and Storage Services
(Serviços de armazenamento de arquivos) do Server Manager, clique em New Share
(novo compartilhamento).
 Usando o File Sharing Wizard (Assistente de compartilhamento de arquivos), ou a

partir do menu do botão direito da pasta, ou clicando no botão Share (compartilhar) na
guia Sharing (compartilhamento) da caixa de diálogo Properties (propriedades) da
pasta.
 Usando Advanced Sharing (compartilhamento avançado), clicando no botão

Advanced Sharing na guia Sharing (compartilhamento) da caixa de diálogo
Properties (propriedades) da pasta.
 Com a ferramenta Net use a partir de uma janela de linha de comando.
 Com o cmdlet New-SMBShare no Windows PowerShell.
Nota: Ao compartilhar uma pasta, precisará dar um nome para a pasta compartilhada.
Esse nome não tem que ser o mesmo nome da pasta atual, que pode ser um nome que melhor
descreve o conteúdo da pasta para os usuários da rede.
Compartilhamentos Administrativos
Você pode criar pastas administrativas compartilhadas (ou ocultas) que precisam estar
disponíveis a partir da rede, mas devem estar escondidas dos usuários que navegam na rede.
Você pode acessar uma pasta administrativa compartilhada digitando o seu caminho UNC,
mas a pasta não será exibido se você procurar o servidor usando uma janela do Windows

Explorer. Pastas compartilhadas administrativas também têm tipicamente um conjunto mais

restrito de permissões atribuídas à pasta compartilhada para refletir a natureza administrativa
do conteúdo da pasta.
Para ocultar uma pasta compartilhada, é preciso adicionar o símbolo de cifrão ($) no
nome do compartilhamento. Por exemplo, uma pasta compartilhada chamada “vendas” no
servidor SVR1 fica como compartilhamento oculto se o nome do compartilhamento desta
pasta for “vendas$”. A pasta compartilhada poderá ser acessada através da rede usando o
caminho UNC \\SVR1\vendas$.
Nota: Permissões de pastas compartilhadas se aplicam somente aos usuários que

acessam a pasta através da rede. Elas não afetam os usuários que acessam a pasta local no
computador onde a pasta está armazenada.
Permissões de pastas compartilhadas

Assim como nas permissões NTFS, você pode atribuir permissões de pasta
compartilhada para os usuários, grupos ou computadores.
No entanto, ao contrário das permissões NTFS, permissões de pastas compartilhadas
não são configuráveis para arquivos individuais ou pastas dentro da pasta compartilhada.
Permissões de pasta compartilhada são definidas uma vez para a pasta compartilhada em si,
e se aplica a todo o conteúdo da pasta para os usuários que acessam ela através da rede.
Quando você cria uma pasta compartilhada, o padrão atribuído permissão

compartilhada para o grupo Todos (everyone) está definido para ler.
A tabela a seguir lista as permissões que você pode conceder a uma pasta
compartilhada.
Permissões de pastas Descrição

compartilhadas
Read (ler) Os usuários podem visualizar os nomes das pastas e arquivos,

visualizar os dados do arquivo e atributos, executar arquivos de
programas e scripts, e navegar pela estrutura de pastas dentro da
pasta compartilhada.
Change (alterar) Os usuários podem criar pastas, adicionar arquivos para pastas,
alterar dados em arquivos, anexar dados para arquivos, alterar os
atributos de arquivo, apagar pastas e arquivos, e executar todas
as tarefas permitidas pela permissão de leitura.
Full Control (controle O usuário pode alterar as permissões de arquivos, se apropriar

total) de arquivos, e executar todas as tarefas permitidas pela
permissão “alterar”.

Nota: Quando você atribuir permissões de “controle total” sobre a pasta compartilhada
a um usuário, o usuário poderá modificar as permissões na pasta compartilhada, que inclui a
remoção de todos os usuários (incluindo os administradores), a partir de lista de permissões
da pasta compartilhada. Na maioria dos casos, você deve conceder permissão “alterar” ao
invés de permissão “controle total”.
Conflitos de Permissão
Às vezes, explicitamente definir permissões em um arquivo ou pasta irá entrar em
conflito com as permissões herdadas de uma pasta pai. Nestes casos, as permissões
explicitamente atribuídas sempre substituem as permissões herdadas.
Bloqueio de Herança
Você também pode desativar o comportamento de herança para um arquivo ou uma
pasta (e seu conteúdo) em uma unidade NTFS para definir explicitamente permissões para
um conjunto de objetos sem incluir qualquer uma das permissões herdadas de quaisquer
pastas pai. Para bloquear a herança de um arquivo ou pasta, execute os seguintes passos:
 Botão direito do mouse no arquivo ou pasta que você deseja bloquear a herança, e
clique em Properties (propriedades).
 • Na janela Propriedades, clique na guia Security (segurança) e, em seguida, clique

no botão Advanced (avançado).
 Na janela Advanced Security Settings (configurações avançadas de segurança),

clique no botão Change Permissions (alterar permissões).
 • Na próxima janela Advanced Security Settings (configurações avançadas de

segurança), clique no botão Disable inheritance (desabilitar herança).
Neste ponto, você será solicitado para converter as permissões herdadas em

permissões explícitas ou remover todas as permissões herdadas do objeto começar com uma
lousa em branco permissões.
Restaurar de herança padrão

Depois de bloquear a herança, as alterações feitas às permissões da pasta pai já não
tem um efeito sobre as permissões para o objeto filho (e seu conteúdo) que bloqueou a
herança, a menos que você reinicie que o comportamento de uma das pastas pai,
selecionando a checkbox Replace all child objects with inheritable permissions (Substituir
todos os objetos filho com permissões herdadas) deste objeto.
Ao selecionar esta caixa de seleção, o conjunto existente de permissões na pasta atual
são propagadas para nas subpastas para todos os objetos filho na estrutura de árvore,
substituindo todas as permissões explicitamente atribuídas para esses arquivos e pastas.

Permissões efetivas
O acesso a um arquivo ou pasta é concedido com base em uma combinação de
permissões.
Quando um usuário tenta acessar um arquivo ou pasta, a permissão que se aplica
dependendo de vários fatores, incluindo:
 Permissões explicitamente definidas e herdadas que se aplicam ao usuário.
 Permissões explicitamente definidas e herdadas que se aplicam aos grupos aos quais
o usuário pertence.
 Como o usuário está acessando o arquivo ou pastas: localmente ou através da rede.
As permissões NTFS efetivas atribuídas a um usuário são cumulativas para um

arquivo ou pasta com base nos fatores listados acima. Os seguintes princípios determinam
uma atribuição eficaz de permissões NTFS:
 Permissões cumulativas são a combinação das permissões NTFS mais altas para o
usuário e para todos os grupos dos quais o usuário é membro. Por exemplo, se um
usuário é membro de um grupo que tem permissão de “leitura” e é membro de um
grupo que tem permissão “modificar”, o usuário terá permissões “modificar” de forma
cumulativa.
 Permissão de “negar” substitui as permissões de “permitir”. No entanto, uma

permissão “permitir” explícita pode substituir uma permissão herdada de “negar”. Por
exemplo, se um usuário é negado acesso de gravação para uma pasta através de um
uma permissão “negar” herdada, mas é explicitamente concedido acesso de gravação
para uma subpasta ou um arquivo particular, o “permitir explícito” substitui o “negar
herdado” para a subpasta ou arquivo específico.
 Você pode aplicar permissões a um usuário ou a um grupo. Atribuir permissões a

grupos é o desejável, porque eles são mais eficientes para gerenciar permissões que
são definidas para muitas pessoas.
 As permissões NTFS de arquivo tem prioridade sobre as permissões de pasta. Por

exemplo, se um usuário tem permissão de leitura para uma pasta, mas foi concedida
a permissão “modificar” para determinados arquivos nessa pasta, a permissão efetiva
para esses arquivos será definido para “modificar”.
 Cada objeto em uma unidade NTFS ou nos Serviços de Domínio Active Directory (AD
DS) é de propriedade. O proprietário controla como as permissões são definidas no
objeto e para quem as permissões são concedidas. Por exemplo, um usuário que cria
um arquivo em uma pasta onde eles têm permissões de “modificar” pode alterar as
permissões do arquivo para “controle total”.

Verificar Permissões Efetivas

A ferramenta de permissões efetivas mostra as permissões NTFS que estão de fato
sendo aplicadas sobre um arquivo ou pasta de um usuário, com base em permissões
atribuídas à conta de usuário e grupos aos quais pertence a conta de usuário. Você pode
acessar a ferramenta de permissões efetivas da seguinte forma:
1. Clique com o botão direito do mouse no arquivo ou pasta para a qual você quer
analisar as permissões, e clique em Properties (propriedades).
2. Na caixa de diálogo Propriedades, clique no botão Advanced (avançado).
3. Na janela Advanced Security Settings (configurações avançadas de segurança), clique

na guia Effective Permissions (permissões efetivas).
4. Escolha um usuário ou grupo para avaliar utilizando o botão Select.
Acess-Based Enumeration
Com a Acess Based Enumeration (enumeração baseada em acesso), os usuários
veem apenas os arquivos e pastas que têm permissão para acessar. Tornando mais fácil para
os usuários a encontrar os arquivos que eles precisam.
Habilitando Access-Based Enumeration

Para habilitar a enumeração baseada em acesso em uma pasta compartilhada:
1. Abra o Server Manager.
2. No painel de navegação, clique File and Storage Services (serviços de arquivo e

armazenamento).
3. No painel de navegação, clique Shares (compartilhamentos).
4. No painel de compartilhamento, botão direito do mouse no diretório onde você deseja

habilitar o access-based enumeration, e clique em Properties (propriedades).
5. Na janela de propriedades, clique em Settings (configurações), e marque a checkbox

Enable access-based enumeration.
Esta configuração é única para cada pasta compartilhada no servidor.
Cópias de sombra (shadow copy)

Você pode usar as cópias de sombra para restaurar versões anteriores de arquivos e
pastas. É muito mais rápido para restaurar uma versão anterior de um arquivo a partir de uma
cópia de sombra do que de uma cópia de backup tradicional, que pode ser armazenado
externamente. Arquivos e pastas podem ser recuperados pelos administradores, ou
diretamente pelos usuários finais.

O que são Cópias Sombra?

Uma cópia de sombra é uma imagem estática (ou um snapshot) de um conjunto de
dados, como um arquivo ou pasta. As cópias de sombra fornecem a capacidade de recuperar
arquivos e pastas com base em “fotos” que são tiradas de discos de armazenamento. Depois
de um snapshot é tomado, você pode visualizar e potencialmente restaurar versões anteriores
de arquivos e pastas que existiam no momento em que o instantâneo foi tirado.
Uma cópia de sombra não faz uma cópia completa de todos os arquivos para cada
foto. Em vez disso, depois de um snapshot é tomado, o Windows acompanha as mudanças
para a unidade. Uma quantidade específica de espaço em disco é reservado para
acompanhar os blocos de disco alterados.
Por padrão, os blocos de disco alterados são armazenados na mesma unidade que o
arquivo original, mas você pode modificar esse comportamento. Você também pode definir a
quantidade de espaço em disco é alocado para cópias de sombra. Vários snapshots são
retidos até que o espaço em disco alocado fique cheia, quando isso ocorre os snapshots mais
antigos são removidos para dar espaço aos mais novos. A quantidade de espaço de disco
que é usado por um snapshot é baseada no tamanho das variações de disco entre os
snapshots.
Importante: Já que um snapshot não é uma cópia completa dos arquivos, você não
pode usar as cópias de sombra como um substituto para backups tradicionais. Se o disco que
contém uma unidade for perdido ou danificado, então as fotos de que a unidade também estão
perdidos.

As cópias de sombra são adequados para a recuperação de arquivos de dados, mas

não para os dados mais complexos (como bancos de dados), que precisam ser logicamente
consistentes antes de um backup é realizado.
Considerações para agendar cópias de sombra

O agendamento padrão para a criação de cópias de sombra é de segunda a sexta-
feira às 07:00, e novamente ao meio-dia. Você pode modificar a programação padrão, como
desejado para sua organização.
Ao agendar cópias de sombra:
 Considere que o aumento da frequência de cópias de sombra aumenta a carga no

servidor. Como uma prática recomendada, você não deve agendar cópias de sombra
mais de uma vez por hora.
 Aumentar a frequência das cópias de sombra para mudança frequente de dados. Isso
aumenta a probabilidade de que as mudanças de arquivos recentes são capturados.
 Aumentar a frequência das cópias de sombra para dados importantes. Isso aumenta
a probabilidade de que as mudanças de arquivos recentes seja capturado.
Restaurando dados de cópias de sombra

Versões anteriores de arquivos podem ser restaurados por usuários ou

administradores. A maioria dos usuários não estão cientes de que eles podem fazer isso, e
eles vão precisar de instruções sobre como restaurar uma versão anterior de um arquivo.
Os administradores podem acessar versões anteriores de arquivos diretamente no

servidor que armazena os arquivos.
Os usuários podem acessar versões anteriores de arquivos através da rede a partir de

um compartilhamento. Em ambos os casos, as versões anteriores são acessadas a partir da
caixa de arquivo ou pasta de diálogo Properties (Propriedades). Os administradores podem
restaurar versões anteriores de arquivos diretamente no servidor, enquanto os usuários
podem restaurar versões anteriores de arquivos e pastas compartilhados que podem ser
acessadas através da rede.
Ao visualizar versões anteriores de uma pasta, você pode procurar os arquivos

disponíveis e selecionar apenas o arquivo que você precisa. Se houver várias versões de
arquivos estão disponíveis, você pode revisar cada versão antes de decidir qual a restaurar.
Finalmente, você pode copiar uma versão anterior de um arquivo para um local alternativo,
em vez de restaurá-lo à sua localização anterior. Isso evita que substituindo a versão do
arquivo atual.
Windows XP com Service Pack 2 (SP2) ou mais recente, o Windows Vista, e Windows
são capazes de acessar as versões anteriores de arquivos sem instalar qualquer software
adicional. A capacidade de acessar as versões anteriores do arquivo não é suportado em
sistemas operacionais Windows anteriores ao Windows XP com SP2.

1.2. DHCP
O protocolo DHCP simplifica a configuração de clientes IP em um ambiente de rede.

Sem o uso de DHCP, cada vez que você adicionar um cliente a uma rede, você tem que
configurá-lo com informações sobre a rede em que você instalou, incluindo o endereço IP,
máscara de sub-rede da rede e o gateway padrão para acesso a outras redes.
Quando você precisa gerenciar vários computadores em uma rede, gerenciá-los

manualmente pode se tornar um processo demorado. Muitas empresas gerenciam milhares
de dispositivos do computador, incluindo computadores de mesa, notebooks e outros
dispositivos móveis. Não é viável para gerenciar manualmente as configurações de IP de rede
para as organizações deste tamanho.
Com a função de servidor DHCP, você pode ajudar a garantir que todos os clientes
têm informações de configuração adequada, o que ajuda a eliminar o erro humano durante a
configuração. Quando principais informações de configuração alterações na rede, você pode
atualizá-lo usando a função de servidor DHCP, sem ter que alterar as informações diretamente
em cada computador.
DHCP também é um serviço essencial para usuários móveis que mudam de redes
muitas vezes. DHCP permite que os administradores de rede para oferecer informações de
configuração de rede complexa para usuários não técnicos, sem que os usuários tenham que
lidar com os detalhes de configuração de rede.
As configurações DHCP versão 6 (v6) stateful e stateless são suportadas para a

configuração de clientes em um ambiente IPv6. Configuração com estado ocorre quando o
servidor DHCPv6 atribui o endereço IPv6 para o cliente, juntamente com os dados DHCP
adicionais. Configuração Stateless ocorre quando o roteador de sub-rede atribui o endereço
IPv6 automaticamente e o servidor DHCPv6 apenas atribui outras definições de configuração
IPv6.
Você pode instalar o DHCP como um papel em uma instalação Server Core do
Windows Server 2012. A instalação do Server Core permite que você crie um servidor com
uma superfície de ataque reduzida. Para gerenciar o DHCP do Server Core, você deve instalar
e configurar a partir da interface de linha de comando. Você também pode gerenciar a função
de DHCP em execução na instalação Server Core do Windows Server 2012 a partir de uma
interface gráfica do usuário (GUI) baseada em console onde o papel DHCP estiver instalado
DHCP e alocação de endereços IP
DHCP atribui endereços IP de forma dinâmica, também conhecido como um contrato

de locação. Embora você possa definir a duração da concessão para Ilimitado, você
normalmente define a duração de algumas horas ou dias. O tempo de concessão padrão para
clientes com fio é de oito dias e, para clientes sem fio que é de três dias.

DHCP usa transmissões de IP para iniciar comunicações. Portanto, os servidores

DHCP são limitadas a comunicação dentro de sua sub-rede IP. Isto significa que, em muitas
redes, existe um servidor DHCP para cada sub-rede IP.
Para um computador ser considerado um cliente DHCP, tem que estar configurado
para obter um endereço IP automaticamente. Por padrão, cada computador está configurado
para obter um endereço IP automaticamente. Em uma rede em que um servidor DHCP está
instalado, um cliente DHCP irá responder a uma transmissão DHCP.
Se um computador está configurado com um endereço IP por um administrador, de

que o computador tem um endereço IP estático e é considerado um cliente não-DHCP, e não
irá se comunicar com um servidor DHCP.
Lease DHCP (concessão de configurações IP)

Você pode usar o processo de geração de locação de quatro etapas DHCP para
atribuir um endereço IP para os clientes. Compreender como funciona cada etapa ajuda a
solucionar problemas quando os clientes não podem obter um endereço IP. Os quatro passos
são como se segue:

1. O cliente DHCP transmite um pacote DHCPDISCOVER para todos os computadores

na sub-rede. Apenas um computador que tenha a função de servidor DHCP ou um
computador ou roteador que está executando um agente de retransmissão DHCP
responde. Neste último caso, o agente de transmissão DHCP encaminha a mensagem
para o servidor de DHCP com o qual está configurado.
2. Um servidor DHCP responde com um pacote DHCPOFFER. Este pacote contém um

endereço uma sugestão de para o cliente.
3. O cliente recebe o pacote DHCPOFFER. Ele pode receber pacotes de vários

servidores e, nesse caso, ele geralmente escolhe o servidor que respondeu mais
rapidamente ao DHCPDISCOVER. O cliente então transmite um DHCPREQUEST que
contém um identificador do servidor.
4. O servidor DHCP recebe o DHCPREQUEST. O servidor escolhido armazena as

informações de endereço IP do cliente no banco de dados DHCP e responde com uma
mensagem DHCPACK. Se por algum motivo, o servidor DHCP não pode fornecer o
endereço que foi oferecido no DHCPOFFER inicial, o servidor DHCP envia uma
mensagem DHCPNAK.

Renovação do Lease de DHCP
Quando a concessão DHCP atinge 50% do tempo de concessão, o cliente tenta

renovar a concessão. Este processo automático ocorre em segundo plano. Computadores
podem ter o mesmo endereço IP que foi atribuído pelo servidor DHCP por um longo período.
Para renovar a concessão de endereços IP, o cliente transmite uma mensagem
DHCPREQUEST. O servidor que alugou o endereço IP originalmente envia uma mensagem
DHCPACK volta para o cliente, esta mensagem contém quaisquer novos parâmetros que
foram alterados desde o contrato original foi criado.
Se o cliente DHCP não pode contatar o servidor DHCP, o cliente espera até 87,5% do
tempo de concessão expirar. Se a renovação não for bem sucedida, o que significa 100% do
tempo de concessão expirou, em seguida, o computador cliente tenta entrar em contato com
o gateway padrão configurado. Se o gateway não responde, o cliente assume que ele está
em uma nova sub-rede e entra na fase de descoberta, onde se tenta obter uma configuração
de IP de qualquer servidor DHCP.
Os computadores cliente também tenta a renovação durante o processo de

inicialização. Isto ocorre porque os computadores cliente podem ter sido movidos enquanto
estavam offline, por exemplo, um computador portátil pode ser ligado a uma nova sub-rede.
Se a renovação for bem sucedida, o período de locação é zerado. A função DHCP no
Windows Server 2012 oferece suporte a um novo recurso, o protocolo DHCP Failover Server.
Este protocolo permite a sincronização de informações de concessão entre os servidores
DHCP e aumenta a disponibilidade do serviço de DHCP. Se um servidor DHCP não estiver
disponível, os outros servidores DHCP continuam a servir os clientes na mesma sub-rede.

DHCP Relay Agent

DHCP usa transmissões de IP para iniciar comunicações. Portanto, os servidores
DHCP são limitadas a comunicação dentro de sua sub-rede IP. Isto significa que, em muitas
redes, existe um servidor DHCP para cada sub-rede IP. Se houver um grande número de sub-
redes, pode ser caro para implantar servidores para cada sub-rede. Um único servidor DHCP
pode servir coleções de sub-redes menores. Para o servidor de DHCP para responder a uma
solicitação do cliente DHCP, ele deve ser capaz de receber solicitações de DHCP. Você pode
ativar isso configurando um agente de retransmissão DHCP (DHCP Relay) em cada sub-rede.
Um agente de retransmissão DHCP é um computador ou roteador que escuta broadcast de
cliente DHCP e repassa para os servidores DHCP em sub-redes diferentes
Com o agente de retransmissão DHCP, os pacotes de broadcast de DHCP pode ser

retransmitida em outra sub-rede IP através de um roteador. Depois, você pode configurar o
agente de retransmissão DHCP (DHCP Relay) na sub-rede que requer endereços IP. Além
disso, você pode configurar o agente com o endereço IP do servidor DHCP. O agente pode,
então, capturar as transmissões de clientes e encaminhá-los para o servidor DHCP em outra
sub-rede.

Autorização de servidor DHCP
DHCP permite que que um computador cliente obtenha informações sobre a

configuração de rede em que ele começa. Comunicação DHCP normalmente ocorre antes de
qualquer autenticação do usuário ou do computador, e porque o protocolo DHCP é baseado
em transmissões IP, um servidor de DHCP configurado incorretamente em uma rede pode
fornecer informações inválidas para os clientes. Para evitar isso, o servidor deve ser
autorizado. Autorização DHCP é o processo de registrar o serviço de Servidor DHCP no
domínio do Active Directory para suportar os clientes DHCP.
Escopos de DHCP

Um escopo DHCP é um intervalo de endereços IP que estão disponíveis para locação,

e que são gerenciados por um servidor DHCP. Um escopo DHCP normalmente está limitado
aos endereços IP em uma determinada sub-rede.
Por exemplo, um escopo DHCP para a rede 192.168.1.0/24 (máscara de sub-rede
255.255.255.0), suporta um range de 192.168.1.1 até 192.168.1.254. Quando um computador
ou dispositivo no requisitou um endereço IP de sub-rede 192.168.1.0/24, o escopo deste
exemplo irá alocar um endereço entre 192.168.1.1 e 192.168.1.254
Nota: Lembre-se que o servidor DHCP, se implantado na mesma sub-rede, consome

um endereço IPv4. Este endereço deve ser excluído a faixa de endereços IPv4.
Para configurar um escopo, você deve definir as seguintes propriedades:

 Name and description. Essa propriedade identifica o escopo.
 IP address range. Esta propriedade relaciona o intervalo de endereços que podem

ser oferecidos para locação, e, geralmente, apresenta o range de endereços para uma
determinada sub-rede.
 Subnet mask. Esta propriedade é usada por computadores clientes para determinar
sua localização em infraestrutura de rede da organização.
 Exclusions. Esta propriedade relaciona os endereços individuais ou blocos de

endereços que caem dentro do intervalo de endereços IP, mas isso não será oferecido
para o lease (alocação).

 Delay. Esta propriedade é a quantidade de tempo de atraso antes de fazer

DHCPOFFER.
 Lease duration. Esta propriedade relaciona a duração lease (concessão). Use

períodos mais curtos para escopos com endereços IP limitados e maior duração para
redes mais estáticos.
 Options. Você pode configurar várias propriedades opcionais em um escopo, mas

normalmente você vai configurar:
o opção 003 – Router (o default gateway para a subnet)
o opção 006 – Domain Name System (DNS) servers
o opção 015 – DNS suffix
Reserva de DHCP
Como uma prática recomendada, você deve considerar o fornecimento de dispositivos
de rede, tais como impressoras de rede com um endereço IP predeterminado. Usando uma
reserva DHCP, você pode garantir que os endereços IP que você definiu para além de um
espaço configurado para não são atribuídos a outro dispositivo. A reserva de DHCP é um
endereço de IP específico dentro de um escopo que é reservada permanentemente para
locação para um cliente DHCP específico. A reserva DHCP também garante que os
dispositivos com reservas teu seu endereço de IP garantido mesmo se um escopo está
esgotado de endereços. Configurando reservas permite centralizar o gerenciamento de
endereços IP fixos.
Opções de DHCP

Os servidores DHCP pode configurar mais do que apenas um endereço IP, mas
também fornece informações sobre os recursos de rede, como servidores DNS e gateway
padrão. Um código de opção identifica as opções DHCP, e a maioria dos códigos de opção
vem da documentação RFC encontrado na Internet Engineering Task Force (IETF).
Common DHCP Options

A tabela a seguir lista os códigos de opção comum que os clientes baseados no
Windows DHCP pedido.
Código da Nome
Opção
1 Subnet mask
3 Router
6 DNS servers
15 DNS domain name
44 WINS/NBNS servers (Windows Internet Naming Service/NetBIOS Name Service)
46 WINS/NetBT node type (WINS/NetBIOS over TCP/IP)
47 NetBIOS scope ID
51 Lease time
58 Renewal (T1) time value
59 Rebinding (T2) time value
31 Perform router discovery
33 Static route
43 Vendor-specific information
249 Classless static routes
Como as opções de DHCP são aplicadas

DHCP aplica opções para computadores cliente na seguinte ordem:
1. Server level. A opção de nível de servidor é atribuído a todos os clientes DHCP do
servidor DHCP.
2. Scope level. A opção de nível de escopo é atribuído a todos os clientes de um escopo.
3. Class level. A opção de nível de classe é atribuído a todos os clientes que se

identificam como membros de uma classe.
4. Reserved client level. A opção de nível de reserva é atribuído a um cliente DHCP.


1.3. DNS
Fornece resolução de nomes e permite que clientes DNS localizem serviços da rede,
como controladores de domínio (Active Directory), servidores de catálogo global, servidores
de arquivos e servidores de mensagem, entre outros. Se você configurar a infraestrutura do
DNS incorretamente, ou ele não estiver funcionando corretamente, esses serviços de rede
importantes serão inacessíveis.
Visão geral da função DNS

O DNS é um serviço de resolução de nomes que resolve nomes para endereços IP. O
serviço DNS é um banco de dados distribuído, hierárquico, logicamente separado que permite
que muitos servidores diferentes hospedem um banco de dados mundial de nomes DNS.
DNS e a Internet
O DNS é um serviço mundial que permite digitar um nome de domínio (por exemplo,
sisnema.com.br) que o computador resolve para um endereço IP. Um benefício de DNS é que
endereços IPv4 podem ser longos e difíceis de lembrar, como 201.86.237.83. Porém, um
nome de domínio costuma ser mais fácil de lembrar. Além disso, é possível usar nomes de
host que não se alteram, mesmo que o endereço de IP modifique.
Com a adoção do IPv6, o DNS se tornará ainda mais crítico porque os endereços IPv6
são ainda mais complexos do que endereços IPv4. Um exemplo de um endereço IPv6 é
2001:db8:4136:e38c:384f:3764:b59c:3d97.

DNS e o AD DS
O DNS é responsável por resolver recursos em um domínio do AD DS. A função DNS
é um pré-requisito para instalar o AD DS. O DNS fornece informações aos clientes da estação
de trabalho, que permitem a entrada na rede. O DNS resolve recursos no domínio, como
servidores, estações de trabalho, impressoras e pastas compartilhadas. Se você configurar
um servidor DNS incorretamente, ele poderá ser a origem de muitos problemas no AD DS.
Visão geral do Namespace

O namespace DNS facilita a maneira como um resolvedor de DNS localiza um
computador. O namespace é organizado em hierarquias para distribuir informações entre
vários servidores.
DNS Namespace
Domínio raiz
Um ponto (.) representa o domínio raiz e você não o digita em um navegador da Web.
O ponto (.) é pressuposto. Na próxima vez em que você digitar um endereço em um
computador, tente adicionar um ponto ao final (por exemplo, www.microsoft.com.). Existem
13 servidores de domínios raiz no mundo inteiro.
Domínio Raiz .
Domínio de
primeiro nível net com org
Domínio de
segundo nível google
Subdominio
america
server1
FQDN: server1.america.google.com.
Observação: Durante a solução de problemas de DNS, é comum especificar o ponto

à direita.

Domínio de primeiro nível

O TLD (Top Level Domain [domínio de primeiro nível]) é o primeiro nível do namespace
DNS (espaço de nome DNS). Entre os exemplos de TLDs na Internet estão .com, .net, .org,
.biz e .ca. Os domínios mais reconhecidos são .com, .net, .org e .gov, para o governo norte-
americano dos Estados Unidos. Há vários mais nomes de domínios nesse nível e existe um
TLD para cada país. Por exemplo, o TLD do Canadá é .ca, e o TLD do Reino Unido é .uk. A
organização que regulamenta nomes de domínios, conhecida como ICANN (Internet
Corporation for Assigned Names and Numbers), adiciona novo TLDs ocasionalmente.
Domínio de segundo nível

O nome de domínio de segundo nível é a parte do nome do domínio que vem antes
do TLD. Um exemplo de nome de domínio de segundo nível é “google” no domínio
america.google.com. As organizações que registram nomes de domínio de segundo nível
controlam esses nomes. Qualquer pessoa pode registrar um nome de domínio de segundo
nível através de serviço um registro da Internet. Vários domínios de segundo nível têm regras
especiais sobre organizações ou pessoas que podem registrar um nome de domínio. Por
exemplo, somente as organizações sem fins lucrativos podem utilizar o domínio .org.
Subdomínio
O subdomínio aparece antes dos domínios de nível superior e de segundo nível. Um
exemplo de subdomínio é “america” no nome de domínio america.google.com. Os
subdomínios são definidos no servidor DNS da organização que mantém o servidor DNS de
segundo nível.
Nome de Domínio Totalmente Qualificado

Um FQDN (Fully Qualified Domain Name [nome de domínio totalmente qualificado]) é
o nome DNS explícito, que contém o nome do host e os subdomínios para o domínio raiz. Por
exemplo, se o computador for designado como “server1” no domínio america.google.com, o
FQDN desse computador será server1.america.google.com.
Padrões de nomenclatura DNS

Os seguintes caracteres são válidos para nomes DNS:
 A-Z
 a-z
 0-9
 Hífen (-)
Observação: O sublinhado (_) é um caractere reservado.
Integração do AD DS e do DNS

Ao começar a planejar o namespace DNS, você deve considerar os namespaces

interno e externo.
O namespace interno é o usado por clientes internos e servidores dentro da rede
privada.
O namespace externo é o utilizado pela na Internet. Não há requisito de que você deva
implementar o mesmo nome de domínio DNS interna e externamente.
Ao implementar o AD DS, você deve usar um namespace DNS para hospedar registros
do AD DS.
Observação: Considere as opções com cuidado para selecionar um design de

namespace para o AD DS. Embora seja possível alterar um namespace depois de
implementar o AD DS, trata-se de um processo demorado e complexo com muitas limitações.
 Para determinar um namespace DNS para o ambiente do AD DS, é possível optar

pelos seguintes cenários:
 Deixe o namespace interno igual ao namespace público. Nesse cenário, os

namespaces internos e públicos são iguais, mas terão registros diferentes. Embora
isso ofereça simplicidade, pode ser difícil gerenciá-lo em redes maiores.
 Deixe o namespace interno diferente do namespace público. Nesse cenário, os

namespaces internos e públicos são completamente diferentes, sem vínculo entre
eles. Isso proporciona a separação óbvia no namespace. Em redes complexas, com
muitos aplicativos para Internet, o uso de um nome diferente pode facilitar um pouco
durante a configuração desses aplicativos. Por exemplo, servidores de borda
colocados em uma rede de perímetro costumam exigir várias placas de rede: uma
conectada à rede privada e uma atendendo a solicitações da rede pública. Se cada
placa de interface de rede tiver um nome de domínio diferente, normalmente será mais
fácil configurar desse servidor.
 Torne o namespace interno um subdomínio do namespace público. Nesse cenário, o

namespace interno é vinculado ao namespace público, mas não há sobreposição entre
eles. Isso fornece uma abordagem híbrida. O nome interno é diferente, o que
possibilita a separação do namespace.
Porém, o nome interno também está relacionado ao nome público, o que garante
simplicidade. Essa abordagem pode ser mais simples gerenciar dependendo do perfil do
administrador. Porém, se não puder usar um subdomínio do namespace público para AD DS,
você deverá usar namespaces exclusivos.
Observação: Na maioria das situações, computadores dentro de um domínio do AD

DS têm um sufixo DNS primário que corresponde ao nome de domínio DNS. Ocasionalmente,
talvez você precise que esses nomes sejam diferentes, como depois de uma fusão ou durante

uma aquisição. Quando os nomes são diferentes, isso é conhecido como um namespace não
contíguo.
Um cenário de namespace não contíguo é aquele no qual o sufixo DNS primário de

um computador não corresponde ao nome de domínio DNS no qual esse computador reside.
Diz-se que o computador com o sufixo DNS primário não correspondente deve ser não
contíguo. Outro cenário de namespace não contíguo ocorrerá se o nome de domínio do
NetBIOS de um controlador de domínio não corresponder ao nome de domínio do DNS.
Integração do Active Directory

A função DNS do Windows Server pode armazenar o banco de dados DNS de duas
maneiras diferentes, conforme mostra a tabela a seguir.
Método de armazenamento Descrição
Arquivo de texto A função Servidor DNS armazena as entradas DNS em

um arquivo de texto, que você pode editar com um editor
de texto.
Active Directory A função Servidor DNS armazena as entradas DNS no
banco de dados do Active Directory, replicado para
outros controladores de domínio. Não é possível utilizar
um editor de texto para editar os dados DNS
armazenados no Active Directory.
As zonas integradas do Active Directory são mais fáceis de gerenciar do que as zonas
baseadas em texto tradicionais, além de serem mais seguras. A replicação dos dados da zona
ocorre como parte da replicação do Active Directory.

Componentes de uma solução DNS

Entre os componentes de uma solução DNS estão servidores DNS, servidores DNS
na Internet e clientes DNS.
Servidores DNS
Um servidor DNS responde a consultas DNS recursivas e iterativas. Os servidores
DNS também podem hospedar uma ou mais zonas de um domínio específico. As zonas
contêm diferentes registros de recursos. Os servidores DNS também podem armazenar as
pesquisas em cache para reservar tempo para as consultas comuns.
Servidores DNS na Internet

Os servidores DNS na Internet estão acessíveis ao público. Eles hospedam
informações de zonas públicas e do servidor raiz, além de outros TLDs comuns, como .com,
.net e .edu.
Observação: Não confunda esses servidores com os servidores DNS da organização

que hospedam o namespace público. Eles estão localizados fisicamente na rede de perímetro
(rede da empresa).

Clientes de DNS
O clientes de DNS ou resolver gera e envia consultas iterativas ou recursivas ao
servidor DNS. Um resolver de DNS pode ser qualquer computador que executa uma pesquisa
de DNS que exige interação com o servidor DNS. Os servidores DNS também podem emitir
consultas DNS para outros servidores DNS.
Consultas de DNS
Uma consulta DNS é o método usado para solicitar a resolução de nomes, além de
envolver uma consulta enviada a um servidor DNS. Existem dois tipos de resposta às
consultas DNS: autoritativa e não autoritativa.
É importante observar que servidores DNS também podem atuar como resolvers de
DNS e enviar consultas DNS a outros servidores DNS.
Um servidor DNS têm autoridade ou não sobre o namespace da consulta. Um servidor

DNS é autoritativo quando hospeda uma cópia primária ou secundária de uma zona DNS.
Existem dois tipos de consultas:
 Uma consulta autoritativa é aquela para a qual o servidor pode retornar uma resposta
que ele sabe estar correta, pois a solicitação é direcionada ao servidor autoritativo que
gerencia o domínio.
 Um servidor DNS que contém no cache o domínio que é solicitado, responde a uma
consulta não autoritativa usando encaminhadores ou root hints (dicas de raiz). No

entanto, a resposta fornecida pode não ser exata, uma vez que somente o servidor
DNS com autoridade sobre o domínio especificado pode emitir essa informação.
Se o servidor DNS tiver autoridade sobre o namespace da consulta, o servidor DNS

verificará a zona e executará um dos seguintes procedimentos:
 Retornará o endereço solicitado.
 Retornará uma resposta autoritativa, "Não, esse nome não existe".
Observação: Uma resposta autoritativa só pode ser dada pelo servidor com
autoridade direta para o nome consultado.
Se for não autoritativo para o namespace da consulta, o servidor DNS local realizará
um dos seguintes procedimentos:
 Verificar o cache e retornar uma resposta armazenada nesse cache.
 Encaminhar a consulta não resolvida para um servidor específico conhecido como um

forwarder (encaminhador).
 Usará endereços conhecidos de diversos servidores raiz para encontrar um servidor

DNS autoritativo que resolva a consulta. Esse processo usa dicas de raiz.
Consultas recursivas
Uma consulta recursiva pode ter dois resultados possíveis:
 Retorna o endereço IP do host solicitado.
 O servidor DNS não pode resolver um endereço IP.
Por motivos de segurança, às vezes, é necessário desabilitar consultas recursivas em

um servidor DNS. Isso impede o servidor DNS em questão de encaminhar as solicitações
DNS para outro servidor. Isso pode ser útil para impedir que determinado servidor DNS se
comunique fora da própria rede local.
Consultas iterativas
As consultas iterativas oferecem um mecanismo para acessar informações de nome
de domínio residentes no sistema DNS e habilitam servidores para resolver nomes de maneira
rápida e eficiente em vários servidores. Ao receber uma solicitação que não pode ser
respondida com as informações locais ou com as pesquisas armazenadas no cache, um
servidor DNS repassa essa solicitação para outro servidor DNS usando uma consulta iterativa.
Ao receber uma consulta iterativa, um servidor DNS pode responder com o endereço
IP do nome do domínio (se for conhecido) ou com uma referência aos servidores DNS
responsáveis pelo domínio que está sendo consultado.

Registros de recursos DNS

O arquivo de zona DNS armazena registros de recurso. Registros de recursos
especificam um tipo de recurso e o endereço IP para localizar o recurso. O registro de recurso
mais comum é o registro de recurso “A”. Ele é um registro simples que resolve um nome de
host para um endereço IP. O host pode ser uma estação de trabalho, um servidor ou outro
dispositivo de rede, como um roteador.
Os registros de recursos também ajudam a encontrar recursos para um domínio

específico. Por exemplo, quando precisar encontrar o servidor responsável por entregar o e-
mail para outro domínio, um Exchange Server solicitará o registro MX (Servidor de
mensagens) desse domínio, apontando para o registro A do host que está executando o
serviço de e-mail SMTP.
Os registros de recurso também podem conter atributos personalizados. Por exemplo,

os registros MX têm um atributo de preferência, que será útil se uma organização tiver vários
servidores de e-mail. Isso informará ao servidor emissor o servidor de correio preferencial da
empresa que está recebendo a solicitação. Os registros SRV (localizador de serviço) também
contêm informações sobre a porta que está sendo escutada pelo serviço e sobre o protocolo
que você deve usar para se comunicar com o serviço.
A tabela a seguir descreve os registros de recursos mais comuns.
Registros de recurso DNS Descrição
Registro de recurso SOA O registro identifica o nome do servidor principal para uma
(início de autoridade) zona DNS, bem como outros detalhes específicos, como
TTL (Time To Live [tempo de vida]) e atualização.

Registros de recurso DNS Descrição
Registro do recurso Endereço O principal registro que resolve um nome de host para um
do host (A) endereço IPv4.
Registro do recurso Nome Um tipo de registro de alias que mapeia um nome para
canônico (CNAME) outro (por exemplo, www.sisnema.com é um CNAME do
registro A sisnema.com).
Registro do recurso MX O registro é usado para especificar um servidor de e-mail
de um domínio específico.
Registro do recurso SRV O registro identifica um serviço disponível no domínio. O
Active Directory usa muito esses registros.
Registro do recurso NS O registro identifica um servidor de nomes para um
(servidor de nomes) domínio.
AAAA O principal registro que resolve um nome de host para um
endereço IPv6.
Registro do recurso PTR O registro é usado para pesquisar e mapear um endereço
(ponteiro) IP para um nome de domínio. A zona de pesquisa inversa
armazena os nomes.
Root hints
Os root hints (dicas de raiz) são a lista dos servidores na Internet que o servidor DNS
utiliza, caso ele não consiga resolver uma consulta DNS usando um (forwarder
(encaminhador) de DNS ou o próprio cache. As dicas de raiz são os servidores mais
importantes na hierarquia do DNS e podem fornecer as informações necessárias para um
servidor DNS fazer uma pesquisa iterativa para a próxima camada mais inferior do namespace
DNS.

Os servidores raiz são instalados automaticamente quando você instala a função DNS.
Eles estão no arquivo cache.dns incluído nos arquivos de instalação da função DNS.
Também é possível adicionar dicas de raiz em um servidor DNS para dar suporte a
pesquisas de domínios não contíguos em uma floresta.
Ao se comunicar com um servidor de dicas de raiz, um servidor DNS usa somente

uma consulta iterativa. Se você marcar a opção “Não usar recursão neste domínio”, o servidor
não poderá fazer consultas sobre dicas de raiz. Se você configurar o servidor para usar um
encaminhador, ele tentará enviar uma consulta recursiva para o respectivo servidor de
encaminhamento. Se o servidor de encaminhamento não responder a essa consulta, o
servidor responderá que não foi possível encontrar o host.
É importante compreender que a recursão em um servidor DNS e consultas recursivas

não significam a mesma coisa. Recursão em um servidor significa que esse servidor usará as
respectivas dicas de raiz e tentará resolver uma consulta DNS.
Encaminhamento de DNS
Um encaminhador é uma definição de configuração do servidor DNS que encaminha
consultas DNS de nomes DNS externos para servidores DNS fora dessa rede. Também é
possível usar encaminhadores condicionais para encaminhar consultas de acordo com nomes
de domínio específicos.
Um servidor DNS da rede é designado como um encaminhador quando outros

servidores DNS da rede encaminham para ele as consultas que não conseguiram resolver
localmente. Ao utilizar um encaminhador, você pode gerenciar a resolução de nomes fora de

sua rede, como os nomes na Internet, e melhorar a eficiência desse processo nos
computadores da rede.
O servidor que estiver encaminhando solicitações na rede deve poder se comunicar

com o servidor DNS localizado na Internet. Isso significa que você o configura para
encaminhar solicitações para outro servidor DNS ou ele utiliza as dicas de raiz para se
comunicar.
Encaminhamento condicional
Um encaminhador condicional é uma definição de configuração no servidor DNS que
encaminha consultas DNS de acordo com o nome de domínio DNS da consulta. Por exemplo,
você pode configurar um servidor DNS para encaminhar todas as consultas por ele recebidas
sobre nomes que terminam com filial.sisnema.com.br para o endereço IP de um servidor DNS
específico ou para os endereços IP de vários servidores DNS. Isso pode ser útil quando você
tem vários namespaces DNS em uma floresta.
Prática recomendada para encaminhamento condicional

Use encaminhadores condicionais, se existirem vários namespaces internos. Isso
agiliza a resolução de nomes.
Cache do servidor DNS

O cache do DNS aumenta o desempenho do sistema DNS de uma organização,
diminuindo o tempo que ele leva para fornecer pesquisas de DNS.
Ao resolver com êxito um nome DNS, um servidor DNS adiciona esse nome ao seu
cache. Com o tempo, isso cria um cache de nomes de domínio e os respectivos endereços IP
dos domínios mais comuns que a organização usa ou acessa.

Observação: O tempo padrão para armazenar dados DNS em cache é de uma hora.
É possível configurar esse recurso alterando o registro SOA da zona DNS adequada.
Um servidor somente de cache não hospedará dados de zonas DNS; apenas

responderá às pesquisas dos clientes DNS. Esse é o tipo ideal de servidor DNS para ser
utilizado como encaminhador.
O cache de cliente DNS é um cache DNS armazenado pelo serviço DNS Client (Cliente
DNS) no computador local. Para exibir o cache do lado do cliente atual, execute o comando
ipconfig /displaydns no prompt de comando. Se você precisar limpar o cache local, como
quando você está solucionando problemas da resolução de nomes, será possível usar
ipconfig /flushdns.
Também é possível usar os seguintes cmdlets do Windows PowerShell:

 clear-DnsClientCache para limpar o cache do resolvedor de DNS
 get-DnsClientCache para exibir o cache do resolvedor
Zona DNS
Uma zona DNS hospeda todo ou parte de um domínio e seus subdomínios. A imagem
abaixo mostra como os subdomínios podem pertencer à mesma zona de seus pais ou podem
ser delegados a outra zona. O domínio sisnema.com.br está dividido em duas zonas. A
primeira zona hospeda os registros www.sisnema.com.br e ftp.sisnema.com.br O
exemplo.sisnema.com.br é delegado para uma nova zona, que hospeda o subdomínio
exemplo.sisnema.com.br e os registros ftp.exemplo.sisnema.com.br e
www.exemplo.sisnema.com.br

Observação: A zona que hospeda uma raiz do domínio (sisnema.com) deve delegar
o subdomínio (exemplo.sisnema.com) à segunda zona. Se isso não ocorrer, o
exemplo.sisnema.com será considerado uma parte da primeira zona.
Os dados da zona podem ser replicados em mais de um servidor. Isso gera

redundância em uma zona, pois as informações necessárias para encontrar os recursos na
zona agora existem em dois ou mais servidores. O nível de redundância necessária é uma
razão para criar mais zonas. Se existir uma zona que hospeda os registros de recursos críticos
do servidor, é provável que essa zona tenha um nível mais alto de redundância do que outra
onde estejam definidos recursos não críticos.
Características de uma zona DNS

Os dados de zona são mantidos em um servidor DNS e são armazenados de uma
destas maneiras:
 Em um arquivo de zona simples que contém listas de mapeamentos
 Integrados ao Active Directory
Um servidor DNS terá autoridade em uma zona se ele hospedar, no arquivo de zona,
os registros de recursos dos nomes e endereços que os clientes solicitarem.
Tipos de zona DNS

Os quatro tipos de zona DNS são?
 Primária
 Secundária
 Stub
 Integrada ao-Active Directory

Zona primária
Quando uma zona hospedada por um servidor DNS é uma zona primária, o servidor
DNS é a fonte principal de informações sobre essa zona e armazena uma cópia mestra dos
dados da zona em um arquivo local ou no AD DS. Quando o servidor DNS armazena a zona
em um arquivo, o arquivo de zona primária é, por padrão, denominado nome_da_zona.dns e
está localizado na pasta %windir%\System32\Dns no servidor. Quando a zona não é
armazenada no Active Directory, o servidor DNS que hospeda a zona primária é o único
servidor DNS que tem uma cópia gravável do arquivo da zona.
Zona secundária
Quando uma zona hospedada em um Servidor DNS é uma zona secundária, o
Servidor DNS é uma fonte secundária de informações da zona. A zona contida nesse servidor
deve ser obtida em outro servidor DNS remoto que também a hospeda. O servidor DNS deve
ter acesso via rede ao servidor DNS remoto para receber informações atualizadas da zona.
Como uma zona secundária é uma cópia de uma zona primária hospedada em outro servidor,
ela não pode ser armazenada no AD DS. As zonas secundárias poderão ser úteis se você
estiver replicando dados de zonas DNS que não estejam no Windows ou executando o DNS
em servidores que não sejam controladores de domínio do AD DS.
Zona de stub
Uma zona de stub é uma cópia de uma zona que só contém os registros de recursos
necessários para identificar os servidores DNS autoritativos para a zona. Uma zona de stub é
usada para resolver nomes entre espaços para nome de DNS separados. Este tipo de
resolução pode ser necessária quando uma fusão para empresas exigir que os servidores
DNS de dois espaços para nome de DNS separados resolvam nomes para clientes em ambos
os espaços para nome.
Uma zona de stub inclui:
 O registro de recurso do SOA (início de autoridade), os registros de recursos de NS
(servidor de nomes) e os registros de recursos A de união para a zona delegada.
 O endereço IP de um ou mais servidores mestres que podem ser usados para atualizar
a zona de stub.
Zona integrada ao Active Directory

Se o Active Directory armazenar a zona, o DNS poderá aproveitar o modelo de
replicação de vários mestres para replicar a zona primária. Isso permite editar dados da zona
em qualquer servidor DNS.
Zonas de pesquisa direta e inversa

As zonas podem ser diretas ou inversas.
Zona de pesquisa direta

A zona de pesquisa direta resolve nomes de host para endereços IP e hospeda os
registros comuns de recursos: A, CNAME, SRV, MX, SOA, TXT e NS.

Zona de pesquisa inversa

A zona de pesquisa inversa resolve um endereço IP para um nome de domínio e
hospeda registros SOA, NS e PTR.
Uma zona inversa funciona da mesma maneira que uma zona direta, mas o endereço
IP faz parte da consulta e o nome do host é a informação retornada. Nem sempre as zonas
inversas são configuradas, mas você deve configurá-las para reduzir as mensagens de aviso
e de erro. Vários protocolos padrão de Internet dependem dos dados de pesquisa das zonas
inversas para validar as informações das zonas diretas. Por exemplo, se a pesquisa direta
indicar que treinamento.sisnema.com.br está resolvido para 192.168.0.222, você poderá usar
uma pesquisa inversa para confirmar se 192.168.0.222 está associado a
training.sisnema.com.
Muitos gateways de segurança de e-mail usam pesquisas inversas para verificar se

um endereço IP que envia mensagens está associado a um domínio.
Transferência de zona DNS

Uma transferência de zona ocorre quando você replica a zona DNS existente em um
servidor é transferida para outro servidor DNS. As transferências de zona sincronizam as
zonas dos servidores DNS primário e secundário. É assim que o DNS forma sua resiliência
na Internet.

É importante que as zonas DNS permaneçam atualizadas nos servidores primário e

secundário. Discrepâncias nas zonas primária e secundária podem causar interrupções de
serviço e nomes de host resolvidos incorretamente.
As transferências de zona podem acontecer de três maneiras:

 Transferência de zona plena. Uma transferência de zona completa ocorre quando a
zona inteira é copiada de um servidor DNS para outro. Uma transferência de zona
completa é conhecida como transferência de zona plena (AXFR).
 Transferência de zona incremental. Uma transferência de zona incremental ocorre

quando existe uma atualização para o servidor DNS e apenas os registros de recursos
alterados são replicados no outro servidor. Essa é uma Transferência de Zona
Incremental (IXFR).
 Transferência rápida. Os servidores DNS do Windows também realizam

transferências rápidas, que é um tipo de transferência de zona que usa a compactação
e envia diversos registros de recurso em cada transmissão.
Nem todas as implementação do servidor DNS oferecem suporte às transferências de

zona incremental e rápida. Ao integrar um servidor DNS do Windows 2012 a um servidor DNS
BIND (Berkeley Internet Name Domain), assegure-se de que, na versão do BIND instalada,
haja suporte para os recursos necessários.
Servidor DNS Zona plena (AXFR) Zona incremental Transferência

(IXFR) rápida
BIND anterior à Com suporte Sem suporte Sem suporte
versão 4.9.4
BIND 4.9.4 – 8.1 Com suporte Sem suporte Com suporte
BIND 8.2 Com suporte Com suporte Com suporte
Windows 2000 Com suporte Com suporte Com suporte
Service Pack 3 (SP3)
Windows 2003 (R2) Com suporte Com suporte Com suporte

Servidor DNS Zona plena (AXFR) Zona incremental Transferência

(IXFR) rápida
Windows 2008 e R2 Com suporte Com suporte Com suporte
Windows 2012 Com suporte Com suporte Com suporte
As zonas integradas ao Active Directory são replicadas usando-se a replicação do AD

DS de vários mestres, em vez do processo de transferência de zona. Isso significa que
qualquer controlador de domínio padrão que também tenha a função DNS pode atualizar a
informação da zona DNS que, posteriormente, replica para todos os servidores DNS que
hospedam a zona DNS.
Notificação DNS
A notificação DNS é usada por um servidor mestre para alertar os servidores
secundários configurados de que há atualizações de zona disponíveis. Em seguida, os
servidores secundários solicitam ao mestre para obter as atualizações. Uma notificação DNS
é uma atualização para a especificação de protocolo DNS original que permite a notificação
em servidores secundários quando ocorrem alterações de zona. Isso é útil em um ambiente
de detecção de hora, em que a exatidão de dados é importante.
Configuração da segurança de transferência de zona

As informações de zona fornecem dados organizacionais e, por isso, você deve tomar
precauções para garantir que estejam protegidos contra o acesso de usuários mal-
intencionados e que não possam ser gravados com dados inválidos, conhecido como
envenenamento do DNS. Uma maneira de proteger a infraestrutura do DNS é resguardando
as zonas de transferência.
Na guia Transferências de Zona da caixa de diálogo Propriedades da Zona, você

pode especificar a lista de servidores DNS permitidos. Você também pode usar essas opções
para impedir a transferência de zona. Por padrão, as transferências de zona estão
desabilitadas.

Embora a opção que especifica os servidores que podem solicitar dados da zona
forneça segurança, restringindo os destinatários dos dados, ela não protege os dados durante
transmissões. Se as informações da zona forem altamente confidenciais, é recomendável
usar uma política IPsec para proteger a transmissão ou replicar os dados da zona por um
túnel VPN (rede virtual privada). Isso impede a detecção de pacotes para determinar
informações na transmissão dos dados.
O uso de zonas integradas ao Active Directory–replica os dados da zona como parte

das replicações habituais do AD DS. A transferência de zona é protegida como parte de
replicação do AD DS.
TTL
O TTL ajuda a gerenciar registros de recursos DNS nos arquivos de zona. Os arquivos
de zona podem mudar ao longo do tempo, de modo que é necessário ter um modo de
gerenciar registros DNS que são atualizados ou que não são mais válidos, pois os hosts que
eles representam não estão mais na rede.
A tabela a seguir descreve as ferramentas do DNS que ajudam a manter um banco de

dados DNS.
Ferramenta Descrição
TTL Indica por quanto tempo um registro DNS continua válido e

inelegível para limpeza.
Duração Ocorre quando os registros inseridos no servidor DNS atingem sua

expiração e são removidos. Isso mantém a exatidão do banco de
dados. Durante as operações normais, a duração deve se
encarregar dos registros de recursos DNS obsoletos.
Eliminação Executa a limpeza de registros de recursos do servidor DNS para os
registros antigos no DNS. Se os registros de recursos não estiverem
obsoletos, um administrador poderá eliminar os registros obsoletos
do banco de dados da zona para forçar uma limpeza do banco de
dados.
Se permanecerem sem gerenciamento, a presença de registros de recursos obsoletos

nos dados da zona pode causar problemas. Por exemplo:
 Se uma grande quantidade de registros de recursos obsoletos permanecer nas zonas

do servidor, o espaço em disco do servidor será esgotado e esses registros
ocasionarão transferências desnecessariamente longas da zona.
 Um servidor DNS que carrega zonas com registros de recursos obsoletos pode utilizar
informações desatualizadas para responder às consultas dos clientes, o que pode
fazer com que os computadores cliente enfrentem problemas de resolução de nomes
ou problemas de conectividade na rede.

 O acúmulo de registros de recursos obsoletos no servidor DNS pode degradar seu

desempenho e sua capacidade de resposta.
 Em alguns casos, se uma zona tiver um registro de recursos obsoleto, ele poderá
impedir que outro computador ou um dispositivo host use um nome de domínio DNS.
Para solucionar esses problemas, o serviço Servidor DNS dispõe dos seguintes
recursos:
 Carimbo de data/hora, baseado na data e hora atuais definidas no computador
servidor, para quaisquer registros de recursos adicionados dinamicamente às zonas
do tipo primário. Além disso, os carimbos de data/hora serão registrados nas zonas
primárias padrão nas quais você habilitar a duração e a eliminação.
 Para os registros de recursos adicionados manualmente, use um valor zero de carimbo

de data/hora para indicar que o processo de duração não afeta esses registros e que
eles podem permanecer sem limitação nos dados da zona, a menos que você altere,
de outra forma, os respectivos carimbos de data/hora ou os exclua.
 Duração dos registros de recursos nos dados locais, com base em um período de
atualização especificado, para quaisquer zonas qualificadas.
 Somente as zonas do tipo primário carregadas pelo serviço Servidor DNS estão
qualificadas a participar nesse processo.
 Eliminação dos registros de recursos que persistirem além do período de atualização

especificado.
Ao executar uma operação de eliminação, um servidor DNS pode detectar que os

registros de recursos envelheceram a ponto de se tornarem obsoletos e pode removê-los dos
dados da zona. Você pode configurar os servidores para executar automaticamente as
operações de eliminação recorrentes ou pode iniciar uma operação de eliminação imediata
no servidor.
Observação: Por padrão, o mecanismo de duração e eliminação do serviço Servidor

DNS está desabilitado. Habilite-o somente quando você realmente entender todos os
parâmetros. Caso contrário, você poderia configurar o servidor para excluir inadvertidamente
os registros que não deveriam ser eliminados. Se um registro for excluído por engano, não
somente os usuários deixarão de resolver as consultas para esse registro, mas qualquer
usuário poderá criar o registro e se apossar dele, inclusive nas zonas que você configurar
para fazer atualização dinâmica segura. Esse é um riscos à segurança significativo.
O servidor utiliza o conteúdo de cada carimbo de data/hora para registros de recurso

específicos, bem como outras propriedades de classificação por vencimento e limpeza que é
possível ajustar ou configurar para determinar quando ele limpa os registros.

Pré-requisitos para duração e eliminação

Para utilizar os recursos de duração e eliminação do DNS, é necessário atender a
algumas condições:
 Habilite a duração e a eliminação no servidor DNS e na zona DNS. Por padrão, a
duração e a eliminação dos registros de recursos estão desabilitadas.
 Adicione dinamicamente os registros de recursos às zonas ou modifique-os

manualmente para uso nas operações de duração e eliminação.
Em geral, somente os registros de recursos adicionados dinamicamente através do

protocolo de atualização dinâmica DNS estão sujeitos à duração e à eliminação.
Para os registros adicionados às zonas carregando um arquivo de zona baseado em

texto de outro servidor DNS ou adicionando-os manualmente a uma zona, é definido um
carimbo de data/hora de valor zero. Isso desqualifica esses registros para uso nas operações
de duração e eliminação.
Para alterar esse padrão, você pode administrar cada um desses registros, de modo
a redefinir e permitir que eles utilizem um valor de carimbo de data/hora atual (diferente de
zero). Isso permite que esses registros se tornem obsoletos e sejam eliminados.


1.4. SERVIDOR WEB E FTP
A função de Servidor Web (IIS) oferece uma plataforma para gerenciar, modular e
extensível para hospedagem de sites, serviços e aplicativos. Com o IIS é possível compartilhar
informações com usuários pela Internet, por uma intranet ou por uma extranet. O IIS é uma
plataforma Web unificada que integra o IIS, o ASP.NET, os serviços FTP, o PHP e o WCF
(Windows Communication Foundation)
Recursos
Os administradores podem usar a função de Servidor Web (IIS) para configurar e
gerenciar vários sites, aplicativos Web e sites FTP. Estes são alguns recursos específicos
 Gerenciador do IIS para configurar recursos do IIS e administrar sites.
 Protocolo FTP para permitir transferência de arquivos, seja para atualizar alguma
página web como para compartilhar arquivos com usuários dentro ou fora do ambiente.
 Isolamento de site para impedir que um site interfira em outros sites no servidor.
 Configurar aplicativos Web que são escritos através de várias tecnologias, como ASP
clássico, ASP.NET e PHP.
 Usar o Windows PowerShell para automatizar o gerenciamento da maioria das tarefas

de administração do servidor Web.
 Configurar vários servidores Web em um farm de servidores que você pode gerenciar
usando o IIS.
Cenários do servidor Web

Será exemplificado os 2 cenários mais comuns de utilização do IIS:
 Site estático
 Site FTP
Criar um site estático no IIS
Um servidor Web de conteúdo estático é a configuração mais básica do IIS que oferece
suporte a sites HTML. Você pode usar um servidor Web de conteúdo estático para hospedar
sites internos ou externos (públicos). Quando você instala o IIS, a instalação padrão fornece
todos os módulos do IIS necessários para oferecer suporte a um servidor Web de conteúdo
estático. A instalação padrão inclui a capacidade de fornecer arquivos HTML estáticos,
documentos e imagens. O IIS oferece suporte a documentos padrão, pesquisa em diretórios,
log e autenticação anônima para o servidor de conteúdo estático.

Passo 1: Instalar o IIS
1. Na página Iniciar, clique no bloco Gerenciador do Servidor e em OK.
2. Em Gerenciador do Servidor, selecione Painel e clique em Adicione funções e

recursos.
3. No Assistente de Adição de Funções e Recursos, na página Antes de Começar,

clique em Avançar.
4. Na página Selecione o Tipo de Instalação, selecione Instalação baseada em

função ou recurso e clique em Avançar.
5. Na página Selecionar Servidor de Destino, selecione Selecione um servidor do

pool de servidor, selecione o nome de seu computador e clique em Avançar.
6. Na página Selecionar Funções do Servidor, selecione Servidor Web (IIS) e clique

em Avançar.
7. Na página Selecionar Recursos, note os recursos pré-selecionados e clique

em Avançar.
8. Na página Função Servidor Web (IIS), clique em Avançar.
9. Na página Selecionar Serviços de Função, observe os serviços de função pré-

selecionados e clique em Avançar.
OBS.: Instale os serviços de função padrão IIS para um servidor Web de conteúdo
estático.
10. Na página Confirmar Seleções de Instalação, confirme suas seleções e clique

em Instalar.
11. Na página Progresso da Instalação, confirme se a instalação da função Servidor

Web (IIS) e dos serviços de função necessários foi concluída com êxito e clique
em Fechar.
12. Para verificar se o IIS foi instalado com êxito, digite o seguinte em um navegador da
Web: http://localhost
13. Você verá a página padrão de boas-vindas do IIS.
Passo 2: Adicionar um site

1. Abra o Gerenciador do IIS.
2. Na página Iniciar, clique no bloco Gerenciador do Servidor e em OK.

No Gerenciador do Servidor, clique no menu Ferramentas e clique
em Gerenciador dos Serviços de Informações da Internet (IIS).
3. No painel Conexões, clique com o botão direito do mouse no nó Sites na árvore e,

em seguida, clique em Adicionar Site.
4. Na caixa de diálogo Adicionar Site, digite um nome para o site na caixa Nome do
site.
5. Caso queira selecionar um pool de aplicativos diferente do relacionado na caixa Pool

de Aplicativos, clique em Selecionar. Na caixa de diálogo Selecionar Pool de
Aplicativos, selecione um pool de aplicativos na lista Pool de Aplicativos e clique
em OK.
6. Na caixa de texto Caminho físico, digite o caminho físico da pasta do site ou clique
no botão Procurar (...) para navegar pelo sistema de arquivos para localizar a pasta.
7. Se o caminho físico inserido na etapa anterior for um compartilhamento remoto, clique

em Conectar como para especificar as credenciais com permissão para acessar o
caminho. Se você não usar credenciais específicas, selecione a opção Usuário do
aplicativo (autenticação de passagem) na caixa de diálogo Conectar como.
8. Selecione o protocolo para o site na lista Tipo.
9. Se você precisar especificar um endereço IP estático para o site (por padrão, ele é
definido como Todos os Não Atribuídos), digite o endereço IP na caixa Endereço
IP.
10. Digite um número de porta na caixa de texto Porta.
11. Opcionalmente, digite um nome de cabeçalho de host para o site na caixa Cabeçalho
do Host.
12. Se você não precisar fazer alterações no site e desejar disponibilizar o site
imediatamente, marque a caixa de seleção Iniciar site imediatamente.
13. Clique em OK.
Etapa 3: Autenticação anônima

A autenticação anônima permite o acesso de usuários às áreas públicas de seu site

sem solicitar um nome de usuário ou senha. Você pode configurar a autenticação anônima
usando a conta de usuário anônima padrão (IUSR) ou pode configurar uma conta de usuário
local para usuários anônimos.
1. Em Exibição de Recursos do Gerenciador do IIS, clique duas vezes

em Autenticação.
2. Na página Autenticação, selecione Autenticação Anônima.
3. No painel Ações, clique em Editar para definir a entidade de segurança (credenciais

de usuário) na qual os usuários anônimos se conectarão ao site.
4. Na caixa de diálogo Editar Credenciais de Autenticação Anônima, selecione uma

das seguintes opções:
 Se desejar configurar uma conta de usuário específica utilizada pelo IIS para
acessar seu site ou aplicativo, selecione Usuário específico. Em seguida,
clique em Definir para abrir a caixa de diálogo Definir Credenciais e digite o
nome de usuário e a senha da conta para a identidade. Em seguida, clique
em OK.
 Se desejar que processos IIS sejam executados usando a conta especificada
no momento na página de propriedades do pool de aplicativos,
selecione Identidade do pool de aplicativos. Por padrão, essa identidade é
a conta IUSR.
OBS.: Caso use a conta IUSR, você concederá a usuários anônimos o acesso
total à rede interna associada a essa conta.
5. Clique em OK para fechar a caixa de diálogo Editar Credenciais de Autenticação

Anônima.
Etapa 4: Configurar Documentos padrão
Quando uma solicitação do cliente para seu site não incluir um nome de documento, o
IIS procurará um arquivo cujo nome é definido como um documento padrão. Normalmente, o
nome de documento padrão é Default.htm. Você pode definir uma lista de nomes de
documentos padrão em ordem de precedência.
1. Em Exibição de Recursos do Gerenciador do IIS, clique duas vezes em Documento

Padrão.
2. No painel Ações, clique em Adicionar.
3. Na caixa Nome, digite o nome do arquivo a ser adicionado à lista de documentos

padrão e, em seguida, clique em OK. Esse nome de arquivo é adicionado ao início da
lista de documentos padrão.

4. Como opção, selecione um documento padrão na lista e, no painel Ações, clique

em Mover para Cima ou Mover para Baixo para alterar a precedência do arquivo.
5. Como opção, selecione um documento padrão na lista e, no painel Ações, clique

em Remover para remover quaisquer nomes de arquivo que você não deseja usar
como documentos padrão.
Criar um site FTP
O protocolo FTP simples é um protocolo para transferência de arquivos entre sistemas

de computador.
Etapa 1: Instale FTP em um Servidor Web existente

1. Na tela Iniciar, clique no bloco Gerenciador de Servidores e clique em Sim.
2. No Painel de Gerenciador de Servidor, clique em Adicionar funções e recursos.
3. Se a página Antes de Começar do Assistente de Adição de Funções e

Recursos for exibida, clique em Avançar.
4. Na página Selecione o tipo de instalação, selecione Instalação baseada em

função ou recurso e clique em Avançar.
5. Na página Selecionar servidor de destino, selecione Selecione um servidor do

pool de servidores, selecione o servidor na lista Pool de Servidores e clique
em Avançar.
6. Na página Selecionar funções do servidor, expanda o nó Servidor Web (IIS) e

expanda o nó Servidor FTP.
7. Marque as caixas de seleção Servidor FTP e Serviço FTP, e clique em Avançar.
8. Na página Selecionar recursos, clique em Avançar.
9. Na página Confirmar seleções de instalação, clique em Instalar.
Etapa 2: Adicione um site FTP

Depois que o serviço FTP for instalado no servidor Web IIS, você poderá adicionar um
ou mais sites FTP. Adicione um site FTP quando quiser permitir que clientes transfiram
arquivos para e de um site usando o protocolo FTP.
OBS.: Como as configurações do FTP estão contidas na seção de sites, a alteração
de qualquer configuração de FTP também forçará a reciclagem do aplicativo de site. Se você
deseja evitar esse efeito colateral, adicione um site que é configurado exclusivamente para
FTP, e não para HTTP e FTP.
2. No painel Conexões, expanda o nó do servidor e clique no nó Sites.
3. No painel Ações, clique em Adicionar Site FTP a fim de abrir o assistente

para Adicionar Site FTP.
4. Na página Informações do Site, na caixa Nome do site FTP, digite um nome

amigável exclusivo para o site FTP.
5. Na caixa Caminho físico, digite o caminho físico ou clique no botão Procurar na caixa
(...) para localizar o caminho físico do diretório de conteúdo.
6. Clique em Avançar para abrir a página Configurações SSL e Associação.
7. Em Associação, na lista Endereço IP, selecione ou digite um endereço IP se você

não desejar que o endereço IP permaneça como Todos os Não Atribuídos.
8. Na caixa Porta, digite o número da porta.
9. Se desejar, na caixa Host Virtual, digite um nome de host se você desejar hospedar
vários sites FTP em um único endereço IP. Por exemplo, digite www.sisnema.com.br
10. Desmarque a caixa Iniciar site FTP automaticamente se você deseja iniciar o site
manualmente.
11. Em SSL, na lista Certificado SSL, selecione um certificado. Se desejar, clique

em Exibir para abrir a caixa de diálogo Certificados e verificar informações sobre o
certificado selecionado.
12. Marque uma das opções a seguir:

 Permitir SSL: permite que o servidor FTP ofereça suporte a conexões SSL e
não SSL com um cliente.
 Exigir SSL: requer criptografia SSL para comunicação entre o servidor FTP e
um cliente.
13. Clique em Avançar para abrir a página Informações de Autenticação e

Autorização.
14. Em Autenticação, selecione o método de autenticação que você deseja usar (ou os
dois):

 Anônimo: permite que qualquer usuário acesse o conteúdo fornecendo

somente o nome de usuário anônimo ou FTP. (A maioria dos clientes FTP, mas
não todos, inserem o nome de usuário para você automaticamente.)
 Básico: requer que os usuários forneçam um nome de usuário válido e uma
senha para acessar o conteúdo. Como a autenticação Básica transmite senhas
não criptografadas pela rede, use este método de autenticação somente
quando você souber que a conexão entre o cliente e o servidor FTP é segura;
por exemplo, usando o protocolo SSL.
15. Em Autorização, na lista Permitir acesso a, selecione uma das seguintes opções:
 Todos os Usuários: todos os usuários, sejam anônimos ou identificados,
podem acessar o conteúdo.
 Usuários Anônimos: os usuários anônimos podem acessar o conteúdo.
 Funções ou Grupos de Usuários Especificados: somente os membros de
determinadas funções ou grupos de usuários podem acessar o conteúdo.
Digite a função ou o grupo de usuários na caixa correspondente.
 Usuários Especificados: somente os usuários especificados podem acessar
o conteúdo. Digite o nome do usuário na caixa correspondente.
16. Se você tiver selecionado uma opção na lista Permitir acesso a, selecione uma das
permissões a seguir ou ambas:
 Leitura: permite que os usuários autorizados leiam o conteúdo do diretório.
 Gravação: permite que os usuários autorizados gravem no diretório.
17. Clique em Concluir.
Etapa 3: Configure isolamento do usuários
O recurso de isolamento do usuário permite configurar o servidor FTP para isolar

usuários, o que impede que os usuários acessem os diretórios de outros usuários no mesmo
site FTP. Se você optar por não isolar os usuários, eles compartilharão uma estrutura de
diretórios comum.
 Diretório de nome de usuário: isola as sessões de usuário de FTP no diretório físico

ou virtual com o mesmo nome da conta de usuário de FTP. O usuário vê somente o
local raiz do FTP e, portanto, não pode navegar acima na árvore de diretórios física ou
virtual. É ignorado qualquer diretório virtual global criado.
 Diretório físico de nome de usuário: isola as sessões de usuário no diretório físico

com o mesmo nome da conta de usuário de FTP. O usuário vê somente o local raiz
do FTP e, portanto, não pode navegar acima na árvore de diretórios física. Qualquer
diretório virtual global criado se aplica a todos os usuários.
 Diretório base FTP configurado no Active Directory: isola as sessões de usuário

no diretório base definido nas configurações de conta do Active Directory para cada
usuário de FTP.

2. Em Exibição de Recursos, clique duas vezes em Isolamento de Usuários de FTP.
3. Se você não desejar isolar os usuários, em Não isolar usuários. Iniciar usuários em,
selecione uma das seguintes opções:
 Diretório raiz FTP: especifica que todas as sessões de FTP iniciam no diretório
raiz do site FTP. Esta opção desabilita todo o isolamento de usuário e a lógica
da pasta de inicialização.
 Diretório de nome de usuário: especifica que todas as sessões FTP
começam no diretório físico ou virtual com o mesmo nome do usuário
conectado no momento, se a pasta existir; caso contrário, a sessão FTP
começará no diretório raiz do site FTP.
4. Se você não deseja isolar os usuários, em Isolar usuários. Restringir usuários ao

seguinte diretório, selecione um das seguintes opções:
 Diretório de nome de usuário (desabilitar diretórios virtuais globais): isola
as sessões de usuário no diretório físico ou virtual com o mesmo nome da conta
de usuário de FTP.
 Diretório físico de nome de usuário (habilitar diretórios virtuais globais):
isola as sessões de usuário no diretório físico com o mesmo nome da conta de
usuário de FTP.
 Diretório base FTP configurado no Active Directory: isola as sessões de
usuário no diretório base definido nas configurações de conta do Active
Directory para cada usuário de FTP.
 Personalizado: esta opção é um recurso avançado; ela permite que os
desenvolvedores criem provedores personalizados que fornecem pesquisas de
diretório base levando em conta suas necessidades comerciais exclusivas.
5. Se você tiver selecionado Diretório base FTP configurado no Active Directory na

etapa anterior, clica no botão Definir e digite um nome de usuário e uma senha nas
caixas Nome de usuário e Senha da caixa de diálogo Definir Credenciais que tem
acesso ao servidor do Active Directory. Digite a senha novamente na caixa Confirmar
Senha e clique em OK.
6. No painel Ações, clique em Aplicar.
Etapa 4: Configure mensagens FTP
Use o recurso Mensagens FTP para modificar as configurações das mensagens

enviadas quando um usuário se conectar ao site FTP.
1. No painel Conexões, selecione o nível do servidor ou o nível do site.

2. Em Exibição de Recursos, clique duas vezes em Mensagens FTP.
3. Na página Mensagens FTP, em Comportamento da Mensagem, selecione como

você deseja que as mensagens FTP se comportem. Você pode selecionar qualquer
uma das opções a seguir:
a. Suprimir faixa padrão: especifica se deve ser exibida a faixa de identificação
padrão do servidor FTP.
b. Dar suporte a variáveis de usuário em mensagens: especifica se deve ser
exibido um conjunto específico de variáveis de usuário nas mensagem FTP.
Há suporte para as seguintes variáveis de usuário:
 %BytesReceived% - o número de bytes enviados do servidor para o
cliente durante a sessão atual.
 %BytesSent% - o número de bytes enviados do cliente para o servidor
durante a sessão atual.
 %SessionID% - o identificador exclusivo da sessão atual.
 %SiteName% - o nome do site FTP que hospeda a sessão atual.
 %UserName% - o nome da conta do usuário conectado no momento.
c. Mostrar mensagens detalhadas para solicitações locais: especifica se
devem ser exibidas mensagens de erro detalhadas quando o cliente FTP está
se conectando ao servidor FTP no próprio servidor (host local).
4. Em Texto da Mensagem, digite as mensagens nas seguintes caixas:

a. Faixa: especifica a mensagem que o servidor FTP exibe quando os clientes
FTP se conectam pela primeira vez ao servidor FTP.
b. Bem-vindo: especifica a mensagem que o servidor FTP exibe quando os
clientes FTP fazem logon no servidor FTP.
c. Sair: especifica a mensagem que o servidor FTP exibe quando os clientes FTP
fazem logoff do servidor FTP.
d. Máximo de Conexões: especifica a mensagem que o servidor FTP exibe
quando os clientes tentam se conectar e não conseguem porque o serviço FTP
atingiu o número máximo de conexões de cliente permitidas.
5. No painel Ações, clique em Aplicar.


2. MÓDULO 9 - ACTIVE DIRECTORY

2.1. AD DS
Serviços de Domínio Active Directory (AD DS) e seus serviços relacionados formam a
base para redes corporativas que rodam os sistemas operacionais Windows. O banco de
dados do AD DS é o repositório central de todos os objetos de domínio, tais como contas de
usuário, contas de computador e grupos. AD DS fornece um diretório hierárquico pesquisável,
e fornece um método para a aplicação de configuração e as configurações de segurança para
objetos na empresa.
Visão Geral do AD DS
O banco de dados do AD DS armazena informações sobre a identidade do usuário,
computadores, grupos, serviços e recursos. Controladores de domínio do AD DS também
hospeda o serviço que autentica contas de usuário e computador quando eles fizerem logon
no domínio. Como o AD DS armazena informações sobre todos os objetos no domínio, todos
os usuários e computadores devem se conectar aos controladores de domínio do AD DS no
momento fazem logon no rede, AD DS é o principal meio pelo qual você pode configurar e
gerenciar contas de usuário e de computador em sua rede.
Uma das características do AD DS é Diretiva de Grupo (Group Policy), que permite

configurar políticas centralizadas que você pode usar para gerenciar a maioria dos objetos no
AD DS.

Componentes físicos
As informações do AD DS são armazenadas em um único arquivo no disco rígido de
cada controlador de domínio. A tabela a seguir lista alguns dos componentes físicos e onde
eles estão armazenados.
Componente físico Descrição

Domain controllers
Contém cópias do banco de dados do AD DS.
(Controlador de
Domínio)
Data store O arquivo onde cada controlador de domínio armazena
informações do AD DS
Global catalog Hospeda o catálogo global, que é uma cópia somente leitura
servers (servidor de parcial de todos os objetos na floresta. Catalogo global agiliza as
catálogo global) pesquisas para objetos que podem ser armazenados nos
controladores de domínio em um domínio diferente na floresta.
Read-only domain Uma instalação especial do AD DS em uma forma de somente
leitura. Estes são frequentemente utilizados em escritórios, onde
controllers (RODC)
a segurança e suporte de TI são muitas vezes menos avançado
do que nos principais centros empresariais.
Componentes lógicos
Componentes lógicos do AD DS são estruturas que você pode usar para implementar
um projeto de Active Directory que é apropriado para uma organização. A tabela a seguir
descreve alguns dos tipos de estruturas lógicas que um banco de dados do Active Directory
pode conter.
Componente lógico Descrição
Partition (partição) Uma seção do banco de dados do AD DS. Embora o banco de

dados seja um arquivo chamado NTDS.DIT, ele é visto,
gerenciado e replicado como se consistisse em seções distintas
ou instâncias. Estes são chamados partições ou contextos.
Schema (esquema) Define a lista de tipos e atributos que todos os objetos no AD DS
pode ter.
Domain (Domínio) Um limite lógico, administrativo para usuários e computadores.
Domain tree (árvore) Uma coleção de domínios que compartilham um domínio raiz
comum e um Domain Name System (DNS).
Forest (floresta) Um conjunto de domínios relacionados através de um domínio em
comum
Site Um conjunto de usuários, grupos e computadores, conforme

definido pela sua localização física. Sites são úteis no
planejamento de tarefas administrativas, tais como replicação de
alterações no banco de dados do AD DS.
OU OUs são recipientes no AD DS que fornecem uma estrutura para
a delegação de direitos administrativos e para a ligação de
Diretivas de grupo (GPOs).

Leitura Adicional: Para mais informações sobre domínios e florestas, consulte

Domínios e Florestas Referência Técnica em http://go.microsoft.com/fwlink/?LinkId=104447.
Domínios AD DS
Um domínio do AD DS é um agrupamento lógico de usuário, computador e objetos de
grupo com a finalidade de gerenciamento e segurança. Todos esses objetos são
armazenados no banco de dados do AD DS e uma cópia desse banco de dados é armazenado
em cada controlador de domínio no domínio AD DS.
Existem vários tipos de objetos que podem ser armazenados no banco de dados do
AD DS, incluindo contas de usuários. As contas de usuário fornecem um mecanismo que pode
ser utilizado para autenticar e autorizar os usuários a acessar os recursos na rede. Cada
computador associado a um domínio deve ter uma conta no AD DS. Isso permite que os
administradores de domínio possam usar políticas (GPO) para gerenciar os computadores. O
domínio também armazena grupos, que são o utilizados para agrupar objetos por motivos de
segurança ou de instâncias administrativas, contas de usuário e contas de computador.
O domínio AD DS também é um limite de replicação. Quando são feitas alterações a

qualquer objeto no domínio, essa alteração é automaticamente replicada para todos os outros
controladores de domínio no domínio.

Um domínio do AD DS é um centro administrativo. Ele contém uma conta de

administrador e de um grupo de administradores de domínio, ambos têm controle total sobre
todos os objetos no domínio. A menos que eles estejam no domínio raiz da floresta, seu
alcance de controle é limitado ao domínio. Regras de senha e conta são gerenciadas no nível
do domínio por padrão. O domínio AD DS fornece um centro de autenticação. Todas as contas
de usuário e contas de computador no domínio são armazenadas no banco de dados de
domínio. Usuários e computadores deve se conectar a um controlador de domínio para
autenticar.
Um único domínio pode conter mais de 1 milhão de objetos, portanto, a maioria das
organizações precisa implantar apenas um único domínio. As organizações que têm
estruturas administrativas descentralizadas, ou que são distribuídos em vários locais, podem
implementar vários domínios na mesma floresta.
Unidades Organizacionais (OUs)
Uma unidade organizacional (OU) é um objeto de contêiner dentro de um domínio que

você pode usar para consolidar usuários, grupos, computadores e outros objetos. Há duas
razões para criar OUs:
 Para configurar os objetos contidos na OU. Você pode atribuir GPOs à OU, e as
configurações se aplicam a todos os objetos dentro da OU. GPOs são condições que
os administradores criam para gerenciar e configurar contas de usuário e computador.
A forma mais comum de implementar essas políticas é associá-los a OUs.

 Para delegar o controle administrativo de objetos dentro da OU. Você pode atribuir
permissões de gerenciamento em uma OU, delegando, assim, o controle da OU a um
usuário ou grupo do além do administrador do AD DS.
Você pode usar as OUs para representar as estruturas hierárquicas e lógicas dentro
de sua organização. Por exemplo, você pode criar OUs que representam os departamentos
dentro, as regiões geográficas dentro de sua organização, ou uma combinação de ambas as
regiões departamentais e geográficas. Você pode usar as OUs para gerenciar a configuração
e uso de usuários, grupos e contas de computador baseado em seu modelo organizacional.
Cada domínio AD DS contém um conjunto padrão de containers e unidades

organizacionais que são criados quando você instala o AD DS, incluindo o seguinte:
 Domain container. Serve como recipiente de raiz para a hierarquia.
 Builtin container. Armazena um número de grupos padrão.
 Users container. O local padrão para novas contas de usuários e grupos que você
criar no domínio. O container usuários também detém as contas de guests (visitante),
administrador e outros grupos padrão do domínio
 Computers container. O local padrão para novas contas de computador criadas no

domínio.
 Domain Controllers OU. O local padrão para as contas de computador de

computador do controlador de domínio. É a única OU que está presente em uma nova
instalação de AD DS.
Nota: Nenhum dos conteiners padrão no domínio AD DS pode ter GPOs vinculados a
eles, com exceção de OU Domain Controllers padrão e do próprio domínio. Todos os outros
conteiners são apenas pastas. Para vincular GPOs e aplicar as configurações e restrições,
crie uma hierarquia de OUs, em seguida, vincule GPOs a elas.
Floresta AD DS
Uma floresta é um conjunto de uma ou mais árvores de domínio. Uma árvore é um
conjunto de um ou mais domínios. O primeiro domínio que é criado na floresta é chamado de
domínio raiz da floresta. O domínio raiz da floresta contém alguns objetos que não existem
em outros domínios na floresta. Por exemplo, o domínio raiz da floresta contém dois papéis
especiais: o mestre de esquema (schema master) e mestre de nomeação de domínio (domain
naming master).
Além disso, o grupo Administradores de Empresa (Enterprise Admins) e grupo
Administradores de esquema (Schema Admins) só existem no domínio raiz da floresta. O
grupo Enterprise Admins tem total controle sobre todos os domínios dentro da floresta.

A floresta AD DS é um limite de segurança. Isto significa que, por padrão, nenhum

usuário de fora da floresta pode acessar todos os recursos dentro da floresta. Isso também
significa que os administradores de fora da floresta não têm acesso administrativo dentro da
floresta. Uma das principais razões pelas quais as organizações implantam várias florestas é
porque elas precisam isolar permissões administrativas entre as diferentes partes da
organização.
A floresta AD DS também é o limite de replicação para as partições de configuração

(configuration) e esquema (schema) no banco de dados do AD DS. Isto significa que todos os
controladores de domínio na floresta devem compartilhar o mesmo schema. A segunda razão
pela qual as organizações implantam várias florestas é porque precisam implantar schemas
incompatíveis em duas partes da organização.
A floresta do AD DS também é o limite de replicação para o catálogo global (Global

Catalog [GC]). Isso faz com que a maioria das formas de colaboração entre usuários em
diferentes domínios sejam mais fáceis. Por exemplo, todos os destinatários do Microsoft
Exchange Server 2010 estão listados no catálogo global, tornando mais fácil para enviar e-
mail para qualquer um dos usuários da floresta, mesmo aqueles usuários em diferentes
domínios.
Por padrão, todos os domínios em uma floresta confiam automaticamente nos outros
domínios na floresta. Isto torna mais fácil para permitir o acesso a recursos como
compartilhamento de arquivos e sites para todos os usuários em uma floresta,
independentemente do domínio no qual a conta de usuário está localizado.
AD DS Schema
O schema (esquema) do AD DS é o componente do AD DS que define todos os tipos

de objetos e atributos que AD DS usa para armazenar dados. Com se fosse o modelo para
AD DS.

AD DS armazena e recupera informações de uma ampla variedade de aplicações e

serviços. AD DS padroniza a forma como os dados são armazenados no diretório AD DS de
modo que possa armazenar e reproduzir os dados provenientes das diferentes fontes. Ao
padronizar como os dados são armazenados, o AD DS pode recuperar, atualizar e replicar
dados, assegurando que a integridade dos dados é mantida.
AD DS usa objetos como unidades de armazenamento. Todos os tipos de objetos são

definidos no schema. Cada vez que o diretório lida com os dados, o diretório consulta o
esquema para uma definição de objeto apropriado. Com base na definição de objeto no
schema, o diretório cria o objeto e armazena os dados.
Definições de objeto controlam os tipos de dados que os objetos podem armazenar, e

a sintaxe dos dados. Usando essas informações, o schema garante que todos os objetos
estão em conformidade com as suas definições padrão. Como resultado, a AD DS pode
armazenar, recuperar e validar os dados que ele gerencia, independentemente da aplicação
que é a fonte original dos dados. Somente os dados que tem uma definição de objeto existente
no esquema podem ser armazenados no diretório. Se um novo tipo de dados precisa ser
armazenado, uma nova definição de objeto para os dados deve ser criada no schema antes.
No AD DS, o schema define o seguinte:

 Objetos que são usados para armazenar dados no diretório
 As regras que definem quais os tipos de objetos que você pode criar, quais atributos
devem ser definidos (obrigatório) quando você cria o objeto, e quais atributos são
opcionais.

 Estrutura e conteúdo do diretório em si
Você pode usar uma conta que seja membro do grupo Administradores de esquema
(schema admins) para modificar os componentes do schema de uma forma gráfica. Exemplos
de objetos que são definidos no schema inclui usuário, computador, grupo e local. Entre os
muitos atributos são localização, accountExpires, buildingName, empresa, gerente, e
displayName.
O mestre de esquema (schema master) é uma das operações de controladores de

domínio mestre único (Flexible Single Master Operation) no AD DS. Também conhecido como
FSMO. Porque é um único mestre, você deve fazer alterações no schema visando o
controlador de domínio que detém a função de mestre de operações de schema.
Como o schema determina a forma que a informação é armazenada, e porque todas

as alterações que são feitas para o schema afetam cada controlador de domínio, alterações
no schema deve ser feita somente quando necessário. Antes de fazer qualquer alteração,
você deve analisar as alterações através de um processo rigidamente controlado, e, em
seguida, implementá-los somente depois de ter realizado testes para garantir que as
mudanças não afetarão negativamente o resto da floresta e todos os aplicativos que usam o
AD DS.
Embora você não possa fazer qualquer alteração no schema diretamente, alguns
aplicativos que fazem alterações no schema para suportar recursos adicionais. Por exemplo,
quando você instala o Exchange Server 2010 em sua floresta AD DS, o programa de
instalação estende o schema para suportar novos tipos de objetos e atributos.
Visão geral de Controladores de Domínio

Como os controladores de domínio autenticam todos os usuários e computadores no
domínio, a implantação do controlador de domínio é fundamental para o correto
funcionamento da rede.
Todos os controladores de domínio são essencialmente o mesmo, com duas

exceções. RODCs contém uma cópia somente leitura do banco de dados do AD DS, enquanto
que outros controladores de domínio tem uma cópia de leitura e escrita. Existem também
algumas operações que só podem ser executadas em controladores de domínio específicos
chamados mestres de operações, que são discutidas no final desta lição.
Controladores de Domínio
Um controlador de domínio é um servidor que estiver configurado para armazenar uma
cópia do banco de dados do diretório do AD DS (NTDS.DIT) e uma cópia da pasta SYSVOL.

Todos os controladores de domínio, exceto um RODCs, armazena uma cópia de

leitura/gravação de ambos NTDS.DIT e a pasta SYSVOL. NTDS.DIT é o próprio banco de
dados e a pasta SYSVOL contém todas as configurações do modelo para GPOs.
Alterações ao banco de dados do AD DS pode ser iniciado em qualquer controlador

de domínio, exceto para RODC. O serviço de replicação do AD DS, em seguida, sincroniza
as alterações e atualizações ao banco de dados do AD DS para todos os outros controladores
de domínio no domínio. As pastas SYSVOL são replicados ou pelo serviço de replicação de
arquivos (FRS), ou o mais recente Distributed File System (DFS).
Os controladores de domínio hospedam vários outros serviços relacionadas ao Active

Directory, incluindo o serviço de autenticação Kerberos, que é usado por contas de usuário e
computador para autenticação de logon, e do Centro de Distribuição de Chaves (Key
Distribution Center [KDC]). O KDC é o serviço que emite o bilhete de concessão de ticket
(Ticket-Granting Ticket [TGT]) para uma conta que fizer logon no domínio AD DS. Você pode
opcionalmente configurar controladores de domínio para hospedar uma cópia do catálogo
global do Active Directory.
Um domínio do AD DS deve sempre ter um mínimo de dois controladores de domínio.

Dessa forma, se um dos controladores de domínio falhar, há uma cópia de segurança para
garantir a continuidade dos serviços de domínio do AD DS. Quando você decidir adicionar
mais de dois controladores de domínio, considere o tamanho da sua organização e os
requisitos de desempenho.
Nota: Dois controladores de domínio devem ser considerado como mínimo.

Quando você implanta um controlador de domínio em uma filial onde a segurança

física é inferior a ideal, existem algumas medidas adicionais que você pode usar para reduzir
o impacto de uma violação de segurança. Uma opção é implantar um RODC.
O RODC contém uma cópia somente leitura do banco de dados do AD DS, e por
padrão, ele não armazena em cache todas as senhas do usuário. Você pode configurar o
RODC para armazenar em cache as senhas de usuários na filial. Se um RODC for
comprometido, o potencial de perda de informações é muito menor do que com um controlador
de domínio completo (leitura e escrita). Outra opção é usar o Windows BitLocker Drive
Encryption para criptografar o controlador de domínio no disco rígido. Se o disco rígido for
roubado, a criptografia BitLocker garante que há uma chance muito baixa de um usuário mal-
intencionado obter qualquer informação útil a partir dele.
Global Catalog (Catalogo Global)
Dentro de um único domínio, o banco de dados do AD DS contém todas as

informações sobre todos os objetos nesse domínio. Esta informação não é replicada fora do
domínio. Por exemplo, uma consulta para um objeto no AD DS é direcionado para um dos
controladores de domínio para desse domínio. Se houver mais de um domínio na floresta,
então essa consulta não fornece nenhum resultado para os objetos em um domínio diferente.
Para habilitar a pesquisa em vários domínios, você pode configurar um ou mais
controladores de domínio para armazenar uma cópia do catálogo global. O catálogo global é
um banco de dados distribuído que contém uma representação pesquisável de todos os
objetos de todos os domínios de uma floresta de domínio múltiplo. Por padrão, o único servidor
de catálogo global é o primeiro do domínio raiz da floresta.

O catálogo global não contém todos os atributos para cada objeto. Em vez disso, o
catálogo global mantém o subconjunto de atributos que são mais suscetíveis de serem úteis
em procuras entre domínios. Há uma variedade de razões pelas quais você pode realizar uma
busca contra um catálogo global, em vez de um controlador de domínio que não é um catálogo
global.
Processo de logon do AD DS
Quando você faz logon no AD DS, o sistema procura no DNS por recursos (SRV) de
serviços para localizar o controlador de domínio mais próximo. SRV são registros que
especificam as informações sobre os serviços disponíveis, e são registrados no DNS por todos
os controladores de domínio. Usando pesquisas de DNS, os clientes podem localizar um
controlador de domínio adequado para atender suas solicitações de logon.
Se o logon for bem sucedido, a autoridade de segurança local (LSA) cria um token de
acesso para o usuário que contém os identificadores de segurança (SIDs) para o usuário e os
grupos dos quais o usuário é membro. O token fornece as credenciais de acesso para
qualquer processo iniciado por esse usuário.
Nota: Um SID é um número único na forma de S-1-5-21-4130086281-3752200129-

271587809-500, onde:
 Os quatro primeiros blocos de letras e números (S-1-5-21) representam o tipo de ID
 Os próximos três blocos de números (4130086281-3752200129-271587809) são o

número de banco de dados onde a conta é armazenado (geralmente o domínio AD
DS)

• A última seção (500) é o ID relativo (RID), que é a parte da SID que identifica
unicamente essa conta no banco de dados
Every user and computer account and every group that you create has a unique SID.
They only differ from each other by virtue of the unique RID. You can tell that this particular
SID is the SID for the administrator account because it ends with RID 500.
Mestres de Operações
Apesar de todos os controladores de domínio serem essencialmente iguais, há
algumas tarefas que só podem ser executadas somente por controlador de domínio em
particular. Por exemplo, se você precisa adicionar um domínio adicional para a floresta, então
você deve ser capaz de se conectar ao mestre de nomeação de domínio.
Os papeis (roles) de controladores de domínio são:
 Operations masters
 Single master roles
 Flexible single-master operations (FSMOs)
Esses papéis são distribuídos da seguinte forma:

 Cada floresta tem um schema master (mestre de esquema) e um de domain naming
master (mestre de nomeação de domínio)
 Cada domínio AD DS tem um RID master (mestre RID), um infrastructure máster

(mestre de infraestrutura), e um PDC emulator (emulador de PDC)
Mestre de Operação de Floresta

Papéis de mestre único encontrado em uma floresta:
 Domain naming master. Este é o controlador de domínio que deve ser consultado ao
adicionar ou remover um domínio, ou quando você faz mudanças de nome de domínio.
 Schema master. Este é o controlador de domínio onde todas as mudanças de

esquema são feitas.
Mestre de Operação de Domínio

Papéis de mestre único encontrados em um domínio:

 RID master. Sempre que um objeto é criado no AD DS, o controlador de domínio onde
o objeto é criado atribui um número de identificação único, conhecido como SID. Para
garantir que não há dois controladores de domínio atribuindo o mesmo SID a dois
objetos diferentes, o RID master aloca blocos para cada controlador de domínio no
domínio.
 Infrastructure master. Este papel é responsável pela manutenção de referências de

objeto inter-domínios, tais como quando um grupo em um domínio contém um membro
de outro domínio. Nesta situação, o Infrastructure master é responsável por manter a
integridade desta referência.
 PDC emulator master. O controlador de domínio que detém a função de PDC

emulator é a fonte de horário para o domínio. Os controladores de domínio que
possuem a função de PDC emulator em cada floresta sincronizam o seu tempo com o
controlador de domínio que tem a função de emulador PDC no domínio raiz da floresta.
O PDC emulator também é o controlador de domínio que recebe mudanças urgentes
de senha. Se a senha de um usuário for alterada, a informação é enviada imediatamente para
o controlador de domínio que detém a função de emulador PDC. Isto significa que se o usuário
posteriormente tentou entrar e eles foram autenticados por um controlador de domínio em um
local diferente, que ainda não havia recebido uma atualização sobre a nova senha, o
controlador de domínio no local para que o usuário tentou fazer logon faria contatar o
controlador de domínio que detém a função de PDC emulator e verificar as mudanças
recentes.
O PDC emulator também é usado durante a edição GPOs que não são locais.
Instalando Controlador de Domínio pelo Server Manager

Antes do Windows Server 2012, era comum usar a ferramenta dcpromo.exe para
instalar controladores de domínio. Se você tentar executar dcpromo.exe em um servidor
Windows Server 2012, você receberá a seguinte mensagem de erro: "O Assistente de
Instalação do Active Directory Domain Services é realocado no Server Manager. Para mais
informações, consulte http://go.microsoft.com/fwlink/?LinkId=220921. "
Nota: No Windows Server 2012, é preciso utilizar o Server Manager ao invés do

dcpromo.exe. Dcpromo.exe ainda está disponível, mas só pode ser usado para instalações
automáticas a partir da interface de linha de comando.
Quando você executa o Server Manager, você pode escolher se a operação é

executada no computador local, em um computador remoto, ou por membros de um grupo de
servidores. Em seguida, você adiciona a função AD DS. No final do processo de instalação
inicial, o AD DS binários são instalados, mas AD DS ainda não está configurado no servidor.
A mensagem para esse efeito exibe no Gerenciador de Servidores.
Você pode selecionar Promote this server to a domain controller (promover esse
servidor para um controlador de domínio) e, em seguida, o Assistente de Configuração do
Active Directory Domain Services é executado. Você pode, então, fornecer as informações
listadas na tabela a seguir sobre a estrutura proposta (veja a imagem).

Informação Necessária Descrição
“Add a domain controller to an Forneça credenciais para esta operação

existing Domain”
“Add a new domain to an Crie um novo domínio na floresta.
existing forest”
“Add a new forest” Crie uma nova floresta.
“Specify the domain information Forneça informações sobre o domínio existente para
for this operation” que o novo controlador de domínio irá se conectar.
“Supply the credentials to Digite o nome de uma conta de usuário que tem os
perform this operation” direitos para executar esta operação.
Outras informações são necessário para promover um servidor a controlador de

domínio:
Informação Necessária Descrição
Nome de DNS para o Domínio AD DS Exemplo: sisnema.local
Se a nova floresta precisa suportar os Exemplo: se você está pensando em implantar

controladores de domínio que controladores de domínio do Windows Server
executam versões anteriores dos 2008 R2, você deve selecionar o nível funcional de
sistemas operacionais Windows domínio e floresta do Windows Server 2008 R2.
(afeta a escolha do nível funcional)
Se o controlador de domínio será Seu DNS deve estar funcionando bem para
também um servidor DNS suportar o AD DS.
Local para armazenar os arquivos de Por padrão, esses arquivos serão armazenados
banco de dados, por exemplo, em C:\Windows\NTDS.
NTDS.DIT, edb.log ou edb.chk
O Assistente de Configuração do Active Directory Domain Services continua através

de várias páginas diferentes, onde você informa o nome de domínio NetBIOS, configuração
de DNS, se o controlador de domínio deve ser um servidor de catálogo global, e as senha
Directory Services Restore Mode. Finalmente, você deve reiniciar para concluir a instalação.
Nota: Se você precisa restaurar o banco de dados do AD DS a partir de um backup, é

preciso reiniciar o controlador de domínio em Directory Services Restore Mode. Quando o
controlador de domínio iniciar, ele não estará executando o serviço AD DS, em vez disso, ele
estará sendo executado como um servidor membro do domínio. Para fazer logon no servidor
é preciso entrar no “Services Recovery Mode password” (Modo de Recuperação de Serviços
de Diretório).

Instalando um controlador de domínio em um Server Core

Para instalar os binários do AD DS no servidor, você pode usar o Gerenciador do
Servidor para conectar remotamente ao servidor Server Core. Você também pode usar o
comando Windows PowerShell Install-WindowsFeature-name AD-Domain-Services para
instalar os binários.
Depois de instalar o AD DS binários, você pode completar a instalação e configuração

em uma das seguintes quatro maneiras:
 No Server Manager, clique no ícone de notificação para completar a configuração pós-

implantação. Isso inicia a configuração e a instalação do controlador de domínio.
 Execute no Windows PowerShell Install-ADDSDomainController-domainname

"sisnema.local", com outros argumentos, conforme exigido.
 Crie um arquivo de resposta e execute dcpromo /unattend:”D:\arqresposta.txt” no

prompt de comando, onde " D:\arqresposta.txt" é o caminho para o arquivo de
resposta.
Execute dcpromo /unattend em um prompt com as opções apropriadas de comando,

por exemplo:
dcpromo /unattend /InstallDns:yes /confirmglobal catalog:yes /replicaOrNewDomain:replica
/replicadomaindnsname:"meudominio.com" /databasePath:"c:\ntds" /logPath:"c:\ntdslogs"
/sysvolpath:"c:\sysvol" /safeModeAdminPassword:Pa$$w0rd /rebootOnCompletion:yes

Atualizando um Controlador de Domínio

Você pode atualizar para Windows Server 2012 de duas formas.
 Você pode atualizar o sistema operacional em controladores de domínio
existentes que estão executando o Windows Server 2008 ou Windows Server
2008 R2.
 Alternativamente, você pode introduzir servidores Windows Server 2012 como
controladores de domínio em um domínio contendo controladores de domínio
que executam versões anteriores do Windows Server.
Dos dois, o segundo é o método preferível, porque você terá uma instalação limpa no
servidor do sistema operacional Windows Server 2012 e banco de dados do AD DS.
Atualizando para Windows Server 2012

Para atualizar um domínio AD DS que está sendo executado em um nível funcional
mais antigo Windows Server em um domínio AD DS rodando a nível funcional do Windows
Server 2012, você deve primeiro atualizar todos os controladores de domínio do sistema
operacional Windows Server 2012. Você pode fazer isso por meio da atualização de todos os
controladores de domínio existentes para o Windows Server 2012, ou através da introdução
de novos controladores de domínio que executam o Windows Server 2012, e, em seguida,
eliminação dos controladores de domínio existentes.
Para executar uma atualização de um computador que tenha a função AD DS

instalado, primeiro você deve usar os comandos de linha de comando Adprep.exe
/forestprep e Adprep.exe /domainprep para preparar a floresta e o domínio. Adprep.exe
está incluído na mídia de instalação na pasta \adprep\Support.
Quando você promove um servidor Windows Server 2012 para ser um controlador de
domínio em um domínio existente, e se você estiver conectado como um membro do grupo
Administradores de esquema e grupos de administradores da empresa, o esquema do AD DS
será automaticamente atualizado para o Windows Server 2012. Neste cenário, você não
precisa executar os comandos Adprep.exe antes de iniciar a instalação.
Implantando controladores de domínio do Windows Server 2012

Para atualizar o sistema operacional de um controlador de domínio do Windows Server
2008 para o Windows Server 2012, execute os seguintes passos
1. Insira o disco de instalação do Windows Server 2012, e, em seguida inicie a instalação.
1. Depois que a página de seleção de idioma, clique em Instalar agora.
2. 2. Após da janela de seleção de sistema operacional e a página de aceitação da

licença, clique em Upgrade: Install Windows and keep files (Atualizar: Instalar o
Windows e manter arquivos).

Nota: Com este tipo de upgrade, não há necessidade de se preservar as configurações

dos usuários e reinstalar os aplicativos, tudo é atualizado no lugar. Lembre-se de verificar se
há compatibilidade de hardware e software antes de realizar uma atualização.
Para uma instalação limpa do Windows Server 2012 como um controlador de domínio,
execute os seguintes passos:
1. Implantar e configurar uma nova instalação do Windows Server 2012 e juntar-se ao
domínio.
2. Promova o novo servidor para ser um controlador de domínio usando o Server

Manager ou em um dos outros métodos descritos anteriormente.
Nota: Você pode atualizar diretamente do Windows Server 2008 e Windows Server
2008 R2 para o Windows Server 2012.

3. MÓDULO 10 - ACTIVE DIRECTORY DOMAIN SERVICES

3.1. GERENCIAMENTO DE GRUPOS E USUÁRIOS
Gerenciando contas de usuário

Um objeto de usuário no AD DS é muito mais do que apenas as propriedades
relacionadas com a identidade de segurança do usuário ou conta. É a referência de identidade
e acesso no AD DS. Portanto, processos consistentes, eficientes e seguros em relação à
administração de contas de usuários são de extrema importância para gestão de segurança
da empresa.
Ferramentas de administração AD DS
Antes de começar a criar e gerenciar contas usuários e grupos, é importante que você
compreenda quais as ferramentas que você pode usar para realizar essas várias tarefas de
gerenciamento.
Snap-ins Administrativos do Active Directory

A maioria da administração no AD DS é realizada com o snap-ins e consoles a seguir:
 Active Directory Users and Computers (Usuários e Computadores). Este snap-in
gerencia os recursos mais comuns do dia-a-dia, incluindo usuários, grupos,
computadores e unidades organizacionais (OUs). Este é provavelmente o snap-in para
um administrador do Active Directory mais utilizado.
 Active Directory Sites and Services (Sites e Serviços). Este snap-in controla a
replicação, topologia de rede e serviços relacionados.
 Active Directory Domains and Trusts (Domínios e relações de confiança). Este

snap-in configura e mantém relações de confiança e o nível funcional da floresta.
 Active Directory Schema snap-in (Esquema). Este snap-in examina e modifica a

definição de atributos do Active Directory e classes de objetos. É o modelo para o AD
DS. É raramente visto, e ainda mais raramente alterado. Portanto, o esquema do
Active Directory snap-in não está instalado, por padrão.
Nota: Para administrar o AD DS de um computador que não é um controlador de

domínio, você deve instalar o Remote Server Administration Tools (RSAT). RSAT é um
recurso que pode ser instalado a partir do nó Recursos do Server Manager do Windows Server
2012.
Você também pode instalar o RSAT em clientes Windows, incluindo o Windows Vista
Service Pack 1 (ou mais recente), Windows 7 e Windows 8. Depois de baixar os arquivos de
instalação do RSAT no site da Microsoft, execute o Assistente de Configuração, que guiará a
instalação. Depois instalar o RSAT, você deve ativar a ferramenta ou ferramentas que você
deseja usar. Para fazer isso, no Control Panel (Painel de Controle), em Programs And

Features (Programas e Recursos), use o Turn Windows Features On or Off (Ativar ou

Desativar recursos do Windows).
Active Directory Administrative Center

O Windows Server 2012 fornece uma outra opção para o gerenciamento de objetos
do AD DS. O Active Directory Administrative Center (Centro Administrativo do Active
Directory) fornece uma interface gráfica do usuário (GUI) construída sobre o Windows
PowerShell. Esta interface permite que você execute gestão de objetos do AD DS usando a
navegação orientada por tarefas. Tarefas que você pode executar:
 Criar e gerenciar usuário, computador e contas de grupo.
 Criar e gerenciar OUs.
 Conecte-se e gerenciar múltiplos domínios em uma única instância do Centro

Administrativo do Active Directory.
 Filtro e pesquisa de dados do Active Directory utilizando consultas.
Windows PowerShell
Você pode usar o módulo do Active Directory para o Windows PowerShell (módulo
Active Directory) para criar e gerenciar objetos no AD DS. Windows PowerShell não é apenas
uma linguagem de script, mas também permite que você execute comandos que executam
tarefas administrativas, tais como a criação de novas contas de usuário, configuração de
serviços, a exclusão de caixas de correio, e funções similares.
Windows PowerShell está instalado por padrão no Windows Server 2012, mas o
módulo Active Directory só está presente quando:
 Você instala a função de servidor AD DS ou Serviços Active Directory Lightweight
Directory (AD LDS.
 Você usa o Dcpromo.exe para promover um computador para um controlador de

domínio.
 Você instala o RSAT.
Ferramentas em linha de comando:

Você também pode usar as ferramentas de linha de comando do serviço de diretório,
além do Windows PowerShell. Estas ferramentas permitem-lhe criar, modificar, gerenciar e
excluir objetos do AD DS, como usuários, grupos e computadores. Você pode usar os
seguintes comandos:
 Dsadd. Use para criar novos objetos.
 Dsget. Use para exibir objetos e suas propriedades.
 Dsmod. Use para editar objetos e suas propriedades.
 Dsmove. Use para mover objetos.

 Dsquery. Use para consultar o AD DS para objetos que correspondam aos critérios
específicos.
 Dsrm. Use para excluir objetos.
Nota: É possível concatenar os resultados do comando Dsquery para outros

comandos de serviço de diretório. Por exemplo, digitando o seguinte em um prompt de
comando retorna o número de telefone do escritório de todos os usuários que têm um nome
começando com Luis:
dsquery user –name Luis* | dsget user –office
Criando contas de usuários

No AD DS, todos os usuários que necessitam de acesso aos recursos da rede devem
ter uma conta de usuário. Com essa conta de usuário, os usuários podem autenticar no
domínio AD DS e receber o acesso aos recursos da rede.
No Windows Server 2012, a conta de usuário é um objeto que contém todas as

informações que definem um usuário. Uma conta de usuário inclui o nome de usuário e senha,

e os grupos que ele pertence. Uma conta de usuário também contém muitas outras
configurações que podem ser configuradas com base em suas necessidades organizacionais.
Com uma conta de usuário, você pode:

 Permitir ou negar aos usuários permissão para fazer logon em um computador com
base em sua identidade de conta de usuário.
 Conceder acesso a processos e serviços para um contexto de segurança específico.
 Gerenciar o acesso dos usuários aos recursos, como objetos do AD DS e suas

propriedades, pastas compartilhadas, arquivos, diretórios e filas de impressão.
Uma conta de usuário permite que um usuário faça logon em computadores e domínios
com uma identidade que o domínio possa autenticar. Ao criar uma conta de usuário, você
deve fornecer um nome de logon do usuário, que deve ser único no domínio/floresta em que
a conta do usuário é criada.
Para aumentar a segurança, você deve evitar vários usuários compartilhando uma
única conta e, mas sim garantir que cada usuário que faz logon na rede tem uma conta de
usuário e senha exclusivos.
Criando contas de usuário

Ao criar contas de usuário, considere as seguintes propriedades:
 O nome completo da propriedade da conta de usuário é usado para criar vários

atributos de um objeto de usuário, principalmente, o nome comum (CN) e as
propriedades de exibição de nome. O CN de um usuário é o nome exibido no painel
de detalhes do snap-in, e deve ser exclusivo dentro do conteiner ou OU. Se está
criando de um objeto de usuário para uma pessoa com o mesmo nome que um usuário
existente na mesma OU ou container, você precisa digitar um nome exclusivo no
campo Nome Completo.
 A propriedade logon UPN (User Principal Name) do usuário consiste em um prefixo do

nome de logon do usuário e um nome de usuário principal (UPN). É o sufixo que será
anexado ao nome de logon do usuário após o símbolo @.
o Os nomes de usuário no AD DS podem conter caracteres especiais, incluindo
pontos, hifens e apóstrofes. No entanto, alguns aplicativos podem ter outras
restrições, por isso recomendamos que você use apenas letras e números
padrão até que você testar completamente as aplicações no ambiente
corporativo para compatibilidade com caracteres especiais.
o Você pode gerenciar a lista de sufixos UPN disponíveis usando os domínios e

relações de confiança do Active Directory Snap-in. Botão direito do mouse na
raiz do snap-in, clique em Properties (Propriedades) e, em seguida, use a guia
sufixos UPN (UPN Suffixes) para adicionar ou remover sufixos. O nome de

DNS do seu domínio AD DS está sempre disponível como um sufixo, e você

não pode removê-lo.
Nota: É importante que você implemente uma estratégia de nomes de conta de

usuário, especialmente em grandes redes, onde os usuários podem compartilhar o mesmo
nome completo. A combinação do sobrenome e primeiro nome e, se necessário, caracteres
adicionais, deve produzir um único nome de conta de usuário. Especificamente, é apenas o
nome UPN que deve ser exclusivo dentro de sua floresta do AD DS. O nome completo deve
ser único apenas dentro da unidade organizacional onde ele reside, enquanto o nome
SamAccountName usuário deve ser único dentro desse domínio.
Configurando atributos de contas de usuários

Quando você cria uma conta de usuário no AD DS, você também pode configurar
todas as propriedades da conta de associados, ou atributos.
Em geral, o esquema não muda com frequência. No entanto, quando um aplicativo de

nível empresarial (como o Microsoft Exchange Server2010) é implementado muitas mudanças
de esquema são obrigatórios. Estas mudanças permitem que objetos, incluindo objetos de
usuário, para ter atributos adicionais.

Categorias de atributos
Os atributos de um objeto de usuário estão em várias categorias. Essas categorias
são exibidas no painel de navegação da caixa de diálogo Propriedades do usuário no Centro
Administrativo do Active Directory, e incluem o seguinte:
 Account. Além, das propriedades de usuário First name, Middle initial, Last name,
Full name. E também User UPN logon, User SamAccountName logon, Existem as
seguintes propriedades:
o Log on hours (horário de logon). Esta propriedade define quando a conta
pode ser usada para acessar os computadores do domínio.
o Log on to . Use esta propriedade para definir quais computadores um usuário

pode usar para fazer logon no domínio. Especifique o nome do computador e
adicione o a uma lista de computadores permitidos.
o Account expires. Este valor é útil quando você quer criar contas de usuário
de utilização temporária. Você pode usar esse valor para definir uma data de
expiração conta antecipadamente. A conta não pode ser usada após a data de
expiração até o reconfiguradas manualmente por um administrador.
o User must change password at next log on. Esta propriedade força um
usuário a redefinir sua própria senha na próxima vez que fizer logon. Isso
normalmente é algo que você pode permitir que depois de ter redefinir a senha
de um usuário.
o Smart card is required for interactive log on. Este valor redefine a senha do
usuário para uma sequência complexa, de caracteres aleatórios, e define uma
propriedade que requer que o usuário usar um cartão inteligente para
autenticar durante o logon.
o Password never expires. Esta é uma propriedade que você normalmente usa
com contas de serviço, ou seja, as contas que não são utilizados por usuários
comuns, mas pelos serviços. Ao definir este valor, você deve se lembrar de
atualizar a senha manualmente em uma base periódica, no entanto, você não
é obrigado a fazê-lo em um intervalo pré-determinado.
o User cannot change password. Novamente, esta opção é geralmente

utilizada para contas de serviço.
o Store password using reversible encryption. Essa política fornece suporte

para aplicativos que usam protocolos que exigem conhecimento da senha do
usuário para fins de autenticação. Armazenar senhas usando criptografia
reversível é essencialmente o mesmo que armazenar versões das senhas em
texto puro. Por esta razão, esta política não deve ser habilitada a menos que
os requisitos das aplicações superem a necessidade de proteger as
informações de senha. Esta política é necessária quando se utiliza
ChallengeHandshake Authentication Protocol (CHAP) através de acesso
remoto ou o serviço de autenticação da Internet (IAS). Também é necessário
ao usar a Autenticação Digest no Internet Information Services (IIS).

o Account is trusted for delegation. Você pode usar essa propriedade para
permitir que uma conta de serviço represente um usuário padrão para acessar
os recursos da rede em nome de um usuário.
 Organization. Inclui propriedades como Nome, Escritório, e-mail, contatos de

telephone, Estrutura gerencial, nome do departamento e compania names, endereços
e assim por diante.
 Member of. Esta seção permite que você defina as associações de grupo para o
usuário.
 Profile. Esta seção permite que você configure um local para os dados pessoais do
usuário, e definir um local para salvar o perfil desktop do usuário quando ele realizar
logout.
 Extensions. Esta seção apresenta muitas propriedades adicionais do utilizador, a

maioria dos quais normalmente não requerem configuração manual.
Usando a Diretiva de Grupo para gerenciar perfis

Como uma alternativa ao uso das configurações da conta de usuário individual, você
também pode usar GPOs para gerenciar essas configurações. Você pode definir as
configurações de redirecionamento de pasta usando o Editor de Gerenciamento de Diretiva
de Grupo para abrir uma GPO para edição e, em seguida, navegar para a configuração do
usuário\Policies\Windows em Configurações.
Estas definições conter os sub-nós na tabela a seguir.
Sub-nós do nó Configurações do Windows
• AppData (Roaming) • Pictures • Downloads

• Desktop • Music • Links
• Start Menu • Videos • Searches
• Document • Favorites • Saved Games
• Contacts
Você pode usar estes sub-nós para configurar todos os aspectos do perfil desktop de
um usuário e de configurações do aplicativo. Para um determinado sub-nó, como “Document”,
você pode escolher entre o redirecionamento Básico e Avançado. No redirecionamento
Básico, todos os usuários afetados pela GPO têm seus documentos pasta redirecionada para
uma subpasta individual fora de uma pasta raiz comum definida por um nome UNC, por
exemplo, SVR1\Users\. Redirecionamento avançado permite que você use os membros do
grupo de segurança para determinar onde as configurações do usuário e os documentos
serão armazenados.

Gerenciando Contas de Grupo

Embora possa ser prático para atribuir permissões para contas de usuários individuais
em pequenas redes, torna-se impraticável e ineficiente em grandes redes corporativas. Por
exemplo, se muitos usuários necessitam do mesmo nível de acesso a uma pasta, é mais
eficiente para criar um grupo que contém as contas de usuário necessárias e, em seguida,
atribuir o grupo as permissões necessárias. Isso tem o benefício adicional de permitir que
você altere as permissões de arquivo de um usuário, adicionando ou removendo-os de grupos
em vez de editar as permissões do arquivo diretamente.
Tipos de grupos
Em uma rede corporativa do Windows Server 2012, existem dois tipos de grupos:
segurança e distribuição. Quando você cria um grupo, você escolhe o tipo e o escopo grupo.
Os (Grupos de Distribuição), que não são de segurança, são usados principalmente

por aplicativos de e-mail. Isto significa que eles não têm SID, de modo que não pode ser dado
autorização para recursos. O envio de uma mensagem para um grupo de distribuição envia a
mensagem para todos os membros do grupo.
Os Security groups (grupos de segurança) são entidades de segurança com SIDs.

Você pode, portanto, utilizar esses grupos em entradas de permissão em listas de controle de
acesso (ACLs) para controlar a segurança para o acesso aos recursos. Você também pode
usar grupos de segurança como meio de distribuição para aplicativos de e-mail. Se você
quiser usar um grupo para gerenciar a segurança, deve ser um grupo de segurança
Nota: O tipo de grupo padrão é a segurança.

Porque você pode usar grupos de segurança, tanto para o acesso aos recursos e
distribuição de e-mail, muitas organizações usam apenas grupos de segurança. No entanto,
recomendamos que, se um grupo é usado apenas para a distribuição de e-mail, você deve
criar o grupo como um grupo de distribuição.
Nota: Considere que quando você adicionar um usuário a um grupo de segurança, o

acesso do usuário token que autentica os usuários nos processos de atualizações somente
quando o usuário autentica, portanto, se o usuário está conectado no momento, eles devem
fazer logoff e login novamente para atualizar o token de acesso com todos os membros do
grupo mudaram.
Nota: A vantagem de usar grupos de distribuição torna-se mais evidente em

implementações de grande escala do Exchange Server, especialmente onde há uma
necessidade de grupos de distribuição em toda a empresa.
Grupos de escopos
O Windows Server 2012 oferece suporte a grupo de escopo. O escopo de um grupo
determina a gama de habilidades ou permissões de um grupo, e os membros do grupo.
Há quatro escopos de grupo:

 Local. Este tipo de grupo é para servidores ou estações de trabalho independentes,

em servidores membros do domínio que não são controladores de domínio, ou em
estações de trabalho membros do domínio. Os grupos locais são verdadeiramente
local, o que significa que eles estão disponíveis apenas no computador em que elas
existem. As características importantes de um grupo local são:
o Você pode atribuir habilidades e permissões somente nos recursos locais, ou
seja, no computador local.
o Os membros podem ser de qualquer lugar do AD DS floresta, e podem incluir:
 As entidades de segurança do domínio: os usuários, computadores,
grupos globais e grupos locais de domínio.
 Os usuários, computadores e grupos globais de qualquer domínio na
floresta.
 Os usuários, computadores e grupos globais de qualquer domínio
confiável.
 Grupos universais definidos em qualquer domínio na floresta.
 Domain Local. Este tipo de grupo é usado principalmente para gerenciar o acesso a
recursos ou para atribuir responsabilidades de gestão (direitos). Grupos locais de
domínio existe em controladores de domínio em uma floresta AD DS e,
consequentemente, o escopo do grupo está localizada no domínio em que residem.
As características importantes de grupos locais de domínio são:
o Você pode atribuir habilidades e permissões somente sobre os recursos locais
de domínio, ou seja, em todos os computadores no domínio local.
o Os membros podem ser de qualquer lugar do AD DS floresta, e podem incluir:
 Quaisquer entidades de segurança do domínio: os usuários,
computadores, grupos globais ou grupos locais de domínio.
 Usuários, computadores e grupos globais de qualquer domínio na
floresta.
 Usuários, computadores e grupos globais de qualquer domínio
confiável.
 Grupos universais definido em qualquer domínio na floresta.
 Global. Este tipo de grupo é usado principalmente para consolidar os usuários que
possuem características semelhantes. Por exemplo, grupos globais muitas vezes são
usados para consolidar os usuários que fazem parte de um departamento ou
localização geográfica. As características importantes de grupos globais são:
o Você pode atribuir habilidades e permissões em qualquer lugar na floresta.
o Os membros podem ser apenas do domínio local, e podem ter:
 Usuários, computadores e grupos globais a partir de então de domínio
local.
 Universal. Este tipo de grupo é mais útil em redes de vários domínios, porque combina
as características de ambos os grupos locais de domínio e grupos globais.
Especificamente, as características importantes dos grupos são universais:
o Você pode atribuir habilidades e permissões em qualquer lugar da floresta,
como com grupos globais.
o Os membros podem ser de qualquer lugar do AD DS floresta, e podem ter:
 Usuários, computadores e grupos globais de qualquer domínio na
floresta.
 Grupos universais definidos em qualquer domínio na floresta.

o Propriedades de grupos universais são propagadas para o catálogo global

(Global Catalog), e disponibilizados na rede corporativa em todos os
controladores de domínio que hospedam a função de catálogo global. Isso faz
com que a lista de grupos universais mais acessível fique mais acessível. O
que pode ser útil em cenários de vários domínios. Por exemplo, se um grupo
universal é utilizado para fins de distribuição de e-mail, o processo para
determinar a lista de membros geralmente é mais rápida em redes de vários
domínios distribuídos.
Grupos Padrão
O servidor Windows Server 2012 cria uma série de grupos automaticamente. Estes
são chamados de grupos locais predefinidos, e que incluem grupos bem conhecidos, tais
como Administrators (Administradores), Backup Operators (Operadores de Backup), e
Remote Desktop Users (Área de trabalho remota). Há outros grupos que são criados em um
domínio, incluindo Domain Admins (Administradores de Domínio), Enterprise Admins
(Administradores de Empresa) e Schema Admins (Administradores de esquema).
A lista a seguir apresenta um resumo das funções para o subconjunto de grupos

padrão que têm permissões e direitos de usuário significativos relacionados com a gestão do
AD DS:
 Enterprise Admins (No container do domínio raiz da floresta). Este grupo é um

membro do grupo Administrators (Administradores) em todos os domínios da floresta,
que lhe dá acesso completo a configuração de todos os controladores de domínio.
Também possui a partição de configuração do diretório e tem total controle do contexto
de nomeação de domínio em todos os domínios da floresta.
 Schema Admins (No container do domínio raiz da floresta). Este grupo é dono e tem
o controle total do schema (esquema) do Active Directory.
 Administrators (container built-in de cada domínio). Os membros deste grupo tem

controle total sobre todos os controladores de domínio e de dados no contexto de
nomeação de domínio (domain naming contexto). Eles podem mudar a relação de
todos os outros grupos administrativos no domínio, e o grupo de Administrators
(administradores) do domínio raiz da floresta pode mudar os membros dos grupos
Enterprise Admins (Administração de Empresa), Schema Admins (Administradores de
esquema) e Administradores do Domínio (Domain Admins). O grupo de
administradores do domínio raiz da floresta é sem dúvida o grupo de administração de
serviços mais poderosa na floresta.
 Domain Admins (container built-in de cada domínio). Este grupo é adicionado ao

grupo de Administrators (administradores) de seu domínio. Consequentemente, herda
todas as capacidades do grupo de administradores. Também é, por padrão,
adicionado ao grupo Administrators (Administradores) local de cada computador
membro de domínio, dando ao Domain Admins (Administradores do Domínio)
propriedade de todos os computadores do domínio.
 Server Operators (container built-in de cada domínio). Os membros deste grupo

podem executar tarefas de manutenção em controladores de domínio. Eles têm o
direito de fazer logon localmente, iniciar e parar serviços, executar operações de

backup e restauração, discos de formato, criar ou excluir ações, e desligar os

controladores de domínio. Por padrão, esse grupo não possui membros.
 Account Operators (container built-in de cada domínio). Os membros deste grupo

podem criar, modificar e apagar contas de usuários, grupos e computadores
localizados em qualquer unidade organizacional no domínio (exceto na OU dos
controladores de domínio), e nos containers Users (usuários) e computers
(computadores). Os membros do grupo de Account Operators não podem modificar
as contas que são membros dos grupos Administrators (Administradores) ou Domain
Admins (Administradores de Domínio), nem podem modificar esses grupos. Os
membros do grupo Account Operators também pode fazer logon localmente para
controladores de domínio. Por padrão, esse grupo não possui membros.
 Backup Operators (container built-in de cada domínio). Os membros desse grupo

podem executar operações de backup e em controladores de domínio restaurar e fazer
logon localmente. Além de desligar os controladores de domínio. Por padrão, esse
grupo não possui membros.
 Print Operators (container built-in de cada domínio). Os membros deste grupo podem
manter as filas de impressão em controladores de domínio. Eles também podem fazer
logon localmente e desligar os controladores de domínio
 • Você precisa gerenciar cuidadosamente os grupos padrão que oferecem privilégios

administrativos, porque eles geralmente têm privilégios mais amplos do que os
necessários para a maioria dos ambientes, e porque muitas vezes aplicar proteção
aos seus membros.
O grupo Account Operators é um bom exemplo disso. Se você examinar as

capacidades deste grupo na lista anterior, você pode ver que os membros deste grupo têm
muito direitos, eles podem até mesmo fazer logon localmente para um controlador de domínio.
Em redes muito pequenas, tais direitos, provavelmente, seria adequado para uma ou duas
pessoas que normalmente seriam administradores de domínio de qualquer maneira. Nas
grandes empresas, os direitos e as permissões concedidas a operadores de contas são
geralmente muito amplo.
Além disso, o grupo Account Operators é, como os outros grupos administrativos, um

grupo protegido.

3.2. GROUP POLICY (GPO)

Política de Grupo fornece uma infraestrutura na qual você pode definir configurações
centralmente e implantá-las aos usuários e aos computadores em sua empresa. Em um
ambiente gerenciado por uma infraestrutura de Política de Grupo bem-implementada, uma
parte muito pequena da configuração é feita diretamente por um administrador no computador
de um usuário. Você pode definir, aplicar e atualizar a configuração inteira usando as
configurações em GPOs (Objetos de Política de Grupo) ou filtragem de GPOs. Por meio de
configurações de GPO, você pode afetar um site ou um domínio inteiro de uma empresa ou
limitar seu foco a uma única OU (unidade organizacional).
Gerenciamento de configuração
Se você tiver só um computador em seu ambiente, por exemplo, em casa, e precisar
modificar o plano de fundo da área de trabalho, poderá fazê-lo de vários modos diferentes. A
maioria das pessoas, provavelmente, abriria Aparência e Personalização no Painel de
Controle e faria a alteração por meio da interface do Windows. Embora isso funcione bem em
um computador, poderá ser tedioso se desejar fazer a alteração em vários computadores. É
mais difícil implementar qualquer alteração e manter um ambiente consistente em vários
computadores.
Gerenciamento de configuração é uma abordagem centralizada à aplicação de uma ou mais

alterações a um ou mais usuários ou computadores. Os principais elementos do
gerenciamento de configuração são os seguintes:
 Configuração. Configuração também é conhecida como uma definição centralizada
de uma alteração. A configuração traz um usuário ou um computador a um estado
desejado de configuração.
 Escopo. O escopo da alteração é a capacidade de alterar os computadores dos

usuários.
 Aplicação. A aplicação é um mecanismo ou um processo que assegura que a

configuração seja aplicada aos usuários e aos computadores dentro do escopo.
Política de Grupo é uma estrutura dentro do Windows - com componentes que residem
no AD DS (Serviços de Domínio Active Directory, em controladores de domínio e em cada
servidor e cliente Windows - que permite gerenciar a configuração em um domínio do AD DS.
Visão geral das Políticas de Grupo

O componente mais granular de Política de Grupo é uma configuração de política
individual, também conhecida como uma política que define uma alteração de configuração
específica a ser aplicada, como uma configuração de política que impede um usuário de
acessar ferramentas de edição de Registro. Se você definir essa configuração de política e,
em seguida, aplicá-la ao usuário, este não poderá executar ferramentas como Regedit.exe.

É importante saber que algumas configurações afetam um usuário, conhecidas como

configurações de usuário (ou políticas de usuário), e algumas afetam o computador,
conhecidas como configurações de computador (ou políticas de computador).
Uma Política de Grupo gerencia várias configurações de política, e a estrutura de

Política de Grupo é extensível. No final, você pode gerenciar quase qualquer definição
configurável com a Política de Grupo.
No Editor de Gerenciamento de Política de Grupo, você pode definir uma configuração

de política clicando nela duas vezes. A caixa de diálogo Propriedades da configuração de
política é exibida. Uma configuração de política pode ter três estados: Não Configurado,
Habilitado e Desabilitado.
No Editor de Gerenciamento de Política de Grupo, você pode definir uma configuração

de política clicando nela duas vezes. A caixa de diálogo Propriedades da configuração de
política é exibida. Uma configuração de política pode ter três estados: Não Configurado,
Habilitado e Desabilitado.
Objetos de Política de Grupo

As configurações de política são definidas e existem dentro de um GPO. GPO é um
objeto que contém uma ou mais configurações de política que se aplicam a um ou mais
configurações para um usuário ou um computador.
Os GPOs são exibidos em um contêiner denominado Objetos de Política de Grupo.
Para criar um novo GPO em um domínio, clique com o botão direito do mouse no
contêiner Objetos de Política de Grupo e, em seguida, clique em Novo.
Para modificar as configurações em um GPO, clique com o botão direito do mouse no

GPO e, em seguida, clique em Editar. O snap-in do Editor de Gerenciamento de Política de
Grupo é aberto.
O Editor de Gerenciamento de Política de Grupo exibe os milhares de configurações

de política disponíveis em um GPO em uma hierarquia organizada que começa com a divisão
entre configurações de computador e de usuário: os nós Configuração do Computador e
Configuração do Usuário.
Observação: O GPO deve ser se aplicado a um domínio, um site ou uma OU na

hierarquia do AD DS para que as configurações dentro do objeto entrem em vigor.

Versão: 1.3- Pág. 100 de 377
Escopo do GPO
A configuração é definida por configurações de política em GPOs. No entanto, as
alterações de configuração em um GPO não afetarão os computadores nem os usuários de
sua organização até que você especifique os computadores ou os usuários aos quais o GPO
se aplicará. Isso é denominado definição do escopo de um GPO. O escopo de um GPO é a
coleção de usuários e computadores que aplicarão as configurações no GPO.
Administração de GPOs
Política de Domínio Padrão
Este GPO é vinculado ao domínio e não tem nenhum grupo de segurança nem filtros
WMI. Portanto, ele afeta todos os usuários e computadores no domínio, inclusive
computadores que são controladores de domínio. Este GPO contém configurações de política
que especificam senha, bloqueio de conta e políticas de protocolo Kerberos versão 5. Você
não deve acrescentar configurações de política não relacionadas a este GPO. Se precisar
definir outras configurações para aplicar amplamente em seu domínio, crie GPOs adicionais
que se vinculem ao domínio.
Política de Controladores de Domínio Padrão

Esse GPO é vinculado à OU dos controladores de domínio. Como as contas de
computador para controladores de domínio são mantidas exclusivamente na OU
Controladores de Domínio, e outras contas de computador devem ser mantidas em outras
OUs, esse GPO só afeta controladores de domínio. É necessário modificar o GPO
Controladores de Domínio Padrão para implementar suas políticas de auditoria e atribuir os
direitos de usuário necessários em controladores de domínio.
Armazenamento de GPO
As configurações de Política de Grupo são apresentadas como GPOs nas ferramentas
de interface do usuário do AD DS, mas, na realidade, o GPO compreende dois componentes:
um contêiner e um modelo Política de Grupo.
O contêiner Política de Grupo é um objeto do AD DS armazenado no contêiner Objetos

de Política de Grupo dentro do contexto de nomeação de domínio do diretório. Como todos
os objetos AD DS, cada contêiner Política de Grupo inclui um atributo GUID (identificador
exclusivo) que identifica, de forma exclusiva, o objeto no AD DS. O contêiner Política de Grupo
define atributos básicos do GPO, mas não contém nenhum das configurações. As
configurações são contidas no modelo Política de Grupo, uma coleção de arquivos
armazenada no Volume de Sistema (SYSVOL) de cada controlador de domínio no caminho
%SystemRoot%\SYSVOL\Domain\Policies\GPOGUID, onde GPOGUID é o GUID do
contêiner Política de Grupo. Quando são feitas alterações nas configurações de um GPO, as
alterações são salvas ao modelo Política de Grupo do servidor do qual o GPO foi aberto.

Versão: 1.3- Pág. 101 de 377
Replicação de GPO
O contêiner e o modelo Política de Grupo são replicados entre todos os controladores
de domínio no AD DS. No entanto, são usados mecanismos de replicação diferentes para
esses dois itens.
Permissões padrão de Política de Grupo

Por padrão, o usuário e os grupos a seguir têm controle total do gerenciamento de
GPOs:
 Administradores de Domínio
 Administradores de Empresa
 Proprietário Criador
 Sistema Local
O grupo Usuários Autenticados tem as permissões Leitura e Aplicar Política de Grupo.
Criação de GPOs
Por padrão, só Administradores de Domínio, Administradores de Empresa e
Proprietários Criadores de Política de Grupo podem criar novos GPOs. Você pode usar dois
métodos para conceder esse direito a um grupo ou um usuário:
 Adicionar o grupo ou o usuário ao grupo Proprietários Criadores de Política de Grupo
 Conceder explicitamente ao grupo ou ao usuário a permissão para criar GPOs com o

GPMC.
Gerenciamento de links de GPO

A capacidade de vincular GPOs a um contêiner é uma permissão que é específica ao
contêiner em questão. No GPMC, você pode gerenciar essa permissão usando a guia
Delegação no contêiner. Você também pode concedê-la por meio da Delegação do Assistente
de Controle em Usuários e Computadores do Active Directory.
Modelagem e Resultados da Política de Grupo

Você pode delegar a capacidade de usar as ferramentas de relatório da mesma forma,
por meio do GPMC ou da Delegação do Assistente de Controle em Usuários e Computadores
do Active Directory.
Criação de filtros WMI

Você pode delegar a capacidade de criar e gerenciar filtros WMI da mesma forma, por
meio do GPMC ou da Delegação do Assistente de Controle em Usuários e Computadores do
Active Directory.
Vinculação de um GPO a várias OUs

Você pode vincular um GPO a mais de um site ou uma OU. Por exemplo, é comum
aplicar configuração a computadores em várias OUs. Você pode definir a configuração em um

Versão: 1.3- Pág. 102 de 377
único GPO e, em seguida, vincular esse GPO a cada OU. Se posteriormente você alterar as
configurações no GPO, suas alterações serão aplicadas a todas as OUs às quais o GPO
estiver vinculado.
Exclusão ou desabilitação de um link de GPO

Depois de vincular um GPO, o link de GPO aparece no GPMC abaixo do site, do
domínio ou da OU. O ícone do link de GPO tem uma pequena seta de atalho. Quando você
clica com o botão direito do mouse no link de GPO, um menu de contexto é exibido:
 Para excluir um link de GPO, clique nele com o botão direito do mouse na árvore de
console do GPMC e, em seguida, clique em Excluir.
A exclusão de um link de GPO não exclui o GPO em si, que permanece no contêiner
de GPO em questão. No entanto, a exclusão do link altera o escopo do GPO, de forma que
ele não se aplique mais aos computadores e aos usuários dentro do objeto de contêiner
vinculado anteriormente.
Você também pode modificar um link de GPO desabilitando o seguinte:

 Para desabilitar um link de GPO, clique nele com o botão direito do mouse na árvore
de console do GPMC e, em seguida, desmarque a opção Vínculo Habilitado.
A desativação do link também altera o escopo do GPO de forma que ele não se aplique
mais aos computadores e aos usuários inseridos no contêiner em questão. No entanto, o link
permanece para que você possa reabilitá-lo com facilidade.
Ordem de processamento da Política de Grupo

Os GPOs que se aplicam a um usuário, um computador ou ambos não são aplicados
imediatamente. Os GPOs são aplicados em uma ordem específica. Essa ordem significa que
as configurações que são processadas primeiro podem ser substituídas por configurações
conflitantes que são processadas posteriormente.

Versão: 1.3- Pág. 103 de 377
A Política de Grupo segue esta ordem de processamento hierárquica:
1. Políticas de grupo locais. Cada computador no qual o Windows 2000 ou versão mais
recente é executado tem, pelo menos, uma política de grupo local. As políticas locais
são aplicadas primeiro.
2. Políticas de grupo de site. As políticas vinculadas a sites são processadas em seguida.

Se houver várias políticas de site, elas serão processadas de forma síncrona na ordem
de preferência listada.
3. Políticas de grupo de domínio. As políticas vinculadas a domínios são processadas

em terceiro lugar. Se houver várias políticas de domínios, elas serão processadas de
forma síncrona na ordem de preferência listada.
4. Políticas de grupo de OU. As políticas vinculadas a OUs de nível superior são

processadas em quarto lugar. Se houver várias políticas de OU de nível superior, elas
serão processadas de forma síncrona na ordem de preferência listada.
5. Políticas de grupo de OU filho. As políticas vinculadas a OUs filho são processadas

em quinto lugar. Se houver várias políticas de OU filho, elas serão processadas de
forma síncrona na ordem de preferência listada. Quando houver vários níveis de OUs
filho, as políticas de OUs de nível superior serão aplicadas primeiro, e as políticas de
OUs de nível inferior serão aplicadas em seguida.

Versão: 1.3- Pág. 104 de 377
Na aplicação de Política de Grupo, a regra geral é que a última política aplicada tem
precedência. Por exemplo, uma política que restringe o acesso ao Painel de Controle aplicada
no nível de domínio pode ser revertida por uma política aplicada no nível da OU para os
objetos contidos nessa OU específica.
Se você vincular vários GPOs a uma OU, o processamento deles ocorrerá na ordem
que o administrador especificar na guia Objetos de Política de Grupo Vinculados no GPMC.
Por padrão, o processando é habilitado para todos os links de GPO. Você pode
desabilitar o link de GPO de um contêiner para bloquear a aplicação de um GPO
completamente para um determinado site, um domínio ou uma OU. Observe que se o GPO
estiver vinculado a outros contêineres, eles continuarão a processar o GPO se os respectivos
links forem habilitados.
Você também pode desabilitar a configuração do usuário ou do computador de um

GPO específico independente do usuário ou do computador. Se uma determinada seção de
uma política estiver vazia, a desativação do outro lado agilizará o processamento de política.
Por exemplo, se você tiver uma política que só entregue configuração da área de trabalho do
usuário, poderá desabilitar o lado do computador da política.
Processamento de política loopback

Por padrão, as configurações de um usuário se originam de GPOs cujo escopo foi
definido para o objeto de usuário no AD DS. Independentemente do computador no qual o
usuário faz logon, o conjunto de políticas resultante que determina o ambiente do usuário é o
mesmo. Porém, há situações nas quais você pode desejar configurar um usuário de forma
diferente, dependendo do computador em uso. Por exemplo, você pode desejar bloquear e
padronizar áreas de trabalho de usuário quando os usuários entram em computadores em
ambientes rigidamente gerenciados, como salas de conferência, áreas de recepção,
laboratórios, salas de aula e quiosques. Isso também é importante para cenários VDI (Virtual
Desktop Infrastructure), inclusive máquinas virtuais remotas e RDS (Serviços de Área de
Trabalho Remota).
Imagine um cenário no qual você deseja aplicar uma aparência corporativa padrão
para a área de trabalho do Windows em todos os computadores de salas de conferência e
outras áreas públicas de seu escritório. Como você gerenciará essa configuração
centralmente usando Política de Grupo? As configurações de política que definem a aparência
de área de trabalho estão localizadas no nó Configuração do Usuário de um GPO. Portanto,
por padrão, as configurações se aplicam a usuários, não importando o computador no qual
eles entrem. O processamento de política padrão não lhe oferece uma maneira de definir o
escopo de configurações de usuário a serem aplicadas a computadores, independentemente
do usuário que faz logon. Essa é a forma como o processamento de política loopback pode
ser útil.
O processamento de política loopback altera o algoritmo padrão que o cliente de

Política de Grupo usa para obter a lista ordenada de GPOs que devem ser aplicados à

Versão: 1.3- Pág. 105 de 377
configuração de um usuário. Em vez de a configuração de usuário ser determinada pelo nó

Configuração do Usuário de GPOs cujo escopo foi definido para o objeto de usuário, a
configuração de usuário pode ser determinada pelas políticas do nó Configuração do Usuário
de GPOs cujo escopo foi definido para o objeto de computador.
Identificar configurações efetivas

Há vários processos que devem ser concluídos para que as configurações de Política
de Grupo sejam de fato aplicadas a um usuário ou um computador.
A replicação de GPOs deve acontecer

Para que um GPO entre em vigor, o contêiner Política de Grupo no Active Directory
deve ser replicado no controlador de domínio do qual o Cliente de Política de Grupo obtém
sua lista ordenada de GPOs. Além disso, o modelo Política de Grupo no SYSVOL deve ser
replicado no mesmo controlador de domínio.
As alterações do grupo devem ser incorporadas

Finalmente, se você adicionou um novo grupo ou alterou a associação de um grupo
que é usado para filtrar o GPO, essa alteração também deverá ser replicada. Além disso, a
alteração deverá ser feita no token de segurança do computador e do usuário, o que exige
uma reinicialização (para que o computador atualize sua associação de grupo) ou logoff e
logon (para que o usuário atualize sua associação de grupo).
A atualização de Política de Grupo de usuário ou computador deverá ocorrer

Por padrão, a atualização ocorre na inicialização (para as configurações de
computador), no logon (para configurações de usuário) e, posteriormente, a cada 90 a 120
minutos.
Atualização manual de Política de Grupo

Ao experimentar o processamento de Política de Grupo para solução de problemas de
Política de Grupo, você pode precisar iniciar uma atualização de Política de Grupo manual
para não precisar aguardar a próxima atualização em segundo plano. Você pode usar o
comando GPUpdate para iniciar essa atualização. Usado isoladamente, esse comando
dispara um processamento idêntico a uma atualização de Política de Grupo em segundo
plano. As políticas de computador e de usuário são atualizadas. Use o parâmetro
/target:computer ou /target:user para limitar a atualização às configurações de computador
ou de usuário, respectivamente. Durante a atualização em segundo plano, por padrão, as
configurações serão aplicadas apenas se o GPO tiver sido atualizado. A opção /force faz com
que o sistema reaplique todas as configurações contidas em todos os GPOs cujo escopo foi
definido para o usuário ou o computer. Algumas configurações de política requerem um logoff
ou uma reinicialização para que realmente entrem em vigor. As opções /logoff e /boot do
comando GPUpdate causam um logoff ou uma reinicialização, conforme o caso. Você pode
usar essas opções ao aplicar configurações que requeiram um logoff ou uma reinicialização.
Por exemplo, o comando que causará uma aplicação de atualização total e, se
necessário, reinicializará e fará logon para aplicar as configurações de política atualizadas é:
gpupdate /force /logoff /boot

Versão: 1.3- Pág. 106 de 377
Geração de relatórios de RSoP

Para ajudar a analisar o efeito cumulativo de GPOs e configurações de política em um
usuário ou um computador em sua organização, o GPMC inclui o Assistente de Resultados
de Política de Grupo. Se você desejar entender exatamente quais configurações de política
foram aplicadas a um usuário ou um computador, e por quê, o Assistente de Resultados de
Política de Grupo é a ferramenta a ser usada.

Versão: 1.3- Pág. 107 de 377
3.3. REPLICAÇÃO
Dentro de uma infraestrutura AD DS, os controladores de domínio padrão replicam
informações do Active Directory usando um modelo de replicação de vários mestres. Isso
significa que, se for feita uma alteração em um controlador de domínio, essa alteração será
replicada em todos os outros controladores do domínio, e provavelmente em todos os
controladores de domínio da floresta inteira. Esta lição fornece uma visão geral de como o AD
DS replica informações entre controladores de domínio padrão e somente leitura (RODCs).
Partições do AD DS
O repositório de dados do Active Directory contém informações que o AD DS distribui
a todos os controladores de domínio na infraestrutura da floresta. A maior parte das
informações que o repositório de dados contém é distribuída dentro de um único domínio.
Entretanto, algumas informações podem estar relacionadas à floresta inteira,
independentemente dos limites do domínio, e replicadas nela.
Para ajudar a fornecer eficiência e escalabilidade de replicação entre controladores de

domínio, os dados do Active Directory são separados logicamente em várias partições. Cada
partição é uma unidade de replicação, e cada uma delas tem sua própria topologia de
replicação. As partições padrão incluem as seguintes:
 Partição de configuração. A partição de configuração é criada automaticamente

quando você cria o primeiro domínio de uma floresta. A partição de configuração
contém informações sobre a estrutura do AD DS na floresta, inclusive quais domínios
e sites existem e quais controladores de domínio existem em cada domínio. A partição
de configuração também armazena informações sobre serviços de toda a floresta,
como autorização do protocolo DHCP e modelos de certificados. Essa partição é
replicada em todos os controladores de domínio da floresta.

Versão: 1.3- Pág. 108 de 377
 Partição de esquema. Contém definições de todos os objetos e atributos que você

pode criar no repositório de dados, além das regras para criá-los e manipulá-los. As
informações de esquema são replicadas em todos os controladores de domínio da
floresta. Portanto, todos os objetos devem estar em conformidade com as regras de
definição de atributos e objetos de esquema. O AD DS contém um conjunto padrão de
classes e atributos que você não pode modificar. Porém, se você tiver credenciais de
Administradores de Esquema, poderá estender o esquema adicionando novos
atributos e classes para representar classes específicas ao aplicativo. Muitos
aplicativos, como o Microsoft Exchange Server e o Microsoft System Center
Configuration Manager, podem estender o esquema para oferecer aprimoramentos de
configuração específicos ao aplicativo. Essas alterações se destinam ao controlador
de domínio que contém a função de mestre de esquema da floresta. Somente o mestre
de esquema está autorizado a fazer acréscimos a classes e atributos.
 Partição de domínio. Quando você cria um novo domínio, o AD DS automaticamente

cria e replica uma instância da partição de domínio em todos os controladores no
domínio. A partição de domínio contém informações sobre todos os objetos
específicos ao domínio, incluindo usuários, grupos, computadores, OUs (unidades
organizacionais) e configurações do sistema relacionadas ao domínio. Todos os
objetos em cada partição de domínio em uma floresta são armazenados no catálogo
global, com apenas um subconjunto de seus valores de atributo.
 Partição de aplicativo. A partição de aplicativo armazena as informações

relacionadas ao aplicativo e não ao domínio que podem ter tendência a serem
atualizadas com frequência ou ter uma vida útil especificada. Um aplicativo é
normalmente programado para determinar como armazena, categoriza e usa
informações específicas ao aplicativo que são armazenadas no banco de dados do
Active Directory. Para evitar a replicação desnecessária de uma partição de aplicativo,
você pode determinar quais controladores de domínio em uma floresta hospedarão a
partição do aplicativo específico. Ao contrário de uma partição de domínio, uma
partição de aplicativo não armazena objetos de entidades de segurança, como contas
de usuário. Além disso, o catálogo global não armazena dados contidos em partições
de aplicativo.
Observação: Você pode usar o Editor do Active Directory Service Interfaces (Editor
ADSI) para se conectar e exibir as partições.
Como funciona a replicação do AD DS dentro de um site

A replicação do AD DS dentro de um único site, que ocorre automaticamente, é
chamada de replicação intra-site. Entretanto, você também pode configurá-la para ocorrer
manualmente, conforme necessário. Os seguintes conceitos estão relacionados à replicação
intra-site:
 Objetos de conexão
 O Knowledge Consistency Checker

Versão: 1.3- Pág. 109 de 377
 Notificação
 Sondagem
Objetos de conexão
Um controlador de domínio que replica alterações de outro controlador de domínio é
chamado de parceiro de replicação. Os parceiros de replicação são vinculados por objetos de
conexão. Um objeto de conexão representa um caminho de replicação de um controlador de
domínio para outro. Os objetos de conexão são unidirecionais, representando a replicação
pulls somente de entrada.
Para exibir e configurar objetos de conexão, abra Serviços e Sites do Active Directory
e selecione o contêiner Configurações de NTDS do objeto de servidor de um controlador de
domínio. Você pode forçar a replicação entre dois controladores de domínio clicando com o
botão direito do mouse no objeto de conexão e selecionando Replicar Agora. Observe que
a replicação é somente de entrada, portanto, se você desejar replicar ambos os controladores
de domínio, precisará replicar o objeto de conexão de entrada de cada controlador de domínio.

Versão: 1.3- Pág. 110 de 377
O Knowledge Consistency Checker

Os caminhos de replicação que são criados entre os controladores de domínio por
objetos de conexão criam a topologia de replicação da floresta. Você não precisa criar a
topologia de replicação manualmente. Por padrão, o AD DS cria uma topologia que assegura
a replicação eficiente. A topologia é bidirecional, o que significa que, se qualquer controlador
de domínio falhar, a replicação continuará sem interrupção. A topologia também assegura que
não haja mais de três saltos entre dois controladores de domínio.
Em cada controlador de domínio, um componente do AD DS chamado KCC

(Knowledge Consistency Checker) ajuda a gerar e otimizar a replicação automaticamente
entre os controladores de domínio de um site. O KCC avalia os controladores de domínio em
um site e, em seguida, cria objetos de conexão para criar a topologia bidirecional de três saltos
descrita anteriormente. Se você adicionar ou remover um controlador de domínio, ou se um
controlador de domínio não estiver respondendo, o KCC reorganizará a topologia
dinamicamente, adicionando e excluindo objetos de conexão para recriar uma topologia de
replicação eficiente. O KCC é executado em intervalos especificados (a cada 15 minutos, por
padrão) e determina as rotas de replicação entre os controladores de domínio que são as
conexões mais favoráveis disponíveis no momento.
Notificação
Quando é feita uma alteração em uma partição do Active Directory em um controlador
de domínio, este coloca a alteração na fila para replicação em seus parceiros. Por padrão, o
servidor de origem espera 15 segundos para notificar seu primeiro parceiro de replicação da
alteração. Notificação é o processo pelo qual um parceiro upstream informa seus parceiros
downstream de que uma alteração está disponível. Por padrão, o controlador de domínio de
origem aguarda três segundos entre as notificações a parceiros adicionais. Esses atrasos,
chamados de atraso de notificação inicial e atraso de notificação subsequente, foram
projetados para coordenar o tráfego de rede que a replicação intra-site pode gerar.
Ao receber a notificação, o parceiro downstream solicita as alterações do controlador

de domínio de origem, e o agente de replicação de diretório efetua pull das alterações do
controlador de domínio de origem. Por exemplo, suponha que o controlador de domínio DC01
inicialize uma alteração no AD DS. Quando o DC02 receber a alteração do DC01, ele fará a
alteração em seu diretório. O DC02 colocará então a alteração na fila para replicação em seus
próprios parceiros downstream.
Em seguida, suponha que o DC03 seja um parceiro de replicação downstream do

DC02. Depois de 15 segundos, o DC02 notifica o DC03 de que tem uma alteração. O DC03
faz a alteração replicada em seu diretório e, em seguida, notifica seus parceiros downstream.
A alteração faz dois saltos, de DC01 para DC02 e de DC02 para DC03. A topologia de
replicação assegura que não ocorram mais de três saltos antes de todos os controladores de
domínio do site receberem a alteração. Em aproximadamente 15 segundos por salto, a
alteração é replicada completamente no site dentro de um minuto.

Versão: 1.3- Pág. 111 de 377
Como o catálogo global afeta a replicação

A partição de configuração contém informações sobre a topologia do site e outros
dados globais de todos os domínios que são os membros da floresta. O AD DS replica a
partição de configuração em todos os controladores de domínio por meio da replicação em
toda a floresta. Cada servidor de catálogo global obtém informações do domínio procurando
o controlador desse domínio e obtendo as informações sobre a réplica parcial. A partição de
configuração também oferece aos controladores de domínio uma lista dos servidores de
catálogo global da floresta. Os servidores de catálogo global armazenam registros do serviço
DNS na zona DNS que corresponde ao domínio raiz da floresta. Esses registros, que são
armazenados somente na zona DNS da raiz da floresta, ajudam os clientes e os servidores a
localizar servidores de catálogo global em toda a floresta para oferecer serviços de logon de
clientes.
Como a replicação RODC funciona

Como mencionado anteriormente, os controladores de domínio replicam dados
efetuando pull das alterações de outros controladores de domínio de origem. Um RODC não
permite que nenhuma alteração não replicada seja gravada em seu banco de dados, e nunca
replica informações em outros controladores de domínio. Como as alterações nunca são
gravadas em um RODC diretamente, outros controladores de domínio não precisam efetuar
pull das alterações de diretório de um RODC. Restringir os RODCs de originar alterações
impede que prováveis alterações ou danos de um usuário ou aplicativo mal-intencionado
sejam replicados no restante da floresta.

Versão: 1.3- Pág. 112 de 377
Replicação de sites do AD DS
Dentro de um único site, a replicação do AD DS ocorre automaticamente sem
considerar a utilização de rede. Porém, algumas organizações possuem vários locais que são
conectados por meio de conexões WAN (rede de longa distância). Se esse for o caso, você
deve assegurar que replicação do AD DS não afete a utilização de rede negativamente entre
os locais. Você também pode precisar localizar serviços de rede em um local específico.
O que são objetos de sub-rede?

Os objetos de sub-rede identificam os endereços de rede que mapeiam computadores
para sites do AD DS. Uma sub-rede é um segmento de uma rede TCP/IP à qual um conjunto
de endereços IP lógicos está atribuído. Como todos os objetos de sub-rede são mapeados
para a rede física, os sites também são. Um site consiste em uma ou mais sub-redes.
Como funciona a replicação entre sites

As principais características da replicação em sites são as seguintes:
 As conexões de rede no site são confiáveis, baratas e têm largura de banda disponível
suficiente.
 O tráfego de replicação no site não é compactado, pois um site presume conexões de

rede altamente confiáveis e rápidas. A não compactação do tráfego de rede ajuda a
reduzir a carga de processamento nos controladores de domínio. Porém, o tráfego
descompactado pode aumentar a largura de banda da rede.
 Um processo de notificação de alteração inicia a replicação no site.
As principais características da replicação entre sites são as seguintes:

Versão: 1.3- Pág. 113 de 377
 Os links de rede entre os sites têm largura de banda disponível limitada, podem ter um
custo mais alto e talvez não sejam confiáveis.
 O tráfego de replicação entre sites pode ser projetado para otimizar a largura de banda
compactando todo o tráfego de replicação. Ele é compactado em 10 a 15% de seu
tamanho original antes de ser transmitido. Apesar de a compactação otimizar a largura
de banda de rede, ela impõe uma carga de processamento adicional nos controladores
de domínio quando compacta e descompacta os dados da replicação.
 A replicação entre sites acontece automaticamente depois que você define valores
configuráveis, como uma agenda ou um intervalo de replicação. Você pode agendar a
replicação para horários mais baratos ou fora do pico. Por padrão, as alterações são
replicadas entre os sites conforme uma agenda definida, e não quando as alterações
ocorrem. A agenda determina quando a replicação pode ocorrer. O intervalo especifica
como os controladores de domínio verificam as alterações durante o tempo que a
replicação pode ocorrer.
O que é o gerador de topologia entre sites?

Quando você configura vários sites, o KCC em um controlador de domínio de cada site
é designado como o ISTG (gerador de topologia entre sites) do site. Existe apenas um ISTG
por site, independentemente de quantos domínios ou outras partições de diretório o site
possui. O ISTG é responsável por calcular a topologia de replicação ideal do site.
Quando você adiciona um novo site à floresta, o ISTG de cada site determina quais
partições de diretório estão presentes no novo site. O ISTG calcula então quantos novos
objetos de conexão são necessários replicar as informações necessárias do novo site. Em
algumas redes, você talvez queira especificar que somente determinados controladores de
domínio sejam responsáveis pela replicação entre sites. Você pode fazer isso especificando
servidores bridgehead. Os servidores bridgehead são responsáveis por toda a replicação que
entra e sai do site. O ISTG cria o acordo de conexão necessário em seu diretório, e essas
informações são replicadas no servidor bridgehead, que então cria uma conexão de
replicação com o servidor bridgehead no site remoto, e a replicação é iniciada. Se um parceiro
de replicação se tornar indisponível, o ITSG selecionará outro controlador de domínio
automaticamente, se possível. Se forem atribuídos servidores bridgehead manualmente, e se
eles ficarem indisponíveis, o ISTG não selecionará outros servidores automaticamente.
O ISTG seleciona servidores bridgehead automaticamente e cria a topologia de

replicação entre sites para assegurar que as alterações sejam replicadas com eficiência entre
os servidores bridgehead que compartilham um link de site. Os servidores bridgehead são
selecionados por partição, então é possível que um controlador de domínio em um site seja o
servidor bridgehead para o esquema, e haja outro para a configuração. Entretanto, você
normalmente achará que um controlador de domínio é o servidor bridgehead para todas as
partições de um site, a menos que haja controladores de domínio de outros domínios ou
partições do diretório de aplicativos. Nesse caso, serão escolhidos bridgeheads para essas
partições.
Ferramentas para gerenciar e monitorar a replicação

Versão: 1.3- Pág. 114 de 377
Depois de implementar sua configuração de replicação, você deverá ser capaz de

monitorar a replicação para suporte contínuo, otimização e solução de problemas. Duas
ferramentas são particularmente úteis para relatar e analisar a replicação: a ferramenta
Diagnósticos da Replicação (Repadmin.exe) e a ferramenta Diagnóstico do Servidor de
Diretório (Dcdiag.exe).
A ferramenta Diagnósticos da Replicação

Diagnósticos da Replicação, Repadmin.exe, é uma ferramenta de linha de comando que
permite relatar o status da replicação em cada controlador de domínio. As informações que
Repadmin.exe gera podem ajudar você a detectar um possível problema com a replicação
na floresta. Você pode exibir níveis de detalhes até os metadados da replicação para
objetos e atributos específicos, permitindo a identificação de onde e quando uma alteração
problemática for feita no AD DS. Você pode até usar a ferramenta Repadmin.exe para exibir
a topologia de replicação e forçar a replicação entre os controladores de domínio.

Versão: 1.3- Pág. 115 de 377
3.4. AD LDS

Versão: 1.3- Pág. 116 de 377
Ao usar a função Active Directory Lightweight Directory Services (AD LDS) do

Windows Server, anteriormente chamada de Active Directory Application Mode (ADAM), você
poderá fornecer serviços de diretório para a aplicativos sem precisar alterar o schema do seu
AD DS.
O que é a função de servidor AD LDS?

O AD LDS é um serviço de diretório do protocolo LDAP (Lightweight Directory Access
Protocol), que fornece um suporte flexível para aplicativos habilitados para diretório, sem as
dependências exigidas para os Serviços de Domínio Active Directory (AD DS). O AD LDS
oferece parte da mesma funcionalidade do AD DS, mas não requer a implantação de domínios
ou controladores de domínio. Você pode executar várias instâncias do AD LDS
simultaneamente em um único computador, com um esquema gerenciado de forma
independente para cada uma.
O AD DS oferece serviços de diretório tanto para o sistema operacional de servidor
Windows erver como para aplicativos habilitados para diretório. Para esse sistema
operacional, o AD DS armazena informações críticas sobre a infraestrutura de rede, os
usuários e os grupos, os serviços de rede etc.
A função de servidor AD LDS, fornece serviços de diretório especificamente para
aplicativos habilitados por diretório. O AD LDS não requer nem depende de domínios ou
florestas do Active Directory. No entanto, em ambientes nos quais existe o AD DS, o AD LDS
pode usar o AD DS para autenticar as entidades de segurança do Windows.
Exemplos de utilização do AD LDS
Fornecendo um armazenamento de diretório empresarial

O AD LDS pode armazenar dados de diretório “particulares”, relevantes somente para
um aplicativo especifico, em um serviço de diretório loca (possivelmente no mesmo servidor
do aplicativo) sem requerer configurações adicionais para o diretório do sistema operacional
do servidor. Esses dados, relevantes somente para o aplicativo e que não precisam ser
amplamente replicados, são armazenados unicamente no diretório do AD LDS que está
associado ao aplicativo
Fornecendo um armazenamento de autenticação extranet

Tome como exemplo um aplicativo de portal da Web que gerencia o acesso extranet
para aplicativos de negócios corporativos e as identidades de serviços que são externos ao
AD DS corporativo. Outro exemplo pode ser um cenário de host no qual um provedor oferece
serviços de domínio e armazenamento para seus clientes através da manutenção e
atualização de servidores de dados ou da Web dedicados ao cliente, sem que os clientes
tenham acesso a esses servidores.

Versão: 1.3- Pág. 117 de 377
Consolidando sistema de identidade

Você pode ter um cenário no qual uma restrição de modelo de dados, como por
exemplo um único modo de partição LDAP ou uma única unidade organizacional (OU), seja
imposta em um aplicativo habilitado para diretório empresarial, que deve acessar dados
associados a usuários autenticados para o AD DS, aplicativos ou recursos de rede que
estejam localizados em várias florestas, domínios ou OUs na empresa. As informações de
identidade desse aplicativo habilitado para diretório devem ser consolidadas de várias
florestas do Active Directory, domínios e OUs ou de vários sistemas de identidade e outros
diretórios, como bancos de dados de recursos humanos, bancos de dados SAP, listas
telefônicas e assim por diante.

Versão: 1.3- Pág. 118 de 377
Recursos da função de servidor AD LDS

Você pode usar a função de servidor AD LDS para criar várias instâncias do AD LDS
em um único computador. Cada instância é executada em um serviço separado no seu próprio
contexto de execução. A função de servidor AD LDS possui os seguintes recursos para
facilitar a criação, a configuração e o gerenciamento de instâncias do AD LDS:
 Um assistente que orienta você no processo de criação de uma instância do AD LDS
 Ferramentas de linha de comando para executar instalação autônoma e remoção de

instâncias do AD LDS
 Snap-ins do MMC (para configurar e gerenciar instâncias do AD LDS, incluindo o

esquema para cada instância
 Ferramentas de linha de comando específicas do AD LDS para gerenciar, preencher

e sincronizar instâncias do AD LDS
Além dessas ferramentas, você também pode usar várias ferramentas do

Active Directory para administrar instâncias do AD LDS.

Versão: 1.3- Pág. 119 de 377

Versão: 1.3- Pág. 120 de 377
3.5. AD CS
A PKI ( Infraestrutura de chave pública) ou Public Key Infrastructure consiste em vários

componentes que ajudam a proteger as comunicações e as transações corporativas. Um
desses componentes é a AC (autoridade de certificação) ou CA (Certification Authority).
Você pode usar as ACs para gerenciar, distribuir e validar certificados digitais que são
usados para proteger informações. Você pode instalar o AD CS (Serviços de Certificados do
Active Directory) como uma AC raiz ou uma AC subordinada em sua organização.
Visão geral do PKI

A PKI ajuda você a verificar e autenticar a identidade de cada parte envolvida em uma
transação eletrônica. Ela também ajuda a estabelecer confiança entre os computadores e os
aplicativos correspondentes que são hospedados em servidores de aplicativos. Um exemplo
comum inclui o uso de tecnologia de PKI para proteger sites. Os certificados digitais são
componentes importantes da PKI que contêm credenciais eletrônicas, as quais são usadas
para autenticar usuários ou computadores.
PKI é uma combinação de software, tecnologias de criptografia, processos e serviços

que ajudam uma organização na proteção de suas comunicações e transações de negócios.
É um sistema de certificados digitais, ACs e outras autoridades de registro. Quando ocorre
uma transação eletrônica, a PKI verifica e autentica a validade de cada parte envolvida. Os
padrões de PKI ainda estão em evolução, mas eles são amplamente implementados como
um componente essencial do comércio eletrônico.
Conceitos gerais de PKI

Versão: 1.3- Pág. 121 de 377
Em geral, uma solução PKI depende de várias tecnologias e componentes. Quando

você planeja a implementação de PKI, deve considerar e entender o seguinte:
 Infraestrutura. O significado neste contexto é igual ao significado em qualquer outro
contexto, como eletricidade, transporte ou fornecimento de água. Cada um desses
elementos realiza um trabalho específico e tem requisitos que devem ser satisfeitos
para funcionar de forma eficiente. A soma desses elementos permite o uso eficiente e
seguro da PKI. Os elementos que compõem uma PKI incluem os seguintes:
o Uma AC
o Um repositório de certificados
o Uma autoridade de registro
o A capacidade para revogar certificados
o A capacidade para fazer backup, recuperar e atualizar chaves
o A capacidade para regular e acompanhar o tempo
o Processamento do lado do cliente
 Chaves públicas/privadas. Em geral, há dois métodos para criptografar e

descriptografar dados:
 Criptografia simétrica: os métodos para criptografar e descriptografar dados são

idênticos ou espelhos um do outro. Os dados são criptografados usando um método
ou uma chave específica. Para descriptografar os dados, você deve ter o método ou a
chave idêntica. Portanto, qualquer um que tenha a chave pode descriptografar os
dados. A chave deve permanecer privada para preservar a integridade da criptografia.
 Criptografia assimétrica: neste caso, os métodos para criptografar e descriptografar

dados não são idênticos e não são espelhos um do outro. Os dados são criptografados
usando um método ou uma chave específica. No entanto, uma chave diferente é usada
para descriptografar dados. Isso é feito usando um par de chaves. Cada pessoa obtém
um par de chaves que consiste em uma chave pública e uma chave privada. Essas
chaves são únicas e os dados que a chave pública criptografa podem ser
descriptografados usando a chave privada e vice-versa. Nessa situação, as chaves
são suficientemente diferentes e o conhecimento ou a posse de uma não permite
determinar a outra. Portanto, uma das chaves (pública) pode ser disponibilizada
publicamente sem reduzir a segurança dos dados, contanto que a outra chave
(particular) permaneça privada; por isso o nome infraestrutura de chave pública.
Os algoritmos que usam criptografia simétrica são rápidos e eficientes para uma
quantidade grande de dados. No entanto, como eles usam uma chave simétrica, não são
considerados seguros o bastante, já que se deve sempre transportar a chave à outra parte.
Alternativamente, os algoritmos que usam criptografia assimétrica são seguros, mas muito
lentos. Por isso, é comum o uso da abordagem híbrida, que significa que os dados são
criptografados usando criptografia simétrica, enquanto a chave de criptografia simétrica é
protegida com criptografia assimétrica.
Componentes de uma solução PKI

Versão: 1.3- Pág. 122 de 377
Muitos componentes devem trabalhar em conjunto para fornecer uma solução PKI
completa. Os componentes de PKI no Windows Server 2012 são os seguintes:
 AC. A AC emite e gerencia certificados digitais para usuários, serviços e

computadores. Com a implantação da AC, você estabelece a PKI na sua organização.
 Certificados digitais. Os certificados digitais são semelhantes em função a um

passaporte eletrônico. Um certificado digital é usado para provar a identidade do
usuário (ou outra entidade). Os certificados digitais contêm as credenciais eletrônicas
associadas a uma chave pública e a uma chave privada, as quais são usadas para
autenticar os usuários e outros dispositivos, como servidores Web e servidores de e-
mail. Os certificados digitais também garantem que o software ou o código seja
executado de uma fonte confiável. Os certificados digitais contêm vários campos,
como Assunto, Emissor e Nome Comum. Esses campos são usados para
determinar o uso específico do certificado. Por exemplo, um certificado de servidor
Web poderia conter o campo Nome Comum de web01.sisnema.com, que tornaria
esse certificado válido apenas para esse servidor Web. Se fosse feita uma tentativa
de usar esse certificado em um servidor Web chamado web02.sisnema.com, o
usuário desse servidor receberia um aviso.
 Modelos de certificados. Esse componente descreve o conteúdo e a finalidade de

um certificado digital. Quando solicita um certificado de uma AC corporativa do AD CS,
o solicitante do certificado, dependendo dos seus direitos de acesso, pode escolher
um dos vários tipos de certificados baseados em modelos de certificados, como

Versão: 1.3- Pág. 123 de 377
Usuário e Assinatura de Código. O modelo de certificado evita que os usuários tenham

que tomar decisões técnicas de nível baixo sobre o tipo de certificado de que
necessitam. Além disso, permite que os administradores identifiquem quem pode
solicitar quais certificados.
 CRLs e respondentes online.

o As CRLs (listas de certificados revogados) são listas completas e assinadas
digitalmente de certificados que foram revogados. Essas listas são publicadas
periodicamente e podem ser recuperadas e armazenadas em cache pelos
clientes (de acordo com o tempo de vida configurado da CRL). As listas são
usadas para verificar o status de revogação de um certificado.
o Os respondentes online fazem parte do serviço de função do protocolo OCSP

no Windows Server 2008 e no Windows Server 2012. Um respondente online
pode receber uma solicitação para verificar a revogação de um certificado sem
exigir que o cliente baixe toda a CRL. Isso acelera a verificação de revogação
de certificado e reduz a largura de banda da rede. Também aumenta a
escalabilidade e a tolerância a falhas, permitindo a configuração de matriz dos
respondentes online.
 Serviços e aplicativos baseados em chave pública. Diz respeito a aplicativos ou

serviços que dão suporte à criptografia de chave pública. Em outras palavras, o
aplicativo ou os serviços devem dar suporte a implementações de chave pública para
receber os benefícios.
 Ferramentas de certificados e gerenciamento de AC. As ferramentas de

gerenciamento fornecem ferramentas de linha de comando e ferramentas baseadas
em GUI para:
o Configurar ACs
o Recuperar chaves privadas arquivadas
o Importar e exportar chaves e certificados
o Publicar certificados de AC e CRLs
o Gerenciar certificados emitidos
 AIA (acesso às informações da autoridade) e CDPs (pontos de distribuição de

CRL). Os pontos de AIA determinam o local onde os certificados da AC são
encontrados e validados, e os locais de CDP determinam os pontos nos quais as listas
de certificados revogados podem ser encontradas durante o processo de validação de
certificados. Como as CRLs podem aumentar (dependendo do número de certificados
emitidos e revogados por uma AC), você também pode publicar CRLs menores e
interinas chamadas CRLs delta. As CRLs delta contêm apenas os certificados
revogados desde a publicação da última CRL normal. Isso permite que os clientes
recuperem as CRLs delta menores e compilem mais rapidamente uma lista completa
de certificados revogados. O uso de CRLs delta também permite a publicação dos
dados de revogação com mais frequência, já que o tamanho de uma CRL delta
significa que ela normalmente não requer tanto tempo de transferência quanto uma
CRL completa
 HSM (módulo de segurança de hardware). Um módulo de segurança de hardware

é um dispositivo seguro opcional de hardware criptográfico que acelera o

Versão: 1.3- Pág. 124 de 377
processamento criptográfico de gerenciamento de chaves digitais. Ele é um

armazenamento especializado de alta segurança que é conectado à AC para gerenciar
os certificados. Um HSM é normalmente anexado fisicamente a um computador. É um
complemento opcional na PKI e é mais usado em ambientes de alta segurança nos
quais o comprometimento de uma chave poderia causar um grande impacto.
Observação: O componente mais importante de qualquer infraestrutura de segurança
é a segurança física. Uma infraestrutura de segurança não é apenas a implementação da PKI.
Outro elementos, como segurança física e políticas de segurança adequadas, também são
partes importantes de uma infraestrutura de segurança holística.
Autoridades de Certificação (AC) ou Certification Authority (CA)

Uma CA ou AC é um serviço que fornece certificados a usuários e computadores,
mantém as CRLs e responde opcionalmente a solicitações de OCSP. Você pode instalar uma
AC em seu ambiente implantando a função AD CS no Windows Server 2012. Quando a
primeira AC é instalada, ela estabelece a PKI na rede e fornece o ponto mais alto em toda a
estrutura. Você pode ter uma ou mais autoridades de certificação em uma rede, mas apenas
uma AC pode estar no ponto mais alto da hierarquia AC.
As finalidades principais da AC são emitir certificados, revogar certificados e publicar

informações sobre AIA e CRL. Fazendo isso, a AC garante a emissão de certificados que
podem ser validados para usuários, serviços e computadores.
Uma AC executa várias funções em uma PKI. Em uma PKI grande, é comum a
separação de funções da AC entre vários servidores. Uma AC fornece várias tarefas de
gerenciamento, inclusive:

Versão: 1.3- Pág. 125 de 377
 Verificação da identidade do solicitante do certificado.

 Emissão de certificados para usuários, computadores e serviços solicitantes.
 Gerenciamento da revogação do certificado.
Quando você implantar a primeira AC (AC raiz) na rede, ela emitirá um certificado
próprio. Depois disso, outras ACs recebem certificados da primeira AC. Também é possível
optar por emitir um certificado para a AC usando uma das ACs públicas.
ACs públicas versus ACs privadas

Quando você estiver planejando a implementação da PKI na sua empresa, uma das
primeiras escolhas que deverá fazer será decidir usar ACs públicas ou privadas. É possível
estabelecer a PKI usando qualquer uma dessas abordagens. Se você decidir usar uma AC
privada, implantará uma função de servidor do AD CS e, em seguida, estabelecerá uma PKI
interna. Se você decidir usar uma PKI externa, não será necessário implantar qualquer serviço
internamente.
As duas abordagens têm vantagens e desvantagens, como especificado na tabela a

seguir.
Tipo de AC Vantagens Desvantagens
AC pública externa • Confiável para muitos clientes • Custo mais alto se

externos (navegadores da Web, comparado a uma AC interna•
sistemas operacionais) O custo é por certificado• A

Versão: 1.3- Pág. 126 de 377
Tipo de AC Vantagens Desvantagens

obtenção de certificados é
• Requer administração mínima
mais lenta
AC privada interna • Fornece maior controle sobre o • Por padrão, não é confiável
gerenciamento de certificado para clientes externos
(navegadores da Web,
• Custo reduzido se comparado a
sistemas operacionais)
uma AC pública
• Requer mais administração
• Modelos personalizados
• Registro automático
Opções para a implementação de hierarquias de AC

Quando você decidir implementar a PKI na sua organização, uma das primeiras
decisões que deverá tomar será o design da sua hierarquia de AC. A hierarquia de AC
determina o design principal da sua PKI interna e também a finalidade de cada AC na
hierarquia. Cada hierarquia de AC inclui duas ou mais ACs. Normalmente, a segunda AC (e
todas as outras depois dela) é implantada com uma finalidade específica, porque apenas a
AC raiz é obrigatória.
 AC política. As ACs políticas são um tipo de AC subordinada localizada diretamente

abaixo da AC raiz em uma hierarquia de AC. As ACs políticas são usadas para emitir
certificados de AC para ACs subordinadas localizadas diretamente abaixo das ACs

Versão: 1.3- Pág. 127 de 377
políticas na hierarquia. Use as ACs políticas quando diferentes divisões, setores ou

locais da sua organização necessitarem de políticas e procedimentos de emissão
diferentes.
 Confiança da certificação cruzada. Neste cenário, duas hierarquias de AC

independentes interoperam quando uma AC em uma hierarquia emite um certificado
de AC na outra hierarquia.
 Hierarquia de duas camadas. Em uma hierarquia de duas camadas, há uma AC raiz e

pelo menos uma AC subordinada. Neste cenário, a AC subordinada é responsável
pelas políticas e pela emissão de certificados a solicitantes.
ACs autônomas versus ACs corporativas

No Windows Server 2012, você pode implantar dois tipos de ACs: uma AC autônoma
e uma AC corporativa. Esses tipos não tratam de hierarquia, mas de funcionalidade e
armazenamento de configuração. A diferença mais importante entre esses dois tipos de AC é
a integração e a dependência do Active Directory. Uma AC autônoma pode funcionar sem o
AD DS e não depende dele. Uma AC corporativa precisa do AD DS, mas também oferece
vários benefícios, como o registro automático. A tabela a seguir detalha as diferenças mais
importantes entre a ACs autônomas e ACs corporativas.

Versão: 1.3- Pág. 128 de 377
Característica AC autônoma AC corporativa
Uso típico Uma AC autônoma é usada Uma AC corporativa geralmente é

normalmente para ACs off-line, usada para emitir certificados a
mas ela pode ser usada para usuários, computadores e serviços
uma AC que está disponível de e não é usada normalmente como
forma consistente na rede. uma AC off-line.
Dependências Uma AC autônoma não Uma AC corporativa necessita do
do dependendo AD DS e pode ser AD DS, que pode ser usado como
implantada em ambientes não uma configuração e como um
Active Directory
pertencentes ao Active Directory. banco de dados de registro. Uma
AC corporativa também oferece
um ponto de publicação para
certificados emitidos para usuários
e computadores
Métodos de Os usuários só podem solicitar • Os usuários podem solicitar
solicitação de certificados de uma AC certificados de uma AC corporativa
certificados autônoma usando um usando os seguintes métodos:
procedimento manual ou registro
O Registro manual
via Web.
O Registro via Web
O Registro automático
O Agente de registro
Geralmente, a AC raiz (que é a primeira AC implantada) é implantada como uma AC

autônoma e fica offline depois de emitir um certificado para ela mesma e para uma AC
subordinada. Opcionalmente, uma AC subordinada geralmente é implantada como uma AC
corporativa e é configurada em um dos cenários descritos no tópico anterior.
Considerações para a implantação de uma AC raiz

Antes de implantar uma AC raiz, há várias decisões que você deve tomar. Primeiro,
você deve decidir se vai implantar uma AC raiz offline. Com base nessa decisão, você também
deve decidir se vai implantar uma AC raiz autônoma ou uma AC raiz corporativa.
Normalmente, se você estiver implantando uma hierarquia de AC de uma camada (o

que significa a implantação de uma única AC), será mais comum escolher a AC raiz
corporativa. No entanto, se você estiver implantando uma hierarquia de duas camadas, o
cenário mais comum será a implantação de uma AC raiz autônoma e uma AC subordinada
corporativa.
O próximo fator a ser considerado é o tipo de instalação do sistema operacional. Há

suporte para o AD CS nos cenários de instalação completa e da instalação Server Core. A
instalação Server Core fornece uma superfície de ataque menor e menos sobrecarga
administrativa e, portanto, deve ser considerada para o AD CS em um ambiente corporativo.
No Windows Server 2012, também é possível usar o Windows PowerShell para implantar e
gerenciar a função AD CS.

Versão: 1.3- Pág. 129 de 377
Você não pode alterar os nomes dos computadores nem as associações do domínio
do computador depois que implantar uma AC de qualquer tipo no computador. Também não
é possível alterar o nome do domínio. Portanto, é importante determinar esses atributos antes
de instalar uma AC.
A tabela a seguir detalha as considerações adicionais.
Consideração Descrição
Um CSP (provedor de serviços de • O CSP padrão é o Microsoft Strong Cryptographic

criptografia) que é usado para gerar
Provider.
uma nova chave
• Qualquer provedor cujo nome comece com uma
cerquilha (#) é um provedor de CNG (Cryptography
Next Generation).
O comprimento da chave em O comprimento da chave padrão do Microsoft
caracteres Strong Cryptographic Provider é 2.048 caracteres.
Esse é o valor mínimo recomendado para uma AC
raiz
O algoritmo de hash que é usado O valor padrão do algoritmo de hash é SHA-1.
para assinar certificados emitidos
por uma AC
O período de validade dos O valor padrão para certificados é cinco anos.
certificados emitidos por uma AC
O status do servidor raiz (online ou O servidor raiz deve ser implantado como uma AC
offline) offline. Isso aumenta a segurança e protege o
certificado raiz (porque ele não está disponível para
invadir a rede).
Especificamente, se você decidir implantar uma AC raiz autônoma offline, há algumas

considerações específicas às quais deve prestar atenção:
 Antes de emitir um certificado subordinado da AC raiz, certifique-se de fornecer pelo
menos um local de CDP e AIA que vai estar disponível para todos os clientes. Isso
deve ser feito porque, geralmente, o CDP e o AIA estão localizados na própria AC raiz
autônoma. Portanto, quando você retirar a AC raiz da rede, a verificação de revogação
vai falhar, já que os locais CDP e AIA estarão inacessíveis. Quando você definir esses
locais, copie as informações de CRL e AIA manualmente para esse local.
 Defina um período de validade para as CRLs publicadas pela AC raiz para um período
longo (por exemplo, um ano). Isso significa que você terá que ativar a AC raiz uma vez
por ano para publicar uma nova CRL e, depois, copiá-la para um local que esteja
disponível para os clientes. Caso não faça isso, depois que a CRL na AC raiz expirar,
a verificação de revogação de todos os certificados falhará.
 Use a Política de Grupo para publicar o certificado da AC raiz em um repositório de

autoridades de certificação raiz em todos os computadores servidores e clientes. Você

Versão: 1.3- Pág. 130 de 377
deve fazer isso manualmente porque uma AC autônoma não pode fazê-lo de maneira
automática, diferentemente de uma AC corporativa. Também é possível publicar o
certificado da AC raiz no AD DS usando a ferramenta de linha de comando Certutil.
Considerações para a implantação de uma AC subordinada

Você pode usar uma AC subordinada para implementar restrições de política da PKI e
para distribuir certificados para os clientes. Depois de instalar uma AC raiz para a organização,
você pode instalar uma ou mais ACs subordinadas. Quando você estiver usando uma AC
subordinada para distribuir certificados para usuários ou computadores que têm uma conta
em um ambiente do AD DS, será possível instalar a AC subordinada como uma AC
corporativa. Em seguida, você pode usar os dados das contas dos clientes no AD DS para
distribuir e gerenciar certificados e para publicar certificados do AD DS. Para concluir esse
procedimento, entretanto, você deve ser um membro do grupo de administradores locais ou
ter permissões equivalentes. Se a AC subordinada for uma AC corporativa, você também
precisará ser um membro do grupo dos administradores do domínio ou ter permissões
equivalentes. Da perspectiva da segurança, um cenário recomendado é ter uma AC raiz
autônoma offline e uma AC subordinada corporativa.
Uma AC subordinada geralmente é implantada para obter algumas das

funcionalidades a seguir:
 Uso. Você pode emitir certificados com diversas finalidades, como S/MIME (Secure
Multipurpose Internet Mail Extensions), EFS (Encrypting File System) ou RAS (Serviço
de Acesso Remoto). A política de emissão para esses usos pode ser diferente e a
separação fornece uma base para administrar essas políticas.

Versão: 1.3- Pág. 131 de 377
 Divisões organizacionais. Você pode ter políticas diferentes para a emissão de

certificados, dependendo da função de uma entidade na organização. É possível criar
ACs subordinadas para separar e administrar essas políticas.
 Divisões geográficas. As organizações geralmente têm entidades em diversos sites

físicos. A conectividade de rede limitada entre esses sites pode exigir ACs
subordinadas individuais para muitos ou todos os sites.
 Balanceamento de carga. Se você vai usar a PKI para emitir e gerenciar um grande
número de certificados, a existência de apenas uma AC pode resultar em uma carga
de rede considerável para essa única AC. O uso de várias ACs subordinadas para
emitir o mesmo tipo de certificado divide a carga de rede entre as ACs.
 Backup e tolerância a falhas. Várias ACs aumentam a possibilidade de que a rede

sempre tenha as ACs operacionais disponíveis para responder a solicitações do
usuário.
Implementação da distribuição e revogação de certificados

Uma das etapas da implantação da PKI na sua organização será definir os métodos
de distribuição e registro de certificados. Além disso, durante o processo de gerenciamento
de certificado, haverá momentos em que talvez seja necessário revogar certificados. Alguns
motivos para revogar certificados podem incluir o comprometimento de uma chave ou quando
alguém deixa a organização. Você precisa verificar se os clientes de rede podem determinar
quais certificados foram revogados antes de aceitar as solicitações de autenticação. Para
garantir escalabilidade e alta disponibilidade, você pode implantar o Respondente Online do
AD CS para fornecer o status de revogação do certificado.
Opções de registro de certificado

No Windows Server 2012, você pode usar vários métodos para registrar um certificado
de usuário ou de computador. O uso desses métodos depende de cenários específicos. Por
exemplo, é provável que você use o registro automático para implantar muitos certificados
para um grande número de usuários ou computadores, enquanto provavelmente usaria o
registro manual para certificados dedicados a entidades de segurança específicas.

Versão: 1.3- Pág. 132 de 377
 Registro automático. Usando este método, o administrador define as permissões e a

configuração de um modelo de certificado. Essas definições ajudam o solicitante a
pedir, recuperar e renovar certificados automaticamente sem interação com o usuário
final. Esse método é usado para computadores de domínio do AD DS. O certificado
deve ser configurado para o registro automático por meio da Política de Grupo.
 Registro manual. Usando esse método, a chave privada e uma solicitação de

certificado são geradas em um dispositivo, como um serviço Web ou um computador.
A solicitação de certificado é, então, transportada para a AC para gerar o certificado
solicitado. O certificado é transportado de volta ao dispositivo para a instalação. Use
esse método quando o solicitante não puder se comunicar diretamente com a AC ou
se o dispositivo não der suporte ao registro automático.
 Registro via Web na AC. Usando esse método, você pode habilitar uma AC de site de
modo que os usuários possam obter certificados. Para usar um registro via Web na
AC, você deve instalar o IIS (Internet Information Server) e a função de registro via
Web na AC do AD CS. Para obter um certificado, o solicitante faz logon no site,
seleciona o modelo de certificado apropriado e envia uma solicitação. O certificado
será emitido automaticamente se o usuário tiver as permissões apropriadas para se
registrar no certificado. O método de registro via Web na AC deverá ser usado para
emitir certificados quando o registro automático não puder ser usado. Isso pode
acontecer no caso de uma solicitação avançada de certificado. No entanto, há casos
em que o registro automático pode ser usado para alguns certificados, mas não para
todos.
 Registro em nome de (agente de registro). Usando esse método, um administrador de

AC cria uma conta de agente de registro para um usuário. O usuário com os direitos

Versão: 1.3- Pág. 133 de 377
de agente de registro pode registrar certificados em nome de outros usuários. Use

esse método, por exemplo, se precisar permitir que um gerenciador pré-carregue
certificados de logon de novos funcionários em cartões inteligentes.
Funcionamento do registro automático

Um dos métodos mais comuns para implantar certificados em um ambiente do Active
Directory é o registro automático. Esse método fornece um modo automatizado de implantar
os certificados em usuários e em computadores dentro da PKI. Você pode usar os ambientes
de registro automático que satisfazem os requisitos específicos, como o uso de modelos de
certificados e Política de Grupo no AD DS. No entanto, é importante observar que você não
pode usar o registro automático com uma AC autônoma. Você deve ter uma AC corporativa
disponível para utilizar o registro automático.
Você pode usar autoenrollment para implantar automaticamente certificado aos

usuários e computadores em uma organização. O administrador dos Serviços de certificado
duplica um modelo de certificado e configura as permissões para permitir as permissões
Registro e Registro Automático dos usuários que receberão os certificados. Políticas de Grupo
baseadas em domínio, como políticas baseadas em computadores e usuários, podem ativar
e gerenciar o registro automático.
Por padrão, a Política de Grupo é aplicada quando se reinicia os computadores ou no

logon de usuários. Também por padrão, a Política de Grupo é atualizada a cada 90 minutos

Versão: 1.3- Pág. 134 de 377
em membros do domínio. A essa configuração da Política de Grupo é dado o nome de Cliente

dos Serviços de Certificado - Registro Automático.
Um temporizador interno dispara o registro automático a cada oito horas depois da
última ativação do registro automático. O modelo de certificado pode especificar a interação
de usuários de cada solicitação. Para tal atualização, uma janela pop-up aparece
aproximadamente 60 segundos depois que o usuário fizer logon.
Muitos certificados podem ser distribuídos sem o cliente sequer perceber que o registro
está sendo executado. Eles incluem a maioria dos tipos de certificados que são emitidos para
computadores e serviços, além de muitos dos certificados emitidos para usuários.
Para registrar os clientes automaticamente em certificados de um ambiente de
domínio, você deve:
 Ser membro dos Administradores do domínio ou da empresa (ou equivalente), esse é
o mínimo exigido para concluir esse procedimento.
 Configurar um modelo de certificado com permissões de Registro Automático.
 Configurar uma política de registro automático para o domínio.
Revogação de certificado
A revogação é o processo no qual você desabilita a validade de um ou mais
certificados. Ao iniciar o processo de revogação, você publica uma impressão digital de
certificado no CRL correspondente.
Uma visão geral do ciclo de vida de revogação do certificado é esboçada a seguir:

Versão: 1.3- Pág. 135 de 377
 Um certificado é revogado do snap-in do MMC da AC. Durante a revogação, um código

de motivo, a data e a hora são especificados. Isso é opcional, mas recomendado.
 O CRL é publicado usando o snap-in do MMC da AC (ou a lista de certificados

revogados agendada é publicada automaticamente baseada no valor configurado). Os
CRLs podem ser publicado no AD DS, em algum local de pasta compartilhada ou em
um site.
 Quando os computadores clientes do Windows recebem um certificado, eles usam um

processo para verificar o status de revogação consultando a AC emissora. Esse
processo determina se o certificado é revogado, e apresenta, então, as informações
ao aplicativo que solicita a verificação. O computador cliente do Windows usa um dos
locais da CRL especificados no certificado para a verificar sua validade.
Os sistemas operacionais do Windows incluem um CryptoAPI, que é responsável pela

revogação de certificados e pelos processos de verificação de status. O CryptoAPI utiliza as
seguintes fases no processo de verificação do certificado:
 Descoberta de certificado. A descoberta de certificado coleta certificados de AC,
informações AIA em certificados emitidos e detalhes sobre o processo de registro do
certificado.
 Validação de caminho. A validação de caminho é o processo de verificação de

certificado por meio da cadeia da AC (ou caminho) até que o certificado da AC raiz
seja alcançado.
 Verificação de revogação. Cada certificado na cadeia de certificados é verificado para

assegurar que nenhum dos certificados seja revogado.
 Recuperação de rede e cache. A recuperação de Rede é executada usando o OCSP.

O CryptoAPI é responsável pela verificação do cache local para obter informações de
revogação, e caso não haja correspondência, ele faz uma chamada usando o OCSP,
que é baseado na URL fornecida pelo certificado emitido.

Versão: 1.3- Pág. 136 de 377
3.6. AD RMS
O Active Directory Rights Management Services (AD RMS) fornece um método para
proteger o conteúdo que vai além da criptografia de dispositivos de armazenamento usando
a Criptografia de Unidade do Windows BitLocker ou a criptografia de arquivos individuais
usando o EFS (Encrypting File System). O AD RMS fornece um método para proteger dados
em trânsito e em repouso, além de garantir sua acessibilidade somente a usuários autorizados
para uma duração específica.
AD RMS
AD RMS é uma tecnologia de proteção de informações criada para minimizar a
possibilidade de vazamento de dados. Vazamento de dados é a transmissão de informações
sem autorização – para pessoas dentro ou fora da organização – para quem não deve ter
acesso a essas informações. O AD RMS integra-se a produtos e sistemas operacionais
existentes Microsoft, incluindo Windows Server, Exchange Server, SharePoint Server e a
Suite Office.
O AD RMS pode proteger dados em trânsito e em repouso. Por exemplo, o AD RMS

pode proteger documentos que são enviados como mensagens de e-mail garantindo que uma
mensagem não possa ser aberta nem mesmo quando endereçada acidentalmente ao
destinatário errado. Você também pode usar o AD RMS para proteger dados armazenados
em dispositivos como unidades USB removíveis. Uma desvantagem das permissões de
arquivos e pastas é que, uma vez que o arquivo é copiado em outro local, as permissões
originais não se aplicam mais. Um arquivo copiado em uma unidade USB herdará as
permissões do dispositivo de destino. Uma vez copiado, um arquivo que era somente leitura
pode se tornar editável alterando as permissões de arquivos e pastas. Com o AD RMS, o
arquivo pode ser protegido em qualquer local, independentemente das permissões de
arquivos e pastas que concedem o acesso. Com o AD RMS, somente os usuários autorizados
a abrir o arquivo poderão ver o conteúdo desse arquivo.

Versão: 1.3- Pág. 137 de 377
Cenários de uso do AD RMS
Cenário 1
O CEO copia um arquivo de planilha que contém os pacotes de compensação dos
executivos de uma organização de uma pasta protegida em um servidor de arquivos na
unidade USB pessoal do CEO. Durante o trajeto para casa, o CEO esquece a unidade USB
no trem, onde alguém sem conexão com a organização o encontra. Sem o AD RMS, quem
encontrar a unidade USB pode abrir o arquivo. Com o AD RMS, é possível garantir que o
arquivo não pode ser aberto por usuários não autorizados.
Cenário 2
Um documento interno deve ser visível por um grupo de pessoas autorizadas na
organização. Essas pessoas não devem poder editar ou imprimir o documento. Embora seja
possível usar a funcionalidade nativa do Microsoft Office Word para restringir esses recursos,
fazer isso exige que cada pessoa tenha uma conta Windows Live. Com o AD RMS, você pode
configurar essas permissões com base em contas existentes nos Serviços de Domínio do
Active Directory (AD DS).
Cenário 3
Pessoas na organização não devem poder encaminhar mensagens de e-mail
confidenciais atribuídas a uma classificação específica. Com o AD RMS, você pode permitir
que um remetente atribua uma classificação específica a uma nova mensagem de e-mail, e
essa classificação irá garantir que o destinatário não possa encaminhar a mensagem.
Visão geral dos componentes do AD RMS

O cluster de certificação raiz do AD RMS é o primeiro servidor AD RMS que você
implanta em uma floresta. O cluster de certificação raiz do AD RMS gerencia todo o tráfego
de licenciamento e certificação para o domínio no qual é instalado. O AD RMS armazena
informações de configuração em um banco de dados do Microsoft SQL Server ou no Banco
de Dados Interno do Windows. Em ambientes grandes, do banco de dados do SQL Server é
hospedado em um servidor separado do servidor que hospeda a função AD RMS.

Versão: 1.3- Pág. 138 de 377
Os clusters somente de licenciamento do AD RMS são usados em ambientes

distribuídos. Os clusters somente de licenciamento não fornecem certificação, mas permitem
a distribuição de licenças que são usadas para consumo e publicação de conteúdo. Os
clusters somente de licenciamento são geralmente implantados em filiais grandes em
organizações que usam o AD RMS.
Servidor AD RMS
Os servidores AD RMS devem ser membros de um domínio do AD DS. Quando você
instala o AD RMS, as informações sobre o local do cluster são publicadas no AD DS em um
local conhecido como ponto de conexão de serviço. Os computadores que são membros do
domínio consultam o ponto de conexão de serviço para determinar o local de serviços do AD
RMS.
Cliente AD RMS
O cliente AD RMS é integrado aos sistemas operacionais Windows Vista, Windows 7
e Windows 8. O cliente AD RMS permite que aplicativos habilitados para o AD RMS imponham
a funcionalidade ditada pelo modelo do AD RMS. Sem o cliente AD RMS, os aplicativos
habilitados para o AD RMS não poderiam interagir com o conteúdo protegido pelo AD RMS.
Aplicativos habilitados para o AD RMS

Os aplicativos habilitados para o AD RMS permitem que usuários criem e consumam
conteúdo protegido pelo AD RMS. Por exemplo, o Microsoft Outlook permite que os usuários
vejam e criem mensagens de e-mail protegidas. O Office Word permite que os usuários vejam

Versão: 1.3- Pág. 139 de 377
e criem documentos de processamento de texto protegidos. A Microsoft fornece um kit de

desenvolvimento de software (SDK) do AD RMS para permitir que os desenvolvedores
habilitem seus aplicativos para oferecer suporte à proteção de conteúdo do AD RMS.
Funcionamento do AD RMS
O AD RMS funciona da seguinte maneira:

1. A primeira vez que o autor do documento configura a proteção de direitos para o
documento, um certificado de licenciante de cliente é solicitado pelo servidor AD RMS.
2. O servidor emite o certificado de licenciante de cliente para o cliente.
3. Quando o autor recebe o certificado do servidor AD RMS, ele pode configurar os

direitos de uso no documento.
4. Quando o autor configura os direitos de uso, o aplicativo criptografa o arquivo com

uma chave simétrica.
5. Essa chave simétrica é criptografada na chave pública do servidor AD RMS que é

usada pelo autor.
6. O destinatário do arquivo o abre usando um aplicativo ou navegador do AD RMS. Não

é possível abrir conteúdo protegido pelo AD RMS a menos que o aplicativo ou
navegador ofereça suporte ao AD RMS. Se o destinatário não tiver um certificado de

Versão: 1.3- Pág. 140 de 377
conta no dispositivo atual, ele será emitido para o usuário nesse momento. O aplicativo
ou navegador transmite uma solicitação ao servidor AD RMS do autor para uma
Licença de Uso.
7. O servidor AD RMS determina se o destinatário está autorizado. Se o destinatário

estiver autorizado, o servidor AD RMS emitirá uma Licença de Uso.
8. O servidor AD RMS descriptografa a chave simétrica que foi criptografada na etapa 3

usando sua chave privada.
9. O servidor AD RMS criptografa novamente a chave simétrica usando a chave pública

do destinatário e adiciona a chave de sessão criptografada à Licença de Uso.
Cenários de implantação do AD RMS

Uma implantação do AD RMS consiste em um ou mais servidores conhecidos como
cluster. Um cluster do AD RMS não é um cluster de failover de alta disponibilidade. Quando
você for implantar o AD RMS, deverá hospedar o servidor de forma que esteja altamente
disponível. O AD RMS geralmente é implantado como uma máquina virtual altamente
disponível.
Quando você implantar o AD RMS em uma única floresta, terá um único cluster do AD
RMS. Essa é a forma mais comum de implantação do AD RMS. Você adiciona servidores ao
cluster do AD RMS conforme necessário para fornecer capacidade adicional.
Quando você implanta o AD RMS em várias florestas, cada floresta deve ter seu
próprio cluster raiz do AD RMS. É necessário configurar Domínios de Publicação Confiáveis
do AD RMS para garantir que o conteúdo do AD RMS possa ser protegido e consumido pelas
várias florestas.

Versão: 1.3- Pág. 141 de 377
Você também pode implantar o AD RMS em locais de extranet. Nessa implantação, o

servidor de licenciamento do AD RMS é acessível para hosts na Internet. Você usa esse tipo
de implantação para oferecer suporte à colaboração com usuários externos.
Você pode implantar o AD RMS com o AD FS ou o Microsoft Federation Gateway.

Nesse cenário, os usuários utilizam a identidade federada para publicar e consumir conteúdo
protegido por direitos.
Como prática recomendada, você não deve implantar o AD RMS em um controlador

de domínio. Você pode implantar o AD RMS somente em um controlador de domínio se a
conta de serviço for membro do grupo Admins. do Domínio.
Requisitos do cliente AD RMS

O conteúdo do AD RMS pode ser publicado e consumido somente por computadores
que executam o cliente AD RMS. Todas as versões dos sistemas operacionais cliente
Windows Vista, Windows 7 e Windows 8 incluem o software cliente AD RMS. Os sistemas
operacionais Windows Server 2008, Windows Server 2008 R2 e Windows Server 2012
também incluem o cliente AD RMS. Esses sistemas operacionais não exigem configuração
adicional para consumir e publicar conteúdo protegido pelo AD RMS
O software cliente AD RMS está disponível para download para computadores que
executam os sistemas operacionais Microsoft Windows XP e Mac OS X. Esse software cliente
deve ser instalado para que os usuários desses sistemas operacionais possam consumir e
publicar o conteúdo protegido pelo AD RMS.

Versão: 1.3- Pág. 142 de 377
O AD RMS requer aplicativos compatíveis. Os aplicativos de servidor que oferecem

suporte ao AD RMS incluem o seguinte:
• Microsoft Exchange Server 2007
• Exchange Server 2010
• Exchange Server 2013
• Microsoft Office SharePoint Server 2007
• SharePoint Server 2010
• SharePoint Server 2013
Os aplicativos cliente, como os incluídos no Microsoft Office 2003, Office 2007, Office
2010 e Office 2013, podem publicar e consumir conteúdo protegido pelo AD RMS. Você pode
usar o SDK do AD RMS para criar aplicativos que podem publicar e consumir conteúdo
protegido pelo AD RMS. O Visualizador XPS e o Windows Internet Explorer também podem
exibir conteúdo protegido pelo AD RMS.
Licenciamento de cliente AD RMS

Para usar os Serviços de Gerenciamento de Direitos em seu ambiente do AD DS, você
deve ter CALs (Licenças de Acesso para Cliente) do Gerenciamento de Direitos do Windows.
Essas CALs são diferentes das tradicionais CALs do Windows Server de que você precisa
para conectar o cliente ao servidor. Cada usuário que irá criar ou usar arquivos protegidos por
direitos deverão ter uma CAL de Usuário do RMS. Opcionalmente, você também pode usar
CALs de Dispositivo do RMS para computadores que serão usados para criar e exibir
conteúdo protegido pelo RMS.
Se você precisar compartilhar seu conteúdo protegido pelo RMS fora de sua
organização, deverá adquirir uma Licença de Conector Externo do RMS. Essa licença
concede às organizações o direito de permitir um número ilimitado de usuários externos a
acessar ou usar uma cópia individual licenciada do software servidor RMS sem precisar
adquirir CALs para cada usuário externo.

Versão: 1.3- Pág. 143 de 377

Versão: 1.3- Pág. 144 de 377
3.7. AD FS
Os Serviços de Federação do Active Directory (AD FS) no Windows Server 2012

oferecem flexibilidade para as organizações que desejam permitir que seus usuários façam
logon em aplicativos que podem estar localizados na rede local, em uma empresa parceira ou
em um serviço online. Com o AD FS, uma organização pode gerenciar suas próprias contas
de usuário e os usuários precisam lembrar apenas de um conjunto de credenciais. Porém,
essas credenciais podem ser usadas para fornecer acesso a uma variedade de aplicativos
que podem estar localizados em diversos locais.
Visão geral do AD FS
AD FS é a implementação da Microsoft de uma estrutura de federação de identidade

que permite que as organizações estabeleçam relações de confiança de federação e
compartilhem recursos dentro dos limites organizacionais e dos Serviços de Domínio Active
Directory (AD DS). O AD FS é compatível com padrões de serviços Web comuns, para
habilitar a interoperabilidade com soluções de federação de identidade oferecidas por outros
fornecedores.
O AD FS foi projetado para abordar vários cenários comerciais, nos quais os

mecanismos de autenticação típicos usados em uma organização única não funcionam. Esta
lição apresenta uma visão geral dos conceitos e padrões implementados no AD FS e também
os cenários comerciais que podem ser abordados com o AD FS.
Federação de Identidade
A federação de identidade permite a distribuição de identificação, autenticação e
autorização dentro dos limites organizacionais e de plataforma. Você pode implementar a
federação de identidade dentro de uma organização única para permitir o acesso a aplicativos
Web diversos ou entre duas organizações que têm uma relação de confiança entre elas.

Versão: 1.3- Pág. 145 de 377
Para estabelecer uma parceria de federação de identidade, ambos os parceiros

concordam em criar uma relação de confiança federada. Essa confiança federada se baseia
em uma relação comercial contínua e permite que as organizações implementem processos
comerciais identificados na relação comercial.
Observação: Uma relação de confiança federada não é igual a uma relação de

confiança de floresta que organizações podem configurar entre florestas do AD DS. Em uma
relação de confiança federada, os servidores AD DS em duas organizações nunca têm que
se comunicar diretamente. Além disso, toda a comunicação em uma implantação de
federação ocorre sobre HTTP, portanto, você não precisa abrir várias portas em algum firewall
para habilitar a federação.
Como parte da relação de confiança federada, cada parceiro define quais recursos
estão acessíveis à outra organização e como o acesso aos recursos é habilitado. Por exemplo,
para atualizar uma previsão de vendas, um representante de vendas talvez precise coletar
informações do banco de dados de um fornecedor hospedado na rede do fornecedor. O
administrador do domínio para o representante de vendas é responsável por assegurar que
os representantes de vendas apropriados sejam membros do grupo que requer acesso ao
banco de dados do fornecedor. O administrador da organização onde o banco de dados está
localizado é responsável por assegurar que os funcionários do parceiro tenham acesso
apenas aos dados de que necessitam.
Em uma solução de federação de identidade, as identidades de usuário e suas

credenciais associadas são armazenadas, pertencentes e gerenciadas pela organização
onde o usuário está localizado. Como parte da relação de confiança de federação de
identidade, cada organização define também como as identidades de usuário são
compartilhadas com segurança para restringir o acesso aos recursos. Cada parceiro deve
definir os serviços que torna disponíveis para parceiros e clientes confiáveis e em quais outras
organizações e usuários confia. Cada parceiro também deve definir que tipos de credenciais
e solicitações aceita e suas políticas de privacidade para assegurar que informações privadas
não fiquem acessíveis na relação de confiança.
Você também pode usar a federação de identidade dentro de uma organização única.
Por exemplo, uma organização pode planejar implantar vários aplicativos baseados na Web
que requerem autenticação. Usando o AD FS, a organização pode implementar uma solução
de autenticação para todos os aplicativos, facilitando o acesso ao aplicativo para os usuários
em vários domínios internos ou florestas. Você também pode estender a solução a parceiros
externos no futuro, sem alterar o aplicativo.
Identidade baseada em declarações
A autenticação baseada em declarações foi criada para abordar problemas por meio
da extensão dos mecanismos típicos de autenticação e autorização fora dos limites
associados a esses mecanismos. Por exemplo, na maioria das organizações, quando os
usuários fazem logon na rede, eles são autenticados por um controlador de domínio do AD
DS. Um usuário que fornece as credenciais certas ao controlador de domínio recebe um token

Versão: 1.3- Pág. 146 de 377
de segurança. Os aplicativos em execução em servidores no mesmo ambiente do AD DS

confiam nos tokens de segurança fornecidos pelos controladores de domínio do AD DS, pois
os servidores podem se comunicar com os mesmos controladores de domínio em que os
usuários foram autenticados.
O problema com esse tipo de autenticação é que ela não se estende facilmente para
fora dos limites da floresta do AD DS. Embora seja possível implementar a autenticação
Kerberos ou relações de confiança baseadas em NTLM entre duas florestas do AD DS, os
computadores cliente e os controladores de domínio em ambos os lados da relação de
confiança devem se comunicar com os controladores de domínio na outra floresta para tomar
decisões sobre autenticação e autorização. Essa comunicação requer tráfego de rede que é
enviado em várias portas, portanto, essas portas devem estar abertas em todos os firewalls
entre os controladores de domínio e outros computadores. O problema fica ainda mais
complicado quando os usuários têm acesso a recursos hospedados em sistemas baseados
na nuvem, como o Windows Azure ou o Office 365.
A autenticação baseada em declarações fornece um mecanismo para separar a

autenticação de usuário e a autorização de aplicativos individuais. Com a autenticação
baseada em declarações, os usuários podem se autenticar em um serviço de diretório
localizado dentro de sua organização e podem receber uma declaração baseada nessa
autenticação. A declaração pode ser apresentada a um aplicativo que esteja em execução em
uma organização diferente. O aplicativo é criado para permitir o acesso do usuário às
informações ou recursos, com base nas declarações apresentadas. Toda a comunicação
também ocorre sobre HTTP.

Versão: 1.3- Pág. 147 de 377
Sobre AD FS
AD FS é a implementação da Microsoft de uma solução de federação de identidade

que usa autenticação baseada em declarações. O AD FS fornece os mecanismos para
implementar tanto os componentes do provedor de identidade quanto do provedor de serviços
em uma implantação de federação de identidade.
O AD FS oferece os seguintes recursos:

 Provedor de declarações corporativo para aplicativos baseados em declarações. Você
pode configurar um servidor AD FS como um provedor de declarações, o que significa
que pode emitir declarações sobre usuários autenticados. Isso permite a uma
organização fornecer a seus usuários acesso para aplicativos com reconhecimento de
declarações em outra organização usando SSO.
 Provedor de Serviço de Federação para federação de identidade entre domínios. Esse

serviço oferece SSO da Web federado entre domínios, aprimorando a segurança e
reduzindo a sobrecarga para administradores e TI.
Recursos do AD FS
Alguns dos recursos chave do AD FS são mostrados a seguir:
 SSO da Web. Muitas organizações implantaram o AD FS. Após a autenticação para

o AD DS por meio da autenticação Integrada do Windows, os usuários podem acessar
todos os outros recursos que têm permissão para acessar dentro dos limites da floresta
do AD DS. O AD FS estende esse recurso para aplicativos voltados para intranet ou
Internet, permitindo que os clientes, os parceiros e os fornecedores tenham uma
experiência de usuário semelhante e simplificada quando acessam os aplicativos Web
de uma organização.

Versão: 1.3- Pág. 148 de 377
 Interoperabilidade de serviços Web. O AD FS é compatível com as especificações

de serviços Web. O AD FS emprega a especificação de federação de WS-*,
denominada WS-Federation. O WS-Federation permite que os ambientes que não
usam o modelo de identidade do Windows realizem a federação com ambientes do
Windows.
 Suporte a cliente passivo e inteligente. Como o AD FS se baseia na arquitetura WS-

*, ele oferece suporte a comunicações federadas entre qualquer ponto de extremidade
habilitado para WS, incluindo comunicações entre servidores e clientes passivos,
como navegadores. O AD FS no Windows Server 2012 também permite o acesso para
clientes inteligentes baseados no SOAP, como servidores, celulares, PDAs
(assistentes pessoais digitais) e aplicativos de área de trabalho. O AD FS implementa
o Perfil de Solicitante Passivo de WS-Federation e alguns dos padrões do Perfil de
Solicitante Ativo de WS-Federation para suporte ao cliente.
 Arquitetura extensível. O AD FS fornece uma arquitetura extensível que oferece

suporte a vários tipos de token de segurança, inclusive tokens SAML e autenticação
Kerberos pela autenticação Integrada do Windows e a capacidade para executar
transformações de declarações personalizadas. Por exemplo, o AD FS pode converter
de um tipo de token em outro ou adicionar lógica corporativa personalizada como uma
variável em uma solicitação de acesso. As organizações podem usar esta
extensibilidade para modificar o AD FS para coexistir com a infraestrutura de
segurança atual e políticas comerciais.
 Maior segurança. O AD FS ajuda aumentar a segurança de soluções federadas

delegando a responsabilidade do gerenciamento de conta à organização mais próxima
do usuário. Cada organização individual em uma federação continua gerenciando suas
próprias identidades e é capaz de compartilhar com segurança e aceitar identidades e
credenciais de outras origens de membros.
Como o AD FS habilita o SSO em uma organização única

Para muitas organizações, configurar o acesso a aplicativos e serviços talvez não exija
uma implantação do AD FS. Se todos os usuários forem membros da mesma floresta do AD
DS e se todos os aplicativos estiverem em execução em servidores que forem membros da
mesma floresta, normalmente você poderá usar a autenticação do AD DS para fornecer
acesso ao aplicativo. Porém, há vários cenários onde você pode usar o AD FS para melhorar
a experiência de usuário habilitando SSO:
 Os aplicativos talvez não estejam em execução em servidores do Windows ou em

qualquer servidor que ofereça suporte à autenticação do AD FS ou em servidores do
Windows Server que não tenham ingressado no domínio. Os aplicativos podem exigir
SAML ou serviços Web para autenticação e autorização.
 Organizações grandes frequentemente têm vários domínios e florestas que podem ser
os resultados de fusões e aquisições ou podem se dever a requisitos de segurança.
Os usuários em várias florestas podem requerer acesso aos mesmos aplicativos.
 Os usuários de fora do escritório talvez precisem de acesso a aplicativos que estão

sendo executados em servidores internos. Os usuários externos talvez estejam

Versão: 1.3- Pág. 149 de 377
fazendo logon nos aplicativos de computadores que não fazem parte do domínio
interno.
As organizações podem usar o AD FS para habilitar SSO nesses cenários. Como todos
os usuários e o aplicativo estão na mesma floresta do AD DS, a organização só tem que
implantar um único servidor de federação. Esse servidor pode operar como o provedor de
declarações para autenticar solicitações de usuário e emitir as declarações. O mesmo servidor
também é a terceira parte confiável ou o consumidor das declarações para fornecer
autorização para acesso de aplicativo.

Versão: 1.3- Pág. 150 de 377
Como o AD FS habilita o SSO em uma federação B2B

Um dos cenários mais comuns para implantar o AD FS é fornecer SSO em uma
federação B2B. No cenário, a organização que requer acesso ao aplicativo de outra
organização ou serviço pode gerenciar as próprias contas de usuário e definir os próprios
mecanismos de autenticação. A outra organização pode definir quais aplicativos e serviços
são expostos aos usuários fora da organização e quais declarações aceita para fornecer
acesso a esses aplicativos e serviços. Para permitir o compartilhamento de aplicativos ou
serviços neste cenário, as organizações têm que estabelecer uma relação de confiança de
federação e depois definir as regras para trocar declarações entre as duas organizações.
O slide demonstra o fluxo de tráfego em um cenário de B2B federado que usa um

aplicativo da Web com reconhecimento de declarações. Neste cenário, os usuários na
Empresa A têm que acessar um aplicativo baseado na Web na A. Empresa B. O processo de
autenticação do AD FS para este cenário é o seguinte:

Versão: 1.3- Pág. 151 de 377
Como o AD FS habilita o SSO com serviços online
À medida que as organizações movem serviços e aplicativos para serviços baseados

na nuvem, é cada vez mais importante que essas organizações tenham algum modo de
simplificar a experiência de autenticação e experiência para seus usuários durante o consumo
dos serviços baseados na nuvem. Os serviços baseados na nuvem adicionam outro nível de
complexidade ao ambiente de ti, pois estão localizados fora do controle administrativo direto
dos administradores de TI e podem estar em execução em muitas plataformas diferentes.
Você pode usar o AD FS para fornecer uma experiência de SSO aos usuários nas
várias plataformas baseadas na nuvem que estão disponíveis. Por exemplo, após a
autenticação dos usuários com credenciais do AD DS, eles poderiam acessar os Microsoft
Online Services, como Microsoft Exchange Online ou SharePoint Online hospedado, usando
essas credenciais de domínio.
O AD FS também pode fornecer SSO para provedores de nuvem não Microsoft. Como
o AD FS se baseia em padrões abertos, ele pode interoperar com qualquer sistema baseado
em declarações compatível.
O processo para acessar um aplicativo baseado na nuvem é bastante semelhante ao

cenário de B2B. Um exemplo de um serviço baseado na nuvem que usa o AD FS para
autenticação é uma implantação do Exchange Online híbrida. Nesse tipo de implantação, uma
organização implanta algumas ou todas as caixas de correio em um ambiente do Microsoft
Office 365™ e Exchange Online. Porém, a organização gerencia todas as contas de usuário
no ambiente do AD DS no local. A implantação usa a Ferramenta de Sincronização de
Diretórios do Microsoft Online Services para sincronizar informações de conta do usuário da
implantação no local para a implantação do Exchange Online.

Versão: 1.3- Pág. 152 de 377
Quando os usuários tentam fazer logon na caixa de correio do Exchange Online, eles
precisam ser autenticados com o uso de suas credenciais do AD DS internas. Se os usuários
tentarem fazer logon diretamente no ambiente do Exchange Online, eles serão redirecionados
novamente para a implantação interna do AD FS para autenticação antes de receberem
acesso.
Componentes do AD FS
O AD FS é instalado como uma função de servidor no Windows Server. A tabela a
seguir lista os componentes do AD FS.
Componente O que ela faz?
Servidor de O servidor de federação emite, gerencia e valida solicitações que envolvem

federação declarações de identidade. Todas as implementações do AD FS requerem
um Serviço de Federação pelo menos para cada floresta participante.
Proxy do O proxy do servidor de federação é um componente opcional que você
servidor de normalmente implanta em uma rede de perímetro. Ele não adiciona
federação funcionalidade à implantação do AD FS, mas é implantado apenas para
fornecer uma camada de segurança para conexões da Internet para o
servidor de federação.
Declarações Uma declaração é uma instrução feita por uma entidade confiável sobre um
objeto como um usuário. A declaração pode incluir o nome do usuário, o
cargo ou qualquer outro fator que possa ser usado em um cenário de
autenticação. Com o Windows Server 2012, o objeto também pode ser um
dispositivo usado em uma implantação de Controle de Acesso Dinâmico.
Regras de As regras de declaração determinam como as declarações são
declaração processadas pelos servidores de federação. Por exemplo, uma regra de
declaração pode dizer que um endereço de e-mail é aceito como uma
declaração válida ou que um nome de grupo de uma organização é

Versão: 1.3- Pág. 153 de 377
Componente O que ela faz?

convertido em uma função específica de aplicativo na outra organização.
As regras normalmente são processadas em tempo real, à medida que as
declarações são feitas.
Repositório O AD FS usa um repositório de atributos para procurar valores de
de atributos declarações. O AD DS é um repositório de atributos comum e está
disponível por padrão porque a função de Servidor de Federação deve ser
instalada em um servidor que ingressou no domínio.
Provedor de O provedor de declarações é o servidor que emite declarações e autentica
declarações os usuários. Um provedor de declarações habilita um lado do processo de
autenticação e autorização do AD FS. O provedor de declarações gerencia
a autenticação do usuário e emite as declarações que o usuário apresenta
a uma terceira parte confiável.
Terceira A terceira parte confiável é o local em que o aplicativo está localizado e
parte habilita o segundo lado do processo de autenticação e autorização do AD
confiável FS. A terceira parte confiável é um serviço Web que consome declarações
do provedor de declarações. O servidor da terceira parte confiável deve ter
o Microsoft Windows Identity Foundation instalado ou usar o agente com
reconhecimento de declarações do AD FS 1.0.
Relação de A relação de confiança do provedor de declarações corresponde aos dados
confiança do de configuração que definem regras sob as quais um cliente pode solicitar
provedor de declarações de um provedor de declarações e, subsequentemente, enviá-
declarações las a uma terceira parte confiável. A relação de confiança consiste em
vários identificadores como nomes, grupos e várias regras.
Relação de O AD FS usa certificados digitais ao se comunicar sobre SSL ou como parte
confiança de do processo de emissão de token, do processo de recebimento de token e
terceira parte do processo de publicação de metadados. Os certificados digitais também
confiável são usados para assinatura de token.
Pontos de Os pontos de extremidade são mecanismos do Windows Communication
extremidade Foundation (WCF) que permitem o acesso às tecnologias AD FS, incluindo
emissão de token e publicação de metadados. O AD FS é fornecido com
pontos de extremidade internos que são responsáveis por funcionalidades
específicas.
Pré-requisitos do AD FS
Antes de implantar o AD FS, você deve assegurar que sua rede interna atenda a
alguns pré-requisitos básicos. A configuração dos serviços de rede seguintes é essencial para
uma implantação bem-sucedida do AD FS:

Versão: 1.3- Pág. 154 de 377
 Conectividade de rede. A conectividade de rede seguinte é necessária:

o O computador cliente deve ser capaz de se comunicar com o aplicativo Web,
o servidor de federação de recurso ou o proxy do servidor de federação e o
servidor de federação de conta ou o proxy de federação usando HTTPS.
o Os proxies do servidor de federação devem ser capazes de se comunicar com

os servidores de federação na mesma organização usando HTTPS.
o Os servidores de federação e os computadores cliente internos devem ser

capazes de se comunicar com controladores de domínio para autenticação.
 AD DS. O AD DS é uma parte essencial do AD FS. Os controladores de domínio

devem estar executando o Windows Server 2003 Service Pack 1 (SP1) no mínimo. Os
servidores de federação devem ingressar em um domínio do AD DS. O Proxy do
Serviço de Federação não tem que ingressar em um domínio. Embora você possa
instalar o AD FS em um controlador de domínio, nós não recomendamos isso devido
a implicações de segurança.
 Repositórios de atributos. O AD FS usa um repositório de atributos para compilar

informações de declarações. O repositório de atributos contém informações sobre
usuários, que são extraídas do repositório pelo servidor do AD FS após a autenticação
do usuário. O AD FS oferece suporte aos repositórios de atributos seguintes:
o ADAM (Active Directory Application Mode) no Windows Server 2003
o Active Directory Lightweight Directory Services (AD LDS) no Windows Server

2008, Windows Server 2008 R2 e Windows Server 2012
o Microsoft SQL Server 2005 (todas as edições)
o SQL Server 2008 (todas as edições)
o Um repositório de atributos personalizado

Versão: 1.3- Pág. 155 de 377
 DNS. A resolução de nomes permite que os clientes localizem servidores de

federação. Os computadores cliente devem resolver os nomes DNS para todos os
servidores de federação ou os farms do AD FS aos quais se conectam e aplicativos
Web que o computador cliente está tentando usar. Se o computador cliente for externo
à rede, ele deverá resolver o nome DNS para o Proxy do Serviço de Federação, não
o servidor de federação interno ou farm do AD FS. O Proxy do Serviço de Federação
deve resolver o nome do servidor de federação interno ou farm. Se os usuários
internos tiverem acesso ao servidor de federação interno diretamente e se usuários
externos tiverem que se conectar por meio do proxy do servidor de federação, será
necessário configurar registros de DNS diferentes nas zonas de DNS internas e
externas.
 Pré-requisitos do sistema operacional. Você pode implantar apenas a versão do

Windows Server 2012 do AD FS como uma função de servidor em um servidor do
Windows Server 2012.

Versão: 1.3- Pág. 156 de 377
3.8. VPN (PPTP, IPSEC E SSTP)
A maioria das organizações tem usuários que trabalham remotamente, talvez de casa
ou de locais do cliente. Para facilitar e dar suporte essas conexões remotas, você deve
implementar tecnologias de acesso remoto a fim de dar suporte a essa força de trabalho
distribuída. Você deve estar familiarizado com as tecnologias que permitem aos usuários
remotos se conectarem à infraestrutura de rede da organização.
Configuração do acesso à rede

Para dar suporte às necessidades da organização e dos usuários remotos O Windows
tem a solução de VPN.
Componentes de uma infraestrutura de serviços de acesso à rede
A infraestrutura subjacente em uma infraestrutura completa de serviços de acesso à

rede no Windows Server normalmente inclui os seguintes componentes:
 Servidor VPN. Fornece conectividade de acesso remoto com base em vários

protocolos de encapsulamento VPN via rede pública, como a Internet.
 AD DS (Active Directory Domain Services).

Versão: 1.3- Pág. 157 de 377
 Atende a solicitações de autenticação de tentativas de conexão do cliente de acesso

remoto.
 AD CS (Serviços de Certificados do Active Directory). É possível usar certificados

digitais para fornecer autenticação em cenários de acesso remoto. Implantando o AD
CS, é possível criar uma PKI na organização para dar suporte ao problema, ao
gerenciamento e à revogação de certificados.
 Servidor DHCP. Fornece conexões de acesso remoto de entrada aceitas com uma
configuração de IP para conectividade de rede com a LAN (rede local) corporativa.
 NPS (Servidor de Políticas de Rede). Fornece serviços de autenticação para outros

componentes de acesso à rede.
 Componentes da NAP (Proteção de Acesso à Rede):

o Servidor de política de integridade de NAP. Avalia a integridade do sistema em
relação às políticas de integridade configuradas que descrevem os requisitos
de integridade e os comportamentos de imposição, como a exigência de que
os clientes de conexão sejam compatíveis para que tenham acesso à rede.
o HRA (Autoridade de Registro de Integridade). Obtém certificados de

integridade para clientes aprovados na verificação da política de integridade.
o Servidores de atualizações. Fornece serviços de correção para os clientes que

não atenderem aos requisitos de integridade da rede corporativa. Os
Servidores de Atualizações são servidores especiais em uma rede limitada.
O que é a função Serviços de Acesso e Política de Rede?

A função Serviços de Acesso e Política de Rede no Windows Server 2012 fornece as
seguintes soluções de conectividade de rede:
 Impõe políticas de integridade. Estabeleça e impõe automaticamente políticas de

integridade, que podem incluir requisitos de software, requisitos de atualização de
segurança e configurações de computador obrigatórias.
 Ajuda a proteger o acesso com fio e sem fio. Quando você implantar pontos de acesso
802.1X sem fio, o acesso seguro sem fio fornecerá aos usuários da tecnologia sem fio
um método de autenticação seguro, com base em senha ou certificado, simples de
implantar. Quando você implanta opções de autenticação 802.1X, elas permitem que
você proteja a rede com fio, garantindo que os usuários da intranet sejam autenticados
para que se conectem à rede ou obtenham um endereço IP usando DHCP.
 Centraliza o gerenciamento de políticas de rede com servidor e proxy RADIUS

(Remote Authentication Dial-in User Service). Em vez de configurar a política de
acesso à rede em cada servidor de acesso à rede (como pontos de acesso sem fio,
opções de autenticação 802.1X, servidores VPN e servidores de discagem), é possível
criar políticas em um único local que especifiquem todos os aspectos das solicitações
de conexão à rede. Entre essas políticas estão quem tem autorização para se
conectar, quando eles podem se conectar e o nível de segurança que devem usar para
se conectar à rede.

Versão: 1.3- Pág. 158 de 377
Observação: Os componentes de acesso remoto são uma função de servidor

separada no Windows Server 2012.
O que é a função Acesso Remoto?

A função Acesso Remoto permite dar aos usuários acesso remoto à rede da
organização usando uma das seguintes tecnologias:
 Acesso VPN. Uma VPN fornece uma conexão ponto a ponto entre os componentes
de uma rede privada por meio de uma rede pública, como a Internet. Os protocolos de
encapsulamento permitem que um cliente VPN estabeleça e mantenha uma conexão
com uma porta virtual de escuta do servidor VPN. Também é possível conectar filiais
à rede com soluções VPN, implantar roteadores de software completos na rede e
compartilhar conexões com a Internet pela intranet.
 DirectAccess. O DirectAccess permite acesso remoto contínuo a recursos de intranet

sem que o usuário estabeleça primeiro uma conexão VPN. O DirectAccess assegura
conectividade contínua à infraestrutura do aplicativo para usuários internos e remotos.
É possível implantar as seguintes tecnologias durante a instalação da função Acesso

Remoto:
 DirectAccess e RAS (serviço de acesso remoto) VPN. Usando DirectAccess e RAS
VPN, é possível habilitar e configurar:
o Soluções do DirectAccess para a organização.
o Conexões VPN para dar aos usuários finais acesso remoto à rede da
organização.
 Roteamento. Ele fornece um roteador de software completo e uma plataforma aberta

para roteamento e trabalho na Internet. Ele oferece serviços de roteamento para as
empresas em ambientes de LAN e WAN (rede de longa distância).
Quando você opta pelo roteamento, a NAT (conversão de endereços de rede) também
é instalada. Quando você implanta a NAT, o servidor que está executando Acesso Remoto é
configurado para compartilhar uma conexão de Internet com computadores em uma rede
privada e converter o tráfego entre o endereço público e a rede privada. Usando a NAT, os
computadores na rede privada obtêm certo nível de proteção, pois o roteador em que você
configura a NAT não encaminha o tráfego da Internet para a rede privada, a menos que um
cliente da rede privada solicite ou o tráfego seja explicitamente permitido.
Ao implantar a VPN e a NAT, você configura o servidor que está executando o Acesso
Remoto para oferecer a NAT à rede privada e aceitar conexões VPN. Os computadores na
Internet não poderão determinar os endereços IP de computadores na rede privada. No
entanto, os clientes VPN poderão se conectar aos computadores na rede privada, como se
estivessem fisicamente conectados à mesma rede
Autenticação e autorização de rede

Versão: 1.3- Pág. 159 de 377
A distinção entre autenticação e autorização é importante para ajudar a compreender

por que as tentativas de conexão são aceitas ou negadas:
 Autenticação é a verificação das credenciais da tentativa de conexão. Esse processo
consiste no envio das credenciais do cliente de acesso remoto para o servidor de
acesso remoto, na forma de texto não criptografado ou criptografado, usando um
protocolo de autenticação.
 Autorização é o processo de verificar se a tentativa de conexão é permitida. A

autorização ocorre após a autenticação bem-sucedida.
Para que uma tentativa de conexão seja aceita, ela deve ser autenticada e autorizada.
É possível que a tentativa de conexão seja autenticada usando credenciais válidas, mas não
seja autorizada; nesse caso, a tentativa de conexão é negada.
Se você configurar um servidor Acesso Remoto para a Autenticação do Windows, os

recursos de segurança do Windows Server verificarão as credenciais de autenticação, e as
propriedades de discagem da conta do usuário, além das políticas de acesso remoto
armazenadas localmente autorizarão a conexão. Se uma tentativa de conexão for autenticada
e autorizada, ela será aceita.
Se você configurar um servidor Acesso Remoto para autenticação RADIUS, as

credenciais da tentativa de conexão passarão ao servidor RADIUS para fins de autenticação
e autorização. Se a tentativa de conexão for autenticada e autorizada, o servidor RADIUS
enviará uma mensagem de aceitação para o servidor Acesso Remoto, e essa tentativa de
conexão será aceita. Se a tentativa de conexão não for autenticada nem autorizada, o servidor
RADIUS retornará uma mensagem de rejeição para o servidor Acesso Remoto, e essa
tentativa de conexão será rejeitada.
Métodos de autenticação

Versão: 1.3- Pág. 160 de 377
A autenticação dos clientes de acesso é uma questão de segurança importante.

Normalmente, os métodos de autenticação utilizam um protocolo de autenticação que é
negociado durante o processo de estabelecimento da conexão. Os métodos a seguir têm
suporte da função Acesso Remoto.
PAP
O PAP (Password Authentication Protocol) usa senhas de texto sem formatação e é o
protocolo de autenticação menos seguro. Ele normalmente será negociado se o cliente de
acesso remoto e o servidor Acesso Remoto não conseguirem negociar uma forma de
validação mais segura. PAP está incluído no Microsoft Windows Server 2012 para dar suporte
a sistemas operacionais de clientes mais antigos não compatíveis com nenhum outro método
de autenticação.
CHAP
O CHAP (Challenge Handshake Authentication Protocol) é um protocolo de
autenticação de desafio/resposta que usa o esquema de hash MD5 padrão do setor para
criptografar a resposta. Diversos fornecedores de servidores e clientes de acesso à rede
utilizam o CHAP. Como o CHAP exige o uso de uma senha de criptografia reversível, você
deve considerar o uso de outro protocolo de autenticação, como o MS-CHAP (Microsoft
Challenge Handshake Authentication Protocol) versão 2.
MS-CHAP V2
O MS-CHAP v2 é um processo de autenticação mútua unidirecional, de senha
criptografada, que funciona da seguinte forma:

Versão: 1.3- Pág. 161 de 377
1. O autenticador (o servidor Acesso Remoto ou o computador que está executando

NPS) envia um desafio ao cliente de acesso remoto. O desafio consiste em um
identificador de sessão e em uma cadeia de caracteres de desafio arbitrária.
2. O cliente de acesso remoto envia uma resposta que contém uma criptografia
unidirecional da cadeia de caracteres de desafio recebida, da cadeia de caracteres de
desafio par, do identificador da sessão e da senha do usuário.
3. O autenticador verifica a resposta do cliente e envia de volta uma resposta contendo

uma indicação de êxito ou falha da tentativa de conexão e uma resposta autenticada
baseada na cadeia de caracteres de desafio enviada, na cadeia de caracteres de
desafio par, na resposta criptografada do cliente e na senha do usuário.
4. O cliente de acesso remoto verifica a resposta da autenticação e, se estiver correta,

utiliza a conexão. Se a resposta da autenticação não estiver correta, o cliente de
acesso remoto encerrará a conexão
EAP
Com o EAP (Extensible Authentication Protocol), um mecanismo de autenticação
arbitrário autentica uma conexão de acesso remoto. O cliente de acesso remoto e o
autenticador (seja o servidor Acesso Remoto ou o servidor RADIUS) negociam o esquema de
autenticação exato a ser usado. Por padrão, o serviço Roteamento e Acesso Remoto inclui
suporte para o protocolo EAP-TLS (EAP-Transport Level Security). Você pode conectar outros
módulos EAP ao servidor que está executando o Roteamento e Acesso Remoto para fornecer
outros métodos EAP.
Outras opções
Além dos métodos de autenticação mencionados anteriormente, existem outras duas
opções que é possível habilitar durante a seleção de um método de autenticação:
 Acesso não autenticado. Falando em termos essenciais, não se trata de um método

de autenticação, e sim da falta de um. O acesso não autenticado permite que sistemas
remotos se conectem sem autenticação. Porém, essa opção jamais deve ser habilitada
em um ambiente de produção, porque deixa a rede em risco. No entanto, essa opção
pode, às vezes, ser útil para solucionar problemas de autenticação em um ambiente
de teste.
 Certificado de máquina para IKEv2 (Internet Key Exchange versão 2). Selecione
esta opção caso você queira usar Reconexão VPN.
Configuração do acesso à VPN

Para implementar corretamente um ambiente VPN e dar suporte a ele dentro da
organização, é importante que você compreenda como selecionar um protocolo de
encapsulamento apropriado, como configurar a autenticação VPN e definir a função de
servidor Serviços de Acesso e Política de Rede para dar suporte à configuração escolhida.

Versão: 1.3- Pág. 162 de 377
Conexão VPN
Para emular um link ponto a ponto, os dados são encapsulados e prefixados com um
cabeçalho; esse cabeçalho fornece informações de roteamento que permitem aos dados
percorram a rede compartilhada ou pública até chegarem a seu destino.
Para emular um link particular, os dados são criptografados a fim de garantir a
confidencialidade. Os pacotes interceptados na rede compartilhada ou pública não podem ser
decifrados sem as chaves de criptografia. O link no qual os dados particulares são
encapsulados e criptografados é conhecido como uma conexão VPN.
Há dois tipos de conexão VPN:

 Acesso remoto
 Site a site
VPN de acesso remoto

As conexões VPN de acesso remoto permitem que os usuários que estejam
trabalhando fora do local (por exemplo, em casa, em um local do cliente ou em um ponto de
acesso público sem fio) acessem um servidor na rede privada da organização usando a
infraestrutura fornecida por uma rede pública, como a Internet.
Da perspectiva do usuário, a VPN é uma conexão ponto a ponto entre o computador,
o cliente VPN, e o servidor da sua organização. A infraestrutura exata da rede compartilhada
ou pública é irrelevante, pois ela aparece em termos lógicos, como se os dados fossem
enviados via link particular dedicado

Versão: 1.3- Pág. 163 de 377
VPN site a site

Conexões VPN site a site, também conhecidas como conexões VPN roteador a
roteador, permitem que a organização tenha conexões roteadas entre escritórios distintos (ou
com outras organizações) via rede pública, além de ajudar a manter a comunicação segura.
Uma conexão VPN roteada na Internet opera de modo lógico como um link WAN dedicado.
Quando as redes se conectam pela Internet, um roteador encaminha pacotes para outro
roteador usando uma conexão VPN. Para os roteadores, a conexão VPN funciona como um
vínculo da camada do vínculo de dados.
Uma conexão VPN site a site conecta duas partes de uma rede privada. O servidor
VPN fornece uma conexão roteada para a rede à qual ele está vinculado. O roteador de
chamada (o cliente VPN) se autentica no roteador de resposta (o servidor VPN) e, para ocorrer
a autenticação mútua, o roteador de resposta se autentica no roteador de chamada. Em uma
conexão VPN site a site, os pacotes enviados de ambos os roteadores através da conexão
VPN geralmente não se originam nos roteadores.
Propriedades das conexões VPN

As conexões VPN que usam o PPTP (Point-to-Point Tunneling Protocol), o L2TP/IPsec
(Layer 2 Tunneling Protocol with Internet Protocol Security) ou o SSTP (Secure Socket
Tunneling Protocol) têm as seguintes propriedades:
 Encapsulamento. Com a tecnologia VPN, os dados particulares são encapsulados

com um cabeçalho contendo informações de roteamento que permitem que os dados
percorram a rede de trânsito.
 Autenticação. A autenticação para conexões VPN usa estas três formas diferentes:
o Autenticação no nível de usuário usando a autenticação PPP. Para estabelecer
a conexão VPN, o servidor VPN autentica o cliente VPN que está tentando a
conexão usando um método de autenticação PPP no nível de usuário e verifica
se o cliente VPN tem a autorização adequada. Se a autenticação mútua for
utilizada, o cliente VPN também autenticará o servidor VPN, o que fornecerá
proteção contra computadores que estejam se passando por servidores VPN.
o Autenticação no nível de computador usando o protocolo IKE. Para estabelecer

uma associação de segurança IPsec, o cliente VPN e o servidor VPN utilizam
o protocolo IKE para trocar certificados de computador ou uma chave pré-
compartilhada. Em ambos os casos, o cliente e o servidor VPN se autenticam
mutuamente, no nível de computador. A autenticação por certificados de
computador é recomendável por ser um método de autenticação muito mais
seguro. A autenticação no nível de computador só é executada para as
conexões L2TP/IPsec.
o Autenticação da origem de dados e integridade de dados. Para que seja

possível verificar se os dados enviados na conexão VPN se originaram na outra
extremidade da conexão e não foram modificados em trânsito, os dados
contêm uma soma de verificação criptográfica baseada em uma chave de
criptografia conhecida apenas pelo emissor e pelo receptor. A autenticação da
origem de dados e a integridade de dados só estão disponíveis para as
conexões L2TP/IPsec.
 Criptografia de dados. Para garantir a confidencialidade dos dados quando eles
percorrerem a rede de trânsito compartilhado ou público, o emissor criptografa os

Versão: 1.3- Pág. 164 de 377
dados e o receptor os descriptografa. Os processos de criptografia e descriptografia

dependem do uso de uma chave de criptografia comum ao emissor e ao receptor.
Os pacotes interceptados na rede de trânsito são ilegíveis para quem não tem a chave
de criptografia comum. O tamanho da chave de criptografia é um parâmetro de segurança
importante. Você pode utilizar técnicas computacionais para determinar a chave de
criptografia. Entretanto, com o aumento do tamanho das chaves de criptografia, essas
técnicas exigem mais poder tecnológico e tempo computacional. Sendo assim, é importante
utilizar o maior tamanho possível de chave para assegurar a confidencialidade dos dados.
Protocolos de encapsulamento
Os protocolos PPTP, L2TP, e SSTP dependem intensamente dos recursos
especificados inicialmente para o PPP. O PPP foi projetado para enviar dados através de
conexões discadas ou ponto a ponto dedicadas. Para o IP, o PPP encapsula pacotes IP em
quadros PPP e transmite os pacotes PPP encapsulados por meio do link ponto a ponto. O
PPP foi definido originalmente como o protocolo a ser usado entre um cliente de conexão
discada e um servidor de acesso à rede.
PPTP
O PPTP permite criptografar e encapsular um tráfego multiprotocolo de cabeçalho IP,
que é posteriormente enviado por meio de uma rede IP ou rede IP pública, como a Internet.
Você pode usar o PPTP para acesso remoto e conexões VPN site a site. Quando você usa a
Internet como rede pública VPN, o servidor PPTP é um servidor—VPN habilitado para PPTP
com uma interface na Internet e uma segunda interface na intranet.
 Encapsulamento. O PPTP encapsula quadros PPP em datagramas IP para
transmissão pela rede. O PPTP usa uma conexão TCP (Transmission Control
Protocol) no gerenciamento de túnel e uma versão modificada do cabeçalho GRE
(Generic Route Encapsulation) para encapsular quadros PPP de dados em túnel. As
cargas dos quadros PPP encapsulados podem ser criptografadas, compactadas, ou
ambas.
 Criptografia. O quadro PPP é criptografado com a MPPE (Criptografia Ponto a Ponto

da Microsoft) usando as chaves de criptografa geradas nos processos de autenticação

Versão: 1.3- Pág. 165 de 377
MS-CHAPv2 ou EAP-TLS. Para que as cargas dos quadros PPP sejam criptografadas,
os clientes VPN devem utilizar o protocolo de autenticação MS-CHAPv2 ou EAP-TLS.
O PPTP usa a criptografia subjacente do PPP e encapsula um quadro PPP já
criptografado.
L2TP
O L2TP permite que você criptografe o tráfego multiprotocolo a ser enviado por
qualquer meio compatível com a entrega de datagramas ponto a ponto, como IP ou ATM
(modo de transferência assíncrona). O L2TP é uma combinação do PPTP e do L2F (Layer 2
Forwarding). O L2TP representa os melhores recursos do PPTP e do L2F.
Diferentemente do PPTP, a implementação Microsoft do L2TP não usa a MPPE para
criptografar os datagramas PPP. O L2TP depende do IPsec no Modo de Transporte para os
serviços de criptografia. A combinação do L2TP com o IPsec é conhecida como L2TP/IPsec.
Para utilizar L2TP/IPsec, cliente e servidor VPN devem dar suporte a L2TP e IPsec. O
suporte do cliente para L2TP é interno dos clientes de acesso remoto do Windows XP, do
Windows Vista, do Windows 7 e do Windows 8. O suporte do servidor VPN para L2TP é
interno nos membros das famílias Windows Server 2012, Windows Server 2008 e Windows
Server 2003.
 Encapsulamento: o encapsulamento para pacotes L2TP/IPsec consiste em duas
camadas, encapsulamentos L2TP e IPsec. L2TP encapsula e criptografa dados da
seguinte maneira:
o Primeira camada. A primeira camada é o encapsulamento L2TP. Um quadro
PPP (um datagrama IP) é encapsulado com um cabeçalho L2TP e um
cabeçalho UDP (User Datagram Protocol).
o Segunda camada. A segunda camada é o encapsulamento IPsec. A

mensagem L2TP resultante é encapsulada com um cabeçalho e trailer ESP de
encapsulamento IPsec, além de um trailer de autenticação IPsec que fornece
integridade de mensagem e autenticação, e um cabeçalho final IP. O
cabeçalho IP contém os endereços IP de origem e de destino que
correspondem ao cliente e ao servidor VPN.
o Criptografia: a mensagem L2TP é criptografada com AES (Advanced

Encryption Standard) ou 3DES (Triple Data Encryption Standard) usando
chaves de criptografia geradas pelo processo de negociação IKE.
SSTP
SSTP é um protocolo de encapsulamento que usa o protocolo HTTPS pela porta TCP
443 para passar o tráfego pelos firewalls e proxies Web, que poderiam bloquear o tráfego
PPTP e L2TP/IPsec. O SSTP dispõe de um mecanismo para encapsular o tráfego PPP pelo
canal SSL (Secure Sockets Layer) do protocolo HTTPS. O uso do PPP permite suporte para
métodos de autenticação seguros, como EAP-TLS. O SSL oferece segurança no nível de
transporte com negociação avançada de chaves, criptografia e verificação de integridade.
Quando um cliente tenta estabelecer uma conexão VPN baseada no SSTP, este
estabelece primeiramente uma camada HTTPS bidirecional com o servidor SSTP. Nessa

Versão: 1.3- Pág. 166 de 377
camada HTTPS, os pacotes do protocolo fluem conforme a carga útil de dados usando os
seguintes métodos de encapsulamento e criptografia:
o Encapsulamento. O SSTP encapsula quadros PPP em datagramas IP para
transmissão pela rede. O SSTP usa uma conexão TCP (pela porta 443) para o
gerenciamento de túneis e como quadros de dados PPP.
o Criptografia. A mensagem SSTP é criptografada com o canal SSL do protocolo HTTPS
IKEv2
IKEv2 usa o protocolo IPsec Tunnel Mode via porta UDP 500. O IKEv2 dá suporte à
mobilidade tornando-o uma boa opção de protocolo para uma força de trabalho móvel. As
VPNs baseadas em IKEv2 permitem que os usuários alternem facilmente pontos de acesso
sem fio ou conexões sem e com fio.
O uso do IKEv2 e do IPsec habilita o suporte para métodos seguros de autenticação
e criptografia.
o Encapsulamento. IKEv2 encapsula datagramas usando ESP ou AH IPsec para
transmissão pela rede.
o Criptografia. A mensagem é criptografada com um dos protocolos a seguir usando

chaves de criptografia que são geradas no processo de negociação do IKEv2:
algoritmos de criptografia AES 256, AES 192, AES 128 e 3DES.
IKEv2 só é compatível em computadores nos quais estejam em execução Windows 7,

Windows 8, Windows Server 2008 R2 e Windows Server 2012. IKEv2 é o protocolo de
encapsulamento VPN padrão no Windows 7 e no Windows 8.
Reconexão VPN
Em cenários de negócios dinâmicos, os usuários devem poder acessar os dados com
segurança a qualquer momento, de qualquer lugar, e acessá-los continuamente, sem
interrupção. Por exemplo, talvez os usuários queiram acessar com segurança dados que
estejam no servidor da empresa, a partir de uma filial ou enquanto estiverem viajando.

Versão: 1.3- Pág. 167 de 377
Para atender a esse requisito, é possível configurar o recurso Reconexão VPN que
está disponível no Windows Server 2012, no Windows Server 2008 R2, no Windows 8 e no
Windows 7. Com esse recurso, os usuários podem acessar os dados da empresa usando
uma conexão VPN, que reconectará automaticamente se a conectividade for interrompida. A
Reconexão VPN também permite roaming entre redes diferentes.
A Reconexão VPN usa a tecnologia IKEv2 para fornecer conectividade VPN contínua
e consistente. Os usuários que se conectam via banda larga móvel sem fio são os que mais
aproveitarão esse recurso. Pense em um usuário com um notebook que esteja executando o
Windows 8. Quando viaja de trem a trabalho, o usuário se conecta à Internet com uma banda
larga móvel sem fio e estabelece uma conexão VPN com a rede da empresa. Quando o trem
passa por um túnel, a conexão com a Internet é perdida. Depois que o trem sai do túnel,
abanda larga móvel sem fio se reconecta automaticamente à Internet. Nas versões anteriores
do sistemas operacionais cliente e servidor do Windows, a VPN não se reconectava
automaticamente. Por isso, o usuário teria que repetir o processo de várias etapas de conexão
com a VPN manualmente. Essa tarefa era demorada e frustrante para usuários móveis com
conectividade intermitente.
Com a Reconexão VPN, o Windows Server 2012 e o Windows 8 restabelecem

conexões VPN ativas automaticamente quando a conectividade com a Internet é
restabelecida. Ainda que a reconexão possa demorar alguns segundos, os usuários não
precisam restabelecer a conexão manualmente ou se autenticar novamente para acessarem
os recursos de rede internos.
Os requisitos de sistema para usar o recurso Reconexão VPN são os seguintes:

 Windows Server 2008 R2 ou Windows Server 2012 como um servidor VPN.
 Cliente Windows 7, Windows 8, Windows Server 2008 R2 ou Windows Server 2012.
 PKI, pois um certificado de computador é obrigatório para uma conexão remota com a
Reconexão VPN. É possível usar certificados emitidos por uma AC interna ou pública.
Requisitos de configuração
Antes de implantar a solução VPN da organização, considere os seguintes requisitos
de configuração:
 O servidor VPN exige duas interfaces de rede. Você deve identificar qual interface de
rede se conectará à Internet e qual interface de rede se conectará à rede privada.
Durante a configuração, você deverá escolher qual interface de rede se conectará à
Internet. Se você especificar a interface incorreta, o servidor VPN de acesso remoto
não funcionará corretamente.
 Determine se clientes remotos recebem endereços IP de um servidor DHCP na rede

privada ou do servidor VPN de acesso remoto que você está configurando. Se você
tiver um servidor DHCP na rede privada, o servidor VPN de acesso remoto poderá
conceder dez endereços de cada vez do servidor DHCP e atribuí-los a clientes
remotos. Se você não tiver um servidor DHCP na rede privada, o servidor VPN de
acesso remoto poderá gerar e atribuir endereços IP automaticamente a clientes

Versão: 1.3- Pág. 168 de 377
remotos. Para que o servidor VPN de acesso remoto atribua endereços IP de um

intervalo especificado, determine esse intervalo.
 Determine se deseja que as solicitações de conexão dos clientes VPN sejam

autenticadas por um servidor RADIUS ou pelo servidor VPN de acesso remoto que
está configurando. A inclusão de um servidor RADIUS será útil se você pretender
instalar vários servidores VPN de acesso remoto, pontos de acesso sem fio ou outros
clientes RADIUS na rede privada.
Observação: Para habilitar uma infraestrutura RADIUS, instale a função de servidor

Serviços de Acesso e Política de Rede. O NPS pode funcionar como um proxy ou um servidor
RADIUS.
 Determine se os clientes VPN podem enviar mensagens DHCPINFORM ao servidor

DHCP em sua rede privada. Se existir um servidor DHCP na mesma sub-rede do
servidor VPN de acesso remoto, as mensagens DHCPINFORM dos clientes VPN
poderão acessar o servidor DHCP depois que a conexão VPN for estabelecida. Se um
servidor DHCP estiver em uma sub-rede diferente daquela do servidor VPN de acesso
remoto, verifique se o roteador entre as sub-redes pode retransmitir mensagens do
DHCP entre os clientes e o servidor. Se o roteador estiver executando o Windows
Server 2008 R2 ou o Windows Server R2 2012, será possível configurar o serviço
Agente de Retransmissão DHCP no roteador para encaminhar mensagens
DHCPINFORM entre as sub-redes.
 Verifique se a pessoa responsável pela implantação da solução VPN tem as

associações ao grupo administrativo necessárias para instalar as funções de servidor
e configurar os serviços necessários; a associação do grupo Administradores local é
obrigatória para realizar essas tarefas.
3.9. NPS E NAP

Versão: 1.3- Pág. 169 de 377
A função NPS (Servidor de Política de Rede) no Windows Server 2012 fornece suporte
para o protocolo RADIUS e pode ser configurada como um servidor ou proxy RADIUS. Além
disso, o NPS fornece funcionalidade essencial à implementação da NAP (Proteção de Acesso
à Rede). Para oferecer suporte a clientes remotos e implementar a NAP, é importante saber
como instalar e configurar o NPS, bem como solucionar problemas relacionados.
Servidor de Políticas de Rede

O NPS permite criar e impor políticas de acesso à rede em nível organizacional, para
fins de integridade do cliente, autenticação e autorização de solicitação de conexão. Você
também pode usar o NPS como um proxy RADIUS para encaminhar solicitações de conexão
para o NPS ou para outros servidores RADIUS configurados em grupos de servidores
RADIUS remotos.
Você pode usar o NPS para configurar e gerenciar de modo centralizado a

autenticação de acesso à rede, a autorização e as políticas de integridade de cliente usando
qualquer combinação das três funções a seguir:
 Servidor RADIUS
 Proxy RADIUS
 Servidor de política NAP
Servidor RADIUS
O NPS realiza a autenticação, a autorização e a contabilização de conexões
centralizadas para conexões sem fio, de comutação de autenticação, bem como dial-up e
VPN (rede virtual privada). Ao usar o NPS como um servidor RADIUS, configure os servidores
de acesso à rede, como pontos de acesso sem fio e servidores VPN, como clientes RADIUS
no NPS. Configure também as políticas de rede que o NPS utiliza para autorizar as
solicitações de conexão, de modo que seja possível configurar a contabilização RADIUS para

Versão: 1.3- Pág. 170 de 377
que o NPS registre as informações de contabilização em arquivos de log no disco rígido local
ou em um banco de dados Microsoft SQL Server.
O NPS é a implementação Microsoft de um servidor RADIUS. O NPS permite o uso

de um conjunto heterogêneo de equipamento sem fio, de comutação, de acesso remoto ou
de VPN. Você pode usar o NPS com o serviço Roteamento e Acesso Remoto, que está
disponível no Windows 2000 e nas versões mais recentes do Windows Server.
Quando um servidor NPS for membro de um domínio AD DS (Serviços de Domínio

Active Directory), o NPS usará o AD DS como seu banco de dados de conta de usuário e
fornecerá SSO (logon único), o que significa que os usuários utilizam o mesmo conjunto de
credenciais para controle de acesso à rede (autenticando e autorizando acesso a uma rede),
da mesma forma que acessam recursos no domínio AD DS.
Organizações que mantêm o acesso à rede, como ISPs (provedores de serviço de
Internet), têm o desafio de gerenciar vários métodos de acesso à rede em um único ponto de
administração, independentemente do tipo de equipamento de acesso à rede que eles
utilizam. O padrão RADIUS dá suporte a este requisito. RADIUS é um protocolo de plataforma
cliente-servidor que permite que os equipamentos de acesso à rede, usados como clientes
RADIUS, enviem solicitações de autenticação e contabilização para um servidor RADIUS.
Um servidor RADIUS tem acesso às informações da conta do usuário e pode verificar

as credenciais de autenticação do acesso à rede. Se as credenciais do usuário forem
autênticas e o RADIUS autorizar a tentativa de conexão, o servidor RADIUS autorizará o
acesso do usuário de acordo com as condições configuradas e registrará a conexão de acesso
à rede em um log de contabilização. O uso do RADIUS permite coletar e manter os dados da
autenticação do usuário, da autorização e da contabilização de acesso à rede em um local
central, e não em cada servidor de acesso.
Proxy RADIUS
Quando o NPS for utilizado como um proxy RADIUS, configure políticas de solicitação
de conexão que indiquem quais solicitações de conexão o servidor NPS encaminhará para
outros servidores RADIUS e os servidores RADIUS para os quais essas solicitações serão
encaminhadas. Você também pode configurar o NPS para encaminhar dados de
contabilização para registro em log por um ou mais computadores em um grupo de servidores
RADIUS remotos.
Com o NPS, sua organização também pode terceirizar a infraestrutura de acesso

remoto para um provedor de serviços, e ainda manter o controle sobre a autenticação do
usuário, a autorização e a contabilização. Você pode criar diferentes configurações NPS para
as seguintes soluções:
 Acesso sem fio
 Acesso remoto à rede dial-up ou à VPN da organização
 Acesso terceirizado à rede dial-up ou sem fio
 Acesso à Internet

Versão: 1.3- Pág. 171 de 377
 Acesso autenticado aos recursos da extranet de parceiros de negócio
Servidor de política NAP

Quando você configura o NPS como um servidor de políticas NAP, o NPS avalia as
declarações de integridade (SoHs) enviadas pelos computadores cliente compatíveis com
NAP que tentam se conectar à rede. O NPS também atua como um servidor RADIUS quando
configurado com a NAP, realizando a autenticação e autorização de solicitações de conexão.
É possível definir políticas e configurações NAP no NPS, inclusive SHVs (validadores da
integridade do sistema), política de integridade e grupos de servidores de atualizações que
permitem que os computadores cliente atualizem as respectivas configurações, de modo a se
tornarem compatíveis com a política de rede de sua organização.
O Windows 8 e o Windows Server 2012 incluem a NAP, o que ajuda a proteger o
acesso às redes privadas, garantindo que os computadores cliente sejam configurados de
acordo com as políticas de integridade da rede da organização para que possam se conectar
aos recursos da rede. Além disso, a NAP monitora a conformidade dos computadores cliente
com a política de integridade definida pelo administrador, enquanto o computador estiver
conectado à rede. O recurso de correção automática da
NAP permite verificar se computadores incompatíveis são atualizados
automaticamente, tornando-os compatíveis com a política de integridade para que obtenham
êxito na conexão com a rede.
Os administradores de sistema definem as políticas de integridade da rede e geram
essas políticas usando componentes da NAP fornecidos pelo NPS, de acordo com a
implantação da NAP, ou fornecidos por terceiros.
As políticas de integridade podem conter requisitos de software, de atualização de
segurança e as definições das configurações necessárias. Para impor as políticas de
integridade, a NAP inspeciona e avalia a integridade dos computadores cliente, restringe o
acesso à rede quando os computadores cliente são considerados problemáticos e os corrige
para que obtenham o acesso total à rede.
Ferramentas para configurar um Servidor de Políticas de Rede

Após instalar a função Servidor de Políticas de Rede, você pode abrir a ferramenta
administrativa NPS no menu Ferramentas Administrativas ou adicionar o snap-in para criar
uma ferramenta personalizada MMC (Console de Gerenciamento Microsoft). Você também
pode usar os comandos netsh para gerenciar e configurar a função NPS

Versão: 1.3- Pág. 172 de 377
Estas ferramentas permitem que você gerencie a função de servidor Serviços de

Acesso e Política de Rede:
 Snap-in do MMC do NPS. Use o MMC do NPS para configurar um servidor RADIUS,
um proxy RADIUS ou uma tecnologia NAP.
 Comandos netsh para NPS. Os comandos netsh para NPS consistem em um conjunto
de comandos que é o equivalente completo de todas as definições de configuração
disponíveis por meio do snap-in NPS MMC. Você pode executar os comandos netsh
manualmente no prompt do netsh ou nos scripts do administrador.
Um exemplo do uso do netsh é que, após instalar e configurar o NPS, é possível salvar
a configuração, emitindo o comando netsh nps show config > path\file.txt. Salve a
configuração NPS com esse comando toda vez que fizer uma alteração.
Por exemplo, para exportar a configuração NPS, você pode usar o cmdlet Export-
NpsConfiguration -Path <nome de arquivo>.
Configuração de clientes e servidores RADIUS

RADIUS é um protocolo de autenticação padrão do setor usado por muitos
fornecedores para oferecer suporte à troca de informações de autenticação entre elementos
de uma solução de acesso remoto. Para centralizar as necessidades da autenticação remota
de sua organização, você pode configurar NPS como um servidor RADIUS ou um proxy
RADIUS. Ao configurar clientes e servidores RADIUS, você deve considerar vários fatores,

Versão: 1.3- Pág. 173 de 377
como os servidores RADIUS que autenticarão solicitações de conexão de clientes RADIUS e

as portas que o tráfego RADIUS usará.
O que é um cliente RADIUS?

Um NAS (servidor de acesso à rede) é um dispositivo que fornece níveis de acesso a
uma rede maior. Um NAS que usa uma infraestrutura RADIUS também é um cliente RADIUS,
que origina solicitações de conexão e mensagens de contabilização para um servidor RADIUS
para autenticação, autorização e contabilização. Os computadores cliente, como laptops sem
fio e outros computadores que executam sistemas operacionais cliente, não são clientes
RADIUS. Os clientes RADIUS são servidores de acesso à rede — incluindo pontos de acesso
sem fio, comutadores de autenticação 802.1X, servidores VPN e servidores de rede dial-up
— uma vez que utilizam o protocolo RADIUS para se comunicar com os servidores RADIUS,
como os servidores NPS.
Para implantar o NPS como um servidor RADIUS, um proxy RADIUS ou um servidor

de políticas NAP, configure os clientes RADIUS no NPS.
Exemplos de clientes RADIUS

Exemplos de servidores de acesso à rede:
 Servidores de acesso à rede que oferecem conectividade de acesso remoto à rede de
uma organização ou à Internet, como um computador que está executando com o
sistema operacional Windows Server 2012 e o serviço Roteamento e Acesso Remoto,

Versão: 1.3- Pág. 174 de 377
que fornece serviços tradicionais de rede dial-up ou de acesso remoto à VPN para a
intranet de uma organização.
 Pontos de acesso sem fio que fornecem acesso à camada física da rede de uma
organização usando tecnologias de transmissão e recepção baseadas no padrão sem
fio.
 Switches que fornecem acesso à camada física da rede de uma organização usando
tecnologias tradicionais de LAN (rede local), como a Ethernet.
 Proxies RADIUS baseados no NPS que encaminham solicitações de conexão para

servidores RADIUS que pertencem a um grupo de servidores remotos RADIUS
configurado no proxy RADIUS ou em outros proxies RADIUS.
Proxy RADIUS
Você pode usar o NPS como um proxy RADIUS para rotear mensagens do RADIUS
entre clientes RADIUS (servidores de acesso à rede) e servidores RADIUS que executam a
autenticação, a autorização e a contabilização de usuário na tentativa de conexão.
Quando você usa o NPS como um proxy RADIUS, o NPS é um ponto de comutação e
roteamento central através do qual fluem as mensagens de contabilização e acesso do
RADIUS. O NPS registra informações em um log de contabilização sobre as mensagens
encaminhadas.
Você pode usar o NPS como um proxy RADIUS quando:
 Você for um provedor de serviços que oferece serviços terceirizados de rede dial-up,
VPN ou de acesso à rede sem fio para diversos clientes. Seu NAS envia solicitações

Versão: 1.3- Pág. 175 de 377
de conexão ao proxy RADIUS NPS. Com base na parte do território do nome do

usuário contida na solicitação de conexão, o proxy RADIUS NPS encaminha a
solicitação de conexão para um servidor RADIUS mantido pelo cliente, e pode
autenticar e autorizar a tentativa de conexão.
 Você deseja oferecer autenticação e autorização de contas do usuário que não são
membros do domínio ao qual o servidor NPS pertence, ou de um domínio que possui
uma relação de confiança bidirecional com o domínio do membro do servidor NPS.
Isso abrange as contas existentes em domínios não confiáveis, domínios com relação
de confiança unidirecional e outras florestas. Em vez de configurar os servidores de
acesso para enviar as respectivas solicitações de conexão para um servidor RADIUS
NPS, você pode configurá-los para enviar essas solicitações para um proxy RADIUS
NPS. O proxy RADIUS NPS usa a parte do nome de realm do nome do usuário e
encaminha a solicitação para um servidor NPS no domínio ou na floresta corretos. As
tentativas de conexão de contas do usuário em um domínio ou floresta podem ser
autenticadas para o NAS em outro domínio ou floresta.
 Você deseja executar autenticação e autorização usando um banco de dados diferente

de um banco de dados da conta do Windows. Nesse caso, o NPS encaminha as
solicitações de conexão correspondentes a um nome de realm especificado para um
servidor RADIUS, que tem acesso a outro banco de dados de contas do usuário e
dados de autorização. Um exemplo de outro banco de dados de usuário são bancos
de dados SQL.
 Você deseja processar uma grande quantidade de solicitações de conexão. Nesse

caso, em vez de configurar os clientes RADIUS para tentar equilibrar as respectivas
solicitações de conexão e contabilização entre vários servidores RADIUS, configure-
os para enviar suas solicitações de conexão e contabilização para um proxy RADIUS
NPS. O proxy RADIUS NPS equilibra dinamicamente a carga das solicitações de
conexão e contabilização entre os diversos servidores RADIUS, além de aumentar o
processamento de grandes quantidades de clientes e autenticações RADIUS a cada
segundo.
 Você deseja fornecer autenticação e autorização RADIUS para provedores de serviços

terceirizados e minimizar a configuração do firewall da intranet.
Um firewall de intranet está entre sua intranet e sua rede de perímetro (a rede existente
entre a intranet e a Internet). Ao colocar um servidor NPS em sua rede de perímetro, o firewall
existente entre a rede de perímetro e a intranet deve permitir o fluxo do tráfego entre o servidor
NPS e os diversos controladores de domínio.
Ao substituir o servidor NPS por um proxy NPS, o firewall deve permitir que somente
o tráfego do RADIUS flua entre o proxy NPS e um ou vários servidores NPS dentro de sua
intranet.
Política de Solicitação de Conexão

Políticas de solicitação de conexão são conjuntos de condições e configurações que
permitem que os administradores de rede designem quais servidores RADIUS executarão a
autenticação e a autorização de solicitações de conexão que o servidor NPS recebe de

Versão: 1.3- Pág. 176 de 377
clientes RADIUS. É possível configurar as políticas de solicitação de conexão para que

designem os servidores RADIUS que serão usados para a contabilização RADIUS.
Observação: Ao implantar a NAP usando os métodos de imposição VPN ou 802.1X

com autenticação PEAP, configure a autenticação PEAP na política de solicitação de
conexão, mesmo que as solicitações de conexões sejam processadas localmente.
Você pode criar uma série de políticas de solicitação de conexão, de forma que
algumas mensagens de solicitação RADIUS enviadas de clientes RADIUS sejam processadas
localmente (NPS é um servidor RADIUS) e que outros tipos de mensagens sejam
encaminhados para outro servidor RADIUS (NPS é um proxy de RADIUS).
Com políticas de solicitação de conexão, você pode usar NPS como um servidor
RADIUS ou como um proxy RADIUS, com base em uma variedade de fatores, incluindo:
 A hora do dia e o dia da semana.
 O nome de realm na solicitação de conexão.
 O tipo de conexão que está sendo solicitada.
 O endereço IP do cliente RADIUS.
Condições
Condições de política de solicitação de conexão são um ou mais atributos RADIUS
comparados com os atributos da mensagem de solicitação de acesso RADIUS recebida. Se
existirem várias condições, o NPS irá impor a política somente se todas as condições contidas

Versão: 1.3- Pág. 177 de 377
na mensagem de solicitação de conexão e na política de solicitação de conexão forem

correspondentes.
Configurações
Configurações de política de solicitação de conexão são um conjunto de propriedades
aplicadas a uma mensagem RADIUS recebida. As configurações são formadas pelos
seguintes grupos de propriedades:
 Autenticação
 Contabilização
 Manipulação de atributos
 Avançado
Política padrão de solicitação de conexão

Quando você instala o NPS, é criada uma política padrão de solicitação de conexão
com as seguintes condições:
 A autenticação não é configurada.
 A contabilização não é configurada para encaminhar as informações de contabilização
para um grupo de servidores remotos RADIUS.
 A manipulação de atributo não é configurada com as regras que alteram os atributos
nas solicitações de conexão encaminhadas.
 A Solicitação de Encaminhamento é ativada, o que significa que o servidor NPS local
autentique e autorize as solicitações de conexão.
 Os atributos avançados não são configurados
A política padrão de solicitação de conexão utiliza o NPS como um servidor RADIUS.

Para configurar um servidor NPS para atuar como um proxy RADIUS, configure também um
grupo de servidores remotos RADIUS. Você pode criar um novo grupo de servidores remotos
RADIUS durante o processo de criação de uma nova política de solicitação de conexão com
o Assistente de Nova Política de Solicitação de Conexão.
É possível excluir a política padrão de solicitação de conexão ou garantir que essa
política padrão seja a última a ser processada.
Observação: Se o NPS e o serviço Roteamento e Acesso Remoto estiverem

instalados no mesmo computador, e esse serviço estiver configurado para autenticação e
contabilização do Windows, será possível que as solicitações de autenticação e
contabilização do serviço Roteamento e Acesso Remoto sejam encaminhadas para um
servidor RADIUS. Isso pode ocorrer quando as solicitações de autenticação e contabilização
do serviço Roteamento e Acesso Remoto atenderem a uma política de solicitação de conexão
configurada para encaminhá-las para um grupo de servidores remotos RADIUS.

Versão: 1.3- Pág. 178 de 377
Configuração do processamento de solicitação de conexão

A política padrão de solicitação de conexão usa o NPS como um servidor RADIUS e
processa todas as solicitações de autenticação localmente.
Considerações sobre a configuração do processamento das solicitações de

conexão
Ao configurar o processamento das solicitações de conexão, leve em consideração os

seguintes pontos:
 Para configurar um servidor NPS para atuar como um proxy RADIUS e

encaminhar as solicitações de conexão para outros servidores NPS ou
RADIUS, é preciso configurar um grupo de servidores remotos RADIUS e
adicionar uma nova política de solicitação de conexão que especifique as
condições e configurações que devem ser atendidas pelas solicitações de
conexão.
 Você pode usar o Assistente de Nova Política de Solicitação de Conexão para

criar um novo grupo de servidores remotos RADIUS ao criar uma nova
solicitação de conexão.
 Para que o servidor NPS não atue como um servidor RADIUS e processe as
solicitações de conexão localmente, exclua a política padrão de solicitação de
conexão.
 Se você preferir que o servidor NPS atue duplamente como um servidor

RADIUS (processando as solicitações de conexão localmente) e como um
proxy RADIUS (encaminhando algumas solicitações de conexão para um

Versão: 1.3- Pág. 179 de 377
grupo de servidores remotos RADIUS), adicione uma nova política e verifique

se a política padrão de solicitação de conexão é a última processada.
Portas para RADIUS e registro em log

Por padrão, o NPS escuta o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 para
os protocolos IPv6 e IPv4 em todos os adaptadores de rede instalados.
Observação: Se você desabilitar o IPv4 ou o IPv6 em um adaptador de rede, o NPS

não monitorará o tráfego RADIUS para o protocolo desinstalado.
Os valores 1812 para autenticação e 1813 para contabilização representam as portas

RADIUS padrão definidas nas RFCs 2865 e 2866. No entanto, por padrão, muitos servidores
de acesso usam as portas 1645 para solicitações de autenticação e 1646 para solicitações de
contabilização. Ao determinar os números de porta a serem usados, verifique se você
configura o NPS e o servidor de acesso para usar os mesmos números de porta. Se você não
usar os números de porta RADIUS padrão, será necessário configurar as exceções no firewall
do computador local para permitir o tráfego RADIUS nas novas portas.
Configuração das informações de porta UDP do NPS

Você pode usar o procedimento a seguir para configurar as portas UDP que o NPS
usa para o tráfego de autenticação e contabilização do RADIUS.
Observação: Para executar esse procedimento, é preciso que você seja membro do
grupo Administradores do Domínio, Administradores de Empresa ou Administradores no
computador local.
Para configurar as informações da porta UDP do NPS por meio da interface do

Windows:
1. Abra o console do NPS.
2. Clique com o botão direito do mouse em Servidor de Políticas de Rede e clique em

Propriedades.
3. Clique na guia Portas e examine as configurações para portas. Se as portas UDP de

autenticação e contabilização RADIUS variarem dos valores padrão fornecidos (1812
e 1645 para autenticação, e 1813 e 1646 para contabilização), digite as configurações
da porta em Autenticação e Contabilização.
Observação: Para usar várias configurações de porta em solicitações de autenticação

ou contabilização, separe os números das portas com vírgulas.

Versão: 1.3- Pág. 180 de 377
Métodos de autenticação do NPS

O NPS autentica e autoriza uma solicitação de conexão antes de permitir ou negar
acesso quando os usuários tentam se conectar com sua rede através de servidores de acesso
à rede, também conhecidos como clientes RADIUS, como pontos de acesso sem fio, switches
de autenticação 802.1X, servidores dial-up e servidores VPN.
Como a autenticação é o processo de verificar a identidade do usuário ou do

computador que está tentando se conectar à rede, o NPS deve comprovar a identidade do
usuário ou do computador na forma de credenciais.
Alguns métodos de autenticação implementam o uso de credenciais baseadas em

senha. Em seguida, o servidor de acesso à rede transfere essas credenciais para o servidor
NPS, que as compara com as entradas contidas no banco de dados de contas de usuário.
Outros métodos de autenticação implementam o uso de credenciais baseadas em

certificados do usuário, do computador cliente, do servidor NPS ou outra combinação. Os
métodos de autenticação baseados em certificados fornecem alta segurança e são mais
recomendáveis do que os métodos de autenticação baseados em senha.
Ao implantar o NPS, especifique o tipo necessário de método de autenticação para

acessar a rede.
Métodos de autenticação baseados em senha

Cada método de autenticação tem vantagens e desvantagens em termos de
segurança, usabilidade e abrangência do suporte. No entanto, métodos de autenticação
baseados em senha não garantem segurança máxima e não são recomendados. É
recomendável usar um método de autenticação baseado em certificado para o acesso à rede
para todos os métodos que ofereçam suporte ao uso de certificado. Isso se constata
principalmente nas conexões sem fio, para as quais é recomendável o uso do PEAP-MS-
CHAP v2 ou PEAP-TLS.

Versão: 1.3- Pág. 181 de 377
O método de autenticação necessário é determinado pela configuração do servidor de

acesso à rede, pelo computador cliente e pela política de rede no servidor NPS. Consulte a
documentação do servidor de acesso para conhecer os métodos de autenticação compatíveis.
É possível configurar o NPS para aceitar vários métodos de autenticação. Você

também pode configurar os servidores de acesso à rede, conhecidos também como clientes
RADIUS, para tentar negociar uma conexão com os computadores cliente, solicitando o uso
do protocolo mais seguro em primeiro lugar, e depois os mais seguros na ordem decrescente,
e assim por diante, até o menos seguro. Por exemplo, o serviço Roteamento e Acesso Remoto
tenta negociar uma conexão usando os protocolos a seguir na ordem mostrada:
1. EAP
2. MS-CHAP v2
3. MS-CHAP
4. CHAP
5. SPAP
6. PAP
Quando o protocolo EAP é escolhido como método de autenticação, ocorre uma
Acesso não autenticado

Com o acesso não autenticado, as credenciais do usuário (um nome de usuário e
senha) não são necessárias. Embora haja algumas situações em que o acesso não
autenticado seja útil, na maioria das vezes, não é recomendável implantar esse tipo de acesso
na rede de sua organização.

Versão: 1.3- Pág. 182 de 377
Quando você habilitar o acesso não autenticado, os usuários poderão acessar sua
rede sem enviar as credenciais do usuário. Além disso, clientes de acesso não autenticados
não negociam o uso de um protocolo de autenticação comum durante o processo de
estabelecimento de conexão e eles não enviam para o NPS um nome de usuário ou senha.
Se você permitir o acesso não autenticado, os clientes poderão se conectar sem

autenticação se os protocolos de autenticação configurados no cliente de acesso não
corresponderem aos protocolos de autenticação configurados no servidor de acesso à rede.
Nesse caso, o uso de um protocolo de autenticação comum não é negociado e o cliente de
acesso não envia um nome de usuário e senha. Essa circunstância gera um problema de
segurança grave. Portanto, o acesso não autenticado não deve ser permitido na maioria das
redes.
Uso de certificados para autenticação

Certificados são documentos digitais emitidos pelas autoridades de certificação, como
AD CS (Serviços de Certificados do Active Directory) ou a autoridade de certificação pública
da VeriSign. Os certificados podem ser usados para vários fins, como a assinatura de código
e a proteção da comunicação por e-mail. No entanto, com o NPS, você usa certificados para
autenticação do acesso à rede, pois eles garantem segurança máxima para a autenticação
de usuários e computadores, e também eliminam a necessidade de métodos de autenticação
baseados em senha, que são menos seguros.
Os servidores NPS utilizam os protocolos EAP-TLS e PEAP para fazer a autenticação

baseada em certificado para diversos tipos de acesso à rede, como as conexões de rede VPN
e sem fio.
Métodos de autenticação

Versão: 1.3- Pág. 183 de 377
Dois métodos de autenticação, quando você os configura com os tipos de autenticação

baseada em certificado, usam certificados: EAP e PEAP. Com o EAP, é possível configurar o
tipo de autenticação TLS (EAP-TLS), e com o PEAP, os tipos de autenticação TLS (PEAP-
TLS) e MS-CHAP v2 (PEAP-MS-CHAP v2).
Esses métodos de autenticação sempre utilizam certificados para a autenticação do
servidor. De acordo com o tipo de autenticação configurado no método de autenticação, você
também pode usar certificados para a autenticação de usuários e de computadores cliente.
Autenticação mútua
Quando você utilizar o EAP com um tipo forte de EAP (como o TLS com cartões
inteligentes ou certificados), tanto o cliente quanto o servidor usarão certificados para validar
mutuamente suas identidades, o que é conhecido como autenticação mútua. Os certificados
devem atender a requisitos específicos para que o servidor e o cliente os utilizem na
autenticação mútua.
Um desses requisitos é que o certificado esteja configurado com um ou mais
propósitos nas extensões EKU (Uso Estendido de Chave), relacionadas ao uso do certificado.
Por exemplo, você deve configurar um certificado que seja utilizado para a autenticação de
um cliente com a finalidade de Autenticação de Cliente. Da mesma forma, você deve
configurar um certificado que seja utilizado para a autenticação de um servidor com a
finalidade de Autenticação de Servidor. Quando você usa certificados para autenticação, o
autenticador examina o certificado do cliente e procura o identificador correto do objeto
finalidade nas extensões EKU. Por exemplo, o identificador do objeto da finalidade
Autenticação do Cliente é 1.3.6.1.5.5.7.3.2. Quando você utiliza um certificado para
autenticação de computadores cliente, esse identificador de objeto deve estar presente nas
extensões EKU do certificado, caso contrário, a autenticação falhará.
Modelos de certificado
Modelos de Certificado é um snap-in do MMC que permite a personalização dos
certificados emitidos pelo AD CS. As opções de personalização abrangem o modo como os
certificados serão emitidos e o que conterão, inclusive suas finalidades. Nos Modelos de
Certificado, é possível usar um modelo padrão, como o modelo Computador, para definir o
modelo que a autoridade de certificação usará para atribuir certificados aos computadores.
Você também pode criar um modelo de certificado e atribuir finalidades a esse modelo nas
extensões EKU. Por padrão, o modelo Computador contém as finalidades Autenticação de
Cliente e Autenticação de Servidor nas extensões EKU.
O modelo de certificado criado pode conter qualquer finalidade para a qual você o
utilizará. Por exemplo, se você usar cartões inteligentes na autenticação, será possível incluir
a finalidade Logon do Cartão Inteligente, além da finalidade Autenticação de Cliente. Ao usar
o NPS, você pode configurá-lo para verificar as finalidades dos certificados antes de conceder
autorização para a rede. O NPS pode verificar outras finalidades das EKUs e das Políticas de
Emissão, conhecidas também como Políticas de Certificado
Observação: Alguns softwares de autoridade de certificação não pertencentes à

Microsoft podem conter uma finalidade denominada Todas, que representa todas as
finalidades possíveis. Isso é indicado por uma extensão EKU em branco (ou nula). Embora
Todas possa significar todas as finalidades possíveis, não é possível substituir essa finalidade

Versão: 1.3- Pág. 184 de 377
pela finalidade Autenticação de Cliente, Autenticação de Servidor ou por qualquer outra

relacionada à autenticação de acesso à rede.
Certificados necessários para autenticação
A tabela a seguir descreve os certificados que devem implantar com êxito cada método
de autenticação listado, baseado em certificado:

Versão: 1.3- Pág. 185 de 377
Certificado Necessário para EAP-TLS e PEAP- Necessário para PEAP-MS- Detalhes

TLS? CHAP v2?
Certificado de autoridade de Sim. O certificado de autoridade de Sim. Esse certificado é Para o PEAP-MS-CHAP
certificação no repositório de certificação é registrado automaticamente registrado automaticamente para v2, esse certificado é
certificados de Autoridades de para os computadores membro do os computadores membro do necessário para a
Certificação Raiz Confiáveis para o domínio. Para os computadores não domínio. Para os computadores autenticação mútua entre
Computador Local e o Usuário pertencentes ao domínio, você deve não pertencentes ao domínio, o cliente e o servidor.
Atua importar o certificado manualmente no você deve importar o certificado
repositório de certificados. manualmente no repositório de
certificados.
Certificado de servidor no Sim. Você pode configurar o AD CS para Sim. Além de usar o AD CS para O servidor NPS envia o
repositório de certificados do registrar automaticamente os certificados certificados de servidor, você certificado de servidor
servidor NPS de servidor para os membros do grupo de pode comprar os certificados de para o computador
servidores RAS e IAS no AD DS. servidor em outras autoridades cliente. O computador
de certificação com as quais já cliente usa o certificado
existe uma relação de confiança para autenticar o servidor
com os computadores cliente. NPS.
Certificado de usuário em um O AD CS para registrar automaticamente Não. A autenticação do usuário é Para os protocolos EAP-
cartão inteligente os certificados de servidor para os feita com credenciais baseadas TLS e PEAP-TLS, se
membros do grupo de servidores RAS e em senha, não em certificados. você não registrar
IAS no AD DS. automaticamente os
certificados de
computadores cliente,
serão necessários os
certificados de usuário
em cartões inteligentes

Versão: 1.3- Pág. 186 de 377
A autenticação Institute of Electrical and Electronics Engineers, Inc. (IEEE) 802.1X

fornece acesso autenticado às redes 802.11 sem fio e às redes Ethernet com fio. O padrão
802.1X é compatível com os tipos de EAP seguros, como o TLS com cartões inteligentes ou
certificados. Você pode configurar o 802.1X com o EAP-TLS de várias maneiras.
Se você configurar a opção Validar certificado do servidor no cliente, o cliente

autenticará o servidor usando seu certificado. A autenticação de computadores cliente e de
usuários acontece por meio dos certificados do repositório de certificados ou de um cartão
inteligente, fornecendo autenticação mútua
Com os clientes de rede sem fio, use o PEAP-MS-CHAP v2 como método de

autenticação. PEAP-MS-CHAP v2 é um método de autenticação de usuário, baseado em
senha, que utiliza o TLS com certificados de servidor. Durante a autenticação do PEAP-MS-
CHAP v2, o servidor NPS fornece ao cliente um certificado para validar sua identificação (se
a opção Validar certificado de servidor estiver configurada no cliente Windows 8). A
autenticação de computadores cliente e de usuários é feita com senhas, o que reduz uma
parte da dificuldade da implantação de certificados para os computadores cliente de rede sem
fio.
Implantação de certificados para PEAP e EAP

Todos os certificados que você usa para autenticação do acesso à rede com EAP-TLS
e PEAP devem atender aos requisitos dos certificados X.509 e funcionar para as conexões
que usam SSL/TLS. Após atender a esse requisito mínimo, os certificados de cliente e de
servidor têm outros requisitos.
Requisitos mínimos para certificados de servidor

Você pode configurar clientes para validar certificados do servidor usando a opção
Validar certificado do servidor nas propriedades do protocolo de autenticação. Com o
protocolo PEAP-MS-CHAP v2, PEAP-TLS ou EAP-TLS como método de autenticação, o
cliente aceita a tentativa de autenticação do servidor quando o certificado atende aos
seguintes requisitos:

Janeiro de 2015 - Versão: 1.3- Pág. 187 de 377
 O Nome do requerente contém um valor. Se você emitir um certificado com um

Requerente em branco para seu servidor NPS, o certificado não ficará disponível para
autenticar o servidor NPS.
Para configurar o modelo de certificado com um Nome de entidade:

a. Abra os Modelos de Certificado.
b. No painel de detalhes, clique com o botão direito do mouse no modelo de
certificado a ser alterado e clique em Propriedades.
c. Clique na guia Nome de Requerente e clique em Criar com base nas
informações do Active Directory.
d. Em Formato de nome de requerente, selecione um valor diferente de
Nenhum.
 O certificado de computador no servidor está vinculado a uma autoridade de

certificação raiz confiável e não é reprovado em nenhuma das verificações executadas
pela CryptoAPI, especificadas pelas políticas de rede e acesso remoto.
 O certificado de computador servidor NPS ou VPN é configurado com a finalidade

Autenticação de Servidor nas extensões EKU (o identificador de objeto Autenticação
de Servidor é 1.3.6.1.5.5.7.3.1).
 O certificado de servidor é configurado com um valor de algoritmo obrigatório de RSA.

Para configurar o parâmetro de criptografia obrigatória:
c. Clique na guia Criptografia. Em Nome de algoritmo, clique em RSA. Verifique
se Tamanho mínimo da chave está definido como 2048.
A extensão do Nome Alternativo da Entidade (SubjectAltName), se utilizada, deve

conter o FQDN (nome de domínio totalmente qualificado) do servidor. Para configurar o
modelo de certificado com o nome do DNS (Sistema de Nomes de Domínio) do servidor de
registro:
c. Clique na guia Nome de Requerente e clique em Criar com base nas
d. Em Incluir esta informação no nome de requerente alternativo, selecione
Nome DNS.
Com o PEAP e o EAP-TLS, os servidores NPS exibem uma lista de todos os
certificados instalados no repositório de certificados de computador, com exceção de:
 Certificados que não contêm a finalidade Autenticação de Servidor nas
extensões EKU.
 Certificados que não contêm um nome de entidade.
 Certificados baseados no Registro e em logon de cartões inteligentes.

Requisitos mínimos para certificados de cliente
Com o EAP-TLS ou o PEAP-TLS, o servidor aceita a tentativa de autenticação do

cliente quando o certificado atende aos seguintes requisitos:
 Uma autoridade de certificação corporativa emitiu o certificado de cliente ou ele foi
mapeado para uma conta de usuário ou de computador do Active Directory.
 O certificado de usuário ou de computador no cliente está vinculado a uma autoridade

de certificação raiz confiável; o certificado inclui a finalidade Autenticação de Cliente
nas extensões EKU (o identificador de objeto da Autenticação de Cliente é
1.3.6.1.5.5.7.3.2) e não é reprovado nas verificações executadas pela CryptoAPI,
especificadas pelas políticas de acesso remoto ou de rede, nem nas verificações de
identificador de objeto Certificado especificadas pelas políticas de rede NPS.
 O cliente 802.1X não usa os certificados baseados no registro, que são certificados de
logon por cartão inteligente ou protegidos por senha.
 Para os certificados de usuário, a extensão Nome Alternativo de Entidade

(SubjectAltName) no certificado contém o Nome UPN (Nome Principal do Usuário).
Para configurar o nome UPN em um modelo de certificado:

c. Clique na guia Nome de Entidade e clique em Criar com base nas
d. Em Incluir esta informação no nome de entidade alternativo, selecione
Nome principal do usuário (UPN).
 Para os certificados de computador, a extensão Nome Alternativo de Entidade

(SubjectAltName) no certificado deve conter o FQDN (Nome de Domínio Totalmente
Qualificado) do cliente, também conhecido como nome DNS. Para configurar esse
nome no modelo de certificado:
c. Clique na guia Nome de Entidade e clique em Criar com base nas
d. Em Incluir esta informação no nome de entidade alternativo, selecione
Nome DNS.
Com o PEAP-TLS e o EAP-TLS, os clientes exibem uma lista de todos os certificados

instalados no snap-in de Certificados, com exceção de:
 Clientes de rede sem fio que não exibem os certificados baseados em registro e de
logon por cartões inteligentes.
 Clientes de rede sem fio e de VPN que não exibem os certificados protegidos por
senha.
 Certificados que não contêm a finalidade Autenticação de Cliente nas extensões EKU.

3.11. BACKUP E RECUPERAÇÃO DE DESASTRES

Organizações sempre são vulneráveis a perder alguns ou todos os seus dados, por
razões como exclusão não intencional, sistema de arquivos corrompido, falhas de hardware,
usuários mal-intencionados e desastres naturais. Por isso, as organizações devem ter
estratégias de recuperação bem definidas e testadas que ajudarão a colocar seus servidores
e dados em um estado íntegro e operacional novamente e o mais rápido possível.
Identificar requisitos de recuperação de desastres

Antes de desenvolver uma estratégia de recuperação de desastres, as organizações
devem identificar os requisitos de recuperação de desastres para assegurar que proverão
fornecer proteção apropriada para recursos críticos.
A lista a seguir é uma lista de alto nível de etapas que você pode usar para identificar
requisitos de recuperação de desastres:
1. Defina os recursos críticos da organização. Esses recursos incluem dados, serviços e
os servidores nos quais os dados e os serviços são executados.
2. Identifique os riscos associados a esses recursos críticos. Por exemplo, os dados

podem ser acidentalmente ou intencionalmente excluídos e um disco rígido ou
controlador de armazenamento no qual estão armazenados pode falhar. Além disso,
os serviços que usam dados críticos podem falhar por muitas razões (como problemas
de rede) e os servidores podem falhar por causa de problemas de hardware.
Interrupções de energia importantes também podem causar o desligamento de sites
inteiros.
3. Identifique a hora necessária para executar a recuperação. Com base em seus

requisitos comerciais, as organizações devem decidir quanto tempo é aceitável para
recuperar recursos críticos. Os cenários podem variar de minutos a horas ou até
mesmo um dia.

4. Desenvolva uma estratégia de recuperação. Com base nas etapas anteriores, as

organizações definirão um contrato de nível de serviço que incluirá informações como
níveis de serviço e horas de atendimento. As organizações devem desenvolver uma
estratégia de recuperação de desastres que as ajudará a minimizar os riscos e, ao
mesmo tempo, recuperar seus recursos críticos dentro do tempo mínimo aceitável
para seus requisitos comerciais.
Observação: A organização terá requisitos de recuperação de desastres diferentes

com base nos seus requisitos comerciais. Os requisitos de recuperação de desastres não
devem ser estáticos, mas devem ser avaliados e atualizados regularmente, por exemplo, uma
vez em alguns poucos meses. Também é importante que os administradores testem as
estratégias de recuperação de desastres regularmente. Os testes devem ser executados em
um ambiente não de produção isolado usando uma cópia dos dados de produção.
Visão geral das estratégias de recuperação de desastres de empresa

Ao planejar o backup para sua empresa, você precisa desenvolver estratégias para
recuperar dados, serviços, servidores e sites. Você também precisa fazer provisões para o
backup fora do local.
Estratégias de recuperação de desastres

Os dados constituem a categoria recuperada mais comumente em um ambiente de
empresa. Isso ocorre porque é mais provável que os usuários excluirão arquivos
acidentalmente, do que o hardware de servidor falhar ou que os aplicativos causem corrupção
de dados. Portanto, ao desenvolver uma estratégia de recuperação de desastres empresarial,
leve em conta desastres pequenos, como exclusão de dados, além de desastres grandes,
como falha de servidor ou de site.
Ao considerar estratégias de recuperação de dados, o backup não é a única tecnologia

para recuperação de dados. Você pode abordar muitos cenários de recuperação de arquivo
e pasta implementando versões anteriores de funcionalidade de arquivo em

compartilhamentos de arquivos. Você também pode replicar dados em locais físicos diferentes
ou para uma nuvem pública ou privada.
Estratégias de recuperação de serviço

A funcionalidade da rede depende da disponibilidade de certos serviços de rede
críticos. Embora redes bem projetadas criem redundância em serviços essenciais, como
Sistema de Nomes de Domínio (DAS) e Serviços de Domínio do Active Directory (AD DS), até
mesmo esses serviços podem ter problemas, por exemplo, quando uma falha grande é
replicada e requer uma restauração de backup. Além disso, uma solução de backup
empresarial deve assegurar que serviços como o Protocolo DHCP e Serviços de Certificados
do Active Directory (AD CS) e recursos importantes como compartilhamentos de arquivos
podem ser restaurados de uma maneira oportuna e atualizada.
Estratégias de recuperação completa de servidor

O desenvolvendo de uma estratégia de recuperação completa de servidor envolve
determinar quais servidores você precisa poder recuperar e o RPO (Recovery Point Objective)
e RTO (Recovey Time Objective) para servidores críticos. Suponha que você tem um site com
dois computadores que funcionam como controladores de domínio. Ao desenvolver sua
estratégia de backup, você deve querer que ambos os servidores sejam capazes de
recuperação completa com um RPO de 15 minutos? Alternativamente, só é necessário que
um servidor seja recuperado rapidamente se falhar, pois qualquer servidor poderá fornecer o
mesmo serviço de rede e assegurar a continuidade comercial?
Ao desenvolver o componente de recuperação completa de servidor do plano de

backup empresarial da sua organização, determine quais servidores são necessários para
assegurar a continuidade comercial e garantir que o backup seja realizado regularmente.
Estratégias de recuperação de site

A maioria das organizações maiores têm sites de filial. Embora talvez seja desejável
fazer backup de todos os computadores nesses locais, isso pode não ser economicamente
viável. O desenvolvimento de uma estratégia de recuperação de site envolve determinar quais
dados, serviços e servidores em um site específico devem ser recuperáveis para assegurar a
continuidade comercial.
Estratégias de backup fora do local

Muitas organizações que não armazenam backups fora do local não se recuperam de
um desastre de site primário. Se o site da matriz de sua organização sofrer um incêndio,
estiver sujeito a uma inundação rara, um terremoto ou um tornado, não importará quais
estratégias de backups existem no local se todos esses backups estiverem armazenados no
local que foi destruído pelo desastre.
Uma estratégia de proteção de dados empresarial abrangente envolve mover os dados

de backup para um local fora do site seguro de forma que você possa recuperá-lo, não importa
que tipo de desastre ocorra. Isso não precisa acontecer diariamente. O RPO para recuperação
no local externo (com frequência denominado local de recuperação de desastres) geralmente
é diferente do RPO no local primário.

Estratégias de manutenção de desastres

A tabela a seguir lista alguns dos riscos associadas à perda de dados ou de serviços
e as estratégias de atenuação apropriadas.
Risco de desastre Estratégia de atenuação
A mídia na qual uma cópia dos Tenha duas cópias de seus dados de backup pelo
dados de backup está localizada é menos e valide seus backups regularmente.
corrompida.
Um administrador excluiu uma OU Proteja as OUs contra exclusão acidental,
(unidade organizacional) que especialmente após as migrações
contém muitos objetos de usuário
e computador acidentalmente.
Um servidor de arquivos em uma Use a Replicação DFS para replicar arquivos de filiais
filial onde arquivos importantes para data centers centrais.
estão localizados falhou
A infraestrutura de virtualização na Evite implantar todos os servidores críticos, como
qual os servidores comerciais controladores de domínio, na mesma infraestrutura
estão localizados está virtual.
indisponível.
Evite implantar todos os servidores Implante um data center secundário que conterá
críticos, como controladores de réplicas da maioria dos servidores críticos em seu
domínio, na mesma infraestrutura data center primário.
virtual
O que precisa ser incluído no backup

Ao planejar backups por sua organização, assegure que você proteja recursos que
são críticos, como:
 Recursos críticos
 Verificação de backup
 Segurança de backup
 Requisitos de conformidade e regulatórios

Tipos de backup
No Windows Server 2012, você pode executar os tipos seguintes de backups:
 Backup completo. Um backup completo é uma réplica no nível de bloco de todos os
blocos nos volumes de servidor. Em vez de copiar arquivos e pastas a mídia de
backup, os blocos subjacentes são copiados para a mídia de backup.
 Backup incremental. Um backup incremental é uma cópia apenas dos blocos que
foram alterados desde o último backup completo ou incremental. Durante um backup
incremental, esses blocos são copiados para a mídia de backup. Quando esse
processo é concluído, os blocos são marcados como backup. Durante a recuperação,
o conjunto original de blocos é restaurado. Em seguida, cada conjunto de blocos
incrementais é aplicado, colocando os dados recuperados novamente no estado
apropriado de uma maneira consistente.
Tecnologias de backup
VSS
O VSS—uma tecnologia que a Microsoft incluiu no Windows Server 2003 R2 e que
está presente em todos os sistemas operacionais de servidor mais novos—resolve o problema
de consistência no nível do bloco de disco criando o que é conhecido como uma cópia de
sombra. Uma cópia de sombra é uma coleção de blocos em um volume que é congelado em
um ponto específico no tempo. Ainda podem ser feitas alterações no disco, mas quando um
backup ocorre, a coleção de blocos congelados é incluída no backup, o que significa que
qualquer alteração que possa ter ocorrido desde o congelamento não entra no backup.
A criação de uma cópia de sombra diz ao sistema operacional para primeiro colocar
todos os arquivos, como bancos de dados DHCP e arquivos de banco de dados do Active
Directory, em um estado consistente por um momento. Em seguida, o estado atual do sistema
de arquivos é registrado nesse ponto específico no tempo. Depois que o VSS cria a cópia de
sombra, todos os acessos de gravação que substituiriam dados armazenam os blocos de
dados anteriores primeiro. Portanto, uma cópia de sombra é pequena no início e cresce com
o tempo, à medida que os dados são alterados. Por padrão, o sistema operacional é
configurado para reservar 12% do volume para dados de VSS e o VSS exclui
automaticamente instantâneos mais antigos quando esse limite é alcançado. Você pode
alterar esse valor padrão e pode alterar o local padrão dos dados de VSS. Isso assegura que
o backup tem um instantâneo do sistema em um estado consistente, não importa quanto
tempo na verdade leva para gravar os dados de backup no dispositivo de armazenamento de
backup.
Backup de streaming
O backup de streaming é usado frequentemente por aplicativos mais antigos que não
usam o VSS. Você faz backup de aplicativos sem reconhecimento de VSS usando um método
conhecido como backup de streaming. Em comparação com o VSS onde o sistema
operacional assegura que os dados sejam mantidos em um estado consistente em um ponto
no tempo atual, quando você usa o backup de streaming, o aplicativo ou o aplicativo de

proteção de dados é responsável por assegurar que os dados permaneçam em um estado

consistente. Além disso, após a conclusão do backup de streaming, alguns arquivos têm o
estado que tinham no início do backup, enquanto outros arquivos têm o estado de término da
janela de backup.
Requisitos de backup completo

Para calcular o espaço necessário para um backup completo, determine de quanto
espaço de todos os volumes você precisará para o backup. Se o servidor tiver uma unidade
dedicada para backups, você não executará um backup nessa unidade.
Com produtos que executam backups baseados em imagem, como o Backup do
Windows Server, esses dados não são compactados. Em alguns tipos de servidores,
especialmente servidores de arquivos, a quantidade de espaço necessária para um backup
completo cresce com o passar do tempo. Você pode reduzir essa tendência usando políticas
de expiração de arquivo como as localizadas no Gerenciador de Recursos de Servidor de
Arquivos (FSRM).
Requisitos de backup incremental

Um backup incremental no Backup do Windows Server armazena todos os blocos do
disco rígido que foram alterados desde o último backup completo ou incremental. Backups
incrementais são substancialmente mais rápidos do que backups completos e requerem
menos espaço. A desvantagem de backups incrementais é que eles podem exigir mais tempo
de recuperação.
O tempo necessário para o backup

A quantidade de tempo necessário para gravar dados do servidor cujo backup está
sendo realizado no dispositivo de armazenamento de backup pode ter um impacto no RPO
projetado, pois não era recomendado começar uma nova operação de backup antes da
conclusão da atual.
Frequência de backup
A Frequência de backup é uma medida da frequência de com que os backups são
realizados. Com backups de nível de bloco incrementais, nenhuma diferença significativa
existirá entre a quantidade de dados gravada durante a soma de quatro sessões de 30
minutos e uma sessão incremental de 2 horas no mesmo servidor. Isso ocorre porque durante
as duas horas, o mesmo número de blocos terá sido alterado no servidor que nas quatro
sessões de 30 minutos. Porém, as quatro sessões de 30 minutos o dividiram em partes
menores. Quando backups ocorrem com maior frequência, eles reduzem o tempo necessário
para executar o backup dividindo-o em partes menores. O total geral será o mesmo.
Retenção de backup

Ao tentar determinar a capacidade de com que necessária, você deve determinar

precisamente quanto tempo precisa reter os dados de backup. Por exemplo, se você precisar
ser capaz de recuperar a qualquer ponto de backup nos últimos 28 dias e se tiver pontos de
recuperação gerados a cada hora, precisará de mais espaço que se tiver pontos de
recuperação gerados uma vez por dia e somente terá que restaurar dados dos últimos 14
dias.
Backup do Windows Server
O recurso de Backup do Windows Server no Windows Server 2012 consiste em um

snap-in de Console de Gerenciamento Microsoft (MMC), no comando wbadmin e em
comandos do Windows PowerShell. Você pode usar assistentes no recurso de Backup do
Windows Server para orientá-lo durante a execução de backups e operações de recuperação.
Você pode usar o Backup do Windows Server para fazer backup do seguinte:
 Servidor completo (todos os volumes).
 Volumes selecionados.
 Selecione itens específicos para backup, como pastas específicas ou o estado do

sistema.
Além disso, o Backup do Windows Server 2012 permite:

 Executar uma restauração bare-metal. Um backup bare-metal contém pelo menos

os volumes críticos e permite restaurar sem instalar um sistema operacional primeiro.
Você faz isso usando a mídia do produto em um DVD ou a chave USB e o Ambiente
de Recuperação do Windows (Windows RE). Você pode usar esse tipo de backup
junto com o Windows RE para se recuperar de uma falha de disco rígido ou se tiver
que recuperar a imagem de computador inteira em um novo hardware.
 Usar o estado do sistema. O backup contém todas as informações para reverter um

servidor a um ponto específico no tempo. Porém, você precisa de um sistema
operacional instalado antes de recuperar o estado do sistema.
 Recuperar arquivos e pastas individuais ou volumes. A opção Arquivos e pastas

individuais permite a você optar por fazer backup de e restaurar arquivos específicos,
pastas ou volumes ou você pode adicionar arquivos específicos, pastas ou volumes
ao backup quando usar uma opção como volume crítico ou estado do sistema.
 Excluir os arquivos ou tipos de arquivos selecionados. Por exemplo, você pode excluir
arquivos temporários do backup.
 Selecionar de mais locais de armazenamento. Você pode armazenar backups em

compartilhamentos remotos ou volumes não dedicados.
 Usar o Windows Azure Online Backup. O Windows Azure Backup Online é uma
solução de backup baseada na nuvem para Windows Server 2012 que permite que
arquivos e pastas sejam incluídos no backup e recuperados da nuvem pública ou
privada para fornecer backup fora do local.
Se houver desastres, como falhas de disco rígido, você poderá executar a recuperação
do sistema usando um backup completo de servidor e Windows RE; isso restaurará seu
sistema completo no novo disco rígido.
Windows Azure Online Backup

O Windows Azure Backup Online é uma solução de backup baseada na nuvem para
Windows Server 2012 que é gerenciada pela Microsoft. Você pode usar este serviço de
assinatura para fornecer proteção fora do local contra perda de dados causada por desastres.
Você faz backup de arquivos e pastas e os recupera, conforme necessário, da nuvem pública
ou privada. Você pode usar o Windows Azure Backup Online para fazer backup e proteger
dados críticos de qualquer local.
O Windows Azure Backup Online foi criado com base na plataforma Windows Azure e
usa o blob storage do Windows Azure para armazenar dados de cliente. O Windows Server
2012 usa o Windows Azure Online Backup Agent para transferir dados de arquivo e pasta
com segurança para o Windows Azure Online Backup. Depois que você instalar o Windows
Azure Online Backup Agent, o agente integrará sua funcionalidade por meio da interface de
Backup do Windows Server. Você pode baixar o Windows Azure Online Backup Agent do site
da Microsoft.

Data Protection Manager
Data Protection Manager (DPM) é um produto de proteção para dados empresariais e

recuperação do Microsoft System Center. O DPM tem os seguintes recursos:
 Centralização de backup. O DPM usa uma arquitetura cliente/servidor, na qual o

software cliente é instalado em todos os computadores que serão incluídos no backup.
Esses clientes transmitem dados de backup ao servidor DPM. Isso permite que cada
servidor DPM ofereça suporte a organizações de pequeno a médio porte. Você
também pode gerenciar vários servidores DPM de um console de DPM centralizado.
 RPO de 15 minutos. O DPM permite instantâneos de 15 minutos de produtos com

suporte. Isso inclui a maioria dos conjuntos de produtos empresariais da Microsoft,
incluindo Windows Server com suas funções e serviços, Exchange Server, Hyper-V e
Microsoft SQL Server.
 Oferece suporte para cargas de trabalho da Microsoft. O DPM foi criado

especificamente pela Microsoft para oferecer suporte a aplicativos Microsoft como o
Exchange Server, o SQL Server e o Hyper-V. Porém, o DPM não foi criado
especificamente para oferecer suporte a aplicativos de servidor não Microsoft que não
têm estados consistentes em disco ou sem suporte para VSS.
 Backup baseado em disco. O DPM pode executar backups agendados em matrizes

de disco e redes de área de armazenamento (SANs). Você também pode configurar o

DPM para exportar dados de backup específicos em fita para retenção e tarefas
relacionadas à conformidade.
 Backup de local remoto. O DPM usa uma arquitetura que permite a realização de
backup de clientes localizados em locais remotos. Isso significa que um servidor DPM
localizado em uma matriz pode executar backups de servidores e clientes localizados
em links de rede de longa distância (WAN).
 Oferece suporte para estratégias de backup na nuvem. O DPM oferece suporte ao

backup de servidores DPM em uma plataforma de nuvem. Isso significa que um
servidor DPM em uma instalação de hospedagem baseada na nuvem pode ser usado
para fazer backup do conteúdo de um servidor DPM da matriz. Para redundância de
desastre, você também pode configurar servidores DPM para fazer backup um do
outro.
Opções de recuperação de servidor

O Backup do Windows Server no Windows Server 2012 oferece as opções de
recuperação seguintes:
 Arquivos e pastas: Você pode fazer backup de arquivos ou pastas individuais,
contanto que o backup esteja em um volume separado ou em uma pasta
compartilhada remota.
 Aplicativos e dados. Você poderá recuperar aplicativos e dados se o aplicativo tiver

um gravador de VSS e estiver registrado no Backup do Windows Server.
 Volumes. A restauração de um volume sempre restaura todo o conteúdo do volume.

Quando você opta por restaurar um volume, não pode restaurar arquivos ou pastas
individuais.

 Sistema operacional. Você pode recuperar o sistema operacional por meio de

Windows RE, o DVD do produto ou uma unidade flash USB.
 Servidor completo. Você pode recuperar o servidor completo por meio de Windows
RE.
 Estado do sistema. O estado do sistema cria um backup pontual que você pode usar
para restaurar um servidor a um estado operacional anterior.
O Assistente de Recuperação no Backup do Windows Server fornece várias opções

para gerenciar a recuperação de arquivos e pastas. São elas:
 Destino de Recuperação. Em Destino de Recuperação, você pode selecionar uma

das seguintes opções:
o Local original. O local original restaura os dados ao local para o qual o backup
foi criado originalmente.
o Outro local. Outro local restaura os dados em um local diferente.
 Resolução de Conflito. A restauração de dados de um backup frequentemente

apresenta conflito com as versões existentes dos dados. A resolução de conflito
permite determinar como tratar esses conflitos. Quando esses conflitos ocorrem, você
tem as seguintes opções:
o Criar cópias e reter ambas as versões.
o Substituir a versão existente pela versão recuperada.
o Não recupere itens se eles já existirem no local de recuperação.
 Configurações de segurança. Use esta opção para restaurar permissões aos dados
que estão sendo recuperados.
Opções de restauração de servidor
Quando você executar a restauração de servidor completa, considere o seguinte:

 Restauração bare-metal. A restauração bare-metal é o processo durante o qual você
restaura um servidor existente em sua totalidade para novo hardware ou o hardware
de substituição. Quando você executar uma restauração bare-metal, a restauração
continuará e o servidor será reiniciado. Posteriormente, o servidor ficará operacional.
Em alguns casos, talvez seja necessário reiniciar a conta do Active Directory do
computador, porque essas contas às vezes podem se tornar dessincronizadas.
 Unidades de disco iguais ou maiores. O hardware de servidor para o qual você está
restaurando deve ter unidades de disco do mesmo tamanho ou maiores que as
unidades do servidor host original. Se esse não for o caso, a restauração falhará. É

possível, embora não aconselhável, restaurar com êxito em hosts que têm
processadores mais lentos e menos memória RAM.
 Importação para o Hyper-V. Como os dados de backup do servidor são gravados no

formato VHD (que também é o formato usado para os discos rígidos da máquina
virtual), se você for cuidadoso, será possível usar dados de backup de servidor
completo como a base para a criação de uma máquina virtual. Isso assegura a
continuidade comercial durante a transferência do o hardware de substituição
apropriado.
Opções de recuperação de dados

Os dados são o componente recuperado com mais frequência de uma infraestrutura
de TI. Isso se deve à exclusão de dados acidental pelos usuários e a necessidade de
recuperá-los. Há várias estratégias que você pode adotar ao desenvolver um procedimento
de recuperação de dados. Você pode:
 Permitir que os usuários recuperem seus próprios dados.
 Executar uma recuperação para um local alternativo.
 Executar uma recuperação para o local original.
 Executar uma recuperação de volume completo.
Restauração com o Windows Azure Online Backup
Você pode usar o Windows Azure Online Backup para fazer backup de servidores do
Windows Server 2012. Porém, você não tem que restaurar dados no mesmo servidor do qual
fez backup.
Você pode recuperar arquivos e pastas usando o MMC do Windows Azure Online
Backup no Gerenciador do Servidor ou a interface de linha de comando do Windows
PowerShell. Para usar o MMC do Windows Azure Online Backup, execute as etapas
seguintes:
1. Selecione o servidor no qual os dados de backup foram criados originalmente. Esse

servidor pode ser um servidor local ou outro servidor. Se você selecionar a opção de
outro servidor, deverá fornecer suas credenciais de administrador do Windows Azure
Online Backup.
2. Procure os arquivos que têm que ser restaurados ou você pode procurá-los no
Windows Azure Online Backup.
3. Depois que você localizar os arquivos, selecione-os para recuperação e selecione um

local onde os arquivos serão restaurados.
4. Ao restaurar arquivos, selecione um das seguintes opções:

o Crie cópias de forma que você tenha o arquivo restaurado e arquivo original no
mesmo local. O arquivo restaurado tem seu nome no formato seguinte: Data
de Recuperação+Cópia de+Nome do arquivo original.
o Substitua as versões existentes pela versão recuperada.
o Não recupere os itens que já existirem no destino de recuperação.

Depois que você concluir o procedimento de restauração, os arquivos serão
restaurados no servidor do Windows Server 2012 no seu local.


4. MÓDULO 11 - SEGURANÇA EM AMBIENTES MICROSOFT
4.1. FIREWALL AVANÇADO
O Windows Firewall with Advanced Security (Firewall do Windows com Segurança

Avançada) é uma ferramenta utilizada para melhorar a segurança do Windows Server 2012
Este snap-in ajuda a prevenir vários problemas de segurança diferentes, tais como
escaneamento de portas ou malware.
É um firewall baseado em host que está incluído no Windows Server 2012. Este snap-
in é executado no computador local e restringe o acesso à rede e de que o computador
Ao contrário de um firewall de perímetro, que oferece proteção apenas contra as

ameaças da Internet, um firewall baseado em host oferece proteção contra ameaças que
possam vir de fora ou dentro da rede.
Regras de entrada e saída
Regras de entrada são iniciadas por outro dispositivo ou computador na rede, com o
computador host. Por padrão, todas as comunicações de entrada são bloqueados, exceto o
tráfico que é explicitamente permitido por uma regra de entrada.
Regras de saída que são iniciados pelo computador próprio computador para outro,
ou seja, e é destinado a um dispositivo ou um computador na rede. Por padrão, toda a
comunicação de saída é permitida, exceto o tráfego que é explicitamente bloqueado por uma
regra de saída. Se você optar por bloquear toda a comunicação de saída, exceto o tráfego
que é explicitamente permitido, é necessário verificar as necessidades dos sistemas ou
softwares que executam no computador a fim de não impedir o seu funcionamento normal
(portas e protocolos utilizados).
Você pode criar regras de entrada e saída com base em portas User Datagram
Protocol (UDP) e Transmission Control Protocol (TCP). Você também pode criar regras de
entrada e saída para um executável específico, independentemente da porta que está ele usa.
Connection Security Rules

São utilizadas para configurar o Internet Protocol Security (IPSec) para Windows
Server 2012. Quando essas regras são configuradas, você pode autenticar a comunicação
entre computadores, e, em seguida, usar essa informação para criar regras de firewall
baseados em contas de usuário de computador específico.
Perfis de Firewall
Windows Firewall with Advanced Security (Firewall do Windows com Segurança

Avançada) usa perfis de firewall para fornecer uma configuração consistente para redes de
um tipo específico. O Windows Server 2012 permite que você defina uma rede como em
domínio de rede, uma rede pública, ou uma rede privada.
Você pode definir um conjunto de configurações para cada um destes três tipos de
rede, cada conjunto de configurações se refere como um perfil de firewall. As regras de firewall
são ativados somente para perfis de firewall específicos. Por exemplo, se você estiver
conectado a uma rede que foi definida como “rede privada”, as configurações de firewall
relacionadas à “rede privada” entrarão em vigor.
Perfil Descrição
Public Use quando você está conectado a uma rede pública não confiável.
(Público) Diferentemente das redes de domínio, todas as redes são classificados
como Público. Por padrão, o perfil de público (mais restritivo) é usado no
Windows Vista, Windows 7 e Windows 8.
Private Use quando você está conectado atrás de um firewall. A rede é

(Particular) classificado como privado somente se um administrador ou um aplicativo
identifica a rede como privado. Este perfil é conhecido como o perfil de
rede doméstica no Windows Vista, Windows 7 e Windows 8.
Domain Use quando o computador é parte de um domínio do Active Directory.

(Domínio) Sistemas operacionais Windows identificam automaticamente as redes
em que se pode autenticar o acesso ao controlador de domínio. Este perfil
é conhecido como o perfil de trabalho do Windows Vista, Windows 7 e
Windows 8.
Regras de conexão de segurança
A Connection Security Rules (regra de conexão de segurança) força a autenticação

entre dois computadores antes que eles possam estabelecer uma conexão e transmissão.
Elas também garantem o tráfego através da criptografia dos dados que são transmitidos entre
computadores. Para isso é utilizado o IPsec.

 Manual. Você pode configurar individualmente regras de firewall em cada servidor. No

entanto, num ambiente com mais servidores, pode ser trabalhoso e propenso a erro.
Este método é normalmente utilizado apenas durante testes e troubleshooting
(resolução de problemas).
 Usando Group Policy (diretivas de grupo). A melhor maneira para distribuir as

regras de firewall é usando as Diretiva de Grupo. Depois de criar e testar um GPO
com as regras de firewall necessárias, você pode rapidamente implantar as regras de
firewall para um grande número de computadores.
 Exportar e importar regras de firewall. Você pode exportar as regras de firewall para
criar um backup antes de configurar manualmente as regras de firewall durante a
resolução de problemas. Ao importar regras de firewall, eles são tratados como um
conjunto completo e substituem todas as regras de firewall atualmente configurados.


4.2. CRIPTOGRAFIA E CERTIFICADO DIGITAL
Criptografia de arquivos usando EFS

EFS é um componente interno do sistema de arquivos NTFS que permite a criptografia
e a descriptografia do arquivo e do conteúdo da pasta em um volume NTFS. É importante
compreender como o EFS funciona antes de implementar o EFS no ambiente. Você também
deve saber como recuperar os arquivos criptografados e resolver problemas quando a
criptografia EFS não funciona corretamente.
O que é o EFS?
EFS é um recurso que pode criptografar arquivos armazenados em uma partição
formatada com NTFS. Por padrão, essa opção está disponível para todos os usuários.
Também é possível usar o EFS para criptografar arquivos em um compartilhamento de
arquivos.
Depois que um arquivo é criptografado usando EFS, ele só pode ser acessado por
usuários autorizados. Se um usuário estiver autorizado, o acesso ao arquivo será transparente
e poderá ser aberto como um arquivo não criptografado. Se um usuário não estiver autorizado,
as tentativas em abrir o arquivo resultarão em uma mensagem de acesso negado.
A criptografia EFS age como uma camada adicional de segurança além de permissões
NTFS. Se os usuários tiverem permissão NTFS para ler um arquivo, ainda assim eles estarão
autorizados pelo EFS para descriptografar o arquivo.
A configuração padrão de EFS não requer nenhum esforço administrativo. Os usuários
podem começar a criptografar os arquivos imediatamente e o EFS gerará um certificado de
usuário automaticamente com um par de chaves para um usuário se não houver. Usar uma
CA (autoridade de certificação) para emitir certificados de usuário aprimora o gerenciamento
dos certificados.
Você pode desabilitar o EFS em computadores cliente usando a Política de Grupo.
Nas Propriedades da política, navegue até Configuração do

Computador\Políticas\Configurações do Windows\Configurações de Segurança\Políticas de

Chave Pública\Sistema de Arquivos de Criptografia e clique em Não permitir
Observação: Se não estiver usando certificados de uma CA e quiser permitir que o

EFS seja usado em um compartilhamento de arquivos, você deverá configurar a conta do
computador do servidor de arquivos para ser confiável para delegação. Os controladores de
domínio são confiáveis para delegação por padrão.
Como o EFS funciona

O EFS usa uma combinação de chave pública e criptografia de chave simétrica para
proteger arquivos do ataque. O EFS usa uma chave simétrica para criptografar o arquivo e
uma chave pública para proteger a chave simétrica.
A criptografia de chave simétrica usa a mesma chave para criptografar e

descriptografar um arquivo. Esse tipo de criptografia é mais rápido e mais seguro do que a
criptografia de chave pública. Como é difícil proteger a chave simétrica durante uma
transferência entre redes, ela exige segurança adicional. A criptografia de chave simétrica é
o método comum de criptografia de grandes quantidades de dados.
O EFS usa a criptografia de chave pública para proteger a chave simétrica, que é
necessária para descriptografar o conteúdo dos arquivos. Cada certificado de usuário contém
uma chave privada e uma chave pública que é usada para criptografar a chave simétrica.
Somente o usuário com o certificado e sua chave privada pode descriptografar a chave
simétrica.
O processo de criptografia de arquivos é o seguinte:

1. Quando um usuário criptografa um arquivo, o EFS gera uma FEK (File Encryption Key
[chave de criptografia de arquivos]) para criptografar os dados. A FEK é criptografada
com a chave pública do usuário, e é então armazenada com o arquivo. Isso assegura
que apenas o usuário com a chave privada de criptografia EFS correspondente seja
capaz de descriptografar o arquivo. Depois que um usuário criptografa um arquivo,
este permanece criptografado pelo tempo em que estiver armazenado no disco.
2. Para descriptografar arquivos, o usuário pode abrir o arquivo, remover o atributo de

criptografia ou descriptografar o arquivo usando o comando de criptografia. Quando
isso ocorre, o EFS descriptografa a FEK com a chave privada do usuário e, em
seguida, descriptografa os dados usando a FEK.
Observação: Além do usuário que criptografou o arquivo, cópias adicionais da chave

simétrica são criptografadas com a chave pública do agente de recuperação e estão
disponíveis para qualquer outro usuário autorizado.

Recuperação de arquivos criptografados por EFS

Se um usuário que criptografou um arquivo usando o EFS perder a chave privada por
qualquer motivo, você precisará de um método para recuperar o arquivo criptografado com
EFS. A chave privada faz parte de um certificado de usuário que é usado para criptografia.
Fazer backup de um certificado de usuário é um método para recuperar arquivos com
criptografia EFS. O certificado de usuário de backup pode ser importado em outro perfil e é
possível usá-lo para descriptografar o arquivo. Porém, este método é difícil de implementar
quando há muitos usuários.
Um método melhor para recuperar arquivos criptografados com EFS é usar um agente
de recuperação. Um agente de recuperação é um indivíduo que está autorizado a
descriptografar todos os arquivos com criptografia EFS. O agente de recuperação padrão é o
administrador do domínio. Porém, é possível delegar a função do agente de recuperação a
qualquer usuário.
Quando você adiciona um novo agente de recuperação por meio da Política de Grupo,
o agente é adicionado automaticamente a todos os arquivos recém-criptografados, mas o
agente não é adicionado automaticamente aos arquivos criptografados existentes. Como o
agente de recuperação para um arquivo é definido no momento em que o arquivo é
criptografado, um arquivo criptografado deve ser acessado e salvo para atualizar o agente de
recuperação.
Para fazer backup do certificado do agente de recuperação, você deve sempre
exportar o certificado com a chave privada e mantê-la em um local seguro. Os dois motivos
para fazer backup da chave privada do agente de recuperação (ou a chave de recuperação)
são:
 Para proteger contra falhas do sistema. A chave de administrador de domínio que é

usada por padrão para a recuperação EFS é armazenada apenas no primeiro
controlador de domínio do domínio. Se algo tivesse acontecido nesse controlador de
domínio, a recuperação EFS seria impossível.
 Tornar a chave de recuperação móvel. A chave de recuperação não está

automaticamente disponível para o agente em todos os computadores. Ela deve ser
instalada no perfil do agente de recuperação.
Se não são usados perfis móveis, a exportação e a importação da chave é um método
para atualizar o perfil do agente de recuperação em um computador em particular.

4.3. SECURITY POLICY
Configurando Templates de Segurança

Os modelos de segurança são arquivos que você pode usar para gerenciar e
configurar as definições de segurança em computadores baseados no Windows. Dependendo
das várias categorias de configurações de segurança, modelos de segurança são divididos
em seções lógicas. Você pode configurar cada uma das seguintes seções de acordo com as
necessidades e solicitações de uma empresa:
 Account Policies (Diretivas de conta). Políticas de senhas, bloqueio e Kerberos.

 Local Policies (Diretivas locais). Políticas de auditoria, direitos de usuários e opções
de segurança.
 Event Log (Logs de evento). Configurações de logs de aplicação, sistema e
segurança.
 Restricted Groups (Grupos restritos). Configuração de membros de grupos que tem
direitos e permissões especiais.
 System Services (Serviços de sistema). Permissões de inicialização e serviços de
Sistema.
 Registry (Registro). Permissões para chaves de registro.
 File System (Sistema de arquivos). Permissões para pastas e arquivos.
Quando você configura um modelo de segurança, você pode usá-lo para configurar
um único computador ou vários computadores na rede. Veja algumas maneiras que você pode
configurar e distribuir os modelos de segurança:
 Secedit.exe. A linha de comando secedit.exe configura e analisa a segurança do
sistema, comparando a configuração atual de um computador com o Windows Server
2012 para modelos de segurança especificados.
 Security Templates snap-in. É um snap-in que você pode usar para criar uma política
de segurança usando modelos de segurança.
 Security Configuration and Analysis Wizard. Este assistente é uma ferramenta que
você pode usar para analisar e configurar a segurança do computador.
 Group Policy. Diretiva de Grupo é uma tecnologia que você pode usar para analisar
e definir as configurações do computador, incluindo a distribuição de configurações de
segurança específicas.
 Security Compliance Manager. O Security Compliance Manager é uma ferramenta

que oferece recursos de gerenciamento de base de segurança centralizados e
funcionalidade de exportação da linha de base de segurança.

Configuring User Rights

Atribuição de direitos do usuário refere-se à capacidade de executar ações no sistema
operacional. Cada computador tem seu próprio conjunto de direitos do usuário, como o direito
de alterar a hora do sistema. A maioria dos direitos são concedidos para a conta Local System
ou ao Administrator.
Privilégios e direitos de logon são divididos em dois tipos:

 Privilégios definem o acesso aos recursos do computador e domínio. Por exemplo, os
direitos para fazer backup de arquivos e diretórios.
 Direitos de logon definem quem está autorizado a fazer logon em um computador, e

como eles podem fazer logon. Por exemplo, os direitos de logon pode definir o direito
de fazer logon em um sistema localmente.
Você pode configurar direitos por meio da Diretiva de Grupo. Inicialmente, a diretiva
de domínio padrão não tem direitos definidos pelo usuário.
Você pode configurar as definições para direitos de usuário, acessando Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights
Assignment from the Group Policy Management Console (GPMC).
Alguns exemplos de direitos de usuário:

 Adicionar computador no domínio. Determina quais usuários ou grupos podem
adicionar estações de trabalho ao domínio.

 Permitir logar localmente. Determina quais usuários podem fazer logon no

computador.
 Permitir logar por Remote Desktop Services. Determina quais usuários ou grupos
têm permissão para fazer logon remotamente.
 Fazer backup de arquivos de diretórios. Determina quais usuários têm permissão

para fazer backup de arquivos e pastas em um computador.
 Alterar hora do sistema. Determina quais usuários ou grupos têm o direito de alterar
a data e hora no relógio interno do computador.
 Forçar desligamento do sistema remotamente. Determina quais usuários têm

permissão para desligar um computador de um local remoto na rede.
 Desligar o sistema. Determina quais usuários que estão conectados localmente em

um computador são autorizados a desliga-lo.
Configurando opções de segurança

Você também pode usar a Diretiva de Grupo para acessar e configurar as opções de
segurança. As configurações de segurança do computador que você pode configurar em
Opções de segurança incluem o seguinte:
 Nomes das contas Administrator e Guest
 Acesso a drives de CD/DVD
 Assinaturas de dados digitais
 Comportamento instalação do driver Logon prompts
 Controle de contas de usuário
Você também pode definir as configurações de opções de segurança, acessando o

seguinte local do GPMC:
Computer Configuration\Policies\Windows Settings\Security Settings\Local
Policies\Security Options. The following are examples of commonly used Security Options:
 Avisar o usuário para alterar a senha antes que ela expire: Determina quantos dias
antes da senha do usuário expirar que o sistema operacional fornece um aviso.
 Logon interativo: Não exibe o último nome do usuário. Determina se o nome do último
usuário a fazer logon no computador exibe na janela de logon do Windows.
 Accounts: Renomear conta de administrador. Determina se um nome de conta

diferente estará associado com o identificador de segurança (SID) para o
Administrador da conta.
 Dispositivos: Restringe o acesso ao CD-ROM apenas localmente usuário conectado.

Determina se um CD-ROM é acessível para os usuários locais e remotos em
simultâneo.

4.4. WSUS
Windows Server melhora a segurança aplicando atualizações de segurança aos
servidores na hora certa. Ele fornece a infraestrutura para baixar, testar e aprovar as
atualizações de segurança. A aplicação de atualizações de segurança de forma rápida ajuda
a evitar incidentes de segurança que resultam de vulnerabilidades conhecidas. Durante a
implementação do WSUS, você deve se lembrar dos requisitos de hardware e software do
WSUS, das configurações a serem definidas e das atualizações a serem aprovadas ou
removidas de acordo com as necessidades da organização.
A função WSUS fornece um ponto de gerenciamento central para atualizações para

computadores com o sistema operacional Windows. Usando o WSUS, é possível criar um
ambiente de atualização mais eficiente na organização e estar mais bem informado sobre o
status da atualização geral dos componentes na rede. Esta lição apresenta o WSUS e
descreve os principais recursos da função de servidor WSUS.
Definição do WSUS
O WSUS é uma função de servidor incluída no sistema operacional Windows Server
2012 que baixa e distribui atualizações a clientes e servidores Windows. O WSUS pode obter
atualizações aplicáveis ao sistema operacional e a aplicativos comuns da Microsoft como
Microsoft Office e Microsoft SQL Server.
Na configuração mais simples, uma organização pequena pode ter um único servidor
do WSUS que baixa atualizações do Microsoft Update. O servidor do WSUS então distribui
as atualizações a computadores que estão configurados para obter atualizações automáticas
desse servidor. Você deve aprovar as atualizações para que os clientes possam baixá-las.
As organizações maiores podem criar uma hierarquia de servidores do WSUS. Nesse

cenário, um único servidor do WSUS centralizado obtém atualizações do Microsoft Update, e
outros servidores do WSUS obtêm atualizações do servidor do WSUS centralizado.
É possível organizar os computadores em grupos para simplificar a aprovação das

atualizações. Por exemplo, é possível configurar um grupo piloto como o primeiro conjunto de
computadores que são usados para testar atualizações.
O WSUS pode gerar relatórios para ajudar no monitoramento da instalação de

atualizações. Esses relatórios podem identificar os computadores que não aplicaram as
atualizações aprovadas recentemente. Com base nesses relatórios, é possível investigar por
que as atualizações não estão sendo aplicadas.

Requisitos de servidor do WSUS

É possível usar o Gerenciador do Servidor para instalar e configurar a função de
servidor WSUS. No entanto, para poder implementar o WSUS, o servidor deve atender a
alguns requisitos mínimos de hardware e software.
O software necessário para o WSUS 3.0 SP2 inclui:

 Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 Service Pack
1 (SP1) ou mais recente, Windows Server 2003 SP1 ou mais recente, Windows Small
Business Server 2008 ou Windows Small Business Server 2003
 IIS (Serviços de Informações da Internet) 6.0 ou mais recente
 Microsoft .NET Framework 2.0 ou mais recente
 MMC (Console de Gerenciamento Microsoft) 3.0
 Microsoft Report Viewer Redistributable 2008 ou mais recente
 SQL Server 2012, SQL Server 2008, SQL Server 2005 SP2 ou Banco de Dados Interno
do Windows.
Os requisitos mínimos de hardware para o WSUS são quase iguais aos requisitos
mínimos de hardware para os sistemas operacionais do Windows Server. No entanto, é
preciso considerar o espaço em disco como parte de sua implantação. Um servidor do WSUS
exige cerca de 10 GB de espaço em disco e você deve alocar pelo menos 30 GB de espaço
em disco para as atualizações baixadas.
Um único servidor do WSUS pode oferecer suporte a milhares de clientes. Por

exemplo, um único servidor do WSUS com 4 GB de RAM e CPUs duplas com núcleo

quádruplo podem oferecer suporte a até 100.000 clientes. No entanto, na maioria das vezes,
uma organização com tantos clientes assim provavelmente terá vários servidores do WSUS
para reduzir a carga nos links WAN (rede de longa distância).
Configuração das Atualizações Automáticas

Quando você habilita o recurso Atualizações Automáticas em um servidor, a
configuração padrão baixa automaticamente as atualizações do Microsoft Update e as instala.
Depois que o WSUS é implementado, os clientes devem ser configurados para obter as
atualizações automaticamente do servidor do WSUS.
O local do qual as Atualizações Automáticas obtêm as atualizações é controlado por

uma chave do Registro. Embora seja possível configurar manualmente a chave do Registro
usando a ferramenta RegEdit, isso não é recomendável, exceto quando o computador estiver
fora de um domínio. Se um computador estiver em um domínio, será muito mais eficiente criar
um GPO (Objeto de Política de Grupo) que configure a chave do Registro.
Para ambientes do AD DS (Serviços de Domínio Active Directory), as Atualizações

Automáticas costumam ser configuradas em um GPO definindo as configurações localizadas
em Configuração do Computador. Para localizar as configurações, expanda Políticas,
Modelos Administrativos, Componentes do Windows e localizar o nó Atualizações do
Windows.
Além de configurar a fonte das atualizações, você também pode usar um GPO para
definir as seguintes configurações:
 Frequência de atualização. Essa configuração determina com que frequência as

atualizações são detectadas.
 Programação da instalação de atualizações. Essa configuração determina quando

as atualizações são instaladas. Essa configuração também determina para quando as
atualizações estão reagendadas, quando as atualizações não podem ser instaladas
na hora agendada.
 Comportamento de reinicialização automática. Essa configuração determina se o

computador será reiniciado automaticamente se exigido por uma atualização.
 Grupo de computadores padrão no WSUS. Essa configuração determina o grupo

de computadores no qual o computador será registrado durante o registro inicial no
WSUS.
Administração do WSUS
O console de administração do WSUS é um snap-in MMC que é possível usar para
administrar o WSUS. Use essas ferramenta para:

 Identificar e baixar atualizações.

 Aprovar atualizações para implantação.
 Organizar computadores em grupos.
 Revisar o status de atualização de computadores.
 Gerar relatórios.
Controle atualizações em computadores clientes

Os computadores clientes realizam atualizações de acordo a configuração manual ou,
na maioria dos ambientes do AD DS, a Política de Grupo. Em alguns casos, convém iniciar o
processo de atualização fora da agenda de atualização normal. É possível usar a ferramenta
wuauclt.exe para controlar o comportamento de atualização automática em computadores
clientes do Windows Update. O comando a seguir inicia a detecção das Atualizações da
Microsoft na origem do Windows Update.
Wuauclt.exe /detectnow
Grupos de computadores
Grupos de computadores são uma maneira de organizar os computadores nos quais
um servidor do WSUS implanta atualizações. Os dois grupos de computadores que existem
por padrão são Todos os Computadores e Computadores Não Atribuídos. Novos
computadores que contatam o servidor do WSUS são atribuídos automaticamente aos dois
grupos.

É possível criar grupos de computadores personalizados para controlar como as

atualizações serão aplicadas. Normalmente, os grupos de computadores personalizados
contêm computadores com características semelhantes. Por exemplo, você pode criar um
grupo de computadores personalizados para cada departamento da sua organização.
Também é possível criar um grupo de computadores personalizados para um laboratório no
qual você implanta as atualizações para teste. Você normalmente agruparia servidores
separados de computadores clientes.
O processo de atribuir novos computadores manualmente a um grupo de

computadores personalizados é chamado de direcionamento no lado do servidor. Você
também pode usar o direcionamento no lado do cliente para atribuir computadores a um grupo
de computadores personalizados. Para usar o direcionamento no lado do cliente, você precisa
configurar uma chave do Registro ou um GPO para o computador que especifica o grupo de
computadores personalizados a serem unidos durante o registro inicial no servidor do WSUS.
O processo de atribuir novos computadores manualmente a um grupo de

computadores personalizados é chamado de direcionamento no lado do servidor. Você
também pode usar o direcionamento no lado do cliente para atribuir computadores a um grupo
de computadores personalizados. Para usar o direcionamento no lado do cliente, você precisa
configurar uma chave do Registro ou um GPO para o computador que especifica o grupo de
computadores personalizados a serem unidos durante o registro inicial no servidor do WSUS.
Aprovação de atualizações
A configuração padrão do WSUS não aprova automaticamente as atualizações de
aplicativos nos computadores. Embora seja possível aprovar as atualizações
automaticamente, isso não é recomendável. O processo recomendado para aprovar
atualizações é primeiro testar as atualizações em um ambiente de laboratório, depois em um
grupo piloto e somente depois no ambiente de produção. Esse processo reduz o risco de uma
atualização gerar um problema inesperado no ambiente de produção. Execute esse processo
aprovando atualizações para grupos específicos de computadores antes de aprová-las para
o grupo Todos os Computadores.
Algumas atualizações não são consideradas críticas e não têm implicações na

segurança. Talvez você não queira implementar algumas dessas atualizações. Se for esse o
caso, você pode recusar a atualização. Depois que uma atualização é recusada, ela é
removida da lista de atualizações na exibição padrão do servidor do WSUS.
Se você aplicar uma atualização e achar que ela está causando problemas, será
possível usar o WSUS para removê-la. No entanto, a atualização só poderá ser removida se
ela oferecer suporte à remoção. A maioria delas permite a remoção.
Observando os detalhes de uma atualização, você saberá se ela foi substituída por
outra. As atualizações substituídas geralmente não são mais necessárias, pois uma mais nova
incluirá as alterações dessa atualização e muito mais. As atualização substituídas não são
recusadas por padrão, pois em alguns casos, elas ainda são necessárias. Por exemplo, a

atualização mais antiga pode ser necessária se alguns servidores não estiverem executando
o service pack mais recente.

5. MÓDULO 12 - SERVIDORES LINUX

5.1. KERNEL E DISTRIBUIÇÕES LINUX
Distribuições Linux
Quando o Linus Torvalds desenvolveu o primeiro Linux, em agosto de 1991, o sistema
operacional era essencialmente constituído de seu Kernel e algumas ferramentas GNU. Com
a ajuda de outros, Torvalds adicionou mais e mais ferramentas e aplicações.
Com o tempo, estudantes universitários e companhias começaram a distribuir o Linux

com suas próprias escolhas de pacotes que iriam acompanhar o Kernel. Foi então que o
conceito de distribuição nasceu. Ou seja, cada distribuição definia o conjunto de pacotes e o
foco que o sistema operacional teria.
Assim, tornou-se possível classificar as distribuições, ou apenas “distros”, em:
 System V: Conforme dito anteriormente, seu principal foco são as corporações.

Exemplos de distribuições baseadas no System V são: Red Hat, Suse e outras.
 BSD: Distribuições geralmente usadas em universidades. Para usuários que gostam

de “aprender fazendo”, ou seja, pesquisadores. Exemplos incluem: Slackware, Debian
e outras.
 Live in CD: Usadas a partir de um CD. Geralmente usadas em sistemas de resgate.

São exemplos: Knoppix e Ubuntu.
 Desktop: Distribuições focadas para os usuários domésticos sem muito tempo ou

paciência para aprender. São exemplos: Mandrake e Conectiva. Estas distribuições
se fundiram gerando a Mandriva.
 Segurança: O principal foco destas distribuições é a segurança do sistema. Um

exemplo de distribuição com este foco é o OpenBSD.

Atualmente, criar e vender distribuições Linux são um negócio muito lucrativo. Você
pode comprar versões em caixas de companhias como Suse, Red Hat, Mandrake e outras
tantas. Você pode ainda, fazer o download do Linux.
NOTA: Não é possível realizar uma comparação para definir qual distribuição é melhor
e qual é pior. Cada uma delas prioriza um aspecto. Assim, a escolha da distribuição deve levar
em conta o propósito da instalação, ou seja, qual será a funcionalidade da máquina onde será
instalado o Linux
Existem distribuições de todos os tipos e para, praticamente, qualquer arquitetura de

computadores.
Abaixo veremos a descrição de algumas das distribuições Linux mais populares

atualmente.
1. Ubuntu Linux: O Ubuntu Linux é um sistema operacional Linux para desktop

completo, disponível de graça e com suporte à comunidade e profissional. A
comunidade Ubuntu é construída em ideias protegidas no manifesto Ubuntu: que o
software deve ser disponibilizado sem custo, que as ferramentas de software devem
ser usadas pelas pessoas em sua língua local e que estas pessoas tenham a liberdade
de personalizar e alterar os seus softwares da maneira que lhes melhor servir. A
palavra “Ubuntu” é uma palavra africana antiga, que significa “humanidade para os
outros”.
2. SuSE Linux: O SuSE Linux é uma Distribuição de cunho Corporativo. Originalmente

derivada da Distribuição Slackeare, foi adquirido pela Empresa Novell em novembro
de 2003.
3. Mandriva Linux: Formalmente conhecido como Mandrakelinux, foi criado em 1988

com o objetivo de fazer o Linux mais fácil de ser usado por todos. Neste tempo, o Linux
já era bem conhecido como um sistema operacional poderoso e estável que
demandava fortes conhecimentos técnicos e uso extensivo da linha de comando. A
MandrakeSoft viu nisto uma oportunidade para integrar os melhores ambientes
gráficos e contribuir com o seu próprio utilitário gráfico de configuração, rapidamente
tornando-se assim, famoso por definir um padrão no fácil uso e funcionalidade. Com
esta abordagem, o Mandriva Linux oferece todo o poder e estabilidade do Linux tanto
para os usuários individuais quanto para os usuários profissionais, em um ambiente
agradável e de fácil uso.
4. Fedora Project: O projeto Fedora é um projeto desenvolvido abertamente pela Red

Hat, aberto para participação geral, liderado pela maioria e seguindo um conjunto de
objetivos de projetos. O principal objetivo do projeto é trabalhar com a comunidade
Linux para construir um sistema operacional completo e de propósito geral,
exclusivamente com softwares open source.

5. Debian GNU/Linux: O projeto Linux é uma associação de indivíduos que definiram

uma causa comum para criar um sistema operacional livre. Este sistema operacional
é chamado de Debian GNU/Linux, ou simplesmente Debian. Os sistemas Debian
atualmente usam o Kernel Linux. O Debian possui mais de 8000 pacotes, todos livres.
6. CENTOS: O CentOS é uma Distribuição Linux baseada nas fontes do Red Hat
Enterprise Linux (RHEL), livremente disponibilizados sob licenciamento GPL. Cada
versão do CentOS é suportada por um período de 7 anos (atualizações de segurança),
sendo um novo release disponibilizado a cada 2 anos (atualizado a cada seis meses,
aproximadamente). O CentOS possui como foco principal o seu uso em Servidores,
sendo considerado uma Distribuição muito segura, confiável e com baixa manutenção,
muito utilizado no meio Corporativo, e com boa parte das características do Red Hat,
(excetuando-se os seus Serviços).
7. Gentoo Linux: O Gentoo é uma distribuição livre de Linux versátil e rápida, guiada
por desenvolvedores e profissionais de redes. Ao contrário de outras distribuições, o
Gentoo possui um sistema de gerenciador de pacotes avançados, chamado Portage.
O Portage é um sistema portado do tradicional BSD, entretanto é baseado na
linguagem Python e suporta uma grande quantidade de características, incluindo
dependências, falsas instalações, perfis de sistemas e muitos outros.
8. The Slackware Linux Project: A versão oficial do Slackware Linux, por Patrick
Volkerding, é um sistema operacional avançado, desenvolvido com dois propósitos
principais de fácil uso e estabilidade. Uma grande variedade de ferramentas de
desenvolvimento, editor e bibliotecas estão incluídas para os usuários que desejam
desenvolver ou compilar softwares adicionais no Slackware.
Além destas distribuições Linux citadas acima, abaixo serão mostradas os três “BSDx
Flavors”: Seus principais focos são, respectivamente: Servidores, segurança e porte de
sistemas.
9. FreeBSD: O FreeBSD é um sistema operacional Unix-Like para plataformas i386, IA-

64, PC-64, PC-98, Alpha/AXP e UltraSPARC baseadas na versão 4.4BSD-Lite com
algumas melhorias da versão 4.4BSD-Lite2, da Universidade de Berkeley. Ele também
e baseado indiretamente no porte da Universidade para o Net/2 para i386, realizado
por William Jolitz. O FreeBSD é usado por companhias, provedores de serviço de
Internet, pesquisadores, profissionais da computação, estudantes e usuários
domésticos por todo o mundo.
10. OpenBSD: O projeto OpenBSD produziu um sistema operacional livre, multi-

plataforma baseado no 4.4BSD Unix-like. O esforço deste projeto é enfatizar a
portabilidade, padronização, correção, segurança pró-ativa e criptografia integrada. O
OpenBSD possui a emulação de binário para a maioria dos programas do SVR4
(Solaris), FreeBSD, Linux, BSD/OS, SunOS e HP-UX.
11. NetBSD: O NetBSD é um porte do sistema operacional open source Unix-Like livre e
seguro para muitas plataformas, desde AlphaServer 64-bit até sistemas desktops para

dispositivos embarcados. Seu projeto limpo e funcionalidades avançadas fizeram dele

um excelente ambiente de produção e pesquisa. Muitas aplicações estão disponíveis
facilmente através da coleção de pacotes NetBSD.
Convém ressaltar aqui que a família Unix BSD, compreendem uma outra categoria de
sistemas operacionais OpenSource, com licenciamento, objetivos e funcionalidades
diferentes do Linux. Sistemas “BSD” privilegiam o uso em Servidores e costumam exigir
pesadas configurações para uso em desktop.

Kernel
Entendendo o Kernel
O Kernel de um sistema operacional é entendido como o seu núcleo ou coração do
sistema operacional. Ele representa o nível mais baixo de troca de mensagens com o
Hardware, sendo responsável por todo o gerenciamento dos recursos do sistema operacional.
No Kernel estão definidas as formas de operação com todos os periféricos, gerenciamento de
memória, interrupções e outros.
Podemos dizer, de forma simples e direta, que o Kernel é um conjunto de aplicações

necessárias para fornecer a outro conjunto de aplicações, utilizadas pelos usuários, uma
forma de utilizar os recursos do sistema. Diferentemente de outros sistemas operativos (ex.:
Windows), no Linux, apenas parte dos drivers estão carregados em memória. A grande
maioria pode ser carregada dinamicamente quando necessário. Por este comportamento
“modular” do sistema, é que costumamos nos referir aos” módulos de dispositivo”, ao invés
do termo “drivers”, mais usual.
Versão Numérica do Kernel

O Kernel do Linux possui um número de versão numérica (ex.: “2.6.15”), sendo esse
número, constituído por uma série de campos, cada qual com um significado próprio:

ONDE:
a) VERSION: Número principal (raramente muda);
b) PATCH LEVEL: Indica mudanças importantes no funcionamento do kernel do Linux.
Se ímpar, indica um kernel experimental, se par, então é um kernel considerado
estável (“de produção”).
c) SUBLEVEL: Sua evolução indica o suporte a novos dispositivos, bem como correção
de bugs e pequenos melhoramentos no sistema.
d) EXTRA VERSION: Usado quando desejamos diferenciar duas compilações de um
kernel de mesma versão, a fim de constituírem dois diretórios de módulos separados.
Como mostrado acima, a série de Kernel que possui o número do “Patch Level”, par,
é considerada um “Kernel de produção” assim, as séries 2.0.X, 2.2.X, 2.4.X e 2.6.X são
consideradas, séries de Kernel estáveis. Os números ímpares representam as séries de
desenvolvimento.
Por um longo período, enquanto o Kernel 2.4 era a série estável, o Kernel 2.5 estava
sendo desenvolvido de forma a avançar para a atual série estável 2.6.
Para sabermos qual Kernel estamos utilizando em nossa máquina, podemos utilizar o
comando abaixo.
uname –r
Módulos do Kernel
No Linux os drivers, doravante aqui chamados módulos, ficam em um diretório, de
mesma versão numérica do kernel e situados em “/lib/modules”. Estes módulos fornecem o
suporte ao hardware e a todos os demais dispositivos (ex.: sistemas de arquivos), que devem
ser manipulados pelo sistema operativo, sendo construídos junto com o kernel. Assim, por
exemplo, caso existam as versão numéricas de kernel compiladas no sistema “2.6.20”, e
2.6.21” existirão dois diretórios de mesma versão em /lib/modules
O diretório de módulos de cada versão numérica de kernel contém várias pastas e

arquivos, sendo os módulos de suporte a dispositivos, existentes a partir do caminho
“/lib/modules/versão_do_kernel/kernel/drivers”, conforme podemos observar no quadro
abaixo:

Abaixo do diretório acima referido os módulos são divididos e organizados em pastas,

de acordo com o tipo de dispositivo a que se destinam. Por exemplo, abaixo listamos a
localização e o conteúdo da pasta “net”, que contém os módulos que dão suporte às interfaces
de rede suportadas nesta versão de kernel:
Quando compilamos um novo kernel, também precisamos compilar os seus módulos

e, instalá-los abaixo de “/lib/modules”. Uma versão de kernel, não pode utilizar os módulos de
outra versão, ou vice-versa, portanto, devem existir tantos diretórios de módulos, quantas
forem as versões de kernel que forem compiladas.
Gerenciamento de módulos do Kernel

Um aspecto importante, em se tratando de sistemas modulares, como é o caso do
LINUX, é o gerenciamento dos módulos, que fazem a interface do Sistema Operacional com
os dispositivos. Para o gerenciamento dos módulos, existe uma série de ferramentas, que
passaremos a estudar abaixo:
O comando lsmod
O comando lsmod, lista os módulos do kernel que estão atualmente carregados na
memória e, portanto, fornecendo suporte a algum tipo de dispositivo. Abaixo, um fragmento
da saída deste comando:

Conforme podemos verificar acima, a saída deste comando é em formato de tabela.

Existe um total de 5 campos nesta tabela, os quais passamos a listar abaixo:
Coluna 1: Nome do módulo

Coluna 2: Tamanho em Kbytes do módulo
Coluna 3: Indica se existe algum dispositivo utilizando o módulo
Coluna 4: O número de módulos que dependem deste módulo (dependências)
Comando modprobe
O Comando modprobe, possui uma série de funções úteis no sistema. É um comando
multifuncional que permite diversas funções, dependendo de suas opções de comando:
 Comando: modprobe “modulo” (carrega o módulo e suas dependências).
Exemplo: modprobe 8139too (carrega o módulo da interface de rede Realtek 8139).
 Comando: modprobe –r “modulo” (remove o módulo da memória, caso o mesmo não

esteja em uso).
Exemplo: modprobe –r 8139too (remove o módulo da interface de Rede 8139)
 Comando: modprobe –l –t “tipo” (lista todos os módulos existentes, de um certo tipo

de dispositivo).
Exemplo: modprobe –l –t net (lista os módulos de todas as interfaces de rede
suportadas nesta versão de kernel).
Comando modinfo
O comando modinfo, permite obter informações variadas dos módulos. Seguem
abaixo, alguns exemplos:
 Comando: modinfo –a “modulo” (obtém o autor e responsável, por um módulo).

Exemplo: modinfo –a 8139too (obtém o autor do módulo 8139too).
 Comando: modinfo –p “modulo” (obtém os parâmetros disponíveis para um módulo).

Exemplo: modinfo –p 8139too (obtém os parâmetros disponíveis para o módulo
8139too).
 Comando: modinfo: -d “modulo” (exibe a descrição de um módulo).

Exemplo: modinfo –d 8139too (exibe a descrição do módulo 8139too).
Comando rmmod
O comando rmmod, permite remover um módulo da memória, porém ao contrário do
“modprobe”, este comando apenas remove o módulo, sem cuidar de suas
dependências:
 Comando: rmmod “modulo”
Comando insmod
O comando insmod, permite carregar um módulo da memória, porém ao contrário do
“modprobe”, este comando apenas carrega o módulo, sem cuidar de suas dependências:
 Comando: insmod “modulo
Comando depmod
O comando depmod, verifica as dependências de um módulo, e cria o arquivo
modules.dep, que lista as dependências dos módulos. Este arquivo fica na raiz do diretório
dos módulos (isto é, em “/lib/modules/versão do kernel”). Sempre que adicionarmos um novo
módulo ao kernel, devemos recriar este arquivo, usando para isto o comando abaixo:
Comando: depmod –a
Compilando um Novo Kernel

O fato de sempre podermos dispor das fontes permite que, a qualquer momento,
possamos compilar um novo kernel para o nosso sistema.
Embora, seja sempre mais aconselhável utilizar o kernel oficial, fornecido pela própria
distribuição utilizada, existem algumas situações onde a compilação de um novo kernel
poderá ser uma opção interessante. São elas:

Ação Efeito Causado

Compilar o kernel para um processador
Aumento de desempenho geral do sistema.
específico.
Torna o kernel menor e sua carga um
Diminuir o número de módulos compilados.
pouco mais rápida.
Permite suportar dispositivos mais atuais,
Compilar uma versão mais nova do kernel.
não existentes no kernel utilizado.
Compilar uma versão mais nova do kernel. Permite corrigir algum “bug” encontrado.
Permite retirar dispositivos não necessários
Retirar módulos não necessários.
ou indesejados (ex.: pendrives).
Motivações para se recompilar o kernel do Linux

Repetimos que, sempre que possível, o ideal é permanecer com o kernel original da
Distribuição, o qual já foi intensivamente testado. Ademais, a maioria das distribuições Linux,
adiciona “Patches”, os quais incorporam funcionalidades adicionais, inexistentes no kernel
original do Linux (“Vanilla”).
Pré-requisitos
O processo de compilação do kernel varia bastante, conforme Distribuição utilizada.
Sendo assim, tudo o que for discutido, a partir deste ponto é valido apenas para a Distro
CentOs (e, obviamente, para as Distribuições RedHat e Fedora também), devendo ser
reconsiderado, no caso de outras Distribuições.
Para configurarmos um novo Kernel, obviamente precisamos possuir as suas fontes

instaladas. Existem várias formas para obtermos as fontes do Kernel.
Uma delas é fazer o download do site http://www.kernel.org onde são lançadas as

versões originais do Kernel, também conhecidas como versões Vanilla.
Pacotes de Desenvolvimento
Além das fontes do Kernel (baixado do kernel.org), precisamos ainda dos seguintes
abaixo:
 Pacote Desenvolvimento em C: Contém as ferramentas para a compilação (make,
automake e GCC);
 Pacote “ncurses-devel” (necessário para a interface de configuração do “menuconfig”)
 Pacote “bison” (ferramenta para fazer “parse” de strings)
 Pacote “rpm-build” (permite “empacotar” o kernel compilado)

Dependendo do tipo de instalação que foi feito (ex.: completa, mínima, etc), estes
pacotes poderão ou não se encontrar instalados. Para verificar se já se encontram instalados
e para instalar algum pacote, caso seja necessário, utilize, respectivamente, os comandos
abaixo:
rpm -qa | grep pacote
yum install gcc make bison ncurses-devel rpm-build
Onde:
Pacote: É o nome do pacote, a ser pesquisado/instalado
Conforme referido anteriormente, a compilação do Kernel tende a variar bastante,

conforme a Distribuição utilizada. No caso específico da Distribuição CentOs 6.2, essa
compilação é irealizada, conforme os passos abaixo indicados:
Procedimentos Genéricos
A compilação do kernel no CentOs, envolve os seguintes procedimentos abaixo:
Passo 1: Instalar as dependências:
yum install gcc make bison ncurses-devel rpm-build
Passo 2: Fazer o download dos fontes do kernel ("Vanilla"):

wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.tar.gz
Passo 3: Ir para o diretório dos fontes do kernel:

cd /usr/src
Passo 4: Descompactar os fontes do kernel:

tar xzvf linux-2.6.39.tar.gz
Passo 5: Criar o link simbólico de nome "linux", apontando para o kernel

descompactado:
ln -s linux-2.6.39 linux
Passo 6: Entrar no diretório das fontes do kernel. Todos os procedimentos de

compilação devem ser executados dentro deste diretório:
cd /usr/src/linux
Passo 7: Copiar o arquivo de configuração do kernel, para o diretório de compilação

("/usr/src/linux")::
cp /boot/config-`uname -r` ./.config

Passo 8: A seguir precisamos efetuar a configuração do suporte aos dispositivos que

será fornecido ao usuário, pelo kernel a ser compilado. Esta configuração pode ser feita
através de três modos diferentes, abaixo referidos:
make menuconfig
Na figura abaixo, podemos observar a tela inicial da interface do “menuconfig”:
Este é o método mais utilizado para a configuração do kernel do Linux, e o que será
adotado aqui. Cada opção corresponde a um módulo de kernel a ser compilado. Estas opções
permitem ao usuário, três possíveis decisões:
 Opção marcada com um “(X)”: Neste caso o módulo será criado dentro do próprio
kernel (“builtin”). Desta forma, o módulo será carregado automaticamente no boot,
junto com o próprio kernel.
 Opção marcada com um “(M)”: Neste caso o módulo será criado separado do kernel,
podendo ser carregado após o boot via comando ‘”modprobe” ou, durante boot, via
arquivo “initrd”.
 Opção marcada com um “( )”: Neste caso o driver não será compilado não estando,
portanto, disponível nem no kernel, nem como módulo.

Na tabela a seguir são referenciadas as opções existentes no menu principal de

configuração do kernel:
Abaixo é descrito o que contém cada um dos grupos principais:
Opção Descrição
Aqui é encontrado um grande conjunto de

opções que não poderiam ter sido
General Setup colocadas em nenhum outro grupo. Tais
como suporte à memória “swap”, “initrd” e
“pae”, entre outros.
Enable loadable module Configura se o kernel será construído com

Support suporte a módulos, ou não.
Importante para alguns filesystems, como

ext3 e dispositivos SCSI. O “block layer,
Enable block layer introduz um mecanismo de checksum por
setor de disco, para verificação e proteção
contra erros.
Permite otimizar o kernel para o

processador utilizado, assim como habilitar
opções relacionadas ao processador como
Processor type and features emulação de ponto flutuante e outros,
suporte à mais de 4 GB de RAM e
processamento simétrico (SMTP), entre
outros...

Aqui ficam descritas as opções de

Power management options gerenciamento de energia, como APM e
APIC.
Suporte a barramentos como, PCI,

Bus options
PCMCIA, ISA e HOTPLUG, entre outros.
Executable file formats Suporte a arquivos ELF e a.out
Protocolos de comunicação, TCP/IP, Apple

Networking TAlk, “QoS” (controle de banda) e Iptables
(firewall).
Drivers de dispositivo, como interfaces de

rede ethernet, serial ata (sata), dispositivos
Device Drivers
raid, placas de som e de vídeo, entre
outros.
Suporte ao “sysfs”, bem como a

Firmware Drivers “frameworks” para criação de drivers por
ferramentas de terceiros (ex.: DELL DKMS)
Sistemas de arquivos como ext2, ext3, vfat,

File systems
ntfs, etc.
Usada quase que apenas por

desenvolvedores, permite configurar
Kernel hacking mensagens de debug de várias estruturas
do kernel, latências de mensagens, entre
outras.
Opções de segurança, como suporte ao

Security options
SELinux e AppArmor.
Suporte a algoritmos de criptografia, como

Cryptographic API
DES, HMAC e SHA1.
Habilita o suporte ao “KVM” (kernel

Virtualization
virtualization machine).
Habilita o suporte a funções utilizadas, por

exemplo, por bibliotecas de uso geral no
Library Routines
sistema como a biblioteca de compressão
“ZILB”.
Existem muitas opções dentro dos itens acima listados. É recomendado que você leia
com atenção cada um deles. Se um item não tiver o nome auto-explicativo, você sempre
poderá usar a ajuda para ele, encontrada na parte de baixo da janela de configuração.
Após escolher todas as opções necessárias, você deve salvar suas opções,
abandonar o “menuconfig” e compilar o Kernel propriamente dito.

Passo 9: Após sair salvando do menu de configuração do kernel, compilar com o

comando abaixo:
make ou
make -jn (onde “n”=número de núcleos do processador)
Passo 10: Instale os módulos do kernel novo: compilado:

make modules_install
Passo 11: Copiar o kernel novo e demais arquivos, para o diretório "/boot":
cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.39
cp .config /boot/config-2.6.39
cp System.map /boot/System.map-2.6.39
Passo 12: Criar agora o arquivo initramfs, para o kernel recém compilado (sistema de
arquivos Raiz temporário:
dracut /boot/initramfs-2.6.39 2.6.39
Passo 13: Editar o arquivo /boot/grub/menu.lst, adicionando uma nova entrada para
o kernel novo compilado, afim de que este se torne disponível no menu de inicialização do
grub, durante o boot (pode ser preciso ajustar de acordo com o sistema):
vim /boot/grub/menu.lst
title CentOS (2.6.39)
root (hd0,2)
kernel /boot/vmlinuz-2.6.39 ro root=UUID=efc89d92-5324-4d74-93b4-411ede462387
rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=br-abnt2 LANG=pt_BR.UTF-8 rd_NO_MD quiet
SYSFONT=latarcyrheb-sun16 rhgb crashkernel=128M rd_NO_LVM rd_NO_DM
initrd /boot/initramfs-2.6.39
Passo 14: Finalmente, salve e abandone o "menu.lst" e reinicie o computador.

Durante o reboot, deverá aparecer listada, a nova imagem adicionada, com o kernel recém
compilado.
Procedimentos após o boot

Após o boot execute o comando abaixo, para verificar se o kernel em execução é o
kernel novo, adicionado ao arquivo menu.lst:
Comando: uname -r

A seguir, reinicie novamente o sistema, escolhendo após, o kernel original do CentOs.
Observação:
Pode ser preciso que se refaçam as dependências do kernel default. Isto será
confirmado, caso, após o reboot, não estejam disponíveis os módulos das interfaces de rede.
Para isso, execute (caso seja preciso) o comando abaixo e, uma vez mais, reinicie o sistema:
depmod -a

5.2. INSTALAÇÃO E CONFIGURAÇÃO INICIAL
Requisitos de Hardware
Ao contrário de alguns outros sistemas operacionais, o Linux possui uma instalação

mínima que necessita de muito pouco dos recursos de hardware.
Por este motivo, é possível instalarmos o Linux em máquinas com baixo poder
computacional ou até mesmo aquelas máquinas mais antigas.
Originalmente, o Linux foi desenvolvido para ser instalado em processadores 80386

com apenas 4MB de memória. Obviamente que devido ao rápido avanço da tecnologia,
muitas características agregadas ao Linux se utilizam do poder computacional proporcionado
pelo avanço tecnológico.
Por exemplo, se quisermos usar o sistema básico do Linux, apenas como servidor de
impressão, iremos necessitar de um hardware mínimo completamente diferente ao necessário
para instalarmos uma estação de trabalho para usarmos gráfico e vídeo. Ou seja, em outras
palavras, os requisitos mínimos irão variar de acordo com a utilização do sistema operacional.
O espaço em disco rígido é outro ponto bom no Linux. Por ser um sistema dividido em
pacotes, podemos escolher somente aqueles que iremos utilizar. Desta maneira podemos
economizar muito espaço e assim seremos capazes de instalar o sistema em discos rígidos
com capacidades máximas de 500MB, por exemplo.

De forma geral, o Linux oferece suporte a praticamente todos os tipos de hardwares

antigos. Da mesma maneira, ele também possui compatibilidade com os equipamentos de
ponta, ou seja, com os dispositivos de hardware mais novos.
Os requisitos de hardware são aproximadamente os mesmo para qualquer Distribuição

Linux que venha a ser utilizada:
 Processador:
 Intel: Pentium 4 ou Xeon.
 AMD: Duron, Athlon, Athlon XP, Athlon MP, Athlon 64, Sempron ou Opteron.
 Memória RAM: Mínimo de 512MB (1GB recomendado).
 Disco Rígido: 500MB para a instalação mínima do sistema básico. 2.5GB
recomendado para a instalação do sistema padrão.
 Placa de vídeo e som: Possui suporte a grande maioria das placas atuais.
Lista de Compatibilidade de Hardware

Devida à sua vasta comunidade, o Linux possui compatibilidade para a grande maioria
de dispositivos de hardware que podemos encontrar no mercado atualmente.
É bem verdade que quando o dispositivo é muito especializado, a compatibilidade com

o Linux pode ser mais difícil, ou seja, é necessário tempo para que a comunidade desenvolva
os drivers necessários para que o dispositivo funcione no Linux, ou então, esperar que o
próprio fabricante disponibilize isso. O Linux possui compatibilidade com diversas marcas de
placas de vídeo, som, processadores, discos rígidos, placas de captura, memórias e muito
mais.
Gerenciamento de Discos no Linux

Durante a instalação do Linux, é necessário particionar o disco rígido, ou seja, dividir
em ele em vários pedaços menores. A figura 1 abaixo ilustra a parte de particionamento de
disco do CentOs:

De modo geral, para sistemas desktops, é recomendável se criar 3 partições distintas
Opção Descrição
/ Sistema de Arquivos raiz (onde é instalado o SO)
/home Os diretórios home de cada usuário cadastrado no didtema
swap Partição de troca (memória virtual)

5.3. SHELL LINUX E SSH
Conceitos de SSH
O SSH (Secure Shell) é um protocolo usado para realizar logins remotos e outros
serviços de rede, de forma segura.
Este protocolo foi desenvolvido para ser utilizado no topo da camada de transporte
SSH e dos protocolos de autenticação de usuários.
Ele provê sessões de login interativas, execução de comandos remotamente,
conexões de encaminhamento TCP/IP e encaminhamento de conexões X11.
A camada de transporte SSH, a qual é utilizada pelas aplicações seguras, define um
protocolo de transporte seguro, como já foi dito.
Este protocolo provê uma criptografia muito forte, autenticação de host através de
chaves criptografadas e proteção de integridade.
A autenticação deste protocolo é feita baseada nos hosts, ou seja, ele não realiza a
autenticação dos usuários. Um protocolo de alto nível pode ser usado para providenciar a
autenticação dos usuários. Protocolo o qual, será utilizado sobre o SSH.
O protocolo SSH foi desenvolvido para ser simples e flexível, permitindo parâmetros
de negociação e minimizando o número de round-trips .
Os métodos de troca de chaves, algoritmo de chave pública, algoritmo simétrico de
encriptação, algoritmo de autenticação de mensagem e algoritmo hash são todos negociados.
É esperado que, na maioria dos ambientes, apenas dois round-trips sejam
necessários para realizar a troca de chaves, autenticação de servidor, requisição de serviço
e notificação de aceitação do serviço requisitado. Na pior das hipóteses, podem acontecer
três round-trips . Entenda-se por round-trip o caminho de ida e volta percorrido, ou seja, o
caminho entre o host de origem e o host de destino.

O OpenSSH
O OpenSSH é uma versão do conjunto de ferramentas de conectividade de rede que
utilizam o protocolo SSH. Os usuários e novos adeptos de tais ferramentas estão em
constante crescimento na Internet.
Muitos usuários de programas como telnet, rlogin e ftp podem não perceber que suas
senhas estão sendo transmitidas através da Internet sem utilizar criptografia, mas na verdade
estão.
O OpenSSH criptografa todo o tráfego (incluindo senhas) para eliminar o risco de

alguém capturar os dados em texto puro, efetuar ataques de man-in-the-middle ou outros
ataques realizados e conhecidos na Internet.
Adicionalmente, o OpenSSH providencia uma forma segura de realizar tunelamentos,

assim como uma grande quantidade de métodos de autenticação.
O conjunto do OpenSSH inclui programas como:
 O ssh: que substitui o rlogin e o telnet.
 O scp: que substitui o rcp.
 O sftp: que substitui o ftp.
Além destes programas usados pelos clientes, ele também provê o sshd, que é o
servidor e outros utilitários básicos como o ssh-add, ssh-agent, ssh-keysign, ssh-keyscan,
ssh-keygen e o servidor sftp-server.
O OpenSSH suporta as versões 1.3, 1.5 e 2.0 do protocolo SSH.


5.4. PRINCIPAIS COMANDOS
Comandos Básicos
O Linux possui uma ampla infinidade de comandos que podem ser utilizados. É
possível administrar o sistema inteiro somente através destes comandos disponibilizados no
modo texto.
Veremos aqui os comandos mais básicos para a utilização do sistema operacional.
ls
O comando ls é utilizado para listar o conteúdo dos diretórios do sistema operacional.
Ou seja, este comando lista os arquivos contidos no diretório alvo. Sua sintaxe é a
seguinte:
ls [opção] [arquivo]
As seguintes opções são válidas para este comando:

Opção Descrição
-a Não esconde arquivos que comecem com ponto (.), ou seja, mostra
todos os arquivos.
--color Exibe arquivos com cores para distinguir os tipos de cada um deles.
-d Exibe os diretórios em vez de seu conteúdo e não segue os links
simbólicos.
--full-time Exibe o conteúdo com a hora completa.
-l Mostra os arquivos no formato de lista longa.
-g A mesma coisa que o –l, entretanto não mostra o dono do arquivo.
-h Exibe tamanho dos arquivos em formato de leitura humana.
-r Lista os arquivos na ordem reversa.
-R Mostra, recursivamente, todos os subdiretórios.

-s Mostra o tamanho de cada arquivo em blocos.

-S Ordena por ordem de tamanho.
-t Lista os arquivos por ordem de modificação.
-v Lista os arquivos por ordem de versão.
-w cols Define que a largura da coluna terá o tamanho cols.
-X Lista os arquivos por ordem alfabética.
-1 Lista um arquivo por linha.
As cores do comando ls
Normalmente, ao executarmos o comando “ls” este apresenta uma saída colorida.
Alguns arquivos são listados com uma cor, outros com outras. As cores do comando “ls”,
servem para indicar o tipo de arquivo com que estamos lidando. Observe a tabela abaixo:
Cor Significado
Branco/Preto Arquivo Texto.
Azul Forte Diretório.
Azul Claro Link (“Atalho”).
Verde Permissão de Execução Ativada.
Amarelo Arquivo de Dispositivo.
Roxo Socket.
Laranja Arquivo Compactado (“zipado”), ou pacote de software.
Vermelho Permissão Especial Ativada (“Suid”).
cd
Este comando é usado para mudar o diretório de trabalho atual.
O comando cd muda o diretório de trabalho do ambiente de execução atual.
Sua sintaxe é a seguinte:
cd [directory]
Onde o parâmetro directory é o nome do diretório para o qual se deseja mudar.

Caso este parâmetro não seja informado, o comando irá mudar o diretório corrente
para o diretório principal do usuário, ou seja, para o diretório “home” dele, que é onde ficam
armazenados seus arquivos.
pwd
O comando pwd mostra o diretório corrente em que o usuário se encontra. Este
comando é muito útil para podermos identificar o lugar do sistema operacional que estamos
trabalhando.
Sua sintaxe é simples, como abaixo:
pwd
mv

Este comando é utilizado para movermos arquivos de um lugar para outro, e também
para renomearmos arquivos.
A sintaxe para este comando, se utilizarmos sua funcionalidade de renomear será:
mv [option] nome_original nome_final
O comando acima irá renomear o arquivo do parâmetro nome_original para
nome_final.
A sintaxe utilizada quando vamos mover um arquivo de um lugar para outro será:
mv [option] arquivo diretório_destino
As opções que podem ser utilizadas nos dois casos são as seguintes:
Opção Descrição
-f Não pergunta antes de sobrescrever arquivos existentes.
--replay={yes, no, query} Especifica como lidar com o prompt sobre um arquivo
existente.
-u Move apenas quando o arquivo de origem for mais recente
que o destino ou quando o arquivo não existe no destino.
-v Modo verbose, ou seja, mostra tudo o que está sendo feito.
-i Modo interativo, sempre pergunta antes de sobrescrever.
cp
O comando cp é utilizado para copiar arquivos e diretórios. Sua sintaxe é a seguinte:
cp [options] origem destino
Onde o parâmetro origem pode ser um arquivo ou diretório que será copiado para
destino. As opções para esse comando são as seguintes:
Opção Descrição
-f Se o destino não puder ser aberto, remove-o e tenta novamente.
-i Modo interativo, pergunta o que fazer caso necessite sobrescrever.
-H Segue os links simbólicos na linha de comando.
-l Cria link para os arquivos ao invés de copiá-los.
-R Copia os arquivos recursivamente.
-s Cria links simbólicos ao invés de copiar os arquivos.
-u Apenas cópia se a origem for mais nova que o destino.
-v Mostra tudo o que está sendo feito pelo comando.
rm
Este comando é utilizado para remover arquivos e diretório. Por padrão ele não é
capaz de remover diretórios, apenas arquivos. Para remover diretório é necessário passar um
determinado parâmetro para ele. Além disso, o diretório que será removido deve estar vazio.

A sintaxe deste comando é a seguinte:

rm [option] arquivo
As opções passadas para esse comando podem ser as seguintes:

Opção Descrição
-d Retira o link de um determinado arquivo.
-f Ignora arquivos inexistentes e nunca pergunta o que fazer.
-i Modo interativo, pergunta sempre antes de remover.
-r Remove o conteúdo de um diretório recursivamente.
-v Mostra tudo o que está sendo feito
Desta forma, se quisermos apagar um diretório que possui diversos arquivos dentro
dele, podemos fazer assim:
rm -rf nome_diretório
O comando acima irá remover todo o conteúdo do diretório nome_diretório e depois
ele próprio.
Nota: Para remover arquivos que comecem com um hífen (-) é necessário realizar a
operação com o -- ou ./, conforme o exemplo abaixo. Além disso, os arquivos removidos
geralmente podem ser recuperados. Se você quiser ter certeza que o arquivo não será
recuperado, pode utilizar o comando shred.
# rm -- -arquivo_com_hifen
# rm ./-arquivo_com_hifen
Se não utilizarmos o comando shred para excluir um arquivo, este pode, na maioria
das vezes, ser recuperado.
Os arquivos são, na verdade, atalhos para endereços de bloco onde os dados
realmente estão armazenados. Desta forma, quando se exclui um arquivo, a operação
realizada e a exclusão deste atalho.
Os blocos são controlados por diversas flags, entre elas existe a que define se um
bloco pode ou não ser usado, ou seja, se não possui ou possui dados nele.
A recuperação pode ser feita de duas formas: a primeira delas, e a menos segura, é
definir a flag, que controla o estado do bloco como sendo um determinado bloco, não excluído.
A segunda forma define que é necessário encontrar o bloco e então copiar ele para um arquivo
qualquer.
touch
O comando touch é usado para atualizar o acesso e modificar a data de cada arquivo
para a data atual, ou também, criar um arquivo vazio.
A sintaxe usada para este comando é a seguinte:

touch [option] arquivo
As seguintes opções podem ser usadas:

Opção Descrição
-a Apenas muda a data de acesso.
-c Não cria arquivo nenhum.
-d data Utiliza data ao invés da data atual.
-m Modifica apenas a data de modificação.
-t timestamp Assim como o –d, modifica a data, entretanto com um formato
diferente, como o seguinte [[CC]YY]MMDDhhmm[.ss].
Se o comando touch for usado sem opção nenhuma, apenas com um nome de arquivo,
ele irá criar o arquivo vazio.
du
O comando du é utilizado para mostrar a quantidade de espaço, em disco, ocupado
pelos arquivos. Sua sintaxe é a seguinte:
du [opção] arquivo
As seguintes opções podem ser usadas:

Opção Descrição
-a Mostra a contagem para todos os arquivos, não apenas para os
diretórios.
-c Mostra o total geral.
-h Exibe o resultado em formato lido por humanos.
-l Conta os hard-links como arquivos normais.
-L Segue todos os links simbólicos.
-P Não segue qualquer link simbólico.
-S Não inclui o tamanho dos diretórios.
-s Mostra apenas o total para cada argumento.
--exclude=string Exclui da contagem os arquivos que forem iguais à string.
mkdir
Comando usado para criar diretórios que não existem.
mkdir diretório
O comando acima irá criar um diretório com o nome especificado no parâmetro
diretório.
rmdir
O comando rmdir é utilizado para remover um diretório, entretanto o diretório precisa
estar vazio para que isso aconteça.


rmdir diretório
Todos os comandos explicados acima podem ser efetuados através de um

gerenciador de arquivos, no ambiente gráfico, padrão do CentOs, o Nautilus:
Comandos de Manipulação de Texto

A seguir veremos alguns dos principais comandos de manipulação de texto no Linux.
Iniciaremos pelo mais simples destes comandos o “cat”:
cat
O comando cat é usado para concatenar arquivos e imprimir sua saída. Sua sintaxe:
cat [option] arquivos
As opções usadas como parâmetro para este comando são:

Opção Descrição
-A É equivalente a usar as opções –vET.
-b Mostra o número de linhas que não estejam em branco no arquivo.
-e Equivalente a –vE.
-E Mostra o caractere $ no final de cada linha.
-n Mostra no número total de linhas.
-T Mostra o caractere TAB como ^I.
tac
O comando tac é semelhante ao comando cat, entretanto ele mostra o conteúdo dos
arquivos de forma reversa.
more
O comando more é usado como um filtro de arquivos. O conteúdo do arquivo é exibido
em uma página e o resto do arquivo não é mostrado enquanto o usuário não pressionar uma
tecla. Esse comando permite visualizar grandes arquivos página a página. A sintaxe básica
para este comando é a seguinte:
more [options] arquivo
As opções podem ser as seguintes:
Opção Descrição

-num Define um número inteiro que será usado para especificar o

tamanho da tela em linhas.
-d Fará com que apareça o prompt com a mensagem “Press space
to continue, ‘q’ to quit”. Além disso, irá aparecer a mensagem
“Press 'h' for instructions” caso uma tecla ilegal seja pressionada.
-l O comando more usa o ^L como um caractere especial, e irá parar
após a linha que tiver esse caractere. Esta opção irá prevenir que
isto ocorra.
-p Não realiza a rolagem do texto, ao invés disto, limpa toda a tela e
mostra o resto do conteúdo.
-c Não rola a tela, ao invés disso, mostra o próximo conteúdo da parte
superior da tela para a inferior, limpando linha após linha.
-s Junta diversas linhas em branco em apenas uma.
-u Inibe o sublinhado.
Uma vez chamado o comando more, iremos entrar no modo interativo dele. Dentro
deste modo podemos utilizar alguns comandos que irão nos auxiliar a gerenciar nosso texto,
conforme a tabela, a seguir:
Comando Descrição
h Mostra o conteúdo da ajuda.
<ESPAÇO> Mostra as próximas linhas, em geral, preenche a tela inteira.
<ENTER> Mostra as próximas n linhas, o padrão é 1.
Q Sai do modo interativo.
S Avança no texto n linhas, o padrão é 1.
F Avança n telas de texto, o padrão é 1.
B Retorna n telas de texto, o padrão é 1. Funciona somente com
arquivos.
= Mostra o número da linha atual.
/ palavra Procura por palavra no texto.
N Procura a próxima ocorrência de palavra.
!<cmd> Executa um comando no shell.
V Inicia um editor de texto na linha atual.
less
O less é um comando que permite a navegação em um arquivo, permitindo que você
se movimente avance ou recue à vontade, dentro do mesmo. Além disso, o less não precisa
ler toda a entrada do arquivo antes de iniciar, assim, com arquivos muito grandes ele inicia
mais rápido do que editores de texto como o vi. Por utilizar o termcap, o less pode ser usado
em uma grande variedade de terminais.
cut
Este comando imprime apenas as partes selecionadas de cada linha de um
determinado arquivo para a saída padrão. Sua sintaxe é a seguinte:
cut [option] [File]

As opções aceitas para esse comando são:

Opção Descrição
-b Imprime somente os bytes definidos.
-c Imprime somente os caracteres definidos.
-d Utiliza o delimitador definido ao invés de TAB.
-f Imprime somente os campos estipulados. Também
imprime qualquer linha que não tenha um caractere
delimitador, a menos que a opção –s seja usada.
-n Usado em conjunto com o –b, não irá separar múltiplos
caracteres.
-s Não imprime linha que não tenham um delimitador.
--output- Utiliza palavra como delimitador de saída.
delimiter=palavra O padrão é utilizar o delimitador como saída.
head
Este comando irá mostrar somente as dez primeiras linhas do arquivo. Sua sintaxe é
a seguinte:
head [option] arquivo
As possíveis opções são as seguintes:

Opção Descrição
-c Imprime os primeiros N bytes dos arquivos.
-n Imprime as primeiras N linhas dos arquivos.
-q Não imprime os cabeçalhos dos nomes dos arquivos.
-v Imprime as informações dos nomes dos arquivos.
tail
Ao contrário do comando head, o comando tail imprime para a saída padrão, as últimas
10 linhas de um determinado arquivo. A sintaxe para este comando é a seguinte:
tail [option] arquivo
As opções para este comando são:

Opção Descrição
--retry Continua tentando abrir um arquivo mesmo que ele esteja
indisponível quando o tail começar ou se tornar indisponível
depois.
-c Mostra os últimos N bytes.
-f Mostra os dados que vão sendo adicionados ao fim do arquivo
depois de ser executado o comando.
-n Mostra as últimas N linhas.
-q Não mostra os cabeçalhos dos nomes dos arquivos.
-s Em conjunto com o –f, determina quanto tempo (em segundos)
será a próxima saída.

-v Mostra tudo o que o comando está fazendo.
sort
O comando sort é usado para concatenar arquivos de forma organizada. Ele é capaz
de organizar as linhas dos arquivos. Sua sintaxe é a seguinte:
sort [options] arquivo
Suas opções podem ser as seguintes:

Opção Descrição
-b Ignora espaços em branco.
-d Considera apenas os caracteres alfanuméricos e brancos.
-f Ignora se o caractere é caixa alta ou caixa baixa.
-g Compara de acordo com o valor numérico geral.
-i Considera apenas os caracteres que podem ser impressos.
-M Efetua comparação entre datas.
-n Compara de acordo com o valor numérico da string.
-r Reverte o resultado da comparação.
-c Verifica se o arquivo de entrada já está ordenado.
-o Escreve a saída para um arquivo ao invés da saída padrão.
wc
Este comando é utilizado para contar o número de linhas, bytes e palavras de um
arquivo e o total de linhas se mais de um arquivo for passado no parâmetro. Sua sintaxe é a
seguinte:
wc [options] Arquivo
As seguintes opções são aceitas:

Opção Descrição
-c Imprime o contador de bytes.
-m Imprime o contador de caracteres.
-l Imprime o contador de linhas.
-L Imprime o tamanho da maior linha.
-w Imprime o contador de palavras.
grep
Este comando é utilizado para procurar palavras em arquivos.
grep [options] pesquisa [arquivos]
O grep irá procurar pela string pesquisa em todos os arquivos. Encontrando ele exibe
o resultado. As seguintes opções podem ser utilizadas por este comando:

Opção Descrição
-A Num Imprime Num linhas depois de encontrar a string procurada.
-a Processa arquivos binários como se fossem arquivos de texto.
-B Num Imprime Num linhas antes de encontrar a string procurada.
-C Num Imprime Num linhas antes e depois de encontrar a string procurada.
--colour Imprime o resultado encontrado em cores.
-c Ao invés de mostrar a saída padrão, mostra o número de
ocorrências da palavra encontrada.
-i Não faz distinção entre letras maiúsculas e minúsculas.
Ao invés de mostrar a saída padrão, mostra o nome dos arquivos
-L onde não encontrar a palavra procurada.
-l Ao invés de mostrar a saída padrão, mostra o nome dos arquivos
onde encontrar a palavra procurada.
-m Num Para de ler o arquivo se encontrar Num vezes a palavra procurada.
-n Imprime o número da linha onde a palavra procurada foi encontrada.
-o Mostra apenas a parte da palavra encontrada, ou seja, se
procurarmos por “cas”, as palavras “casa”, “casaco” e “casca” irão
retornar apenas “cas".
-q Executa no modo silencioso, ou seja, não imprime nada na saída
padrão.
-r Efetua a busca recursiva.

6. MÓDULO 13 - GERENCIAMENTO DE SERVIDORES LINUX

6.1. GERENCIAMENTO DE GRUPOS E USUÁRIOS
De um modo geral, a palavra “usuário”, é associada a alguma pessoa. Entretanto, em
Sistemas Unix/Linux, isso nem sempre condiz com a realidade.
No Linux, um usuário pode ser não apenas “de carne e osso”, mas também um Serviço
(Aplicação), ou até mesmo um dispositivo de rede. O usuário é a forma de identificação de
alguém neste sistema operacional, que pode ser dono de alguma coisa.
Porém, em Sistemas Operacionais Unix/Linux, um “usuário” não é descrito pelo

sistema através de seu nome de login (exemplo: “tux”). A forma de identificação de usuários
nestes Sistemas é feita através de um código, chamado de UID. O nome de login serve
apenas para o processo de autenticação junto ao sistema. Um usuário possui um UID e este
não se repete. Além disso, ele também terá um código para identificar o seu grupo Primário
ao qual pertence. Este é chamado de GID. Sempre que criarmos um novo usuário, será
atribuído a ele um UID e um GID,
Para sabermos quais são UID e GID do nosso usuário, assim como outras informações
sobre ele, podemos executar o comando id, conforme abaixo:
Comando: id tux
uid=500(tux) gid=500(tux) grupos=500(tux)
O comando acima, nos mostra o código 500 que é a representação numérica para o
usuário tux, ou seja, sempre que visualizarmos um UID (User Identifier) será referente ao
usuário.
Depois, podemos ver o mesmo código 1000, entretanto este código está se referindo
ao “Grupo do Primário” do usuário GID (Group Identifier), e o nome do grupo, (tux).
Após o grupo primário, criado juntamente com o novo usuário, são mostrados os outros
grupos os quais o usuário pertence, como por exemplo, o grupo dialout que possui o GID
20.
Estes grupos adicionais, chamados “Grupos Secundários”, geralmente se referem a

recursos adicionais que o usuário tem acesso. Um usuário pode ou não possuir grupos
secundários, mas sempre possuirá um (e apenas um) Grupo Primário (GID).
Nota: Lembre-se que um usuário possui um UID único, ou seja, este código não se
repete nunca e só pode ser atribuído a um usuário. Além disso, um usuário pode pertencer a
mais de um grupo.
Adicionando novos usuários

Para se adicionar um novo usuário ao sistema, utilizamos o comando useradd.
Este comando aceita as seguintes opções.

Opção Descrição
--conf ARQUIVO Usará ARQUIVO ao invés do /etc/adduser.conf.

Este arquivo define as configurações do usuário criado.
--disable-login Não executa o comando passwd para definir uma senha.

O usuário não poderá usar a sua conta até que uma senha
seja definida.
--disable-password Semelhante ao anterior, porém o usuário pode efetuar o

login através de chaves SSH RSA, mas não usando a
autenticação por senha.
--force-badname Por padrão, os nomes de usuários serão comparados

contra expressões regulares. Esta opção define uma
forma fraca de validação para o nome de usuário.
--gid ID Irá colocar o usuário criado no grupo ID
--home DIR Usa DIR como o diretório home do usuário. Se este

diretório não existe, ele é criado e o esqueleto básico é
copiado.
--shell Define que o shell de login será SHELL.
--no-create-home Não cria o diretório home do usuário.
--quiet Não mostra mensagens.
--system Cria um usuário de sistema.
--uid ID Define que o usuário possuirá ID como código. Se este

UID já pertencer a outro usuário, então o comando
useradd irá falhar.
Exemplo, para adicionar via modo texto o usuário “tux”, criando ao mesmo tempo o
seu diretório home, podemos usar o comando abaixo:
useradd –m tux
O Parâmetro “-m”, informa o sistema para criar também o diretório home deste usuário,
no caso, será criado o diretório “/home/tux”.
Modificando Contas de usuários, no modo texto:

Uma vez criado o usuário, com o comando acima, podemos modificar os parâmetros
de sua conta (exemplo: nome de login, shell utilizados, etc), através do comando usermod.
No exemplo acima, para substituir o shell do usuário de “/bin/bash”, por “/bin/csh”, podemos
usar o comando abaixo:
usermod –s /sbin/nologin tux

Todos os parâmetros de conta de um usuário, existentes na linha que o define no

arquivo “/etc/passwd”, podem ser modificados desta forma. Para listar todas as opções
disponíveis com o comando “usermod”, utilize o comando abaixo:
usermod --help
Grupos no Linux
Assim como criamos usuários no Linux, é possível criar grupos para reunir usuários
de mesmo interesse.
Em sistemas Unix, Grupos são utilizados para permitir o acesso a certos recursos do
sistema. Por exemplo, para que um usuário possa utilizar os recursos multimídia do sistema,
pode ser que este usuário precise pertencer ao grupo “áudio”, que controla o acesso à placa
de som e a unidade de CD/DVD. Esta sistemática de controle de acesso é uma prática
constante no Linux.
Se quisermos saber a quais grupos um usuário pertence, podemos utilizar o comando
id, visto previamente, ou então utilizar o comando groups.
O comando groups exibe os grupos que um determinado usuário está.
Abaixo podemos ver a utilização deste comando.
# groups
tux dialout cdrom floppy audio video plugdev
A saída do comando acima irá mostrar o nome de todos os grupos que o usuário que
executou o comando, no caso o usuário “tux”, se encontra.
Se quisermos, podemos descobrir os grupos de outro usuário apenas passando o
nome do usuário como parâmetro, como abaixo.
# groups tux
tux cdrom áudio

Usuários: Administração Avançada

Se preferirmos, podemos fazer a edição dos dados dos usuários através do arquivo
/etc/passwd. A visualização deste arquivo é ilustrada na abaixo:
Visualização do arquivo /etc/passwd
O arquivo apresentado na figura acima é dividido em sete colunas, separadas pelo

delimitador “:”.
O primeiro campo indica o nome de usuário da pessoa, ou seja, esse é o nome que
ela irá utilizar para logar no sistema. Em geral, este é um nome pequeno como, por exemplo,
a primeira letra do nome e o sobrenome.
O segundo campo apresenta, opcionalmente, a senha criptografada do usuário.
O terceiro campo é a representação do código do usuário ou ID, como é conhecido
nos sistemas Linux. Este código não pode se repetir nunca e é usado para identificar o usuário
pelo sistema.
O quarto campo é a representação numérica do grupo. Tem as mesmas características
do terceiro campo, entretanto ao invés de ser utilizado para identificar o usuário ele é usado
para identificar o grupo do usuário. É conhecido como GID.
O quinto campo é utilizado para uma descrição do usuário. Em geral se utiliza esse
campo para colocar o nome da pessoa que um determinado usuário representa.
O sexto campo indica o lugar onde o usuário irá colocar seus arquivos pessoais,
também conhecido como diretório “home”. Neste diretório o usuário possui permissão para
fazer o que bem entender.
O sétimo e último campo especifica o interpretador de comando que será atribuído
para o usuário em questão.

Reparem que o segundo campo, onde é armazenada a senha do usuário,

encontramos a letra minúscula “x” para todos os usuários. Quando isso acontece significa que
as senhas estão armazenadas em outro lugar.
O arquivo /etc/shadow possui as senhas criptografadas dos usuários, este arquivo
é apresentado na figura abaixo.
Visualização do arquivo /etc/shadow
As senhas armazenadas neste arquivo devem corresponder às linhas encontradas no

arquivo /etc/passwd, ou seja, o usuário na quarta linha possui a senha na quarta linha do
arquivo /etc/shadow.
Nota: É possível encontramos o campo da senha em branco. Isso significa que não é
necessário colocar uma senha na hora da autenticação, entretanto, algumas aplicações ao
encontrarem este campo vazio não permitem que o usuário efetue o login.
Como vimos acima, o sétimo campo define qual será o interpretador dos comandos do
usuário. Em geral utiliza-se o /bin/bash para esse fim.
Sendo utilizado este interpretador de comandos, cabe ressaltar mais alguns pontos
em relação a ele. Dentro o diretório do usuário poderá existir os seguintes arquivos:
1. .bashrc: Dentro deste arquivo ficam todos os comandos que serão executados
sempre que o usuário efetuar um processo de login com sucesso. Nele encontramos
definições de paths, aliases e outros.
2. .bash_profile: Semelhante ao arquivo acima, entretanto é este arquivo que irá

executar ou no o .bashrc, dependendo da opção do usuário.
3. .bash_history: Aqui ficam armazenados todos os comando digitados no shell do

usuário. O histórico de comandos pode ser acessado com o uso da seta de navegação
para cima ou através do comando history.
Para mudarmos a senha do usuário é necessário executar o comando passwd, como abaixo:
# passwd
Este comando irá perguntar a senha atual e depois a nova senha do usuário.

Deleção de Usuário
Por fim, para removermos um usuário, podemos utilizar a ferramenta de linha de
comando userdel. O comando userdel possui algumas opções, abaixo indicadas:
Opção Descrição
-r Remove todo o diretório e e-mails do usuário.
-f Remove os arquivos mesmo que não pertençam à conta que está sendo
removida.
Assim, se quisermos remover o usuário “tux” do sistema, junto com o diretório e e-

mails, podemos executar o seguinte comando:
# userdel –r tux
Administração de Grupos
Anteriormente vimos o conceito de grupos no Linux. Agora, nesta seção, veremos
como fazer o gerenciamento de grupos através no CentOs.
Se quisermos criar um novo grupo através da linha de comando, podemos utilizar o
comando groupadd. Abaixo o exemplo de como poderíamos criar um grupo “teste”:
# groupadd teste
O comando acima criaria no arquivo /etc/group, a seguinte entrada, abaixo

reproduzida:
teste:x:501:
Também podemos fazer as alterações do grupo através do comando groupmod. Este

comando possui as seguintes opções.
Opção Descrição
-g GID Define o novo identificador GID do grupo.
-n Nome Define o novo nome do grupo para Nome.
-A User Adiciona User ao grupo.
-p Senha Define Senha como a senha do grupo.
Assim, se quisermos modificar o grupo “teste” criado anteriormente, usamos o seguinte

comando:

# groupmod –n grupoA teste

O comando acima irá renomear o grupo “teste” para “grupoA”.
Se, por outro lado, precisarmos adicionar um o usuário “tux” ao grupo “teste”,
precisamos apenas executar o comando abaixo:
# groupmod -A tux teste
No arquivo /etc/group, cada linha representa um grupo. Estas linhas possuem

informações sobre o nome, senha, GID e a lista de usuários. Assim, se quisermos adicionar
ou remover usuários de um determinado grupo, precisamos apenas localizar o grupo em
questão e adicionar ou remover o nome do usuário na lista.
Removendo um grupo
Se quisermos excluir o grupo através da linha de comando, podemos usar o comando
groupdel. Abaixo segue um exemplo.
# groupdel teste
O comando acima irá excluir do sistema o grupo “teste” previamente criado.


6.2. INSTALANDO PACOTES
Gerenciamento de Pacotes RPM

O RPM é uma ferramenta poderosa para se fazer o gerenciamento de pacotes de uma
distribuição Linux, sendo utilizada também na Distribuição CentOs. O RPM originou-se na
distribuição Red Hat, com o nome de Red Hat Package Manager, e era utilizado para instalar,
desinstalar, verificar, pesquisar e atualizar o sistema de pacotes de um computador.
Antes do RPM, para a instalação de um aplicativo era necessário obter-se o código
fonte dele e então efetuar um complexo trabalho de compilação do código fonte. Esta tarefa
nem sempre era feita rapidamente pelo fato de que, algumas vezes, era preciso resolver
diversos problemas de dependência de bibliotecas ou outros programas.
Para resolver essa questão, nasceu o RPM. Seu funcionamento é bastante simples e
eficiente, visto que o RPM informa o usuário sobre as dependências necessárias para a
instalação de um determinado pacote.
Os pacotes RPM, em geral, utilizam os binários compilados do programa. Ou seja,
quando você escolhia instalar um programa apenas ocorria o download desse pacote e a
cópia dos binários, encontrados no pacote, para seus diretórios específicos. Entretanto, caso
a pessoa escolhesse fazer alterações no código fonte e compilar o pacote novamente,
também é possível através do download das fontes dos pacotes e não dos binários. O RPM
possui diversas opções de uso. Veremos aqui as mais comuns e usadas diariamente:
Pesquisa de Pacotes
 Comando: rpm -qa (procura por todos os pacotes)
 Comando: rpm -qa | grep squid (procura por um pacote específico)
 Comando: rpm -qf /etc/hosts (descobre a qual pacote, um arquivo pertence)
Instalação de Pacotes
 Comando: rpm -i pacote.rpm (instalação apenas)
 Comando: rpm -ivh pacote.rpm (instalação com barra de progresso)
 Comando: rpm -i(-ivh) pacote.rpm –force (ignora dependências)
Assim, se quisermos fazer a instalação do pacote do grub, por exemplo, utilizaremos

o comando:
rpm –i grub-0.96-6.i386.rpm
O comando acima faz a instalação de um pacote, previamente adquirido, no sistema

operacional. Um bom costume é utilizar, junto com a opção –i, a opção –vh, pois assim
teremos mais informações sobre a instalação, além de uma barra de progresso (“h” = “hash”),
informando o progresso da sua instalação no sistema.
No caso do pacote não existir localmente, é possível usar o comando a seguir, para
fazer a instalação de um pacote remoto, em uma única linha de comando, exemplo:
rpm –i ftp://www.redhat.com/pub/i386/Fedora/RPMS/grub-0.96-6.i386.rpm

Além disso, existe ainda a opção -f (force), que permite a instalação de um pacote,
ignorando eventuais dependências não satisfeitas. Esta opção deve ser utilizada com muito
cuidado, pois pode inclusive, danificar a base rpm do sistema.
Upgrade de Pacotes
 Comando: rpm -U pacote.rpm (atualização, apenas)
 Comando: rpm -Uvh pacote.rpm (atualização com barra de progressos)
 Comando: rpm -U(-Uvh) pacote.rpm –force (ignora dependências)
No upgrade de pacotes, os arquivos de configuração anteriores, serão mantidos.

Da mesma forma, que na instalação, o comando de Upgrade de um pacote aceita as
opções de verbose (-v), e de barra de progresso, além da opção “force” (-f).
Desinstalação de Pacotes
 Comando: rpm -e pacote (remoção, apenas)
 Comando: rpm -e pacote –nodeps (ignora dependências)
Dessa forma, se quisermos, por exemplo, o nosso pacote recém instalado, grup,
utilizaremos o comando que segue:
rpm –e ntp
“Note que, agora, devemos informar APENAS o nome do pacote, sem informar sua
extensão (pois, uma vez que o software já se encontra instalado, não existe mais pacote)
“.rpm”.
Caso ocorra de querermos remover um pacote, entretanto não lembrarmos o nome
completo dele, podemos fazer uma pesquisa na base de dados dos pacotes instalados. Isso
é possível com a sintaxe abaixo:
Comando: rpm –qa | grep –i pacote
O parâmetro –i, passado para o comando grep indica que não queremos fazer
distinção entre maiúsculas e minúsculas. Abaixo, como exemplo, ilustramos como procurar e
saber se existe um pacote chamado xmms no nosso sistema:
rpm –qa | grep –i xmms
Reindexando o Banco RPM

Eventualmente, poderá ocorrer algum dano à base RPM. No caso desta
eventualidade, não será possível, por exemplo, obterem-se informações sobre quais pacotes
se encontram ou não instalados no sistema. Para resolver este problema, podemos utilizar o
comando abaixo, para reindexar a base de dados RPM:
rpm –rebuilddb

Após alguns segundos, o banco RPM, deverá ter se encontrar, novamente em

condições.
Ferramentas de gerenciamento de Dependências

Durante a instalação/desinstalação de um pacote, é possível que o sistema informe
sobre a necessidade de se instalar (ou desinstalar), o “software X”, entretanto, qual é o nome
do pacote rpm que contém o “software X”?? É para estes casos, que foi desenvolvido um tipo
de software especial, chamado de “Ferramentas de gerenciamento de Dependências”.
Exemplos deste tipo de ferramentas podem ser encontrados na Tabela abaixo:
Ferramenta Distribuição
APT DEBIAN
APTITUDE DEBIAN
YUM REDHAT (CentOs)
YAST SUSE
ZYPPER SUSE
Ferramentas de Gerenciamento de Dependências
De acordo com a tabela acima, o CentOs, utiliza a ferramenta YUM, originária da

Distribuição RedHat. Por exemplo, para instalarmos o servidor de SMTP Postfix, bem como
todas as suas dependências, basta utilizar o comando a seguir:
yum install postfix
O YUM irá procurar e instalar o postfix e todas as suas dependências, a partir da lista
de servidores de ftp, existente a partir de “/var/cache/yum”.

6.3. COMPILANDO CÓDIGO FONTE
Instalando Programas Através do Código Fonte

A instalação de programas a partir de um código fonte é mais complexa que a
instalação através de um gerenciador de pacotes, como o YUM. De modo geral, devemos
utilizar os pacotes pré-compilados, originais da Distribuição e, apenas em casos especiais,
partir para a compilação dos pacotes. Dentre as razões para este procedimento, podemos
citar:
Razões Para Compilar Razões Para Não Compilar
Corrigir bugs, mais rápido Perde-se a garantia do fabricante
Ativar funcionalidades extras Perdem-se as atualizações automáticas
Incrementar a performance Procedimento manual e mais complexo
Razões pró/contra compilação de aplicações
Uma vez decidido que compilar o software seja o mais indicado, devemos proceder,
de acordo com o indicado, logo a seguir:
Passo 1: Obter as fontes do software e descompactar em:

 /usr/src: Se depender das fontes do kernel (ex. Drivers de dispositivo)
 Outro diretório qualquer (ex “/usr/local”): Maioria das aplicações
Passo 2: Entrar no diretório descompactado e LER o arquivo INSTALL, o qual contém

as orientações essenciais (ex. O diretório de instalação) para o procedimento de instalação.
Passo 3: Após ler o arquivo INSTALL executar o script “configure”, adicionando, se

necessário os parâmetros de instalação que forem indicados. Por exemplo, para compilar o
Web Server Apache, seria:
 ./configure –with-dir=/usr/local/apache2
Passo 4: Após a conclusão do “configure”, será criado o arquivo “Makefile”, que

contém as orientações e parâmetros para a compilação do software. A seguir, para compilar
o software, execute:
 make

Passo 5: Finalmente, para instalar os arquivos compilados e o software, nos diretórios

corretos, execute:
make install
O comando acima fará com que os arquivos binários sejam copiados para os diretórios
específicos do sistema, como por exemplo, o diretório /usr/local/bin, onde podemos
encontrar diversos outros programas.
Nota: Procure manter seu sistema atualizado, preferencialmente através dos pacotes
RPM, ou então, através das fontes compiladas. Misturar ambas as formas de atualização
certamente trará problemas com versões de software.


6.4. GERENCIANDO SERVIÇOS
O CentOs permite que boa parte das tarefas administrativas possam ser realizadas,
através do modo gráfico, em um modo alternativo ao uso das populares ferramentas de linha
de comando Unix. Estas ferramentas podem ser encontradas a partir do diretório “/usr/bin”,
conforme podemos observar, através do comando a seguir:
[root@localhost bin]# ls -1 system*
system-cdinstall-helper
system-config-authentication
system-config-date
system-config-display
system-config-httpd
system-config-keyboard
system-config-language
system-config-network
system-config-network-cmd
system-config-nfs
system-config-printer
system-config-samba
system-config-securitylevel
system-config-securitylevel-tui
system-config-services
system-config-soundcard
system-config-time
system-config-users
system-control-network
system-install-packages
[root@localhost bin]#
Lista de Ferramentas de Administração do CentOs

O acesso à estas ferramentas, pode ser efetuado de dois modos:

 Diretamente, executando-se, a partir de um console (ex.: system-config-network, para
chamar a ferramenta de configuração de rede).
 A partir do menu principal do Gnome (Sistema --> Administração).
A figura abaixo, ilustra o acesso as ferramentas de administração do CentOs, via

ambiente gráfico:
Ferramentas Gráficas de Administração do CentOs
Ferramentas Extras - Webmin

O Webmin é uma ferramenta de administração modular baseada na Web que é
utilizada em uma grande variedade de versões Linux, assim como em sistemas Unix.
Esta ferramenta permite que você faça o login através de uma página web e realize as
tarefas de administração. O Webmin é responsável por efetuar as alterações necessárias nos
arquivos de configuração apropriados para completar as suas tarefas.

O Webmin é uma ferramenta muito conveniente para você gerenciar o seu sistema.
Ela pode também auxiliar a configuração de arquivos de servidores, como o Samba, DNS e
outros.
Depois de instalado, para acessarmos o Webmin precisamos apenas abrir um
navegador como, por exemplo, o Firefox e então digitar o endereço
http://localhost:10000. A figura 9 abaixo ilustra a tela que irá ser exibida depois de
digitarmos o endereço:
Tela de login do Webmin

Para efetuar o login é necessário usar o usuário root e sua respectiva senha.
Depois de preenchido os campos necessários, precisamos pressionar o botão “Login”.
A figura abaixo ilustra a tela principal da ferramenta, ou seja, após o login:
Tela principal do Webmin
Na parte superior podemos encontrar o menu principal, indicado pela seta mais acima
direcionada para a esquerda. Neste menu é possível fazer a navegação no Webmin, ou seja,
este menu agrupa os módulos de configuração por afinidade.
Na parte central da tela é exibido o conteúdo do menu selecionado, indicado pela seta
mais abaixo. Cada menu possui um conjunto de módulos para a configuração.
Para ficar mais clara a explicação, vamos supor que desejamos configurar um servidor
SSH. Assim, primeiro iríamos selecionar o menu dos servidores e depois o módulo de
configuração do servidor SSH.
Após selecionar o módulo desejado, uma nova tela será exibida contendo os menus
de configuração do servidor. A figura 11 abaixo ilustra a configuração para o servidor SSH.

Configuração do servidor SSH
Depois de selecionado o Servidor desejado, configure uma série de opções sobre a

configuração dele que já estará disponível, conforme ilustrado na figura acima.
Nota: Sendo uma ferramenta de configuração do sistema baseada na Web, é

extremamente importante definir políticas de acesso a ela, por exemplo, permitir o acesso
somente através de comunicação segura e de apenas um host é uma boa dica para a
segurança do sistema.


7. MÓDULO 14 - SERVIÇOS DE REDE LINUX
7.1. DHCP
Como é sabido, todos os dispositivos que estiverem em uma rede, seja ela local ou
não, devem possuir um endereço IP. A forma como estes dispositivos recebem o seu
endereço IP pode ser feita através de uma configuração manual ou através de um protocolo
de auto-negociação de rede.
Assim, iremos abortar a seguir os dois tipos de endereçamento IP existentes: o
endereçamento através de IP estático e através de IP dinâmico.
IPs Estáticos
Os endereços IPs estáticos são aqueles que devem ser configurados, previamente,
pelo administrador do sistema e não irão mudar no decorrer do tempo sem a intervenção
humana. Em outras palavras, ao definir um endereço IP estático, ele somente i rá mudar caso
alguém altere ele manualmente, caso contrário, ele será sempre o mesmo.
Um problema comum, encontrado devido ao uso dos endereços IP estáticos, é o
conflito de endereços causado por eles. Ou seja, se tivermos dois dispositivos de rede, na
mesma rede, configurados com o mesmo endereço IP, teremos um conflito, pois o endereço
IP deve ser único dentro de uma determinada rede.Assim, quando um dos dispositivos
for iniciado, o outro que já estava em funcionamento irá perder o seu endereço IP, pois o que
recém foi ligado irá utilizar ele.
Este é um problema comumente encontrado em grandes redes que utilizam endereços
IP estáticos. Isto porque fica a cargo do administrador manter um mapeamento de todos os
dispositivos que se encontram na rede e seus r espectivos endereços IP.
No Linux, a configuração estática do endereço IP pode ser feita através da
configuração do dispositivo de rede.
Dentro do diretório /etc/sysconfig/network-scripts, encontramos uma série de arquivos
de configuração de rede.
Entre eles, podemos visualizar os arquivos de configuração dos dispositivos de rede,
como por exemplo, uma placa de rede.Estes arquivos começam com ifcfg, depois o
identificador do tipo de dispositivo, Por exemplo, para a interface eth0, o seu arquivo de
configuração seria:
ifcfg-eth0
Dentro deste arquivo de configuração podemos encontrar diversos parâmetros de

configuração da interface.
Se desejarmos, podemos escolher a forma manual para especificarmos um endereço
IP estático.

Isto é possível através das opções BOOTPROTO e IPADDR encontradas no arquivo

de configuração. A primeira opção especifica o tipo de protocolo usado para iniciar a interface
de rede durante o processo de inicialização e a segunda define o endereço IP da interface.
Assim, se quisermos definir um endereço IP estático, precisamos definir o protocolo
como estático e atribuir um endereço IP para a opção IPADDR.
BOOTPROTO = ‘static’
IPADDR = ‘192.168.0.6’
Se adicionarmos esta linha ao arquivo, então estamos definindo que a nossa interface
de rede possuirá o endereço IP estático 192.168.0.6.
Nota: Cada interface de rede possui um arquivo separado para a configuração de

suas opções, por isso, atente-se para qual dispositivo as opções estão sendo alteradas de
acordo com o nome do arquivo de configuração.
Além da utilização da linha de comando para definir um endereço IP estático, no
CentOs, podemos usar a ferramenta system-config-network, para realizarmos esta tarefa:
system-config-network
Abaixo, podemos conferir a tela inicial de configuração, desta ferramenta:
IPs Dinâmicos
Ao contrário dos IPs estáticos, os endereços IP dinâmicos podem sofrer alterações ao
longo do tempo sem que isso seja feito pelo administrador do sistema. Este tipo de
endereçamento dos dispositivos de rede é feito através de um protocolo de rede chamado
DHCP.

O DHCP (Dynamic Host Configuration Protocol) é um protocolo de comunicação que

permite aos administradores da rede centralizar o gerenciam ento e automatizar a atribuição
de endereços IP para os dispositivos da rede.
Esta abordagem permite ao administrador supervisionar e distribuir endereço IP de um
ponto centralizado. Além disto, o envio automático do endereço IP acontece sempre que um
novo computador é conectado à rede, sem necessitar que a configuração do novo dispositivo
seja feita pelo administrador.
Este protocolo utiliza uma quantia de tempo em que um determinado endereço IP será
válido para um computador. Este tempo dependerá de quant o tempo o usuário irá necessitar
da conexão com a Internet em um local determinado.
Este protocolo também suporta endereços IP estáticos para os computadores que
necessitam de um endereço permanente, como é o caso de servidores de e -mail, Web e
outros.
Assim, para definirmos que o dispositivo de rede irá utilizar este protocolo, precisamos
editar o arquivo de configuração dele encontrado no diretório /etc/sysconfig/network-scripts,
da mesma forma como foi feito para o endereçamento estático, alterando os v alores das
opções BOOTPROTO e IPADDR:
BOOTPROTO = ‘dhcp’
STARTMODE = ‘AUTO’
Com os valores acima, definimos que a opção BOOTPROTO deverá usar o protocolo
DCHP e a opção IPADDR deverá ficar sem valor. Ou seja, usando o DHCP, o endereço IP
do dispositivo será determinado pelo servidor DHCP que veremos posteriormente.
Além destas configurações, é possível a uma interface configurada com endereço IP
estático, obter um endereço IP dinâmico. Isto é possível através de uma aplicação especial
de nome “Cliente de DHCP”. Existem, atualmente, dois clientes DHCP, mais utilizados no
mundo Linux:
 dhcpcd (“dhcp client daemon”): Utilizado em muitas distros, inclusive no SuSE
 dhclient: Mais atual, também bastante utilizado no mundo Linux, é o default do

CentOs;
O dhclient adquire as informações para o host através de requisições para um

servidor DHCP e então, configura a interface de rede da máquina onde ele foi executado.
Assim, quando quisermos realizar a configuração de um dispositivo de rede, através
de um servidor DHCP, podemos utilizar o comando abaixo, por exemplo:
 dhclient eth0
O comando acima irá levantar a interface de rede eth0 e irá atribuir as informações
de rede advindas do servidor DHCP, à ela.Se quisermos solicitar um novo endereço de rede
para o servidor DHCP, podemos, ainda, utilizar o comando abaixo.
 dhclient eth0 new
Assim, uma nova solicitação será feita ao servidor DHCP.

Instalando o Servidor DHCP

Nesta seção, será abordada uma forma de realizarmos a instalação do servidorDHCP
através do yum:
yum install dhcp
O comando acima ivai instalar o servidor dhcp bem como suas eventuais
dependências, bastando para isto confirmar, quando solicitado.
Configuração do Servidor DHCP

O arquivo de configuração para o servidor DHCP é o /etc/dhcp/dhcpd.conf. Na
Distribuição CentOs, release 6.2, este arquivo se encontra vazio e deve ser construído, a partir
de um exemplo de configuração existente em /usr/share/docs. Para isto, execute o comando
abaixo:
cp /usr/share/doc/dhcp-versão/dhcpd.conf.sample /etc/dhcp/dhcpd.conf
Definindo faixas de endereços IP

Para configurar o servidor dhcp, devemos editar o arquivo /etc/dhcpd.conf.
Primeiramente, devemos estabelecer a rede/máscara de endereços da rede a ser servida pelo
dhcp server:
subnet 192.168.6.0 netmask 255.255.255.0;
Atribuindo um gateway padrão

Além da faixa de distribuição de endereço, outra informação comumente usada na
configuração de uma interface de rede é o gateway padrão, ou seja, quem é o roteador da
rede em questão.
Para definirmos esta opção, precisamos apenas adicionar a seguinte linha ao arquivo
de configuração.
option routers 192.168.6.240;
Esta linha define que o gateway padrão da rede é o dispositivo com o endereço IP
192.168.1.100.
Definindo um servidor de nomes

Para ser capaz de resolver os nomes dos hosts, é necessário que um cliente DNS seja
configurado. Isto é feito através das linhas abaixo:
option domain-name-servers 8.8.8.8;
option domain-name “sisnet.com.br”;
Usando as opções
Depois de vistas algumas opções iniciais, vamos colocar todas elas juntas no arquivo
/etc/dhcpd.conf:
# A slightly different configuration for an internal subnet.
subnet 192.168.5.0 netmask 255.255.255.0 {
range 192.168.5.128 192.168.5.240;
option domain - na me- servers 8.8.8.8;
Li nux Professional Serviços de Internet
SSLXPI – CentOS 6.2 - v1.0 Página 34
option domain - name "sisnet.com.br";
option routers 192.168.6.250;
option broadcast- address 192.168.6.255;
default- lease- time 600;
max- lease- time 7200;
}
Desta forma, teremos um servidor DHCP para a rede 192.168.5.0/24.

Nesta rede será alocada a faixa de endereços entre 192.168.5.128 até 192.168.5.240
para os clientes DHCP.
Os clientes serão configurados com o gateway padrão apontando para o endereço
192.168.5.250 e o servidor de nomes 8.8.8.8. O nome do domínio destes clientes será
sisnema.com.br.
Depois de concluirmos a configuração do arquivo /etc/dhcpd.conf é necessário
definirmos qual interface de rede será usada pelo servidor DHCP, no caso de existir mais de
uma no dispositivo que ele foi instalado.
Para tal, é necessário editar o arquivo /etc/sysconfig/dhcpd e editar o parâmetro
DHCPD_INTERFACE. Assim, se quisermos utilizar este serviço na interface eth0, a linha do
arquivo de configuração deverá ficar assim:
DHCPDARGS="eth0"
Concluída esta última alteração, é necessário reiniciar o servidor DHCP para que as
novas opções entrem em vigor:
service dhcpd restart

7.2. DNS

Sempre que precisamos acessar um endereço Web na Internet, de maneira geral,

pensamos no nome que desejamos acessar e colocamos o http://www na frente.
Por exemplo, se quisermos acessar a página da empresa SISNEMA, então colocamos
o http://www, depois colocamos o nome da empresa, ou seja, SISNEMA, e depois
completamos com o .com.br, formando assim o endereço http://www.sisnema.com.br.
Entretanto, o protocolo TCP/IP usado na Internet, necessita de um endereço IP para
realizar a identificação dos dispositivos na rede. Ou seja, o endereço 200.186.48.68 pode ser
usado pelo protocolo, mas o endereço www.sisnema.com.br não será reconhecido por ele.
O responsável por fazer a tradução do nome do host, entendido pelos humanos, para
o endereço IP, entendido pelo protocolo TCP/IP, é o DNS.
O DNS (Domain Name System) possui a tarefa de realizar a tradução de nomes,
embora esta não seja a única de suas tarefas. Ele também é responsável pelos servidores de
e-mail e resolução reversa de nomes, ou seja, traduzir os endereços IP para nomes.
O DNS possui um design distribuído e hierárquico. O seu gerenciamento é controlado
localmente em um domínio.
O termo domínio é usado para descrever um nome de domínio, entretanto, ele significa
um local ou área onde um controle é exercido. Em outras palavras, podemos dizer que o
domínio de uma rede é todo aquele território que é controlado pelo administrador da rede.
Por exemplo, o domínio sisnema.com.br é controlado pelo administrador da empresa
SISNEMA. Todas as informações que trafegarem neste domínio são de responsabilidades do
administrador, da mesma forma como todos os problemas de configuração.
Assim, cada domínio na Internet é de responsabilidade de um administrador em
particular. Ou seja, se não fosse usada esta abordagem, seria praticamente impossível
centralizar a responsabilidade dos milhares de domínios existentes na Internet.
Mesmo que a ideia de centralizar todo o controle da Internet seja absurda, ainda assim
existe uma pequena porção desta parte central que controla as requisições de dados em um
sistema distribuído.
Estes servidores gerenciados centralmente são chamados de root DNS servers. Eles
controlam os domínios de alto nível na Internet (TLD – Top-Level Domains), e isto ajuda a
facilitar a ideia de um a rede massivamente distribuída.
Os domínios TLD englobam o .com, .net, .org, co.uk e assim por diante. Estes
domínios contêm informações sobre os domínios de nível inferior no espaço de endereço
DNS.
Por exemplo, google.com está sobre o domínio do espaço de nome .com. A figura
abaixo ilustra a árvore do domínio administrativo

Existem diversos domínios de alto nível. Abaixo vamos listar os domínios mais
comuns:
Domínio de alto nível – TLD Uso
.com Organizações comerciais
.net Redes de máquinas
.org Organizações sem fins lucrativos
.mil Instituição Militar Americana
.gov Instituição Governamental Americana
.co.uk Companhia do Reino Unido
Como funciona o DNS

Para entendermos como funciona o DNS, veremos um exemplo de busca para ficar
mais clara a ideia de um sistema distribuído e hierárquico.
1. Vamos pegar uma estação de trabalho qualquer. O servidor de nomes da rede possui
o endereço 192.168.0.2. Assim, quando nós digitamos o endereço www.google.com a

nossa estação irá contatar a máquina 192.168.0.2 perguntando o endereço de

www.google.com. Como o nosso servidor utiliza cache (será explicado
posteriormente), ele irá contatar um servidor de DNS público para ver se ele sabe o
endereço.
2. O servidor DNS público, no endereço 200.132.0.69, aceita a nossa requisição e tenta

encontrar o endereço IP do Google para nós. Como este servidor de DNS não sabe o
endereço direto, por não controlar o domínio do Google, ele pergunta para o root DNS
server para ver se ele sabe o endereço. O root DNS server também não controla o
domínio Google, entretanto, ele informa para o nosso servidor DNS que ele deve fazer
a pergunta para o servidor de DNS que controla o domínio .com.
3. Então, o nosso servidor DNS público pergunta ao servidor DNS .com qual o endereço
IP de www.google.com. Como o servidor DNS .com não sabe o endereço diretamente,
ele indica para o nosso DNS o servidor DNS que controla o domínio google.com.
4. O nosso DNS então pergunta para o servidor DNS do domínio google.com se ele sabe
o endereço de www.google.com. Desta vez nós temos sorte, pois o servidor DNS sabe
o endereço e retorna ele para o nosso DNS.
5. Quando o DNS público conhece o endereço IP, ele passa adiante para o nosso
servidor DNS local (192.168.0.2) que finalmente passa para a nossa estação de
trabalho.
Como você pode perceber, os sistemas servidores de DNS trabalham em cooperação

uns com os outros para encontrar a resposta para uma determinada pergunta DNS. Isto ajuda
a aliviar a carga de tradução de nome em apenas um servidor DNS ou em um pequeno grupo
de servidores.
Nota: O caminho percorrido pelos servidores DNS é sempre o inverso do endereço

solicitado. Por exemplo, o endereço saturno.nasa.com. Primeiro é necessário saber quem
conhece o domínio .com, este por sua vez, irá indicar quem conhece o domínio .nasa.com
que por sua vez irá indicar o endereço de saturno.nasa.com.
Caching
Conforme dito anteriormente, vamos explicar o significado do cache. Você pode estar
imaginando que com todas as máquinas do mundo requisitando o endereço IP de um site
famoso como o Google, por exemplo, isso irá impactar diretamente na performance dos
servidores DNS root, .com e Google.
Para combater esta sobrecarga, a maioria dos servidores DNS locais guardam o
resultado de uma requisição por um determinado período d e tempo, denominado TTL (Time
to Live). Até que este tempo termine, as requisições subsequentes para o endereço
www.google.com serão respondidas pelo servidor DNS local.
Zonas

De forma geral, uma zona é uma área administrativa. O significado de zona é similar
ao significado de domínio. Dependendo do ambiente de rede, este termo pode ter sentidos
diferentes.
No ambiente do DNS, uma zona é o espaço de nome alocado para um servidor
particular. Um arquivo de zona possui instruções para resolver os nomes de domínios
específicos na Internet em endereços IP.
Assim, para podermos configurar e manter um servidor de nomes de maneira correta
é importante entendermos, bem, a diferença entre zona e domínio.
Como vimos acima, a zona é um ponto de delegação em uma árvore DNS. Uma zona
consiste naquela parte contínua da árvore do domínio, onde o servidor de nomes possui a
informação completa, e sobre o qual ele é autoritário.
Ele possui todos os nomes do domínio de certo ponto para baixo, na árvore de
domínios, exceto sobre aqueles domínios delegados para outras zonas. Um ponto de
delegação é marcado por um ou mais registros NS na zona pai, o qual deve ser comparado
exatamente com o registro NS na raiz da zona delegada.
Por exemplo, vamos imaginar o domínio sisnema.com.br, o qual possui um nome
como linux.sisnema.com.br e outro tux.sisnema.com.br, ainda assim, a zona sisnema.com.br
inclui apenas delegações para as zonas linux.sisnema.com.br e tux.sisnema.com.br.
Uma zona pode mapear, exatamente, para um único domínio, mas pode, também,
incluir apenas uma parte de um domínio, o qual o resto pode ser delegado para outros
servidores de nome.
Cada nome na árvore DNS é um domínio, mesmo que ele seja terminal, ou seja, não
tenha subdomínios. Todo subdomínio é um domínio e todo domínio, exceto o raiz, também e
um subdomínio.
Assim, o BIND é chamado um “servidor de nomes de domínios”, ou seja, DNS. Ele lida
primariamente com termos de zonas. Veremos o BIND mais detalhadamente a seguir.
Servidores de Nome Autoritários
Cada zona é servida por, pelo menos, um servidor de nomes autoritário, o qual contém
os dados completos para a zona. Para fazer com que o DNS seja tolerante a falhas dos
servidores e de rede, a maioria das zonas possui dois ou mais servidores autoritários.
O Servidor Primário ou Mestre
O servidor autoritário, onde uma cópia mestre dos dados da zona é mantida, é
conhecido como servidor primário mestre, ou simplesmente primário. Ele carrega o conteúdo
de um arquivo local, editado pelos administradores ou gerado através de algum mecanismo,
a partir de algum outro arquivo local.
Este arquivo é chamado arquivo de zona ou arquivo mestre.
Servidores Secundários ou Escravos

São os outros servidores autoritários, estes servidores, também conhecidos como

servidores secundários, carregam o conteúdo das zonas de um outro servidor, usando um
processo de replicação conhecido como transferência de zona.
Tipicamente os dados são transferidos diretamente do servidor primário, mas também
é possível realizar esta transferência de outro servidor secundário. Ou seja, em outras
palavras, o servidor secundário pode atuar como um servidor primário para um servidor
secundário subordinado.
Servidores Escondidos
Normalmente, todos os servidores autoritários de uma zona, são listados em registros

NS na zona pai. Estes registros constituem a delegação de zonas a partir de um pai.
Os servidores autoritários também são listados nos arquivos de zona, no topo mais
alto da zona, ou apex. Você pode listar os servidores, encontrados nos registros NS de topo
de zona, que não estão nos NS de delegação do seu pai, mas você não pode listar os
servidores na delegação do pai que não estão presentes no nível de zona mais alto.
Um servidor escondido, ou stealth, é um servidor que é autoritário para uma zona, mas
não é listado nos registros NS de zona.
Instalando um Servidor DNS
Para instalarmos o servidor DNS no CentOs, versão 6.2, primeiro precisamos conferir
se todos os pacotes se encontram instalados.
O nome do servidor é named, entretanto, o nome do pacote que contém o conjunto de
ferramentas necessárias para configurarmos um servidor DNS, é chamado bind. Assim,
devemos procurar por pacotes com este nome:
Comando: rpm -qa | grep bind
bind- libs- 9.7.3- 8.P3.el6_2.2.i686

bind- 9.7.3- 8.P3.el6_2.2.i686
bind- utils- 9.7.3- 8.P3.el6_2.2.i686
Caso o pacote servidor não tenha sido instalado, instale-o, com o comando a seguir:
yum install bind
Feita a instalação dos pacotes necessários, podemos efetuar a configuração do
servidor.
Configuração do BIND

Nesta versão do bind, a configuração de uma zona DNS é realizada em dois arquivos,
ambos existentes no diretório “/etc:
Arquivo /etc/named.conf: Parâmetros básicos incluindo a localização dos demais

arquivos envolvidos, bem como restrições de acesso ao serviço.
Arquivo /etc/named.rfc1912.zones: Arquivo onde declaramos a zona dns a ser

configurada;
Assim, para declarar uma zona DNS, precisamos proceder, de acordo com o mostrado
abaixo:
Passo 1: Editar o arquivo /etc/named.conf e acrescentar os itens que aparecem em

destaque, onde:
listen-on port 53 { 127.0.0.1; 192.168.6.0/24; };

As redes e a porta que o bind vai escutar.
allow-query { localhost; 192.168.6.0/24; };

As redes autorizadas a resolver nomes através deste servidor

Arquivo /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example name d configuration files.
//
options {
listen - on port 53 { 127.0.0.1; 192.168.6.0/24; };
listen - on - v6 port 53 { ::1; };
directory "/var/named";
dump- file "/var/named/data/cache_dump.db";
statistics- file "/var/named/data/named_stats.txt";
memstatistics- file "/var/named/data/named_mem_stats.txt";
allow- query { localhost; 192.168.5.0/24; };
recursion yes;
dnssec- enable yes;
dnssec- validation yes;
dnssec- lookaside auto;
/* Path to ISC DLV key */
bindkeys- file " /etc/named.iscdlv.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";

Passo 2: No arquivo /etc/named.rfc1912.zones, declare o domínio DNS, conforme

modelo a seguir. Aqui será utilizado como domínio o domínio fictício “sisnet.com.br”:
Arquivo /etc/ named.rfc1912.zones (trecho final)
...
zone "sisnet.com.br" IN {
type master;
file "sisnet.com.br.zone";
};
zone "6.168.192.in - addr.arpa" IN {
type master;
file "sisnet.com.br.rev";
};
Note que apenas a parte final do arquivo (que contém a zona DNS a ser declarada), é
mostrada, para fins de maior clareza. Os parâmetros mais importantes neste arquivo são:
 zone: O domínio dns a ser configurado (“sisnet.com.br”).
 Type: Tipo de servidor dns. Pode ser:
master: Servidor dns primário;

slave: Servidor dns secundário;
Cache -only: Propriamente, não resolve nomes, porém acelera a resolução fazendo cache
das consultas já resolvidas anteriormente;

Passo 3: No arquivo de zona dns, em /var/named/, declare a zona dns, conforme o

modelo abaixo:
Arquivo sisnet.com.br.zone
$TTL 3600
@ IN SOA instrutor.sisnet.com.br. hostmaster.sisnet.com.br. (
1 ; serial
3H ; refresh
1H ; retry
1W ; expiry
3H ) ; minimum
sisnet.com.br. IN NS ns.sisnet.com.br.
sisnet.com.br. IN MX 10 mail.sisnet.com.br.
sisnet.com.br. IN MX 20 mail2.sisnet.com.br.
instrutor IN A 192.168.6.200
mail IN A 192.168.6.200
mail2 IN A 192.168.6.201
ns IN A 192.168.6.200
ftp IN A 192.168.6.225
www IN A 192.168.6.225
www2 IN A 192.168.6.225

Tipos de Registros
Nos arquivos que configuramos as zonas, podemos encontrar uma série de registros.
Aqui, iremos explicar cada um deles. Observe o exemplo abaixo:
Arquivo sisnet.com.br.zone
$TTL 3600
@ IN SOA instrutor.sisnet.com.br. hostmaster.sisnet.com.br. (
1 ; serial
3H ; refresh
1H ; retry
1W ; expiry
3H ) ; minimum
sisnet.com.br. IN NS ns.sisnet.com.br.
sisnet.com.br. IN MX 20 mail2.sisnet.com.br.
ftp IN A 192.168.3.225
www IN A 192.168.3.225
www2 IN A 192.168.3.225
squid IN A 192.168.3.225
dns IN A 192.168.3.225
ldap IN A 192.168.3.225
ssh IN A 192.168.3.225
nfs IN A 192.168.3.225
mail IN A 192.168.5.200
mail2 IN A 192.168.5.201
Neste arquivo acima, encontramos apenas três tipos de registros, entretanto, existem
mais. Assim, seguem os registros possíveis para os arquivos de zona:
 SOA: Indica o servidor autoritário para a zona que está sendo configurada.
 NS: Lista de servidores de nomes para a zona que está sendo configurada.
 A: Mapeamento do nome para o endereço IP.
 PTR: Mapeamento do endereço IP para o nome.
 CNAME: Nome do alias para os hosts.
 MX: Indica o servidor de e-mail da zona.

Os Registros MX
Os registros MX são usados para o controle da entrega de correspondências. Os

dados especificados no registro são: prioridade e um nome de domínio. A prioridade controla
a ordem na qual a entrega da correspondência será tentada, com o menor número sendo o
primeiro.
Caso existam duas prioridades iguais, o servidor é escolhido aleatoriamente. Se
nenhum servidor em uma determinada prioridade estiver respondendo, o MTA irá tentar a
próxima prioridade. Os números de prioridade não possuem significado especial, eles são
relevantes apenas para os registros MX de um determinado nome de domínio.
O nome do domínio é a máquina que irá receber a correspondência. Ele deve possuir
um registro A associado, um registro CNAME não é o suficiente.
Para um dado domínio, se existir ambos os registros CNAME e MX, o registro M X

estará em erro e será ignorado. Ao invés disso, a correspondência será entregue para o
servidor especificado no registro MX que é apontado pelo CNAME. Vejamos as seguintes
entradas abaixo:
IN MX 20 mail2.sisnet.com.br.
mail.sisnet.com.br. IN A 10.0.0.1
mail2.sisnet.com.br. IN A 10.0.0.2
De acordo com estas entradas, uma entrega de correspondência será tent ada para
os hosts mail.sisnema.com.br e mail2.sisnema.com.br , em qualquer ordem. Caso nenhum
dos dois obtenha sucesso, então o host mail.backup.org será tentado.
Zonas Reversas
As zonas reversas são utilizadas para converter os endereços IPs em nomes de host.
Assim, vamos pegar um trecho do nosso arquivo de configuração /etc/named.conf.
zone "3.168.192.in-addr.arpa" in {
file "master/3.168.192.in-addr.arpa";
type master;
};
O fragmento de configuração acima está definindo o arquivo que possui as

informações para a zona reversa da rede 127.0.0.0/24. Se olharmos o arquivo indicado pelo
parâmetro file, teremos as seguintes informações:

Arquivo sisnet.com.br.rev
$TTL 2D
@ IN SOA sisnet.com.br. hostmaster.sisnet.com.br. (
1 ; serial
3H ; refresh
1H ; retry
1W ; expiry
3H ) ; minimum
6.168.192.in-addr.arpa. IN NS ns.sisnet.com.br.
200 IN PTR mail.sisnet.com.br.
Conforme a descrição acima, podemos perceber que na última linha possui uma
entrada para o registro PTR, o qual é responsável por efetuar o mapeamento do endereço IP
para um nome de host. Assim, podemos presumir que o endereço 192.168.3.225 será
mapeado para o nome mail.instrutor.com.br.
Nota: A opção masters deve aparecer na configuração de zona de um domínio quando

ele é um servidor slave do domínio. No master, as opções allow-transfer e notify devem estar
setadas.
Master
zone "sisnet.com.br" in {
file "master/sisnet.com.br";
type master;
allow-transfer { 192.168.0.0/255.255.0.0; };
notify yes;
};
Slave
zone "sisnet.com.br" in {
file "slave/sisnet.com.br";
type slave;
masters { 192.168.6.200; };
};
7.3. SERVIDOR WEB

A instalação dos pacotes do apache na Distribuição CentOs 6.2, pode ser conferida,
através do comando abaixo

rpm -qa | grep httpd
O resultado do comando acima deverá mostrar os seguintes pacotes;

httpd-2.2.15-15.el6.centos.1.i686
httpd-tools -2.2.15-15.el6.centos.1.i686
httpd-manual-2.2.15-15.el6.cent os.1.noarch
Caso necessário, instale-os através da ferramenta “yum” ( yum install

nome_do_pacote).
Configurando o Apache
O principal arquivo de configuração do servidor Web Apache é um arquivo em texto
puro e está localizado em /etc/httpd/conf/httpd.conf. Este arquivo contém as diretivas para
controlar o comportamento de todo o servidor Web, páginas Web ou outros arquivos
necessários.
Além disso, o arquivo de configuração principal pode incorporar as diretivas

relacionadas ao Apache localizadas em outros arquivos de texto, usando a diretiva include.
Qualquer mudança nestes arquivos somente é reconhecida pelo Apache quando ele é
reiniciado. O arquivo de configuração foi dividido em três seções principais, que são:
 Seção de ambiente global: Diretivas que afetam todas as operações do servidor Web
Apache.
 Seção principal do Servidor: Opções de configuração dedicadas às operações do

Web site primário.
 Seção de Host Virtual: Aqui você pode aplicar as mesmas opções de configurações
disponíveis na seção do servidor para qualquer host virtual.
A sintaxe de configuração é bastante simples. Cada linha contém uma diretiva, e, se

preciso, uma contra-barra (\) pode ser usada como o último caractere na linha, para indicar
que a diretiva continua na linha abaixo.
As diretivas não são sensíveis à caixa, ou seja, não são diferenciadas maiúsculas de
minúsculas. Entretanto, os argumentos para elas, em geral, são. Assim como a maioria dos
arquivos de configuração, o caractere (#) define um comentário, entretanto, um comentário
não pode ser incluído em uma linha depois da diretiva de configuração. Linhas e espaços em
branco que forem encontrados antes de uma diretiva serão ignorados, permitindo às diretivas
serem espaçadas conforme desejado, para facilitar a clareza.
A sintaxe da configuração pode ser verificada com o comando abaixo:
# apachectl configtest

Diretivas Globais
Conforme mencionado, as diretivas globais definem o comportamento do servidor
Apache. A opção mais importante inclui o controle para o número concorrente de acessos que
o servidor irá tratar e como ele irá tratar aquelas requisições quando elas forem aceitas.
O modelo de processamento usado no Apache para Linux é conhecido como Prefork
. Com este método, depois que o servidor é iniciado, diversos processos filhos são criados. O
número de processos e o tipo de usuário são definidos pela diretiva use, no arquivo de
configuração.
Os processos filhos irão atender às requisições uma a uma. Se ocorrer um alto número
de requisições, além do esperado pelo servidor, o processo pai irá criar mais processos filhos
para atender a demanda. Entretanto, existe um número máximo de filhos que ele poderá criar.
Pelo fato de que a criação dos processos filhos é uma operação que demanda muito
recurso computacional, o modelo Prefork cria os processos filhos antes da necessidade deles.
Existem diversas diretivas para controlar o módulo de processamento Prefork,
incluindo:
 StartServers: O número de processos servidores que o processo pai irá iniciar.
 MinSpareServers: O número mínimo de processos servidores disponíveis.
 MaxSpareServers: O número máximo de processos servidores disponíveis.
 MaxClients: O número máximo de processos servidores permitidos a rodarem em um

determinado tempo.
 MaxRequestsPerChild: O número máximo de processos gerenciados.
Abaixo podemos visualizar uma configuração típica do Apache.

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
No exemplo acima, o Apache irá iniciar com 5 processos para gerenciar as requisições
iniciais. O processo pai irá gerenciar os processos filhos decidindo, quando necessário, criar
mais destes para atender a demanda, garantindo que nunca ultrapasse o máximo de 10 e
nem o mínimo de 5.
O servidor não irá atender a mais de 150 requisições. Este limite ajuda a manter o
servidor sem sobrecarregar os recursos computacionais disponíveis.
Pelo fato de que a diretiva MaxRequestsPerChild está com o valor zero, o processo
pai permite que o processo filho gerencie um número ilimitado de requisições durante seu
tempo de vida. Se esta diretiva tivesse um valor positivo, o servidor pai iria limitar o número
de requisições que o filho poderia lidar durante seu tempo de vida. Ou seja, se o processo
filho estiver limitado a gerenciar apenas dez requisições, uma vez que ele termine o

processamento destas requisições, o processo pai terminará o processo filho e criará um novo
para gerenciar mais dez requisições. Esta abordagem especifica dois benefícios:
 Ela limita o número total de memória que qualquer processo pode consumir, limitando
a chance de uma perda de memória acidental.
 Definindo um tempo de vida finito para o processo, ajuda a reduzir o número d e

processos quando o servidor estiver sobrecarregado.
Servidor Principal
A seção do servidor principal cobre as diretivas usado para gerenciar a operação do
site Web primário, o qual o servidor Apache está hospedado. Adicionalmente, os valores
usados para as diretivas nesta seção são usados como valores padrão para qualquer
configuração feita dentro da seção de host virtual.
As opções de configuração mais comuns encontradas dentro desta seção e da seção
de host virtual são os “containers” que operam na configuração de um recurso particular no
sistema de arquivos ou espaço Web:
 Sistema de arquivos: A visualização dos recursos como são vistos pelo sistema
operacional. Por exemplo, no CentOs, as páginas servidas pelo Apache são colocadas
no diretório /var/www do sistema de arquivos.
 Espaço Web: A visualização de um recurso como é visto pelo servidor Web e pelo
cliente. Por exemplo, o caminho /dir no espaço Web pode corresponder ao caminho
/var/www/html/dir, no sistema de arquivos. Os espaços Web não precisam ser
mapeados diretamente para o sistema de arquivo pelo fato de que as páginas podem
ser geradas dinamicamente, a partir de base de dados ou outras localizações.
Os containeres <Directory> e <Files> são diretivas aplicadas aos recursos como

eles são vistos do sistema de arquivos. Diretivas colocadas em um container <Directory> são
aplicadas ao diretório e todos os seus subdiretórios subsequentes.
Por exemplo, na seguinte configuração os índices dos diretórios estarão habilitados
para o diretório /var/www/html/dir e todos os seus subdiretórios.
<Directory /var/www/html/dir>
Options +Indexes
</Directory>
Diretivas colocadas dentro do container <Files> são aplicadas a qualquer arquivo com
o nome especificado, sem se preocupar em qual diretório ele está residindo.
Por exemplo, as seguintes diretivas de configuração negam o acesso a qualquer

arquivo com o nome private.html, indiferentemente de onde ele seja encontrado.
<Files private.html>
Order allow,deny
Deny from all

</Files>
Entretanto, se uma diretiva precisa especificar um arquivo em um determinado lugar

no sistema de arquivos, então os containeres <Files> e <Directory> podem ser usados para
permitir um controle granular dos recursos.
<Directory /var/www/html/dir>
<Files private.html>
Order allow,deny
Deny from all
</Files>
</Directory>
Neste exemplo, a configuração irá negar o acesso ao arquivo

/var/www/html/dir/private.html e a qualquer arquivo, com este nome, que seja encontrado em
diretórios subsequentes ao /srv/www/htdocs/dir.
Na área do espaço Web, a diretiva <Location> opera na configuração dos recursos

encontrados dentro de um ponto de vista. A seguinte configuração de exemplo previne o
acesso à qualquer caminho URL que comece com a palavra /private, como, por exemplo,
http://www.sisnema.com.br/private:
<Location /private>
Order Allow,Deny
Deny from all
</Location>
Ao contrário das diretivas <Directory> e <Files>, <Location> não tem ligação com o
recurso no sistema de arquivos. Isto é útil para conteúdos gerados dinamicamente e que não
possuem localização física no sistema de arquivos.
Estas diretivas estão disponíveis no arquivo /etc/httpd/conf/httpd.conf.
Virtual Hosts
O Apache tem a capacidade de servir mais de uma página simultaneamente. Isto é
conhecido como virtual hosting. Para permitir esta funcionalidade, o arquivo de configuração
do servidor disponibiliza o container <VirtualHost>, para que o administrador possa manipular
nomes de host e domínios em apenas um servidor.
A seção de virtual host é uma reimplementarão simples das diretivas encontradas na

seção do servidor principal, vista anteriormente, apenas direcionadas para um host virtual
específico.
Além disto, pelo fato de que esta seção herda as configurações padrão, definidas para
o servidor principal, só é necessário especificar o que é diferente no host determinado, já que
as outras diretivas foram configuradas anteriormente nas outras seções.

Por exemplo:
<VirtualHost 192.168.0.3>
ServerName linux.sisnema.com.br
DocumentRoot /var/www/linux.sisnema.com.br/html
ErrorLog /var/www/log/linux.sisnema.com.br-error_log
CustomLog /var/www/log/linux.sisnema.com.br access_log combined
<Directory “/var/www/linux.sisnema.com.br/html”>
Options Indexes FollowSymLinks
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
A configuração acima, que é um site rodando em um subdomínio linux do domínio
sisnema.com.br, está esperando conexão no endereço IP 192.168.0.3.
Pelo fato de que nenhuma porta foi especificada para este host virtual, a porta 80
padrão é utilizada. Isto porque esta porta foi definida na seção do servidor principal e através
da herança chega até o host virtual.
O nome do site é linux.sisnema.com.br e a raiz dos documentos, onde os arquivos são
encontrados no sistema de arquivos, é o diretório /var/www/linux.sisnema.com.br/html. Ou
seja, ao acessarmos o endereço http://linux.sisnema.com.br, estaremos acessando este
diretório.
Além disso, os logs para este site serão armazenados em um arquivo separado
daqueles usados para o servidor principal.
Configurando os logs do Apache

Por padrão, os logs do Apache serão colocados no diretório /var/www/log/. Entretanto,
se você desejar, é possível mudar este caminho assim como a forma que o servidor irá efetuar
os logs.
Para fazermos isto, é necessário alterar algumas diretivas no arquivo

/etc/httpd/conf/httpd.conf. Tais diretivas são:
 CustonLog: Define o local para o arquivo de log de acessos.
 ErrorLog: Define o local para o arquivo de log de erros.
 HostnameLookups: Indica ao Apache se ele deve ou não procurar pelos nomes dos
endereços IP que estão conectados nele. É uma boa ideia deixar esta opção
desabilitada, pois o log pode ficar demorado pelo fato de que o servidor precisará
descobrir o nome de todos os IPs conectados nele.
 LogLevel: Esta opção define o quanto de informações devem ser armazenadas nos
logs. O padrão é warn, mas os valores possíveis são debug, info, notice, warn, error,
crit, alert e emerc. Quanto maior o nível do log, menos informação será logada.
 LogFormat: Através desta opção é possível definir o formato que o log será escrito.
Dados como data e endereço IP podem ser colocados em qualquer formato desejado.
As opções padrão geralmente não são alteradas.


7.4. SERVIDOR FTP
O FTP (File Transfer Protocol) é um protocolo de transferência de arquivos.

Tradicionalmente, os sistemas Unix rodavam o servidor FTP por padrão e os usuários
esperavam ser capazes de mover arquivos para os seus diretórios e dos seus diretórios
usando um cliente FTP.
Este era um modo conveniente de acessar o sistema sem precisar se autenticar nele.
Este tipo de uso do FTP tornou-se muito inseguro e desnecessário.
Inseguro pelo fato de que, tipicamente, o nome de usuário e a senha eram enviados
pela rede em texto pleno, permitindo assim, que alguém capturasse essas informações e
usasse de forma indevida. Assim, da mesma forma como o telnet e o rsh tornaram-se
inseguros, o uso do FTP em uma rede pública deve ser usado com cautela.
A reputação de fraca segurança do FTP ficou ainda pior pelo fato de que algumas
implementações do servidor sofreram, durante tempos, sérios problemas de vulnerabilidade,
incluindo exploits que permitiam acesso de root ao cliente, através de buffer overflow e
técnicas como esta.
Um outro ponto importante é sobre a intenção de permitir que os usuários façam
upload de dados. Esta utilização necessita de cuidados extremos de segurança. Se um
servidor FTP permitir o upload anônimo de arquivos, logo em seguida ele poderá estar cheio
de material pirata, pornografia, vírus, cavalos de tróia e outros. Com certeza, este é um ponto
que desejamos evitar.
Entretanto, atualmente podemos encontrar alguns servidores de FTP que se
preocupam com a questão de segurança. Neste capítulo iremos abordar um destes
servidores, chamado vsftpd.
Instalação e Configuração de Servidor de FTP

Para verificar se o pacote do vsftpd se encontra instalado em seu sistema, execute o
comando abaixo:
rpm -qa | grep vsftpd
O resultado deverá ser o mostrado abaIxo:

vsftpd-2.0.5-16.el5_5.1
Caso não se encontre instalado, instale-o através do gerenciador de pacotes do

CentOs, o “yum”:
yum install vsftpd
Após instalado, podemos iniciar a configuração do servidor. Para isso execute o

comando abaixo:
service vsftpd start ( se estiver em configuração “StandAlone”)
service xinetd start ( se estiver em configuração via “xinetd”)

Após inicializado o serviço e reiniciado o daemon “xinetd”, o servidor de FTP já deverá

estar acessível. Isto pode ser comprovado pelo comando abaixo:
netstat –vant
O comando acima, deverá retornar a porta 21/TCP, em estado “LISTEN” (
“escutando”).
Por padrão o FTP disponibiliza apenas o FTP “anônimo” este pode ser acessado
através do user “anonymous” e senha <ENTER>:
ftp 127.0.0.1
Por razões de segurança, este usuário é fortemente limitado. Em geral só pode fazer
“downloads” e não pode sair do diretório de logon, ficando “preso” a este (“chroot jail”). A figura
abaixo ilustra um login bem sucedido, deste usuário:
Depois de feito o processo de login, podemos então executar comandos dentro do

FTP, um deles é o ls, que serve para listar o conteúdo dos diretórios.
A última seta indica a execução do comando para listar o conteúdo do diretório,
entretanto, como é possível observar na figura acima, não existe nenhum arquivo disponível
no servidor.
Nota: Os nomes de usuário anonymous e ftp podem ser usados para logar no servidor
vsftpd de forma anônima, ou seja, qualquer pessoa ou serviço pode utilizar este nome de
usuário, pois eles não necessitam de senha. A senha requerida pelo servidor é uma mera
formalidade, qualquer informação digitada ali é válida, entretanto, utiliza-se o endereço de e-
mail como senha.
O diretório padrão, para os usuários anônimos, é o /srv/ftp. Em outras palavras, o

conteúdo deste diretório será exibido para as pessoas que efetuar o login de forma anônima
no servidor FTP.

Se colocarmos alguns arquivos neste diretório e realizar a listagem de dentro do FTP,

termos uma saída similar à figura abaixo:
Conforme podemos reparar, a seta da figura acima está indicando que agora o FTP
possui um arquivo chamado “Primeiro_Arquivo_no_FTP _Publico”.
Atentem para o fato de que este arquivo não foi colocado lá através do FTP e sim
através do sistema de arquivos, com um comando como o touch, por exemplo.
Depois de vermos que o nosso servidor é capaz de ser executado como um FTP
público com sua configuração padrão devemos olhar o arquivo de configuração para que
possamos fazer nossas próprias escolhas, ou seja, ao invés de utilizar as opções padrões,
nós iremos escolher o comportamento do servidor. O arquivo de configuração principal do
vsftpd é o /etc/vsftpd/vsftpd.conf.
Abaixo estão listadas algumas das opções que podem ser utilizadas neste arquivo de
configuração.
Opção Descrição
write_enable=YES Permite que qualquer um escreva no FTP.
dirmessage_enable=YES Ativa as mensagens para os usuários quando eles entrarem

nos diretórios.
ftpd_banner="Bem Vindo ao Servidor FTP Permite personalizar uma mensagem para os usuários que
efetuarem o login.
Sisnema"
Banned_email_file=/etc/vs ftpd.banned_emails Define qual o arquivo possui os endereços de e-mail que

tem o acesso negado no FTP.
hide_ids=YES Se habilitado, exibe todos os arquivos do FTP como sendo

do usuário e grupo ftp.
local_enable=YES Permite que usuários locais do sistema efetuem o login.
local_umask=022 Define a máscara de permissões para os usuários locais.
chroot_local_user=YES Esta opção define que os usuários não poderão descer

níveis abaixo dos seus homes.
chroot_list_enable=YES Permite a especificação de uma lista para os usuários que

não poderão descer os níveis abaixo dos seus home. Se a
opção ac ima, chroot_local_users estiver habilitada, então a
lista de usuários define os que PODERÃO descer níveis
abaixo do home.

Opção Descrição
chroot_list_file=/etc/vsftpd.chroot_list Especifica a lista para os usuários, de acordo com as

opções acima (chroot_local_user e chroot_list_enable).
local_max_rate=7200 Define a taxa máxima permitida em bytes por segundo. O

valor 0 define que não existe taxa máxima.
anonymous_enable=YES Permite o login de usuários anônimos.
anon_world_readable_only=YES Define que os usuários anônimos só poderão fazer

downloads dos arquivos que podem ser lidos por todos os
usuários.
anon_upload_enable=YES Permite que os usuários anônimos efetuem o upload de

arquivos.
anon_umask=022 Define a máscara de permissões para os arquivos criados

pelos usuários anônimos.
anon_mkdir_write_enable=YES Permite que os usuários anônimos criem diretórios.
anon_other_write_enable=YES Permite que os usuários anônimos apaguem e renomeiem

os arquivos.
anon_max_rate=7200 Define a taxa máxima de transmissão para os usuários

anônimos.
syslog_enable=YES Utiliza o arquivo syslog para fazer os log do FTP.
log_ftp_protocol=YES Efetua o log de todas as requisições e respostas do servidor

FTP.
vsftpd_log_file=/ var/log/ vs ftpd.log Permite definir um arquivo de log personalizado.
connect_from_port_20=YES Define a porta para conexão com o servidor FTP.
idle_session_timeout=600 Define o valor de timeout para conexões ociosas.
listen=YES Permite que o servidor seja rodado sozinho, ou seja,

Sem precisar do xinetd.

De acordo com estas opções, podemos então, configurar o servidor FTP da forma
como desejarmos melhor.
# Exemplo de Configuração para o Arquivo /etc/vsftpd/vsftpd.conf

# Personalizando mensagens
dirmessage_enable=YES
ftpd_banner="Bem vindo ao servidor de FTP Linux Professional"
# Definindo opções para usuários locais
local_enable=YES
local_umask=022
local_max_rate=0
# Definindo opções para usuários anônimos
anonymous_enable=YES
anon_world_readable_only=YES
anon_max_rate=7200
# Definindo logs
log_ftp_protocol=YES
xferlog_enable=YES
xferlog_std_format=YES
xferlog_file=/var/log/xferlog
# Definindo porta de conexão
connect_from_port_20=YES
# Definindo nome utilizado pelo PAM
pam_service_name=vsftpd
# Definindo forma de incialização (xinetd ou standalone)
# listen=YES
Depois de editarmos o arquivo de configuração /etc/vsftpd.conf, reiniciamos o serviço

xinetd.
A figura abaixo ilustra o teste feito após reiniciar o sistema.

Conforme podemos observar, na figura acima, o usuário tourinho consegue realizar o

login (seta superior). Isto é devido ao fato de termos permitido a utilização de usuários do
sistema no servidor de FTP.
Também podemos visualizar os arquivos do diretório pessoal do usuário logado,
indicado pelo comando ls (seta inferior).
Controle de Acesso
Conforme vimos na parte de configuração do servidor de FTP, é possível definir uma
lista de e-mails banidos, quando os usuários efetuam o login através de usuários anônimos.
Entretanto, esta forma não garante que um determinado usuário não vá efetuar o login. Se
quisermos controlar o acesso dos usuários do sistema ao serviço de FTP, precisamos fazer
isso através de um arquivo de configuração.
Este arquivo é o /etc/ftpusers e ele define uma lista de usuário que não poderão efetuar
o login no servidor de FTP. Em geral, este arquivo possui os nomes de usuários como o root,
news, named, mail e outros.
Assim, se quisermos especificar que um determinado usuário, mesmo possuindo uma
conta no sistema, não consiga utilizar o serviço de FTP, basta colocar o nome de usuário
deste no arquivo de controle de acesso.
Nota: É muito importante usar a opção chroot_local_user=YES. Depois do login, ela

fecha o acesso do usuário ao seu diretório home.

7.5. SQUID PROXY
Conceitos de Proxy
O servidor Squid é um dos mais populares servidores de cache para web, também
conhecido como servidor proxy.
Isto significa que ele é responsável por buscar e armazenar cópias locais das páginas
e imagens da web. As máquinas dos clientes, requisitando estes dados, irão obtê-los do
servidor proxy Squid, ao invés de conectar diretamente no site em questão.
Existem diversas razões boas que justificam o uso do servidor proxy Squid ou um
outro servidor de proxy qualquer. São elas:
 Um cache web na rede local significa que os objetos (páginas, imagens, sons e outros)
que já foram requisitados por algum usuário, não precisarão ser buscados de novo de
seu endereço original. Ao invés disto, o servidor cache irá prover estas informações.
Esta ação aumenta a performance para os usuários e reduz o uso de banda da rede.
 Ao mesmo tempo em que isso ocorre, usando um servidor proxy, é possível permitir
um ótimo controle da forma e quando os usuários poderão acessar a web. Além disso, é
possível realizar o log de toda a navegação dos usuários. O Squid também pode ser
usado para prevenir acessos a sites indesejáveis, ou seja, sendo executado em
conjunto com uma lista de palavras, o servidor proxy irá determinar se o usuário
poderá ou não obter as informações desejadas.
 O Squid permite o cache para o protocolo FTP, isto significa que você pode configurar
um Firewall de forma que os usuários não tenham acesso à Internet, diretamente dos

seus computadores. O acesso feito através dos protocolos FTP e hutu serão
gerenciados pelo Squid. Apesar de tirar o direito dos usuários utilizarem outros
serviços na Internet, esta ação permite uma segurança simplificada.
Uma vez que o servidor proxy Squid estiver configurado e rodando, adicionalmente,
todos os navegadores web dos clientes necessitarão ser configurados com as opções corretas
de proxy.
Esta configuração pode se tornar um problema em grandes redes corporativas.
Veremos neste capítulo uma forma de contornar este problema e, ainda assim, utilizarmos um
servidor de cache web.
Instalando e Configurando o Squid
Conforme vimos ao longo dos capítulos apresentados nesta apostila, a instalação no

CentOs pode ser feita através do gerenciador de pacotes “yum”:
yum install squid
O CentOS, em sua versão 6.2, utiliza o Squid 3.1. Para verificar se o mesmo se encontra
instalado, utilize o comando abaixo:
Comando: rpm -qa | grep squid
squid-3.1.10-1.el6_2.2.i686
Algumas configurações iniciais precisam ser feitas no proxy, antes de que o mesmo
se encontre pronto para uso. Para isto precisamos editar o seu único arquivo de configuração
“squid.conf”.
Na versão 6.2 do CentOS, o squid vem com uma versão de arquivo mínima, em seu
diretório de configuração. No entanto, existe uma versão mais completa (inclusive com todas
as linhas de comentários de cada opção), em seu diretório de documentação:
Comando: ls /usr/share/doc/squid-3.1.10/squid*
/usr/share/doc/squid-3.1.10/squid.conf.documented
As opções básicas de configuração que devem ser adicionadas ao arquivo

“squid.conf”, são abaixo refenciadas em negrito, ao final do arquivo:
vim /etc/squid/squid.conf
Arquivo “squid.conf” com opções adicionais

#


# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possibl e internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link- local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025- 65535 # unregistered ports
acl Safe_ports port 280 # http- mgmt
acl Safe_ports port 488 # gss- http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access den y CONNECT !SSL_ports
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR
CLIENTS
#
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
# Squid normally listens to port 3128
http_port 3128
# We recommend you to use at least the following line.
hierarchy_stoplist cgi - bin ?
# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256
# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid


# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern - i (/cgi - bin/| \ ?) 0 0% 0
refresh_pattern . 0 20% 4320
### Configuracoes Adicionais Recomendadas ###
cache_mem 128 MB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/s pool/squid 256 16 256
visible_hostname instrutor
error_default_language Portuguese
Onde:
 Cache_mem: Quantidade de RAM do sistema, utilizada pelo squid;
 Cache_swap_low: Quando o squid volta a cachear apenas em RAM;
 Cache_swap_high: Quando o squid começa a cachear em disco;
 Cache_dir: Define o tipo, tamanho e organização dos diretórios de cache do squid
 Visible_hostname: Define o nome do host, onde está instalado o squid;
 Error_default_language Portuguese: O idioma padrão das páginas de erro;
Após adicionar as opções acima, salve, abandone o arquivo e crie os diretórios de

cache, com o comando abaixo:
squid -z
Os diretórios de cache do squid foram gerados em “/var/spool/squid”:
Comando: ls/var/spool/squid
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
Configurando ACLs no Squid

Uma “ACL”, é uma regra que criamos no squid, definindo um “recurso” a ser controlado
por este. Este “recurso” pode ser um endereço de site, palavra, horário, endereço IP, etc. A esta
“ACL”, associamos um nome, o qual utilizamos para referenciá-la ao definir o tipo de controle
que o squid deverá exercer sobre esta.
O squid pode executar os seguintes controles sobre uma “ACL”:

 Negar o acesso: Utiliza a diretiva de controle “http_access deny”;
 Permitir o acesso: Utiliza a diretiva de controle “http_access allow”;
Sintaxe de uma ACL

A sintaxe de uma “ACL”, obedece ao modelo abaixo:

acl MINHAREDE src 192.168.5.0/24
comando nome acl tipo da acl parâmetros dada acl
Importante: Diretivas do tipo “http_access deny”, têm precedência sobre diretivas tipo
“http_access al low” e, portanto, devem vir listadas antes (isto é, mais acima no arquivo), pois,
uma vez que o squid libere uma conexão, este não volta a fechá-la.
O arquivo squid.conf, também normalmente, possui já predefinidas, uma série de “ACLS”

default. As ACLS do usuário devem ser colocadas logo abaixo da “acl CONNECT”, conforme
indicado no quadro, a seguir:
(Adicione suas acls, a partir desta linha)
#
# Recommended minimum Access Permission configuration:
Definindo uma acl para uma rede

Nesta primeira acl, vamos definir qual rede poderá utilizar os serviços do proxy, para
navegar. Para isto, logo abaixo da acl “CONNECT” (como indicado acima), adicione a acl abaixo:
Diretiva de acesso “http_access” deve, obrigatoriamente, vir ANTES da diretiva indicada

no quadro abaixo:
(adicione aqui suas diretivas htt_acess)
A diretiva “http_access deny all”, existe para que, caso nenhuma acl permita a
navegação, então o proxy, por default bloqueará a navegação dos clientes deste. Deste modo,
o proxy squid opera por default no modo “negar primeiro”. No caso, como desejamos que os
clientes pertencentes a rede nomeada, possam navegar pelo proxy, a diretiva a ser adicionada
será:
http_access allow MINHAREDE
Para que seja possível testar esta e outras acls a partir da própria máquina onde o squid
se encontra instalado, precisaremos também comentar as linhas abaixo, inserindo um “#”, em
seu início:
# http_access allow localnet

# http_access allow localhost
As linhas acima, se descomentadas, permitem o acesso através do endereço local

(127.0.0.1). A seguir, salve, abandone o “squid.conf” e reinicie o squid, com o comando abaixo:
service squid restart
Uma vez iniciado, por default, o squid utiliza a porta 3128/tcp. Para verificar se o squid
está ativo, após iniciá-lo, utilize o seguinte comando:
netstat -vantp | grep 3128
tcp 0 0 :::3128 :::* OUÇA 5005/(squid)
Caso o resultado obtido, indique que a porta 3128, se encontra ativa, configure o
navegador para utilizar o proxy. Encerre as configurações feche o navegador e inicie -o
novamente:
Conforme podemos observar na figura acima, o teste foi realizado com sucesso, ou seja,
o cliente pode realizar uma navegação através do nosso servidor Squid.
Além disso, o Squid também começou a efetuar seus logs. Dentro do diretório
/var/log/squid é possível encontrar o conjunto de logs utilizados pelo servidor.
A seta, na figura acima, está indicando o site que o usuário realizou a conexão. Desta
maneira é possível controlar o acesso dos usuários a qualquer site na Internet.
Nota: Este tipo de controle de acesso, pode ser definido tanto para redes quando para
endereços IPs específicos.
Concatenando ACLs
Algumas vezes, podemos precisar combinar duas ou mais ACLS, de tal forma, que o
acesso deva ocorrer apenas se e somente, todas as ACLs, forem satisfeitas. Neste caso,
precisamos efetuar um “E” lógico. Para obter este efeito, precisamos proceder, conforme
indicado abaixo:
Passo 1: adicione logo abaixo da anterior, a seguinte ACL:

#
### Minhas Acls ###

#
acl HORABOA time MTWHFA 8:00-18:00
Esta ACL, estabelece um período de tempo, a ser controlado, de segunda a sábado
das 8:00 às 18:00h.
Passo 2: Para combinar ambas as ACLS, simplesmente, adicione-as, na mesma linha,

em um única diretiva “http_access”, conforme o exemplo abaixo:
http_access allow MINHAREDE HORABOA
A navegação neste caso, só será permitida se ambas as ACLS (MINHAREDE E
HORABOA), forem satisfeitas.
A seguir, veremos mais alguns tipos de ACLs, muito uteis no controle de acesso:
A. Bloqueio de Site:
acl TERRA dstdomain .terra.com.br
B. Bloqueio de palavra:
acl SEXO url_regex -i sexo
C. Bloqueio de download, por extensão de arquivo:

acl EXTENSOES url_regex -i .exe$ .zip$ .ppt$
D. Bloqueio de portas críticas (evitar “relay de smtp”):

acl DANGEROUS_PORTS port 7 9 19 22 23 25 53 109 110 119
Configurando “Black lists”

Uma “black list” é um arquivo, contendo recursos a serem bloqueados. Dentre estes,
podemos lista, sites indesejados, palavras ou termos, extensões de arquivos, por exemplo.
Para criar uma “black list”, execute o seguinte procedimento, a seguir:
Passo 1: Adicione a seguinte acl ao “squid.conf:

acl PROIBIDOS url_regex -i "/etc/squid/proibidos.txt"
Passo 2: Adicione também ao squid.conf, a diretiva “http_access”:

http_access deny PROIBIDOS

Passo 3: Crie o arquivo “proibidos.txt”, adicionando conforme indicado abaixo:

vim /etc/squid/proibidos.txt
.site1.com.br
.site2.com.br
palavra1
palavra2
.mp3$
.avi$
Adicione sites e palavras reais ao arquivo. Após, salve e abandone o arquivo e reinicie
o squid. É possível também apenas forçar o squid a reler o seu arquivo de configuração. Para
isto use o comando abaixo:
squid -k reconfigure
Após, abra o navegador e procure acessar os recursos listados em “proibidos.txt”.

Estes deverão ser bloqueados pelo proxy.
Autenticação de Usuários
Um dos requisitos mais desejados, após a instalação de um servidor proxy, é saber
qual usuário está acessando uma determinada página. Assim, através da autenticação de
usuários podemos garantir que apenas os usuários de dentro da nossa rede estejam
utilizando o serviço do nosso Squid.
Uma das formas mais simples de fazer isso é usando uma forma de autenticação
qualquer existente, na máquina onde o servidor Squid está rodando, através do PAM. Para
que isso seja possível, você precisará definir a seguinte opção no arquivo de configuração do
Squid.
auth_param basic program /usr/sbin/pam_auth
Esta linha indica que a autenticação deve ser feita através do PAM. Seja qual for o
método de autenticação usado, por exemplo, /etc/passwd, NIS, LDAP ou outro qualquer, ele
será usado agora para o Squid.
Precisamos, também, forçar que os usuários se autentiquem para utilizar o serviço.
Isso é conseguido através da linha abaixo:
acl redelocal_auth proxy_auth REQUIRED
http_access allow redelocal_auth
Depois de reiniciarmos o servidor com a nova configuração, a cada vez que abrirmos
o nosso navegador e tentarmos iniciar a navegação, um usuário e senha serão exigidos.

Conforme podemos observar, na figura acima, uma nova janela irá aparecer após
digitarmos qualquer endereço para navegação web.
Nesta janela, devemos digitar um nome de usuário e uma senha correspondendo, o
que é indicado pelas setas na figura acima.
Autenticado o usuário corretamente, é possível então continuarmos a navegação pelas
páginas na Internet. Além disso, o Squid irá continuar o seu processo de registro nos arquivos
de log, entretanto, agora com uma diferença. Ele irá logar o nome do usuário que está
acessando determinado site.
Para melhor combinar a autenticação com o acl que define a rede local, podemos
utilizar a seguinte configuração.
auth_param basic program /usr/sbin/pam_auth
acl redelocal_auth proxy_auth REQUIRED
acl redelocal src 192.168.0.0/24
http_access deny !redelocal
http_access allow redelocal_auth
...
Em outras palavras, esta configuração define que será negado o acesso a todos que
não estiverem na rede definida antes que seja forçada a autenticação. Então é permitido o
acesso do segmento de rede. Como dito anteriormente, se necessário, é possível definir
endereços IP individuais para os ACLs.
Este tipo de autenticação usa o método de autenticação padrão do HTTP, ou seja, isto
significa que o par usuário/senha será transmitido pela rede no formato codificado ba se64.
Em outras palavras, não é transmitido em texto puro, mas também não é criptografado.
Se um método de autenticação está sendo usado e que também está a disposição
para outros propósitos no servidor, existe um risco de segurança eminente, o que
potencialmente pode compromissar as contas dos usuários no servidor.
Para evitarmos este risco, podemos usar o método de autenticação digest_pw_auth.
Se desejarmos implementar este método, então precisaremos adicionar as seguintes linhas
no arquivo de configuração.
auth_param digest program /usr/sbin/digest_pw_auth /etc/squid/digestpw

auth_param digest children 5

auth_param digest realm Squid proxy-caching web server
Com estas opções, você estará definindo um arquivo de senhas /etc/squid/digestpw

que irá possuir os usuários e suas correspondentes senhas no seguinte formato
nomeusuario:senha
As senhas são armazenadas em texto puro, por este motivo o dono do arquivo e grupo
devem ser squid:root e com permissão 600, ou seja, apenas o usuário squid poderá ler e
escrever no arquivo e mais nenhum outro usuário do sistema. Desta maneira, quando uma
sessão do cliente for iniciada, o Squid irá autentica-la usando as informações do arquivo
/etc/squid/digestpw. Entretanto, isso não significa que a senha precise ser enviada p ela rede.
Ao invés disso, o servidor e o cliente podem calcular a chave MD5 ou uma hash de uma via
baseada na senha e na URL.
O cliente então envia o resultado do seu cálculo para o servidor, que irá comparar
estas informações com os seus cálculos. A maior ia dos navegadores web irá operar
corretamente com esta forma de autenticação.
O Arquivo de Log
O principal arquivo de log do Squid, por padrão, é o arquivo de nome

/var/log/squid/access.log.
Os logs do Squid são muito extensos e complicados de ler, por este motivo, uma série
de ferramentas de análise destes logs está disponível. O CentOs utiliza uma ferramenta
chamada sarg (Squid Analysis Report Generator). Se você quiser usar esta ferramenta, ela
deve ser instalada à parte do servidor, ou seja, ela é disponibilizado em outro pacote, chamado
SARG.
O SARG gera uma saída HTML que pode ser analisada pelo administrador da rede de
forma mais clara. A figura ilustra a página principal dos logs.

Como podemos perceber, a página principal do sarg permite selecionar os logs

distribuídos por datas, ou seja, se o administrador deseja encontrar informações em certo dia,
ele irá procurar nos logs do dia escolhido.
Depois de escolhido o dia, outra forma de classificação é permitida, conforme podemos
visualizar na figura abaixo.
Na figura ilustrada acima, podemos visualizar que, para este log específico, as
informações foram classificadas como:
Topsites: Relação dos sites mais acessados.
Sites & Users: Relação dos sites e dos usuários que acessaram eles.
Denied: Informações sobre os sites que foram negados.
Authenticatioin Failures: Dados sobre as tentativas de autenticação que não
puderam ser concluídas com sucesso pelo servidor Squid.
Assim, se quisermos informações sobre os sites mais acessados, precisamos apenas

clicar sobre o link. A figura abaixo ilustra tais informações.

A figura acima nos mostra os sites mais acessados pelos usuários do servidor proxy.
Com base nestas informações, o administrador é capaz de saber, por exemplo, as
características dos usuários de seu proxy, além, é claro, de encontrar sites muito utilizados e
que deveriam estar na black list.
Nota: O arquivo de configuração do sarg fica em /etc/sarg.conf. Para gerar os

relatórios, basta executar o comando sarg –xz.

7.6. SAMBA
Introdução ao Samba e Protocolo SMB
Andrew Tridgell foi o criador do Samba. Atualmente ele lidera a equipe de

desenvolvimento. Seu projeto iniciou em 1991, quando ele trabalhava com um conjunto de
softwares da DEC (Digital Equipment Corporation) chamado Pathworks, criado para conectar
computadores DEC VAX a computadores feitos por outras empresas.
Sem saber o que estava fazendo, Andrew criou um programa de servidor de arquivos
para um protocolo estranho que fazia parte do Pathworks. Este protocolo posteriormente se
tornaria o SMB. Alguns anos mais tarde, ele expandiu por conta própria o servidor SMB e
começou a distribuir seu produto pela Internet com o nome “SMB Server”.
Entretanto, Andrew não pode manter este nome, que já pertencia a uma outra
empresa. Assim, para criar um nome para o seu servidor ele tentou a seguinte abordagem,
pesquisa por palavras no dicionário que tivessem as letras S, M e B. Para isso ele usou o
comando abaixo:
# grep -i '^s.*m.*b' /usr/share/dict/words
A saída deste comando foi a seguinte:

salmonberry
samba
sawtimber
scramble
Foi assim nasceu o nome “Samba”. Irônicamente, Tridgell, nunca tinha ouvido falar
nesta palavra antes e, muito menos, a associará com o nome de nosso País. O Samba é um

conjunto de aplicação para os sistemas Unix e Unix -Like que utilizam o protocolo SMB (Server
Message Block). Os sistemas operacionais Windows e OS/2 usam o SMB para compartilhar
arquivos e impressoras pela rede baseado na arquitetura cliente / servidor. Suportando este
protocolo, o Samba permite que computadores Linux também utilizem esses
compartilhamentos.
Ou seja, através do Samba é possível fazer o Linux passar-se por um sistema
Windows na rede, garantindo as sim que todas as operações feitas por um sistema Windows
verdadeiro sejam feitas pelo sistema Linux utilizando o Samba.
O servidor Samba oferece os seguintes serviços:

 Compartilhamento de uma ou mais árvores de diretórios;
 Compartilhamento de uma ou mais árvores de sistemas de arquivos distribuídos;
 Compartilhamento de impressoras instaladas de rede;
 Autenticação de clientes de domínios Windows;
 Resolução de nomes com o WINS (Windows Internet Name Service);
Além disso, o conjunto de aplicações Samba inclui ferramentas para clientes,

permitindo assim que usuários em sistemas Linux acessem pastas e impressoras em sistema
Windows.
Como funciona a integração com ambientes Microsoft

Conforme vimos, de forma prévia, o Samba utiliza um protocolo de comunicação
chamado SMB. Este protocolo é encontrado acima do TCP/IP.
Embora seja perfeitamente possível a coexistência pacífica de ambos os tipos de rede,
(Windows e Linux) em um mesmo ambiente corporativo, existem algumas razões que auxiliam
na definição de instalar um servidor Samba. São elas:
 Se você não deseja pagar, ou não pode pagar por um conjunto completo de servidores
Windows e ainda assim precisa das funcionalidades providas por eles.
 Ainda que você esteja disposto a pagar pelas licenças dos servidores Windows, cada
cliente Windows necessita de uma licença de acesso, camada CAL (Client Acess
Licenses). O custo destas licenças é extremamente elevado.
 Se você deseja prover uma área comum de dados, ou diretórios, para a transição de
um servidor Windows para um Linux e vice-versa.
 Se você deseja compartilhar impressoras entre estações Windows e Linux.
 Se você deseja integrar a autenticação Linux e Windows, mantendo apenas uma base
de dados com as contas dos usuários para ambos os sistemas.
A figura abaixo ilustra uma rede típica usando o serviço de compartilhamento de

arquivos e impressoras Samba.

A rede ilustrada na figura acima exemplifica uma das utilizações do Samba. A rede é
composta por três estações clientes, sendo duas delas Windows e uma Linux, um servidor
Samba e uma impressora.
A impressora encontra-se ligada diretamente ao servidor. Este servidor disponibiliza o
compartilhamento da impressora para todos os clientes da rede, a través do protocolo SMB.
Desta forma, os clientes Windows e Linux poderão acessar e utilizar a impressora.
Este é um exemplo básico. Conforme dito anteriormente, o Samba permite que
diversos recursos sejam compartilhados na rede além de outras funcionalidades.
O que é o protocolo SMB

O protocolo SMB (Server Message Block Protocol) providencia um método para as
aplicações clientes, em um computador, serem capazes de ler e escrever arquivos em
programas servidores e requisitar serviços deles também, através de uma rede de
computadores.
O protocolo SMB pode ser usado pela Internet no topo do protocolo TCP/IP ou no topo
de outros protocolos de redes, como o IPX (Internetwork Pack et Exchange) e o NetBeui.
Através deste protocolo, aplicações podem acessar arquivos em um servidor remoto,
assim como outros recursos incluindo impressoras, scanners e outros.
Desde o Windows 95, os sistemas operacionais da Microsoft incluem um cliente e um
servidor do protocolo SMB. No Linux, o conjunto de aplicações Samba está disponível.
Este protocolo, originado pela Microsoft, passou por diversos números de
desenvolvimentos. Um determinado servidor e cliente podem implementar um conjunto de
protocolos variantes, os quais são negociados antes de se iniciar uma sessão.

Instalando o Samba
No CentOs, versão 6.2, a instalação do Samba, abordada nesta seção, poderá ser
feita através do gerenciador “yum”. Para isso, os seguintes pacotes deverão ser instalados:
rpm -qa | grep samba
 samba-common-3.5.10-114.el6.i686
 samba-3.5.10-114.el6.i686
 samba-client-3.5.10-114.el6.i686
 samba-winbind-clients-3.5.10-114.el6.i686
Configurando o Samba
Nesta seção veremos a configuração do arquivo smb.conf, o principal arquivo de
configuração do samba.
O arquivo de configuração do Samba é chamado smb.conf e pode ser encontrado no
diretório /etc/samba/. Este arquivo pode ser muito simples ou extremamente complexo de se
configurar, tudo vai depender das funcionalidades esperadas do Samba.
Por enquanto, veremos como configurar um simples servidor de arquivos, que irá
permitir a você visualizar a inicialização dos processos do Samba e ver o serviço sendo
utilizado.
O processo de instalação não cria o arquivo de configuração automaticamente,
entretanto, diversos exemplos de configuração para ele estão disponíveis nos pacotes de
documentação do Samba. Como o arquivo de configuração não é criado automaticamente,
iremos criar ele com um editor de texto qualquer.
vim /etc/samba/smb.conf
Após isso, iremos então adicionar algumas linhas de configuração para vermos o
nosso servidor Samba rodando:
[global]
workgroup = workgroup
[public]
comment = Primeiro servidor SMB
path = /home/samba/public
read only = no
guest ok = yes
Esta simples configuração está dizendo para o servidor Samba oferecer o diretório
/home/samba/public, como um diretório compartilhado chamado “public”. Além disso, o
servidor irá fazer parte do grupo de trabalho chamado workgroup.

Testes
Depois de editarmos o arquivo de configuração, precisamos então, iniciar o servidor
Samba. Na versão 6.2 do CentOS, os serviços “smbd” e “nmbd” são ativados separadamente,
portanto, para ativar o samba, precisamos executar os comandos abaixo:
service smb start
service nmb start
Uma vez ativado o samba, podemos efetuar os seguintes testes:

a) Visualizar suas portas:
netstat -ln | egrep ":((137)|(138))|(139)"
b) Verificar a sintaxe do arquivo de configuração:

testparm
c) Verificar se o SAMBA está escutando os clientes:

smbclient -L 127.0.0.1
A saída deste último comando, deve ser similar a mostrada a seguir:

smbclient - L 127.0.0.1
Enter root's password:
Anonymous login successful
Domain=[TUX- NET200] OS=[Unix] Server=[Samba 3.5.10- 114.el6]
Sharename Type Comment
--------- ---- -------public Disk Acesso Publico
IPC$ IPC IPC Service (Samba Server Version 3.5.10 - 114.el6)
Anonymous login successful
Domain=[TUX- NET200] OS=[Unix] Server=[Samba 3.5.10- 114.el6]
Server Comment
--------- -------EDUC- 2 Samba Server Version 3.5.10- 114.el6
Workgroup Master
--------- -------TUX- NET200
O comando smbclient ao ser executado acima deverá lis tar todos os

compartilhamentos oferecidos pelo servidor SAMBA. A senha a ser digitada, corresponde ao
simples pressionamento da tecla <ENTER>.
Depois de iniciado o servidor, podemos visualizá-lo em operação, utilizando, por
exemplo, a ferramenta de gerenciamento de redes de um Cliente Windows, conforme abaixo:

Na parte superior da figura existe uma seta. Esta seta está indicando o endereço do
servidor que está rodando o Samba, 192.168.0.7.
Existem duas formas para chegarmos ao compartilhamento que criamos com o
Samba: a primeira é através da utilização do endereço explícito do servidor, como é indicado
pela seta superior.
A segunda forma é através da navegação pelas redes do Windows, conforme é
indicado pela seta mais abaixo e a esquerda, onde podemos ver o grupo de trabalho
workgroup, definido na configuração do arquivo /etc/samba/smb.conf.
Por fim, podemos visualizar o compartilhamento criado, chamado teste. A seta
encontrada mais à direita da tela está indicando ele. Também podemos ver a descrição do
compartilhamento que definimos no arquivo de configuração do Samba.
Este arquivo de configuração do Samba é dividido em um número de seções primárias,

cada uma delimitada pelo nome da seção, que é colocado entre colchetes. A única seção
obrigatória neste arquivo é a [global].
Veremos agora as seções que são geralmente encontradas na configuração deste
arquivo.
 [global]: Configurações gerais, como informações de autenticação e grupo de trabalho

ou domínio. Estas configurações serão aplicadas ao longo do arquivo smb.conf.
 [groups]: Configurações para um conjunto de diretórios compartilhados que são

pertencentes aos grupos do Linux.
 [homes]: Configurações para os diretórios pessoais (home) dos usuários do Linux, que
serão compartilhados pelo Samba.
 [pdf]: Configurações para o gerador de arquivos PDF provido pelo Samba.
 [print$]: Configurações para um compartilhamento geralmente usados para guardar

drivers de impressoras que podem ser usadas por clientes Windows.
 [printers]: Configuração sobre impressoras que estão disponíveis via Samba.
 [users]: Configurações para o compartilhamento de todos os diretórios home dos

usuários do Linux.
Conceitos de Redes Microsoft

O conceito de “workgroups” ou grupos de trabalho surgiu no Windows 3.11 e por isso
esta versão recebeu a designação “Windows for Work groups”. O conceito de grupo de
trabalho permite realizar o agrupamento de acordo com uma determinada organização lógica.
Os grupos de trabalho da Microsoft obedecem a uma filosofia "peer-to-peer" onde as
estações de trabalho são simultaneamente clientes e servidores. Assim, o termo "servir"
arquivos, diretórios e impressoras é então substituído por "compartilhar".

Desta maneira, através das redes Microsoft, podemos realizar o compartilhamento de

recursos através da rede.
Por exemplo, uma determinada máquina da rede possui uma impressora
compartilhada.
Uma estação de trabalho, também na rede, pode utilizar a impressora remota como se
estivesse conectada localmente.
Como dito, além de impressoras, as redes Windows permitem compartilharmos dados
também.
Arquivo smb.conf
[global]
netbios name = Linux
workgroup = sisnema
passdb backend = smbpasswd
os level = 33
preferred master = auto
domain master = yes
local master = yes
security = user
domain logons = yes
logon path = \\%N\profiles\%U
logon drive = H:
logon home = \\linux\%U\winprofile
logon script = logon.bat
[netlogon]
path = /var/lib/samba/netlogon
read only = yes
[homes]
browseable = no
writeable = no
available = yes
public = no
only user = yes
[profiles]
path = /var/lib/samba/profiles
read only = no
create mask = 0600
directory mask = 070

Instalando o Samba como um PDC

A utilização dos grupos de trabalho para efetuar o compartilhamento de recursos pode
ser uma saída rápida e fácil para as pequenas redes.
Entretanto, o compartilhamento através destas redes, também conhecidas como redes
domésticas, não garantem qualquer segurança.
Para que possamos realizar o compartilhamento com segurança, precisaremos então
utilizar o conceito de domínios de controle.
Os domínios de controle podem garantir que determinadas máquinas são confiáveis,
e assim, possam acessar os dispositivos compartilhados através de um processo de logon na
rede controlada pelo PDC (Primary Domain Controller).
Para configurarmos o Samba como um PDC, precisaremos alterar seu arquivo de

configuração /etc/samba/smb.conf e colocar as seguintes linhas:
Assim, os parâmetros acima são explicados abaixo:

 passdb backend: Contém as informação das contas dos usuários e grupos. Valores
aceitáveis para um PDC são: smbpasswd, tdbsam e ldapsam.
 Domain Control Parameters: Os parâmetros os level, preferred master, domain

master, security, encrypt password e domain logons realizam a garantia de um controle
central para o domínio e para o suporte de logon de rede. O parâmetro os level deve
possuir o valor 32 ou acima dele.
 Environment Parameters: Os parâmetros logon path, logon home, logon drive e

logon script são configurações de suporte que ajudam a facilitar o logon do cliente e a
automatizar o gerenciamento da rede.
 Compartilhamento NETLOGON: Este compartilhamento efetua uma posição central

no logon do domínio e no suporte aos membros do domínio. Este compartilhamento é
providenciado em todos os controladores de domínio Microsoft. Ele é usado para
prover os scripts de logon, para armazenar arquivos de políticas de grupo e outros.
 Compartilhamento PROFILE: Este compartilhamento é usado para armazenar os

perfis dos usuários das estações de trabalho. Cada usuário deve possuir um diretório
na raiz deste compartilhamento.
Nota: Deve ser setado na estação o endereço wins, apontando para o endereço ip do
servidor samba.
A estação deve ser criada no servidor, assim como o usuário. Então, temos que criar
a estação no sistema e depois no samba. Por exemplo, para criar a estação devemos digitar
os seguintes comandos: useradd –c winxp -s /bin/false winxp$; smbpasswd –m –a winxp$.
Devemos ainda, criar o usuário root no samba, pois é ele o usuário administrador que deve
ser usado para inserir uma estação no domínio, para isso, usamos o seguinte comando:
smbpasswd –a root; smbpasswd –e root.

O script de logon do sistema pode ser usado para mapear um compartilhamento e

ajustar à hora da estação.
### SCRIPT DE LOGON ###
echo ajustando a hora
net time \\linux /set /yes
net use p: \\linux\profiles

Serviço de Diretório LDAP
Conceitos sobre LDAP

O LDAP (Lightweight Directory Access Protocol) é um protocolo que permite a
qualquer um localizar organizações, pessoas individuais e outros recursos como arquivos e
dispositivos em uma rede, tanto na rede pública Internet quando em uma rede Intranet. O
LDAP é uma versão leve (lightweight) do protocolo DAP (Directory Access Protocol), que é
parte de um padrão para serviços de diretório em rede, chamado X.500.
Mais “leve”, pelo fato de que foi implementado na camada de Rede do OSI, permitindo
um número de linhas de código menor. Originado na Universidade do Michigan, o LDAP é
amplamente adotado hoje, sendo homologado em através de várias RFCs. Contudo, antes
de estudá-lo, convém definir o que vem a ser um “Diretório”:
Definindo Diretório
De modo simples e direto o termo “Diretório”, significa simplesmente um “catálogo de
índices”, portanto, um “Serviço de Diretório”, nada mais é do que um banco de dados
especializado, utilizado nos processos de autenticação de serviços de rede.
“Especializado”, porque, ao contrário de um banco de dados “SQL”, as informações
contidas neste banco, devem ser frequentemente lidas e só mais raramente alteradas
(exemplo: nomes de usuários, senhas, e-mails, etc). Além disso, e, novamente, ao contrário

de um banco de dados tradicional, um “serviço de diretório” não trabalha com tabelas, mas
sim com “objetos”:
Cada objeto possui atributos e propriedades que os definem. Dizemos, portanto, que
um “serviço de diretórios” é “orientado a objetos”. Um banco de dados utilizado em um “serviço
de diretório”, deve ser muito veloz para operações de leitura, embora não importe muito se
não possuir a mesma performance para operações de escrita, visto que seu conteúdo é pouco
alterado.
Objetivos de um “Serviço de Diretório”

 Unificar o processo de autenticação de serviços de rede;
 Centralizar todas as informações de consulta frequente, em uma rede;
 Reduzir as tarefas de administração ao longo de uma rede ampla e descentralizada;
Podemos tranquilamente afirmar, que toda Empresa ou Organização que ainda não
faça parte de um “serviço de diretório”, terminará fazendo parte de algum, mesmo que não o
implemente, pois acabará integrando o banco de alguma outra organização.
Por se tratar de um serviço homologado Internacionalmente através de “RFCs”, não
corremos o risco de ficarmos “escravos” de algum banco de dados “proprietário”. Existem
numerosas implementações de terceiros deste serviço, todas obedecendo aos parâmetros
estabelecidos em suas RFCs. Alguns dos mais utilizados são:
 O “NDS” (NetWare Directory Services), da Novell; A Microsoft inclui ele como parte do
que eles chamam de AD (Active Directory).
 O “etrust”, da Computer Associates; A Novell usa o LDAP em seu NetWare Directory

Services.
 O “AD (Active Directory)” da Microsoft;
 O “OpenLdap”, este último opensource e, alvo do presente trabalho;
Para assegurar a compatibilidade entre as várias implementações existentes, foi criado

um padrão universal de importação de dados, através de arquivos texto de formato especial,
chamados “ldif” (Ldap Data Interchange Format). Deste modo, é possível se extrair todas as
informações de um banco ou, pelo contrário, alimentar um banco de dados através deste
método. Abaixo, um exemplo bem simples deste tipo de arquivo:
dn: dc=sisnema,dc=com,dc=br
objectclass: top
objectclass: domain
dc: sisnema
OID (Object Identifier)

Como dito anteriormente, um “serviço de diretório”, organiza seus dados sob forma de
“objetos” e, cada objeto possui “propriedades”, que são os atributos que o definem. Estes
“objetos” são referenciados através de um número de formato especial, chamado de “OID”
(Object Identifier), um “OID”, descreve perfeitamente um objeto e seus atributos, sem
possibilidade de erro. Abaixo, um exemplo de um “OID”:
1.3.6.1.4.1.2
O conceito de OID é bastante similar ao conceito de uma “MIB”, do protocolo de

gerenciamento de redes SNMP o qual, por sua vez, também é mantido e administrado pelo
IANA.
Muitas “OIDs” são registradas e podem ser encontradas no site do “IANA” (iana.org ),
a OID acima, por exemplo, é a OID que descreve a empresa IBM, e pode ser encontrada na
seguinte url: http://www.alvestrand.no/objectid/1.3.6.1.4.1.html.
Schema
Podemos definir o “schema”, como um “mapa”, que informa o banco de dado s do
“serviço de diretório”, sobre como compreender o objeto e seus atributos. Como dito
anteriormente, um “serviço de diretório” pode armazenar muitos tipos diferentes de dados,
cada dado possuindo seus próprios atributos. Sendo assim deve existir um modo de se instruir
o banco de dados, sobre como “funciona” o objeto. Este meio é o “schema”, que é um arquivo
texto, que descreve o objeto e seus atributos. Sem o “schema”, os objetos, não têm significado
útil para o banco. Abaixo, um pequeno fragmento de um arquivo de “schema”:
...
attributetype ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
...
Fragmento do arquivo /etc/openldap/esquema, “cosine.schema”
No “openldap”, os arquivos de “schema”, são encontrados no diretório

“/etc/openldap/schema”.
Organização de uma “Árvore de Diretórios” LDAP
O LDAP é organizado em uma árvore hierárquica que possui os seguintes níveis.

 O diretório raiz (ponto inicial), com ramos para
 Países, cada um com ramos para
 Organizações, cada um com ramos para
 Unidades organizacionais (divisões, departamentos e assim por diante), com ramos

para

 Indivíduos (que podem ser pessoas ou recursos como impressoras, por exemplo). Um
diretório LDAP pode ser distribuído também entre muitos servidores. Cada servidor
pode ter uma versão replicada de todo o diretório que é sincronizado periodicamente.
Este protocolo utiliza uma base de dados em árvore, no formato de “árvore invertida”,
similar ao “DNS”, ou então a um sistema de arquivos: No topo desta árvore existe o objeto
base, que é o nome da organização. Abaixo, existem as pastas, que contém os objetos
contidos no banco. No ldap, estas pastas recebem o nome de “OUs” ou “unidade
organizacional (organizational unit)”. No exemplo, a figura abaixo ilustra o diagrama
organizacional de uma empresa:
Quando você pensar no LDAP, não pense no nível tecnológico e sim no nível
organizacional. O LDAP deve seguir o formato de como a organização armazena seus dados.
No exemplo ilustrado pela figura acima, nós temos um diagrama fictício da empresa
SISNEMA. A SISNEMA, assim como a maioria das empresas, possui direções para tratar de
assuntos relacionados com vendas, contabilidade e ensino.
Além disso, podemos perceber que a direção de vendas é responsável pelo setor de
vendas, assim como a direção de ensino é responsável pelos instrutores.
Todas as pessoas desta empresa pertencem a algum setor, que pertence a alguma
direção. Esta é a forma como você deve enxergar o LDAP. Você pode ver que a estrutura de
árvore permite uma ótima organização dos dados da empresa.
Portanto e, idealmente, o LDAP deve obedecer tanto quanto possível a estrutura
contida no organograma da empresa. Por exemplo, se uma pessoa chamada “Michel Alves”
for hipoteticamente, contratada para trabalhar na empresa SISNEMA como instrutor, podemos

descrever esta pessoa através do caminho completo na árvore de diretório do banco de

dados.
No exemplo a seguir, isto fica mais claro:
“cn= Michel Alves, ou=Instrutores,ou=Direção de Ensino,dc=Sisnema,dc=com,dc=br”
Podemos ver, então, que o funcionário Michel Alves está na empresa SISNEMA, da
Direção de Ensino e do setor de Instrutores. Esta pessoa é única sendo instrutor, da mesma
forma como é única no diretório LDAP. Este identificador único é chamado dn ( Distinguished
Name) ou “nome distinto” e identifica perfeitamente um objeto dentro de um banco Ldap, não
permitindo dúvidas ou ambiguidades a esse respeito.
Formas de se descrever uma Base Ldap

Atualmente, existem dois padrões para descrever a base (topo) de banco de dados
LDAP:
 Padrão Novell: o=Empresa,c=País
 Padrão Microsoft: dc=Empresa,dc=com,dc=br
Onde:
O = Organização (geralmente, o nome da empresa);
Dc = Domain Component, é uma forma de descrição criada pela Empresa Microsoft,
que segue a estrutura de uma árvore “DNS.
Qual dos formatos será utilizado depende, sobretudo, do formato empregado pelas
aplicações que serão usadas: Se utilizadas muitas aplicações “Novell”, torna-se mais prático
descrever a base do primeiro modo. Por outro lado, a grande difusão de aplicações
“Microsoft”, torna o segundo método mais usual hoje em dia. Este último padrão também será
usado no decorrer deste capítulo.
Implementando um Servidor OpenLDAP

Passaremos a partir deste ponto, a discutir a implementação do serviço de diretório
openldap. Inicialmente, vamos verificar se os seguintes pacotes estão instalados em seu
sistema:

Pacotes OpenLDAP
python-ldap-2.3.10-1.el6.i686
apr-util-ldap-1.3.9-3. el6_0.1.i686
ldapjdk -4.18-6.el6.i686
pam_ldap-185-11.el6.i686
krb5-server-ldap -1.9 -22. el6_2.1.i686
nss-pam-ldapd-0.7.5-14.el6_2.1.i686
php-ldap-5.3.3-3.el6_2.6.i686
openldap-devel -2.4.23- 20.el6.i686
openldap-servers -2.4.23-20.el6.i686
openldap-2.4.23-20.el6.i686
openldap-clients-2.4.23- 20.el6.i686
Você pode conferir se os mesmos se encontram instalados através do comando RPM

–qa | grep “pacote”. Exemplo:
 rpm –qa | grep ldap
Caso esteja faltando algum pacote, basta instalá-lo através do “yum”, conforme já
mostrado anteriormente.
Procedimentos de Configuração
Uma vez instalados os pacotes referidos acima, precisamos agora configurar o
openldap. A configuração deste serviço mudou bastante a partir da versão 2.4. Na Distribuição
CentOS 62, para configurar o servidor openldap, execute os passos abaixo:
Passo 1: Incialmente, mude para o diretório /etc/openldap/slapd.d/cn=config. Toda a

configuração do openldfap, será feita, a partir deste diretório:
cd /etc/openldap/slapd.d/cn=config
Passo 2: Copie o arquivo de configuração do banco de dados Berkley (a database

default do openldap), para o seu diretório de configuração definitivo:
cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
Passo 3: Adicione direitos de posse ao usuário “ldap”, para que o daemon “slapd”
possa gerenciar essa base:
chown -R ldap:ldap /var/lib/ldap
Passo 4: Gere a senha de acesso do usuário manager do banco ldap. Esta senha
precisar ser mais tarde, colada dentro do arquivo de configuração do ldap:
slappasswd
slappasswd
New password:
Re- enter new password:
{SSHA}IMHnms2zHiIFbM5LYnlacTshL5e4SjTm

Nota: Por motivos didáticos e de facilidade de configuração, aqui utilizaremos a senha

padrão “secret”, que deverá ser digitada após o comando “slappasswd”.
Passo 5: A seguir, com o editor vim, abra o arquivo olcDatabase={2}bdb.ldif e altere

os campos mostrados a seguir:
vim olcDatabase={2}bdb.ldif
Primeiro, edite a linha :

olcSuffix: dc=my-domain,dc=com
Modifique para:
olcSuffix: dc=sisnema,dc=com,dc=br
A seguir, edite a linha olcRootDN:

olcRootDN: cn=Manager,dc=my -domain,dc=com
Modifique para:
olcRootDN: cn=Manager,dc=sisnema,dc=com,dc=br
Finalmente, configure a senha de autenticação do usuário “manager”, que terá direito

de gerenciar o banco ldap. Para isso, logo abaixo de “olcRootDN”, inclua a linha abaixo:
OlcRootPW: (cole aqui o “hash” da senha gerada com o comando slapasswd)
Salve e feche o arquivo “cn=config” e passe para o próximo arquivo a ser editado.
Passo 6: Edite o arquivo “olcDatabase={1}monitor.ldif”, conforme abaixo indicado:

vim olcDatabase={1}monitor.ldif
Altere a linha:
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa
l,cn=auth" read by dn.base="cn=manager,dc=my - domain,dc=com" read by * none
Para:
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa
l,cn=auth" read by dn.base="cn=manager, dc=sisnema,dc=com ,dc=br " read by * none
Uma vez mais, salve e abandone o arquivo.

Passo 7: Teste a sintaxe dos arquivos de configuração do openldap:

slaptest -u
slaptest - u
config file testing succeeded
Se a mensagem obtida for similar à acima mostrada, então podemos passar a etapa
seguinte. Do contrário, precisaremos rever a edição dos arquivos configurados, pois,
provavelmente, algum erro de configuração deve ter ocorrido.
Passo 8: Subir o daemon “slapd”, para isto executando o comando abaixo:

service slapd start
Você pode se certificar do sucesso deste comando, através do comando abaixo:

netstat –ln | grep 389
Caso ocorra tudo conforme o esperado, deve aparecer a porta 389/TCP em “LISTEN”
Passo 9: Importar os arquivos “base.ldif” e “containers.ldif”, para dentro do banco ldap,

com os comandos abaixo:
ldapadd –W –D “cn=manager,dc=sisnema,dc=com,dc=br” -f base.ldif –x
ldapadd –W –D “cn=manager,dc=sisnema,dc=com,dc=br” -f containers.ldif –x
Onde:
“-W”: Informa que será fornecido a senha do administrador (“manager”) do banco;
“-D”: Informa que será fornecido o “rootdn” (“cn=manager,dc=sisnema...”);
“-f”: Informa que será passado o nome do arquivo “.ldif”;
“-x”: Informa que a senha será enviada em “Plain Text”;
Abaixo, o conteúdo dos arquivos base.ldif e containers,ldif:
O arquivo “base.ldif”
objectclass: top

O arquivo “base.ldif”
objectclass: domain
dc: sisnema
O arquivo “containers.ldif”
dn: ou=people,dc=sisnema,dc=com,dc=br
ou: people
objectclass: top
objectclass: organizationalunit
dn: ou=group,dc=sisnema,dc=com,dc=br
ou: group
objectclass: top
objectclass: organizationalunit
Estes arquivos serão fornecidos pelo Instrutor e poderão ser copiados para qualquer
diretório como, por exemplo o “/root”.
Para cada um dos comandos acima, será pedida a senha do manager. É a senha
gerada anteriormente através do comando “slapasswd” (“secret”). A saída dos comandos
executados deverá ser similar a mostra abaixo:
Enter LDAP Password:

adding new entry "dc=sisnema,dc=com,dc=br"
Enter LDAP Password:
adding new entry "ou=people,dc=sisnema,dc=com,dc=br"
adding new entry "ou=group,dc=sisnema,dc=com,dc=br"
Passo 10: Podemos ainda conferir diretamente o conteúdo adicionado ao banco Ldap,
através do comando abaixo:
ldapsearch -x -b dc=sisnema,dc=com,dc=br
Onde:
“-x”: Sem criptografia;
“-b”: O nome da base ldap, a ser consultada;
O resultado obtido, deverá ser similar ao mostrado no quadro, a seguir:

Saída do comando “ldapsearch -x -b dc=sisnema,dc=com,dc=br”

# extended LDIF
#
# LDAPv3
# base <dc=sisnema,dc=com,dc=br> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# sisnema.com.br
objectClass: top
objectClass: domain
dc: sisnema
# people, sisnema.com.br
dn: ou=people,dc=sisnema,dc=com,dc=br
ou: people
objectClass: top
objectClass: organizationalUnit
# group, sisnema.com.br
dn: ou=group,dc=sisnema,dc=com,dc=br
ou: group
objectClass: top
objectClass: organizationalUnit
# search result
search: 2
result: 0 Success
# numResponses: 4
# numEntries: 3
Gerando os Certificados SSL

Para que seja possível fazer o CentOS 6.2 autenticar no OpenLdap, devemos antes
providenciar os certificados SSL, pois, a partir da versão 6.0 do CentOS, não é possível mais
utilizar autenticação “plain-text”. Para este fim, devemos então executar os passos abaixo:
Passo 1: Gerar os certificados SSL com o comando a seguir:

openssl req - new - x509 - nodes - out /etc/openldap/certs/slapdcert.pem -keyout
/etc/openldap/certs/slapdkey.pem - days 1825
Saída do comando:
Generating a 2048 bit RSA private key
.......................+++
..............................................+++
writing new private key to '/etc/openldap/cacerts/slapdkey.pem'
-----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----Country Name (2 letter code) [XX]:BR
State or Province Name (full name) []:RS

Locality Name (eg, city) [Default City]:POA

Organization Name (eg, company) [Default Company Ltd]:SISNEMA
Organizational Unit Name (eg, section) []:MATRIZ
Common Name (eg, your name or your server's hostname) []:instrutor
Email Address []:root@localhost
Nota: Importante lembrar que o nome do Servidor fornecido no campo “Common

Name”, deve ser o mesmo da máquina onde este comando é executado (adapte-o, conforme
o nome de seu computador, ex. “aluno5-1”).
Passo 2: Configurar o OpenLdap, para utilizar os certificados gerados. Para é preciso

editar o arquivo /etc/openldap/slapd.d/cn=config.ldif, adicionando as linhas indicadas abaixo,
ao seu final:
vim /etc/openldap/slapd.d/cn=config.ldif
olcTLSCertificateFile: /etc/openldap/certs/slapdcert.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/slapdkey.pem
Passo 3: Salve, abandone o arquivo “cn=config.ldif” e reinicie o ldap:

service slapd restart
Configurando a autenticação LDAP

Uma vez configurado o sistema para utilizar chaves de autenticação SSL, precisamos
efetuar a autenticação do mesmo, junto ao Serviço de Diretório. Para isto, podemos utilizar a
ferramenta “system -config-authentication”, conforme abaixo demonstrado:
system-config-authentication
O processo de integração dos CentOS ao Ldap, utiliza o pacote “nss -pam-ldapd”,

previamente instalado. As telas de configuração, deste processo serão mostradas a seguir.
Na primeira tela mostrada logo abaixo, devemos selecionar a opção “LDAP”:

“system-config-authentication” - Tela incial
Na segunda tela, devemos fornecer os seguintes parâmetros:

 Base para Pesquisa: dc=sisnema,dc=com,dc=br
 Servidor LDAP: ldaps://127.0.0.1
 Método de autenticação: Senha LDAP
 Utilizar TLS para Criptografar Sessões: Deixar Ativado

“system-config-authentication” - Segunda Tela
Finalmente, a tela a seguir nos ilustra as opções que devem estar ativadas na aba
“Opções Avançadas”:
 Habilitar Controle de Acesso Loca l: Ativado
 Algoritmo Hash da Senha : MD5
 Criar diretórios home, no primeiro login: Ativado

“system-config-authentication” - Terceira Tela
A partir deste ponto, o sistema estará preparado para autenticar no LDAP.
Configuração do “phpldapadmin”
Como visto anteriormente, o gerenciamento de um banco de dados via interface “CLI”
é trabalhoso e cansativo. Embora o “yum”, possa nos poupar algum trabalho, ele ainda, não
pode fazer todo o “trabalho sujo”, para nós. Para resolver este problema, utilizaremos uma
interface em php, de nome “phpldapadmin”. Esta será fornecida pelo Instrutor, mas pode ser
obtida a partir da “url” a seguir: http://sourceforge.net/projects/phpldapadmin. A versão que
utilizaremos (0.9.6c), não é a mais recente, mas já foi extensivamente testada, atendendo às
nossas necessidades. Para proceder a sua configuração, execute os passos abaixo:
Passo1: Obter o “tar.gz” do “phpldapadmin e descompactá-lo. Este poderá ser obtido

a partir do site indicado pelo seu Instrutor. Após, descompacte-o com o comando a seguir:
tar xzvf phpldapadmin - 0.9.6c.tar.gz

Passo 2: Copie a pasta descompactada com o comando anterior, para o

“DocumentRoot” do “Apache”, renomeando-a, para “phpldapadmin”. No caso do CentOs, o
“DocumentRoot”, fica em “/var/www/html’;
cp –a phpldapadmin-0.9.6c /var/www/html/phpldapadmin
Passo 3: Atribua permissão de execução recursiva à pasta copiada e crie o arquivo

“config.php”:
 Comando: chmod –R 755 /var/www/html/phpldapadmin
 Comando: cd /var/www/html/phpldapadmin
 Comando: cp config.php.example config.php
Passo 4: Utilizando o editor “vi”, modifique os campos indicados, conforme sugerido

abaixo:
vi config.php
Linha Modificada Linha
$servers[$i]['name'] = 'Aluno5-5'; 23
$servers[$i]['host'] = '127.0.0.1'; 26
$servers[$i]['base'] = 'dc=sisnema,dc=com,dc=br'; 33
$servers[$i]['login_dn'] = 'cn=Manager,dc=sisnema,dc=com,dc=br'; 52
$servers[$i]['enable_auto_uid_numbers'] = true; 100
$servers[$i]['auto_uid_number_search_base'] = 111
'ou=People,dc=sisnema,dc=com,dc=br';
$servers[$i]['auto_uid_number_uid_pool_dn'] = 118
'cn=uidPool,dc=sisnema,dc=com,dc=br';
Observação: Na linha “23”, do arquivo acima, substitua o campo 'Aluno5-5', pelo

nome, do seu computador.
Passo 5: Ativar o web-server “apache”, abrir o browser e apontar para a url do servidor
ldap (http://localhost/phpldapadmin):
service httpd start
Caso todas as configurações acima, tenham sido bem sucedidas, a tela a abaixo,
deverá aparecer no seu Web Browser:

Menu de Abertura do “phpldapadmin”

As imagens seguintes ilustram o início do processo de adição de um usuário ao
openldap, através desta ferramenta de configuração:
Phpldapadmin – Containers “Group” e “people”

Phpldapadmin – Usarios são adicionados ao container “people”

Phpldapadmin – Adição de Usuários: Menu Inicial
Passo 6: Adicionado o novo usuário, este deverá ser visível na lateral esquerda do
“phpldapaadmin”. Também deverá ser exibido através do comando “ldapsearch”:
ldapsearch -h 127.0.0.1 -b dc=sisnema,dc=com,dc=br -x

7.7. INTEGRAÇÃO COM AMBIENTES MICROSOFT

A partir deste ponto, vamos estudar o processo de integração do Samba com o Active
Directory Services. O Samba, também pode atuar como um “member-server” de um Domínio
Windows já existente, para isto efetuando ele próprio um “Join” no Active Directory deste. Para
isto, serão necessárias as seguintes etapas abaixo:
 Configurar o Samba
 Configurar o Kerberos
 Efetuar o Join no AD
 Inicializar o daemon winbind, do Samba
Pré-requisitos:
Para executar as tarefas propostas aqui, consideram-se os seguintes pré-requisitos:
 Servidor Windows 2008 com o AD configurado.
 Nome do Domínio: ADDOMAIN.LOCAL;
Inicialmente, vamos instalar e configurar o cliente Kerberos, necessário para efetuar o
“Join” no Domínio do Active Directory.
Integração com Kerberos

O Kerberos é um Protocolo de rede, desenvolvido pelo MIT (Massachusetts Institute
of Technology), que permite comunicações individuais seguras e identificadas, em uma rede
insegura. O Kerberos possui uma arquitetura cliente-servidor, tornando possível a
autenticação mútua entre o cliente e o servidor.
O Kerberos é necessário para o processo de autenticação em um Domínio Windows
pós NT4.0 e permite também funcionalidades adicionais, como o recurso de "Single Sign On",
em que apenas com uma única autenticação, pode-se habilitar o acesso a inúmeros recursos
de rede.
Passo 1: Verifique se os pacotes do kerberos se encontram instalados no seu sistema:

rpm -qa | grep krb
Os pacotes do kerberos, no CentOs
krb5-auth-dialog-0.13-3.el6
pam_krb5-2.3.11-9.el6
krb5-libs-1.9-22.el6_2.1
krb5-workstation-1.9-22.el6_2.1
krb5-devel-1.9-22.el6_2.1
Passo 2: A seguir precisamos editar o arquivo de cliente do kerberos, “krb5.conf”:

vim /etc/krb5.conf
Arquivo /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log

Arquivo /etc/krb5.conf
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = ADDOMAIN.LOCAL
[realms]
ADDOMAIN.LOCAL = {
kdc = aluno3-15.addomain.local:88
}
[domain_realm]
.kerberos.server = ADDOMAIN.LOCAL
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Onde:
default_realm: Nome do Domínio do Kerberoskdc: Nome/Endereço IP do Servidor
Kerberos
Normalmente, o nome e o endereço do Kerberos serão os mesmos do Active Directory

a menos que instalados em máquina diferentes. O domínio Kerberos, é sempre expresso todo
em letras capitais (maiúsculas).
Autenticação entre plataformas

Configurado o kerberos, para efetuar o processo de autenticação entre as plataformas,
precisamos executar alguns procedimentos adicionais:
Passo 1: Editar e configurar o arquivo /etc/smb.conf:

vim /etc/samba/smb.conf
Arquivo /etc/samba/smb.conf
### AD OPTIONS ###
workgroup = ADDOMAIN
lm announce = yes
encrypt passwords = Yes
username map = /etc/samba/smbusers
name resolve order = wins bcast hosts
logon drive = q:
log level = 3
realm = ADDOMAIN.LOCAL
security = ADS
password server = 192.168.3.52
winbind cache time = 15
winbind gid = 10000-20000
winbind uid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

Arquivo /etc/samba/smb.conf
winbind use default domain = yes
socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
ONDE:
workgroup: No caso o nome do Domínio Windows, ao qual o Samba irá fazer o
“Join”;realm: O nome do Domínio (“reino”) do kerberos;
Importante notar ainda que a opção “;passdb backend“, se encontra COMENTADA
com um “;” (“ponto e vírgula”), pois a autenticação agora será por conta do servidor LDAP (no
caso o “AD”).
Passo 2: Salve e abandone o arquivo smb.conf e reinicie os daemons do samba:

service smb restart
service nmb restart
Passo 3: É necessário fazer com que o Linux resolva o endereço do Servidor PDC da
rede Windows (isto é, aponte para a máquina onde fica o “AD”). Para isto, edite os arquivos
indicados adicionando a estes o conteúdo conforme mostrado abaixo:
vim /etc/resolv.conf
nameserver 192.168.3.52
Onde:
nameserver: Aponta para o endereço IP do Active Directory, o qual também agrega as
funções de servidor DNS para o Domínio:
vim /etc/hosts
192.168.3.52 winsrv.addomain.local winsrv
Onde:
192.168.3.52: É o endereço IP do Active Directory, onde o Samba irá efetuar o “Join”.
Integração com AD (Active Directory)

Finalmente estamos prontos para integrar o Samba, como um “Member Server” de um
Domínio do Active Directory. Para isso, execute os procedimentos abaixo:

Passo 1: Para fazer o Join no domínio, execute o comando abaixo, EXATAMENTE

como mostrado:
net ads join -Uadministrator
Saída do comando “ net ads join”
Enter administrator's password:
Using short domain name -- ADDOMAIN
Joined 'INSTRUTOR' to realm 'ADDOMAIN.LOCAL'
Passo 2: Obtenha o “ticket” do kerberos, para que o usuário “administrator” do samba,

possa consultar a lista de usuários do domínio.
kinit -V administrator
Saída do comando “kinit -V administrator”
Using default cache: /tmp/krb5cc_0
Using principal: administrator@ADDOMAIN.LOCAL
Password for administrator@ADDOMAIN.LOCAL:
Authenticated to Kerberos v5
Passo 3: Agora, consulte a lista de usuários do Domínio do AD/Kerberos:

klist
Saída do comando “klist”
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@ADDOMAIN.LOCAL
Valid starting Expires Service principal
09/03/12 13:55:49 09/03/12 23:56:37
krbtgt/ADDOMAIN.LOCAL@ADDOMAIN.LOCAL
renew until 09/10/12 13:55:49
Passo 4: Ative o serviço “winbind” do Samba, pois este serviço será usado para o
Samba, para validar usuários do Domínio Windows, que não possuam conta local no Samba:
service winbind restart
Passo 5: Finalmente, para verificar se a integração do Samba com o Active Directory,

foi, de fato, realizada, podemos utilizar ainda os seguintes comandos abaixo:
 wbinfo -u
 wbinfo -g
Onde:
-u: Pesquisa por usuários existentes no domínio.
-g: Pesquisa por grupos existentes no domínio.

SSO (Single-Sign On)

Conforme referido anteriormente o SSO (Single-Sign On) é uma funcionalidade
adicional provida pelo Servidor Kerberos, que permite a um usuário a autenticação em
múltiplos serviços, de modo automático e transparente, bastando para isto autenticar-se uma
vez apenas. No caso específico do Linux, para ativar esta funcionalidade, precisamos apenas
editar o arquivo abaixo, colocando o serviço “winbind”, onde for indicado:
vim /etc/nsswitch.conf
Fragmento do arquivo /etc/nsswitch.conf
passwd: files ldap winbind
shadow: files ldap winbind
group: files ldap winbind
netgroup: files ldap winb
Adicionado ao arquivo “nsswitch.conf”, o protocolo winbind, permitirá aos clientes do

Domínio Windows, a autenticação transparente aos recursos do Servidor Samba.

8. MÓDULO 15 - SEGURANÇA EM AMBIENTES LINUX

8.1. IPTABLES
O que é um Firewall
"Firewall é um conjunto de hardware e software cujo o objetivo é rotear pacotes de
dados entre duas ou mais redes, através de um conjunto de regras estabelecidas e
conhecidas como regras de filtragem. Um Firewall adiciona um grau de segurança variável a
uma rede de computadores contra acessos indesejados por parte de terceiros. Firewalls são
para as redes, o que os esquemas de privilégio de usuário são para os sistemas operacionais.
Tipos de Firewall
Os sistemas de Firewall podem ser classificados em dois tipos básicos:
A) Quanto à forma de funcionamento:

Filtro de Pacotes: Os pacotes IP chegam até o Firewall, que decide se os passa ou
não para a rede, dependendo das regras de filtragem embutidas em seu sistema operacional.
Esta modalidade, também chamada de Firewall de nível de Rede, é considerada a mais rápida
e flexível, e atua nas camadas 3 e 4 do modelo OSI, para interconexão de redes abertas.
Possuem como principais características:
Pontos Fortes: Muito rápido, consome poucos recursos (ex. memória, cpu,
etc,) é um firewall “genérico” (protege qualquer serviço), muito confiável (tecnologia
muito testada).
Deficiências: Conjunto de regras de filtragem reduzidas (regras para porta,

protocolo IPs de origem/destino, tipo de socket); olha apenas o cabeçalho IP e não o
conteúdo do pacote; não isola completamente as duas redes envolvidas no processo
de comunicação.
Em resumo, embora permaneça um componente essencial em qualquer rede, um

Firewall baseado em Filtro de Pacotes, não pode mais proteger completamente uma rede de
computadores.
Firewall de Aplicações: Esse tipo de Firewall não permite que nenhum pacote passe
diretamente entre a rede externa e a rede corporativa. Os pacotes de dados são enviados ao
Firewall que determina quando se deve ou não estabelecer a conexão, passando depois os
resultados ao hosts cliente (que originou o pedido de conexão). Este sistema é mais lento que
o filtro de pacotes e mais inflexível (o Firewall tem que conhecer a aplicação e se uma nova
aplicação for necessária na rede, deve-se obter com o fornecedor desta um novo código que
a contemple). Também chamado de Proxy ou de Firewall de Gateway de aplicativo, este tipo
de Firewall opera na camada 7 do modelo OSI.

Assim, quando um usuário remoto entra em contato com uma rede executando um
gateway de aplicativo, o gateway gerencia (proxies) a conexão. Nesse caso, pacotes de IP
não são encaminhados à rede interna. Em vez disso, um tipo de tradução ocorre, com o
gateway agindo como canal e intérprete.
B) Quanto à Topologia Utilizada:

As disposições físicas utilizada em sua montagem têm também, grande influência
quanto ao seu modo de funcionamento. Abaixo, veremos as disposições mais utilizadas:
Packed Filter: Sua forma mais simples de emprego é um router que possui habilitadas
as regras de filtragem de pacotes. Quando empregada nesta disposição, também é chamado
de "Filtro de Perímetro", porque os roteadores são dispositivos externos, então eles eliminam
a necessidade de interromper a operação normal da rede. Se você utiliza um Firewall baseado
em roteador, você não tem de configurar várias máquinas (ou vários serviços) para fazer
interface com ele.
A figura abaixo ilustra a forma física desta topologia de firewall:
Packet Filter
Dual or multi-homed host: Esta arquitetura de Firewall é montada sobre um

computador, que recebe o nome de "bastion host," com no mínimo duas placas de rede (daí
o nome). O Firewall então age como um roteador entre as redes que estão conectadas às
suas placas de rede, que não tem contato direto uma com a outra. Esta arquitetura, além de
isolar ambas as redes, permite o emprego de regras de filtragem de pacotes em seu kernel e
de "IP Masquerade", onde apenas uma Interface possui um endereço IP válido, sendo as
demais constituídas por IP’s de redes privadas. É hoje talvez a solução mais difundida de
Firewall, por ser relativamente simples segura e barata.

Abaixo, uma figura, representativa deste formato de topologia:
Dual Homed Host
Screened Host: Esta arquitetura utiliza uma camada de segurança primária (um router
com um "packed filter" configurado) e uma segunda camada de proteção que é o "bastion
host". O packed filter do router, é configurado de tal maneira que o bastion host é a única
máquina com a qual os hosts na Internet podem iniciar uma conexão com as máquinas da
rede interna. Por outro lado os hosts internos podem iniciar uma conexão diretamente, sem
passar pelo "bastion host".
Screned Host

Screened Subnet: Esta arquitetura possui três camadas de proteção: um router

externo, o Bastion host e um router interno. A função do router externo é de proteger o "bastion
host" da rede externa e a função do router interno é proteger a rede interna da rede externa e
do próprio "bastion host". A região entre os roteadores, onde se situa o bastion host é
chamada também de "DMZ", uma alusão à faixa de terra que separa as duas Coréias.
Screened Subnet (DMZ)
Implementando Firewall com o iptables

Neste capítulo, vamos nos concentrar na ferramenta IPTABLES, que é a ferramenta
de filtro de pacotes, atualmente utilizada no LINUX.
Nesta solução, além das cadeias INPUT, OUTPUT e FORWARD, existem as cadeias
de PREROUTING e POSTROUTING. Além disso, o funcionamento das cadeias de INPUT,
OUTPUT e FORWARD foram modificados de tal maneira que cada um funciona de modo
independente dos demais. Isto possibilita um nível ainda maior de segurança no projeto final
de Firewall que utilize o Iptables. O IPTABLES é uma ótima ferramenta de Filtro de pacotes
com características de STATEFUL. Um filtro de pacotes STATEFUL, é capaz de controlar
(negar/permitir) os pacotes IP, baseado no tipo de SOCKET.
Por exemplo: Só serão permitidas conexões que se iniciem do Cliente Interno, em

direção a Internet (“ESTABLISHED”, ou conexão do tipo “estabelecida”).
O uso de STATEFUL aumenta ainda mais a segurança, pois introduz mais um

elemento de filtragem utilizável para criar regras. Além disso, o funcionamento das cadeias
INPUT, OUTPUT e FORWARD, foram modificados, conforme mostrado no quadro abaixo:

Iptables – Roteamento de Pacotes:

FORWARD
NAT dados NAT
(PREROUTING) <------------------------------------
>(PREROUTING)
(POSTROUTING) ^ | ________ | ^
(POSTROUTING)
| | INPUT | | INPUT | |
dados | +------> |FIREWALL| <------+ | dados
+--------- |________| ---------+
OUTPUT eth0 eth1 OUTPUT
Como pode ser observado no diagrama acima, os pacotes tanto de entrada quanto de
saída não passaram pelas regras de INPUT e OUTPUT, porque essas regras só dizem
respeito a pacotes direcionados ao Firewall. Qualquer pacote cujo destino seja o Firewall,
passará pelas regras de INPUT do Firewall e todo pacote que sair do Firewall passa pelas
regras de OUTPUT do mesmo.
Desta forma temos como proteger ainda mais o Firewall, pois podemos usar DENY
para qualquer regra INPUT, pois isso não afetará o acesso ao servidor HTTP mostrado acima.
Para todos os pacotes de dados que passam de uma rede para outra através do
Firewall, passam pelas regras de FORWARD e agora com o iptables, podemos especificar
regras que controlem pacotes que entrem por uma interface em específico e saiam por outra
interface.

Uso do IPTABLES:
A ferramenta IPTABLES, é a ferramenta de firewall padrão do Linux, nas versões de
kernel 2.4 e atual (2.6), e foi desenvolvida por Rusty Russell, tendo como base a ferramenta
IPFILTER do Unix BSD. Abaixo vamos desenvolver o seu uso, começando pelo diagrama em
blocos de seu funcionamento:
Diagrama em blocos resumido do Iptables
Em uma breve descrição do Diagrama acima, podemos considerar as Tabelas como

compartimentos de memória onde ficam guardados dados e Regras de filtragem e as Cadeias
ou “Chains”, são como “Sinalizações de Estrada”, indicando em qual sentido devem fluir os
pacotes de certa origem e para um determinado destino. As Regras ou também chamadas
“Rules”, são o conjunto de condições ou requisitos que identificam e classificam os pacotes
IP, distinguindo-os dos demais. Como norma geral, tenha sempre em mente o quadro abaixo:

Sintaxe: Cadeias são cinco, e sempre em maiúsculas. Tabelas são três e

sempre em minúsculas, sendo que a tabela “filter”, por ser default, nunca é indicada.
Uso das Cadeias: INPUT e OUTPUT, só afetam a máquina local (firewall),

quem controla a rede interna é a cadeia FORWARD.
Uso do Nat: Usamos a Cadeia POSTROUTING, para liberar acesso a Internet,

para a rede interna e para liberar acesso aos servidores ao mundo externo (Internet),
usamos a Cadeia PREROUTING.
O Básico de Iptables
Política de um Firewall:
Denominamos de “Política de um Firewall”, o comportamento default que um Firewall,
como por exemplo, o Iptables, apresenta, na ausência de regras, quando recebe um pacote
IP. Existem duas políticas possíveis:
ACCEPT: Aceita o pacote, caso não existam regras contrárias, este é o

comportamento padrão do Iptables, quando o “host” (computador) é ligado. É o modo mais
simples, mas o menos seguro de se configurar um Firewall.
DROP: Descarta por default, um pacote IP, caso não exista uma regra em contrário.
O Iptables só assume este estado se existir um comando específico para isto, normalmente,
no início do “script” ou arquivo de regras de Firewall. Pode ser um pouco mais trabalhoso de
se configurar um Firewall neste modo, mas, sem dúvida, é o mais seguro.

Elaboração de um script de Firewall com o iptables
Existem dois modos de se criar um “Firewall Script”, com o Iptables:
Utilizando uma ferramenta específica para este fim: A maioria das distribuições Linux
modernas possui alguma instalada, como no caso da Distribuição CentOS (Yast). Existem
também, muitas ferramentas de terceiros, como é o caso da ferramenta FwBuilder. Este
método, não será abordado, devido à diversidade das ferramentas e aos seus diferentes
métodos de funcionamento.
Criando-se um “bash script”, que é um arquivo executável, similar (em princípio) aos
arquivos “.bat” do DOS e Windows, o qual contém as regras de Firewall e, que, normalmente
é carregado durante a inicialização do LINUX através de um dos arquivos abaixo:
No CentOS: /etc/rc.d/rc.local
Para a criação de um “Script”, devemos seguir algumas recomendações no sentido de

facilitar sua correta elaboração e, mais tarde, sua correta manutenção. Para tal listamos
abaixo os procedimentos necessários:
Definir os serviços: Aqui falamos de uma listagem de aplicações, porta e protocolos

que trafegarão na rede. Sempre construa esta tabela antes! Agindo assim, você conhecerá
melhor a rede a ser protegida e saberá, de antemão que política de Firewall irá adotar;
Definir a Política de Firewall: As escolhas são duas “DROP” (mais segura) ou

“ACCEPT” (menos segura). Devemos ressaltar que, embora “DROP” deva ser SEMPRE sua
primeira escolha, esta implica no conhecimento total das aplicações e suas portas e
protocolos. Nem sempre isto será possível, contudo em caso de aplicações não
documentadas ou de terceiros.
Definir um “esqueleto” de um “Script”: Com as regras em certa ordem. Isto tornará

mais fácil o seu desenvolvimento e, mais tarde (quando não se lembrar mais dele) seu
entendimento.
A título de exemplo, observe o modelo abaixo:

Exemplo proposto de um Firewall Script

#!/bin/bash
# Modelo de Script de Firewall
# Como regra geral, siga o roteiro abaixo:

# 1 - Zere as regras pre-existentes nas cadeias;
# 2 - Defina a Politica default do Firewall;
# 3 - Desabilite o trafego IP, ateh que o Firewall esteja ativado;
# 4 - Ative todas as protecoes, incluindo o anti-spoofing;
# 5 - Configure o acesso a cadeia INPUT;
# 6 - Configure o mascaramento;
# 7 - Configure o acesso a cadeia FORWARD;
# 8 - Configure o acesso a cadeia OUTPUT;
# 9 - Ative o "forward", entre as interfaces de rede;
################################################################
# ATENCAO: #
# - Nao se esqueca, que, quando trabalhamos com uma cadeia #
# negada (DROP), devemos tambem dizer qual tipo de socket sera #
# permitido. #
# - Para executa-lo durante o boot, voce pode usar o arquivo #
# /etc/rc.d/rc.local #
################################################################
### Inicio das Regras ###
### Passo 1: Primeiro vamos arrumar a casa :) ###

# Limpando as Regras
/sbin/iptables -F # Limpa as cadeias INPUT, OUTPUT e FORWARD
/sbin/iptables -F -t nat # Limpa a tabela de nat
# Definindo a Politica Default das Cadeias

/sbin/iptables -P INPUT DROP # Protege o Firewall
/sbin/iptables -P OUTPUT ACCEPT # Na maioria das vezes, pode ser deixada aberta
/sbin/iptables -P FORWARD DROP # Protege a rede Local
### Passo 2: Antes de Servir, vamos nos proteger ! ###

# Desabilitando o trafego IP Entre as Placas de Rede
echo "0" > /proc/sys/net/ipv4/ip_forward
# Configurando a Protecao anti-spoofing

echo " Setting anti-spoofing .....[ OK ]"
for spoofing in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo "1" > $spoofing
done
### Passo 3: Agora, vamos definir o que pode passar e o que nao ###
# Cadeia de Entrada. Esta cadeia, no iptables, soh vale para o proprio host
# Qualquer pacote Ip que venha do localhost, Ok.

/sbin/iptables -A INPUT -i lo -j ACCEPT
# Qualquer pacote Ip que venha da rede interna, Ok.

/sbin/iptables -A INPUT -i eth1 -j ACCEPT
### Passo 4:
# No iptables, temos de dizer quais sockets são validos em uma conexao
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
### Passo 5: Cadeia de Reenvio ( FORWARD ).

Exemplo proposto de um Firewall Script

# Primeiro, vamos ativar o mascaramento ( nat ).
/sbin/iptables -t nat -F POSTROUTING
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
### Passo 6: Agora dizemos quem e o que podem acessar externamente

# No iptables, o controle do acesso a rede externa eh feito na cadeia "FORWARD"
# Mail
/sbin/iptables -A FORWARD -p tcp -s 192.168.3.0/24 --dport 25 -d 0/0 -j ACCEPT
# Pop
# DNS
/sbin/iptables -A FORWARD -p udp -s 192.168.3.0/24 --dport 53 -d 0/0 -j ACCEPT
# WWW
# No iptables, temos de dizer quais sockets são validos em uma conexao

/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
### Finalmente, podemos "Ligar" os nossos clientes :) ###

# Habilitando o trafego Ip, entre as Interfaces de rede
echo " Firewall OK ...............[ OK ]"
Obtendo Dados para a elaboração do “Firewall Script”
Nosso primeiro passo, sempre deve ser descobrir quais aplicações devem ser
acessadas, bem como seu método de acesso (portas x protocolos). Por exemplo, do Script
acima, podemos extrair as seguintes informações úteis:
Tabela de Serviços: É a tabela de aplicações X portas X protocolos, que devemos

criar, ANTES, de iniciar a implementação do Firewall:
SERVIÇO PORTA(s) PROTOCOLO(S)

SMTP 25 TCP
DNS 53 UDP
HTTP 80 TCP
POP 110 TCP
Serviços
Definindo a política do Firewall

Uma vez, sabendo-se quais (e quantas) serão as aplicações, bem como seu método
de acesso (portas x serviços), devemos adotar um comportamento padrão para o Firewall.
Como regra geral e para maior segurança, sempre trabalhe com as cadeia “fechadas”, a não
ser em caso de situações muito específicas (ex. um número muito grande de portas).
CADEIA POLÍTICA
INPUT DROP
OUTPUT ACCEPT
FORWARD DROP
Política Default
Esta é uma política bem restritiva. Costuma-se deixar a cadeia OUTPUT em ACCEPT,
porque esta cadeia controla apenas o que sai do Firewall, sendo assim, não existe uma
implicação direta com a segurança da rede e, ao mesmo tempo, ocorre uma simplificação
maior das regras. Quando trabalhamos com uma cadeia em DROP, devemos especificar
todos os serviços que devem ser aceitos pela cadeia.
Por exemplo: No exemplo acima, não previmos o protocolo “icmp” (ping), portanto, não
será possível, na configuração atual do Firewall proposto saber se o Firewall ou o Link estão
ativos, a não ser indiretamente (abrindo o browser e testando a navegação, por exemplo).
Definindo qual cadeia utilizar

Definidos os Serviços e a política default, do Firewall, devemos a seguir definir qual
cadeia será utilizada por cada regra a ser criada. Exemplo: Observando o exemplo acima, em
qual cadeia devemos colocar regras de acesso ao protocolo icmp? A resposta é:
Em INPUT: Se desejamos pingar o Firewall externamente (da Internet);

Em FORWARD: Se desejamos que os Clientes internos possam pingar para fora;
Sintaxe de uma Regra:

Uma regra de Firewall com o Iptables segue um padrão similar ao mostrado a seguir:
iptables –t filter -A FORWARD -p tcp -s 192.168.3.0/24 --dport 110 -d 0/0 -j ACCEPT

1 2 3 4 5 6 7 8 9
ONDE:
1) iptables: Nome do executável que cria as regras de Firewall;
2) –t: Tabela usada. No caso, como é a tabela default (filter) poderia ser omitido;
3) Comando: “–A”, adiciona uma nova regra ao Firewall ( cria uma nova regra);
4) FORWARD: Cadeia a qual a regra se refere;
5) –p: Protocolo utilizado. Pode ser: tcp, udp, icmp, ou all (todos os três);
6) –s: Endereço Ip/máscara de origem do pacote;

7) –dport: Porta de destino. Normalmente, indica a porta do serviço desejado;

8) –d: Endereço Ip/máscara de destino do pacote;
9) –j: “Jump” (“salto”): Indica para onde será encaminhado o pacote IP (destino);
Sintaxe geral de uma Regra

Iptables – Comandos Utilizados

Comandos são argumentos de linha, que instruem o iptables sobre o que fazer com
uma nova regra. Existem 13 comandos básicos sendo que os mais usados são os citados
abaixo:
COMANDO SIGNIFICADO
"-A" anexa regra à cadeia escolhida
"-D" apaga uma regra da cadeia escolhida
"-I" insere regras em uma cadeia existente
"-P" a política padrão ou default, para a cadeia escolhida
"-F" ou apaga todas as regras de uma cadeia
"-L" lista todas as regras de uma cadeia
Como mencionamos antes, a tabela “filter é a default, então podemos omiti-la na regra
acima, ficando está assim:
iptables -A FORWARD -p tcp -s 192.168.3.0/24 --dport 110 -d 0/0 -j ACCEPT

Iptables - Sintaxe geral de uma regra, se omitida a tabela default
Se perguntassem a você agora: Olhando a regra acima qual a política default da

cadeia FORWARD? Pense bem, a regra termina em ACCEPT (aceitar), logo, a política para
a cadeia forward, deve ser DROP, para que a regra faça sentido, afinal, não seria lógico
instruir o Firewall a aceitar algo que este aceitaria de qualquer forma, ou seja: A resposta seria
que a cadeia FORWARD está em DROP.
Além da política default para a cadeia, e a própria cadeia na qual esta será
implementada, uma regra depende fundamentalmente do modo de funcionamento do serviço
a ser controlado. Para ilustrar esta afirmação, seguem 3 exemplos:
DNS: O serviço de DNS utiliza a porta 53/UDP, para escutar as requisições dos
clientes e a porta 53/TCP para efetuar transferências de zonas DNS, entre servidores, logo,
uma rede que disponha também de servidores DNS, deverá prever regras de acesso também
para porta 53/TCP;
FTP: O Serviço de FTP utiliza a porta 21/TCP, para comandos entre Cliente/Servidor
e a porta 20/TCP, para o tráfego de dados;
ICMP: O protocolo ICMP, foi desenvolvido para teste de redes, sendo assim, existe
um tipo de pacote ICMP, para cada tipo de teste. A título de exemplo, um simples “ping”,
envolve dois tipos de pacotes icmp diferentes: tipo “0”, ou “echo response” , é a reposta do
host remoto a um ping recebido e tipo “8” ou echo request” é o “ping” propriamente dito. No
mínimo, caso a cadeia esteja “dropada” deve existir uma regra para os tipos “8” (ida) e “0”
(volta).

Habilitando o protocolo icmp

Como exemplo, para liberar o “ping” da Internet, em direção ao Firewall e para os
Clientes da rede interna, podemos adicionar ao modelo de Firewall Script acima proposto, as
regras abaixo:
Da Internet, em direção ao Firewall, devemos adicionar a cadeia INPUT às regras:

Liberando o ping externo
iptables -A INPUT -p icmp -s 0/0 --icmp-type 0 -j ACCEPT
Para liberar o “ping” para os Clientes na rede interna, devemos adicionar a cadeia
FORWARD às regras:
Liberando o ping na Rede Interna:

Definindo os “sockets” (conexões) que serão permitidos

Como dissemos anteriormente, o Iptables é um Firewall “STATEFUL”. Isto significa
que, quando trabalhamos com uma cadeia “Dropada” (negada) devemos, além de criar uma
regra para a porta ou endereço IP a ser liberado, dizer qual tipo de socket será permitido
passar. Os tipos de sockets já foram discutidos anteriormente e são:
Socket O Que Controla

ESTABLISHED O sentido da conexão é de dentro para fora (rede interna -
Internet).
RELATED A conexão está relacionada com outra já estabelecida (ex. ftp:
Inicia na porta 21 e depois abre a porta 20).
NEW A Conexão inicia da Internet, em direção ao Firewall (ex: acesso de
Clientes Externos a Servidores Internos).
INVALID O Pacote está mal formado (ex, “checksum” inválido).
Tipos de Sockets
Como definimos que nosso Firewall irá negar (drop) os pacotes nas cadeias INPUT e
FORWARD, precisaremos de regras específicas para cada cadeia:
Cadeia INPUT:
iptables -A INPUT-m state --state ESTABLISHED,RELATED -j ACCEPT

Cadeia FORWARD:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
NAT – Network Address Translation
Para que um Firewall possa também funcionar como roteador, permitindo a passagem
de pacotes IP entre as redes envolvidas, precisamos ativar o NAT. Sem o NAT, o acesso as
redes Interna e Externa (ex: Internet), só será possível a partir do console do próprio Firewall,
o que não prático. Com o NAT, o Firewall atua como um intermediário, trocando os endereços
Ip de Origem ou destino por outro endereço, conforme o caso (daí o nome NAT: Tradução de
Endereço de Rede). Se o objetivo final é apenas prover acesso Internet aos clientes da Rede
Interna, usamos o nat “Dinâmico”. Por outro lado, se desejamos que Clientes na Internet,
possam se conectar a um servidor nosso, mesmo que este esteja configurado com um
endereço IP não roteável (“invalido”), utilizamos o nat “reverso”, também chamado de
“redirecionamento de portas”. As regras são as seguintes:
Nat Dinâmico (1 única Regra)

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
A regra acima substitui o endereço original do pacote que vêm do Cliente interno
(endereço inválido), trocando-o pelo endereço externo do firewall (endereço Internet).
Nat Reverso (duas regras)

iptables -t nat -A PREROUTING -p tcp -d $firewall --dport 80 -j DNAT --to $server
A regra acima direciona os pacotes que vem para o firewall, para o servidor interno.
iptables -t nat -A POSTROUTING -p tcp -s $server --sport 80 -j SNAT --to $firewall
A regra acima direciona todos os pacotes que vem do servidor interno, de volta ao IP
externo do firewall.
Onde:
“$firewall”: É o endereço externo (endereço Internet) do Firewall, o único acessível ao
Cliente externo.
“$server”: É o endereço IP do servidor de aplicação (visível pelo firewall), que
desejamos contatar externamente.

Ativando o Roteamento IP:

Além do NAT, é necessário se informar ao Kernel, que os pacotes IP podem atravessar
ambas as Interfaces de Rede. Isto é chamado de “roteamento” ou então “forwarding”. Por
questões de segurança o roteamento de pacotes IP é desabilitado por padrão, em qualquer
sistema operacional. No Linux e, mais especificamente em Firewall, o roteamento IP costuma
ser habilitado, diretamente no próprio “sript”, através da linha a seguir:
Ativa o reenvio de pacotes (Forward), entre as interfaces

Após esta última regra, o Firewall estará ativo e os Clientes deverão estar acessando
normalmente suas aplicações.

8.2. LOGS E AUDITORIAS
Um log é um arquivo texto que tem por finalidade registrar tudo o que ocorre no
sistema.
Os sistemas Unix-like possuem um serviço exclusivo de manutenção de logs que pode

ser utilizado por qualquer aplicação no sistema, na maioria das vezes esse mecanismo é
utilizado pelo kernel e pelos serviços conhecidos como deamons, pois eles não têm o terminal
como saído para suas mensagens, uma vez que são executados em background. Existe um
serviço responsável por esse mecanismo, o syslogd. Assim como todo serviço o syslog é
iniciado como um daemon, ou seja, inicia automaticamente durante o boot.
Os registros executados pelo syslogd podem ser classificados pela aplicação ou

serviço que solicitou o registro mais o nível de informação gerada. O solicitante pode ser, por
exemplo: kern para informações do Kernel; mail - Para informações do servidor de Correio;
user - Para registros originados de aplicações dos usuários; auth - Para aplicações que
utilizam autenticação, etc.
Tabela dos níveis:

Nível Descrição
info Mensagens informativas
notice Mensagens observativas
warning Avisos
err Mensagens de Erro
crit Mensagens críticas
alert Mensagens de Alerta
emerg Mensagens de Emergência
none Mensagens sem qualquer classificação
O destino dos registros pode ser qualquer arquivo em qualquer file system, ou até
mesmo um pc remoto.
Agora vamos entender o arquivo de configuração, o syslog.conf.

Arquivo /etc/syslogd.conf
# /etc/syslog.conf Configuration file for syslogd.
#
# For more information see syslog.conf(5)
# manpage.
#
# First some standard logfiles. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none /var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log

Arquivo /etc/syslogd.conf
mail.* -/var/log/mail.log
user.* -/var/log/user.log
uucp.* /var/log/uucp.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
# Logging for INN news system

#
news.crit /var/log/news/news.crit
news.err /var/log/news/news.err
news.notice -/var/log/news/news.notice
#
# Some `catch-all' logfiles.
#
*.=debug;
auth,authpriv.none;
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;
auth,authpriv.none;
cron,daemon.none;
mail,news.none /var/log/messages
#
# Emergencies are sent to everybody logged in.
#
*.emerg *
#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;
# news.=crit;news.=err;news.=notice;
# *.=debug;*.=info;
# *.=notice;*.=warn /dev/tty8
# The named pipe /dev/xconsole is for the `xconsole' utility. To use it,
# you must invoke `xconsole' with the `-file' option:
#
# $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
# busy site..
#
daemon.*;mail.*;
news.crit;news.err;news.notice;
*.=debug;*.=info;
*.=notice;*.=warn |/dev/xconsole

As linhas do arquivo seguem o layout "recurso.nivel arquivo_de_registro", e ainda

podemos utilizar alguns caracteres especiais conforme a tabela a seguir.
Caractere Descrição
* Todos os níveis ou recursos
= É usado para montar esquemas de logging de maneira a
restringir o registro apenas a determinado nível ou recurso
- Indica uma exceção para um recurso ou nível
! Sinal de negação, utilizado para montar esquemas de logging
de maneira a especificar níveis ou recursos que não devem ser
registrados.
As primeiras linhas do arquivo, começadas com # são comentários informativos e as

demais são instruções:
Exemplo:
auth,authpriv.* /var/log/auth.log
Essa linha acima pede para o syslog grava todas as informações da instrução auth
(autenticação) no /var/log/auth.log.
Arquivo Messages
Agora vamos entender como funciona o arquivo messages, é a partir dele que
começamos a investigação de qualquer problema do sistema, pois ele é o que contém mais
informações genéricas do sistema. Abaixo veremos um trecho do arquivo messages.
Dec 11 06:47:02 localhost syslogd 1.4.1#17: restart.
Conforme podemos observar o próprio syslog utiliza esse arquivo para logar as
informações de seu início.
Dec 12 07:38:01 localhost kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2799.70-MHz
686-class CPU)
Pelo arquivo de log messages também é possível verificar configurações de hardware

do computador que são coletados durante o boot.
Dec 15 12:23:11 localhost dhclient: New IP Address (sis0): 201.37.170.40
Dec 15 12:23:11 localhost named[511]: starting BIND 9.3.4 -t /var/named -u bind
Também é possível verificar configurações sobre services rodando no servidor.

8.3. RELATÓRIOS
O Sarg ou “Gerador automático de relatórios do Squid”, é uma ferramenta em PHP,
que permite a geração de relatórios em páginas WEB, do conteúdo do arquivo de logs do
squid (access.log), através desta ferramenta, podemos claramente verificar dados
importantes para o bom funcionamento dos serviços bem como o controle do que os usuários
estão acessando na Internet. Abaixo podemos visualizar um “screenshot” de um relatório de
acesso utilizando o Sarg:
Relatório gerado pelo Sarg
Instalação e Configuração:
A Instalação e rápida e simples. “Algumas distribuições possuem inclusive pacotes
“.rpm” mas, caso isto não ocorra com a sua distribuição, nem por isso sua configuração será
difícil ou cansativa. Para instalar e configurar o Sarg a partir dos seus fontes, proceda
conforme indicado abaixo:
Passo 1: Efetue o “download” do Sarg. (http://sarg.sourceforge.net/).
Passo 2: Descompacte as fontes em /usr/local:

tar xzvf “pacote.tar.gz”

Passo 3: Entre agora, no diretório descompactado e execute os comandos:

./configure
make
make install
Passo 4: Concluídos com sucesso os passos acima, será criado um diretório base do
Sarg em ‘/usr/local/sarg”. Agora, tudo o que precisamos é editar um único arquivo de
configuração (sarg.conf). Para isso execute o comando abaixo:
vim /usr/local/sarg/etc/sarg.conf
Passo 5: Mude as linhas indicadas abaixo:

language Portuguese
access_log /var/log/squid/access.log
title "Relatorio de Acesso do Squid"
output_dir /var/www/html/squid-reports
report_type topsites sites_users users_sites date_time denied auth_failures
site_user_time_date
Sarg.conf – Parâmetros a serem configurados
Estes são os únicos parâmetros essenciais a serem configurados. O parâmetro

“output_dir” referido acima, deve indicar o diretório correspondente ao “DocumentRoot” do
apache que se encontra instalado, e que pode variar de distribuição para distribuição.
Passo 6: Gere o relatório através do comando abaixo:

sarg
Passo 7: Ative o “apache”. Isto dependerá de qual distribuição está utilizando. No caso
específico do CentOS, execute o comando abaixo:
service httpd restart
Passo 8: Abra o browser e digite a url: http://localhost/squid-reports

Caso o procedimento acima tenha sido bem sucedido, deverá ser mostrada a página
inicial do sarg.


8.4. TESTES DE INTRUSÃO
• Planejamento
• Tipos dos testes de penetração
• Ataques de ambiente
• Ataques de entrada
• Ataques de dados e lógica
• Cuidados com serviços
• Ferramentas para testes de Intrusão
Ao ouvir o termo testes de penetração, você provavelmente imagina um gênio solitário

realizando testes misteriosos em alguma pobre parte de um software. E antes do
renascimento em testes de penetração, certamente houve uma imagem real.
Atualmente, os testes de penetração são realizados de maneira muito mais metódica. Isso
é necessário porque o SDL (Security Development Lifecycle), além do projeto de segurança
com carregamento frontal e do foco no desenvolvimento, está reduzindo o número de defeitos
latentes, o que torna muito mais difícil a tarefa de encontrar vulnerabilidades durante os testes.
Os testes de segurança de software são muito importantes. Eles devem ser metódicos,
podendo ser ensinados e repetidos, para que todos possam ser aplicados em uma ampla
gama de circunstâncias.
Isso sem mencionar que os testes de penetração são uma ciência. Todos os testes têm
aspectos exploratórios; os testadores aplicam entradas, que alteram os dados dentro do
software, fazendo com que eles reajam de várias formas. A complexidade é tamanha para
que haja uma previsão precisa.
Planejamento
Com os testes tradicionais, especificações, documentações do usuário, casos de uso e
outras documentações de design estão abundantemente disponíveis. Essas informações
podem ser usadas para criar um conjunto de casos de teste que verificarão a funcionalidade
especificada. Mas as fontes de informações disponíveis a respeito do planejamento são muito
limitadas. Testes de penetração não significam verificar funcionalidade; trata-se de verificar a
ausência de funcionalidade sem segurança. Infelizmente, ninguém definiu nenhum artefato
de desenvolvimento de software para esses comportamentos, e os testadores são obrigados
a procurá-los por si.
O primeiro lugar para colher informações a respeito dos testes de penetração são as
interfaces entre o software e o ambiente externo. Interfaces do usuário, interfaces de rede,
APIs e qualquer outro lugar em que entradas sejam processadas são claros vetores de ataque

para hackers. Caso alguma destas interfaces esteja mal projetada ou implementada, elas
podem permitir entradas criadas de maneira mal-intencionada e a destruição causada por
elas.
Identificar e documentar essas interfaces são um bom lugar para começar os testes de
penetração.
A segunda área que exige atenção especial são as mensagens de erro e as caixas de
diálogo de alerta do usuário, que comunicam informações do software para usuários externos.
Como esses usuários podem ter más intenções, é importante compreender quais
informações são reveladas a eles e como essas informações são comunicadas.
Por fim, os testadores de penetração normalmente definem cenários de desastre que

especificam como deve ser um ataque bem-sucedido. Esses casos de uso indevido (ou casos
de abuso, se você preferir) normalmente provêm de um modelo de ameaça ou de ataques
conhecidos anteriores.
Coletar informações de todas essas três fontes é um trabalho de preparação crucial
para um teste de penetração e ajudará a orientá-lo em meio aos testes reais.
Tipos dos testes de penetração

Os testes dizem respeito à variação – encontrar as coisas no software e no ambiente que
podem ser variadas, variá-las e ver como o software responde. A meta é garantir que o
software funcione de maneira confiável e segura em cenários de produção aceitáveis e até
mesmo inaceitáveis.
Assim, o planejamento mais essencial que um testador pode fazer é compreender o que
pode ser variado e de quais formas essa variação precisa ser preparada tendo em vista os
testes.
Do ponto de vista da segurança, o ambiente, a entrada do usuário, os dados internos e a

lógica são os principais locais nos quais essa variação pode revelar problemas de segurança.
O ambiente consiste nos arquivos, nos aplicativos, nos recursos de sistema e nos demais
recursos locais ou de rede usados pelo aplicativo. Qualquer um desses poderia ser o ponto
de entrada do ataque. A entrada do usuário são os dados originados com entidades externas
(normalmente não confiáveis) e que são analisados e usados pelo software. Os dados
internos e a lógica são as variáveis armazenadas internamente e os caminhos lógicos, que
contam com um número qualquer de enumerações potenciais.
Variando as informações no ambiente do software, o domínio da entrada e os caminhos

lógico-dados, é possível realizar ataques. Abordarei cada uma dessas três categorias mais
detalhadamente.

Ataques de ambiente
O software não é executado isoladamente. Ele conta com um número qualquer de binários
e módulos equivalentes a códigos como, por exemplo, scripts e plug-ins. Ele também pode
usar informações de configuração do Registro ou do sistema de arquivos, bem como bancos
de dados e serviços que podem residir em qualquer lugar. Cada uma dessas interações
ambientais pode ser a fonte de uma violação de segurança e, por isso, deve ser testada.
Também existem algumas perguntas importantes que você deve fazer a respeito do nível
de confiança que o aplicativo tem nessas interações, algumas delas:
 Qual é o nível de confiança que o aplicativo tem no ambiente local e nos recursos
remotos?
 O aplicativo coloca informações confidenciais em um recurso (por exemplo, o Registro)

que pode ser lido por outros aplicativos?
 Ele confia em todos os arquivos ou bibliotecas que carrega sem verificar o conteúdo?
 Um invasor pode explorar essa confiança para forçar o aplicativo a aceitar sua oferta?
Além das perguntas quanto à confiança, os testadores de penetração se preocupam com

DLLs que podem estar defeituosas ou que tenham sido substituídas (ou modificadas) por um
invasor, com binários ou com arquivos com os quais o aplicativo interage e que não estão
totalmente protegidos por ACLs (listas de controle de acesso) ou que estejam desprotegidos
de alguma outra forma. Os testadores também estão à procura de outros aplicativos que
acessem recursos de memória compartilhada ou que armazenem dados confidenciais no
Registro ou em arquivos temporários. Por fim, os testadores devem considerar fatores que
criam estresse no sistema como, por exemplo, rede lenta, pouca memória etc., além de
determinar o impacto desses fatores nos recursos de segurança.
Os ataques de ambiente costumam ser realizados simulando um ambiente desprotegido

e, em seguida, executando o aplicativo dentro desse ambiente para ver como ele responde.
Trata-se de uma forma indireta de teste; os ataques são feitos contra o ambiente no qual o
aplicativo está em operação. Agora observemos os testes diretos.
Ataques de entrada
Em testes de penetração, o subconjunto de entradas provenientes de fontes não
confiáveis é o mais importante. Elas incluem caminhos de comunicação como, por exemplo,
protocolos de rede e soquetes, funcionalidades remotas expostas como DCOM, RPCs
(chamadas de procedimento remoto) e Web services, arquivos de dados (binários ou de
texto), arquivos temporários criados durante a execução e arquivos de controle como scripts
e XML, todos eles sujeitos à violação. Por fim, a interface do usuário que controla a permissão
da entrada do usuário direta, inclusive telas de logon, front-ends da Web e similares, também
deve ser verificada.

Mais especificamente, você deverá determinar se a entrada é controlada de maneira

apropriada: as boas entradas são permitidas e as más (como, por exemplo, cadeias de
caracteres longas, pacotes malformados etc.), não? A verificação de entrada apropriada e a
análise do arquivo são críticas.
Você precisará testar e ver se a entrada perigosa pode ser inserida nos controles da
interface do usuário e descobrir o que ocorre quando isso acontece. Isso inclui caracteres
especiais, entrada codificada, fragmentos de script, cadeias de caractere de formato,
sequências de escape. Você precisará determinar se cadeias de caracteres longas
incorporadas a campos de pacotes ou arquivos e que são capazes de causar estouro de
memória passarão sem problemas. Os pacotes corrompidos em fluxos de protocolo também
são uma preocupação. Você deve procurar falhas e paralisações e verificar a pilha em busca
de danos na memória explorável.
Por fim, você deve verificar se coisas como mensagens de validação e de erro acontecem
no local certo (no lado do cliente, e não no lado do servidor) como uma defesa apropriada
contra uma entrada incorreta.
Os ataques de entrada são bem parecidos como lançar granadas contra um aplicativo.
Alguns deles serão abortados apropriadamente e outros farão com que o software exploda. É
de responsabilidade da equipe de penetração determinar qual é o que e iniciar as correções
apropriadas.
Ataques de dados e lógica

Algumas falhas são incorporadas a mecanismos de armazenamento dos dados internos
do aplicativo e a lógica do algoritmo. Nesses casos, parece haver erros de design e
codificação nos quais o desenvolvedor estava pressupondo um usuário benevolente ou
deixou de considerar alguns caminhos de código que um usuário pode percorrer.
O ataque de negação de serviço é o principal exemplo dessa categoria, embora

certamente não seja o mais perigoso. Os ataques de negação de serviço podem ser bem-
sucedidos quando os desenvolvedores deixam de planejar tendo em vista um número grande
de usuários (ou conexões, arquivos, ou qualquer entrada que faça com que algum recurso
exceda seu limite). No entanto, há muito mais defeitos lógicos traiçoeiros que precisam ser
testados.
Por exemplo, a divulgação das informações pode acontecer quando as entradas que
controlam mensagens de erro e outras entradas geradas revelam informações exploráveis a
um invasor. Um exemplo prático desses dados que você deve sempre remover são as contas
de teste codificadas ou as APIs de teste (que são normalmente incluídas em compilações
internas para auxiliar na automação do teste). Eles podem fornecer acesso fácil a um invasor.
Mais dois testes que você deve executar são inserir credenciais falsas para determinar se os
mecanismos de autorização internos são eficientes e escolher as entradas que variam os
caminhos de código. Normalmente, um caminho de código é seguro, mas a mesma
funcionalidade pode ser acessada de maneira diferente, o que poderia ignorar
inadvertidamente alguma verificação crucial.

Não se intimide
Os testes de penetração são muito diferentes dos testes funcionais tradicionais; os
testadores de penetração não apenas se ressentem da falta de documentação apropriada,
mas também devem ser capazes de pensar como usuários que pretendem provocar danos.
Esse ponto é muito importante – os desenvolvedores normalmente operam com a
pressuposição de que nenhum usuário razoável executaria um determinado cenário,
negando, assim, a correção de bug. Mas você não pode, efetivamente, dar chances como
essa.
Os hackers percorrerão grandes distâncias para encontrar vulnerabilidades, e nenhum

truque, roteiro ou caso de teste está fora dos limites. O mesmo deve acontecer com testadores
de penetração.
Cuidados com serviços

• Servidores de Nomes (DSN)
• Servidores de Senha/Chave (KDC)
• Servidores de Autenticação/Proxy
• Correio Eletrônico
• World Wide Web(WWW)
• Transferência de Arquivo (FTC, TFTP)
• NFS
• Firewalls
Servidores de Nomes (DNS)

A Internet usa o Domain Name System (DNS) para realizar resolução de endereço
para nomes de host e rede. Resolução nome-endereço é crítica para a operação segura
de qualquer rede. Um atacante que pode controlar ou personificar um servidor DNS pode
alterar o tráfego para subverter proteções de segurança. Por exemplo, tráfego normal pode
ser desviado para um sistema comprometido para ser monitorado; ou, usuários podem ser
enganados e fornecer segredos de autenticação. Uma organização deveria criar sites
protegidos, bem conhecidos, para atuar como servidores de nomes secundários e proteger
seu DNS mestre de ataques por bloqueio de serviço usando roteadores filtradores.
Tradicionalmente, DNS não tem nenhuma capacidade de segurança. Em particular, a

informação retornada de uma consulta não pode ser conferida para verificar eventual
modificação ou se ela originou-se do servidor de nome solicitado. Trabalho tem sido feito
para incorporar assinaturas digitais no protocolo que, quando utilizado, permitirá que a
integridade da informação seja verificada criptograficamente (veja RFC 2065).

Servidores de Senha/Chave (KDC)

Servidores de senha e chave geralmente protegem suas informações vitais (i.e., as
senhas e chaves) com algoritmos de criptografia. Porém, mesmo uma senha encriptada
em uma única via pode ser determinada por um ataque do dicionário (em que são
encriptadas palavras comuns para ver se elas correspondem à encriptação armazenada).
É então necessário garantir que esses servidores não sejam acessíveis por hosts que não
planejam usá-los para o serviço, e mesmo estes hosts deveriam somente estar aptos a
acessar o serviço (i.e., serviços gerais, tais como Telnet e FTP, não deveriam ser
permitidos por ninguém além dos administradores).
Servidores de Autenticação/Proxy
Um servidor proxy fornece vários aprimoramentos de segurança. Ele permite aos
administradores concentrar serviços através de um host específico para permitir
monitoração, esconder a estrutura interna, etc. Esta concentração dos serviços cria um
alvo atraente para um intruso potencial.
O tipo de proteção necessário para um servidor de proxy depende muito do protocolo

em uso e os serviços sendo fornecidos através dele. A regra geral de limitar o acesso
somente aos hosts que precisam dos serviços é um bom ponto de partida.
Correio Eletrônico
Os sistemas de correio eletrônico (e-mail) foram, por um longo tempo, uma fonte para
intrusos porque os protocolos de e-mail estão entre os mais antigos e os serviços mais
amplamente utilizados. Também, por sua natureza, um servidor de e-mail requer acesso
ao mundo externo; a maioria dos servidores de e-mail aceita entrada de qualquer origem.
Um servidor de e-mail geralmente consiste de duas partes: um agente

receptor/emissor e um agente de processamento. Desde que e-mail é entregue a todos os
usuários, e é normalmente privado, o agente de processamento tipicamente requer
privilégios (root) do sistema pra entregar o mail. A maioria das implementações de e-mail
executam ambas as porções do serviço, o que significa que o agente receptor também
tem privilégios do sistema.
Existem algumas implementações disponíveis que permitem uma separação dos dois
agentes. Tais implementações são geralmente consideradas mais seguras, mas ainda
exigem instalação cuidadosa para evitar a criação de um problema de segurança.
World Wide Web (WWW)
A Web cresceu exponencialmente em popularidade devido a sua facilidade de uso e a

poderosa habilidade de concentrar serviços de informação. A maioria dos servidores

WWW aceita algum tipo de direção e ação de pessoas acessando seus serviços. O
exemplo mais comum é enviar um pedido de um usuário remoto e passar a informação
fornecida para um programa executando no servidor para processar o pedido.
Alguns desses programas não são escritos com segurança em mente e podem criar
furos de segurança. Se um servidor Web está disponível para a comunidade Internet, é
especialmente importante que informações confidenciais não sejam colocadas no mesmo
host que o servidor. De fato, é recomendado que o servidor tenha um host dedicado que
não é confiável pelos outros hosts internos.
Muitos sites podem querer colocar serviço FTP com seu serviço WWW. Mas isto
deveria ocorrer somente para servidores de ftp-anônimo que apenas fornecem
informações (ftp-get). Operação put no ftp-anônimo, em combinação com WWW, pode ser
perigoso (por exemplo, elas poderiam resultar em modificações para as informações que
seu site está publicando para a rede) e eles mesmos fazem as considerações de
segurança para cada serviço diferente.
Transferência de Arquivo (FTP, TFTP)

FTP e TFTP permitem aos usuários receber e enviar arquivos eletrônicos em modo
ponto-a-ponto. Porém, FTP requer autenticação, enquanto o TFP não necessita. Por esta
razão, TFTP deveria ser evitado tanto quanto possível.
Servidores FTP configurados inadequadamente podem permitir aos intrusos copiar,

substituir e apagar arquivos à vontade, em qualquer lugar de um host, então é muito
importante configurar este serviço corretamente. Acesso a senhas encriptadas e dados
proprietários e a introdução de cavalos de Tróia são apenas alguns dos potenciais furos
de segurança que podem ocorrer quando o serviço é configurado incorretamente.
Servidores FTP deveriam ter seu próprio host. Alguns sites decidem colocar FTP com
servidor Web, uma vez que os dois protocolos compartilham considerações de segurança
comuns.
Porém, na prática não é recomendado, especialmente quando o serviço FTP permite

o envio de arquivos (veja seção em WWW acima). TFTP não suporta o mesmo conjunto
de funções que o FTP e não tem qualquer segurança. Este serviço deveria somente ser
considerado para uso interno, e então ele deveria ser configurado de maneira restrita tal
que o servidor tem acesso somente a um conjunto pré-determinado de arquivos (ao invés
de todos os arquivos com permissão de leitura para todos). Provavelmente o uso mais
comum do TFTP é para downloading de arquivos de configuração para um roteador. TFTP
deveria residir em seu próprio host, e não deveria ser instalado em hosts suportado FTP
externo ou acesso Web.
NFS
O Serviço de Arquivo de Rede (Network File System) permite aos hosts compartilhar
discos comuns. NFS é frequentemente usado por hosts sem disco que dependem de um

servidor de disco para todas as suas necessidades de armazenamento. Infelizmente, NFS

não tem nenhuma segurança embutida. É então necessário que o servidor NFS seja
acessível somente pelos hosts que estão usando-o para serviço. Isto é obtido
especificando para quais hosts o sistema de arquivos está sendo exportado e de que modo
(por exemplo, somente leitura, somente escrita, etc.).
Sistemas de arquivos não deveriam ser exportados para qualquer host externo à rede
local, uma vez que isso irá necessitar que o serviço NFS seja acessível externamente.
Idealmente, o acesso externo ao serviço NFS deveria ser bloqueado por um firewall.
Firewalls
Uma das medidas de segurança mais amplamente empregada e publicada em uso
na Internet é um "firewall".
Os Firewalls são apenas outra ferramenta em questão para segurança de sistema.

Eles fornecem certo nível de proteção e são, em geral, uma maneira de implementar a
política de segurança no nível de rede. O nível de segurança que um firewall fornece pode
variar tanto quanto o nível de segurança em uma máquina particular.
Um firewall é um dos vários mecanismos usados para controlar e observar o acesso

de uma rede com a finalidade de protegê-la. Um firewall atua como um gateway através
do qual todo o tráfego para a rede ou sistemas protegidos passa. Firewalls ajudam a
colocar limitações na quantidade e tipo de comunicação que ocorre entre a rede protegida
e a outra rede (por exemplo, a Internet, ou outra parte da rede de um site).
Firewalls não são sempre, ou mesmo tipicamente, uma única máquina. Firewalls são
frequentemente uma combinação de roteadores, segmentos de rede, e computadores
host. Portanto, para o propósito desta discussão, o termo "firewall" pode consistir em mais
de um dispositivo físico. Firewalls são tipicamente construídos usando dois diferentes
componentes, roteadores de filtragem e servidores proxy.
Roteadores de filtragem são o componente mais fácil de conceituar em um firewall. Um

roteador move dados de um lado para outro entre duas (ou mais) redes diferentes. Um
roteador "normal" pega um pacote da rede A e encaminha-o para seu destino na rede B.
Um roteador de filtragem faz a mesma coisa, mas decide não apenas como rotear o
pacote, mas se deveria rotear o pacote. Isto é feito instalando uma série de filtros pelos
quais o roteador decide o que fazer com qualquer pacote de dados.
Uma discussão referente às capacidades de uma marca particular de roteador,

executando uma versão de software específica está fora do escopo. Porém, quando
avaliando um roteador para ser usado para filtragem de pacotes, o seguinte critério pode
ser importante quando da implementação de uma política de filtragem: endereço IP origem
e destino, números de porta TCP origem e destino, estado do bit "ACK" no pacote TCP,
números de porta UDP origem e destino, e direção do fluxo de pacotes (i.e., A->B ou B-
>A).

Outra informação necessária para construir um esquema de filtragem seguro é se o

roteador reordena instruções de filtro (de modo a otimizar a filtragem, isto algumas vezes
pode mudar o significado e causar acesso não pretendido), e se é possível aplicar filtros
para pacotes que chegam e que saem em cada interface (se o roteador filtra somente
pacotes que saem então o roteador é externo aos seus filtros e pode ser mais vulnerável
para atacar). Além de o roteador ser vulnerável, esta distinção entre aplicar filtros em
pacotes que chegam ou que saem é especialmente relevante para roteadores com mais
de duas interfaces. Outras questões importantes são a capacidade de criar filtros baseado
nas opções do cabeçalho IP e o fragmento do estado do pacote. Construir um bom filtro
pode ser muito difícil e requer um bom entendimento do tipo de serviços (protocolos) que
serão filtrados.
Um servidor proxy é um modo para concentrar serviços de aplicação através de uma

única máquina. Tipicamente existe uma única máquina (o bastion host) que atua como um
servidor proxy para uma variedade de protocolos (Telnet, SMTP, TFP, HTTP, etc.) mas
podem existir computadores host individuais para cada serviço. Ao invés de conectar
diretamente um servidor externo, o cliente conecta para o servidor proxy que em troca
inicia uma conexão para o servidor externo solicitado. Dependendo do tipo de servidor
proxy usado, é possível configurar clientes internos para realizar este redirecionamento
automaticamente, sem conhecimento para o usuário, outros podem requerer que o usuário
conecte diretamente para o servidor proxy e então iniciar a conexão através de um formato
específico.
Existem benefícios de segurança significantes que podem ser obtidos pelo uso de
servidores proxy. É possível adicionar listas de controle de acesso para protocolos, exigir
que usuários ou sistemas forneçam algum nível de autenticação antes do acesso ser
concedido. Servidores proxy mais espertos, algumas vezes chamados Gateways da
Camada de Aplicação, podem ser escritos de modo que entendam protocolos específicos
e podem ser configurados para bloquear somente subseções do protocolo. Por exemplo,
um Gateway de Aplicação para FTP pode reconhecer a diferença entre o comando "put"
e o comando "get"; uma organização pode desejar permitir aos usuários realizar "get" de
arquivos da Internet, mas não permitir "put" de arquivos internos no servidor remoto. Em
contraste, um roteador de filtragem poderia ou bloquear todo acesso ao FTP, ou não, mas
não um subconjunto.
Servidores proxy também podem ser configurados para criptografar fluxos de dados
baseado em uma variedade de parâmetros. Uma organização pode usar esta
característica para permitir conexões criptografadas entre duas localizações interligadas
via Internet.

Ferramentas para testes de Intrusão
 Nessus:
O Nessus é um software de auditoria de redes e varredura de vulnerabilidades que
pode ser utilizado para descobrir falhas de segurança em sistemas UNIX e Windows. É
possível ajustar o aplicativo para reproduzir a política de segurança de sua empresa, dos
relatórios públicos das agências de segurança NSA, CERT e CIS, dentre outras.
 Nmap:
Nmap é um software livre que realiza port scan desenvolvido pelo auto-proclamado
hacker Fyodor. É muito utilizado para avaliar a segurança dos computadores, e para descobrir
serviços ou servidores em uma rede de computadores.
 Metasploit:
Metasploit é uma ferramenta utilizada, em sua maior parte, por Pen Testers, para
a realização de testes de penetração (penetration test), podendo ser usada pelas mais
variadas áreas, para fins de testes, análises, conhecimento etc.
 Scanmetender Standart:
Scanmetender Standart é um scanner de rede multifuncional e suíte de
segurança, que não só é capaz de mostrar-lhe abrir as portas do seu computador,
também para fechá-las.
 Superscan:
SuperScan é um scanner de portas gratuito voltado para utilizadores Windows.
Com ele é possível fazer um scan em diversas portas em uma rede, gerando reports,
estatísticas e informações sobre a rede. De fácil utilização, ele pode ser utilizado
facilmente por um utilizador mais leigo.
 Unicornscan:
Unicornscan é uma reunião de informação e mecanismo de correlação
construída para e pelos membros da investigação sobre segurança e as comunidades
de testes. Ele foi projetado para fornecer um motor que é escalável, flexível e eficiente.
Ele é liberado para a comunidade a utilizar nos termos da licença GPL.


Formação Administrador de Redes Multiplataforma PT2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Formação Administrador de Redes Multiplataforma PT2

Enviado por

Direitos autorais:

Formatos disponíveis

APOSTILA DE TREINAMENTO

TÓPICOS ABORDADOS NA PARTE 2:

1. MÓDULO 8 - SERVIÇOS DE REDE MICROSOFT 13

Apostila para o treinamento SS3136

Transferência de zona DNS ................................................................................................... 52

Apostila para o treinamento SS3136

Métodos de autenticação do NPS ....................................................................................... 181

2. MÓDULO 9 - ACTIVE DIRECTORY 69

3. MÓDULO 10 - ACTIVE DIRECTORY DOMAIN SERVICES 87

Apostila para o treinamento SS3136

Objetos de Política de Grupo .............................................................................................. 100

Apostila para o treinamento SS3136

Identidade baseada em declarações .................................................................................. 146

4. MÓDULO 11 - SEGURANÇA EM AMBIENTES MICROSOFT 204

Apostila para o treinamento SS3136

Requisitos de servidor do WSUS........................................................................................ 215

5. MÓDULO 12 - SERVIDORES LINUX 220

6. MÓDULO 13 - GERENCIAMENTO DE SERVIDORES LINUX 252

Apostila para o treinamento SS3136

Gerenciamento de Pacotes RPM ........................................................................................ 260

7. MÓDULO 14 - SERVIÇOS DE REDE LINUX 272

Apostila para o treinamento SS3136

Introdução ao Samba e Protocolo SMB ............................................................................. 314

8. MÓDULO 15 - SEGURANÇA EM AMBIENTES LINUX 346

Apostila para o treinamento SS3136

8.4. TESTES DE INTRUSÃO .............................................................................................. 368

Apostila para o treinamento SS3136

Apostila para o treinamento SS3136

1. MÓDULO 8 - SERVIÇOS DE REDE MICROSOFT

Segurança de Arquivos e Pastas

Conflito de precedência de permissão:

Os pontos seguintes descrevem os principais aspectos de permissões NTFS:

 As permissões NTFS podem ser atribuídas individualmente

 As permissões NTFS são controladas negando ou permitindo tipos específicos de

Apostila para o treinamento SS3136

Tipos de permissões NTFS

A tabela abaixo detalha as opções de permissões padrão para arquivos e pastas

Permissões de arquivos Descrição

Full Control (controle total) Concede ao usuário controle total do arquivo ou

Modify (modificar) Concede ao usuário permissão para ler, escrever ou

Read (ler) Concede ao usuário permissão para ver o conteúdo

Write (escrever) Concede ao usuário permissão para gravar em um

Apostila para o treinamento SS3136

A tabela abaixo detalha as permissões avançadas para arquivos e pastas NTFS.

Permissões de arquivos Descrição

Transverse A permissão “Percorrer pasta” aplica-se somente a pastas.

List Folder/Read A permissão “Listar pasta” concede ao usuário permissão

Read Attributes (ler Atributos de permissão de leitura concede ao usuário

Read Extended O atributo de leitura estendida concede ao usuário

Create Files/Write A permissão de criar arquivos se aplica apenas a pastas e

Apostila para o treinamento SS3136

Permissões de arquivos Descrição

Write Attributes (gravar A permissão “Gravar Atributos” concede ao usuário

Write Extended A permissão “Gravar Atributos estendidos” concede ao

Delete Subfolders and Files A permissão “Excluir as subpastas e arquivos” concede ao

Delete (excluir) A permissão “Excluir” concede ao usuário excluir o arquivo

Read Permissions Permissão de “Ler” concede ao usuário permissão para ler

Change Permissions Permissão Alterar permite alterar as permissões do arquivo

Take Ownership (apropriar- A permissão “Apropriar-se” concede ao usuário permissão

Apostila para o treinamento SS3136

Nota: Permissões padrão são combinações de várias permissões avançadas

Exemplos de Permissão NFTS

 Ao aplicar permissões NTFS, os resultados são cumulativos. Por exemplo, no exemplo