Re: ADFS, ISA and SSL offloading
- From: "Phillip Windell" <philwindell@xxxxxxxxxxx>
- Date: Mon, 19 Jan 2009 09:32:56 -0600
Excellent detective work.
Good job!
--
Phillip Windell
www.wandtv.com
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
"Avis77" <Avis77@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1B098BB6-6DB0-4EA3-B9BD-AD22D0A9856B@xxxxxxxxxxxxxxxx
Thanks for all the responses. In the process I have learnt a lot.
After using tools like fiddler and wireshark I was able to see that the
final redirection URL coming to the client from the ADFS web agent was not
what the client would understand. This was something which I already knew
looking at the ISA log. But what was causing this issue is what I did not
know and hence to think of a solution was not possible.
I finally enabled logging (with a couple of registry entries) on the ADFS
web agent and saw that the final redirection URL was formed with https
instead of http. This should have struck to me earlier looking at all the
redirection URLs because the wctx parameter in the query string actually
contains this URL. So, if my website is called ssoapps running on, say,
port
81 then the web agent was redirecting the client to
https://ssoapps:81/testssoapp.
Looking at this made me perform Link Translation in ISA and that's it, it
worked!
The mapping I configured in Link Translation is simple - replace any text
matching https://ssoapps:81/ with https://ssoapps/
Avis
"Joe Kaplan" wrote:
Thanks for the info, Phillip. That's helpful.
I'd be shocked if ADFS actually suffered from any protocol violations
that
ISA was sensitive to as ADFS is a Microsoft product (Active Directory
Federation Services, which is a component of 2003 R2 server and a role in
2008 server). That said, it makes to avoid the whole issue if possible.
On the other hand, the OP may have other things he needs to do in ISA
which
makes SSL termination necessary for him. For me, I'm really curious to
see
if this can be made to work at the IIS level, regardless of what is
providing the front end to the browser, just to know the options.
Thanks!
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
"Phillip Windell" <philwindell@xxxxxxxxxxx> wrote in message
news:eTQaOl$dJHA.1328@xxxxxxxxxxxxxxxxxxxxxxx
"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:eZvAJX$dJHA.5288@xxxxxxxxxxxxxxxxxxxxxxx
Regarding ISA, I don't know anything about ISA specifically. However,
ADFS is just normal web traffic. There should be nothing particular
about it that is different than any normal SSL web app.
Your thinking like a NAT Firewall that does not "process" the content
embedded within the HTTP protocol. This doesn't fit ISA's situation.
The
HTTP Application Filter in ISA is a "proxying" filter,...this means
that
the traffic does not go "through" it,...it only goes "TO" it and then
*dies*. The proxying process then creates and entirely new HTTP session
with the destination and recreates the HTTP content based on its own
methods and inserts it into the HTTP Packets. Now this is not unique
to
ISA Server,...every "proxy" server does this,...but not all of them
would
nessessarily have the same results in the end, some are more loose and
less picky than others.
ISA is extremely picky and is very strick about following all RFCs
concerning HTTP communication. It would not be the first time that a
Product or Protocol running over HTTP did not have its implementation
stictly follow the RFCs which caused ISA to either reject it or "break"
it
when the communication came out the other side. There have already
been
web sites that were revealed to have flaws introduced by the Web Server
Admins in the HTTP headers that caused ISA to reject parts of their
sites.
When the RFCs were applied it was the site that was wrong and not the
ISA,...and they did get their site fixed later. In the process of that
MS
found a few minor flaws of their own and corrected them as well. The
site
belonged to one of the major Airlines. Luckily in this story everyone
worked together and fixed the problems rather than just a bunch of
finger-pointing.
Anyway, the reason I say to leave the SSL intact from end-to-end and
not
open it,....is becuase it will dodge this whole thing. With the SSL ISA
will take a "hands-off" approach to the HTTP Contents and just relay
the
SSL packets on their merry way.
--
Phillip Windell
www.wandtv.com
The views expressed, are my own and not those of my employer, or
Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
.
- References:
- ADFS, ISA and SSL offloading
- From: Avis77
- Re: ADFS, ISA and SSL offloading
- From: Phillip Windell
- Re: ADFS, ISA and SSL offloading
- From: Avis77
- Re: ADFS, ISA and SSL offloading
- From: Joe Kaplan
- Re: ADFS, ISA and SSL offloading
- From: Avis77
- Re: ADFS, ISA and SSL offloading
- From: Joe Kaplan
- Re: ADFS, ISA and SSL offloading
- From: Phillip Windell
- Re: ADFS, ISA and SSL offloading
- From: Joe Kaplan
- ADFS, ISA and SSL offloading
- Prev by Date: Re: [WARNING] Failed to query SPN registration on DC
- Next by Date: Re: Trusts need to see all DC's on each side?
- Previous by thread: Re: ADFS, ISA and SSL offloading
- Next by thread: Group membership in sub-domains
- Index(es):
Relevant Pages
|
