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, linking the Kerberos principals to the corresponding Windows user account in the root domain. This occurs when the request for resources in the Infrastructure forest is made, allowing 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 SUNetI D 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.
Trust and delegation
Trust relationships specify how domains or realms can assert identify for each other. In Microsoft terms, a domain with an inbound trust (also known as a "Trusted" domain) can assert identity for a domain with an outbound trust (also known as a "Trusting" domain). Trust can be transitive — a third domain can accept the assertions of the trusted domain based on that domain's trust of the trusting party. Windows also allows for the trusting domain to constrain an external trust, which is 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 domains have inbound and outbound transitive trusts with each other. The Infrastructure also has transitive inbound and outbound trust with the MIT Kerberos version 5 realm. Temporary external trusts are created as needed for migrations.
Delegation, the ability for one entity to authentication on behalf of another entity, is typically used for a service to act on the behalf of a user. Allowing a service to act as a delegate, however, creates a potential security risk that should be carefully evaluated. If used, the delegate's allowed use of credentials should be constrained as much as possible.
Kerberos version 5
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 (KDC). Microsoft has added extensions into the vendor extension are of the Ticket structure to support the Microsoft credential system, a form of 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.
For more information about Kerberos, see these links:
NTLM v2 protocol
NTLM v2 stands for NT LAN Manager authentication protocol version 2, 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 NTLM v1 protocols are not allowed in the Stanford Windows Infrastructure.
The NTLM v2 Protocol provides protection against replay by a third party and against man-in-the-middle attacks, in which a hostile system intercepts authentication network traffic to pose as the authentication server. Additionally, passwords are never transmitted in any form.
More information about this protocol can be found on Microsoft's website.