1. IIS Authentication overview... 3
1. Anonymous Access... 3
2. Integrated windows Authentication... 3
2.1. NTLM verification... 3
2.2. Kerberos verification... 3
3. Basic Authentication... 4
2. Anonymous Access... 4
Iii. Windows integration verification... 5
1. NTLM verification process... 5
1.1. The client selects the NTLM method... 5
1.2. The server returns the question code... 5
1.3. The client encrypts the question code and resends the request... 5
1.4. Verify the client user and password on the server... 5
2. Kerberos verification process... 6
2.1. Select Kerberos authentication on the client... 6
2.2. Server authentication ticket... 6
3. The client and server are not in the domain... 6
3.1. The client uses an IP address to access the service... 6
3.1.1. Client IE application page... 6
3.1.2. The server returns an unauthorized response... 6
3.1.3. The client selects NTLM for verification and requires that the user name and password be entered to request the question code... 7
3.1.4. The server returns the question code... 7
3.1.5. The client sends the question code encrypted with the password entered in the previous step... 7
3.1.6. The server passes the verification and the system returns the resource... 8.
3.2. The client uses the machine name to access the server. The login username/password does not match the server... 9
3.2.1. Client IE application page... 9
3.2.2. The server returns an unauthorized response... 9
3.2.3. The client selects NTLM verification and requests the question code... 9
3.2.4. The server returns the question code... 9
3.2.5. The client sends the question code encrypted with the account logged on to the local machine... 10
3.2.6. The server returns an unauthorized response... 10
3.2.7. Check the client and select NTLM for verification. Enter the user name and password and request the question code again.
3.2.8. The server returns the question code... 11
3.2.9. The client sends the question code encrypted with the password entered in the previous step... 11
3.2.10. The server passes the verification and returns the resource... 11.
3.3. The client uses the machine name to access the server. The login username/password matches the server... 12
3.3.1. Client IE application page... 12
3.3.2. The server returns an unauthorized response... 12
3.3.3. The client selects NTLM verification and requests the question code... 12
3.3.4. The server returns the question code... 13
3.3.5. The client sends an encrypted question code to the account that logs on to the local machine... 13
3.3.6. The server passes the verification and the system returns the resource... 13
4. The client and server are both in the same domain... 14
4.1. access the server using the Client ip address... 14
4.1.1. Client IE application page... 14
4.1.2. The server returns an unauthorized response... 14
4.1.3. The client selects NTLM for verification and requires that the user name and password be entered and the question code be requested... 15
4.1.4. The server returns the question code... 15
4.1.5. The client sends the question code encrypted with the password entered in the previous step... 15
4.1.6. The server passes the verification and the resource is returned... 16
4.2. The client accesses the server with the machine name, and the client user logs on with the domain account... 16
4.2.1. Client IE application page... 16
4.2.2. the server returns an unauthorized response... 16
4.2.3. The client selects Kerberos Authentication and sends the verification ticket to the server... 17
4.2.4. The server passes the verification and returns the resource... 17
4.3. The client uses the machine name to access the server. The client user logs on as the local client user. The user name/password does not match the server account 18.
4.3.1. Client IE application page... 18
4.3.2. the server returns an unauthorized response... 18
4.3.3. The client selects NTLM verification and requests the question code... 19
4.3.4. The server returns the question code... 19
4.3.5. The client sends a question code encrypted by the account that logs on to the local machine... 19
4.3.6. The server returns an unauthorized response... 20
4.3.7. Check the client and select NTLM for verification. Enter the user name and password and request the question code again... 20
4.3.8. The server returns the question code... 20
4.3.9. The client sends the question code encrypted with the password entered in the previous step... 20
4.3.10. The server passes the verification and returns the resource... 21.
4.4. The client uses the machine name to access the server. The client user logs on as the local client user. The user name/Password Matches the server account 21.
4.4.1. Client IE application page... 21
4.4.2. the server returns an unauthorized response... 22
4.4.3. The client selects NTLM verification and requests the question code... 22
4.4.4. The server returns the question code... 22
4.4.5. The client sends the question code encrypted with the account logged on to the local machine... 22
4.4.6. The server passes the verification and the resource is returned... 23
5. Summary of integration verification... 23
5.1. The client accesses the server by IP address... 23
5.2. The server is in the domain, and the client logs in with the domain account... 24
5.3. In other cases, IE adopts the NTLM verification method .... 24
Iv. Basic Authentication... 24
1. Client IE application page... 24
2. The server returns an unauthorized response and notifies the client to request basic authentication... 24
3. In the client pop-up dialog box, enter the user name and password... 25
4. The server passes the verification and the resource is returned... 25
1. IIS Authentication Overview
IIS has the identity authentication function and can be verified in the following ways:
1. Anonymous Access
In this way, the access user's identity is not verified, and the client does not need to provide any authentication creden. The server uses such access as anonymous access, and map these access users to a server account. Generally, this user is IUSER_MACHINE. You can modify the user mapped:
2. Integrated windows Authentication
This authentication method can be divided into two situations.
2.1.
NTLM
Verify
This authentication method transfers the user name and password to the server. The server verifies that the user name and password are consistent with the password of the server. The user name is transmitted in plaintext. However, after the password is processed, an 8-byte key encryption question code is derived and then transmitted.
2.2.
Kerberos
Verify
This authentication method only sends the verification ticket sent by the client to the IIS server. When IIS receives this ticket, it can determine the identity of the client without transmitting the user password. The user that requires kerberos authentication must be a domain user.
Each login user is verified by the Verification server in the domain to generate a ticket authorization ticket (TGT) as the credential for this user to access other services to verify the ticket (this is the so-called single sign-on SSO function for accessing all resources in the domain that need to be verified at one login ), the ticket to access the IIS server is obtained from IIS through the user's ticket authorization ticket (TGT. This verification ticket will be used when this customer accesses this IIS. Access to other services that require verification is also based on the TGT to obtain the verification ticket for this service.
The following describes the detailed principles of kerberos.
Kerberos principles:
The workstation runs a ticket Authorization Service called Kinit, which is used for identity authentication between the workstation and the Authentication Server Kerberos.
1. the user starts logging on, enters the user name, verifies that the server receives the user name, searches for the user in the user database, and finds the user.
2. the verification server generates a Session key shared between the verification server and the login user. This password is used only between the authentication server and the login user for mutual authentication. At the same time, the verification server generates a ticket authorization ticket (ticket-granting ticket) for the login user, and the workstation can then request other tickets from the verification server with this ticket authorization ticket, instead of verifying your identity again. The verification server encrypts {Session key + ticket-granting ticket} with the login user's password and then returns it to the workstation.
3. the workstation uses its own password to decrypt the data packets returned by the server. If the decryption is correct, the verification is successful. After decryption, you can obtain the Session key shared by the login user and the verification server and a ticket-granting ticket.
At this point, the login user did not send a password on the network. by verifying that the server uses the user password encryption to verify the authorization ticket, the user has established a relationship with the authentication server, the ID card is also saved on the workstation. If you use other services on the network in the future, you can use this ID card to apply for a service ticket from the verification server to obtain the Service identity verification.
4. If the user visits the IIS server for the first time, kinit of the workstation will check that there is no verification ticket to access the IIS server on the local machine. Then kinit will send a request to the verification server to request a verification ticket to access the IIS service. Kinit must first generate a validators. The validators are like this: {User name: workstation address} encrypted with the Session key between the verification server. Kinit verifies that the authorization ticket is valid by verifying the validators, ticket authorization tickets, your name, your workstation address, and the verification server sent by the IIS service name, then, use the Session key you shared with you to unbind the validators and obtain the username and address, which are compared with the user and address that sent the request. If they are consistent, the verification is passed and the request is valid.
5. the server authenticates the Session key password between the user and the IIS server, and then generates a verification ticket for the IIS server according to the user request. It looks like this: {Session password: User Name: user Machine address: Service name: Validity Period: Timestamp}. This verification ticket is encrypted using the password of the IIS server (the verification server knows the password of all authorized services) to form the final verification ticket. Finally, the verification server {session password + encrypted verification ticket} is encrypted with the user password and then sent to the user.
6. the workstation receives the data packet returned by the Verification server and decrypts it with its own password to obtain the Session key of the IIS server and the verification ticket of the IIS server.
7. the workstation kinit also generates a validators. The validators are like this: {User name: workstation address} encrypted with the Session key between the IIS server. Send the validators and IIS verification tickets together to the IIS server.
8. the IIS server uses its own server password to unbind the IIS verification ticket. If the decryption is successful, the verification ticket is valid and valid. Then, check whether the verification ticket is within the validity period, use the session password in the verification ticket to decrypt the validator and obtain the username and workstation address, if it matches the user name and address in the verification ticket, it means that the user who sent the verification ticket is the owner of the verification ticket, thus verifying the validity of this request.
3. Basic Authentication
This authentication method completely transmits the user name and plain text in plaintext (base64 encoding, but base64 encoding is not encrypted, and can be converted to the original plaintext after conversion) to the server for verification. The server directly verifies whether the local server matches the user name and password provided by the client. If yes, the server passes verification.
2. Anonymous Access
After IIS on the server allows anonymous access, the requested resources are directly returned to the client without authentication after receiving the resource request from the client.
GET/iisstart.htm HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Fri, 21 Feb 2003 12:15:52 GMT
If-None-Match: "0ce1f9a2d9c21: d87"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322; InfoPath.1;. net clr 2.0.50727; MAXTHON 2.0)
Host: 192.168.100.5
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Length: 1193
Content-Type: text/html
Last-Modified: Fri, 21 Feb 2003 12:15:52 GMT
Accept-Ranges: bytes
ETag: "0ce1f9a2d9c21: d8b"
Server: Microsoft-Microsoft IIS/6.0
Microsoftofficeweb server: 5.0 _ Pub
X-Powered-By: ASP. NET
Date: Mon, 12 Nov 2007 07:29:40 GMT
Iii. Windows integration verification
For integrated Windows authentication, NTLM or Kerberos V5 authentication can be used. when Internet Explorer attempts to set it as an IIS resource for integrated authentication, IIS sends two WWW authentication headers, Negotiate and NTLM.
The client IE recognizes the Negotiate header and selects the Negotiate header. Then, IE can select the NTLM or Kerberos authentication methods.
If the client does not know the Negotiate header, you can only select the NTLM header, and you can only use the NTLM authentication method.
Currently, Internet Explorer uses Versions later than 5.0. Therefore, the Internet Explorer client can recognize the Negotiate header.
Therefore, this article only considers whether IE accepts the Negotiate header and uses NTLM or Kerberos for verification.
1. NTLM verification process
1.1.
Client Selection
NTLM
Method
If IE has selected NTLM authentication, IE adds an Authorization: Negotiate header to the request sent to IIS. The content is:
Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXX
In reality, the blue part is base64 encoded. "NTLMSSP" indicates that the request is verified by NTLM, and the "XXXXXXXX" section after it is binary data, telling the server, the client has now selected NTLM verification. The server is requested to send a question code to the client.
1.2.
Question code returned by the server
The server adds the Authorization: Negotiate header to the header of the http response that returns unauthenticated access. The content is:
Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The "XXXXXXXX" section returned by the server contains an eight-character question code.
1.3.
Client-side encryption question code resends the request
The client uses the 8-byte token derived from the password of the client account to encrypt the received question code using the DES algorithm. Send the username of the client account to the server in the following format:
Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXX
The "XXXXXXX" section contains the encrypted question code and client user name, in which the user name exists in the clear code form.
1.4.
The server verifies the client user and password.
After receiving the user name, the server first checks whether the user exists on the local machine. If no unauthorized http response is directly returned.
If this user exists, use the 8-byte challenge key derived from the user's password to use the DES algorithm to encrypt the 8-byte question code sent to the client, then compare it with the encrypted question code sent by the client. If they are different, the client enters an incorrect password and returns an unauthorized http response. If they are the same, it indicates that the user's password entered by the client is correct, and the resource requested by the client is returned after verification is passed.
2. Kerberos authentication process
2.1.
Client Selection
Kerberos
Verify
If Kerberos authentication is selected for the client, the client directly adds the Authorization: Negotiate header to the request header. The content is:
Authorization: Negotiate XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
"XXXXXXXXXX" contains the authentication ticket for the Client Login User (the ticket issued by the Logon Time Domain Server that identifies the login user, excluding the user password ).
2.2.
Server authentication ticket
The server verifies the user authentication ticket. If the ticket is valid, the server can obtain the user name accordingly and verify the validity of the user. After the verification is passed, the server returns the requested resource from the client.
But when does the client IE choose NTLM and Kerberos? The following uses a series of tests to find out the answer.
The sub-server and client are tested in the case that the domain is not in the domain.
3. The client and server are not in the domain.
The test environment is that the server and client machine are in the same LAN, but not in the domain. The client IE requests a page of IIS on the Server default. aspx.
IIS server settings:
L do not enable Anonymous Access
L only enable integrated windows Authentication
This environment is divided into the following situations:
3.1.
Client
Ip
Address Access Service
3.1.1. Client IE application page
Enter the URL to access in the address bar of the client IE browser, and a GET request will be sent to the server:
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: 192.168.1.13: 81
Connection: Keep-Alive
3.1.2. The server returns an unauthorized response.
The server sets disabling anonymous access and only allows windows authentication. Therefore, the server returns an unauthorized response:
HTTP/1.1 401 Unauthorized
The returned http header also includes:
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
The two headers indicate that the server only accepts the integrated windows authentication method.
HTTP/1.1 401 Unauthorized
Content-Length: 1327
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP. NET
Date: Sun, 11 Nov 2007 12:28:29 GMT
3.1.3. The client selects NTLM for verification and requires entering the user name and password and request the question code.
The client uses the Authorization: Negotiate NTLMSSPXXXX header to notify the server that the client requires NTLM verification and requests the server to send a question code.
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: 192.168.1.13: 81
Connection: Keep-Alive
Authorization: Negotiate tlmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaad3 =
3.1.4. The server returns the question code
The server receives a request from the client and sends an eight-character question code.
HTTP/1.1 401 Unauthorized
Content-Length: 1251
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate authorization =
X-Powered-By: ASP. NET
Date: Sun, 11 Nov 2007 12:29:44 GMT
3.1.5. The client sends a question code encrypted with the password entered in the previous step.
After the client IE receives the question code, it uses the 8-byte key derived from the Login User Password according to certain rules to encrypt the question code by DES, the encrypted question code and user name are sent to the server together with the page request.
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: 192.168.1.13: 81
Connection: Keep-Alive
Authorization: Negotiate Authorization + Authorization/NILU1CtW =
3.1.6. The server passes the verification and the resource is returned.
After receiving the user name and the encrypted question code, the server finds the password of the user on the server based on the user name, encrypts the question code in the same way as the client, and then receives the question code returned by the client, if they are the same, it means that both the user name and password are consistent. If the verification is successful, the client IE is returned to request resources. If not, an unauthorized http response is returned again.
HTTP/1.1 200 OK
Date: Sun, 11 Nov 2007 12:29:44 GMT
Server: Microsoft-Microsoft IIS/6.0
X-Powered-By: ASP. NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset = UTF-8
Content-Length: 522
<! DOCTYPE html PUBLIC "-// W3C // dtd xhtml 1.0 Transitional // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<Html xmlns = "http://www.w3.org/1999/xhtml">
<Head> <title>
. Untitled Page
</Title> <Body>
<Form name = "form1" method = "post" action = "default. aspx" id = "form1">
<Div>
<Input type = "hidden" name = "_ VIEWSTATE" id = "_ VIEWSTATE" value = "/wEPDwUJNzgzNDMwNTMzZGTcefU2sz1MLsbXiZdUEXomIyZ20Q ="/>
</Div>
<Div>
This is a simple page! </Div>
</Form>
</Body>
</Html>
3.2.
The client uses the machine name to access the server, and the Login User Name
/
The password does not match the server
In this case, the client uses the server name to access the server, but the user logging on to the system on the client does not match the user name and password on the server, that is, either the server does not have this user, either the password of the server user is different from that of the client user.
3.2.1. Client IE application page
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: biztalkr2: 81
Connection: Keep-Alive
3.2.2. The server returns an unauthorized response
The server does not allow anonymous access. The server returns the http header that requires integration verification.
HTTP/1.1 401 Unauthorized
Content-Length: 1327
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP. NET
Date: Wed, 14 Nov 2007 12:38:36 GMT
3.2.3. The client selects NTLM verification and requests the question code.
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: biztalkr2: 81
Connection: Keep-Alive
Authorization: Negotiate tlmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaadw =
3.2.4. The server returns the question code
HTTP/1.1 401 Unauthorized
Content-Length: 1251
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate authorization =
X-Powered-By: ASP. NET
Date: Wed, 14 Nov 2007 12:38:36 GMT
3.2.5. The client sends an encrypted question code from the account that logs on to the local machine.
The client IE first encrypts the question code with the key derived from the password of the local login user, and then sends it together with the user name to the server for verification.
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: biztalkr2: 81
Connection: Keep-Alive
Authorization: Negotiate Authorization/kscwhI0mmAC6W4OmsZjbrRyrS2NGUX
3.2.6. The server returns an unauthorized response.
The user name and password used to log on to the client locally do not match the server. Therefore, if the verification fails on the server, the server returns an unauthorized response.
HTTP/1.1 401 Unauthorized
Content-Length: 1251
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP. NET
Date: Wed, 14 Nov 2007 12:38:36 GMT
3.2.7. Check the client and select NTLM for verification. Enter the user name and password and request the question code again.
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: biztalkr2: 81
Connection: Keep-Alive
Authorization: Negotiate tlmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaadw =
3.2.8. The server returns the question code
HTTP/1.1 401 Unauthorized
Content-Length: 1251
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate authorization =
X-Powered-By: ASP. NET
Date: Wed, 14 Nov 2007 12:38:45 GMT
3.2.9. The client sends a question code encrypted with the password entered in the previous step.
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: biztalkr2: 81
Connection: Keep-Alive
Authorization: Negotiate Authorization + IzohNdmnopPU1B9pp7QBplA =
3.2.10. The server passes the verification and the resource is returned.
HTTP/1.1 200 OK
Date: Wed, 14 Nov 2007 12:38:45 GMT
Server: Microsoft-Microsoft IIS/6.0
X-Powered-By: ASP. NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset = UTF-8
Content-Length: 522
<! DOCTYPE html PUBLIC "-// W3C // dtd xhtml 1.0 Transitional // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<Html xmlns = "http://www.w3.org/1999/xhtml">
<Head> <title>
. Untitled Page
</Title> <Body>
<Form name = "form1" method = "post" action = "default. aspx" id = "form1">
<Div>
<Input type = "hidden" name = "_ VIEWSTATE" id = "_ VIEWSTATE" value = "/wEPDwUJNzgzNDMwNTMzZGTcefU2sz1MLsbXiZdUEXomIyZ20Q ="/>
</Div>
<Div>
This is a simple page! </Div>
</Form>
</Body>
</Html>
3.3.
The client uses the machine name to access the server.
, Login Username
/
Password Match with server
In this case, the client accesses the server with the server name, and the user logging on to the system from the client has a user with the same name and password on the server.
3.3.1. Client IE application page
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: biztalkr2: 81
Connection: Keep-Alive
3.3.2. The server returns an unauthorized response.
Similarly, the server does not allow anonymous access. The server returns the http header that requires integration verification.
HTTP/1.1 401 Unauthorized
Content-Length: 1327
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP. NET
Date: Wed, 14 Nov 2007 12:35:41 GMT
3.3.3. The client selects NTLM verification and requests the question code.
GET/wstest/default. aspx HTTP/1.1
Accept :*/*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;. net clr 1.1.4322;. net clr 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: biztalkr2: 81
Connection: Keep-Alive
Authorization: Negotiate tlmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaadw =
3.3.4. The server returns the question code
HTTP/1.1 401 Unauthorized
Content-Length: 1251
Content-Type: text/html
Server: Microsoft-Microsoft IIS/6.0
WWW-Authenticate: Negotiate authorization =
X-Powered-By: ASP. NET
Date: Wed, 14 Nov 2007 12:35:41 GMT
