internal
Stanford Windows Infrastructure - Authentication
Authentication is the process of verification of identity. This page provides a brief description about Authentication services provided by the Stanford Windows Infrastructure.
SUNet ID Integration
SUNet IDs are supported for logon to the Stanford Windows Infrastructure in two ways.
- The production forest trusts the stanford.edu MIT Kerberos version 5 realm to assert identity. The Windows Infrastructure provides Kerberos interoperability by linking those kerberos principals to the corresponding Windows user account (in the root domain) when request for resources in the Infrastructure forest is made. This allows for Windows Infrastructure users to specify stanford.edu as the authenticating realm when establishing initial credentials. This authentication path only supports Kerberos Version 5
- Windows Infrastructure user accounts are created and managed by the SUNet ID processes. This allows for Windows Infrastructure users to specify win.stanford.edu (or WIN) as the authenticating realm when establishing credentials. This authentication path supports all available authentication protocols
Kerberos Version 5 Protocol
Kerberos Version 5, also known as K5 or Kerberos v5, is the preferred authentication protocol for Windows when operating in a domain environment. Every Windows Infrastructure domain controller is also a Kerberos Key Distribution Center or "KDC". Microsoft has added extensions into the vendor extension area of the Ticket structure to support the Microsoft credential system (Authorization).
Features of Kerberos v5 as implemented by Microsoft:
- Provides for mutual authentication (KDC, requested service, and client all have to prove who they are).
- Ticket usage can be restricted.
- Protocol provides protection against replay by a third party.
- Passwords are never transmitted in any form.
More info on Kerberos:
Kerberos Home page at MITMicrosoft Technical Reference: Kerberos
Kerberos v5 RFC 1510
Kerberos v5 RFC 1964
NTLMv2 Protocol
NTLMv2 stands for NT LAN Manager authentication protocol version 2. This is a challenge-response based protocol. In a challenge-response protocol, the client generates a response using the server challenge and a secret value that the client and server both know (like a password) and sends it back for validation. Security features were added to the protocol in version 2 to provide for stronger protection of encryption keys and challenges. LM and NTLMv1 protocols are not allowed in the Stanford Windows Infrastructure.
- Protocol provides protection against man-in-the-middle attacks (hostile system intercepting authentication network traffic to pose as the authentication server)
- Protocol provides protection against replay by a third party.
- Passwords are never transmitted in any form.
Simple and Protected GSS-API Negotiation (SPNEGO) Protocol
This protocol, also known as "Windows Integrated" or "Negotiate" authentication is a provider layer that allows the mutual selection of an authentication protocol by the client and server. For Windows, SPNEGO tries Kerberos first, then "falls back" to NTLMv2.
SPNEGO RFC 2478Trust and Delegation
Trust relationships specify how domains or realms can assert identity for each other. In Microsoft terms a domain with an inbound trust or "Trusted" domain can assert identity for a domain with an outbound trust or "Trusting" domain. Trust can be transitive - allowing a 3rd domain to accept the assertions of the trusted domain based on it's trust to the trusting party. Windows also allows for the trusting domain to constrain an external trust (a trust to a realm or domain outside of an AD forest) such that only certain identities from the trusted domain can authenticate to computers.
In the Stanford Windows Infrastructure, as is default, all of the domains have inbound and outbound transitive trusts with each other. Also, the Windows Infrastructure has transitive inbound and outbound trust with the MIT K5 realm. Temporary external trusts are created as needed for migrations.
Delegation is the ability for one entity to authenticate on behalf of another entity. This is typically used for a service to act on the behalf of a user. Allowing a service to act as a delegate creates a potential security risk that should carefully be evaluated. If used, the delegate's allowed use of credentials should be constrained as much as possible.
Other Authentication protocols
Certificate Logon, also known as "pkinit" or "Smart Card Login" is not supported by the Stanford Windows Infrastructure at this time.LDAP and Web servers support Basic and Digest authentication. Both of these authentication protocols are not secure and should be avoided. When absolutely necessary, authentication must be performed using an encrypted channel (IPSec or TLS/SSL) to keep a third party from acquiring the credential information.
- Basic authentication. Basic authentication consists of an encoded string containing the users username and password. The web server decodes that string and performs authentication
- Digest/Advanced Digest authentication. Digest authentication is a
challenge-response protocol. The older version requires passwords to be
encrypted in a reversible format and thus is not supported. The
"Secure" or "Advanced" Digest authentication method is new for Windows
Server 2003 and implements a more secure algorithm.
Microsoft Technical Reference: Digest Authentication
