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

  • 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
  • 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-Droguet Aug 31 '18 at 7: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-Droguet Aug 31 '18 at 7:34
  • 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
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=*))

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.