Claim Provider Error

Question

I have an error with MySite as it seems it can not recognise usernames, I try to resolve a username and it comes up with "An error has occured in the claim providers configured for this site collection". I have had a good look an I can not find what this might be. Can anyone assist?

Answer 1

1) Is CBA working already for your regular content site?

2) Is your farm setup so that your MySite web app is separate from your content web app, or are they in the same web app?

3) What method are you using?  FBA, Windows Integration Authentication, or something else?

In my farm that is using Windows Integrated Auth for external users to connect, I have the MySite web app separate from the content web app, and because of this, my external users cannot browse to MySites - they don't have a way to authenticate.  In my next iteration, I will make sure the MySite web app is also claims aware.

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 2

1) I am not sure.

2) they are both on the same web app

3) Windows Intergrated

Answer 3

You don't know if it's working at all yet?  I would be more worried about it working in general than worrying about it working with MySites.  You haven't authenticated once through CBA yet?

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 4

What can I say I dont exactly know what claim based authentication is. I am able to log into my home page using our domain accounts and am able to find other users on that.

Answer 5

CBA is very complicated and takes a lot of work.  Have you set it up at all?  Do you have ADFS 2.0 running on your STS server?  Or have you not attempted to set up claims at all and just got an error with the wrods "claim providers" in it?  Sorry, because of your thread title, I thought you were working on CBA.

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 6

Thank you for your help but the answer to all your above questions is I dont know. I am not very knowledgeble with sharepoint and I have done an install to try and get to grips with it all.

This error is not stopping me from being able to continue so ill investigate it more at a later date.

Again thank you.

Answer 7

When you created the web application, did you do it manually, or did you let the Wizard do it?  Go to Application Management > Manage Web Applications > Single-Click on your content web application > Click Authentication Providers in the ribbon.  Is the Claims identity provider box checked?

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 8

Clicking authentication providers opens a window with

Zone      Membership Provider Name
Default   Windows

It was all created with the wizard

Answer 9

You have to click Default - it should be hyperlinked.  After you click that, does it say it's a Claims Mode web app or Classic Mode?  Then, scroll down and check your identity providers.

Are you able to resolve users in the main site?

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 10

It says neither it does not mention Claims at all just Windows as authentication type

Answer 11

I am having the same issue. Has anyone found a resolution?

Answer 12

I am having the same issue. Has anyone found a resolution?

It's hard to find a resolution, because we don't actually know what the problem is.  There should be no message like this unless you are trying to incorporate Claims-Based Authentication (CBA).  I haven't gotten an error like this in any of my farm builds, and that includes my CBA farm, which is operational.

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 13

Do not have claims based set up on my site so the I can't say why it is giving errors on claims. It is only doing it for the MySite area which is ont eh same web application as the main content which is working fine.

Answer 14

Do not have claims based set up on my site so the I can't say why it is giving errors on claims. It is only doing it for the MySite area which is ont eh same web application as the main content which is working fine.

Yeah, and the strange thing about that is authentication methods are only scoped to the web app level, so site collections in the same web app all use the same authentication methods.

One thing I don't think I asked was...where are you trying to resolve usernames in your My Site?  Do MySites auto-create for the current user when you go to My Content?  Does all of that work fine, but then you are trying to resolve a username in a People Picker within a list or library on your own MySite?

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 15

If I go into User Profile Server Application > Setup My Sites The read permission label is in an error state with the red jagged lines. You click on browse and this is were it says "An error has occurred in the claim providers configured from this site collection." So you are not able t pick users, the same accross Configre Personal Site, the user browse has the same error.

Answer 16

If I go into User Profile Server Application > Setup My Sites The read permission label is in an error state with the red jagged lines. You click on browse and this is were it says "An error has occurred in the claim providers configured from this site collection." So you are not able t pick users, the same accross Configre Personal Site, the user browse has the same error.

Ohhhh, jeez, no wonder - you never gave that info.  This is a much different problem area than what I thought you were saying the whole time.  I thought you were in your My Site trying to resolve a user, not that you were having back-end issues within the service application settings..

I would start by deleting the UPS and then running the Configuration Wizard again to automatically provision it.

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 17

Unfortunatly deleting and recreating did not solve the problem.

Answer 18

What happens when you browse to My Profile and then My Content?

What uses do you see in the Read Permissions box that has the red italics?  Is it All Authenticated Users?

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 19

Authenticated users ; c:0(,s|true ;

 

That is what is displayed

Answer 20

Yeah, I can't think of how this particular box would not be able to connect with your identity provider but yet the rest of the web application can (and entire farm, I presume).  There should be some info either in the SharePoint server's Application log (Event Viewer) or in the 14\Logs (most recent file).

---

SharePoint Architect || Microsoft MVP || My Blog

Answer 21

Would Migration be an Issue? I used the Dettached/Attach db method, on MOSS 2007 My sites were on a seperate WebAppPool (port 90) and I am getting the same as Alex ( NT AUTHORITY\Authenticated Users; c:0(,s|true ; ) - Internal Domain, User sync and Domain sync are working , Have not used or setup CBA just Windows Intergrated (no FBA either)

 

EDIT: okay a little more digging revealed ( for referance see this post: http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/ed773249-8589-4829-aba3-6a113ab0c394 the LAB setup was used by suggestion of Microsoft support but considered the case closed once I got a good migration now I'm left with the broken and clean up)

Profile Links and Mysite links are tring to go to our LAB url (http://LAB/my/Person.aspx?) when they should go to the PRODUCTION url (http://PRODUCTION/my) some how I have to mass change those server names either through the db itself or through a cmd line (btw manually changeing the LAB name to the PRODUCTION name returns good resaults) any Ideas?

Answer 22

We did not do a migration just a fresh install. 

To make matters worse I deleted the User Profile Service, had a few errors to fix to get it working again and got synchronization working and this error went away. Unfortunately 24 hours later it is back.

Answer 23

I am seeing the same error when trying to configure the Secure Store. I get to thge Target Application Admins and I type in my user name and it resolves to my full name but with a red line under it. When I open the address Book I get the error "an error has occurred in the claim providers configured from this site collection. Any ideas?

Answer 24

This may be off-base, but when I saw the same issue in RTM 2010 Central Admin, the problem turned out to be that I needed to create an Alternate Access Mapping for the CA website, using the Fully Qualified Domain name.  Once I did that, the claims error issue stopped.  So, trying creating an AAM for your site.

 

 

Answer 25

This may be off-base, but when I saw the same issue in RTM 2010 Central Admin, the problem turned out to be that I needed to create an Alternate Access Mapping for the CA website, using the Fully Qualified Domain name.  Once I did that, the claims error issue stopped.  So, trying creating an AAM for your site.

 

 

Can you elaborate on this?  I am having this same issue.  I have already changed my AAM to point to the fully qualified name.  But I still get this error when trying to modify the "Read Permission Level" in the "My Site Settings".

Did anyone else find a solution?

Answer 26

I just tried something new.  I tried accessing my management site using just the hostname in the url instead of the FQDN.  That fixed it.  Now I need to find out why it doesn't like the FQDN.

Answer 27

Mine too is now working but the opposite of ddod. It likes the fqdn:port for central administration but not the hostname.

It seems this error is very much related to the AAM of central administration. Many thanks

Answer 28

I had the same problem.  I was accessing Central Admin from an address that wasn't in AAM.  Once the address was added, everything worked.

FWIW:  I did not have anything related to Claims Auth configured--pretty much OOTB install on RTM build.

Answer 29

Hey Tom, as a Microsoft person has explained to me "It's all claims under the hood in 2010".  So even though you're using OOTB 2010, even if the web apps are set to NTLM, you're still using claims at a lower level in the code.  That's why you see the "Claims Provider" errors.

It just seems that with Central Admin in 2010, since the web app is created using the non-FQDN of the site, you need to create an AAM for the FQDN to get everything working.

Hope that helps,

 

Answer 30

I had the same error message when I used the FQDN. Worked fine when I used the NetBIOS name of the server to access Central admin. Also the AAM is not setup for the Central admin site. This post was helpful. Thanks all.

Answer 31

This is exactly what was happening for me and I got mine fixed by adding my additional address into AAM. Working for me now as well!

Answer 32

this also helped me! thank you very much! these aam's are confusing because the error messages don't have any indication of whats really going wrong.

Answer 33

Same for me.  Central Admin allowed me to use the FQDN, but I had to use NetBios for the Secure Store setup.

Answer 34

None of these suggestions have proven useful for me.  Even after deleting and recreating the Central Admin site.  Still stuck with the "An error has occurred in the claim providers configured from this site collection" error message when selecting the People picker after provisioning the MMS, UPS Service applications/instances, and a MySites web application.

Answer 35

Hi

I had exactly the same problem - I was trying to setup a new Secure Store Target Application for the first time on a new development server. I followed the advice on the AAM settings. It didn't work at first when I set up the full FQDN and then I realised why. I had added the AAM just for the web site and NOT the Central Admin site. As soon as I selected the Central Admin address from the selection dropdown at the top right of the AAM screen and added this to my Intranet zone, the Claim provider error message disappeared and I could then pick the correct account when setting up the Secure Store.

 

Thanks

Answer 36

Hi

I had exactly the same problem - I was trying to setup a new Secure Store Target Application for the first time on a new development server. I followed the advice on the AAM settings. It didn't work at first when I set up the full FQDN and then I realised why. I had added the AAM just for the web site and NOT the Central Admin site. As soon as I selected the Central Admin address from the selection dropdown at the top right of the AAM screen and added this to my Intranet zone, the Claim provider error message disappeared and I could then pick the correct account when setting up the Secure Store.

 

Thanks

Alternate Access Mappings in Central Admin fixed the issue for me as well.

Cheers

Answer 37

Our error was the CA site was not using a FQDN, fixed that and re-ran the timer jobs for the UPS and reset IIS (just in case) and all works now.

Answer 38

Works like a charm. I was actually trying to manage service applications from my desktop connected to my extranet domain. The issue is that i was using http://sharepointserver.exdomain.com:####. I had to add that to AAM since the original url was http://sharepointserver:####. Thanks again.

Answer 39

I had the same issue, but it wasn't with MySite, but with the Managed Metadata Term Store.  I would get the same error when I tried to add any user as a Stakeholder on the term set.

After reading everything here, I noticed that I was accessing my central admin site by going to the FQDN... for example, http://computer.mydomain.tld:12345

Then, I changed the url to just use the hostname, such as: http://computer:12345 and it worked!

That led me to check my Alternate Access Mappings for the central admin site and I realized that it was only set to the computer's name, not the FQDN.

Adding the FQDN as an AAM for the central admin site resolved the issue when accessing using the FQDN.

So, it appears to simply be an issue with how you access the site.  Definitely a bug, but setting up an AAM for the FQDN resolves it!

Answer 40

Same thing for me ... I was using http://10.100.1.150:8080/#####  changed to the bound domain .. e.g. http://intranet.ourcompany.datacenter:8080/###### and it worked!!

Answer 41

Adding a new Alternate access mapping for the Central admin site worked for me also.

Open Central Administration.
Select System Settings.
Under Farm Management, select Alternate Access Mappings (AAM)

Change Alternate Access Mapping Collection to show only the AAM's for Central Admin.
Our OOTB Installation showed only the local Hostname and Port.   Example:

http://MachineName:Port

This works locally of course - but will not work if you are remoting in from outside of that domain (Or geographically in another country!)
So as suggested above - I clicked on Add a new Internal URL and entered a new Fully Qualified Domain Name like this:

http://MachineName.region.companyName.com:Port

(This is our format - Your format may not be the same - just ensure you can ping the FQDN you enter.)
I assigned this to the Intranet zone. 
Working immediately and no more claim providor messages!

Answer 42

I don't know if this is still relevant - I had a problem adding names to the Managed Metadata Service application. Using the Term Store Management tool for this service. Every time I added names to the Term Store administrators or clicked browse and tried to add names i received the same error. I added the new URL that i binded to the Central Admin site to AAM and it resolved the issue.

Answer 43

Thanks ddod :)

Answer 44

Wonderful, worked like a charm.

---

Munna

Answer 45

I have run into this and resolved it by logging onto the system hosting Central admin, not an explorer window from my system.