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

Diese Firmware schreibt der Schädling für den Benutzer ( sehr nett gell :) )in das EProm der Festplatte rein.

Das schlimme daran ist nun das kein Sicherheitsprogramm diesen Schädling finden kann denn er ist ja nicht auf der Festplatte gespeichert.

 

Der Schädling meldet sich nun bei seinem Herrn: " Ich bin ready".

 

Was dann passieren kann hängt vom Schädling und dessen Meister ab, aber möglich ist Alles ! :schreck:

 

HTH

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

Bist du dir da sicher, dass ich das ignorieren kann? Ich war mir nicht so sicher, ob das nicht noch Folgen nach sich zieht.

 

Die Diagnose der DCs liefert mir ebenfalls einen Fehler. Zumindest hat sie vorhin darauf hingedeutet, dass zumindest einer der beiden einen Fehler hat. Clients die vom "guten" DC die GPO ziehen, sind ok. Clients die vom Backup-DC ziehen, bringen den Fehler.

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

Du willst also fremde Root Zertifikate ausrollen? Da geht nun wieder per GPO. und mit GPUPDATE.

 

Einfach mal beschreiben, was Du wirklich machen willst.  

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 :

In one demo, shown off at the Black Hat hackers conference in Las Vegas, a standard USB drive was inserted into a normal computer.

Malicious code implanted on the stick tricked the machine into thinking a keyboard had been plugged in. After just a few moments, the "keyboard" began typing in commands - and instructed the computer to download a malicious program from the internet.

....the only protection he could advise was to simply be ultra-cautious when allowing USB devices to be connected to your machines.

"Our approach to using USB will have to change," he told the BBC.

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

 

We added this feature to make it easier to deal with commands that return one or many objects.  Experienced PowerShell scripters knew they needed to use @() to handle that situation correctly, but we really thought that was less than perfect.

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

Mit einem abgelaufenen Kennwort kann man sich nicht mehr am System authentifizieren. .... Die Ausnahme ist der Windows-Anmeldedialog -

Der Satz hat was!

Lassen wir es damit gut sein!

carnivore

dann gib mir eine andere Interpretation deiner Worte

 z.B. per RADIUS authentifizieren willst, wirst Du einfach abgelehnt, weil ein abgelaufenes Kennwort einem deaktiviertem Account gleichgesetzt wird.

Ok danke für die Ausführungen.

- wenn Du Dich z.B. per RADIUS authentifizieren willst, wirst Du einfach abgelehnt, weil ein abgelaufenes Kennwort einem deaktiviertem Account gleichgesetzt wird. Oder wenn Du Dein Mails abrufen willst. Oder wenn Du auf eine Freigabe zugreifen willst...

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.