Questions[credentials](server)

Setup: I have an application that I currently deploy manually on a server. It requires several credentials (client secrets of external services, tokens, and AES keys and IVs etc.) that I currently have stored in a file encrypted with gpg. Whenever I restart the application I unlock the gpg-key in the console and the service will then decrypt the file again from within the application script (as gpg-agent persists the passphrase in memory for a limited time) and parse them through a pipe.

The advantage of this method is that neither the credentials nor the gpg-passphrase needed to access them are NEVER persisted to disk and only kept in memory. So even with full root access it is impossible to recover the credentials. The only chance is to gain access during the short time-window during which the gpg-key stays unlocked.

The disadvantages are that (a) no other user can start the service (unless we share my account) and (b) the application cannot be started by any automated means.

There is the creds project on github that is similar to what I'm doing, but which still shares the above shortcomings. It may be possible to encrypt the file with multiple gpg keys and then attempt to decrypt it with all keys until one succeeds.

Question: What are better ways to handle the credentials that is (a) accessible by multiple users without key or account sharing, (b) accessible by a CI/CD system (where I do not have a console every time a deployment happens), and (c) only keeps password data in memory? The "workaround" with multiple gpg keys looks like a complex hack and doesn't work with CI/CD systems.

I have a credential provider that does not act the way I want it to. It provides secondary authentication, but it's scope is for all interactive Windows logins host-wide, not for a specific user.

In addition to the credential provider, a credential provider filter is installed. The credential provider filter restricts the use of credential providers on the login screen to just this credential provider. However, if the credential provider filter is removed (via deletion of the key below HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters), then a user can change the credential provider to any other available credential provider (including our good old friend PasswordProvider).

My intention is to enforce the use of credential provider for certain users. For instance, it's fine if this user attempts to login with another credential provider, but I'd like AD to reject this request... only allowing requests if they are called from the correct credential provider.

Is this possible? I'm hoping there is a way to configure a user object in AD to restrict the acceptable credential providers.

Thanks

At our office, all of our Windows 7 Clients get this error message when we try and RDP to a remote Windows 2008 Server outside of the office:

Your system administrator does not allow the user of saved credentials to log on to the remote computer XXX because its identity is not fully verified. Please enter new credentials

A quick google search leads to some posts they all suggest I edit group policy, etc.

I'm under the impression, that the common fix for this, is to follow those instructions on every Windows 7 machine.

Is there any way that I can do something via the Active Directory which could update all Windows 7 clients in the office LAN?

This article describes the (relatively laborious) steps you should go through to grant an Active Directory user the Log On As A Service right. However, if I install a service and manually specify my AD account's logon credentials (service properties | Log On), Windows tells me that 'The account [myaccount] has been granted the Log On As A Service right.' I can then run the service under my account credentials. However, on a subsequent reinstall of the service (or sometimes on reboot), the service is once again unable to start because of a login failure... until I go in and manually enter my credentials again, and the account is magically 'granted the Log On As A Service right.' After this, the service can once again start under my account's credentials.

What's going on here? Why do I apparently have the permission to grant this right to myself on-the-fly? If I can grant it on-the-fly, why doesn't it stay granted and I have to keep re-granting it? Bear in mind I'm not asking how to grant someone this right through Active Directory - I'm talking about the fact that this right appears to be 'auto-granted' by Windows upon your entering your credentials in the Log On window.

Is there a way to pass the username and password from a file instead of the command line via --user and --password?

Background: I want to run wget via cron and don't want the username/password show up in process view