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

From SambaWiki
Line 44: Line 44:
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.
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===
====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.
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.

Revision as of 23:18, 10 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 http://wiki.samba.org/index.php/Samba4/Linking_AD_and_unix_directories

Forest trust Design

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).

Forest-trust.png
Ipa-split.png

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.

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