Hi i am learning to create a windows service i searched a lot and did not get a clear understanding of the Account property in the ServiceProcessInstaller Class can anybody please explain what is the difference between
1.User
2.LocasService etc..
The ServiceAccount Enumeration page on MSDN has a table that describes each account.
It is best practice to use an account with the lowest privileges that is appropriate to the functionality of your service. Normally that means using the LocalService account unless you're doing something that requires the privileges of LocalSystem.
LocalSystem basically has free reign over the machine, whereas LocalService/NetworkService have roughly the same privileges of a standard user account. As you'd expect, running the service in the context of a specific user would provide the service with that user's privileges.
I think the best one is:
LocalService
An account that acts as a non-privileged user on the local computer, and presents anonymous credentials to any remote server.
LocalSystem
An account, used by the service control manager, that has extensive privileges on the local computer and acts as the computer on the network.
NetworkService
An account that provides extensive local privileges, and presents the computer's credentials to any remote server.
User
An account defined by a specific user on the network. Specifying User for the ServiceProcessInstaller.Account member causes the system to prompt for a valid user name and password when the service is installed, unless you set values for both the Username and Password properties of your ServiceProcessInstaller instance.
from: https://msdn.microsoft.com/en-us/library/system.serviceprocess.serviceaccount(v=vs.110).aspx
Related
Applications in GSuite can have domain-wide delegation (DWD) enabled, allowing the application to access user data (and other domain data) without any interaction on the part of the users.
According to a Google Support article, it is implied that the application is limited by the scopes set on the application.
However, reading various responses on Stack Exchange regarding "user impersonation" makes me wonder about the validity of this. See:
Breno's response "The domain-wide delegation model allows a service account to impersonate a user and thus obtain the same privileges in the domain that the user identity + set of scopes granted to the application imply."
Kessy's and Gilfoyle's responses "...This means that the service account only has access to data from the account the application is impersonating...." and "...First and foremost: A service account is technically a superadministrator once DWD ..."
Edited question ("Solution")
There is nothing concrete, but it appears (possibly incorrectly) that once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed. I've trawled through the Google Support documentation, but there is very little about scopes with regards to impersonating users that I could find. I haven't the experience building such an application to know what to look for.
My questions:
(Q) Can applications with DWD enabled do more than the scopes allow by impersonating a superadmin? If not, if one of those scopes includes the authority to change the user password (e.g. https://www.googleapis.com/auth/admin.directory.user), doesn't that mean an application can bootstrap itself and add any other, needed scopes?
Alternatively, are applications with DWD limited by their scopes, even when impersonating a super admin?
I'm not a developer; I'm a system admin with very some light/informal dev experience, so I would be greatly appreciative if you could pitch your answers accordingly.
The privelleges that an impersonated account has are limited in two ways
The impersonation can only perform requests on user's behalf within the range of the scopes authorized in the Admin consoles under Security -> API controls
A certain application can only use the scopes that were given to the service account when creating a credentials object
In other words:
If you enable in the admin console e.g. the scope https://www.googleapis.com/auth/admin.directory.user.readonly for a specific service account, this service account - when impersonated - will only be able to VIEW users, not to perform any request what goes beyond the limits of https://www.googleapis.com/auth/admin.directory.user.readonly
Even if you enable the full https://www.googleapis.com/auth/admin.directory.user scope in the admin console, but when creating the service account credentials object, you pass it only https://www.googleapis.com/auth/admin.directory.user.readonly as a scope - within the frame of the specific application, the service account equally will not be able to perform requests going beyond the scope https://www.googleapis.com/auth/admin.directory.user.readonly
The assumption once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed is confusing.
It would be more correct to say once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed - IF THE RESPECTIVE SCOPES HAVE BEEN ENABLED IN THE ADMIN CONSOLE AND GRANTED TO THE SERVICE ACCOUNT CREDENTIALS OBJECT OF THE SPECIFIC APPLICATION.
As a general rule of thumb, you should avoid providing (both when working with and without service account) to generous scopes, it is better to provide several specific scopes, rather than one broad scope.
I have an API that is hosting on IIS 7.5. The application pool is configured use a domain service account. Then, I grant the account full permission on the default site.
The API and the database are on different server.
I create a SQL Server login for the account and associate it with a user. The user is granted db_onwer to the database. SQL Server service is configured to run using that service account as well. However, The API can't connect to the database. The database log shows this error message "Login failed for user host\servername$. If host\servername$ is given access to the server, it would work fine. However, IT said no way.
Majority of the solutions that I have found online so far either gave permission to host\servername$ to the database or change the apppool to use network or local service, or use a username and password where the username is not a domain account user.
I have to use a domain name account, so I am struggling to find a solution.
There was an issue with the way the domain account was created. IT had to create another service account. Once I set up the app pool with the new server account, I had no issue.
I would like to create a user similar to admin, but with restricted privs. The user would be able to create/read/delete objects under a certain DN in the directory, but not others.
Typically, the native server providing the LDAP service has an ACL model.
Within that system, you can create users with appropriate trustee rights/ACLs.
For example, in eDirectory, you would grant this new user object BCRDI rights to the container of interest, then have your LDAP app authenticate as that user.
In Active Directory you can do the same thing.
In Open LDAP you can do the same thing.
The specific details depend on the server providing the LDAP service. (I like others, hate saying LDAP server, since really they are not LDAP servers. They are offering an LDAP service on top of whatever database they store objects in.)
I am using a WCF call to update my database with any changes from ActiveDirectory.
I call this WCF functin via client browser and the function trys to get details from AD within the servive itself. However the issue is AD needs UserName and Password to get any records.
Please advise how can I overcome this problem so that Windows looged in credentials are automactically accepted and AD is read.
I am using wsHttPBinding,Security: message and clientCredentials="Windows".
Thanks
Vikram
The call to Active Directory is going from the service.
The default settings for the service is impersonate=false and the identity of the application pool is NETWORK SERVICE.
Therefore, the call to AD is going in the security context of Network Service, which does not have the correct access, and cannot be given them, since it is a machine local account.
There are 3 ways to fix this.
Set Authenticate=true in the web.config to allow access to AD to be done in the security context of the calling user.
Change the identity of the application pool to that of a domain user that is allowed to access AD. Be sure to add this user to the local IIS_WPG group.
Store the username and password of a user that is allowed to access AD, in the web.config file, and use these credentials to access AD.
I have a number of services that will be running under the security context of NT Authority\System as a Windows service (the services are NetTCP-based). There are six groups stored in Active Directory that will be allowed to access these services:
Users
Agents
Approvers
Administrators (three levels of admins)
I know I can get the user who is connecting to the service using ServiceSecurityContext.Current.WindowsIdentity.Name.
What I need to do is validate in a business layer that the user context being passed in is able to access the particular service though, and I'd like it to follow an older application my company supports that uses PrincipalPermission passing it a role and using the Demand() method to ensure access.
I guess my initial question is, if I pass PrincipalPermission the ServiceSecurityContext username and the associated role (group), will it automatically know to hit Active Directory behind the scenes since the service is running under the context of an AD account on the same domain? Or is there something special I should do?
Right, when you demand a role, it'll call IPrincipal.IsInRole. This will use whatever implementation the principal has. So, if it's set to Windows, it'll do all the work to hit AD.