New

Separate Users database from CM database, to allow for independent management

Recently, we did an upgrade from Tridion Docs 14 to 15. As is typically the case, there is some iteration to migrate/upgrade the existing CM database, validate, and then often we will go back and "refresh" by migrating the old environment database again, for various reasons (to pick up delta of content changes, to correct any issues found, etc.).

With Docs 15, we moved to SSO, which means all of the user configuration had to be updated after the database migration, to convert users from the older, independent SDL logins to new SSO logins integration with our Microsoft ecosystem. But then this creates an issue in the above described situation, where we do a database "refresh", as this can wipe out all of the updated SSO users, resulting in needing to redo all of them.

I'm not sure if there is a way to do this, since user data is closely coupled with the CM database (creation dates, modified by, etc.), but if it were possible to separate the user data out from the CM database (either another database or maybe an export/import mechanism of some sort), this would solve the issue of having to redo all of the user accounts manually.

Damian Jewett

  • From Docs User Group: It would be nice to have all of the user access and account info available to manage together. Many of us have mixed-method environments (SSO and internal account management), and the current method of managing in two different formats/places becomes problematic at scale. Example would be the fine-grained permissions controls of internal controls that aren't available for SSO-based users (i.e. allow or disallow applications like Draft Space vs Review Space). It may make as much or more sense to merge application-layer access management with the user access management layer of Docs "proper," whether that is in the DB or different DB as CM.

  • Hi Damian,

    Splitting out databases, in turn applications, in turn maintaince manuals is not a small effort. The SSO switch from built-in to external is also something that happened once, and for this one between 14SP4/14.0.4 and 15/15.0.0, the product would be late with this feature :) So I would like to ask what where the exact tasks that you had to "re do"?

    The only technical demand I saw in your description, that you seemingly did manually, was adding a value to the FISHEXTERNAL. This can quite easily be automated in an ISHRemote script. But perhaps there other things we might have missed?

    The linked script is 8 years old, but the concepts are still there... Synchronize - so add/disable/delete/alter-rights - on InfoShare user profiles with a group of Active Directory users. This maintains the necessary Knowledge Center Content Manager (= LiveContent Architect = Trisoft InfoShare) user profiles for usage with (indirect) Windows Authentication. gist.github.com/.../c80ef8a5a6025eb2267a9c1a91c3a9c4

    Best wishes,
    Dave