[isapros] Re: ISA and SAN Certs
- From: "Jason Jones" <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Thu, 20 Sep 2007 14:59:05 +0100
Which the client-side proxy would then probably block, as it is a non-standard
port :-) :-)
-----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.
Other related posts:
