Microsoft Office SharePoint Server 2007 and Novell eDirectory LDAP Authentication
Posted by Nick Kellett on 06/11/07 | SharePoint
Microsoft Office SharePoint Server 2007 is a great web platform. It's robust, secure, and extensible. Sometimes it can be a little hard to figure out though.
During one recent implementation I had to connect to Novell eDirectory to import user profiles and authenticate via Lightweight Directory Access Protocol (LDAP). A quick search of the net turned up some information about using LDAP in SharePoint, but lots of people were still having problems connecting to Novell eDirectory.
Liam Cleary's excellent blog articles, "MOSS2007 – Multiple Authentication Providers" and "MOSS 2007 - LDAP Authentication" were a huge help to me in figuring out how to do this. This article will provide some step-by-step instructions for importing your Novell users and authenticating them in MOSS 2007, and in particular will cover some little gotcha's you might run into along the way.
Adding an LDAP Membership Provider: Get Your Hands Dirty
LDAP Browser 2.6, available from Softerra as a freeware version at http://www.ldapbrowser.com/download.htm, is a great little tool to help you confirm what objects and properties you are trying to import. The first order of business should be to get your hands on such a tool. It will be your debugger and "sanity check" if you're not getting the results you expect in SharePoint. Once you've installed it, create a new profile that connects and returns your Novell eDirectory users and groups.
Now things immediately get a little messy. To begin with, MOSS 2007 is built upon the .NET 3 framework, which uses a plug-and-play concept called the Provider Model. This model allows you to use multiple mechanisms to provide core functionalities such as site navigation information, user roles, and user authentication. MOSS 2007 uses a default authentication provider, the Windows Authentication Provider, to import users from Windows NT or Active Directory. We need to add an additional provider, the LDAP Membership Provider. To do this, log in to your MOSS server and browse to the web.config files for your SharePoint Central Administrator, Shared Services Provider, and Default Portal websites. Where these are located depends on where you set up the default folders when you installed SharePoint. They can often be found by default in c:\inetpub\wwwroot. Note that if you installed multiple web front end servers, the Central Administrator web.config will only be found on one of them, while the portal website web.config might be found on all of them.
In each of these web config files, add the following within the System.Web element (after making a file backup!):
<membership > <providers> <add name="LdapMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="[LDAP Server]" port="389" useSSL="false" useDNAttribute="false" userDNAttribute="uid" userNameAttribute="uid" userContainer="[LDAP path to get base containers and Root object]" userObjectClass= "user"userFilter="(ObjectClass=person)" scope="Subtree" otherRequiredUserAttributes="sn,givenName,cn" /> </providers> </membership>
By adding this to the web.config, we are telling SharePoint that at runtime it has access to Microsoft's LDAPMembershipProvider class, which contains code to connect to an LDAP store. There are a few things to note here. To begin with, you have to provide the membership provider with a unique name. This is important as you will refer to this name elsewhere in the setup. Fill in the server attribute with the fully qualified domain name or ip address of the LDAP server, and its port number (the default is 389). Your userContainer information is what will allow you to get at the users and groups contained in this directory. You can test all of this by using your LDAP tool, to ensure that you are calling the correct container and root object. If your tool can return information using these settings, then so can the LDAPMembershipProvider.
Having setup the provider in the web config files, we'll now go into SharePoint Central Administrator and start by importing your users into the User Profile database.
Importing User Profiles
Create A New Connection in the Shared Service Provider
Log in to your SharePoint Central Administration site. Select your Shared Service Provider and click on "User profiles and properties" under the "User Profiles and My Sites" column. On this page click on the link, "Manage Connections". Click on "Create New Connection".
Give the connection a meaningful name. In the Directory service server name textbox, enter the server name or ip address of your LDAP server. For Provider name, you must enter the name you gave your LDAP provider previously. It's safest to copy this directly from the web.config file to make sure you don't mispell it. For username attribute, use either "uid" or "cn". Make sure that whatever you use is also specified in the web.config file - it should match whatever you have in the userDNAttribute and userNameAttribute LDAP Membership Provider attributes.
Once you've entered these, hit "Auto Fill Root Search Base". This will automatically bind to your LDAP store. If you want to narrow the search base you can enter the appropriate container in the Search base field, and change the User filter as well if you like (one possible option is to set the filter to (&(objectClass=*) to return everything).
Note that you can create as many import connections as you like. You can use multiple LDAP providers or import users from the Business Data Catalogue if you want to. In the case of additional LDAP providers you will have to add these to the web.config files as you did before.
Import The User Profiles
Now you're ready to import your LDAP users into SharePoint's User Profile database. Go back to the User Profiles and properties screen and start a full import. Once it starts enumerating you should see user profiles being imported into SharePoint. When the import is complete, click "View Profiles" to see what's been imported. Note that the account names start with the LDAP provider name you used. Your accounts will probably look like this: [Ldap Membership Provider Name]:[LDAP unique user ID]. A potential gotcha is that you may find you are missing users after you do imports. I had this problem when I specified the value "uid" for the userDNAttribute and userNameAttribute attributes and after switching it to "cn" the import returned everybody. If you run into issues like this, use your LDAP tool to try to identify accounts that may be set up incorrectly or are missing attributes you are importing on.
At this point, SharePoint should at least be importing your eDirectory users into the User Profile database. The next step is getting them to authenticate.
Extending Applications
In order to authenticate users using LDAP, you have to extend the existing portal to allow LDAP authentication. To do this, go to the SharePoint Central Administration site and click the "Operations" tab. Select "Create or Extend Web Application" and click "Extend an existing web application". Extending the application means that you will be sharing the same content but allowing users to log in on different port numbers using different different authentication methods.
Keep all the defaults, including NTLM authentication. Select the "custom" zone and choose a free port. If your default portal's port number is 80, choose port 81. This will create an additional virtual directory complete with web.config. Make sure to add the LDAP membership provider to this new web.config as you did before. Now your default portal responds to both windows (port 80) and LDAPauthentication (port 81).
The next step is to edit the authentication method for this application. Under the "Applications" tab, click "Authentication Providers". Select the "Custom" zone you just created to edit its settings.
Make sure you've selected the portal's web application. Choose Forms authentication and the provider name you used in the web.config file. You can choose to enable client integration; but be aware that many applications don't integrate well through SharePoint if you use non-default authentication providers such as LDAP. More on this in the last section of this article.
Assign A System Administrator
The next step is to add one of the LDAP users as the system administrator for this web application. To do this, on the Application Management page, click "Policy for Web Applications". Choose the application you extended, and the Custom zone. Choose a user to be the system admin. The account name will likely be in the form[Ldap Membership Provider Name]:[LDAP unique user ID]. Select Full Control for the permission level.
This user should also be the Site Collection Administrator for the site collection. On the Applications tab of SharePoint Central Administration, click Site collection administrators. Add the account as the primary or secondary site collection administrator.
Test Authentication
Here comes the moment of truth. Open both the default windows authentication port (80 in our example) and the extended LDAP authentication port (81 in our example) in different tabs in your browser. Notice that in the Windows NTLM tab, you are automatically authenticated into the site. In the LDAP port tab, you are presented with this sign in page:
Log in using your LDAP Site Collection administrator account. You don't need to include the [Ldap Membership Provider Name]: part, just the LDAP account name. You may see the following message:
If you see this, make sure you add the following to the LDAP Membership Provider code in the web.config file: useDNAttribute="false". Thanks to Renee Hulsman for this fix: http://www.sharepointblogs.com/rhulsman/archive/2006/12/12/16853.aspx.
If the login works, notice that you have two different users logged in to the portal, on different ports but viewing the same content:
You can test this by modifying the content in one tab, and then watching it updated in the other tab (after a refresh). This is further proof that you are authenticating to the same content using different mechanisms.
You'll have to add your LDAP users to portal groups such as Portal Members or Portal Visitors in order to let them view the portal.
At this point, you can authenticate your eDirectory users into the portal using the extended web application you created. The next page of this article outlines a few issues to be aware of when using any kind of Forms authentication.
1 Authentication Method = 1 Web Application
Each authentication method requires its own web application. This means if you wish to share the same content but allow different authentication, you need to extend the existing application as we did. This isn't exactly a limitation as it keeps things simple, but you need to keep an eye on which ports have which authentication methods.
Client Integration Problems
The biggest limitation is the client integration experience. Although you can tick the checkbox to Enable client integration, there is a warning message on the page indicating you may face problems.
I ran into a problem using SharePoint Designer after I enabled LDAP on the farm. At first the Designer couldn't even find the SharePoint site, and eventually it started complaining about authentication. The resolution was to point it at the NTLM-authentication address because it had no chance of getting into the LDAP one.
Another, more serious example of this problem is when LDAP-authenticated users try to create new content from the SharePoint portal. Here's an example of what I see when I try to create a new document from a document library while I'm logged in to the LDAP-authentication port:
Your users can create the documents on their own and then upload them, but they will then have to manually edit the document to change any metadata. Hopefully this will be fixed in a service pack.
Conclusion
I didn't want to end this article talking about issues and limitations, because the truth is SharePoint has a great deal of flexibility when it comes to authentication, and this will only get better. The use of the Provider Model is a wonderful decision because third party vendors can provide authentication providers for SharePoint, and you can even write your own against a documented standard. An added bonus is that all .NET 2.0 + applications you have can also use these providers. Even better, software like IIS 7 will support them as well. So the bad old days of multiple authentication silos are on the wane.
If you have any questions or comments about the content of this article, please feel free to contact me at nick@griffonsolutions.com. I'll try to keep it up-to-date as I learn new things or get good advice from the SharePoint community.
In the meantime, best of luck with your SharePoint deployments!
Want to learn more about Microsoft SharePoint Server 2007?
View SetFocus' SharePoint Training options.
About Nick Kellett
Nick Kellett is a former alumni of the SetFocus Master’s Program Java Track, with over a decade of Java and .NET development experience in New York, London, Ottawa, and Sydney. He has been working with SharePoint since the Office 12 TAP program and is currently contracting in Australia. Nick has delivered over a dozen successful SharePoint 2007 projects for government and private-sector clients. Technical deliverables for these projects include managing low-bandwidth content replication, creating Business Data Catalogue schemas, architecting site and farm topologies, designing master pages, and developing workflow processes.