Core of Single Sign-On (SSO)-technical reference of kerberos Authentication Protocol (I)

The Microsoft Windows Server 2003 operating system implements the authentication protocol for Kerberos version 5. Windows Server 2003 also extends public key authentication. The client for Kerberos authentication is implemented as a SSP (security support provider) that can be accessed through SSPI (Security Support Provider Interface. Initial User Authentication was integrated with Winlogon's Single Sign-On architecture. The Key Distribution Center of Kerberos is integrated with the Security Service on the domain controller DC (domain controller) of Windows Server 2003, KDC uses the Active Directory database of the domain as its security account database. The default Kerberos implementation requires the support of the Active Directory.

This topic explains how Windows Server 2003 supports the Kerberos V5 protocol and its extensions.

1. What is Kerberos authentication?

The Kerberos V5 authentication protocol provides an authentication mechanism (and mutual authentication mechanism) between the client and the server or between the server and the server)

Windows Server 2003 implements the Kerberos V5 authentication protocol as an SSP (Security Support Provider) that can pass the SSPS (security support provider Interface). In addition, windows Server 2003 also extends this protocol by using the public key certificates of the smart card for initial authentication.

The Key Distribution Center (KDC) of Kerberos uses the service database of the Active Directory as its own security account database. The default implementations of NTLM and Kerberos both require support from the Active Directory.

The Kerberos V5 Protocol assumes that the initial information exchange between the client and the server occurs in an open network environment. packets transmitted online can be monitored and modified at will. This hypothetical environment is very similar to the current Internet. Attackers can easily pretend to be a client or a server, and easily eavesdrop and tamper with communication between a legitimate client and the server.

Microsoft's Kerberos V5 protocol implementation is:

Windows Server 2003Default Identity Authentication

Kerberos V5 becomes the default authentication for Windows 2003. Windows Server 2003 also supports NTLM to support non-Kerberos operating systems such as Windows NT Server 4.0.

Based onRFC 1510And its revised draft

Kerberos protocol is a mature, widely used and open standard. The implementation of Microsoft Kerberos V5 follows the RFC standard, so it can provide interoperability with other implementations.

Scalability

The Kerberos architecture allows you to specify another or replaceable security solution. In addition, you can use the public key/private key of the smart card to provide the default shared security key process.

1. Benefits of Kerberos identity authentication

The Kerberos V5 protocol is safer, more flexible, and more effective than the NTLM protocol. The advantages of Kerberos authentication are:

1.1 identity assignment

When a Windows Service accesses resources for a client, it acts as the client. In most cases, a service on the local machine can access resources for the client, because both NTLM and Kerberos can provide the Service with information that needs to assume the client. However, distributed applications are designed to act as front-end services and connect clients to backend services on other servers. The Kerberos V5 protocol includes a proxy mechanism that allows services to act as clients to connect to services on other servers, NTLM does not have such a function.

Interoperability.

1.2 interoperability

Microsoft's Kerberos V5 implementation is based on the IETF Recommendation Standard Specification. In this way, the Kerberos V5 Implementation of Windows Server 2003 lays the foundation for the interoperation of other networks using the Kerberos V5 protocol.

1.3 more efficient authentication

For NTLM, to verify each client, the application server must connect to the domain controller to confirm the identity of the client. For the Kerberos V5 authentication protocol, the server does not need to connect to the domain controller. Correspondingly, the server can check the verification tickets provided by the client. The client can obtain a verification ticket for a specific service and use it repeatedly during a logon. The updatable session ticket replaces pass-through authenticatio (I don't know how to translate ).

1.4 mutual authentication

By using the Kerberos protocol, one end of the network connection can verify that the declaration of the other end of the network is its own entity. Although NTLM allows the server to verify the identity of the client, it does not provide the client to verify the identity of the server, nor does it provide the server to verify the identity of another server. NTLM is designed to assume that the server is a real network environment, but Kerberos does not.

2. Kerberos V5 protocol standard

The Kerberos Authentication Protocol originated from MIT decades ago and was developed by engineers of the Athena project. The first public release version is Kerberos version 4. After being widely used, protocol developers have released the fifth version of Kerberos.

Kerberos V5 is now the IETF standard. The implementation of Kerberos V5 in Windows Server 2003 strictly follows the standard defined in RFC 1510. In addition, the security token (security tokens) in Kerberos messages) the format and Mechanism follow the standard defined in RFC 1964.

The Kerberos V5 Protocol specifies the following mechanisms:

L verify the user identity. When a user needs to get access to a server right, the server needs to authenticate the user's identity and consider a scenario where the user claims that he is, for example, a Alice@tailspintoys.com. Because access to resources is based on identity-related permissions, the server must determine that the user is the user he claims.

L secure packaging username, username (the user's Master name, in this example is the Alice@tailspintoys.com), and the user's identity trust credential (credentials) is packaged in) in

L safe transmission of user trust credenl. After the ticket is encrypted, the Kerberos message transmits the user's credentials over the network ).

Note:

Although the Kerberos protocol verifies the user's identity, it does not authorize access. This is an important difference. In other cases, tickets, like driving licenses, provide identity and driving license at the same time. Kerberos tickets are only used to prove that this user is the user it claims. After the user's identity is confirmed, the local security permission will decide to grant the access permission or reject the access.

2.1. Key

Kerberos messages are encrypted by multiple encryption keys to ensure that no one can tamper with the customer's tickets or other data in Kerberos messages.

L Long-term key)

A key (only known to the target server and KDC) that is used to encrypt the key used by the client to access the ticket on the target server.

L Client/server session key)

A short-term, single-session key is the key established by KDC after the user's identity and permissions have been confirmed for the user's encrypted exchange information with a server.

L KDC/session key ).

It is a key shared by KDC and is used to encrypt messages between the user and KDC.

 

Kerberos V5 uses symmetric encryption and asymmetric encryption.

Because most Kerberos encryption methods are based on keys used only between KDC and users or between KDC and network services, Kerberos V5 is designed to adopt symmetric encryption, the same key is used to encrypt and encrypt messages.

Microsoft's Kerberos protocol enables limited asymmetric encryption. A private key/public key pair is used to encrypt and decrypt the initial verification information from the client or network service.

2.2 Kerberos Authentication prevents data packet Reuse

The Kerberos authentication mechanism establishes and securely transfers a trust credential with a client ticket (usually based on a unique timestamp). The trust credential is unique and valid for one use at a time. This limit minimizes the possibility of obtaining and reusing client bills or attempting to steal the customer's identity.

3. Kerberos V5 protocol Extension

Windows Server 2003 implements Kerberos V5 protocol extension. This extension replaces the conventional symmetric encryption key with a public key certificate during initial identity authentication. This improvement allows the Protocol to support interactive login with a smart card. Public key authentication extension is based on the IETF Working Group's draft protocol.

4. Kerberos authentication technologies

Shows how Kerberos Authentication works with other technologies in Windows Server 2003. Depending on whether the client or server application is a user-mode or a kernel-mode application, they use Secur32.dll or Ksecdd respectively. sys, call SSPI to communicate with Local Security Authority Subsystem (LSASS)

 

The following table describes the components involved in kerberos authentication.

Component	Description
Kerberos. dll	The Protocol SSP is used for password or smart card interactive login to implement industrial standards. It is also the preferred authentication method for Windows 2000 and Windows Server 2003.
Kdcsvc. dll	The Kerberos Key Distribution Center (KDC) service, which responds to the application for a client ticket authorization ticket (ticket-granting tickets)
Ksecdd. sys	Core security device driver for communications between users and LSASS in kernel-mode
Lsasrv. dll	The LSA Service enforces security policies and acts as the LSA Security Package Manager.
Secur32.dll	Secur32.dll is a component that implements SSPI in user mode.

Windows Server 2003 uses SSP to implement the Kerberos V5 authentication protocol. It is a dynamic link library (DLL) provided by the operating system. The system uses Kerberos SSP and Kerberos. dll is the first choice for authentication. The LSA creates a secure context for an interactive Login User. To support the signing and encapsulation of Kerberos information, another Kerberos SSP instance is loaded in the running user security context.

Because the Kerberos authentication protocol is the preferred protocol for Windows Server 2003, all domain services support Kerberos SSP, including:

L The Active Directory of AD must use LDAP (Lightweight Directory Access Protocol)

L remote service or workstation management using RPC

L customer-Server Authentication

L use Common Internet File System/server message block (CIFS/SMB) for Remote File Access

L Distributed File System Management

L IIS intranet Authentication

L Internet Protocol security (IPSec) security Verification

L requests to issue certificates to Domain Users and computers

 

5. Kerberos authentication depends on

This section discusses the Kerberos Authentication dependencies and their relationships with the book.

 

5.1 Operating System

Kerberos Authentication relies on client functions, which are built on Windows Server 2003, Windows XP, and Windows 2000 operating systems. If a client, Domain Controller, or target server runs on an earlier operating system, Kerberos authentication is not supported.

5.2 TCP/IP network connectivity

Once Kerberos Authentication occurs, a TCP/IP network connection must be established between the client, the domain controller, and the target server. For more information about TCP/IP, see "TCP/IP Technical Reference."

5.3 Domain Name System

The client uses the fully qualified name fully qualified domain name (FQDN) to access the domain controller. The DNS must ensure that the client can obtain the address of this domain controller. It is best not to use DNS host files. For more information about DNS, see "DNS Technical Reference ."

5.4 domain activity directory

Kerberos Authentication does not support worse operating systems, such as Windows NT 4.0. You must use the user and computer in the Active Directory Service. The local account and Windows NT domain account cannot be authenticated by Kerberos.

5.5. Time Service

To ensure normal use of Kerberos authentication, all domains in the network and the forest use the same time source to ensure the time synchronization of all computers in the network. An Active Directory domain controller acts as an authoritative time source and ensures that all domains have the same time. For more information, see "Windows Time Service Technical Reference ."

5.6 service subject name

The service entity name (SPNs) is the unique identifier of the Service Running on the server. Each service that uses Kerberos authentication requires an SPNs so that the client can identify the service on the network. Without setting SPNs correctly, Kerberos authentication is impossible.