Como integrar o SUSE Linux Enterprise 11 com o Windows Active Directory
09/04/2012 Deixe um comentário
Obtendo SUSE Enterprise Linux integrado com o Microsoft Active Directory é muito mais fácil do que parece.
Existem alguns pré-requisitos para atender antes:
- Samba cliente deve ser instalado.
- Pacotes de samba-winbind e krb5-client deve ser instalado.
- O servidor DNS primário deve ser o controlador de domínio.
Para esta tarefa, vamos utilizar YaST2, a ferramenta de configuração do SUSE.
YaST2 pode ser executado em gráfica …
… Ou em modo texto.
Eu decidi usar o modo de texto, uma vez que será de longe o caso de uso mais comum, de qualquer maneira em ambos os casos o procedimento é exatamente o mesmo.
Vai para a seção de Serviços de Rede e depois selecione Windows Participação no domínio. O domínio do Windows tela de configuração do Membership irá aparecer.
Na área de Membership digite o nome do domínio e configurar as opções que melhor se adequar ao seu ambiente, incluindo as outras seções da tela.
Eu configurá-lo para permitir SSH single sign-on, mais sobre isso mais tarde, e para criar um diretório home do usuário em seu primeiro login.
Você deve levar em conta a configuração NTP já que é um componente crítico de autenticação Active Directory.
Selecione OK para confirmar a sua selecção e um pequeno pop-up irá aparecer para informar que o host não faz parte do domínio e se você quiser participar.
Em seguida, você deve digitar a senha do administrador de domínio.
E, finalmente, YaST confirmar o sucesso da operação.
Neste ponto, a configuração básica é feito e que o servidor deve ser integrado no domínio do Windows.
Sob o capô, este processo alterou vários arquivos de configuração, de modo a obter o sistema pronto para autenticar contra o Active Directory:
- smb.conf
- krb5.conf
- nsswitch.conf
smb.conf
O primeiro é o arquivo de configuração do samba de serviço. Como você deve saber Samba é uma implementação open source do SMB / CIFS do Windows protocolo, que permite que sistemas Unix para integrar quase transparente em uma infra-estrutura de domínio do Windows e também fornece serviços de arquivo e impressão para clientes Windows.
O arquivo reside em / etc / samba. Dê uma olhada no conteúdo do arquivo, a parte relevante é a seção global.
[global] workgroup = VJLAB passdb backend = tdbsam printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User include = /etc/samba/dhcp.conf logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = No idmap gid = 10000-20000 idmap uid = 10000-20000 realm = VJLAB.LOCAL security = ADS template homedir = /home/%D/%U template shell = /bin/bash winbind refresh tickets = yes
krb5.confO krb5.conf é o arquivo de configuração do Kerberos daemon que contém as informações necessárias para a biblioteca Kerberos.
jreypo@sles11-01:/etc> cat krb5.conf
[libdefaults]
default_realm = VJLAB.LOCAL
clockskew = 300
[realms]
VJLAB.LOCAL = {
kdc = dc.vjlab.local
default_domain = vjlab.local
admin_server = dc.vjlab.local
}
[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON
[domain_realm]
.vjlab.local = VJLAB.LOCAL
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 1
}
jreypo@sles11-01:/etc>
nsswitch.conf
nsswitch.conf
O arquivo nsswitch.conf como afirma a sua página man é os bancos de dados do sistema eo nome do serviço de arquivo de configuração do Switch. Basicamente, ele inclui as diferentes bases de dados do sistema para procurar informações de autenticação quando o usuário tenta fazer logon no servidor.
Dê uma olhada rápida no arquivo e você verá os dois campos alterados, passwd e group. Em ambos a opção winbind foi adicionado a fim de indicar o sistema para usar o Winbind, o nome daemon Service Switch usado para resolver nomes de servidores NT.
passwd: compat winbind group: compat winbind
SSH single sign-on
Finalmente, precisamos testar a conexão SSH ao host usando uma conta de usuário do domínio. Quando perguntado sobre as credenciais de login utilizar o DOMAIN \ USER fórmula para o nome do usuário.
Esse tipo de integração é muito útil, especialmente para as lojas maiores, porque você não tem que manter a lista de usuários de seus servidores SLES individualmente, basta apenas a conta de raiz desde as outras contas pode ser gerenciado centralmente a partir do domínio do Windows.
No entanto, há uma questão que deve ser levado em conta, o sign-on único de autenticação SSH significa que qualquer pessoa com uma conta de domínio podem registrar em seus servidores Linux e não queremos isso.
Para evitar essa situação potencialmente perigosa que vão limitar o acesso apenas aos grupos de usuários que realmente necessitam. Eu vou usar os Domain Admins para lhe mostrar como.
Primeiro, precisamos olhar para o ID do grupo Domain Admins dentro da nossa caixa de Linux. Entrar como DOMAIN \ Administrator e use o comando ID para obter a informação do usuário.
VJLAB\administrator@sles11-01:~> id uid=10000(VJLAB\administrator) gid=10000(VJLAB\domain users) groups=10000(VJLAB\domain users),10001(VJLAB\schema admins),10002(VJLAB\domain admins),10003(VJLAB\enterprise admins),10004(VJLAB\group policy creator owners) VJLAB\administrator@sles11-01:~>
Existem vários IDs de grupo, para os nossos propósitos, precisamos da VJLAB \ domain admins que é 10002.
Você deve estar se perguntando, mas o GID não é 10002, mas 10 mil? Sim você está certo e por isso precisamos fazer algumas alterações a nível controlador de domínio.
Fogo até o Server Manager e vá para Funções -> Active Directory Domain Services –> Active Directory Users and Computers –> DOMAIN –> Users.
No painel à direita editar as propriedades da conta que você quer ser capaz de acessar o servidor linux via SSH. No meu caso eu usei o meu juanma conta própria. Na guia Membro de selecionar o grupo Domain Admins e clique em Definir Grupo Primário.
Agora precisamos modificar a forma como o daemon pam gerenciar a autenticação. Volte para o SLES e editar / etc / pam.d / sshd.
#%PAM-1.0 auth requisite pam_nologin.so auth include common-auth account include common-account password include common-password session required pam_loginuid.so session include common-session
Excluir a linha conta e adicionar as duas linhas seguintes.
account sufficient pam_localuser.so account sufficient pam_succeed_if.so gid = 10002
O arquivo sshd deve ficar assim:
#%PAM-1.0 auth requisite pam_nologin.so auth include common-auth account sufficient pam_localuser.so account sufficient pam_succeed_if.so gid = 10002 password include common-password session required pam_loginuid.so session include common-session
E estamos a fazer. Qualquer comentário seria sempre bem-vindas 
Fonte: jreypo
Licença: BSD
Download: FreeBSD-9.0-BETA2 
Homepage: 
)
