Difference between revisions of "Projects/Samba4 Port"

Latest revision as of 08:40, 18 September 2009

Introduction

Samba4 aims to provide a complete OSS replacement for Active Directory. Samba4, like earlier versions of Samba, uses Heimdal Kerberos. The Samba4 Port project proposes to enable Samba4 to use MIT kerberos as an alternative. The near-term goal is that mixed krb5+AD deployments could use Samba4 to provide better interoperation between AD realms and MIT-krb5 realms.

Use case: For example, suppose a kerberos customer is deploying a network with mixed operating systems using kerberos and would want to use one KDC for all of them. In this case, a single MIT Kerberos deployment should be able to support both traditonal UNIX clients and servers, intermixed with Windows clients and Samba servers:

1. The Windows clients should be able to use the MIT KDC(s) as AD servers, so as to authenticate themselves to Samba file-servers and to Windows servers;
2. A Windows client's tickets will carry PACs, as usual for AD;
3. The UNIX clients should be able to access the KDC as a traditional non-AD-style KDC, so as to access UNIX services securely;
4. A UNIX client's ticket will not carry a PAC, except when the UNIX client accesses a Windows server (Rationale) .

The Samba4 team, the MIT Krb Consortium, RedHat, Ubuntu, and Sun all have shown some interest in this Samba4 Port project. Here is a table showing which OS platforms are supported by Samba4, Heimdal, and MIT kerberos. Summary: MIT-krb5 & Samba4 both run on Mac OS X, NetBSD, Debian, RedHat, Ubuntu, & Solaris.

Concise to-do list

This is a condensed version of the task-list offered by Samba4's Andrew Bartlett, containing only what hasn't yet been done already by MIT.

The two big chunks of work are LDAP Driver and Replacing / improving MIT's DAL, but the DAL work may not be needed.

Replace the MIT KDC's LDAP driver

Samba4's LDAP driver for the MIT KDB needs to know how to do AD's intricate naming:

1. Canonicalization of server names, user-names, and realm names. MIT 1.7 already supports canonicalization.
2. AD-style aliases for HOST/ service names.
3. Implicit names for Win2k accounts.
4. Principal "types": client / server / krbtgs
5. Flexible server-naming
6. Keytabs & name-canonicalization

Most or all of Heimdal's LDAP driver code is in three Samba4 source files, ~1000 lines in all.

Small changes

Of the things on this list, only NTLM support (bullet 2) is needed for the Samba4 KDC port. The other tasks are all application-library stuff, and arguably aren't needed at all, because Samba3 already works well with MIT application libraries.

1. MIT library changes
2. Samba4/AD libraries: NTLM support. See also this Sept-2009 NTLM thread (this implies to me that a GSS NTLM mech is not an immediate requirement - LH)
3. Key-handling changes]
4. Extra Krb library functions
5. Error-handling, logging, testing

Use 1.7's AD-support features

This stuff should already just work:

1. PAC handling;
2. AD-style name canonicalization;
3. NT-ENTERPRISE names, which carry two realm-suffixes;
4. CHECK_POLICY/AUDIT methods (needed for TGS access-control);
5. DCE_STYLE Challenge/Response handshakes: see Krb lib & GSSAPI.
6. Accept legacy Samba3 clients' bad GSSAPI checksums;
7. Principal-manipulation functions;
8. State-machine safety;

Controversial proposed changes for the port

Maybe: Improve or replace MIT's DAL

Rewrite the MIT KDC's Data-Abstraction Layer (DAL), mostly because the MIT KDC needs to see & manipulate more LDAP detail, on Samba4's behalf;

Maybe, or not: Add a KDC-as-library API

Samba4 currently runs as a single process, and Samba4's smbd invokes the Heimdal KDC via a libkdc interface (KDC as library).

1. Rationale:
   1. smbd uses the libkdc interface to configure the KDC, both at startup & during runtime.
   2. Samba4's build/test environment uses libkdc's socket-passing, to simulate network traffic.
2. Andrew Bartlett says this libkdc interface is "nice to have", but not essential for getting the port to work.
3. Tom Yu says adding a libkdc interface to MIT's code would be a lot of work, but would tie naturally into code-cleanup work that MIT wants to do, anyway.
4. Sam Hartman says he needs the libkdc interface, too, for his work on PK-U2U (but not immediately).
5. Another way, which Simo dismisses on Samba4's behalf: Samba can use iptables remapping, but only for kdc packets, so that Samba acts as a router between the AD client and the KDC. This would work for MIT-krb & for Heimdal.
6. If we do have to build a libkdc interface for MIT's KDC, Samba4 will need the KDC to use Samba's socket library correctly.

Later: TGS access-control

MIT krb will need to support these AD features, once Samba4 does. Alternatively, this could be seen as an opportunity for MIT-based Samba4 to surpass Heimdal-based Samba.

1. Add HBAC to the TGS, so that Samba4 can refuse TGTs to kinit, based on time-of-day & IP-addr constraints;
   1. DTD: This is natural; the TGS should enforce its own access-control, as all other services do.
   2. TGS-HBAC is part of the rationale for rewriting the DAL.
2. Failed-kinit counts: Add a KDC heuristic for tracking intervals between kinits, so that Samba4 can enforce AD's unified account-lockout on kinit. Samba4 already does lockouts for other PW-based authentication methods (NTLM, LDAP simple bind, etc).

Samba's use of Heimdal symbols, with MIT differences

Samba4 uses around 265 Heimdal symbols:

1. 150 functions,
2. 45 structs & typedefs, and
3. 70 macros & enums.

Of these, roughly half present problems for the port:

1. 25 symbols have different definitions in the MIT & Heimdal trees.
2. 110 symbols are missing from MIT's krb5 tree.

Samba4 Interfaces with Heimdal

1. Samba4's Database Interfaces enable Heimdal to use Samba4's directory data, whether the directory is stored in LDAP or in local disk files.
2. Heimdal's libkdc Interface gives Samba4 a direct subroutine interface to the Heimdal KDC, with the KDC running as part of the Samba4 process.