欢迎您访问 最编程 本站为您分享编程语言代码，编程技术文章！

热门搜索/Hot Search

您现在的位置是： 首页

登录和身份验证技术（windows 身份验证和授权）

最编程 2024-07-06 22:50:07
...

The SSPI in Windows Server 2003 provides a mechanism that carries authentication tokens over the existing protocol, thus eliminating the need for communicating parties to specify a network protocol for use during authentication. When two parties need to be authenticated so that they can communicate, the requests for authentication are routed to the SSPI, which completes the authentication process, regardless of the network protocol currently in use.

Any application can make a request of the SSPI. Each of these requests goes through the SSPI, for example:

  • Winlogon sends requests to the Local Security Authority (LSA), which obtains tickets to access the local computer.
  • Internet Explorer obtains tickets to access information about a Web site.
  • An LDAP client obtains tickets to enable access to information in an x500 directory, such as Active Directory.

Some applications integrate use of the SSPI into their authentication designs. When such applications need to authenticate a user, they ask the SSPI to complete the authentication by using specific parameters, such as the user’s name and secret key (if they were not cached from a previous logon), and the service that the user wants to access. The SSPI receives the request, examines its contents, and passes the request to the SSP specified in the request. The SSP handles the details of the authentication and sends a success or failure message back to the SSPI, which relays the message back to the application that initially requested authentication. SSPI enables an application to use various security models available on a computer or network without changing the interface to the security system.

For example, if a client has a service ticket for a server for which the preferred authentication protocol is Kerberos, and the client wants to issue that server a remote procedure call (RPC), the client’s Kerberos SSP generates a request message based on standard GSS-API (RFC 1964) calls, which the application sends to the server. When the server receives the request, the server passes the ticket to the Kerberos SSP. The client routes the reply token to its SSP, which then evaluates and manages the contents of the reply. The server and the client know nothing about the contents of the token that is used to enable secure communication, because this information is handled by the SSP. The details of authentication are handled behind the scenes, and the results of the authentication process are passed back to the applications.

Security Support Provider Selection

The SSPI in Windows Server 2003 can use any of the five protocols — Negotiate, Kerberos, NTLM, Schannel, and Digest — that it supports. However, because not all operating systems support the same SSP packages that Windows Server 2003 supports; clients and servers must negotiate to use a protocol that they both support. Windows Server 2003 prefers clients to use Kerberos, a strong standards-based protocol, when possible, but continues to allow clients that do not support Kerberos, such as Windows NT 4.0 clients, to authenticate.

Before authentication can take place, however, the two communicating computers must agree on a protocol that they both can support. For any protocol to be usable through the SSPI, each party must have the appropriate SSP. For example, in order for a client and server to use the Kerberos authentication protocol, they must both support Kerberos V5. Windows Server 2003 uses the function EnumerateSecurityPackages to identify which SSPs are supported on a computer and what the capabilities of those SSPs are.

The selection of an authentication protocol can be handled in one of two ways, each of which is described in more detail below:

  • A single authentication protocol can be specified.
  • The negotiate option can be used to allow the parties to attempt to find an acceptable protocol. This is based on the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO, RFC 2478).
Single Authentication Protocol Specified

When a single acceptable protocol is specified, the server allows only one acceptable authentication method for the exchange. If the client does not support the protocol specified, the communication fails. When a single acceptable protocol is specified, the authentication exchange takes place as follows:

  1. The client requests access to a service.
  2. The server replies with an authentication challenge in which it specifies the protocol that be used.
  3. The client examines the contents of the reply and checks to determine whether it supports the specified protocol. If the client does support the specified protocol, the authentication continues. If the client does not support the protocol, the authentication fails, regardless of whether the client is authorized to access the resource.

For example, if a Windows Server 2003 client received a reply that specified the Kerberos protocol, the authentication exchange could proceed. On the other hand, if a Windows NT 4.0 client received the same reply, the authentication exchange would fail, because computers running versions of Windows earlier than Windows 2000 do not support Kerberos authentication. If the specified protocol fails, then negotiation is needed.

Negotiate Option Is Used

When the authentication begins with the option to negotiate for an authentication protocol, the SPNEGO exchange takes place as follows:

  1. The client requests access to a service.
  2. The server replies with a list of authentication protocols that it can support and an authentication challenge based on the protocol that is its first choice. For example, the server might list Kerberos and NTLM, and send a Kerberos challenge.
  3. The client examines the contents of the reply and checks to determine whether it supports any of the specified protocols. 
    • If the client supports the preferred protocol, authentication proceeds.
    • If the client does not support the preferred protocol, but does support one of the other protocols listed by the server, the client lets the server know which authentication protocol it supports, and the authentication proceeds.
    • If the client does not support any of the listed protocols, the authentication exchange fails.

For example, if the server specified Kerberos and NTLM, and returned a Kerberos challenge, a Windows Server 2003 client could immediately authenticate by using Kerberos. A Windows NT 4.0 client could negotiate to complete the authentication exchange by using NTLM.

Kerberos SSP

The Kerberos SSP (Kerberos.dll) is the first choice for authentication in Windows Server 2003. The Kerberos SSP uses the Kerberos V5 authentication protocol (RFC 1510).

Because Kerberos is the default authentication protocol for Windows Server 2003, all domain services support the Kerberos SSP, which includes:

  • Active Directory queries using the Lightweight Directory Access Protocol (LDAP).
  • Remote server or workstation management using RPC calls.
  • Print services.
  • Client-server authentication.
  • Remote file access using Common Internet File System/server message block (CIFS/SMB).
  • Distributed file system management and referrals.
  • Intranet authentication to Internet Information Services (IIS).
  • Security authority authentication for Internet Protocol security (IPSec).
  • Certificate requests to Certificate Services for domain users and computers.

NTLM SSP

Windows Server 2003 supports the NTLM SSP, Msv1_0.dll, to enable clients running versions of Windows earlier than Windows 2000 to authenticate. NTLM is the default authentication protocol for Windows NT 4.0. The NTLM SSP includes the NTLM and NTLMv2 authentication protocols.

Windows Server 2003 can use the NTLM SSP for the following:

  • Client/server authentication
  • Print services
  • File access using CIFS/SMB
  • Secure RPC/DCOM-based services

Negotiate SSP

Microsoft Negotiate is a security support provider (SSP) that acts as an application layer between the Security Support Provider Interface (SSPI) and the other SSPs. When an application calls in to the SSPI to log on to a network, it can specify an SSP to process the request. If the application specifies Negotiate, Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.

Negotiate implements RFC 2478, “The Simple and Protected GSS-API Negotiation Mechanism.”

Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos by default unless Kerberos cannot be used by one of the systems involved in the authentication or the calling application did not provide sufficient information to use Kerberos.

Secure Channel (Schannel) SSP

The Schannel SSP is used for access to Web-enabled services, such as mail or personal information served on Web pages.

The Schannel SSP, which includes a suite of four authentication protocols, uses public key certificates to authenticate parties. When authenticating parties, Schannel SSP selects one of the four protocols in the following order of preference:

  • Transport Layer Security (TLS).
  • Secure Socket Layer (SSL) version 3.0.
  • Private Communications Technology (PCT). PCT is disabled by default in Windows Server 2003.
  • SSL version 2.0.

The protocol that is selected is the preferred authentication protocol that both parties can support. For example, if a server supports all four Schannel protocols and the client supports only SSL 3.0 and SSL 2.0, the authentication process uses SSL 3.0.

Digest SSP

Digest SSP (Wdigest.dll) is the preferred authentication protocol for certain applications, such as LDAP and HTTP. Digest SSP is used for the following:

  • Internet Explorer (IE) and Internet Information Services (IIS) access.
  • LDAP queries.

Passport SSP

Windows Server 2003 contains no specific Passport SSP. Instead, passport authentication is enabled by an Internet Server Application Programming Interface (ISAPI) DLL called Passport.dll that captures and processes any cookie information that contains passport credentials.

      

Authentication Protocols

Each authentication protocol is composed of a series of steps, used by two or more parties, that verifies the identity of one or more of the parties.

The authentication process is vulnerable to numerous types of security attacks. For example, an attacker who has access to authentication information can steal keys to the network, modify messages, or replay old messages.

The authentication protocols in Windows Server 2003, which include Kerberos, NTLM, Schannel, Digest, and Passport, are designed to address potential security threats by verifying the identities of one or more of the communicating parties.

Windows Server                       2003 Authentication Protocols        

 

Authentication Protocol Description

Kerberos V5 authentication

An industry standard protocol that is used with either a password or a smart card for interactive logon. It is also the default method of network authentication for services in Windows 2000, Windows XP, and Windows Server 2003.

Digest authentication

An industry standard that is used in Windows Server 2003 for Lightweight Directory Access Protocol (LDAP) and Web authentication that transmits credentials across the network as an MD5 hash or message digest.

Negotiate

Negotiate implements RFC 2478, “The Simple and Protected GSS-API Negotiation Mechanism.”

Currently, the Negotiate security package selects between Kerberos and NTLM. By default, Negotiate selects Kerberos unless Kerberos cannot be used by one of the systems involved in the authentication, or the calling application did not provide sufficient information to use Kerberos.

NTLM authentication

A challenge response protocol that is used to provide compatibility with versions of Windows earlier than Windows 2000.

Passport authentication

A user-authentication service that provides a Web-based authentication mechanism enabling Web-services to offer a single sign-in service.

Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication

A protocol that is used for Web-based server authentication, such as when a user attempts to access a secure Web server.

Each of these protocols is used in different ways in Windows Server 2003 to promote secure communication in a network environment that is not secure.

      

Logon Authentication Scenarios

It is not possible to use a computer that is running Windows Server 2003 without using at least some system services. To use a system service, the account must be a client of the service, and all clients must first be authenticated by the service. Authentication requires the service to know the user’s credentials.

On computers running Windows Server 2003, system services can run under various accounts depending on the way that the applications are written. For example, a computer can access domain resources by using the network service, local system, or domain user accounts. Domain users who log on interactively must also be assigned the appropriate permissions before they can access the computer’s services.

Interactive Logon

The logon process begins when a user enters credentials into the Log On to Windows dialog box or when the user inserts a smart card into the smart card reader. Credentials consist of a user’s user name and password for local logons and the user’s user name, password, and domain for domain logons. The process confirms the user’s identification to the security database on the user’s local computer or to an Active Directory domain. This mandatory logon process cannot be turned off for users in a domain.

Users can perform an interactive logon to a computer in either of two ways:

  • Locally, when the user has direct physical access to the computer.
  • Remotely, through Terminal Services, in which case the logon is further qualified as remote interactive.

After an interactive logon, Windows runs applications on the user's behalf and the user can interact with those applications.

Users can perform an interactive logon by using a local user account or a domain account to log on to a computer.

Local Logon

A local logon grants a user access to Windows resources on the local computer. A local logon requires that the user have a user account in the Security Accounts Manager (SAM) on the local computer. The SAM protects and manages user and group information in the form of security accounts stored in the local computer registry. The computer can have network access, but it is not required. Local user account and group membership information is used to manage access to local resources.

Domain Logon

A domain logon grants a user access to local and domain resources. A domain logon requires that the user have a user account in Active Directory. The computer must have an account in the Active Directory domain and be physically connected to the network. Users must also have the user rights to log on to a local computer or a domain. Domain user account information and group membership information is used to manage access to domain and local resources.

Smart Card Logon

Logging on to a domain with a smart card provides a strong form of authentication because smart cards use cryptography-based identification and proof of possession when authenticating a user to a domain.

To log on to a domain with a smart card, a user does not need to press CTRL+ALT+DEL and enter credentials into the Log On to Windows dialog box. The user merely inserts the smart card into the smart card reader and the computer prompts for the user’s personal identification number (PIN) instead of the user name and password.

Smart cards are a tamper-resistant, portable way to provide security solutions for tasks such as client authentication, code signing, securing e-mail, and logging on to a Windows Server operating systems domain.

Smart cards provide:

  • Tamper-resistant storage for protecting private keys and other forms of personal information.
  • Isolation of security-critical computations involving authentication, digital signatures, and key exchange from other parts of the computer that do not have a “need to know.” The security critical operations are all performed on the smart card.
  • Portability of credentials and other private information between computers at work, home, or on the road.

Network Logon

A network logon can only be used after a user, service, or computer authentication has taken place. During network logon, the process does not use the logon dialog boxes, such as the Log On to Windows dialog box, to collect data. Instead, previously established credentials or another method to collect credentials is used. This process confirms the users identification to any network service that the user is attempting to access. This process is typically invisible to the user unless alternate credentials need to be provided.

To provide this type of authentication, the security system includes these authentication mechanisms:

  • Kerberos V5
  • Public key certificates
  • Secure Sockets Layer/Transport Layer Security (SSL/TLS)
  • Digest
  • NTLM (for compatibility with Windows NT 4.0-based systems)

上一篇： 第..：Windows 权限维护 - 后门章节

下一篇： 使用 powershell 进行 Windows 日志分析

推荐阅读