Redhat – Should SSSD perform AD access validation for matching local users

active-directorypamredhatrhel7sssd

I have been spending many, many happy hours exploring the sssd configuration needed to integrate RHEL7 and Active Directory. A large portion of those have included looking through the many posts here on SSSD and AD integration, particularly to do with local UID lookups in AD. Whilst these have been enlightening, none seem to cover my scenario.

My problem at present is that I can login via SSH using a windows user ("DOMAIN1\sales1" using the windows user's password) and SSSD will validate the state of the windows user correctly. If the windows user is disabled, or the account is expired, the login fails – all as it should be.

If I login via SSH using a linux user with the same id as the windows user ("sales1" using the linux user's password) SSSD will lookup and match the windows user in AD but will NOT validate the AD account. I have applied the linux users UID to the uidNumber attribute of the windows user in order to help the AD-linux user match, but nothing I try seems to influence the AD user state validation when logging in using linux user credentials.

sssd.conf

[sssd]
domains = domain1.local
config_file_version = 2
services = nss, pam
debug_level = 7


[domain/domain1.local]
ad_domain = domain1.local
krb5_realm = DOMAIN1.LOCAL
realmd_tags = manages-system joined-with-adcli 

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

## We do NOT want offline caching of Windows authentications
cache_credentials = False
krb5_store_password_if_offline = False

## Found this ticket for sssd: https://fedorahosted.org/sssd/ticket/2851
## might be the GC lookup that is stopping expired users from being denied access
ad_enable_gc = False
ldap_id_mapping = False
override_homedir = /home/%u
default_shell = /bin/bash
debug_level = 8

nsswitch.conf

passwd:     files sss
shadow:     files sss
group:      files sss
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
netgroup:   files sss
publickey:  nisplus
automount:  files
aliases:    files nisplus

pam.d/password-auth-ac

(as configured by authconfig)

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

Is what I am attempting to achieve at all viable using SSSD?

Edit #1

I am very new to sssd and the impact of the AD integration on a RHEL system, so I think my approach to solving my requirements is all wrong.

I have an existing RHEL stand-alone server running an application that uses the linux user authentication (passwd, shadow, groups). I have been given the requirement to validate application users within ad prior to allowing their access to the linux application. The application MUST continue to use existing linux user and group ids as it is not currently capable of dealing with either long windows users or user id with "@", and a large portion of the acl behaviour is built on the existing group.

My original approach (which lead to the asking of this question) was to use sssd & realm to join RHEL to AD and then (via pam/sssd ) get the linux login to find a matching AD user for the linux user, most likely using POSIX attributes on the windows user, and validate their AD account.

I think what I actually need to achieve is
– Establish a map/relationship between an AD user and a local linux user that uses the application

When such a map/relationship exists:
– Only require the AD password at login
– Validate the AD account access status (account enabled/not expired/GPO logon rights/member of the right AD group)
– Always use the local username, uid, and gid of the mapped user

I think using the realm permit --groups adgroup@dlomain.ad will allow me to restrict AD user logins to a specific AD group (we do not currently want to have windows users logging into linux, outside of the above application use case).
What I am not sure about is the best way to map AD users to existing linux users. The application currently creates and maintains the linux user accounts so any solution needs to be able to work with this.

From what I have read over the past 2 weeks, I think my options are:
– Use SSSD local overrides to map between AD and linux users.
I have no experience with this so am relying on articles like SSSD Local overrides as indicators that this is viable
– Rely on POSIX attributes being defined on the AD user.
This does imply that these values will be used by the user on EVERY server they connect to that also references the POSIX attributes. I'm not sure if this is sensible in the long term. Testing has shown that with the uid, uidNumber, and gidNumber defined on a windows user when the user logs in linux uses these values. This does impose a maintenance effort to ensure these values are defined on the AD user.
– Install IPA and use id views.
I have no experience with installing or setting this up, but my reading indicates this is a possible option. There does seem to be additional installation, configuration and maintenance costs for using this option.

So I think I now need to confirm if these are indeed the only options, or if there are others I am not aware of, and of the available options which is best suited to my minimal AD integration need.

Best Answer

Yes, it's correct. As a matter of fact, it's a design decision of SSSD to only care about users that SSSD itself is able to serve (getent passwd -s sss $someuser).

If you want to keep using local users with remote password (why though? sssd has caching..) you want to use id_provider=proxy and a remote auth_provider. See for example my blog post on the topic: https://jhrozek.wordpress.com/2015/07/17/get-rid-of-calling-manually-calling-kinit-with-sssds-help/

Related Solutions

Redhat – passwd for ldap users

Are you using Kerberos or Samba winbind at all? Or are you just trying straight LDAP?

If the latter, your /etc/ldap.conf file should have a series of 'pam_*' parameters that seem to be missing. In particular 'pam_password ad' is necessary to specify ADSI as the password change protocol. You may also need 'pam_login_attribute sAMAccountName' (+ others)

Personally I've always just bound the Linux machine using winbind, then changing passwords is as done with 'net ads password'

Linux (Ubuntu vs CentOS) LDAP Client for 389-ds – password policy

I have been playing around with 389-ds on Ubuntu for a work project and came across the exact same issue.

I'm not sure about copying the config over from CentOS - I didn't have a box handy.

But when I looked and read up on PAM, it turned out to all be in the file /etc/pam.d/common-account.

pam_unix.so was above pam_ldap.so, and it also had [success=2 default=ignore], which means if it succeeds skip the next two rules, and for anything else, ignore the line.

Now since LDAP accounts are valid UNIX accounts since we added ldap to /etc/nsswitch.conf, this rule will return success and the pam_ldap.so module will never get run.

To get around this, my /etc/pam.d/common-account now looks like this:

# here are the per-package modules (the "Primary" block)
account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet
account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet
account [success=2 user_unknown=ignore default=ok]      pam_ldap.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

As you can see, I've also added some rules in there to only allow users in either the LDAP group "auth-access", or system users with a UID below 500 to be seen as valid accounts.

And to explain a little:

We hit the first rule

account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet

Which succeeds if the user is in that group and if so, we skip the next line as we know that'll fail (they're a valid LDAP user, so they won't have a system UID below 500) - if it doesn't succeed, return a fail (bad).

Then the next rule if it wasn't skipped

account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet

So if this on succeeds (because the UID is below 500), reset the fail value set by the module above, because they won't be part of that LDAP group.

And the important part

account [success=2 user_unknown=ignore default=ok]      pam_ldap.so

Check the LDAP server for the account status - if it succeeds, we know an LDAP user is a valid UNIX user, so go ahead and skip the next two lines (to take us to pam_permit.so and let the user login). If the user is unknown to the LDAP server, ignore this line and move to the next one - and for all other statuses, "ok" means it's ok to pass those return codes as-is, which will pass things like password expired, etc.

And then:

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so

We weren't a valid LDAP user if we hit this rule, so check if we're a valid system user - if succeed, skip next 1 line (takes us to pam_permit.so). Otherwise, ignore, which will take us to pam_deny.so.

Hope that helps explain a little more - the document that helped me if I wasn't very easy to understand was: http://uw714doc.sco.com/en/SEC_pam/pam-4.html

Regards, iamacarpet