Eu tenho gasto muitas, muitas horas felizes explorando a configuração sssd necessária para integrar o RHEL7 e o Active Directory. Uma grande parte deles incluiu a procura por muitos posts aqui na integração SSSD e AD, particularmente para fazer com pesquisas UID locais no AD. Embora estes tenham sido esclarecedores, nenhum parece cobrir meu cenário.
Meu problema no momento é que posso fazer o login via SSH usando um usuário do Windows ("DOMAIN1 \ sales1" usando a senha do usuário do Windows) e o SSSD validará o estado do usuário do Windows corretamente. Se o usuário do Windows estiver desativado ou a conta expirar, o login falhará - tudo como deveria ser.
Se eu fizer login via SSH usando um usuário linux com o mesmo id que o usuário do Windows ("sales1" usando a senha do usuário linux), o SSSD pesquisará e combinará o usuário do Windows no AD, mas NÃO validar a conta do AD. Eu apliquei o UID dos usuários do Linux ao atributo uidNumber do usuário do Windows para ajudar na correspondência do AD-linux, mas nada que tente parece influenciar a validação do estado do usuário do AD ao efetuar login usando as credenciais do usuário linux.
[sssd]
domains = domain1.local
config_file_version = 2
services = nss, pam
debug_level = 7
[domain/domain1.local]
ad_domain = domain1.local
krb5_realm = DOMAIN1.LOCAL
realmd_tags = manages-system joined-with-adcli
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
## We do NOT want offline caching of Windows authentications
cache_credentials = False
krb5_store_password_if_offline = False
## Found this ticket for sssd: https://fedorahosted.org/sssd/ticket/2851
## might be the GC lookup that is stopping expired users from being denied access
ad_enable_gc = False
ldap_id_mapping = False
override_homedir = /home/%u
default_shell = /bin/bash
debug_level = 8
passwd: files sss
shadow: files sss
group: files sss
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
netgroup: files sss
publickey: nisplus
automount: files
aliases: files nisplus
(conforme configurado pelo authconfig)
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth [default=1 success=ok] pam_localuser.so
auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
O que eu estou tentando alcançar é viável usando o SSSD?
Sou muito novo no sssd e o impacto da integração do AD em um sistema RHEL, então acho que minha abordagem para resolver meus requisitos está totalmente errada.
Eu tenho um servidor independente do RHEL rodando um aplicativo que usa a autenticação do usuário linux (passwd, shadow, groups). Recebi o requisito de validar os usuários do aplicativo no anúncio antes de permitir seu acesso ao aplicativo linux. A aplicação DEVE continuar a usar os IDs de usuário e grupo linux existentes, pois atualmente não é capaz de lidar com usuários de janelas longas ou com id de usuário com "@", e uma grande parte do comportamento de acl é construída no grupo existente.
Minha abordagem original (que levou à pergunta) foi usar sssd & realm para juntar o RHEL ao AD e depois (via pam / sssd) obter o login linux para encontrar um usuário correspondente do AD para o usuário linux, provavelmente usando atributos POSIX no usuário do windows, e validar sua conta do AD.
Eu acho que o que eu realmente preciso alcançar é o - Estabelecer um mapa / relacionamento entre um usuário AD e um usuário linux local que usa o aplicativo
Quando existe tal mapa / relacionamento:
- Apenas requer a senha do AD no login
- Validar o status de acesso da conta do AD (conta ativada / não expirada / direitos de logon do GPO / membro do grupo AD correto)
- Sempre use o nome de usuário local, uid e gid do usuário mapeado
Acho que usar o realm permit --groups [email protected] permitirá que eu restrinja os logons do usuário do AD a um grupo específico do AD (atualmente, não desejamos que os usuários do Windows façam login no linux, fora do caso de uso do aplicativo acima).
O que eu não tenho certeza é a melhor maneira de mapear os usuários do AD para os usuários linux existentes. Atualmente, o aplicativo cria e mantém as contas de usuário do Linux para que qualquer solução possa funcionar com isso.
Pelo que li nas últimas duas semanas, acho que minhas opções são:
- Use substituições locais SSSD para mapear entre usuários do AD e do Linux.
Eu não tenho experiência com isso, então estou contando com artigos como Substituições SSSD locais como indicadores de que isso é viável
- Confie nos atributos POSIX que estão sendo definidos no usuário do AD.
Isso implica que esses valores serão usados pelo usuário em TODOS os servidores aos quais eles se conectam e também referenciam os atributos POSIX. Não tenho certeza se isso é sensato a longo prazo. O teste mostrou que, com o uid, o uidNumber e o gidNumber definidos em um usuário do Windows, quando o usuário faz login no linux, usa esses valores. Isso impõe um esforço de manutenção para garantir que esses valores sejam definidos no usuário do AD.
- Instale o IPA e use visualizações de id.
Eu não tenho experiência com a instalação ou configuração, mas minha leitura indica que esta é uma opção possível. Parece haver custos adicionais de instalação, configuração e manutenção para usar essa opção.
Então, acho que agora preciso confirmar se essas são, de fato, as únicas opções, ou se há outras que não conheço, e das opções disponíveis que melhor se adequam à minha necessidade mínima de integração do AD.
Sim, está correto. De fato, é uma decisão de design do SSSD apenas se preocupar com os usuários que o próprio SSSD é capaz de servir (getent passwd -s sss $ someuser).
Se você quiser continuar usando usuários locais com senha remota (por que? sssd tem cache ...) você quer usar id_provider = proxy e um auth_provider remoto. Veja, por exemplo, minha postagem no blog sobre o assunto: link
Tags pam active-directory sssd redhat rhel7