5

I'm trying to define different login shells for different users of an AD domain, as described here. The aim is to deny members of a particular group from logging in while allowing them to do SSH tunneling.

Here below is the file /etc/sssd/sssd.conf. MYDOMAIN.GLOBAL is the default domain provided by the AD. The config below defines a test domain MYDOMAIN_TEST.GLOBAL, which is not in the AD, as the domain for these limited users. (This is just a configuration for testing: later, in the MYDOMAIN_TEST.GLOBAL domain section, override_shell = /bin/zsh will be replaced by 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

A member of MYDOMAIN.GLOBAL is able to login via SSH, while a member of MYDOMAIN_TEST.GLOBAL can't and gets a "Permission denied, please try again" or a "Authentication failed" error.

The sssd logfiles don't show any error.

Why is that?

Does MYDOMAIN_TEST.GLOBAL need to be present in the AD? If yes, is it possible to somehow bypass this and configure sss with different "local categories" of users to do what I want?

(Note: Apparently this can be done with nlscd, as per this question and this other question, but it requires a LDAP server, and configuring it to use an AD is another can of worms.)

Improve this question
10
  • 2
    In the MYDOMAIN_TEST.GLOBAL definition block do you really intend to compare against groups within MYDOMAIN.GLOBAL rather than MYDOMAIN_TEST.GLOBAL? Similarly, does the ad.mydomain.global AD server really serve the MYDOMAIN_TEST.GLOBAL domain?
    – Chris Davies
    Aug 27, 2018 at 17:57
  • 1
    Oops, you're right. Fixed typo.
    – dr_
    Aug 28, 2018 at 6:59
  • 1
    The MYDOMAIN_TEST.GLOBAL does not exist in the AD, is only defined here in the SSS config. I'd like to know if this would work.
    – dr_
    Aug 28, 2018 at 7:02
  • 2
    A similar question over on SF serverfault.com/q/928369/267016 might get you some possible answers
    – Chris Davies
    Aug 28, 2018 at 20:09
  • 1
    @ChristopheDrevet-Droguet It's sssd 1.16.0-19.el7_5.5. By setting the user login shell to /sbin/nologin or /bin/false, the user can perform a SSH tunnel but not a SSH login, I've tested.
    – dr_
    Aug 31, 2018 at 7:40

2 Answers 2

Reset to default
3
+300

This should work with newer versions of 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

The ldap_user_search_base is used instead of the now deprecated (removed?) ldap_user_search_filter.

I don't know if adding a simple_allow_groups with a ldap_user_search_base filter is correct or not. I wonder if it would work with only a simple_allow_groups directive.

Improve this answer
5
  • I've tested, it does not work because [domain/MYDOMAIN_ADMINS] and [domain/MYDOMAIN_LIMITED] are defined in sssd only and not in the AD. A sssd section [domain/MYDOMAIN.GLOBAL] works because this matches the AD domain. But thanks for the effort.
    – dr_
    Aug 31, 2018 at 8:22
  • I respectfully disagree. The sssd domain name has nothing to do with the actual AD domain name. It's working for me with a brand new CentOS 7.5. I'll update my answer with my exact configuration.
    – Christophe Drevet
    Aug 31, 2018 at 13:41
  • What you say makes sense, however as a matter of fact this config does not work. I would be very happy if you prove me wrong, as my issue would then be solved :)
    – dr_
    Aug 31, 2018 at 14:25
  • I understand your frustration. There must be some other issue at stake. What happens if you bypass authentication entirely, by using su - auser with root? Do you have more info in the system authentification log?
    – Christophe Drevet
    Aug 31, 2018 at 15:31
  • 1
    Someone helped me in finding a solution, see my answer. I marked it as "accepted" for future readers because I verified it works for me, but I have rewarded your good answer with the bounty.
    – dr_
    Sep 4, 2018 at 7:53
3

Thanks to the sssd maintainers I found the answer. Here's a working config which does what I needed, i.e. allow SSH tunneling but not SSH login to the AD users which are members of the AD LimitedGroup.

Note that a member of the limited group must ssh as user@MYDOMAIN_TEST.GLOBAL, not as [email protected], or it won't work.

The gist of the solution is in using the SSSD section domain name instead of the AD domain name in the simple_allow_groups directive. Note, however, that the config also works without the lines access_provider = simple and simple_allow_groups = .... It is also possible to set simple_allow_groups = group without the use_fully_qualified_names = True directive, as reported by an user in the comments.

Also, note that this config uses ldap_user_search_base instead of the deprecated ldap_user_search_filter.

The other configuration options are only for completeness as they were already in the config file.

[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]
Improve this answer
4
  • I'm glad it works for you. I just don't understand why you have to add these simple access directives while I don't. I really use my actual answer in my environment.
    – Christophe Drevet
    Sep 4, 2018 at 6:30
  • It could be the use of access_provider = simple with simple_allow_groups = group@DOMAIN instead of simple_allow_groups = group (the latter seems to work for me) without the use_fully_qualified_names = True directive. I don't use access directives at all, as the ldap_user_search_base should just return the selected accounts anyway. Another thing: if you use use_fully_qualified_names = True, you must connect with ssh -l user@MYDOMAIN_TEST.GLOBAL myserver to use the right sssd domain, don't you? "If set to TRUE, all requests to this domain must use fully qualified names" tells man.
    – Christophe Drevet
    Sep 4, 2018 at 6:53
  • I just tested and you're right, these 2 config lines are not needed. I'll update my answer.
    – dr_
    Sep 4, 2018 at 7:33
  • 1
    Cool. I think we have reached some mutual understanding of this configuration. Thank you for the bounty, too.
    – Christophe Drevet
    Sep 4, 2018 at 11:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .