Logonscript Anmeldeinformationsverwaltung

[StephanR 10]

Moin,

 

per lokaler Gruppenrichtlinie habe ich die Ausführung eines Powershell Logonscripts (Benutzerkonfiguration) konfiguriert. In diesem Logonscript ist folgende Funktion enthalten, die ein Netzlaufwerk mappen soll.

 

##### Netzlaufwerk verbinden #####
function lw_mapping($freigabe){
    Start-Process -FilePath cmd -Wait -ArgumentList "/c net use Z: $freigabe"
}

lw_mapping "\\servera.ad.local.net\p1"

Auf dem Client existiert ein lokales Benutzerkonto, welches per Autologin nach Reboot direkt angemeldet wird. In der Anmeldeinformationsverwaltung wurden für die Serveradresse "servera.ad.local.net" Zugangsdaten hinterlegt, die Zugriff auf die genannte Freigabe haben.

 

Das Problem stellt sich jetzt so dar, dass nach einem Reboot das Logonscript ausgeführt wird, aber das Laufwerk nicht gemappt wird. Stattdessen erscheint ein CMD-Fenster mit der Bitte einen Benutzernamen für den Zugriff auf die Freigabe einzugeben. Dieses Verhalten kenne ich grundsätzlich, wenn die hinterlegten Zugangsdaten in der Anmeldeinformationsverwaltung nicht korrekt sind. Daher habe ich diese als erstes Überprüft und konnte auch einen Fehler feststellen. Leider ist das Verhalten nach der Korrektur der Zugangsdaten weiterhin vorhanden. Um wirklich sicherzustellen, dass die Zugangsdaten korrekt sind, bin ich manuell auf die Freigabe gegangen und habe auf dem Server überprüft, dass die Anmeldung auch wirklich mit dem hinterlegten Konto erfolgt ist.

 

Zunächst habe ich ein eventuelles Timingproblem mit der Netzwerkkonnektivität vermutet. Daher habe ich in den lokalen Richtlinien eine Skript-Verzögerung von 120Sek konfiguriert. Leider ohne Erfolg. Dann habe ich das Logonscript aus den lokalen Richtlinien entfernt, einen Reboot durchgeführt und das Logonscript manuell ausgeführt. Dies hatte dann Erfolg. Für einen weiteren Test und als aktuellen Workaround habe ich die Ausführung des Logonscripts per Aufgabenplanung eingerichtet (Ausführung bei Anmeldung). Dies funktioniert ebenfalls!

 

Auf 4 anderen Clients funktioniert das Logonscript per lokalen Richtlinien auch. Nur dieser eine Client - auf dem einmal falsche Zugangsdaten hinterlegt waren - funktioniert so eben nicht. Gibt es irgendwie einen Cache den ich ggfs. löschen sollte? Oder andere Ideen, warum sich dieser eine Client komplett anders verhält?

 

Vielen Dank und viele Grüße

Stephan

[Dukel 455]

Wieso lokale Policy? Wieso extra Anmeldeinformationen?

[StephanR 10]

vor 43 Minuten schrieb Dukel:

Wieso lokale Policy? Wieso extra Anmeldeinformationen?

Die PCs sind keine Domänenmitgleider. Daher die Nutzung der lokalen Policy. Irgendwie muss der lokale Nutzer vom Client ja Zugriffsrechte auf die externe Ressource bekommen. Das geht halt über die Anmeldeinformationsverwaltung und das Hinterlegen eines privilegierten Kontos.

 

[Dukel 455]

Und wieso sind die PC's nicht in der Domäne?

[StephanR 10]

vor 21 Minuten schrieb Dukel:

Und wieso sind die PC's nicht in der Domäne?

Die gewünschte und erforderliche Netztrennung erlaubt dies nicht. Darf ich fragen welche Relevanz deine Fragen auf das vorhandene, technische Problem haben?

[testperson 1.707]

vor 3 Stunden schrieb StephanR:

Die gewünschte und erforderliche Netztrennung erlaubt dies nicht.

Eine "Netztrennung" mit _verbundenem_ Netzlaufwerk?

 

vor 3 Stunden schrieb StephanR:

Darf ich fragen welche Relevanz deine Fragen auf das vorhandene, technische Problem haben?

Ab und an hilft ein bisschen Info von "drumrum" halt das Problem besser zu verstehen bzw. alternative / bessere Lösungswege zu finden.

 

Ich würde die ohnehin nicht vorhandene Netztrennung sein lassen, den / die PCs in die Domäne aufnehmen und die User / PCs entsprechend einschränken.

[NorbertFe 2.061]

vor 3 Stunden schrieb StephanR:

Die gewünschte und erforderliche Netztrennung erlaubt dies nicht.

Eine Netztrennung mit der Erlaubnis Netzlaufwerke zu „verbinden“. Irgendwie nicht das, was ich unter Netztrennung verstehe. Vielleicht wäre es wirklich gut, die Anforderungen nochmal zu definieren, ehe man mit solchen Basteleien eine angebliche Sicherheit herstellt. (Das ist noch keine Bewertung deiner aktuellen sicherheit, sondern einfach eine Vermutung meinerseits). 

[StephanR 10]

Clients und Server (mit Freigabe) befinden sich im gleichen Netz und sind per FW von der Office-Zone (Konzerndomäne mit den AD-Servern) getrennt. Bitte jetzt keine Diskussion über die Öffnung der notwendigen Kommunikation lostreten... Für mich eine typische Netzwerkzonierung/Trennung. Wenn ihr das anders interpretiert gerne, hilft mir dann aber nicht

 

Was ist denn genau Bastelei? Die Nutzung von lokalen Richtlinien und der Anmeldeinformationsverwaltung? Sind jetzt beides für mich Bestandteile eines marktführenden Produktes....

[Dukel 455]

Wieso gibt es dann kein eigenes AD in der getrennten Umgebung?

"manuelles/lokales" Verwalten ist ein gebastel auch wenn es Möglich ist.

[NorbertFe 2.061]

vor 11 Stunden schrieb StephanR:

Was ist denn genau Bastelei? Die Nutzung von lokalen Richtlinien und der Anmeldeinformationsverwaltung? Sind jetzt beides für mich Bestandteile eines marktführenden Produktes....

Die Verwendung lokaler Tools in diesem Zusammenhang. Über das SIcherheitslevel der Anmeldeinformationsverwaltung würde ich jetzt auch noch genauer nachdenken, wenn es eben um "Security" sprich Netzwerktrennung usw. geht. Und ja, das ist Bestandteil von Windows. Aber das ist Cortana und der Internet Explorer auch. ;) 

[StephanR 10]

vor 38 Minuten schrieb Dukel:

Wieso gibt es dann kein eigenes AD in der getrennten Umgebung?

"manuelles/lokales" Verwalten ist ein gebastel auch wenn es Möglich ist.

Weil bisher - ich bin noch kein Jahr im Unternehmen - keiner eine AD-Infrastruktur aufgebaut hat. Die Clients und deren Verwaltung ist grundsätzlich äußerst statisch. Wie ja inzwischen klar sein sollte geht es nicht um Office-Clients, sondern produktionsnahe Systeme, deren Dynamik (User/Applikationen/Netzwerkzugriffe) deutlich geringer ist als bei Office-Clients. Im Prinzip werden die Clients bis auf die Installation von Windows Updates über Ihren Lebenszyklus nicht verändert. Trotzdem mag es durchaus sein, dass eine AD an wenigen Punkten eine bessere Verwaltung zuließe, nur sind die Gegebenheiten nun mal andere.

 

vor 2 Minuten schrieb NorbertFe:

Die Verwendung lokaler Tools in diesem Zusammenhang. Über das SIcherheitslevel der Anmeldeinformationsverwaltung würde ich jetzt auch noch genauer nachdenken, wenn es eben um "Security" sprich Netzwerktrennung usw. geht. Und ja, das ist Bestandteil von Windows. Aber das ist Cortana und der Internet Explorer auch. ;) 

Welche konkreten Sicherheitsbedenken bestehen denn zur Nutzung der Anmeldeinformationsverwaltung? Bitte auch Quellen nennen.

[NorbertFe 2.061]

vor 2 Minuten schrieb StephanR:

Welche konkreten Sicherheitsbedenken bestehen denn zur Nutzung der Anmeldeinformationsverwaltung? Bitte auch Quellen nennen.

Soweit ich weiß, werden diese Kennworte eben auch im Klartext dort gespeichert und jedes so gespeicherte Kennwort kann man dann eben auch in der ein oder anderen Form auslesen. Gibt ja nicht umsonst die Richtlinie:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj852185(v=ws.10) und dort gibts dann u.a. auch gleich den Abschnitt:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj852185(v=ws.10)#vulnerability

 

Wie gesagt, ich kenne deine Anforderungen nicht, aber evtl. hilft dir der andere Blickwinkel ja doch, über die Lösungsmöglichkeiten nochmal nachzudenken.

 

Viel Erfolg.

Norbert

 

[StephanR 10]

vor 11 Minuten schrieb NorbertFe:

Soweit ich weiß, werden diese Kennworte eben auch im Klartext dort gespeichert und jedes so gespeicherte Kennwort kann man dann eben auch in der ein oder anderen Form auslesen. Gibt ja nicht umsonst die Richtlinie:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj852185(v=ws.10) und dort gibts dann u.a. auch gleich den Abschnitt:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj852185(v=ws.10)#vulnerability

 

Wie gesagt, ich kenne deine Anforderungen nicht, aber evtl. hilft dir der andere Blickwinkel ja doch, über die Lösungsmöglichkeiten nochmal nachzudenken.

 

Viel Erfolg.

Norbert

 

Danke für die Links. Sehe aus folgenden Gründen kein Sicherheitsproblem:

• Passwörter werden nicht im Klartext durch den Passwort Locker Service abgespeichert Quelle
• Wenn Malware auf dem Client ist kann diese ggfs. die Credentials auslesen. Ok, dann hat der Angreifer "lesenden" Zugriff auf den von mir erwähnten Share. Ansonsten hat das Konto keine weiteren Rechte. Da geht von der eigentlichen Infektion ein viel höheres Risiko aus, auch wenn der per Autologin angemeldete User nur "Standard"-Berechtigungen hat.

Noch jemand Ideen zu meinem ursprünglichen Anliegen?