ASP. NET windows part.1 (Introduction, NTLM authentication protocol, Kerberos Authentication Protocol)

ArticleDirectory

• 1. Why use Windows verification?
• 2. Why not use Windows verification?
• 3. Windows Authentication Mechanism
• 3.1 basic verification
• 3.2 digest Verification
• 3.3 integrate windows Verification
• 3.3.1 NTLM Verification
• 3.3.2 introduction to Kerberos Authentication

If you develop webProgramAnd these users all have windows accounts. In this case, Windows verification is a suitable solution. It can use existing user and user group information for system verification.

Unlike form verification, Windows verification is not built in ASP. NET. For Windows verification, the verification responsibility is handed over to IIS. IIS verifies the Windows User Account creden。 through a browser. If the user authentication succeeds, IIS allows this webpage request and passes the user and role information to ASP. in this way, your program can process the information in almost the same way as form verification.

 

1. Why use Windows verification?

• Almost no programming work is required for development.
• Windows verification allows IIS and the browser to process the verification process, youYou do not need to create a logon page, check the database, or write any customCodeWindows already provides basic user account functions, such as password expiration, password lock and user group.
• Allow existing users to log on
• Generally, when Windows authentication is used, users are part of the same local network or internal enterprise network as web servers. This means that you can verify the user by logging on to the computer.Most importantly, based on your configuration and network structure, you can provide a "hidden" authentication mechanism without separate logon steps. The browser only uses the identity of the current user that has logged on.
• Provides a separate verification model for multiple types of applications
• YouThe same authentication model can be used for Web Services, ASP. NET programs, and WCF-based services.. Windows authentication can free you from the pain of having your identity information flow between computers.
• Allow identity simulation and Windows Security
• For example, you can set file access permissions for Windows to control file access. But remember that these settings will not automatically work. Because web programs run as a fixed account by default (IIS 7.x is usually a network service), you can use Windows Authentication and identity simulation to change this line with caution.

 

2. Why not use Windows verification?

Windows verification has potential risks. A Windows User Account may have permissions on Web servers or other machines on the network. You will not take the risk of granting these permissions to website users?

Some authentication methods used by IIS require users to have corresponding software on their machines. This makes it unavailable to users who use a non-Microsoft operating system or who do not have an IE browser.

Windows verification does not give you any control over the verification process. Windows Account information cannot be managed by programming, and user-specific information cannot be stored.

 

3. Windows Authentication Mechanism

When you deploy Windows verification, IIS has three policies to verify each request it receives.

• Basic Verification: The user name and password are transmitted in plain text format. As part of the HTML standard, this is the only Authentication Mode Supported by all browsers
• Digest Verification: The user name and password are not transmitted. On the contrary, an encrypted secure hash string is sent.
• Integrated windows Verification: The user name and password are not passed. The identity of a user who has logged on to Windows is automatically transferred as a token.

 

3.1 basic verification

The most widely supported verification protocols are basic verification. During client verification, the browser displays a logon box used to enter the user name and password. After the user provides the information, the information is sent to the Web server. Once IIS receives the verification data, it uses the corresponding Windows Account to verify the Website user.

The key limitation of basic verification is that it is insecure, at least it is insecure.The user name and password are transmitted in plain text format, and the data is encoded (unencrypted) as strings in base64 format.Network eavesdroppers can easily read data.

Use Basic verification only for security purposes. For example, if you do not need to protect your creden, or bind an HTTP network encryption protocol (such as SSL ),.

 

3.2 digest Verification

You also need to provide account information in the Login Dialog Box displayed in the browser. But the difference is that,Hash string used to verify the password passed by DigestInstead of the password itself, you can prevent password theft without using SSL.

The process of verifying a user using digest is as follows:

1. Unauthenticated client requests a restricted webpage
2. The server returns an HTTP 401 response. This response contains a nonce value (a random Character Sequence). The web server ensures its uniqueness before sending the nonce.
3. The client uses this nonce, password, user name, and other values to create a hash. Hashed strings and plain text usernames are sent back to the server.
4. The server uses the nonce value, creates a hash string for the Password Saved by the current user, and other values, and matches the hash string sent from the client to determine whether the verification is successful or not.

The Nonce value changes for each authentication request, which ensures the security mechanism. HoweverOne restriction of IIS digest authentication is that the virtual directory to be verified must run on a Windows Active Directory domain controller or be controlled by it to work.

 

3.3 integrate windows Verification

This mode is the most convenient verification standard for enterprise intranet applications based on Wan or LAN, and verification can be performed without any client interaction.When IIS requires client authentication, the browser will send a flag representing the current user's Windows Account identity, but if the web server cannot use this information for authentication, it will display a logon box for users to enter a different user name and password.

The client and web server must be on the same LAN or enterprise intranet. This is because integrated Windows Authentication does not actually send user name and password information. Instead, it corresponds toDomain ServerOrActive Directory instanceCollaborate with each other to log on and obtain the verification information sent to the client machine of the Web server.

 

There are two protocols used to transmit verification information:NTLM(Nt lan Manager, nt lan Management) Verification andKerberos5. Select the operating system version based on the client and server. If both the client and server operating systems are in Windows 2000 or later versions and both machines are running in an Active Directory, Kerberos is used as the authentication protocol, otherwise NTLM verification is used.

 

3.3.1 NTLM Verification

NTLM verifies that a three-way handshake Based on the client and serverInterrogation/ResponseTo verify the client.

1. The client sends a message to the server, indicating that it wants to communicate with the server.
2. The server generates a 64-bit random value nonce (current value) cache and returns nonce to the client in response to the client's request. This response is called a question query (challenge ).
3. The client operating system requires the user to enter the user name and password, and then automatically hashed. The hash key is the master key used to encrypt nonce. Then, the encrypted nonce and user name are used as responses to the server.
4. The Nonce returned by the Server check. Check whether the user is a local user or a domain user occurs locally or on the domain controller. The user's master key (that is, the hash version of the password) is extracted from the security account database, and then the plain text nonce on the server is encrypted. If the new nonce encryption version matches the encrypted version returned by the client, the user authentication is successful.
5. Create a logon session for the current user on the server.

Throughout the process, passwords are never transmitted over the network, which makes NTLM very secure, but there is another safer protocol.

 

3.3.2 introduction to Kerberos Authentication

Currently, Kerberos 5 is the safest protocol. It is composedIETF(Internet Engineering Task Force(Internet Engineering Task Group) to create a famous public standard, to achieve a bill-based authentication protocol. If integrated Windows authentication is activated, Kerberos is automatically used in the following cases.

• Both the client and server run on Windows 2000 or later.
• There is an Active Directory domain in the network where the primary domain controller (playing the role of the Key Distribution Center)

Kerberos content can write a book. Here we will only learn some basic concepts to help you understand the necessary configuration tasks and when each function will take effect. For exampleOne major difference between NTLM and Kerberos is that Kerberos supports both identity simulation and delegation, while NTLM only supports identity simulation..

 

The core component of the Kerberos system is KDC (Key Distribution Center, Key Distribution Center), which is responsible for sending bills and managing creden. In the Windows world, the primary domain controller of the Active Directory plays the role of KDC. Each participant (client and server) involved in the verification process must trust KDC. KDC manages accounts of all users and computers and sendsVerify ticketAndSession ticket.

There is another big difference between Kerberos and NTLM:NTLM runs in a working group environment without central authorization. Kerberos requires a central authorization to send any type of tickets. Therefore, to make Kerberos take effect, you need to connect to the domain controller of an active directory.

 

The basic process of Kerberos Authentication and ticket:

1. The client submits a request to the Verification Service, which runs on KDC (Active Directory domain controller. The request contains the user name. KDC reads the user's master key (hash version of the password) from the security account database ).
2. It creates a TGT (Ticket-granting ticket, The bill is granted to the ticket ). Contains a session key for user sessions and the time of an expiration date. The server uses the CMK to encrypt the TGT, and then sends it to the client.
3. Only by entering the correct password on the client can the client operating system create the same master key (hash) to successfully decrypt the TGT received from the server. Decryption successful, verification passed.
4. The client caches the TGT locally.
5. When the client wants to communicate with a member server in the network, it first requests a session ticket from KDC. To this end, it sends a locally cached TGT to the ticket on KDC to the service. This service checks TGT. If TGT is valid (not expired or tampered with), it creates a session key for communication between the client and the member server, then, encrypt the session key using the client's master key. In addition, the session key is packaged into (Session ticket, Session ticket), St contains additional expiration information. This session ticket is encrypted using the master key of the member server. Of course, both the server and client must be known to KDC, that is, they have been added to the domain before (adding a machine in the domain means that the machine and KDC establish a trust relationship ). Therefore, KDC knows the master key of the client and the member server.
6. The encrypted session key and session ticket are both sent to the client.
7. The client decrypts the session key and saves a copy of the session key in the local cache.
8. The client delivers the encrypted session key to the server.
9. If the server can successfully decrypt and verify the session ticket received from the client, a communication session is established.
10. Both the client and server use the previously generated session key to encrypt communication. Once the session ticket expires, the entire operation will be repeated.

 

each ticket (session ticket, ticket granting ticket) has a certain function. These functions are only a set of defined attributes required for certain features (such as identity simulation or delegation. For example, with specific attributes, they can simulate the identity of the client user on the server or delegate the client identity to another server.