Alle Aktivitäten

Hallo, ich muss, das erste mal seit 25 Jahren mal wieder eine Vertrauensstellung zwischen zwei domains herstellen. Der Schock, brauche ich dafür wirklich WINS? Ich habe es konfiguriert aber es funktioniert nicht. Die Ports 137 und 138 habe ich freigegeben. Doch der WINS behauptet immer noch. das er inaktiv wäre.

Hi, was wird in diesem GPO denn im Bereich der "Scripts" (Startup / Shutdown / Logon / Logoff) erledigt? Für die GPPs: GPS: Configure Drive Maps preference logging and tracing GPS: Configure Files preference logging and tracing GPS: Configure Folder Options preference logging and tracing GPS: Configure Registry preference logging and tracing Gruß Jan

Was mir gefällt: Du brauchst kein Mega-Technik-Wissen. Ich arbeite im Vertrieb und will einfach nur verstehen, wie KI mein Daily Business unterstützen kann.

@Update wir sind mittlerweile auf drei PCs gekommen die das Problem haben. bei alle drei ist im Event Log der Fehler mit dem "Benutzername oder Kennwort falsch" Das Auftreten hat auch kein System. Im Event Log ist bei dem ersten beiden Usern einmal Anfang und ende Januar aufgetreten, bei dem dritten im März. Alle drei sind auch in unterschiedlichen Abteilungen, haben also nichts direkt gemeinsam was ich jetzt so erkennen könnte.

Moin an Board, auf geht es in den Tag - ich koche Kaffee Allen einen ruhigen Donnerstag, bleibt gesund! Hier derzeit teilweise Bewölkt bei 9°C Wird nicht so warm, bis etwa 14°C Regen ist hier keiner gefallen, heute auch nichts in Sicht

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...