Ist es gefährlich sich als Domain Admin auf einem Client anzumelden?

[Johannes80 10]

Hi Leute,

 

ich hab grad in meiner Firma eine interessante Diskussion angeregt. :D

Es handelt sich um einen Umgebung mit W2k3 Server und W2k und XP Clients.

 

Und zwar gehts darum wie ein Admin seine Clients administriert.

Was spricht dagegen, das mit dem Domain Admin zu tun?

Was spricht dafür?

 

Wie sieht es aus wenn das Admin Profil auf einem Client liegt und ein Benutzer lokale Admin rechte hat, kann er dann das Domain Admin Passwort herausfinden und wenn ja wie? Wo liegt diese Passwort Datei?

 

Was meint ihr zu dem Thema?

 

lg. Joe

[carlito 10]

Wie sieht es aus wenn das Admin Profil auf einem Client liegt und ein Benutzer lokale Admin rechte hat, kann er dann das Domain Admin Passwort herausfinden

 

Nein.

 

Wo liegt diese Passwort Datei?

 

Es gibt keine lokale Passwort Datei, da die Authentifizierung durch ADS erfolgt.

 

Was meint ihr zu dem Thema?

 

Dieses Thema hatten wir schon mal:

http://www.mcseboard.de/showthread.php?t=92039

[Johannes80 10]

hmm,

 

Wo liegt diese Passwort Datei?

Es gibt keine lokale Passwort Datei, da die Authentifizierung durch ADS erfolgt.

 

also das kann ich mir so nicht vorstellen, denn ein Benutzer kann sich ja auch wenn er nicht mit einem DC verbunden ist anmelden, also muss sein Passwort irgendwo lokal liegen! Ist das wie in der guten alten NT4.0 Zeit nich die Sam-Datei?

 

Dieses Thema hatten wir schon mal:

http://www.mcseboard.de/showthread.php?t=92039

Nein mein Thema zielt jetzt nicht aufs Installieren sondern auf die Sicherheit hin!

[IThome 10]

Die Credential-Sätze werden verschlüsselt in der Registry gespeichert

HKLM\SECURITY\Cache

Schau mal hier ...

http://thelazyadmin.com/index.php?/archives/343-Understanding-Cached-Credentials.html

!Windows 2000/XP and 2003 does not cache the credentials directly, what it does is store an encrypted verifier. This verifier is uses what is termed a "salted" MD4 hash that is computed two times that leaves a hash of the hash of the credentials. This verifier cannot be used to log on from any other computer."

[carlito 10]

also das kann ich mir so nicht vorstellen, denn ein Benutzer kann sich ja auch wenn er nicht mit einem DC verbunden ist anmelden, also muss sein Passwort irgendwo lokal liegen!

 

Hast Recht.

 

Ist das wie in der guten alten NT4.0 Zeit nich die Sam-Datei?

 

Nein. Wie bereits gesagt, werden die Daten verschlüsselt in der Registry gespeichert. Es gibt jedoch Tools, die diese Informationen auslesen und die Hashes anzeigen können.

[Gadget 37]

Moin,

 

u. wenn du es ganz genau wissen willst stehts hier:

 

Security Management - October 2005

http://www.microsoft.com/technet/community/columns/secmgmt/sm1005.mspx

 

richtig ausführlich, da es da auch ein paar Unterschiede zwischen LM, NTLM u. NTLMv2 gibt.

 

Neither the NT hash nor the LM hash is salted. Salting is a process that was first used on UNIX-based computers over 20 years ago. On those computers password hashes were stored in a world-readable file. A user could simply search the file for any other users who had the same stored hash. If any were found, it would mean they shared the same password. To solve this problem, the designers of the UNIX operating system decided to salt the passwords prior to storing them. The process of salting combines the password with a small number the salt - before computing the OWF. The salt could be stored in clear text in the password file. This ensured that two users with the same password had two different password representations stored. Windows has never stored hashes in world-readable form, so there has never been a need to salt them.

 

LG Gadget

[IThome 10]

Das in dem Artikel gilt auch für Credentials, nicht nur für Passwörter ?

[Gadget 37]

Das in dem Artikel gilt auch für Credentials, nicht nur für Passwörter ?

 

Von Credentials wird weiter unten im Artikel gesprochen:

 

Since January 2005, cracking against the stored password verifier (the cached credential) has received renewed interest due to the publication of the first commonly available tool to extract those verifiers from a compromised computer. Cracking the password verifier is reasonably efficient, taking roughly three times longer than cracking against the NT hashes. This, however, is really not an interesting attack either. First, the verifier is a hash of a hash, making it at least twice as resilient as the original hash. Second, since the password verifier is salted with the username it is unique even for two users using the same password. While a pre-computed hash attack can still be used to speed up the first computation, it is useless against the second hash. Finally, the password verifier serves a very important purpose.

[IThome 10]

Danke, ist also relativ sicher ... :)

[Gadget 37]

Wobei grundsätzlich andere Auth-Methoden wohl besser wären aber leider bei uns dafür die finanziellen Mittel nicht zur Verfügung gestellt werden. SmartCard o. RSA-Token wäre schon besser.

 

Ich bin da ein bisserl weniger optimistisch wie Jesper, da ich bei uns nur sehr schwer dran glauben kann meine Leute dazu zu bringen sichere Passwörter zu verwenden u. wenn wir ehrlich sind, schaffen wir es als IT´ler den selber ein Passwort definitiv nur für eine Ressource zu verwenden. Naja ich lenke ein bisserl vom Thema ab, sorry aber solche grundsätzlichen Security-Fragen bewegen mich doch sehr.

 

Much of the current commonly accepted wisdom about passwords, including all the arguments that we need account lockout turned on, is based on the assumption that people cannot be trained to use good passwords. However, if people cannot be trained to use a password that is resilient against a guessing attack, then we must also assume that we cannot train them not to trade it for chocolate to the first person who asks. If we have to give up all hope of training our people then security will be a losing battle forever. Attackers will always find a way around it by exploiting people, and people will always remain the weak link. Attackers who focus on our people will be much more successful than those who focus on technical attacks and we will never be able to prevent this. The thought that people can be trained to perform rudimentary security-related actions is what keeps me going to work. Please do not spoil that for me.

 

LG Gadget

[IThome 10]

Ja, das Problem habe ich auch, die lieben Kennwörter. Implementiert man sichere Kennwortrichtlinien, setzt man den ganzen Tag Kennwörter zurück oder überall kleben Zettel. Und die anderen Möglichkeiten sind leider relativ teuer (wenn man bedenkt, dass es schon schwierig ist, dem Kunden einen richtigen Server oder eine vernünftige Firewall zu verkaufen) ...

[nobex 10]

Um nochmal auf das ursprüngliche Szenario zurückzukommen:

Ich finde es in diesem Fall doch sehr kritisch, mit domänenweiten Admin-Accounts zu arbeiten denn wenn der User einen Keylogger installiert hat, braucht er gar nicht erst nach verschlüsselt hinterlegten Kennwörtern zu suchen.

[Johannes80 10]

ja klar wenn er einen keylogger drauf hätte ;-)

Aber ich vertrau in dem Fall wirklich auf unseren Viren Scanner der so ein Programm sicher gleich entdeckt und auch eine dementsprechende Warnung an uns schickt.

 

hat nochirgendjemand Argumente, die dagegen spechen mit einem Domänen Admin auf einem Client Pobleme zu lösen?

 

lg. Joe

[nobex 10]

ja klar wenn er einen keylogger drauf hätte ;-)

Aber ich vertrau in dem Fall wirklich auf unseren Viren Scanner der so ein Programm sicher gleich entdeckt und auch eine dementsprechende Warnung an uns schickt.

Ich denke, mit lokalen Admin-Rechten könnte man auch da was tricksen ...

[cschra 10]

Dazu müsste man lokal im hklm schreiben dürfen. Geht definitv als lok. Admin. Und auch nicht jeder Virenscanner erkennt einen Keylogger als Virus an. Generell die Grundidee einem User lokale Adminrechte zu verpassen, dabei aber dann den Gedanken dazu verlieren, der User könnte das Domänenadminpasswort ausspionieren finde ich doch etwas paradox.