[isapros] Re: ISA and SAN Certs
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Wed, 19 Sep 2007 17:50:42 -0700
Egress
Egress
Egress...
:-p
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: Wednesday, September 19, 2007 5:05 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Oh no, he said "egress" -- he's being polluted!
This way to the egress! (P.T. Barnum)
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, September 19, 2007 7:03 PM
> 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.
Other related posts:
