question

YuryStrozhevsky avatar image
0 Votes"
YuryStrozhevsky asked JeffMcCashland-5087 commented

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

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.

windows-10-securitywindows-server-securityopenspecs-questionsopenspecs-windows
· 13
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

This is a kind of duplicate of this question, but with additional tag related to "OpenSpecs".


0 Votes 0 ·

please add openspecs-windows tag as well and remove windows-10-security and windows-server-security tags.

0 Votes 0 ·

Append a new openspec tag, but do think other two tags are strongly related to my question.

0 Votes 0 ·

Hi @YuryStrozhevsky-3385 ,

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

Mike Bowen
Microsoft Open Specifications

0 Votes 0 ·

Hi @YuryStrozhevsky-3385 ,

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

Thanks,
Jeff McCashland
Microsoft Open Specifications

0 Votes 0 ·

Hi,

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

Best Regards,
Sunny

0 Votes 0 ·

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

0 Votes 0 ·
Show more comments

1 Answer

JeffMcCashland-5087 avatar image
0 Votes"
JeffMcCashland-5087 answered JeffMcCashland-5087 commented

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://docs.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://docs.microsoft.com/en-us/answers/topics/364719/windows-api-system-services.html

Best Regards,
Jeff McCashland
Microsoft Open Specifications

· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

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

0 Votes 0 ·

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


0 Votes 0 ·

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

0 Votes 0 ·

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

0 Votes 0 ·