NPLogonNotify always called under account LocalSystem??? RRS feed

  • Question

  • On MSDN's pages for "Credential Manager" and "Credential Management API", it clearly states, "The credential management functions are always called in the system context (LocalSystem) rather than the user context." The credential management functions to which it refers are NPLogonNotify and NPPasswordChangeNotify.


    Yet, I have a case whereby, *** at least under Vista ***, function NPLogonNotify is called in [Terminal-Services] session 1, whose context, of course, is that of a user, not LocalSystem!!! In this case, my credential-manager DLL, through which said function is exposed, is loaded by mpnotify.exe.


    To be fair...


    1) I do know that there have been cases, under Vista, whereby said function is called in session 0, under context LocalSystem. As that was in accordance with the documentation cited above, I did not record the circumstances of these cases; what's more, they happened some time ago -- at least a couple of months. The documentation cited above, however, says that those functions are ALWAYS called under context LocalSystem -- not true, as I have seen, and about which I'm complaining here.


    2) I cannot speak about this falsity under XP (or 2000, for that matter), as it has not been convenient for me to do test. Furthermore, I'm interested in these O.S.', but less so than in Vista.


    So, what's the story? What is the rhyme and/or reason for choice of session and context, regarding the calling of this function and the other credential-management function -- NPPasswordChangeNotify? Under what circumstances are these functions called under context LocalSystem (session 0)? Under which are they called under a user-context?


    Thanks, in advance, for any help.

    Wednesday, November 5, 2008 9:17 PM

All replies

  • Erik,

    It seems that you are confusing Windows Sessions and Accounts. On Vista
    NPLogonNotify and NPPasswordChangeNotify are called under "Local System" account (SID is "S-1-5-18").

    Wednesday, December 3, 2008 4:13 PM
  • Indeed.

    MPNotify.exe is always running as LocalSystem, and always runs in the session in which the user logged on (local or remote desktop). That's true for XP and Vista.

    And since no users ever logon in session 0 on Vista, MPNotify.exe should never run in that session on that OS...





    Friday, December 5, 2008 11:24 PM
  • Maybe Sergey was right -- that I am confusing context with session.


    I presumed that, in Vista, due to Session 0 Isolation, just as no user-spawned processes ran within session 0, no LocalSystem-processes ran *outside* of session 0.  According to you, that assumption is incorrect.  For my sake, I hope so...


    I will test it shortly, and then report back...






    Wednesday, December 10, 2008 10:20 PM
  • I'm authoritative on this one.
    MpNotify.exe is actually an optional case of LocalSYSTEM process running "outside" of session 0.
    At any time, you have at least winlogon.exe and csrss.exe running in the user's TS session.
    When on the secure desktop, you also have logonui.exe.
    On that same desktop, accessibility applications also run within the session.
    Any process that need to interact with NTUser object have to run within the session in question...
    The desktop is a security boundary so this is OK.

    By the way, none of these processes are services. There system processes.
    Services indeed always run in session 0.

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Sunday, December 14, 2008 12:58 AM
  • Sorry for the long delay in my response...

    You are right!!!

    MpNotify.exe is called within Session 1 and under account LocalSystem.  So, too, then, is NPLogonNotify!

    I'm very pleased to hear this, as my entire design has not crumbled!

    Much thanks to you two guys, Sergey and Eric!
    Erik S.
    Tuesday, March 17, 2009 5:26 PM