Netlogon Scripte: Anfängerfragen

[j.bussmann 12]

vor 1 Stunde schrieb Lian:

Alles gut... 

Danke Lian, war gerade selber dabei mir etwas ähnliches zu überlegen und zu tippen. Ich denke niemand wollte und will hier anderen etwas vorenthalten oder gegen jemanden sein.

 

Wenn also noch jemand Verbesserungsvorschläge oder anders aktives zum Thema hat, ich bin offen für Eure Gedanken.

[daabm 1.339]

Sodele, nachdem wir ( @j.bussmann und ich) heute telefonisch mal das eigentliche Problem besprochen haben - insbesondere die Hintergründe der eigenartigen Situation ( @Sunny61 manche Interna kann man am Telefon besprechen, die definitiv nicht in ein Forum gehören) - hier mal meine gesammelten Gedanken zu einer skriptbasierten Lösung. Teile davon wurden bereits erwähnt.

• Wir sprechen ab sofort nicht mehr über Logonskripte. Das ist der falsche Andockpunkt. Richtig ist ein geplanter Task mit geeigneten Triggern.
• Der Task kann erstellt werden entweder über ein Computerstartup-Skript oder über die vorhandene Softwareverteilung. Idealerweise mit beiden Methoden, um die Trefferquote zu maximieren. Und nein, ich würde ihn nicht über GPP erstellen, das ist zu fehleranfällig. Lieber in der Aufgabenplanung an einem Referenzrechner interaktiv zusammenbauen und dann als XML exportieren. Das kann dann mit schtasks (oder register-taskdefinition) importiert werden.
• Trigger, die ich für sinnvoll halte: Startup (Delay 30 Minuten mit 10 Minuten Zufall), dann alle 12 Stunden im Hintergrund. Und auf Netzwerk-Events -> https://ardamis.com/2015/09/09/windows-event-log-query-for-domain-joined-network-connection/
  Die Trigger sind der Teil, der per GPP relativ mühsam ist, das geht einfacher in der Aufgabenplanung. Der Trigger auf Domain Joined Network würde den Usern heute schon helfen - wer führt schon nach der VPN-Verbindung noch manuell ein Logonskript aus?

Der Task muß IMHO ein Skript ausfürhen und in diesem dann folgende Aufgaben erledigen - seriell, nacheinander:

1. Test-NetConnection (oder ping) auf den Server, der die UNC-Ressourcen bereitstellt
2. Robocopy <Docusnap-Programmquellpfad> <lokaler Docusnap-Programmpfad> /xj /mir /log:xyz.log (Logs sind wichtig...)
3. Docusnap-Inventoryskript aufrufen
4. Robocopy <lokaler Docusnap-Inventorypfad> <Docusnap-Shared Inventory>

Bei Step 4 muß der Zielpfad passend gestaltet sein - jeder PC braucht sein eigenes Verzeichnis. Wie genau es darunter dann aussehen soll, muß definiert werden. Und natürlich brauchen die Computer Leserechte auf den Programmquellpfad und Schreibrechte auf ihr Shared Inventory (könnte man ähnlich wie bei servergespeicherten Benutzerprofilen regeln...). Die Parameter für Robocopy sind auch nicht erschöpfend, dan kann man noch ein wenig tunen.

 

Anmerkung: Ich hab keine Ahnung von Docusnap. Wenn Step 3 und 4 so nicht umsetzbar sind, dann kann 4 auch entfallen und 3 direkt irgendwo zentral ablegen...

 

Wenn der Task mal auf einen Rechner verteilt wurde, dann sollte das alles relativ reibungslos laufen. Wie gesagt, Logging ist wichtig (egal wohin). Und Logs dürfen nicht überlaufen, auch da muß was passendes gestaltet werden (entweder nur ein Log immer überschreiben, oder anhängen und die Größe überwachen, oder mit Timestamp und die Anzahl überwachen).

 

Und wenn man noch etwas tunen will, zerlegt man das in 2 Tasks. Der eine macht die beiden Robocopys und läuft mit dem Trigger auf Domain Joined Network Connection und zyklisch. Der andere macht nur das Inventory und läuft nur zyklisch.

[j.bussmann 12]

vor einer Stunde schrieb daabm:

Der Trigger auf Domain Joined Network würde den Usern heute schon helfen - wer führt schon nach der VPN-Verbindung noch manuell ein Logonskript aus?

Der Kunde macht das tatsächlich!

Alle Notebook User habe das Logon Script als Verknüpfung auf dem Desktop liegen, und Führen das nach dem Ausbau einer VPN Verbindung manuell aus.

Ansonsten werde ich mir Deine Lösung noch mal genauer anschauen und versuchen mich da "hineinzuverstehen".

Sieht auf den ersten Blick aber alles sehr durchdacht aus, für mich zumindest.
 

Heute Abend bin ich aber definitiv nicht mehr Aufnahmefähig genug. Bei Fragen melde ich mich.

 

 

[j.bussmann 12]

So, ich habe mir das mal ein bisschen angeschaut, soweit der frühe Morgen schon klare Gedanken zulässt.

vor 8 Stunden schrieb daabm:

• Wir sprechen ab sofort nicht mehr über Logonskripte. Das ist der falsche Andockpunkt. Richtig ist ein geplanter Task mit geeigneten Triggern.
• Der Task kann erstellt werden entweder über ein Computerstartup-Skript oder über die vorhandene Softwareverteilung. Idealerweise mit beiden Methoden, um die Trefferquote zu maximieren. Und nein, ich würde ihn nicht über GPP erstellen, das ist zu fehleranfällig. Lieber in der Aufgabenplanung an einem Referenzrechner interaktiv zusammenbauen und dann als XML exportieren. Das kann dann mit schtasks (oder register-taskdefinition) importiert werden.

Mit "Computerstartup-Script" ist, so nehme ich mal an, die Option (Trigger) "Beim Start" gemeint.

Der Export ist soweit auch klar, habe gesehen, dass man Jobs exportieren und auf andere Rechner übertragen kann.

Was mir noch nicht ganz klar ist, wie ich diese Aufgabe dann im großen Stil auf alle anderen Rechner verteilen kann.

Ich vermute dass mir dort https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/schtasks weiterhelfen kann.

 

Damit plane ich aber dann nur den Import der XML Datei, richtig?

 

vor 8 Stunden schrieb daabm:

• Trigger, die ich für sinnvoll halte: Startup (Delay 30 Minuten mit 10 Minuten Zufall), dann alle 12 Stunden im Hintergrund. Und auf Netzwerk-Events -> https://ardamis.com/2015/09/09/windows-event-log-query-for-domain-joined-network-connection/
  Die Trigger sind der Teil, der per GPP relativ mühsam ist, das geht einfacher in der Aufgabenplanung. Der Trigger auf Domain Joined Network würde den Usern heute schon helfen - wer führt schon nach der VPN-Verbindung noch manuell ein Logonskript aus?

Das unter dem Link bei ardamis.com habe ich noch nicht so ganz verstanden. Wie bekomme ich das in eine Aufgabenplanung hinein. Da habe ich noch nicht die richtigen Punkte gefunden.

Hat da jemand einen Tipp?

 

vor 8 Stunden schrieb daabm:

Der Task muß IMHO ein Skript ausfürhen und in diesem dann folgende Aufgaben erledigen - seriell, nacheinander:

1. Test-NetConnection (oder ping) auf den Server, der die UNC-Ressourcen bereitstellt
2. Robocopy <Docusnap-Programmquellpfad> <lokaler Docusnap-Programmpfad> /xj /mir /log:xyz.log (Logs sind wichtig...)
3. Docusnap-Inventoryskript aufrufen
4. Robocopy <lokaler Docusnap-Inventorypfad> <Docusnap-Shared Inventory>

Bei Step 4 muß der Zielpfad passend gestaltet sein - jeder PC braucht sein eigenes Verzeichnis. Wie genau es darunter dann aussehen soll, muß definiert werden. Und natürlich brauchen die Computer Leserechte auf den Programmquellpfad und Schreibrechte auf ihr Shared Inventory (könnte man ähnlich wie bei servergespeicherten Benutzerprofilen regeln...). Die Parameter für Robocopy sind auch nicht erschöpfend, dan kann man noch ein wenig tunen.

 

Anmerkung: Ich hab keine Ahnung von Docusnap. Wenn Step 3 und 4 so nicht umsetzbar sind, dann kann 4 auch entfallen und 3 direkt irgendwo zentral ablegen...

Das sollte so weit funktionieren, werde ich mir aber auch noch im Detail ansehen.

vor 8 Stunden schrieb daabm:

Wenn der Task mal auf einen Rechner verteilt wurde, dann sollte das alles relativ reibungslos laufen. Wie gesagt, Logging ist wichtig (egal wohin). Und Logs dürfen nicht überlaufen, auch da muß was passendes gestaltet werden (entweder nur ein Log immer überschreiben, oder anhängen und die Größe überwachen, oder mit Timestamp und die Anzahl überwachen).

 

Danke auf schon mal für die Hilfe hier hin. Ich denke ich werde meine Lösung als Quick an Dirty am Donnerstag dem Kunden vorstellen und gleich einschränken, dass das keine Dauerlösung ist und dann diese hier, wenn ich sie soweit verstanden habe, als dauerhafte Lösung präsentieren.

Vielleicht bekomme ich das ja auch bis dahin noch so weit in meinen Kopf (Verständnis) dass ich am Donnerstag gleich die perfekte Lösung präsentieren kann.

[NorbertFe 2.026]

vor 26 Minuten schrieb j.bussmann:

Mit "Computerstartup-Script" ist, so nehme ich mal an, die Option (Trigger) "Beim Start" gemeint.

Nein, damit ist ein Computerstartskript gemeint, denn sonst kommt der Task ja nie zum Computer. :)

https://www.petri.com/run-startup-script-batch-file-with-administrative-privileges

 

Bye

Norbert

[daabm 1.339]

Task mit Trigger auf ein Ereignis in einem Eventlog:

 

 

Hier kannst das XML aus dem Link im Prinzip direkt reinkopieren. Ja, wenn man das noch nie gesehen hat, kommt man nicht so schnell drauf Aber ein IT-ler mit grundlegenden Kenntnissen bekommt das schon hin.

 

Und wie Norbert schon geschrieben hat: Das Task-XML exportierst Du von dem Referenzrechner, wo Du den Task passend eingerichtet hast. Per Startup-Skript erstellst Du daraus mit schtasks /create /tn "Mein neuer Task" /xml <Pfad zum XML> /ru SYSTEM den Task auf den Zielrechnern. Kann sein, daß ein Parameter fehlt, aber so prinzipiell...

[j.bussmann 12]

Wir haben nun bei dem Versuch der Umsetzung beim Kunden (oder besser gesagt der Kunde) folgendes Problem.

Der Task wurde auf einem Musterrechner von einem Techniker erstellt, exportiert und beim Import auf einem neuen Rechner will der Task, damit er funktioniert die LoginDaten des Erstellers haben. 

Ursache ist, dass mit dem Aufruf "SYSTEM" also als Systemuser ein Zugriff auf den Netzwerk Share nicht möglich ist und laut Aussage des Kunden damit auch der Rest des Scriptes fehlschlägt. 

Erstellt man das Script stattdessen mit einem berechtigten User, so wird beim Import erwartet dass genau dessen Login Daten mitgegeben werden. Eine Variable, die bei der Ausführung quasi den angemeldeten Benutzer verwendet scheint es dabei nicht zu geben.

Also müssten damit die Login-Daten des Erstellers im Klartext mitgegeben werden. (So die Auskunft des Technikers).

Ist das tatsächlich so? Ist da bei der Erstellung des Tasks irgendwo ein Fehler gemacht worden? 

Was wäre ggf. ein möglicher Workarround?

 

Ich kann mir irgendwie nicht so ganz vorstellen, dass das richtig ist. Bin aber ein wenig verwirrt.

Denn den Link den Norbert eingefügt hat, der bezieht sich auf die Erstellung eines Computer Startup Scripts per GPO für dessen Erstellung man das auf dem DC konfiguriert.

Zitat

Log on to a Windows Server 2012 R2 domain controller (DC) with a domain administrator account and follow the instructions below.

Wenn ich jedoch Martin (daadm) richtig verstanden habe, wird das Script auf einem lokalen PC erstellt und dann exportiert:

Hier gibt es aber eben genau den vom Kunden beschriebenen Umstand.

Reden wir aneinander vorbei oder machen wir etwas falsch?

 

Wer kann helfen?

 

Danke

Jörg

[NorbertFe 2.026]

vor 5 Minuten schrieb j.bussmann:

dass mit dem Aufruf "SYSTEM" also als Systemuser ein Zugriff auf den Netzwerk Share nicht möglich ist

Warum sollte das so sein? Dann wäre ja nie ein Zugriff aufs Netlogon für einen Computer möglich.

[tesso 375]

SYSTEM sollte im Normalfall auf Shares zugreifen können. Ansonsten kann man es ja so anpassen, daß der Zugriff funktioniert.

 

Schau dir mal die Hilfe zu schtasks an:

schtasks /create /?

Dort siehst du wie du für SYSTEM das Kennwort mitgibst.

[j.bussmann 12]

vor 1 Minute schrieb NorbertFe:

Warum sollte das so sein? Dann wäre ja nie ein Zugriff aufs Netlogon für einen Computer möglich.

Ich habe die Optionen: Nur Ausführen wenn der Benutzer angemeldet ist, dies setzt voraus, dass der oben angegebene Benutzer angemeldet ist, in dem Beispiel (Screenshot also ich selbst).

Aktiviere ich hingegen die Option "Unabhängig von der Benutzeranmeldung ausführen", so werde ich nach einem Benutzernamen und Kennwort gefragt.

 

 

Das scheint das Problem des Kunden zu sein.

 

Ändere ich stattdessen oben über den Button "Benutzer oder Gruppe ändern" den User auf "System" sieht das Ganze so aus:

 

 

Hier sagt der Kunde wäre dann aber beim Export dieses Jobs eben kein Zugriff auf ein Netzwerkshare möglich.
Ich habe nur einen lokalen Rechner und kann das auch in Ermangelung einer Domäne nicht mal so eben verifizieren. 

 

Verstehe ich die Rückfrage von Norbert richtig, dann impliziert diese Frage, dass bei einem Zugriff auf den Netlogon-Pfad auf dem DC ebenfalls die NT-Autorität "System" genutzt wird. Aber ist es nicht vielmehr so, dass die Anmeldedaten des Users genutzt werden, die als verifizierbar sind?

 

 

[Sunny61 806]

vor 56 Minuten schrieb j.bussmann:

Hier sagt der Kunde wäre dann aber beim Export dieses Jobs eben kein Zugriff auf ein Netzwerkshare möglich.

SYSTEM ist der lokale Computer. D.h. wenn auf dem Share die Authentifizierten Benutzer LESEN dürfen, darf das auch der Computer. Das ist in 5 Minuten getestet.

[j.bussmann 12]

Ja SYSTEM ist der lokale Computer, wenn aber doch das Script oder besser gesagt der Task mit den Credentials "System" ausgeführt wird, ist es doch eben kein authentifizierter Benutzer an der Domäne und damit am Share auf dem das eigentlich auszuführende Script (die exe-Datei) abgeholt  per Robocopy abgeholt werden soll (siehe dazu den Lösungsvorschlag von Martin / daabm) und auf die das Ergebnis geschrieben werden soll. 

 

Wie gesagt ich versuche die Thematik nur so weit zu verstehen, dass ich sie auch korrekt wiedergeben kann, sorry dass ich dabei technisch nicht alles direkt 1:1 nachvollziehen kann in Ermangelung der richtigen Systeme und daher das eine oder andere genauer erfragen muss.

 

Wenn ich dann dabei Probleme habe Eure Statements zu verstehen, dann bitte ich das zu entschuldigen. Aber der Kunde sagt ja, dass er genau das getestet hat.

Im Moment habe ich das Gefühl wir reden alle irgendwie aneinander vorbei. Ich versuche hier ja schon die Dinge bei mir nachzustellen, bin mir dabei aber auch nicht ganz sicher, ob ich immer den richtigen Weg gehe.

 

[NorbertFe 2.026]

vor 1 Stunde schrieb j.bussmann:

ist es doch eben kein authentifizierter Benutzer

Was glaubst du, wozu es die Computerkonten im ad gibt? ;)

[Sunny61 806]

vor 4 Stunden schrieb j.bussmann:

Ja SYSTEM ist der lokale Computer, wenn aber doch das Script oder besser gesagt der Task mit den Credentials "System" ausgeführt wird, ist es doch eben kein authentifizierter Benutzer an der Domäne und damit am Share auf dem das eigentlich auszuführende Script (die exe-Datei) abgeholt  per Robocopy abgeholt werden soll

Ein Computer IST Mitglied der Authentifizierten Benutzer. Wie Norbert schon schrub, ansonsten könnten Computer nicht die Scripte vom SYSVOL oder NETLOGON lesen.

 

Viel Erfolg weiterhin, ich bin jetzt auch raus.

[j.bussmann 12]

Norbert, es würde mir echt helfen, wenn ihr Euch, sollte das nicht zu viel verlangt sein, die Mühe machen würdet, nicht nur Stichworte in den Raum zu schmeißen, sondern vielleicht einen erklärenden Ansatz zu liefern. Wie gesagt ich versuche das jeweils nachzuvollziehen und suche nach jedem Post nach weitergehenden Erklärungen, aber wie ich schon mal sagte, ich bin kein Administrator und die Zeit als ich mich das letzte Mal mit solchen Themen befasst habe liegt gut 20 Jahre zurück.

Da mag der eine oder andere mich auslachen oder für doof halten, damit muss ich wohl leben, ich für meinen Teil möchte niemanden angreifen oder auf die Füße treten und hoffe sehr, dass das auch von niemandem so verstanden wird, aber so lange ich immer nur Bruchstücke ohne Erklärungen bekomme, ist es für mich sehr schwer, nachzuvollziehen, worum es in der jeweiligen Aussage geht.

 

Um auf Deine obige Frage z.B. zurück zu kommen, ich weiß dass es Computerkonten in der AD gibt, aber mir ist der Zusammenhang nicht klar.

 

Denn etwas weiter oben wurde gesagt der System-Account ist ein lokaler Account und wenn ich mir das hier so durchlese, und richtig verstehe, dann hat ein System-Account ausschließlich lokale Rechte. Für mich macht das auch insofern Sinn, denn wäre dem nicht so, könnte ich ja auch eine Aufgabe erstellen die z.B. das Löschen aller Dateien auf einem Netzlaufwerk durchführt, würde diese Aufgabe mit der Berechtigung SYSTEM ausführen und damit dann Dinge ausführen, für die ich persönlich gar keine Berechtigungen habe. 

Ganz so einfach kann es also, wenn ich das richtig verstehe mit dem System Account nicht sein.  

 

Für mich ist damit nicht klar, wenn ich einen solche Aufgabe in der Aufgabenplanung erstelle und diese Aufgabe dann an einen anderen Rechner importiere, dann funktioniert das bei mir schon mal völlig problemlos, wenn ich die Aufgabe mit dem System Account auf meinem privaten Rechner erstelle, der kein Mitglied einer Domäne ist dann sieht der Job wie in der obigen Abbildung aus: 

 

(hier noch einmal gepostet)

 

Im Moment macht die Aufgabe erst einmal nichts anderes, als einfach nur Notepad starten, es geht mir zunächst erst einmal nur um die Aufgabe an sich, also hier alles richtig zu verstehen.

 

Diese Aufgabe kann ich exportieren als xml-Datei und füge sie z.B. in meinen Firmenrechner wieder ein (nur als Test versteht sich).

Dann sieht sie dort im Prinzip so aus:

 

 

Außer das aus NT-AUTORITÄT\SYSTEM nun System geworden ist, istkeine Veränderung festzustellen und der Aufruf von Notepad funktioniert damit auch wunderbar.

 

Notepad ist ja nun aber auch keine Applikation die besonderer Berechtigungen bedarf. Daher ist mir klar, dass das ohne Probleme funktioniert.

 

Soweit so klar. Das bestätigt soweit auch der Kunde.

Wird nun aber nicht Notepad ausgeführt sondern wie Martin das vorgeschlagen hat folgendes abgearbeitet:

 

Zitat

 

1. Test-NetConnection (oder ping) auf den Server, der die UNC-Ressourcen bereitstellt
2. Robocopy <Docusnap-Programmquellpfad> <lokaler Docusnap-Programmpfad> /xj /mir /log:xyz.log (Logs sind wichtig...)
3. Docusnap-Inventoryskript aufrufen
4. Robocopy <lokaler Docusnap-Inventorypfad> <Docusnap-Shared Inventory>

 

Dann scheitert das eben an den Rechten, weil System eben keine Rechte hat auf ein Netzwerk-Share zuzugreifen (siehe dazu auch meine Anmerkung oben). 

Dieser Artikel hier https://www.vectorsoft.de/blog/2013/09/zugriff-auf-netzwerkressourcen-ueber-eine-windows-dienstanwendung/) bestätigt für mich meine Vermutung, denn auch hier steht: 

Zitat

Typischerweise sind Dienst-Anwendungen so konzipiert, dass für die Verarbeitung der Zugriff auf lokale Ressourcen des Systems ausreicht. Je nach Aufgabenstellung kann es aber erforderlich werden, auf freigegebene Verzeichnisse oder Netzwerkdrucker zuzugreifen.

Grundsätzlich ist ein Zugriff auf Netzwerkressourcen auch von einem Windows-Dienst aus möglich. Dazu ist allerdings der Kontext, in dem der Dienst läuft, zu ändern. Standardmäßig werden Dienste unter Windows – so auch der SOA-Service – unter dem „lokalen Systemkonto“ gestartet. Wie der Name des Kontos schon vermuten lässt, gewährt es dem Dienst umfassende Rechte auf dem lokalen Computer. Ein Zugriff auf das Netzwerk besteht in diesem Kontext allerdings nicht.

Hierzu muss sich der Dienst mit einem Benutzerkonto anmelden, welches die notwendigen Rechte besitzt. Die Einstellungen der Dienste sind über Systemsteuerung -> Verwaltung -> Dienste zu erreichen. Alternativ lässt sich die Verwaltung über den Ausführen-Dialog durch die Eingabe von „services.msc“ starten. Nach der Auswahl des Dienstes „CONZEPT 16 SOA-Service“ kann auf der Registerseite „Anmelden“ das gewünschte Benutzerkonto angegeben werden. Nach erfolgter Änderung muss ein Neustart des Dienstes durchgeführt werden.

Das beschreibt auch genau die selbe Problematik die der Kunde hat. Will er auf ein Netzwerk Share zugreifen, so muss er Login Daten mitgeben. Genau das verursacht aber eben beim Reimport Probleme.

Ich habe daraufhin etwas weiter gesucht und bin dabei hier fündig geworden:

https://www.libe.net/local-system

 

Wenn ich das richtig verstehe, wird hier genau die Lösung beschrieben und ich vermute, dass dies auch die Lösung (nur in ausführlicher Form ist, die Sunny61 und NorbertFE meinten.

 

Liege ich da richtig?