Vấn đề 1: 1 máy PC đã join domain sau khi đăng nhập máy bằng Ctrl + Alt + Delete thì truy cập vào website trong mạng Intranet IIS 7.x theo kiểu Windows Authenticate sẽ phải tự động truy cập vào được bằng Domain User ?
Vấn đề 2: Máy chủ hosting website đó là IIS7.5 / Windows Server 2008 R2 SP1. Máy chủ chạy website ASP.NET có cả SharePoint 2007 vậy khi triển khai gói MS Live@edu SSO Kit thì cấu hình SSO như thế nào để máy PC trong Domain Local (đang join domain) sẽ có thể truy cập tự động (không hỏi user/password) khi truy cập site:SSO ?
Hãy tham khảo bài viết dưới đây:
IIS and Kerberos. Part 1 – What is Kerberos and how does it work?
Edit: I’ve 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 Avanade. Since Kerberos isn’t a simple topic, I’m 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 other 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 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 remember 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 resource
b) there is an issue in securely transmitting the shared secret from the user to the server. Various technologies (like TLS/SSL) exist for securing 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 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 should 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 Windows 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 doesn’t need to authenticate itself to the Domain Controller. However 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 user’s password (this is why the user doesn’t need to authenticate – if the user isn’t who they say they are, they won’t be able to decrypt the session key because they don’t know the user’s password). The KDC also prepares a second piece of data – it again encrypts the session key as well as the user’s username (known as a Kerberos principal), but using the service’s 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 client. 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 service’s 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, but they aren’t 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. 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 user, 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 wouldn’t know the correct session key necessary to encrypt the timestamp correctly. Alternatively, if the imposter 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 Kerberos, 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 you made!). To get around this, the client machine could cache the user’s password, but that isn’t 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 service 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 a Service Ticket to the remote service. However instead of encrypting anything using the user’s password, it encrypts using the session key originally generated by the AS. Since the client machine aleady knows this from when the TGT was received in the first place, there is no need to bother the user for their password. The TGT typically has a short lifespan – around 8 hours or so.
IIS and Kerberos. Part 2 – Service Principal Names
Apologies for the delay in posting Part 2 – I’ve been on holidays so it’s been a bit hard finding the time to write these posts. In this part we cover Service Principal Names (SPNs).
In a previous post we covered the basics of Kerberos authentication. Everything is relatively straitforward, however I didn’t cover the one particular aspect. Namely, how does the Authorisation Service (AS) and remote Service share their shared secret?
In an Active Directory domain, all computer and user objects have a password. This password is used as the basis of the shared secret between the AS and the remote service. If the remote service is running under an inbuilt principal such as LocalSystem or Network Service then the computer account’s password is used as the basis of the shared secret. If the remote service is running under a custom user account, then the user account’s password is used as the basis of the shared secret.
So how does the AS know which user or computer account’s password should be used? When a user wishes to connect to a remote service, it tells the Domain Controller what Kerberos service it wishes to connect to. The AS searches through Active Directory to find a matching Service Principal Name (SPN). SPNs are attributes of user and computer objects in the directory. For example, for the computer w03-svr-sql we can see the following SPNs (using ADSIEdit):
SPNs can be viewed, added and removed using a GUI tool like ADSIEdit, or you can do the same using a command line tool such as SetSPN (part of the Windows 2000 Resource Kit).
Generally, when installing a product such as SQL Server or IIS that supports Kerberos, SPNs are registered for you for the accounts that those products are configured to use. However you later change the user account that the services are running under, you may need to set a new SPN for that Kerberos authentication continues working.
This method of determining the shared secret to be used between the AS and remote service raising a couple of gotchas which can break Kerberos Authentication:
1) The missing SPN
When installing IIS (and a lot of other common services) the installer will register a set of default SPNs in the Directory. However if you change the way that your service runs after installation, you may need to update the SPNs that are registered.
For example, after installing IIS, SPNs for servername and servername.domain.tld are registered under the server’s computer account in Active Directory. These SPNs will allow Kerberos authentication to work when using the following built-in service principles: LocalSystem, Network Service or Local Service as the identity for your worker processes.
However if you change the process identity of your web application pool, and assign its worker process a custom domain user acccount as a process identity, then you will need to create SPNs for servername and servername.domain.tld under this custom user account. This allows the KDC to encrypt the service ticket with the password of the user account rather than the computer account.
2) The duplicate SPN
In the event that an SPN for the same service is registered under multiple accounts in Active Directory (e.g. under a computer account and a user account), then the KDC will not know which password should be used to encrypt the service ticket, and Kerberos Authentication will fail.
In the above scenario, once you change the identity of your web application pool, and add the new SPNs for servername and servername.domain.tld, you may need to remove the existing SPNs from under the computer account. Likewise, if you change the process identity from one user account, to another user account, you would most likely need to remove the SPNs from the first user account, and add them to the second user account.
3) Load-balanced IIS solutions
In this situation, the user’s request might be routed to either of the two (or more) nodes in your cluster. In this case, you can not run your web application pools under an inbuilt principal (such as Network Service), because the KDC can not know which computer account’s password should be used (it does not know which node in the cluster the request will be routed to). In this situation you must use a common domain user account as the process identity of your worker processes.
4) Multiple web applications hosted at a single domain name
Because SPNs are organised by name (either NetBIOS or fully qualified domain name), all web applications hosted at that domain name must be running in worker processes utilising the same, common, identity. This is so that the KDC can generate a service ticket using that identity, no matter what web application is being accessed at the FQDN. You can still run the web applications in separate web application pools, but each pool must be running under the same, common, identity.
IIS and Kerberos. Part 3 – A simple scenario
In Part 3 of this series we look at setting up Kerberos Authentication in the simplest possible scenario. If you missed Parts 1 (What is Kerberos and how does it work) and 2 (Service Principal Names) they may be worth reading first. In this scenario, we have a client, a DC and a single IIS server. As we progress through the series, we will progressively add more elements into the mix.
In this very simplistic example a client wishes to authenticate to a website hosted on the webserver. The sequence of events is illustrated in the diagram:
1) The client makes a HTTP Request
2) The server denies the request with a 401 Authorization Required. It includes the WWW-Authenticate: Negotiate header and/or the WWW-Authenticate: Kerberos header indicating that it supports Kerberos authentication
3) The client requests a Service Ticket from the KDC hosted on the Domain Controller
4) The Domain Controller returns the Service Ticket
5) The Client generates the Authenticator, and sends this plus the Service Ticket in a new HTTP request to the web server
6) The webserver determines the identity of the client, checks the ACL on the resource and either permits or denies access to the resource.
In order for this sequence of events to work the following need to be configured.
For Internet Explorer to use Kerberos to authenticate to IIS the following must be configured correctly:
- Under Tools -> Internet Options -> Advanced the option “Enable Integrated Windows Authentication (Requires Restart)” must be checked. Whilst technically IWA encompasses both NTLm and Kerberos, IE will use NTLM only if this option is not checked whilst it can use both Kerberos or NTLM if this option is checked.
- The website you are connecting to must be located in the “Intranet” Security zone. You can see what zone IE thinks the website is in by looking at the icon in the bottom right-hand side of IE’s status bar. If the website is located in the “Internet” zone, IE will not even attempt Kerberos authentication. This is because, in most Internet scenarios, a connection with a domain controller can not be established. The simple rule is that any website that contains full stops (periods for Americans) such as an IP address or Fully Qualified Domain Name (FQDN) is in the Internet zone. If you are connecting to an IP address or FQDN then use IE’s settings or Group Policy to add this site to the Intranet security zone. For more information on how IE determines what zone the website is in please see KB 258063
The Domain Controller
For the Domain Controller to generate the appropriate tickets to give to the client an appropriate Service Principal Name (SPN) must be registered in Active Directory. When a Windows Server 2003 machine is added to a domain, a HOST SPN for both the NetBIOS name and the FQDN of the server is automatically added to Active Directory. If your website is accessible at http://servername or http://servername.domain.tld (tld = Top Level Domain, such .com or .local) and the web application pool is running as Network Service, Local Service or Local System, you do not need to change any SPNs.
If the web application pool hosting the site is running under a custom account, the SPN HTTP/servername or HTTP/servername.domain.tld needs to be registered under that custom user account. If those HTTP SPNs exist under any other account, they need to be removed.
And lastly, if the website is accessible at an arbitrary hostname that is unrelated to the actual server’s name (e.g. http://www.domain.tld) then a SPN needs to be registered for that hostname. If the web application pool hosting the website is running as Network Service, Local Service or LocalSystem, then the SPN needs to be registered under the server’s computer account. If the web app pool is running under a custom user account, then the SPN needs to be registered under that user account in Active Directory.
SPNs can be added using a GUI-based tool such as ADSIEdit. Or can be added programmatically using an interface to AD (such as ADSI), or can be added using the SetSPN.exe command line tool (SetSPN is discussed in Part 2 of IIS and Kerberos listed earlier). To add an SPN using SetSPN for:
- a servername under a custom user account:
setspn –A HTTP/servername Domain\Username
- an arbitrary hostname under a computer account:
setspn –A HTTP/hostname.domain.tld Domain\MachineName
- an arbitrary hostname under a custom user account:
setspn –A HTTP/hostname.domain.tld Domain\UserName
The IIS Server
There isn’t a lot to configure on the IIS Server. Firstly Integrated Windows Authentication (IWA) should be enabled for the website or application you are seeking to protect. By default this enabled both the Negotiate and NTLM Authentication Providers in the IIS metabase. If you have edited the metabase to remove the Negotiate provider, you will need to add it back in. The installation of some products (e.g. Sharepoint Portal Server 2001) removes the Negotiate provider – you may need to manually add it back in. See Microsoft KB Article 832769 for your options.
Secondly, all web applications hosted at the DNS name in question need to be running in one or more web application pools that are all running under the same user account. It’s easiest if all the web applications at that DNS name are running in a single web app pool. However if you do need to split web applications into multiple pools, those pools need to be running under the same user account.
And that should be all that is required for your Internet Explorer browser to authenticate to IIS using Kerberos. To verify whether this is occuring, you can use the tools described in my previous post on determining whether the browser is using NTLM or Kerberos to authenticate to IIS.