[PATCH] Do not crash if GetUserAttrs cannot be parsed
by Jakub Hrozek
Hi Pavel,
can you check if this is the right thing to do for methods that parse
arguments on their own?
To reproduce, it was enough to run:
sudo dbus-send --print-reply --system
--dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe
org.freedesktop.sssd.infopipe.GetUserAttr string:admin
string:gecos
instead of the proper:
sudo dbus-send --print-reply --system
--dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe
org.freedesktop.sssd.infopipe.GetUserAttr string:admin
array:string:gecos
7 years, 10 months
[DESIGN] Lookup Users by Certificate - Active Directory
by Sumit Bose
Hi,
please find a new design document at
https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificatePart2.
It describes the extended support for user lookup by certificates namely
for certificates stored in AD and overrides.
The related patches are ready from the functional point of view but I
want to add some more test before sending them to the list.
For your convenience please find the text of the design document below
as well.
bye,
Sumit
= Lookup Users by Certificate - Active Directory =
Related ticket(s):
* https://fedorahosted.org/sssd/ticket/2897
=== Problem statement ===
So far the main focus of the SSSD certificate and Smartcard
authentication support in SSSD was on FreeIPA. Although it is possible
to use it with the AD provider as well (see
[https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationTest...
SmartcardAuthenticationTestingWithAD] for details) it requires some
manual configuration.
On this page we describe the enhanced support for certificates in AD and
in override data for the direct (AD provider) and indirect (IPA with
trust to AD) integration.
=== Use cases ===
==== Apache ====
Apache is using ''mod_lookup_identity'' to look up a user who used
certificate based authentication with the help of the certificate.
Currently, without additional configuration, only IPA users were
supported. Now users from AD which have the certificate stored in the
user entry as supported as well for both direct and indirect
integration. Additionally certificates can be stored in local overrides
for the direct integration and in IPA server-side overrides for the
indirect integration.
==== Smartcard authentication ====
If the certificate of the user is stored in the user's entry in AD or in
a IPA or local override the user can authenticate with a Smartcard which
holds the certificate and the matching private key.
Since both use-case rely in the same common code only the user lookup is
discussed later on because it is easier to test and validate.
=== Overview of the solution ===
==== General ====
The common override lookup code must be enhanced to allow lookups by
certificates as well.
==== AD provider (direct integration) ====
To support the direct integration
* the attribute containing the certificate must be read by default
* sss_override must be enhanced to store certificates in local overrides
* as well
==== IPA provider (indirect integration) ====
To support the indirect integration
* the IPA override lookup code must be enhanced to read certificate
* overrides from the server and store them in the cache
* the IPA client code to look up AD users via the extdom plugin must be
* enhanced to allow lookups by certificates
==== Support for the IPA extdom plugin ====
Currently it is only possible to look up users by certificate with the
InfoPipe which uses DBus. To avoid to add a DBus requirement to the
extdom plugin and the directory server a call similar to
sss_nss_getnamebysid() should be added to allow easy lookups by
certificate via the NSS responder.
=== Implementation details ===
Most of the changes are related to adding the new attribute to the
various lookup requests.
=== Configuration changes ===
For the AD provider the currently unset option ''ldap_user_certificate''
will be set to ''userCertificate;binary''. This means that is a
certificate is available in the user entry it will be downloaded and
written to the cache by default. To avoid this ''ldap_user_certificate''
must be set to a non-existing attribute name like e.g.
{{{
ldap_user_certificate = nonExistingAttributeName
}}}
The ''sss_override user-add'' utility has a new option ''--certificate''
(''-x'') which expects the base64-endode certificate as an argument.
=== How To Test ===
Testing can be done with ''dbus-send'' as described in
LookupUsersByCertificate. Instead of storing the certificate in the user
object of an IPA user it should be now stored in the user object of an
AD user as e.g. described in
[https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationTest...
WritingthecertificatetoAD]. Additionally certificates overrides can be
written with the ''sss_override'' utility for the direct integration or
the ''ipa idoverrideuser_add_cert'' command for the indirect
integration.
If multiple certificate are added it should be noted that a user my have
multiple different certificates but a single certificate should be only
assigned to a single user. If a certificate is assigned to multiple
users no matter if in the user object or in the override the lookup will
fail sooner or later.
For the indirect integration the different lookups should be tested
independently on the IPA master and an IPA client because different code
paths are used since SSSD is running in the ipa-server-mode on the
master.
=== How To Debug ===
Explain how to debug this feature if something goes wrong. This section
might include examples of additional commands the user might run (such
as keytab or certificate sanity checks) or explain what message to look
for.
=== Authors ===
* Sumit Bose <sbose(a)redhat.com>
7 years, 10 months
[PATCH] AUTOFS: Removing of redudant debug message
by Petr Cech
Hi,
this patch is about removing redudant debug message from middle layer of
autofs responder.
The point is that called function confdb_get_int() has very nice messaging.
Please, look at how we call autofs_get_config, there is another debug
message at top level, but this is important because it says that error
is fatal.
Regards
--
Petr^4 Čech
7 years, 11 months
[PATCH] LDAP: Print port in sdap_print_server
by Lukas Slebodnik
ehlo,
following patch help me to find out issues with GPO.
I think it might be useful also in other cases.
But ideal would be if fail-over code would print port as well.
ATM "0" is logged as a port with AD.
LS
7 years, 11 months
Running tests with different environment
by Jakub Hrozek
Hi,
I'm working on pam_sss.so tests[1] and I ran into a problem that I don't
know how to solve best.
tl;dr, I would like to set different environment variables for different
tests in order to set up cwrap libraries differently per-test.
I can't use setenv() in the test itself, because that's too late, I need
the variables to be set when __attribute__(constructor) is run, so normally
at program startup, when the libraries are loaded.
With cmake it's easy, use set(TEST_ENVIRONMENT). But with autotools, I
only found two ways:
- TESTS_ENVIRONMENT - this is fine, but it's per Makefile.am. So I
would have to split the tests more, into pam_wrapper tests that also
require uid_wrapper, tests that only require pam_wrapper, ...
- LOG_COMPILER - this allows to run a wrapper script before a test
that receives the test name as argv. So this is pretty much what I
want except this is a feature new to automake 1.12, which would
rule out both RHEL-6 and Ubuntu Trusty (which is used by Travis)
So I'm really leaning towards creating a src/tests/cwrap/pwrap/Makefile.am
and src/tests/cwrap/pwrap_root/Makefile.am. The downside of multiple
Makefile.am files is that there is some code duplication and the build
takes longer. But I still think there is enough interest (from us and from
our users) to support git master on old platforms. I can file a ticket to
remove this and use LOG_COMPILER when we drop support for RHEL-6 and old
Ubuntu versions...
If you disagree, please reply, otherwise I'm going to send a patch with
per-test Makefile...
[1]
https://jhrozek.fedorapeople.org/cov/sssdcov/sss_client/pam_sss.c.gcov.html
42% code coverage, up from 0% last week. Woo!
7 years, 11 months