[sssd PR#413][opened] mmap_cache: add SID and type to struct sss_mc_rec
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/413
Author: sumit-bose
Title: #413: mmap_cache: add SID and type to struct sss_mc_rec
Action: opened
PR body:
"""
This patchset updates the memory cache by adding some new members to struct
sss_mc_rec. One is the addition of a hash value for SID based lookup which will
be added in later patches.
The other is a new record type and a member indicating the type. The new type
is a link record which links an alias name, e.g. an UPN, to the original record
of the related user or group object.
Besides aliases this link record will be used in case in-sensitive setups. E.g.
if getpwnam() returns the name of an AD users as Administrator(a)ad.domain bit
some applications or users use administrator(a)ad.domain for lookups the memory
cache is currently never used because there is no entry with the hash of
'administrator(a)ad.domain'. With this patch the original data record is created
as before with the hash for 'Administrator(a)ad.domain' and a link record is
create with the hash of 'administrator(a)ad.domain'. Now both lookups can be
handled by the memory cache. If now another application uses
ADMINISTRATOR(a)AD.DOMAIN for lookups the first request will go to the NSS
responder but upcoming requests can use the memory cache as well because a link
record for ADMINISTRATOR(a)AD.DOMAIN is created.
The last patch in this series adds some additional data to the user and group
lookup requests, the short name, the domain name, the short domain name and the
SID. Those are needed to be able to support SID based lookups in the memory
cache and allow applications to not depend on the name format returned by
getpw{nam|uid}. Upcoming patches for libsss_nss_idmap will make those
additional values available to applications I added them already here to keep
the memory cache related changes in one PR. Application which will benefit here
are the interfaces SSSD provides e.g. to Samba related applications like SSSD's
version of libwbclient but also IPA plugins like extdom and slapi-nis.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/413/head:pr413
git checkout pr413
5 years, 5 months
[sssd PR#601][opened] sbus: integrate sssd with sbus2
by pbrezina
URL: https://github.com/SSSD/sssd/pull/601
Author: pbrezina
Title: #601: sbus: integrate sssd with sbus2
Action: opened
PR body:
"""
Hi folks,
this is a really large patch set and I have now idea how to review it.
I know that Jakub tried to review the proof of concept, but he have not
managed to finish it so far. It is not in human power to review it all
so hard testing should be done.
I consider the code itself and the integration with sssd finished. I will
push only bug fixes and review issues now. This first version does not
run through make check so far because some tests needs to be altered,
this however does not prevent manual testing and reviewing.
I tried to make the changes small at first while running old and new sbus
in parallel, but it was too hard as the changes were too much interconnected.
Therefore each patch modifies one area, but completely and sssd will not build.
There are new libraries, each in pair. Each pair consist of asynchronous
(used inside sssd) and synchronous (used inside tools; sssctl) versions of API.
- libsss_sbus, libsss_sbus_sync: sbus interface
- libsss_iface, libsss_iface_sync: internal sssd interface, used for internal communication
- libifp_iface, libifp_iface_sync: infopipe interface
At this point, changes are mostly one to one. We still have separate server for monitor and
backends. We still do not use signals, even though it is possible. I will file separate
tickets with ideas how to improve our api further and we can work together after
this patch set is tested and merged.
I did my best with manual testing but I doubt I run all the scenarious. Especially, I want
to ask @sbose to test ifp smartcard API and @fidencio to test Fleet Commander integration
(the one dbus call in ipa code).
Thank you.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/601/head:pr601
git checkout pr601
5 years, 7 months
[sssd PR#522][opened] Prepare SSSD to support IPA in trust to Samba AD
by abbra
URL: https://github.com/SSSD/sssd/pull/522
Author: abbra
Title: #522: Prepare SSSD to support IPA in trust to Samba AD
Action: opened
PR body:
"""
This pull request prepares SSSD ipa provider to support IPA in trust to Samba AD but the same changes are needed for a properly working bi-directional trust against Microsoft AD as well. To make everything fully working, one needs patches against FreeIPA too but SSSD changes are isolated.
@sumit-bose @jhrozek please review.
1. When IPA establishes a trust to an Active Directory forest, a number of special objects is created in a subtree of `cn=trusts,$SUFFIX`. These objects represent Kerberos principals for trusted domain objects (TDOs) used for both incoming and outgoing trusts. For bi-directional trust there is a requirement that one of them (`<REMOTE FLAT NAME>$@<OUR REALM>`) must have a POSIX identity because a remote domain controller will use it to authenticate against smbd running on IPA master.
SSSD only looks for user accounts in `cn=accounts,$SUFFIX`, so an attempt by smbd to resolve this principal name as a POSIX user via `getpwnam()` will fail. And the reason why smbd behaves this way is due to the fact that a Kerberos ticket used for authentication contains no MS-PAC record, thus not allowing Samba to build a local security token it needs. This is expected for the authentication using TDO account as it is used for bootstrapping reasons (AD DC couldn't create and sign MS-PAC record for an account in IPA realm) but the side effect is that TDO object must be known as a POSIX account on IPA master.
Thus, we extend user search base in IPA provider to search in both `cn=accounts,$SUFFIX` and `cn=trusts,$SUFFIX`. Changes on FreeIPA side will handle access controls and generation of the POSIX information for the TDO accounts.
2. For long time we relied on using cross-realm TGTs to talk to Active Directory domain controllers (LDAP and GC services) in case of bi-directional trust. Unfortunately, this is not something we can continue using as there are multiple reasons such access can be denied by a trusted AD side, including SID filtering and other security measurements. It also happens that right now Samba AD in Fedora has a bug in handling a cross-realm TGT generated by the FreeIPA KDC. As result, while technically IPA could establish a bi-directional trust to Samba AD, it does not work as any SSSD attempt to connect to AD DCs via LDAP with GSSAPI will fail (Samba AD DC answers error with PROCESS_TGS message on Kerberos level and authentication fails).
For this reason, we should remove any distinction when using bi-directional trust and simply always use a special keytab with a TDO object as we do in uni-directional trust case. While a more generic Kerberos authentication will not work in the outbound direction, SSSD will be able to resolve users/groups.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/522/head:pr522
git checkout pr522
5 years, 8 months
[sssd PR#609][opened] SUDO: Don't save duplicates when saving qualified names
by jhrozek
URL: https://github.com/SSSD/sssd/pull/609
Author: jhrozek
Title: #609: SUDO: Don't save duplicates when saving qualified names
Action: opened
PR body:
"""
The sudoUser attribute which is part of the sudo rule can contain any name
that sudo can parse on the LDAP side. Internally, however, the attribute is
always qualified with the name of the SSSD domain.
This patch makes sure that if two or more sudoUser attributes contain the
same name in both qualified and an unqualified form, the rule is actually
saved. Previously, the rule would have failed to be saved and the sysdb
sudo code would have errored out with EEXIST.
Resolves: https://pagure.io/SSSD/sssd/issue/3596
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/609/head:pr609
git checkout pr609
5 years, 8 months