Re: ADFS - Not Authorized To View Message

Tech-Archive recommends: Fix windows errors by optimizing your registry

It sounds like you are trying to build an NT token-integrated app instead of
a claims aware application. My experience with this is that these types of
apps are a bit harder to get working and harder to troubleshoot than claims
aware apps because of the extra layer of indirection/mapping between the
claims and the token that gets generated and the different types of mapping
options that are available.

Essentially, token apps can generate a Windows token for the authenticated
user based on one of two mapping approaches:
- token generated by mapping the UPN claim to a specific Windows user in
the forest with that UPN (shadow account)
- token generated by mapping group claim(s) in the ADFS token to
organizational claim(s) that has an associated resource group in the
resource forest (shadow groups)

There are actually 4 different options, as you can tell ADFS to only do
shadow accounts, do both but try shadow accounts first, do both but try
shadow groups first or only do shadow groups. My preference is usually to
use one of the "extreme" settings as I think it forces you to pick a mapping
strategy and use it, but I can imagine scenarios where the extra flexibility
is useful.

For shadow accounts, it is pretty easy. The UPN claim issued by the
resource FS to the app must match a user in the resource forest with that
UPN. If it doesn't, you won't get a Windows token for that user.

For shadow groups, it is a little more complex. The authenticated user must
have at least one group claim from the resource FS that has a resource group
associated with it. You can have multiple, but there must be at least one.

What I generally like to do is verify that this is all working correctly
with a claims aware test app first so that I can see how the claims are
being transformed and how they appear to the application. Once this is
verified, then a token aware app with the same claims enabled should get the
same claims for any given user. Then, you just need to know how the mapping
will work and you can get predictable results. I also posted on my blog a
few months back a sample ASP.NET app that will dump out the contents of the
Windows token for the authenticated user and allow you to see what the
identity and group membership of the user is. I find that to be easier to
test with an a full scale app.

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

Another thing to be aware of is that if ADFS fails to map an ADFS user/SAML
token to a Windows token (shadow accounts or groups), then it will create a
token for the "anonymous" Windows user (token id = 0). This is not the same
as the user defined in IIS as the anonymous user (IUSR_XXX). If this
mapping to the anonymous user happens, the consuming application will tend
to choke on it badly. That may be what you are seeing now.

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
--
"nboothe" <nboothe@xxxxxxxxx> wrote in message
news:1178114897.543932.257640@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'm getting SO close to making this work I can't stand it.

I've gotten ADFS implemented to the point that I go to
http://servername/certsrv
and am prompted to accept two separate certificates, then a logon box
appears. I type in my AD user name and password and Internet Explorer
starts doing something, the word "Working..." appears in the title
bar, then I get a page that says "You are not authorized to view this
page".

In the ifsaplog have a failures. One in particular says
webssophandleupnlogon failed for urn:federation:domain:domain\upn.
It's not even possible to logon with domain/UPN is it?

I think I may have set up my URI wrong? Or my claims? I'm using a
group claim and I mapped it an AD group. Am I supposed to use an
identity claim?

In my event logs on the web server there is an event 104 every time I
get the IE error page. Part of the message says "The cookies that
were presented by the client could not be validated.


There is a light at the end of the tunnel finally, hopefully it's not
a train.

Thanks for any help you can provide!



.

Relevant Pages

  • Re: ADFS - Not Authorized To View Message
    ... claims and the token that gets generated and the different types of mapping ... organizational claimthat has an associated resource group in the ... shadow accounts, do both but try shadow accounts first, do both but try ... with a claims aware test app first so that I can see how the claims are ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS - Not Authorized To View Message
    ... If I put all the pieces in the same network it all works perfect. ... claims and the token that gets generated and the different types of mapping ... shadow accounts, do both but try shadow accounts first, do both but try ... with a claims aware test app first so that I can see how the claims are ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS - Not Authorized To View Message
    ... For your token app, are you trying to map the ADFS token to a user in the ... store of the resource partner itself, you can't map based on groups. ... shadow accounts, do both but try shadow accounts first, do both but try ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS - Not Authorized To View Message
    ... the web server will use the "token aware" agent that integrates with IIS, ... then the web server must be a domain member of the forest the resource FS is ... if you want to use the "shadow groups" mapping ... approach for a token-based app, that can only be accomplished with separate ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS June 2006 Step-by-step guide
    ... One of those tabs is called "resource accounts". ... the incoming user's UPN must map to a UPN in ... UPN will be used create the windows token. ... claims mappings showing up in the UI of the claims app. ...
    (microsoft.public.windows.server.active_directory)