[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
Idea for multilib handling in Fedora and RHEL
by Stephen Gallagher
I was thinking this morning again about how we could deal with the 32-bit on 64-bit problem. On Fedora 24 and newer, we have the ability to use rich RPM dependencies (Recommends: sssd-client.i686 if glibc.i686) That doesn't help on older Fedora or RHEL systems though.
What if we were to split the nss_sss.so.2 library into its own subpackage and then turn off the automatic dependency generation for it? We could then have sssd-common Requires: the one for the same arch and Recommends: the one for the other architecture (or Requires: for older systems that don't support Recommends:)
The result would be that default installations of the OS could have both versions of nss_sss.so.2 but of course the 32-bit one wouldn't actually do anything unless someone installs glibc.i686 (or it is pulled in by something else).
This would not be an approach I would recommend in general, but the NSS client is a special case: it's only meaningful if glibc is installed because otherwise nothing would ever call into it. Even for the primary arch, it's a safe assumption that glibc will always be installed at least for that arch, so there's no reason to add that dependency explicitly.
7 years
sssd behaviour with large nested netgroups.
by Malahal Naineni
Hi All,
We have ganesha NFS server that calls innetgr() call to validate
client request. Noticing that all ganesha threads were making innetgr()
calls and spending a lot of time there, I wrote a small script that just
repeatedly calls innetgr() with same host name but with two different
netgroups. Each call seems take about 0.5 second. I would like to know
if sssd is expected to cache innetger() results or is it left to glibc?
Does any one know if glibc caches such requests of a larger nested
subgroup? Is this behaviour expected or something badly configured here?
Appreciate any responses.
Regards, Malahal.
7 years
[DESIGN][PATCH] IPA HBAC Time Rules
by Stanislav Laznicka
Hello,
So after quite some time I finally got some HBAC time rules code I am
able to present. I forked your sssd Github repository and added the code
in my branch, the forked repo can be found on the following link:
https://github.com/stlaz/sssd/tree/freeipa-timerules
Please note that if there are any changes to the current state of
implementation it will be done via rebases so simply pulling the repo
might not always do. I will also attach my patches to this mail.
About the implementation:
You can read most about it at the feature's design page:
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. I'm using
libical for parsing iCalendar strings which form the base of the time
rules. As such, for proper time zone handling, the Olson city name of
the host running SSSD is required.
Now I know that the pressure with this part of SSSD is on portability
lately and I have to say that to make getting Olson name portable, this
might get a bit painful. Currently, the presented solution should run
just fine on Red Hat-like and Debian-like distros and it's based on the
/etc/localtime (/etc/timezone) file. From what I've gathered, you would
also like to have it ported to FreeBSD and Solaris (correct me if I'm
wrong). I already did some research on how to get the Olson name there
but it all seems a bit messy so if you know of a good way, please, let
me know.
Also currently the Python bindings are missing but I'm hoping to add
these if not today then later this week. I have them pre-prepared from
the previous implementation, they just need to be modified a bit.
Standa
7 years, 1 month
[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, 1 month