I haven't really seen many cases when LDAP seemed like a good solution -- though I've never tried it, so maybe I'm just talking myself out of learning something new. (I have tried to learn it, but it seems like a PITA)
However, keeping user information centrally managed really isn't a very good option. If I was doing intranet design for a single company I could make that kind of decision, but we're making websites for clients that already have IT departments with their own policies, and I don't want to compete with those departments. Nor do I want to take over their jobs ;) I need to find common protocols, not concrete data stores.
I think LDAP is definitely the correct solution for you here, although it is a pita if you haven't used it before. It is supported by pretty much everything however, and once you've got it set up it is very straightforward to administer.
It also handles one of the things that I don't think the other schemes you have discussed do, which is additional data associated with a user. Things like their real name, while not essential to authentication, are very useful to centralise, rather than repeating them ad infinitum in every new application that requires them.
I'd say it is worth the learning curve for LDAP - since I got the hang of it I have found it a useful tool in a number of situations where previously I would have chosen something else, but the LDAP fit is actually far better.
On your second point, that IT already have a central database of user information, I think LDAP is still the right answer. First, if they are a Microsoft shop then it is quite likely they use Active Directory, which supports LDAP. You can authenticate directly against that and bob's your uncle.
If they have some other user source (NIS perhaps) they you still have the issue of duplicating data somewhere however you do this. At least with a central store that uses a rich and well-supported protocol you only have to handle reconciliation/import/merge or whatever policy you come up with at a single point.