forms auth with AD
I've got one Web Application with multiple authentication providers. Problem, the forms auth site isn't seeing the AD user: testuser. It is looking at someother account. Why? Two Authentication Methods1. Windows - uses domain2. Forms - uses domain - see web.config below User Info per auth sites1. mydomain\testuser --- windows auth site -- see my AD user2. membershipadprovider:testuser --- forms auth site -- sees some other user -- not sure why Web.Config for Forms Auth Site:-----<connectionStrings> <add name="ADConnectionString" connectionString="LDAP://mydomain.com/DC=mydomain,DC=com" /></connectionStrings> <SharePoint><PeoplePickerWildcards> <clear /> <!--<add key="MembershipADProvider" value="%" />--></PeoplePickerWildcards> <system.web><authentication mode="Forms"> <forms loginUrl="/_layouts/login.aspx" domain="" name=".ADAuthCookie" timeout="20" protection="All" /></authentication> <membership defaultProvider="MembershipADProvider"><providers> <add name="MembershipADProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADConnectionString" connectionUsername="mydomain.com\appadmin" connectionPassword="password" attributeMapUsername="sAMAccountName" connectionProtection="Secure" enableSearchMethods="true" applicationName="/" requiresUniqueEmail="true" enablePasswordReset="false" requiresQuestionAndAnswer="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" /></providers></membership>----- In Central Admin, I have the forms auth provider membership pointing to MembershipADProvider. Why doesn't the mydomain\testuser have access to the forms auth site? Why and what is this membershipadprovider:testuser? If the MembershipADProvider is pointing back to the mydomain, should it look at the same profile? Any suggestions?
March 19th, 2008 8:03pm

has anyone experienced this before?
Free Windows Admin Tool Kit Click here and download it now
March 20th, 2008 4:05pm

understand what you're saying. that means i'll have two data stores to keep updated which is not good. this is for customers that are in a domain separate from employees. was hoping to avoid prompting users with the win-login process and leveraging the ad accounts via forms.
March 20th, 2008 10:07pm

I understand that completely about maintaining users in other places. It certainly becomes a management nightmare, but we did it in 2 seperate stores, because we didn't want any of our internal AD policies accidentally leaking to our external users, thus granting them access to items internally whether they realize it or not. So what is the core of the issue...That you see different stuff with domain\username than you do with membershipadprovider:username? I think the solution is just that you have to add each external users membershipadprovider:username to the site. You do not want to add their domain\username account. If you do, they ,in theory, have access to your site via your Windows Auth portion. Even though they are technically the same account with the same information, SharePoint needs to treat them seperate since one is AD and one is FBA. As long as all of the membershipadprovider:usernames are there you should be good to go...I think? If not, what is the core issue you are trying to solve here?
Free Windows Admin Tool Kit Click here and download it now
March 20th, 2008 10:23pm

Yeah, unfortunately that is just how SPhandles accounts. Once they are in SP, it pretty much forgets that they ever came from AD, and treats them as seperate users with different GUIDs and different profiles, even though in AD it is the exact same account.
March 20th, 2008 10:36pm

so how wouldone get to the profile for updating? i've got ssp setup on the default web app - uses win auth
Free Windows Admin Tool Kit Click here and download it now
March 20th, 2008 10:44pm

even gave this a try with LDAP: Constraints of Using the LDAP Membership and Role Provider http://msdn2.microsoft.com/en-us/library/bb977430.aspx#MOSSFBAPart3_UsingLDAPProvider ----- <membership defaultProvider="LdapMembership"> <providers> <add connectionUsername="mydomain.net\admin" connectionPassword="password" server="server1.mydomain.net" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="CN=Users,DC=mydomain,DC=net" userObjectClass="person" userFilter="(ObjectClass=person)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" name="LdapMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" /> ----- Had no luck. Any other suggestions?
March 21st, 2008 10:38pm

Craig-I'm not sure its possible to do what you are suggesting unless you get really custom. Don't forget though, that when you use FBA you lose funtionality. But let's pretend you could crack the nut of allowing users to login in different ways to the same URL. You've now got to figure out how to manage all of your users. Honestly, the only way an AD user could ever login via FBA/SQL would be if there was some way to keep the SQL user store and AD in sync. That ends up getting really complicated. I think you'd have better luck just trying to keep the directories in sync. Forget SharePoint, not sure this can easily be done in .NET :-)In my opinion, I think time and effort is better spent attacking other SharePoint problems such as workflow than something like this. Even if you were able to solve this problem you'd end up with something very difficult to support and maintain.John SharePoint911: SharePoint Consulting http://www.rossonmoss.com
Free Windows Admin Tool Kit Click here and download it now
January 16th, 2009 5:59am

So just to confirm, you can't maintain FBA users from the Windows version of the site, even with the Membership Provider configured in Windows web.config (as non-default)?
October 22nd, 2010 11:23am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics