I. Authentication overview for IIS .... 3
1, Anonymous access ... 3
2. Integrated Windows authentication ... 3
2.1. NTLM authentication ... 3
2.2. Kerberos Authentication ... 3
3. Basic Authentication ... 4
Second, anonymous access .... 4
Third, Windows integration verification .... 5
1. NTLM Verification process ... 5
1.1. The client chooses the NTLM method ... 5
1.2. The service side returns the question code ... 5
1.3. Client encryption Challenge code send request again ... 5
1.4. Server-side Authentication Client user and password ... 5
2. Kerberos Verification process ... 6
2.1. Client Select Kerberos Authentication ... 6
2.2. Service-side verification of authentication ticket ... 6
3, the client and server are not in the domain ... 6
3.1. Client Access Service with IP address ... 6
3.1.1. Client IE Application Page ... 6
3.1.2. Service side return no authorization response ... 6
3.1.3. The client chooses NTLM authentication, asks for the username password, requests the Challenge code ... 7
3.1.4. The server returns the challenge code ... 7
3.1.5. The client sends the query code encrypted using the password previously entered into the account ... 7
3.1.6. Service-side validation passed, returning resources ... 8
3.2. The client uses the machine name to access the server, the login username/password does not match with the server ... 9
3.2.1. Client IE Application Page ... 9
3.2.2. Service side return no authorization response ... 9
3.2.3. Client chooses NTLM authentication, request a challenge code ... 9
3.2.4. The server returns the challenge code ... 9
3.2.5. The client sends the inquiry code after it is encrypted with the account of the landing machine ... 10
3.2.6. Service side return no authorization response ... 10
3.2.7. Client and select NTLM authentication, request the username and password, request the challenge code again ... 10
3.2.8. Service side return Challenge code ... 11
3.2.9. The client sends the query code encrypted using the password previously entered into the account ... 11
3.2.10. Service-side validation passed, returning resources ... 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. Service side return no authorization response ... 12
3.3.3. Client chooses NTLM authentication, request a challenge code ... 12
3.3.4. The server returns the challenge code ... 13
3.3.5. The client sends the inquiry code after it is encrypted with the account of the landing machine ... 13
3.3.6. Service-side validation passed, returning resources ... 13
4. Both the client and the server are in the same domain ... 14
4.1. client computer IP Access server ... 14
4.1.1. Client IE Application Page ... 14
4.1.2. Service side return no authorization response ... 14
4.1.3. The client chooses NTLM authentication, asks for the username password, requests the Challenge code ... 15
4.1.4. The server returns the challenge code ... 15
4.1.5. The client sends the query code encrypted using the password previously entered into the account ... 15
4.1.6. Service-side validation passed, returning resources ... 16
4.2. Client Access server with machine name, client user login with domain account ... 16
4.2.1. Client IE Application Page ... 16
4.2.2. Service side return no authorization response ... 16
4.2.3. The client chooses Kerberos authentication, sends the authentication ticket to the service side ... 17
4.2.4. Service-side validation passed, returning resources ... 17
4.3. The client uses the machine name to access the server, the client user is logged in with the client local user, username/password and server account does not match 18
4.3.1. Client IE Application Page ... 18
4.3.2. Service side return no authorization response ... 18
4.3.3. Client chooses NTLM authentication, request a challenge code ... 19
4.3.4. The server returns the challenge code ... 19
4.3.5. The client sends the inquiry code after it is encrypted with the account of the landing machine ... 19
4.3.6. Service side return no authorization response ... 20
4.3.7. Client and select NTLM authentication, request the username and password, request the challenge code again ... 20
4.3.8. Service side return Challenge code ... 20
4.3.9. The client sends the query code encrypted using the password previously entered into the account ... 20
4.3.10. Service-side validation passed, returning resources ... 21st
4.4. The client uses the machine name to access the server, the client user is logged in with the client local user, username/password and the server account match 21
4.4.1. Client IE Application Page ... 21st
4.4.2. Service side return no authorization response ... 22
4.4.3. Client chooses NTLM authentication, request a challenge code ... 22
4.4.4. The server returns the challenge code ... 22
4.4.5. The client sends the inquiry code after it is encrypted with the account of the landing machine ... 22
4.4.6. Service-side validation passed, returning resources ... 23
5. Integrated Validation Summary ... 23
5.1. Client access to server with IP address ... 23
5.2. Server in domain, client login with domain account ... 24
5.3. In other cases, IE chose to use the NTLM authentication method. ... 24
Four, Basic authentication .... 24
1, Client IE Application page ... 24
2, the service side returned an unauthorized response, and told the client to require Basic authentication ... 24
3, the Client pop-up dialog box required to enter a username and password ... 25
4, service-side validation through, return resources ... 25
I. Authentication overview for IIS
IIS has authentication capabilities, and there are several ways to verify this:
1. Anonymous access
This way does not verify the identity of the access user, the client does not need to provide any authentication credentials, the service side of such access as anonymous access, and such access users are mapped to a server account, typically iuser_machine this user, you can modify the mapped to the user:
2. Integrated Windows authentication
There are two types of validation in this way
2.1.
Ntlm
Verify
This authentication requires the user's username and password to be delivered to the server, and the service side verifies that the username and password are consistent with the user's password. The user name is transmitted in plaintext, but the password is processed to derive a 8-byte key encryption challenge code after transmission.
2.2.
Kerberos
Verify
This authentication only sends the authentication ticket that the client accesses IIS to the IIS server, and IIS receives the ticket to determine the identity of the client and does not need to transmit the user's password. Users who require Kerberos authentication must be domain users.
Each logged-on user will be authenticated by the authentication server in the domain to generate a ticket authorization ticket (TGT) as the user accesses the other service voucher (this is the single Sign-on SSO feature that enables you to access all of the resources that need to be validated in the domain for one login), The authentication ticket that accesses the IIS server is obtained from the user's ticket Authorization ticket (TGT) to IIS. This verification ticket is used by this client after accessing this IIS. Also access to other services that need to be validated is to obtain the verification ticket for the service with this TGT.
The following is the principle of Kerberos in more detail.
Kerberos Principle Introduction:
The workstation side runs a ticket-authorized service called Kinit, which is dedicated to the authentication service between the workstation and the authentication server Kerberos.
1. The user starts to log in, enters the user name, the authentication server receives the user name, searches in the user database the user, the result discovers this user.
2. The authentication server generates a session password shared between the authenticating server and the logged-on user, which is used only by the authentication server and the logged-on user to authenticate each other. At the same time, the authentication server generates a ticket authorization ticket for the logged-on user (Ticket-granting ticket), and the workstation can then request other bills from the verification server with the ticket authorization, without verifying his identity again. Verify that the server encrypts {session key + Ticket-granting ticket} with the password of the logged-on user and sends it back to the workstation.
3. The workstation uses its own password to decrypt the data packets returned by the authentication server, and if the decryption is correct, the validation succeeds. After decryption can obtain the login user and authentication server share session key and a ticket-granting ticket.
To this, the logged-on user does not send the password on the network, through the authentication server uses the user password encryption authentication authorization ticket method to authenticate the user, the user and the authentication server has established the relation, on the workstation also saves the corresponding identity proof, later if uses the network the other service, This identification can be used to verify that the server's service ticket is applied to the authentication servers for appropriate service authentication.
4. If the user accesses the IIS server for the first time, the workstation's kinit view does not have an authenticated ticket to the IIS server on this computer, so kinit makes a request to the authentication server requesting access to the authentication ticket for the IIS service. Kinit first to generate a validator, the validator is like this: {username: Workstation address} is encrypted with the session key between the authentication server. Kinit will verify the validator, ticket authorization ticket, your name, your workstation address, the IIS service name to send the authentication server, verify that the server verifies the validity of the authorization ticket, and then use the session key with you to unlock the validator, get the username and address, Compared to the user and address that sent the request, if it matches, the verification passes, and the request is valid.
5. Verify that the server is a session key conversation password between this user and the IIS server, and then generate a verification ticket for the IIS server based on the user's request. {Session Password: User name: User machine Address: Service Name: Validity: Timestamp}, This verification ticket is encrypted with the password of the IIS server (the authentication server knows the password of all authorized services) to form the final verification ticket. Finally, verify that the server {session password + cryptographic ticket is encrypted with the user password and sent to the user.
6. The workstation receives the data packet returned by the authentication server, decrypts it with its own password, obtains the verification ticket with the session key of the IIS server and the IIS server.
7. Workstation Kinit also to generate a validator, the validator is this: {User name: Workstation address} is encrypted with the session key between IIS servers. Send the validator and the IIS authentication ticket to the IIS server.
8. The IIS server first unlocks the IIS authentication ticket with its own server password. If the decryption is successful, the verification ticket is true and valid, and then check whether this ticket is in the validity period, in the validity period, with the verification ticket with the session password to decrypt the validator, get the user name and workstation address, If the user name and address in the verification ticket match, the user who sent the verification ticket is the owner of the verification ticket, verifying that the request is valid.
3. Basic Authentication
This method of verification is entirely to the user name and plaintext (after Base64 encoding, but the base64 encoding is not encrypted, converted to the original plaintext) to the server-side validation. The server directly verifies that the server locally matches the user name and password provided by the client, and if so, validates it.
Second, anonymous access
When server-side IIS sets the Allow anonymous access, the requested resource is returned directly to the client after the client's resource request is received and no authentication is required.
Get/iisstart.htm http/1.1
Accept: */*
Accept-language:zh-cn
Ua-cpu:x86
Accept-encoding:gzip, deflate
If-modified-since:fri, 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 OK
content-length:1193
Content-type:text/html
Last-modified:fri, Feb 2003 12:15:52 GMT
Accept-ranges:bytes
ETag: "0ce1f9a2d9c21:d8b"
server:microsoft-iis/6.0
Microsoftofficewebserver:5.0_pub
X-powered-by:asp.net
Date:mon, Nov 2007 07:29:40 GMT
Iii. Windows Integration Validation
Integrated Windows authentication can use NTLM or Kerberos V5 authentication, and when Internet Explorer attempts to set up a resource for integrated authenticated IIS, IIS sends two WWW authentication headers, negotiate, and NTLM.
Client IE knows negotiate header, will select Negotiate header, after IE can choose NTLM or Kerberos two authentication method.
If the client does not recognize the Negotiate header, only NTLM headers can be selected, and only NTLM authentication can be used.
Now IE use version is generally more than 5.0, so now you can think that IE clients can identify negotiate head.
So this article only considers IE accepts negotiate headers, using NTLM or Kerberos two authentication respectively.
1. NTLM Verification process
1.1.
Client Selection
Ntlm
Way
If IE chooses NTLM authentication, IE adds a authorization:negotiate header to the request sent to IIS, which reads:
Authorization:negotiate ntlmsspxxxxxxxxxxxxxxxxx
The blue section is actually encoded in base64, where "NTLMSSP" is a request for NTLM authentication, and the "XXXXXXXX" part of the following is binary data that tells the server that the client now chooses NTLM authentication and asks the server to send a challenge code to the client.
1.2.
Service Side return Challenge code
The server joins the Authorization:negotiate header at the head of an HTTP response that returns no authorized access, as follows:
Authorization:negotiate ntlmsspxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The "XXXXXXXX" section returned by the server contains a eight-byte challenge code.
1.3.
Client encryption Challenge code sends request again
The 8-byte deskey that the client derives from the password of the client account uses the DES algorithm to encrypt the received challenge code. The user name, along with the client account number, is sent to the server, in the form of:
Authorization:negotiate ntlmsspxxxxxxxxxxxxxxxxx
The "XXXXXXX" section here contains the encrypted challenge code and the client username, in which the username exists in plaintext.
1.4.
Server-side Authentication Client user and password
The server receives the user name, first check whether this machine has this user, if not directly return the HTTP response without authorization.
If there is this user, the user's password derived from the 8-byte deskey using the DES algorithm to encrypt the client's 8-byte Challenge code, and then received the client sent to the encryption after the query code comparison, if not the same, indicating that the client input password is not correct to see, Returns an HTTP response that is not authorized and, if the same, indicates that the client entered the user's password correctly, validated through, and returns the resource requested by the client.
2. Kerberos Verification Process
2.1.
Client Selection
Kerberos
Verify
If the client chooses Kerberos authentication, the client adds the Authorization:negotiate header directly to the request header, which reads:
Authorization:negotiate xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
where "Xxxxxxxxxx" contains the authentication ticket for the client logged-on user (the ticket issued by the ticket server in the domain at the time of logon that identifies the identity of this logged-on user, which does not contain the user's password).
2.2.
Service-side authentication ticket
The server verifies the user authentication ticket, if the valid ticket, the service side can obtain the user's user name accordingly, and verifies the user's validity. After validation is passed, the service side returns the resource requested by the client.
But when does the client IE choose NTLM, the appropriate option for Kerberos? Here's a series of tests to find the answer.
Both the server and the client are tested in domain-not domain.
3, the client and server are not in the domain
The test environment is in the same LAN as the server and client machine, but none of them are in the domain. Client IE requests a page default.aspx for server-side IIS.
IIS server-side settings:
L do not enable anonymous access
L only enable Integrated Windows authentication
This environment is divided into the following several situations:
3.1.
Client with
Ip
Address Access Service
3.1.1. Client IE Application Page
A GET request is sent to the server by entering the URL to be accessed on the address bar of the client IE browser:
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. Server side returns no authorization response
The server side has set up to disable anonymous access, allowing only Windows authentication, so the server returns an unlicensed response:
http/1.1 401 Unauthorized
Also included in the returned HTTP headers:
Www-authenticate:negotiate
Www-authenticate:ntlm
These two headers indicate that the service side accepts only integrated Windows authentication methods
http/1.1 401 Unauthorized
content-length:1327
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate
Www-authenticate:ntlm
X-powered-by:asp.net
Date:sun, Nov 2007 12:28:29 GMT
3.1.3. Client chooses NTLM authentication, requires a username password, requests a challenge code
The client tells the server through the Authorization:negotiate ntlmsspxxxx header that the client requires NTLM authentication and requests that the service side send the challenge 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 tlrmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaad3==
3.1.4. Server Return Challenge code
The server receives a request from the client and sends a eight-byte challenge code.
http/1.1 401 Unauthorized
content-length:1251
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate Tlrmtvntuaacaaaaegasadgaaaafgoqii7rzphzu6meaaaaaaaaaafwaxabkaaaabqlodgaaaa9caekawgbuaeeatablafiamgacabiaqgbjafoavabbaewas wbsadiaaqasaeiasqbaafqaqqbmaesaugayaaqaegbiagkaegb0ageababrafiamgadabiaygbpahoadabhagwaawbsadiaaaaaaa==
X-powered-by:asp.net
Date:sun, Nov 2007 12:29:44 GMT
3.1.5. Client sends a query code that is encrypted with the password previously entered into the account
Client IE received the query code, using a certain rule from the login user password derived from the 8-byte key to the query Code des encryption, after the encryption of the challenge Code and username with the page request to send 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
Authorization:negotiate tlrmtvntuaadaaaagaayai4aaaayabgapgaaabgagabiaaaaggaaagaaaaauabqaegaaaaaaaac+ Aaaabykioguczg4aaaapmqa5adialgaxadyaoaauadealgaxadmayqbkag0aaqbuagkacwb0ahiayqb0ag8acgbxaekatgayadaamaazac0auabdal0ammkke mwlaaaaaaaaaaaaaaaaaaaaafnd1boc0kthz0tbnfxn3z4w9/nilu1ctw==
3.1.6. Server-side validation through, returning resources
After the server receives the username and the encrypted challenge code, according to the user name to find the user's password on the server, the same method to encrypt the challenge code, and then receive the client returned the challenge code, if consistent, then the user name and password are consistent, verify through, return the client IE request resources. If not, return the unauthorized HTTP response again.
http/1.1 OK
Date:sun, Nov 2007 12:29:44 GMT
server: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 ">
. Untitled Page
</title><body>
<form name= "Form1" method= "post" action= "default.aspx" Id= "Form1" >
<div>
<input type= "hidden" name= "__viewstate" id= "__viewstate"/ wepdwujnzgzndmwntmzzgtcefu2sz1mlsbxizduexomiyz20q== "/>
</div>
<div>
This is a simple page!</div>
</form>
</body>
3.2.
Client Access server with machine name, login username
/
Password does not match server
In this case, the client uses the server name to access the server, but the client login system users and the server's username and password does not match, that is, either the server does not have this user, or the server is the user's password and client this user's password is not the same.
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. Server side returns no authorization response
The server side does not allow anonymous access, and the server returns the HTTP headers that require integrated authentication.
http/1.1 401 Unauthorized
content-length:1327
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate
Www-authenticate:ntlm
X-powered-by:asp.net
date:wed, Nov 2007 12:38:36 GMT
3.2.3. Client selects NTLM authentication and requests a challenge 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 tlrmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaadw==
3.2.4. Server Return Challenge code
http/1.1 401 Unauthorized
content-length:1251
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate Tlrmtvntuaacaaaaegasadgaaaafgoqikemftrqx0quaaaaaaaaaafwaxabkaaaabqlodgaaaa9caekawgbuaeeatablafiamgacabiaqgbjafoavabbaewas wbsadiaaqasaeiasqbaafqaqqbmaesaugayaaqaegbiagkaegb0ageababrafiamgadabiaygbpahoadabhagwaawbsadiaaaaaaa==
X-powered-by:asp.net
date:wed, Nov 2007 12:38:36 GMT
3.2.5. The client sends a query code that is encrypted with the account of the login computer
Client IE first encrypts the key with the password of the local logged-on user, and then sends it along with the user name to the server-side validation.
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 Tlrmtvntuaadaaaagaayaioaaaayabgaogaaabqafabiaaaaggaaafwaaaauabqadgaaaaaaaac6aaaabykioguczg4aaaapvwbjae4amgawadaamwatafaaq wbbagqabqbpag4aaqbzahqacgbhahqabwbyafcasqboadiamaawadmalqbqaemawo4jxecjeuwaaaaaaaaaaaaaaaaaaaaa2/ Kscwhi0mmac6w4omszjbrryrs2ngux
3.2.6. Server side returns no authorization response
The user name and password for the client's native logon do not match the server side, so authentication is not passed on the service side and the service side returns an unauthorized response.
http/1.1 401 Unauthorized
content-length:1251
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate
Www-authenticate:ntlm
X-powered-by:asp.net
date:wed, Nov 2007 12:38:36 GMT
3.2.7. Client and select NTLM authentication, ask for a username and password, and request a challenge 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 tlrmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaadw==
3.2.8. Service Side return Challenge code
http/1.1 401 Unauthorized
content-length:1251
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate Tlrmtvntuaacaaaaegasadgaaaafgoqi3ghim9qd6tuaaaaaaaaaafwaxabkaaaabqlodgaaaa9caekawgbuaeeatablafiamgacabiaqgbjafoavabbaewas wbsadiaaqasaeiasqbaafqaqqbmaesaugayaaqaegbiagkaegb0ageababrafiamgadabiaygbpahoadabhagwaawbsadiaaaaaaa==
X-powered-by:asp.net
date:wed, Nov 2007 12:38:45 GMT
3.2.9. Client sends a query code that is encrypted with the password previously entered into the account
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 Tlrmtvntuaadaaaagaayaigaaaayabgaoaaaabiaegbiaaaaggaaafoaaaauabqadaaaaaaaaac4aaaabykioguczg4aaaapqgbjafoavabbaewaswbsadiay qbkag0aaqbuagkacwb0ahiayqb0ag8acgbxaekatgayadaamaazac0auabdakeymtcyzwkjaaaaaaaaaaaaaaaaaaaaaexqwtipbr+ izohndmnoppu1b9pp7qbpla==
3.2.10. Server-side validation through, returning resources
http/1.1 OK
date:wed, Nov 2007 12:38:45 GMT
server: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 ">
. Untitled Page
</title><body>
<form name= "Form1" method= "post" action= "default.aspx" Id= "Form1" >
<div>
<input type= "hidden" name= "__viewstate" id= "__viewstate"/ wepdwujnzgzndmwntmzzgtcefu2sz1mlsbxizduexomiyz20q== "/>
</div>
<div>
This is a simple page!</div>
</form>
</body>
3.3.
Client Access server with machine name
, Login user Name
/
Password and server match
In this case, the client accesses the server with the server name, and the client who logs on to the system has a user with the same password as the same name 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. Server side returns no authorization response
Similarly, the service side does not allow anonymous access, and the service side returns the HTTP headers that require integrated authentication.
http/1.1 401 Unauthorized
content-length:1327
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate
Www-authenticate:ntlm
X-powered-by:asp.net
date:wed, Nov 2007 12:35:41 GMT
3.3.3. Client selects NTLM authentication and requests a challenge 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 tlrmtvntuaabaaaab4iiogaaaaaaaaaaaaaaaaaaaaafas4oaaaadw==
3.3.4. Server Return Challenge code
http/1.1 401 Unauthorized
content-length:1251
Content-type:text/html
server:microsoft-iis/6.0
Www-authenticate:negotiate Tlrmtvntuaacaaaaegasadgaaaafgoqiswltzjlmelaaaaaaaaaaafwaxabkaaaabqlodgaaaa9caekawgbuaeeatablafiamgacabiaqgbjafoavabbaewas wbsadiaaqasaeiasqbaafqaqqbmaesaugayaaqaegbiagkaegb0ageababrafiamgadabiaygbpahoadabhagwaawbsadiaaaaaaa==
X-powered-by:asp.net
date:wed, Nov 2007 12:35:41 GMT
Current 1/2 page
12 Next read the full text
