Note: This is a repost, the original one was published on SharePoint Blogs on October 24, 2007
Last year, just after the release of MOSS 2007 we run into a very strange problem when we tried to configure FBA. After using this feature on B2 and B2TR more-or-less successfully on the RTM it was totally unusable. When the users entered their correct username and password the login screen appeared again without any sign of incorrect credentials or access denied message. If they provided incorrect credentials, it was handled by the system correctly (e.g. they received a warning message about the incorrect username or password).
Using SQL Profiler we created traces that showed that using the correct credentials the FBA was successful (at least on the database level). It means that the SP responsible for FBA returned success.
It was an interesting addition to the issue that when we checked the working with FireFox the FBA was working as it should be. Later there were issues with FireFox (it is another story) but users were able to log in at least.
When we used the Central Admin web site there we experienced another issue that we thought may be related to the login problem: after selecting the application to manage from the HTML list on the admin pages, the selection was lost and the first item got selected, although the setting we made on the pages were applied correctly to the selected web application.
We read all important blogs about using FBA on MOSS 2007, trying to remember what we made differently on the beta versions. We reinstalled the system several times, even the DC was reinstalled in the test domain (who knows?) without any success.
We felt it was almost sure that the direct cause of the problem is the incorrect cookie-handling in the browser, but were not able to catch the root of the problem.
I tried to remember what could be different between the previous beta-based and the current RTM installation. Somehow my attention was focused for a moment on the name of the MOSS server machine and I immediately knew I had found it! While we gave the name MOSS for the server previously, my colleague who made the installation started to name it MOSS_DEV recently. I did not know why, but I was sure that the underscore will be the source of our pain.
After a short google I found the proof of my theory. This page on SAP site about Fully Qualified Domain Names (FQDN) tells that "The browser does not accept cookies if a host name contains the underscore character".
This MS support article says that "Cookies Are Not Saved If the Host Name Is Invalid".
Also I found a very similar incident in IBM’s knowledge base: Form login does not work when the hostname contains an underscore. I feel this one very instructive. Unfortunately, I found it only after solving the problem myself. It could have saved a lot of time for us.
Main thing quoted, but I suggest you to read the entire article: "Internet standards do specify that hostnames should not contain underscores (RFC 1123 & RFC 932)".
Well, we already know it. Sad, that MS Windows Server 2003 is not aware of this when allowing users to set host name containing underscore without alerting them for the dangers. The browser made by the same company follows the RFC rules. Not very consistent.