Wir haben eine AD-Domäne (immer noch vor Ort), die unter anderem eine Bibliothek unterstützt. Diese Bibliothek verfügt über eine Reihe öffentlicher Computer, und diese öffentlichen Computer befinden sich in ihrer eigenen Organisationseinheit im Active Directory. Wir haben auch einen allgemeinen publicGast-Login, mit dem unsere Bibliothekare externen Gästen Zugriff auf die Rechner gewähren können.
Ich möchte dieses Konto – und nur dieses Konto – beschränken, sodass es nur auf Computer in der PublicComputersOrganisationseinheit zugreifen kann.
Wir haben viele andere Benutzer, die sich auch weiterhin bei diesen und anderen Computern anmelden können sollten.
Ich weiß, dass es Log On To...in AD eine Schaltfläche für ein Benutzerobjekt gibt, aber das passt nicht so gut, da diese Computer kommen und gehen. Die OU-Mitgliedschaft wird aus anderen Gründen beibehalten, aber wenn wir diese Schaltfläche jedes Mal verwenden müssen, wenn ein Computer verschoben wird, ist sie schnell veraltet.
Die relevanten Teile unserer AD-Hierarchie sehen folgendermaßen aus:
Domain Root > InstitutionComputers > Library > PublicComputers
> ServiceAccounts > public
> Users (group) > {ManyOtherUsers}
> OtherOU > {ManyOtherUsers}
Wie kann ich das machen?
Ich habe versucht, auf Domänenebene eine Richtlinie zum Verweigern der Anmeldung festzulegen, die das öffentliche Konto einschließt, und dann auf der spezifischeren OU-Ebene eine weitere Richtlinie zum Verweigern der Anmeldung, die das Konto nicht einschließt.
Beim Testen funktioniert dies auf einigen Maschinen, aber andere blockieren die Anmeldung des öffentlichen Benutzers. Wenn ich mir die lokale Sicherheitsrichtlinie einer Maschine ansehe, die nicht funktioniert, sehe ich, dass sie die vollständige Richtlinie auf Domänenebene und nicht auf OU-Ebene hat, aber ich habe bestätigt, dass die Maschine Mitglied der richtigen OU ist. Außerdem gpresultwerden beide Richtlinien angezeigt. (Ich füge diese Informationen auch der Frage hinzu), sodass ich weiß, dass die spezifischere Richtlinie auf diese Computer zutrifft. Dies passiert auch weiterhin, nachdem gpupdate /forceder Computer ausgeführt und neu gestartet wurde.
Es stellte sich heraus, dass ich eine falsche Vorstellung davon hatte, wie „erzwungen“ in Gruppenrichtlinien funktioniert, wo es eher wie „css !important“ vs. „aktiviert/deaktiviert“ ist. Durch das Aufheben der Markierung von „erzwungen“ funktionierten die dokumentierten Vorrangregeln, während weiterhin alle Richtlinien angewendet wurden.
Antwort1
Erstellen Sie zwei Gruppenrichtlinienobjekte:
- GPO auf Domänenebene.
publicBenutzer zur Sicherheitsrichtlinie „Lokale Anmeldung verweigern“ hinzufügen - GPO auf OU-Ebene (die OU, die Computerobjekte enthält). Konfigurieren Sie „Lokale Anmeldung verweigern“ als leer (oder was auch immer Sie brauchen, falls Sie andere Benutzer blockieren müssen).
Weitere Informationen finden Sie in den Microsoft-Dokumenten:https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/deny-log-on-locally
Die Durchsetzungspriorität funktioniert umgekehrt zur üblichen Anwendungsreihenfolge:
Wenn es in Gruppenrichtlinienobjekten, die auf zwei Hierarchieebenen erzwungen werden, widersprüchliche Einstellungen gibt, hat die Einstellung Vorrang, die am weitesten vom Client entfernt erzwungen wird. Dies ist eine Umkehrung der üblichen Regel, bei der die Einstellung des am nächsten verknüpften Gruppenrichtlinienobjekts Vorrang hätte.