Datenbank auf einen anderen Server und eine neuere SQL Server Version umziehen

[cj_berlin 1.138]

vor 56 Minuten schrieb t-sql:

Außerdem ist Best Practice eben keine SQL Authentifizierung zu nutzen.

"Best Practice" ist ein starkes Wort. Das Microsoft-Dokument dazu listet 5 Advantages und 4 Disadvantages der SQL-Auth auf, somit hätte nach Business Consultant-Logik die SQL-Auth gewonnen  . Auch wenn dort am Anfang steht, man solle wo möglich Windows-Auth verwenden. 

 

Der einzige wirkliche Vorteil der Windows-Authentifizierung ist, dass Kerberos verwendet werden *kann*. In Realität jedoch

• funktioniert dies nur, wenn zwischen SQL-Server und dem zugreifenden User eine Vertrauensstellung existiert. Und in gehärteten AD-Umgebungen müsste man das auf "...und dem User sowie dem Client" verschärfen.
• sind SQL-Server *und Clients* oft fehlkonfiguriert, so dass selbst innerhalb eines AD-Forests auf NTLM zurückgefallen wird.
• bei der Notwendigkeit, andere Credentials als die angemeldeten zu verwenden: Die Anwendung muss Impersonation verwenden, das heißt Windows-seitig am Client den Context wechseln.
• bei der Notwendigkeit, Credentials zu speichern: mit SQL-Auth sind es Credentials, die im Zweifel nichts außer ihre Berechtigungen auf dem SQL-Server missbrauchen können, bei Windows Auth ist es ein Account, das auch woanders Permissions hat, und sei es nur Permissions sich anzumelden.
• bei Betrieb von SQL auf Linux: der Linux-Server muss in den Kerberos-Realm von AD integriert werden, um Windows Auth zu verwenden

Und da sind wir noch nicht im Dev-Test-Integration-Teil angekommen, wo es bei Windows-Logins nicht möglich ist, die Datenbank lustig hin und her zu transportieren und dabei Berechtigungen zu erhalten.

 

Ich will damit keine Diskussion vom Zaun brechen, sondern nur den Ton der bereits begonnenen Diskussion ein wenig mäßigen, denn was des einen Best Practice ist, kommt bei dem anderen aus zwingenden technischen Gründen gar nicht in Frage.

[zahni 521]

vor 2 Stunden schrieb t-sql:

Siehste. ist halt in deinem Kontext so. Bei uns isses genau umgekehrt. Daher einfach net pauschale Aussagen über sowas machen. Außerdem ist Best Practice eben keine SQL Authentifizierung zu nutzen.

Mag sein. Die einzige Server-Anwendung, die hier tatsächlich Kerberos-SSO gegen einen SQL-Server macht, ist der WSUS-Server. Und dort muss man das Computer-Konto berechtigen. Alle anderen Anwendungen, inkl. Server-Applikationen, die in .NET geschrieben sind, bekommen das nicht hin. Denn auch hier müsste das Computer-Konto verwendet werden oder die Client-Authentifizierung via Kerberos Delegation durchreichen. Ziel ist ja, dass man nirgendwo ein Passwort konfiguriert. Clientseitige Zugriffe auf den SQL-Server sind natürlich etwas Anderes.

 

[Forseti2003 14]

Die Group-BY-Fehlermeldung klingt fast, als wenn das Frontend ACCESS wäre. Die Fehlermeldung kenne ich, wenn Anwender eine Spaltensortierung Gruppieren und im Formular abspeichern - auch wenn diese dann unsinnig ist. Beim starten des Frontend kommt dann auch so eine Fehlermeldung.

bearbeitet 10. Oktober 2023 von Forseti2003

[stefannsv 0]

OK danke für den Hinweis. Bei der Anwendung handelt es sich allerdings nicht um ein Access Frontend.

Die Daten des Frontends stehen in einer SQL Server Datenbank. Von daher ist eine Group-By bzw. Group-By Klausel in einer Abfrage gegen die SQL Engine eigentlich völlig ok.

[Forseti2003 14]

vor 30 Minuten schrieb stefannsv:

OK danke für den Hinweis. Bei der Anwendung handelt es sich allerdings nicht um ein Access Frontend.

Die Daten des Frontends stehen in einer SQL Server Datenbank. Von daher ist eine Group-By bzw. Group-By Klausel in einer Abfrage gegen die SQL Engine eigentlich völlig ok.

Group-By per se ist kein Problem, außer das in der Abfrage eventuell noch auf einen alten Befehlssatz zugegriffen wird. Du migrierst ja von einer alten auf eine neue Version.