c estadual de educaÇÃo tecnolÓgica paula...
TRANSCRIPT
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
EDUARDO SIERRA FERNANDES
SAMBA 4 ALTERNATIVA OPENSOURCE AO ACTIVE DIRECTORY
LINS/SP 1º SEMESTRE/2015
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
EDUARDO SIERRA FERNANDES
SAMBA 4 ALTERNATIVA OPENSOURCE AO ACTIVE DIRECTORY
Trabalho de Conclusão de Curso apresentado àFaculdade de Tecnologia de Lins para obtenção doTítulo de Tecnólogo em Redes de Computadores.
Orientador: Prof. Me. Alexandre Ponce de Oliveira
LINS/SP 1º SEMESTRE/2015
EDUARDO SIERRA FERNANDES
SAMBA 4
ALTERNATIVA OPENSOURCE AO ACTIVE DIRECTORY
Trabalho de Conclusão de Curso apresentado àFaculdade de Tecnologia de Lins, como parte dosrequisitos necessários para a obtenção do título deTecnólogo(a) em Redes de Computadores soborientação do Prof. MSC Alexandre Ponce deOliveira.
Data de aprovação: ___/___/___
___________________________
Orientador (Nome do Orientador)
______________________________
Examinador 1 (Nome do Examinador)
______________________________
Examinador 2 (Nome do Examinador).
Aos meus pais, José Luiz Fernandes e Sara SierraAscêncio Fernandes, aos meus avós, Aurio SierraPardo, in memoriam e Percília Sierra AssêncioPardo e a minha futura esposa Eloisa Suzuki Maiapelo apoio e incentivo nesta jornada.
EDUARDO SIERRA FERNANDES
AGRADECIMENTOS
Primeiramente gostaria de agradecer a todos que participaram de forma
direta ou indireta para a conquista dessa meta tão importante em minha vida.
Faltariam páginas para listar todos vocês e certamente haveria alguma omissão.
Quero agradecer especialmente a meus pais, José Luiz Fernandes e Sara
Sierra Ascêncio Fernandes, meus avós maternos Aurio Sierra Pardo in memoriam e
Percília Sierra Assêncio, a minha namorada Eloisa Suzuki Maia pelo incentivo (e
cobrança) ao longo dos anos para eu concluir o ensino superior. Sem vocês eu teria
desistido (novamente).
Meus sinceros agradecimentos a meu orientador, Alexandre Ponce de
Oliveira, pela amizade e ajuda na realização deste sonho, ao Centro Paula Souza
pela oportunidade que me foi dada e a todos Colaboradores e Professores da Fatec
de Lins.
EDUARDO SIERRA FERNANDES
RESUMO
Em pequenas e médias empresas o investimento em Tecnologia da Informação é
escasso e realizado em casos de extrema necessidade. É comum o uso de
softwares proprietários, sem licenciamento, para suprir necessidades básicas de
funcionamento da rede em servidores e em estações de trabalho. A facilidade de uso
dos recursos providos pelo Microsoft Active Directory para gerenciamento de
usuários e compartilhamento de arquivos são os principais motivos para o uso de
servidores Windows sem licenciamento, de modo que a empresa está passível de
multas e outros transtornos causados pela pirataria de software. Este trabalho
apresenta uma proposta de implementação de um servidor Active Directory com
utilização somente de softwares livres, conforme designação da Free Software
Foundation, de modo a implementar a interoperabilidade entre os sistemas
operacionais Linux e Windows em ambientes de produção, com baixo custo de
manutenção e livre de licenciamento de software, do lado servidor. Para o total
entendimento da solução adotada, foram abordados conceitos de funcionamento do
Active Directory e tecnologias necessárias para seu funcionamento. A estrutura
utilizada simula um ambiente comum em pequenas e medias empresas,
implementando gerenciamento de usuários, compartilhamento de arquivos, controle
de acesso à Internet e procedimentos básicos de administração.
Palavras-chave: Gerenciamento de Usuários. Active Directory. Samba. Kerberos.
ABSTRACT
In small and medium enterprises investing in Information Technology is scarce and
performed in cases of extreme need. It's common the use of proprietary software
without licensing for basic needs of the network in servers and workstations. The
ease of use of the resources provided by Microsoft Active Directory for user
management and file sharing are the main reasons for using unlicensed Windows
servers, so the company is subject to fines and other disorders caused by software
piracy. This paper presents a proposal to implement an Active Directory server that's
use only free software, as designated by the Free Software Foundation, in order to
implement interoperability between Linux and Windows operating systems in
production environments, with low maintenance costs and free software licensing on
the server-side. For the full understanding of the solution adopted, they were
addressed Active Directory operating concepts and technologies required for its
operation. The structure used simulates a common environment for small and
medium enterprises, implementing user management, file sharing, internet access
control and basic administration procedures.
Keywords: User management. Active Directory. Samba. Kerberos.
LISTA DE ILUSTRAÇÕES
Figura 1.1: Modelo de referência TCP/IP....................................................................16
Figura 1.2: Protocolos e redes no modelo TCP/IP Inicial...........................................17
Figura 1.3: Servidores DNS raiz em 2012..................................................................18
Figura 1.4: DNS Root Servers distribuídos pelo mundo.............................................18
Figura 1.5: Hierarquia de servidores DNS..................................................................19
Figura 1.6: Exemplo de uma árvore de diretório LDAP..............................................21
Figura 1.7: Exemplo de domínio Kerberos..................................................................23
Figura 1.8: O mascote do Linux - Tux.........................................................................25
Figura 2.1: Hierarquia de um domínio Active Directory..............................................31
Figura 2.2: Domínios de uma árvore...........................................................................32
Figura 2.3: Relações de confiança bidirecionais e transitivas....................................33
Figura 2.4: Relações de confiança externas – unidirecional ou bidirecional..............35
Figura 2.5: Relação de confiança do tipo Shortcut.....................................................36
Figura 2.6: Usuário herda as permissões do grupo....................................................38
Figura 2.7: Divisão de um domínio em Unidades Organizacionais............................41
Figura 2.8: Definição de um site..................................................................................43
Figura 2.9:Topologia de replicação simples................................................................45
Figura 2.10: MMC sem nenhum snap-in carregado...................................................48
Figura 2.11: Janela de adição de Snap-ins.................................................................48
Figura 3.1: Registro de nome com e sem servidor de Nomes NetBIOS....................51
Figura 3.2: Resolução de nomes com e sem servidor de nomes NetBIOS...............52
Figura 4.1: Topologia da rede de testes......................................................................58
Figura 4.2: Snap-ins....................................................................................................66
Figura 4.3: Criação de novo grupo..............................................................................67
Figura 4.4: Parâmetros para criação do grupo...........................................................67
Figura 4.5: Grupos criados separados em unidades organizacionais........................68
Figura 4.6: Parâmetros para criação de um novo usuário..........................................68
Figura 4.7: Parâmetros de segurança.........................................................................69
Figura 4.8: Usuários criados separados em unidades organizacionais.....................69
Figura 4.9: Grupos do usuário.....................................................................................70
Figura 4.10: Seleção de grupos do usuário................................................................70
Figura 4.11: Adição de snap-in para controle de GPO...............................................71
Figura 4.12: Configurações de proxy via GPO...........................................................72
Figura 4.13: snap-in para permissões de pastas........................................................72
Figura 4.14: Seleção do computador a ser gerenciado..............................................73
Figura 4.15: Permissões da pasta ADM......................................................................73
Figura 4.16: Domínio disponível para logon...............................................................75
Figura 4.17: Acesso às pastas compartilhadas pelo servidor.....................................75
Figura A.1: Tela de boot do CD de Instalação Debian 8.0 (Jessie)............................80
Figura A.2: Falha na configuração automática de rede..............................................81
Figura A.3: Seleção de configuração manual de rede................................................81
Figura A.4: Configurações de rede - SRV-FW001......................................................81
Figura A.5: Configurações de rede - SRV-AD001.......................................................82
Figura A.6: Configuração de gateway em SRV-AD001..............................................82
Figura A.7: Configuração de servidores DNS em SRV-AD001...................................83
Figura A.8: Configuração de domínio em SRV-AD001 e SRV-FW001.......................83
Figura A.9: Definição da senha de root.......................................................................83
Figura A.10: Definição de nome de usuário “restrito”.................................................84
Figura A.11: Definição de senha de usuário “restrito”.................................................84
Figura A.12: Seleção do método de particionamento de disco..................................84
Figura A.13: Particionamento de disco – SRV-FW001...............................................85
Figura A.14: Particionamento de disco – SRV-AD001................................................85
Figura A.15: Seleção de mirror do gerenciador de pacotes.......................................86
Figura A.16: Seleção de software...............................................................................86
Figura A.17: Instalação do gerenciador GRUB...........................................................87
Figura A.18: Instalação do sistema finalizada.............................................................87
Figura A.19: Tela de login – SRV-FW001....................................................................87
Figura A.20: Tela de login – SRV-AD001....................................................................87
LISTA DE TABELAS
Tabela 1.1 - Principais tipos de registros de recursos DNS para IPv4.......................20
Tabela 1.2 - Nomes de atributo comuns encontrados em hierarquias LDAP.............22
Tabela 2.1 - Requisitos de Hardware – Windows Server 2008..................................30
Tabela 3.1 - Tipos de nós NetBIOS.............................................................................53
Tabela 3.2 - Tipos de recursos....................................................................................53
Tabela 3.3 - Tipos de recursos de grupos NetBIOS....................................................53
Tabela 4.1 - Distribuição de endereços IP..................................................................58
Tabela 4.2 - Configurações das máquinas virtuais.....................................................59
Tabela 4.3 - Opções utilizadas no provisionamento do domínio................................63
Tabela 4.4 - Relacionamento entre usuários e grupos...............................................71
Tabela A.1 - Particionamento de disco........................................................................85
Tabela E.1 - Funcionalidades disponíveis em cada um dos modos de domínios......99
Tabela F.1 - Funcionalidades disponíveis em cada um dos modos de florestas......100
LISTA DE ABREVIATURAS E SIGLAS
AD – Active Directory
BGP – Border Gateway Protocol
BIND – Berkeley Internet Name Domain
CIFS – Common Internet File System
DC – Domain Controller
DFS – Distributed File System
DNS – Domain Name System
FSF – Free Software Foundation
FTP – File Transfer Protocol
GPL – Gnu Public License
GPO – Group Policy Object
IETF – Internet Engineering Task Force
IP – Internet Protocol
ISO – International Organization for Standardization
ITU – International Telecommunication Union
KCC – Knowledge Consistency Checker
LDAP – Lightweight Directory Access Protocol
MMC – Microsoft Management Console
MIT – Massachusetts Institute of Technology
NBNS – NetBIOS Name Server
NTP – Network Time Protocol
OSI – Open Systems Interconnection
OSPF – Open Shortest Path First
RODC – Read-only Domain Controller
SMB – Server Message Block
TCP – Transmission Control Protocol
TLD – Top-Level-Domain
UDP – User Datagram Protocol
UNC – Universal Naming Convention
WINS – Windows Internet Name Service
SUMÁRIO
INTRODUÇÃO............................................................................................................13
1 TECNOLOGIAS ENVOLVIDAS................................................................................15
1.1 TRANSMISSION CONTROL PROTOCOL/INTERNET PROTOCOL (TCP/IP)....15
1.2 DOMAIN NAME SYSTEM (DNS)..........................................................................17
1.2.1 BIND...................................................................................................................20
1.3 LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP)..............................21
1.4 KERBEROS...........................................................................................................22
1.5 LINUX....................................................................................................................24
1.5.1 Debian GNU/Linux.............................................................................................26
2 MICROSOFT® ACTIVE DIRECTORY.....................................................................28
2.1 NOMENCLATURAS E CAMINHOS UNC.............................................................28
2.2 INTRODUÇÃO AO ACTIVE DIRECTORY............................................................29
2.2.1 Domínios............................................................................................................31
2.2.2 Árvores...............................................................................................................32
2.2.3 Relação de Confiança e Florestas.....................................................................32
2.2.4 Contas de Usuário..............................................................................................36
2.2.5 Grupos de Usuários...........................................................................................37
2.2.6 Contas de Computador......................................................................................39
2.2.7 Unidades Organizacionais.................................................................................40
2.2.8 Schema..............................................................................................................41
2.2.9 Sites....................................................................................................................42
2.3 REPLICAÇÃO.......................................................................................................44
2.4 FUNCIONALIDADES DE UM DOMÍNIO...............................................................45
2.5 GROUP POLICY OBJECT (GPO)........................................................................46
2.6 CONSOLE DE ADMINISTRAÇÃO E SNAP-IN.....................................................47
3 SAMBA.....................................................................................................................49
3.1 O QUE É O SAMBA..............................................................................................49
3.2 HISTÓRIA..............................................................................................................49
3.3 BASE DE FUNCIONAMENTO..............................................................................50
3.3.1 NetBIOS.............................................................................................................50
3.3.2 SMB/CIFS...........................................................................................................54
3.4 SAMBA 4...............................................................................................................54
3.4.1 Modos de Operação Suportados.......................................................................55
3.4.2 Limitações..........................................................................................................55
3.4.3 Novos Recursos (versão 4.2).............................................................................55
3.4.4 Requisitos de Software......................................................................................56
4 ESTUDO DE CASO.................................................................................................58
4.1 CONFIGURAÇÃO SRV-FW001............................................................................59
4.1.1 Configuração do Servidor DHCP.......................................................................60
4.1.2 Configuração do Servidor DNS Secundário......................................................60
4.1.3 Configuração do Firewall....................................................................................61
4.1.4 Configuração do Proxy SQUID..........................................................................61
4.2 CONFIGURAÇÃO SRV-AD001.............................................................................61
4.2.1 Instalação do SAMBA 4......................................................................................62
4.2.2 Provisionamento do Domínio.............................................................................63
4.2.3 Configuração do BIND9.....................................................................................64
4.2.3 Configuração do Kerberos.................................................................................64
4.2.3 Criação das Pastas Compartilhadas..................................................................65
4.3 GERENCIAMENTO DO DOMÍNIO.......................................................................66
4.3.1 Criação de Grupos.............................................................................................67
4.3.2 Criação de Usuários...........................................................................................68
4.3.3 Atribuição de Usuários a Grupos.......................................................................69
4.3.4 Definição de Proxy via GPO...............................................................................71
4.3.5 Permissão de Pastas Compartilhadas...............................................................72
4.4 INGRESSAR ESTAÇÕES DE TRABALHO NO DOMÍNIO...................................74
CONCLUSÃO..............................................................................................................76
REFERÊNCIAS BIBLIOGRÁFICAS............................................................................78
ANEXO A – INSTALAÇÃO DEBIAN GNU/LINUX.......................................................80
ANEXO B – SCRIPT DE FIREWALL..........................................................................88
ANEXO C – ARQUIVO SQUID.CONF........................................................................92
ANEXO D – ARQUIVO DE INICIALIZAÇÃO DO SAMBA 4........................................95
ANEXO E – FUNCIONALIDADES DE MODOS DE DOMÍNIOS................................99
ANEXO F – FUNCIONALIDADES DE MODOS DE FLORESTAS...........................100
13
INTRODUÇÃO
As redes de computadores são atualmente um recurso indispensável para as
empresas. Compartilhar recursos, dispositivos e gerenciamento de usuários tornou-
se uma necessidade crescente nas empresas de todos os tamanhos.
(TANENBAUM, 2003)
Nas décadas de 70 e 80, o modelo de armazenamento de dados e sistemas
era baseado em computadores de grande porte, os chamados mainframes. Os
terminais (comumente conhecidos como terminais burros) se conectavam ao
mainframe, normalmente via modem, e acessavam os sistemas e dados após
autenticação. Dentre as principais vantagens do uso de mainframes, pode-se citar:
gerenciamento e atualização centralizada, ambiente mais seguro e facilidade na
atualização dos sistemas. Em contrapartida, as principais desvantagens do uso de
mainframes são: custo elevado, sistema de comunicação precário e os dados da
empresa eram administrados por terceiros. (BATTISTI; SANTANA, 2009)
Na década de 90 iniciou-se um processo de substituição dos mainframes,
principalmente devido ao aumento do poder de processamento e barateamento dos
computadores pessoais do padrão IBM/PC. O mainframe continua em uso, porém
em empresas de grande porte ou em aplicações que necessitem alto poder de
processamento. Com essa migração, um processo natural foi a interligação desses
computadores através de redes, inicialmente com o uso de cabos coaxiais. Surgiu
então um modelo conhecido como Cliente/Servidor, onde um equipamento com
maior capacidade de processamento (Servidor) compartilha recursos com outros
equipamentos (Cliente). Com essa migração, ocorreu uma descentralização de
acesso, criando-se a necessidade de definir permissões de acesso aos recursos
compartilhados, de forma que um determinado usuário tivesse acesso apenas ao
que fosse necessário à execução de seu trabalho, o que gerou um problema devido
a cada sistema criar seu próprio arquivo de senhas, de maneira descentralizada,
isso dificultou a manutenção e gerenciamento. (BATTISTI; SANTANA, 2009)
Com o lançamento do Windows 2000 Server, foi introduzido o serviço Active
Directory (AD), que foi a principal atualização do sistema em relação a seu
antecessor, o Windows NT Server 4.0. A proposta da Microsoft® é que aos poucos
as aplicações sejam integradas com o AD, ou seja, em vez de cada sistema ter seu
próprio cadastro de usuários, senhas e grupos, ele seja capaz de acessar as contas
14
e grupos do AD e com isso atribuir as respectivas permissões de acesso. (BATTISTI;
SANTANA, 2009)
Em sistemas operacionais do tipo UNIX, a interoperabilidade com os sistemas
de rede da Microsoft (tanto do lado cliente quanto do lado servidor) é feita através do
software Samba. Segundo Blackman (1997), o Samba é um conjunto de
programas que trabalham juntos para permitir que clientes acessem
compartilhamento de arquivos e impressoras.
O Samba 4 lançado em dezembro de 2012, possibilitou a replicação completa
de um controlador AD sem a necessidade de outros programas, como acontecia
com o Samba 3 e versões anteriores. (SAMBA-HISTORY, 2012)
O objetivo deste trabalho é realizar a implementação do Samba 4 em uma
empresa de médio porte, com aproximadamente 400 usuários, para utilizar os
recursos de autenticação centralizada para prover acesso às áreas de rede de cada
departamento e o controle do uso de internet.
A metodologia utilizada para realizar a implementação deste trabalho foi a
utilização de diversos materiais, como manuais disponibilizados pela equipe de
desenvolvimento do Samba 4 e livros relacionados a redes de computadores,
Windows Server e Linux.
O presente trabalho está dividido em quatro capítulos. O primeiro capítulo
aborda as tecnologias envolvidas que servirão de base fundamental para atingir o
objetivo do trabalho. O segundo capítulo aborda os conceitos fundamentais para
funcionamento do Active Directory, incluindo e não se limitando a árvores, grupos,
usuários e outros objetos. No terceiro capítulo tem-se a história, conceitos e
funcionamento do Samba, assim como uma apresentação da versão 4. O quarto
capítulo contém a implementação do Samba 4 como um controlador de domínio
Active Directory e os passos para realizar a configuração do servidor proxy Squid,
para utilizar a base de dados centralizada e prover acesso à Internet.
Por fim, têm-se as considerações finais do trabalho e as referências utilizadas
ao longo de seu desenvolvimento.
15
1 TECNOLOGIAS ENVOLVIDAS
Este capítulo descreve os conceitos e tecnologias que serviram de base para
a implementação do Samba 4 como um controlador de domínio Active Directory em
um servidor Linux.
Para o desenvolvimento do presente trabalho foram utilizadas diversas
tecnologias, interligadas ou não, sendo que todos os softwares utilizados são
gratuitos, segundo enquadramento da Free Software Foundation (FSF). Dentre os
softwares e tecnologias utilizadas destacam-se os protocolos, serviços e sistemas
operacionais.
1.1 TRANSMISSION CONTROL PROTOCOL/INTERNET PROTOCOL (TCP/IP)
O modelo de interconexão TCP/IP foi desenvolvido pelo departamento de
defesa americano para resolver o problema de interconexão de computadores
heterogêneos, sendo uma evolução de trabalhos iniciados no Massachusetts
Institute of Technology (MIT) e contando com a cooperação de várias empresas. Foi
implementado dez anos antes em relação ao modelo de referência Open Systems
Interconnection/International Organization for Standardization (OSI/ISO). (TEIXEIRA
JR. et al., 1998)
Uma das preocupações do Departamento de Defesa dos Estados Unidos era
com a destruição de hosts, pois a rede deveria ser capaz de sobreviver a essas
perdas e manter as comunicações existentes, ou seja, as conexões deveriam
permanecer intactas enquanto as máquinas de origem e destino estivessem
funcionando, independente se algumas máquinas ou linhas de transmissão
deixassem de operar repentinamente. Outra necessidade era que a implementação
deveria ser em uma arquitetura flexível, que fosse capaz de se adaptar a aplicações
com requisitos diferentes, como por exemplo, transferência de arquivos e
transmissão de dados de voz, em tempo real. (TANENBAUM, 2003)
Segundo Teixeira Jr. et al. (1998), os serviços de protocolos TCP/IP podem
ser organizados de acordo com o esquema de camadas proposto pelo modelo de
referência OSI/ISO, sendo que no TCP/IP, o modelo de arquitetura tem base em 4
camadas, ante as 7 camadas do modelo de referência OSI, conforme ilustra a Figura
1.1.
16
Figura 1.1: Modelo de referência TCP/IPFonte: Tanenbaum, 2003, p. 46
Segundo Tanenbaum (2003), a camada de aplicação contém todos os
protocolos de nível mais alto. A camada de transporte tem a finalidade de permitir
que os hosts de origem e destino mantenham comunicação. Para isso, são
utilizados o TCP e o User Datagram Protocol (UDP). A camada Inter-redes trabalha
de forma a permitir que os hosts injetem pacotes em qualquer rede e garanta que
eles trafegarão de forma independente até o destino, inclusive receber em uma
ordem diferente da ordem que foram enviados. A camada de host/rede não
especifica exatamente uma regra, excetuando-se o fato de que o host precisa se
conectar através de algum protocolo que permita o envio de pacotes IP.
Em cada camada são encontrados um ou mais protocolos usados na
comunicação entre os pares na mesma camada, por exemplo, o File Transfer
Protocol (FTP) é um protocolo da camada de aplicação, o TCP um protocolo da
camada de transporte, o IP um protocolo da camada inter-redes e o Ethernet é um
protocolo da camada de host/rede. (TEIXEIRA JR. et al., 1998).
As camadas do protocolo TCP/IP representam a forma mais usada de
comunicação entre computadores remotos atualmente, pois suas especificações e
muitas implementações estão disponíveis a um preço mínimo ou de graça.
(TEIXEIRA JR. et al., 1998)
A Figura 1.2 ilustra as camadas e alguns de seus protocolos.
17
Fonte: Tanenbaum, 2003, p. 47
1.2 DOMAIN NAME SYSTEM (DNS)
O DNS é um serviço de banco de dados distribuído utilizado pelas aplicações
TCP/IP para traduzir endereços simbólicos de estações para endereços IP
numéricos. Cada domínio mantém isoladamente o seu próprio banco de dados e
fornece tais informações através de um serviço para os demais domínios terem
acesso. Sendo assim, o DNS fornece o protocolo para permitir que clientes e
servidores possam se comunicar uns com os outros em ambientes de Serviços de
Redes. (TEIXEIRA JR. et al., 1998)
O software de serviços de nomes do DNS é dividido conceitualmente em dois
componentes: o resolver, que é o módulo de software responsável pela montagem
das consultas e o servidor de nomes, que é o processo responsável por responder
às perguntas. (TEIXEIRA JR. et al., 1998)
O DNS utiliza um grande número de servidores, organizados de maneira
hierárquica e distribuídos por todo o mundo. Nenhum servidor de nomes isolado tem
todos os mapeamentos para todos os hospedeiros da Internet. Em vez disso, os
mapeamentos são distribuídos pelos servidores de nomes. Há três classes de
servidores de nomes: servidores de nome raiz, servidores de nomes de alto nível
(Top-Level Domain – TLD) e servidores de nome com autoridade. (KUROSE; ROSS,
2013)
Por não possuir uma tabela centralizada e sim um sistema de banco de dados
distribuído, não ocorre degradação do serviço à medida que as bases de dados
crescem. O DNS propaga automaticamente as novas informações de suas bases de
dados, para o restante da rede, à medida que essas novas informações forem
solicitadas por outros domínios. Além de propagar as informações de forma
automática, essas só são propagadas para quem tiver interesse nelas, ou seja, essa
Figura 1.2: Protocolos e redes no modelo TCP/IP Inicial
18
propagação é feita por demanda. (TEIXEIRA JR. et al., 1998)
Na Internet há 13 servidores de nomes raiz, nomeados de A a M, sendo que a
maior parte deles está localizada na América do Norte. Apesar de nos
referenciarmos a cada um dos 13 servidores como se fossem um único servidor, na
realidade, cada um é um conglomerado de servidores replicados, para fins de
segurança e confiabilidade. (KUROSE; ROSS, 2013)
Na Figura 1.3 é exibida uma lista dos servidores de nome raiz, conforme sua
distribuição geográfica em 2012. É exibido o nome, organização e localização.
Fonte: Kurose; Ross, 2013, p. 135
É possível visualizar um mapa completo e atualizado desses servidores,
através do site http://www.root-servers.org, conforme mostrado pela Figura 1.4.
Fonte: Root-Server, 2013 Figura 1.4: DNS Root Servers distribuídos pelo mundo
Figura 1.3: Servidores DNS raiz em 2012
19
Os servidores TLD são responsáveis por domínios de alto nível, como por
exemplo, domínios com, org, net, edu e gov, além de todos os domínios de alto nível
que identificam os países, como, por exemplo, br, uk, fr, ca e jp. (KUROSE; ROSS,
2013)
Os servidores de nomes com autoridade são aqueles utilizados por empresas
para que seus serviços possam ser acessados pela Internet. Dentre esses serviços
podemos citar servidores web e correio eletrônico. Os servidores de nomes raiz, TLD
e com autoridade pertencem à hierarquia de servidores DNS, como exemplifica a
Figura 1.5. (KUROSE; ROSS, 2013)
Fonte: Kurose, Ross, 2013, p. 134
Outra funcionalidade muito importante dos servidores DNS é o cache DNS. O
Cache é utilizado extensivamente para melhorar o desempenho e reduzir o tráfego
de mensagens DNS pela Internet e seu funcionamento é extremamente simples.
Quando o servidor recebe uma resposta DNS, ele faz cache das informações em
sua memória local. Se em uma próxima consulta o servidor possuir no cache a
informação para o host em questão, ele fornecerá o endereço desejado, mesmo que
não seja a autoridade para este domínio. (KUROSE; ROSS, 2013)
Todo domínio, independente de ser um único host ou um domínio de nível
superior, pode ter um conjunto de registros de recursos associados a ele. Para um
único host, o registro de recurso mais comum é apenas o seu endereço IP, porém
existem muitos outros tipos de registros de recursos. Um registro de recurso é uma
tupla de cinco campos: Domain Name – informa o domínio ao qual esse registro se
aplica; Time to Live – fornece uma indicação de estabilidade do registo; Class – No
caso de informações relacionadas à Internet, ele é sempre definido como IN; Type –
Figura 1.5: Hierarquia de servidores DNS
20
Informa qual o tipo do registro; e Value – um número, nome de domínio ou string
ASCII, sendo que sua semântica dependerá do tipo de registro. Os principais tipos
de registros para o sistema IPv4 são mostrados na Tabela 1.1. (TANENBAUM, 2003)
Tabela 1.1 - Principais tipos de registros de recursos DNS para IPv4Tipo Significado Valor
SOA Início de autoridade Parâmetros para essa zona
A Endereço IP de um host Inteiro de 32 bits
MX Troca de mensagens de correioPrioridade, domínio disposto a aceitar
correio eletrônico
NS Servidor de nomesNome de um servidor para este
domínio
CNAME Nome canônico Nome alternativo de um endereço IP
PTR Ponteiro CPU e sistema operacional em ASCII
HINFO Descrição de host Texto ASCII não-interpretado
TXT TextoFonte: Tanenbaum, 2003, p. 621
No DNS, existe somente um servidor primário (master) para cada domínio,
sendo que os dados do DNS são fornecidos à base de dados do servidor primário
pelo administrador do domínio. Há também o servidor secundário (slave) que possui
a base de dados completa, referente a um determinado domínio replicada a partir do
servidor primário (master). (TEIXEIRA JR. et al.1998)
1.2.1 BIND
O Bind é o software open-source que implementa o protocolo DNS para a
Internet. Além de ser uma implementação de referência desses protocolos, também
é um software de nível de produção, adequado para uso em aplicações de alto
volume e de alta confiança. O Bind fornece uma plataforma robusta e estável sobre
a qual as organizações podem construir sistemas de computação distribuída com o
conhecimento que esses sistemas são totalmente compatíveis com os padrões de
DNS publicados. (ISC-BIND, 2013)
A distribuição do Bind possui três partes: Um servidor de DNS (named –
name daemon) responsável por responder a todas as perguntas recebidas, seguindo
as regras especificadas nos padrões de protocolo DNS; um resolver – um programa
21
que resolve questões sobre nomes, enviando as perguntas para servidores
apropriados e responder adequadamente às respostas dos servidores; e
ferramentas para teste de servidores que servem para auxiliar em testes e
diagnósticos. (ISC-BIND, 2013)
1.3 LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP)
O protocolo LDAP é uma versão simplificada do serviço de diretório X.500,
sendo descrito pela RFC 2251. Suas informações são organizadas como uma árvore
e permite a consulta em diferentes componentes. (TANENBAUM, 2003)
Os dados LDAP assumem a forma de listas de propriedades, conhecidas
como “entradas”, cada uma contendo um conjunto de atributos junto com os valores
desses atributos. As entradas são organizadas em uma hierarquia, pelo uso de
nomes distintos, que acaba formando um tipo de caminho de pesquisa. As entradas
LDAP são esquematizadas pelo uso de um atributo objectClass, que especificam os
atributos que uma entrada pode conter, alguns dos quais podem ser exigidos para
validação. O aninhamento e a combinação das classes de objeto são feitos baseado
no conceito de orientação a objetos, sendo que o nível superior da árvore é a classe
top, conforme ilustrada pela Figura 1.6. (NEMETH et al., 2007)
Fonte: Carter, 2003, p. 10
A tabela 1.2 lista alguns nomes de atributos comuns em hierarquias LDAP.
Figura 1.6: Exemplo de uma árvore de diretório LDAP
22
Tabela 1.2 - Nomes de atributo comuns encontrados em hierarquias LDAPAtributo Significado O que é
Atributo OrganizaçãoIdentifica frequentemente a entrada de
primeiro nível de uma instalação
ou Unidade Organizacional Uma subdivisão lógica
cn Nome Comum O nome mais natural para representar a
entrada
dc Componente de domínioUtilizado em sites que modelam sua
hierarquia LDAP com base no DNS
objectClass Classe de objetosEsquema ao qual os atributos dessa
entrada obedecemFonte: Nemeth et al., 2007, p. 362
Segundo Battisti e Santana (2009), um nome LDAP é formatado pelo caminho
completo do objeto, partindo do domínio raiz, até chegar ao objeto referenciado.
Serão usados os exemplos a seguir, para entender o formato de um nome LDAP:
CN=jsilva,OU=contabilidade,DC=vendas,DC=abc,DC=COM – Este nome
representa o usuário jsilva, cuja conta esta contida na unidade organizacional
contabilidade do domínio vendas.abc.com.
CN=maria,OU=auditoria,DC=euro,DC=vendas,DC=abc,DC=COM – Este
nome representa o usuário maria, cuja conta esta contida na unidade organizacional
auditoria do domínio euro.vendas.abc.com.
1.4 KERBEROS
O Kerberos é um protocolo de autenticação de rede, sendo desenvolvido para
prover forte autenticação para aplicações cliente/servidor com o uso de criptografia
através de senha. Uma implementação gratuita desse protocolo está disponível
através do MIT e também em diversos produtos comerciais. (KERBEROS, 2013)
Segundo Garman (2003), a definição completa do que o Kerberos provê é:
segurança, login unificado, confiabilidade e mutua autenticação de serviços de
terceiros, destacando-se os seguintes recursos:
Segurança – As senhas nunca são transmitidas sem criptografia pela rede. O
Kerberos é o pioneiro na utilização de tickets. Os tickets são mensagens
criptografadas com tempo de validade pré-definido que provê a identidade para um
23
servidor requisitante, sem a necessidade do envio constante de senhas pela rede ou
o armazenando das senhas no disco local do servidor.
Login unificado – O usuário identifica-se (provê seu usuário e senha)
apenas uma vez. Uma vez autenticado no Kerberos, no início da sessão, suas
credenciais são passadas de forma transparente para todos os outros recursos que
ele acessar durante o dia.
Confiança em terceiros – refere-se ao fato de que o Kerberos funciona
através de um servidor de autenticação central que todos os sistemas na rede
devem confiar. Todas requisições de autenticação passam obrigatoriamente pelo
servidor Kerberos centralizado.
Autenticação mútua – o Kerberos assegura-se que não somente o usuário
que digitou seu usuário e senha seja quem ele é, porém que o servidor que ele se
comunica seja quem ele é. A autenticação mútua protege a confidenciabilidade de
informações sensíveis que assegura que o serviço que o usuário se comunica é
genuíno.
A Figura 1.7 exemplifica o funcionamento de um domínio Kerberos.
Fonte: Siqueira, 2009, p. 110Figura 1.7: Exemplo de domínio Kerberos
24
Em resumo, o Kerberos é uma solução de diversos problemas de segurança
de rede pois provê as ferramentas de autenticação e forte criptografia sobre a rede
para ajudar a manter seguras suas informações de sistemas em toda a empresa.
(KERBEROS, 2013)
O sistema de autenticação utilizado no Kerberos atinge diversos objetivos
para melhorar a segurança mantendo a conveniência ao mesmo tempo. Ele provê
autenticação centralizada em um servidor (ou um conjunto de servidores), cada um
contendo uma base de dados de todos os usuários e serviços que utilizam o
Kerberos. Para não permitir o tráfego de senhas sem criptografia na rede, o
Kerberos trabalha com tickets criptografados para assegurar a identidade do usuário
e dos servidores de rede. Esses tickets são gerados assim que o usuário se
autentica na rede. (GARMAN, 2003)
1.5 LINUX
Segundo Siqueira (2009), o Linux é um sistema operacional de código aberto
iniciado por Linus Torvalds, cujo objetivo inicial era desenvolver um sistema básico
para estudo e lazer. O Linux em si é apenas o núcleo (kernel) do sistema. Os
programas, compiladores e outros componentes do sistema são projetos de
terceiros, sendo que em sua maioria fazem parte do projeto GNU. O projeto GNU é
liderado por Richard Stallman, renomado desenvolvedor que idealizou todo um
sistema de código aberto, que funcionasse à semelhança dos sistemas Unix
tradicionais.
Pelo fato de o Linux ser um sistema de código aberto existem pessoas,
empresas ou organizações que decidem distribuir o Linux junto com outros
aplicativos, sendo esse o significado essencial de distribuição. Cada distribuição tem
suas próprias características, como por exemplo o sistema de instalação, objetivos,
localização de programas, nome de arquivos, dentre outros. (SILVA, 2010)
Na década de 1990, o Sistema GNU/Linux ganhou muito espaço entre os fãs
de dispositivos de gerenciamento de rede. Ao lançar mão de um sistema
praticamente pronto, que poderia ser alterado e sem restrições de uso, esses
fabricantes reduziam drasticamente os custos de desenvolvimento do produto. O
projeto era beneficiado em consequência, pois todas as melhorias feitas por esses
fabricantes passavam a fazer parte do sistema operacional nas novas versões.
25
(SIQUEIRA, 2009)
Em 1992, Orest Zborowski adaptou o sistema X Window para funcionar com o
Linux. O X Window é uma interface gráfica livre, responsável pelas janelas exibidas
na tela. Essa inovação trouxe o Linux para a versão 0.95. A meta para a versão 1.0
era que o sistema deveria possuir todos os recursos de redes essenciais. Tão logo
as metas para um sistema com recursos satisfatórios e estabilidade foram
alcançadas, surgiram as primeiras distribuições Linux. (SIQUEIRA, 2009)
A reunião do kernel, ferramentas GNU e outros aplicativos utilitários damos o
nome de distribuição. Uma distribuição pode, inclusive, utilizar o kernel Linux e as
ferramentas GNU, adicionando ao pacote de aplicativos softwares proprietários
licenciados, ou adotar a utilização de ferramentas de configuração próprias,
protegidas por copyright. Essas combinações tomam forma nas cerca de 250
distribuições baseadas em Linux que existem atualmente, sob vários tipos de
licença, e com vários enfoques diferentes: existem as distribuições voltadas para
jogos, as educacionais, aquelas voltadas para trabalhos de escritório, para
servidores, etc. (CARMONA, 2007)
O projeto Linux precisava ter uma identidade que o fizesse ser facilmente
reconhecido. Linus Torvalds é fã de pinguins desde o dia que fora mordido por um
em um zoológico australiano. Pela Usenet, ele lançou um concurso para a criação
do logotipo sendo que a ilustração deveria exibir um pinguim um pouco acima do
peso, como que satisfeito logo após finalizar uma refeição. Larry Ewing fez a
imagem vencedora, conforme Figura 1.8, e a mesma foi batizada de Tux.
(SIQUEIRA, 2009)
Fonte: Siqueira, 2009, p. 20Figura 1.8: O mascote do Linux - Tux
26
Dentre os diversos recursos presentes no sistema operacional Linux, podem-
se citar: multitarefa real; multiusuário; utilização de permissões de acesso a
arquivos, diretórios e programas em execução na memória; modularização –
somente é carregado na memória o que é utilizado, inclui drivers de periféricos e
recursos do sistema; suporte nativo a diversas tecnologias como, por exemplo,
balanceamento de carga, ip alias, failover, vlan, bridge, trunking, open shortest path
first (OSPF), border gateway protocol (BGP); suporte nativo a múltiplas CPU's;
roteamento estático e dinâmico de pacotes; dentre outros. (SILVA, 2010)
1.5.1 Debian GNU/Linux
Segundo Carmona (2007), em 1993 o americano Ian Murdock lançou o
projeto Debian, adotando o modelo de desenvolvimento do Linux para uma
distribuição em sua totalidade.
Debian é, ao mesmo tempo, o nome de uma distribuição não comercial do
kernel GNU/Linux e de um grupo de desenvolvedores voluntários, espalhados pelo
mundo. Como o Debian é fortemente estruturado tanto na filosofia quanto na
concepção e utilização de ferramentas do projeto GNU ele é usualmente chamado
de Debian GNU/Linux. (CARMONA, 2007)
O Debian GNU/Linux possui suporte a língua Portuguesa, é a única que tem
suporte a quatorze arquiteturas diferentes, por exemplo, i386, IA64, AMD64, Alpha,
Sparc, PowerPc, Macintosh e Arm. (SILVA, 2010)
O Projeto Debian lançou suas versões 0.9x em 1994 e 1995. Neste último
ano ganhou notoriedade o sistema de empacotamento do Debian, o dpkg,
principalmente devido a sua alta taxa de compactação. Em 1996, Bruce Perens
substituiu Ian Murdock como líder do projeto. A primeira ação da nova liderança,
seguindo a linha “filosófica” do Debian foi a redação de vários documentos
importantes: o contrato social e o free software guidelines.
Segundo DEBIAN-RELEASES (2013), o Debian Gnu/Linux possui três
versões, stable, testing e unstable, suas respectivas características são:
stable (estável): é a última versão oficial lançada, sendo a recomendada para
uso em produção;
testing (testes): contém os pacotes que ainda não foram aceitos na versão
estável, mas que estão na fila para aprovação. A vantagem do uso dessa
27
distribuição é que a mesma possui versões mais atualizadas dos softwares;
unstable (instável): é onde o desenvolvimento ativo do Debian ocorre, sendo
uma distribuição mais utilizada por desenvolvedores.
Os nomes das versões oficiais de lançamento são retirados do filme Toy Story
da Pixar. As versões já lançadas são: 1.1 – Buzz, 1996; 1.2 – Rex, 1996; 1.3 – Bo, 2
de junho de 1997; 2.0 – Hamm, 24 de julho 1998; 2.1 – Slink, 9 de março de 1999;
2.2 – Potato, 15 de agosto 2000; 3.0 – Woody, 19 de julho de 2002; 3.1 – Sarge, 6
de junho de 2005; 4.0 – Etch, 8 de abril de 2007; 5.0 – Lenny, 15 de fevereiro de
2009; 6.0 – Squeeze, 6 de fevereiro de 2011; 7.0 – Wheezy, 4 de maio de 2013. A
próxima versão, ainda sem previsão de lançamento, será nomeada Jessie.
(DEBIAN-RELEASES, 2013)
28
2 MICROSOFT® ACTIVE DIRECTORY
Este capítulo descreve os conceitos e tecnologias relacionadas ao
funcionamento e estrutura interna do Microsoft Active Directory.
2.1 NOMENCLATURAS E CAMINHOS UNC
O AD além de uma base de dados e um conjunto de serviços também
interage e depende de vários outros serviços e padrões para seu completo
funcionamento. O AD foi projetado baseado em padrões de diretórios, definidos por
entidades internacionais de padronização, tais como a International
Telecommunication Union (ITU), International Organization for Standardization (ISO)
e o Internet engineering Task Force (IETF). Essas instituições trabalham em
conjunto ou em colaboração para definir uma série de padrões que dão suporte a
serviços de diretórios. (BATTISTI; SANTANA, 2009)
Um padrão de uso genérico é o X.500 porém apesar de sua grande
abrangência ele é bastante complexo e acabou por não ser adotado em sua
totalidade como um padrão de mercado para a criação de serviços de diretórios. Um
mais leve e que efetivamente tornou-se padrão de mercado é o LDAP. O LDAP
fornece mecanismos de acesso aos objetos do AD, de tal maneira que qualquer
programa ou sistema habilitado ao padrão LDAP será capaz de acessar as
informações do AD. O padrão LDAP define um sistema de nomeação hierárquico,
através do qual é possível referenciar qualquer objeto do AD. (BATTISTI; SANTANA,
2009).
Segundo Battisti e Santana (2009), um nome LDAP é formado pelo caminho
completo do objeto, a partir do domínio raiz até chegar ao objeto referenciado. Nesta
nomenclatura hierárquica são utilizadas algumas abreviaturas, conforme descrito a
seguir:
CN: common name: por exemplo, o nome da conta de um usuário, grupo ou
computador;
OU: faz referência a uma unidade organizacional;
DC: um componente de domínio: Normalmente o nome de um domínio;
O: Nome da organização. Normalmente representado pelo nome do domínio
29
Root;
C: Country: identificação de país, não sendo normalmente utilizado;
Segundo Battisti e Santana (2009), a nomenclatura para localização de
recursos em um servidor segue o padrão Universal Naming Convention (UNC).
Neste padrão, um recurso é identificado pelo nome do servidor, separado do nome
do recurso por uma barra. Abaixo são ilustrados alguns exemplos comuns de uso
deste tipo de nomenclatura:
\\server01.vendas.abc.com\documentos – Caminho para uma pasta
compartilhada com o nome de compartilhamento “documentos” no servidor server01
do domínio vendas.abc.com;
\\10.10.20.5\documentos – Exemplo anterior utilizando o número de IP do
servidor ao invés do nome DNS;
\\pr-server.prod.abc.com\laser01 – Caminho para uma impressora
compartilhada com o nome de compartilhamento “laser01” no servidor pr-server do
domínio prod.abc.com;
\\10.10.30.5\laser01 – Exemplo anterior onde foi utilizado o endereço IP do
servidor ao invés do nome DNS;
vendas.abc.com\jsilva – referência ao usuário jsilva do domínio
vendas.abc.com;
VENDAS\jsilva – referência ao usuário jsilva do domínio vendas.abc.com
utilizando apenas o nome NETBIOS.
2.2 INTRODUÇÃO AO ACTIVE DIRECTORY
O AD é uma implementação da Microsoft, de um serviço de diretórios que
provê autenticação centralizada e serviços de autorização com armazenamento e
gerenciamento de segurança, como por exemplo, usuários, grupos de computadores
e controle de permissão de recursos de rede. Adicionalmente, uma grande variedade
de produtos voltados para empresas, incluindo o Servidor Exchange e os Serviços
Sharepoint, necessitam do AD para funcionamento. Os requisitos para
funcionamento de um servidor Windows (versão 2008) são ilustrados na tabela 2.1.
(POLICELLI, 2009)
30
Tabela 2.1 - Requisitos de Hardware – Windows Server 2008
Componente Requisitos
Processador Mínimo: 1GHz (para processadores x86) ou 1.4GHz (para
processadores x64) – Recomendado: 2GHz ou mais
Memória Mínimo: 512MB – Recomendado: 2GB ou mais
Máximo (sistemas de 32-bit: 4GB (versão Standard) ou 64GB
(versões Enterprise ou Datacenter)
Máximo (Sistemas de 64-bit): 32GB (versão Standard) ou
2 TB (versões Enterprise, Datacenter, ou Itanium-Based)
Espaço em
disco/outros
Mínimo: 10GB – Recomendado: 40GB ou mais
NOTA: Computadores com mais de 16GB de memória requerem
mais espaço em disco para paginação, hibernação e logs.
Drive de DVD-ROM
Monitor com resolução VGA (800 x 600) ou superior
Teclado/MouseFonte: Policelli, 2009, p. 7
Segundo Battisti e Santana (2009), os principais elementos que compõem e
mantém em funcionamento o AD são: Domínios, Árvores, Relações de
confiança/Florestas, Principais objetos do AD (contas de usuário, grupos de usuários
e contas de computador), Unidades organizacionais, Schema e Sites.
Esses elementos compõem a chamada estrutura lógica do AD, ou seja, a
maneira como o AD é apresentado ao administrador e aos usuários, quando estes
utilizam as ferramentas de administração e pesquisa do AD. A estrutura lógica pode
ser diferente (normalmente é) da estrutura física. A estrutura física determina onde
são armazenadas as informações do AD, e as informações são sincronizadas entre
os diferentes Domain Controller (DC). Este processo conhecido como replicação.
(BATTISTI; SANTANA, 2009)
Segundo Battisti e Santana (2009), além do banco de dados com informações
sobre os elementos (objetos) que compõem o domínio, o AD também disponibiliza
uma série de serviços que executam as seguintes funções: Replicação entre
controladores de Domínio; Autenticação; Pesquisa de objetos na base de dados;
Interface de programação para acesso aos objetos do diretório.
Os domínios AD são nomeados usando o DNS. Pode-se agrupar domínios
que fazem parte do mesmo DNS dentro da mesma árvore do domínio sendo esse o
31
motivo de o DNS ser um dos pré-requisitos para que o AD possa ser configurado e
funcionar perfeitamente. (HUNTER; ALLEN, 2009)
A Figura 2.1 representa a hierarquia de um domínio Active Directory e entre
seus objetos.
Fonte: Desmond, et. al, 2013, p. 6
2.2.1 Domínios
Um domínio é constituído por um grupo de servidores, estações de trabalho
que concordam em centralizar os nomes de contas de usuário e máquinas em um
banco de dados compartilhado, e com isso permitir que um usuário tenha apenas
um nome de conta e senha e possa utilizá-lo em qualquer computador dentro do
domínio de uma organização. (MINASI, M. et al., 2003)
Segundo Battisti e Santana (2009), todos os servidores que contém uma
cópia da base de dados do AD fazem parte do domínio. Cada estação de trabalho
que faz parte do domínio possui uma conta de computador criada, sendo essa o
mesmo nome da estação na rede.
Um domínio também pode ser definido com um limite administrativo e de
segurança pois a conta de administrador possui permissão de acesso em todos os
recursos do domínio mas não em recursos de outros domínios. Ele é um limite de
segurança porque cada domínio tem definições de políticas de segurança que se
Figura 2.1: Hierarquia de um domínio Active Directory
32
aplicam as contas de usuário e demais recursos dentro do domínio. Em um domínio
baseado no AD, é possível ter dois tipos de servidores: DC e Servidor Membro
(Member Server). (BATTISTI; SANTANA, 2009)
2.2.2 Árvores
Segundo Battisti e Santana (2009), uma árvore é o agrupamento ou arranjo
hierárquico de um ou mais domínios que compartilham o mesmo nome de espaço,
conforme exemplificado na Figura 2.2.
Fonte: Battisti; Santana, 2009, p. 296
Na Figura 2.2 é exibida uma árvore com 7 (sete) domínios, sendo que o
domínio pai (ou root) é abc.com. Os domínios seguintes são vendas.abc.com e
prod.abc.com. Quando é formada uma hierarquia de domínios, nome de espaço
significa que os nomes dos objetos filho contém o nome do objeto pai. Com isso
uma árvore de diretórios forma um espaço de nomes contínuo, onde o nome do
objeto filho sempre contém o nome do objeto pai. (BATTISTI; SANTANA, 2009)
2.2.3 Relação de Confiança e Florestas
Uma floresta é uma coleção de uma ou mais árvores de domínio. Estas
árvores de domínio compartilham o mesmo esquema e contêiner, e essas árvores
estão conectadas entre si através de relações de confiança transitivas. (DESMOND,
Figura 2.2: Domínios de uma árvore
33
et al., 2013)
Por meio do uso de relações de confiança entre domínios, é possível que um
usuário de domínio possa fazer logon com sua conta de usuário e senha, mesmo
utilizando o computador de outro domínio. As relações de confiança são criadas
automaticamente entre os domínios de uma árvore de domínios. As relações são
bidirecionais, ou seja, se o domínio “Dom A” confia no domínio “Dom B”, isso
significa que o domínio “Dom B” também confia no domínio “Dom A”. As relações de
confiança são transitivas, ou seja, se “Dom A” confia em “Dom B”, o qual confia em
“Dom C”, então o “Dom A” também confia no “Dom C” e vice-versa. (BATTISTI;
SANTANA, 2009)
A Figura 2.3 ilustra o sistema de relações de confiança bidirecional.
Fonte: Battisti; Santana, 2009, p. 307
Segundo Battisti e Santana (2009), as relações de confiança criadas
automaticamente, entre os domínios de uma árvore apresentam as características
descritas anteriormente: Automaticamente criadas, bidirecionais e transitivas. Porém
existem situações em que pode ser necessária a criação de outros tipos de relações
Figura 2.3: Relações de confiança bidirecionais e transitivas
34
de confiança. Por exemplo, pode ser necessária a criação de uma relação de
confiança entre um dos domínios da sua rede, com um domínio baseado no
Windows NT Server da rede de um fornecedor ou parceiro de negócio. Ou pode ser
necessária a criação de uma relação de confiança entre um domínio da sua rede
com um domínio da rede de outra empresa, ambos utilizando a mesma versão do
Windows Server. Neste caso será necessário criar uma relação de confiança com
um domínio em outra árvore de domínios. Abaixo são descritos os tipos de relação
de confiança entre domínios e árvores de domínios.
Transitiva bidirecional entre um Domínio pai e um Domínio filho: Quando
o Administrador cria um domínio filho, uma relação de confiança bidirecional e
transitiva é criada, automaticamente, pelo assistente de instalação do AD. Por
exemplo, um domínio root chamado abc.com e cria um domínio filho chamado
vendas.abc.com, o assistente de instalação do AD, automaticamente cria durante a
criação do domínio vendas.abc.com, uma relação de confiança bidirecional e
transitiva entre os domínios abc.com e vendas.abc.com.
Transitiva bidirecional entre uma árvore de domínios e o domínio root de
uma floresta: Pode-se juntar várias árvores de domínios para formar uma floresta.
Este tipo de relação de confiança é automaticamente criado, quando cria-se um
novo domínio em uma floresta já existente.
Externa, não transitiva, unidirecional ou bidirecional: Este tipo de
relacionamento é criado com um domínio externo localizado em outra floresta. Se o
domínio for baseado no NT Server 4.0 a relação será unidirecional, caso contrário
será bidirecional. Cabe ressaltar que para ser bidirecional a relação deve ser criada
e configurada nos dois domínios. Para criar uma relação externa, bidirecional entre o
domínio abc.com da árvore abc.com e o domínio vendas.xyz.com da árvore
xyz.com, a relação tem que ser criada no domínio abc.com pelo administrador deste
domínio e também no domínio vendas.xyz.com pelo respectivo administrador.
Somente após esse processo ela será bidirecional. Caso contrário, se for criada
somente em um dos domínios, ela será unidirecional.
A Figura 2.4 ilustra uma relação de confiança deste tipo.
35
Fonte: Battisti; Santana, 2009, p. 308
Realm, transitiva ou não transitiva, unidirecional ou bidirecional: Este
tipo de relação é criado entre um domínio baseado no Windows Server e outros
domínios não Windows, também baseado no protocolo Kerberos, como por exemplo
o UNIX. O protocolo Kerberos é um padrão de fato que fornece, dentre outros,
serviços de autenticação em um domínio do Windows Server. Outros sistemas
operacionais também utilizam o Kerberos. Este tipo de relacionamento poderia ser
utilizado, por exemplo, para que as contas de um domínio baseado no UNIX,
pudessem receber permissões de acesso em recursos de um domínio baseado no
Windows Server.
Entre florestas, transitiva, unidirecional ou bidirecional: Este tipo de
relacionamento é criado entre os domínios root de duas florestas. Pode ser do tipo
unidirecional ou bidirecional. Se for do tipo bidirecional, os usuários de uma floresta
podem acessar recursos nos domínios da outra floresta e vice-versa. Um exemplo
prático de uso deste tipo de relação de confiança seria quando é feita a fusão de
duas empresas e seja necessário permitir que os usuários de uma empresa possam
acessar recursos nos servidores da rede da outra empresa.
Shortcut, transitiva, unidirecional ou bidirecional: Este tipo de relação de
confiança é utilizado para melhorar o tempo de logon entre dois domínios, em uma
Figura 2.4: Relações de confiança externas – unidirecional ou bidirecional
36
floresta. O principal objetivo deste tipo de relação de confiança é otimizar os tempos
de logon. Quanto mais afastados (quanto maior o caminho e o número de relações
de confiança a ser percorrido), menor será o tempo de logon entre os domínios, se o
Administrador criar uma relação de confiança do tipo Shortcut. Importante: Só faz
sentido criar este tipo de relação de confiança, se for comum usuários de um
domínio acessarem recursos do outro domínio e se o tempo de logon apresentar
tempos muito elevados a 2.5 exemplifica uma relação desse tipo. A Figura 2.5 ilustra
uma relação de confiança desse tipo.
Fonte: Battisti; Santana, 2009, p. 308
2.2.4 Contas de Usuário
Todo usuário que quer ter acesso aos recursos dos computadores do domínio
(pastas compartilhadas, impressoras compartilhadas, etc) deve ser cadastrado no
AD. Cadastrar o usuário, significa criar uma conta de usuário e uma senha. Ao
cadastrar um usuário, outras informações tais como: seção, nome completo,
endereço, telefone, etc, podem ser cadastradas. (BATTISTI; SANTANA, 2009)
As contas de usuário são os objetos mais frequentemente usados no AD.
Através desse tipo de objeto são criados os meios de autenticação e autorização
para acessar recursos disponíveis na rede. Em particular, o AD gerencia
informações sobre senhas de usuário, grupos, ativar/desativar ou expirar uma conta
de usuário. (HUNTER; ALLEN, 2009)
Figura 2.5: Relação de confiança do tipo Shortcut
37
Segundo Battisti e Santana (2009), uma conta precisa ser criada somente
uma vez, em um dos Controladores de domínio. Após criada, a conta será replicada
para os demais DC do domínio. As contas de usuário também podem ser criadas
com o Windows 2000 Professional, Windows XP Professional ou Windows 7
Professional. As contas criadas nestes computadores são conhecidas como contas
locais, ou seja, existem somente no computador onde foram criadas, sendo
recomendado que:
Todo usuário que acessa a rede deve ter a sua própria conta: Não é
recomendado que dois ou mais usuários compartilhem a mesma conta. A conta é a
identidade do usuário para a rede;
Com base nas contas de usuários e grupos: O administrador pode habilitar
ou negar permissões de acesso aos recursos da rede, como por exemplo, restringir
o acesso às pastas e arquivos compartilhados, definindo quais usuários podem ter
acesso e qual o nível de acesso de cada usuário – leitura, leitura e alteração,
exclusão e assim por diante;
Utilização de um padrão para o nome das contas de usuários: Não
podem existir dois usuários com o mesmo nome de logon dentro do mesmo
Domínio. Para isso é importante que seja definido um padrão e no caso de nomes
iguais deve ser definido uma maneira de diferenciá-los;
Podem ter no máximo 20 caracteres e os seguintes caracteres não
podem ser utilizados: “ / \ : ; [ ] | = , + * ? < > e
Sempre que você for cadastrar um usuário também deve ser cadastrada
uma senha para o usuário: O administrador pode especificar um número mínimo
de caracteres aceito para a senha. O número máximo de caracteres da senha é 128.
Para as senhas, o Windows Server distingue letras maiúsculas de minúsculas.
2.2.5 Grupos de Usuários
Segundo Battisti e Santana (2009), um grupo de usuários é uma coleção de
38
contas de usuários. A principal função dos grupos de usuários é facilitar a
administração e a atribuição de permissões para acesso a recursos, tais como:
pastas compartilhadas, impressoras remotas, serviços diversos, etc, pois em vez de
conceder permissões individualmente para cada usuário que necessitar acessar um
determinado recurso, cria-se um grupo, inclui os usuários no grupo e atribui
permissões para o grupo. Para que um usuário tenha permissão ao recurso, basta
incluir o usuário no grupo, pois todos os usuários de um determinado grupo, herdam
as permissões dos grupos aos quais o usuário pertence. A Figura 2.6 exemplifica a
herança de permissões.
Fonte: Battisti; Santana, 2009, p. 292
Segundo Desmond, et al. (2013), o AD suporta três escopos de grupo: Local,
Global e Universal. Grupos em cada um desses escopos comportam-se de forma
diferente baseado nos níveis de funcionalidade do domínio e da floresta. Cada grupo
acima relacionado pode ter dois tipos: distribuição e segurança. Se o tipo é
distribuição, o SID não é adicionado ao token durante o logon, não podendo ser
utilizado para propósitos de segurança. Grupos de distribuição são normalmente
utilizados para listas de distribuição de mensagens (grupos de e-mail, por exemplo)
porém também podem ser utilizados para propósitos de segurança em aplicativos
com suporte a grupos LDAP porém que não utilizem o modelo de segurança do
Windows.
Segundo Battisti e Santana (2009), o escopo de um grupo determina em que
partes do domínio ou de uma floresta o grupo será visível, podendo ser utilizado
para receber permissões de acesso aos recursos de rede. As principais
características e uso de cada tipo são:
Universal: Pode ser utilizado em qualquer parte do domínio; Pode conter
Figura 2.6: Usuário herda as permissões do grupo
39
contas de usuários, outros grupos universais e grupos globais de qualquer domínio;
Pode ser membro de grupos locais do domínio ou grupos universais e grupos
globais de qualquer domínio; Pode receber permissões para recursos localizados
em qualquer domínio.
Global: Pode ser utilizado em qualquer domínio; Pode conter contas de
usuários e grupos globais do mesmo domínio; Pode ser membro de grupos
universais e grupos locais do domínio, de qualquer domínio e pode ser membro de
qualquer grupo global do mesmo domínio; Pode receber permissões para recursos
localizados em qualquer domínio.
Local: Utilizados para atribuir permissões de acesso aos recursos de rede.
Segundo Desmond, et al. (2013), pode haver necessidade de conversão entre
tipos, contudo existem algumas restrições e observações, abaixo listadas:
• Grupos de segurança podem ser convertidos em grupos de distribuição;
• Grupos de distribuição podem ser convertidos em grupos de segurança;
• Um grupo Local pode ser convertido em um grupo universal desde que o
grupo local não seja membro de outro grupo local;
• Um grupo global pode ser convertido em um grupo universal desde que o
grupo global não seja membro de outro grupo global;
• Um grupo do domínio universal pode ser convertido em um grupo global
desde que o grupo local não seja membro de outro grupo local;
• Um grupo universal pode ser convertido para um global desde que todos os
membros no grupo sejam usuários do grupo;
• Um grupo universal pode ser convertido para local.
2.2.6 Contas de Computador
Segundo Battisti e Santana (2009), estações de trabalho que rodam o
Windows NT Workstation 4.0, Windows 2000 Professional, Windows XP Professional
ou Windows 7 e que fazem parte do domínio, devem ter uma conta de computador
no AD. Servidores, sejam membros ou DCs, rodando Windows NT Server 4.0 ou
Windows Server, também precisam possuir contas de computador no AD. A conta de
40
computador pode ser criada antes do computador ser adicionado ao domínio ou no
momento em que o computador é configurado para fazer parte do domínio. A conta
do computador deve ter o mesmo nome do computador na rede. Por exemplo, um
computador com o nome de microxp01, terá uma conta no AD, com o nome:
microxp01. Computadores rodando Windows 95/98/Me, mesmo tendo acesso à lista
de usuários e grupos do domínio, não terão contas de computador criadas no AD.
2.2.7 Unidades Organizacionais
Segundo Battisti e Santana (2009), uma unidade organizacional é uma
divisão lógica do domínio, a qual pode ser utilizada para organizar os objetos de
determinado domínio em um agrupamento lógico para efeito de administração.
Segundo Desmond, et al. (2013), quando se visualiza internamente um
domínio AD, se enxerga uma estrutura hierárquica dos objetos. Esta hierarquia é
feita de objetos que podem servir de contêiner e outros não. O primeiro tipo de
contêiner que será criado para acomodar os objetos é chamado de Unidade
Organizacional. Uma unidade organizacional também pode possuir políticas de
grupos específicas aplicadas a ela.
Segundo Battisti e Santana (2009), as Unidades Organizacionais devem ser
utilizadas quando:
For necessário representar a estrutura e organização da companhia em
um domínio. Sem a utilização de Unidades Organizacionais, todas as contas de
usuário serão mantidas e exibidas em uma única lista, independente da localização,
departamento ou função do usuário;
For necessário delegar tarefas administrativas sem para isso dar
poderes em todo o Domínio. Com o uso de Unidades Organizacionais, poderão
ser concedidas permissões para um usuário somente em nível de Unidade
Organizacional;
Facilitar e melhor acomodar alterações na estrutura da companhia. Por
exemplo, é mais fácil mover contas de usuário entre Unidades Organizacionais do
que entre domínios.
A Figura 2.7 ilustra a divisão de um domínio em Unidades Organizacionais.
41
Fonte: Battisti; Santana, 2009, p. 304
2.2.8 Schema
Segundo Battisti e Santana (2009), a definição de todos os objetos do AD e
demais informações esta contida no que é conhecido como Schema do AD,
utilizando um modelo de banco de dados hierárquico, ou seja, a definição de cada
objeto e seus atributos está contida no Schema. Quando um novo objeto é criado, as
informações são validadas com base nas definições contidas no Schema antes que
o objeto seja salvo na base de dados do AD. O Schema é feito de objetos, classes e
atributos, sendo que o Schema definido por padrão com o AD contém um número de
classes e atributos que atende as necessidades da maioria das empresas, sendo
permitido ao administrador modificar as classes existentes ou adicionar novas
classes ou atributos, sendo que essas modificações devem ser cuidadosamente
planejadas, pois afetarão toda a árvore de domínios. Todos os domínios de uma
árvore têm que utilizar o mesmo Schema, ou seja, não podem ser utilizados
diferentes Schemas para os diferentes domínios de uma árvore de domínios.
Uma característica interessante do AD, não comum em outras
implementações do LDAP, é que o Schema é armazenado no AD como um conjunto
de Objetos. Isso significa que o Administrador pode utilizar ferramentas para
gerenciar o Schema, da mesma forma que faria em outros objetos sem a
necessidade de desligar ou reiniciar o AD. Todos os Schemas são armazenados no
Figura 2.7: Divisão de um domínio em Unidades Organizacionais
42
contêiner Schema, como por exemplo, cn=schema,cn=configuration,<Floresta>. O
Schema é composto por duas classes de objetos: classSchema e attributeSchema.
O classSchema é responsável pela definição das classes e o attributeSchema é
responsável pela definição de atributos. O contêiner Schema possui um terceiro tipo
de objeto chamado subSchema, também conhecido como abstractSchema, o qual é
definido no LDAP versão 3 (RFC 2251). (HUNTER; ALLEN, 2009)
Cada floresta pode conter um único Schema, ou seja, o Schema tem que ser
único ao longo de todos os domínios da floresta. Uma cópia do Schema é replicada
em todos os controladores de domínio da floresta, sendo que um único DC controla
a estrutura do Schema, sendo conhecido como Schema Master. A cópia replicada
para os outros DC é uma cópia somente leitura. Para que um usuário possa realizar
alterações no Schema, ele deve ser membro do grupo Schema Admins. Caso um
usuário com as permissões adequadas tente realizar a alteração do Schema em um
DC que não seja o Schema Master, será emitida uma mensagem de erro. Após as
modificações no Schema, elas serão replicadas a partir do Schema Master para os
demais DCs da floresta ou árvore de domínios. Cada DC mantém uma cópia do
Schema na memória do servidor para melhorar a performance de operações
relacionadas ao Schema. A versão armazenada no Cache do servidor é
automaticamente atualizada (em intervalos de tempo definidos) cada vez que o
Schema é atualizado. (BATTISTI; SANTANA, 2009)
2.2.9 Sites
O AD possui um elemento conhecido como site que é utilizado para
representar a divisão física da rede e, é de extrema importância para a
implementação de um sistema de replicação otimizado das informações do AD,
entre os diversos DCs de um domínio. Um site no AD é utilizado para representar a
estrutura física da rede. As informações sobre topologia da rede, contidas nos
objetos site e link entre sites são utilizadas pelo AD para a criação de configurações
de replicação otimizadas, sempre procurando reduzir o máximo possível o tráfego
através de links de WAN. Um site normalmente é definido com uma ou mais redes
conectadas por um caminho de alta velocidade, ou seja, é definido por um ou mais
endereços IP e uma ou mais máscaras de sub-rede, ou seja, um conjunto de redes e
sub-redes conectadas por um caminho de alta velocidade. (Battisti; Santana, 2009)
43
Segundo Battisti e Santana (2009), a utilização de sites e links entre sites
facilita a implementação de várias atividades no AD, destacando-se:
Replicação: O AD procura equilibrar a necessidade de manter os dados
atualizados em todos DCs, com a necessidade de otimizar o volume de tráfego
gerado devido à replicação das informações entre os DCs do domínio, sendo que a
replicação entre os DCs de um mesmo site ocorre mais frequentemente do que
entre DCs de sites diferentes.
Autenticação: A informação sobre sites auxilia o AD a fazer a autenticação
dos usuários de uma maneira mais rápida e eficiente. Quando um usuário faz logon
no domínio, o AD primeiro tenta localizar um DC dentro do site definido para a rede
do usuário, evitando que tráfego de autenticação desnecessário seja gerado em
links mais lentos (WAN).
Serviços que possuem “conhecimento” sobre as configurações de sites
existentes na rede: Por exemplo, quando um usuário tenta acessar um serviço que
utiliza este recurso, o serviço tentará fazer com que o usuário acesse um servidor do
mesmo, evitando dessa forma que o usuário acesse um servidor remoto em outro
site gerando tráfego em links mais lentos (WAN). Um exemplo dessa utilização é a
do serviço DFS (permite a criação de réplicas de pastas compartilhadas em vários
servidores de rede). Por exemplo, quando um usuário em sua estação de trabalho
tenta acesso a uma pasta compartilhada no DFS, este é direcionado para uma
réplica em um servidor do mesmo site do usuário.
A Figura 2.8 ilustra a utilização de uma sub-rede para a definição de um site.
Fonte: Battisti; Santana, 2009, p. 315Figura 2.8: Definição de um site
44
2.3 REPLICAÇÃO
Segundo Battisti e Santana (2009), a base de dados do AD com todas
informações completas sobre todos os objetos do AD é armazenada nos DCs do
domínio e as alterações podem ser efetuadas em qualquer DC. Essas alterações
devem ser replicadas para os demais DCs do domínio, de modo que todos os DCs
estejam sincronizados e com uma cópia idêntica da base de dados do AD. Este
processo ocorre o tempo todo, pois alterações no AD são feitas diariamente e a
replicação é um processo contínuo. O AD procura determinar automaticamente qual
a melhor configuração de replicação, procurando obter o menor tempo possível para
atualização dos DCs do domínio, mas balanceando com o volume de tráfego gerado
na rede, de tal maneira que o tráfego gerado pela replicação não venha a
sobrecarregar os links de WAN. As configurações de replicação do AD são feitas
automaticamente pelo processo conhecido como Knowledge Consistency Checker
(KCC), que é um processo que roda em todos os DCs. O KCC automaticamente
identifica as configurações de replicação mais eficientes com base nas
configurações de sites do AD. O KCC regularmente recalcula a topologia de
replicação para ajustar o processo para quaisquer alterações que tenham ocorrido
na estrutura física da rede, como a criação de novos sites ou a inserção de novas
sub-redes em um site existente.
Segundo Desmond et al. (2013), o KCC possui dois tipos de algorítimos
usados para determinar quais objetos de conexão são necessários: intrasite e
intersite.
Intrasite: Designado para criar o mínimo de latência em uma topologia de
anel para cada contexto de nome, de forma que não sejam realizados mais de dois
saltos entre dois DCs em um site. O KCC adiciona e remove as conexões entre os
DCs quando necessário, para manter uma topologia com o mínimo de saltos. A
visualização é simples quando lida-se com um único domínio e um número pequeno
de controladores de domínio, porém fica extremamente difícil de visualizar quando
são adicionados diversos DCs e domínios adicionais.
Intersite: Não é um algorítimo baseado em um número mínimo de saltos. Ele
tenta determinar quais sites são conectados entre si através de um algorítimo de
spanning-tree e cria métricas para realizar as conexões entre os servidores. Uma
45
topologia de site bem definida auxiliará o KCC a gerar uma coleção de objetos para
replicação de forma mais inteligente e eficiente. A Figura 2.9 exemplifica uma
topologia de replicação simples.
Fonte: Desmond et al., 2013, p. 123
2.4 FUNCIONALIDADES DE UM DOMÍNIO
Segundo Battisti e Santana (2009), o nível de funcionalidade do domínio
determina quais características estão ou não disponíveis no domínio e quais versões
do Windows podem ou não estar presentes nos DCs do domínio. No Windows
Server 2008 existem quatro níveis de funcionalidade: Windows 2000 Misto; Windows
2000 Nativo; Windows Server 2003; Windows Server 2008.
O nível de funcionalidade Windows 2000 misto é o único que permite que
existam DCs com NT Server 4.0, porém não é possível instalar DCs com o Windows
Server em um domínio com o nível Windows 2000 Misto, pois muitos dos recursos
mais avançados, tais como grupos Universais somente estão disponíveis nos
demais níveis de funcionalidade. Este nível deve ser utilizado apenas na fase de
migração de DCs NT Server 4.0. Após a migração do último DC com NT Server 4.0 o
nível de funcionalidade do domínio pode ser alterado para os demais níveis.
(BATTISTI; SANTANA, 2009).
Segundo Battisti e Santana (2009), o nível de funcionalidade da floresta é
uma novidade que foi introduzida com o Windows Server 2003, existindo três níveis:
Windows 2000; Windows Server 2003; Windows Server 2008.
Figura 2.9:Topologia de replicação simples
46
A tabela E.1 disponível no Anexo E descreve as funcionalidades disponíveis e
quais versões do Windows podem ser utilizadas nos DCs para cada um dos modos
de funcionalidade do domínio.
A tabela F.1 disponível no Anexo F descreve quais funcionalidades estão
disponíveis e quais versões do Windows podem ser utilizadas nos DCs para cada
um dos modos de funcionalidade de floresta.
2.5 GROUP POLICY OBJECT (GPO)
Segundo Desmond et al. (2013), as políticas de grupo são utilizadas por um
administrador para definir o ambiente para usuários e computadores. O escopo e
funcionalidades das GPO podem ser estendidos a uma grande diversidade de
objetos e ações.
Segundo Battisti e Santana (2009), com o uso de GPO é possível:
• Gerenciar centralizadamente configurações definidas no registro do Windows,
com base em modelos de administração;
• Atribuição de scripts a serem executados na inicialização, desligamento,
logon e logoff do Windows;
• Redirecionamento de pastas, tais como Documentos, Imagens, Downloads
para que elas sejam automaticamente gravadas em um servidor, facilitando e
flexibilizando uma possível política de backup centralizada;
• Gerenciamento de software, permitindo que um administrador possa fazer as
instalações de maneira centralizada, sendo possível associar uma aplicação a
um grupo de usuários;
• Definir configurações de segurança para computadores executando o
Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Windows
Server 2008 ou Windows 7.
É possível criar objetos do tipo GPO e associá-los a diferentes elementos do
AD, podendo ser um domínio, unidade organizacional ou um site. Também é
possível a criação de GPO localmente em cada computador, desde que eles estejam
executando o Windows 2000, Windows XP, Windows Vista, Windows Server 2003,
Windows Server 2008 ou Windows 7. A ordem de aplicação das GPOs é:
• GPO local;
47
• GPO definida para o site ao qual o computador pertence;
• GPO do domínio;
• GPO da unidade organizacional ou um filho (grupos, computadores, etc).
2.6 CONSOLE DE ADMINISTRAÇÃO E SNAP-IN
Segundo Battisti e Santana (2009), o Microsoft Management Console (MMC)
foi criado para servir como uma interface unificada para a administração e
gerenciamento dos mais variados recursos do Windows. Nas versões anteriores ao
Windows 2000, como por exemplo, o Windows NT Server 4.0 e 3.5.1 cada
ferramenta administrativa apresentava uma interface diferente, de modo que o
administrador era obrigado a aprender a utilizar uma série de interfaces e
ferramentas diferentes para as tarefas de administração necessárias.
Na prática o MMC por si só não oferece nenhuma funcionalidade, ele apenas
fornece uma maneira padronizada para a criação de ferramentas administrativas.
Toda a funcionalidade do MMC é fornecida por aplicações de gerenciamento e
administração chamadas Snap-ins. O conjunto MMC + Snap-in é conhecido como
console ou console de administração. Um console é composto por uma janela
dividida em três painéis: o painel da esquerda exibe a árvore do console; o painel
central contém o painel de detalhes e o painel de detalhes mostra as informações e
funções relativas ao item que está selecionado no painel da esquerda. Cada snap-in
possui seus próprios menus e sua própria barra de ferramentas, separados dos
menus e da barra de ferramentas da janela principal do MMC. (BATTISTI;
SANTANA, 2009)
Segundo Battisti e Santana (2009), o MMC pode ser utilizado para uma série
de atividades, como por exemplo:
• Administração de contas de usuários, grupos e computadores;
• Gerenciamento de logs de segurança e monitoramento de desempenho;
• Administração e gerenciamento de servidores remotos (com a devida
permissão);
• Criação de consoles personalizados e definição de permissões para delegar
funções para um ou mais usuários.
A Figura 2.10 ilustra a janela principal do MMC sem snap-ins carregados.
48
Fonte: Battisti; Santana, 2009, p. 373
Segundo Battisti e Santana (2009), é possível para o administrador realizar a
criação de consoles personalizados através da adição ou remoção de snap-ins,
conforme necessidade. A Figura 2.11 demonstra alguns snap-ins, acessíveis através
do menu Arquivo -> Adicionar ou Remover Snap-in do MMC.
Fonte: Battisti; Santana, 2009, p. 377
Figura 2.10: MMC sem nenhum snap-in carregado
Figura 2.11: Janela de adição de Snap-ins
49
3 SAMBA
Este capítulo tem como objetivo apresentar o software livre Samba
mostrando suas principais características, um pouco de sua história, conceitos e
protocolos envolvidos de forma a exemplificar o funcionamento básico em todas as
suas versões
3.1 O QUE É O SAMBA
Segundo Barreiros (2015), Samba é um conjunto de aplicativos UNIX que se
comunicam através do protocolo Server Message Block (SMB). Suportando este
protocolo, o Samba permite que servidores UNIX like se comuniquem com produtos
para o Microsoft Windows. Uma máquina rodando um servidor Samba pode ficar
mascarado em uma rede Microsoft, oferecendo os seguintes serviços:
• Compartilhamento de um ou mais sistemas de arquivos;
• Compartilhamento de impressoras, tanto no servidor como no cliente;
• Auxiliar clientes na navegação do ambiente de rede;
• Autenticação de clientes em domínios Windows;
• Prover ou auxiliar na resolução de servidores através do Windows Internet
Name Service (WINS).
3.2 HISTÓRIA
Segundo Morimoto (2004), a primeira versão do Samba, disponibilizada em
1992, foi escrita por Andrew Tridgell. Naquela época, a especificação do SMB
utilizada pela Microsoft ainda era fechada e Andrew desenvolveu um pequeno
programa – batizado de clockspy – para examinar os pacotes de dados enviados por
uma máquina Windows e assim implementar chamada por chamada de sistema
utilizada. O resultado foi um programa que era executado no Solaris e era capaz de
responder às chamadas do SMB como se fosse um servidor Windows. O objetivo
dessa primeira versão era resolver um problema doméstico: interligar um PC
executando Windows 3.1 ao servidor Solaris.
50
Algum tempo depois de começar a distribuir seu servidor sob o nome de SMB
server, descobriu-se que este nome já pertencia ao produto de outra empresa. Ao
pesquisar em seu sistema UNIX like por palavras contendo S, M e B (grep -i 's.*m.*b'
/usr/dict/words) o resultado apresentado sugeriu, dentre outras, a palavra samba
(salmonberry samba sawtimber scramble), por isso essa a escolhida. (BARREIROS,
2015)
Em 1994, a Microsoft liberou as especificações do SMB e do NetBIOS, o que
permitiu que o desenvolvimento do Samba desse um grande salto, tanto em termos
de recursos quando em compatibilidade, passando a acompanhar em tempo real a
adição dos novos recursos ao protocolo da Microsoft. (MORIMOTO, 2004)
3.3 BASE DE FUNCIONAMENTO
Segundo Carmona (2007), a compatibilidade com o Windows proporcionada
pelo Samba se dá, devido ele ser uma implementação do protocolo SMB, que por
sua vez, é uma implementação proposta pela Microsoft para o antigo protocolo
NetBEUI, oriundo do protocolo NetBIOS, criado pela IBM, no início da década de
1980.
3.3.1 NetBIOS
O NetBIOS é um protocolo de transporte e de sessão, para uso geral, mas
originalmente destinado a serviços de arquivo e impressão. O Samba trabalha com
NetBIOS encapsulado em TCP/IP, e repassando para a rede de clientes pelo
sistema de broadcasting, ou seja, os pacotes NetBIOS que saem do servidor são
enviados para toda a rede. (CARMONA, 2007)
Segundo Barreiros (2015), no protocolo NetBIOS, cada máquina quando se
conecta na rede, clama por um nome para si, o que é chamado de registro de nome
(name registration), não podendo haver mais de uma máquina reclamando o mesmo
nome em um ambiente de trabalho. Existem então duas diferentes abordagens para
evitar que isto ocorra: Usar o NetBIOS Name Server (NBNS) para manter um
controle sobre qual cliente registrou cada nome NetBIOS; Permitir que cada
máquina na rede reclame o seu nome, quando uma outra máquina tentar registrar o
51
nome já utilizado.
A Figura 3.1 demonstra a tentativa de registro de um nome com e sem um
servidor de nomes NetBIOS.
Fonte: Barreiros, 2015
Segundo Barreiros (2015), além desta verificação do nome deve existir uma
maneira de se traduzir o nome NetBIOS para um endereço IP, este processo é
chamado de resolução de nome (name resolution). Na NBT esta resolução pode se
dar de duas maneiras: Fazer com que cada máquina responda seu endereço IP
quando “escuta” uma broadcast de requisição do seu nome NetBIOS e usar o NBNS
para ajudar na resolução dos nomes NetBIOS para endereços IP.
A Figura 3.2 demonstra a resolução de nomes com e sem servidor de nomes
NetBIOS.
Figura 3.1: Registro de nome com e sem servidor de Nomes NetBIOS
52
Fonte: Barreiros, 2015
Segundo Barreiros (2015), cada máquina em uma rede NetBIOS recebe uma
das seguintes designações, dependendo de como processa o registro de nome e a
resolução: nó-b, nó-p, nó-m, nó-h. Os comportamentos destes nós são resumidos
conforme demonstra a tabela 3.1. Oos nomes NetBIOS devem seguir um rígido
conjunto de regras. A seguir são descritos as principais regras:
• Um nome NetBIOS registrado pode se referir a uma única estação de
trabalho, ou a nós múltiplos que façam parte de um grupo de trabalho;
• Nomes NetBIOS não possuem formato hierárquico. Ou seja, não
existem pontos como no DNS;
• Nomes NetBIOS devem somente possuir caracteres de a..z, A..Z, 0..9
ou um dos seguintes caracteres: ! @ # $ % ^ & ( ) – ‘ { } . ~
• Nomes NetBIOS podem ter no máximo 15 caracteres para descrever o
recurso, e um octeto hexadecimal para se referir ao tipo de recurso.
Este último octeto indica que propriedades o computador registrado
possui.
Figura 3.2: Resolução de nomes com e sem servidor de nomes NetBIOS
53
A tabela 3.2 exemplifica os tipos de recursos disponíveis:
Tabela 3.1 - Tipos de nós NetBIOSDescrição Comportamento
nó-b Utiliza somente broadcast para o registro de nome e a resolução.
nó-p Utiliza registro e resolução ponto a ponto somente.
nó-m Utiliza broadcast para o registro. Se registrado com sucesso notifica o NBNS do resultado. Utiliza broadcast para a resolução, se o este não tiver sucesso utiliza o NBNS.
nó-h (híbrido) Utiliza o NBNS para registro e resolução. Utiliza o broadcast se o NBNS não der resposta ou estiver inoperante.
Fonte: Barreiros, 2015
Tabela 3.2 - Tipos de recursosRecurso Valor (Hexa)
Serviço padrão de estação de trabalho 00
Serviço de mensagem – Messenger Service (WinPopup) 03
RAS Server Service 06
Domain Master Browser Service (associado com o controlador de domínio primário)
1b
Nome do Master Browser 1d
Serviço de NetDDE 1f
Servidor de arquivos (incluindo servidor de impressora) 20
Serviço de cliente de RAS 21Fonte: Barreiros, 2015
Segundo Barreiros (2015), redes SMB/CIFS também utilizam o conceito de
grupos onde cada máquina da rede pode se registrar. Em um universo Windows um
grupo de trabalho é equivalente a um grupo SMB. A tabela 3.3 exemplifica os tipos
de recursos de grupos.
Tabela 3.3 - Tipos de recursos de grupos NetBIOSRecurso Valor
Grupo padrão de estação de trabalho 00
Servidor de logon 1c
Nome de Master Browser 1d
Nome de grupo normal (utilizado em browser elections) 1e
Nome de grupo de internet (administrativo) 20Fonte: Barreiros, 2015
54
3.3.2 SMB/CIFS
O Server Message Block (SMB) e o Common Internet File System (CIFS) são
protocolos de redes cujo uso mais comum é o compartilhamento de arquivos em
uma LAN. Estes protocolos permitem que o cliente manipule arquivos de rede como
se estes estivessem em sua máquina local, de modo a permitir operações como
leitura, gravação, criação, exclusão e renomeação. O protocolos SMB/CIFS
funcionam através do envio de pacotes do cliente para o servidor. Cada pacote é
tipicamente baseado em uma requisição de algum tipo, como a abertura ou leitura
de um arquivo. O servidor então recebe este pacote checa-o para ver se a
requisição é válida, ou seja, verifica se o cliente possui as permissões apropriadas
para efetuar a requisição e finalmente executa a requisição e retorna um pacote de
resposta ao cliente. O cliente então analisa o pacote de resposta para determinar se
a requisição inicial foi completada com sucesso. (BARREIROS, 2015)
Segundo Barreiros (2015), o conjunto de aplicativos Samba resume-se a um
par de daemons Unix que provêm recursos compartilhados para clientes SMB na
rede. Estes recursos são também usualmente chamados de serviços: smbd:
Permite o compartilhamento de arquivos e impressoras em uma rede SMB e
autenticação e autorização para clientes SMB; nmbd: Procura pelo Windows
Internet Name Service (WINS) e o assiste na navegação.
3.4 SAMBA 4
Segundo Leal (2014), após anos de trabalho, codificação e testes, a
comunidade open source apresentou no final de 2012 o Samba 4. Além de todos os
novos recursos que o servidor Samba 4 traz, destaca-se com unanimidade os
recursos do AD. O Microsoft AD é muito popular em diferentes empresas e
organizações de pequeno a grande porte. Com a nova versão do Samba 4, os
usuários e administradores de sistema são capazes de implementar serviços de
diretório, compartilhamento de arquivos e impressoras além de fornecer uma ampla
gama de serviços de rede, que utilizam tecnologia de código aberto. O Samba 4 tem
incluído de forma nativa todas as tecnologias necessárias do lado servidor para
operar os serviços do Active Directory, como por exemplo, servidor LDAP, o centro
de distribuição de chaves Kerberos, e um servidor de DNS simples.
55
3.4.1 Modos de Operação Suportados
Segundo SAMBA-WIKI (2015), os seguintes modos de operação são
suportados: Active Directory Domain Controller (AD-DC); Member Server em um AD
ou domínio NT4-style; NT4-style (classic) PDC ou BDC; Standalone Server e
Windows Print Server.
3.4.2 Limitações
Segundo SAMBA-WIKI (2015), as seguintes limitações são encontradas na
implementação atual: Não há suporte à tecnologia DFS-R, ou seja, não haverá
replicação no conteúdo do Sysvol (diretório compartilhado que armazena os
arquivos públicos de comum acesso e replicação entre os componentes do
domínio). Até esta implementação ser realizada, é necessário sincronismo manual
ou uso de ferramentas externas, como por exemplo, o rsync; Se o BIND foi utilizado
como servidor de DNS ele deverá ser executado na mesma máquina de instalação
do DC (pode ser utilizado servidor DNS forwarder – caso necessário); Distributed
File System (DFS) está disponível para funcionamento apenas no modo stand-alone;
Relações de confiança entre domínios e subdomínios não são suportadas; Suporte a
Read-only Domain Controller (RODC) não está implementado; Os DCs não podem
ser utilizados em sistemas de arquivos distribuídos, pois o DC samba não é
compatível com esta implementação; Winbind não é suportado nos DCs até a
versão 4.2.
3.4.3 Novos Recursos (versão 4.2)
Segundo SAMBA-WIKI (2015), alguns dos novos recursos implementados
com a versão 4.2 são:
Compressão de arquivos transparente: Adiciona suporte à manipulação de
arquivos e pastas compactadas no sistema de arquivos Btrfs;
Versões de arquivos com Snapper: O módulo de suporte ao VFS adiciona
suporte a versões anteriores de arquivos através do Windows Explorer, por meio da
janela de diálogo “Versões Anteriores”;
56
Melhorias na segurança do Winbindd/Netlogon: Os canais seguros entre
controladores de domínio foram reescritos para manter um estado global em
netlogon_creds_cli.tdb, corrigindo diversos bugs, porém é necessário que uma
senha de sessão “forte” seja definida, fazendo com que a antiga comunicação com
servidores e clientes possa ser rejeitada;
Uso do Winbindd no DC: O Winbindd é utilizado por padrão em um AD DC
Samba, facilitando o suporte a relações de confiança entre os domínios do DC;
Editor de Registro: Um aplicativo que permite a alteração do registro do
Samba, permitindo a navegação entre as chaves de registro e edição de diferentes
tipos de valores;
Bloqueio de contas: Quando múltiplas tentativas de acesso indevida são
detectadas, o sistema bloqueia automaticamente o acesso por 60 minutos (período
pode ser manipulado);
3.4.4 Requisitos de Software
Segundo SAMBA-WIKI (2015), os requisitos abaixo são
recomendados/necessários para um correto funcionamento do Samba 4:
Para os sistemas de arquivos que serão compartilhados pelo samba, o uso
das opções user_xattr e acl,barrier=1 no /etc/fstab.
Suporte do Kernel Linux às flags CONFIG_EXT4_FS_XATTR,
CONFIG_EXT4_FS_SECURITY e CONFIG_EXT4_FS_POSIX_ACL;
Phyton (obrigatório);
perl (obrigatório);
acl (opcional);
xattr (opcional);
blkid (opcional);
gnutls (opcional);
readline (opcional);
cups (opcional – suporte a impressão);
bsd ou setproctitle (opcional);
xsltproc (opcional – suporte a criação de páginas de manuais);
docbook (opcional – suporte a criação de páginas de manuais);
57
openldap (opcional – suporte a migração de servidores DC da versão 3 do
samba para a versão 4).
58
4 ESTUDO DE CASO
A implementação do projeto foi realizada em ambiente virtual, com a
utilização do software VirtualBox. A topologia de rede utilizada nos servidores que
foram virtualizados é representada pela Figura 4.1.
Fonte: Elaborado pelo autor, 2015
Para o endereçamento de IP (versão 4) foi utilizada a classe 172.16.0.0/22. A
tabela 4.1 exemplifica a distribuição de endereços IP na topologia anteriormente
descrita.
Tabela 4.1 - Distribuição de endereços IP
EQUIPAMENTO FUNÇÃO IP
SRV-FW001FIREWALL/GATEWAY, SERVIDOR DHCP,SERVIDOR DNS SECUNDÁRIO
172.22.0.1/22
SRV-AD001 SERVIDOR AD, SERVIDOR DNS PRIMÁRIO 172.22.0.2/22
- RESERVADO INFRAESTRUTURA172.22.0.3/22 a172.22.0.255/22
CLIENTESDIVERSOS
COMPUTADORES DE USUÁRIOSDINÂMICO,ATRIBUÍDO PORDHCP
Fonte: Elaborado pelo autor, 2015
Figura 4.1: Topologia da rede de testes
59
Foram utilizados o domínio EMPRESA.LOCAL e nome NetBIOS EMPRESA
para a implementação. As configurações referentes às máquinas virtuais utilizadas
na implementação são descritas na tabela 4.2.
Tabela 4.2 - Configurações das máquinas virtuaisMáquina Memória (RAM) HD Rede
SRV-FW001 512MB 1x 10GB1x rede bridge 1x rede host-only
SRV-AD001 512MB1x 10GB1x 250GB
1x rede host-only
CLIENTE 1 512MB 1x 10GB 1x rede host-only
CLIENTE 2 512MB 1x 10GB 1x rede host-onlyFonte: Elaborado pelo autor, 2015
Após as definições e configurações das máquinas virtuais no VirtualBox foi
realizada a instalação dos respectivos sistemas operacionais em cada máquina, o
processo de instalação está disponível no Anexo A.
4.1 CONFIGURAÇÃO SRV-FW001
O primeiro passo para a instalação do firewall é definir as configurações de
interface WAN. Na topologia atual, a interface de rede eth0 foi utilizada para a rede
WAN e o método de atribuição de IP é DHCP. Para realizar as configurações
necessárias deve-se alterar o arquivo /etc/network/interfaces e reiniciar o serviço de
rede, conforme comandos:
A seguir procedimento realizado para instalação dos pacotes, conforme
comando:
# echo allow-hotplug eth0 >> /etc/network/interfaces
# echo iface eth0 inet dhcp >> /etc/network/interfaces
# service networking restart
# apt-get install openssh-server squid3 bind9 isc-dhcp-server
60
4.1.1 Configuração do Servidor DHCP
A configuração do servidor DHCP foi realizada com alterações no arquivo
/etc/dhcp/dhcpd.conf. O conteúdo do arquivo de configuração é ilustrado a seguir:
Na sequência deve-se reiniciar o serviço DHCP, conforme comando:
4.1.2 Configuração do Servidor DNS Secundário
O servidor SRV-FW01 é responsável pelo servidor DNS secundário, isto é,
replica a zona empresa.local. Para a configuração do servidor como “slave” deve ser
adicionadas as seguintes configurações no arquivo “/etc/bind/named.conf.local”:
ddns-update-style none;
default-lease-time 64800;
max-lease-time 6480;
authoritative;
log-facility local7;
ddns-domainname "empresa.local";
option domain-name "empresa.local";
subnet 172.16.0.0 netmask 255.255.252.0
{
range 172.16.1.0 172.16.3.254;
option routers 172.16.0.1;
option domain-name-servers 172.16.0.1, 172.16.0.2;}
zone "empresa.local" {
type slave;
file "db.empresa.local";
masters { 172.16.0.2; };
allow-notify { 172.16.0.2; };
};
# service isc-dhcp-server restart
61
Na sequência deve-se reiniciar o serviço bind, conforme comando:
4.1.3 Configuração do Firewall
O primeiro passo para a configuração do firewall é a criação do arquivo
/etc/init.d/firewall com o conteúdo definido no Anexo B.
Após a criação do arquivo /etc/init.d/firewall, é necessário definir as
permissões de execução do script e adicioná-lo à inicialização do sistema, conforme
comandos:
4.1.4 Configuração do Proxy SQUID
O arquivo de configuração squid.conf deve ser configurado conforme
conteúdo definido no anexo C. Após a configuração do arquivo, deve-se reiniciar o
serviço de PROXY, conforme comando:
4.2 CONFIGURAÇÃO SRV-AD001
O primeiro passo necessário é a instalação dos pacotes do BIND e bibliotecas
de desenvolvimento utilizadas para a compilação do Samba 4, conforme comando:
Em seguida é alterado o arquivo /etc/fstab para permitir que a partição onde
# service bind9 restart
# chmod +x /etc/init.d/firewall
# update-rc.d firewall defaults
# service squid3 restart
# apt-get install build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls28-dev
libreadline-dev python-dev python-dnspython gdb pkg-config libpopt-dev libldap2-
dev dnsutils libbsd-dev attr krb5-user docbook-xsl openssh-server bind9
62
serão gravados os dados compartilhados pelo servidor Samba 4 possa manusear
corretamente as permissões de pasta necessárias pelo AD. Para isso, deve-se
adicionar às opções de montagem os parâmetros user_xattr,acl,barrier=1 e
sequencialmente aplicar as configurações, conforme abaixo ilustrado:
As opções user_xattr e acl habilitam a lista de controle de acesso em
sistemas POSIX enquanto a opção barrier=1 garante que as transações no banco de
dados tdb estejam seguras mesmo que ocorra desligamento incorreto do sistema.
4.2.1 Instalação do SAMBA 4
Após a instalação dos pacotes necessários e configuração do sistema de
arquivos, o passo seguinte é obter o código fonte da versão atual do samba,
acessível através do site https://www.samba.org/samba/download/. A versão
utilizada na elaboração deste estudo de caso é a 4.2.2. Por tratar-se de um arquivo
com códigos-fonte que foram compilados, por convenção foi utilizado o diretório
/usr/src para trabalho. A sequência de comandos utilizados para obter, compilar e
instalar o código fonte do Samba 4 foram:
Após a criação do arquivo /etc/init.d/samba-ad-dc, é necessário definir as
permissões de execução do script e adicioná-lo à inicialização do sistema, conforme
comandos:
# UUID=6ffe3049-b88b-4e20-bbff-4300c566ca33 /srv ext4 user_xattr,acl,barrier=1
# cd /usr/src
# wget -c https://www.samba.org/samba/ftp/stable/samba-4.2.2.tar.gz
# tar -zxvf samba-4.2.2.tar.gz
# cd samba-4.2.2/
# ./configure
# make
# make install
# chmod +x /etc/init.d/samba-ad-dc
# update-rc.d samba-ad-dc defaults
63
4.2.2 Provisionamento do Domínio
O próximo passo é o provisionamento do domínio. Para isso é utilizado o
utilitário samba-tool com os parâmetros de configuração, conforme:
A tabela 4.3 explica a funcionalidade de cada opção utilizada.
Tabela 4.3 - Opções utilizadas no provisionamento do domínioOPÇÃO FUNÇÃO
domain provisionInstrui o samba-tool que será realizado oprovisionamento de um novo domínio
--domain=EMPRESA Define o grupo NetBIOS do domínio que será utilizado
--realm=EMPRESA.LOCALDefine o nome do sufixo do domínio que será utilizadopelo AD
--dns_backend=BIND9_DLZDefine que o programa de DNS utilizado será oBIND9
--server-role=dc Define que o servidor será um DC
--adminpass=p@ssw0rdDefine a senha do usuário administrator(administrador do domínio)
Fonte: Elaborado pelo autor, 2015
Finalizado o provisionamento do domínio, é exibido um resumo com os locais
dos arquivos de configuração do servidor DNS BIND9 e do Kerberos, abaixo
ilustrado:
# /usr/local/samba/bin/samba-tool domain provision --domain=EMPRESA
--realm=EMPRESA.LOCAL --dns-backend=BIND9_DLZ --server-role=dc
--adminpass=p@ssw0rd
See /usr/local/samba/private/named.conf for an example configuration for BIND and /usr/local/samba/private/named.txt for required for secure DNS updatesSetting up sam.ldb rootDSE marking as synchronizedA Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.confOnce the above files are installed, your Samba4 server will be ready to useServer Role: active directory domain controllerHostname: SRV-AD001NetBIOS Domain: EMPRESADNS Domain: empresa.localDOMAIN SID: S-1-5-21-662070037-2242896996-10792671
64
4.2.3 Configuração do BIND9
O próximo passo é a configuração do BIND9 para permitir que o DNS seja
atualizado de forma dinâmica pelo AD.
Para isso, é necessário configurar o arquivo “/etc/bind/named.conf.local” e
incluir a linha include "/usr/local/samba/private/named.conf", conforme
comandos:
Na sequência é necessário iniciar o serviço do Samba 4 através do comando
“service samba-ad-dc start”.
4.2.3 Configuração do Kerberos
A configuração do cliente Kerberos é realizada com a cópia do arquivo
krb5.conf (criado pelo samba-tool no provisionamento do domínio) para o diretório
/etc através do comando “cp /usr/local/samba/private/krb5.conf /etc”. Finalizado
este processo, o Kerberos já está funcional e pode ser testado através do utilitário
kinit. A seguir é exibido uma demonstração de uso e saída do comando kinit:
O teste realizado pelo utilitário kinit não mostra muitos detalhes. Para uma
saída mais detalhada o utilitário klist deverá ser utilizado, conforme:
# echo include "/usr/local/samba/private/named.conf"; >> /etc/bind/named.conf
# service bind9 restart
# kinit [email protected]
Password for [email protected]:
Warning: Your password will expire in 19 days on Seg 13 Jul 2015 20:42:54 BRT
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
24-06-2015 13:47:51 24-06-2015 23:47:51
krbtgt/[email protected] renew until 25-06-2015 13:47:48
65
Finalizados os procedimentos anteriormente descritos, o AD já esta funcional
e pode ser utilizado nas máquinas Windows.
4.2.3 Criação das Pastas Compartilhadas
A criação das pastas compartilhadas pelo servidor Samba 4 é realizada no
console do servidor Linux e posteriormente deve-se mapeá-las para
compartilhamento no servidor Samba 4. Como diretório base, foi utilizado o
diretório /srv e criadas as pastas ADM (Administração), CONT (Contabilidade), FIN
(Financeiro) e TI (Tecnologia da Informação). Os comandos para criação das pastas
são demonstrados abaixo:
Criadas as pastas, é necessário o mapeá-las para uso do Samba 4 realizando
a adição de entradas de compartilhamento correspondentes no arquivo de
configuração do Samba 4, localizado em /usr/local/samba/etc/smb.conf. Abaixo são
exemplificados os compartilhamentos para as pastas anteriormente criadas:
# mkdir /srv/ADM
# mkdir /srv/CONT
# mkdir /srv/FIN
# mkdir /srv/TI
[ADM]
path = /srv/ADM
read only = No
[CONT]
path = /srv/CONT
read only = No
[FIN]
path = /srv/FIN
read only = No
[TI]
path = /srv/TI
read only = No
66
Não é necessário o reinício do servidor Samba 4 após a criação dos
compartilhamentos pois eles já estão disponíveis para uso, assim que o arquivo
smb.conf for salvo. A única ressalva sobre a criação de compartilhamentos é que,
por padrão, qualquer usuário tem acesso completo às pastas, é necessário a
atribuição de permissões pelo administrador para evitar uso indevido.
4.3 GERENCIAMENTO DO DOMÍNIO
O gerenciamento do domínio pode ser realizado via console do servidor Linux
através do software utilitário samba-tool ou pelas ferramentas disponíveis para
gerenciamento de servidores AD do próprio Windows. A última é recomendada pela
equipe de desenvolvimento do Samba pela facilidade de uso e. não ser necessário
acesso ao console do servidor Linux. As ferramentas para gerenciamento do
servidor AD através do Windows XP estão disponíveis para download no site da
Microsoft, acessível por meio do endereço https://www.microsoft.com/en-
us/download/details.aspx?id=6315.
Após download e instalação do adminpack os snap-ins de gerenciamento
estão disponíveis através do MMC, conforme ilustra a Figura 4.2.
Fonte: Elaborado pelo autor, 2015
Para fins de teste, as seguintes ações foram realizadas pelo console de
gerenciamento: Criação de 4 grupos; Criação de 4 usuários; Atribuição dos usuários
a seus respectivos grupos; Definição de proxy via GPO global e Atribuição de
permissão por grupo às pastas compartilhadas;
Figura 4.2: Snap-ins
67
4.3.1 Criação de Grupos
A criação de grupos no AD é realizada pelo console de gerenciamento,
através do snap-in “Usuários e computadores do Active Directory”. Após adicionado
o snap-in, clica-se com o botão direito em área vaga do quadro da direita e em Novo
→ Grupo, conforme ilustra a Figura 4.3.
Fonte: Elaborado pelo autor, 2015
Na sequência é exibida uma janela, que informa a criação de um novo objeto
do tipo grupo. Define-se o nome do grupo, escopo e tipo, conforme ilustra a Figura
4.4.
Fonte: Elaborado pelo autor, 2015Figura 4.4: Parâmetros para criação do grupo
Figura 4.3: Criação de novo grupo
68
A Figura 4.5 ilustra os grupos criados neste estudo de caso, separados em
uma unidade organizacional “Matriz”.
Fonte: Elaborado pelo autor, 2015
4.3.2 Criação de Usuários
O processo de criação de usuários é semelhante ao processo de criação de
grupos, basta selecionar a opção Novo → Usuário. Sequencialmente será exibida a
janela para a criação de um novo objeto do tipo Usuário, conforme ilustra a Figura
4.6.
Fonte: Elaborado pelo autor, 2015Figura 4.6: Parâmetros para criação de um novo usuário
Figura 4.5: Grupos criados separados em unidades organizacionais
69
Depois são solicitadas informações referentes à segurança da conta.Nenhuma opção é selecionada conforme exemplifica a Figura 4.7.
Fonte: Elaborado pelo autor, 2015
A Figura 4.8 ilustra os usuários criados neste estudo de caso, separados em
uma unidade organizacional “Matriz”.
Fonte: Elaborado pelo autor, 2015
4.3.3 Atribuição de Usuários a Grupos
A atribuição de grupos a usuários pode ser realizada de várias formas. Optou-
se neste estudo de caso a atribuição através da alteração dos parâmetros
Figura 4.7: Parâmetros de segurança
Figura 4.8: Usuários criados separados em unidades organizacionais
70
diretamente na conta do usuário, por meio do menu suspenso “Propriedades”, aba
“Membro de”, conforme ilustra a Figura 4.9.
Fonte: Elaborado pelo autor, 2015
Após clicar em adicionar, é exibida a janela para seleção de grupo (mais de
um pode ser selecionado – separados por ponto e vírgula), conforme ilustra a Figura
4.10.
Fonte: Elaborado pelo autor, 2015
Figura 4.9: Grupos do usuário
Figura 4.10: Seleção de grupos do usuário
71
Os grupos foram atribuídos aos usuários, conforme descrito na tabela 4.4.
Tabela 4.4 - Relacionamento entre usuários e gruposUSUÁRIO GRUPO
Alexandre Ponce de Oliveira Administração
Amabili Sierra Fernandes Financeiro
Eduardo Sierra Fernandes Tecnologia da Informação
Eloisa Suzuki Maia ContabilidadeFonte: Elaborado pelo autor, 2015
4.3.4 Definição de Proxy via GPO
O uso de GPO permite ao administrador definir comportamentos do
computador utilizado pelo usuário, grupo de usuários ou unidades organizacionais.
No presente estudo de caso é utilizado o recurso de GPO para definir
automaticamente o endereço proxy do sistema após o login do usuário.
Primeiramente deve-se adicionar o snap-in “Editor de objeto de diretiva de
grupo”, conforme Figura 4.11.
Fonte: Elaborado pelo autor, 2015Figura 4.11: Adição de snap-in para controle de GPO
72
Adicionado o snap-in, o caminho para acesso à opção de configuração do
proxy é: “Configurações do usuário” → “Configurações do Windows” → “Manutenção
do Internet Explorer” → “Conexão” → “Configurações de proxy”. Ao clicar duas
vezes sobre a opção, abre-se a janela para definição das configurações de proxy do
sistema. Foi utilizado o endereço de IP 172.16.0.1 e porta 3128 para todos os
endereços, conforme ilustrado pela Figura 4.12.
Fonte: Elaborado pelo autor, 2015
4.3.5 Permissão de Pastas Compartilhadas
As permissões das pastas compartilhadas são definidas através do snap-in
“Pastas Compartilhadas”, conforme ilustrado pela Figura 4.13.
Fonte: Elaborado pelo autor, 2015Figura 4.13: snap-in para permissões de pastas
Figura 4.12: Configurações de proxy via GPO
73
Após adicionar o snap-in, é solicitado definir o computador que possui
compartilhamentos gerenciados pelo snap-in, conforme ilustra a Figura 4.14.
Fonte: Elaborado pelo autor, 2015
Após aberto, o snap-in mostrará no quadro da direita os compartilhamentos.
Seleciona-se a opção propriedades do menu suspenso em cima do item desejado
seguido de clique na aba “Permissões de compartilhamento”. Por padrão, o Samba
4 permite que todos os usuários acessem o compartilhamento após sua criação. No
estudo de caso atual, foi atribuído a cada compartilhamento seu respectivo grupo
com permissão de acesso, conforme ilustra a Figura 4.15.
Fonte: Elaborado pelo autor, 2015
Figura 4.14: Seleção do computador a ser gerenciado
Figura 4.15: Permissões da pasta ADM
74
4.4 INGRESSAR ESTAÇÕES DE TRABALHO NO DOMÍNIO
O ingresso de estações de trabalho ao domínio Samba 4 é idêntico ao
realizado em um domínio AD com um Windows. Para fins de compatibilidade, devido
aos recursos limitados das máquinas virtuais, foi utilizado o Windows XP como
estação de trabalho. Em testes, não documentados neste estudo de caso, foi
possível a adição de estações de trabalho Windows 7 e Windows 8 sem qualquer
restrição.
O processo para adição das máquinas virtuais de teste com Windows XP foi
realizado na seguinte sequência:
A. Dentro das Propriedades de Meu Computador, na aba “Nome do
Computador” seleciona-se a opção Alterar. O acesso às Propriedades do Meu
Computador pode ser realizado de várias formas, como por exemplo, clicar
com o Botão direito do mouse no ícone Meu Computador e posteriormente
em Propriedades ou através do Painel de Controle → Sistema;
B. Na janela “Alterações de nome do computador”, alterar a opção “Membro de”
para “Domínio” e digitar o nome do domínio EMPRESA.LOCAL. Clicar em
OK;
C. É exibida uma janela solicitando usuário e senha. Deve-se utilizar o usuário
administrator (ou algum usuário com privilégio de administrador) seguido da
senha. Clicar em OK;
D. Após um curto período de tempo é exibida a mensagem que o computador foi
adicionado ao domínio. Clicar em OK;
E. É solicitado o reinício do sistema para aplicar as alterações. Clicar em OK;
F. A janela “Alterações de nome do computador” fica acessível. Clicar em OK;
G. É exibida uma janela que solicita o reinício do sistema. Clicar em Sim;
Neste ponto ocorrerá o reinício do sistema;
Após o sistema ser reiniciado, o domínio EMPRESA aparece na caixa de
seleção “Fazer logon em”, conforme ilustra a Figura 4.16.
Após o usuário realizar o acesso ao sistema, utilizando seu usuário e senha,
os recursos anteriormente configurados no servidor já podem ser acessados. A
75
Figura 4.17 ilustra o acesso às pastas compartilhadas pelo servidor.
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Finalizadas as configurações realizadas no decorrer do capítulo, o domínio
EMPRESA.LOCAL está disponível para uso das estações de trabalho e usuários da
rede, disponibilizando os serviços de: Definição automática de endereço IP; Logon
centralizado; Compartilhamento de arquivos; Acesso à internet mediante solicitação
de login e senha dentre outros.
Figura 4.16: Domínio disponível para logon
Figura 4.17: Acesso às pastas compartilhadas pelo servidor
76
CONCLUSÃO
Este trabalho mostrou que é possível realizar a interoperabilidade de
ambientes Linux e Windows através da nova versão do software servidor Samba, no
qual fornece praticamente todos os recursos mais utilizados em servidores Windows
com Active Directory. A solução apresentada pode ser utilizada por empresas que
queiram economizar em licenciamento de software do lado servidor sem gerar
transtorno no processo de administração dos recursos de rede pois a curva de
aprendizado necessária à administração do servidor Samba 4 é mínima e nos
clientes Windows é inexistente.
A complexidade que existia em versões anteriores do Samba para fornecer os
recursos de um servidor Active Directory é inexistente nesta nova versão. Todos os
serviços necessários ao funcionamento do servidor estão integrados e em
funcionamento quando o servidor é iniciado. Adicionalmente, não há necessidade de
configuração de softwares adicionais, alteração de chaves de registro no Windows
das estações de trabalho e instalação de programas de terceiros para a gerência do
domínio, como por exemplo, clientes LDAP. Toda a administração é realizada
através das ferramentas de gerenciamento disponíveis para gerenciamento dos
servidores Windows.
O fácil acesso à base de dados LDAP e ao Kerberos permitem que softwares
com suporte a estes protocolos possam de forma simples utilizar os recursos
providos pela autenticação centralizada, assim facilita a administração. No estudo de
caso foi realizada a configuração do servidor proxy Squid que utiliza a base de
dados LDAP para autenticar os usuários antes de prover o acesso à internet, assim
melhora a segurança da rede.
Entretanto ocorreram alguns problemas durante a realização do estudo de
caso. O servidor DNS interno do Samba 4 parava de resolver nomes em intervalos
de tempo aleatórios. Para resolver é necessária de atuação do administrador por um
processo conhecido como flush DNS, através do snap-in DNS, o servidor DNS
voltava a funcionar adequadamente. Após reconfiguração do Samba 4 para que
fosse utilizado o BIND em detrimento ao servidor DNS interno, o problema parou de
ocorrer. Outro problema encontrado foi a falta de suporte à sincronização de
conteúdo da pasta SYSVOL, consequentemente, as GPO e outros objetos públicos
77
compartilhados por esta pasta deixassem de ser replicados. A solução paliativa para
este problema é o uso do utilitário rsync através do agendador de tarefas do Linux
(cron) para que de tempo em tempo o conteúdo fosse replicado entre os servidores.
O presente trabalho pode ser melhorado com implementação de mais
serviços para suprir determinadas necessidades, como por exemplo, a configuração
de um servidor Network Time Protocol (NTP) para manter o sincronismo de data e
hora entre os servidores e estações de trabalho pois caso não exista este
sincronismo o Kerberos não funcionará.
Uma proposta de trabalho futuro é utilizar o recurso de autenticação
centralizada para autenticar estações de trabalho Linux no domínio Active Directory.
78
REFERÊNCIAS BIBLIOGRÁFICAS
BATTISTI, J; SANTANA, F. Windows server 2008 – guia de estudos completo:implementação, administração e certificações. Rio de Janeiro: Nova Terra, 2009.
BARREIROS, C. Samba. 2015. Disponível em:<http://www.gta.ufrj.br/grad/01_2/samba/samba.htm>. Acesso em: 20 mai. 2015.
BLACKMAN, P. Samba FAQ. 1997. Disponível em:<http://wdocs.kmu.edu.tw/samba_faq/sambafaq.html>. Acesso em: 04 nov. 2013.
CARMONA, T. Universidade Linux. 2. ed. São Paulo: Digerati Books, 2007.
CARTER, G. LDAP system administration. Sebastopol: O’Reilly, 2003.
DEBIAN-RELEASES. Debian releases. 2013. Disponível em:<http://www.debian.org/releases/>. Acesso em: 30 nov. 2013.
DESMOND, B.; RICHARDS, J.; ALLEN, R.; LOWE-NORRIS, A., Active directory.Sebastopol: O’Reilly, 2013.
GARMAN, J., Kerberos: the definitive guide. Sebastopol: O’Reilly, 2003.
HUNTER, L. E.; ALLEN, R., Active directory cookbookTM. 3. ed. Sebastopol:O'Reilly, 2009.
ISC-BIND. INTERNET SUSTEMS CONSORTIUM – BIND. 2013. Disponível em:<https://www.isc.org/downloads/bind/>. Acesso em: 10 nov. 2013.
KERBEROS. What´s kerberos. 2013. Disponível em:<http://web.mit.edu/kerberos/>. Acesso em: 19 nov. 2013.
KUROSE, J. F.; ROSS, K. W. Computer networking: A Top-Down Approach. 6. ed.São Paulo: Pearson Prentice Hall, 2013.
LEAL, M. Implementing samba 4. Birmingham: Packt Publishing, 2014.
MINASI, M.;ANDERSON, C.; BEVERIDGE, M.; CALLAHAN, C.; JUSTICE, L.,Dominando o Windows Server 2003: A Bíblia. São Paulo: Pearson Prentice Hall,2003.
MORIMOTO, C. E.; Entendendo e Dominando o Linux. 3. ed. São Paulo: DigeratiBooks, 2004.
NEMETH, E.; SNYDER, G.; HEIN, T. R.; MCGINLEY, L.; WHALEY, B.; BOGGS, A.;HAEMER, J. S.; OETIKER, T.; ZAUCKER, F.; SEIDEL, S. BUSS, B.; MCCLAIN, N.;SCHEWEIKERT, D., Manual completo do linux. 2. ed. São Paulo: Pearson PrenticeHall, 2007.
79
POLICELLI, J., Active directory domain services 2008. São Paulo: PearsonPrentice Hall, 2009.
ROOT-SERVER. List of DNS root-servers. 2013. Disponível em: <http://www.root-servers.org/map/>. Acesso em: 10 nov. 2013.
SAMBA-HISTORY. Samba release notes archive. 2012. Disponível em:<http://www.samba.org/samba/history/samba-4.0.0.html>. Acesso em: 04 nov. 2013.
SAMBA-WIKI. SambaWiki. 2015. Disponível em:<https://wiki.samba.org/index.php/Main_Page>. Acesso em: 29 mai. 2015.
SILVA, G. M., Guia foca linux iniciante. 2010. Disponível em:<http://www.guiafoca.org/?page_id=238>. Acesso em: 25 nov. 2013.
SIQUEIRA, L. A., Coleção linux pro ubuntu. São Paulo: Linux New Media do Brasil,2009.
TANENBAUM, A. S., Redes de computadores. 4. ed. Rio de Janeiro: Elsevier,2003.
TEIXEIRA JR., J. H.; SUAVÉ, J. P.; MOURA, J. A. B.; TEIXEIRA, S. Q. R., Redes decomputadores: Serviços Administração e Segurança. São Paulo: Makron Books,1998.
80
ANEXO A – INSTALAÇÃO DEBIAN GNU/LINUX
O primeiro passo antes de iniciar a instalação é obter o arquivo ISO de
instalação do Debian GNU/LINUX disponível em https://www.debian.org/CD/http-ftp/.
A versão utilizada foi a 8.0 (jessie) na arquitetura amd64.
Após a inicialização do sistema é apresentada uma tela que solicita a
operação desejada. Selecione a opção “Install” conforme ilustra a Figura A1.
Fonte: Elaborado pelo autor, 2015
Iniciado o processo de instalação, os primeiros passos são definir as opções
de localização (linguagem, localidade, região e tipo de teclado). Para linguagem foi
selecionado Português do Brasil. Para localidade, Brasil e para o tipo de teclado,
Português Brasileiro (teclado com ç padrão ABNT2).
Posterior às configurações referentes a localização, é iniciado o processo de
configuração automática das placas de rede. Esse processo falha, conforme Figura
A.2 pois não há configurações automáticas disponíveis. Selecione a opção para
configurar a rede manualmente conforme Figura A.6. As configurações serão
Figura A.1: Tela de boot do CD de Instalação Debian 8.0 (Jessie)
81
realizadas de forma independente, conforme regras estabelecidas na tabela 4.1. As
figuras A.4 e A.5 mostram as individualidades nas configurações entre SRV-FW001 e
SRV-AD001.
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Figura A.2: Falha na configuração automática de rede
Figura A.3: Seleção de configuração manual de rede
Figura A.4: Configurações de rede - SRV-FW001
82
Fonte: Elaborado pelo autor, 2015
Finalizado o processo de configuração de rede, são solicitadas as
configurações de gateway, servidores DNS e domínio.
O servidor SRV-AD001 tem como gateway o IP 172.16.0.1 (SRV-FW001) e
servidores de DNS 127.0.0.1 (LOOPBACK) e 172.16.0.1 (SRV-FW001). O servidor
SRV-FW001 não tem gateway nesta interface e os servidores de DNS são 127.0.0.1
(LOOPBACK) e 172.16.0.2 (SRV-AD001).
Ambos os servidores são atribuídos ao domínio EMPRESA.LOCAL. As figuras
A.6 e A.7 exibem as configurações de gateway e DNS selecionadas para o servidor
SRV-AD001 enquanto a Figura A.8 exibe a configuração de domínio para ambos os
servidores.
Fonte: Elaborado pelo autor, 2015
Figura A.5: Configurações de rede - SRV-AD001
Figura A.6: Configuração de gateway em SRV-AD001
83
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Realizadas as definições de rede, é solicitado a senha do usuário root
(superusuário). Para fins de estudo, a senha utilizada é empresa.local.123. Posterior
à definição da senha de root, é necessário a criação de um usuário “restrito” para
uso do sistema. O nome de usuário utilizado é suporte com a senha
suporte.local.123 A Figura A.9 mostra a tela de definição de senha do usuário root
enquanto as figuras A.10 e A.11 exibem as telas de definição do nome de usuário
“restrito” e sua senha, respectivamente.
Fonte: Elaborado pelo autor, 2015
Figura A.7: Configuração de servidores DNS em SRV-AD001
Figura A.8: Configuração de domínio em SRV-AD001 e SRV-FW001
Figura A.9: Definição da senha de root
84
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Na sequência é necessário definir o fuso horário dos servidores, a opção
escolhida é “São Paulo” e depois é iniciado o processo de particionamento de disco.
Foi selecionado a opção “Manual” conforme ilustra a Figura A.12.
Fonte: Elaborado pelo autor, 2015
As definições de particionamento de disco foram realizadas conforme ilustra a
tabela A.1
Figura A.11: Definição de senha de usuário “restrito”
Figura A.12: Seleção do método de particionamento de disco
Figura A.10: Definição de nome de usuário “restrito”
85
Tabela A.1 - Particionamento de discoSERVIDOR PARTIÇÃO DISPOSITIVO TAMANHO
SRV-FW001 /boot /dev/sda1 200mb
SRV-FW001 Swap /dev/sda5 1gb
SRV-FW001 / /dev/sda6Espaço restante.
Em torno de 9gbps
SRV-AD001 /boot /dev/sda1 200mb
SRV-AD001 Swap /dev/sda5 1gb
SRV-AD001 / /dev/sda6Espaço restante.
Em torno de 9gbps
SRV-AD001 /srv /dev/sdb1 250gbFonte: Elaborado pelo autor, 2015
As figuras A.13 e A.14 ilustram o particionamento realizado nos servidores
SRV-FW001 e SRV-AD001, respectivamente.
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Finalizado o particionamento de disco, o instalador realiza a instalação dos
Figura A.13: Particionamento de disco – SRV-FW001
Figura A.14: Particionamento de disco – SRV-AD001
86
pacotes básicos do sistema. Em seguida é solicitado a configuração de mirror
(espelho) do gerenciador de pacotes do Debian (apt-get). A Figura A.15 ilustra a
escolha do servidor utilizado pelo gerenciador de pacotes.
Fonte: Elaborado pelo autor, 2015
Finalizado a configuração do gerenciador de pacotes o instalador solicita o
software a ser instalado. É utilizado apenas a opção “Utilitários standard de sistema”.
A Figura A.19 ilustra a tela de seleção de software.
Fonte: Elaborado pelo autor, 2015
Após a instalação dos programas selecionados, o sistema solicita a instalação
do gerenciador de inicialização “GRUB”. Deve-se selecionar o primeiro disco rígido
(sda) conforme ilustra a Figura A17.
Figura A.15: Seleção de mirror do gerenciador de pacotes
Figura A.16: Seleção de software
87
Fonte: Elaborado pelo autor, 2015
Na sequência o sistema informa que a instalação foi concluída, conforme
ilustra a Figura A.18 e reinicia já no prompt de login e senha conforme ilustram as
figuras A.19 e A.20.
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Fonte: Elaborado pelo autor, 2015
Figura A.17: Instalação do gerenciador GRUB
Figura A.18: Instalação do sistema finalizada
Figura A.19: Tela de login – SRV-FW001
Figura A.20: Tela de login – SRV-AD001
88
ANEXO B – SCRIPT DE FIREWALL
#!bin/bash
# DEFINICAO DE VARIAVEIS PARA USO NO SCRIPT
IPTABLES="/sbin/iptables"
LAN="eth1"
WAN="eth0"
REDEINTERNA="172.16.0.0/22"
PIDFILE="/var/lock/nat"
defaultpolice(){
echo "*** Definindo politica/regras padrao"
$IPTABLES -P INPUT DROP
#Liberando interface lo e LAN
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A INPUT -i $LAN -j ACCEPT
#Bloqueia ICMP (PING) da rede interna para Internet
$IPTABLES -A FORWARD -i $LAN -p icmp -j DROP
#MASQUERADE
$IPTABLES -t nat -A POSTROUTING -o $WAN -j MASQUERADE
#MICROS QUE NAO PASSAM PELO SQUID (SEM BLOQUEIO NA PORTA 80)
$IPTABLES -A FORWARD -i $LAN -p tcp --dport 80 -s 172.16.0.2/32 -j ACCEPT
#BLOQUEIA ACESSO DIRETO A PORTA 80
$IPTABLES -A FORWARD -i $LAN -p tcp --dport 80 -j DROP
#CONEXOES RELACIONADAS
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
}
ativanat(){
89
echo "*** Ativando NAT"
#Caregando Modulos
modprobe iptable_nat
modprobe nf_conntrack_ftp
modprobe nf_nat_ftp
modprobe nf_conntrack_netlink
modprobe nfnetlink
echo 1 > /proc/sys/net/ipv4/ip_forward
}
reloadsquid(){
SQUIDPID=/var/run/squid3.pid
if [ -e $SQUIDPID ]; then
echo "*** Fazendo reload do squid"
service squid3 reload
else
echo "*** Fazendo start do squid"
service squid3 start
fi
}
case "$1" in
start)
if [ -e $PIDFILE ]; then
echo " * $0 ja iniciado. Tente $0 (stop|restart|firewall-rules|
reloadsquid)"
exit 1
fi
#Ativando NAT
ativanat
#Aplicando politica padrao
defaultpolice
#Reload do squid
reloadsquid
90
echo "*** Concluido"
touch $PIDFILE
exit 0
;;
stop)
if [ -e $PIDFILE ]; then
echo "*** Restaurando politica padrao "
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
echo "*** Limpando Regras do iptables"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
$IPTABLES -t nat -X
$IPTABLES -t mangle -F
$IPTABLES -t mangle -X
echo "*** Removendo Modulos"
echo 0 > /proc/sys/net/ipv4/ip_forward
rmmod nf_nat_ftp
rmmod nf_conntrack_ftp
rmmod iptable_nat
rmmod nf_conntrack_netlink
rmmod nfnetlink_queue
rmmod nfnetlink
rm $PIDFILE
exit 0
else
echo " * $0 nao iniciado. Tente $0 (start)"
fi
;;
restart)
echo ""
echo "*** Parando serviços ***"
$0 stop
91
echo ""
sleep 1
echo "*** Iniciando serviços ***"
$0 start
;;
firewall-rules)
if [ -e $PIDFILE ]; then
echo ""
echo "**********************************************"
echo "*** Tabela Filter ***"
echo "**********************************************"
echo ""
$IPTABLES -L -n
echo ""
echo "**********************************************"
echo "*** Tabela nat ***"
echo "**********************************************"
echo ""
$IPTABLES -t nat -L -n
echo ""
echo "**********************************************"
echo "*** Tabela mangle ***"
echo "**********************************************"
echo ""
$IPTABLES -t mangle -L -n
else
echo " * $0 nao iniciado. Tente $0 (start)"
fi
;;
*)
echo " * Uso: $0 (start|stop|restart|firewall-rules)"
exit 1
;;
esac
92
ANEXO C – ARQUIVO SQUID.CONF
http_port 172.16.0.1:3128
visible_hostname SRV-FW001
cache_mgr [email protected]
error_directory /usr/share/squid-langpack/pt-br/
cache_mem 8 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 8 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid3 1024 8 128
cache_access_log /var/log/squid3/access.log
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280
#Windows update
refresh_pattern windowsupdate.com/.*\.(cab|exe|dll|msi) 10080 100% 43200 reload-
into-ims
refresh_pattern download.microsoft.com/.*\.(cab|exe|dll|msi) 10080 100% 43200
reload-into-ims
refresh_pattern www.microsoft.com/.*\.(cab|exe|dll|msi) 10080 100% 43200
reloadinto-ims
refresh_pattern au.download.windowsupdate.com/.*\.(cab|exe|dll|msi) 4320 100%
43200 reload-into-ims
refresh_pattern download.windowsupdate.com/.*\.(cab|exe|dll|msi) 4320 100%
43200 reload-into-ims
refresh_pattern update.microsoft.com/.*\.(cab|exe|dll|msi) 4320 100% 43200
reloadinto-ims
#Lista de ACL
93
acl safe_ports port 80 # http
acl safe_ports port 81 # http
acl safe_ports port 21 # ftp
acl safe_ports port 443 # https
acl safe_ports port 563 # snews
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 safe_ports port 901 # SWAT
acl purge method PURGE
acl connect method CONNECT
acl localhost src 127.0.0.1
#Autenticacao por LDAP
auth_param basic program /usr/lib/squid3/basic_ldap_auth -R -b
"dc=empresa,dc=local" -D "cn=ldap,cn=Users,dc=empresa,dc=local" -w "P@ssw0rd"
-f sAMAccountName=%s -h 172.16.0.2
auth_param basic children 15
auth_param basic realm Digite seu Login/Senha
#Windows Update
acl windowsupdate dstdomain windowsupdate.microsoft.com
acl windowsupdate dstdomain .update.microsoft.com
acl windowsupdate dstdomain download.windowsupdate.com
acl windowsupdate dstdomain redir.metaservices.microsoft.com
acl windowsupdate dstdomain images.metaservices.microsoft.com
acl windowsupdate dstdomain c.microsoft.com
acl windowsupdate dstdomain www.download.windowsupdate.com
acl windowsupdate dstdomain wustat.windows.com
acl windowsupdate dstdomain crl.microsoft.com
94
acl windowsupdate dstdomain sls.microsoft.com
acl windowsupdate dstdomain productactivation.one.microsoft.com
acl windowsupdate dstdomain ntservicepack.microsoft.com
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny CONNECT !safe_ports
http_access deny !safe_ports
http_access allow windowsupdate
acl autenticados proxy_auth REQUIRED
http_access allow autenticados
http_access deny all
95
ANEXO D – ARQUIVO DE INICIALIZAÇÃO DO SAMBA 4
#! /bin/sh
### BEGIN INIT INFO
# Provides: samba-ad-dc
# Required-Start: $network $local_fs $remote_fs
# Required-Stop: $network $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start Samba daemons for the AD DC
### END INIT INFO
#
# Start/stops the Samba daemon (samba).
# Adapted from the Samba 3 packages.
#
PIDDIR=/usr/local/samba/var/run
SAMBAPID=$PIDDIR/samba.pid
# clear conflicting settings from the environment
unset TMPDIR
# See if the daemon and the config file are there
test -x /usr/local/samba/sbin/samba -a -r /usr/local/samba/etc/smb.conf || exit 0
. /lib/lsb/init-functions
case "$1" in
start)
SERVER_ROLE=`/usr/local/samba/bin/samba-tool testparm --parameter-
name="server role" 2>/dev/null | tail -1`
96
if [ "$SERVER_ROLE" != "active directory domain controller" ]; then
exit 0
fi
if init_is_upstart; then
exit 1
fi
# CVE-2013-4475
KEYFILE=/var/lib/samba/private/tls/key.pem
if [ -e $KEYFILE ]
then
KEYPERMS=`stat -c %a $KEYFILE`
if [ "$KEYPERMS" != "600" ]
then
echo "wrong permission on $KEYFILE, must be 600"
echo "samba will not start (CVE-2013-4475)"
echo "Removing all tls .pem files will cause an auto-
regeneration with the correct permissions."
exit 1
fi
fi
log_daemon_msg "Starting Samba AD DC daemon" "samba"
# Make sure we have our PIDDIR, even if it's on a tmpfs
install -o root -g root -m 755 -d $PIDDIR
if ! start-stop-daemon --start --quiet --oknodo --exec
/usr/local/samba/sbin/samba -- -D; then
log_end_msg 1
exit 1
fi
log_end_msg 0
97
;;
stop)
if init_is_upstart; then
exit 0
fi
log_daemon_msg "Stopping Samba AD DC daemon" "samba"
start-stop-daemon --stop --quiet --pidfile $SAMBAPID
# Wait a little and remove stale PID file
sleep 1
if [ -f $SAMBAPID ] && ! ps h `cat $SAMBAPID` > /dev/null
then
# Stale PID file (samba was succesfully stopped),
# remove it (should be removed by samba itself IMHO.)
rm -f $SAMBAPID
fi
log_end_msg 0
;;
restart|force-reload)
if init_is_upstart; then
exit 1
fi
$0 stop
sleep 1
$0 start
;;
status)
status_of_proc -p $SAMBAPID /usr/local/samba/sbin/samba samba
exit $?
;;
*)
echo "Usage: /etc/init.d/samba-ad-dc {start|stop|restart|force-reload|
98
status}"
exit 1
;;
esac
exit 0
99
ANEXO E – FUNCIONALIDADES DE MODOS DE DOMÍNIOS
Tabela E.1 - Funcionalidades disponíveis em cada um dos modos de domínios
Nível do domínio Funcionalidades Disponíveis Pode ter DCs com:
Windows 2000 misto – Somente as básicas, comuns a todas as
versões do Windows
– NT Server 4.0
– Windows 2000 Server
– Windows Server 2003
Windows 2000 Nativo – Todas as funcionalidades básicas do AD
– Grupos Universais
– Grupos dentro de grupos
– Conversão de tipo de grupo
– Histórico de SID
– Windows 2000 Server
– Windows Server 2003
– Windows Server 2008
Windows Server 2003 – Todas as funcionalidades básicas do AD
– Todas as funcionalidades do modo
Windows 2000 nativo
– Renomeação de domínios
– Atualização de horário do último logon
– Redirecionamento dos contêineres
Usuários e Computadores
– Armazenamento de políticas de
gerenciamento de autorização no AD
– Autenticação seletiva de usuários de
florestas confiáveis
– Recursos avançados de segurança para
o desenvolvimento de aplicações
– Windows Server 2003
– Windows Server 2008
Windows Server 2008 – Todas as funcionalidades básicas do AD
– Todas as funcionalidades do modo
Windows 2000 nativo
Todas as funcionalidades do modo
Windows Server 2003
– Replicação distribuída do SYSVOL
– Serviço avançado de criptografia (AES
128 e 256) para o protocolo de
autenticação Kerberos
– Informações sobre o último logon
interativo bem-sucedido
– Opções mais refinadas e avançadas
para a definição de políticas e senhas
– Windows Server 2008
Fonte: Battisti; Santana, 2009, p. 322
100
ANEXO F – FUNCIONALIDADES DE MODOS DE FLORESTAS
Tabela F.1 - Funcionalidades disponíveis em cada um dos modos de florestasNível da floresta Funcionalidades Disponíveis Pode ter DCs com:
Windows 2000 – Todas as funcionalidades básicas do AD
– Grupos Universais
– Grupos dentro de grupos
– Conversão de tipo de grupo
– Histórico de SID
– Windows 2000 Server
– Windows Server 2003
– Windows Server 2008
Windows Server 2003 – Todas as funcionalidades básicas do AD
– Relação de confiança entre florestas
– Renomeação de domínios
– Replicação diferencial de grupos, onde
somente as alterações feitas no grupo são
replicadas entre os DCs
– Instalação de DCs somente leitura
(RODC)
– Melhorias no KCC, as quais implicam
em melhorias na replicação entre DCs
Criação de instâncias de classes
dinâmicas auxiliares
Conversão de uma instância de objeto da
classe INETORGPERSON em um objeto
da classe User
– Desativação e redefinição de atributos
de classes e no Schema
– Windows Server 2003
– Windows Server 2008
Windows Server 2008 – Todas as funcionalidades básicas do AD
– Todas as funcionalidades do modo
Windows Server 2003
– Todos os novos domínios que forem
adicionados a uma árvore com esta
funcionalidade já serão automaticamente
configurados para o nível de
funcionalidade de domínio Windows
Server 2008
– Windows Server 2008
Fonte: Battisti; Santana, 2009, p. 323