Custom Membership Provider “Server not operational”

Posted: November 15, 2007 in MOSS 2007

You have coded your own Membership and Role providers to manage the authentication, role validation, user information, etc to a non-AD LDAP data store. You have utilized the standard DirectorySearcher, Directory,Entry, etc classes from the System.DirectoryServices namespace. The installation on central admin, the windows auth site, goes smoothly and you easily verify communication between these sites and LDAP as you add a couple LDAP users to the extended FBA site to make it possible for you to log in to that site and add other users/LDAP groups.

You attempt to log into the FBA site and despite being a high level user your LDAP authentication fails. You check the logs from your membership provider and find that all attempts to access the LDAP server return a “server not operational” error. As an additional hint, you can look in your SYSTEM event log and find an exception kicked out by “Schannel”, just once. It generally will not repeat until you reboot the server. The text of that exception will be something like:

“System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational. Also, schannel event 36882 is logged to the event log: "The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate.".  

The code failing is the exact same code that runs fine on the other 2 sites (CA and non-FBA site) and you have installed the certificate for the SSL communication on your server.

There are a couple circumstances that lead to this exception. The first thing to understand is this, the actual thread that is accessing the membership provider, on the central administration and Windows integration security site, is running under the logged in user, and NOT one of the MOSS service accounts. However, when you set up FBA on the 3rd site, in IIS is turned off integrated security, and enabled anonymous access. As a result, when you attempted to log into the FBA site, there was no windows login to run under. SharePoint will call and run the membership provider validation code under a “GenericIdentity” object user.  

Now since the LDAP directory requires SSL, there are some certificates that need to be checked. The classes in System.DirectoryServices ( as opposed to System.DirectoryServices.Protocols ) automatically manage the whole certificate validation process for you.  When you are logged in as a known user, it will check the user HIVE for the certificate LDAP is passing to validate, when you are a GenericIdentity, it will check the machine root  for the certificate. This can present a problem since under certain circumstances it appears , that even though the certificate is in the trusted store,  ASP.Net 2.0 would not examine the machine-level certificate store. The result was, the LDAP server’s certificate could not be validated and the machine would NOT make the connection. The first time sChannel logged it in the SYSTEM log (and never again till I rebooted), though in the exception object returned by the catch statement you will only get “server is not operational”

This is one area where the fix gets ugly. At the current time the only way I found around this issue was to code around it. You need to implement the LDAP connection and queries in the affected methods using the System.DirectoryServices.Protocols namespace level and you need to manually code a function to validate the certificate passed by the LDAP server to the membership/role provider. Keep in mind, the majority of the role provider calls even once you are logged in will be made with a genericidentity or as a user unknown to the server.

  1. Guru says:

    Hi Mike, we have sharepoint 2010 environment with FBA authentication( ADLDS users) with wildcard veri-sign certificate ( * we have configured SSL in sharepoint as well as connecting AD-LDS also SSL ( 636). when I am trying to connect AD-LDS with non-ssl (389) port I am able to login the site. The same thing when I am trying to connect AD-LDS with ssl(636) port I am not able to login to the site. we have done all necessary configuation from sharepoint and LDAP side. we don’t have any idea what is the problem. Please suggest me on this. your help will be appreciated.

    • mstarr13 says:

      Hey Guru,
      So your login works fine non-SLL (standard Http) and not with SSL. When you say you cannot login, are you prompted for the login at all? What specific error message, page do you see? I would also make sure you do not have any firewall or other issues with the 636 port. Double check your IIS logs, server logs (via event viewer), and SharePoint ULS logs and pull any events that seem relevant to the date/time of the failed authentication.

      My typical route with troubleshooting Auth issues is to write all the info up on the white board, how the connection SHOULD happen, use the logs and error messages to try to determine what leg of the auth process is erring out on you, and hopefully that will allow you to zoom in on the specific issue. Please feel free to post up any information you get from the questions I asked and I will see if I can provide any further assistance. Any additional information you can provide on your infrastructure (without compromising your security/confidentiality) may also help. So server count, specifically WFEs, etc, anything that may be relevant to the point where the auth error is being returned. Also, what version IIS you got going on there.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s