Show Service permissions programmatically - winapi

It is possible to get service permissions via command line:
C:\Users\myname>sc sdshow EventSystem
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCR
RC;;;IU)(A;;CCLCSWLOCRRC;;;SU)
How can I get this value via C++ code and winapi?

From Service Security and Access Rights on MSDN:
To get or set the security descriptor for a service object, use the
QueryServiceObjectSecurity and SetServiceObjectSecurity functions.
For more information, see Modifying the DACL for a Service.
So there's the answer. You call QueryServiceObjectSecurity.

Related

ErrorAccessDenied when try to get/set messagerules API using Microsoft Graph

I tried get/set the outlook rules using messagerules, the Microsoft Graph API call. It's working for my mailbox without any problem. When i tried doing for other user mailboxes it's failing with error
"code: ErrorAccessDenied", "message:Access is denied. Check
credentials and try again".
I set delegated permissions for the app, passed correct credentials, still it's failing. How to investigate and fix this issue? Any guidance would be of help.
For your scenario, you should use application permission instead of delegated permission, as it won't work for you.
Let me explain a bit. Some apps call Microsoft Graph using their own
identity and not on behalf of a user. They can be background services
or daemon apps that run on a server without the presence of a
signed-in user. These apps make use of OAuth 2.0 client credentials
grant flow to authenticate and are configured with application
permissions, which enable such apps to access all mailboxes in a
organization on Exchange Online.
The related documentation/steps available # link (yes, you can test this via POSTMAN too - detailed steps are given in the documentation itself) as well
You tested it out, confirmed the steps working for you!!

How to use an unrestricted service token to restrict a service's access to a file

Sue has a standard user account domain account on Windows 10 Pro. She has an application that can run from the command line or as a service. The service runs with her credentials. Using the SC command the service has been assigned an unrestricted sid (SERVICE_SID_TYPE: UNRESTRICTED). The service name is NT SERVICE\MyService. I want to allow Sue full control of a file when running the program from the command line. I want the service to have Read Attributes and Read Extended Attributes access only.
Using the service account I adjusted the security settings on the file by denying the service all access except for Read Attributes and Read Extended Attributes. I added a second entry that gave it Read Attributes and Read Extended Attributes permission. I've confirmed these are the settings by viewing the Effective Access settings in the Advanced Security Settings dialog box: all of the rows in the Effective Access column contain Xs except for Read Attributes and Read Extended Attributes. They have checkboxes. The rows with Xs have "File Permissions" as their "Access limited by" column.
Still the service is able to change the files permissions. I'm not sure what I'm doing wrong and would appreciate any pointers. I'm open to other approaches to achieving the results I'm after.
The per-service SID was working properly. After reviewing Harry's comments and checking the containing folder permissions I got things working. Thanks a lot Harry.

How to call LogonUser() to get a non-restricted full token inside a Windows Service with UAC enabled?

I am running a WindowsService on Windows Server 2012 and it needs to impersonate a domain admin user (who is also added to the local administrators group on the machine).
UAC is enabled on the system and Calling LogonUser using the credentials with a LogonType of LOGON32_LOGON_INTERACTIVE, seems to return a restricted token instead of a full token.
This is causing the administrative task i'm trying to do to fail.
What is the right way to call LogonUser in this situation so that a full token is returned instead of an restricted token?
PS: I came across a related question here How can I get elevated permissions (UAC) via impersonation under a non-interactive login?
but it does not show the exact calls that need to be made to get the full token.
You can get an unfiltered token from LogonUser() by using the LOGON32_LOGON_BATCH option instead of the LOGON32_LOGON_INTERACTIVE option.
There is some sample code in this answer which shows the use of LOGON32_LOGON_BATCH and the LogonUser() function to obtain an administrative token.
Addendum:
If you have SeTcbPrivilege, you have another option: you can use LOGON32_LOGON_INTERACTIVE when calling LogonUser() and then use the TokenLinkedToken option in GetTokenInformation() to obtain a handle to the elevated token that is linked to the filtered token.
SeTcbPrivilege is also known as "Act as part of the operating system" and is usually only available when you are running in local system context.
If you do not have SeTcbPrivilege, you can still call GetTokenInformation() to fetch a copy of the linked token, but in this case you get an impersonation token at SecurityIdentification level so it is of no use if you are wanting to create a new process. (Credit to RbMm for pointing this out.)

Google API BlackList

our company is developing some services which use Google's ADMIN SDK apis.
Our problem is that when we call the apis endpoints it starts to say "403 insufficient permissions".
If we change the server with another IP then the service works again without any trouble.
Since we need to use the IP where we get "insufficient permissions" is it possibile that this is blackisted? And if so is it possibile
to whitelist them?
We havn't found any answer to this question in the documentation.
Thanks in advance
Antonio
Insufficient permissions does not mean you have been black listed. It means that you are trying to execute a method against the API that you haven't been authenticated for.
You specify what access you need by the scope command in your authentication process. There are a large number of scopes.
Lets say I authenticate my user with
https://www.googleapis.com/auth/admin.directory.group.member.readonly Scope
for only retrieving group member roles and information.
This will only give me read-only access to the group member directory.
What happens if I try and do Users: insert the documentation states that I need the scope of https://www.googleapis.com/auth/admin.directory.user. So if I try and insert a user when I only have read only access I am going to get
403 insufficient permissions

IX509PrivateKey::Create throws access denied when called as "Network Service"

I'm using IX509PrivateKey to create a key for an X.509 cert request (as "NT AUTHORITY\NETWORK SERVICE"), and the Create method is generating an access denied (I'm P/Invoke-ing the dispatch interface from C#, so the HRESULT is getting translated to a .NET exception). Process Monitor also shows an access denied attempt to access the key file (the key file is being created).
Here's the actual code:
IX509PrivateKey privateKey = new CX509PrivateKey() as IX509PrivateKey;
privateKey.Length = request.KeyLength;
privateKey.ExportPolicy = X509PrivateKeyExportFlags.XCN_NCRYPT_ALLOW_EXPORT_FLAG;
privateKey.KeySpec = X509KeySpec.XCN_AT_SIGNATURE;
privateKey.KeyUsage = X509PrivateKeyUsageFlags.XCN_NCRYPT_ALLOW_ALL_USAGES;
privateKey.MachineContext = true;
privateKey.Create();
return privateKey;
If I create a user key set instead (by setting MachineContext to false), I see a "File Not Found" instead of "Access Denied". But ProcMon shows nothing; no attempt to access any key files.
In Process Monitor, I was able to determine that "Network Service" did not have access to the key file, so I used the IX509PrivateKey::SecurityDescriptor property to set it. "Network Service" indeed then had access to the key file, but I still received the access denied from Create, and ProcMon still showed an access denied attempt on the file.
Much TIA for any and all ideas.
The cause of this issue has been determined.
The call to IX509PrivateKey::Create was occurring within a web service. As a result, it was occurring under impersonation of IUSR. We edited ACLs enabling the wrong user. It turned out to be straightforward access denied, only for an obfuscated user account. This condition can be observed in ProcMon. ProcMon's "Detail" column will clearly indicate (you may have to enable "Advanced Output")that the call was under an impersonated user account.
In order to more tightly control the user account under which the call is made, and the CA is accessed, we moved the request out-of-process. The enrollment API calls are now made from their own Windows service, and exposed via WCF (net.tcp) to the web service running in IIS. That would be my recommendation for others. IMO, the risk of having another "moving part" is outweighed by the lack of control of making the calls within IIS.

Resources