Lokale Sicherheitsrichtlinien

[MathiasSimmack]

Hallo.

Ich brauche mal einen Ansatzpunkt für o.g. Problem. Als Beispiel dafür sei "SetSystemTime" genannt, wo wir vor einiger Zeit einen Widerspruch zwischen Borlands Hilfedatei und dem aktuellen PSDK aufgedeckt haben:

Zitat von Win32 Programmer´s Help:

The SetSystemTime function fails if the calling process does not have the SE_SYSTEMTIME_NAME privilege. This privilege is disabled by default. Use the AdjustTokenPrivileges function to enable this privilege and again to disable it after the time has been set.

Zitat von PSDK:

The SetSystemTime function enables the SE_SYSTEMTIME_NAME privilege before changing the system time. This privilege is disabled by default.

Kurz gesagt: die alte Hilfedatei behauptet, man müsse (unter NT-Systemen, natürlich!) das Recht SE_SYSTEMTIME_NAME setzen, bevor man die Zeit ändern kann. Das PSDK sagt IMHO dagegen, dass die Funktion "SetSystemTime" dieses Recht selbst aktiviert.

Und ich tendiere zur letzten Aussage. Unter WinXP kann man dieses Recht z.B. so oft und so lange aktivieren, wie man möchte. Wenn man nicht in der passenden Gruppe ist, darf man die Zeit auch nicht ändern.
Bei XP sind´s standardmäßig die Admins und Hauptbenutzer, die das dürfen. Bei Win2000 dürfte es wohl ähnlich aussehen.

Lösung des Problems: "Systemsteuerung/Verwaltung/Lokale Sicherheitsrichtlinien -> Lokale Richtlinien/Zuweisen von Benutzerrechten -> Ändern der Systemzeit". Trägt man sich hier ein, bzw. die Gruppe, der man angehört, kann man die Zeit ändern ohne vorher das Recht SE_SYSTEMTIME_NAME aktivieren zu müssen!


Frage: Wie bekommt man heraus, ob man solche Rechte hat? Das Nachschauen mit "LookupPrivilegeValue" und Co. bringt IMHO nichts, weil ja im PSDK steht, dass das Recht standardmäßig deaktiviert ist! Das Ergebnis wäre also zwangsläufig FALSE.
Nötig wäre eher eine Funktion, die z.B. die genannten Richtlinien ausliest, bzw. die Gruppen und Benutzer, so dass man dann einen Ansatzpunkt für einen Vergleich hätte.

Weiß da jemand was?
In der Zwischenzeit suche ich das PSDK weiter ab ... bei "Access Control" bin ich schon ...

Gruß.

[Christian Seehase]

Moin Mathias,

so ganz bin ich auch noch nicht hinter die Logik bei den Privilegien gestiegen, aber soweit ich das bislang verstanden habe kann es durchaus sein, dass der Account eines der Privilegien besitzt, dieses aber nicht aktiv ist.
Das hat den den gleichen Effekt, als wäre es nicht zugeordnet.
Also müsste es doch genügen den Wert mit LookupPrivilegeValue auszulesen, um festzustellen, ob der Account über dieses Privileg verfügt. Man weiss dann nur nicht, ob dieses auch aktiv ist.

Bei der Verwendung von LogonUser bin ich selbst dann noch daran gescheitert, nachdem ich das Privileg zugewiesen hatte
(unter W2K, unter NT4 hatte ich es mal hinbekommen )

[Olli]

Moin Christian,

ich weiß ich bin spät dran ... so ungefähr zweieinhalb Jahre zu spät. Aber was soll's

Zitat von Christian Seehase:

so ganz bin ich auch noch nicht hinter die Logik bei den Privilegien gestiegen, aber soweit ich das bislang verstanden habe kann es durchaus sein, dass der Account eines der Privilegien besitzt, dieses aber nicht aktiv ist.

Korrekt. Privilegien muß man aber besitzen (bei NT4 bereits während des Bootvorgangs) um sie zu aktivieren.

Zitat von Christian Seehase:

Das hat den den gleichen Effekt, als wäre es nicht zugeordnet.

Dann könntest du es nicht aktivieren.

Beispiel: Der Administrator (RID 500) hat im Prinzip weniger Rechte als SYSTEM (außer Netzwerk), er darf aber wiederum Privilegien aktivieren, die er nutzen kann um als SYSTEM zu agieren. Ich hoffe du verstehst nun den Unterschied zwischen aktiviert und nicht vorhanden. In letzterem Fall (Gast zB) hätte der Nutzer ja nichtmal die Möglichkeit das Privileg zu aktivieren, er hat es ja nicht.

Das System ist ziemlich clever, wenn man bedenkt, daß man immer mit möglichst wenigen _aktiven_ Rechten rumlaufen sollte.

Zitat von Christian Seehase:

Also müsste es doch genügen den Wert mit LookupPrivilegeValue auszulesen, um festzustellen, ob der Account über dieses Privileg verfügt. Man weiss dann nur nicht, ob dieses auch aktiv ist.

AdjustTokenPrivileges() gibt dir die alten Werte zurück nachdem du ein Privileg angepaßt hast und GetTokenInformation() kannst du nutzen um das nur auszulesen

@Mathias: Ich gucke mal eben mit nem Disassembler nach, ob das aktiviert wird oder nicht!

[Olli]

In Windows 2003 wird definitiv das Privileg automatisch geholt. Siehe:

Code:

.text:77E8F99B                 push    eax
[color=green].text:77E8F99C                 push    0Ch[/color]
[b].text:77E8F99E                 call    _BasepAcquirePrivilegeEx@8[/b]
.text:77E8F9A3                 mov     esi, eax
.text:77E8F9A5                 test    esi, esi
.text:77E8F9A7                 jl      short loc_77E8F9C3
.text:77E8F9A9                 push    0
.text:77E8F9AB                 lea     eax, [ebp+var_8]
.text:77E8F9AE                 push    eax
.text:77E8F9AF                 call    ds:__imp__NtSetSystemTime@8
.text:77E8F9B5                 push    [ebp+arg_0]
.text:77E8F9B8                 mov     esi, eax
[b].text:77E8F9BA                 call    _BasepReleasePrivilege@4[/b]
.text:77E8F9BF                 test    esi, esi

Das sind zwar Symbole aus den PDBs (werden also nicht exportiert), aber da gucke ich auch nicht weiter nach bei so eindeutigem Namen. Auf Ebene der Native APIs gibt es keine Namen für die Privilegien ... nur falls sich jemand wundern sollte. Hier wäre das der Übergabewert aus der grün markierten Zeile, der natürlich kein String ist. Stattdessen werden LUIDs benutzt (64bit-Werte die auf dem System eindeutig sind).

Habe jetzt nur die Kernel32.dll von NT4 in der Schnelle zur Hand, aber da der Code fast identisch zu dem bei 2003 Server ist, denke ich, daß es durchgehend ab mindestend NT4 automatisch passiert, daß diese Win32-API ihre Rechte holt!