1

I have an Active Directory working as id, access and auth provider for my CentOS 7 servers using sssd. I have been following this post in order to have users from different groups use different shells as they login but I have some issues. Here is my sssd.conf file:

[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


The idea is when someone from dev group logins, the shell would be tcsh and when some other folk logins, it uses bash. The issue is, with this conf, I can login succesfully with Smith, a member of dev group and it gets to tcsh succesfully, but if I login with John, member also of the domain but not a member of dev, it happens the following:

  • Reviewing /var/log/secure I get an authentication failure first from pam_unix and then a success from pam_sss
  • First user logins as john and get its shell as tcsh (even though it should be bash).Second, user logins as john@domain.local and gets bash. Third, user logins again as john and now it gets correct shell (bash)

Apparently sssd after checking second domain with the FQDN it caches the user shell and on the third login it does it right.
Which is the correct configuration in order to login each user to its correspondent shell?

UPDATE:
It looks like sometimes the login process goes through pam modules alone and sometimes through sssd GPO-based policies taken from the active directory. I tried disabling the filter and restarting sssd several times and in one of those I got these in the 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.

With filter disabled user Smith from dev groups succesfully gets tcsh but also does john. With filter enabled both get bash.

UPDATE2
Apparently there is a package named sssd-tools which has a command that would let you override the shell of any separate user, however, after trying this solution I still doesn't get appropiate result. Here is the command, but at least for me, it's not working as it should:
sss_override user-add smith -s /usr/bin/sh

Edgar Sampere
  • 75
  • 1
  • 8
  • I don't see how you distinguish the two domains... The link to the other question uses ldap_user_search_filter to distinguish the groups of users and you don't. – Tomek Aug 28 '18 at 19:03
  • You're right. I'm not using the filter because even without it, it falls in dev domain. So the logic is not exclusive, I mean, it does not goes to the second domain as "the others" domain, but it falls in the first it finds. Let's try this, I'm including the filter which I have just tried and the result's the same. – Edgar Sampere Aug 28 '18 at 19:14
  • Clear sssd cache after making any config changes. You probably are still using cached entry. Also - is `john` user a member of `dev` group? – Tomek Aug 28 '18 at 19:44
  • No, `john` doesn't belong to `dev` group but I discovered something interesting. In the `[domain/dev]` entry, it should be `[domain/dev.domain.local]` instead. This combined with the `ldap_user_search_base` filter seems to work and as you say, it had some cache leftovers. However, I also discovered that, if you have the filter but group is without the domain in its respective section, it happens either I get bash in both logins or sh in both – Edgar Sampere Aug 28 '18 at 20:12
  • Actually it gets weirder. After restarting sssd i started getting bash for Smith even tough it should get tcsh. If I comment the filter, delete cache and restart Smith gets correct tcsh shell and john also gets tcsh. Then delete cache and restart sssd and now John get tcsh and Smith gets bash, as it should ideally be – Edgar Sampere Aug 28 '18 at 20:34
  • 1
    Use `ou=Domain,dc=domain,dc=local?subtree?(cn=dev,ou=Security Groups,ou=Domain,dc=domain,dc=local)` for `ldap_user_search_base`. The domain name specified in `[domain/...]` can be anything. It's just internal reference for sssd. – Christophe Drevet Aug 31 '18 at 07:10
  • 1
    Actually, it should be: `ou=Domain,dc=domain,dc=local?subtree?(memberOf=cn=dev,ou=Security Groups,ou=Domain,dc=domain,dc=local)` – Christophe Drevet Aug 31 '18 at 07:34
  • The downside of sss_override is that you need to execute it for each new user. My method was working for any new member of the group, without manual action on the GNU/Linux server(s). – Christophe Drevet Aug 31 '18 at 14:01
  • 1
    Ey @ChristopheDrevet-Droguet! Thanks for the start point. Tried the filter but didn't worked out and as you pointed, the domain name in `[domain/...]` is just a placeholder. With you help I found the right filter which was: `ldap_user_search_base = dc=domain,dc=local??(&(memberOf=cn=dev,ou=Security Groups,ou=Domain,dc=veritran,dc=local)(objectClass=*))` – Edgar Sampere Aug 31 '18 at 16:01
  • So you succeeded? That's good to hear. Congrats. – Christophe Drevet Aug 31 '18 at 16:03
  • Yeah! Thanks, what mas missing was de last objectClass clausule to parse all the subobjects of the query. What I still fail to understand why does the '&' is necessary – Edgar Sampere Aug 31 '18 at 16:05

1 Answers1

0

After a long search and with the help of @ChristopheDrevet-Droguet with the filter ou=Domain,dc=domain,dc=local?subtree?(memberOf=cn=dev,ou=Security Groups,ou=Domain,dc=domain,dc=local) as a base, the only thing missing was a tree of objects to parse, I mean, in which the user could be found.
The sssd should look like the following in order for this to work (at least for me):

[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=*))
Edgar Sampere
  • 75
  • 1
  • 8