Configurando o shell de login na configuração do SSS para usuários do Active Directory

Question

Estou tentando definir diferentes shells de login para diferentes usuários de um domínio do AD, como descrito aqui . O objetivo é impedir que os membros de um determinado grupo efetuem login, permitindo que façam tunelamento SSH.

Aqui abaixo está o arquivo /etc/sssd/sssd.conf . MYDOMAIN.GLOBAL é o domínio padrão fornecido pelo AD. A configuração abaixo define um domínio de teste MYDOMAIN_TEST.GLOBAL, que não está no AD, como o domínio para esses usuários limitados. (Esta é apenas uma configuração para teste: mais tarde, na seção do domínio MYDOMAIN_TEST.GLOBAL, override_shell = /bin/zsh será substituído por override_shell = /sbin/nologin .)

[sssd]
domains = MYDOMAIN.GLOBAL,MYDOMAIN_TEST.GLOBAL
config_file_version = 2
services = nss, pam

[nss]
default_shell = /bin/bash

[domain/MYDOMAIN.GLOBAL]
ad_server = ad.mydomain.global
ad_domain = MYDOMAIN.GLOBAL
ldap_user_search_filter = (memberOf=CN=AdminsGroup,OU=Groups,DC=MYDOMAIN,DC=GLOBAL)
id_provider = ad
simple_allow_groups = [email protected]
override_shell = /bin/bash

[domain/MYDOMAIN_TEST.GLOBAL]
ad_server = ad.mydomain.global
ad_domain = MYDOMAIN.GLOBAL
ldap_user_search_filter = (memberOf=CN=LimitedGroup,OU=Groups,DC=MYDOMAIN,DC=GLOBAL)
id_provider = ad
simple_allow_groups = [email protected]
override_shell = /bin/zsh

Um membro do MYDOMAIN.GLOBAL pode efetuar login via SSH, enquanto um membro do MYDOMAIN_TEST.GLOBAL não pode e recebe um erro "Permissão negada, por favor, tente novamente" ou "Falha na autenticação".

Os arquivos de log sssd não mostram nenhum erro.

Por que isso?

O MYDOMAIN_TEST.GLOBAL precisa estar presente no AD? Se sim, é possível de alguma forma contornar isso e configurar sss com diferentes "categorias locais" de usuários para fazer o que eu quero?

(Nota: Aparentemente isso pode ser feito com nlscd, como por esta questão e esta outra pergunta , mas requer um servidor LDAP, e configurá-lo para usar um AD é outra lata de worms.)

    

Answer 1

Graças aos mantenedores do sssd , encontrei a resposta. Aqui está uma configuração de trabalho que faz o que eu precisava, ou seja, permitir o tunelamento SSH, mas não o login SSH para os usuários AD que são membros do AD LimitedGroup.

Observe que um membro do grupo limitado deve ssh como user@MYDOMAIN_TEST.GLOBAL , não como [email protected] ou não funcionará.

A essência da solução é usar o nome de domínio da seção SSSD em vez do nome de domínio do AD na diretiva simple_allow_groups . Observe, no entanto, que a configuração também funciona sem as linhas access_provider = simple e simple_allow_groups = ... . Também é possível definir simple_allow_groups = group sem a diretiva use_fully_qualified_names = True , conforme relatado por um usuário nos comentários.

Além disso, observe que essa configuração usa ldap_user_search_base em vez do ldap_user_search_filter preterido.

As outras opções de configuração são apenas para integridade, pois já estavam no arquivo de configuração.

[sssd]
domains = MYDOMAIN.GLOBAL,MYDOMAIN_TEST.GLOBAL
config_file_version = 2
services = nss, pam

[nss]
default_shell = /bin/bash

[domain/MYDOMAIN_TEST.GLOBAL]
ldap_user_search_base = DC=MYDOMAIN,DC=GLOBAL?subtree?(memberOf=CN=LimitedGroup,OU=Groups,DC=MYDOMAIN,DC=GLOBAL)
default_shell = /sbin/nologin
ad_server = ad.mydomain.global
ad_backup_server = ad2.mydomain.global
ad_domain = MYDOMAIN.GLOBAL
krb5_realm = MYDOMAIN.GLOBAL
realmd_tags = manages-system joined-with-adcli 
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = True
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = LimitedGroup@MYDOMAIN_TEST.GLOBAL

[domain/MYDOMAIN.GLOBAL]
ldap_user_search_base = DC=MYDOMAIN,DC=GLOBAL?subtree?(memberOf=CN=AdminsGroup,OU=Groups,DC=MYDOMAIN,DC=GLOBAL)
default_shell = /bin/bash
ad_server = ad.mydomain.global
ad_backup_server = ad2.mydomain.global
ad_domain = MYDOMAIN.GLOBAL
krb5_realm = MYDOMAIN.GLOBAL
realmd_tags = manages-system joined-with-adcli 
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = True
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = [email protected]

    

Answer 2

Isso deve funcionar com versões mais novas do sssd:

[sssd]
domains = MYDOMAIN_ADMINS,MYDOMAIN_LIMITED,MYDOMAIN_ALL
config_file_version = 2
services = nss, pam

[nss]
default_shell = /bin/bash

[domain/MYDOMAIN_ADMINS]
ad_server = srv001.company.local,srv002.company.local,srv003.company.local,srv004.company.local
ad_domain = company.local  
ldap_user_search_base = DC=company,DC=local?subtree?(memberOf=CN=unix_admins,OU=Groupes,OU=Main Office,DC=company,DC=local)
id_provider = ad
override_shell = /usr/bin/pwd
override_homedir = /home/%u

[domain/MYDOMAIN_LIMITED]
ad_server = srv001.company.local,srv002.company.local,srv003.company.local,srv004.company.local
ad_domain = company.local  
ldap_user_search_base = DC=company,DC=local?subtree?(memberOf=CN=unix_limited,OU=Groupes,OU=Main Office,DC=company,DC=local)
id_provider = ad
override_shell = /usr/bin/date
override_homedir = /home/%u

[domain/MYDOMAIN_ALL]
ad_server = srv001.company.local,srv002.company.local,srv003.company.local,srv004.company.local
ad_domain = company.local  
ldap_user_search_base = DC=company,DC=local
id_provider = ad
override_homedir = /home/%u

O ldap_user_search_base é usado em vez do agora obsoleto (removido?) ldap_user_search_filter .

Não sei se adicionar um filtro simple_allow_groups com ldap_user_search_base está correto ou não. Gostaria de saber se funcionaria apenas com uma diretiva simple_allow_groups .