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 = AdminsGroup@MYDOMAIN.GLOBAL
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 = LimitedGroup@MYDOMAIN.GLOBAL
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.)

  • 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? – roaima Aug 27 '18 at 17:57
  • 1
    Oops, you're right. Fixed typo. – dr01 Aug 28 '18 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. – dr01 Aug 28 '18 at 7:02
  • 2
    A similar question over on SF serverfault.com/q/928369/267016 might get you some possible answers – roaima Aug 28 '18 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. – dr01 Aug 31 '18 at 7:40
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.

  • 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. – dr01 Aug 31 '18 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-Droguet Aug 31 '18 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 :) – dr01 Aug 31 '18 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-Droguet Aug 31 '18 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. – dr01 Sep 4 '18 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 user@MYDOMAIN.GLOBAL, 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 = AdminsGroup@MYDOMAIN.GLOBAL
  • 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-Droguet Sep 4 '18 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-Droguet Sep 4 '18 at 6:53
  • I just tested and you're right, these 2 config lines are not needed. I'll update my answer. – dr01 Sep 4 '18 at 7:33
  • 1
    Cool. I think we have reached some mutual understanding of this configuration. Thank you for the bounty, too. – Christophe Drevet-Droguet Sep 4 '18 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.