☰

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

tag-icon • tag-icon active-directory domain sssd
Configurando o shell de login na configuração SSS para usuários do Active Directory

Estou tentando definir diferentes shells de login para diferentes usuários de um domínio AD,como descrito aqui. O objetivo é impedir que membros de um grupo específico façam login e, ao mesmo tempo, permitir que eles 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 domínio para esses usuários limitados. (Esta é apenas uma configuração para teste: posteriormente, na seção do domínio MYDOMAIN_TEST.GLOBAL, override_shell = /bin/zshserá 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 de MYDOMAIN.GLOBAL consegue fazer login via SSH, enquanto um membro de MYDOMAIN_TEST.GLOBAL não consegue e recebe um erro "Permissão negada, tente novamente" ou "Falha na autenticação".

Os sssdarquivos de log não mostram nenhum erro.

Por que é que?

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

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

Responder1

Isso deve funcionar com versões mais recentes 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 simple_allow_groupsfiltro ldap_user_search_baseestá correto ou não. Eu me pergunto se funcionaria apenas com uma simple_allow_groupsdiretiva.

Responder2

Graças aomantenedores sssdEu encontrei a resposta. Aqui está uma configuração funcional que faz o que eu precisava, ou seja, permite o tunelamento SSH, mas não o login SSH para os usuários do AD que são membros do AD LimitedGroup.

Observe que um membro do grupo limitado deve usar 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 AD na simple_allow_groupsdiretiva. Observe, entretanto, que a configuração também funciona sem as linhas access_provider = simplee simple_allow_groups = .... Também é possível configurar simple_allow_groups = groupsem a use_fully_qualified_names = Truediretiva, conforme relatado por um usuário nos comentários.

Além disso, observe que esta configuração usa ldap_user_search_baseem vez do obsoleto ldap_user_search_filter.

As outras opções de configuração são apenas completas, 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]

informação relacionada