Deny Read on AD Attribute

[Charles F Sullivan]

I am trying to hide the IP Phone attribute on user accounts. I used dsacls against the Domain Users group and confirmed by checking a user object that it does in fact show Deny for that attribute.

So why is it that I can still read the IP Phone number for an affected user? Authenticate Users or other built-in entities might still have the allow ACE, but shouldn't deny override any allow ACEs? Or is this different than deny for NTFS?

The change was applied to the OU where all of the user objects directly live by choosing "descendant user objects", so I don't think it's an inheritance vs. explicit thing, but maybe I'm missing something in that regard.

--

Charlie Sullivan

Principal Windows Systems Administrator

[Micheal Espinola]

This might be terribly out-of-date, but, does the schema still support the "Confidential Bit" ?

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzznYUnB%3D8DbD36WeiK5GZ5EAyvKDCr%2BaFftatyk_uuT0Gg%40mail.gmail.com.

--

Espi

[Michael B. Smith]

It does.

 

I honestly don’t know how to interacts with property set permissions tho.

 

Thanks.

 

Regards,

Michael B. Smith

Managing Consultant

Smith Consulting, LLC

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAAfzEuxZ%3DVNTE6X4vcHAcECdT3QJOG37g6pv0LPkhusLRYyLAQ%40mail.gmail.com.

[Michael B. Smith]

Welcome to the world of “property sets” (sometimes called “property groups”).

 

In attributes which are members of property sets, you must either remove them from the property set or change the permissions for the property set (don’t do it!).

 

This is the “personal information” property set. https://learn.microsoft.com/en-us/windows/win32/adschema/r-personal-information

 

What is the actual goal here? To get it out of the GAL? Modify the GAL.

 

Thanks.

 

Regards,

Michael B. Smith

Managing Consultant

Smith Consulting, LLC

 

--

[Charles F Sullivan]

I hadn't come across the concept of the confidential bit until I was doing the research yesterday. I tried that (in a test env of course), but it turns out to be a base-schema attribute, which you can't use with that solution.

Because some people have chosen to not make their phone number public, we need to keep that attribute hidden from most users. Users here are provisioned by a third party product into AD and another LDAP solution. Another department is responsible, so how the users come into AD is beyond our control.

I am assuming that if I can make the attribute unreadable, then the provisioning system will still be able to write to that field, which is the goal.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/6cf9428a32914477b22a309198a39201%40smithcons.com.

[Michael B. Smith]

I’d still recommend modifying the GAL as a first step.

 

Modifying the property set as a second option.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzzkPpJ9D_v%2BdFcfNFyb238O%2BuuZcTWizMiD-hvWSy_rcjA%40mail.gmail.com.