In order to migrate from pam_ldap to sssd, I would need support for the authorizedService and host fields to limit access for certain users.
From pam_ldap(5):
pam_check_host_attr <yes|no> Specifies whether the "host" attribute should be checked for logon authorization ("account" in the PAM stack). The default is not to. If set to "yes" and a user has no value for the "host" attribute, then the user will be unable to login. pam_check_service_attr <yes|no> Specifies whether the "authorizedService" attribute should be checked for logon authorization ("account" in the PAM stack). The default is not to. If set to "yes" and a user has no value for the "authorizedService" attribute, then the user will be unable to login.
Behaviour is to compare machine hostname with "host" attributes and PAM service name with "authorizedService" attributes. "*" is interpreted as allowing all, haven't tested if there is full wildcard support.
Fields changed
type: defect => enhancement
{{{pam_check_host_attr}}} can be simulated right now in SSSD with the use of
access_provider = ldap ldap_access_filter = host=hostname.example.com
This will cause SSSD to check whether the user has an attribute {{{host}}} with the value {{{hostname.example.com}}}.
This is not identical to pam_check_host_attr as it does not currently auto-detect the current system's hostname - it needs to be set in the /etc/sssd/sssd.conf, but it provides the same behavior once properly set.
{{{pam_check_service_attr}}} is somewhat more complicated, and we do not have support for it at this time, so we'll use this ticket to track its addition.
Instead of behaving simply like the access_filter and just returning success if the search request succeeds, we'll need to request all {{{authorizedService}}} attributes from the user and then iterate through it on the client, only passing if they match. Probably we could support {{{authorizedService=}}} as a catch-all match, but I think we'll draw the line at supporting {{{authorizedService=su}}} to catch {{{su}}} vs {{{su-l}}}.
I've also opened tickey #671 to track making the HBAC provider available to all LDAP servers, not just IPA.
I got a bit bored and had a look at the pam_ldap code to get details about the implementation. This is what I found:
The local names to try for "host" is determined by calling gethostname() and feeding that into gethostbyname(). The names tried are are then h_name and all h_aliases. Normally this means both the FQDN as well as just the first portion.
It first looks for entries starting with '!' to indicate explicit denies.
Only '*' has special meaning. I.e. no generic wild card support.
milestone: NEEDS_TRIAGE => SSSD 1.6.0
milestone: SSSD 1.6.0 => SSSD 1.5.0 priority: major => minor
I have split these two tickets. Host support will be tracked in ticket #746.
coverity: => owner: somebody => sgallagh status: new => assigned summary: [enh] support authorizedService and host LDAP fields => [enh] support authorizedService LDAP attributes
Fixed by 2a2f642aae37e3f41cbbda162a74c2b946a4521f
component: SSSD => LDAP Provider resolution: => fixed status: assigned => closed tests: 0 => 1
Works like a charm. Tried various combinations of allows, denies and wildcard.
rhbz: => 0
Metadata Update from @ossman: - Issue assigned to sgallagh - Issue set to the milestone: SSSD 1.5.0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1712
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.