[isapros] Re: ISA and SAN Certs
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Wed, 29 Aug 2007 14:37:59 -0500
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 <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?
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.
>
>
>
>
Other related posts: