Sưu tầm: Kịch bản bảo mật và mở rộng dịch vụ Exchange của UN
Using Forefront TMG to publish Exchange ActiveSync and Outlook Web App Using Certificate Based Authentication
This is an overview on how Exchange 2010 OWA/EAS clients connect when TMG is deployed in DMZ
The following steps describe the process involved when a mobile device or Outlook Web App (OWA) connects to a mailbox using a certificate and how Kerberos Constrained Delegation and Protocol transitioning are used.
- User attempts to access mailbox using OWA or a mobile device over a cellular network. Connection between client and external TMG interface is encrypted using SSL certificate.
- TMG has been configured to publish OWA and Exchange ActiveSync URL and prompts the user for authentication.
- The user or device presents an X509 certificate as proof of identity.
TMG has been configured to use Kerberos Constrained Delegation (KCD) and connects to Key Distribution Center service on the Domain Controller and requests a Kerberos Ticket on behalf of the connecting user.
Note: This is where Protocol Transitioning takes place as initial user authentication method was X.509 certificate and TMG Firewall service has been configured to be allowed to request a Kerberos ticket on behalf of the user.
- The Key Distribution Center service passes back the user Kerberos Ticket to Network Service identity under which TMG Firewall is running.
- TMG has been configured to be able to delegate Kerberos tickets to an Exchange CAS server. The firewall rule on the TMG server knows the internal URL of the Exchange CAS server and passes the requested Kerberos Ticket for the authenticated user to the Exchange CAS server.
- The Exchange CAS then accesses the mailbox server where the mailbox is located, authenticating using Windows Integrated Authentication.
It is important to realize early in the planning stages of a deployment like this, that a single TMG listener cannot provide both certificate based authentication at the same time as Basic, Forms Based Authentication, or NTLM authentication. A listener can provide Forms Based Authentication with fallback to Basic, or Basic and NTLM can be used on the same listener, but certificate based authentication when used as the primary form of authentication cannot be combined with any other form of authentication.
This means it is not possible to share one external namespace/listener between clients such as Exchange ActiveSync, when it is using certificate based authentication, and Outlook Anywhere when it is using Basic Authentication. In a scenario such as this, two listeners, and therefore two namespaces and IP addresses must be used. For example, Outlook Anywhere could be configured to use mail.fabrikam.com and certificate based Exchange ActiveSync could be configured to use cert.fabrikam.com. This would require TMG to have two external facing IP addresses, two certificates (though one certificate with both names listed as SAN attributes could also be used) and two listeners.
Are you using TMG and having issues publishing Outlook Anywhere?
Ever tried to publish Outlook Anywhere using NTLM with TMG and use Kerberos Constrained Delegation? Many people have tried and failed, or at least had some major trouble before they were finally able to get things going.
To help make things a little easier, here is a simple checklist on how to publish Outlook Anywhere using NTLM with TMG, using Kerberos Constrained Delegation.
The simplest scenario is a single Exchange server and a single TMG server.
1. TMG must be domain joined to use Kerberos Constrained Delegation (KCD), which can be a problem for some organizations. http://www.isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html. Domain where TMG is member of must be in Windows 2003 mode and it must be the same domain that your Exchange server is on.
2. Configure KCD.
With ADUC (Active Directory Users and Computers),
Find the TMG computer object, select properties and the Delegation tab,
click “Trust this computer for delegation to specified services only” and then select the “Use any authentication protocol”.
Click Add button and then Click “Users or Computers” button and enter the Exchange server.
Then click “OK” and scroll to find “http – servername”,
click to select it, and then click OK twice to save the configuration.
If you tick the checkbox “Expanded” while selecting protocol you will see that both the FQDN and host name will be in the list.
What you have done now is allowed TMG computer to delegate credentials to the Exchange server, but only if it’s using HTTP, that’s why it’s called constrained delegation.
Why do we mess with the Exchange computer object? Well, Exchange web services run under the local system account, if it was running using a service account, then we must use this account to delegate to instead.
3. Create a Listener and publish rule on TMG.
Start by creating a Listener. As the create Listener wizard goes by select these options:
Select “Require SSL secured connections with clients”,
Select an external IP and a certificate to be used by the listener.
For Authentication you have several options and it all depends on what you want to do, but for this walkthrough select HTTP and Integrated. This means NTLM since we are connecting from internet where there is no Kerberos service is available (or have you put a Domain Controller on Internet?).
Create the publishing rule by starting the Exchange Web Client Access publishing rule wizard.
Select version of Exchange and Outlook Anywhere as the service, and also select “Publish additional folders…”. This will add paths for OAB, EWS and Autodiscover URL.
Select “Publish a server farm of load balanced web servers”,
“Use SSL to connect to the web server or server Farm”,
Internal site name is important: enter a name that is on the certificate used by IIS on Exchange server, that is not the certificate clients “see” when connecting to TMG from internet. This certificate is seen only by TMG.
Create a new Exchange server farm. Give it a name and add your Exchange server to it.
For the connectivity monitoring, select “Send an HTTP/HTTPS Get request”.
Farm is complete.
For the public name, select a name that this publishing rule will accept traffic on.
Select the Listener you created earlier.
For the Authentication delegation select Kerberos constrained delegation and change the SPN to “http/*”.
On user sets, select “All authenticated users”. This can be changed to an AD group to limit who is allowed to use the services you’re publishing.
4. Configure Outlook Anywhere to use NTLM.
Set-OutlookAnywhere -IISAuthenticationMethods ‘Ntlm’ -ClientAuthenticationMethod ‘Ntlm’
Why do a farm of servers instead of just a single server? With a farm, you get the opportunity to do monitoring of the published server. This means that if you encounter that the published server doesn’t work while monitoring, it won’t even try to send traffic to the published server. Flexibility is another thing, you never know what will happen in the future, servers may be added, changed or removed and it’s easier to change the farm membership instead of redoing the publishing rule.
“Test Rule” button. This function is really good but when using KCD it will often fail. One reason for failure is that there is a firewall running between or on the published server which blocks traffic to port 445 and 139. TechNet has a good post related to “test rule” button failure
Another failure is when you set change configuration on the Authentication Delegation tab to use KCD and set the SPN to “http/*”, a star tell TMG to replace it with the published server FQDN when doing the KCD. Unfortunately, TMG doesn’t do this when you click “Test Rule” button. My thought on this is function behind “Test Rule” button only takes this text string and doesn’t translate the star to FQDN. KCD will fail because it is not allowed to delegate to http/*. To overcome this while testing your configuration,replace “http/*” with “http/x” where x is one of the previously allowed delegation. If you have multiple servers in your farm, you should change configuration and test every published server. When done, don’t forget to change back to “http/*”.
One more plus is that even if you have Basic authentication enabled on the Listener, you can still use KCD on the Authentication Delegation tab, which is good for clients who don’t know how to use NTLM.
More advanced configuration with multiple CAS servers and Load Balancer.
The difference with this configuration is that we have a Load Balancer between TMG and CAS. This provides us with a couple of options. Either a) configure TMG to send traffic to Load Balancer, or b) configure TMG to send traffic directly to CAS.
The problem with the first option is that Load Balancer most likely thinks everything comes from TMG and therefore will not distribute traffic to all CAS, but instead sends it to only one of them. This can be fixed by using more sophisticated distribution algorithms on Load Balancer. But in order for that to work, we need to disable SSL between TMG and Load Balancer, and also allow HTTP to CAS. We also have another source to troubleshoot if something breaks. Another thing is the KCD configuration. Since there is no computer account for Load Balancer, the KCD needs to be configured with a name that TMG can use for the delegation. You must add the SPN string to the msDS-AllowedToDelegateTo attribute on the TMG computer account and finally this invented name must be configured in the publishing rule in the delegation tab as the SPN. This is a valid configuration, but with many variables’ in it I think it’s much too .The other option with TMG sending traffic to CAS servers directly and bypass Load Balancer is much easier to configure and to troubleshoot.
Picture only shoving a single TMG and a single Load Balancer but they can in fact me multiple of them for redundancy and load distribution. Either way, it doesn’t matter when you use KCD.
TMG will periodically connect to the published server. How TMG connects depends on the connectivity monitoring configuration. We selected to “Send an HTTP/HTTPS Get request” together with a URL. This means that TMG will connect to this URL and if it gets a response back it will allow traffic on this rule.
If you publish for example outlook anywhere you would most certain need to publish a couple of more URL’s than the /RPC such as /OAB, /EWS and /Autodiscover. Sad story here is that TMG cannot monitor more than one URL. If we monitor /rpc directory then all other can fail without TMG noticing it so TMG will still end traffic to one farm member even though for example the EWS service don’t work on it.
Solution can be to have individual publishing rule for each service you publish. Another solution could be your own developed solution. Create a script that monitor services of your choice, and simply create a file in an IIS directory if every service is working or delete the file if something is not working. In TMG we can then configure the URL to point to this file.
If you published Outlook Anywhere you verify configuration with rpcping.exe.
Be aware of that rpcping has several parameters and you have to specify them correctly. Here is an example.
rpcping -t ncacn_http -s mapi.corp.contoso.com -o RpcProxy=oa.contoso.com -P “billg,contoso,Password2” -I “billg,contoso,Password2” -H 2 -u 10 -a connect -F 3 -v 3 -a connect -e 6001
This means connect to the rpcproxy name “oa.contoso.com” and the internal server name with mapi.corp.contoso.com. User name is billg, password is Password2,netbios domain name is contoso both for the rpcproxy auth and auth to internal server, e = 6001 means internal tcp port 6001 which is on out of the three ports used by outlook anywhere. The others are 6002 and 6004.
The other parameters aren’t that easy to figure out but you can read everything about them here http://support.microsoft.com/kb/831051.
Posted on 11/11/2012, in Công nghệ và Giáo dục, Chính sách CNTT, Microsoft, Microsoft Exchange & TMG, Microsoft Exchange 2007, TMG 2010 and tagged Microsoft, Microsoft Exchange 2007. Bookmark the permalink. Để lại bình luận.