Jump to content

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


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar
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

Link zu diesem Kommentar

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!

Link zu diesem Kommentar

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."
Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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.
Link zu diesem Kommentar

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

Link zu diesem Kommentar

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) ...

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...