[MS-DTYP] ACCESS_ALLOWED_CALLBACK_OBJECT_ACE and ACCESS_DENIED_CALLBACK_OBJECT_ACE: why these ACEs does not count during access control processing?

Yury Strozhevsky 116

During my own internal testing I found that any ACEs with types ACCESS_ALLOWED_CALLBACK_OBJECT_ACE and ACCESS_DENIED_CALLBACK_OBJECT_ACE does not count during access control processing. I made different variations of the ACEs: with or without ObjectType GUID, with or without ApplicationData field, with ApplicationData having correct "conditional expression" (as described in [MS-DTYP] 2.4.4.17). In all cases such ACEs had no influence on access checking process. At the same time I was able correctly apply any ACCESS_ALLOWED_OBJECT_ACE and ACCESS_DENIED_OBJECT_ACE. Also I am able to build correct ACEs with types ACCESS_ALLOWED_CALLBACK_ACE and ACCESS_DENIED_CALLBACK_ACE.

So, seems like internally in a callback function like "AuthzAccessCheckCallback" for ACCESS_ALLOWED_CALLBACK_OBJECT_ACE and ACCESS_DENIED_CALLBACK_OBJECT_ACE I got "*pbAceApplicable = FALSE".

Additional details: I am making all the security descriptors using my own library on C++, access checking performed by "AccessCheckByTypeResultListAndAuditAlarmByHandle" function. All was tested on Windows 10 under a process having elevated administrator account (with all related privileges enabled). Plus I tested the same code on fresh installation of Windows Server 2019 having configured ActiveDirectory domain - same result, such ACE types does not count during access control checking.

Yury Strozhevsky 116 Reputation points

2021-05-18T07:52:19.933+00:00

This is a kind of duplicate of this question, but with additional tag related to "OpenSpecs".
Vadims Podāns 9,036 Reputation points MVP

2021-05-18T09:02:31.863+00:00

please add openspecs-windows tag as well and remove windows-10-security and windows-server-security tags.
Yury Strozhevsky 116 Reputation points

2021-05-18T09:50:24.857+00:00

Append a new openspec tag, but do think other two tags are strongly related to my question.
Mike Bowen 1,276 Reputation points Microsoft Employee

2021-05-18T17:05:11.43+00:00

Hi @YuryStrozhevsky-3385 ,

Thank you for your question. One of our engineers will respond soon to assist.

Mike Bowen
Microsoft Open Specifications
Jeff McCashland 476 Reputation points Microsoft Employee

2021-05-18T17:30:12.613+00:00

Hi @YuryStrozhevsky-3385 ,

I will investigate this question, and let you know what I find.

Thanks,
Jeff McCashland
Microsoft Open Specifications
Sunny Qi 10,906 Reputation points Microsoft Vendor

2021-05-24T07:19:57.7+00:00

Hi,

just want to confirm the current situations. Is there any update on this issue?

Best Regards,
Sunny
Jeff McCashland 476 Reputation points Microsoft Employee

2021-05-24T16:36:14.28+00:00

Hi Sunny,

I'm setting up a repro of the issue for debugging. I will let you know what I find.

Thanks,
Jeff McCashland
Microsoft Open Specifications
Yury Strozhevsky 116 Reputation points

2021-05-25T10:46:43.89+00:00

Now you can use my own tests. In particular the special test for this case is here.
Yury Strozhevsky 116 Reputation points

2021-05-31T11:56:38.79+00:00

Hello Jeff!

Anything new on this my question?

Best regards,
Yury Strozhevsky
Jeff McCashland 476 Reputation points Microsoft Employee

2021-06-02T18:56:49.803+00:00

Hi Yury,

I'm reading through code and debugging. I'll let you know as soon as I have more information.

Jeff
Yury Strozhevsky 116 Reputation points

2021-06-18T06:10:58.19+00:00

Hello Jeff,

Anything new from the debugging?

Best regards,
Yury Strozhevsky
Jeff McCashland 476 Reputation points Microsoft Employee

2021-06-18T16:00:09.64+00:00

Hi Yury,

Debugging has not yielded results. I am working with our ACL/ACE experts to diagnose the issue.

Can you tell us more about how you are using the ACEs in question? How is this impacting your project? If you prefer to discuss this offline, you can send email to our dochelp@microsoft.com alias with more information.

Please provide a network trace illustrating the issue, and indicate specific frame numbers. You can send these to our dochelp@microsoft.com alias as well.

Thank you,
Jeff McCashland
Microsoft Open Specifications
Yury Strozhevsky 116 Reputation points

2021-06-19T06:06:26.61+00:00

Hello Jeff,

The issue have no impact on any of my projects. In fact I already gave you a link to my project: https://github.com/YuryStrozhevsky/XSEC. There I made a full set of tests on every kind of ACEs and other specific part of Windows Access Control. So, if the part with ACCESS_ALLOWED_CALLBACK_OBJECT_ACE would not work it would not have any impact on other parts of my project. The issue here (on this Microsoft site) is because there is a problem inside Microsoft code. It is up to you (Microsoft): would you solve it or not. If you would not solve it just let me know. If you would - please provide any estimates on it.

Best regards,
Yury Strozhevsky

Accepted answer

Jeff McCashland 476 Reputation points Microsoft Employee

2021-09-15T23:10:13.78+00:00

Hello Yury,

The ACCESS_*_CALLBACK_OBJECT_ACE is a conditional ACE used by the AuthZ framework for Claims-Based Access Control. The AccessCheckByTypeResultListAndAuditAlarmByHandle API uses the common SeAccessCheck routine, which does not recognize Callback Object ACEs. The AuthZ API AuthZAccessCheck is used to assess conditional ACEs.

[MS-DTYP] accurately describes the ACE, but does not intend to discuss usage. For more information, see [MS-AZOD], and:

Checking Access with Authz API
https://learn.microsoft.com/en-us/windows/win32/secauthz/checking-access-with-authz-api

For this and other API questions, you may get better results by using the windows-api-system-services tag:
https://learn.microsoft.com/en-us/answers/topics/364719/windows-api-system-services.html

Best Regards,
Jeff McCashland
Microsoft Open Specifications
Please sign in to rate this answer.
Jeff McCashland 476 Reputation points Microsoft Employee

2021-09-20T20:49:04.993+00:00

Also, in regards to your comment:
"So, seems like internally in a callback function like "AuthzAccessCheckCallback" for ACCESS_ALLOWED_CALLBACK_OBJECT_ACE and ACCESS_DENIED_CALLBACK_OBJECT_ACE I got "*pbAceApplicable = FALSE"."

The logic of whether to allow the ACE is determined by the application implementing the AuthzAccessCheckCallback function, not Windows.

Best Regards,
Jeff McCashland
Microsoft Open Specifications

Yury Strozhevsky 116 Reputation points

2021-12-04T13:23:19.627+00:00

Hello Jeff,

So, all is fine now, AuthZ functions are working. Almost :)
When I have ACCESS_DENIED_CALLBACK_OBJECT_ACE in my ACL I do have a call to AuthzAccessCheckCallback function.
But when I have ACCESS_ALLOWED_CALLBACK_OBJECT_ACE no calls to AuthzAccessCheckCallback.
Is it as intended to be? But in this link it is clearly stated that such call should exists.

Is it a bug or something?

Thank you in advance,
Yury Strozhevsky

Yury Strozhevsky 116 Reputation points

2021-12-04T13:31:21.437+00:00

Also a "side question": it is possible to run AuthzAccessCheck without AuthzAccessCheckCallback in resource?
I did assume that with AuthzAccessCheck = NULL the AuthzAccessCheck function would be equal with AccessCheckByTypeResultListAndAuditAlarmByHandle function.
But when I make completely same GUID tree with same ACL (just replaced all ACEs like *_OBJECT_ACE to *_CALLBACK_OBJECT_ACE and put there additional simple condition which is always true) I had completely different result.
What is wrong with my assumptions?

Thank you in advance,
Yury Strozhevsky

Jeff McCashland 476 Reputation points Microsoft Employee

2021-12-06T16:48:22.977+00:00

Hi Yury,

These are good questions, but not related to the Open Specifications that these tags support. I suggest starting a new thread using a tag for API questions.

Thanks,
Jeff McCashland
Open Specifications
Sign in to comment

[MS-DTYP] ACCESS_ALLOWED_CALLBACK_OBJECT_ACE and ACCESS_DENIED_CALLBACK_OBJECT_ACE: why these ACEs does not count during access control processing?

0 additional answers