Re: ADFS Web Agent exception

Glad that worked. :)

I keep thinking about writing a book on this stuff, as I think there is a
need for it. I'm still learning as I go, but there doesn't seem to be a ton
of expertise out there yet, so at this point I feel qualified enough to do
something. :)

You can definitely achieve what you want to do with ADFS. There is a lot to
making it happen, but nothing in your scenario below sounds like a
showstopper to me and we are actually doing similar stuff internally at my
company right now with good success.

For your own internal resources, you need at least one federation server to
serve as a resource federation server for all of your trusting apps. You
also need a federation server that can host your AD and ADAM account stores.
My suggestion would be to create a separate account federation server that
hosts your ADAM account store, as you'll get more flexibility with how you
can map claims to Windows tokens by doing that. That may in turn make it
easier to do certain types of application integrations, especially with apps
that need to use Windows token mode for compatibility. It is also REALLY
helpful to have two federation servers internally so that you can test out
lots of different scenarios without having to get your external partners
involved in your testing.

You can put the AD account store in either the resource federation server or
the account federation server for ADAM. My inclination is to use your
resource federation server so that you have 1 account store in each one.

In order to use integrated auth on the "inside" and forms auth on the public
internet with ADFS and your internal AD users, ADFS supports that out of the
box with the federation service proxy (FSP). It requires some DNS trickery
and even more SSL goofiness to get it working than with the straight stock
federation server, but it does work and will support that exact scenario.

Note that you cannot use the built in Integrated authentication support in
the federation server to authenticate ADAM users. That is because Windows
integrated authentication only authenticates Windows users (it is not doing
anything special in ADFS, it is just doing normal Windows Kerberos auth).
In order to authenticate ADAM users in ADFS, you must use forms auth or the
ADFS support for Basic auth. They way I've done this in the past is to
borrow the clientlogon.aspx page that comes with the FSP install and use
that to replace the one that comes in the /adfs/ls/ vdir FS (which just
redirects to the integrated auth virtual directory).

From the app integration perspective, MOSS allows you to integrate at the
claims/provider level or by just using Windows auth and the built in support
in ADFS to generate Windows tokens from ADFS SAML tokens. That said, the
claims integration is a struggle (for us anyway) and isn't well documented
yet, so expect some initial frustration if you dive in now. It will get
better.

Your other apps can basically choose between token integrationa and claims
integration, although claims integration currently requires .NET 2.0 web
apps and may require code changes, depending on how the app's authorization
model is implemented. There are a lot of devils in those details. The
bottom line is that either can be made to work.

I hope that helps provide some more big picture stuff that can be helpful.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Dima" <Dima@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BFF7FC80-2D1B-4660-99A3-008AD82E5F8E@xxxxxxxxxxxxxxxx
Well, it's official: I'm an idiot!
Thanks for the explanation. Now that I removed the agent from the claimapp
it works fine.

Here's a setup I'm hoping to configure, and I was wondering if you have
some
advice for me:

I would like to set up ADFS to be an integrated SSO solution for my web
applications. I would like to allow access to both internal users (inside
my
domain) and outside users. Internal users are managed using the active
directory on my domain controler. Outside users will be managed using
ADAM. I
have configured two account stores in ADFS, one for AD and one for my ADAM
instance. Now, there are several types of web applications that I need to
secure: MOSS web applications and legacy asp.net 2.0 web applications.
Here's my interpretation of how things should work, feel free to correct
me
if I'm wrong: As far as legacy asp.net 2.0 web applications go, I should
convert them to be claims aware, so keep the custom authZ implementation
embedded in them, and rely on ADFS for authentication. As far as MOSS
goes,
authZ should be implemented inside it, and it should be configured to use
WebSSO authN provider.
Here's my biggest concern, and I was hoping you could clear that out: my
ADFS usage scenario is somewhat of a combination of the usage scenarios
depicted in the ADFS overview doc. I have a need to serve both internal
users, outside individual users and outside federated users. So, my ADFS
setup needs to support all of these different kinds of users. Is it
possible
to do it with ADFS? Can I set up ADFS to log on both domain users from the
inside, and provide a logon form for internet users, and federate to a
trusted ADFS account server for trusted users, all at the same time (for a
single web application)?


"Joe Kaplan" wrote:

I'm a little confused. It looks like you have tracing output from both
the
web service extension AND the HTTP module. I would only expect to see
that
if you were trying to configure the application to do both token-based
integration AND claims-based integration. That is supposed to be
possible,
but generally I wouldn't recommend starting with that. You should do one
or
the other while you are getting your feet wet, and I generally like to
start
with claims as I think it is easier to figure out what's going on there.

Essentially, this means that in IIS Manager, you should NOT have the ADFS
Agent "enabled" checkbox checked, but you should have the ADFS
configuration
set up properly in your web.config with with HTTP module loaded and the
proper configuration of the <websso> section.

I also recommend using the test page/sample app that comes with the Step
By
Step guide so that you can see the claims that are being included in the
token and all of the other federation details.

I have a reasonable test page on my blog that I like to use for testing
token-based applications. It basically just dumps out the user and their
groups for the Windows token that was generated by ADFS (it also works
with
anything else doing Windows auth like IWA or Basic).

http://www.joekaplan.net/DiscoveringTheUsersNameAndGroupsInTheirWindowsToken.aspx

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Dima" <Dima@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:35AA754D-3F0D-4A03-953A-8E7A4BE78BA2@xxxxxxxxxxxxxxxx
One thing that I don't really understand:
From my logs, you can see that ADFS issues a SAML token and that it
generates an output claim with UPN. I assumed that would be enough to
grant
access to an application. Is there any authorization stuff that I need
to
configure in addition to configuring the ADFS account
store/application?
If
so, how/where?
BTW, the logs I generated were from accessing myApp, but I get same
exception when I access claimapp from the stepbystep guide.

"Joe Kaplan" wrote:

I see in the code where that method throws an
UnauthorizedAccessException
if
the the client authentication with the token fails, so that is
probably
what
is going on, but I don't know why that would happen in your case. You
can
see this for yourself if you reverse engineer the assembly with
Reflector
(what I did).

Perhaps you could post some of your verbose log so we could look to
see
how
far it got.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Dima" <Dima@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:145958E5-CC39-402A-83E3-ABDB22C571A8@xxxxxxxxxxxxxxxx
I am getting an exception from the ADFS Web agent. Here's the info:

"Attempted to perform an unauthorized operation.
Description: An unhandled exception occurred during the execution of
the
current web request. Please review the stack trace for more
information
about
the error and where it originated in the code.

Exception Details: System.UnauthorizedAccessException: Attempted to
perform
an unauthorized operation.

ASP.NET is not authorized to access the requested resource. Consider
granting access rights to the resource to the ASP.NET request
identity.
ASP.NET has a base process identity (typically {MACHINE}\ASPNET on
IIS
5
or
Network Service on IIS 6) that is used if the application is not
impersonating. If the application is impersonating via <identity
impersonate="true"/>, the identity will be the anonymous user
(typically
IUSR_MACHINENAME) or the authenticated request user.

To grant ASP.NET access to a file, right-click the file in Explorer,
choose
"Properties" and select the Security tab. Click "Add" to add the
appropriate
user or group. Highlight the ASP.NET account, and check the boxes
for
the
desired access.

Source Error:

An unhandled exception was generated during the execution of the
current
web
request. Information regarding the origin and location of the
exception
can
be identified using the exception stack trace below.

Stack Trace:


[UnauthorizedAccessException: Attempted to perform an unauthorized
operation.]

System.Web.Security.SingleSignOn.WebSsoAuthenticationModule.OnEnter(Object
o,
EventArgs args) +3324

System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
+92
System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
Boolean&
completedSynchronously) +64"

I couldn't find a lot of resources about this online, except from
some
guy
saying it's a problem with the clock difference and SSL
certificates.
However, this is most definitely not my problem since I am running
both
ADFS
and the claims-aware app on a single server.
I have set up ADFS with AD account store, and the claimsapp
claims-aware
application from the step-by-step guide. I have set all the options
and
settings as in that guide except the federation trust which I don't
need
since I am accessing claimsapp from inside the domain, logged on as
a
domain
user.
The ADFS logs show that ADFS does it's job correct, issues a SAML
token
and
returns it as a cookie, but what happens next is beyond me.
I enabled web agent logs and I can't find any error information
there,
nor
in the system event logs.
Anyone have any idea what's going on?








.

Relevant Pages

  • Re: How should we do it with ADFS?
    ... applications (basically be a resource partner with an account store). ... then conversion of those accounts into a directory that ADFS ... and resource federation server and then configure the web server to trust ...
    (microsoft.public.windows.server.active_directory)
  • Re: How should we do it with ADFS?
    ... I definetely need federation server which needs windows 2003 ... standard use cases for ADFS and my company has an identical application ... in order to use ADFS as the account store for the external ...
    (microsoft.public.windows.server.active_directory)
  • Re: How should we do it with ADFS?
    ... applications as ADFS requires SSL for all HTTP communication. ... with a second federation server and a second separate account store. ... Joe Kaplan-MS MVP Directory Services Programming ... When I install the federation services, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS Web Agent exception
    ... I have a single Windows 2003 Enterprise Server R2, hosting ADAM, ADFS, MOSS, ... ADAM account store. ... you need at least one federation server to ...
    (microsoft.public.windows.server.active_directory)
  • Re: How should we do it with ADFS?
    ... According to guide for two forests, you need ADFS account ... and resource federation server and then configure the web server to trust the ... According to my environment since we hold account and web servers, ...
    (microsoft.public.windows.server.active_directory)