Jump to content
Sign in to follow this  
StephanR

Logonscript Anmeldeinformationsverwaltung

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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). 

  • Like 1

Share this post


Link to post
Share on other sites

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....

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
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. ;) 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

Werbepartner:



×
×
  • Create New...