centro estadual de educação tecnológica paula souza

Transcription

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
SAMBA 4
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins para obtenção do
Título de Tecnólogo em Redes de Computadores.
Orientador: Prof. Me. Alexandre Ponce de Oliveira
LINS/SP
1º SEMESTRE/2015
SAMBA 4
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins, como parte dos
requisitos necessários para a obtenção do título de
Tecnólogo(a) em Redes de Computadores sob
orientação do Prof. MSC Alexandre Ponce de
Oliveira.
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 Sierra
Ascêncio Fernandes, aos meus avós, Aurio Sierra
Pardo, in memoriam e Percília Sierra Assêncio
Pardo e a minha futura esposa Eloisa Suzuki Maia
pelo apoio e incentivo nesta jornada.
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.
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 tornouse
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
trabalham
que
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/IP
Fonte: 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
Figura 1.2: Protocolos e redes no modelo TCP/IP Inicial
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
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.
Figura 1.3: Servidores DNS raiz em 2012
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.
Figura 1.4: DNS Root Servers distribuídos pelo mundo
Fonte: Root-Server, 2013
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)
Figura 1.5: Hierarquia de servidores DNS
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 –
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 IPv4
Tipo
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 correio
NS
Servidor de nomes
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
Texto
Prioridade, domínio disposto a aceitar
correio eletrônico
Nome de um servidor para este
domínio
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)
Figura 1.6: Exemplo de uma árvore de diretório LDAP
Fonte: Carter, 2003, p. 10
A tabela 1.2 lista alguns nomes de atributos comuns em hierarquias LDAP.
22
Tabela 1.2 - Nomes de atributo comuns encontrados em hierarquias LDAP
Atributo
Significado
O que é
Atributo
Organização
ou
Unidade Organizacional
cn
Nome Comum
dc
Componente de domínio
objectClass Classe de objetos
Identifica frequentemente a entrada de
primeiro nível de uma instalação
Uma subdivisão lógica
O nome mais natural para representar a
entrada
Utilizado em sites que modelam sua
hierarquia LDAP com base no DNS
Esquema ao qual os atributos dessa
entrada obedecem
Fonte: 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.
Figura 1.7: Exemplo de domínio Kerberos
Fonte: Siqueira, 2009, p. 110
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)
Figura 1.8: O mascote do Linux - Tux
Fonte: Siqueira, 2009, p. 20
26
Dentre os diversos recursos presentes no sistema operacional Linux, podemse 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
Mínimo: 10GB – Recomendado: 40GB ou mais
disco/outros
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/Mouse
Fonte: 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.
Figura 2.1: Hierarquia de um domínio Active Directory
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
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.
Figura 2.2: Domínios de uma árvore
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,
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.
Figura 2.3: Relações de confiança bidirecionais e transitivas
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
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
Figura 2.4: Relações de confiança externas – unidirecional ou bidirecional
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
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.
Figura 2.5: Relação de confiança do tipo Shortcut
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)
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.
Figura 2.6: Usuário herda as permissões do grupo
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
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
Figura 2.7: Divisão de um domínio em Unidades Organizacionais
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
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.
Figura 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.
Figura 2.9: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.
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
Figura 2.10: MMC sem nenhum snap-in carregado
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.
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.
Figura 3.1: Registro de nome com e sem 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.
52
Figura 3.2: Resolução de nomes com e sem servidor de nomes NetBIOS
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.
53
A tabela 3.2 exemplifica os tipos de recursos disponíveis:
Tabela 3.1 - Tipos de nós NetBIOS
Descriçã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.
Tabela 3.2 - Tipos de recursos
Recurso
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
21
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 NetBIOS
Recurso
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)
20
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.
Figura 4.1: Topologia da rede de testes
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-FW001
FIREWALL/GATEWAY, SERVIDOR
SERVIDOR DNS SECUNDÁRIO
SRV-AD001
SERVIDOR AD, SERVIDOR DNS PRIMÁRIO
172.22.0.2/22
-
RESERVADO INFRAESTRUTURA
172.22.0.3/22 a
172.22.0.255/22
CLIENTES
DIVERSOS
COMPUTADORES DE USUÁRIOS
DINÂMICO,
ATRIBUÍDO POR
DHCP
DHCP,
172.22.0.1/22
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 virtuais
Máquina
Memória (RAM)
HD
Rede
SRV-FW001
512MB
1x 10GB
1x rede bridge
1x rede host-only
SRV-AD001
512MB
1x 10GB
1x 250GB
1x rede host-only
CLIENTE 1
512MB
1x 10GB
1x rede host-only
CLIENTE 2
512MB
1x 10GB
1x rede host-only
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:
# echo allow-hotplug eth0 >> /etc/network/interfaces
# echo iface eth0 inet dhcp >> /etc/network/interfaces
# service networking restart
A seguir procedimento realizado para instalação dos pacotes, conforme
comando:
# 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:
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;
}
Na sequência deve-se reiniciar o serviço DHCP, conforme comando:
# service isc-dhcp-server restart
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”:
zone "empresa.local" {
type slave;
file "db.empresa.local";
masters { 172.16.0.2; };
allow-notify { 172.16.0.2; };
};
61
Na sequência deve-se reiniciar o serviço bind, conforme comando:
# service bind9 restart
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:
# chmod +x /etc/init.d/firewall
# update-rc.d firewall defaults
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:
# service squid3 restart
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:
# apt-get install build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls28-dev
libreadline-dev python-dev python-dnspython gdb pkg-config libpopt-dev libldap2dev dnsutils libbsd-dev attr krb5-user docbook-xsl openssh-server bind9
Em seguida é alterado o arquivo /etc/fstab para permitir que a partição onde
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:
# UUID=6ffe3049-b88b-4e20-bbff-4300c566ca33 /srv ext4 user_xattr,acl,barrier=1
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:
# 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
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:
# 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:
# /usr/local/samba/bin/samba-tool domain provision --domain=EMPRESA
--realm=EMPRESA.LOCAL --dns-backend=BIND9_DLZ --server-role=dc
--adminpass=p@ssw0rd
A tabela 4.3 explica a funcionalidade de cada opção utilizada.
Tabela 4.3 - Opções utilizadas no provisionamento do domínio
OPÇÃO
FUNÇÃO
domain provision
Instrui o samba-tool que será
provisionamento de um novo domínio
--domain=EMPRESA
Define o grupo NetBIOS do domínio que será utilizado
--realm=EMPRESA.LOCAL
Define o nome do sufixo do domínio que será utilizado
pelo AD
--dns_backend=BIND9_DLZ
Define que o programa de DNS utilizado será o
BIND9
--server-role=dc
Define que o servidor será um DC
--adminpass=p@ssw0rd
Define
a
senha
do
(administrador do domínio)
usuário
realizado
o
administrator
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:
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 updates
Setting up sam.ldb rootDSE marking as synchronized
A Kerberos configuration suitable for Samba 4 has been generated at
/usr/local/samba/private/krb5.conf
Once the above files are installed, your Samba4 server will be ready to use
Server Role:
active directory domain controller
Hostname:
SRV-AD001
NetBIOS Domain:
EMPRESA
DNS Domain:
empresa.local
DOMAIN 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:
# echo include "/usr/local/samba/private/named.conf"; >> /etc/bind/named.conf
# service bind9 restart
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:
# kinit [email protected]
Password for [email protected]:
Warning: Your password will expire in 19 days on Seg 13 Jul 2015 20:42:54 BRT
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:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting
Expires
24-06-2015
13:47:51
Service principal
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:
# mkdir /srv/ADM
# mkdir /srv/CONT
# mkdir /srv/FIN
# mkdir /srv/TI
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:
[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.
Figura 4.2: Snap-ins
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;
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.
Figura 4.3: Criação de novo grupo
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.
Figura 4.4: Parâmetros para criação do grupo
68
A Figura 4.5 ilustra os grupos criados neste estudo de caso, separados em
uma unidade organizacional “Matriz”.
Figura 4.5: Grupos criados separados em unidades organizacionais
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.
Figura 4.6: Parâmetros para criação de um novo usuário
69
Depois são solicitadas informações referentes à segurança da conta.
Nenhuma opção é selecionada conforme exemplifica a Figura 4.7.
Figura 4.7: Parâmetros de segurança
A Figura 4.8 ilustra os usuários criados neste estudo de caso, separados em
uma unidade organizacional “Matriz”.
Figura 4.8: Usuários criados separados em unidades organizacionais
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. Optouse neste estudo de caso a atribuição através da alteração dos parâmetros
70
diretamente na conta do usuário, por meio do menu suspenso “Propriedades”, aba
“Membro de”, conforme ilustra a Figura 4.9.
Figura 4.9: Grupos do usuário
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.
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 grupos
USUÁRIO
GRUPO
Alexandre Ponce de Oliveira
Administração
Amabili Sierra Fernandes
Financeiro
Eduardo Sierra Fernandes
Tecnologia da Informação
Eloisa Suzuki Maia
Contabilidade
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.
Figura 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.
Figura 4.12: Configurações de proxy via GPO
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.
Figura 4.13: snap-in para permissões de pastas
73
Após adicionar o snap-in, é solicitado definir o computador que possui
compartilhamentos gerenciados pelo snap-in, conforme ilustra a Figura 4.14.
Figura 4.14: Seleção do computador a ser gerenciado
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.
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.
Figura 4.16: Domínio disponível para logon
Figura 4.17: Acesso às pastas compartilhadas pelo servidor
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.
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.
<http://www.debian.org/releases/>. Acesso em: 30 nov. 2013.
Disponível
em:
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.
<http://web.mit.edu/kerberos/>. Acesso em: 19 nov. 2013.
Disponível
em:
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: Digerati
Books, 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 Prentice
Hall, 2007.
79
POLICELLI, J., Active directory domain services 2008. São Paulo: Pearson
Prentice Hall, 2009.
ROOT-SERVER. List of DNS root-servers. 2013. Disponível em: <http://www.rootservers.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
<https://wiki.samba.org/index.php/Main_Page>. Acesso em: 29 mai. 2015.
em:
SILVA, G. M., Guia foca linux iniciante. 2010. Disponível
<http://www.guiafoca.org/?page_id=238>. Acesso em: 25 nov. 2013.
em:
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 de
computadores: 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.
Figura A.1: Tela de boot do CD de Instalação Debian 8.0 (Jessie)
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
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.
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
Figura A.5: Configurações de rede - SRV-AD001
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.
Figura A.6: Configuração de gateway em SRV-AD001
83
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
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.
Figura A.9: Definição da senha de root
84
Figura A.10: Definição de nome de usuário “restrito”
Figura A.11: Definição de senha de usuário “restrito”
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.
Figura A.12: Seleção do método de particionamento de disco
As definições de particionamento de disco foram realizadas conforme ilustra a
tabela A.1
85
Tabela A.1 - Particionamento de disco
SERVIDOR
PARTIÇÃO
DISPOSITIVO
TAMANHO
SRV-FW001
/boot
/dev/sda1
200mb
SRV-FW001
Swap
/dev/sda5
1gb
SRV-FW001
/
/dev/sda6
SRV-AD001
/boot
/dev/sda1
200mb
SRV-AD001
Swap
/dev/sda5
1gb
SRV-AD001
/
/dev/sda6
SRV-AD001
/srv
/dev/sdb1
Espaço restante.
Em torno de 9gbps
Espaço restante.
Em torno de 9gbps
250gb
As figuras A.13 e A.14 ilustram o particionamento realizado nos servidores
SRV-FW001 e SRV-AD001, respectivamente.
Figura A.13: Particionamento de disco – SRV-FW001
Figura A.14: Particionamento de disco – SRV-AD001
Finalizado o particionamento de disco, o instalador realiza a instalação dos
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.
Figura A.15: Seleção de mirror do gerenciador de pacotes
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.
Figura A.16: Seleção de software
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.
87
Figura A.17: Instalação do gerenciador GRUB
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.
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)
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)
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 reloadinto-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:
2345
# Default-Stop:
016
# 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 --parametername="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 autoregeneration 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)
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)
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 – NT Server 4.0
versões do Windows
– Windows 2000 Server
– Windows Server 2003
Windows 2000 Nativo
– Todas as funcionalidades básicas do AD – Windows 2000 Server
– Grupos Universais
– Grupos dentro de grupos
– Conversão de tipo de grupo
– Histórico de SID
Windows Server 2003
– Todas as funcionalidades básicas do AD – Windows Server 2003
– Todas as funcionalidades do modo – Windows Server 2008
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 2008
– 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
100
ANEXO F – FUNCIONALIDADES DE MODOS DE FLORESTAS
Tabela F.1 - Funcionalidades disponíveis em cada um dos modos de florestas
Nível da floresta
Funcionalidades Disponíveis
Pode ter DCs com:
Windows 2000
– Todas as funcionalidades básicas do AD – Windows 2000 Server
– Grupos Universais
– Grupos dentro de grupos
– Conversão de tipo de grupo
– Histórico de SID
Windows Server 2003
– 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 2008
– 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
funcionalidade
de
Server 2008
o
domínio
nível
de
Windows

centro estadual de educação tecnológica paula souza

Transcription

Similar documents

HP Pavilion Data Sheet

Tutorial Windows Movie Maker

Missão: Carnavalesco

50 HACKS PARA O WINDOWS XP

Diretivas de grupo-Book

do Folheto

Apostila de informática básica - PET

Os Alicerces da Folia

moviemakeryoutube - BomByte - Servicos Informaticos Lda.

uma etnografia da Escola de Samba Embaixada Copa Lord.

Shell Script do zero