carnivore

Hi Daniel, Ich habe eine MSDN-Lizenz. Es ist trotzdem schade, dass man Clients nicht produktiv laufen lassen darf. carnivore

Hallo, Ich habe seit kurzem angefangen, in der Azure Cloud zu arbeiten, stehe daher noch am Anfang. Jedenfalls habe ich mir einen Win8.1 Rechner aufgesetzt (A1 - 1 Core 1,75 GB) und meine täglich verwendeten Programme installiert und lizensiert. Ein paar Stunden Arbeit stecken jetzt schon drinnen. Der Zugriff erfolgte über default RDP und ein https-Desktoptool (Port 443) problemlos Die HW-Ausstattung war aber doch zu dünn, daher habe ich ein upscale auf A2 - 2 Cores -3,5 GB durchgeführt. Nach einem Reboot sollte lt. Consolenmessage die Config übernommen werden. Leider komme ich seit dem Restart nicht mehr an den Rechner ran. In der Managementconsole steht er auf "running", die MonitoringCounter sind seit dem UpScale allerdings auf 0. Mehrfach restarten hat nichts geändert. Fehlermeldung kommen in der Console keine. Habt ihr eine Idee wie ich den Rechner zum Leben erwecken kann und/ oder was ich falsch gemacht haben könnte. Ich habe nur brav über die Managementconsole zugegriffen, keine Powershellhacks etc. danke carnivore hat sich erledigt...der upscale dauert offenbar einige Zeit >45 Minuten ... jetzt komme ich wieder drauf Again what learned :-) Carnivore

Hallo Dunkelmann, Danke für die Links! Ja, ich habe etliche längst abgelaufene Zertifikate, die ich löschen möchte Merci carnivore

Hallo, Eventuell hat jemand einen Tipp für mich. Ich habe einen Issuing-CA Server (2008R2) im AD, der seit einigen Jahren Maschinenzertifikate für unsere Clients automatisch ausrollt. Mit der Zeit ist die Anzahl der ausgestellten Zertikate so groß geworden, dass ein Handling der GUI auf dem Server praktisch nicht mehr möglich ist. Ausstellen funktioniert aber einwandfrei Ich suche schon längere Zeit, wie man einen CA-Server von alten und abgelaufenen Zertifikaten befreien kann. Vermutlich muss man auch die Datenbank danach shrinken, etc. Merci carnivore

Hallo zusammen, Auf unseren DCs ist noch SSL V3.0 aktiviert, was eigentlich nicht sein sollte http://support.microsoft.com/kb/245030/en-us Kennt ihr potentielle Auswirkungen, die ein Deaktivieren von SSL auf DCs nach sich ziehen könnte? Mir fallen momentan allgemein nur LDAP-Searches auf Port 636 von alten Clients ein, die evtl. nicht mehr funktionieren. Danke Carnivore

Die wenigsten Schadprogramme werden noch direkt von Sicherheitsprogrammen erkannt, egal wo sie liegen. Der Schlüssel liegt im Satz "Der Schädling meldet sich nun bei seinem Herrn: " Ich bin ready". Es gibt laufend aktualisierte Listen z.B. vom BSI mit verdächtigen IPs. Auf Verbindungsversuche zu diesen IPs sollte man seinen Netzwerktraffic überwachen, bzw. der Netzprovider sollte dies tun. Auch kein 100%-iger Schutz, aber ein Ansatz, der bei uns schon gelegentlich zu verseuchten Rechnern geführt hat, die wir sonst nicht erkannt hätten. Die Spuren zeigten dann übrigens meist eher in Richtung Russland, weniger zu den üblichen Hauptverdächtigen wie USA oder China.

gib doch einfach mal bei youtoube z.B. "micorosoftlearning 410" oder "itfreelearning 410" ein alleine damit kommst du schon an tonnenweise kostenloses Supermaterial heran. Damit kannst du zumindest feststellen, ob dir der Stoff zusagt. carnivore

Hi, Vergleich doch mal die Größe der PolicyOrdner im Sysvolordner auf deinen DCs, sowie die Policyversionen in der jeweiligen GPT.ini Die File-Versionen vergleich noch mit der Version im AD mit ADSIEdit oder LDP.exe: "CN=Policies,CN=System,DC=<domain>" -> deine Policy -> VersionNumber Wenn es Unterschiede gibt, machst du am einfachsten eine Neuinitialisierung der Filereplikation mit D2 von deinem guten DC aus. http://support.microsoft.com/kb/290762/de Bei nur 2 DCs ist es relativ egal, ob D2 oder D4 Gruß carnivore

Fremde Root Zertifikate ausrollen, geht AUCH! per GPO. und mit GPUPDATE., korrekt! Aber auch per "certutil -dspublish". Beide Wege haben ihre Vor- und Nachteile. Gerne nochmal die Frage: Wie kann man gezielt den AIA-Container des ActiveDirectories auf den lokalen Enterprise Store unter "Trusted Root Certification Authorities" synchronisieren? Warum ich 3rd-party certificates mittels AIA/ "certutil -dspublish" manage und nicht per GPO?...In erster Linie sind es Prozessgründe Wenn jemand eine Lösung zu meiner Frage kennt, freu ich mich. Wenn nicht, ist es auch kein Drama. carnivore

Trusted Root Certificate Container <> Root CA aber lasst gut sein, so wichtig ist es auch nicht

Hallo Zahni, am Client (win7 / Win8 / Server 2008R2) : MMC -> Certificates (computer account) -> Trusted Root Certification Authorities -> (physical Store = Enterprise) . Die zu synchronisierenden Daten liegen im AIA-Container des ADs in der Config-Partition Da ich relativ häufig diesen AIA-Container mittels certutil -f dspublish "123.cer" Root updaten muss, suche ich nach einem Befehl, den Enterprise Store des Clients schneller mit dem AIA-Container des ADs zu synchronisieren. Prinzipiell funktioniert die Synchronisation auch, dauert meist aber Stunden bis Tage, egal ob in unserer relativ großen ProdUmgebung oder in einer Mini-Testumgebung mit 2 DCs. Selbst ein Client-Reboot beschleunigt übrigens die Synchronisierung nicht. Bei certutil hören sich einige Befehle vielversprechend an, haben aber keinen Effekt. Das könnte aber natürlich auch ein Layer 8 Fehler sein :-) Gruß Carnivore

genau, so etwas ähnliches wie der "gpupdate". Nur eben nicht für Policies (=domain partition), sondern für Trusted Store (=configuration partition).

nee, leider nicht. Ich suche einen Befehl/ Trigger für das Update der Informationen auf einen Client (konkret der AIA-Container), kein Anschubsen der Replication zwischen den DCs.

Hallo, kennt Ihr einen Befehl, damit Clients und Server die Informationen von der AD Configuration-Partition sofort updaten? Bei mir dauert es oft mehrere Stunden, selbst auf dem DC, auf dem die Conf-Partition geändert wurde. Für Testfälle wäre ein erzwungenes Update hilfreich. Merci carnivore

Hallo zusammen, In folgendem Artikel ist beschrieben, dass es Probleme geben kann, wenn sich zu viele (>100) Root Zertifikate im Enterprise-Store befinden. In unserem Trusted Store befinden sich nun deutlich mehr Root Zertifikate (ca. 500), ohne dass es bis jetzt zu Problemen gekommen ist. http://blogs.technet.com/b/ad/archive/2013/05/13/certificate-trust-list-size-problem-check-pki.aspx Sollten aber bestimmte RootZerts nicht mehr angezogen werden können, könnte das aber schnell ein ernstes Problem für mich werden. Außer diesem Blogeintrag habe ich keine weiteren Hinweise oder einen richtigen MS-Supportartikel auf das "List Size Problem" gefunden. Ich habe schon ein paar Lösungsansätze gefunden, den Standard Update Mechanismus umzubiegen und so die Anzahl der Root Zertifikate zu verringern, allerdings sind die relativ aufwändig. Ist euch das ListSize-Problem im AuthRoot bekannt (2008R2 / Win7 / Win8) bzw. kennt ihr offizielle MS-Artikel dazu? Gilt die Grenze von >100 für den gesamten Trusted Root Store, oder jeweils nur für die einzelnen darunter liegenden physical Stores (GPO, Registry, Local Computer...). vielen Dank carnivore

Hi nochmal, Auch wenn es nochmehr Arbeit für dich bedeutet: :) Selbst Microsoft sagt in seinen Papers, dass es nicht ausreichend ist nur präventiv tätig zu sein. Man braucht auch ein Konzept um erfolgreiche Angriffe zu erkennen (entsprechende Eventlogs überwachen etc.) und du musst wissen, was im Falle des Falles zu tun ist (Beweissicherung etc.) Gruß carnivore vielleicht noch ganz nützlich für dein USB-Konzept: http://usbglue.com/

ein gewöhnlicher USBSticks lässt sich wohl relativ einfach so umprogrammieren, dass er sich als Keyboard ausgibt, damit als erlaubte Geräteklasse erkannt wird und dadurch Schadcode auf den Rechne bringen kann : http://www.bbc.com/news/technology-28701124 Carnivore

Hallo, Schau mal hier; http://www.codeproject.com/Articles/14284/How-to-change-a-user-s-password-on-a-remote-comput Lade dir das Projekt runter, dann hast du die exe. Wenn du Visual Studio hast, kannst du auch ohne C++ Kenntnisse beispielsweise die Oberfläche anpassen. Ich hatte den Code auch schon produktiv im Einsatz, wo er einwandfrei funktionierte bzw. immer noch funktioniert. Da mein C++ KnoffHoff für das Verständnis dieses Codes nicht ausreichte, hatte den Code vorher noch auf evtl. Schadwirkung analysieren lassen -> keine Probleme. Gruß carnivore

http://blogs.msdn.com/b/powershell/archive/2012/06/14/new-v3-language-features.aspx -> Member Enumeration

Konstrukte, wie $out = $out -split(';') funktionieren erst ab Powershell V3.0. Ich empfinde diese Syntax als unlogisch und vermeide sie daher.

Hi $out ist kein String, sondern ein Array aus Strings. Mit $Out | foreach { $_ -split(";") } kannst du die einzelenen Felder des Arrays nacheinander analysieren. Deklariere $out mit $out = @(() sicherheitshalber vorneweg als Array carnivore

Der Satz hat was! Lassen wir es damit gut sein! carnivore

dann gib mir eine andere Interpretation deiner Worte

Ok danke für die Ausführungen. Ok, dann sehen zumindest Teile von euren Entwicklern abgelaufene Kennwörter bei enablten Accounts auch als potentielles Risiko. Mit Boardmitteln alleine ist es nicht zu beheben. Das ist genau die Antwort auf meine Frage. Sorry, wenn ich diese so schlecht formuliert habe. Merci carnvore

Drehen wirs mal um: Welchen Wert hat die PwdMaxAge-Policy, wenn nicht alle enabled Accounts berücksichtigt werden? sobald ein Auto auch nur auf der Straße steht, muss es sich an die SecurityPolicies des Straßenverkehrs halten und u.a. versichert sein, alle 2 Jahre eine neue TÜV-Plakette erhalten, etc.