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.
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.