IIS+and+Kerberos.docx

1、IIS+and+KerberosIIS and Kerberos Part 6 - New in IIS 7Note: previous articlesWindows Server 2008 and IIS 7.0 introduce some changes to the way that you need to implement Kerberos support. The three major changes that Im aware of are:1. Service Principal Names (SPNs) no longer need to be registered u

2、nder the account that the web application pool is running under. Instead, in a default configuration you can run the web application pool under any account (custom user account, or LocalSystem, Local Service or Network Service) and register the SPN under the machine account in Active Directory. See

3、this post for more details. 2. Your web application pool does not need LocalSystem privileges to be able to perform protocol transition. You can do this using Network Service. 3. If you want to use in web.configfor your ASP.NET pages, you need to disable validateIntegratedModeConfiguration if you ar

4、e using the Integrated Mode Pipeline. Otherwise youll get a 500.24 error.You can either set validateIntegratedModeConfiguration to False or you can run in Classic Mode PipelineNew in IIS 7 - Kernel Mode AuthenticationWindows Server 2003 SP1 introduces kernel mode SSL. Windows Server 2008 takes this

5、one step further and introduces kernel mode authentication. This can be utilised by IIS 7.0 applications to improve performance. It also has implications for Kerberos authentication and management of SPNs.Consider the following scenario:Ensuring Kerberos AuthN for App1 wouldnt be possible in IIS 6/5

6、 (earlier versions were pre-Windows 2000 so didnt support Kerberos). This was because SPNs are based on a FQDN and the SPN for http/ could only be registered under a single account (and not under the two different accounts that App Pool 1 and App Pool 2 are using).In Windows Server 2008 there is sup

7、port for a new kernel mode authentication. I am supposing that this is implemented in ksecdd.sys, but it may be implemented elsewhere. When using kernel mode authentication, the service ticket is decrypted by the server (aka machine account), not by the user account that the web app pool is running

8、under.Because of this, its possible to: Register every SPN for each application hosted webserver under the machine account in Active Directory, regardless of the identity of the web app pool that the application is being hosted in Run multiple web applications hosted at the same FQDN under web app p

9、ools that are, in turn, running under multiple Windows identities.Edit: Anil from the IIS ProductGroup pointed out an error in my advice below (its not necessary to actually disable Kernel Mode Authentication).I have updated the section below:There is a caveat. This is because the service ticket dec

10、ryption takes place using the servers AD machine account. If you are using a web farm, then the KDC doesnt know in advance which individual server will be servicing the request. In that case, its impossible to deterministically register the SPN under a single machine account. Instead, you will need

11、to: Disable kernel mode authentication Configure IIS to use the web application pools identity for Kerberos service ticket decryption Run the web app pool under a common domain user account Be restricted to running all web application accessible at that FQDN under web app pools that are using the sa

12、me domain user account aboveIf you are in this situation, then you can disable kernel mode authentication enable the use of the web app pools identity for Kerberos service ticket decryption by setting the property useAppPoolCredentials to true for the web application or web site in question. An exam

13、ple would be: IIS and Kerberos. Part 1 - What is Kerberos and how does it work?Edit: Ive created a list of all the parts in this series here, which will be updated as I add more parts.Configuring Kerberos and Delegation is one of the more common problems I see in the communities and even within Avan

14、ade. Since Kerberos isnt a simple topic, Im going to write a quick series explaining how Kerberos works, common scenarios and problems and some troubleshooting tips.Kerberos is an open authentication protocol developed at MIT, and implemented in Windows 2000/2003 Active Directory domains (amongst ot

15、her places). Authentication is the process of proving your identity to a remote system. Your identity is who you are, and authentication is the process of proving that. In many systems your identity is your username, and you use a secret shared between you and the remote system (a password) to prove

16、 that your identity.The problem with simplistic shared secret systems is two-fold:a) there is a scalability problem. If every user needs to maintain a shared secret with every individual server (or every service on every server!) then that results in poor passwords. Users can not be expected to reme

17、mber dozens, hundreds or thousands of unique passwords and so end up repeating them regardless of whether the server is a low security or high security resourceb) there is an issue in securely transmitting the shared secret from the user to the server. Various technologies (like TLS/SSL) exist for s

18、ecuring the transport of data between machines, however it is incumbent upon each service to utilise services lower down in the network stack.Kerberos is designed to overcome these limitations. In this part we look at how a simple Kerberos implementation works. In this scenario we have a user using

19、a client machine that wishes to connect to a remote service (the user here is a person or application, the client is the OS or machine). Remember that we want a system that allows us to store shared secrets centrally, and to securely transmit user credentials between client and service. Lastly we sh

20、ould look to prevent replay attacks (where someone who is sniffing the wire can replay captured packets to impersonate a legitimate user, even if they do not know how to create the authentication packets themselves).To begin with we introduce the Kerberos KDC - Key Distribution Centre. In the Window

21、s Active Directory world, the KDC lives on Domain Controllers (DCs). The client connects to the Authorisation Service (AS) that runs on the KDC and asks the AS to authenticate the user to the remote service. Technically, the client doesnt need to authenticate itself to the Domain Controller. However

22、 in the Active Directory world, something called pre-authentication is used to ensure that the user (or client application) is actually who they say they are.The AS on the KDC generates a session key that will be used by the client and the remote service. It encrypts the session key with the users p

23、assword (this is why the user doesnt need to authenticate - if the user isnt who they say they are, they wont be able to decrypt the session key because they dont know the users password). The KDC also prepares a second piece of data - it again encrypts the session key as well as the users username

24、(known as a Kerberos principal), but using the services password this time to encrypt the data. Only the remote service will be able to decrypt this second piece of data. This second piece of data is known as the Service Ticket (or just Ticket).The KDC now sends both pieces of data back to the clien

25、t. The user, knowing their own password, is able to decrypt the first piece of data, and extract the session key. The user however does not know the services password, so is unable to decrypt the second piece of data. The client uses the session key to encrypt the current time (amongst other things,

26、 but they arent so important right now). This piece of data is known as the Authenticator. The client sends the Authenticator it just generated, along with the Service Ticket received from the KDC to the remote service.The remote service is able to decrypt the Service Ticket using its own password.

27、It is thus able to get access to the session key, and the Principal (user) attempting to connect. It now uses the session key to decrypt the Authenticator, and extract the time. It compares the time to the current system time on the server to ensure a match. Since only the service, the KDC and the u

28、ser, know the session key then the service can assume that user must be who they say they are. If an imposter sent a Service Ticket to the service (e.g. by replaying captured packets) they wouldnt know the correct session key necessary to encrypt the timestamp correctly. Alternatively, if the impost

29、er attempts to use captured Authenticator packets (which contain a timestamp), thus bypassing the need to know the session key, then the times will not match when the Authenticator is decrypted by the service and the service will refuse to authenticate the remote user.If this was the extent of the K

30、erberos, then each and every time the client received an encrypted session key from the KDC, the user would need to enter their password to allow the client machine access to it. That could rapidly become a productivity sinkhole (imagine having to enter your password for each and every HTTP request

31、you made!). To get around this, the client machine could cache the users password, but that isnt a particulary secure system. What Kerberos does is introduce the concept of a Ticket Granting Ticket (TGT). Ticket Granting Tickets are issued by the AS running on the KDC in the same way that a normal s

32、ervice ticket is issued. However the TGT is valid for the Ticket Granting Service, rather than a remote HTTP server (or any other type of server). Whenever the user wishes to connect to a remote service, it can use the TGT that it has already received to connect to the TGS. The TGS, after authenticating the user via the TGT, issues