[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, 9 months
[sssd PR#553][opened] Use p11_child to verify certificates for the ssh responder
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/553
Author: sumit-bose
Title: #553: Use p11_child to verify certificates for the ssh responder
Action: opened
PR body:
"""
This patch set is another step to solve https://pagure.io/SSSD/sssd/issue/3489,
i.e to remove the NSS dependency and allow all Smartcard and certificate
related features to be build with OpenSSL as well.
To have all the code related to certificate verification in one place the
verification code is removed from the ssh responder and the ssh responder will
now call p11_child to verify a certificate before extracting the public key as
ssh key. Another benefit is that the ssh responder is not blocked anymore
during OCSP check since they now run in p11_child and the ssh responder can
process other requests in parallel.
In this context I also added a patch which improves the documentation of the
feature in the sss_ssh_authorizedkeys man page as requested in
https://pagure.io/SSSD/sssd/issue/3688.
Besides adding unit tests for the new calls I added an unit test for the ssh
responder, similar to the ones for the nss and pam responder.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/553/head:pr553
git checkout pr553
5 years, 10 months
[sssd PR#247][opened] Subdomain inherit
by mzidek-rh
URL: https://github.com/SSSD/sssd/pull/247
Author: mzidek-rh
Title: #247: Subdomain inherit
Action: opened
PR body:
"""
I tested if the options that work in subdomain inherit also work in trusted domain section in sssd.conf. Most seem to work without any changes in the code except for two. With these two patches only one that does not work remains (I wanted to send patchset that adds all the options, but I got stuck on the option that sets the ldap principal, so I am sending this in the meantime).
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/247/head:pr247
git checkout pr247
5 years, 11 months
[sssd PR#556][opened] COVERITY: Add coverity support
by fidencio
URL: https://github.com/SSSD/sssd/pull/556
Author: fidencio
Title: #556: COVERITY: Add coverity support
Action: opened
PR body:
"""
Using travis-ci we can start doing coverity scans on every pushed code.
This is not something new as so far we have been relying on sgallagh's
internal infra to do so, unfortunatelly the infra is about to be
retired ... thus, start to use public coverity's instance is a hard
requirement for us.
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
Signed-off-by: Edjunior Machado <emachado(a)redhat.com>
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/556/head:pr556
git checkout pr556
5 years, 11 months
[sssd PR#531][opened] Add the needed machinery to have automated builds for our COPR repos
by fidencio
URL: https://github.com/SSSD/sssd/pull/531
Author: fidencio
Title: #531: Add the needed machinery to have automated builds for our COPR repos
Action: opened
PR body:
"""
As the title says, these patches are introducing the needed machinery to have automated builds for our COPR repos.
The next steps are:
- On Pagure, someone who has admin rights will have to:
- Go to the project's web page: https://pagure.io/SSSD/sssd
- Click in the "Settings" button
- Go down to the "Hook" section
- Click in the "Fedmsg" field
- Check the "Active" checkbox
- Click in the "Update" button
- On COPR:
- Go to the each project's webpage:
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
- To be created
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-master/
- Go to the "Packages" tab
- Click in "sssd" package
- In "Default Build Source" section, click in the "Edit" button
- In the SCM tab do:
- Type: Git
- Clone url: https://pagure.io/SSSD/sssd.git
- Committish: <branch name> (eg, master, sssd-1-13, sssd-1-14, ...)
- In the "How to build SRPM from the source" section, select:
- make srpm
- Click in the "Submit" button
After those steps, a new push would trigger a new copr build to the project.
The OSes that we're targeting are:
- el (all version, all arches)
- fedora (all versions, all arches)
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/531/head:pr531
git checkout pr531
5 years, 11 months
[sssd PR#464][opened] SYSDB: Properly handle name/gid override when using domain resolution order
by fidencio
URL: https://github.com/SSSD/sssd/pull/464
Author: fidencio
Title: #464: SYSDB: Properly handle name/gid override when using domain resolution order
Action: opened
PR body:
"""
When using name/gid override together with domain resolution order the
mpg name/gid may be returned instead of the overridden one.
In order to avoid that, let's add a check in case the domain supports
mpg so we can ensure that the originalADname and originalADgidNumber
attributes are the very same as the ones searched and then normally
proceed with the current flow in the code. In case those are not the
same, we *must* follow the code path for the non-mpg domains and then
return the proper values.
Resolves: https://pagure.io/SSSD/sssd/issue/3595
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/464/head:pr464
git checkout pr464
5 years, 11 months