[isapros] Re: ISA and SAN Certs
- From: Jim Harrison <Jim@xxxxxxxxxxxx>
- To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
- Date: Mon, 8 Oct 2007 06:49:06 -0700
CNAME works fine for SSL connections *as long as* the destination certificate
includes a name matching the original FQDN and the client can find it.
For Tom's concern, a mail server with mail.domain.tld in the cert subject and
no SAN would break an autodiscover.domain.tld connection, but if the cert has a
SAN entry that includes autodiscover.domain.tld (and the client can find it),
the connection will proceed just fine.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: Monday, October 08, 2007 6:46 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Actually, CNAME shouldn't work for SSL connections. What name is the client
going to end up using in the SSL session negotiation when you use CNAME records?
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 Jason Jones
> Sent: Monday, October 08, 2007 8:42 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> Ah, good point...so assuming you are using default ports, the
> CNAME idea sounds like a better option then?
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: 08 October 2007 14:39
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> Because only a SRV record can describe a protocol and port
> from a DNS query.
> Lots of folks use custom SSL ports and a SRV record is the
> only way it can be found "automagically".
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Moffat
> Sent: Monday, October 08, 2007 6:22 AM
> 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:
