[isapros] Re: ISA and SAN Certs

  • From: Jason Jones <Jason.Jones@xxxxxxxxxxxxxxxxx>
  • To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
  • Date: Mon, 8 Oct 2007 22:28:01 +0100

Spoken like a true author :-)

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Steve Moffat
Sent: 08 October 2007 22:07
To: ISAPros Mailing List
Subject: [isapros] Re: ISA and SAN Certs

I reckon it's because they are wrong and I am right....but I've been wrong 
before.....

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Monday, October 08, 2007 5:50 PM
To: ISAPros Mailing List
Subject: [isapros] Re: ISA and SAN Certs

Geez, not even just for testing!!!! What I was getting at was to see if you get 
errors when you access Exch2k7 web services.

So explain the magic, just how have you got autodiscover working with a single 
IP and cert as everyone else seems to think it is not possible...even with 
CNAMEs.

JJ

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Steve Moffat
Sent: 08 October 2007 18:18
To: ISAPros Mailing List
Subject: [isapros] Re: ISA and SAN Certs

No, I don't condone the use of OOF....:P~~

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Monday, October 08, 2007 1:54 PM
To: ISAPros Mailing List
Subject: [isapros] Re: ISA and SAN Certs

Steve,

Have you tried configuring Out of Office settings whilst using Outlook Anywhere 
externally?

Cheers

JJ

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Steve Moffat
Sent: 08 October 2007 14:22
To: ISAPros Mailing List
Subject: [isapros] Re: ISA and SAN Certs

Because they didn't know?

:)

Because they never tried it??

:)

Because they like making things harder than they need tp?

:)

S

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Monday, October 08, 2007 4:55 AM
To: ISAPros Mailing List
Subject: [isapros] Re: ISA and SAN Certs

Ok, now I am confused. If you can simply add a CNAME to redirect 
autodiscover.domain.com to your chosen URL, why did the Outlook team bother to 
create the hotfix to use SRV records???

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Steve Moffat
Sent: 06 October 2007 20:51
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

Just to muddy the waters...:)

I pass this information on, that it may be of help to others (including myself 
in remembering what i did!)

Preamble: This is my setup, so i cannot guarantee that this will work for you, 
I have for this setup, 1 server running Windows 2003 x64. If you want to 
install Exchange 2007 you will need it on either Windows 2003 x64 or 2007 x64 
bit versions, the 32bit (x86) will not work. I also have one static public 
(external) IP. Most of the configurations i came across for Exchange will talk 
about multiple web sites (with different internal IPs) the thing they rarely 
mention is that you will need multiple external IPs to map to these internal 
IPs. If you have multiple external IPs then it is probably better that you 
assign 1 for autodiscover.domain.com so that you have more choices down the 
road instead of locking it to the same IP as your main CAS IP. If however you 
are restricted to 1 external IP this may help you.
A little note about SSL certificates, Exchange 2007 is a bit of a nightmare for 
SSL certificates, by default you have a self-signed certificate made by 
exchange, which is ok if you have no one accessing any external services like 
OWA, activesync, RPC over HTTP (OutlookAnywhere). However this scenario is 
probably unlikely. If you do have these services then you either can install 
this self-signed certificate on every computer that needs to access these 
services not to mention telling people to click through the IE7 stupid "There 
is a problem with this website's security certificate", needless to say this is 
really not a viable option for most people. So pretty much the only real option 
is a commercial SSL certificate. Trying to find the most economical way to do 
things, i tried StartCom's free (yes really free, not trial) SSL certificate, 
problem is that it is trusted by almost everyone INCEPT Internet Explorer, 
needless to say it becomes a pain to teach people the same thing about 
untrusted certificates. OK - other choices - for Exchange 2007 you are talking 
about 2 SSL (I'll show you the bypass to get it to 1 later), one for 
mail.domain.com and another for autodiscover.domain.com, that means if you've 
done any research on the subject that you need an SSL cert that supports SAN 
(Subject Alternative Name). At present the cheapest one is $200/year, others 
are considerably more expensive. Better but even $200/year i find a little 
steep if all you need is just a CAS certificate (exchange 2003 front-end certs 
are easily <$100). On top of this you may already have a mail.domain.com cert 
that would now be useless. I have a mail.domain.com cert from GoDaddy which 
cost $20/year (or less) and that is the one that i will be using.
Getting Started:
To start off I did a clean install of windows 2003 x64, setup DNS, WINS (if 
necessary), DHCP, IIS in that order, a fairly typical PDC. Then a standard 
install of Exchange 2007, there a few extra programs and hotfixes to install 
but the install program is good about telling you what you need. A little note, 
you can install the Exchange tools on a 32 bit machine to do most of the 
administration from a client machine. Ok so you have a clean Exchange install, 
let's configure it.
To allow Exchange to accept connections from other mail server, open Exchange 
Management Shell (EMS)
Run the following command;
Set-RecieveConnector -Identity "Default <ServerName>" -PermissionGroups 
"AnonymousUsers"
Replace <ServerName> with your CAS name. Close the EMS
To allow Exchange to send mail to other mail servers, open Exchange Management 
Console (EMC), open Organization Configuration->Hub Transport, click on 'Send 
Connectors', Right click (RC) in the 'Send Connectors' box and select 'New Send 
Connector', choose a name, for example 'All Outgoing Connector', leave the 
'Select the intended...' as Custom, for the Address Space click the 'Add' 
button and enter * in the Add Address Space window marked Domain, to accept 
SMTP connections from all domains, leave the 'Include all subdomains' 
unchecked. In Network settings leave all values at their default settings, in 
'Source Server' again leave the default values, and finally in 'New Connector' 
click on 'New' to create the connector.
At this point Exchange should be able to send & receive mail.
At this point if you are going to support Outlook with RPC over HTTP you will 
need to install that service, go to Control Panel->Add/Remove 
Programs->Add/Remove Windows Components, Select Networking Services, click on 
details, click the 'RPC over HTTP Proxy', click 'ok', Click 'next', make sure 
Windows has access to the install source, after the proxy is installed, click 
'Next'.
Now you need to remove the Exchange self-signed cert, Open up IIS manager 
(Administrative Tools->Internet Information Services (IIS) Manager), Open the 
Server subfolder, open the 'Web Sites' folder, and open the 'Default Web Site', 
there will be several virtual directories (VD) below the DWS including owa, and 
Autodiscover. RC the DWS and select Properties, then click the 'Directory 
Security' tab, then click 'Server Certificate' and then click 'Next' at the SSL 
welcome wizard. The next step depends if you already have an SSL certificate 
for mail.domain.com or not. If you do then click 'Replace the current 
certificate' and follow the instructions. If you do not have an SSL certificate 
then select the 'Remove the current certificate'. The latter will only remove 
the certificate from the DWS, it will stay in the windows certificate store so 
if you ever need it in the future you can always get it back. After you remove 
the certificate, re-run the wizard and it should ask you to go through the 
process of asking for an SSL certificate, follow the wizard which will create 
an certreq.txt file which you will need to make the application at a 
Certification Authority (CA) company, such as GoDaddy or others. I will leave 
this to you to follow since the process varies a bit from CA to CA (ie for 
GoDaddy you need to install an intermediate certificate, which may not be 
necessary for more expensive CAs. I am using a turbo ssl cert which is 
registered for mail.domain.com and costs $20/year.
At this point you should have your mail.domain.com cert on the DWS, and any 
other intermediate certs installed.
Next lets change owa so you need to just enter your username and not 
domain\username; In EMC go to Server Configuration->Client Access, RC the owa 
(DWS) click Properties, click the authentication tab, select the 'use 
forms-based authentication:' and then select the 'User name only', then click 
on Browse and choose your logon domain. Click 'Ok' to exit.
To install Outlook Anywhere in EMC go to Server Configuration->Client Access, 
RC the server and select 'Enable Outlook Anywhere', for the External host name 
use: mail.domain.com , External authentication methods: choose NTLM 
authentication, do not select 'Allow secure channel (SSL) offloading', click 
Finish to exit.
Next we need to change the URLs used autodiscover so that all services point to 
mail.domain.com.
In EMC go to Server Configuration->Client Access choose the Offline Address 
Book (OAB) Distribution tab, RC the OAB (DWS) and select properties, Click on 
the URLs tab and put in: https://mail.domain.com/oab for both both internal and 
external URLs. Click 'Ok' to accept and exit.
Do the same for owa by going to Server Configuration->Client Access (Outlook 
Web Access tab) andRC the owa (DWS) and choose properties, on the General tab 
change the Internal and External URLs to: https://mail.domain.com/owa , click 
'Apply', an extra feature you may want to give is access to network shares 
through owa, this is available on the Documents box in owa, if you do then go 
to the 'Remote File Servers' tab and click the 'Configure' button on the 
bottom, enter the domain you are using, ie for mail.domain.com you would put 
domain.com, click 'add' then click 'ok' to exit. Then click on the 'Allow' 
button and enter the FQDN of your CAS, ie if the CAS computer name is 
mx1.domain.com, then enter mx1.domain.com and click 'add' then 'ok'. This will 
give owa users access to any network shares that exist on mx1. Click 'ok' to 
save and exit. If you do not want this then disregard that previous procedure 
and click 'ok' to exit.
Next we'll change the URLs for the Unified Messaging, while this step is 
probably not necessary for most people, it will look better at the end. However 
to change the URLs we need to go to the EMS.
Open the EMS and enter the following command;
Set-UMVirtualDirectory "UnifiedMessaging (Default Web Site)" -InternalURL 
https://mail.domain.com/Unifiedmessaging/Service.asmx -ExternalURL 
https://mail.domain.com/Unifiedmessaging/Service.asmx
Next we change the URLs of the Availability service which will also be the same 
for OOF, in EMS enter the following command;
Set-WebServicesVirtualDirectory -Identity "EWS*" -InternalURL 
https://mail.domain.com/EWS/Exchange.asmx -ExternalURL 
https://mail.domain.com/EWS/Exchange.asmx
Finally we set the autodiscover URL, now this is a little special since it is 
not possible to set the external URL of autodiscover. Outlook 2007 is set to 
look for autodiscover.domain.com or domain.com/autodiscover, and this is in my 
opinion where all the security alert mess comes from. Anyways in the EMS enter 
the following command;
Set-ClientAccessServer -Identity "your CAS server name (ie mx1)" 
-AutoDiscoverServiceInternalUri 
https://mail.domain.com/autodiscover/autodiscover.xml
Ok all done with EMS, you can close it and go to your DNS management, 
Administrative tools->DNS. First in the Foward Lookup Zone (FLZ) for 
domain.com, RC the domain.com and select 'New Host (A)', enter: mail ,for the 
name and input the Internal IP of your CAS. Next RC the FLZ under your server 
and select 'New Zone', click 'Next' at the wizard introduction, leave the zone 
type as Primary and ActiveDirectory integrated, click 'Next', leave the zone 
replication on the default, which is to all domain dns servers, click 'Next', 
For the name enter: autodiscover.domain.com , click 'Next', for the dynamic 
updates change the setting to 'Allow both unsecure and secure dynamic updates, 
click 'next then click 'Finish'. Now RC the new autodiscover.domain.com and 
select 'New Alias (CNAME)', leave the name field blank and just click on the 
Browse button, In the new browse window, double-click (DC) the server name, DC 
the FLZ folder, DC domain.com and then select the mail entry, click 'ok' to 
complete. You can now close DNS.
I would recommend restarting the server to insure that the new settings are 
accepted. One thing you will want to check after the restart is to go to 
EMC->Server Configuration->Mailbox, RC the mailbox database, select properties, 
click on the 'Client Settings' tab and verify that you have the 'Default 
Offline Address Book' listed in the Offline address Book window, if not click 
on the Browse button and select it. If it was not there then restart the server 
again after you have selected it.
Ok almost done! You should be able to start up a Outlook 2007 client and when 
adding an exchange mail account it should use the autodiscover feature to get 
all the URLs. Hopefully everything should work, if you do get a Security Alert 
windows then try restarting the client and server, also verify that the SSL 
cert is accepted on the client. If everything did go well then Outlook can 
connect and send/receive from exchange. Now you can check that all the URLs are 
pointing to mail.domain.com, while holding down the left 'Ctrl' button RC the 
Outlook icon in the system tray, this should give you a menu which has 'Test 
e-mail Autoconfiguration' in the test window, enter your email (ie 
user@xxxxxxxxxx), unselect the "use guesssmart" and "secure guesssmart 
authentication" then click 'Test'
If everything goes well then you should have 2 sections after the results come 
in, one for Exchange RPC and the other Exchange HTTP. The RPC is for LAN 
connections and HTTP is for HTTP connections. In both sections all the URLs 
should start https://mail.domain.com
If this is not the case then go back and find the problem.
Another test to do is to verify that your OWA is working internally. If you 
open Internet Explorer (IE) and enter https://mail.domain.com/owa , don't 
forget to change domain to whatever your domain is. This should give you the 
OWA login webpage, if not then go back and find the problem. You should not 
have any Security Alerts with the OWA.
 If this is ok then your 200x Outlook clients should be working ok internally 
and your 2003 clients should be ok externally. However if you try your Outlook 
2007 clients from the internet you will probably find that they give a Security 
Alert, and that is because they are looking for either an SSL with a name of 
autodiscover.domain.com or domain.com. Since yours is for mail.domain.com it 
will give a name mismatch error. To resolve this you must access your external 
dns entries which are usually handled by your hosting provider. For your 
external DNS you will have a MX record for where your mail is sent and probably 
entries for www, ftp, etc. These are the way that computers on the internet 
find domain.com resources. Usually it takes 4 to 24 hours for adding or 
changing the external DNS entries to actually start redirecting clients, so 
don't expect just because you changed the MX record that your email will be 
redirected right away. The setup is very similar to the DNS entries for the 
internal network, for the external DNS entries you will have the MX record to 
point to mail.domain.com (MX cannot point to an IP), you will need a Host 
record (A) that is for mail.domain.com which points to your external IP and 
finally an Alias (CNAME) entry for autodiscover.domain.com which will point to 
mail.domain.com.
This way when Outlook 2007 is on the internet and asks joeblow_nameserver for 
autodiscover.domain.com it will be sent to your external DNS entries where it 
will find autodiscover.domain.com which is an alias for mail.domain.com, the 
exact details of why outlook accepts it i am not sure, but it doesn't give me 
any complaints. So this way you don't need multiple external IPs (expensive), 
nor SAN SSL certificates (unnecessary and expensive), nor create multiple 
internal websites (unnecessary).
I have been using this for a few weeks now and everything appears normal and 
stable, i have been using Outlook 2007, i have not tested this on Outlook 2003 
however i do not think there should be any problems. The OWA and Outlook 
clients have no problems connecting, the only thing which i find a bit 
un-normal is that it seems to take about 2 minutes for Outlook to connect and 
synchronize, with Exchange 2003 and Outlook 2003 it seems to be quite a bit 
faster, if anyone can comment on this I'd appreciate any insight.
I have tested this also with Windows Mobile 2003SE and the activesync works 
well, if you have the GoDaddy cert you will need to add the CA cert to the 
WM2003 trusted root store, then after that it connects fine.
Most of this information is around the internet but I thought this would be 
useful to write down in one place since i didn't find much information about 
external DNS settings. I did leave out some extra information about redirecting 
the OWA URL, which allows users to log into the port 80 http owa url and then 
get redirected to the 443 https url, however i am not really satisfied with the 
current method of the redirect html page. If i find something i'll post back. 
Anyways i hope this give some insight for some and will help with the 
installation.

Heh heh...Steve


-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Thursday, September 20, 2007 11:16 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

The fact is you just can't be sure, in my book, that makes is useless if you 
want to provide a robust solution and not have to worry about use 
location/infrastucture...anyhow, just testing my logic before I decide what to 
tell customers...

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: 20 September 2007 15:05
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

That's kinda myopic...
Your statement suggests that you think all OL clients will be found behind CERN 
or SOCKS proxies.  That just ain't true.
Most folks at home use some CompIsUs $25 toy that barely qualifies as a NAT 
device; much less a firewall or proxy.  In this case, the SRV record lookup 
will (may?) work.


-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Thursday, September 20, 2007 7:00 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

How about we look at it like this; the SRV solution, in reality, is useless! :-P

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: 20 September 2007 14:48
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

I see what you mean.
Look at it this way - the benefit for a SRV record in this case is to specify a 
non-standard port if one is required.

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Thursday, September 20, 2007 3:29 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

From what I can tell, OA looks for the A record first, this is the bit that 
seems silly...especially when combined with the issues of SRV and CERN proxies.

Quote from KB:

In this example, the Autodiscover service does the following when the client 
tries to contact the Autodiscover service:

1. Autodiscover posts to https://contoso.com/Autodiscover/Autodiscover.xml. 
This fails.
2. Autodiscover posts to 
https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml. This fails.
3. Autodiscover performs the following redirect check:
GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
This fails.
4. Autodiscover uses DNS SRV lookup for _autodiscover._tcp.contoso.com, and 
then "mail.contoso.com" is returned.
5. Outlook asks permission from the user to continue with Autodiscover to post 
to https://mail.contoso.com/autodiscover/autodiscover.xml.
6. Autodiscover's POST request is successfully posted to 
https://mail.contoso.com/autodiscover/autodiscover.xml.

The Outlook 2007 "Test E-Mail Auto Configuration" utility also follows the same 
sequence of doing A records first.

JJ

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: 20 September 2007 01:03
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

Actually, what I'm saying is that if OL 2003/7 is operating as a CERN proxy 
client, it performs absolutely no name queries at all; regardless of whether 
the name is listed as an A, SRV, TXT, CNAME, etc. record.  This is the basic 
nature of a CERN proxy client; it sends a "gimme this, wouldya?" request 
without regard for how the endpoint might be resolved.  Thus, OL will never 
communicate with a DNS server in this scenario.

The egress proxy will seek an A record, since there is no way for the CERN 
proxy client to specify how the proxy should resolve the destination (it's just 
not part of the protocol).

You're correct that you have to maintain A as well as SRV records if you intend 
to support CERN proxy as well as direct-connected clients.  I'm not sure how 
"silly" this is, since CERN proxy mechanisms existed long before OL started 
using autodiscover.  AFAIK, OL will seek the SRV record first, since this is 
much more informative than the A record.

Jim

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Tuesday, September 18, 2007 3:42 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs

Hi Jim,



So, in reality, we are saying that you can never be sure Outlook 2007 will work 
correctly with SRV records if you are unsure if the client will ever be working 
from behind a CERN proxy??



This seems a little silly as the SRV check is the last in the list, so 
therefore you will always need an A record for autodiscover.domain.com to cater 
to clients that *may* be behind a proxy. If this A record exists, surely 
Outlook will never actually use the SRV record (as it is only used if the A 
record cannot be found) and you still need ISA publishing and certs for 
autodiscover.domain.com to allow for "behind proxy" outlook clients...



As we provide solution for customers, I cannot really afford to deploy a 
solution that may or may not work depending on whether the Outlook client is 
behind a proxy or not. So I feel forced to have to go with the A record method 
(reluctantly) to avoid potentially embarrassing questions when a CEO cannot get 
OA to work when at an internet café that uses a CERN proxy...



Am I way off base here or does the logic seem wrong to you???



Cheers



JJ



From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: 31 August 2007 15:00
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs



The problem is that many applications operating behind CERN, SOCKS or Socket 
proxies can't use SRV records.

1.      CERN proxy clients *never* perform name resolution for themselves other 
than to determine if a host is local or remote.  When it comes time to make the 
connection, OL (for instance), will simple send a "GET 
http://autodiscover.domain.tld/autodiscover.xml"; via its local CERN proxy.  The 
proxy assumes that it should resolve "autodiscover.domain.tld" using an A 
record query and continues on that basis  If all you build is a SRV record, 
this connection will fail.

2.      SOCKS proxy clients *may* self-resolve names; it depends on the SOCKS 
version in use by the application and SOCKS proxy.  For the record, ISA 
operates as SOCKS 4.3A, meaning that it is capable of performing name 
resolution on behalf of the client.  If the application knows that it is 
speaking to a SOCKS4.3a proxy, it will make the connection request using the 
hostname.  In this case, the proxy handles name resolution in the same way that 
a CERN proxy does.  If the SOCKS proxy is operating as SOCKS4 or earlier and 
the application knows this, the application is required to perform its own name 
resolution.

3.      Socket proxy (think FWC) clients will perform name resolution as if 
they had access to the 'Net.  How this process is handled depends on how the 
client makes the name lookup request.  If it (as OL does) makes a Winsock 
GetHostByname or GetAddrInfo call, they don't specify the type of record they 
want, and Winsock (and the Winsock LSP/BSP) will send it to the proxy as 
received.



IOW, it's a rare case where a proxy-served client will even seek; much less 
receive the SRV record.



Jim



From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thomas W Shinder
Sent: Friday, August 31, 2007 6:42 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs



Hi Jason,



OK, that makes perfect sense and it's the scenario I'm testing today. One 
listener, one rule for Outlook Anywhere and one rule for Autodiscovery, correct?



So I was right that you can't use the /AutoDiscover path that is included in 
the Outlook Anywhere rule since the Outlook Anywhere rule doesn't respond to 
the public name autodiscover.domain.com. The Outlook Autodiscover rule would 
respond to autodiscover.domain.com and forward to the /AutoDiscover path.



The SRV record solution will solve ALL of this complexity because it will 
bypass the need for a second URL and second IP address and second certificate. 
However, its a hotfix that you have to call PSS to download and will be 
included with Office 2007 SP1.

















Thanks!

Tom



Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)





________________________________

        From: isapros-bounce@xxxxxxxxxxxxx 
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
        Sent: Friday, August 31, 2007 8:15 AM
        To: isapros@xxxxxxxxxxxxx
        Subject: [isapros] Re: ISA and SAN Certs

        Yep - one listener, two IPs, each IP assigned a different SSL cert.



        Not sure if the SRV record will negate the need for the autodiscover 
URL and hence allow us to get away with a single SSL cert - have to check 
this...



        From: isapros-bounce@xxxxxxxxxxxxx 
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
        Sent: 31 August 2007 14:13
        To: isapros@xxxxxxxxxxxxx
        Subject: [isapros] Re: ISA and SAN Certs



        Hi Jason,



        One Web listener, but two IP addresses are being used by the Web 
listener, correct?



        Thanks!

        Tom



        Thomas W Shinder, M.D.
        Site: www.isaserver.org <http://www.isaserver.org/>
        Blog: http://blogs.isaserver.org/shinder/
        Book: http://tinyurl.com/3xqb7
        MVP -- Microsoft Firewalls (ISA)





________________________________

                From: isapros-bounce@xxxxxxxxxxxxx 
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
                Sent: Friday, August 31, 2007 6:50 AM
                To: isapros@xxxxxxxxxxxxx
                Subject: [isapros] Re: ISA and SAN Certs

                Hi Tom,



                Managed to get this working today too, although I am using two 
individual certs on the same external web listener. The internal cert on 
Exchange is SAN'd up and ISA publishes everything to the internal cert common 
name irrespective of the public URL.



                The key to most of it working is defining correct URLs in 
Exchange where is defines "External URLs" for things like OOF, OAB, EWS etc.



                Now we have all exchange 2k7 services (and all the new funky 
stuff) working externally...had to do a lot of it by investigation and cobbling 
blog entries together, not ideal, but go there at last.



                We currently have it working without SRV records, but just 
waiting for the ISP to add these records to test if that is a better solution...



                Cheers



                JJ



                From: isapros-bounce@xxxxxxxxxxxxx 
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
                Sent: 31 August 2007 00:32
                To: isapros@xxxxxxxxxxxxx
                Subject: [isapros] Re: ISA and SAN Certs



                I'd think that Jim might need to update his SAN article. The 
article implies that ISA doesn't support SANs on the Web listener, however I 
have a guy who has the autodiscover FQDN as a second SAN on the certificate 
bound to his Web listener and he's shown me strong evidence that it actually 
works, even though it shouldn't.



                I wish the Exchange or ISA UE teams could get it together to 
explain how to get autodiscovery working correctly and more importantly, show 
us how it works with and without DNS SRV records. It looks like once you have 
DNS SRV records, its a no brainer.



                Tom



                Thomas W Shinder, M.D.
                Site: www.isaserver.org <http://www.isaserver.org/>
                Blog: http://blogs.isaserver.org/shinder/
                Book: http://tinyurl.com/3xqb7
                MVP -- Microsoft Firewalls (ISA)





________________________________

                        From: isapros-bounce@xxxxxxxxxxxxx 
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
                        Sent: Wednesday, August 29, 2007 2:38 PM
                        To: isapros@xxxxxxxxxxxxx
                        Subject: [isapros] Re: ISA and SAN Certs

                        Never mind :)



                        I found it:



                        http://support.microsoft.com/kb/940881



                        Thomas W Shinder, M.D.
                        Site: www.isaserver.org <http://www.isaserver.org/>
                        Blog: http://blogs.isaserver.org/shinder/
                        Book: http://tinyurl.com/3xqb7
                        MVP -- Microsoft Firewalls (ISA)





________________________________

                                From: isapros-bounce@xxxxxxxxxxxxx 
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
                                Sent: Wednesday, August 29, 2007 2:35 PM
                                To: isapros@xxxxxxxxxxxxx
                                Subject: [isapros] Re: ISA and SAN Certs

                                OK, that's an interesting sentence in a KB OL 
update article. But there's no mention of this anywhere else on the ms.com site.



                                In addition, how do we configure the SRV 
records?



                                Service?

                                Protocol?

                                Priority?

                                Weight?

                                Port number?

                                Host offering this service?



                                cid:image001.jpg@01C7F522.ABDB5600



                                I try to read minds best as I can, but I'm 
flailing on this one :))







                                Thomas W Shinder, M.D.
                                Site: www.isaserver.org
                                Blog: http://blogs.isaserver.org/shinder/
                                Book: http://tinyurl.com/3xqb7
                                MVP -- Microsoft Firewalls (ISA)



                                > -----Original Message-----
                                > From: isapros-bounce@xxxxxxxxxxxxx
                                > [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
                                > Sent: Wednesday, August 29, 2007 2:27 PM
                                > To: isapros@xxxxxxxxxxxxx
                                > Subject: [isapros] Re: ISA and SAN Certs
                                >
                                > DatzDeWun!  O'curse it works in real life; I 
tested it.
                                >
                                > http://support.microsoft.com/kb/939184
                                > OL 2K7 seeks a "autodiscovery" SRV record 
first, and only if
                                > that fails,
                                > it'll seek the A record.  This is based on 
the same domain suffix as
                                > specified in the mail domain.
                                > If your OL client is behind a CERN proxy (and 
it knows it), it can't
                                > specify that the proxy should look up a SRV 
record for
                                > autodiscover.sfx.
                                > The proxy assumes that any CERN request will 
be for a "host"
                                > and makes a
                                > DNS query for an A record.
                                >
                                > OL 2K7 uses the SRV record to discover the 
host
                                >
                                > -----Original Message-----
                                > From: isapros-bounce@xxxxxxxxxxxxx
                                > [mailto:isapros-bounce@xxxxxxxxxxxxx]
                                > On Behalf Of Thomas W Shinder
                                > Sent: Wednesday, August 29, 2007 12:15 PM
                                > To: isapros@xxxxxxxxxxxxx
                                > Subject: [isapros] Re: ISA and SAN Certs
                                >
                                > BAM!!!!
                                >
                                > I think I get it. On the TO tab for the 
autodiscover.msfirewall.org, I
                                > can still use owa.msfirewall.org since it 
resolves to the same IP
                                > address as autodiscover.msfirewall.org on the 
internal network -- and
                                > the path is going to /autodiscover, so that's 
cool. It's all making
                                > sense on paper -- now to see if it works in 
real life :)
                                >
                                > BTW -- why do I need a SRV record for OL 
autodiscovery? I haven't seen
                                > any documentation on that requirement on the 
Exchange side.
                                >
                                > Thanks!
                                > Tom
                                >
                                > Thomas W Shinder, M.D.
                                > Site: www.isaserver.org
                                > Blog: http://blogs.isaserver.org/shinder/
                                > Book: http://tinyurl.com/3xqb7
                                > MVP -- Microsoft Firewalls (ISA)
                                >
                                >
                                >
                                > > -----Original Message-----
                                > > From: isapros-bounce@xxxxxxxxxxxxx
                                > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
                                > > Sent: Wednesday, August 29, 2007 2:09 PM
                                > > To: isapros@xxxxxxxxxxxxx
                                > > Subject: [isapros] Re: ISA and SAN Certs
                                > >
                                > > Yes; I'd forgotten about the OL client's 
"SAN problem".
                                > > It amazed me how much noise the Exch folks 
make about the same
                                > > limitation for ISA..  ..but I digress.
                                > >
                                > > "Web Publishing Rule that is publishing the
                                > > autodiscover.msfirewall.org/autodiscover 
path must be
                                > > configured on the
                                > > TO tab to use autodiscover.msfirewall.org " 
- how do you
                                > cone to that
                                > > contusion?
                                > > Why do you think you need to use 
"autodiscover" in the ISA rule
                                > > published hostname?  Use whatever works for 
ISA and let the
                                > > client be as
                                > > stupid as you want.
                                > >
                                > > -----Original Message-----
                                > > From: isapros-bounce@xxxxxxxxxxxxx
                                > > [mailto:isapros-bounce@xxxxxxxxxxxxx]
                                > > On Behalf Of Thomas W Shinder
                                > > Sent: Wednesday, August 29, 2007 12:05 PM
                                > > To: isapros@xxxxxxxxxxxxx
                                > > Subject: [isapros] Re: ISA and SAN Certs
                                > >
                                > > Hi Jim,
                                > >
                                > > CIL...
                                > >
                                > > Thomas W Shinder, M.D.
                                > > Site: www.isaserver.org
                                > > Blog: http://blogs.isaserver.org/shinder/
                                > > Book: http://tinyurl.com/3xqb7
                                > > MVP -- Microsoft Firewalls (ISA)
                                > >
                                > >
                                > >
                                > > > -----Original Message-----
                                > > > From: isapros-bounce@xxxxxxxxxxxxx
                                > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
                                > > > Sent: Wednesday, August 29, 2007 1:49 PM
                                > > > To: isapros@xxxxxxxxxxxxx
                                > > > Subject: [isapros] Re: ISA and SAN Certs
                                > > >
                                > > > All good points, but really orthogonal to 
the question of how ISA
                                > > > handles SAN certs.  Actually, I wrote 
that because some folks were
                                > > > whining about how ISA handled SAN certs 
in general.  In
                                > > fact, I tried
                                > > > not to delve into the variant forms of 
self-inflicted ISA
                                > manglement
                                > > > pain that were filling other blogs.
                                > > >
                                > > > Q1 - Why do you need a second listener?  
Use your DNS to point
                                > > > autodiscover to the same Exch listener.  
The public name is a
                                > > > rule; not
                                > > > a listener arttribute.
                                > >
                                > > TOM: We need a second listener because we 
can't have two
                                > certificates
                                > > with different common names listening on 
the same listener using the
                                > > same IP address. OK, in ISA 2006 I *can* 
use multiple
                                > > certificates using
                                > > the same listener, but each of the 
certificates must be
                                > assigned to a
                                > > different IP address, so no big deal there 
-- so I create two
                                > > different
                                > > Web Publishing Rules -- one for 
owa.msfirewall.org and a second Web
                                > > Publishing Rule for 
autodiscover.msfirewall.org. So far so
                                > > good and SANs
                                > > aren't even an issue.
                                > >
                                > > > Q2 - why does the external OL client give 
a rats bahootie
                                > > > what's listed
                                > > > in the cert used at the CAS?  It never 
sees it.
                                > >
                                > > TOM: That's true and I didn't mean to imply 
that it did. The
                                > > concern is
                                > > that common name and the first SAN on the 
Web site
                                > > certificate bound to
                                > > the Client Access Server site is 
owa.msfirewall.org. The
                                > second SAN is
                                > > autodiscover.msfirewall.org
                                > >
                                > >
                                > > > Q3 - why is the lack of the 
autodiscover.suffix public
                                > name make the
                                > > > /autodiscover path "useless"?  
"Incomplete" perhaps, but
                                > > > hardly useless.
                                > >
                                > > TOM: Because the OWA publishing rule is 
listening for
                                > > owa.msfirewall.org, NOT 
autodiscover.msfirewall.org. Since
                                > > there are two
                                > > certificates involved here, one with the 
common name
                                > > owa.msfirewall.org
                                > > and a second with 
autodiscover.msfirewall.org -- we have to use two
                                > > different IP addresses, and 
owa.msfirewall.org is NOT going
                                > to resolve
                                > > to the same IP address as 
autodiscover.msfirewall.org. Thus,
                                > > adding the
                                > > /autodiscover path to the 
owa.msfirewall.org Web Publishing
                                > Rule won't
                                > > work and is extraneous. The /autodiscover 
path only applies to the
                                > > autodiscover.msfirewall.org Web Publishing 
Rule.
                                > >
                                > > >
                                > > > IOW, create your SRV and A records for 
autodiscover.suffix, add
                                > > > "autodiscover.suffix" to the public names 
(ISA 2006 only) and
                                > > > make sure
                                > > > the cert used in the ISA web listener 
includes
                                > > > "autodiscover.suffix" in
                                > > > the SAN.
                                > >
                                > > Again, the issue isn't with the Web 
listeners, I have no
                                > problem with
                                > > that. The issue is with the connection 
between the ISA
                                > > Firewall and the
                                > > Client Access Server. The Web site 
certificate bound to the Client
                                > > Access Server has a common name and a first 
SAN name of
                                > > owa.msfirewall.org and a second SAN name of
                                > > autodiscover.msfirewall.org.
                                > >
                                > > Given that, the Web Publishing Rule that is 
publishing the
                                > > autodiscover.msfirewall.org/autodiscover 
path must be
                                > > configured on the
                                > > TO tab to use autodiscover.msfirewall.org 
-- HOWEVER, and
                                > this is THE
                                > > QUESTION -- with the ISA Firewall when 
establishing the SSL channel
                                > > between itself and the Client Access 
Server, be able to use
                                > the SECOND
                                > > SAN on the Client Access Server Web site 
certificate to allow the
                                > > connection?
                                > >
                                > > Make sense?
                                > >
                                > >
                                > > >
                                > > > Jim
                                > > >
                                > > > -----Original Message-----
                                > > > From: isapros-bounce@xxxxxxxxxxxxx
                                > > > [mailto:isapros-bounce@xxxxxxxxxxxxx]
                                > > > On Behalf Of Thomas W Shinder
                                > > > Sent: Wednesday, August 29, 2007 11:33 AM
                                > > > To: isapros@xxxxxxxxxxxxx
                                > > > Subject: [isapros] Re: ISA and SAN Certs
                                > > >
                                > > > This is a good step in understanding some 
of the issues,
                                > > but I suspect
                                > > > the major problems people are running 
into relates to
                                > publishing the
                                > > > autodisocvery site. You'll notice that 
when you run the Exchange
                                > > > Publishing Wizard in ISA 2006 that is 
includes an
                                > > /autodiscover path,
                                > > > which is completely useless, since the 
client is looking for
                                > > > autodiscover.domain.com/autodiscover and 
not the Client
                                > > Access Server
                                > > > Public Name, which would be something 
like owa.domain.com.
                                > > >
                                > > > OK, easy problem to solve, right? All we 
need to do is
                                > > create a second
                                > > > Web listener on a second IP address and 
configure it to listen for
                                > > > public name autodiscover.company.com.  
HOWEVER, the Client Access
                                > > > Server's common/subject name and first 
SAN is owa.company.com. The
                                > > > second SAN is autodiscover.company.com.
                                > > >
                                > > > So, if we put on the TO tab 
autodiscover.company.com, will
                                > > ISA 2006 be
                                > > > able to "consume" the second SAN to 
support to the Outlook 2007
                                > > > autodiscovery service?
                                > > >
                                > > > Thanks!
                                > > > Tom
                                > > >
                                > > > Thomas W Shinder, M.D.
                                > > > Site: www.isaserver.org
                                > > > Blog: http://blogs.isaserver.org/shinder/
                                > > > Book: http://tinyurl.com/3xqb7
                                > > > MVP -- Microsoft Firewalls (ISA)
                                > > >
                                > > >
                                > > >
                                > > > > -----Original Message-----
                                > > > > From: isapros-bounce@xxxxxxxxxxxxx
                                > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] 
On Behalf Of Jim Harrison
                                > > > > Sent: Wednesday, August 29, 2007 1:10 PM
                                > > > > To: isapros@xxxxxxxxxxxxx
                                > > > > Subject: [isapros] ISA and SAN Certs
                                > > > >
                                > > > >
                                > > > > Another isablog for your reading 
pleasure.
                                > > > >
                                > > > >
                                > > > > 
http://blogs.technet.com/isablog/archive/2007/08/29/certificat
                                > > > > es-with-mu
                                > > > > 
ltiple-san-entries-may-break-isa-server-web-publishing.aspx
                                > > > >
                                > > > > All mail to and from this domain is 
GFI-scanned.
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > >
                                > > >
                                > > > All mail to and from this domain is 
GFI-scanned.
                                > > >
                                > > >
                                > > >
                                > > >
                                > >
                                > >
                                > > All mail to and from this domain is 
GFI-scanned.
                                > >
                                > >
                                > >
                                > >
                                >
                                >
                                > All mail to and from this domain is 
GFI-scanned.
                                >
                                >
                                >
                                >

All mail to and from this domain is GFI-scanned.


All mail to and from this domain is GFI-scanned.





All mail to and from this domain is GFI-scanned.





All mail to and from this domain is GFI-scanned.
















Other related posts: