Re: INTERACTIVE group missing after SSPI auth

From: Richard Ward (richardw_at_delete-yellow-dogs.com)
Date: 11/20/05

  • Next message: Danny: "GINA and Minidumps" 
    Date: Sun, 20 Nov 2005 00:08:32 -0800

    You can make the argument that the logon types should have
    been exposed at the SSPI layer as well, but the number of
    apps doing netowrk style auth using SSPI dwarf the number
    channeling some interactive access like telnet. Regardless,
    most everything in system32 should be readable:

    C:\WINDOWS\system32>cacls ntdll.dll
    C:\WINDOWS\system32\ntdll.dll BUILTIN\Users:R
                                  BUILTIN\Power Users:R
                                  BUILTIN\Administrators:F
                                  NT AUTHORITY\SYSTEM:F

    C:\WINDOWS\system32>net localgroup users
    Alias name users
    Comment Users are prevented from making accidental or intentional
    system-
    wide changes. Thus, Users can run certified applications, but not most
    legacy a
    pplications

    Members

    -------------------------------------------------------------------------------
    HOME\Domain Users
    NT AUTHORITY\Authenticated Users
    NT AUTHORITY\INTERACTIVE

    Unless you have mucked with the local groups or ACLs in some way, every
    principal that is authenticated to the system should have read access in
    system32.

    "Sami J. Lehtinen" <sjl@newsgroups.nospam> wrote in message
    news:OhyxrA26FHA.3976@TK2MSFTNGP15.phx.gbl...
    > Richard Ward wrote:
    >> This is not an issue with SSPI. SSPI authentication always
    >> results in a network-auth token, and thus will not have
    >> INTERACTIVE group.
    >
    > So, there is no way to get that INTERACTIVE group to the token?
    >
    > I don't understand why SSPI network-auth should be fundamentally
    > different: when I use LsaLogonUser() and specify a "Network" logon type, I
    > get an impersonation token. After I use DuplicateTokenEx() to make a
    > primary token out of that (for process execution), the duplicated token
    > works fine. Same thing is done to the token that results from SSPI auth.
    >
    >> ACLs are more restrictive on server 2003. Ordinary users
    >> should be able to read anything in %SystemRoot%\system32,
    >> but there is no reason for them to be writing anything there.
    >
    > The issue is not writing to, but executing binaries from System32.
    >
    > --
    > sjl@ssh.com

  • Next message: Danny: "GINA and Minidumps"