Deny Read on Attribute but Users Still Can View

Question

I need to hide the ipPhone attribute from all users (ideally a few privileged accounts would be able to see it). As it turns out ipPhone is a base-schema attribute so I can't use the Confidentiality Bit solution and we can't switch to a custom attribute; it needs to be ipPhone for a particular app.

So onto the OU which directly contains all of our user accounts I set the following:
Deny - Domain Users - Descendant Users - Read - ipPhone

I am not understanding why a user can still view another user's IP Phone number.

As I was writing this I decided to do the same against a user-created group, but it has the same effect: A user from that group can still read the IP Phone attribute.

Answer 1

Changing the display order would explain the order in the screenshot.

You are correct this doesn't change the order in which they are applied. The permissions in the ACL are ordered based on the following rule:

Explicit Deny  
Explicit Allow  
Inherited Deny  
Inherited Allow  

The inherited permissions are also sorted based DN path, with the closest OU first, then the next OU and so on. The permissions at the top of the list take precedence over the lower permissions. You can think of it as the permissions are applied from the bottom up.

The dsacls command is correct and will assign a deny permission to the user object. I would reconsider the use of the Domain User group, as this will block all users including Domain Admins from reading the attribute, unless you change the default PrimaryGroupID for users that you want to read the attribute.

With your command the following permission will be applied, I've used the Deny-Enum group here:

When you look at the permissions that are applied to the a user account in the OU, the user has these permissions:

The deny permissions is shown as inherited as expected.

To understand why the deny permissions is not being applied, first we need to look the ipphone attribute and how the user is getting the permissions to read this attribute in the first place.

The ipPhone attribute is a member of a Property Set called Personal Information which includes a lot of attributes:

Looking at the permissions of the user the Authenticated Users has been granted read rights to the Personal Information Property set. As this permissions is an explicit permission which will take precedence over the inherited deny permission from the OU.

This Authenticated Users right is grant by the default security descriptor from the User Object in the schema.

You could edit the default Security Descriptor but this could cause other issues down the track with other applications relying on this permissions.

Other option is to remove the ipPhone attribute from the Personal Information Property Set, however, like changing the default security descriptor it could cause issues later.

If you want to remove the ipPhone atttribute from the Personal Information Property Set, you just need to clear the AttributeSecurityGUID attribute from the Phone-Ip-Primary schema object.

This does work however, there is a sneaky permission that will still provide access the attribute via the Pre-Windows 2000 Compatible Access permissions, removing this does cause a lot of the attribute to inaccessible, so may cause other problems as well.

Probably best to get MS to provide their advice on how to deny access with the minimal downstream impacts. The simplest option might be to assign an explicit deny permission to the default security descriptor of the user object in the schema, but does mean this will only be applied to new user objects and you will have to apply this permission to all the existing user objects.

Gary.

Answer 2

Hi @Charles Sullivan

I think I can see in your screenshot that there is an allow permission above your deny, are you able to share the complete list of permissions that have been assigned above the deny, as these are likely to be the reason why the users still have access.

Gary

Answer 3

Sorry, looks like you replied 3 days ago but I got no notification until a short while ago for your latest reply.

There is only one entry for Domain Users, which is the one that is visible. The partially viewable one is for Domain Admins. In any case I would expect Deny to always override Allow within an ACL. If I check a user object in the respective OU, the user object does in fact show the Deny for the ipPhone attribute;

Keeping that in mind: I discovered today that if I apply the Deny directly to a user object, as opposed to relying on the inheritance, it successfully hides the ipPhone attribute. Unfortunately, that is not a solution.

I have a case open with MS, but after spending well over an hour working with the tech, we seem to be no closer to a solution. He collected some logs so maybe he'll come back with something helpful.

Answer 4

Hi

Based on the screenshot the deny permission is after the allow, as you mentioned, this should only be the case if the deny is inherited, but based on the screenshot this is not case. I would make the assumption that the util that set the permission hasn't honoured the normal permissions rules and set the deny at the end of the ACL, instead of at the top.

Gary.

Answer 5

You mention the order of ACEs, as when you say "at the top". I changed the view order to be alphabetical, but that doesn't change how they are applied. Still, can you clarify what you are saying about the order of the ACEs?

Here is the dsacls syntax that I used:
dsacls.exe "<DN_of_OU_containing_users>" /I:S /D "<domain_name>\Domain Users:RP;ipPhone;user"

It doesn't seem as though any other syntax would be appropriate for what I am trying to do.