[sssd PR#475][opened] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
by jhrozek
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
Action: opened
PR body:
"""
NOTE: This fix doesn't address the segfault, only the condition that led
to it. I would prefer to track the segfault and the search base issues
separately
NOTE2: I didn't have much time to test this PR yet. I'm mostly submitting
it to get feedback
Please see the full commit message below. I'm really confused about this
issue mostly because it seems we've had this bug for quite some time but did
not see it. I would be glad if somebody helps me understand if iterating
over all domains and adding all domains that are not yet present in the
ad_id_ctx->ad_options->sdap_id_ctx->sdom list is correct or not
The commit message follows:
Resolves: https://pagure.io/SSSD/sssd/issue/3594
Previously, sdap_domain_subdom_add() was called when a new ad_id_ctx was
being instantiated in the AD subdomains provider. The
sdap_domain_subdom_add() call iterates over all known subdomains and adds a
sdap_domain instance for every domain that is not present in an existing
sdap_domain list.
This is problematic for the AD subdomains provider e.g in this scenario
found by downstream ticket #3594:
- there is a domain child1.sssdad.com the sssd is joined to
- the subdomain provider auto-discovers ssdad_tree.com and
sssdad.com, in this order (which is important). The list of
sss_domain_info objects is updated in this order, too
- for each domain, ad_subdom_ad_ctx_new() is called. This function
creates a new ad_id_ctx and calls sdap_domain_subdom_add() to
add an sdap_domain object into the sdap_id_ctx. The
sdap_domain_subdom_add() call adds both domains to the list
-- for the sssdad_tree subdomain is is ok, because subsequent
calls only use the first sdap_domain object which is
ssdad_tree.com (remember, order is important)
-- for the sssdad.com domain, ssdad_tree.com is added first,
which then causes all searches in the sssdad.com to have a
search base from ssdad_tree.com
Because the sdap_domain instance in sdap_id_ctx should not be a list, but a
single domain, this patch adds a utility function that creates an
sdap_domain instance for a single subdomain instance.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/475/head:pr475
git checkout pr475
5 years, 7 months
[sssd PR#237][opened] providers: Move hostid from ipa to sdap
by hvenev
URL: https://github.com/SSSD/sssd/pull/237
Author: hvenev
Title: #237: providers: Move hostid from ipa to sdap
Action: opened
PR body:
"""
This just makes sss_ssh_knownhostsproxy work. There is no support for hostgroups (although hostgroups in `ipa` should continue working).
I've been using this for a few days with the `ldap` and `krb5` providers and I haven't noticed any regressions. I haven't tested `ipa` and `ad` but all tests seem to pass.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/237/head:pr237
git checkout pr237
5 years, 7 months
SSSD Virtual Test Suite
by Pavel Březina
Hello,
It took me a lot longer than I expected but here it is at last. This is
my set of scripts that use vagrant and Ansible to automatically
provision virtual environment that I use to develop and test SSSD.
To create this environment you only need to run one command:
$ ./setup.sh
and after a while you have several machines provisioned and ready. This
machines include LDAP, IPA and AD servers with one machine dedicated to
SSSD. This machine is already enrolled to those servers.
To start building and/or testing SSSD with all available providers, you
can just run:
$ vagrant ssh client
Additionally, it allows you to automatically source your set of scripts
on each login and access IPA web-ui from your browser.
I tried to make the provisioning as fast as possible but it still takes
approximately one hour on my machine. So be patient.
Any ideas and patches for improvements are welcomed.
The source is available at:
https://github.com/pbrezina/sssd-test-suite
5 years, 7 months
[sssd PR#483][opened] Password change with two factor authentication
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/483
Author: sumit-bose
Title: #483: Password change with two factor authentication
Action: opened
PR body:
"""
If two factor authentication is enforced both authentication factors are
needed to update or change the long term password. This means that during
the PAM chauthok operation it has to be determined if two factor
authentication is enable for the user and the user must be prompted
accordingly.
Typically in the first step of the chauthok operation (PAM_PRELIM_CHECK)
the current password is verified before asking the user for a new password.
With two factor authentication this has to be skipped because the one-time
factor would then be invalid to authenticate the actual password change.
In krb5_child if the long term Kerberos password is expired the available
pre-authentication types for the user should be checked by requesting the
kadmin/changepw principal.
Related to https://pagure.io/SSSD/sssd/issue/3585
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/483/head:pr483
git checkout pr483
5 years, 8 months
Design page: Automatic private group creation for the LDAP provider
by Jakub Hrozek
Hi,
I wrote a design page about exposing the functionality that creates the
user private groups based on the user entry only:
https://pagure.io/fork/jhrozek/SSSD/docs/blob/mpg/f/design_pages/auto_pri...
For your convenience, I'm also copying the design text in the RST format
below.
Once the design is approved, I'll propose a PR against the sssd/docs
repository.
Automatic Private Groups
========================
Related ticket(s):
------------------
https://pagure.io/SSSD/sssd/issue/1872
Problem statement
-----------------
This change will enable SSSD to automatically generate private groups for
users based on the UID number without the group actually being present as
an LDAP object.
Use cases
---------
The primary use-case is ease of management. The LDAP administrator will only
create the user object and add the user to supplementary groups as needed.
This has two advantages:
* There is one less object to manage and keep in sync with the user
* In AD environments, it is not possible to create a user and a group
with the same samAccountName, therefore even manually creating the private
groups requires the admin to remap the group attribute to a non-default one
since by default both users and groups use samAccountName.
Overview of the solution
------------------------
Most of the low-level functionality in the sysdb layer had been developed
for many years for use in the ``local`` provider. At the same time, there
are also most of the infrastrucure ready in the LDAP provider, because
the automatic private groups are used by default already for trusted domains.
At the moment, the functionality is enabled internally by an option called
``mpg``, short for Magic-Private-Groups. On a high level, the private groups
are not created in the SSSD cache at all, but the work is done by the NSS
responder which generates the group reply based on the user object
only. However, since the ``mpg`` option was always set for truste
Therefore, the majority of the work will be exposing the option in
configuration and making sure all codepaths work equally well for joined
domains as they do for trusted domains.
Implementation details
----------------------
A new option needs to be added that would control the user private group
creation. In the past, we've had an option called ``magic_private_groups``
and the internal boolean flag inside the ``sss_domain_info`` structure is
still called ``mpg``.
Instead of resurrecting the old option, we should introduce a newly named
option that would be understood by admins better, such as
``auto_private_groups``. The new option must be read on SSSD startup and set
the ``sss_domain_info->mpg`` flag, which is currently auto-enabled with
sudomains only.
The code branch that saves the user (currently ``sdap_save_user``) must be
extended to allow setting the GID number to be the same as UID number for
any domain that sets the ``mpg`` flag. Care must be taken to store the
original GID number (if any) to the ``SYSDB_PRIMARY_GROUP_GIDNUM`` attribute
which is then used by the NSS responder to add the original primary GID
as a supplementary group.
Finally, the group-by-GID LDAP request in the LDAP provider must be extended
to make sure that if a private group GID is requested before the user is,
the group request will also turn the group-by-GID request to a user-by-UID
request which would save the user object which would then allow the NSS responder
to auto-generate the group reply.
Configuration changes
---------------------
A new option ``auto_private_groups`` will be introduced. At the moment, it
will only be possible to set the option for the joined domains as the trusted
domains always create the private groups already by default. Therefore
the only viable usage of this new option in a trusted domain would be
`disabling` the functionality, which is out of scope of this RFE.
The ``auto_private_groups`` option will default to ``false``.
The new option must document that currently the cache must be removed when
changing the option value.
How To Test
-----------
The primary use-cases are SSSD being a client of a generic LDAP server
and SSSD on a Linux machine directly joined to an AD domain with
``id_provider=ad``.
In both cases, setting the ``auto_private_groups`` option to ``true``
should result in the ``initgroups`` call returning the primary GID number
of the user with the same value and resolving to the same name as the
primary UID namber and the username.
Other intefaces should produce symmetrical results, although at least in
the case of the D-Bus based IFP interface, is it currently not the case,
see `ticket #3543 <https://pagure.io/SSSD/sssd/issue/3543>`_.
For example, here is an output of a test user with private groups autogenerated::
id puser(a)win.trust.test
uid=20000(puser(a)win.trust.test) gid=20000(puser(a)win.trust.test) groups=20000(puser@win.trust.test),20002(user1_group2@win.trust.test),20001(user1_group1@win.trust.test),10000(pgroup(a)win.trust.test)
and without::
id puser(a)win.trust.test
uid=20000(puser(a)win.trust.test) gid=10000(pgroup(a)win.trust.test) groups=10000(pgroup@win.trust.test),20001(user1_group1@win.trust.test),20002(user1_group2(a)win.trust.test)
Note that in the case of the private groups being generated, the original
GID number is turned into a supplementary group by the initgroups call.
How To Debug
------------
There's not much extra debugging added for this feature. Debugging this
feature should amount to the usual checking of the debug logs. In addition,
the cache can be inspected with the ``ldbsearch`` tool to make sure all the
groups are saved as expected as well as the ``SYSDB_PRIMARY_GROUP_GIDNUM``
attribute.
Authors
-------
* Jakub Hrozek <jhrozek(a)redhat.com>
5 years, 8 months
[sssd PR#484][opened] SDAP: skip builtin AD groups in sdap_save_grpmem()
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/484
Author: sumit-bose
Title: #484: SDAP: skip builtin AD groups in sdap_save_grpmem()
Action: opened
PR body:
"""
While processing group memberships SSSD might accidentally save builtin
or other well known AD groups. With this patch those groups are skipped
similar as e.g. in sdap_save_group().
Resolves https://pagure.io/SSSD/sssd/issue/3610
There are other ways to solve the issue reported in ticket #3610, e.g. making
sure 'isPosix=False' is added to the group object in the cache. But since the
builtin groups are also ignored in sdap_save_group() I think this way is
currently more consistent. Long term I think we should find a way to assign
POSIX IDs to the well-known SIDs so that we can treat them as Posix objects.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/484/head:pr484
git checkout pr484
5 years, 8 months
[sssd PR#470][opened] IPA: Enable periodic subdomains refresh only after responder-induced refresh finishes
by jhrozek
URL: https://github.com/SSSD/sssd/pull/470
Author: jhrozek
Title: #470: IPA: Enable periodic subdomains refresh only after responder-induced refresh finishes
Action: opened
PR body:
"""
Resolves: https://pagure.io/SSSD/sssd/issue/3601
When the IPA subdomains code is initialized, the responders send a request
to fetch subdomains. This request first stores the list of trusted domains
to the cache and then runs the ipa-getkeytab helper.
At the same time, the periodical task to update the subdomains is also
started. The task founds out that all the trusted domains are already known
and finishes the request, which replies to the Data Provider requests as
well even while the ipa-getkeytab request is still running.
This unblocks requests from the responders, which try to connect to the AD
DCs even before the keytab is available, which switches the SSSD status to
offline.
The fix in this PR is only one of the alternatives. I wonder if it's OK
to rely on the responders to enable the ptask, especially in cases where
all the responders might be socket-activated, so none might be running
on SSSD startup. In this case, we might want to enable the ptask later,
with a delay. On the other hand, this way makes sure that at least one
request from the responder runs to full completion, otherwise we still
might run into the reverse race when the responder request comes into
the middle of the delayed ptask..
In both cases, I think we shouldn't also call the full handler from the
ptask, because the ptask shouldn't ever call the DP reply functions. Instead,
we should split the handler into an internal request and a wrapper around
it that also replies to DP. The ptask should just call the internal request
without replying to anything.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/470/head:pr470
git checkout pr470
5 years, 8 months