Directory Programming .NET

I'm having some basic problems with the PeoplePicker that is causing me some headache.  I have two sets of environments:

1. Environment 1
1. Win2k3 ADFS Resource Server (with AD account store setup)
2. Winsk3 ADFS Account Server
3. Win2k8 WSS Server A
2. Environment 2
1. Win2k8 ADFS Resource Server
2. Win2k8 ADFS Account Server
3. Win2k3 ADFS Account Server (same as 1.2 above)
4. Win2k8 WSS Server B

Within environment 1, I'm able to get the PeoplePicker to resolve users from both the ADFS RS account store and the ADFS AS.  Like many people have noted on these boards, I can actually type any email address into the PeoplePicker and it will be accepted.

Within environment 2, I'm able to get the PeoplePicker to resolve users from ONLY the ADFS AS 2.2.  It will not resolve users in the other ADFS AS (2.3).  In fact, in this particular case it only resolves users from the 2.2 account server.  Any ideas?

I did make sure that the 2.3 account server is enabled in the resource server and that the UPN suffix is correct.  Has anyone else seen this?

Unfortunately I don't know the exact answer on this.  Let me see if I can get Laura Hunter to answer here or provide me a clue as I know she spent a lot of time dinking around with this in her lab preparation to get it to work.

(As Laura suddenly realizes she'd never actually registered on this forum before now...)

As I'm understanding you, the People Picker is able to resolve claims from the 2K8 FS, but -not- from the 2K3 FS? I've historically encountered the opposite problem, which arose from needing to enable that "Allow anonymous access to claims" check-box that was added in 2008 on the Federation Service node Properties sheet. (Pretty sure it's on the Advanced tab from there, but poke around for it as I don't have a box immediately in front of me to verify the UI.)

You were right on target in terms of the GUI property sheets.  Unfortunately, this didn't do the trick for me.

To clarify the server setup:

1. 2k8 WSS 3.0
2. 2k8 AS
3. 2k3 AS
4. 2k8 RS

In this setup, the People Picker is able to resolve users from the 2k8 AS but not from the 2k3 AS.  I verified that the domain suffix I'm supplying in the People Picker is correct and that the RS is configured to allow those suffixes from that AS.

I wonder if there is something wrong with the way I did the "export policy file" on the 2k3 server AS and then the "import policy file" on the win2k8 RS.

I should note that I do have another setup where all the federation servers are win2k3 and the WSS box is win2k8 and in that environment the People Picker works correctly.

Hmmm...you might be having an "order matters" problem, depending on how one box was set up versus the other. I've found that if I get ahead of myself and extend the MOSS site on a box -before- installing the claims agent, People Picker no workie even though it looks like it should. Try removing Sharepoint from the site in question (from within Sharepoint Central Admin) and then re-adding it.

Finally got around to trying your suggestion...

I actually removed the entire sp web application containing both sites (intranet and extranet) and started over.  Unfortunately, I'm still hitting the same goofy problem.

I did try another experiment.  If you remember, I had to environments and one of them works but not the other.  I changed the FS info in the web.config for the environment that works to point to the FS for the environment that does not work.  Doing some testing, it turns out that pointing to that FS causes the other environment's people picker to fail as well.  To me, that sounds like the problem is in the FS, not SP.  That is good news, because SP is a beast.

I'm going to poke around with FS to see what I can find.  I'm considering deleting the trust relationship and re-establishing it.  Any other ideas??

Thanks again!

I think it is much more likely to be an issue with claims configuration either in the extraction or the mapping between partners and less having to do with the trust itself which is largely just a matter of the certificate and identifiers.  Unfortunately, I don't know quite what to look for with the claims.

You might consider examining the trustpolicy.xml file for the fed servers involved at the XML level to see if you see anything that looks like a key difference.  Sometimes the GUI hides the important thing you need to look at.

I started to look at the trust policy and realized that I deployed SSO sample page that MS provided in their ADFS setup guide.  So, I decided I would give that a try using one of the users in the federated domain.  As it turns out, that works perfectly fine.  Also, I tried logging into WSS using an account from the federated domain and proved that the login was successful, it was just the authorization that failed (WSS access denied page appeared).

So, I think this tells me that the trust policies are perfectly fine.  It makes no sense to me though why the stupid people picker still won't let me add a user from the federated domain to the sites groups.

Sigh... any other suggestions?  Did I misunderstand the reasoning of checking the policy files?

The reason for checking the trust policies at the XML level was to see if you could perhaps see anything in terms of how any of the claims or the partner config might have been set up differently.  The XML in those files is a little overwhelming but sometimes you can pick things up by comparing at the text level.

The SharePoint picker is built on top of the ASP.NET membership provider framework and uses a feature in the ADFS membership provider to "work", but that stuff actually doesn't have anything to do with the WS-Federation protocol or the ADFS trust or basically anything else that is part of the standard.  As far as I know, there is no documentation anywhere discussing how this thing works, what it is supposed to actually do or how to troubleshoot it.  As such, I'm just guessing at this point.

FINALLY!!!!!!

As it turns out, a post on the MS ADFS blog shed some light on the subject.  Specifically, the PeoplePicker (PP) will use the email claim, not the UPN claim, to resolve users.  The post goes over the 3 conditions that need to be met in order for an item to be resolved successfully.  My solution was to enable the email claim from all the partners and things started to work.

Is there any direction in terms of what types of identity claims should and shouldn't be enabled and how those claims get mapped into SharePoint??  I'll spin off another thread on this topic.

Thanks everyone for their suggestions... I definitely learned a few things by digging into new areas!!

Hi All,

i´m facing the same problem but with Sharepoint Server.

Where can i find "Allow anonymous access to claims" check-box that was added in 2008 on the Federation Service node Properties" on W2k8???