I do have a domain where the default ACLs have been altered on all user and computer objects and the List Object Mode (Access Based Enumeration for directory objects) has been enabled. Most notably, the Everyone:Read permission has been removed from the list for most directory objects so users are unable to read "foreign" objects to comply with a privacy protection policy.

In this constellation, an application's client (based on the UniPaas Framework if this matters) is trying to read a specific user's group memberships and fails for an unknown reason. From the software manufacturer we got a simple test case where a net user %USERNAME% /domain is failing with an Error 5 - Access is denied in this infrastructure. The network protocols net use is using and the way how it is failing corresponds to what we are seeing when taking network traces of the application.

I am now somewhat as a loss as I do not know anything about the internals of the net user call (especially what API it is using to read the attributes and which permission the user has to have to get them). How do I start debugging this?

Edit: one thing I came up with was running Wireshark to record the network traffic induced by a net user %username% /domain call. Everything looks good up to the point where a SAMR OpenDomain call is issued for the BUILTIN domain (S-1-5-32) which returns STATUS_ACCESS_DENIED, after which all connections are torn down. See packets 33 and 34 in this pcap trace. This seems to be the reason for the Access denied response from net user, although I have no idea what is going wrong here.

  • To clarify, a given account needs to be able to query the properties of itself? If that is the case, you may want to try adding SELF with the same ACE's that the previous ACE's had. – Greg Askew Aug 30 '13 at 16:07
  • @GregAskew The AD objects already do have the SELF ACE allowing them to access the information. The trouble seems to be that the WinNT provider (or whatever it is net user and the application are using) is not using LDAP queries to retreive group membership information, but something else. And the restrictive permissions (along with access-based enumeration enabled in the directory) seem to break the process for some obscure reason. – the-wabbit Sep 1 '13 at 6:03

It looks like you've somehow managed to prevent enumeration of the builtin groups. That net user call opens connections to two domains as part of it's operation:

  1. To your AD Domain based on the domain SID.
  2. To the BUILTIN domain based on the widely known SID for that (S-1-5-32).

Most of the queries are done to the first connection, one is passed through the second. This pass turns $YOURDOMAIN\Domain Users into the widely known principle of BUILTIN\Domain Users (S-1-5-32-545), which the system knows to treat special. When the connection to the BUILTIN domain is rejected, the whole call fails.

Check the permissions for the Builtin AD container in your domain tree - it should have an "Authenticated Users:Read" ACE. Also the enumeration of the Builtin container should be allowed - an Authenticated Users:Read ACE for the top level of the domain should take care of this too.

  • I was able to find the culprit: the "Builtin" container in the AD seems indeed to be the bit the BUILTIN domain is populated with. It needs to be a) enumearble in the AD and b) all contained objects need to be accessible for the resulution in the second pass to work. – the-wabbit Sep 9 '13 at 13:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.