[isapros] Re: ISA and SAN Certs
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Sun, 7 Oct 2007 09:39:44 -0500
Hey Steve,
Want me to convert this into something to put up on ISAserver.org?
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 Steve Moffat
> Sent: Saturday, October 06, 2007 2:51 PM
> 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:
