Jump to content

OnkelGauss

Members
  • Gesamte Inhalte

    303
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von OnkelGauss

  1. Hallo benomatic

     

    Mit "RUNDLL32 PRINTUI.DLL,PrintUIEntry ..." könntest du dein Ziel erreichen. Schau' die mal die Beispiele unter Rob van der Woude's Scripting Pages: Batch Files, PowerShell, Rexx, KiXtart, Perl, VBScript, HTA an. Vor allem "Store all printer settings into a file" und "Restore all printer settings from a file" könnten interessant sein...

     

    PS: Die Infos gibt es auch auf Deutsch unter Gruppenrichtlinien - Übersicht, FAQ und Tutorials ,->

    PPS: Drucker-Ports lassen sich via REG-Datei- Import installieren: https://engineering.purdue.edu/ECN/Support/KnowledgeBase/Docs/20040216090320

     

    Viel Glück!

  2. Eine andere Lösung: Via Logon- Script und RunAs unter einem Benutzer kopieren/laufen lassen, welcher lokal Administratoren-Rechte hat.

     

    Ich lasse via Logon-Script ein zweites Script unter anderen Benutzerrechten starten, in welchem ich solche Änderungen ausführen lasse... RunAs mit Passwort habe ich mit einem kleinen AutoIt-Script realisiert.

  3. Hallo z0rn

     

    Du könntest zuerst alle Dateien auf die Festplatte kopieren (lassen) und anschliessend die Installation(en) starten. Oder zu könntest alles in ein selbstextrahierendes WinRAR-Archiv (SFX) verpacken.

     

    Den Internet Explorer kannst du auch ohne Neustart installieren lassen:

    start /wait <PFAD_zum_IE6_Full>\ie6setup.exe /C:"ie6wzd /S:""#e"" /Q:A /R:N"

    So könntest du alles in einem Durchgang installieren. (Je nachdem, was du alles installieren willst.)

     

    PS: Schau dir mal RunOnceEx (Windows-unattended - RunOnceEX) an. Eine Alternative zum Kopieren in den Autostart.

  4. Das Beste ist wohl, wenn die Benutzer so gut wie möglich über alle Folgen informiert und geschult werden. Absichtlicher Schaden kann wohl nie verhindert werden, denn sobald ein Benutzer Zugriff auf "heikle" Bereiche hat, könnte er auch Schaden anrichten. Viele Probleme tauchen auf, weil Benutzer zu wenig geschult werden (Social Engineering, Passwort-Weitergaben an andere Mitarbeiter, unverschlüsselter Datentransport).

     

    Durch Zugriffseinschränkungen (Gruppenrichtlinien, NTFS-Berechtigungen, Freigaberechte, Türschlösser, USB deaktivieren, usw.), Logfiles, usw. kann man schon einiges erreichen.

     

    Einen 100%-igen Schutz gibt es nicht. Je mehr Sicherheit, desto weniger Benutzerfreundlichkeit.

  5. Weiters verstehe ich nicht ganz warum ihr die Benutzerkonten sooft angreifen müßt!

     

    Haben leider fast keine Gruppenrichtlinien und keine Softwareverteilung, usw. Die (meisten) Benutzer arbeiten mit eingeschränkten Benutzerrechten. Wenn es aber Softwareänderungen, usw. gibt, deren Einstellungen im Benutzerprofil gemacht werden müssen, muss man sich als Benutzer anmelden (gebe dem User dann kurz lokale Adminrechte).

     

     

    Eine einfache Lösung wird es wohl nicht geben. Wie schon erwähnt, sollten wohl Gruppenrichtlinien und Softwareverteilung, usw. genauer betrachtet werden, so dass manuelle Änderungen am Rechner nicht mehr nötig sind.

     

    Eine Meldung vor der Anmeldung auszugeben ist eine Idee. Aber es wird Benutzer geben, welche diese Meldung einfach ohne zu lesen wegklicken werden...

     

    Vielen Dank für eure (langen) Beiträge!

  6. Für die Fernwartung der Clients verwenden wir RealVNC und Telnet. Fast alle Änderungen (Software aktualisieren/änden/deinstallieren, Einstellungen, usw.) werden auf jedem Rechner einzeln durchgeführt. Dies mache ich meistens am Abend und in der Nacht, damit die Benutzer die Arbeit nicht unterbrechen müssen, denn es dauert immer länger, als man denkt ,->

     

    Software, usw. können wir ohne Probleme mit dem lokalen Admin- oder Domain-Admin-Accounts pflegen, die meisten Änderungen betreffen aber auch das Benutzerprofil (Software konfigureren).

     

    Die Idee mit dem Anrufbeantworter ist Klasse. Total vergessen, dass es so etwas noch gibt, denn heute ist man ja 24 Stunden erreichbar ,-> An Wochenenden ist dann der Benutzer evtl. informiert, dass das Kennwort geändert wurde, kann sich aber nicht bei uns melden und somit nicht arbeiten.

     

    Ich glaube Gruppenrichtlinien und Softwareverteilung wären wohl die Lösung.

  7. Hallo ChristianHemker

     

    [zitat]da sträuben sich aber jedem sicherheitsbewussten Netzwerker die Nackenhaare[/zitat]

     

    Das Kennwort wäre ja nur für Benutzer geändert, an deren Rechnern etwas geändert wurde. Aber mir gefällt diese Idee auch nicht... Aber wir brauchen irgend eine Lösung. Gelbe Zettel an den Monitor klappt nicht, da die meisten Rechner in den Niederlassungen im ganzen Land stehen. Und eine E-Mail senden geht ja auch nicht, da er Outlook erst nach der Anmeldung sichtbar wird ,->

     

    Das einfachste ist, wenn der Benutzer anrufen kann und wir dann das "neue" Passwort eintippen und er anschliessend das Kennwort ändern/muss. Teilweise sind die Mitarbeiter früher an Arbeitsplatz, als die Informatik. Auch an den Wochenenden sind manche Mitarbeiter aktiv und wenn am Freitag noch etwas geändert wurde, dann werden diese keine Freude mehr haben... Wir anschliessend auch nicht mehr ,->

  8. Hallo Leute

     

    Ausgangslage

    Wir müssen wegen eines Entscheids der Gruppenleitung neue Kennwortrichtlinien erzwingen. Das Kennwort muss durch den Benutzer mindestens ein mal Pro Jahr geändert werden. Bis jetzt war eine Änderung nicht erlaubt. Die Kennwortrichtlinien werden gerade erarbeitet und gesetzt.

     

    Jetzt zum Problem

    Bis jetzt wurden die Kennwörter bei einer Benutzereröffnung zentral vergeben und waren der Informatik somit bekannt. Wenn jetzt jeder Benutzer sein Passwort selbst ändern kann/muss, ist dies nicht mehr der Fall.

    Es kommt oft vor, dass wir Änderungen (Profil des Benutzers) an den Rechnern vornehmen müssen und, wie es bei Windows halt so ist, die Rechner auch öfters neu starten und uns anschliessend ja wieder anmelden müssen. Dies wird ohne Kennwort sehr stark erschwert ,->

    Eine (umständliche) "Lösung" wäre, das Kennwort auf irgend ein Standard-Kennwort zurückzusetzen, welches jedem User bekannt ist/gemacht wird und falls dieser sich mit seinem Kennwort nicht einloggen kann, soll er es mit dem "Support"-Kennwort probieren und nach erfolgreicher Anmeldung das Kennwort wieder ändern. Aber wie will man ihn zur Änderung zwingen?

     

    Gibt es eine saubere Lösung für dieses Problem?

     

    PS: Wir haben noch keine zentrale Softwareverteilung, keine servergespeicherten Profile und nur minimale Gruppenrichtlinen. Aus diesem Grund der Aufwand an den Kisten.

    PPS: "User must change password at next logon" will irgendwie nicht greifen. Erst nach secedit /refreshpolicy ... /enforce melden sich die Kisten. Idee?

     

    Danke für eure Vorschläge!

  9. Hallo hegl

     

    Eine Idee:

    Zuerst würde ich einmal kontrollieren, was beim Systemstart alles mit gestartet wird. Zum Beispiel mit msconfig oder autoruns (AutoRuns for Windows v8.61) von Microsoft.

     

    Anschliessend schauen, zu welchem Zeitpunkt dies genau passiert und mit Process Monitor (Process Monitor v1.01) schauen, was für ein Programm zu diesem "Verbindungszeitpunkt" welche aufrufe tätigt.

     

    Idee 2:

    Alle Dateien auf dem Rechner und die Registry nach "somebody@somecompany.com" durchsuchen lassen.

     

    Idee 3:

    Schauen, was gesendet wird mit Wireshark (Wireshark: The World's Most Popular Network Protocol Analyzer) o.Ä.

     

    Viel Glück!

     

    PS: Du schreibst, dass versucht wird eine Verbindung aufzubauen, blockst du mit einer Firewall?

×
×
  • Neu erstellen...