Quão prático é autenticar um servidor Linux contra o AD?

Utilizamos os servidores Windows e Linux em nossa empresa de desenvolvimento de software.

Um dos pontos de atrito com essa configuração é que não temos uma solução de logon único. Sendo mais uma loja Microsoft do que uma loja Linux, queremos nos autenticar no AD.

Li alguns artigos on-line e entendo que isso é possível.

Atualmente, estamos usando os seguintes serviços no Linux que requerem autenticação:
- servidor git (por SSH)
- Sendmail
- servidor web Apache atualmente usando arquivos .htaccess.
- compartilhamentos de arquivos SAMBA

O que eu quero saber é quão prático é esse tipo de configuração? Realmente funciona ou é propenso a erros?

Não é difícil e é perfeitamente prático.

Temos algumas centenas de máquinas de desktop de inicialização dupla que usam autenticação do AD, bem como vários servidores que usam a autenticação do AD para permitir que clientes do Windows usem seus compartilhamentos de samba sem autenticação explícita dos usuários.

Havia outro artigo no SF sobre o que você precisa fazer.

Basicamente, você precisa configurar o kerberos, winbind, nss e pam.

Então você faz um kinite um net ads joine você está pronto.

Você pode configurar o pam para usar vários métodos de autenticação, se desejar, portanto, se um não funcionar, ele voltará para o próximo.

Geralmente usamos arquivos, winbindd e ldap para servidores que servem compartilhamento de arquivos para servidores Windows.

Se possível, eu usaria LDAP para informações da conta e windbind estritamente para auth, mas acredito que você pode mapear atributos em /etc/ldap.conf, se necessário. Se você acabar usando o winbindd para obter informações da conta, é possível usar o RID (método de hash) para gerar uids / gids, mas também é possível usar outros métodos. Usamos RIDs em um servidor de arquivos grande e isso foi um grande problema, então eu tentaria explorar uma das outras opções, se possível. No nosso caso, todos os usuários e grupos do AD são refletidos no LDAP por um sistema IDM upstream; portanto, usamos o LDAP para obter informações da conta em servidores mais recentes e o winbind apenas para autenticação.

A autenticação é absolutamente simples usando o Likewise Open. http://www.likewise.com/products/likewise_open/index.php

Quase toda a minha infraestrutura Linux centralizou a autenticação e o gerenciamento de usuários, graças ao Likewise Open. É incrivelmente simples de instalar e implementar. Eu não posso dizer o suficiente sobre isso.

Como observação, os UIDs e os GIDs são atribuídos de acordo com uma função de hash; portanto, eles são idênticos em toda a infraestrutura, para que as montagens do NFS funcionem perfeitamente.

Instalei o Windows Services for Unix e adicionei um usuário no AD chamado "Unix Authenticator" e, em seguida, fiz as seguintes alterações no arquivo de configuração nas máquinas linux:

host ldap.<foo>.com
base cn=Users,dc=<foo>,dc=com
binddn cn=Unix Authenticator,cn=Users,dc=<foo>,dc=com
bindpw <password>
nss_base_passwd cn=Users,dc=<foo>,dc=com?sub
nss_base_shadow cn=Users,dc=<foo>,dc=com?sub
nss_base_group cn=Users,dc=<foo>,dc=com?sub
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_objectclass posixGroup Group
nss_map_attribute cn msSFUName
nss_map_attribute uid msSFUName
nss_map_attribute gid gidNumber
nss_map_attribute gecos sAMAccountName
nss_map_attribute homeDirectory msSFUHomeDirectory
nss_map_attribute uniqueMember Member
pam_login_attribute msSFUName
pam_filter objectclass=user
pam_password ad

<password>

passwd: compat ldap
shadow: compat ldap
group: compat ldap

host files dns

auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so

account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix.so

password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok
password sufficient /lib/security/pam_ldap.so use_first_pass use_authtok
password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so

Espero que isto ajude.

Usuários do Windows conseguiram autenticação no AD, mas a maioria dos nossos servidores (unidade pública etc.) é Linux e faz parte do domínio. De uma janela PoV ninguém percebe. Do meu lado, parece um pouco frutado ssh'ing com o nome de usuário do meu Windows, mas é sobre o tamanho dele.

Apenas usando samba velho e simples.

Você não precisa usar o Samba, o AD suporta Kerberos e LDAP diretamente. Não há motivo para você usar qualquer software externo na maioria das distribuições.

Para o Debian / Ubuntu, você pode fazer isso com libnss-ldap e libpam-krb5. Existem alguns truques para obtê-lo 100%. Isso pressupõe que você tenha "unixHomeDirectory" preenchido para usuários do Linux, suas caixas Linux estejam usando o NTP comum com seus sistemas Windows (exigido pelo Kerberos) e que você esteja bem com pesquisas em NSS em texto sem formatação (não senha, mas informações de associação ao grupo etc. - você também pode use TLS, mas isso é mais complicado de configurar). Você NÃO deve ter o pam_ldap como uma senha ou fonte de autenticação no PAM, a menos que esteja configurado para usar o TLS.

/etc/ldap.conf

# LDAP Configuration for libnss-ldap and libpam-ldap.
# Permit host to continue boot process with out contacting LDAP server
bind_policy soft
# Define LDAP servers to use for queries, these must be Global Catalog servers
uri ldap://ldap.site.company.local
# Define root search location for queries
base dc=company,dc=local
#debug 1
# LDAP version, almost always going to be v3, it is quite mature
ldap_version 3
# Username used to proxy authentication. You can have this in a separate file owned by root for security OR use TLS/SSL (see man page)
# Do NOT use LDAP for authentication if you are using plain text binds, use Kerberos instead (and LDAP for authorization only). See libpam-krb5.
binddn cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
# Password for proxy acct
bindpw SooperSekeretPazzwerd
#  TCP port to perform queries on, 3268 is a Global Catalog port which will reply for all users in *.company.local
port 3268
# Search range scope (sub = all)
scope sub
# Tell the client to close TCP connctions after 30 seconds, Windows will do this on the server side anyways, this will prevent errors from showing up in the logs.
 idle_timelimit 30
# Expect queries for group membership to return DN for group members instead of usernames (lets you use MSAD group membership seamlessly)
nss_schema rfc2307bis
# Filters - User accounts must have a UID >= 2000 to be recognized in this configuration and must have a unixHomeDirectory defined.
nss_base_group dc=company,dc=local?sub?&(objectClass=group)(gidNumber=*)
nss_base_user dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
nss_base_shadow dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
# Object Class mappings.  You may want to have the posixAccount to map to "mail" and have users login with their email addresses, i.e.  "nss_map_objectclass posixAccount mail".
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
# Attribute mappings.
nss_map_attribute uniqueMember member
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
# Attribute in LDAP to query to match the username used by PAM for authentication
pam_login_attribute sAMAccountName
# Filter for objects which are allowed to login via PAM
pam_filter objectclass=User

Não é necessário editar o arquivo /etc/krb5.conf, supondo que suas caixas Linux estejam usando servidores DNS que conhecem o AD (as zonas _msdcs com os registros SRV apropriados são resolvíveis)

O arquivo /etc/nsswitch.conf deve ter "arquivos ldap" para usuários, grupos e sombra.

Para o Red Hat usando SSSD:

/etc/sssd/sssd.conf

[domain/AD]
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_uri = ldap://ldap.company.local:3268/
ldap_search_base = dc=company,dc=com
ldap_default_bind_dn = cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
ldap_default_authtok = SooperSekeretPazzwerd
ldap_schema = rfc2307bis
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
enumerate = true
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

ldap_id_use_start_tls = False
cache_credentials = True
krb5_realm = SITE.COMPANY.COM
case_sensitive = false
[sssd]
services = nss, pam
config_file_version = 2

domains = AD
[nss]
filter_users = root,named,avahi,nscd