zahni

Dann sollte der User eh SSO machen und nicht nach einem Konto fragen. Hast Du mal und Email & Konten geprüft, ob da ein Konto steht, dass dort nicht hingehört? Mal löschen und neu anmelden. In dem Admin-Gedöns vom Tennant gibt gibt es auch irgendwo User- und Computerlisten. Dort mal nach dem PC suchen und anschauen. Ist alles aktuell? Sorry, den Rest macht mein Kollege, daher so nebulös.

Ist der Rechner im Azur-AD gejoint? Bin da zwar kein Spezi, aber daran lag es bei uns (mal).

Wurde die Default Domain Controllers Policy verändert? Die muss in der Domin Controller-OU verknüpft sein und deren Einstellungen unterscheiden sich teilweise von normalen Servern und und Clients/Usern. Wenn man dort was ändert, muss man genau wissen, was man macht. Siehe: https://www.vkernel.ro/blog/enable-computer-and-user-accounts-to-be-trusted-for-delegation und https://www.gruppenrichtlinien.de/artikel/wiederherstellung-der-default-richtlinien

Wie meldet er sich denn am SQL-Server an? Also mit welcher Anwendung? Wenn Kerberos nicht korrekt konfiguriert ist, klappt das SSO u.U. nicht. Dann kommt User /Password. Ich hatte schon Fälle, wo die GUI schlicht bestimmte Sonderzeichen im Passwort falsch übertragen hatte, speziell Umlaute und das Paragraphenzeichen. Ob der User vom gewünschten Server ein Kerberos-Ticket bekommen hat, kann man einfach mit "KLIST" abfragen. Da kann man dann auch prüfen ob die Verschlüsselung auf AES-256-CTS-HMAC-SHA1-96 konfiguriert ist. BTW, da fällt mir ein: Vielleicht hat Microsoft in der Windows-Version RC4 und DES deaktiviert, die sind nämlich unsicher. Hier muss man prüfen, ob das Konto mit den SPNs die Option angehakt hat. Ist mir auch vor einiger Zeit bei neueren Java-Versionen auf die Füße gefallen, weil die dort RC4/DES schon entfernt haben.

Du könntest ihm die Umgebung als DL mit seinen (!) Lizenzen betreiben, wenn er mit Dir einen entsprechenden Vertrag abschließt. Der Kunde muss sich dann an die EULA halten, die seinen Lizenzen beiliegt. Der Server darf dann auch nur von diesem Kunden genutzt werden. Du darfst ihm die Lizenzen nicht per monatlicher Gebühr vermieten. Wer den Server bei Hetzner bezahlt, ist vermutlich egal.

Nun musst Du Dir überlegen, was Du oder Dein Kunde mit dem Server machen will. Beachte, dass Du als Endkunde generell kein Recht zur Vermietung hast. Es gibt zwar für Windows External Connector Lizenzen (CAL), die decken aber nicht RDS ab. Auf dem Server dürfen dann nur Du oder mit dir verbundene Unternehmen (keine Kunden) zugreifen.

Meine Anmerkung oben schließt natürlich MFA ein. Wir nutzen RSA SecurID. Hier gibt es sowohl Hardware-Token als auch den RSA Authenticator per App. Via App könnte man auch die Push-Freigabe nutzen. Wenn man sich mit der MS-Cloud verheiratet hat, geht vermutlich auch der MS-Authenticator. Dann gibt es aber keine Hardware-Token.

Ich vermute hier, dass NTLM genutzt wurde. Daher die Klärung. PS: https://learn.microsoft.com/de-de/troubleshoot/sql/database-engine/connect/cannot-generate-sspi-context-error

Wenn man mit den Client-Produkten via Citrix Netscaler ADC oder z.B. Vmware UAG zugreift, halte ich das Risiko für vertretbar. USB, Zwischenablage und Drucken kann man jeweils sperren und die Endpoints hängen eh im Internet, Bei VPN würde ich das auch anders sehen.

Bei mir hatte das komische Kerberos-Tool von MS beim SQL 2022 bei mir nicht mehr funktioniert. Das sollte man händisch machen. Läuft der SQL mit einem Domain-Konto? Da müssen die SPN's rein. Prüfe auch, ob Du nicht irgendwo Dopplungen hast.

Eventuell ein anderer SQL-Client, der kein NTLM mehr macht?

Bei uns Backup-DC: - System State und File-System via Backup Agent -AD-Backup via AD-Agenten der Backupsoftware (damit kann man einzelne Objekte zurück sichern) -Snapshot-Sicherungen der virtuellen DC's. Da kann man sich dann was aussuchen.

Warum kein Backup von den DC's? Wichtig ist, dass man im DR-Fall nur einen DC wiederherstellt und alle anderen DC's neu installiert. Dazu muss man nach dem Restore natürlich vorher die alten DC's im AD entfernen. Einen DC kann man durchaus per Snapshot sichern. Der muss dann aber im DR-Fall der alleinige DC sein. Man darf keinen anderen DC aus einer Snapshot-Sicherung wiederherstellen oder geben einen anderen noch funktionierenden DC.

Eigentlich müsste zuerst ein Migrationskonzept für alle Lösungen erstellt werden und darauf basierend eine Leistungsbeschreibung. Beispielsweise sind nicht alles Anwendungen kompatibel mit WebDAV (Sharepoint, One Drive). Access-DB's werden z.B. komplett heruntergeladen, geändert und wieder hochgeladen. Man kann da nicht gemeinsam zugreifen. Das würde nur über eine Web-Lösung gehen. Die Access Web App ist kaum eine Alternative, zumal man das pro Lösung machen müsste. Ohne so ein Konzept würde ich kein Angebot abgeben bzw. nur ein Angebot zu Konzepterstellung.

Eigener Tennant? Microsoft Entra Connect installiert? Nur dann geht SSO mit dem lokalen AD-Konto. https://learn.microsoft.com/en-us/microsoft-365/enterprise/set-up-directory-synchronization?view=o365-worldwide Ansonsten https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online

Wie wäre es mit Outlook, wie sonst auch? Ansonsten wird der Mac ein korrekt konfiguriertes Autodiscover für Deine Internet-Domain erwarten. https://support.apple.com/de-de/guide/deployment/dep158966b23/web

Ich habe auch die Erfahrung gemacht, dass originale Intel-Treiber besser funktioniert. Leider verpassen sich Hardwarehersteller oft eigene Device-ID, mit denen generische Treiber von Intel nicht mehr funktionieren. Wenn der Treiber sich partout nicht installieren lässt, mal ein den Einstellungen prüfen, ob Flow Control in beiden Richtungen aktiviert ist.

Mein Kollege macht das irgendwie beim SCCM-Deploy der Rechner. Den Bitlocker später für Bios-Updates anzuhalten, ist dann aber kein Problem. Du könntest auch remote mit PSEXECUTE probieren. Die MMC benutze ich auch nur ganz selten, Wir benutzen schon ewig https://www.systemtools.com/hyena/ Da muss man nicht ständig Tools jonglieren und kann bei Bedarf trotzdem entsprechende GUI-Elemente vom RSAT aufrufen.

Ah, ok. Noch nie gesehen oder benutzt. Kaum in meinen "Contoso"-Seminaren offenbar nicht vor. Sieht doch wie ein eigenen Objekt mit Attributen aus. Man lernt nie aus... Das ich ein einem Freitag nochmal das dazulerne

Hm, in meiner MMC kann ich da nichts aufklappen. Wobei ich noch Windows 10 mit den 2019'er Tools habe. Vermutlich ist das nur eine andere Darstellung. Aber gut: Das Property heißt dann wirklich wie im Internet geheißen und man kann es auch mit Domain-Admin-Rechten nicht direkt in der Liste der Attribute sehen. mit den 2019'er MMC-Tools ist es komplett unsichtbar. Und wenn MS das als "Child-Object" bezeichnet, ok. Auf diese Daten kann man aber eben nur via einer speziellen API zugreifen: https://learn.microsoft.com/en-us/powershell/module/mbam/read-adrecoveryinformation?view=win-mdop2-ps

Ich habe mal ein wenig bei uns geguckt und gegoogelt. Ich tippe darauf, dass der im "ntsecuritydescriptor" gespeichert wird. Das Attribut zeigt die normale MMC von Windows nicht an. Nur ein Zusatztool von uns. In der MMC ist eine Funktion implementiert, die dann im Reiter Bitlocker Wiederherstellungsschlüssel den Schlüssel anzeigt. Hier habe ich dazu eine längere Diskussion gefunden. Ich warne aber davor, hier irgendwelche Rechte zu verstellen: https://administrator.de/forum/bitlocker-wiederherstellungsschluessel-werden-nicht-im-ad-gespeichert-343431.html

Hä? Der Recovery-key ist doch nur ein Property im Computer-Objekt.

Hatte er die Funktion "Vorschaltseite anzeigen" aktiv und dort eine geeignete Haftungsausschluss-Erklärung platziert? Bitte mal nach wlan störerhaftung Googeln. Leider kein ganz einfaches Thema, wo ihm nur ein Anwalt helfen kann. Eigentlich soll die Störerhaftung abgeschafft sein, leider ist dies im Detail dann doch nicht so. Siehe https://www.wbs.legal/urheberrecht/bgh-zur-stoererhaftung-gewerbliche-betreiber-offener-wlan-netze-koennen-sich-freuen-24238/ PS: Rechtsberatung ist und leider nicht erlaubt.

Ich glaube, so einfach geh das nicht. Dieses Property ist explizit nur für Domain-Admins lesbar und beschreibbar, damit andere User die Recovery-Keys nicht auslesen können.

Heute kam dann doch wieder ein Report. Keine Ahnung, was da geklemmt hat. Sogar Beide: Den von "Enterprise" und von Outlook.com Irgendwie haben die Spammer unsere Domain als Absender entdeckt...