I am trying to figure out SIDs configured for an executable and finding hard for one of the scenario.
I have restricted access to 2 user accounts ( u1 , u2 ) using Group policy for Notepad.exe.
and 2 user accounts ( u1 and u2 ) are unable to access notepad.exe as per the policy.
in an enterprise scenario it is always difficult to find permissions assigned for executable. I tried using Sysinternals utility Process explorer / icacls to list the restricted users sid but couldn’t find.
is there a way to find out restricted SIDs through windbg.
Eg:1) open notepad.exe using administrator account
2) get complete memory dump
3) navigate to the notepad.exe threads
4) find the object
5) get the SD
will I be able to find out the SID which is blocked ? ( eg SID of U1 and U2 )
Alan Perlis often referred to the “Turing Tarpit”, in which all things are
possible but nothing is easy.
Yes, you could run a program under an admin account, and dump all of
memory, but
This assumes the information you want is on a page that has not been
paged out
That, in looking at 4GB (or whatever your physical memory is) that
you know where to look for the SID
That the SID is actually retained in memory after the program’s image
has been loaded
And these are just the simple problems!
You would be better served by writing a user app which can access a file
and its ACLs, and run it under an admin account, and print out the
information in useful ways. It would take less time than your proposed
attack, even if all the objections I raised are overcome.
joe
Hello Guru’s
I am trying to figure out SIDs configured for an executable and finding
hard for one of the scenario.
I have restricted access to 2 user accounts ( u1 , u2 ) using Group policy
for Notepad.exe.
and 2 user accounts ( u1 and u2 ) are unable to access notepad.exe as per
the policy.
in an enterprise scenario it is always difficult to find permissions
assigned for executable. I tried using Sysinternals utility Process
explorer / icacls to list the restricted users sid but couldn’t find.
is there a way to find out restricted SIDs through windbg.
Eg:1) open notepad.exe using administrator account
2) get complete memory dump
3) navigate to the notepad.exe threads
4) find the object
5) get the SD
will I be able to find out the SID which is blocked ? ( eg SID of U1 and
U2 )
will windows stores the SIDs of users that are blocked for specific app ? - I find it difficult to view through generic method ( right click notepad.exe –> properties –> security ) about the SIDs which do not have access to specific app.
will windows manage SID history / sid cache for specific application , which can be analyzed ?
will windows stores the SIDs of users that are blocked for specific app ?
I find it difficult to view through generic method ( right click
notepad.exe –> properties –> security ) about the SIDs which do not have
access to specific app.
will windows manage SID history / sid cache for specific application ,
which can be analyzed ?
Remember the phrase “that which is not forbidden is compulsory”? The SIDs
in the ACLs can say who is permitted and who is denied, but anyone not
explicitly mentioned cannot be found. In a domain, users you never heard
of, from machines you do not know exist, may attempt to access a file (for
any purpose). If they are not in the “permitted” list or are in the
“denied” list, they will not be able to access the file. Thereis no way
to explicitly enumerate this set of users. I also don’t know how group
policies are enforced, but if an ACL permits or denies a group, there is
no way to discover who has been denied access, with one exception: if you
turn on security logging, failed attempts to access files will be logged.
You may then examine this log (there are APIs for reading system logs).
Concepts like a SID cache, if they exist at all, are at a level far below
anything you know about. A SID cache would be unlikely, because if there
is any form of caching, there must be a way to make sure the cache has no
stale entries. So I might not be a member of the X group. I try to
access a file only permitted to the X group. The access is denied. This
information is cached. I call up the group manager, and say “I don’t
have access to the file you told me to read!” So I get added to the
group, on the central file server. Every cache in the domain that thought
I was in the to-be-denied set now must be told there is a change.
Analogous problem if I am removed from a group. So I suspect such a cache
does not exist.
keeping the fact that = access check compares the union of the user’s identity and the list of groups the user is a member of against the ACL of interest
how can I find that / any cache/ datastructure which stores these per sid ?
You want a cache of rejected SIDs for a particular object? No such thing.
Instead, put an SACL on the object as well and you will get a Security Event
Log entry for the attempt.
-scott
OSR
wrote in message news:xxxxx@windbg…
keeping the fact that = access check compares the union of the user’s
identity and the list of groups the user is a member of against the ACL of
interest
how can I find that / any cache/ datastructure which stores these per sid ?
A cache of rejected SIDs cannot possibly make sense, since there is no way
to guarantee coherence with reality. Why the OP wants such a cache is not
explainable. Since there is no means to notify all cache-holders of any
change in reality, it creates more problems than it could ever hope to
solve.
joe
You want a cache of rejected SIDs for a particular object? No such thing.
Instead, put an SACL on the object as well and you will get a Security
Event
Log entry for the attempt.
-scott
OSR
wrote in message news:xxxxx@windbg…
keeping the fact that = access check compares the union of the user’s
identity and the list of groups the user is a member of against the ACL of
interest
how can I find that / any cache/ datastructure which stores these per sid
?
After much of reading one the post by Larry oysterman talks about SID and subauthority count
“The ?good stuff? in the SID (the stuff that makes a SID unique) lives in the SubAuthority array in the SID. Each entry in the SubAuthority array is known as a RID (for Relative ID”
this means that the data is getting stored under the subauthority structure, and I was under impression that if I get the complete memory dump , these subauthority structure for a SID can be viewed.
>these subauthority structure for a SID can be viewed.
Sure, given the address of a SID you could dump its structure. The question
is, “where are you getting the address of the SID from?” It’s still not
clear to me what it is you’re trying to do. You originally said:
What object is, “the object” in this case?
-scott
OSR
wrote in message news:xxxxx@windbg…
Hi,
After much of reading one the post by Larry oysterman talks about SID and
subauthority count
“The ?good stuff? in the SID (the stuff that makes a SID unique) lives in
the SubAuthority array in the SID. Each entry in the SubAuthority array is
known as a RID (for Relative ID”
this means that the data is getting stored under the subauthority structure,
and I was under impression that if I get the complete memory dump , these
subauthority structure for a SID can be viewed.
On 5/31/13, Scott Noone wrote: >>these subauthority structure for a SID can be viewed. > > Sure, given the address of a SID you could dump its structure. The question > > is, “where are you getting the address of the SID from?” It’s still not > clear to me what it is you’re trying to do. You originally said: > >
> > What object is, “the object” in this case? > > -scott > OSR > > wrote in message news:xxxxx@windbg… > > Hi, > > After much of reading one the post by Larry oysterman talks about SID and > subauthority count > “The ?good stuff? in the SID (the stuff that makes a SID unique) lives in > the SubAuthority array in the SID. Each entry in the SubAuthority array is > > known as a RID (for Relative ID” > > this means that the data is getting stored under the subauthority structure, > > and I was under impression that if I get the complete memory dump , these > subauthority structure for a SID can be viewed. > > typedef struct _SID { > BYTE Revision; > BYTE SubAuthorityCount; > SID_IDENTIFIER_AUTHORITY IdentifierAuthority; > DWORD SubAuthority[ANYSIZE_ARRAY]; > } SID, *PISID; > > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
User Account Control: Only elevate UIAccess applications that are installed in secure locations
EnableSecureUIAPaths
?\Program Files, including subfolders
?\Windows\system32
?\Program Files (x86), including subfolders for 64-bit versions of Windows
I was bitten by this few weeks back. Spent an entire day only to find this setting messing up. I could not launch any administrative program from any other locations other than the one mentioned above. Debugging from UM-2-KM and back was not an option as it was a production server. But while debugging the administrative program, I could see the “AdjustTokenPrivileges” API failure. When I compared the SID dump against a working one, the only difference was in the token flags field.
Honestly, debugging UM for security failures is becoming a challenge with the advent of UAC, SRP and their derivatives.
Thanks,
Arvind
P.S.
The administrative program could be launched form other volumes like D:
