You didn't mention adding an FBA user to the site collection as a Site
Collection Owner. Even if users authenticate, you need to authorize them by
giving them permissions to the site. That normally results in an error page
about access denied, so I don't know why that isn't coming up. But its one
thing to check.

I tried adding a Site Collection Owner, but People Picker wouldn't recognize
any of my users (The Dreaded Red Squiggly Line).

Did you add the Membership provider and connection string settings to both
the site collection web app and the CA web app? Not putting it in the CA
web app is normally why you can't add a new site collection owner from the
FBA. That or a PermissionPolicy at the web app level is required or you
won't be able to login.

Yep, they're in there. The weird thing now is that I can add SCAs through
Central Admin, but when I go to the FBA site collection, I'm getting the
login page... even though I've told it to allow anonymous. Whether I
provide it with real credentials or fake, I get no success and no error
message.

Funny story: I went through the whole process again on my local dev server,
and FBA started working like a champ. It even brought me anonymously to the
portal home page, and then allowed me to sign in as a Sql membership user.

So now I'm wondering what could possibly be wrong with this server, since
the same parameters worked on my dev box. I even copied the web.config
verbatim to the offending site collection, but no change.

I got FBA to work on my local dev server, but when I copied the web.config
to the test box at the client site (making sure there was no server-specific
stuff in there), I could not log in. No access, no error. However, the
client's Central Admin was able to recognize the FBA provider and add Site
Collection Administrators.

Then, this morning, it miraculously worked -- but not from my laptop. I'm
inside the client's building, but for some reason I can only log in via FBA
when I use one of their machines (NTLM works just fine either way).

What kind of policy or other wacked-out security setting would cause this to
happen?

Do you by any chance have cookies disabled in IE on your laptop? That would
do it.

my dev server FBA authenticated me with no problems.

In fact, I had added the URL of the test site to the Local Intranet zone as
well, just to make sure I was treating the environments the same way.

Oh, and yes, I did add the membership provider to the CA web.config before
doing that (assuming you meant for me to use CA when adding that SCO).

If the membershipProvider information was added to the CA web.config before
you tried to add the site owner then there is either something wrong with
the configuration entries you added or something wrong with the custom
membership provider. If the membership provider configuration is correct
and working you should be able to lookup users from CA. The problem is
either in the web.config or the membership provider itself if you can't.
Assuming it works in a regular ASP.net app then I would double check where
you put your entries in the SharePoint web.configs and also what access the
application pool identity account has to the sql database being used for
membership (assuming you are using integrated security).

The provider appears to be working. I pulled the web.config entries for the
connection string and provider, and inserted them into a local
VS.NETwebsite project. The provider was listed as expected, and I was
able to
open the Membership config site and add users and roles.

This leaves the web.config. Sounds like I need a giant magnet to pull that
needle out of the haystack, eh?

BTW, I'm using SQL auth with an account known to be working (as demonstrated
in the test ASP.NET app).

It may sound silly, but few years back I had some problem with the anonymous
authentication and I found some file or folder permissions missing from some
files in the layouts directory.

Okay, I've gotten past that problem and now access is denied when I use bad
credentials :) The problem is, I don't get an error with good credentials,
but I don't get in either! When I try to switch to that application in
Central Admin, I get a login prompt... and no existing credentials work.

I feel like I'm chasing myself through a four-dimensional house. Any
helpful hints?

The latest: I managed to get Central Administration working again by
specifying the correct default role provider (namely
AspNetWindowsTokenRoleProvider) in the CA web.config roles section.

NOW, Central Admin will let me choose users from my membership DB as Site
Collection Admins... however, I'm back to "no success, no error" when I
attempt to log in to the Forms Auth site collection in question (which, as
far as I can tell, has all the necessary stuff in web.config).

There has to be some silly thing I'm missing, but for the life of me, I
still can't figure out what it is. If CA can see your membership provider,
but that same provider isn't available from the app you're trying to
protect... what the heck?

Could you send me a copy of the Web App's Web.config from the site that
isn't authenticating? I'll take a look and let you know if something seems
out of place.