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.
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 am trying to access the IBM Domino Access Services 9.0.1, which is REST based service for accessing all calendar items.
Lets say for getting calendar items for a user , i have to pass credentials of that particular user.
I don't think it is feasible to store the user credentials in the client side and pass the same while accessing those service instead will create one service account in domino server and access the service using the same service account.
Any idea how to configure in the domino side or how can i achieve accessing the calendar service without passing the credentials of the user.
Looking for similar to what we have are having like Exchange impersonation.
Thanks
Anil
It depends on what kind of application you are building. If each Notes calendar owner logs in to your application directly, it is possible to store the user credentials on the client side. Of course, your application would be responsible for securely managing the credentials. On the other hand, your application might require access to each calendar without directly involving the calendar owner. This can be the case for server-side applications.
Your question doesn't specify, so I'll assume yours is the second situation. In that case, you could create a user identity for your application and then add that identity to the Access Control List (ACL) for each mail file. There are two ways to modify the ACL: 1) You can change the design of the master template and let the design propagate to individual mail files, or 2) You can ask each user to delegate access to your application's identity.
The bottom line is the Domino calendar service acts on behalf of the authenticated web user. If that's the calendar owner, the calendar service will have full access to the calendar. If the web user is some other identity, access will be limited to the rights granted in the ACL. For more information about the ACL see this tutorial.
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
We have a WCF (Windows Communication Foundation) client and service application. We're using Windows Authentication with Kerberos.
The issue is that the service may be run under one of many accounts (maybe Network Service, maybe a specific user account -- depends on the IT group). This account is not not likely to change daily, but possibly on occassion (every few months maybe). Additionally, we deliver this client/service package to several groups, and each group may have its own account that they use to run the service on (this is to just let you know that we can't do a custom solution for a single team).
Now the reason the above paragraph is an issue is apparently if the service is not running in the SYSTEM or NETWORK SERVICE account, i.e., a user account, then the client must specify the name of the user account in the identity of its endpoint.
For more on this restriction see: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/feb6bc31-9a4b-4f8d-a887-ef6d2c7abe41
and http://www.vistax64.com/indigo/146204-using-localhost-v-s-environment-machinename.html
Now this seemingly makes it tough to deal with the situation where the IT department changes the account that the service runs on. What is the pattern for handling this, if there is one? How have other people handled this? One solution I've thought of is that the admin sends out an email when the user account of the service has changed, which has a weblink to an application that updates the client or a config file, so the client refers to the new user account. But that seems hackish.
Admittedly, this is a lot like the URI of the endpoint moving. Except, I think there's a lot more expectation on behalf of people that changing the URI is something the client should have to know about, but changing the account the service is running on is something that should be relatively transparent to the client.
BTW, this is required to be hosted on IIS 7.0, if that matters.
I think you can set NegotiateServiceCredential property to True so your binding uses SPNego instead of hard-cold Kerberos. When is set to true, the client does not need to specify the SPN and it can connect to a server running a non-machine account.
Note that since the client no longer requests a specific SPN, it can no longer detect if is connected to a hijacked impersonator of the service, but this is usually a minor concern unless you are really paranoid about security.
Also, as a side rant: the fact that WCF requests as SPN the account name is basically a brain fart. It client should use the DsMakeSpn API to compose the SPN from the service name, host and port. The server should register that SPN for itslef at start up or let an administrator do it using setspn.exe. This is the way they do it by all traditional (well behaved) services in the Kerberos/ActiveDirecotry/Windows environment.
Update
On second though I don't see anything specifying that the client must use the account name as SPN. Looks more like a documentation oversight, instead of documenting the proper way they just recommended what is basically a bad practice. Or maybe just the forum advice is bad, since I did not dig to see what does the MSDN binding spec actually says about the SPN to use...
I don't have a WCF environment handy to test with, but perhaps you can configure the clients to requests a proper SPN like YourService/server:port and you also register the same SPN on the server side. Either manually as an exercise left to the admins, or automatically from your service when it starts up, and unregister it at shut down. The proper way to do it is to let the admins do it, but in reality that is such a pain that most services register the SPN themselves and you can probably follow this practice too. To register an SPN, your service calls DsWriteAccountSpn. The write has to propagate to the AD and be replicated between AD servers, and this at least one reason why having the service auto-register/auto-unregister the SPN is a questionable practice.
If you want to learn more about the wonderfool world of SPNs and how they can wreck your day, you can read up on How Service Publication and Service Principal Names Work.
Update
I'm pretty sure you can use any SPN you like. Most exmaples out there use the account name as 'UPN' (User Principal Name) instead of SPN, but that is just for the convenience of samples as using a true SPN would run into administrative issues setting up the SPN under an user account (again, why admins should do it...). From Overriding the Identity of a Service for Authentication, relevant emphasized:
By default, when a service is
configured to use a Windows
credential, an element that
contains a <userPrincipalName> or
<servicePrincipalName> element is
generated in the WSDL. If the service
is running under the LocalSystem,
LocalService, or NetworkService
account, a service principal name
(SPN) is generated by default in the
form of host/<hostname> because those
accounts have access to the computer's
SPN data. If the service is running
under a different account, Windows
Communication Foundation (WCF)
generates a UPN in the form of
<username>#<domainName>. This occurs
because Kerberos authentication
requires that a UPN or SPN be supplied
to the client to authenticate the
service.
You can also use the Setspn.exe tool
to register an additional SPN with a
service's account in a domain. You can
then use the SPN as the identity of
the service. To download the tool, see
Windows 2000 Resource Kit Tool :
Setspn.exe. For more information about
the tool, see Setspn Overview.
Set NegotiateServiceCredential and EstablishSecurityContext properties to False.
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.