Alle Aktivitäten

Hallo, danke an alle, die mir Hinweise gegeben haben. Ich komme aus zeitlichen Gründe erstmal nicht dazu, mich weiter mit dem Router zu beschäftigen. Aber mir scheint die Anleitung von Headcrash ausreichend zu sein. Vielen Dank dafür. Und bitte nicht übel nehmen, dass ich mich so selten melde, ist nicht böse gemeint. Beste Grüße

das klingt wirklich frustrierend – besonders wenn man nicht genau weiß, wo der alte Pfad noch versteckt ist. 😕 Die Punkte sind schon super, ich würde zusätzlich auch mal prüfen: Ob im Registry-Pfad HKCU\Software\Microsoft\Windows NT\CurrentVersion\ProfileList noch Einträge mit Bezug auf DC01 existieren (insbesondere ProfileImagePath) Ob evtl. ein Skript oder alte GPO noch hart auf DC01 verweist – z.B. per Logon Script oder Home Drive Mapping Falls du ein Tool wie GPResult oder RSOP nutzt, bekommst du schnell raus, welche Richtlinien gerade aktiv greifen – hat mir schon oft geholfen, Altlasten zu entlarven.

Interessante Diskussion hier – hatte mit PSWindowsUpdate und Remote-Installationen auch schon meine „Freuden“. 😅 Was bei mir damals geholfen hat: sicherstellen, dass der Remote-Server nicht nur elevated, sondern auch interaktiv angemeldet war (je nach Umgebung spinnt es sonst gern). Außerdem: Wenn’s mit Invoke-Command hakt, hat bei mir ein Fallback auf PSEXEC tatsächlich funktioniert – auch wenn’s nicht ganz so elegant ist. Evtl. auch mal Enable-PSRemoting und Set-Item WSMan:\localhost\Client\TrustedHosts * auf beiden Seiten checken – manchmal liegt’s einfach an sowas.

Hi Jan, musste deine Lösung etwas abändern, da die IP natürlich immer unsere eigene ist. Das Überspringen von Hosts geht nur in der erweiterten Filterung, die aber dann eben nicht das macht was sie soll. Insgesamt eher unbefriedigend was MS da konfigurationsmäßig zur Verfügung stellt. :/ Ich habs jetzt per Header gelöst. Also wenn Header (DKIM) contains (Signing Domain). Danke für den Tipp Bye Norbert

Moin an Board, dann wollen wir mal - ich koche Kaffee Bergfest! Allen einen guten Mittwoch, bleibt gesund! Hier sonnig mit leichter Bewölkung bei 12°C, es wird ein mix aus Sonne und Wolken bis etwa 19°C Nachmittags ggf. Schauer - die Natur brauchts

Hi, ist das ein tcp-basiertes SSL VPN oder UDP? Generell zum Testen: GPS: Select RDP transport protocols ( -> Use only TCP) (Clientseitig könntest du das mit GPS: Turn Off UDP On Client lösen) GPS: Select network detection on the server ( -> Turn off Connect Time Detect and Continuous Network Detect) Ansonsten bist du derzeit nicht alleine: Schlagwort: RDPBorns IT- und Windows-Blog Gruß Jan

Hallo Leute, ich habe folgendes Problem, für das wir einfach keine Lösung finden: In der Firma: Fortigate 60F mit Verbindung zur Domäne Windows 10 und 11-Rechner Windows 2019 Domänen-Controller Wir verbinden uns per SSL-VPN ins Firmennetzwerk. Wenn die Verbindung steht, geht es weiter per RDP auf den jew. Rechner der am Arbeitsplatz steht. Seit kurzem haben wir, ohne offensichtliche Veränderung irgendwelcher Einstellungen, folgende Problematik: Wir können den VPN-Tunnel wie gewohnt aufbauen. Beim Aufbauen der RDP-Sitzung kommen wir zur Kennworteingabe, die auch erfolgreich ist. Die RDP-Sitzung geht dann entweder auf und bleibt schwarz oder es steht ca. 2 Minuten "Remoteverbindung wird gesichert" um dann am Ende zu sagen, dass die Verbindung nicht aufgebaut werden kann. Wenn ich danach versuche mich nochmal per RDP zu verbinden, kommt direkt die Meldung, dass die Verbindung nicht hergestellt werden konnte. Baue ich den VPN-Tunnel neu auf, kann ich in der RDP-Verbindung wieder das PW eingeben, die Verbindung wird aber nicht aufgebaut. Wir haben die Fortigate neugestartet, den Domänencontroller, alle Rechner. Im Büro selber funktioniert alles einwandfrei, d. h. ich kann mich auch von meinem Rechner per RDP auf andere Rechner verbinden (was per VPN nicht geht). Im Eventlog des Domänencontrollers sind keinerlei Fehler zu sehen. Auch im Log der Firewall nicht. Anscheinend hängt es in der Phase nach dem erfolgreichen Verbindungsaufbau (TCP 3389) und vor der Authentifizierung. Habt Ihr einen Tip was wir noch prüfen könnten? Vielen Dank! Gruß Jens

Moin, ok, falsch verstanden. Das bezog ich darauf. Also Kommunikation mit zentralem KDC und LocalKDC selber spielen. Der Punkt wo ich auf dem Schlauch stehe ist der, wo aus Sicht des Clients der Unterschied ist, ob er nun gegen einen zentralen oder einen lokalen KDC authentifziert. Der Ablauf müsste für Ihn ja identisch sein, da gleiche Technik aber andere Maschine. Daher auch meine Missinterpretation Deiner Aussage oben. Aber ja eine gewisse Illusion spielt da sicher mit, da gebe ich Dir vollkommen recht!

Kleine Anmerkung am Rande: An sich ein sehr cooles Gerät mit kleineren Schwächen. Habe selbst mal eines geordert. Die Herkunft ist zumindest "interessant". Es wird einem suggeriert, dass es ein europäisches Produkt ist, aber es kommt vollständig aus China. inkl. der Software und auch dem Cloud-Anbindung. Auch konkrete Anfragen ergeben mitunter interessante Antworten. Gesunde Skepsis dürfte nicht verkehrt sein.

Moin an Board, auf geht es in den Tag - ich koche Kaffee Allen einen ruhigen Dienstag, bleibt gesund! Hier aktuell klar bei 10°C Es wird ein schöner Tag bis etwa 23°C

Moin Davorin, es wurde schon angedeutet, dass das von dem Modul verwendete COM-Interface nicht remote funktioniert. Was Du machen kannst, ist per GPO einen Scheduled Task überall hin deployen, der nur on-demand läuft. Den kannst Du dann remote triggern. Brauchst auch das Modul nicht überall, kannst direkt das COM-Interface ansteuern: $wu_session = New-Object -COM "Microsoft.Update.Session" $wu_searcher = $wu_session.CreateUpdateSearcher() $wures = $wu_searcher.Search("IsInstalled=0 and Type='Software'") $updates_to_install = $wures.Updates.Count Write-Host "Updates: $($updates_to_install)" if ($updates_to_install -gt 0) { $wu_dl = $wu_session.CreateUpdateDownloader() $wu_dl.Updates = $wures.Updates $dlres = $wu_dl.Download() if ($dlres.HResult -eq 0) { $wu_in = $wu_session.CreateUpdateInstaller() $wu_in.Updates = $wures.Updates $inres = $wu_in.Install() if ($inres.RebootRequired) { Restart-Computer -Force -Confirm:$false } } }

Genau. Und bei wem holt er sich das Ticket? Und woher weiß er, dass er sich das Ticket dort holen muss? Ich habe übrigens nirgends gesagt, dass der Client (also der Drucker) einen LocalKDC haben muss Aber lassen wir's.

@cj_berlin Also jetzt stehe ich wirklich auf dem Schlauch bzw. verstehe nicht worauf Du hinaus willst. Wozu muss der Drucker ein LocalKDC haben? Er ist ja der "Client" und muss sich ein Ticket holen damit er etwas auf dem Fileserver ablegen kann. Andersum - also wenn ein Windows-Client etwas auf dem Drucker holen will - sieht das natürlich anders aus. Da sind es dann in der Regel Abteilungs-Pins die man eingeben muss. Sofern das überhaupt geht. Normal gibt man für ein Scan-Ziel einen User und einen Pfad pro Ziel an. Sprich man definiert worauf der Drucker zugreifen und mit welchem User/PW er sich anmelden soll. Das Ziel - der Fileserver - sagt ob das mit den User-Creds möglich ist. Wenn es zufällig der gleiche Computer ist, gut, wenn nicht, egal. Zumindest müste es ja so umgesetzt sein mit Kerberos. *hust* Schätze mit NTLM ist es wohl eher so, dass man auf die Ressource zugreifen möchte und die verlangt dann die User-Credentials. Den genauen Ablauf kenne ich nicht. Aber auch da kann man angeben ob es ein Lokales oder ein Domänen-Konto ist. Geht eigentlich immer beides egal ob der Filer in einer Domäne ist oder nicht. Einfach indem User@ComputerFQDN oder User@domäneFQDN angegeben wird. Aktuelle mache ich das so: Separater Scan-Fileserver der in der Domäne ist Lokales Dienst-Konto auf dem Fileserver welches im Drucker angegeben wird (ich mag für Dienskotos üblicherweise lieber lokale Konten, sofern möglich) NTLM für Domänenkonten AD-Weit gesperrt Ausnahme für NTLM auf diesem Fileserver Nur ein spezielles Admin-Konto das sonst nirgends verwendet wird, hat auf dem Filer Anmelderechte mit einem Domänenkonto, sonst niemand, also alle explizit verboten Heisst der Drucker greift mit einem Konto zu, dass nur auf dem Scan-Server existiert. Aktuell verwendet z.B. ein Canon Drucker NTLM um sich zu authentifizieren. Versucht sich jemand mit NTLM gegen ein Domänenkonto via dem Scan-Filer zu authentifzieren, schlägt es fehl obwohl der Filer selbst ein NTLM-Ausnahme hat. Verwendet er ein lokales Konto des Filers, ist es dagegen möglich. -->Schön wäre nun, wenn das ganze über den LocalKDC laufen würde und keine Ausnahme notwendig wäre. Inwiefern es tatsächlich ein Sicherheitsgewinn ist, keine Ahnung. Aber das NTLM nicht sicher ist, wurde bereits bewiesen. ;) Bei den Adresslisten die von einem Server gestellt werden, sieht das anders aus. Da geht oft Druckerweit nur eine Anmeldung an einem Verzeichnisdienst. Da können eigentlich auch alle Kerberos. Selbst Canon. Insofern wüssten die schon wie das geht.

Sehr spannendes Thema , ich suche nämlich was ähnliches

Nach langer Zeit habe ich es noch einmal getestet. Auf dem remote Server ist UAC auf "aus" (unterste Einstellung), der verwendete admin-User ist lokaler Admin auf allen Servern. Ich habe ausprobiert: Invoke-Command -ComputerName REMOTE-SERVER -Credential $Creds -ScriptBlock { Install-WindowsUpdate -AcceptAll -AutoReboot } In einer PS-Session: Install-WindowsUpdate -KBArticleID KB5025229 -AcceptAll -AutoReboot Ich bekomme bei beiden "Access Denied". Direkt am Server ausgeführt funktioniert es. Ich bin doch nicht der einzige, der Windows Updates über remote Powershell installiert, oder?

@Weingeist Du stehst evtl. auf dem Schlauch, denn bei NTLM ist die Ressource dafür zuständig, die Authentifizierung durchzuführen, und sie sucht dann einen DC, falls es sich um einen Domänen-User handelt. Bei Kerberos spricht der Client ja *zuerst* mit dem KDC und besorgt sich ein TGT und dann daraus ein Service-Ticket, und erst dann tritt die Ressource in Aktion. Somit muss bei LocalKDC ja erst mal der Client überhaupt wissen, dass er die Ressource nach dem TGT fragen muss. Bei Windows werden sie es vielleicht irgendwie hinbiegen, als Fallback oder so, was dann vermutlich irgendeinen Angriffsvektor öffnet, an den vorher niemand gedacht hat. Bei einem Scan-To-Folder-Gerät hast Du vielleicht nur einen Fileserver und kannst ihn explizit als KDC eintragen. Was aber, wenn Du mehrere Fileserver hast, aber nur einen Eintrag für den KDC im Client-System, weil der Hersteller davon ausgeht, dass das ganze im AD steht, wenn es schon Kerberos machen will? Alles lösbare Probleme, die aber nicht einseitig durch MSFT gelöst werden können. Da muss die ganze Branche mit anpacken. Und dass Canon, die heute gar kein Kerberos können, morgen neben einem zentralen KDC auch noch LocalKDC spielen, ist eben illusorisch. Insofern wäre IAKerb meines Erachtens erst mal wichtiger, und wenn die ganzen Dritthersteller es sich angewöhnt haben, die Zielressource nach Kerberos zu fragen (IAKerb), *dann* könnte man für Workgroup-Ressourcen auch LocalKDC implementieren.

Livescribe und Wacom habe ich im Chat gefragt, nichts aktuelles ohne zusätzliche Hardware

Amazon sagt, dass LAMY auch sowas herstellt. Ob es was taugt? Da hilft wohl nur Youtube-Videos gucken,

Moin, die Geräteklasse nennt sich "Smart Pen". In Aktion habe ich sowas noch nicht gesehen, daher bin ich skeptisch, ob es wirklich belastbare Erfahrungen mit sowas gibt. Die Idee finde ich ganz hübsch. Gruß, Nils

Danke für die Antworten, ich möchte kein zusätzliches Gerät mitschleppen. Deswegen default Windows für egal welchen Rechner wäre ideal...

@cj_berlin Sehe noch nicht ganz die Problematik. Entweder meldet man sich mit EINEM User an EIN Ziel und somit EINEN lokalen KDC an oder man verwendet EIN Domänenkonte wo die Authentifzierung gegen MEHRERE Ziele (DC's) möglich ist. In beiden Fällen liefert der DNS doch die entsprechenden IP's der bzw. des Anmeldeservers für einen externen Zugriff. Bedingt natürlich, dass der zugreifende User nicht einfach ein Username sondern eben der vollständige Anmeldename ist. Also "user@domänexy.xy" oder "user@computer.domäne.xy". Oder "User@computer.xy". Ist kein DNS vorhanden müsste man eben die IP händisch mit angeben. So wie auch für NTLM wo sie einfach via Broadcast oder auch mit DNS ermittelt wird. Mit der Ressource selbst hat das ja erstmal nichts zu tun, das ist ja immer eine separate Angabe. Oder stehe ich auf dem Schlauch? Wie die ganze Vortrauenssache aussieht damit überhaupt eine geschützte und sichere Authentifizierung vorgenommen werden kann, steht wieder auf einem anderen Blatt. Aber da wird ja MS schon eine Idee haben wenn sie das implementieren. Dazu habe ich mich noch zu wenig damit beschäftigt. Vielleicht weiss ja Du dazu mehr? Ansonsten bin ich mal gespannt wie lange es geht bis die Malware-Entwickler so kreativ werden und die integrierten KI-Funktionen gleich für den Angriff zu nutzen. Könnte "interessant" werden. Hat etwas von der Büchse der Pandora. Ich würde jedenfalls lieber die Lizenzgebühren für ein reines, stabiles, sicheres OS bezahlen. Vielleicht lässt es sich dann ja auch easy entfernen. MS hat ja mittlerweile eine sehr gute Kapselung der Komponenten.

Mit digitalem Stift auf Normalpapier habe ich keine Erfahrung, aber ich verwende ein reMarkable. Das ist ein ePaper-Tablet. Das Schreibgefühl ist dank der nicht ganz glatten Oberfläche wie "echt".

Keine Ahnung. Sowas gibt es und funktioniert? Wie wäre es mit einem13" Ipad und Stift?

Hallo zusammen, wer kann mir hier einen Stift empfehlen, wo man parallel z.B. an Teams Meetings auf Normalpapier Notizen machen kann und diese dann am PC bzw. 2. Bildschirm verfügbar sind? Ebenso wäre es Klasse, damit auch im MS Whiteboard zeichnen zu können. Empfohlen wurde mir der Livescribe Echo2, App und Treiber aus den Rezessionen eher nicht so toll... Gruß Gill

Die Clients bekommen vom DHCP die IP-Adressen aus unserem Client-Netz zugewiesen und im DHCP stehen unsere beiden DNS drinnen (also der DC1 ->primär und der DC2 -> sekundär) Die Clients laufen überwiegend als LAN Geräte können aber auch übers WLAN arbeiten. Der DHCP ist für beide Fälle gleich nur der IP-Adressbereich außerdem die IP vergeben wird ist anders im WLAN