mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
Add design page for one-way trust to AD with shared secret
Reviewed-By: Christian Heimes <cheimes@redhat.com>
This commit is contained in:
Alexander Bokovoy
committed by
Christian Heimes
Christian Heimes
parent
e9fd8adf59
commit
2a8176ee03
174
doc/designs/adtrust/oneway-trust-with-shared-secret.md
Normal file
174
doc/designs/adtrust/oneway-trust-with-shared-secret.md
Normal file
@@ -0,0 +1,174 @@
|
||||
# One-way trust with shared secret
|
||||
|
||||
## Overview
|
||||
|
||||
FreeIPA does support trust to an Active Directory forest. The trust can be
|
||||
established using administrative credentials from the forest root domain or
|
||||
using a so-called shared secret. In the latter case no administrative access is
|
||||
given to the remote side of the trust and each administrator performs their
|
||||
configuration separately: FreeIPA administrator configures IPA side, Active
|
||||
Directory administrator adds IPA forest as a trusted one on the Active
|
||||
Directory side.
|
||||
|
||||
For trust to be active, one needs to validate it. Validation process includes a
|
||||
sequences of DCE RPC calls that force a domain controller on the trusted side
|
||||
to establish a so-called "secure channel" to a remote domain controller in the
|
||||
trusting domain. This is an administrative operation and requires
|
||||
administrative privileges to activate. If trust was established using a shared
|
||||
secret, IPA side will lack ability to initiate a validation process.
|
||||
|
||||
At the same time, FreeIPA 4.6 or earlier versions do not include functionality
|
||||
to allow a remote validation from Active Directory to happen before trust
|
||||
objects are created and SSSD can retrieve information from the Active Directory
|
||||
side. Unfortunately, the latter is not possible until trust is validated.
|
||||
|
||||
The purpose of this design is to extend FreeIPA setup to allow trust validation
|
||||
to be initiated from Windows UI in case a shared secret is used to create a
|
||||
trust agreement.
|
||||
|
||||
## Use Cases
|
||||
|
||||
As a FreeIPA administrator, I'd like to establish a trust between an Active
|
||||
Directory forest and a FreeIPA deployment using a shared secret. As FreeIPA
|
||||
administrator, I have no administrative access to Active Directory and would
|
||||
like to delegate the operation to create trust on Active Directory side to my
|
||||
counterpart in Active Directory forest.
|
||||
|
||||
|
||||
## How to Use
|
||||
|
||||
|
||||
1. Establish a one-way trust with a shared secret on IPA side:
|
||||
`ipa trust-add <ad-domain> --shared-secret`
|
||||
|
||||
2. On Windows side, open Active Directory Domain and Trusts tool
|
||||
* Open properties for the Windows forest
|
||||
* Choose 'Trusts' tab and press 'New trust' button there
|
||||
* Navigate through the trust wizard by entering:
|
||||
* IPA forest name, then 'next'
|
||||
* Choose 'Forest trust' on the Trust Type page
|
||||
* Choose 'One-way: incoming' on the Direction of Trust page
|
||||
* Choose 'This domain only' on the Sides of Trust page
|
||||
* Enter the same shared secret one was using in step (1) with 'ipa trust-add'
|
||||
* Complete trust wizard
|
||||
|
||||
3. Going back to the trust properties, one can now validate the trust from Windows side.
|
||||
|
||||
One limitation is that it is not possible to retrieve forest trust information
|
||||
about IPA realm by Active Directory domain controllers due to the fact that
|
||||
Samba configuration used by IPA does not support a remote query for this
|
||||
information. It is only available when Samba is used in Samba AD configuration.
|
||||
|
||||
TODO: check whether it is possible to force to set forest trust information
|
||||
from IPA side after both sides of trust are were configured.
|
||||
|
||||
## Design
|
||||
|
||||
There are two important parts of the solution. On IPA side, there is a module
|
||||
to allow Samba to look up trusted domains and user/group information in IPA
|
||||
LDAP. On the other side, there is support for POSIX identities of trusted
|
||||
domain objects in SSSD.
|
||||
|
||||
### FreeIPA module for Samba passdb interface
|
||||
|
||||
FreeIPA provides a special module for Samba, `ipasam`, that looks up
|
||||
information about trusted domains and user/group in FreeIPA LDAP. The module
|
||||
also maintains trust-related information when trust is created via DCE RPC
|
||||
interfaces.
|
||||
|
||||
When trust is created, `ipasam` module needs to create a set of Kerberos
|
||||
principals to allow Kerberos KDC to issue cross-realm ticket granting tickets.
|
||||
These principals will have the same keys as trusted domain objects on Active
|
||||
Directory level.
|
||||
|
||||
When a secure channel is established between two domain controllers from
|
||||
separate trusted domains, both DCs rely on the trusted domain object account
|
||||
credentials to be the same on both sides. However, since Samba has to perform
|
||||
SMB to POSIX translation when running in POSIX environment, it also needs to
|
||||
have a POSIX identity associated with the trusted domain object account.
|
||||
|
||||
As result, `ipasam` module needs to maintain POSIX attributes for the trusted
|
||||
domain object account, along with Kerberos principals associated with the
|
||||
trust.
|
||||
|
||||
### SSSD
|
||||
|
||||
When Windows successfully authenticates to Samba, Samba needs a POSIX identity
|
||||
to run `smbd` processes as the authenticated 'user'. `smbd` and `winbindd`
|
||||
processes use standard system calls to resolve authenticated user to a system
|
||||
one (`getpwnam_r()`) and if the call fails, whole Windows request is rejected.
|
||||
|
||||
Given that trusted domain object accounts are associated with the cross-realm
|
||||
Kerberos principals, they are located in a special subtree in FreeIPA LDAP:
|
||||
`cn=trusts,$SUFFIX`. However, SSSD does not look by default in this subtree for
|
||||
users. By default, SSSD configuration for user accounts looks in
|
||||
`cn=users,cn=accounts,$SUFFIX` for `id_provider = ipa` and will not be able to
|
||||
see trusted domain object accounts.
|
||||
|
||||
Thus, to allow Windows to successfully validate a one-way shared incoming trust
|
||||
to FreeIPA, SSSD needs to resolve trusted domain object accounts as POSIX users
|
||||
on IPA master side.
|
||||
|
||||
|
||||
## Implementation
|
||||
|
||||
### FreeIPA `ipasam` module
|
||||
|
||||
`ipasam` module needs to create and maintain POSIX identities of the trusted
|
||||
domain object accounts.
|
||||
|
||||
Following objects and their aliases are created and maintained by `ipasam`
|
||||
module. In the description below `REMOTE` means Kerberos realm of the Active
|
||||
Directory forest's root domain (e.g. `AD.EXAMPLE.COM`), `REMOTE-FLAT` is
|
||||
NetBIOS name of the Active Directory forest's root domain (e.g. `AD`).
|
||||
Correspondingly, `LOCAL` means FreeIPA Kerberos realm (e.g. `IPA.EXAMPLE.COM`)
|
||||
and `LOCAL-FLAT` is the NetBIOS name of the FreeIPA primary domain (e.g.
|
||||
`IPA`).
|
||||
|
||||
Principal | Description
|
||||
--------- | -----------
|
||||
krbtgt/REMOTE@LOCAL | Cross-realm principal representing Active Directory forest root domain
|
||||
REMOTE-FLAT$@LOCAL | Trusted domain object account for the Active Directory forest root domain
|
||||
krbtgt/REMOTE-FLAT@LOCAL | Alias to REMOTE-FLAT$ TDO
|
||||
krbtgt/LOCAL@REMOTE | Cross-realm principal representing IPA domain in Active Directory forest to allow crross-realm TGT issuance from IPA KDC side
|
||||
LOCAL-FLAT$@REMOTE | Trusted domain object account for IPA domain in Active Directory forest
|
||||
krbtgt/LOCAL-FLAT@REMOTE | Alias to LOCAL-FLAT$
|
||||
|
||||
For inbound trust `ipasam` module creates following principals:
|
||||
* `krbtgt/LOCAL@REMOTE`, enabled by default
|
||||
* `LOCAL-FLAT$@REMOTE`, used by SSSD to talk to Active Directory domain
|
||||
controllers, with canonical name set to `LOCAL-FLAT$` because Kerberos KDC
|
||||
must use this salt when issuing tickets for this principal. The use of this
|
||||
principal is disabled on IPA side (IPA KDC does not issue tickets in this name)
|
||||
--- we only retrieve a keytab for the principal in SSSD.
|
||||
|
||||
For outbound trust `ipasam` module creates following principals:
|
||||
* `krbtgt/REMOTE@LOCAL`, enabled by default.
|
||||
* `REMOTE-FLAT$@LOCAL`, enabled by default. Used by a remote AD DC to
|
||||
authenticate against Samba on IPA master. This principal will have POSIX
|
||||
identity associated.
|
||||
|
||||
|
||||
### SSSD
|
||||
|
||||
In IPA master mode, SSSD needs to start look into `cn=trusts,$SUFFIX` subtree
|
||||
in addition to `cn=users,cn=accounts,$SUFFIX` subtree to find trusted domain
|
||||
object accounts. This can be achieved either by explicitly adding a second
|
||||
search base to `ldap_search_user_base` option in the `[domain/...]` section or
|
||||
by automatically expanding a list of search bases when running in the IPA
|
||||
master mode. The latter is already implemented in SSSD 1.16.3 and 2.1.0 with
|
||||
https://pagure.io/SSSD/sssd/c/14faec9cd9437ef116ae054412d25ec2e820e409
|
||||
|
||||
|
||||
Feature Management
|
||||
------------------
|
||||
|
||||
We already allow to create a shared secret-based trust to Active Directory. No
|
||||
functional change is needed in either Web UI or CLI.
|
||||
|
||||
Upgrade
|
||||
-------
|
||||
|
||||
During upgrade POSIX identities need to be created for existing trust
|
||||
agreements.
|
||||
|
||||
Reference in New Issue
Block a user