User Profile Service Sharepoint 2010 problem

HumblePie

Lifer
Oct 30, 2000
14,665
440
126
So I'm trying to setup User Profile Service Synchronization on my site using Active Directory. Right now I have a site set up for claims forms base authentication. If I use the connection string that accesses the System.Web.Security.ActiveDirectoryMembershipProvider DLL in the web config then it works. If I use the other DLL which is Microsoft.Office.Server.Security.LdapMembershipProvider as a connection string recommended off MSDN then the forms based authentication setup doesn't work. Or at least I can't figured out what the hell is wrong exactly with it. I'll post what those connection strings I'm trying in a moment are.

Anyhow, I have User Profile Service running with an account that has AD permissions to replicate changes. I go to setup a new connection for User Profile Service Synchronization to sync through the FBA connection I have set through the web config. From the drop down box on the setup new connection screen, I chance the Authentication Provider Type from Windows Authentication to Trusted Claims Provider Authentication.

When I do the drop down for the Authentication Provider Instance is changed to No Trusted Providers were found!

If I attempt to change the Authentication Provider Type to Forms Based Authentication then I get a Sharepoint Error page with nothing useful on it.

Here is the web.config code for the two forms based connection strings. The first one is the one that works.

Code:
<membership defaultProvider="i">
      <providers>
        <clear />
            <add name="admembers" 
			type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
			connectionStringName="adconn" 
			connectionUsername="Domain\spadm" 
			connectionPassword="xxxxxx" 
			enableSearchMethods="true" 
			attributeMapUsername="sAMAccountName" />

            <add name="i" 
			type= "Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      </providers>
</membership>

<connectionStrings>
    <add name="adconn" connectionString="LDAP://DOMAIN.COM/DC=DOMAIN,DC=COM" />
</connectionStrings>

That one works when I have it in the web config. In central admin for the website application I make sure to set the forms based authentication to use "admembers" for the ASP.NET Membership provider name in the authentication providers of the site.

This is the one off MSDN that I can not get to work though.
Code:
<membership defaultProvider="i">
      <providers>
        <clear />
            <add name="LDAPmembership" 
			type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
			server="DOMAIN.COM" 
			port="389" 
			useSSL="false" 
			useDNAttribute="false" 
			userDNAttribute="distinguishedName" 
			userNameAttribute="sAMAccountName" 
			userContainer="OU=Users,DC=DOMAIN,DC=COM" 
			userObjectClass="person" 
			userFilter="(&amp;(ObjectClass=*))"
			scope="Subtree" 
			otherRequiredUserAttributes="sn,givenName,cn" />

            <add name="i" 
			type= "Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      </providers>
</membership>

That one doesn't work. Not sure why but it doesn't. There are examples all over the net showing both ways. I've followed them all as best I can, but can't get the second way to work when I set it up as the connection for my forms based authentication to my active directory server.

Either way, it doesn't matter because the User Profile Service Synchronization won't recognize a Forms Based Authentication connection at all. I can setup a Windows Authentication connection for synchronization no problem. Just not the Forms Based Authentication connection.

Literally at my wit's end in trying to figure this out.
 

IndyColtsFan

Lifer
Sep 22, 2007
33,655
687
126
This is just a shot in the dark, but have you modified the web.config of the Security Token Service with your connection info? If you go here it will explain the process. Yes, the instructions are for a specific product but I think the steps are general enough to follow.
 

HumblePie

Lifer
Oct 30, 2000
14,665
440
126
This is just a shot in the dark, but have you modified the web.config of the Security Token Service with your connection info? If you go here it will explain the process. Yes, the instructions are for a specific product but I think the steps are general enough to follow.

I've modified it for all 3 web configs. I followed the instructions of many sites from MSDN, to Harbar, to tons of others. I can get the FBA connection to work for ay site but only if I use the DLL with the connection string in the first set of code. I can not get the second DLL connection to work at all. I can not get User Profile Service Synchronization to recognize that I have another trusted source. Which is my FBA connection on my site. It's bugging me to no end.
 

HumblePie

Lifer
Oct 30, 2000
14,665
440
126
Here is what I've done...


I used this site to get the User Profile Service running. The previous User Profile Service was not running right and was bugged some how. So I deleted it and started a new one. So I provisioned the new User Profile Service on central admin with the farm account used to setup the farm. I made sure the farm account also had local admin rights to the machine that Sharepoint was loaded on. I then remove the local admin rights after creating the service. I associated the service with a register account that has read access to the active directory. I then created a new connection string, using windows authentication, using an account that has both read permissions and replication permissions in active directory. This is not a register account per the buggy rules outlined in the site I used.

http://www.harbar.net/articles/sp2010ups.aspx

I basically followed those steps outlined on that site. I started the created the User Profile Service, started it, created a new sync connection, and let it run. It works perfectly fine if the connection I have setup is a windows authentication connection. I can verify the success of the connection using the MIISclient.exe for the forefront identity manager service that is also started and works with the User Profile Service.

The problem is trying to create a connection for synchronization for accounts using a forms based authentication connection and not the windows authentication.

I have a forms based authentication membership setup in the web.config of the central admin, the sharepoint site I set up, and the STS service. It's setup per the instructions I found off this website.

http://blogs.msdn.com/b/sridhara/ar...ith-active-directory-membership-provider.aspx

There were several others, but the instructions for the others didn't work as they used the second DLL I listed in the OP.


I also tried following these instructions for setting up FBA for my web app site.

http://technet.microsoft.com/en-us/library/ee806890(office.14).aspx

that's from technet. I'll tell you something, if you follow those instructions exactly you'll blow up central admin. Mainly because it has a role provider for the web.config under central admin that isn't actually provided in the xml. So when you set the default provider using the code that you cut and paste from that link above, it will not work at all.
 
Last edited:

IndyColtsFan

Lifer
Sep 22, 2007
33,655
687
126
Here is what I've done...


I used this site to get the User Profile Service running. The previous User Profile Service was not running right and was bugged some how. So I deleted it and started a new one. So I provisioned the new User Profile Service on central admin with the farm account used to setup the farm. I made sure the farm account also had local admin rights to the machine that Sharepoint was loaded on. I then remove the local admin rights after creating the service. I associated the service with a register account that has read access to the active directory. I then created a new connection string, using windows authentication, using an account that has both read permissions and replication permissions in active directory. This is not a register account per the buggy rules outlined in the site I used.

http://www.harbar.net/articles/sp2010ups.aspx

I basically followed those steps outlined on that site. I started the created the User Profile Service, started it, created a new sync connection, and let it run. It works perfectly fine if the connection I have setup is a windows authentication connection. I can verify the success of the connection using the MIISclient.exe for the forefront identity manager service that is also started and works with the User Profile Service.

The problem is trying to create a connection for synchronization for accounts using a forms based authentication connection and not the windows authentication.

I have a forms based authentication membership setup in the web.config of the central admin, the sharepoint site I set up, and the STS service. It's setup per the instructions I found off this website.

http://blogs.msdn.com/b/sridhara/ar...ith-active-directory-membership-provider.aspx

There were several others, but the instructions for the others didn't work as they used the second DLL I listed in the OP.


I also tried following these instructions for setting up FBA for my web app site.

http://technet.microsoft.com/en-us/library/ee806890%28office.14%29.aspx

that's from technet. I'll tell you something, if you follow those instructions exactly you'll blow up central admin. Mainly because it has a role provider for the web.config under central admin that isn't actually provided in the xml. So when you set the default provider using the code that you cut and paste from that link above, it will not work at all.

Sorry, I may have missed this, but are you able to see any of the FBA user accounts when you try to add users to the site permissions? Also, are you using SSL for any of this site?
 
Last edited:

HumblePie

Lifer
Oct 30, 2000
14,665
440
126
Sorry, I may have missed this, but are you able to see any of the FBA user accounts when you try to add users to the site permissions? Also, are you using SSL for any of this site?

No SSL. Yes I can see FBA members. However they show up as Organization and not Forms Authentication when using the People Picker.

I have managed to get the second DLL working right from the OP. Which is the LdapMembershipProvider DLL that wasn't working before and comes straight from technet. There was a couple of bugs and things left off with the technet such as unbalanced parens and lack of a username and password account info to be passed.

So here is my current setup for the web.config files.

This is PeoplePicker portion of both the Web App and the Central Admin
Code:
<PeoplePickerWildcards>
      <clear />
      <add key="AspNetSqlMembershipProvider" value="%" />
      <add key="admembers" value="*" />
      <add key="LdapMember" value="*" />
      <add key="LdapRole" value="*" />
</PeoplePickerWildcards>

This is the membership, rolemanager, and connection string portion of the Web App. I left in both forms connection types for the active directory because I can easily swap between them now.
Code:
    <membership defaultProvider="i">
      <providers>
        <clear />
        <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

        <add name="admembers" 
			type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
			connectionStringName="adconn" 
			enableSearchMethods="true" 
			attributeMapUsername="sAMAccountName" 
			connectionUsername="Domain\admin" 
			connectionPassword="xxxxxxx" />

        <add name="LdapMember" 
			type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
			server="domain.com" 
			port="389" 
			useSSL="false" 
			userDNAttribute="distinguishedName" 
			userNameAttribute="sAMAccountName" 
			userContainer="DC=domain,DC=com" 
			userObjectClass="person" 
			userFilter="(ObjectClass=*)" 
			scope="Subtree" 
			otherRequiredUserAttributes="sn,givenname,cn,mail" 
			connectionUsername="domain\admin" 
			connectionPassword="xxxxxxx" />
      </providers>
    </membership>

    <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
      <providers>
        <clear />
        <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

        <add name="LdapRole" 
			type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
			server="domain.com" 
			port="389"
			useSSL="false"
			groupContainer="DC=domain,DC=com" 
			groupNameAttribute="cn" 
			groupMemberAttribute="member" 
			userNameAttribute="sAMAccountName"
			groupNameAlternateSearchAttribute="sAMAccountName"
			dnAttribute="distinguishedName"
			useUserDNAttribute="false"
			groupFilter="(&amp;(ObjectClass=group))"
			userFilter="(&amp;(ObjectClass=person))"
			scope="Subtree" />
      </providers>
    </roleManager>
  </system.web>

  <connectionStrings>
    <add name="adconn" connectionString="LDAP://DOMAIN.COM/DC=DOMAIN,DC=COM" />
  </connectionStrings>

Here is the Central admin web config file for the same areas as the Web app
Code:
    <membership defaultProvider="i">
      <providers>
		<clear />
		<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

        <add name="admembers" 
			type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
			connectionStringName="adconn" 
			enableSearchMethods="true" 
			attributeMapUsername="sAMAccountName" 
			connectionUsername="domain\admin" 
			connectionPassword="xxxxxxx" />

        <add name="LdapMember" 
			type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
			server="domain.com" 
			port="389" 
			useSSL="false" 
			userDNAttribute="distinguishedName" 
			userNameAttribute="sAMAccountName" 
			userContainer="DC=domain,DC=com" 
			userObjectClass="person" 
			userFilter="(ObjectClass=*)" 
			scope="Subtree" 
			otherRequiredUserAttributes="sn,givenname,cn,mail" 
			connectionUsername="domain\admin" 
			connectionPassword="xxxxxxx" />
      </providers>
    </membership>

	<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" cacheRolesInCookie="false">
      <providers>
		<clear />
		<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

		<add name="LdapRole" 
			type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
			server="domain.com" 
			port="389"
			useSSL="false"
			groupContainer="DC=domain,DC=com" 
			groupNameAttribute="cn" 
			groupMemberAttribute="member" 
			userNameAttribute="sAMAccountName"
			groupNameAlternateSearchAttribute="sAMAccountName"
			dnAttribute="distinguishedName" 
			useUserDNAttribute="false"
			groupFilter="(&amp;(ObjectClass=groupOfNames))"
			userFilter="(&amp;(ObjectClass=person))"
			scope="Subtree" />

		<add connectionStringName="AspNetSqlMembershipProvider" 
			applicationName="/" 
			name="SqlRole" 
			type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

		<add applicationName="/" 
			name="AspNetWindowsTokenRoleProvider" 
			type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </roleManager>
  </system.web>

  <connectionStrings>
    <add name="adconn" connectionString="LDAP://DOMAIN.COM/DC=DOMAIN,DC=COM" />
	<add name="AspNetSqlMembershipProvider" connectionString="data source=127.0.0.1;Integrated Security=SSPI;Initial Catalog=aspnetdb" providerName="" />
  </connectionStrings>

And here is the same sections for the STS web config file.
Code:
  <system.web>
    <membership> 
      <providers>
		<clear />
		<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

        <add name="admembers" 
			type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
			connectionStringName="adconn" 
			enableSearchMethods="true" 
			attributeMapUsername="sAMAccountName" 
			connectionUsername="domain\admin" 
			connectionPassword="xxxxxxxx" />
        <add name="LdapMember" 
			type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
			server="domain.com" 
			port="389" 
			useSSL="false" 
			userDNAttribute="distinguishedName" 
			userNameAttribute="sAMAccountName" 
			userContainer="DC=domain,DC=com" 
			userObjectClass="person" 
			userFilter="(ObjectClass=*)" 
			scope="Subtree" 
			otherRequiredUserAttributes="sn,givenname,cn,mail" 
			connectionUsername="domain\admin" 
			connectionPassword="xxxxxxx" />
      </providers>
    </membership>

    <roleManager enabled="true">
      <providers>
        <clear />
		<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

        <add name="LdapRole" 
			type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
			server="domain.com" 
			port="389"
			useSSL="false"
			groupContainer="DC=domain,DC=com" 
			groupNameAttribute="cn" 
			groupMemberAttribute="member" 
			userNameAttribute="sAMAccountName"
			groupNameAlternateSearchAttribute="sAMAccountName"
			dnAttribute="distinguishedName"
			useUserDNAttribute="false"			
			groupFilter="(&amp;(ObjectClass=groupOfNames))"
			userFilter="(&amp;(ObjectClass=person))"
			scope="Subtree" />

		<add connectionStringName="AspNetSqlMembershipProvider" 
			applicationName="/" 
			name="SqlRole" 
			type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

		<add applicationName="/" 
			name="AspNetWindowsTokenRoleProvider" 
			type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
	</roleManager>
  </system.web>
  <connectionStrings>
	<add name="adconn" connectionString="LDAP://DOMAIN.COM/DC=DOMAIN,DC=COM" />
  </connectionStrings>


Some of what I've learned through some experimentation. In the Central Admin config file, if I set the rolemanager section to a default provider like the C which is what is provided with the Web App, then it gives me a complete HTML 500 error even trying to open the page. If I disable the rolemanager I everything works fine. If I set it to the AspNetWindowsTokenRoleProvider which I have it now, everything works fine in Central Admin. If I set it to the LdapRole I copied from technet, I can log into the Central Admin but any time I try to go to the Manage Web Applications in Central Admin I get prompted for my credentials and will get an access denied regardless of the credentials I give.

So with either rolemanager set to disabled, or using that AspNetWindowsTokenRoleProvider as the role manager I can log into Central Admin, go to Manage Web Applications, and do work on the Web Application sites I have just fine. I can assign user permissions to them and what not. If I go to managing the Web Application I want to have using Forms Authentication for which I have already configured the web config file for, I run into that strangeness of the Forms Authentication users coming back as "Organization" and not under Forms Authentication. I also don't get back any Windows Authentication versions of the accounts either in the people picker. This is despite the Authenticatio Providers for the Web App having both Windows Authentication and Forms Authentication turned on. I can assign either the "admembers" or the "LdapMember" Forms Authentication strings and have user accounts returned just fine from the Active Directory server.

When I go through the FBA connection to pull in an account, I know it is using that FBA connection string because of the prefix on the account name being returned. Also, the FBA connection only returns back the Username and no other meta data unlike Windows Authentication.

So for example to what I just described, I am in Central Admin. I go to Application Management -> Manage Web Applications -> Select Web Application Site -> Click on User Policy at the top.

From the window that pops up I click Add Users. I then go to the People Picker to search for users to add by clicking on that little book icon. If I have Windows Authentication ONLY turned on of the Web Application site I'll get back users with the following full names.

i:0#.w|domain\newuseraccount

If I turn on Forms Based Authentication for that Web Application and do a search in People Picker for the same account I get the following.

i:0#.f|admembers|newuseraccount

or

i:0#.f|LdapMember|newuseraccount


Just depends on which FBA connection string I have set to default to be used in central admin web config file.

Same thing goes if I try to add users to the Web Application directly when I log into the Web Application's site.

From all the examples I've seen on the net from setting this all up, I SHOULD be getting multiple accounts returned for every connection I setup. So I have for a given Web Application site set up to use Windows Authentication and Forms Authentication then I should get both accounts found in People Picker when I do a search. Which would be both
i:0#.w|domain\newuseraccount and i:0#.f|admembers|newuseraccount. The latter would be listed under Forms Auth category in People Picker and the other in Windows Auth category.

However I will say that if I do a "Check Names" to a username I want to add without using the People Picker search, the Check Names functions finds all connections.

Again, the biggest reason for this is to get User Profile Synchronization in Central Admin working with my Forms Based Authentication string. I am trying to make a site use ONLY Forms Based Authentication. I want only Forms Based Authentication profiles used on the Web Application site I have. I want to set it up so that meta data like email's, profile names, and other stuff is all properly synced between the Active Directory server and the profiles imported into the Web Application. This way if I make a change to the email in the Web Application user profile then that change will be reflected back to the Active Directory server.