daabm

Wenn Du 2. umsetzt, musst Du alle Member Computer neu joinen. Falls bei Dir das Computerkennwort-Gültigkeitsintervall (wtf ist das für ein Wort? ) nicht vom Standardwert 30 Tage geändert wurde. Geht AD auf einen Stand mit dem Alter zurück, sind alle Member erst mal "raus". Das Kennwort des Computeraccounts ist der "Trust Anchor" in AD.

Time flies... 100 Jahre und ein Tag:

Ich kann mich dem nur anschließen. Ein AD kaputt zu machen, ist ziemlich schwierig - aber möglich. USN-Rollback mit ungeeigneten Reparaturmaßnahmen ist eine der besten Möglichkeiten dafür.

Siehe meine Posts #2 und #4. Schaff dich rein oder such jemand, der es schon kann.

🕯🕯🕯🕯🕯 - finde den Fehler 😂

SSL-Interception? Aber Du hast Recht, der Anbieter sollte das genauso gut tracen können. Und vielleicht hat der ja Menschen, die das können 👍

Ich bin Angestellter - "kurz mal Remote" zahlt mir niemand, und hier gibt's auch kein Entgelt Sorry, aber das geht nicht. Wenn Du's nicht selber kannst, mußt Du jemand suchen (und bezahlen), der es kann. So ist der Wirtschaftskreislauf definiert. Und Norbert gab ja schon nen entsprechenden Hinweis.

Dankeschön Ich weiß, daß der Code (obwohl eigentlich nicht "gewachsen", sondern erst knapp 4 Monate alt) schon direkt ein paar Verbesserungspotentiale hat - ich hätte z.B. Klassen nehmen sollen statt verdammt vieler [PSCustomObject]. Aber wir sind in der Firma echt zufrieden damit, weil's halt sackschnell sauviele Ports "kreuz und quer" prüfen kann. Und ParameterFromPipelineByPropertyName war auch keine freiwillige Erfindung - ich mußte tatsächlich mal von 9 Sytemen aus Verbindungen zu 12 verschiedenen DB2-Datenbankservern prüfen, die jeweils auf anderen Ports laufen

Netzwerktrace machen (Netmon/Wireshark/"netsh trace start capture=yes tracefile=xyz.etl" - sollte mit Netmon analysiert werden, Wireshark kann netsh-Traces nicht lesen ohne Konvertierung), reinschauen was beim Handshake schiefgeht.

Hallo miteinander. Heute mal keine Frage, keine Antwort, sondern ein Angebot: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 Wir haben beruflich immer wieder mit Multi-Domain-Umgebungen zu tun, in denen User, Computer und Target Accounts (aka "zu verwaltende Konten") in verschiedenen Domänen sind. Das bedeutet, daß wir relativl viel AD-Kommunikation brauchen. Und naturgemäß liegen dazwischen Firewalls. Daraus entstand das Bedürfnis, Ports schneller und einfacher zu prüfen also "pro Host, pro Ziel-DC und pro Port per Test-NetConnection oder portqry.exe". Test-NetConnection ist eh ganz furchtbar langsam... Was dabei herauskam: Ein Skript, dem Du eine Liste von Zielcomputern (oder einen Domänennamen - DNS-Auflösung ist mit drin) übergeben kannst. Dann prüft es vom lokalen Computer aus alle AD-relevanten (default) oder eine benutzerdefinierte Liste von Ports gegen diese Computer. Wenn Powershell Remoting in Deiner Umgebung funktioniert, kannst Du zusätzlich eine Liste von Quellcomputern angeben, von denen aus diese Ports geprüft werden sollen. Beides läuft multithreaded. Auf dem ausführenden Rechner wird über Runspaces und PSSessions das Skript auf den Quellcomputern gestartet. Dort jeweils macht es wieder über Runspaces parallel die Port-Prüfungen. Soweit klar? Du kannst also parallel von 4 Quellcomputern Zielports auf 4 Zielcomputern prüfen. Damit ist auch der Thread-Titel erklärt - Matrix-Multithreading Dazu kommt noch: Das Skript kann auch die RPC-HighPorts prüfen (holt diese dynamisch vom RPC-Portmapper des Zielcomputers, Credits an Ryan Ries), es kann SSL/TLS-Ports prüfen inkl. deren Protokollversion und Zertifikat. Eignet sich also auch für Webserver-Farmen o.ä. Wenn man's "einfach so" aufruft, prüft es "nur" alle DCs der aktuellen Umgebung auf alle (naja, die meisten) AD-relevanten Ports. Dabei kommt dann z.B .so was raus: Natürlich kannst Du das Ergebnis auch ("-PassThru") in Powershell weiterverarbeiten statt es nur in ein Out-Gridview zu pipen Und mit "-IncludeEPM" bekommst Du auch die RPC Highports. Oder Du willst alle DCs von allen Trusting Domains prüfen - IncludeAllTrustingDomains (und vielleicht noch IncludeAllTrustedDomains?) Interessant wird's mit diesem Aufruf: .\Test-TcpPorts.ps1 -Computer <ZielDom1>, <ZielDom2> -SourceComputer ( Get-ADDomain ).ReplicaDirectoryServers -IncludeEPM Das Ergebnis (und vor allem die Ausführungszeit) mag sich jeder Interessierte gern selber mal anschauen. Die ändert sich nämlich kaum, ob es nun 5 oder 50 Server sind. Du weißt in wenigen Sekunden, welche Kommunikationswege gefiltert werden. PS: Modulabhängigkeiten gibt es keine - intern ist alles mit AD über [DirectoryServices] gelöst. Nur das DNS-Modul brauche ich, aber das ist immer vorhanden. Und wenn Du die Zertifkate beim SSL-Check speichern willst - die Objekte dazu haben eine .Save( TargetDirectory ) Methode.

Per IP geht, weil NTLM. Dein krbtgt-Kennwort ist "out of sync". Löst man normalerweise, indem man auf allen bis auf einem DC (meist PDC) den Dienst kdc deaktivert und stoppt, und danach alle diese DCs neu bootet. Wenn das nicht hilft, muß der Secure Channel zurückgesetzt werden (nltest /sc_reset). Und bevor noch mehr kaputt geht: Hol jemand, der's kann Keine Kritik, nur ein wohlmeinender Hinweis. PS: USN-Rollback findest Du prominent im Directory Service Eventlog - das solltest Du eh mal anschauen auf beiden. Und im Zweifel ist es am einfachsten, den (noch zu identifizierenden) aktuellen "Chef im Ring" (auch meist der PDC) zu behalten und den Rest platt und neu zu machen. Aber siehe oben - hol Dir jemand.

Ah - mea culpa, hab nur in der Powershell "curl" eingegeben und da dann den Alias entdeckt. Dann noch "where curl.exe" - aber blöderweise immer noch in der Powershell, wo das ein Alias für Where-Object ist In cmd.exe findet's dann korrekt. Ok, man lernt nie aus - die klassische Commandline ist immer noch relevant.

Interessant - wußte ich auch noch nicht curl ist ein Alias für Invoke-Webrequest. Vielleicht kanns dann auch die gleichen Parameter? Und eine curl.exe in System32 hat dann "irgendwer" da hinkopiert. "Aus dem Nichts" ist sie nicht vorhanden.

"Die Wiki" Warten wir mal auf den TO und seine Rückmeldung.

Im produktiven Umfeld haben wir nur LDAP Simple Bind eliminiert - hat schlappe 3 Jahre gedauert... SMBv1 erledigt sich durch die OS-Updates von selbst. Aktuell nutzen wir die Chance, daß wir ein neues AD-Umfeld aufbauen. NTLM-Blocking (what a mess...), Kerberos AES only. Das ist immer noch mühsam genug.

Da ist es hier ja mit derzeit 0° richtig kuschelig

Wenn es Powershell sein muß oder soll: Invoke-WebRequest. Den Auth-Header mußt dann halt zusammenbauen, und was die -F Parameter von curl bedeuten, weiß ich nicht Gibt viele Beispiele im Netz. Wenn Du nichts findest oder Hilfe brauchst, melde Dich noch mal.

Und bist auf dem Sicherheitsniveau von Windows NT/2000 gelandet. Das will man nicht, Du mußt weiter analysieren, was das "eigentliche" Problem ist.

Definiere mal genauer, was "fehlen ihm die Rechte" bedeutet. "whoami /groups" und "net localgroup Administrators" sagen Dir schon mal mehr zur Lage der Nation. Und ansonsten - wegen dem "wie geht das gut und günstig": https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html

Gut, Günstig, Schnell - "pick two"

Welche denn? Da fällt mir spontan SCCM ein. Dem ist es völlig egal, was sein Computeraccount auf dem SQL effektiv an Rechten hat - ist er nicht in den lokalen Administratoren "direkt" drin, scheitert's. Vor 3 Wochen erst live gesehen... Und ohne NTLM geht's natürlich auch nicht

Ich bin bei allen Vorrednern - DFS-N mit ABE kann alle Netzlaufwerke außer einem eliminieren, maximal einfach. Und mit GPOs kann man sich nicht nur "schöne Sachen" ausdenken, sondern auch richtig praktische Netzlaufwerke gehören aber in keinem Fall dazu.

Ausnahmsweise mal Sonntagsgrüße: 🕯🕯🕯

Servergespeichertes Profil (im AD-Konto eingetragen), das nicht geladen werden kann - aus "Gründen"... Die mußt Du jetzt finden.

AFAIK nein. HT ist nix, von dem Anwendungen wissen. Und dem virtuellen System ist es egal, es muß nur genug Cores haben -> Performance Monitor.