cj_berlin

Doch, doch, die kommen später. Und im Kerberos-Ticket, das Du beim Benutzer sieht, steht der korrekte UPN und auch der korrekte SPN für HTTP/exchange? Kannst Du anhand der IIS-Logs sehen, welches virtuelle Verzeichnis die erneute Authentifizierung verlangt?

Ja. Und es gibt fast jeden Monat Updates, die Kerberos betreffen und etwas kaputtmachen. Wo ist denn hier ein Widerspruch?

Moin, es ehrt Dich, dass Du von Deinen Erfahrungen und gefundenen Workarounds berichtest. Allerdings glaube ich, dass es hier um mehrere Probleme geht, die miteinander nichts zu tun haben: das Riesenfenster, das nicht minimiert oder normalisiert werden kann --> noch nie an dieser Stelle gesehen, aber ein paar andere Dialoge haben das in der Vergangenheit auch schon "geschafft" --> bei Fenstern, die normalerweise sofort wieder verschwinden, ist es meistens kein Problem. die Anmeldung mit dem UPN dauert länger als mit dem sAMAccountName --> wenn man sich anschaut, wie Kerberos im Vergleich zu NTLM funktioniert, gewinnt man schon den ersten Anhaltspunkt dazu, wo man suchen sollte. Ich würde ja gern "lernt man in jedem Server-Lehrgang" hinzufügen, aber leider weiß ich nur zu gut, dass dem nicht so ist :-( Und wenn in Deiner Infrastruktur tatsächlich Fehlkonfigurationen vorhanden sind, die ausgerechnet bei RDP ein Fallback von Kerberos auf NTLM erforderlich machen, dann solltest Du diese dringend suchen und beheben, statt nach Workarounds bei einem einzelnen Symptom zu forschen.

Moin, Azure AD hat übrigens auch eine solche Prüfung, die durchaus auch für synchronisierte AD-Accounts angewandt wird. Beim Passwortwechsel in AD freilich erst im Nachhinein, beim Passwortwechsel in AAD halt schon bevor das Passwort gesetzt wird. Aber die haben auch einen eigenen Filter-Agenten, den man für die Prüfung im AD, aber gegen die Listen aus dem Azure AD, einsetzen kann. Diesen würde ich im Zweifel als vertrauenswürdiger einstufen als eine Third Party. Das generelle Problem bei ALLEN diesen Filter-DLLs ist, dass in Windows keinerlei API existiert, um dem Kontoinhaber mitzuteilen, WORAN GENAU sein Änderungsversuch gescheitert ist.

Das wiederum hinge davon ab, ob Outlook im Online Mode oder im Cache Mode betrieben wird

Moin, ich rekapituliere: Angst vor Server mit externem Zugriff (es ist auch keiner da, der Ihn sinnvoll betreiben könnte) Mail liegt jetzt schon dauerhaft auf einem Server herum, der aus dem Internet frei erreichbar ist (STRATO) Windows-Benutzer ist überall gleich Die Lösung ist *eigentlich* Exchange Online, und den/die vorhandenen User nicht ins Azure AD synchronisieren, sondern die Anmeldung in Outlook explizit durchführen. Das zu lizenzieren, wird allerdings spannend, denn Du musst ja echte User lizenzieren, aber solche Sammelpostfächer, auf die man mit "ihrem" Usernamen zugreift, brauchen ebenfalls eine Lizenz...

Es kann ja ein Drucker im Büro stehen und trotzdem über Follow-Me erreichbar sein Die meisten Anbieter unterstützen inzwischen auch Kleingeräte und sogar die von der Konkurrenz.

Drum mache ich den Kram auch nicht mehr. Enough is enough. Ich habe mir 25 Jahre lang den Mund in diversen Sachen fusselig geredet. Habe neulich in den Archiven eine Mail-Konversation entdeckt, wo ich 2007 jemanden darauf hinwies, dass man auf DCs den Print Spooler deaktivieren sollte. Und, hat jemand drauf gehört? So ist es hier auch.

Dem Partner erklären, dass ein Verfahren, das zwingend auf Gateway-to-Gateway-Verschlüssellung beruht, Murks und rausgeschmissenes Geld ist, denn: die Vertraulichkeit ist nicht besser als bei TLS (was vermutlich eh schon da ist): Innerhalb beider Mailsysteme liegt Kartext, dazwischen ist verschlüsselt die Authentizität (der Organisation, nicht des Absenders!) und die Integrität können mit DKIM gewährleistet werden, was die Mailsysteme möglicherweise bereits können Es ist im Business-Umfeld auch vollkommen unklar, wofür das gut sein soll. Innerhalb der Mailsysteme möchte man explizit Klartext haben, weil Stellvertretung Archivierung DSGVO Antimalware und nach außen kommunizieren die Mailsysteme direkt miteinander oder durch Services, deren Geschäftsauftrag es ja ist, den Content zu untersuchen! Integrität kann man mit DKIM genauso gut absichern wie mit S/MIME-Signatur. Und gegen Wiretapping hilft TLS ausreichend gut.

Ja, nur so funktioniert es auch mit den Domain-Zertifikaten, as defined in RFC3183.

Moin, da Windows IoT auch nicht die VDA ersetzt, wäre es zumindest nicht falscher als vorher

Juchu, ich habe eine Frage! Ist aber vollkommen unwichtig, ich muss halt jeden Tag drüber schmunzeln Meine Audio-Steuerung sieht nämlich (auf allen Geräten zwischen Win10 und Win11 konsistent) so aus: ist eine 3,5mm Buchse direkt am Laptop, in der noch nie irgendwas drin gesteckt hat - vermutlich werden's aber eher Kopfhörer als Lautsprecher sein sind ganz eindeutig Kopfhörer, die hinter diesem Bluetooth-Dongle sind das ist eine 3,5mm Buchse an der Docking Station - vielleicht schließt da jemand auch mal Kopfhörer an, aber hier waren es immer die Lautsprecher). Ich bin mir nicht sicher, ob sie auch Audio-In kann, das würde die Einstufung als "Headset" erklären. Nun ja, ist halt auch eine 3,5mm Buchse, aber da würde man vermutlich wirklich Kopfhörer anschließen. Ich habe kein zu lösendes Problem, daher auch zu faul zum Suchen - falls jemand aber aus dem Kopf weiß, wo die Info versteckt ist (INF-Dateien, Device Manager, Registry, was weiß ich), würde ich da gern ein wenig herumstöbern... Danke im vorab!

Sehr relevant --> Thin Clients mit Windows 7 Embedded. Da sind in einigen Behörden noch Zehntausende von unterwegs. Die hat man ja gekauft mit der Maßgabe, dass sie länger leben als Arbeitsplatz-PCs, und auch weniger anfällig für Schweinereien sind, weil Write Filter Ich würde sagen, Tippel-Tappel-Troubleshooting: ist der Port 3389/tcp vom Win7-Client zum Server grundsätzlich erreichbar? Test-NetConnection oder PORTQRY... ist evtl. der Server auf "Nur UDP" und die Win7-Clients auf "Nur TCP" für RDP konfiguriert? irgendwelche anderen Inkompatibilitäten in den Settings? WMI-Klassen Win32_TSGeneralSetting und Win32_TerminalServiceSetting sind Deine Freunde - da Du einen funktionierenden Server hast, einfach mit diesem vergleichen. WireShark / NetMon und schauen, was da läuft bzw. an welcher Stelle im Datenaustausch das knallt. Könnte bereits TLS sein, je nachdem, was die Policy sagt.

Moin, ja, das tritt bei 2019 öfters auf. Aber nicht überall. Ich habe bisher nicht herausfinden können, woran das liegt. Lizenzen werden nach 120 Tage Nichtbenutzung von alleine frei. Aber so lange könnt ihr natürlich nicht warten. Ticket aufmachen, vielleicht kann der Hersteller euch helfen. Bis dahin die User schulen, dass sie den Namen immer klein eingeben.

Moin, was @NilsK sagt. Aber: Du könntest mal mir Process Monitor versuchen, festzustellen, wo es genau knallt. Vielleicht ist es so eine olle App, die Zustandsdaten im Programmverzeichnis (statt %ProgramData%, %AppData% oder %temp%) oder Einstellungen im Maschinen- statt im Userzweig der Registry speichern will. Dann kannst Du dem Benutzer (oder der Gruppe "Users" des lokalen Computers) gezielt Schreibrechte genau dort geben. Und dem Hersteller dann trotzdem die Hände abhacken

Moin, ich meine, es gab mal ein Problem mit Firefox, wenn in den SANs sowohl ein konkreter FQDN stand als auch ein Wildcard-FQDN, der auf den konkreten auch gepasst hätte, also praktisch *.doma.in und www.doma.in. Dann wurde bei mail.doma.in bei Firefox anstandslos validiert und bei www.doma.in der o.g. Fehler geschmissen. Aber das ist die schwindende Erinnerung eines alten Mannes, braucht also nicht zu stimmen Kannst Du das Zertifikat noch einmal neu ausstellen, aber die Reihenfolge der SANs vertauschen, so dass der, den Du tatsächlich aufrufst, an erster Stelle steht?

Wollen wir das jetzt einen "FALSE-1" Restore nennen?

Nö, 2004 gab es noch. Danach kam erst 20H2.

Ich habe den im Dinosauerier-Saal des Naturkunde-Museums gehalten, das war geil

Ist aber oben schon verlinkt, daher musst Du noch nicht einmal schlechtes Gewissen haben

Ein Fullscan hat IMO nur zwei Funktionen: bei persistenten Maschinen: Zero Days entdecken, bevor sie aufgerufen werden, indem die zuvor als sauber markierten Dateien nochmal gescannt werden. Das natürlich unabhängig von FVE, siehe Solorigate. bei nicht-persistendent Maschinen (VDI): Golden Image vorbereiten, damit die einmal als sauber eingestuften Dateien markiert und in Zukunft vom On-Demand-Scan übersprungen werden.

Das oder so etwas in der Art meinte ich mit "Stricken".

Moin, so wie Du es beschreibst, wird es wahrscheinlich nicht klappen. Je nachdem, was mit "auf Prozess warten" technisch gemeint ist, kann man da vielleicht etwas drumherum stricken, aber RemoteApp in Reinform gibt so etwas nicht her.

Moin, mit dem Visual Studio-Abo (aber nicht mit jedem, wenn ich mich Recht erinnere) gibt es Azure-Guthaben. Es ist natürlich nicht ganz kostenlos 😉

Ich werde diese Diskussion hier nicht weiter führen, aber falls es tatsächlich genau dieser Fall war (sprich: zwei Instanzen auf einer Maschine, ihr hattet die Lizenzierung für die höhere Version neu gekauft, die Lizenzierung für die ältere Version schon vorher besessen und Microsoft ließ euch eine zweite bzw. in diesem Fall ja sogar dritte Lizenz kaufen), solltet ihr das vielleicht noch einmal betrachten Wenn ihr in Wirklichkeit *zwei Server* hattet, dann ist natürlich alles richtig, aber das ist nicht das Thema in diesem Thread.