Re: ADFS - Not Authorized To View Message

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Another observation...

If I put all the pieces in the same network it all works perfect.
Once I separate them out it stops. 443 is the only traffic between
networks right?

Config not working:

Network A has DC and Federarion Server
Netowrk B has Client, Federation Proxy, and Web Server

Config working:

Network A has all 5 pieces.


On May 4, 9:12 am, nboothe <nboo...@xxxxxxxxx> wrote:
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
theadfsproxy and it just sits there for a very long time.

The event logs say that an anonymous cookie is being used and theadfs
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!


.

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
    ... It sounds like you are trying to build an NT token-integrated app instead of ... 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 ...
    (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: iPaq 3870 3 times faster than HP2210 ???
    ... If you need to examine the file contents one byte at a time then memory ... mapping it is quite an efficient and easy way to do this. ... > my normal exit window and then exit program buttons still work OK ... I didn't notice any speed difference in my app but the ...
    (microsoft.public.pocketpc.developer)
  • Re: patched server still serves HTWs
    ... Also check that particular instance's app ... Michael C. Gates ... > I have patched the server to the hilt, and run IIS Lockdown Tool on it. ... I have removed the HTW App mapping at ...
    (microsoft.public.inetserver.iis.security)