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

From SambaWiki
(clarify how DNS must be configured.)
Line 32: Line 32:


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

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


===Other Samba4 DC services===
===Other Samba4 DC services===

Revision as of 22:56, 8 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).

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

DNS

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

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

Other Samba4 DC services

CIFS, CLDAP, and 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.

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