[isapros] Re: ISA and SAN Certs
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 31 Aug 2007 09:11:16 -0500
Hi Jim,
True, but I think the SRV scenario is one where the client is external
to the ISA Firewall and the client is a non-domain join host. In that
scenario, the SRV record allows you to use the actual FQDN of the
published service to get autodiscover information instead of the
autodiscover.domain.com FQDN.
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 <http://tinyurl.com/3xqb7>
MVP -- Microsoft Firewalls (ISA)
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
Sent: Friday, August 31, 2007 9:00 AM
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?
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.
Other related posts:
