The title says it all.
There's a section in Eric Evans' DDD book where he spends about 3-5 pages saying that composite keys are bad and surrogate keys are good (without just coming out and saying that). At the time I thought he was being exceptionally wordy, but it's an awfully good point to drive home. Composite keys (multi column primary keys) make any kind of Object/Relational mapping and persistance in general harder. Life is so much easier with surrogate keys. You can always make unique constraints where it's necessary.
When I've used NHibernate against a legacy database, we just cut our losses and added autonumber columns with a unique constraint to act as the identifier for NHibernate and left the old key alone. It worked pretty well, but I don't think those classes had any relationships, so I don't know how that would work. I'd like to recommend to my current client to quietly ditch their homegrown Java persistence tool in favor of Hibernate, but putting an O/R mapper on a legacy database is challenging. iBatis maybe, but I don't know much about it yet.
From anybody older than me out there, why were Composite keys so widely used in older databases? Was there a real reason? All I've ever seen from composite keys is pain.