Lokales Administratorpasswort per Script ändern (Sicherheitsproblem)

[Markus Klein]

Hallo liebe Gemeinde,

es geht um eine menge Rechner die in einer Domäne hängen.
Die Mitarbeiter verfügen auf ihren eigenen Kisten über
Administrations-Rechte via Domäne.

Nun soll ich auf allen Rechnern per Script das Administrator-Passwort
ändern.
Ansich kein Problem, per WSH Scripting wirklich nicht schwierig.

Mein Problem liegt beim Passwort ansich. Wie schaffe ich es, dass
keiner das Passwort klauen kann? Das haarige ist, wenn ein User sein
lokales Administratoren Passwort rausbekommen hat, kann er sich damit
auch auf jedem anderen Rechner einloggen!

Meine erste Idee war das Passwort per C++ einzubinden. Bis ich
festgestellt habe, dass diese Methode völlig zwecklos ist, denn egal
wie stark ich die c++ Datei verschlüssele, wird sie im Speicher in
Klarschrift liegen und per debugger ganz einfach auszulesen sein!

Was kann ich tun?

Ein Anfang wäre, wenn kein Domänen-User auf die Freigabe, auf dem das
verschlüsselte Passwort hinterlegt ist, zugreifen darf, sondern nur
das System. Ist das überhaupt möglich?

Über Hilfe würde ich mich sehr freuen,

Gruss

[Winfried Sonntag]

Markus Klein schrieb:

Hallo Markus,

> Mein Problem liegt beim Passwort ansich. Wie schaffe ich es, dass
> keiner das Passwort klauen kann? Das haarige ist, wenn ein User sein
> lokales Administratoren Passwort rausbekommen hat, kann er sich damit
> auch auf jedem anderen Rechner einloggen!

alternativ zu Norberts Antwort in der Scripting Gruppe wäre auch noch
das Script in eine VB6-EXE zu verpacken. Damit sollte es ohne die
Projektdatei auch nicht ausgelesen werden können.

Servus
Winfried
--
Win2000-FAQ: http://w2k-faq.ebend.de
Richtig zitieren: http://got.to/quote
GPO's: www.gruppenrichtlinien.de
W2K Up2date: http://home.arcor.de/jterlinden/index.htm

[Mark Heitbrink [MVP]]

Hi,

Winfried Sonntag schrieb:

> alternativ zu Norberts Antwort in der Scripting Gruppe wäre auch noch
> das Script in eine VB6-EXE zu verpacken.

Etwas einfacher als VB: AutoIT, Script ist ähnlich einer Batchdatei,
also "simpel" zu erstellen und kann zu einer .exe kompiliert werden.

Tschö
Mark
--
Mark Heitbrink - MVP Windows Server
Homepage: www.gruppenrichtlinien.de
W2K FAQ : http://w2k-faq.ebend.de
PM: Vorname@Homepage, Versende-Adresse wird nicht abgerufen.

[Winfried Sonntag]

Mark Heitbrink [MVP] schrieb:

Servus Mark,

>> alternativ zu Norberts Antwort in der Scripting Gruppe wäre auch noch
>> das Script in eine VB6-EXE zu verpacken.
>
> Etwas einfacher als VB: AutoIT, Script ist ähnlich einer Batchdatei,
> also "simpel" zu erstellen und kann zu einer .exe kompiliert werden.

der zeitliche Aufwand dürfte wohl gleich sein. ;-) Kann denn so eine
EXE von AutoIT mit dem Tool auch wieder extrahiert werden? Oder
brauchts da auch sowas wie eine Projektdatei?

[Mark Heitbrink [MVP]]

Hi,

Winfried Sonntag schrieb:

> Kann denn so eine EXE von AutoIT mit dem Tool auch wieder
> extrahiert werden?

Nö. Einmal kompiliert kommst du nicht mehr dran.
Du musst wieder auf die Scriptdatei zurückgreifen.

> Oder brauchts da auch sowas wie eine Projektdatei?

Du brauchst das Script. Ist eine reine Textdatei. Wenn sie
.au3 heisst kann sie per Autoit getestet und ausgeführt
werden. Ist aber wie gesagt PlainText. Script zu exe ist
ein eigenes Tool das dabei ist.

[Winfried Sonntag]

Mark Heitbrink [MVP] schrieb:

Hallo Mark,

> Nö. Einmal kompiliert kommst du nicht mehr dran.
> Du musst wieder auf die Scriptdatei zurückgreifen.

auch nicht schlecht.

> Du brauchst das Script. Ist eine reine Textdatei. Wenn sie
> .au3 heisst kann sie per Autoit getestet und ausgeführt
> werden. Ist aber wie gesagt PlainText. Script zu exe ist
> ein eigenes Tool das dabei ist.

Danke , muß ich mir wohl auch mal ansehen. ;-)

[Markus Klein]

Ich weiss nicht welche Vorteile die Alternative VisualBasic6.0 bzw.
AutoIT gegenüber C++ haben soll. Ich sehe da keine... sorry.

Der Lösungsansatz ist falsch.

[Mark Heitbrink [MVP]]

Hi,

Markus Klein schrieb:

> Ich weiss nicht welche Vorteile die Alternative VisualBasic6.0 bzw.
> AutoIT gegenüber C++ haben soll. Ich sehe da keine... sorry.

Es ging einfach nur um dein Problem ein Passwort in PlainText zu
verwenden. Wenn du dann eben ein Script verwendest,
das zu einer EXE kompiliert ist, existiert das Problem nicht.

Selbst wenn es kurzfristig im Speicher liegen sollte und du mit
einem Debugger rankämst, bräuchtest du nur in dein Script einen
shutdown mit deletepagefile einbauen, für ganz panische Attacken ...

> Der Lösungsansatz ist falsch.

Es hindert dich keiner, an jeden Rechner einzeln heranzugehen.

[Markus Klein]

Hm, dass mit dem Shutdown ist eine Idee !

Auf Deiner Homepage (gruppenrichtlinien.de) habe ich ein Tutorial
gelesen, dass beschreibt wie man ein LogonScript Ausführen kann, bevor
die explorer.exe initialisiert wird (um Registry-Einträge ohne Reboot
zu übernehmen).

Warum ich das sage... vielleicht kann man so das Script ausführen
lassen, bevor ein anderes Programm durch Autostart o.ä. gestartet
werden kann. z.B. einen debugger

Zwei Probleme habe ich noch:

Ist der Reboot wirklich nötig um den Ram und Pagefile.sys zu löschen?
Den bekomme ich sowieso nur durch einen Registry-Eintrag gelöscht
glaube ich.

Wie bekomme ich eine art Freigabe auf die das Script bei der
Ausführung zugreifen kann, die aber sonst für die Domänen-Benutzer
geschlossen bleibt?

[Norbert Fehlauer [MVP]]

Markus Klein wrote:
Hi,
ich hab mal ein paar generelle Frage dazu. Geht es dir darum, dass dein
Passwort nicht im Klartext über die Leitung rutschen soll? Haben bei euch
alle Rechner einen Debugger installiert? Wie oft änderst du das lokale
Adminkennwort?

Nur damit ich nachvollziehen kann warum das für dich ein Problem ist ein
Tool bzw. Script zu verwenden.

Bye
Norbert
--
Dilbert's words of wisdom #11: Last night I lay in bed looking up at
the stars in the sky and I thought to myself, "Where the heck is the
ceiling?!

[Mark Heitbrink [MVP]]

Hi,

Markus Klein schrieb:

> Ist der Reboot wirklich nötig um den Ram und Pagefile.sys zu löschen?
> Den bekomme ich sowieso nur durch einen Registry-Eintrag gelöscht
> glaube ich.

Yepp.

> Wie bekomme ich eine art Freigabe auf die das Script bei der
> Ausführung zugreifen kann, die aber sonst für die Domänen-Benutzer
> geschlossen bleibt?

Einfachere Idee:
Vergiss das Script. denn der User muss zumindest auf die Freigabe
lesend zugreifen dürfen. Als ComputerStartup Script könnte es klappen
allerdings bin ich mir gerade ziemlich sicher, daß dann der "net user"
Befehl nicht funktioniert, da dieser in einem Bentzerkontext ausgeführt
werden muss. Wie das bei anderen "Scripten" aussieht, keine Ahnung.

Also eine Alternative: Computer StartupScript.
Zugfriff nur für die Gruppe der DomänenComputer, damit sind die
User ausgesperrt.

Bessere Idee:
Erstell dir eine Liste aller Computer im AD und verwende psexec
von Sysinternals und eine AdminWorkstation und rufe das Script
Remote auf. Dann kriegt der Client nichts davon mit, daß das
Script überhaupt ausgeführt wird.

Ich denke aber, daß dein Problem mit dem Debugger eher in
den Rahmen einer extremen Ausnahme fällt.

Zudem denke ich, daß die USer schon lokale Amdinrechte haben
müssten, um den Speicher auszulesen, da er in den Bereich
"direkter Zugriff auf Hardware" fällt, würde jetzt aber nicht wetten.

[Mark Heitbrink [MVP]]

Mark Heitbrink [MVP] schrieb:

> Zudem denke ich, daß die USer schon lokale Amdinrechte haben
> müssten, um den Speicher auszulesen,

Gerade noch mal geschaut,
Zuweisen von Benutzerrechten:
Debuggen von Programmen -> "Administratoren"
Das ist die Standardkonfiguration.

Also von daher sehe ich jetzt kein Problem mehr.

[Markus Klein]

Die User haben via Domäne Adminrechte !

Computer Startup Script hört sich echt interessant an. Ich lese mir
grad ein paar Artikel durch. Der Net Use Befehl geht laut
TechNet(Microsoft) :-))

Hm, bist du dir sicher, dass man die Gruppe der Rechner hinzufügen und
die User ausschliessen kann? Habe eine Seite zu dem Thema gefunden,
schade würde das ja jetzt gerne testen aber kann erst morgen wieder
http://www.windowsitpro.com/Article/ArticleID/27330/27330.html

und wozu schreibt der Author des Tutorials das Passwort in die Paramter
der GPO/Add Script? hat das irgendeinen vorteil gegenüber der Methode,
das Passwort einfach in die .bat zu schreiben ? *grübel
http://www.windowsitpro.com/Files/07/27330/Figure_06.jpg

Deine zweite Lösung finde ich nicht gut. Nicht alle Rechner sind jeden
Tag online! Ich müsste also mit Fehlerprüfung arbeiten, damit kein
Rechner vergessen wird! Was ja noch im Bereich des möglichen liegt,
allerdings würde das Passwort doch in klarschrift an hunderte Rechner
übers Netz geschickt - ist das nicht ein bisschen naiv? Microsoft geht
darauf nicht ein - ich weiss es nicht.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/optimize/startw2k.mspx

[Mark Heitbrink [MVP]]

Markus Klein schrieb:

> Die User haben via Domäne Adminrechte !

Gibt es einen zwingenden Grund?
Denn an dieser Stelle ist dein Vorhaben egal wie es gelöst
wird völlig sinnfrei. Du änderst das Admin PW, damit es keiner
kennt. Der Benutzer hat Adminrechte und ändert es wieder ...
wozu der Aufwand?

Selbst wenn er das Kennwort vom Admin nicht kennt, kann er
es wie ihm beliebt setzen, shcliesslich hast du ihn als
lokalen Admin definiert.

Nimms mir nicht übel, aber die restlichen Ideen lese ich nicht,
denn dein Vorhaben ist völlig umöglich, solange die Benutzer
Adminrechte haben.

Nur als Beispiel:
http://www.gruppenrichtlinien.de/HowTo/MusicMatch_als_Benutzer_ausfuehren.htm

Tschö
Mark

[Stefan Kittel]

Hallo....

ist es nicht möglich von einem PC aus das Kennwort eines Benutzers auf einem
anderem PC zu setzen.
Dazu benötigt man Adminrechte auf dem entfernten PC.

Wäre das nicht viel einfacher?

Stefan

"Markus Klein" <wu...@web.de> schrieb im Newsbeitrag
news:1116072237.7...@z14g2000cwz.googlegroups.com...

[Nils Kaczenski [MVP]]

Moin,

Stefan Kittel schrieb:

> Wäre das nicht viel einfacher?

wenn es um Einzelrechner geht, vielleicht.

Gruß, Nils
--
Nils Kaczenski - MVP Windows Server
NEU: www.faq-o-matic.net
Antworten bitte nur in die Newsgroup!
PM: Vorname at Nachname .de
Das MVP-Buch zu Windows XP: http://www.kaczenski.de/content/view/8/27/

[Denis Jedig]

On Tue, 17 May 2005 14:12:37 +0200 Mark Heitbrink [MVP] wrote:

> Markus Klein schrieb:
>> Die User haben via Domäne Adminrechte !
>
> Gibt es einen zwingenden Grund?
> Denn an dieser Stelle ist dein Vorhaben egal wie es gelöst
> wird völlig sinnfrei. Du änderst das Admin PW, damit es keiner
> kennt. Der Benutzer hat Adminrechte und ändert es wieder ...
> wozu der Aufwand?

Ich glaube, was er hat ist eine Konstruktion, bei der der Benutzer nur an
"seiner" Workstation administrative Rechte hat, nicht aber an den anderen.
Trotzdem gilt, dass die Nutzer mit Admin-Rechten in jedem Fall die SAM
auslesen und mit mehr oder weniger Aufwand (aber oft tatsächlich machbar)
offline bruteforcen können.

--
Denis Jedig
syneticon GbR

[Markus Klein]

Nee, das ganze hat einen Sinn sonst würden wir es nicht tun oder?
Also, alle User haben in der Firma Domänen-Adminrechte auf ihrer
Kiste. Bis auf die Administratoren kennt keiner das Lokale
Administrator Passwort - es ist auf fast allen Kisten gleich.

Nun soll es auf allen Kisten geändert werden, da wir schon ewig lange
das gleiche benutzen. obs dir gefällt oder nicht.

Ob es von einzelnen "Freaks" geändert wurde, ist doch jetzt unwichtig.
ich weiss nicht warum dich dieser Punkt so aufregt.

[Markus Klein]

Na ja, um am Thema zu bleiben: ;)

Es ist ganz einfach Möglich das Passwort per Scripting über das Netz
zu setzen.
Nur kann mir keiner sagen wie sicher oder unsicher das ist.

[Norbert Fehlauer [MVP]]

Markus Klein wrote:
Hi,

> Es ist ganz einfach Möglich das Passwort per Scripting über das Netz
> zu setzen.
> Nur kann mir keiner sagen wie sicher oder unsicher das ist.

Weils in dem Fall egal ist wie sicher oder unsicher es ist, da sowieso jeder
auf seiner eigenen Kiste lokaler Admin ist und es damit notfalls auch
rausbekommen kann.

Bye
Norbert

[Walter Steinsdorfer [MVP]]

Hi,

> Nee, das ganze hat einen Sinn sonst würden wir es nicht tun oder?
> Also, alle User haben in der Firma Domänen-Adminrechte auf ihrer
> Kiste. Bis auf die Administratoren kennt keiner das Lokale
> Administrator Passwort - es ist auf fast allen Kisten gleich.

wenn ich Domänen-Adminrechte habe dann interessiert mich i.d.R. das lokale
Adminpasswort überhauptnicht.

--
Viele Grüsse aus dem Münchner Süden

Walter Steinsdorfer [MVP]
www.faq-o-matic.net

[Markus Klein]

Es geht doch darum, dass niemand das Passwort in erfahrung bekommen
soll damit er sich beim Nachbars PC einloggen kann.

[Nils Kaczenski [MVP]]

Moin,

Markus Klein schrieb:

> ich weiss nicht warum dich dieser Punkt so aufregt.

ganz einfach, weil deine Aufregung um potenzielle Lesbarkeit des
Passworts in eurem Fall völlig unsinnig ist. Warum soll sich jemand die
Mühe machen, mit einem Debugger nach Fragmenten einer Applikation im
Arbeitsspeicher oder mit einem Sniffer (in einem vermutlich geswitchten
Netz) nach einem irgendwann eventuell übertragenen Passwort zu suchen,
um ein Passwort herauszubekommen, das er einfach ändern oder dessen
Hashwert er relativ simpel aus dem Original-SAM auslesen kann?

[Walter Steinsdorfer [MVP]]

Hi,

> Es geht doch darum, dass niemand das Passwort in erfahrung bekommen
> soll damit er sich beim Nachbars PC einloggen kann.

du hast da irgendwo einen Denkfehler, wenn ich Domänenadmin bin kann ich das
und noch ein paar andere Dinge sehr einfach.

[Nils Kaczenski [MVP]]

Moin,

Markus Klein schrieb:

> Es geht doch darum, dass niemand das Passwort in erfahrung bekommen
> soll damit er sich beim Nachbars PC einloggen kann.

eine sehr wirksame Methode dagegen ist, kein Standardpasswort für
administrative Konten zu verwenden. Ein Skript, das zufällige, starke
Kennwörter generiert, jeweils eins davon jeder Maschine zuweist und in
einer geschützten Datei protokolliert, ist relativ einfach aufzubauen.
Wenn man dann der Übertragungsmethode nicht traut, sorgt man für eine
IPSec-Verschlüsselung zwischen Admin- und Ziel-PCs.

[Mark Heitbrink [MVP]]

Hi,

Markus Klein schrieb:

> Nee, das ganze hat einen Sinn sonst würden wir es nicht tun oder?

Sagen wir mal so, in den meisten Fällen ist das nicht nötig,
sondern ein Stück Bequemlichkeit.

> Also, alle User haben in der Firma Domänen-Adminrechte auf ihrer Kiste.

Domänen-Adminrechte oder Lokale Adminrechte?
Ersters ist in keinem Konzept eine Lösung , letzteres
wäre unter bestimmten Vorraussetzungen akzeptabel.

> Bis auf die Administratoren kennt keiner das Lokale
> Administrator Passwort - es ist auf fast allen Kisten gleich.

Wer Adminrechte hat, braucht es nicht zu kennen.

> Nun soll es auf allen Kisten geändert werden, da wir schon ewig lange
> das gleiche benutzen. obs dir gefällt oder nicht.

Das macht ja auch Sinn, solange die User als Benutzer arbeiten und nicht
als lokale Administratoren. Ich verstehe den Sinn, warum es geändert
werden soll, ich verstehe nur deine Sicherheitsbedenken im Zusammenhang
mit deinem Benutzerkonzept überhaupt nicht.

> Ob es von einzelnen "Freaks" geändert wurde, ist doch jetzt unwichtig.

Ich muss kein Freak sein, wenn ich Adminrechte habe.
Google: Administrator Passwort ändern

> ich weiss nicht warum dich dieser Punkt so aufregt.

Weil du auf der einen Seite Angst hast, daß man es evtl. mit einem
Debugger aus dem Speicher auslesen könnte, den ein Normalsterblicher
nicht mal bedienen kann, du aber auf der anderen Seite mit Benutzern
arbeitest, die sich die Arbeit mit dem Debugger garnicht erst machen
müssen, da sie nur die Lokale Benutzerverwaltung aufrufen müssen und
diese ist wesentlich leichter zu finden, als ein Debugger zu bedienen.

Du verstrickst dich da meiner Meinung nach gerade im kleinen und
vergisst das große. Du flickst ein kleines Loch im Dach, hast aber
überhaupt keine Seitenwände, die den Regen abhalten könnten.

> Es ist ganz einfach Möglich das Passwort per Scripting über das
> Netz zu setzen.

Da haben wir ja jetzt diverse Möglichkeiten diskutiert.

> Nur kann mir keiner sagen wie sicher oder unsicher das ist.

Ein Script (VB, Batch) wäre auf jeden Fall unsicher, da es zumindest
mit Leserechten für den ausführenden hinterlegt werden muss und das
PW dann als Klartext drinsteht. Das scheidet also aus.

Als kompilierte EXE per psexec übers Netz aufgerufen find ich das
neue PW in den Paketen nicht wieder im Gegensatz zu einem
psexec \\zielrechner net user administrator neuesPW
Diese Befehlszeile ist komplett wiederzufinden.

Als exe habe ich den gleichen Befehl per AutoIt Script2Exe verwendet.

[Markus Klein]

ist ja gut. ich sage nichts mehr :-)

Man kann also tatsächlich das Passwort herausfinden? Ich wusste bisher
nur von tools die das überschreiben können

[Nils Kaczenski [MVP]]

Moin,

Markus Klein schrieb:

> Man kann also tatsächlich das Passwort herausfinden? Ich wusste bisher
> nur von tools die das überschreiben können

nein, das Passwort selbst lässt sich nicht auslesen - schon deshalb
nicht, weil es nirgends gespeichert wird. Man kann aber mit ein bisschen
Know-how den gespeicherten Hashwert auslesen (oder abfangen) und dann
versuchen, das passende Passwort dazu zu finden. Das ist dank geeigneter
Tools aber i.d.R. recht einfach - ein wirksames Gegenmittel sind
/wirklich/ komplexe Kennwörter.

[Nils Kaczenski [MVP]]

Moin,

Mark Heitbrink [MVP] schrieb:

> Ein Script (VB, Batch) wäre auf jeden Fall unsicher, da es zumindest
> mit Leserechten für den ausführenden hinterlegt werden muss und das
> PW dann als Klartext drinsteht. Das scheidet also aus.

das trifft zu, wenn wir von Anmeldeskripts reden. Es trifft aber nicht
zu, wenn wir von einem Zentralskript reden, das über ADSI oder WMI (oder
wie auch immer) remote die Kennwörter ändert. Denn in dem Fall wird auf
dem Ziel-PC überhaupt nichts direkt ausgeführt und liegt daher auch
nicht im Speicher rum.

[Markus Klein]

Ja, ich meinte ein zentrales ADSI Script. Bin schon dabei es zu
schreiben... eins das für jede Kiste ein Randompasswort setzt.

@Nils, entscheid dich mal :) kann man ein komplexes
Administratorpasswort durch den Hashwert rekonstruieren oder nicht?

@Mark Heitbrink Es geht nur darum das Lokale Administratorpasswort von
500 REchnern zu ändern. Nicht darum, die User davon zu hindern. Das
Problem ist an der ganzen Sache ist folgendes: wenn EIN User das
Passwort von seiner Kiste herausfindet, kann er sich mit diesem
Passwort auf jedem anderen Rechner als lokaler Administrator
einwählen.

[Walter Steinsdorfer [MVP]]

Hi,

> @Nils, entscheid dich mal :) kann man ein komplexes
> Administratorpasswort durch den Hashwert rekonstruieren oder nicht?

>
> @Mark Heitbrink Es geht nur darum das Lokale Administratorpasswort von
> 500 REchnern zu ändern. Nicht darum, die User davon zu hindern. Das
> Problem ist an der ganzen Sache ist folgendes: wenn EIN User das
> Passwort von seiner Kiste herausfindet, kann er sich mit diesem
> Passwort auf jedem anderen Rechner als lokaler Administrator
> einwählen.

Wozu, wenn er doch domänenadmin ist ? Lies doch mal Marks Posting, er hat es
sehr plastisch dargestellt.

[Norbert Fehlauer [MVP]]

Markus Klein wrote:
Hi,

> Passwort von seiner Kiste herausfindet, kann er sich mit diesem
> Passwort auf jedem anderen Rechner als lokaler Administrator
> einwählen.

Richtig. Und das ist auch kein Problem solange man lokaler Admin ist. Dazu
ist es im Endeffekt wurscht ob das Teil im Klartext über die Leitung rutscht
oder nicht. Denn ich mache mir dann gar nicht erst die Arbeit mittels
Sniffer o.ä. sondern lese einfach die lokale SAM aus. Insofern ist es
natürlich günstiger auf jedem PC ein anderes Kennwort zu verwenden.

Bye
Norbert

[Mark Heitbrink [MVP]]

Hi,

Markus Klein schrieb:

> @Mark Heitbrink Es geht nur darum das Lokale Administratorpasswort von
> 500 REchnern zu ändern. Nicht darum, die User davon zu hindern. Das
> Problem ist an der ganzen Sache ist folgendes: wenn EIN User das
> Passwort von seiner Kiste herausfindet, kann er sich mit diesem
> Passwort auf jedem anderen Rechner als lokaler Administrator
> einwählen.

Ich glaube, wir reden etwas aneinander vorbei.

Ihr habt es also so gelöst, das jeder Benutzer an _seinem_
Rechner lokale Adminrechte hat, aber nicht an jedem Rechner
an dem er sich anmeldet?
zb an jedem Rechner per
net localgroup Adminstratoren derBenutzer /add

Oder habt ihr mit der GPO und "Eingeschränkte Gruppen" gearbeitet?
Dann hätte er die Rechte an jedem Rechner, wenn ihr nicht mit
500 GPOs oder 500 DSACls Filtern auf einer GPO gearbeitet habt.

Wenn er nur an seinem Rechner Adminrechte hat, dann würde ich
die Lösung über einen Remoteaufruf von einer Workstation oder
vom Server aus oder ein ComputerstartupScript bevorzugen.

[Walter Steinsdorfer [MVP]]

Hallo Mark,

>
> Ich glaube, wir reden etwas aneinander vorbei.
>
> Ihr habt es also so gelöst, das jeder Benutzer an _seinem_
> Rechner lokale Adminrechte hat, aber nicht an jedem Rechner
> an dem er sich anmeldet?
> zb an jedem Rechner per
> net localgroup Adminstratoren derBenutzer /add

ich glaubs auch. Der OP hat vorher gepostet, das bei ihm eh alle DomAdmins
sind (vgl. news://1116331336....@g47g2000cwa.googlegroups.com.
Nachdem die DomAdmins Mitglied in der Gruppe der lokalen Admins sind (so wie
der lokale Admin auch) kann ich immer noch nicht den Sinn der Aktion
erkennen ? Hilft mir jemand auf die Sprünge ?

[Markus Klein]

>Ihr habt es also so gelöst, das jeder Benutzer an _seinem_
>Rechner lokale Adminrechte hat, aber nicht an jedem Rechner
>an dem er sich anmeldet?

genau. Jeder MA hat nur an seinem Rechner Administratoren Rechte via
Domäne.

>Wenn er nur an seinem Rechner Adminrechte hat, dann würde ich
>die Lösung über einen Remoteaufruf von einer Workstation oder
>vom Server aus oder ein ComputerstartupScript bevorzugen.

ja, so weit war ich auch schon :-) Nur welche ist am besten. Gibt es
denn jetzt die Möglichkeit Computerstartupscript vor dem Domänen-User
mit lokalen Administratoren-Rechten zu schützen ?

[Norbert Fehlauer [MVP]]

Markus Klein wrote:
Hi,

> genau. Jeder MA hat nur an seinem Rechner Administratoren Rechte via
> Domäne.

Klärst du uns bitte mal auf wie du das bewerkstelligt hast? Das sorgt ja
schon weiter oben für Unklarheiten.

Danke
Norbert
--
Dilbert's words of wisdom #11: Last night I lay in bed looking up at
the stars in the sky and I thought to myself, "Where the heck is the
ceiling?!

[Markus Klein]

der MA erlangt an seiner Kiste Adminrechte, indem ich(domänen-admin)
ihn(domänen-user) in der lokalen _Administratorengruppe_ hinzufüge.
er hat somit Adminrechte wenn er sich an der Kiste über die Domäne
anmeldet.

Mir ging es darum dem lokalen _user_ administrator das passwort zu
ändern :-) und zwar automatiesiert per LogonScript oder ServerScript.

nacht!

[Norbert Fehlauer [MVP]]

Markus Klein wrote:
Hi,

> der MA erlangt an seiner Kiste Adminrechte, indem ich(domänen-admin)
> ihn(domänen-user) in der lokalen _Administratorengruppe_ hinzufüge.
> er hat somit Adminrechte wenn er sich an der Kiste über die Domäne
> anmeldet.

OK. Also händisch bei 500 PCs.

> Mir ging es darum dem lokalen _user_ administrator das passwort zu
> ändern :-) und zwar automatiesiert per LogonScript oder ServerScript.

Das ist mir schon klar. Nur versteh ich's immer noch nicht warum du dir um
Debugger und Sniffer sorgen machst aber lauter lokale Admins hast.

Moin.

Norbert
--
Dilbert's words of wisdom #19: Am I getting smart with you? How would
you know?

[Mark Heitbrink [MVP]]

Hi,

Norbert Fehlauer [MVP] schrieb:

> Nur versteh ich's immer noch nicht warum du dir um Debugger und
> Sniffer sorgen machst aber lauter lokale Admins hast.

Ganz einfach:
Der User ist nur an seinem Rechner Admin. An jedem anderen ist
er Benutzer. Würde er das Kennwort des lokalen AdminAccounts
kennen, könnte er sich an einem anderen Rechner ebenfalls vom
Benutzer zum Admin hochstufen. Deswegen, die Ganze Bastelei.

Das er an seiner Kiste machen kann was er will, haben wir
ja geklärt, es geht jetzt nur darum, daß er das nicht auch
noch an den anderen Rechnern kann.

So einfach ist das, wenn man es verstanden hat :-)

[Mark Heitbrink [MVP]]

Markus Klein schrieb:

> Nur welche ist am besten. Gibt es denn jetzt die Möglichkeit
> Computerstartupscript vor dem Domänen-User mit lokalen
> Administratoren-Rechten zu schützen ?

Was du versuchen kannst:
ComputerStartupScript, eine einfache Batch mit einem Verweis auf eine
weitere Batch in einem UNC, denn im SYSVOL, wo das Script liegen würde
darf jeder lesen und an diesen Default Einstellungen sollte man die
Finger von lassen.

1. Batch (zB startup.bat)
call \\deinserver\diefreigabe\changepw.bat

2. Batch (changepw.bat)
net user administrator neuesPasswort

Auf \\deinserver\diefreigabe\ Vergibst du als Share und NTFS
Berechtigungen nur Leserechte für Domänen-Computer (DomAdmin
nicht vergessen, sonst kommst du nicht mehr dran ...)

Nächste Alternative: Wahrscheinlich die einfachste
Da ich gerade etwas AutoIT vernarrt bin nehme ich den Befehl von
gerade und compiliere ihn als EXE. Dann kann keiner, auch wenn er
die EXE öffnet das PW "sehen".

Die EXE hinterlegst du als LoginScript für die Benutzer, da sie ja
das Recht haben das lokale AdminPW zurückzusetzen. Die EXE kannst
du jeden Monat aktualisieren und ein anderes PW setzen.

Script für AutoIT, ist völlig simpel
Run("net user Administrator neuesPW", "", @SW_HIDE)
... das wars schon. Mit @SW_HIDE wird das Fenster nicht angezeigt.

Nächste Alternative: Aufwendiger aber mit PUSH Funktion:
psexec + Batch (oder .exe) + Liste aller Computer.

Eine Liste mit allen Computer braucht man ständig, also von daher
garnicht so verkehrt. Jetzt brauchst du nur eine Batch, die als
Schleife arbeitet und den Befehl anhand der Liste aller Computer
auf jedem einmal ausführt.

Ist noch relativ simpel:
for /f %%a in (liste.txt) do "psexec \\%%a ..."

Aus der internen Hilfe:
| Mit diesem Befehl wird die Datei MeineDat.txt zeilenweise eingelesen,
| wobei Zeilen, die mit einem Semikolon beginnen, überlesen [...] werden

Jetzt fällt mir wirklich nichts mehr ein, mangels Programmierkenntnissen.
Die Entscheidung muss du jetzt selber finden. Der Einfachheithalber
präferiere ich die EXE im Benutzer Login Script.
Einfach zu benutzer, leicht zu ändern und sicher, da das PW in der
EXE nicht in Klartext zu finden ist.
Die letzte Alternative hat den Vorteil, daß man damit eine Vorlage
hat um beliebige Befehle an jedem Rechner auszuführen, was sich
oft genug ergibt.

[Nils Kaczenski [MVP]]

Moin,

Markus Klein schrieb:

> @Nils, entscheid dich mal :)

hab ich schon.

> kann man ein komplexes
> Administratorpasswort durch den Hashwert rekonstruieren oder nicht?

Man /kann/ immer, es ist nur eine Frage des Aufwands. Die Hashfunktion
ist eine Einwegfunktion: Dasselbe Passwort erzeugt immer denselben Hash,
aber aus dem Hash lässt sich das Passwort nicht zurückrechnen. Hier muss
dann ein Brute-Force-Angriff erfolgen: Man probiert einfach Passwörter
aus und guckt, ob zufällig der passende Hash rauskommt. Je nach Länge
des Passworts (und Konfiguration des Netzwerks) kann das mit heutigen
Rechnern sehr schnell gehen.

Kurze komplexe Kennwörter helfen nicht ernsthaft, weil es im Internet
bereits Hash-Datenbanken gibt: Mit Grid-Technik wurden gezielt für alle
möglichen Passwörter bestimmter Längen die Hashes berechnet und in der
Datenbank ablegegt. Habe ich nun einen Hash und die Datenbank, kann ich
in Millisekunden abfragen, ob das passende Kennwort bekannt ist. Vor
dieser Methode schützen nur wirklich lange und komplexe Kennwörter, weil
es da (noch) nicht zu machen ist, sämtliche Kombinationen auszuprobieren.

Siehe dazu auch die hervorragenden Artikel von Jesper M. Johansson auf
Microsoft TechNet, z.B.:
http://www.microsoft.com/technet/community/columns/secmgmt/sm1004.mspx

[Norbert Fehlauer [MVP]]

Mark Heitbrink [MVP] wrote:
Hi Mark,

> Ganz einfach:
> Der User ist nur an seinem Rechner Admin. An jedem anderen ist
> er Benutzer. Würde er das Kennwort des lokalen AdminAccounts
> kennen, könnte er sich an einem anderen Rechner ebenfalls vom
> Benutzer zum Admin hochstufen. Deswegen, die Ganze Bastelei.

Das ist mir schon klar. Allerdings hilft dann wirklich nur für jeden PC ein
eigenständiges Passwort (nicht durchnummeriert oder sowas). Denn wenn ich
auf meinem PC das Kennwort rauskriege (durch lokale SAM) dann hab ich auch
alle anderen.

> Das er an seiner Kiste machen kann was er will, haben wir
> ja geklärt, es geht jetzt nur darum, daß er das nicht auch
> noch an den anderen Rechnern kann.
>
> So einfach ist das, wenn man es verstanden hat :-)

Verstanden hab ich das wie gesagt schon länger, nur den Aufwand von wegen
Debugger usw. ist mir immer noch unklar da ja doch jeder an seiner Kiste
lokaler Admin ist. Aber ich gebs auf und nehms hin.

Bye
Norbert