7
In Windows gespeicherte Anmeldedaten prüfen ob noch gültig
Hallo,
ich lasse als Autostart nach dem Login mit einem Domänen-User an der Windowsanmeldung eine Batch-Datei laufen die nacheinander mehrere net use Befehle ausführt und mir Laufwerke neu mappt. Die Laufwerke werden mit einem anderen Benutzer gemappt als mit dem an Windows angemeldeten User.
Nun muss das Passwort bei allen Domänenbenutzern bei uns alle 30 Tage geändert werden.
Beim Ausführen von net use speichere ich die Anmeldedaten in den Windows Credential Manager so dass diese die nächsten 30 Tage nicht mehr eingegeben werden müssen.
Wenn das Passwort aber geändert wurde, so verlangt jeder Net Use Befehl die erneute Eingabe des neuen Zugangsdaten
Daher möchte ich im Skript vor den Net Use Befehlen erst prüfen ob die gespeicherten Anmeldedaten noch aktuell sind und dann eine "Weiche" einbauen:
Wenn die gespeicherten Anmeldedaten aktuell sind, dann führe die net use Befehle aus. Es kommen die gespeicherten Werte zum Einsatz.
Sind sie nicht aktuell, frage das neue Passwort ab und aktualisiere mit cmdkey erst die Einträge im Windows Credential Manager und führe danach erst die net use Befehle aus.
Wie kann ich per Skript abfragen ob die gespeicherten (!) Zugangsdaten noch gültig sind?
Ich dachte zuerst daran nur einen net use Befehl auszuführen und dann mittels Errorlevel zu prüfen ob ich die restlichen Einträge im Windows Credential Manager mittels cmdkey aktualisieren muss.
Allerdings fragt net use sofort nach den Zugangsdaten nachdem es festgestellt hat dass die gespeicherten Daten nicht stimmen. Hier ist eine Interaktion erforderlich. Somit kann ich net use denke ich nicht zum reinen Prüfen verwenden.
Vielen Dank schonmal für eure Hilfe
ich lasse als Autostart nach dem Login mit einem Domänen-User an der Windowsanmeldung eine Batch-Datei laufen die nacheinander mehrere net use Befehle ausführt und mir Laufwerke neu mappt. Die Laufwerke werden mit einem anderen Benutzer gemappt als mit dem an Windows angemeldeten User.
Nun muss das Passwort bei allen Domänenbenutzern bei uns alle 30 Tage geändert werden.
Beim Ausführen von net use speichere ich die Anmeldedaten in den Windows Credential Manager so dass diese die nächsten 30 Tage nicht mehr eingegeben werden müssen.
Wenn das Passwort aber geändert wurde, so verlangt jeder Net Use Befehl die erneute Eingabe des neuen Zugangsdaten
Daher möchte ich im Skript vor den Net Use Befehlen erst prüfen ob die gespeicherten Anmeldedaten noch aktuell sind und dann eine "Weiche" einbauen:
Wenn die gespeicherten Anmeldedaten aktuell sind, dann führe die net use Befehle aus. Es kommen die gespeicherten Werte zum Einsatz.
Sind sie nicht aktuell, frage das neue Passwort ab und aktualisiere mit cmdkey erst die Einträge im Windows Credential Manager und führe danach erst die net use Befehle aus.
Wie kann ich per Skript abfragen ob die gespeicherten (!) Zugangsdaten noch gültig sind?
Ich dachte zuerst daran nur einen net use Befehl auszuführen und dann mittels Errorlevel zu prüfen ob ich die restlichen Einträge im Windows Credential Manager mittels cmdkey aktualisieren muss.
Allerdings fragt net use sofort nach den Zugangsdaten nachdem es festgestellt hat dass die gespeicherten Daten nicht stimmen. Hier ist eine Interaktion erforderlich. Somit kann ich net use denke ich nicht zum reinen Prüfen verwenden.
Vielen Dank schonmal für eure Hilfe
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2131905362
Url: https://administrator.de/contentid/2131905362
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
vielleicht nicht die Antwort, die du hören willst, dennoch:
Warum machst du das per batch/net use? Wieso nicht per GPO?
Wäre das nicht vielleicht der bessere Weg?
Kamel
vielleicht nicht die Antwort, die du hören willst, dennoch:
Warum machst du das per batch/net use? Wieso nicht per GPO?
Wäre das nicht vielleicht der bessere Weg?
Kamel
1
Map die Dingers doch per GPO
Hier ausführlichst https://activedirectorypro.com/map-network-drives-with-group-policy/
Hier ausführlichst https://activedirectorypro.com/map-network-drives-with-group-policy/
Moin
Aber ich weiß... Da hat man ggf. auch keinen Einfluss drauf.
Das macht doch keinen Sinn!!
Also Lösung für Dein Problem ganz einfach: Konfiguriere die ACLs auf dem Serverfür die Benutzer vernünftig und verbinde die Laufwerke ohne Verwendung alternativer Konten.
Gruß
Zitat von @blacksun:
ich lasse als Autostart nach dem Login mit einem Domänen-User an der Windowsanmeldung eine Batch-Datei laufen die nacheinander mehrere net use Befehle ausführt und mir Laufwerke neu mappt.
Dieses Konstrukt verstehe ich nicht wirklich. Aber das muss ich ja auch nicht. (Andere regeln das Verbinden von Laufwerken über GPOs oder in speziellen Fällen über ein Logon-Script)ich lasse als Autostart nach dem Login mit einem Domänen-User an der Windowsanmeldung eine Batch-Datei laufen die nacheinander mehrere net use Befehle ausführt und mir Laufwerke neu mappt.
Nun muss das Passwort bei allen Domänenbenutzern bei uns alle 30 Tage geändert werden.
Was man so eigenrlich auch nicht mehr machen soll. Empfehlung ist inzwischen ein langes, komplexes Kennwort zu nutzen und dieses nicht mehr ändern zu lassenAber ich weiß... Da hat man ggf. auch keinen Einfluss drauf.
Beim Ausführen von net use speichere ich die Anmeldedaten in den Windows Credential Manager so dass diese die nächsten 30 Tage nicht mehr eingegeben werden müssen.
??? - wozu gibt es eine zentrales Rechtemanagement über das AD? Für mich liest sich das so, dass Du im Script die Verbindung über einen anderen als den gerade angemeldeten Benutzer herstellst.Das macht doch keinen Sinn!!
Also Lösung für Dein Problem ganz einfach: Konfiguriere die ACLs auf dem Serverfür die Benutzer vernünftig und verbinde die Laufwerke ohne Verwendung alternativer Konten.
Gruß
1
Per group policy preferences kann man keine Alternativen Credentials verwenden.
Frage an den Autor: wozu der andere Nutzerkontext? Sicherheitstechnisch bringt das nichts, macht nur Aufwand.
Frage an den Autor: wozu der andere Nutzerkontext? Sicherheitstechnisch bringt das nichts, macht nur Aufwand.
Zitat von @Hubert.N:
Was man so eigenrlich auch nicht mehr machen soll. Empfehlung ist inzwischen ein langes, komplexes Kennwort zu nutzen und dieses nicht mehr ändern zu lassen
Aber ich weiß... Da hat man ggf. auch keinen Einfluss drauf.
Was man so eigenrlich auch nicht mehr machen soll. Empfehlung ist inzwischen ein langes, komplexes Kennwort zu nutzen und dieses nicht mehr ändern zu lassen
Aber ich weiß... Da hat man ggf. auch keinen Einfluss drauf.
Unser Prüfungsverband hält sich da noch an den Vorgaben des LDA bzw. DSB des Landes. Und der ist meines Wissens noch der einzige, der auf eine dauernde Änderung setzt.
Die prüfen dann auch gerne (zumindest bei uns), obs die GPO gibt. Die Prüfer halten das selber für Quatsch, müssen es aber auch durchziehen.
Mit Chefität wurde das so geregelt, dass die GPO zwar da ist, das Ändern über das AD aber abgestellt ist.
Zitat von @Hubert.N:
Andere regeln das Verbinden von Laufwerken über GPOs oder in speziellen Fällen über ein Logon-Script)
Andere regeln das Verbinden von Laufwerken über GPOs oder in speziellen Fällen über ein Logon-Script)
Hintergrund ist dass ich weder auf das eine noch das andere Zugriff habe. Das kann nur das Rechenzentrum
??? - wozu gibt es eine zentrales Rechtemanagement über das AD? Für mich liest sich das so, dass Du im Script die Verbindung über einen anderen als den gerade angemeldeten Benutzer herstellst.
Das macht doch keinen Sinn!!
Das macht doch keinen Sinn!!
Hintergrund ist dass Administratoren bei uns 2 Benutzer haben, einen normalen User wie Jedermann, und einen User zur Administration.
Um nicht ständig hin und her wechseln zu müssen, nutze ich für einfach Dinge wie Laufwerkmount auf Admin-Freigaben das Feature mit "anderer Benutzer".
Die Trennung, die du versuchst, wird durch den Einsatz von cmdkey zunichte gemacht. Die eingespeicherten Credentials sind stets verfügbar, auch für Malware, die dein schwacher Nutzer ausführt.
Du solltest nach einem anderen Ansatz suchen.
Du solltest nach einem anderen Ansatz suchen.
1
