MS AuthZ Technologie AuthZAccessCheck Problem.

[Dezipaitor]

AuthZ ist eine MS Technologie, mit der man unter anderem ein AccessCheck machen kann, ohne ein Token verwenden zu müssen. "AuthZAccessCheck" kann eine Sid verwenden, um Zugriff zu testen.

Das folgende Programm und alle Units kann man auch hier laden:
jedi-apilib-rev136.zip.

Dieses Programm demonstriert MS AuthZ mit JWSCL.

Delphi-Quellcode:

program AuthCtx2;

{$APPTYPE CONSOLE}

uses
  dialogs,
  JwaWindows,
  jwsclConstants,
  jwsclTypes,
  JwsclMapping,
  JwsclSid,
  JwsclToken,
  JwsclResource,
  JwsclDescriptor,
  JwsclACL,
  JwsclUtils,
  JwsclSecureObjects,
  JwsclKnownSid,
  JwsclAuthCtx;


const
  GUID_1: TGUID = (D1: 1; D2: 2; D3: 1; D4: (1, 2, 3, 4, 5, 6, 7, 8));
  GUID_2: TGUID = (D1: 1; D2: 2; D3: 1; D4: (1, 34, 3, 4, 5, 6, 7, 8));

var
    RMCtx : TJwAuthResourceManager;
    AuthZCtx : TJwAuthContext;

    Reply: TJwAuthZAccessReply;
    AuthZHandle: TAuthZAccessCheckResultHandle;
    Request: TJwAuthZAccessRequest;
    SD : TJwSecurityDescriptor;
    SDArray : TJwSecurityDescriptorArray;
    ObjectTypeArray: TJwObjectTypeArray;
    i : Integer;
begin
  JwInitWellKnownSIDs;

  RMCtx := TJwAuthResourceManager.Create('',
    [authRM_NoAudit],nil,nil,nil);

  AuthZCtx := TJwAuthContext.CreateBySid(
      RMCtx,//const ResourceManager: TJwAuthResourceManager;
      [authZSF_Default],//const Flags : TAuthZSidContextFlags;
      JwAdministratorsSID,//
      0,//const ExpirationTime: Int64;
      nil//const DynamicGroupArgs: Pointer
      );

  SD := TJwSecurityDescriptor.Create; //CreateDefaultByToken();
  SD.Owner := JwNullSID;
  SD.PrimaryGroup := JwNullSID;

  SD.DACL.Clear;
  SD.DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(
                  nil,[], FILE_READ_EA, JwAdministratorsSID, false));
  {SD.DACL.Add(TJwDiscretionaryAccessControlEntryDeny.Create(
                  nil,[], FILE_READ_DATA, JwAdministratorsSID, false));
  }
  SetLength(SDArray,2);

    SDArray[0] := TJwSecurityDescriptor.CreateDefaultByToken();
    SDArray[0].DACL.Clear;
    SDArray[0].DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(
                  nil,[], FILE_READ_ATTRIBUTES, JwAdministratorsSID, false));

    SDArray[1] := TJwSecurityDescriptor.CreateDefaultByToken();
    SDArray[1].DACL.Clear;
    SDArray[1].DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(
                  nil,[], FILE_WRITE_DATA, JwAdministratorsSID, false));



  SetLength(ObjectTypeArray, 2);
  ZeroMemory(@ObjectTypeArray[0], sizeof(ObjectTypeArray[0]));
  ObjectTypeArray[0].Level := ACCESS_OBJECT_GUID;
  ObjectTypeArray[0].ObjectType := @GUID_1;

  ZeroMemory(@ObjectTypeArray[1], sizeof(ObjectTypeArray[1]));
  ObjectTypeArray[1].Level := ACCESS_OBJECT_GUID;
  ObjectTypeArray[1].ObjectType := @GUID_2;
  

  Request := TJwAuthZAccessRequest.Create(
    MAXIMUM_ALLOWED,//FILE_READ_EA,//DesiredAccess: TJwAccessMask;
    JwNullSID, //PrincipalSelfSid: TJwSecurityID;
    ObjectTypeArray,//ObjectTypeArray,//ObjectTypeArray: TJwObjectTypeArray;
    nil,//Data: Pointer
    shOwned
    );

  AuthZCtx.AccessCheck(
    1,//Flags: Cardinal;
    Request,//const Request: TJwAuthZAccessRequest;
    0,//const AuditInfo: TAuthZAuditInfoHandle;
    SD,//const SecurityDescriptor: TJwSecurityDescriptor;
    SDArray,//const OptionalSecurityDescriptorArray: TJwSecurityDescriptorArray;
    Reply,//out Reply: TJwAuthZAccessReply;
    AuthZHandle//out AuthZHandle: TAuthZAccessCheckResultHandle
  );

  writeln(JwFormatAccessRights(Reply.GrantedAccessMask[0], FileMapping));

  Reply.Free;

  //readln;

  AuthZCtx.Free;
  RMCtx.Free;

end.

Was ist das Problem?
1. SDArray ist ein Array von Sicherheitsdeskriptoren, die einfach ein SD sind, jedoch hintereinandergeschrieben. Die DACL wird also zu einer riesigen DACL verschmolzen. Die Reihenfolge ist logisch, also 1,2,3,4... (zuerst der erste, dann der zweite, usf.)
Das Problem ist, dass nur der erste SD in SDArray gehör findet. Das Recht "FILE_WRITE_DATA" müsste in der Ausgabe von JwFormatAccessRights auch vorkommen.

2.
AuthZCtx.AccessCheck hat als Eingabe eine Klasse "Request", welche eine Reihe von Objekteigenschaften entgegen nehmen kann. Das sind Eigenschaften eines Objektes, welche auch gesichert werden wollen. Z.b. ist eine (fiktive) Eigenschaft "Visible", welche nur von Administratoren verändert werden kann, aber sonst jeder lesen darf.
Gebe ich diesen Array an, wirft AuthZAccessCheck jedesmal einen Fehler.

Delphi-Quellcode:

 Request := TJwAuthZAccessRequest.Create(
    MAXIMUM_ALLOWED,//FILE_READ_EA,//DesiredAccess: TJwAccessMask;
    JwNullSID, //PrincipalSelfSid: TJwSecurityID;
    ObjectTypeArray, //<--- wichtig!!
    nil,//Data: Pointer
    shOwned
    );

Vorsicht, das Beispiel im Download funktioniert nur, weil es nil statt ObjectTypeArray an den Konstruktor übergibt. Das Beispiel hier bringt jedoch den Fehler.


Alles klar?

[Dezipaitor]

Ich hab schon gewettet, dass k/einer Antwortet :D

[Alter Mann]

Hallo kleiner 'Scherzkeks',

um 15:00 Uhr geschrieben und keine 6 Stunden später schon eine Antwort
erwarten. Und das bei diesem Thema :lol:

Habe mir gerade die 11 Mega geladen und werde mir Unit JwsclAuthCtx mal
ansehen. Ergebnis wird verkündet.

Gruß

[Dezipaitor]

Ich hatte da eine Unterhaltung mit jemand, und daher hab ich es einfach nochmal kommentiert.
Die Frage Nr.1 habe ich schon gelöst. Mir kam die Antwort sozusagen im Schlaf.

An der Frage Nr. 2 bin ich dran.


Ehrlich gesagt, hat das Problem garnichts mit dem Thema an sich zu tun. Es ist viel mehr eine Frage von Pointerarithmetik.


---

Aber das Thema kann sehr nützlich sein.
Die Funktion LSALogonUser kann eine Reihe von zusätzlichen Gruppen in das Token aufnehmen. So ist es möglich, dass jemand kurzzeitig in einer weiteren Gruppe Mitglied ist. Die AuthZ kann das auch - jedoch ist kein Token dazu notwendig (kann aber benutzt werden). Man kann einen Benutzer (durch Token oder Sid) zusätzlich in eine weitere Gruppe aufnehmen und dann überprüfen, wieviel Zugriff ihm dann gestattet ist.

[Alter Mann]

Hi Dezipaitor,

habe den Programmsource mit Copy and Paste entnommen
und will ihn starten. Kommt doch glattweg eine Fehlermeldung, alá:
"Der Prozedureinsprungspunkt "AddMandatoryAce" wurde in der "advapi32.dll" nicht gefunden".

Woran liegt es? Ich lasse das ganze in einer virtuellen Domäne (W2K3 mit ADS) auf
einem WinXP SP2 -Rechner laufen(Delphi7).

Vielleicht kannst Du mir ja verraten in welcher Unit die Librarys geladen werden, spart
die Suche.

Gruß

[Dezipaitor]

AddMandatoryAce ist nur in Vista verfügbar.

D.h. du musst "DYNAMIC_LINK" in den Compilerdirektiven für JwaWindows.pas verwenden, damit die DLLs dynamisch geladen werden, oder du entfernst "VISTA" aus den Compilerdirektiven. Damit wird AddMandatoryAce in JwsclAcl.pas nicht mehr benutzt.

Am besten du kompilierst dir eine JwaWindows.dcu und JwaVista.dcu aus den Paketen im Packageordner von Jwa.

[Alter Mann]

Hi,

schon klar, aber laut JwaWindos ist "DYNAMIC_LINK" aktiv, wenn die 'Package Conditions' nicht definiert sind.
In der jediapilib.inc ist nur {$DEFINE WINXP} deklariert.
Dank der übersichtlichen!!! Verwendung der Compilerdirektiven findet man die entsprechenden Stellen
auch auf sofort.

Schon mal was davon gehört: Weniger ist oft mehr.

Nun also die Frage, sind die 'Package Conditions' nun definiert oder nicht.

Gruß

[Dezipaitor]

'Package Conditions' ist auch nur eine String, der in den Compileroptionen angegeben werden muss.

jediapilib.inc gilt nicht für die JwaVista.pas, worin die betreffende Funktion eingesetzt ist.

Werden bei dir die blauen Punkte neben ausführbaren Quelltext angezeigt an Stelle JwsclACL:1495 - AddMandatoryAce ?

Ich habe grad bemerkt, das Windows XP bei der Initialisierung des Context
einen echten Benutzer haben will.

Das im Beispiel angegeben funktioniert daher nur in Vista.

Delphi-Quellcode:

AuthZCtx := TJwAuthContext.CreateBySid(
      RMCtx,//const ResourceManager: TJwAuthResourceManager;
      [authZSF_Default],//const Flags : TAuthZSidContextFlags;
      JwAdministratorsSID,
      0,//const ExpirationTime: Int64;
      nil//const DynamicGroupArgs: Pointer
      );

Windows XP will einen echten Benutzer (keine Gruppe)

Delphi-Quellcode:

AuthZCtx := TJwAuthContext.CreateBySid(
      RMCtx,//const ResourceManager: TJwAuthResourceManager;
      [authZSF_Default],//const Flags : TAuthZSidContextFlags;
      JwSecurityProcessUserSID,
      0,//const ExpirationTime: Int64;
      nil//const DynamicGroupArgs: Pointer
      );

Wenn der aktuelle Benutzer in der Gruppe Administrator ist, sollte es keine Veränderung geben. Wenn doch kann man alle Vorkommen von JwAdministratorsSID durch JwSecurityProcessUserSID ersetzen.

[Alter Mann]

Hi,

die blauen Punkte sind vorhanden.
Das mit dem Administrator ist in der VM kein Problem.

[Dezipaitor]

Ok das ist normal.
Aber du kannst die Direktive VISTA testweise in jwscl.inc ausschalten.

Mich wundert es nur, dass du so einen Fehler bekommst. Es ist garnicht mgölich mit dynamischen Linken so ein Problem zu haben. Wie hast du JwaWindows.pas eingebunden?
Ich empfehle immer die mitgeliefierten Pakete zu verwenden und nicht die JWA Quellen in den Suchpfad aufzunehmen, sondern eben die Binär/DCU-Dateien.

[Alter Mann]

Hallo,

ich muss mal schauen wo die ursprüngliche Installationsanleitung ist.
Ich habe ebend nur das zip-File entpackt und den Suchpfad darauf gesetzt,
vielleicht liegt es ja daran.

Bis Morgen.

[Dezipaitor]

Das ist tatsächlich ein Bug.
JwaWindows.pas läuft korrekt. Jedoch wird JwaVista.pas, welche diese Funktion enthält nicht DYNAMISCH gelinkt. Und daher der Fehler. Man kann natürlich jwaWindows + jwaVista auch direkt in den Quellpfad aufnehmen und kompilieren, muss dann aber explizit in den Optionen die Direktive "DYNAMIC_LINK" setzen. Sonst wird nur JwaWindows.pas dynamisch gelinkt.

JwaVista.pas gibt es nur, damit ich bei zahlreichen Änderungen, nicht immer die gesamte Bibliothek kompilieren muss. Die Inhalte an sich werden wohl bald eh auf die korrektn Units verteilt.

[Dezipaitor]

Alles gelöst.