at the moment the services (aka responders) that SSSD starts must be listed
explicitly in the 'services' line in the [sssd] section of sssd.conf. For
services like PAM, NSS or even sudo, this is not too problematic, just
inconvenient and we have plans to socket-activate the responders:
I could swear we also had an option to get rid of the 'services' option
completely but I only found a ticket to get rid of the 'domains':
For the ifp service, we could do something similar as planned for domains
and take advantage of the bus-activation. Patches that bus-activate the
ifp responder are alrady on review:
But these patches only deal with the case where messagebus was started
We could take advantage of the socket-activation even sooner than we get
to implementing #2243. The proposal was:
- if 'services' are not specified, use the default list (nss, pam).
If a request arrived to the system bus, socket-activate ifp
- if 'services' were specified, treat that as a canonical list and
don't activate the ifp responder
But my opinion is that we have already quite a lot of work for 1.12 and we
should implement bus-activating the ifp responder together with the socket
activation in 1.13. But if any of the projects that use or plan to use our
DBus API would see adding the 'ifp' to the list of services as problematic,
we should reconsider #2242 for inclusion in 1.12.x
On a related note, the dbus responder is currently packaged in its own
subpackage that is not dragged in when the user yum installs the 'sssd'
meta-package. That's because the sssd-dbus subpackage has some additional
dependencies admins might not like to have installed by default. From
the point of view of users of our DBus service, is this expected and/or
acceptable? Or would it be more expected to have the whole lot after
installing the 'sssd' package?
ad_gpo_test is linked with library NDR_NBT, which is part of samba4.
Simple patch is attached.
BTW I saw in Noam's nfs patches he is using $(NULL) after the end of lists in
Makefile.am. I saw it also in other projects. Do we want to use this patter as
This is the last patch related to ticket
The warnings here are currently all false positives (refcount) or
the alignment is calculated during runtime with PADDING_SIZE macro
so this patch is just about silencing the compiler.
The patch is attached.
The attached patch adds support for gpo permissive mode. Specifically, if the ad_gpo_access_control option is set to "permissive" (which it is by default), and the gpo-based access control evaluation indicates that the user is denied access, then a syslog message is emitted indicating that the user would have been denied logon access if the option were set to "enforcing".
In order to simplify sending syslog messages to the security log (with or without journald), I have introduced a generic sss_log_ext function, which can be used with any syslog facility (including our standard "LOG_DAEMON" facility, as well as the security log "LOG_AUTHPRIV" facility).
This patch depends on a previously submitted patch ("Add initial gpo-smb implementation"), which has not yet been pushed to master.
The attached patch adds an initial gpo-smb implementation. It uses SMB to retrieve HBAC policy files, evaluate them, and enforce the whitelists and blacklists found in those policy files. This is an initial implementation and there are a few things that I am planning on implementing, but are not part of this patch.
This patch does not implement:
* the "permissive" mode, in which the policy files are evaluated, but not enforced
* a separate gpo_child process to make the blocking libsmbclient calls
* use of a cache
* few other things
As such, most of this patch will be moved to a separate gpo_child process in a subsequent patch.
Also note that some (but not all) of the changes that were pushed to master as part of my patch titled "add libsmbclient to makefiles" seem to have been deleted by subsequent pushes to master. As such, this patch reintroduces those changes (which only affect configure.ac and libsmbclient.m4).