What are the accounts in SQL created/used by AccessData products during and after install?
AccessData applications create the following SQL server accounts for internal use:
This SQL Login is the owner of the shared database schema. This is necessary
because AccessData’s forensic products allow multiple versions of the
application to exist concurrently within the same database instance. For
example, this allows AccessData to support an FTK® environment running
both version 5.6.3 (ADG510) and version 6.0.1 (ADG6) concurrently within
the same database instance.
This SQL Login is the owner of the application’s DLL files that are used in the
database for supporting the sequence files for all versions and databases that
the application uses. The application does not use this Login to access SQL.
This SQL Login is the owner of the certificate used to create privileged stored
procedures within the shared and project schemas. This allows database access
through the other SQL Logins without requiring them to possess sysadmin
privileges. The application does not use this Login to access SQL.
This SQL Login is the owner of the project databases and is for a specific
schema version within both the shared and project databases.
Each project database has an associated SQL Login created, which is the owner
of the project schema for its associated project database. The names of these
SQL Logins correspond to their project schema (e.g., the ADG6_0001 SQL
Login would be associated with the Case_ADG6_0001 project database).
The connection parameters of these Logins simplify database access, resource
management, and control of the databases.
Is it possible to change Internal SQL Server Accounts?
AccessData’s applications do not use internal SQL Logins to control access to the databases in a traditional manner. Rather, the applications employ the internal SQL Logins in such a way as to isolate the data of each project database from another.
AccessData applications generate randomized passwords for each internal SQL Login during the initial installation and setup of the application and, subsequently, during the creation of project databases. AccessData does not support the modification of the passwords of these SQL Logins, as it would render the application components unable to access SQL properly and consequently compromise the functionality of the AccessData application.
Is it possible to change Summation® Pro’s internal database owners?
AccessData does not support the modification of the database owner from the internally configured SQL Logins. Internal control of the ownership of the databases allows the application to support specific functionality including the archiving, detaching and deleting of project databases. Modification of the database owners will also adversely aect the upgrade process, during which time the internally configured SQL Logins are necessary to perform the backup and renaming of the databases.
The attached is the original PDF to this KB.