Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
CIFS Service Kerberos user authentication for AD users
1.2. Name of Document Author/Supplier:
Author: Natalie Li
1.3 Date of This Document:
07 December, 2009
1.4. Name of Major Document Customer(s)/Consumer(s):
PSARC
CIFS team
1.5. Email Aliases:
1.5.1. Responsible Manager: Barry.Greenberg at Sun.COM
1.5.2. Responsible Engineer: Natalie.Li at Sun.COM
1.5.3. Marketing Manager:
1.5.4. Interest List: cifs-team at sun.com
4. Technical Description:
4.1. Details:
This fast track proposes Kerberos user authentication support for
Active Directory (AD) user accounts when using the CIFS Service
(PSARC/2006/715) in domain mode. The CIFS Service currently supports
pass-through authentication using the NTLMv2, NTLM, LMv2 and LM
challenge-response algorithms ([8] cifs-design_1_2.pdf Appendix D).
As with Windows, the Solaris CIFS Service can operate in workgroup
(standalone) mode or domain mode. In workgroup mode, local
authentication is performed against a local password database.
In domain mode, both local and domain users are supported: local
users are authenticated as in workgroup mode, domain users are
authenticated using pass-through authentication to a domain controller.
Microsoft introduced Kerberos user authentication [7] for SMB in
Windows 2000, to supplement the existing authentication mechanisms
used in earlier versions of Windows: NTLMv2, NTLM, LMv2 and LM.
These earlier authentication mechanisms are retained in Windows to
support standalone or workgroup environments and for backward
compatibility.
Clients negotiate one of two mechanisms during SMB protocol dialect
negotiation and session setup:
- Basic security, which is based on the NTLM challenge-response
exchange ([8] cifs-design_1_2.pdf Appendix D)
- Extended security ([1] section 4.1), which supports NTLM or Kerberos.
Despite the name, extended security is not a security mechanism per
se; it is a transport for authentication protocols such as NTLM or
Kerberos ([7] section 5.1).
When using Kerberos user authentication, the SMB client prompts the
user for credentials (user name and password), which are used to obtain
a Kerberos ticket-granting ticket (TGT) from an Active Directory domain
controller that is running the KDC service. The TGT is then used to
acquire service tickets, which are used to prove the user's identity
to application servers (such as the CIFS Service).
Kerberos is primarily an authentication protocol, not an authorization
protocol, but Microsoft has extended the base Kerberos protocol to
include authorization data, which is encoded within the Privilege
Attribute Certificate (PAC). The PAC conveys authorization related
information provided by an Active Directory domain controller, such
as group membership and privileges. See [4] for more information on
the PAC.
With the recent resync of Kerberos on Solaris with the MIT Kerberos
Consortium's release of version 1.7 (PSARC/2009/418) Solaris kerberized
application servers can extract the PAC from a service ticket embedded
in KRB_AP_REQ requests, and subsequently generate user credentials for
authorization purposes. The use of the PAC to carry authorization data
should provide a performance benefit during session setup because,
unlike pass-through authentication, the SMB server does not have to
make MSRPC calls to obtain that information from a domain controller.
The Solaris CIFS Service will be enhanced to offer extended security
and Kerberos V5 user authentication for AD domain user accounts,
which requires underlying support for GSSAPI/SPNEGO and GSSAPI/KRB5.
The Simple and Protected GSSAPI Negotiation (SPNEGO) mechanism is widely
used for security protocol or authentication mechanism selection. In
SMB, it is used to select either NTLMSSP or Kerberos [6].
The following diagram and subsequent description provide more details
on the architecture and changes being proposed.
|
|
V
+-------------------+
| Extended Security +---------------------------+
+---------+---------+ |
| |
extended security=yes extended security=no
| |
+---------------------+ |
| | |
SPNEGO token=yes SPNEGO token=no |
| | |
V | |
+-------------------+ | |
| SPNEGO | | |
+---------+---------+ | |
| | |
+-----------------+-------------+ | |
| | | |
V V V |
+---------------+ +-------------------------------+ |
| Kerberos V5 | | NTLMSSP | |
+---------------+ +---------------+---------------+ |
| |
V V
+--------------------------------------------+
| lmauth_level |
+---------------+----------------------------+
|
V
+-------------------------------+
| NTLMv2, NTLM, LMv2, LM |
+-------------------------------+
The CIFS Service currently supports NTLMv2, NTLM, LMv2 and LM
authentication for both local and domain users. The lmauth_level
controls the authentication algorithm offered to clients as described
in smb(4). In order to provide a similar level of support when
Kerberos AD domain user authentication is introduced, the CIFS Service
will have to support both extended security and NTLMSSP [5]. The NT LAN
Manager Security Support Provider (NTLMSSP) is a wrapper protocol
used to facilitate the challenge-response authentication mechanisms
when using SPNEGO. For Microsoft interoperability, the CIFS Service
will also accept raw NTLMSSP messages that are not embedded in
SPNEGO messages ([2] Section 3.2.5.2 "Universal Receiver").
The following Service Principal Names (SPNs) will be registered with
Active Directory during domain join to indicate that the CIFS Service
runs under the system account security context. This is to satisfy
Windows client requests for a CIFS Service service ticket using host,
cifs or NetBIOS SPNs.
cifs/<hostname>.<fqdn>
host/<NetBIOS name>
The following entries will be added to the local keytab file
/etc/krb5/krb5.keytab during domain join:
cifs/<hostname>.<fqdn>@<REALM>
<NetBIOS name>$@<REALM>
kclient(1M) [10] has recently been modified to include the proposed
SPNs in the core SPN set in order to support this fast track. See [5]
and [6] in section 4.2.
smbadm(1M), CIFS service domain join utility, will be modified
accordingly as part of this Kerberos user authentication for AD users
support.
The process for Kerberos user authentication and session setup with
extended security negotiated will be as follows:
i) Upon receipt of a SmbNegotiate request from a client that
supports extended security, the CIFS Service will send an
extended reply with the initial SPNEGO negotiation token
containing an ordered list of mechanisms supported by the
server in decreasing preference order and the server's
preferred principal name. For more information on SPNEGO
see [2] (NegTokenInit2 section) and [6].
ii) Upon receipt of an extended SmbSessionSetupX request, the
CIFS Service will decode the request and pass the incoming
GSS context token to the GSS-API acceptor for security
context establishment. See [2], section 4.12. With
Kerberos authentication, the CIFS Service doesn't need to
contact a domain controller, which results in faster
connection establishment.
iii) Upon successful user authentication via Kerberos, an access
token is generated from the service ticket PAC, avoiding the
need for MSRPC calls to obtain group and privilege data from
the domain controller.
iv) For SMB signing, the session key extracted from the GSS
security context will be used as the Message Authentication
Code (MAC) key to verify the signature of the incoming SMB
messages and to sign outgoing SMB messages. Previously,
the MAC key was computed using both the NTLM user session
key returned by the DC, after successful pass-through
authentication, and the NTLM challenge-response in the client's
SmbSessionSetupX request. See [1] (Message Signing Example)
for more information on SMB signing.
v) The CIFS Service will send extended SmbSessionSetupX replies
that carry an outgoing GSS context token. Upon receipt of a
positive response, clients can use the GSS context token to
verify the server's identity. On error, clients might recover
from a logon failure by interpreting the Kerberos error code
and data presented in the context token, which is actually an
error token returned by the krb5 security mechanism.
4.2. Bug/RFE Number(s):
[1] RFE: 6791210 CIFS Service Kerberos user authentication for AD users
[2] RFE: 6791165 Extended Security
[3] RFE: 6906492 NTLMSSP support
[4] Bug: 6791642 Unable to connect to the CIFS server using
\\servername.fqdn
[5] Bug: 6824434 Unable to accept context establishment initiated by
Windows 2000 clients
[6] Bug: 6405422 kerberosv5_b/interop Solaris acceptors fail in AD-KDC
environments when using non-"host" services (e.g.
"cifs")
4.4. Out of Scope:
Support for non-AD users is out of scope.
4.5. Interfaces:
Exported Interfaces:
| Proposed | Specified |
| Stability | in what |
Interface Name | Classification | Document? | Comments
===================================================================
cifs/<hostname>.<fqdn> | Committed | This document | /etc/krb5/
<NetBIOS name>$ | | | krb5.keytab
| | | See klist(1)
Imported Interfaces:
| Proposed | Specified
| Stability | in what
Interface Name | Classifi- | Document?
| cation |
===================================================================
libgss.so(3LIB) | Committed | PSARC/1996/059
| |
gss_inquire_sec_context_by_oid | Volatile | PSARC/2009/418
- for SMB signing | |
| |
gsskrb5_extract_authz_data_from_sec_context| Contracted | contract [11]
| Project |
| Private |
| |
libkrb5.so(3LIB) - for PAC manipulation | Volatile | PSARC/2009/418
Both mech_krb5.so and mech_spnego.so are used indirectly via libgss.so
for the following purposes:
1. GSSAPI/SPNEGO
SPNEGO is used for NegTokenInit2 [2] token generation and security
mechanism negotiation [6].
2. GSSAPI/KRB5
Kerberos V5 [7] is used for security context establishment.
4.11. Security Impact:
This project will use GSSAPI/SPNEGO/KRB5 as the security model.
The benefits gained by using Kerberos authentication are:
1. Stronger cryptography than NTLM challenge-response based
authentication
2. Mutual authentication. Kerberos allows the client and server
to verify each others identity. NTLM only allows servers to
verify the identity of clients.
5. Reference Documents:
[1] MS-SMB: Server Message Block (SMB) Protocol
http://msdn.microsoft.com/en-us/library/cc246231(PROT.13).aspx
[2] MS-SPNG: Simple and Protected Generic Security Service
Application Program Interface Negotiation Mechansim
http://msdn.microsoft.com/en-us/library/cc247021(PROT.13).aspx
[3] MS-KILE: Kerberos Protocol Extensions
http://msdn.microsoft.com/en-us/library/cc233855(PROT.13).aspx
[4] MS-PAC: Privilege Attribute Certificate Data Structure
http://msdn.microsoft.com/en-us/library/cc237917(PROT.13).aspx
[5] MS-NLMP: NT LAN Manger (NTLM) Authentication Protocol Spec
http://msdn.microsoft.com/en-us/library/cc236621(PROT.13).aspx
[6] RFC 4178: The Simple and Protected Generic Security Service
Application Program Interface (GSS-API) Negotiation Mechanism
http://www.ietf.org/rfc/rfc4178.txt
[7] RFC 4120: The Kerberos Network Authentication Service (V5)
http://www.ietf.org/rfc/rfc4120.txt
[8] PSARC/2006/715 CIFS Service
http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2006/715/
[9] PSARC/2008/418 Kerberos V5 PAC API
http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2009/418/
[10] PSARC/2007/401 kclient version 2
http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2007/401/
[11] Contract for contract private interfaces (PSARC/2009/418)
http://sac.sfbay/PSARC/2006/715/contracts/cifs_psarc2009_418_contract.txt
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
