locked
SID for "Users" group RRS feed

  • Question

  • Hello,

    This sample code I found creates a SID for the {ComputerName}\Administrators group (along with other supporting code I haven't included):

        // Create a SID for the BUILTIN\Administrators group.
        if(! AllocateAndInitializeSid(&SIDAuthNT, 2,
                         SECURITY_BUILTIN_DOMAIN_RID,
                         DOMAIN_ALIAS_RID_ADMINS,
                         0, 0, 0, 0, 0, 0,
                         &pAdminSID)) 
        {
            ...
        }

    If I create a directory using the above SID the security tab in its properties has an entry for "{ComputerName}\Administrators". All well and good. Now I want a SID for the {ComputerName}\Users group. I've been experimenting with DOMAIN_ALIAS_RID_USERS (by itself or with a second parameter, as above), but after creation the security tab always gives it in literal form (such as "S-1-1-32-545") rather than "{ComputerName}\Users". There is a users group and it has one limited user as a member. What is the correct way to create the SID, and where is this documented? I've been searching for two days. I am doing this on Windows XP, but I'm guessing I'd have similar trouble on Windows 8.

    Wednesday, May 28, 2014 5:26 AM

Answers

  • The correct SID for BUILTIN\Users is S-1-5-32-545, not S-1-1-32-545. It seems your SIDAuthNT variable incorrectly contains SECURITY_WORLD_SID_AUTHORITY rather than SECURITY_NT_AUTHORITY.

    Unless you still need to support Windows 2000, you can also use CreateWellKnownSid(WinBuiltinUsersSid, …), which is easier to get correct.

    • Marked as answer by solar1914 Thursday, June 5, 2014 10:15 PM
    • Unmarked as answer by solar1914 Tuesday, June 17, 2014 1:38 AM
    • Marked as answer by solar1914 Tuesday, June 17, 2014 1:39 AM
    Wednesday, May 28, 2014 7:12 PM
  • To grant administrators full access to a file, the file itself must have a suitable access control entry. Set an inheritable ACE in the parent directory so the file will inherit it from there unless the application provides a DACL.

    It seems you'll need three ACEs in the DACL of the directory:

    • Grant FILE_ALL_ACCESS or GENERIC_ALL to Administrators, with SUB_CONTAINERS_AND_OBJECTS_INHERIT. This gives administrators full access to the directory and is inherited by the files (and subdirectories) created in it.
    • Grant FILE_ADD_FILE to Users, with NO_INHERITANCE. This lets users add files to the directory but does not affect the DACLs of the files.
    • Grant FILE_WRITE_DATA | FILE_READ_DATA | FILE_APPEND_DATA to Users, with SUB_OBJECTS_ONLY_INHERIT and INHERIT_ONLY. This does not let users do anything with the directory itself (because of INHERIT_ONLY) but is inherited by the files created in it.

    According to File Access Rights Constants, both FILE_WRITE_DATA and FILE_ADD_FILE are defined as 2. The meaning of the bit depends on whether the ACE applies to a file or to a directory. Computing FILE_ADD_FILE | FILE_WRITE_DATA looks rather suspicious then.

    • Marked as answer by solar1914 Thursday, June 5, 2014 10:15 PM
    • Unmarked as answer by solar1914 Tuesday, June 17, 2014 1:38 AM
    • Marked as answer by solar1914 Tuesday, June 17, 2014 1:39 AM
    • Unmarked as answer by solar1914 Tuesday, June 17, 2014 5:14 AM
    • Marked as answer by solar1914 Thursday, June 19, 2014 4:01 AM
    Friday, May 30, 2014 11:05 AM

All replies

  • The correct SID for BUILTIN\Users is S-1-5-32-545, not S-1-1-32-545. It seems your SIDAuthNT variable incorrectly contains SECURITY_WORLD_SID_AUTHORITY rather than SECURITY_NT_AUTHORITY.

    Unless you still need to support Windows 2000, you can also use CreateWellKnownSid(WinBuiltinUsersSid, …), which is easier to get correct.

    • Marked as answer by solar1914 Thursday, June 5, 2014 10:15 PM
    • Unmarked as answer by solar1914 Tuesday, June 17, 2014 1:38 AM
    • Marked as answer by solar1914 Tuesday, June 17, 2014 1:39 AM
    Wednesday, May 28, 2014 7:12 PM
  • Thanks, you are correct and now it works. The code was originally for Administrators and Everyone and I tried to convert the Everyone part to Users and I missed that difference.

    However, I have a new problem. I've created the directory with FILE_ALL_ACCESS for Administrators and FILE_ADD_FILE | FILE_WRITE_DATA | FILE_READ_DATA | FILE_APPEND_DATA for Users (so they can write/read files in the directory but not list the directory contents). I have specified NO_INHERITANCE in both cases. But if I log in as a limited user and create a file (from C:\ in a command prompt, echo abc >DirName\test.txt) an administrator account is unable to read it. I need Administrators to have full access to files created by the limited user.


    • Edited by solar1914 Thursday, May 29, 2014 5:22 AM
    Thursday, May 29, 2014 5:18 AM
  • To grant administrators full access to a file, the file itself must have a suitable access control entry. Set an inheritable ACE in the parent directory so the file will inherit it from there unless the application provides a DACL.

    It seems you'll need three ACEs in the DACL of the directory:

    • Grant FILE_ALL_ACCESS or GENERIC_ALL to Administrators, with SUB_CONTAINERS_AND_OBJECTS_INHERIT. This gives administrators full access to the directory and is inherited by the files (and subdirectories) created in it.
    • Grant FILE_ADD_FILE to Users, with NO_INHERITANCE. This lets users add files to the directory but does not affect the DACLs of the files.
    • Grant FILE_WRITE_DATA | FILE_READ_DATA | FILE_APPEND_DATA to Users, with SUB_OBJECTS_ONLY_INHERIT and INHERIT_ONLY. This does not let users do anything with the directory itself (because of INHERIT_ONLY) but is inherited by the files created in it.

    According to File Access Rights Constants, both FILE_WRITE_DATA and FILE_ADD_FILE are defined as 2. The meaning of the bit depends on whether the ACE applies to a file or to a directory. Computing FILE_ADD_FILE | FILE_WRITE_DATA looks rather suspicious then.

    • Marked as answer by solar1914 Thursday, June 5, 2014 10:15 PM
    • Unmarked as answer by solar1914 Tuesday, June 17, 2014 1:38 AM
    • Marked as answer by solar1914 Tuesday, June 17, 2014 1:39 AM
    • Unmarked as answer by solar1914 Tuesday, June 17, 2014 5:14 AM
    • Marked as answer by solar1914 Thursday, June 19, 2014 4:01 AM
    Friday, May 30, 2014 11:05 AM
  • Sorry for taking so long to respond. I was diverted to something else for a while.

    You are correct that FILE_ADD_FILE | FILE_WRITE_DATA doesn't make sense. I should have realized that, particularly as I had noted exactly that issue with those two values in my thread on log-file location earlier.

    I have used the ACEs you suggested and the administrator file access is working now. The only thing that doesn't work is that from a user account I can't append to a file I created with 'echo' from a command prompt (using echo again with '>>'). Appending with echo does work if I change the ACE to FILE_ALL_ACCESS, so I don't know what echo is trying to do that's being denied with the more restrictive rights (after some experimenting I haven't stumbled across the bits that make the difference yet). But that is a minor problem that will probably disappear for file access within the application. The main problem is now solved. so thanks very much for your help.

    • Edited by solar1914 Thursday, June 5, 2014 1:21 AM
    Thursday, June 5, 2014 1:20 AM