sssd-ad uses wrong key to verify tgt at login time
by Jurjen Bokma
Hi,
I believe the closing of
https://fedorahosted.org/sssd/ticket/1871#comment:2
to be wrong. Jakub Hrozek asked me to bring this up here after I brought it to his attention through
https://bugs.launchpad.net/bugs/1274543
When it logs in to the AD server, sssd uses the first key in the keytab. In my case, that first key is of a 'join account': a special purpose AD account that has permission to join machines to the domain, and nothing else. In particular, it lacks the permissions to list users. Hence it is unfit to be used by sssd for lookups. As soon as I remove the offending key, sssd works fine, by using another key, which happens to work. When I put it back in the keytab (as the first key), sssd stops working again. I second Jakub in the opinion that sssd should select the 'right' principal to use: ldap_sasl_authid or shortname$@realm.
I believe the cause of the problem to be in src/providers/krb5/krb5_child.c in the loop immediately following the comment:
/* We look for the first entry from our realm or take the last one */
Indeed, if I make that loop skip the first key found, everything works as expected, whether the ADJoiner key is in the keytab or not.
This is just an ad-hoc fix for my case of course.
Regards
Jurjen
9 years, 10 months
[DESIGN DISCUSSION] Configuring SSSD
by Dmitri Pal
Hello,
Over the time multiple tools have been developed and used to address
different use cases around SSSD configuration.
We now have:
1) SSSD that needs to read a configuration. It uses ding-libs
libini_config for that purpose.
libini_config was historically developed to read configuration from C
services like SSSD.
It is currently used by SSSD and GSS proxy
It is not capable of modifying and saving the configuration. To be fair
it is capable but the interfaces are not exposed at the high level API.
It will take some (couple days or so to close this gap).
2) SSSD also needed to create sssd.conf at the installation time. It is
ueasy to do it from Python this is why an SSSD config python script have
been created. It is good at modifying the configuration and setting
specific values at the beginning of the sssd.conf's life. It is not
suited well (at least yet) for long term maintenance of the
configuration file. It is also SSSD specific.
3) Over the time there were RFEs that suggested that sssd configuration
should be extensible or overwritable.
The following ticket cover that: https://fedorahosted.org/sssd/ticket/2247
The design has been published here
https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
4) There is a desire to manage SSSD over OpenLMI a cockpit in an object
oriented way. To do that (following the standard LMI model) the
following layring has been suggested and implemented:
Consumer (OpenLMI/Cockpit) -> D-Bus interface -> ifp service (responder)
-> augeas c api
More details are here:
https://fedorahosted.org/sssd/wiki/DesignDocs/OpenLMIProvider
5) In the absence of the good configuration solution for the integration
purposes, i.e. to integrate applications running on top of the system
with SSSD as a short term solution a puppet-augeas based way of
configuring sssd.conf was introduced the other day. The main
requirements are to be able to modify existing configuration and more
specifically change the values that represent a list of values.
6) From the very beginning we were hoping that there would be a way to
be able to define the grammar of the configuration file and check it to
be able to diagnose the config files and prevent their corruption. The
idea was to add this capability to libini as it provides a set of nice
convenience capabilities in comparison to Augeas. Also Augeas until not
long ago was not included in some distors.
The list above presents a spectrum of use cases and solution to those
use cases.
The goal of this email is to try to enumerate the use cases and
constraints and understand how the solution for those use cases can be
consolidated and unified and where it makes sense todo and where not. It
is a goal to define a reasonable alignment between the technologies and
provide a path forward to a reusable and maintanable stack.
So we have the needs:
1) Read config files at run time from C (daemons and D-BUS provider)
2) Write config files from C (configuration interface over LMI)
3) Create and modify files at installation and upgade using some simple
mean/API which can be C, python or anything else
4) Be able to manage configuration files in a object oriented manner
with or without D-BUS running
5) Be able to augment the code file without touching it
6) Provide a way to validate the file
So I see the following layering
+------------------+
| High level tools |
+------------------+
|
\/
+---------------------------+
| Object oriented interface |
+---------------------------+
| |
\/ \/
+-----------------+ +------------------+
| D-BUS responder | | D-BUS shim layer |
+-----------------+ +------------------+
| --------------------|
| |
\/ \/
+-------+ +----------------+
| C API |<-------------| File validator |
+-------+ +----------------+
/\ \
| \ +--------------+
| -------------->| Config file |
| +--------------+
| /\
+----------------+ |
| SSSD/GSS proxy | |
+----------------+ |
|
+------------------+
| SSSD Coinfig API |
+------------------+
/\
|
+--------------+
| Simple tools |
+--------------+
This layout shows three distinct paths towards config file:
1) Old python API and tools on top (does authconfig use this path?)
2) Top level D-BUS api and advanced object oriented tools
3) C API
We need to make several decisions at this point:
a) How much we enhance-update-improve existing python API instead of
using new D-BUS interface.
IMO we should leave python API alone for foreseeable future but any new
changes should go via the new D-BUS interface
b) How we make sure that the D-BUS interface is really usable. It is not
that light weight.
Would be nice to be able to have a shim layer for the cases like docker
where there might not be D-BUS or systemd. This however might not be a
problem for us to solve. It might be a generic problem for all LMI style
providers. A lot in D-BUS world is autogenerated so I suggest that we
ask to be able to generate a mini D-BUS interface that would go directly
from the interface to the logic implemented in responder. I do not know
what is best. But I think it is a discussion to have with D-BUS guys and
should be more general.
For now we can assume that D-BUS is there and docker use case will be
solved in some generic way.
c) If we assume D-BUS and systemd it really makes sense to separate the
responder in charge of configuration from other responders and make it
started on demand when there is a real call over the D-BUS to make a
config change. IMO this work for splitting ifp into data ifp and config
ifp should be filed as a ticket and done as a part of 1.13 release.
d) What is going to be the low level C library? We have two candidates
libini and augeas.
I definitely have a preference towards libini but this does not mean I
am right. I do not have a lot of time to maintain libini. I do not see a
reason to rip it out and replace with augeas yet. But I also do not see
a reason why we should rely on augeas. Right now IMO it would be more
work to rip libini and switch to augeas but over time if we do more and
more augeas work it might be much less. I feel people are more
comfortable with augeas than using libini and adding to it as they go. I
do not know why but suspect it is because augeas has appeal of a more
commonly used tool/interface. It is all about what we think is the right
path. If we decide that augeas is the way to go then we should not
invest into enhancing libini and start building our improvements in
augeas or around augeas. If we think that libini is the right path
because it fill give us more features, flexibility and control then let
us make it so that I am not the only contributor to it and people would
not have problems throwing patches at it on as needed basis.
For me this is a very important decision. Right now I feel I am on hook
to continue investing my scares time into libini. I think I am holding
people back with this so I would rather come to terms and move forward
whatever we think is best for SSSD, GSS proxy and potential other
daemons that need to read and deal with config files.
Thoughts?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
9 years, 10 months
Announcing SSSD 1.12 beta 2
by Jakub Hrozek
=== SSSD 1.12 Beta 2 ===
The SSSD team is proud to announce the second beta release of version 1.12
of the System Security Services Daemon.
As always, the source is available from https://fedorahosted.org/sssd.
RPM packages will be made available for Fedora rawhide shortly.
The SSSD 1.12.0 release is scheduled for the end of June. Our goal is
to stabilize the release and focus solely on bug fixes until the final
1.12.0 release. At the same time, the SSSD is string-frozen until the
release of 1.12.0.
== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
== Highlights ==
* This releases merges the enhancements that were included in 1.11.6 and
stabilizes the strings before releasing 1.12.0. With this beta2, SSSD
enters a string freeze period before the final 1.12.0 release
* Several patches that improve portability of SSSD, especially with
consideration of BSD systems have been included
* The sss_usermod tool was enhanced to add or modify custom attributes
for entries in domains configured with id_provider=local. This feature
is mostly useful for testing the InfoPipe responder without having to
configure a remote server.
* Fixed unit tests on big-endian architectures
== Documentation Changes ==
* A new option ldap_use_tokengroups was added. Setting this option to False
disables the support for tokenGroups, which is useful for environments that
wish to restrict the group nesting level. Doing so with tokenGroups enabled
is nontrivial since the tokenGroups attribute flattens the group memberships.
* A new option homedir_substring makes it possible to substitute a
templatized home directory attribute for a client-side defined value
== Tickets Fixed ==
https://fedorahosted.org/sssd/ticket/2182
[RFE] Add the possibility to add custom attributes for the local provider
https://fedorahosted.org/sssd/ticket/2308
document that simple access provider supports group nesting
== Detailed Changelog ==
Jakub Hrozek (6):
* Updating the version to 1.12beta2
* TOOLS: Allow adding and modifying custom attributes with sss_usermod
* TESTS: fgetc returns int, not char
* MAN: Fix a typo in the ldap_id_mapping page
* LDAP: Fix DEBUG message
* Updating the translations for the 1.12beta2 release
Lukas Slebodnik (14):
* UTIL: Add function sss_parse_name_const
* NSS: Refactor expand_homedir_template
* NSS: Add option to expand homedir template format
* TEST: Add test for expand homedir
* PAM: Include header file security/pam_appl.h
* MAKE: Remove PAM libraries from libsss_simple
* CONFIGURE: Enhance detection of pam
* PAM: Fix compilation of pam_test_client with openpam
* PAM: Use fallback version of some pam macros
* PAM: Define compatible macros for some functions.
* PAM: add ignore_authinfo_unavail option
* SDAP: Use portable constant as level in setsockopt
* Unify usage of function gethostname
* MAN: Add reference to manual page sssd-sudo
Pavel Březina (1):
* man: clarify refresh_expired_interval
Pavel Reichl (5):
* LDAP: fix - find primary group by gid
* MAN: Detailed ldap_group_nesting_level option
* SDAP: Make nesting_level = 0 to ignore nested groups
* SDAP: Add option to disable use of Token-Groups
* MAN: hint nested groups by simple access provider
9 years, 10 months