I'd like to continue the discussion of tlog integration, and also present you
the first release of tlog - a development preview, which has the configuration
interface necessary to implement the integration:
You're more than welcome to download RPMs, install, read tlog-rec(8) and
tlog-rec.conf(5), and experiment! Building from the Git tree and the tarball
works as well, if you're so inclined. I'm also attaching those manpages for
Here are the integration plans so far, as discussed with Jakub on our
devconf.cz trip meetings and before on the list. Jakub, please correct me or
* We follow the route similar to that taken by SELinux rule control
implementation . I.e. store the configuration in LDAP HBAC rules,
write to files on the client side and then specify them to tlog upon user
However, I'm also rather fond of the idea of specifying the whole
configuration through an environment variable instead of through a file
referenced by an environment variable - it's not big at all, and we'll avoid
the hassle of managing the files.
I implemented support for both in tlog (was easy).
* We'll have to make nss_sss report user's shell as tlog-rec (how?) and
specify the actual shell to tlog-rec via an environment variable, through
pam_sss (with SSS_PAM_ENV_ITEM messages). I.e.:
* Nss_sss would always report tlog-rec as the user's shell.
* During login (e.g. through "login" or "sshd") pam_sss would add a variable
to the user environment, containing, or pointing at, a tlog-rec
configuration (TLOG_REC_CONF_TEXT or TLOG_REC_CONF_FILE). That
configuration would contain the user's actual shell. I can also implement
support for a separate variable just for the shell (TLOG_REC_SHELL?) to
simplify the implementation for the start.
* Tlog-rec would read the system-wide configuration and overlay it with the
one specified in the environment, adding the specific user shell, and then
would spawn it.
Please also see the draft integration design page  for reference.
I hope to refine and extend it in the coming weeks to match FreeIPA standards.
Please chime in and suggest, object, discuss!
Also, please report tlog bugs at https://github.com/spbnick/tlog/issues
the attached patches implement unit tests for the pam_sss module using
pam_wrapper and libpamtest. In my testing, the coverage is around 75%
with mostly the parts that require running as root being untested.
I worked on this patchset even though the features for 1.14 are in full
swing because there are several tickets that will require us to patch
pam_sss, so it's important to have the code that changes tested. In
addition, when we merge Dan's patches to use TLS with integration tests,
then we'll be able to also test authentication in integration tests
easily using libpamtest-python.
However, our CI fails for me constantly:
The strange thing is that running CI locally works fine and so does make
check. Can anyone help point me in the right direction as to what should
I check next? I suspect some of the environment variables might not be
set correctly, but I don't see why..
I wanted to split include/debug_levels.xml into more files so we don't
duplicate information, but I didn't figure out how to use xi:include in
files that are already beeing included. I always managed to fail on dtd
validation. Maybe someone more familiar with docbook may chime in.
the following 3 patches are related to the Smartcard authentication
feature but imo can be tested even without having one.
The first patch just adds some missing pieces. The second adds a new
'no_verification' switch to the 'certificate_verification' option, which
is already tested by the unit tests.
The third adds two new OCSP related switches. With OCSP a certificate
can be validates online by talking to a server which is listed in the
certificate. Of course it might not always be possible to directly talk
to this server. We already have the 'no_ocsp' switch to disable OCSP
completely. The two new switches allow SSSD to talk to a different
server or a proxy. To see how it is working you can do to following:
- call 'make check' to build and rung all the tests
- call './pam-srv-tests' to run the PAM responder tests but do not let
it complete but stop it with CTRL-C. This is needed to create the test
nss database in /dev/shm/tp_pam_srv_tests-test_pam_srv/, it can be
created differently but this way it is most easy :-)
- add a OCSP signing cert with
the NSS library call check this certificate first before trying to connect to
the OCSP responder, so a valid one with the right key usage must be added to
make NSS try to reach the new OCSP responder
strace -s 128 -f -esend .libs/lt-p11_child --debug-microseconds=1 --debug-timestamps=1 --debug-to-stderr --debug-level=10 --pre --nssdb sql:/dev/shm/tp_pam_srv_tests-test_pam_srv
where you should see lines like
send(7, "\313D\1\0\0\1\0\0\0\0\0\0\6ipa-ca\3ipa\5devel\0\0\1\0\1", 34, MSG_NOSIGNAL) = 34
from the DNS lookups for ipa-ca.ipa.devel which is the OCSP server from the
strace -s 128 -f -esend ./p11_child --debug-microseconds=1 --debug-timestamps=1 --debug-to-stderr --debug-level=10 --pre --nssdb sql:/dev/shm/tp_pam_srv_tests-test_pam_srv --verify 'ocsp_default_responder=http://oooo.cccc.ssss.pppp:80,ocsp_default_responder_signing_cert=ocsp_cert'
where you should now see lines like
send(7, "yO\1\0\0\1\0\0\0\0\0\0\4oooo\4cccc\4ssss\4pppp\0\0\1\0\1", 37, MSG_NOSIGNAL) = 37
from the DNS lookups for the OCSP responder from the command line.
Of course all the validations will fail with "Certificate [SSSD Test
Token:Server-Cert][CN=ipa-devel.ipa.devel,O=IPA.DEVEL] not valid [-8071],
skipping" because none of the OCSP responders are available but I think this
test is sufficient to see that the patch is working as expected.
We can fail in sasl_bind_send() with ERR_AUTH_FAILED for basically
unspecified reason but we do not failover to next server. This patch
should fix it.
As said on the meeting, I didn't reproduce it and I'm not sure if it
will fix the customer issue unless they confirm it, but it seems to be a
valid patch anyway.
First patch, see attached.
This is for easy fix from ticket
I am going on the assumption that if the first 2 characters of ad_server
are digits then it is likely an IP address and not hostname. If you have
a better idea for this please let me know.
attached patch should fix ticket #2926
The default case (no adding, no removing services) is tested
If the patch is not ready for stable branch sssd-1-13
then we might merge this case with GPO code which uses slightly
modified way using hash tables.
please see the attached patch. I didn't find any information in the ssh
man pages about the expected error codes from the AuthorizedKeysCommand,
but I think we should at least suppress the error messages..
I tested with:
$ sss_ssh_authorizedkeys root
$ sss_ssh_authorizedkeys user-from-passwd
$ sss_ssh_authorizedkeys user-from-ipa
$ sss_ssh_authorizedkeys non-existing-user
The first three should be silent, the last one still prints an error
message. I think that's acceptable, because I would expect ssh to call
getpwnam() on its own before calling the AuthorizedKeysCommand.