Currently CA Data Protection infrastructure components with a SQL backend require a SQL-Server-Authenticated SQL Login.
Our company Information Security department has issued a security mandate requiring all connections to SQL Backend databases to use windows authenticated accounts. We need this functionality to be able to meet this mandate. As it stands, our implementation of Data Protection is currently non-compliant with this mandate and as a result have been flagged violations. We are now under review by internal security audit teams who have requested that the product be extended to meet and support this requirement.
As a result, this idea is submitted to request a modification to the supported infrastructure login types for SQL server to allow the infrastructure to connect to the database as a named windows account.
Example: by using "Integrated Security=SSPI" or "Trusted_Connection=yes" in the connection string.
This can be implemented / controlled as a startup.properties param and/or dword reg value
db.AuthScheme=[0,1] and/or registry value DBAuthScheme= [0,1] - Where
0 = SQL Server Auth Login (default/current behavior)
1 = IWA SQL Login (using windows named account / integrated SSPI, etc)
This might require db.jdbcDatabase connection string include an addition parameter, ie:
or perhaps that is appended dynamically via the code.
The domain credentials can be either cached on the infrastructure server via wgncred - which the infra can then use/impersonate to connect to SQL; Or, probably easier, the infrastructure service itself can be configured to run-as that named windows account as a pre-requisite to enabling IWA SQL Login support.