LookupAccountSid Function

I have the sid of the owner of a file, and I am using it to call LookupAccountSid ( http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx ) so that it returns the name of the owner + the domain.

When I do this, I often get the owner as "Administrators",
while ReferencedDomainName returns "BUILTIN".

In the referencedDomainName section in the MS documentation regarding the function (in the link above) it says:
"Some accounts are predefined by the system. The domain name returned for these accounts is BUILTIN."

Although I would like to distinguish between files that are owned by administrators on different domains.

Is there a way to get:
local machine name or sever name\Administrators?

Actually after trying to ascertain the owner of files from a foreign XP domain (unknown to the computer on which it is executed), it seems that the LookupAccountSid Function fails reporting:
error code 1332 "No mapping between account names and security Ids was done."
meaning that unless there is a way for the function to resolve the sid to the foreign domain associated with the file it cannot provide a return value.

By contrast when the file is owned by an administrator from a foreign windows seven domain, LookupAccountSid returns "Administrators" and a ReferencedDomainName of "BUILTIN", even though it could not resolve the domain name, which is quite surprising.

My main problem is that this function returns "Administrators" and a ReferencedDomainName of "BUILTIN", sometimes even for unknown domains.
Is there a way to force LookupAccountSid to try to resolve the domain name instead of reporting a built in account, or should I be looking at another function?

BUILTIN\Administrators is a local group of administrators. When you obtain the domain BUILTIN, this indicates that the domain is the local machine itself.

In case the machine is a member of some domain, the domain administrators are automatically included into local Administrators group during machine registration, and this way the file resources appear accessible to both local and domain admin accounts via the same BUILTIN\Administrators.

Igor Vartanov, thank you for your detailed reply and good information regarding the built in account.
Although I still have a problem...

When LookupAccountSid is called it:
"The LookupAccountSid function attempts to find a name for the specified SID by first checking a list of well-known SIDs. If the supplied SID does not correspond to a well-known SID, the function checks built-in and administratively defined local accounts. Next, the function checks the primary domain."

The problem is that it is finding the built in account before doing a lookup on the primary domain, where as I need to check the primary domain first.
Is there another function that just allows me to lookup the file owner's sid on the domain (i.e a specialised domain lookup function)?

Sorry, I believe you don't get the situation completely. In case the SID you look for is BUILTIN\Administrators well known SID, there's no such in domain. Thus, you never could find it there.

Hi again Igor Vartanov, thank you for your answer, and I think I understand the problem a bit better now. I started with the sid:

A sid starts with S to indiate the string is a sid then
+ The revision level (the version of the SID specification) - usually 1
+ The identifier authority value:
0 - Null Authority
1 - World Authority
2 - Local Authority
3 - Creator Authority
4 - Non-unique Authority
5 - NT Authority
9 - Resource Manager Authority
+ Domain or local computer identifier e.g 21-3623811015-3361044348-30300820
+ Relative ID (RID). Any group or user that is not created by default will have a Relative ID of 1000 or greater.

In the case of the administrators built in account:
SID: S-1-5-32-544
Name: Administrators
Description: A built-in group. After the initial installation of the operating system,
the only member of the group is the Administrator account.
When a computer joins a domain, the Domain Admins group is added to the Administrators group.
When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.

I think this means the domain will always be 32-544 for files owned by the the built in administrators account.
As my code did not include the sid string for me to look at, I used the pointer returned from the GetSecurityDescriptorOwner function to display the sid string via the ConvertSidToStringSid function, and then I could see the sid string was indeed S-1-5-32-544 when the owner was "Administrators" domain "Builtin".

I think this confirms all of your previous comments, there does not seem to be a way to get the domain from the owner sid when it is set to S-1-5-32-544.

The problem I have is how to distinguish between a file owned by a built in administrators account on one machine from a file owned by a built in administrators account on another machine as they both return an file owner sid of S-1-5-32-544?

Okay, let's try it again. BUILTIN domain means the local system itself is the domain (already said that above). So all you need is to substitute BUILTIN with the computer name.

Hi Igor Vartanov, thanks again for your reply. The problem I have is this:
1. I format a usb drive with NTFS, and then create a text file on it and manually set its owner to administrators (via the properties -> security -> advanced -> owner menu)
2. Transfer this usb it to another machine (unrelated in any way + not on the same domain)
3. Now check the owner of the text file to confirm it is still "Administrators" "BuiltIn" (sid is S-1-5-32-544).
4. Even though this text file's sid is S-1-5-32-544, Windows won't let me save changes to it while the usb is in the second machine (only when the usb is in the first machine where the file was created), meaning that internally Windows does know that the file is owned by the first machine and not the second. This means I cannot substitute BUILTIN with the local computer name.
So how do I get access to the information stored in the file which tells windows which domain the S-1-5-32-544 sid is linked to?

Owner of the secured object is able to change security settings on the object. But this does not imply the owner is automatically able to access the object. The access is controlled by object's ACL you say nothing about. :)

Ok, I checked the permissions on the text file when it is in the second machine:
From the text file's properties menu I selected the security tab and then left clicked on "Administrators" in the group or user names section.
The permissions listed included: Full control, Modify and Write.

Then I clicked on the Advanced button and Windows reports:
Allow Administrators Full control

Next I clicked the Owner tab and it says the owner is:
Administrators

Finally I audited the file and then checked the audit log which reports:
Read Control Granted
WriteEA:Not Granted
Read attributed granted by ACE on parent folder.

Even though Windows says that the owner of the text file is Administrators, and that the Administrators have full control of this file, I still cannot modify the file while it is in the second machine, I can only edit the textfile when I move the usb back to the first machine. To me it seems that Windows can tell that the textfile is owned by the first machine not the second.

And to me it does snot. You say the text file on a usb ntfs drive can be edited on one machine while cannot be on another one. Sorry, this contradicts to my everyday experience. :)

Did you try opposite? Create the file in the second machine and read it in the first one?

The first machine is XP, the second machine is windows seven, I have tested this extensively and can confirm my findings are not snot.

I then formatted the usb with NTFS on windows seven ultimate and created a single text file, and the error became apparent.
If the Administrators group is given full control over the text file, and all other permissions are removed (including the inheritable permissions from parent object), access to the text file is denied by windows seven.
To confirm this is a Windows Seven problem, move the usb to a windows XP machine and the text file can be edited again.

Thus in my examination of windows seven, it does not allow access to a text file where the only permissions are for the administrators group.

I "test" the file access issues for decades (since NT4 :)), though I cannot call that "extensive". I've just tested this particular case once again, with USB HDD (sorry, no flash device reachable at the moment). I do not confirm what you described before. The plain text file New Text Document.txt, created in the root folder of NTFS volume in Win XP Pro SP3 Eng, owned by BUILTIN\Administrators and having full access for Administrators gets opened fairly fine in Win 7 Pro Russian (UAC: disabled, antivirus: MSE, enabled) and remains modifiable alright. In both systems the logged in user is a member of Administrators group.