cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cnaslain
Level 3

Is there a way to keep untouched a service credential (user/password) set after install whe upgrading a product?

Hi,

We have a product installed with Installshiled. This product installs a service.

I some case, the client needs to add connexion credentials to allow the service to read data from a shared network drive. After adding credentials and restarting the service, the service works fine and can read data on the shared network drive.

When upgrading the product (major upgrade), the service is removed and re-installed and the connexion credentials are lost.

Is there any solution to keep untouched these connexion information or backup/restore them after an upgrade?

I have read old documents talking about HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\_SC_<ServiceName> access; but it seems that access to this part of the registry protected by Windows LSA is no longer possible.

Regards,

Chris

Labels (1)
0 Kudos

(2) Replies
Jenifer
Flexera Alumni

Hi @cnaslain ,

 

Can you try setting the credentials in property which can be saved to registry values?

You can do the following:

  • Save the values of your credentials in property say ServiceCredential
  • Specifically, define an IS-property that represents the Account attribute value and load that value from the registry during MSI startup and if the value is not present, use a default value of NT AUTHORITY\LocalService.
  • Ideally the property value would be stored in the application's own registry key and it is the application's responsibility to ensure that value matches the current service configuration.
    • This can be done by creating a new registry key in HKLM that lets LocalService or NetworkService (or whatever the service account is) write to it, so when the service starts-up it records its user-account's name there - This can be done via script or custom action 
    • Do not use HKCU to store the value because that won't work: HKCU resolves to completely different registry hives (that might not even be loaded or accessible) for different users.

If it is installscript code you can try reading the service information from the registry in OnUpdateUIBefore & storing it in a global variable, and writing the information back to the registry in OnUpdateUIAfter.

Sample code would be:

RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE);

  if (ServiceExistsService(serviceName) then
        sRegKey = //Registry key to be saved;
        nResult = RegDBSetKeyValueEx(sRegKey,"Credential","ServiceCredential's value");
        if(nResult < 0) then
            MessageBox ("Unable to save service settings:", SEVERE);
        endif;
    endif;

loading can be done using RegDBGetValueEx function

Thanks,

Jenifer

0 Kudos

Thanks@Jenifer for your suggestion.

This could allow us to store/restore credentials somewhere in the registry (then we would have to manage password encryption and security); your example looks like some found on the Internet.

The problem with this is that even if we can manage a user/password with our Installshield setup, we won't be able to start the service with this account. I guess only the windows LSA option can do that. The final goal here is to access a remote network share that could only be reached with a service started with a dedicated service account (managed by windows LSA).

Can you confirm this?

Our current workaround is to not delete the service at product uninstallation; I guess the service account will remain after product uninstallation, then it could work on upgrade. This is not really pretty (ghost service will exists with no binary available; some errors in event logs...) but I do not see any other to keep these LSA credential associated to the service.

Regards,

Christophe

0 Kudos