Re: ADFS - Not Authorized To View Message

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

For your token app, are you trying to map the ADFS token to a user in the
resource forest via UPN (shadow account) or to a set of groups (shadow
groups). It sounds like the latter, but it still isn't clear to me.

If it is the latter, you need to make sure that you have configured the
account partner in question to use the setting specifying "use groups only"
(the bottom radio button; can't remember the exact wording off the top of my
head). Note that if you are trying to authenticate a user in the account
store of the resource partner itself, you can't map based on groups. For
the resource partner account store, you can only map based on UPN. This is
a limitation of the way ADFS works.

Assuming you are trying to map based on groups, there are two key things
that are required to make this work:
- The resource application must receive a token for the authenticated user
that contains at least one group claim
- In your organizational claims for the resource partner, the group claims
that you want mapped to resource groups MUST have a resource group defined
for them. This is different from the place where you configure the group
claim extractions in the account store configuration. In fact, it is
possible to extract from one set of groups and map to a different one!

To verify that the authenticated user has the group claim, I would first
test with a claims-based app that simply dumps out the user's ADFS identity
so you can see the claims and verify that the claim is there. You are
basically flying blind until you know that the claim is being passed all the
way through to the application. Once you get that working, then another
token-based resource app configured with the same set of claims enabled
should give you the exact same claims for the token app.

I hope this helps. Token-based apps can be a real pain. :)

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:1178284326.170322.111380@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks for all your help on this so far.

I'm one step away from getting this work I think. I'm no longer
getting the not authorized message. What happens now after logging in
with my username a password the Internet Explorer window goes blank,
the word "Working..." appears in the task bar, the url is pointing to
the adfs proxy and it just sits there for a very long time.

The event logs say that an anonymous cookie is being used and the adfs
logs look like the token/cookie was made and posted to the web server,
but the cookie is blank so the user is null. I've enabled every
identity claim available by default, pointed them to the LDAP
attributes "mail" for E-mail, and "cn" for common name. I've enabled
a group claim that is mapped to the All user group in AD, and tried to
map it to my single account.

I'm overlooking something really simple I'm sure. The only other
error that stands out is in the ifssvc.log file that has some errors
mentioning "ldap_search_s failed with 0x51", "forest functional level
cannot be discovered - choosing webssoap", and "couldn't lsalogonuser:
0xc00000e5.0". These would appear to say that it could query AD, but
the other logs show that it found what appears to be my sid, shows it
making a token etc.

any more tips??

Thanks!


On May 2, 11:22 am, "Joe Kaplan"
<joseph.e.kap...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
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 theADFStoken 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 tellADFSto 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/DiscoveringTheUsersNameAndGroupsInTheirWindo...

Another thing to be aware of is that ifADFSfails to map anADFSuser/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" <nboo...@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 gottenADFSimplemented 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!




.

Quantcast