Lokale Adminrechte für Anwendungen

Hi!

Und dann beschwert sich der User auch noch, daß sein Pc so langsam geworden ist.

Also ganz im Ernst. DAmit hättest du aber rechnen müssen. Was macht ein DAU zuerst, wenn er merkt dass alles möglich ist? Richtig! ER installiert jeden auffindbaren SChrott und müllt das System zu.


Durchaus möglich. Manche Programme brauchen zusätzlich Schreibrechte auf Ordner auf C:\ oder wollen dort temporär was ablegen. Meißtens kannst du den Programmen in der Registry auf die SChliche kommen was die wann machen wollen. Da hilft nur testen, testen testen.


Und noch eine Frage wie entferne ich von allen Benutzern per GPO die lokalen Admin-Rechte.
Oder reichte es wenn ich einfach in der GPO bei Eingeschränkten Gruppen einfach eine Gruppe loklae Admins erstelle und dort erst mal keine Benutzer rein tue, löscht diese GPO dann die vorhandenen Einstellungen am Client in der Benutzerverwaltung?


DAzu mein Tipp: http://www.gruppenrichtlinien.de/


@2hard4you: Da bin ich nicht ganz deiner Meinung. Bei der Planung und Erstellung der SW denkt kaum ein HErstellen an Rechteverwaltung. Der Programmierer Arbeitet explizit mit Adminrechten. Testen kommte erst danach und Bereinigung erst nachdem das Produkt auf dem Markt ist.

Wer die Aufgabe hat Solcherart SW zu installieren, das vielleicht auch noch automatisiert per SCCM oder RIS weis genau was zu tun ist und dazu gehört auch die Installation so zu verbiegen, dass die SW auch entweder ganz ohne Adminrechten läuft oder zumindest eingeschränkt.

Und nochwas. Auch lokalen Admins kann man die Rechte nehmen oder diese löschen. Vorraussetzung ist natürlich, dass der USer nicht gerade mit "dem" Administrator arbeitet. Aber wer das zulässt, steht sowieso auf verlorenem Posten.

'Rechte Lokaler Admin entfernen
'VBS

strComputer = "TESTPC0001"
strGroup = "Administrators"
arrUsers = Array("kenmyer", "adambarr", "lewjudy")
Set objGroup = GetObject("WinNT:" & strComputer & "/" & strGroup & ",group")
For Each strUser In arrUsers
Set objUser = GetObject("WinNT:" & strComputer & "/" & strUser & ",user")
objGroup.Remove(objUser.ADsPath)
Next

Grüße

Mayho

Hi meddie.
Das Thema ist zwar immer wieder zu finden, eigentlich aber uralt.
Ich werf mal der Einfachheit halber ein paar Brocken hin und Du kannst bei Bedarf Rückfragen stellen.
-procmon nutzen und schauen, wohin genau die Programme schreiben wollen (bzw. welche Privilegien sie haben wollen) und anpassen
-Erzieherische Maßnahmen ("Sie verpflichten sich hiermit, die Adminrechte einzig und allein zum Zweck... zu verwenden") - funktionieren nur, wenn auch ernst und von oben angeordnet und überwachbar.
-alle vermeintlichen Workarounds (runas/runas mit savecred/runasspc/GPOs zum Einschränken von Admins) sind nicht wasserdicht, gewiefte Leute können diese immer umgehen
-der einzige Fall, wann man gesichert einen Benutzer mit hohen Rechten zum Programmstart ausstatten kann, ist leider, das Programm unsichtbar (nicht interaktiv, zum Beispiel über den Taskplaner) zu starten - dies hat also nur Wert, wenn das Programm keine Interaktion braucht (wie zum Bsp. Skripte zum Defragmentieren oder IP ändern)

Deine Frage zu den eingeschränkten Gruppen hast Du Dir selbst beantwortet. Probier es an einer Test-OU aus.
Schreibrechte auf Ordner und Registryzweige kann man auch per Computerpolicy vergeben ->im Bereich Windowseinstellungen - Sicherheitseinstellungen - Dateisystem/Registry

...REGMON und REGSHOT sind auch sehr nützliche Tools die du einsetzen kannst um eigensonnige Installationen zu zähmen

Moin,

wie wäre es denn für die Programme je ein lokales Admin-Konto anzulegen und dem User das PW dafür zu geben? Sein Domänen-User hat dann nur Benutzerrechte und er kann das Programm mittels "Ausführen als" dann mit dem Admin-Account starten.

Hintergrund ist einfach der das du keinem User was auf die Finger geben kannst weil er sich 20 Toolbars installiert hat. Der behauptet nämlich einfach das er das nicht bewusst gemacht hat - und da heute teilweise die Webseiten schon anbieten so nen Müll zu installieren musst du dem erstmal die Absicht nachweisen.

Dasselbe gilt fast schon für Software - ups, das war nicht beabsichtigt, das Programm X hat gesagt es will was machen und ich hab ja gesagt. Auch wenn du genau weisst das sowas nicht stimmt - du kannst es schlecht nachweisen.

Mit der vorgeschlagenen Vorgehensweise kann er nichts installieren - und sich auch nicht rausreden. Denn: Warum gibt er das Admin-PW ausserhalb dieser beiden Anwendungen denn ein?

Wäre zumindest mein Ansatz - ob es klappt weiss ich ehrlich gesagt auch nich

Moin Maretz.
Ich glaube, es ist nicht schwer zu sehen, dass das nicht vor Missbaruch schützt. Wenn es darum geht "dass er sich nur nicht rausreden kann", dann lässt man ihn einfach unterschreiben, dass er die Adminrechte nur für einen bestimmten Zweck nutzt, dann braucht man den (kleinen) Aufwand mit mehreren Konten auch nicht mehr.

HI!

@DerWoWusste: Leider ist diese Vorgehensweise nicht unbedingt zielführend. Auch bei uns gibt es solche Formulare und die Erfahrung hat gezeigt, dass die User sich kaum daran halten. Bei insgesamt 1200 Clients, davon 300 Workstations mit Adminrechten haben wir festgestellt, das mindestens 10 Workstations die Woche durch Zusatztools versaut wurden. Von Google Earth bis IE7Pro Updatefinder ist alles installiert. Jede Menge Zusatztools die dem armen User die Arbeit erleichtern sollen kannst du finden und noch mehr. Nur wenn dann plötzlich die Performance einbricht und du dem User erklärst woran das liegt gibts fpr etwa 10 Sekunden Einsicht. Spätestens nach dem bereinigen des Systems ist alles vergessen.

Wen man das halbwegs wasserdicht machen möchte muss jemand die Installation anpassen damit das ohne Adminrechte laufen kann. Ausnahmen gibts natürlich (ProE Wildfire, AutoDesk, AutoCAD, Inventor)

@maretz: Wenn du den User nicht demoralisieren willst, darunter leidet seine Arbeitsleistung, solltest du ihm erst garnicht die Möglichkeit geben etwas selbst zu installieren und ihm dann auf die Finger hauen. Ein User bleibt ein User und User machen was ihnen von der IT ermöglicht wird. Der einzige der eine auf die Finger bekommen sollte wenn da was passiert ist die IT.

Das zumindest ist meine Meinung.

Grüße!

mayho

Ich hab, wie Du oben lesen kannst, dies als eine unter mehreren Wegen aufgezählt. "Unbedingt" zielführend ist es nur dann, wenn die Überwachung stattfindet (technisch möglich) und dann auch Sanktionen folgen, die den Anwender auch interessieren.

Sollte auch keine Kritik sein. Sorry, wenn das so verstanden wurde
Ich wollte/möchte nur meine Erfahrung zum Besten und ein paar Tipps geben.

Welche Sanktionen könnten das sein?

°Das die Abteilung die Wiederherstellung zahlen muss?
°Kündigung im Wiederholungsfall?
°Verlust der Adminrechte (und somit Entzug der Arbeitsgrundlage)?

Hatten wir alles irgendwie schon durch. Alles was das gebracht hat war Verdruss. Und außerdem muss man da ziemlich lückenlos nachweisen können, dass genau der User, dem die Löffel lang gezogen werden, an allem schuld ist. Und das ist oft nicht möglich.

Nach wie vor vertrete ich die Meinung es erst garnicht soweit kommen zu lassen, Sprich, so viel Einschränkung wie möglich, so viel Freiraum wie nötig. Alles andere macht nur Arbeit.

grüße!

Mayho

Wir überwachen Installationsereignisse und bekommen E-Mails gesendet (die auch regelmäßig gelesen werden), welche durch Eventlogtriggering hervorgerufen werden - darin steht, was installiert wurde. Das wissen die Kollegen und halten sich tatsächlich daran. Etwaige Schwere von Maßnahmen mussten wir nicht einmal diskutieren - aber ich gebe Dir Recht, das wäre nicht leicht. Dennoch halte ich es durchaus für denkbar, wenn dies schriftlich vereinbart wird, auch Schritte bis hin zur Abmahnung zu gehen.

Das mit dem EventlogTriggering hört sich sehr interessant an. Kannst du mir das etwas genauer erklären wei das läuft, welche Tools verwendet werden?

Danke!

Bei xp: über eventtriggers.exe in Verbindung mit Blat.exe Bei vista über das in den Scheduler eingebaute eventtriggering.
Log: Application, Source: MSIInstaller, EventID:1033
Aktion: dumping des Eventlogs, zippen (7zip-Kommandozeile - nur, falls notwendig, hier eher unnötig) und per Blat.exe versenden.
\\server\share\dumpel.exe -e 1033 -d 1 -l application -m MsiInstaller -f %windir%\temp\dump.txt
[Edit: dumpel sollte natürlich auch auf einem Server liegen, Pfade angepasst]
--Blat--
\\server\share\Blat -install Mailserver %username%@domain
\\server\share\Blat "%windir%\temp\dump.txt" -to empfänger@domain -server Mailserver -debug -timestamp -subject "Installation fand statt***Syslogging"