daabm

Du kannst "Freigaben" nicht an eine NIC binden. Den Serverdienst bzw. den Hostnamen dagegen problemlos. Im Managementnetz macht man kein DHCP und hat keine Hostnamen - wir zumindest nicht.

Meine letzte OSI-Schulung ist glaub 28 Jahre her - bitte um Nachsicht mit einem alten Mann, hilf mir lieber über die Straße 😂

@cj_berlin Disjoint Namespaces innerhalb eines Forest sind kein Problem. Interessant wird's mit ganz vielen Forests und "welche SPNs sind jetzt eigentlich wo registriert. wie findet der Client den richtigen KDC und was ist per DNS auflösbar und was nicht". Aber jetzt wird's zu OT

Guck - hätte ich mal die Klappe gehalten oder besser noch mal nachgedacht. Klar, muss ja "da unten" sein 😘 Ok, aber technisch wäre es egal, Hauptsache ein Gerät im Subnetz hat nen Helper. Da simmer uns glaub einig.

Wenn Ihr in flachem Gelände (oder "im Tal") wohnt - freundet Euch schon mal damit an, das wird das neue "Normal"... SCNR

Normalerweise laufen Helper auf dem Router. Aber in Zeiten von Layer-x-Switches weiß man das nicht so genau

Über Multi-Domain Umgebungen kannst mit mir prima diskutieren - wir haben etwa 1.500 Stück von diesen komischen Domänen. Nur 3 davon haben in ihrem Forest noch eine Child-Domain, und das sind genau die 3, die uns den meisten Ärger bereiten... Inkl. der besch***** universellen Gruppen, die auch kein Mensch braucht. Alle anderen sind Single-Domain/Single-Forest, und mit den richtigen Trusts klappt das ganz hervorragend. Sogar mit Kerberos und Disjoint Namespaces. Ja, weiß ich, disjoint sollte man nicht machen, aber wir machen ungefähr alles, was "irgendwie machbar ist"

Nein. "Kann es nur einmal geben" stimmt, DDP ist falsch. Richtig wäre "kann in einer beliebigen Policy auf Domainebene gesetzt werden und landet dann auch in der DDP"

Ja dann fehlt wohl im Stripeset eine HDD...

Beides falsch... Und die Default Domain Policy fasst man am besten gar nicht an, die hat eine unheilige Beziehung zum Domain Head. gpedit.msc zeigt Dir die "lokale Policy" an. Was da drinsteht (oder auch nicht), wird von Domain Policies überschrieben. Und das Gesamtergebnis findest Du dann in auditpol. Oder auch nicht https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/getting-the-effective-audit-policy-in-windows-7-and-2008-r2/ba-p/399010

BTW: Storage Pools werden in keinster Weise über die Datenträgerverwaltung verwaltet - das passiert nur über den Servermanager bzw. Powershell.

Last 24 h...

Warnwetter heute: "Warnung vor HITZE"... Aktuell 33°

Hab mir das mal angeschaut... (Erzeugt mit https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 ) Die bieten eine extrem eingeschränkte Auswahl von Cipher Suites an - https://www.ssllabs.com/ssltest/analyze.html?d=nvd.nist.gov Möglicherweise hat Powershell/Invoke-WebRequest damit ein Problem. Für nähere Diagnose fehlt mir grad die Konzentration.

Da wären wir dann wieder bei dem Zertifikatsproblem mit dem Truststore. Der Angreifer muß ein Zertifikat präsentieren, das den "eigentlichen" Namen enthält.

Und die enthalten was genau? Du hast vielleicht eine Ahnung, wie viele verschiedene Event-IDs es aus unterschiedlichsten Quellen in den diversen Eventlogs gibt - meine Glaskugel kennt die alle nicht

Nene, nicht auf Share-Ebene. Die Heimnetzfreigabe macht auch auf Dateisystemebene "komische" Sachen.

@NilsK Du hast schon lange nichts mehr mit der Heimnetzfreigabe gemacht... "Everyone"

Jaja, weiß ich doch... $ValidationCallback = [Net.Security.RemoteCertificateValidationCallback] { return $True } $Socket = [Net.Sockets.Socket]::new( [Net.Sockets.SocketType]::Stream, [Net.Sockets.ProtocolType]::Tcp ) $Socket.Connect( $TargetComputer, $Port ) $NetStream = [Net.Sockets.NetworkStream]::new( $Socket, $true ) $SslStream = [Net.Security.SslStream]::new( $NetStream, $true, $ValidationCallback )

Entweder hat Dein DC kein Serverzertifikat, dann gibt es keinen Listener auf Port 636. Oder Du hast irgendwo anders Firewalls, die 636 nicht durchlassen. Portqry/Test-NetConnection könnte hier Klarheit schaffen. Das hier kann das alles für Dich prüfen inkl. der verwendeten Zertifkate: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 Wichtig bei LDAPS, wenn die Basis mal funktioniert: Der Client (also Dein Webserver) muß der kompletten CA-Kette vorher schon vertrauen - LDAPS liefert im Handshake die CA-Chain nicht mit aus (wie das https macht).

Ja, ich hab oft mit "unbekannten" Speicherorten für Konfigs zu tun, die zentral deployt werden sollen - da fehlt mir die Zeit, jedesmal individuell zu suchen. Set-NetAdapterAdvancedProperty macht ja laut (kurz überflogener) Beschreibung im Prinzip das gleiche, nur daß es ein paar Dinge "convenient" auflöst

Typischerweise sollte das ein Regwert sein - wenn Du nix findest, probier's mal mit Regshot, das erstellt und vergleicht vorher/nachher Snapshots der Registry. Da muß man zwar dann ziemlich viel Müll rausfiltern, aber oft ist es hilfreich. Alternativ ProcMon mit Filter auf RegWrite.

Sysinternals "handle.exe" oder ProcMon sagen Dir, wer (welcher Prozess) genau welche Dateien offen hat.

Hast hoffentlich ein Windkraftwerk auf dem Dach

Ne, wäre es nicht. Den gleichen Quatsch hatten sie schon mal mit tsadmin.dll, die plötzlich gefehlt hat. Wäre eher "if you can't, we can"