Three common (IME) manifestations:
1. the domainObjectClass is disallowed to do something across the ORM due to constraints enforced on the domainEntityTable (varchar truncation, anyone? No? Just me?)
2. some domainObjects fetched through the ORM are deserialized into an implicitly (e.g. null/empty collection members) or explicitly (violates some invariant enforced by domainObjectClass) invalid state
3. domainObjectClass has to grow hairy with bookkeeping metadata (read: implementation details) to facilitate work with partial object graphs while still enforcing domain invariants on the data in scope (null vs DbNull, "object with PK already exists" oh God please just kill me now)
The common cause for the preceding examples is that the ORM (and it's tutorials) encourage you to do the same domain modelling twice, for the price of one. To wit: You do your domain modelling in your classes and the ORM translates this into a database schema with the same entities at the same level of abstraction. This causes a coupling of the semantics of database constraints to your domain objects and vice-versa: your database records may not violate domainObjectClass invariants otherwise inexpressible in the database engine.
Whether or not this is a problem depends on context, but it happens either way. If and when it becomes a problem your options are usually: quit, rant on you blog or both.