daabm

Negativ... Dem AD-Client (und auch den DCs) ist es völlig wurscht, wo ihr DNS liegt. Wichtig ist nur, daß dort alle erforderlichen Subzonen und SRV-Records korrekt registriert sind. Hier im Forum sind alle noch viel zu sehr auf AD-integriertes DNS gepolt Wenn man dem Pihole die DNS-Einträge der DCs nahebringen könnte, wäre das kein Problem. Hab ich aber auch noch nicht geschafft - hier laufen die HINTER dem AD-DNS, nicht davor.

Kunde oder Ausbildungsbetreuer? Egal, Thread ist wohl eh tot

Korrektur - das geht sehr wohl. Muß man nur "drumrum improvisieren"... Die Grundlagen sind hier zu finden: https://evilgpo.blogspot.com/2014/10/implementieren-von-ordner-nur-auf.html Da hier das Umleitungsziel quasi beliebig definiert werden kann, ist "Name_Vorname" natürlich problemlos.

Noch kurz mein Senf dazu: https://evilgpo.blogspot.com/2012/02/loopback-demystified.html Nicht von dem Loopback irritieren lassen - das ist ein Grundlagenartikel über GPO-Vererbung. PS: Give a man a fish and feed him for a day. Teach him how to fish and feed him for a life.

Das "morgen" ist jetzt fast ne Woche her, aber egal. Du hast mehrere Probleme - eines davon ist, daß vermutlich Deine Sysvol-Replikation kaputt ist. Daher kommt nämlich dieser Fehler: Reparieren heißt allerdings erst mal analyiseren... Und dann folge dem Licht: NTFRS oder DFSR? (Wenn die Replikation nicht fehlerhaft ist, hast Du mehr als seltsame ACLs auf diese GPO gesetzt... Der Klassiker wäre "Allow: Apply und Deny: Read", dann geht die GPO-Engine auf die Bretter...) Das nächste Problem hat @Sunny61 oben schon angesprochen: login.cmd, login.vbs, logon.vbs - wovon reden wir genau?

"Letzter Arbeitstag" - kann man so sagen. Hatte heute schon frei, hab aber den ganzen Tag gearbeitet. In der Küche Gans, Rotkohl, Soße dazu (für morgen). Das dauert...

In dem Ausschnitt steckt wohl der entscheidende Punkt für trojanerfeste Backups: Das Backup wird gezogen, nicht geschoben. Oder anders formuliert: Nicht der Client "schreibt" sein Backup auf den Backupserver, sondern der Backupserver "liest" es vom Client. Die Alternative, die wohl die meisten Backupsysteme bieten dürften, ist: Der Backup-Client kann nur Backups erstellen, er kann aber bestehende Backups weder lesen noch schreiben. Beides funktioniert explizit NICHT, wenn man einfach auf eine SMB-Freigabe schreibt Die Bastellösung (sorry...) mit Skripts, die irgendwelche Daten mehrfach auf irgendwelche Freigaben schreiben, wird niemals trojanerfest sein.

Ich blas dann mal die Adventskerzen aus - übermorgen ist Heiligabend

"Die Kleinen spielen grad so schön". Wer nur einen Credential Store (=AD) hat, der kommt damit vielleicht noch klar. Wir haben viele - ich hab geschätzt 25 Accounts. Und jetzt? SCNR... @Weltalltrauma ich würde da auf die Entscheider zugehen (wenn das nicht ihr selber seid) - Kennwortwechsel sind ein absolut veraltetes Prinzip aus dem vergangenen Jahrtausend. Sogar das BSI hat sich von der Empfehlung verabschiedet. PS: Ist schon schwer genug, allen Beteiligten den Unterschied zwischen "User-ID" (überall gleich) und "Account" zu vermitteln...

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