Priasoft finds that there are only 4 configurable ways to provide SSO in a cross-forest migration:

1. Linked-Mailboxes.  This is an Exchange specific feature for which no other application or service in the target environment benefits.  Priasoft can create linked mailboxes in the target via a couple of checkboxes.  The Microsoft feature of Linked Mailboxes requires a trust between the domains.
2. SID-Future.  This is essentially SID-History in reverse.  If the SIDs of the pre-staged target user accounts were carried back to the source accounts prior to migration (using ADMT), then the source user accounts would have two SID values:  the primary SID of the original source user account and the additional SID of the target account.  Users logging in to the source domain, but accessing a migrated mailbox would have SSO because of the second SID attached to their user account.  However, unlike Linked Mailboxes, SID-Future works for ALL applications in the target environment that use Active Directory for identity and authentication.  This means that services like Lync and Sharepoint get automatic benefit from this idea.  Migrating and using SID History also requires a trust between the domains.
3. ADFS (Active Directory Federation Services).  This additional toolset from Microsoft (which requires additional licensing) can be a cross-forest authentication broker and does not require a trust.  Setup is not trivial and may take some time to get “just right”.
4. Migrate and cause user account logons to occur in the target domain immediately following a mailbox migration.  In this migration pattern, users would be logging on in the target domain, the same one holding the new mailbox, and would have natural SSO because of the relationship.

Outside of these 4 options, there’s no other way for SSO to occur.
For SSO with Office365, the only option is with ADFS