as requested by an important downstream, we need to do a release
release. I created a Release Notes page:
and moved the rest of the tickets we're definitely not fix in time to a
new milestone 1.12.3
We need to push Sumit's views patchset and my simple man page patch. It
would be nice to push Pavel's reconnection patches, although 1.12.3
would be fine, too, I guess.
I'll be glad for any corrections of the wiki page. Also, if there are
any pending patches that need to make it to 1.12.2, please reply with
a request for review.
this patch adds support for the new extdom plugin version as described on
I will send the server side updates to the freeipa-devel list soon.
Nevertheless it would be nice if these changes can already be tested
against the old version to avoid regressions.
I have prepared a wiki page summarizing the discussion that happened
previously on this list:
Here is the wiki page:
For your convenience, I copied the design page text below verbatim.
Does that reflect the discussion accurately?
Provided it does...
Daniel, based on the contents of the page, do you which parts of SSSD
need to be touched? I was wondering if we could help with some of the
three subtasks. For example adding a new option requires touching
several places such as the man pages or the python configAPI. Could we
maybe create a skeleton that just loads the option for you?
Please note I'm not trying to take over the feature from you, your
contribution is really welcome. It's just that some parts of the SSSD
development process, such as adding a new option are not documented
anywhere and might be difficult to find for a newcomer. And we would
like to get this feature merged sooner rather than later..
See the full design page text below:
= Restricting the domains a PAM service can auth against =
=== Problem statement ===
Some environments require that different PAM applications can use
a different set of SSSD domains. An example might be a system where,
depending on which VPN PAM service you log with, you authenticate against
a different set of remote servers. The legacy PAM modules were able to
use a different configuration file altogether as a parameter for the PAM
module. This wiki page describes a similar feature for the SSSD.
=== Overview of the solution ===
On the PAM client side, the PAM module should receive a new option that
specifies the SSSD domains to authenticate against. However, the SSSD
daemon can't fully trust all PAM services. We can't rely on the PAM service
fields either, as the data the PAM client sends to the PAM application can
be faked by the client, especially by users who posses shell access or can
start custom applications. Instead, there needs to be a list of users who
we trust. Typically, this would be a list of users who run the PAM aware
applications we wish to restrict (such as `vsftpd` or `openvpn`). This list
would default to `root` only.
These trusted users would be allowed to authenticate against any domain
and would also be able to restrict the domains further using a new pam_sss
option. For the untrusted users, we need to keep a list of domains allowed
to authenticate against, too. Since by default there are no restrictions
on the allowed domains, this list would default to "all domains are allowed".
=== Implementation details ===
This section breaks down the Overview of the solution into consumable pieces.
==== Add a new option `pam_trusted_users` ====
A new option must be added to the PAM responder. This option will be a list
of numerical UIDs or user names that are trusted. This list will be parsed
during PAM responder initialization (`pam_process_init` call) using the
`csv_string_to_uid_array` function and stored in the PAM responder context
(`struct pam_ctx`). The PAC responder does pretty much the same in the
In the responder, we already have the credentials of the client stored in
the `cli_ctx` structure. When a new request comes into the `pam_forwarder`
function, we will match the client UID against the list of trusted IDs and
determine whether the client is trusted or not.
==== Add a option to limit the domains for untrusted users ====
Another option, called `pam_allowed_auth_domains` shall be
added. This option will list the SSSD domains an untrusted client can
authenticate against. The option will accept either a comma-separated
list of SSSD domains or any of two special values "all" and "none". The
default value will be "all" in order to keep the current behaviour where
any client can authenticate against any domain.
The option will be parsed during `pam_process_init` and stored in the
`pam_ctx` structure. An untrusted client will only be allowed to send a
request to a domain that matches the list of allowed domains.
In order to keep the implementation simple, the `allow` keyword would
copy all domain names into `pam_ctx` and the `none` keyword would set the
variable holding the names to NULL. Then the check would be a simple loop
for all cases.
Care must be taken to ensure a sensible PAM error code for cases where
the domain wouldn't match.
==== Add a new pam module option to limit the domains ====
The PAM module will gain a new option, called `domains` that will allow the
administrator to use a list of domains to authenticate this PAM service
against. In the PAM responder, this option will only be in effect for
trusted clients. If the client is trusted, only domains listed in this
PAM option will be considered for authentication.
Please note that a patch implementing most of the functionality of this
PAM module option was contributed to the sssd-devel mailing list by Daniel
==== Password Changes ====
Password changes should be allowed against all domains.
=== How To Test ===
1. Prepare an SSSD installation with at least two domains A and B.
1. Pick a PAM service that is running by a trusted user. One example might be VPN service ran by the openvpn user or similar. Add this user as a value of `pam_trusted_users` option in the `[pam]` section.
1. Add one of the domains (domain A) as a `domain=` parameter into the `auth` section of your service's PAM config file
1. Edit `sssd.conf` and set `pam_allowed_auth_domains = none`.
1. Authenticate using the selected PAM service as a user from domain A. The authentication should succeed.
1. Authenticate using the same service as a user from domain B. The authentication should fail and there should be a reasonable (ie not System Error) return code returned to the application
1. Authenticate using a different PAM service. Make sure this service is ran by an untrusted user (not root!). Logins against both A and B should fail.
1. Change the value of `pam_allowed_auth_domains` to A. Login against A should succeed from a service running as untrusted user.
1. Change the value of `pam_allowed_auth_domains` to all. Login against both domains should succeed from a service running as untrusted user.
1. Remove the `domains=` option from the PAM config file. The trusted service should now be able to log in against both SSSD domains.
=== Authors ===
* Daniel Gollub <dgollub(a)brocade.com>
* Jakub Hrozek <jhrozek(a)redhat.com>
* Simo Sorce <simo(a)redhat.com>
-----BEGIN PGP SIGNED MESSAGE-----
We were assuming that the ad_hostname value would match the
sAMAccountName attribute, but in practice this was almost never the
case on a properly-configured system.
Microsoft's convention is that the sAMAccountName is always the
portion of the FQDN before the first dot, so this patch makes that
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----