SharePoint 2010 - Accounts not resolving after setting up Claims Based Authentication?
Greetings all! I hope everyone has had an enjoyable week!
Background:
I upgraded my server farm from SP2007 to SP2010. After the upgrade, I converted the web application that houses all of my site collections from Classic Mode to Claims Based authentication. I then went into the Authentication Providers for this web application and turned on Forms Based Authentication. After that, I modified the web.config file for Central Administration (on server with CA), the Web Application housing my sites (on the Web Front End), and STS (on the Web Front End). I then ran another three line script in Powershell that I found online to bring over our old database of FBA accounts (from a different server farm, our "production" database).
The problem that I've run into, is that AS SOON AS we ran the script to use Claims authentication on the web application, whenever we added user accounts to a group (for instance, the Change Site Collection Administrators link in Central Admin > Application Management), it added some odd characters in front of the account name.
Here is what I ran to enable CBA on the Web App:
$w = Get-SPWebApplication "https://SPPortal.com/"
$w.UseClaimsAuthentication
$w.Update()
$w.ProvisionGlobally()
Now, after running that set of commands in a PowerShell script, all of my accounts that we added to the sites had these characters tacked in front of them:
Is the "i:0#.w|" a side effect of enabling CBA?
After running the above script, I modified the three web.config files, and then saw that FBA was working (it would ask to log in with Windows Authentication or Forms Authentication). So then, I ran the following script to migrate my old FBA accounts into this setup of FBA:
Now, since the accounts had that funny lettering in front of them, I figured that I needed to remove and then add all my user accounts back to their respective sites again, because "domain\SPAdmin" (my admin account) could not edit a page, yet when I removed him and typed in "i:0#.w|domain\SPAdmin" through Powershell to add it as the Owner of a site collection, it worked fine and I had all the permissions that I needed.
However, when i came in this morning to start my work day, I noticed that on every site that had people on it, I get this error on the text box that you type in user accounts with (near the People Picker and the checkbox that resolves account names (ie - "domain\spadmin" turns into "Share Point Admin":
This page contains one or more errors. Fix the following before continuing:
•No exact match was found. Click the item(s) that did not resolve for more options.
So, even when I click the little "Browse" icon to open the People Picker (the little phonebook next to the textbox), and search for an account (which comes up, so it finds it), and then add it and click "OK"...if I go back into the group to add someone, it lists the little error above about not finding a match for the site.
I have only seen this when trying to add an account to the Site Collection Administrators group through Central Administration, but I'm going to assume that it's everywhere else. And without this account in there, I cannot manage my site collections.
I can click the name itself, and select what it resolves to, or choose "more names", but either way the same thing always happens.
Can anyone help?
Background:
I upgraded my server farm from SP2007 to SP2010. After the upgrade, I converted the web application that houses all of my site collections from Classic Mode to Claims Based authentication. I then went into the Authentication Providers for this web application and turned on Forms Based Authentication. After that, I modified the web.config file for Central Administration (on server with CA), the Web Application housing my sites (on the Web Front End), and STS (on the Web Front End). I then ran another three line script in Powershell that I found online to bring over our old database of FBA accounts (from a different server farm, our "production" database).
The problem that I've run into, is that AS SOON AS we ran the script to use Claims authentication on the web application, whenever we added user accounts to a group (for instance, the Change Site Collection Administrators link in Central Admin > Application Management), it added some odd characters in front of the account name.
Here is what I ran to enable CBA on the Web App:
$w = Get-SPWebApplication "https://SPPortal.com/"
$w.UseClaimsAuthentication
$w.Update()
$w.ProvisionGlobally()
Now, after running that set of commands in a PowerShell script, all of my accounts that we added to the sites had these characters tacked in front of them:
[i]i:0#.w|domain\SpAdmin ; [/i]
Is the "i:0#.w|" a side effect of enabling CBA?
After running the above script, I modified the three web.config files, and then saw that FBA was working (it would ask to log in with Windows Authentication or Forms Authentication). So then, I ran the following script to migrate my old FBA accounts into this setup of FBA:
$w = Get-SPWebApplication "https://SPPortal.com/"
$w.MigrateUsers(1)
$w.MigrateUsers(1)
Now, since the accounts had that funny lettering in front of them, I figured that I needed to remove and then add all my user accounts back to their respective sites again, because "domain\SPAdmin" (my admin account) could not edit a page, yet when I removed him and typed in "i:0#.w|domain\SPAdmin" through Powershell to add it as the Owner of a site collection, it worked fine and I had all the permissions that I needed.
However, when i came in this morning to start my work day, I noticed that on every site that had people on it, I get this error on the text box that you type in user accounts with (near the People Picker and the checkbox that resolves account names (ie - "domain\spadmin" turns into "Share Point Admin":
This page contains one or more errors. Fix the following before continuing:
•No exact match was found. Click the item(s) that did not resolve for more options.
So, even when I click the little "Browse" icon to open the People Picker (the little phonebook next to the textbox), and search for an account (which comes up, so it finds it), and then add it and click "OK"...if I go back into the group to add someone, it lists the little error above about not finding a match for the site.
I have only seen this when trying to add an account to the Site Collection Administrators group through Central Administration, but I'm going to assume that it's everywhere else. And without this account in there, I cannot manage my site collections.
I can click the name itself, and select what it resolves to, or choose "more names", but either way the same thing always happens.
Can anyone help?
ASKER
SharePointGuru,
Oddly enough, the day after I posted this, the problems went away.
There are three other people who have access to the server itself...one of which is a web administrator for many different web technologies (knows a little about SharePoint, but doesn't work on it often enough to do too much), and the other two are developers (who don't know much about server administration). It's my line of thinking that "someone" did "something", but I have no proof, and when asked they say that they didn't do anything. Oh well...maybe they didn't do anything? Out of the four of us, I've got the most knowledge on SharePoint, although I am far from a good admin :p I learn something new every day, though!
Details:
We had two environments for SharePoint prior to the upgrade. One was our production environment, running MOSS 2007 on Server 2003, which had FBA set up. The database for the user security was on another server that had other databases which were used for user authentication for other systems.
The development environment was MOSS 2007 on Server 2008. This did not have FBA set up. We have a list of Site Collection Administrators that we add to each site (mainly, our developers and the team that I work on). The membership for each site collection and sub webs within each collection vary, but in most cases the sub webs inherit permissions from the top level site (there are a rare few that use Unique permissions, though).
When we did the upgrade to SP 2010 on our development server, we had issues during the upgrade, which I had (mostly) taken care of. Then we edited the web.config files, ran the above PS scripts, and set up FBA.
We are using FBA because we have people that access the server from outside the network, and thus are unable to authenticate through normal means. I don't know much about FBA and CBA, other than what I've read online, but it seems to me that even though our web application is converted to use CBA, it seems like it's still FBA.
We don't pull user information from anywhere other than Active Directory and our FBA membership database...and when adding permissions to the sites, I still have to add both the FBA account and the AD account...and I thought that CBA was supposed to "merge" these into one identity.
The names are not restricted per site collection. So domain\john.doe on SC1 is the same account as on SC2.
Any ideas why that would happen?
Oddly enough, the day after I posted this, the problems went away.
There are three other people who have access to the server itself...one of which is a web administrator for many different web technologies (knows a little about SharePoint, but doesn't work on it often enough to do too much), and the other two are developers (who don't know much about server administration). It's my line of thinking that "someone" did "something", but I have no proof, and when asked they say that they didn't do anything. Oh well...maybe they didn't do anything? Out of the four of us, I've got the most knowledge on SharePoint, although I am far from a good admin :p I learn something new every day, though!
Details:
We had two environments for SharePoint prior to the upgrade. One was our production environment, running MOSS 2007 on Server 2003, which had FBA set up. The database for the user security was on another server that had other databases which were used for user authentication for other systems.
The development environment was MOSS 2007 on Server 2008. This did not have FBA set up. We have a list of Site Collection Administrators that we add to each site (mainly, our developers and the team that I work on). The membership for each site collection and sub webs within each collection vary, but in most cases the sub webs inherit permissions from the top level site (there are a rare few that use Unique permissions, though).
When we did the upgrade to SP 2010 on our development server, we had issues during the upgrade, which I had (mostly) taken care of. Then we edited the web.config files, ran the above PS scripts, and set up FBA.
We are using FBA because we have people that access the server from outside the network, and thus are unable to authenticate through normal means. I don't know much about FBA and CBA, other than what I've read online, but it seems to me that even though our web application is converted to use CBA, it seems like it's still FBA.
We don't pull user information from anywhere other than Active Directory and our FBA membership database...and when adding permissions to the sites, I still have to add both the FBA account and the AD account...and I thought that CBA was supposed to "merge" these into one identity.
The names are not restricted per site collection. So domain\john.doe on SC1 is the same account as on SC2.
Any ideas why that would happen?
Well Claims Based Authentication doesn't merge AD accounts and FBA accounts. Actually it works with both. Claims is an alternative authentication model not a membership provider such as AD or SQL db users. From what it sounds like you don't have something configured correctly for either AD or FBA (most likely FBA)
Do you know for a fact that you are browsing SQL db users as opposed to AD users?
Do you know for a fact that you are browsing SQL db users as opposed to AD users?
ASKER
I believe we are.
Because on the login page, it asks if we want to use windows authentication of forms authentication.
If i go to a site that has domain\thatsharepointguy on it, and doesn't have fbausers:thatsharepointguy
Because on the login page, it asks if we want to use windows authentication of forms authentication.
If i go to a site that has domain\thatsharepointguy on it, and doesn't have fbausers:thatsharepointguy
and when you get the access denied can you confirm that the FBAusers: account actually has permission and not the AD user.
ASKER
Confirmed.
I went into the site collection with our administrative account, and removed both of my accounts. I then used the People Picker to search the FBA accounts for mine, and added it to the Members group for the site I was in (Contribute). I then signed out, signed back in with my FBA account, and got in fine.
I then signed out, and tried signing in with Windows Authentication, and it failed (since my domain account wasn't in any groups on the site).
I removed the FBA account, added my domain account, and signed in with Windows Authentication, and was allowed access.
I then tried signing in with the FBA account (when only the domain account was listed on the site), and was denied.
As I mentioned above, we haven't had the exact error that I posted about for a few days now. It's just strange that it would do that, and I'm still looking through logs to try to find anything, from the timeframe during which it happened.
I went into the site collection with our administrative account, and removed both of my accounts. I then used the People Picker to search the FBA accounts for mine, and added it to the Members group for the site I was in (Contribute). I then signed out, signed back in with my FBA account, and got in fine.
I then signed out, and tried signing in with Windows Authentication, and it failed (since my domain account wasn't in any groups on the site).
I removed the FBA account, added my domain account, and signed in with Windows Authentication, and was allowed access.
I then tried signing in with the FBA account (when only the domain account was listed on the site), and was denied.
As I mentioned above, we haven't had the exact error that I posted about for a few days now. It's just strange that it would do that, and I'm still looking through logs to try to find anything, from the timeframe during which it happened.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I wanted to offer my apologies to both SharePointGuru14 and to Chris-Dent. I've been unable to get online in a reasonable amount of time recently and have not been able to update this question. I'm going to go ahead and accept SPG14's answer, as that is most likely the cause. I have found no other reason for the accounts to act the way they did, and it has not happened since.
My sincere apologies for not getting back to this sooner!
My sincere apologies for not getting back to this sooner!
ASKER
Most probable answer. There has been no trace of what happened in the logs, and we have not seen any similar problems rear their ugly heads in the time since this happened.
Do you only have the name resolution adding problem when adding users from central admin? Does it work on the sites themselves? This is a common problem when using FBA if you have certain users for certain site collections. Can you give us more detail on your environment before the upgrade. Why are you using FBA?, how was that setup? Are you restricting accounts to the site collection so that you can have the same name for different users of different site collections? This is common in hosting scenarios.