All,
This is not a big deal -- just curious.
We have a commercial Linux AD integration product. In it, the incoming user's authorization to log in is validated during the PAM "authentication" phase. So if it's a legal AD user and good password, but that user is not authorized in -- you're returned to the "login name: / password:" prompt.
In sssd, it appears that validating if you're a legally-authorized user or in a legally-authorized group occurs in the PAM "account" phase. It's done by the "simple" access_provider.
Consider again a legal AD user and good password, but again -- that user is not authorized in.
Now that user name is accepted, that password is accepted, but then the server closes your putty session. You're not returned to a "login name: / password:" prompt.
Like I say -- not a big deal. Unauthorized users are intercepted and disallowed, just in different ways. Just curious if there's a way to make sssd fail in the former manner, instead of the latter.
Spike White
On Fri, Feb 15, 2019 at 09:02:44PM -0600, Spike White wrote:
All,
This is not a big deal -- just curious.
We have a commercial Linux AD integration product. In it, the incoming user's authorization to log in is validated during the PAM "authentication" phase. So if it's a legal AD user and good password, but that user is not authorized in -- you're returned to the "login name: / password:" prompt.
In sssd, it appears that validating if you're a legally-authorized user or in a legally-authorized group occurs in the PAM "account" phase. It's done by the "simple" access_provider.
Consider again a legal AD user and good password, but again -- that user is not authorized in.
Now that user name is accepted, that password is accepted, but then the server closes your putty session. You're not returned to a "login name: / password:" prompt.
Like I say -- not a big deal. Unauthorized users are intercepted and disallowed, just in different ways. Just curious if there's a way to make sssd fail in the former manner, instead of the latter.
No, I can't think of any, sorry. All the access checks are invoked from pam_sss's account module.
sssd-users@lists.fedorahosted.org