LSALogonUser und Authentifikation (nichts komplexes!)

[Dezipaitor]

hi

Wer kenn die Funktion LsaLogonUser denn nicht - ok ein Scherz :D

Code:

NTSTATUS LsaLogonUser(
  HANDLE LsaHandle,
  PLSA_STRING OriginName,
  SECURITY_LOGON_TYPE LogonType,
  ULONG AuthenticationPackage,
  PVOID AuthenticationInformation,
  ULONG AuthenticationInformationLength,
  PTOKEN_GROUPS LocalGroups,
  PTOKEN_SOURCE SourceContext,
  PVOID* ProfileBuffer,
  PULONG ProfileBufferLength,
  PLUID LogonId,
  PHANDLE Token,
  PQUOTA_LIMITS Quotas,
  PNTSTATUS SubStatus
);

Es geht hier weniger um die Frage über die Funktion selbst, als mehr über das Problem, dass der Parameter AuthenticationInformation gut definiert werden muss.
Für den interaktiven standard login verwendet man dazu MSV1_0_INTERACTIVE_LOGON. D.h. ein Pointer auf eine Struktur von.
Die Struktur muss jedoch eine Besonderheit aufweißen. Und zwar müssen die Unicode Strings direkt unterhalb der Struktur im Speicher stehen.
Die Strings in der Struktur sind wiederum eine Struktur UNICODE_STRING. Der Member Buffer muss dabei eben auf den Speicher unterhalb der Struktur im Speicher zeigen. D.h. die Speicherplatz ist die Strukturgröße + die Stringlänge in Bytes (da Unicode).
Tja, das muss man erstmal wissen.


Wie man das macht? Ich habe mal Keith Brown gefragt. Und es stellte sich heraus, dass die Funktion LSALogonUser bereits als "Funktion aus der Hölle" bekannt ist.
Es gibt dazu einen Link : The function from the hell.
Den Quelltext habe ich nach Delphi übersetzt, allerdings ohne Erfolg.

Delphi-Quellcode:

procedure _initUnicodeString(target : PUNICODE_STRING; source : PWideChar; cbMax : USHORT );
begin
  target.Length := cbMax ;//-2;//- sizeof(source^); //bei -2 und cbMax = 0 gibts nen integer unterlauf (=große Zahl, also lassen wirs)
  target.MaximumLength := cbMax;
  target.Buffer := source;
end;


function Create_MSV1_0_INTERACTIVE_LOGON(
                MessageType : MSV1_0_LOGON_SUBMIT_TYPE;
                LogonDomainName,
                UserName,
                Password  : WideString;
                out authLen : Cardinal) : PMSV1_0_INTERACTIVE_LOGON;
var iSize,i1 : Integer;
    uniStr : UNICODE_STRING;
    p : PWCHAR;

    cbHeader,
    cbDom,
    cbUser,
    cbPass : Integer;

    pDom, pUser, pPass : PWChar;


const iUSHORT = sizeof(USHORT);
      iWCHAR = sizeof(WideChar);
begin
  cbHeader := sizeof(MSV1_0_INTERACTIVE_LOGON);
  cbDom    := Length(LogonDomainName) * iWCHAR;
  cbUser   := Length(UserName) * iWCHAR;
  cbPass   := Length(Password) * iWCHAR;

  iSize := cbHeader + cbDom + cbUser + cbPass;

  authLen := iSize;

  result := PMSV1_0_INTERACTIVE_LOGON(LocalAlloc(LMEM_ZEROINIT or LMEM_FIXED, iSize));

  result.MessageType := MessageType;
  p := PWCHAR(result);
  Inc(Integer(p));
  
  pDom := p;
  pUser := PWChar(Integer(p) + cbDom);
  pPass := PWChar(Integer(p) + cbDom + cbUser);

  CopyMemory(pDom,  @LogonDomainName[1], cbDom);
  CopyMemory(pUser, @UserName[1],   cbUser);
  CopyMemory(pPass, @Password[1],   cbPass);

  _initUnicodeString(@result.LogonDomainName, pDom, cbDom);
  _initUnicodeString(@result.UserName, pUser , cbUser);
  _initUnicodeString(@result.Password, pPass , cbPass);
end;

Es ist doch so richtig übersetzt oder? Erst bitte drüber nachdenken, dann weiterlesen.























Bin mir nicht sicher.
Jedoch habe ich eine Änderung machen müssen bei :

Delphi-Quellcode:

Inc(Integer(p));

durch

Delphi-Quellcode:

Inc(Integer(p),cbHeader);

Danach hat der Aufruf von LSALogon funktioniert.

Meiner Meinung nach, zeigt der erste Code mit Inc, nur an den Anfang der Struktur - jedoch nicht ans Ende.


Wer hat nun Recht?

[Muetze1]

Das sind doch zwei ganz unterschiedliche Anweisung. Einmal wird der Zeiger nur um 1 Byte weiter geschoben und beim anderen Inc() wird der Zeiger um cbHeader weiter geschoben. Somit zeigt der Zeiger beim zweiten Inc() auf das Byte nach der Struktur.

Bei dem C++ Quellcode erhöht er das ganze um eins, aber dabei ist der Pointer aber typisiert, somit erhöht er um 1*SizeOf(Typ). Gleiches mach auch Inc() in Delphi, dazu müsste aber der Pointer den entsprechenden Typ haben. Somit ist sein Code korrekt.

[Dezipaitor]

boha, du hast tatsächlich Recht. Das ist mir garnicht aufgefallen. Es wird tatsächlich implizit die Zeigervariable ans Ende gesetzt.

Naja, wenn ich das Update der Security Library rausbringe, dann muss man sich damit nicht rumschlagen. Zumindest für den Login durch das Windows Auth Paket (kein Kerberos)

[Remko]

I've put up some sample code for LsaLogonUser recently on DP: http://www.delphipraxis.net/internal...t=lsalogonuser

[Dezipaitor]

You forgot to use CreateEnvironmentBlock to set the correct env. for the user.

The function LsaLogonUser is helpful for adding the user to a group for this session. But is it possible without using CreateToken to change privileges?

Its nearly the same code I produced some days ago without knowing yours :D
However I wrapped the LSA functions in my Security Library classes so its easier to use. I will publish it when the time is right.

[Remko]

For my purpose I didn't need user environment :-) I put up the sample code because I struggled on it for a while. Essentially the sample is a translation of Gary Nebbet's sample. You do need to have the SeTcbPrivilege (Act as part of the operation system) and enable it. This corresponds with MSDN documentation. The purpose of Gary's example was (as I recall) to show the danger of this privilege.

I see LsaLogonUser as an easy (and Vista compatible way) of launching something on the user's desktop from a service (In general services run under the SYSTEM account which has SeTcpPrivilege). Because you obtain the user's LogonSid you need not worry about setting ACL's on the user's desktop etc. Other purposes could be to acquire admin permissions to the launched application.

[Dezipaitor]

Do I understand correctly? Your code will run not as a service but as a normal process that can be used by a logged on user?

I tested my program as a service :
1. I logged on the current logged on user - but I needed to add the new logged on user SID to the windows station+desktop DACL to run a graphic process.
2. the CreateEnv... parameter must be set to the users envir. - otherwise the env. was set to the local system env. which lead to terrible result - I killed the explorer on purpose and started it again in the command line I created by that service. The result was that this user could no more start explorer with winlogon. It always used the local system. I restarted windows and logged on - but only the command line was started. All I could do was to use an partition image I created.
Thus I test such a program in a VM.

[Remko]

Zitat:

Zitat von Dezipaitor

Do I understand correctly? Your code will run not as a service but as a normal process that can be used by a logged on user?

That's right, but the user who starts my code needs SeTcbPrivilege

Zitat:

Zitat von Dezipaitor

1. I logged on the current logged on user - but I needed to add the new logged on user SID to the windows station+desktop DACL to run a graphic process.

Not needed, add the users LogonSid to the PTOKEN_GROUPS parameter

Zitat:

Zitat von Dezipaitor

2. the CreateEnv... parameter must be set to the users envir. - otherwise the env. was set to the local system env. which lead to terrible result - I killed the explorer on purpose and started it again in the command line I created by that service. The result was that this user could no more start explorer with winlogon. It always used the local system. I restarted windows and logged on - but only the command line was started. All I could do was to use an partition image I created.
Thus I test such a program in a VM.

I think this has got to do with acl on the user desktop and not the environment. Remember that ACL's that you set on the desktop do not survive a reboot

If you simply want to start a process from a service and run this on the user's desktop (or even a specific terminal sessions desktop) I use this:

Delphi-Quellcode:

procedure TService1.ServiceStart(Sender: TService; var Started: Boolean);
var hToken: THandle;
  si: _STARTUPINFOA;
  pi: _PROCESS_INFORMATION;
begin
  ZeroMemory(@si, SizeOf(si));
  si.cb := SizeOf(si);
  si.lpDesktop := nil;
  
  if WTSQueryUserToken(3, hToken) then
  begin
    if CreateProcessAsUser(hToken, nil, 'cmd.exe', nil, nil, False,
      CREATE_NEW_CONSOLE or CREATE_NEW_PROCESS_GROUP, nil,
      nil, si, pi) then
    begin
      // Do some stuff
    end;
  end;
  Self.DoStop;
end;

This sample start a process in Terminal Session 3 but you can use WTSGetActiveConsoleSession for obtaining the logged on users session ID.

[Dezipaitor]

All I wanted to do is :

1. Logon as a power user (without debug privileges)
2. Start a service that is already installed.
3. Connect to service and supply an admin password and process user token.
4. The process checks the password and logs on the user with debug privilege and add the user to the debug users for this session.
Then it starts a given program (e.g. delphi).
Maybe this should also work in a remote desktop session.

Now I can debug services or anything else. However MSVC++ 2003 does not run in debug mode without debug privileges - but MSVC++ 2005 does. Taskmanager is another example.

So I get rid of the powerful debug privilege which can be used by a virus for example.

Thats all.

[Remko]

Sure: Suppose you poweruser is called Joe.
Let your service find the LogonSid for Joe. Use LsaLogonUser to start your process (eg Delphi) (eg with the supplied credentials). Include in the PTOKEN_GROUPS both the (local) admin sid and Joe's LogonSid. The process has full access to Joe's desktop without the need to set ACL's because you "are" Joe. Because the process has also Admin's SID you also have his privilegs. If wanted replace admin by a special user with debug privileges.