GPO zur Einschränkung/Kontrolle der Benutzeranmeldung

[willy-goergen 0]

Ich bin heute über ein kleines Problem gestolpert, für das ich eine Lösung finden möchte.

Heute war eine Serverumstellung bei uns im Haus, weswegen ich in der Mittagspause auf bestimmte Clients zugreifen musste, um deren Software für den künftigen Zugriff anzupassen.

 

Nachdem die Mittagspause dann vorbei war, hat mich eine Kollegin dann einfach mal unbemerkt rausgeschmissen, während die Installation der Client-Software noch lief. Hatte noch ein paar andere Installationen am Laufen. Hinterher kamen dann auch die üblichen Beschwerden. "Wieso geht das nicht? Mach, das es geht. Und überhaupt hab ich auch nix gemacht!"

 

Gibt es eine Möglichkeit die Anmeldung von Nutzern (unter Windows 7) ohne Nachfrage zu unterbinden, sofern ich mit Administratorrechten (in der Domäne) unterwegs bin, während ich per Remotezugriff zugange bin? Umgekehrt muss es mir aber möglich sein mit Administratorrechten ggf. hartnäckige Zeitgenossen herauszuschmeißen.

 

Ich möchte den einzelnen Domänenbenutzern auch nicht die Berechtigung geben, sich per Remote an ihrem Rechner anzumelden.

 

Momentan kommt eine Nachfrage, ob ich die Anmeldung zulassen möchte. Reagiere ich nicht rechtzeitig drauf (30 Sekunden), schmeißt mich der User aus der Sitzung. Ich würde, falls möglich, dahingehend gerne eine Regel per GPO für alle setzen, um derartige Diskussionen in Zukunft auszuschließen.

bearbeitet 11. März 2015 von willy-goergen

[daabm 1.348]

Lange Frage, kurze Antwort: Nein.

[lefg 276]

Eine wohl nicht wirklich praktikable Methode: In den Kontoeigenschaften des Benutzers das Anmelden verweigern, einschränken.

 

Eigentlich müsste man nicht den bestimmten Benutzer beschränken, sondern das Anmelden am Rechner allegemein für Jedermann.

 

Oder ein anderes Remoteverwaltungsprogramm benutzen wie die Dameware Remote Control oder ein Produkt von NetOP.

 

 

Einige Zeit war es mit XPSP2 eineige Zeit möglich,von der lokalen Sitzung des Benutzers unabhängig zusätzlich eine oder mehrere Remotesitzungen zu betreiben. Das war eine gute Zeit.

bearbeitet 11. März 2015 von lefg

[zahni 550]

Die Remote-Software  vom SCCM bietet hier paar nette Optionen. Wenn der User angemeldet ist, gibt es eine Rückfrage beim User. Wenn nicht, kommt man "so" drauf und kann ich in der Remote-Sitzung auch neu anmelden. Dann gibt es noch VNC & Co.

[daabm 1.348]

Zahni, korrigier mich: Aber genau das meint er doch - die Rückfrage kommt, und wenn die nicht innerhalb 30 Sekunden abgelehnt wird, dann wird "übernommen"....

[willy-goergen 0]

Lange Frage, kurze Antwort: Nein.

 

Ok... dann muss ich wohl damit leben, bzw. mir ggf. was anderes überlegen. Wollte nur etwas genauer umreißen, was ich möchte.

Hatte zuerst gedacht, ich hab möglicherweise die falschen Schlagworte zur Suche benutzt. (siehe: Point and Print Restrictions)

 

 

Eine wohl nicht wirklich praktikable Methode: In den Kontoeigenschaften des Benutzers das Anmelden verweigern, einschränken.

 

Eigentlich müsste man nicht den bestimmten Benutzer beschränken, sondern das Anmelden am Rechner allegemein für Jedermann.

 

Oder ein anderes Remoteverwaltungsprogramm benutzen wie die Dameware Remote Control oder ein Produkt von NetOP.

 

 

Einige Zeit war es mit XPSP2 eineige Zeit möglich,von der lokalen Sitzung des Benutzers unabhängig zusätzlich eine oder mehrere Remotesitzungen zu betreiben. Das war eine gute Zeit.

 

XP verhält sich meine ich in etwa so, wie ich mir das dachte. Bringt mir in dem Fall nur auch nichts.

 

Ansonsten hab ich die "nicht wirklich praktikable Methode" benutzt, um die Anmeldungen einzuschränken. Meistens so, dass sich Nutzer innerhalb ihrer OU sich nur an den entsprechenden Rechnern (meist nur einen) anmelden können. Vorher gabs Experten aus der Produktion die den allgemeinen Produktionsaccount dazu genutzt haben, sich nachts an den Rechnern in den Meisterbüros anzumelden, um dort zu surfen, bzw. irgendwelchen Müll zu fabrizieren.

 

 

Zahni, korrigier mich: Aber genau das meint er doch - die Rückfrage kommt, und wenn die nicht innerhalb 30 Sekunden abgelehnt wird, dann wird "übernommen"....

 

Genau das meinte ich. Das SCCM haben wir zwar nicht, aber die Nachfrage kommt trotzdem.

 

 

... Dann gibt es noch VNC & Co.

 

VNC wäre evtl. eine Idee, wobei ich für's Erste froh bin, dass ich den in seinem ursprünglichen Zustand in der Firma los habe. Mein Vorgänger hatte da kaum was konfiguriert gehabt und ein sehr einfaches Passwort vergeben. Im Prinzip war es damit möglich Nutzer "unbemerkt" zu überwachen. Wir haben zwar keinen Betriebsrat, aber sowas muss dann auch nicht sein. Hab da lieber mit der Windows Remoteunterstützung gearbeitet.

 

Eventuell wäre VNC mit ein bisschen mehr Konfigurationsarbeit eine Alternative.

bearbeitet 12. März 2015 von willy-goergen

[testperson 1.674]

Hi,

Heute war eine Serverumstellung bei uns im Haus, weswegen ich in der Mittagspause auf bestimmte Clients zugreifen musste, um deren Software für den künftigen Zugriff anzupassen.

 

bevor ich mich da wahllos remote auf mehrere PCs vebinde, hätte ich mich da vermutlich im Vorfeld einfach mal hingesetzt und ggfs. mit dem Hersteller der Software abgeklärt, ob es nicht möglich ist, die Anpassungen zentral zu verteilen.

 

Gruß

Jan

[lefg 276]

Es gibt Artikel zum Thema:

 

Enable Multiple User Access/Concurrent User Sessions For Remote Desktop on Windows 7

 

Multiple RDP Sessions for Windows 7

 

Und es gibt http://www.netop.com/de/fernwartungssoftware/kompetenzen/module/netop-remote-control.htm

bearbeitet 12. März 2015 von lefg

[willy-goergen 0]

Hi,

bevor ich mich da wahllos remote auf mehrere PCs vebinde, hätte ich mich da vermutlich im Vorfeld einfach mal hingesetzt und ggfs. mit dem Hersteller der Software abgeklärt, ob es nicht möglich ist, die Anpassungen zentral zu verteilen.

 

Gruß

Jan

 

 

Normalerweise wäre ich selber an die Rechner hin. Mich plagt derzeit nur eine ziemlich heftige Grippe. Da wollte ich mir unnötige Bewegung sparen. Den Termin wollte ich auch nicht mehr verschieben. Den Rest der Woche bleib ich aber zuhause.

 

Den Gedanken das zu verteilen hatte ich auch schon gehabt, weil ich eigentlich alle Werkzeuge hätte, um das zu realisieren. Mangels Vorarbeit ist da aber nichts draus geworden. Für das nächste Mal werde ich das aber ins Auge fassen und nachfragen. Im konkreten Fall werde ich nächste Woche mal nachfragen, wenn ich bei dem Hersteller zur Administratorenschulung bin.

 

 

Es gibt Artikel zum Thema:

 

Enable Multiple User Access/Concurrent User Sessions For Remote Desktop on Windows 7

 

Multiple RDP Sessions for Windows 7

 

 

Das mit dem DLL patchen hatte ich schon mal auf einem Testrechner probiert. Erfolg hatte ich keinen damit. Ich konnte mich trotzdem nicht einfach per Remote anmelden, wenn schon ein Benutzer angemeldet ist. Mir schien auch die Quelle etwas zweifelhaft zu sein. Kann man das denn guten Gewissens verwenden?

bearbeitet 12. März 2015 von willy-goergen

[lefg 276]

Das Risiko bei solchen Patches ist deines, das ist doch wohl klar. Auch besteht die Möglichkeit, MS hat das mitbekommen und bereits vorgebaut.

bearbeitet 12. März 2015 von lefg

[Sunny61 806]

Normalerweise wäre ich selber an die Rechner hin. Mich plagt derzeit nur eine ziemlich heftige Grippe. Da wollte ich mir unnötige Bewegung sparen. Den Termin wollte ich auch nicht mehr verschieben. Den Rest der Woche bleib ich aber zuhause.

Wenn man krank ist bleibt man zu Hause und verzichtet auf solche Aktionen. Wie man es falsch macht hast Du jetzt am eigenen Leib gespürt, vielleicht lernst Du daraus ja etwas.

[Dukel 451]

Wieso musst du an jedem Rechner Software manuell installieren? Bevor du Benutzer sperrst würde ich schauen, dass ich die Clients ohne Anwender Beeinflussung Administriert bekomme.

[willy-goergen 0]

Wieso musst du an jedem Rechner Software manuell installieren? Bevor du Benutzer sperrst würde ich schauen, dass ich die Clients ohne Anwender Beeinflussung Administriert bekomme.

 

Meine Herangehensweise war wohl noch nicht so ganz optimal. Wobei ich das bei mir in der Firma immer als Gratwanderung sehe. In dem Fall waren nur ein paar wenige Clients betroffen, weswegen ich mir dann dachte, ist auch egal, wenn ich selber hingehe. 

 

Ursprünglich zielte meine Frage darauf ab, wie ich die Clients ohne Beeinflussung von Anwendern administriert bekomme. Richtig. So wie ich mir das vorgestellt hatte, funktioniert das aber wohl nicht.

Die einzige Möglichkeit, die mir dazu jetzt einfallen würde, wäre die Verteilung der neuen Software über einen WSUS (oder notfalls per GPO). Das wurde hier ja auch schon genannt.

Irgendwie testen muss man das dann vielleicht aber auch noch, weswegen ich mich in dem Fall frage, ob das den Aufwand in dem kleinen Rahmen überhaupt wert ist. Es geht vielleicht um 7-8 Clients.

bearbeitet 15. März 2015 von willy-goergen

[lefg 276]

Ob ein WSUS und WPP wirklich solch ein Aufwand sind? Ob es nicht auch in solch kleiner Umgebung die Arbeit erleichtert, Zeit, Arbeit und Ärger spart? Man muss es letztenlich selbst wollen und können, es erfordert ja etwas Ressource und Zeit. In diesem Fall haben die User dich rausgeworfen, es wäre doch viel angenehmer, die User müssten etwas beim Hochfahren warten, bei leistungsfähigen Rechnern ist das aber nicht wirklich merkbar, bei leistungsschwachen Rechnern trinken die User beim Hochfahrensowieso Kaffee oder machen was anderes. Und mit WSUS hättest Du die Kontrolle, wann die Aktualisierungen gemacht werden, nicht alle auf einen Rutsch sondern verteilt auf mehrere Starts oder Pausen.

 

Ich denke mal, Sunny wird sich dazu noch äusssern.

bearbeitet 15. März 2015 von lefg

[Sunny61 806]

In Bezug auf WSUS/WPP rentiert sich natürlich die Einarbeitung. Aber auch wir haben SW für sich der Aufwand in WSUS/WPP nicht rentiert, da macht man mit den betroffenen MAs Termine aus und installiert dann die SW manuell. Das ist SW die läuft auf 4 Rechnern und bekommt einmal im Jahr eine neue Version.

bearbeitet 15. März 2015 von Sunny61