Samba4/Proposal for IPA to AD trust: Difference between revisions

From SambaWiki
(explain choice of a single KDC)
(move trust proposals to seperate pages)
 
(One intermediate revision by the same user not shown)
Line 10: Line 10:
=Background=
=Background=


See http://wiki.samba.org/index.php/Samba4/Linking_AD_and_unix_directories
See the [[Samba4/Linking_AD_and_unix_directories|discussion of various trust types available in AD]]


=Forest trust Design=


=Designs=
The most complete and sensible trust mechanism for this task is a 'Forest Trust'. This modal provides for mismatching schema, and mismatching functional levels, both of which are highly desirable (to avoid forced upgrades with the AD infrastructure).


There are two feasable designs for the IPA to AD trust:
[[image:forest-trust.png|left]]
* [[Samba4/Proposal_for_IPA_to_AD_forest_trust|Forest Trusts]]

* [[Samba4/Proposal_for_IPA_to_AD_MIT_trust|MIT Trusts]]
[[image:ipa-split.png|right]]

==Components==

The design consists of these parts:

===KDC===
A single KDC, representing the IPA realm. The KDC technology needs to support the all the different AD extensions (referrals to the other side of the forest trust in particular), and of course be in sync with all the other password handling systems.

Because Microsoft's extensions to Kerberos are not particularly invasive (they are pervasive, but perhaps surprisingly do not disrupt traditional Kerberos behaviour very much), no duplication of KDC services is required. Furthermore, creating two separate realms would simply create the complexity of both the Forest trust and the MIT trust proposals, as both a forest trust (to AD) and an MIT trust (to IPA) would be required, and IPA users would have two different principals, just as the MIT trust proposal would create.

===LDAP (port 389) server===
Samba4's LDAP server providing service on port 389

===LDAP Backend for IPA clients===
Some means of showing the existing schema to IPA clients, but not in conflict with the above.

Most likely this would be the existing Fedora DS server providing FreeIPA clients the existing service as currently provided, but on a different port (perhaps ldaps, or just another?)

Given the design with DNS and Kerberos, it is not possible simply to use a different IP address, unless that IP is not announced in the _ldap._tcp SRV record.

===DNS===
A single DNS zone, matching the IPA realm, with the extra AD details embedded as per the Samba4 provision.

====Reasoning====

Because this design calls for a single realm, and a single set of replicated KDCs, it makes best sense to match this with a single DNS zone. This also ensures that hosts trivially map to a realm, and that the SRV records for locating the KDC function easily and correctly.

====Consequences====

Note that because this is a single DNS zone, the _ldap._tcp SRV records must point at the AD server and the AD LDAP emulator (Samba4) on port 389, not FreeIPA. All servers (there can be multiple) pointed at by this record must run Samba4 on that port.

This is because non-Microsoft AD clients (at least) expect to use the _ldap SRV record, despite the separate tree under _msdcs. (Unsure of the MS client behaviour, but given the trouble the other clients will cause, it does not really matter).

===LSA Server===
Most of the LSA service must be available to trusted domain clients. Fortunately, if implemented fully for the standalone domain case, this should also cover most of the trusted domain cases too. Additional calls would clearly include the create/query trusted domain calls.

This is the most vital pipe for interdomain trust relations.

===NETLOGON Server===

Not only required for NTLM authentication (but clearly the most vital function it performs), the NETLOGON server also provides DC location and many other services. We should try to implement the full pipe here, save the NT4 SamSync services (old BDC replication).

===Other Samba4 DC services===
CIFS, CLDAP, and other RPC services to be provided by Samba4, as normal for a standalone DC

===Virtual Directory===
A mapping between the ultimate LDAP backend and the AD schema that Samba4 needs. If some composite schema is used, perhaps the IPA clients

===IPA servers===
SSSD or some other service to present IPA and AD users in a consistent namespace, client side. These need to contact the AD domains directly (using Samba3's winbind most probably), or via an RPC proxy on the servers.

The IPA clients and servers also need a modified GSSAPI able to both read the PAC, but also to stash it for use (as Samba3 does with winbind, but only for CIFS so far) as the authenticated provider of groups.

Alternately, perhaps the same RPC proxy could do a s2u4self call to do a separate lookup against AD.

By whatever method, the clients will be responsible to doing lookups that eventually target the AD and IPA servers simultaneously, to gain an accurate real-time view of the whole enterprise.

(By way of example, this is just as a Samba3 client in pure AD would have to contact all trusted domains and forests. )

===IPA Clients===

The IPA clients will need to be modified to us a Kerberos library that understands the AD referrals, so that access to servers in the AD realm, and access by AD users operates correctly across the trust.

The SSSD or similar will need to handle caching of the PAC for the login session, to get correct groups etc.

==Advantages==
This is a clean, complete solution. The user data is not synchronised, nor are shadow user entries created, but simply accessed in real time from it's native source. The PAC is used by both AD and IPA clients, and avoids extra lookup traffic.

=MIT Trusts design=

==Components==

===KDC===

The KDC will need to be modified at least to give referrals to the AD domain for user and machine requests.

===LDAP server===

Operating as current FreeIPA versions do.

===IPA servers===

Servers will use SSSD to lookup user identity information in AD, via a RPC proxy at the IPA server

===IPA clients===

Clients will need a Kerberos library capable of following referrals to find the AD servers.

The SSSD will need to lookup user identity information in AD, via a RPC proxy at the IPA server

===Windows server sync===

Something like AD-sync will need to operate, to keep shadow copies of all IPA users in AD. However, AD users will not need to be in IPA (this may lead to all users being in AD at some sites)

==Advantages==

Much less work than implementing Forest trusts

==Disadvantages==

Little change from the current situation with AD-sync

Latest revision as of 23:07, 15 February 2009

Purpose

To link FreeIPA to AD in a way that minimises replication of data.

Key assumptions

IPA and AD are both seperate DNS domains, seen by each other in the same company, that administrators which to join in such a way that users and services are easily accessed on both sides of the trust, using Kerberos.

That Kerberos is the only authentication protocol in use (that fallback to NTLM has been disabled or is unwanted)

Background

See the discussion of various trust types available in AD


Designs

There are two feasable designs for the IPA to AD trust:

Retrieved from "https://wiki.samba.org/index.php?title=Samba4/Proposal_for_IPA_to_AD_trust&oldid=3942"