[sssd PR#762][opened] responder: fix domain lookup refresh timeout
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/762
Author: sumit-bose
Title: #762: responder: fix domain lookup refresh timeout
Action: opened
PR body:
"""
Currently the timeout to check for new domains is reset whenever there
is a request with an unknown domain name. If those requests happen more
then once a minute (the default timeout) the timeout is always reset
before it can expire and as a result the domain list is never refreshed.
If SSSD starts offline with an empty domain list the NSS responder might
never be able to resolve sub-domain users or groups even if the backend
has switched to the online state and already refreshed the domain list.
Related to https://pagure.io/SSSD/sssd/issue/3967
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/762/head:pr762
git checkout pr762
5 years, 1 month
Design Document: Change password without Password Modify Extended Operation
by Pavel Březina
https://pagure.io/SSSD/docs/pull-request/77
.. highlight:: none
Change password on LDAP server that does not support Password Mofify
Extended Operation
=======================================================================================
Related ticket(s):
------------------
https://pagure.io/SSSD/sssd/issue/1314
Problem statement
-----------------
Some directory servers either do not support Password Mofify Extended
Operation
(OID 1.3.6.1.4.1.4203.1.11.1, RFC 3062) for password change or this
feature is
disabled by default. SSSD is unable to perform password change on such
servers.
Even though we recommend to upgrade to servers that supports this feature,
there are still users that will benefit from SSSD being able to change
password without it.
Use cases
---------
* A user wants to change his/her password against LDAP that does not
support
Password Modify Extended Operation.
Overview of the solution
------------------------
Provide new configuration option ``ldap_pwmodify_exop`` that will default
to true (use extended operation for password change). If this options is set
to false, SSSD will use simple LDAP modify operation instead of extended
operation.
Implementation details
----------------------
When a password change is requested, ``sdap_pam_chpass_handler_send`` is
called.
This request first authenticates the user with current password and then in
``sdap_pam_chpass_handler_auth_done`` tries to change it with extended
operation
by calling ``sdap_exop_modify_passwd_send``. At this point we should check
the value of ``ldap_pwmodify_exop`` option and decide whether to
continue with
extended operation or use ``ldap_modify_ext`` instead.
Information on how to change the password using simple LDAP modify operation
can be found `here
<https://www.ibm.com/support/knowledgecenter/SSVJJU_6.3.0/com.ibm.IBMDS.do...>`_
Configuration changes
---------------------
* New option: ``ldap_pwmodify_exop``
How To Test
-----------
Set ``ldap_pwmodify_exop`` to false and try to change user's password.
Authors
-------
* Pavel Březina <pbrezina(a)redhat.com>
5 years, 1 month
fleet commander integration
by Levin Stanislav
Hello,
I want to ask you about design of fleet commander integration, which I
found on
https://docs.pagure.org/SSSD.sssd/design_pages/fleet_commander_integratio....
> The JSON files will be stored in a new directory owned by the
> |sssd-ipa| subpackage. The top-level directory could be at
> |/var/lib/sss/deskprofile/| with per-user subdirectories. So each
> per-user JSON file would be stored at
> |/var/lib/sss/deskprofile/<domain>/<username>/<profilename>.json|. The
> |<username>| directories need to be owned by the user being logged in.
> /var/lib/sss/deskprofile/<domain>/<username>/<profilename>.json
> ------------ -------- ---------- ------------------
> | | | |
> v | | |
> Created by sssd package as | | |
> root:root (or sssd:sssd) | | |
> and has permissions 0751 | | |
> | | |
> v | |
> Owned by user:user_group | |
> and has permissions 0751 | |
> | |
> | |
> v |
> Owned by user:user_group |
> and has permissions 0700 |
> |
> v
> Owned by user:user_group
> and has permissions 0400
As I see FleetCommander is executed with root privileges (without CAPs
dropping) and is allowed to read user profiles.
Why is "user" owner of the directory "<username>"? and why should we
grant "user" with any permissions for this path?
Why is it not just 0700 for dirs, 0400 for profiles, owner
root/sssd_user for all subpaths?
Could you please explain?
Thank you in advance!
5 years, 1 month