I want to deploy a C++ application that will run in enterprises where users have low privileges on their machines, so they can't run as admin or do tasks that require admin privileges.
The service I want can be run as Local Service, which is a low privilege account in Windows, so how can I , programmaticaly, let my application which is run with the context of the low privilege user start a Windows service that can be run as Local Service?
Will it require impersonation, and will the low privileged users be able to temporarily impersonate the Local Service account to run the service?
I heard that even if the specific service can be run as Local Service, I would still not be able to start it without admin powers because the Service Control Manager (SCM) would still require admin privileges?
EDIT: I should note that the service is installed by default in Windows (smart card service), I just want to start it.
This is simply not possible; standard users don't have the necessary privileges to do this. By default, only members of the Administrators and Power Users group can start, stop, and pause services.
This is a problem best solved by group policies, rather than by software. Ask about that on Server Fault.
As you'll require administrator privileges to install this service either way, you could install a second auto-start service which has the single purpose of accepting requests from your application to start/stop the real service.
Related
We have a scenario where a secure agent is installed on an ms server environment with a specific Informatica cloud user.
Now we would like to change the user which is being used by the secure agent. What would be the procedure to change username and password to another Informatica cloud user. Are there any precautions to assure like visibility and rights?
I have doubts about your question, but from what I understand you want to change the agent owner, right?
To change the owner of the secure agent
for windows:
Change user agent secure - for windows
for linux:
Change user agent secure - for linux
Or in the last case you can delete the secure agent folder and perform a new installation.
Enabling the Cloud Run API (dev console→Cloud Run→Enable) creates five service accounts. I want to understand their purpose. I need to know if it's my responsibility to configure them for least privileged access.
The Default compute service account has the Editor role. This is the Cloud Run runtime service account. Its purpose is clear, and I know it's my responsibility to configure it for least privileged access.
The App Engine default service account has the Editor role. This matches the description of the Cloud Functions runtime service account. Its purpose is unclear, given the existence of the Cloud Run runtime service account. I don't know if it's my responsibility to configure it for least privileged access.
The Google Container Registry Service Agent (Editor role) and Google Cloud Run Service Agent (Cloud Run Service Agent role) are both Google-managed service accounts "used to access the APIs of Google Cloud Platform services":
I'd like to see Google-managed service accounts configured for least privileged access. I'd also like to be able to filter the Google-managed service accounts in the IAM section of the GCP console. That said, I know I should ignore them.
The unnamed {project-number}{at}cloudbuild.gserviceaccount.com service account has the Cloud Build Service Account role. This service account "can perform builds" but does not appear in the Cloud Run Building Containers docs. It's used for Continuous Deployment—but can't do that without additional user configuration. It's not a Google-managed service account, but it does not appear in the Service Accounts section of the GCP console like the runtime service accounts. Its purpose is unclear. I don't know if it's my responsibility to configure it for least privileged access.
Cloud Run PM:
Yep, exactly right.
We should probably not create this if you're only using Run (and likely not enable the App Engine APIs, which is what created this). During Alpha, this was the runtime service account, and it's likely that it wasn't cleaned up.
I have a feeling it's stuck as Editor because it accesses Cloud Storage, which is oddly broken for "non Editor access" (I'm still trying to track down the exact issue, but it looks like there's a connection to the legacy Editor role that requires it).
Is already "least privileged" from it's perspective, as it only has the permissions to do the things that Run needs to do in order to set up resources on your behalf.
This is the runtime service account equivalent for Cloud Build, and falls into the same category as 1,2. If you need a build to deploy to Cloud Run, you have to grant this account something like Cloud Run Deployer (plus to the additional step of allowing the build service account to act as your runtime service account, to prevent [or at least acknowledge] privilege escalation).
I too want better filtering of "Google created" and "Google managed" and have been talking with the Cloud IAM team about this.
I am planning to use Amazon Workspace, to run a communication software which is restricted in a country where I am about to visit in few days, so what I was thinking is to use amazon workspace, but I was wondering if anyone can guide me if its safe to keep running any communication software with personal credentials on Amazon Workspace?
I have confusion if I run Workspace, will I get the same desktop each time? or if I log out from client it will end the existing desktop, and once I sign in again it will get me a new desktop with everything same as previous one?
Amazon WorkSpaces provisions a virtual server that is always "yours". Just keep it running and connect to it whenever you want to use it. It will continue exactly how you left-off, such as mid-sentence in a word processor.
Clients are available for Windows, Mac, iOS, Android and even via Web Browser so it should be easy to connect.
The only potential problem is if the country has blocked access to the AWS IP address range, which might happen if they want to block people from using VPN services.
I think it is a standard procedure for you to be cautious whenever you are using internet connection away from the trusted connection points. However, it is quite secure to keep running your communication software on AWS Workspaces. Their security protocol is advanced. You should also change your credentials on a regular basis.
You will always get the same desktop anytime you login and so that shouldn't be a problem.
Alternatively, you can checkout V2 Cloud's WorkSpaces they have an enterprise-grade security strategy to protect both your data and credential. They use multi-factor authentication to ensure that even if your credentials are stolen, the theif can't sign into your WOrkPSaces.
About having access to the same desktop, their desktop is very consistent and you will always have access to the same desktop. They will not only host your communication software, they will render to you via your web browser so you don't have to install any client application like in AWS WorkSpaces.
I hope that helps.
For local development (including other team members) should we be using application default credentials for our apps, or service accounts when authenticating and using Google Cloud Platform services?
I was thinking that being able to control the individual user permissions instead of a random service account would be better, as it also prevents us from having to revoke the whole service account key if someone leaves the team. Whereas if we used ADC, it would just work as we'd disable their account and remove its permissions. However, the documentation in the Authentication overview contains this note:
Important: For almost all cases, whether you are developing locally or
in a production application, you should use service accounts, rather
than user accounts or API keys.
What is the correct authentication method to use for local development?
From the same page:
All GCP APIs support service accounts. For most server applications that need to communicate with GCP APIs, we recommend using service accounts, as they are the most widely-supported and flexible way to authenticate.
In this sense, the randomness of the service account is determined only on your way of managing it.
For your scenario, when someone leaves the team, it would indeed be easier to revoke the user account('s permissions), instead of revoking the key, affecting all using it. In my opinion, both ways are correct and the best way would be the one that best suits your context. The documentation pushes for service accounts as it is a Google account, as opposed to a specific user, and it can be used for authentication regardless of where your code runs.
After we created a new project in Google developer console, we see one App Engine service account and one Google APIs service account already there in "Permission" page. But we have no client Ids in credential. Those two accounts seems to be dummy, what are they for?
They are not exactly dummy.
Those are "service" accounts meant to be used if you want an application or utility/tool that is sitting inside/on your app engine VM or compute engine VM, to perform actions that will require authentication ... having service accounts should ideally let you can skip the oauth step which would otherwise require browser access and user intervention ... things that an automated process in a VM should not have to deal with.
I'm guessing they were provisioned automatically with ease of use (? shrug) in mind so folks wouldn't have to go about creating them.
https://cloud.google.com/compute/docs/faq#serviceaccounts
https://cloud.google.com/compute/docs/authentication