Login Script als Domänenadmin ausführen
Hallo zusammen,
folgendes Problem:
Es sollen Außendienstmitarbeiter je nach Einsatzort einer bestimmten Gruppe im AD zugewiesen werden, damit sie Zugriff auf die jeweiligen Daten für diesen Ort bekommen. Zur Lösung habe ich ein Powershell-Skript geschrieben, das den Ort aus einer Textdatei ausliest und den User beim Logon in die Gruppe einfügt. Beim Logoff wird er wieder aus der Gruppe entfernt. Das funktioniert auch wunderbar, sofern der User Admin ist. Nun möchte ich natürlich nicht die User alle zu Admins machen.
folgendes Problem:
Es sollen Außendienstmitarbeiter je nach Einsatzort einer bestimmten Gruppe im AD zugewiesen werden, damit sie Zugriff auf die jeweiligen Daten für diesen Ort bekommen. Zur Lösung habe ich ein Powershell-Skript geschrieben, das den Ort aus einer Textdatei ausliest und den User beim Logon in die Gruppe einfügt. Beim Logoff wird er wieder aus der Gruppe entfernt. Das funktioniert auch wunderbar, sofern der User Admin ist. Nun möchte ich natürlich nicht die User alle zu Admins machen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 343184
Url: https://administrator.de/contentid/343184
Ausgedruckt am: 19.03.2024 um 03:03 Uhr
28 Kommentare
Neuester Kommentar
Hi,
sorry, aber dieses Konzept ist Nonsens.
Sinnvoller wäre es, den Zugriff z.B. über Netzlaufwerke zu lenken. Wenn er in München angemeldet ist, dann wird Netzlaufwerk X: mit \\server\münchen verbunden. Wenn er in Hamburg ist dann mit \\server\hamburg. Für den Anwender ist es immer X:\.
E.
sorry, aber dieses Konzept ist Nonsens.
Es sollen Außendienstmitarbeiter je nach Einsatzort einer bestimmten Gruppe im AD zugewiesen werden, damit sie Zugriff auf die jeweiligen Daten für diesen Ort bekommen.
Welchen Sinn soll das haben? Wenn er in München ist kann er auf die München-Daten sowieso zugreifen. Warum sollte es nötig sein, explizit zu verbieten, dass er von Hamburg aus nicht auf diese Daten zugreifen kann, auch wenn er sie dort nicht benötigt?Sinnvoller wäre es, den Zugriff z.B. über Netzlaufwerke zu lenken. Wenn er in München angemeldet ist, dann wird Netzlaufwerk X: mit \\server\münchen verbunden. Wenn er in Hamburg ist dann mit \\server\hamburg. Für den Anwender ist es immer X:\.
E.
Hallo,
welche Umgebung ist im Einsatz?
Je nach Umgebung kann die Lösung
Aber dazu sollte man beim erstellen eines Beitrages auch die nötigen Informationen angeben.
Siehe dazu Abschnitt Je nach Fragestellung werden folgende Informationen zusätzlich benötigt:
Gruss Penny
welche Umgebung ist im Einsatz?
Je nach Umgebung kann die Lösung
- Direct Access
- Dynamic Access
- Work Folders
- oder anderes
Aber dazu sollte man beim erstellen eines Beitrages auch die nötigen Informationen angeben.
Siehe dazu Abschnitt Je nach Fragestellung werden folgende Informationen zusätzlich benötigt:
Gruss Penny
Datensicherheit? Das musst mir mal erklären ...
Wenn es darum geht, dass die Daten des einen Standorts auch nicht theoretisch am anderen Standort eingesehen werden können, dann sollte man das netzwerktechnisch trennen.
Bedenke:
Du redest von Loginscript o.ä.
Dieses greift aber bloß bei einer interaktiven Anmeldung. Wenn man an einen PC geht, wo jemand anderes angemeldet ist, dann kann man rein mit den Anmeldedaten auf die Freigabe des anderen Standorts zugreifen, auch ohne sich lokal an diesem PC anzumelden.
In puncto Datensicherheit kommst Du mit Deinem Ansatz da nicht weit.
Edit:
Das mit deinem Script bei Logon kann auch aus einem anderen Grund nicht funktionieren. Wenn ich angemeldet bin und dann ein Loginscript o.ä. läuft, welche dann erst meine Gruppenmitgliedschaft ändert, dann gilt das für die aktuelle Anmeldung überhaupt nicht. Geänderte Gruppenmitgliedschaften greifen erst bei nächster Anmeldung oder nach Ablauf des Token, was i.A. aber länger dauert.
Wenn es darum geht, dass die Daten des einen Standorts auch nicht theoretisch am anderen Standort eingesehen werden können, dann sollte man das netzwerktechnisch trennen.
Bedenke:
Du redest von Loginscript o.ä.
Dieses greift aber bloß bei einer interaktiven Anmeldung. Wenn man an einen PC geht, wo jemand anderes angemeldet ist, dann kann man rein mit den Anmeldedaten auf die Freigabe des anderen Standorts zugreifen, auch ohne sich lokal an diesem PC anzumelden.
net use \\server\freigabe /user:domain\username
Edit:
Das mit deinem Script bei Logon kann auch aus einem anderen Grund nicht funktionieren. Wenn ich angemeldet bin und dann ein Loginscript o.ä. läuft, welche dann erst meine Gruppenmitgliedschaft ändert, dann gilt das für die aktuelle Anmeldung überhaupt nicht. Geänderte Gruppenmitgliedschaften greifen erst bei nächster Anmeldung oder nach Ablauf des Token, was i.A. aber länger dauert.
Sorry, aber irgendwie hast Du KEINEN Plan bzw. Ahnung wie man deine Anforderung umsetzt.
soweit die Anforderung, richtig?
Welche Umgebung setzt Ihr ein (Windows Server 2008, R2 2012, R2, oder neuer)? - meine Frage hast Du ja nicht beantwortet.
Bei Windows Server 2012 gibt es nämlich diverse Möglichkeiten, solche Anforderungen umzusetzen.
- Du hast verschiedene Außendienstmitarbeiter
- die sind unter Umständen an verschiedenen Standorten
- sollen Zugriff auf die Daten der jeweiligen Standorte bekommen
soweit die Anforderung, richtig?
Welche Umgebung setzt Ihr ein (Windows Server 2008, R2 2012, R2, oder neuer)? - meine Frage hast Du ja nicht beantwortet.
Bei Windows Server 2012 gibt es nämlich diverse Möglichkeiten, solche Anforderungen umzusetzen.
Es geht um den Zugriff auf Dateien, die in einer DFS-Freigabe liegen. Stimmt, das war schlecht ausgedrückt. Ich pack nochmal ein wenig Butter bei die Fische.
DFS-N ändert daran gar nichts.Lass mich raten: Die standortbezogenen Daten liegen dann jeweils in einer Freigabe auf einem Server, welcher vor Ort am betreffenden Standort steht?
Das wäre dann eine Frage des Arbeitsprozess. Das kann man vergleichen mit Arbeit in Projekten bei uns im Haus. Wenn jemand einem anderen Projekt zugeteilt wird, dann wird sein Konto vorher in die entsprechenden Berechtigungsgruppen aufgenommen. Entweder durch einen Admin oder durch eine Person mit delegierten Rechten im AD oder meinetwegen durch eine Software, welche das in Form eines Workflows abbildet.
Mir scheint, Du willst unbedingt diese Lösung über das Loginscript wissen. Den "Trick" dahinter.
Letzter Versuch von mir:
Letzter Versuch von mir:
Und der definierte Prozess heißt: Trage das Datum und das Schiff in den Einsatzplan des Users ein und er wird per Skript in die entsprechende Gruppe eingefügt. Ganz einfach.
Ganz einfach wäre es, wenn Du jeden Tag um 00:01 Uhr eine Geplante Aufgabe laufen lässt, welche Name, Datum und Schiff aus dieser Datei ausliest und damit die Gruppenmitgliedschsaft des Benutzers anpasst.
Also mal halblang.
@emeriks hat völlig recht. Der Prozeß ist bei Euch in keinster Weise durchdacht worden.
Deine Lösungsversuche in Ehren, es kann nicht sein, daß die Administratoren die Fehlplanung der Prozesse ausbügeln müssen.
Korrekterweise MUSS für dieses Ansinnen ein Pflichtenheft erstellt werden, um die Arbeitsprozesse zu definieren.
Dafür gibt es das Prozeßmanagement. Anhand der definierten Prozesse werden die Lösungsmöglichkeiten erarbeitet.
Da dies aber nicht gewollt/gewünscht ist, sondern man nach der Methode Setzt das um, oder Ihr seid nicht für den Job geeignet verfährt,
stehst Du und (möglicherweise) Deine Kollegen in der Schußlinie.
Irgendwas läuft also bei Euch schief. - Aus diesem Grunde kommen auch keine weiteren Lösungvorschläge,
weil die Anforderung nicht einfach mit einem Loginscript umzusetzen ist. *Punkt*
Gruss Penny
@emeriks hat völlig recht. Der Prozeß ist bei Euch in keinster Weise durchdacht worden.
Deine Lösungsversuche in Ehren, es kann nicht sein, daß die Administratoren die Fehlplanung der Prozesse ausbügeln müssen.
Korrekterweise MUSS für dieses Ansinnen ein Pflichtenheft erstellt werden, um die Arbeitsprozesse zu definieren.
Dafür gibt es das Prozeßmanagement. Anhand der definierten Prozesse werden die Lösungsmöglichkeiten erarbeitet.
Da dies aber nicht gewollt/gewünscht ist, sondern man nach der Methode Setzt das um, oder Ihr seid nicht für den Job geeignet verfährt,
stehst Du und (möglicherweise) Deine Kollegen in der Schußlinie.
Irgendwas läuft also bei Euch schief. - Aus diesem Grunde kommen auch keine weiteren Lösungvorschläge,
weil die Anforderung nicht einfach mit einem Loginscript umzusetzen ist. *Punkt*
Gruss Penny
@Penny.Cilin
Dito!
@erikro
Suche die Fehler hier bitte nicht bei mir! Ich will Dir nur helfen ...
Dito!
@erikro
Suche die Fehler hier bitte nicht bei mir! Ich will Dir nur helfen ...
00:01 in Hamburg? Oder in Lima? Oder in Hongkong?
Denkfehler! Die Zeit muss natürlich relativ zur Zeitzone, in welcher der Computer mit der geplanten Aufgabe steht, in diese betreffende Datei geschrieben werden. Da ist der Fehler!wenn der Kapitän um 00:02 anruft? Soll das Schiff dann einen ganzen Tag im Hafen liegen?
Es ist ein leichtes, einen Trigger zu hinterlegen, welcher die geplante Aufgabe sofort ausführt, wenn diese Datei geändert wird.Zitat von @emeriks:
Ok, ich klinke mich dann mal aus.
Es wäre trotzdem toll, wenn Du die Lösung hier posten würdest, falls Du es hinbekommst. Die Müchhausen-Lösung mit dem Zopf wird es jedenfalls nicht sein können.
Auch ich klinke mich her aus und schließe mich @emeriks an.Ok, ich klinke mich dann mal aus.
Es wäre trotzdem toll, wenn Du die Lösung hier posten würdest, falls Du es hinbekommst. Die Müchhausen-Lösung mit dem Zopf wird es jedenfalls nicht sein können.
Leider hast Du uns bisher nicht verraten, welche Umgebung eingesetzt wird.
Ich hatte Dir weiter oben mitgeteilt, daß unter Umständen
- Direct Access
- Dynamic Access
Hast du nicht, aber davon abgesehen wird es aus der oben bereits erwähnten Problematik das der Logon je nach Art eurer Gruppenzuweisung zu spät für die Security Token ist nicht funktionieren. Sinnvoller Ansatz wäre ein Workflowsystem das die User entsprechend ihrem Order Book den Gruppen zeitnah zum Termin zuweisst. Aber wie immer gilt, man kann organisatorsche Defizite nicht technisch lösen.
VG,
Thomas
VG,
Thomas
Nöö leider nicht. Du hattest nur DFS-Freigabe erwähnt (nämlich gestern um 16:41 Beitrag)
Aber wenn W2K12 R2 eingesetzt wird, dann schau Dir mal die beiden von mir genannten Funktionen an.
Möglicherweise kannst Du damit Deine Anforderung lösen.
Aber wenn W2K12 R2 eingesetzt wird, dann schau Dir mal die beiden von mir genannten Funktionen an.
Möglicherweise kannst Du damit Deine Anforderung lösen.
das was du/ihr plant ist AD Missbrauch vom Feinsten. Sowas realisiert man nicht über ein AD. Wenn der Workflow schon derart verkorkst ist, würde ich mir eine Plattform bauen (lassen), wo die User sich selber einen einmaligen und zeitlich begrenzten Zugriffstoken generieren können. Das ganze wird natürlich protokolliert. Wie siehts mit GPS aus? Zur Not könnte man ja noch den GPS Standort als Bedingung mit rein nehmen. Oder die Kombi der Mac Adresse von Client und Gateway und und und... Machbar ist da vieles aber nicht übers AD!
Wer hat euch da beraten?
Wer hat euch da beraten?