none
lokales Adminpasswort Clients ändern über GPO RRS feed

Antworten

Alle Antworten

  • Hi,
     
    Am 09.07.2015 17:19, schrieb -Dirk-:
    > Ich möchte gerne auf einen Schlag alle lokalen Adminpassworte auf den
    > Clinets ändern.
     
    Das Thema ist leider seit letztem Jahr März durch ein Sicherheitsupdate
    nicht mehr möglich. Die beste Lösung ist jetzt aus meiner Sicher: LAPS
     
    Local Administrator Password Solution (LAPS)
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Donnerstag, 9. Juli 2015 16:17
  • Hi Mark,

    danke, ich hab LAPS mal installiert und damit rumgespielt. Was ich nicht ganz verstehe ist: Wie setze ich ein ganz bestimmtes Passwort?

    Die GUI des Tools schlägt mir ein PW vor gemäß der GPO-Einstellungen, z. Bsp. "0{#KuCC5H8" und dieses kann ich dann setzen.

    Wie aber setzte ich ein von mir gewähltes PW, und das auch noch für alle Clients gleich?


    Viele Grüße Dirk

    Freitag, 10. Juli 2015 08:24
  • Hi,
     
    Am 10.07.2015 10:24, schrieb -Dirk-:
    > [LAPS] Wie setze ich ein ganz bestimmtes Passwort?
     
    Garnicht. Das ist ja der Trick. Brauchst du nicht. Es wird dynamsich
    generiert und jemand, den du berechtigst, darf es immer über die GUI
    auslesen, sobald er es braucht.
     
    > Wie aber setzte ich ein von mir gewähltes PW, und das auch noch für alle
    > Clients gleich?
     
    Garnicht. Das ist ja das Sicherheitsrisiko, gegen das LAPS gebaut wurde.
     
    Lies mal:
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Freitag, 10. Juli 2015 09:30
  • Hmm, und wenn ich den Client aus irgendwelchen Gründen aus der Domäne nehmen muss - wie soll ichs dann auslesen?

    Viele Grüße Dirk

    Freitag, 10. Juli 2015 10:16
  • Am 10.07.2015 12:16, schrieb -Dirk-:
    > Hmm, und wenn ich den Client aus irgendwelchen Gründen aus der Domäne
    > nehmen muss - wie soll ichs dann auslesen?
     
    Mitdenken, vor dem löschen lesen. :-)
    Oder mit utilman.exe/sethc.exe neusetzen.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Freitag, 10. Juli 2015 10:30
  • mit Mitdenken hat das nichts zu tun. Hattest Du noch nie Techber, die nach einem Crash oder wegen Vollmond sich plötzlich nicht mehr an der Domäne anmelden konnten, Selten, aber es kommt vor. Ich weissnicht, ob LAPS das Richtige ist, vermutlich ist der 'Remote-Turnschuh' angesagt :-)

    Viele Grüße Dirk

    Freitag, 10. Juli 2015 10:39
  • Hi Dirk,

    in diesem Fall gilt doch das zuletzt konfigurierte Kennwort, das Du weiterhin aus dem AD auslesen kannst.


    Gruß

    Ben

    MCSA Windows 8 (.1) MCSA Windows Server 2012 (R2)

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Freitag, 10. Juli 2015 11:32
  • ja, solange das Computerobjekt noch existiert bzw. nicht korrupt ist.

    Ich finde die Lösung/Implementation zu aufwändig für das, was sie bringt. Ich werde von Hand das lokale AdminPW in ein komplexes und sicheres PW ändern.


    Viele Grüße Dirk

    Freitag, 10. Juli 2015 11:35
  • 1. Für gelöschte Computerobjekte gibt es entweder den AD-Papierkorb oder die Tombstone Lifetime - und hattest Du schon mal den Fall, dass Du Dich an einem Computer erst nach 180 Tagen mal anmelden musstest...? ;-)

    2. Ich persönlich hatte noch nie den Fall, dass ein Objekt im AD korrupt war...

    Genau dieses Problem hatte ich auch, als wir gemerkt haben, dass das vordefinierte Kennwort auf diversen neu ausgerollten PCs nicht stimmte - ich hab das dann erstmal (auch wenn sicherheitstechnisch absoluter Unsinn) per GPO und Startskript versucht, zu korrigieren.

    Die LAPS-Lösung finde ich aber wesentlich besser, weil sie mir automatisiert sichere und vor allem individuelle Kennwörter auf allen Geräten ausrollt. Also nichts mehr mit Turnschuh ;-)


    Gruß

    Ben

    MCSA Windows 8 (.1) MCSA Windows Server 2012 (R2)

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Freitag, 10. Juli 2015 11:59
  • Am 10.07.2015 12:39, schrieb -Dirk-:
    > [...] sich plötzlich nicht mehr an der Domäne anmelden konnten
     
    Für die 3mal im Jahr? Das Computerkonto ist dann noch vorhanden und in
    dessen Attributen steht das Kennwort noch drin.
     
    a) normalerweise hast du im LAN überhaupt keine lokalen Konten
    b) Das Adminkonto (RID 500) ist deaktiviert
     
    In dem Scenario hast du sowieso das Problem mit einem Computer, den du
    aus dem AD genommen hast.
     
    Boot CD -> Eingabeaufforderung -> utilman.exe/sethc.exe tauschen
    Reboot -> net user Administrator /active:yes dann net user Administrator
    "meinKennnwort"
     
    fertig. Kein Aufwand, kein Stress.
     
    Dafür aber:
    Individuelle Kennworte, Reduktion der PtH Angriffe, Automatismus ohne
    "plaintext" Verteilung über Netzwerk, die Chance "Tagesadmins" zu bauen,
    zentrale Ablage, das Kennwort spricht sich nicht rum, usw.usw.
     
    Turnschuh ist keine Alternative.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Freitag, 10. Juli 2015 12:02
  • ja, nachvollziehbar.

    Wenn die LAPS-Lösung nun auch noch vorgegebene (komplexe) PWs ausrollen könnte, dann wär sie ganz toll.

    Ja, es kann schon mal es sein, dass Rechner älter als 180 Tage nicht an der Domäne waren (Praktikantenrechner, Laptops aus dem Pool etc)


    Viele Grüße Dirk

    Freitag, 10. Juli 2015 12:03
  • Am 10.07.2015 14:03, schrieb -Dirk-:
    > Wenn die LAPS-Lösung nun auch noch vorgegebene (komplexe) PWs ausrollen
    > könnte, dann wär sie ganz toll.
     
    äh ... hast du dir einfach mal die ADMs dazu angeschaut?
     
    Die Mindestlänge ist 8, die maximale 64 und im Gegensatz zur normalen
    Komplexität, kannst du aus 4 Optionen wählen:
     
    Large letters
    Large letters + small letters
    Large letters + small letters + numbers
    Large letters + small letters + numbers + specials
     
    Ich verwende bei den Kunden 16 Zeichen + Option 3
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Freitag, 10. Juli 2015 12:40
  • ja, klar, hab ich gesehen. Das ist ja auch nett und gut so. Wenn man jetzt noch ein PW, dass den GPO-Vorgaben entspricht, optional per Hand eingeben könnte, dann wärs für mich das Richtig.

    Viele Grüße Dirk

    Freitag, 10. Juli 2015 12:43
  • Am 10.07.2015 14:43, schrieb -Dirk-:
    > ja, klar, hab ich gesehen. Das ist ja auch nett und gut so. Wenn man
    > jetzt noch ein PW, dass den GPO-Vorgaben entspricht, optional per Hand
    > eingeben könnte, dann wärs für mich das Richtig.
     
    Kannst du ja. Du definierst das Kennwortablaufdatum über die LAPSGUI
    oder Powershell auf den 31.12.2115 und überschreibst das von LAPS
    gesetzte per Hand. Du kannst auch das eigene dann in dem AD Attribut
    dokumentieren.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Montag, 13. Juli 2015 08:47
  • Hi Mark,

    wo überschreibe ich das vorgeschlagen KW? In der LAPSGUI lässt es sich nicht überschreiben.


    Viele Grüße Dirk

    Montag, 13. Juli 2015 12:18
  • Hi,
     
    Am 13.07.2015 14:18, schrieb -Dirk-:
    > wo überschreibe ich das vorgeschlagen KW?
     
    per Hand am PC. Dafür gibt es keinen Verteil-Automatismus.
     
    Ganz ehrlich: Das macht ja keinen Sinn, wozu willst du dasselbe Kenwort
    bei mehreren PCs?
    Du hast damit ein Sicherheitsproblem, aber das ist evtl. zu theoretisch.
    Die Frage ist aus der Praxis ist, wozu soll ich ein Kennwort manuell
    setzen, das ich kenne? Ich muss es nicht kennen, Ich kann ja jederzeit
    nachschauen, wenn ich es brauchen sollte.
     
    Wenn es jemand zur "weitergabe" braucht, dann muss er damit leben, daß
    es etwas umständlicher ist als "Passw0rd" und es nach Zeitfaktor "x"
    wieder geändert wird.
     
    Es geht um den lokalen Adminaccount, den brauchst du normalerweise 1mal
    im Jahr, dann schau einfach nach.
     
    ... oder Scripte es, Computer Startup Script, eine Zeile, bzw. ein
    Befehle mit Parameter:
    net user administrator "MeinKennwortistgeheim"
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Montag, 13. Juli 2015 13:00
  • Hi Mark,

    das theoretische Sicherheitsproblem ist mir bekannt, es ist aber überschaubar und tolerierbar, da nur auf den lokalen Admin begrenzt, keinen Domänenzugriff damit.

    Du hast recht, man braucht es wirklich recht selten, nur im Fehlerfall und wenn der PC nicht mehr in der Domäne ist.

    Ich habe es mittlerweile von Hand an den meisten PCs geändert, insofern lassen wirs gut sein.

    Danke Dir herzlich für Deine Antworten und die Mühe.


    Viele Grüße Dirk

    Montag, 13. Juli 2015 13:08
  • Hi,
     
    Am 13.07.2015 15:08, schrieb -Dirk-:
    > insofern lassen wirs gut sein
     
    Jau :-)
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Montag, 13. Juli 2015 13:54
  • das theoretische Sicherheitsproblem ist mir bekannt, es ist aber überschaubar und tolerierbar, da nur auf den lokalen Admin begrenzt, keinen Domänenzugriff damit.

    Aber wenn das lokale Administratorkennwort auf allen Rechnern gleich ist, hat der lokale Administrator eines Rechners doch auch Zugriff auf alle anderen Rechner.

    Freitag, 17. Juli 2015 04:30
  • ja, das stimmt. Das lokale Adminpasswort ist nur für administrative Zwecke, d.h. es ist niemand (ausser Admins) bekannt und wird nicht von normalen Benutzern genutzt. Es unterscheidet sich vom lokalen Serveradminpasswort und vom Dom-Adminpasswort.

    Viele Grüße Dirk

    Freitag, 17. Juli 2015 04:36
  • und dann baut man nicht nochmal nen domain subadmin user (ohne rechte in der Domain) und fügt den per gpo jeder maschine als lokalen admin hinzu? wenns eh nur administrativ ist?

    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Freitag, 17. Juli 2015 07:22
  • Nein, denn wenn der Client sich nicht mit der Domain kontaktieren kann (aus vielerlei Gründen) und der Subadmin noch nicht angemeldet war, dann meldet er sich auch nicht mehr an.

    Viele Grüße Dirk

    Freitag, 17. Juli 2015 07:24
  • Was bitteschön ist "ein Domain Subadmin User (ohne Rechte in der Domain)"?

    Ansonsten ist es meiner Ansicht nach ein Sicherheitsrisiko, auf allen Rechnern einen administrativen User mit dem gleichen Passwort zu haben. (Nehmen wir an, das Gerät muss repariert werden, du gibst irgendeinem Techniker das Passwort dieses Users - schon hat er administrativen Zugriff auf alle deine Rechner.)

    Freitag, 17. Juli 2015 07:26
  • Er meint sicherlich, dem Subdomainadmin das Anmelden auf den DomänenServer zu verbieten.

    PCs werden nur vor Ort repariert, im Beisein des Admins. Sollte eine Mitnahme oder ein Einschicken nötig sein, wir die HDD gesichert und gelöscht bzw. eine leere HDD eingebaut.

    Das einzigste Sicherheitsproblem, das ich hier sehe, ist (auch bei komplexem und langem Admin PW):

    - der physikalische Zugriff (dann aber spielt das PW überhaupt keine Rolle mehr, da jederzeit mit Bordmitteln löschbar)

    - ist es auf einem PC gelknackt, könnte der Remoteangreifer auf alle anderen PCs zugreifen. Da dort aber keine Daten liegen, ist der mögliche Schaden gering


    Viele Grüße Dirk

    Freitag, 17. Juli 2015 07:33
  • Hallo svhelden,

    Na du baust nen Domain User nennst ihn "Hans Wurst", der ist in keiner Domain Gruppe drin. Du kannst ihn aber via GPO an allen Arbeitsplätzen zum lokalen Admin machen.

    Dann plfegst du dein Kennwort genau einmal und nicht an jedem Arbeitsplatz.

    Das ist soweit ich das verstanden habe sein anliegen. Er möchte sich einheitlich administrativ mit EINEM Kennwort überall anmelden können, OHNE die Sicherheit seiner Domain zu gefährden.

    Dass das sicherheitstechnisch nicht optimal und stellenweise fahrlässig ist überall das gleiche Passwort zu nutzen wurde mehrfach erwähnt.

    Aber er hat nach etwas konkretem gefragt. Dann bekommt er halt ne Antwort. :)

    Aber dennoch nochmal der Hinweis: Wenn jeder Client das gleiche lokale Adminkennwort hat, kann man quer durchs Netzwerk auf jeden Client zugreifen und Systemrelevantes verändern.


    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Freitag, 17. Juli 2015 07:35

  • Na du baust nen Domain User nennst ihn "Hans Wurst", der ist in keiner Domain Gruppe drin. Du kannst ihn aber via GPO an allen Arbeitsplätzen zum lokalen Admin machen.

    Dann plfegst du dein Kennwort genau einmal und nicht an jedem Arbeitsplatz.


    Es geht aber doch um den Fall, dass der Rechner nicht mehr an der Domäne ist und man sich lokal anmelden muss. Dann ist ein Domänenuser doch völlig nutzlos.

    Freitag, 17. Juli 2015 07:43
  • na dann soll er sich doch n powershell script bauen:

    - Abfrage rechner OU -> Pipe -> Kennwort setzen.

    Powershell kann ja so schön remote arbeiten ;)


    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Freitag, 17. Juli 2015 07:50
  • genau so isses.

    Ich hatte 2-3x den Fall, dass der PC (egal mit welchem Nutzer) sich nicht mehr an der Domäne anmelden konnte. Ohne lokalen Admin hätte ich den PC neu aufsetzen oder das AdminPW über die üblichen Tricks resetten müssen.


    Viele Grüße Dirk

    Freitag, 17. Juli 2015 07:51
  • Dennis,

    hast Du ein Beispiel für ein solches Script? Wäre das PW darin im Klartext?

    Nur zur Klarstellung: alle lokelen AdminPWs sind bereits geändert. Eine Lösung wäre für den nächsten Änderungszyklus aber dennoch interessant.


    Viele Grüße Dirk

    Freitag, 17. Juli 2015 07:53
  •  

    Ohne lokalen Admin hätte ich den PC neu aufsetzen oder das AdminPW über die üblichen Tricks resetten müssen.



    Genau. Und deshalb braucht man ein lokales Adminkonto. Und weil gleiche Adminkennwörter auf allen Rechnern ein Sicherheitsproblem darstellen, braucht man LAPS. Was aber bereits in der ersten Antwort auf das Eingangsposting gesagt wurde ;)
    Freitag, 17. Juli 2015 07:53
  • Wenn ein gleiches lokales Adminpaswort ein so großes Sicherheitsproblem ist - habt Ihr dann auf allen Servern auch unterschiedliche *DomainAdmin"Passworte?  Weil das wäre dann ja auch ein großes Sicherheitsproblem, dort dasselbe zu haben. Oder ändert Ihr die DomAdminPWs stündlich? ;-)


    Viele Grüße Dirk

    Freitag, 17. Juli 2015 07:57
  • Wenn ein gleiches lokales Adminpaswort ein so großes Sicherheitsproblem ist - habt Ihr dann auf allen Servern auch unterschiedliche *DomainAdmin"Passworte?  Weil das wäre dann ja auch ein großes Sicherheitsproblem, dort dasselbe zu haben. Oder ändert Ihr die DomAdminPWs stündlich? ;-)



    Das Domain-Admin-Kennwort ist nicht als Hash auf den Workstations gespeichert. Das lokale Administratorkennwort schon.

    Das Domain-Admin-Kennwort kennen nur wenige Personen, bzw. es gibt wenige Domain Admins, die jeweils ein eigenes Domain-Admin-Konto haben. Das lokale Administratorkennwort müssen in einem großen Unternehmen deutlich mehr Personen kennen (wenn es überall das gleiche ist).

    Freitag, 17. Juli 2015 08:01
  • also das klassische Domain Admin Passwort sollte eh im Safe liegen und nicht verwendet werden.

    Im Optimum hast du pro Einsatzzweck nen administrativen User.

    So dass beispielsweise ein Exchange Admin nichts in deinem Rest zu suchen hat.


    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Freitag, 17. Juli 2015 08:02
  • Das ist klar, nur hast Du bei kleineren Unternehmen diese strikte Trennung nicht.

    Ändert aber nichts dran, dass es ein Benutzerkoto gibt, welches auf allen DCs abmelden kann. Und das ist ja auch nicht unterschiedlich pro DC, d.h. wir das PW korrumpiert, kann man sich anmelden. Ich sehe darin eher größere Probleme wie beim lokalen Adminpasswort. Als Konsequenz müsste man es sehr oft ändern.

    Das Domain-Admin PW wird sehr wohl auf dem Client gecached, sonst wäre eine Anmeldung offline gar nicht möglich.
    Unser lokales Adminpasswort weiss außer den Admins niemand, muss auch niemand wissen. Ist auch ein gewisser Schutz vor Mehrarbeit :-)


    Viele Grüße Dirk

    Freitag, 17. Juli 2015 08:06
  • naja das könnte nun in einer ewigen Diskussion enden :)

    nichts desto trotz:

    Du kannst die Powershell nutzen um dein Wunsch zu erreichen.


    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Freitag, 17. Juli 2015 08:13
  • Ändert aber nichts dran, dass es ein Benutzerkoto gibt, welches auf allen DCs abmelden kann. Und das ist ja auch nicht unterschiedlich pro DC, d.h. wir das PW korrumpiert, kann man sich anmelden.

    Beim Caching wird aber weder das Kennwort noch der komplette Hash gespeichert. Aus den Cache-Informationen lässt sich das Kennwort nicht so rekonstruieren, wie das beim Kennwort eines lokalen Users der Fall ist.

    https://technet.microsoft.com/en-us/library/hh994565.aspx?f=255&MSPPError=-2147217396

    Windows logon cached password verifiers

    These verifiers are not credentials because they cannot be presented to another computer for authentication, and they can only be used to locally verify a credential. They are stored in the registry on the local computer and provide credentials validation when a domain-joined computer cannot connect to AD DS during a user’s logon.

    Im Übrigen sind die Domänencontroller, auf denen der Hash eines Domänenbenutzers gespeichert ist, in gesicherter Umgebung (Serverraum, verschlossen, Wachdienst etc.), während die Laptops, auf denen die lokalen Kennwörter gespeichert sind, ungesichert in der Welt herumreisen.

    Unser lokales Adminpasswort weiss außer den Admins niemand, muss auch niemand wissen.

    In einem interntionalen Unternehmen mit fünf Domain Admins und insgesamt fünfzig Administratoren gibt es halt solche und solche Admins. Der IT-Mitarbeiter in China kann das lokale Administratorkennwort für die Rechner in China ruhig wissen. Das lokale Administratorkennwort für die Rechner in Frankreich soll er aber nicht haben. Wenn aber ein Mitarbeiter aus Frankreich das Büro in China besucht und dort sein Rechner kaputtgeht, dann soll er ihm helfen können (natürlich ohne das Kennwort für ALLE französischen Rechner zu bekommen). Und GENAU DAS geht halt mit LAPS perfekt.

    • Bearbeitet svhelden Freitag, 17. Juli 2015 09:24
    Freitag, 17. Juli 2015 08:13
  • Yup. LAPS wäre perfekt für mich, wenn man ein statisches KW für alle nehmen könnte.

    Viele Grüße Dirk

    Freitag, 17. Juli 2015 08:17
  • Yup. LAPS wäre perfekt für mich, wenn man ein statisches KW für alle nehmen könnte.


    Nein, ein "statisches KW" ist eben NICHT "perfekt" und deshalb erlaubt LAPS das auch nicht. 


    Freitag, 17. Juli 2015 08:20
  • Hi,
     
    Am 17.07.2015 09:33, schrieb -Dirk-:
    > - ist es auf einem PC gelknackt, könnte der Remoteangreifer auf alle
    > anderen PCs zugreifen. Da dort aber keine Daten liegen, ist der mögliche
    > Schaden gering
     
    Lies bitte in aller Ruhe:
    Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft,
    Version 1 and 2
     
    Angreifer haben heutzutage sehr viel Zeit und dein Client ist nur das
    erste Sprungziel, bis sich der erste Domain Admin anmeldet ...
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Freitag, 17. Juli 2015 20:26
  • Am 17.07.2015 09:51, schrieb -Dirk-:
    > Ohne lokalen Admin hätte ich den PC neu aufsetzen oder das AdminPW über
    > die üblichen Tricks resetten müssen.
     
    In der idealen Welt hast du ja deswegen aus Microsoft Sicht ein
    funktionierendes OS Deployment und der Client ist nach 2 Stunden wieder
    da. Die Kisten werden in großen Firmen nicht mehr großartig bebastelt,
    die werden einfach Re-Deployed.
    /Sarkasmus aus
     
    Böse gefragt: Rechtfertigen 3 Fälle pro Jahr das real existente
    Sicherheitsrisiko von Pass-the-Hash?
     
    Am Ende, im Falle eines Falles, musst du als Administrator nach "Besten
    Wissen und Gewissen" handeln, ob das jetzt noch gilt könnte in Frage
    gestellt werden.
     
    ´tschuldige, aber ich führe genau diese Diskussionen zur Zeit in vielen
    großen Unternehmen und beim Stichwort "Security" will keiner die Kappe
    aufsetzen und Verantwortung übernehmen, wenn er weiss, daß es besser geht.
     
    jetzt höre ich aber auf, ich wollte keinen Glaubenskrieg anzetteln.
     
    Schönen Abend,
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Freitag, 17. Juli 2015 20:33

  • ist es auf einem PC gelknackt, könnte der Remoteangreifer auf alle anderen PCs zugreifen. Da dort aber keine Daten liegen, ist der mögliche Schaden gering


    Aber wenn man Administratorrechte auf anderen Rechnern hat, kann man dort Schadcode einschleusen, der z. B. die Kennwörter der Domänenbenutzer bei der Anmeldung mitschneidet.
    Freitag, 17. Juli 2015 20:33
  • Am 09.07.2015 18:17, schrieb Mark Heitbrink [MVP]:
    > Das Thema ist leider seit letztem Jahr März durch ein Sicherheitsupdate
    > nicht mehr möglich.
     
    Total vergessen, aber eine Alternative ist:
    Deinstallation von MS14-025
     
    Das ist der Sicherheitspatch, der die cpassword Felder in den GPPs
    ausgraut. Ohne diesen ist die Verwendung wieder möglich.
    Im Unternehmen kannst du ihn ja über den WSUS "zurückziehen" und nicht
    mehr freigeben.
     
    Stichwort Sicherheit mal aussen vor gelassen ;-)
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Samstag, 18. Juli 2015 07:38
  • Danke Euch allen für die lebhafte Diskussion hier.

    Insb. das Argument des Einschleußens von Schadcode bei geknacktem lokalem Adminkonto zum Abgreifen des DomAdmin-Logins ist nicht von der Hand zu weisen.

    Ich werd noch mal in mich gehen, vielleicht verabschiede ich mich vom statischen KW und setze LAPS dann doch ein.

    Läuft LAPS auch unter einem 2003er SBS? (anderes Netzwerk, andere Domäne, ja ich weiss, der muss eigentlich weg...)


    Viele Grüße Dirk

    Samstag, 18. Juli 2015 09:26
  • Eigentlich?
    Der ist fast ein größeres Problem als deine Kennwörter der lokalen Admins.

    Zum Administrationskonzept:
    Lass das bleiben! Die Realität zeigt, dass gleiche Kennwörter an mehreren Stellen keine gute Idee sind.
    Ein potentieller Angreifer müsste nur einen einzelnen Rechner infizieren und das Passwort knacken, schon hat er deine komplette Client Infrastruktur geowned.
    Damit braucht er gar keinen Zugriff mehr auf deine Domäne um gewaltigen Schaden anrichten zu können.

    Sonntag, 19. Juli 2015 16:28
  • Euren Bedenken folgend werde ich LAPS nun doch mal intensiver testen :-)

    Ich habe per GPO 16 Zeichen konfiguriert und am Testclient ein gpupdate /force laufen lassen - dennoch zeigt mir die LAPS-Gui nur 10 Zeichen an beim Passwort und auch der Gültigkeitsintervall entspricht nicht dem konfigurierten. Lt. gpresult kommt die GPO an.

    Hab ich was übersehen?


    Viele Grüße Dirk

    Montag, 20. Juli 2015 12:28
  • Frage erledigt, ich war zu ungeduldig, es funktioniert.

    Viele Grüße Dirk

    Montag, 20. Juli 2015 13:23
  • Hi,
     
    Am 18.07.2015 11:26, schrieb -Dirk-:
    > Läuft LAPS auch unter einem 2003er SBS
     
    Ja. Das OS ist halt nur nicht mehr supportet.
     
    Die AD Version ist egal, die Attribute werden dem Schema hinzugefügt und
    das wars. Den Rest erledigt ja der Client über die CSE.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Mittwoch, 22. Juli 2015 19:28
  • Am 10.07.2015 schrieb Mark Heitbrink [MVP]:
    Nabend,

    Am 10.07.2015 12:16, schrieb -Dirk-:

    Hmm, und wenn ich den Client aus irgendwelchen Gründen aus der Domäne
    nehmen muss - wie soll ichs dann auslesen?

     
    Mitdenken, vor dem löschen lesen. :-)

    Solange das AD Konto noch im AD steht, gibts doch gar kein Problem. Der
    Client kann die POlicies nicht mehr anwenden, und selbst wenn, würde er es
    nicht ändern, weil erst das Kennwort ins AD geschrieben wird und dann
    geändert. Also problemfrei... :)

    Bye
    Norbert


    Frank, I never thought I'd say this again. I'm getting the pig!
    nntp-bridge Zugriff auf die MS Foren wieder möglich:
    https://communitybridge.codeplex.com/

    Freitag, 24. Juli 2015 22:03
    Moderator
  • Am 22.07.2015 schrieb Mark Heitbrink [MVP]:

    Nabend,

    Die AD Version ist egal, die Attribute werden dem Schema hinzugefügt und
    das wars. Den Rest erledigt ja der Client über die CSE.

    Und dran denken, dass die MS Version 6 und 6.1 sich auch nicht mehr auf XP
    installieren lassen (zum Glück), da hilft auch kein sicheres Kennwort mehr,
    wenn man sich die neuesten Meldungen zum Thema "Hacking Team" so durchliest.
    ;)

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich:
    https://communitybridge.codeplex.com/

    Freitag, 24. Juli 2015 22:06
    Moderator