Sharepoint 2010 Form Based Authentication Setup with LDAP

For our example we’ll use the LDAP provider that ships in SharePoint 2010 for our directory.  Let’s look at each of these steps in more detail now.

Step 1 – Create a New Web Application

Start by going to the Central Administration web site.  Click on Manage Web Applications, then click on the New button in the ribbon to create a new web application.  In the new web application dialog we’re going to select the following settings:

·         Authentication:  Claims Based Authentication

·         Identity Providers

o   Check the Enable Windows Authentication box or you won’t be able to crawl the site

o   Check the Enable ASP.NET Membership and Role Provider checkbox

§  In the Membership provider name edit box, type LdapMember

§  In the Role provider name edit boxy, type LdapRole

·         I won’t cover all of the other sections in the new web app dialog because they aren’t specific to using FBA, so just fill them in with whatever values are appropriate for your implementation

When you’re all done click the OK button to create the new web application.  Now that the web app is created, I Highly Recommend That You Create A New Site Collection I’ll move forward assuming you have done as I’ve suggested.  Now…okay – step 1 is done, let’s keep moving.

Step 2 – Configure FBA Support

This step is where we go through that same process as 2007, where we need to add some entries to the web.config file for our web application, and we need to do it on each web front end in the farm.  The basic chunk of Xml we’re going to work with for the LDAP provider looks like this; I’ve highlighted the parts in yellow that you will want to change for your implementation:

<membership>

      <providers>

        <add name="LdapMember"

             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

             server=" yourserverDC.LUSERS.local "

             port="389"

             useSSL="false"

             userDNAttribute="distinguishedName"

             userNameAttribute="sAMAccountName"

             userContainer=" CN=Users,DC=LUSER,DC=local "

             userObjectClass="person"

             userFilter="(ObjectClass=person)"

             scope="Subtree"

             otherRequiredUserAttributes="sn,givenname,cn" />

      </providers>

    </membership>

    <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" >

      <providers>

        <add name="LdapRole"   

             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

             server="yourserverDC.LUSERS.local"

             port="389"

             useSSL="false"

             groupContainer="CN=Users,DC=LUSER,DC=local"

             groupNameAttribute="cn"

             groupNameAlternateSearchAttribute="samAccountName"

             groupMemberAttribute="member"

             userNameAttribute="sAMAccountName"

             dnAttribute="distinguishedName"

             groupFilter="(ObjectClass=group)"

             userFilter="(ObjectClass=person)"

             scope="Subtree" />

      </providers>

 </roleManager>

 

Copy this chunk of Xml into something like notepad and change the parts highlighted in yellow to values that will work in your environment.  Now you can copy from there into each of the config files we need to change.  Unfortunately we’ll need to use a slightly different version of this in each web.config file.  Let’s start with the easy one first – central admin.  Find the web.config file for central admin and open it up in your favorite editor, like notepad.  Scroll down to the <system.web> entry, and paste the entire chunk of Xml directly below it.  Save your changes and the first one’s done.

The next one we’re gonna hit is the web.config for the Security Token Service (STS) virtual directory.  Explaining what the STS does, what claims based auth is, etc. is all way beyond the scope of this posting, but we’ll get to those things in time.  For now, we need to find the directory where it’s web.config file is and the easiest way to do that is to open the IIS Manager.  Expand the plus sign next to the server name.  Expand the plus sign next to the Sites object.  Expand the plus sign next to the SharePoint Web Services virtual directory.  Beneath it, find the SecurityTokenServiceApplication virtual directory.  Click on it, then click on the Content View button in the bottom of the middle part of the screen.  That will cause the Explore link to appear in the Actions pane on the right hand side of the screen (it’s the third link down from the top).  Click the Explore link and Windows Explorer will open up and you will see the web.config file you need to work with.  Open up the web.config file in a text editor and scroll all the way down to the bottom.  Directly under the </system.net> entry, do the following:

1.       Add a <system.web> entry and press enter.

2.       Copy and paste in the chunk of Xml shown above.

3.       Add a </system.web> closing tag directly below the stuff you pasted in.

4.       Find the <roleManager> element in the chunk of Xml you pasted in, and delete the defaultProvider attribute.  That leaves your roleManager element looking like this: <roleManager enabled="true"> 

Save your changes and the second one’s done.  Now, go find the web.config file for the new FBA web application you created and open it up in notepad.  When you configured the web application to support claims based authentication, it automatically added in some Membership and Role provider information that points to a custom set of providers SharePoint 2010 adds out of the box.  So all we need to do is to just add in our provider into the correct section in the web.config The Role provider is listed first, and the Membership provider is listed second.  Scroll down the web.config file until you find the roleManager element (it’s a ways down there).  Copy out just the role provider definition from the chunk of Xml above and paste it below the <roleManager><providers> sections.  So you will paste in just this part (with your site specific info replacing the part in yellow):

<add name="LdapRole"   

             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

             server=" yourserverDC.LUSERS.local "

             port="389"

             useSSL="false"

             groupContainer=" CN=Users,DC=LUSER,DC=local "

             groupNameAttribute="cn"

             groupNameAlternateSearchAttribute="samAccountName"

             groupMemberAttribute="member"

             userNameAttribute="sAMAccountName"

             dnAttribute="distinguishedName"

             groupFilter="(ObjectClass=group)"

             userFilter="(ObjectClass=person)"

             scope="Subtree" />

 

Now scroll down a little more and do the same thing to add in your Membership provider.  Find the <membership><providers> element and right below paste in membership provider stuff from the chunk of Xml above (with your site specific info replacing the part in yellow):

<add name="LdapMember"

             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

             server=" yourserverDC.LUSERS.local "

             port="389"

             useSSL="false"

             userDNAttribute="distinguishedName"

             userNameAttribute="sAMAccountName"

             userContainer=" CN=Users,DC=LUSER,DC=local "

             userObjectClass="person"

             userFilter="(ObjectClass=person)"

             scope="Subtree"

             otherRequiredUserAttributes="sn,givenname,cn" />

Step 3 – Add A User Policy

This part is basically exactly the same as you did in SharePoint 2007, with a couple of very minor differences.  Go to the central admin site and click on Manage web applications.  Click on your new FBA web application, then click on the User Policy button in the ribbon; this brings up the User Policy dialog.  Now do the following steps:

1.       Click on the Add Users link.

2.       In the Zones drop down, select the Default zone and click the Next button.

3.       Click the Address Book icon.  This will bring up the people picker and will let you know real quickly whether everything is configured correctly or not.  The first thing you should notice is the you see a new interface.  I think it’s going to be called the Principal Picker or some other equally nerdy name, but you get the point – it allows you to search in one dialog and show matches from all of the directories you have configured.  It’s pretty slick.  So go ahead and type in the NT login name or account name (use whatever nomenclature you prefer here) and click the search button.  If it’s working correctly you should see at least two entries for the account – one that is for the user’s Active Directory account, and one that is for that same account but which was found using the LDAP provider. 

4.       Select the account in the User section and click the Add button.

5.       Click the OK button.

6.       Check the Full Control checkbox, then click the Finish button.

That’s it – everything should be all configured now for you to log into your new FBA site.

Step 4 – Login

Go ahead now and navigate to the site in your FBA web application.  You should get an initial prompt where it asks you what kind of authentication you want to use to access the site – Windows Authentication or Forms Authentication.  Select Forms Authentication from the drop down and the page posts back with a standard forms login page.  Enter the credentials of the user to which you granted the Full Control user policy and you should log into the site.  Now you can start adding other FBA members and roles into SharePoint groups.

Install SharePoint 2010 on Windows 7 Enterprise, Pro & Ultimate.

In the real world, particularly in a production environment do you really want to be poking around in VB and doing development work? Not really. Most development environments are slow and you have to wait for other folks to log of remote desktop, cause no terminal license are available due to budget cuts, etc. Everything dampers your efforts in getting your job done.

Well Microsoft came to realize this, so they made it real easy for any SharePoint developer to get a development workstation up and running seamlessly on their own machine or any other for that matter.

Download the following from Microsoft: (these are free)

SharePoint2010EasySetup.exe

SharepointServer.exe

The "SharePoint2010EasySetup" will download everything for you, including SharePoint itself, but it will take forever and it will install things that you may not need. In its setup process it downloads trials of software that may or not be relevant for you. In this case, I recommend you download SharePointServer.exe  (64 or 32 bit) separately. For this article, it’s a must.

Run "Machine Role Prep Script" below. Open as an administrator a command prompt. Copy and paste it, then execute it. This will install IIS and setup the proper "ROLES and FEATURES" needed to run SharePoint. (It may or may not download solutions depending on your Windows version.)

1. Decompress Sharepoint2010easysetup and place it on the root (c:).
2. Create this PATH and Folders like this: C:/Sharepoint2010easysetup/Setup/SpApp
3. Place "SharePointServer.exe into the "SpApp" folder.
4. Go to C:/Sharepoint2010easysetup/Labs/EasySetup/Source
5. Find "config.xml" open it with any text editor and remove the lines of code representing the downloads of software you don't need, located between "<Applications>", make sure you end the script properly like this: "</Applications>"
6. You are ready to execute "Run.bat" which is in the same folder.

What will happen?  Simple, it will configure and install SharePoint 2010 on your local machine. You can later go into CA and enter an Foundation or Enterprise key if so desired after or before the trial period.

Follow the instructions it asks and you will be ok. Once completed, you can then start working immediately. You will have SharePoint 2010 and SQL Server2008 Express installed, ready to go. This will work faster than any virtual and it runs in the background all the time. If you have powerful desktop or laptop, your SharePoint will be really fast.

Enjoy,

Fasty

Machine Role Prep Script:

start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ManagementScriptingTools;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-RequestFiltering;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI;WCF-HTTP-Activation;WCF-NonHTTP-Activation

To AD or not to AD, that is the Question.

It has always been a point between System Admins vs

SharePoint Admins. Active Directory and SharePoint Group Permissions.

Should you use or not AD Groups in SharePoint instead of the native SharePoint

groups? Many have found wondering on implementing solutions without really

taking a look at the actual needs for the enterprise.

I found a very simple solution or "mind state" that can quickly put to rest

on how to choose and properly set permissions, depending on your IT environment.

1. If you have consultants working on the server, until they are a full employee,

you don't want anyone snooping around in your AD. In this case, allowing

them to add and manage users in SharePoint is the proper course.

2. We all know you can have file level management, but do you really want to enter

this world of chaos? Do you really want to manage all content at a file level permission?

This is ridiculous and very time consuming, simply there is no need. In a large

SharePoint environment, allowing users to manage at a file level is not the recommended

course. As a matter of fact, most companies simply do not allow it. So how do you manage

files and all other SharePoint items?

You use both, Active Directory and Custom SharePoint Groups. I say custom, cause in reality

and in most cases only 3 groups are actually needed and you can name them almost the

same as the naming convention used in AD. Example:

3. Create three SharePoint groups for a portal:  XYZ CONTENT MANAGERS,  XYZ CONTRIBUTORS, XYZ READERS.

Content managers have full control of their portal, contributors can add and edit items, readers can only view.

In AD create a Main SharePoint Group in which all sub group will be stored. It should look like this:

SHAREPOINT GROUPS --(top level)

            SP XYZ -- ( Portal Group Name )

                        SP XYZ CONTENT MANAGERS

                        SP XYZ CONTRIBUTORS

                        SP XYZ READERS

In SharePoint simply add the AD group name into the SharePoint designated group. In AD, add the user to their respective

AD Group to allow the proper access. If in SharePoint you have a document library that only contributors should have access too,

in the setting for that list, set permission not to inherit from the parent site, and add the group that should have access.

If you keep this "process" you will have a very organized SharePoint permission structure. More to come on Active Directory and SharePoint.

Fasty.