locked
LSA authentication group weirdness RRS feed

  • Question

  • Hi,

    I have two problems on Vista RC2 with group settings created by my custom LSA authentication
    package, which both don't occur on XP.

    First, the token created under Vista is missing the "Local" SID, S-1-2-0. Per documentation
    I don't add this group to the TOKEN_GROUPS list returned by LsaApLogonUser. On XP, the
    "Local" group is added by the LSA,. On Vista, it's not. I can add the group in LsaApLogonUser,
    though, and LSA doesn't remove it.
    Is that a bug or a security related feature?

    Second, consider a user logging on, who's member of the local administrators group. The
    group is added to the TOKEN_GROUPS list filled in by LsaApLogonUser. The
    TOKEN_PRIMARY_GROUP SID is also set to the admin group. This doesn't work. LSA returns
    with a status of 0xC000005A, STATUS_INVALID_OWNER to the calling logon application.
    This works fine under XP.
    What's especially weird is that virtually every other group is ok as primary group, not only, say,
    "None" or "Power Users", but even stuff like "Everyone" or "SYSTEM".
    Note that in either case, LsaApLogonUser sets the TOKEN_OWNER value to NULL. But even
    setting it explicitely to the user SID, or to the admin group SID, the call invariably fails with
    STATUS_INVALID_OWNER if the primary group is set to the admin group.
    This behaviour seems rather strange, given the fact that a subsequent

      SetTokenInformation(new_token,TokenPrimaryGroup, [...]);


    works anyway.


    Glad for any help,
    Corinna
    Monday, November 13, 2006 6:58 PM

All replies

  • The local SID seems to have a special treatment based on whether the LsaLogonUser caller specified SIDs to be included or not (i.e. if it does, it'd better include the local SID). Winlogon always specifies such SIDs but I don't know which scenario you are testing this with.

    With regards to the second point, my conjecture is the following:
    After the call to your AP, the LSA will build 2 tokens for administrators, and link them together for UAC purposes.
    When creating the non elevated token, the administrators group is not valid since it doesn't exist in that token...

    Note that the primary group for local users is S-1-5-21-machineGUID-513 for both tokens (based on the output of !token in the debugger).

    Tuesday, November 14, 2006 12:56 AM
  • Hi Eric,

    thanks for your reply.

    > the local SID seems to have a special treatment based on whether the LsaLogonUser caller
    > specified SIDs to be included or not (i.e. if it does, it'd better include the local SID). Winlogon
    > always specifies such SIDs but I don't know which scenario you are testing this with.

    In my case the LocalGroups parameter is NULL.  A group list is only returned by the AP.
    That's an interesting hint, though.  I will change the group handling to use LsaLogonUser's
    LocalGroups parameter and see how this changes things.  I would be curious to learn
    why the local group was automatically added by XP and now it's not, though.

    > With regards to the second point, my conjecture is the following:
    > After the call to your AP, the LSA will build 2 tokens for administrators, and link them together
    > for UAC purposes.  When creating the non elevated token, the administrators group is not valid
    > since it doesn't exist in that token...

    Hmm, I'm not sure about that.  MSDN Lib states in the manual page about
    LSA_TOKEN_INFORMATION_V1, the primary group SID "does not have to correspond with the
    SIDs assigned to the user".  As I understand that, the primary group does not necessarily has
    to correspond to the token's group list, at least not when returned by the LSA.  Keep in mind
    that it's no problem to set the primary group to, say, "Power Users" or even "SYSTEM", no
    matter if the SID is in the group list return by the AP or not.

    There's also the point that the admin group *is* in the non elevated token, even though
    only as "deny only" group.  Maybe that's the problem?  The fact that this very group
    is "deny only"?


    Corinna

    Tuesday, November 14, 2006 3:39 PM
  • Local SID: I believe you'll find that this behavior change with Server 2003.
    The Local SID is now only added implicitly for batch and service logons, and seems to rely on the callers in the interactive case (winlogon and seclogon) otherwise. I do not know the reason for that change.

    PrimaryGroup: I'm a little stunned indeed.
    I have evidence that there are checks for validity of the group, but you should get STATUS_INVALID_PRIMARY_GROUP anyway.
    I'd only expect STATUS_INVALID_OWNER if one is passed in but either isn't one of the SIDs provided, or that SID doesn't have its attribute set with SE_GROUP_OWNER.

    Wednesday, November 15, 2006 4:12 AM
  • As for the local SID, it seems I made some dumb mistake, so never mind.
    I have a working version now, which adds the Local group to the group list
    and which gives equivalent results (with only the platform specific differences)
    on both platforms.

    As for the the primary group issue, yes, I would also expect a
    STATUS_INVALID_PRIMARY_GROUP status.  Since the owner is actually
    set to NULL, the status code is rather puzzeling.


    Corinna
    Thursday, November 16, 2006 5:51 PM