Thursday, February 5, 2009

Configure Forms Authentication Using LDAP

Microsoft Office Sharepoint Server 2007 came up with various new features and one of most awaited feature in this product is capability of providing different authentications for the same web site based on set of users. One can extend any MOSS web application on to 5 different zones and implement 5 different kinds of authentication mechanisms. The basic and default authentication MOSS provides is NTLM, apart from that MOSS can be configurable with SQL membership, another Active directory source using Active Directory connection or LDAP connection based on the requirement.

In this article I am providing information on from how to extend a web application to configuring profile import for forms based authentication users using LDAP.

How to extend a web application for forms authentication zone:

1. Logon to central administrator of farm with full rights.
2. Click on Create or extend web application option under sharepoint web application management section.

3. Choose the option extend in the resulting screen.

4. Leave the default NTLM site at time of extending the web application, and provide all other necessary information like load balancing URL port number, host headers etc.

5. Now open web.config file of your administrator web application using notepad or any other compatible editor and place the following strings at specified sections.
1. Just below closing tab of configSections (), add the below lines of code.

2. Search for peoplepicker in the config file and change that tag into below tag lines.

3. Now Locate tab in the config file and place the following string under system.web section.

Note: Make sure to use the public key token from your servier GAC instead of using the one mentioned here, because some .net versions will have different public key token for this assembly. In that case the authentication simply won’t works and we will never see hints on why it is failing.

6. Now Go back to central admin site and click on authentication providers tab under application security section.

7. Click on the zone name of the desired web application to set forms authentication.

8. Make sure to choose forms under authentication section and provide correct LDAP provider name for your zone to authenticate successfully. Also choose client integration NO, this is important because some times client systems which come from public zone may not be having full compatibility with MOSS client related applications, thus end users may find it difficulty to download the content.


9. Click save, now you are all set for authenticating your users with forms login instead of IE browser window pop ups. To verify the change, simply browse the forms authentication URL and see if you are able to see login page with user id and password text boxes with standard layout.

Now we are all set for forms authentication configured. Make sure your repeat steps a,b,c under 5 for web.config file of all zones of your web application.

Now we have to configure profile import for this FBA users and add users to forms based authentication zone. I will explain those details in the next posting under this blog.


Wednesday, February 4, 2009

Display name shows membershipprovider:SAMAccountName in LDAP profile import, here is the solution

Background:

I had to deal with configuring user authentication from different Active Directory domains for the same MOSS web application based on access zone at one of my client environment. The default zone works with internal domain AD where as the same site when accessed over Internet by the public partners, it should work with forms authentication which is configured though an LDAP connection.
Now the problem is, my customers are able to add external partners into the site but the display name shows MembershipProviderName + sAMAccountName. When the farm didn't configured to import profiles from external domain AD, the system is used to form the display name as First name + last name but as soon as we configured the profile import from external AD along with Internal AD we ended up seeing all display names being converted to MembershipProvider + samAccountName.

Solution:

After altering profile import configurations in several ways and play around Active Directory values in test environment we found two possible reasons for the behaviour.
1. Some times specific attributes of AD will require authentication and MOSS won't be able to pull that information with anonymous access over LDAP connection. To address this issue the service account with sufficient rights on targetted AD should be provided while forming LDAP import connection in SSP.

But our case didn't fall into this category and required more investigation, and allowed us to understand the default SSP profile bahaviour in more deeper way.

2. When there is no value in display name attribute of domain which is configured over LDAP connection, MOSS profile filling the display name attibute with MembershipProviderName + SAMAccountName.

What made us to confuse and diverted the investigation towards profile synchronization and import part is , when there is no profile configuration setup all profiles seem to be good with WSS basic attributes directly forming display name as first name and last name. But once profile import configured in SSP the output is completely differed. This is one more area where WSS and MOSS profiles various comes into picture.

I posted this as there is no documentation available on configuring profile import from multiple domains and related issues, may be my experience solve problem of other developers trying to fix similar issue.

Will come back soon with more MOSS configuration issues.