Implementing custom windows authentication package

2.3k Views Asked by At

I'm building a custom authentication subpackage for MSV1_0 for Windows 7. I've used the msvsubauth sample in from the Windows SDK and I have 2 questions regarding some problems I'm facing with that:

  1. When I'm trying just to make sure that the routine get's invoked and set the Auth0 property in the registry to my package and add a simple code at the end of the Msv1_0SubAuthenticationRoutine that creates a file:

    //
    // Cleanup up before returning.
    //
    
    
    Cleanup:
    hTestFile = CreateFile(
                  TEXT("C:\\lsa\\lsa.txt"), 
                  GENERIC_READ|GENERIC_WRITE, 0, 
                  NULL, CREATE_ALWAYS, 
                  FILE_ATTRIBUTE_NORMAL, NULL);
    
    
    if(hTestFile != INVALID_HANDLE_VALUE) {
          CloseHandle(hTestFile);
    }
    
    
    return Status;
    
    
    }  // Msv1_0SubAuthenticationRoutine
    

    Apparently the package gets invoked because when I enter my password I get an error message from windows "the parameter is incorrect" which is a good sign. But why I'm getting that error? when the exactly same code is executed from a separate .exe file it runs perfectly and creates the test text file. I've checked the permissions and set "full control" for "everyone". Any ideas? the SDK doesn't exactly mention what kind of isolation LSA is creating for code within auth packages.

  2. The second problem is testing the AP. Currently with every change I rebuild the library, copy it to a test VM and then to the System32 folder and reboot it. Is there an easier way to do that?

Thank in advance!

2

There are 2 best solutions below

0
On BEST ANSWER

Debugging in Winlogon and LSASS makes for the most time consuming debugging.

To ease your debugging, you could write a proxy AP that exports the same functions. When loaded, you proxy_ap would

  1. Copy the real AP from a known location to a temp locationand.
  2. LoadLibrary that DLL, GetProcAddress of everything, and forward any calls it receives to that newly loaded DLL.
  3. Watch for changes in the directory where the original AP was copied from
  4. When a change occurs (and if your AP changed) FreeLibrary and goto step 2

But you need to keep a tight grip on what happens on your development target, because handling the dll switch while dealing with requests comming from many threads can become a worse nightmare that what you are trying to solve.

LogonUI.exe starts a new instance every time, but LSASS.exe is long lived.

+Have a look at CVSNT source code (http://cvsnt.sourcearchive.com/). They have a pretty nice AP that implements su. Run the sample in the local system account with psexec -s (from Microsoft/SysInternals pstools suite)

0
On

Perhaps your problem is Everyone only includes Authenticated users? This is just a guess.

I suggest you use Process Monitor to monitor for Access Denied messages or for your path. It is fantastic for debugging permission/path problems of all kinds.

If you experience the issue at the "Unlock Workstation" or "change Password" screens, and it doesn't prevent you logging in, this should be easy to do - set it running, reproduce the problem, log back in and hey presto.

Otherwise you might have to resort to tricks like executing that code path only for certain user accounts, on the Nth try, etc.