Instalação do Squid com autenticação NTLM e Kerberos

gtt Neste projeto foi usado um micro para agir na rede como firewall de filtragem de pacotes e proxy. Para filtragem de pacotes recebidos da internet usamos o iptables v1. 4.2, Squid versão 2.5 STABLE14 e sistema operacional Debian Etch GNU/Linux com o kernel 2.6.18-6-k7. Para controle de relatórios de acesso usei o Sarg 2.2.5 e para controle de pacotes usei o Iptraf 3.0.0. Como método de segurança na autenticação de senhas usei o Kerberos v5.
Descrição dos softwares:

Firewall Iptables

Firewall pode ser definido como uma barreira de proteção, que controla o tráfego de dados entre seu computador e a Internet (ou entre a rede onde seu computador está instalado e a Internet). Seu objetivo é permitir somente a transmissão e a recepção de dados autorizados. Existem firewalls baseados na combinação de hardware e software e firewalls baseados somente em software. Este último é o tipo recomendado ao uso doméstico e também é o mais comum.

Explicando de maneira mais precisa, o firewall é um mecanismo que atua como “defesa” de um computador ou de uma rede, controlando o acesso ao sistema por meio de regras e a filtragem de dados. A vantagem do uso de firewalls em redes, é que somente um computador pode atuar como firewall, não sendo necessário instalá-lo em cada máquina conectada.
Como funciona: Há mais de uma forma de funcionamento de um firewall, que varia de acordo com o sistema, aplicação ou do desenvolvedor do programa. No entanto, existem dois tipos básicos de conceitos de firewalls: o que é baseado em filtragem de pacotes e o que é baseado em controle de aplicações. Ambos não devem ser comparados para se saber qual o melhor, uma vez que cada um trabalha para um determinado fim, fazendo que a comparação não seja aplicável. Conheça cada tipo a seguir. No nosso caso usamos o modo FILTRAGEM DE PACOTES.
Filtragem de pacotes: O firewall que trabalha na filtragem de pacotes é muito utilizado em redes pequenas ou de porte médio. Por meio de um conjunto de regras estabelecidas, esse tipo de firewall determina que endereços IPs e dados possam estabelecer comunicação e/ou transmitir/receber dados. Alguns sistemas ou serviços podem ser liberados completamente (por exemplo, o serviço de e-mail da rede), enquanto outros são bloqueados por padrão, por terem riscos elevados (como softwares de mensagens instantâneas, tal como o ICQ). O grande problema desse tipo de firewall, é que as regras aplicadas podem ser muito complexas e causar perda de desempenho da rede ou não ser eficaz o suficiente.
Este tipo se restringe a trabalhar nas camadas TCP/IP, decidindo quais pacotes de dados podem passar e quais não. Tais escolhas são regras baseadas nas informações endereço IP remoto, endereço IP do destinatário, além da porta TCP usada.
Quando devidamente configurado, esse tipo de firewall permite que somente “computadores conhecidos troquem determinadas informações entre si e tenham acesso a determinados recursos”. Um firewall assim, também é capaz de analisar informações sobre a conexão e notar alterações suspeitas, além de ter a capacidade de analisar o conteúdo dos pacotes, o que permite um controle ainda maior do que pode ou não ser acessível.

Iptraf

Iptraf é um programa que possui a função de monitorar a rede a qual o seu computador está conectado, através de dados transmitidos sobre os protocolos IP/TCP e UDP/IP, entre outros. O aplicativo tem a capacidade de exibir diversas estatísticas, como número de pacotes e seus respectivos tamanhos, além da velocidade de suas transmissões. O programa funciona em modo texto, em algum terminal de sistema, como o Konsole.
A princípio é possível aplicar IPTRAF em diversas tecnologias de rede físicas distintas, entre elas: Ethernet, FDDI, SLIPP e interfaces de loopback. Além das várias redes, é possível também utilizar o programa para monitorar diversos protocolos distintos.

Squid

O Squid é um servidor proxy que suporta HTTP, HTTPS, FTP e outros. Ele reduz a utilização da conexão e melhora os tempos de resposta fazendo cache de requisições frequentes de páginas web numa rede de computadores. Ele pode também ser usado como um proxy reverso. No cache são armazenados os objetos da Internet (ex. dados de páginas web) disponíveis via protocolo HTTP, FTP e Gopher num sistema mais próximo ao do cliente.
Os navegadores podem então usar o Squid local como um servidor Proxy HTTP, reduzindo o tempo de acesso aos objetos e reduzindo a utilização da conexão. Isto é muito usado por provedores no mundo todo para melhorar a velocidade de navegação para seus clientes e também em LAN que compartilham a mesma conexão à Internet.
Ele pode fornecer anonimato e segurança dado ser um intermediário no acesso aos objetos. No entanto a sua utilização pode gerar preocupações a respeito da privacidade pois o Squid é capaz de armazenar registos sobre os acessos, incluindo URLs acedidas, a data e hora exatas, e quem acedeu. Isto é usado frequentemente nas empresas para controlarem o acesso à Internet dos seus funcionários.
A aplicação cliente (ex.navegador) deverá especificar explicitamente o servidor proxy que quer utilizar (típico para os clientes de provedores), ou poderá utilizar uma proxy sem qualquer configuração extra: caching transparente, em que todos os pedidos HTTP para fora, são interceptados pelo Squid e todas as respostas são armazenadas em cache. Este é uma típica configuração em corporações (todos os clientes na mesma rede local) e introduz as preocupações com privacidade mencionadas acima.
Squid tem algumas funcionalidades que permitem tornar as conexões anônimas, tais como desabilitar ou alterar campos específicos do cabeçalho dos pedidos HTTP do cliente. Se isto é feito e como, é controlado pela pessoa que administra a máquina que corre o Squid. As pessoas que requisitam páginas numa rede que usa Squid de forma transparente podem não saber que esta informação está a ser registada. Em determinados países, os utilizadores devem ser informados sobre a possível monitorização e registo das ligações internet.

Sarg

O Sarg é um interpretador de logs para o Squid, assim como o Webalizer e o Apache. Sempre que executado ele cria um conjunto de páginas, divididas por dia, com uma lista de todas as máquinas que foram acessadas e a partir de cada máquina da rede veio cada acesso. Ele também mostra os usuários, caso o Squid esteja configurado para exigir autenticação.
A partir daí você pode acompanhar as páginas que estão sendo acessadas, mesmo que não exista nenhum filtro de conteúdo e tomar as medidas cabíveis em casos de abuso. Todos sabem que os filtros de conteúdo nunca são completamente eficazes, eles sempre bloqueiam algumas páginas úteis e deixam passar muitas páginas impróprias. Se você tiver algum tempo para ir acompanhando os logs, a inspeção manual é sempre o método mais eficiente.

Kerberos

Kerberos é um protocolo de autenticação de rede que oferece um método extremamente seguro para autenticar clientes e servidores (entidades de segurança) de uma rede. Essas entidades de segurança usam uma autenticação baseada em chaves mestras e permissões criptografadas.
No modelo de protocolo Kerberos, todas as conexões de cliente/servidor começam com a autenticação. Por sua vez, cliente e servidor seguem uma sequência de ações que se destinam a verificar em uma ponta da conexão se a outra ponta é verdadeira. Se a autenticação tiver êxito, a configuração da sessão será concluída e uma sessão cliente/servidor segura será estabelecida.
Entre os principais benefícios da autenticação Kerberos estão:

  • Autenticação mútua. O cliente pode validar a identidade da entidade de servidor e o servidor pode validar o cliente. Com essa documentação, as duas entidades são denominadas “cliente” e “servidor” mesmo que seja possível estabelecer conexões seguras de rede entre servidores.
  • Permissões de autenticação seguras. São utilizadas somente permissões criptografadas, e as senhas nunca são incluídas na permissão.
  • Autenticação integrada. Uma vez que o usuário faça logon, ele não precisa efetuar logon novamente para acessar algum serviço que suporte a autenticação Kerberos, pois a permissão do cliente não expira. Todas as permissões têm um prazo de validade determinado pelas diretivas do Kerberos que geram a permissão.

O Kerberos oferece um mecanismo para autenticação mútua entre entidades antes do estabelecimento de uma conexão de rede segura. Kerberos usa terceiros confiáveis, o KDC (Key Distribution Center), para facilitar a geração e a distribuição segura de permissões de autenticação e chaves de sessões simétricas. O KDC é executado como um serviço em um servidor seguro e mantém um banco de dados para todas as entidades de segurança de seu território. No contexto de Kerberos, um território é o equivalente a um domínio do Windows.
Mas também temos as desvantagens que precisam ser mostradas:

  • Migrar senhas de usuário de um banco de dados UNIX padrão, como o /etc/passwd ou o /etc/shadow, para um banco de dados de senhas Kerberos pode ser entediante, pois não há um mecanismo automatizado para executar esta tarefa.
  • O Kerberos tem apenas compatibilidade parcial com os Módulos de Autenticação Plugáveis (PAM), sistema usado pela maioria dos servidores Red Hat Enterprise Linux.
  • O Kerberos presume que cada usuário é confiável e está usando uma máquina não confiável em uma rede não confiável. Seu objetivo principal é evitar que senhas não criptografadas sejam enviadas pela rede. No entanto, se alguém além do usuário legítimo tiver acesso à máquina que emite tickets usados para autenticação – chamada de centro de distribuição de chave (KDC) – o sistema de autenticação inteiro do Kerberos estará em risco.
  • Para que um aplicativo use o Kerberos, sua fonte deve ser alterada para fazer as chamadas apropriadas às bibliotecas do Kerberos. Os aplicativos modificados desta maneira são considerados kerberizados. Para alguns aplicativos, isto pode ser bastante problemático devido ao tamanho ou design do aplicativo. Para outros aplicativos incompatíveis, as alterações devem ser feitas na maneira como o lado servidor e clientes se comunicam. Vale frisar que isto pode requerer uma programação extensiva. Aplicativos de código fechado que não têm suporte ao Kerberos por padrão são geralmente os mais problemáticos.
  • O Kerberos é uma solução ‘tudo ou nada’. Se ele for utilizado na rede, quaisquer senhas não criptografadas transferidas a um serviço não-kerberizado estão em risco. Portanto, a rede não se beneficia do uso do Kerberos. Para proteger uma rede com o Kerberos, devem-se utilizar versões kerberizadas de todos os aplicativos cliente/servidor que enviam senhas não criptografadas ou não usar nenhum aplicativo do tipo cliente/servidor.

Como tudo funciona

O firewall foi criado com regras para compartilhar a internet, lembrando que temos 2 interfaces de rede, sendo 1 para (rede local) e outra para receber a internet a (Ethernet). Nele, acrescentei as regras para redirecionamento, liberação e bloqueio de portas, liberação da rede local e loopback, bloqueio para rede externa, Nat, mascaramento da rede, redirecionamento da porta 80 para o proxy e o bloqueio do restante. Ainda estou estruturando da o firewall da melhor maneira, mas por enquanto é o necessário.
O Squid funciona como o gerente do acesso a internet, liberando o que for preciso e bloqueando o restante. Nele criei regras para o bloqueio de sites, palavras, streamings, downloads e regras para liberar os mesmos quando for preciso. Sua autenticação é feita no Active Directory via NTLM. Ele autentica pela senha do usuário logado na estação de trabalho.

Como o NTLM funciona

As etapas a seguir apresentar um esboço de autenticação NTLM não interativo. O primeiro passo fornece as credenciais NTLM do utilizador e só ocorre como parte da autenticação interativa (logon) do processo.
Autenticação Interactive apenas – um usuário acessa um computador cliente e fornece um nome de domínio, nome de usuário e senha. hash O cliente calcula a criptografia hash da senha e descarta a senha real.
plaintext – o cliente envia o nome de usuário para o servidor (no texto original).
nonce – o servidor gera um byte aleatório número 16, chamado de desafio ou nonce, e envia para o cliente. O cliente criptografa o desafio com o hash da senha do usuário e retorna o resultado para o servidor. Isso é chamado de a resposta.
O servidor envia os seguintes três itens para o controlador de domínio:

  • Nome de usuário
  • Desafio enviado para o cliente
  • Resposta recebida do cliente
  • O controlador de domínio usa o nome de usuário para recuperar o hash da senha do usuário do banco de dados Security Account Manager. Ele usa este hash de senha para criptografar o desafio.
    O controlador de domínio compara o desafio é criptografado computadorizada (na etapa 6) a resposta calculada pelo cliente (na etapa 4). Se forem idênticos, a autenticação é bem sucedida.
    O kerberos funciona como segurança para essa autenticação, pois invés de se usar as senhas e usuários como em outros métodos de autenticação ele usa “Tickets”. Vamos entender melhor.
    Vejamos como o Kerberos trabalha. Usuários e serviços que utilizem o Kerberos possuem chaves armazenadas no AS. As chaves dos usuários são derivadas de senhas escolhidas por estes, e as chaves dos serviços são geradas aleatoriamente.
    Para esta explicação, imaginemos que as mensagens são escritas em papel, e são criptografadas colocando-as em uma caixa-forte, associada a uma chave.
    Primeiro o usuário envia uma mensagem ao AS: “Eu, J. Random User gostaria de falar com o servidor Foo”.
    Quando o AS recebe a mensagem, ele faz duas cópias de uma nova chave registrada. Estas chaves são chamadas de chaves de sessão. Elas serão usadas nas trocas diretas entre serviço e usuário.
    Ele coloca uma das chaves de sessão na Caixa 1, junto com um pedaço de papel com o nome “Servidor Foo” escrito. A caixa é trancada com a chave do usuário (o AS conhece todas as chaves de usuário e todas as chaves de serviço).
    Por que este papel aqui? Devemos nos lembra que a caixa é na realidade apenas uma mensagem criptografada, e que a chave de sessão é uma sequência randômica de bytes. Se a Caixa 1 somente contivesse a chave de sessão, o usuário não teria como reconhecer se a resposta veio do AS, ou não saberia se a decriptação teve sucesso. Pela adição da mensagem “Servidor Foo”, o usuário (mais precisamente a aplicação do usuário) poderia saber se a caixa veio do AS, e se a decriptação obteve sucesso.
    Ele coloca a outra chave de sessão em uma Caixa 2, junto com um pedaço de papel com o nome “J. Random User”. Esta caixa é fechada com a chave do serviço.
    Ele envia ambas as caixas ao usuário. Na versão 4 do Kerberos, a Caixa 2 era colocada (sem necessidade) dentro da caixa 1, mas na versão 5 isto foi corrigido. O usuário destranca a Caixa 1 com sua chave, extraindo assim a chave de sessão e o papel com o nome “Servidor Foo” escrito nele.
    O usuário não consegue abrir a Caixa 2 (ela foi trancada com a chave do serviço, que só o AS e o serviço conhecem). Então ele coloca um pedaço de papel com a hora corrente numa Caixa 3, e tranca esta com chave de sessão, e envia ambas ao serviço.
    O serviço abre a Caixa 2 com sua própria chave, extraindo a chave de sessão e o papel com “J. Random User” escrito nele. Ele abre a Caixa 3 com a chave de sessão para extrair o pedaço de papel com a hora corrente nele. Estes itens demonstram a identidade do usuário.
    O timestamp é colocado na Caixa 3 para prevenir que alguém faça uma cópia da Caixa 2 (devemos nos lembrar que as caixas são na verdade mensagens eletrônicas) e a utilize para se passar pelo usuário mais tarde. Como os relógios da rede nunca são perfeitamente sincronizados, uma pequena margem (em geral 5 minutos) é permitida entre o timestamp e a hora atual. Além disto, o serviço mantém uma lista das autenticações recebidas recentemente para garantir que elas não foram reenviadas.
    A chave de serviço é gerada aleatoriamente e armazenada em um arquivo especial chamado de SECRETE KEY FILE. O Kerberos assume que este é seguro, que ninguém pode copiá-lo e se passar pelo serviço.
    No Kerberos, a Caixa 2 é chamada de ticket, e a Caixa 3 de authenticator. O authenticator tipicamente contém mais informações do que as listadas acima. Algumas destas informações são adicionadas em decorrência do fato de que as mensagens são eletrônicas (por exemplo, existem checksum). Pode existir também uma chave secreta usada para criptografar as mensagens que serão trocadas entre usuário e serviço após a autenticação, garantindo assim a privacidade.

Instalando o Kerberos

Estou partindo do princípio que na rede a ser implementada essa solução já exista um Active Directory e um servidor DNS instalado. O servidor DNS é de fundamental importância para o trabalho do Kerberos assim como um servidor de NTP. Então instale esse 3 serviços na rede e configure-os da maneira correta. Antes da instalação do cliente kerberos atente para os seguinte itens:
Antes de instalar qualquer coisa, verificar se o sistema operacional usado está atualizado para não haver nenhum problema como por exemplo: instalar o pacote apt-build que contém compiladores entre outros softwares.
Primeiro, edite o arquivo /etc/hosts colocando o nome e o ip do seu Domain Controller:
# vi /etc/hosts

xxx.xxx.xxx.xxx nomedomicro@dominio.com.br nome do micro
127.0.0.1 localhost.localdomain localhost prx

Obs.: Onde está xxx.xxx.xxx.xxx coloque o ip servidor Active Directory.
Depois edite o seu resolv.conf e coloque o nome do servidor DNS:
# vi /etc/resolv.conf

nameserver xxx.xxx.xxx.xxx
search nomedodomínio.com.br

Obs.: Onde está xxx.xxx.xxx.xxx coloque o ip servidor DNS.
Depois atualize o relógio do micro com o servidor Ntp da rede ou com um Ntp Server.
# ntpdate [nome do servidor ntp]
ou
# ntpdate ntp.cais.rnp.br (onde está nome do servidor é o servidor de Ntp da rede)
Para instalar o ntpdate use:
# apt-get install ntpdate
Depois vá até seu servidor DNS e crie um host para seu servidor Proxy com o ip do mesmo.
Agora vamos instalar o cliente Kerberos:
# apt-get install krb5-kdc krb5-config krb5-clients libpam-krb5 krb5-user
Obs.: Se for pedido o nome do domínio, disponibilize.
Depois é necessário alterar o aquivo /etc/krb5.conf:
# vi /etc/krb5.conf

[libdefaults]
default_realm = ELETROMOTORES.COM.BR
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
fcc-mit-ticketflags = true
}
[realms]
ELETROMOTORES.COM.BR = {
kdc = xxx.xxx.xxx.xxx
admin_server = xxx.xxx.xxx.xxx
default_domain = xxx.xxx.xxx.xxx
}
[domain_realm]
.eletromotores.com.br = ELETROMOTORES.COM.BR
eletromotores.com.br = ELETROMOTORES.COM.BR
[login]
krb4_convert = true
krb4_get_tickets = false
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log

Obs.: Onde está xxx.xxx.xxx.xxx coloque o ip do Domain Controller e onde está ELETROMOTORES.COM.BR troque pelo domínio da rede respeitando maiúsculas e minúsculas.
Depois altere o arquivo /etc/krb5kdc/kdc.conf:
# vi /etc/krb5kdc/kdc.conf

[kdcdefaults]
kdc_ports = 88
[realms]
ELETROMOTORES.COM.BR = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth
}

Obs.: Faça o mesmo do que no arquivo anterior troque ELETROMOTORES.COM.BR pelo domínio usado na rede.
Depois altere o arquivo /etc/default/krb5-kdc:
# vi /etc/default/krb5-kdc

KRB4_MODE=disable
RUN_KRB524D=false

Obs.: Isso é para desabilitar o Kerberos 4.
Em seguida, vamos iniciar a comunicação entre o Linux e o Domain Controller utilizando Kerberos.
# kinit administrator@ELETROMOTORES.COM.BR
Lembrando que estamos usando o domínio ELETROMOTORES.COM.BR como teste, então troque pelo domínio da sua rede.
Será solicitada a senha do usuário “administrator”. Depois deste passo use o comando klist e veja se retorna isto:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@LAB.VIRTUAL
Valid starting Expires Service principal
02/22/07 14:25:47 02/23/07 00:25:47 krbtgt/LAB.VIRTUAL@LAB.VIRTUAL
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
Caso não seja este o retorno do comando, reveja os passos acima. Gostaria de salientar que encontrei diversos sites com abordagens da instalação do Kerberos no Linux e seus arquivos .conf, mas a única maneira que consegui realizar os testes foi com os arquivos .conf desta maneira descrita no projeto. Portanto se copiarem como está no projeto e só trocar o que for pedido correrá tudo certo. Para testes execute o comando kinit com outros usuários do domínio.
Em seguida vamos editar o arquivo nsswitch.conf:
# vi /etc/nsswitch.conf
Alterar as linhas:
De:
passwd: compat
group: compat
Para:

passwd: compat winbind
group: compat winbind

Instalando o Winbind

Descrição dos componentes usados:

Samba

O Samba é um “software servidor” para Linux (e outros sistemas baseados em Unix) que permite o gerenciamento e compartilhamento de recursos em redes formadas por computadores com o Windows. Assim, é possível usar o Linux como servidor de arquivos, servidor de impressão, entre outros, como se a rede utilizasse servidores Windows (NT, 2000, XP, Server 2003). Este artigo faz uma abordagem introdutória ao Samba, mostrando suas principais características e um pouco de sua história.

Winbind

O Windbind faz a integração entre o Linux e o Domínio NT e toda a comunicação com o Domínio NT é realizada através do Samba, neste caso apenas o Samba-client é utilizado, ou seja, sem carregar o serviço smb. O winbind é responsável por fazer a autenticação usando o NTLM.
Na verdade dentro do pacote samba contém o winbind se fizéssemos o download do samba via wget precisaríamos apenas compilar para usarmos o winbind, mas eu preferi instalar os dois, ai fica a gosto do freguês. A instalação do SAMBA e do WINBIND é simples e pode ser feita via apt-get. Então, vamos por a mão na massa:
# apt-get install samba winbind
Após rodarmos o comando acima, será aberta uma tela de configuração, onde é solicitado o nome do domínio, o uso de senhas encriptadas, que OBRIGATORIAMENTE tem que ser SIM e também é necessário que o samba crie o arquivo de senhas.
Agora é necessário configurar o samba. Para isso, vamos fazer backup do arquivo original e depois vamos criar o nosso arquivo de configuração.
# mv /etc/samba/smb.conf /etc/samba/smb.original
# vi /etc/samba/smb.conf
O arquivo smb.conf deve conter OBRIGATORIAMENTE as linhas abaixo. Outras configurações podem ser feitas de acordo com a necessidade.

[global]
workgroup = ELETROMOTORES
netbios name = SRV-PROXY
server string = PROXY SERVER
load printers = no
log file = /var/log/samba/log.%m
max log size = 500
realm = ELETROMOTORES.COM.BR
security = ads
auth methods = winbind
password server = 192.168.52.3
winbind separator = +
encrypt passwords = yes
winbind cache time = 15
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
local master = no
os level = 233
domain master = no
preferred master = no
domain logons = no
wins server = 192.168.52.3
dns proxy = no
ldap ssl = no

Lembre-se de trocar o domínio na 1º linha mas coloque só o nome do domínio sem .com.br e colocar o nome do micro que será o proxy na 2º linha. Onde está password server coloque o ip do Domain Controller e onde está o Wins Server coloque o ip do servidor Dns que no meu caso é o mesmo do Domain Controller.
Criado o arquivo de configuração, vamos reiniciar os serviços do Samba e do Winbind.
# /etc/init.d/samba stop
# /etc/init.d/winbind stop
# /etc/init.d/samba start
# /etc/init.d/winbind start

Não se esqueça de verificar os logs para saber se tudo iniciou corretamente.
Agora vamos colocar a máquina Linux no domínio Windows.
# net ads join -U administrator -S ELETROMOTORES
Após digitar a senha, que será solicitada, o retorno deve ser semelhante ao retornado abaixo:

Using short domain name — ELETROMOTORES
Joined ‘PROXY’ to realm ‘ELETROMOTORES.COM.BR’

Pronto! A máquina que está rodando o LINUX já faz parte do Domínio Microsoft e pode ser vista no Active Directory Users and Computers.
Você também pode usar o seguinte comando:
# net rpc join ELETROMOTORES -S servidor -Uadministrador
Troque onde está ELETROMOTORES pelo seu domínio onde está SERVIDOR pelo nome do Domain Controller e ADMINISTRADOR por um usuário que tenha permissão de administrador ou pelo próprio mesmo.
Verificando se o Winbind está comunicando com o RPC Server:
# wbinfo -t
Retorno esperado: checking the trust secret via RPC calls succeeded
Listando usuários do AD:
# wbinfo -u
Listando os grupos do AD:
# wbinfo -g
Se não for esse o retorno, revise os passos acima.

Fonte: Desmonta&CIA

Anúncios

Tags:,

About Desmonta&CIA

Somos um blog que busca informar aos apaixonados por tecnologia tudo sobre o mundo de TI.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: