LDAP Forms Authentication revisited

I've had a few comments on the configuration of Forms Authentication using LDAP and thought it worth raising some of these points in a new posting.


1.  LDAP forms authentication is only supported by Office Servers and not WSS

The architecture for forms authentication is based on WSS 3.0 but the specific implementation described in mine (and others) posting for use of Active Directory Application Mode (ADAM) and LDAP authentication is based on the Microsoft.Office.Server.Security.LDAPMembershipProvider and so is a component that shipped with Office Servers (Microsoft Office SharePoint Server, Microsoft Office Project Server, Microsoft Office Forms Server...).  So if you just have WSS 3.0 then you will not find this component.  One possible option might be to use the ASPNET Active Directory Provider and configure this for the LDAP port ADAM is running on (see http://blogs.msdn.com/harsh/archive/2007/01/10/forms-based-authentication-in-moss.aspx for some guidance) .  Or you could write your own authentication provider for LDAP... On-demand webcast here - http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032346257&CountryCode=US

2.  New ADAM users are disabled by default

If you are using ADAM hopefully you have already discovered that by default any new user is disabled.  To enable you need to set the msDS-UserAccountDisabled attribute of the user to false.

3.  Need to give ANONYMOUS LOGON read access to directory

I haven't needed to do this and certainly would not recommend it in a production environment.  I am guessing it relates to the account used for some application pool is set such that it appears to the directory as ANONYMOUS.  Much better to have an explicit user and give an explicit permission. 

Technorati Tags: Project Server 2007

Comments (22)

  1. Martin Winzig says:

    Hi I have again same smart comments 🙂

    As you guessing LDAP account relates to application pool, but this is Microsoft point of view. in real life I can’t use AD account to log in to 3rd party LDAP server as TAM.

    So we created custom Security provider, in which we can enter account of user who have access to LDAP (tested only against Tivoli Access Manager).


    I also have problems with Project Pro .from same strange reason  Project Professional  do not use credentials of user who is logged to PWA but:

    1) AD authentication: Credentials of users logged to computer , this should be classified as bug on premier support.

    2) Forms authentication: User has to enter credentials manually.   Because Project Pro sending this account to using Loginforms.asmx  we can’t deploy SSO.  (This isn’t bug SSO isn’t supported)  I discussed this issue with WebSeal guys but they are able parse user name and password only from HTTP header, so in case that project pro will be able add user credentials HTTP header of  SOAP request webseal can use this credentials to authenticate user and send original  request to project server. But even in this scenario user have to use Password 

  2. Interesting Martin.  Thanks for the feedback.  So to clarify, the bug you mention in section 1 is that if you choose to open a project from PWA (and you are logged in as an LDAP authenticated forms user) you expect Pro to open as this user and not the logged in AD account?

    Best regards,


  3. Martin Winzig says:

    In first scenario I’m logged to PWA as user Martin ,

    in the right corner I see welcome Martin,

    i click to this element and I select option  sign in as different user

    login dialog appears  i’ll enter Tom user name and password,

    then i go to the project center when i click to Edit, project pro can’t open this project because Project pro using account of user logged to the computer and Martin haven’t permission open this project.

    PS as I remember when I’m using Form Auth user is  asked for user name and password when he click to Edit,  but project isn’t opened (there is probably problem with script which opening the project)

  4. KH says:

    Hi Brain,

    I’ve recently installed and configured PS 2007 and SQL Server on a single machine using a local administrator account. It is required that users accessing to PWA go through authentication with Novell LDAP on the same network. As such I’ve tried using form authentication method mention in this forum to do it.

    I’ve tested authenticating the user DN (CN=userid,ou=DeptA,o=Company) using LDAP Browser. Initially there was a problem due to the server rejecting clear password, but after changing the port to 636 and using SSL, I was able to login successfully and is able to browse the see the userids in the base DN.

    However when I add the LDAPmembership to web.config files for CA and PWA extended site, I was unable to retrieve the user using Add User from CA, getting a “no exact match” message. The trace log also show a “cannot resolve user” message.

    My web.config membership provider section is as follows:

    <membership > <providers> <add name=”LdapMembership” type=”Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=, Culture=neutral, PublicKeyToken=71E9BCE111E9429C” server=”servername” port=”636″ useSSL=”true” useDNAttribute=”false” userDNAttribute=”cn” userNameAttribute=”cn” userContainer=”ou=DeptA,o=Company” userObjectClass= “person” userFilter=”(ObjectClass=person)” scope=”Subtree” otherRequiredUserAttributes=”sn” /> </providers> </membership>

    What do you think is wrong? What access right does the Novell LDAP need to grant and to whom (keeping in mind  the PS 2007 is run by the local administrator)? Any means to troubleshoot the membership provider?

    Your help is greatly appreciated.


  5. Hi KH,

    Not sure what is wrong but I’d try checking the userDNAttribute, userNameAttribute and otherRequiredUserAttributes in case the Novell directory does not use the exact attributes that ADAM does.  

    If you resolve this I will happily post your solution as it would be good to get a web.config for Novell to help others in the same situation.

    Best regards,


  6. KH says:

    Hi Brian,

    I managed to get the form authentication working after some help from the Novell LDAP administrator. The trick was to grant read access to anonymous login, first to all attributes, then narrow down to a few required ones.

    What I deduced is as follows:

    As the machine is setup using a local administrator account, an anonymous bind is done at the Novell LDAP server before the user credentials are authenticated. This is unlike an ADAM setup where ADAM recognizes a windows domain account if used as farm admin.

    By default, Novell LDAP grants anonymous bind "browse" access. That is why the LDAP Browser was able to show the users in the container. However, what the LDAPMembership provider requires is not just  "browse", but "read" access, which has higher authority than "browse".

    The web.config in my earlier post worked after the correct access rights were given.

    If you do not agree with my deduction, pls enlighten.

    Thank you and best regards,


  7. Excellent!  Thanks for the feedback and sharing the web.config KH.

    Best regards,


  8. Tom says:

    Glad I found some info on Novell LDAP with Project Server 2007.  This question I guess goes towards KH…  Where do you go in edir to change the rights for the anonymous bind from "browse" to "Read"?

  9. Sarath says:

    can you help me out how to implement forms authentication for MOSS using LDAP and Fetching the Users from Active Directory.It would be really Helpfull if you can do this.

  10. Hi Sarath, if you let me know exactly what problem you are having with this I can certainly try.  The tricky part of using LDAP against AD is probably getting the right permisisons on the directory to allow reading – or configuring the right paths to the containers.


  11. Gigabit says:

    I work for a large corporation that is upgrading from SharePoint 2003 to 2007.  Currently, the users and roles are in AD, and mgmt/scalability are already a complete mess (ie. org hierarchy rarely aligns with access requirements).

    The number of groups is getting out of hand, and this will only worsen with our intended use of SP 2007 (eg. more granular site, blog, and wiki perms).  Also, we’re finding that users can’t belong to > 100 AD groups (2003 native mode).

    Aligning the expected explosion in SharePoint roles with our long-term SSO goal, I’m lead to believe that moving all accounts and roles to a beefy LDAP platform, with a Kerberos access tier would offer the most scalability and performance.

    Given all of this, and thousands of existing SP 2003 sites, am I barking up the right tree(s)?  I feel like we’re going to be steam-rolled by SP 2007 administration requirements (ie. users rely heavily on IT for most security mgmt, and trying to roll-back a bad process this large will not be practical down the road [we’ve all been there]).

    Any guidance would be greatly appreciated.  Thanx!

  12. pursca says:

    Hi, Brian,

    Do you have information on how to configure MOSS 2007 authenticate with Tivoli Access Manager + WebSeal Reverse Proxy?

    Thanks very much!


  13. No sorry John, I don’t.  But if anyone else does then feel free to help out!

    Best regards,


  14. Ghayath says:


    Dear Jhon…. I don’t know if this would help you. kindly check above referred URL and let me posted if you got your answer.

  15. Thanks Ghayath – much appreciated!

  16. Michelle says:

    Hi Brian:

    Any references on how to move users from Forms to Windwos Auth? I know you can migrate these in SharePoint, but I can’t find anything on Pserver.

    Thanks for all of your help!


  17. Hi Michelle,

    Great question!  My initial thought was just change the authentication type in the PWA user setup and put in the domainuser account in place of the forms auth name for the user.  This will certainly work for the PWA part of the story – but I am not sure if this is enough to correctly ensure all WSS entities relating to the user would get updated.  It may be – but I don’t like saying yes until I have tested it.  I will try and test this out tomorrow – or if you have a test system you could give it a try too.

    Best regards,


  18. verayut says:

    Hi Brian,

    I’ve implement the forms-based authen follow this article http://technet.microsoft.com/en-us/library/cc197721.aspx

    I can completed all step in that article including "Verify communication with the LDAP directory" and already add user in Project Server.

    But when I login to pwa by form authen I got this error "The server could not sign you in. Make sure your user name and password are correct, and then try again." and I’m sure that user and password correct.

    Any guidance would be greatly appreciated

    Best Regards,


  19. Hi Verayut, have you confirmed that your user in LDAP is enabled?  Not sure if a disabled user would have passed the verification or not.  Can you browse to other pages as that user in SharePoint, such as the root site rather than PWA?

    Best regards,


  20. verayut says:

    Hi Brian,

    Thanks for your response. I have fixed already. The problem is user in application pool it should be add to member of CN=Reader.

    Best regards,


  21. Palinda says:

    I add our user to CN=Reader but still it gives same error. Did you do any thing other than that.

    plz help.

    Best Regards,


  22. annonymous says:

    The problem is user in application pool it should be add to member of CN=Reader. How you do that can you tell me the steps.

Skip to main content