☰

SSSD: Como forçar usuários em grupos diferentes a usar shells diferentes

tag-icon • tag-icon active-directory sssd
SSSD: Como forçar usuários em grupos diferentes a usar shells diferentes

Eu tenho um Active Directory funcionando como provedor de id, acesso e autenticação para meus servidores CentOS 7 usando sssd. Eu tenho acompanhado issopublicarpara que usuários de grupos diferentes usem shells diferentes ao fazer login, mas tenho alguns problemas. Aqui está meu sssd.confarquivo:

[sssd]
domains = dev, domain.local
config_file_version = 2
services = nss, pam

[nss]
default_shell = /bin/bash

[domain/dev]
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
ad_server = adserver.domain.local
id_provider = ad
access_provider = ad
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
override_shell = /bin/tcsh
ldap_user_search_base = cn=dev,ou=Security Groups,ou=Domain,dc=domain,dc=local #According to sssd-ldap man page ldap_user_search_filter is deprecated


[domain/domain.local]
ad_server = adserver.domain.local
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad


A idéia é que quando alguém do grupo de desenvolvimento fizer login, o shell seria tcsh e quando algum outro folk fizer login, ele usará o bash. O problema é que, com esta configuração, consigo fazer login com sucesso com Smith, membro do grupo dev e chega ao tcsh com sucesso, mas se eu fizer login com John, membro também do domínio, mas não membro do dev, acontece o seguinte :

  • Revendo, /var/log/securerecebo uma falha de autenticação primeiro do pam_unix e depois um sucesso do pam_sss
  • O primeiro usuário faz login como johne obtém seu shell como tcsh (mesmo que deva ser bash). Em segundo lugar, o usuário faz login como [email protected]e obtém bash. Terceiro, o usuário faz login novamente johne agora obtém o shell correto (bash)

Aparentemente, o sssd depois de verificar o segundo domínio com o FQDN ele armazena em cache o shell do usuário e no terceiro login ele faz tudo certo.
Qual é a configuração correta para logar cada usuário em seu shell correspondente?

ATUALIZAR:
Parece que às vezes o processo de login passa apenas pelos módulos pam e às vezes por políticas baseadas em GPO sssd retiradas do diretório ativo. Tentei desabilitar o filtro e reiniciar o sssd diversas vezes e em uma delas consegui isso no log:

Aug 28 15:42:43 co-proy-02 sssd[be[dev.domain.local]]: Warning: user would have been denied GPO-based logon access if the ad_gpo_access_control option were set to enforcing mode.

Com o filtro desabilitado, o usuário Smithdos devgrupos obtém o tcsh com sucesso, mas também o faz john. Com o filtro ativado, ambos obtêm o bash.

ATUALIZAÇÃO2
Aparentemente existe um pacote chamado sssd-toolsque possui um comando que permite substituir o shell de qualquer usuário separado, porém, depois de tentar esta solução ainda não obtive o resultado apropriado. Aqui está o comando, mas pelo menos para mim não está funcionando como deveria:
sss_override user-add smith -s /usr/bin/sh

Responder1

Depois de uma longa pesquisa e com a ajuda do @ChristopheDrevet-Droguet com o filtro ou=Domain,dc=domain,dc=local?subtree?(memberOf=cn=dev,ou=Security Groups,ou=Domain,dc=domain,dc=local)como base, só faltava uma árvore de objetos para analisar, quer dizer, na qual o usuário pudesse ser encontrado.
O sssd deve ter a seguinte aparência para que isso funcione (pelo menos para mim):

[sssd]
domains = dev, domain.local
config_file_version = 2
services = nss, pam

[nss]
default_shell = /bin/bash

[domain/dev]
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
ad_server = adserver.domain.local
id_provider = ad
access_provider = ad
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
override_shell = /bin/tcsh
ldap_user_search_base = dc=domain,dc=local??(&(memberOf=cn=dev,ou=Security Groups,ou=Domain,dc=veritran,dc=local)(objectClass=*))


[domain/domain.local]
ad_server = adserver.domain.local
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
ldap_user_search_base = dc=domain,dc=local??(&(memberOf=cn=other,ou=Security Groups,ou=Domain,dc=veritran,dc=local)(objectClass=*))

informação relacionada