5
MS ODBC Driver 17 18 invalid authorization
Guten Morgen,
folgende Situation:
ich möchte für eine Software statt dem Native Client 11 den Zugang über den MS ODBC Driver 17 oder 18 konfigurieren.
Das ist mir auf einigen Systemen auch gelungen, und war z.B. die Lösung für ein anderes Problem "Certificate is not from a trusted Root CA". Was da "trusted" ist und warum weiß scheinbar nur Microsoft und sollte mit echten Zertifikaten von einer MS anerkannten Root CA nicht auftreten, und tritt auf wenn man seine RootCA "self signed" hat.
Aber...
auf einigen Systemen bleibe ich mit einem Fehler "invalid authorization specification" Fehler hängen, der laut Microsft den Fehlercode 28000 hat (Anmeldefehler) nur vermutlich aus irgendeiner Fremdsprache falsch ins Englische übersetzt. An der Authentifizierung liegt es aber nicht.
Wie debuggt man sowas?
Bisher konnte ich noch kein Muster erkennen, als Clientmaschinen - Windows 10, Windows 11 und Server 2008R2 kriege ich den Login hin, auf einem anderen Windows 10 und einem Server 2016 nicht.
Einziges Indiz wäre noch daß für den Datenbankzugriff ein leeres Kennwort verwendet wird... was mir noch aufgefallen ist, ist daß die GPOs teilweise fehlerhaft oder garnicht auf den Clients verarbeitet werden, auf einigen fehlte z.B. in der Registry der RootCA eintrag - aber der hat damit nichts zu tun und ändert nur eine Fehlermeldung "Certificate is not trusted" in "Certificate is from an untrusted Root CA"
Der ODBC Driver 17 und höher hat dafür eine Checkbox "Trust Server Certificate", die das Problem definitiv löst bzw umgeht, da ich den Treiber bisher nicht dazu bringen konnte, "unsere" RootCA zu akzeptieren - da das ein Inselnetz ohne Internetanbindung ist und in einer Dummydomäne beheimatet ist gibts nur eine Self signed Root CA.
Ich hab ein paar Mutmaßungen dazu gefunden, z.B. gibt es bei Microsoft eine Root Gruppe, der Unternehmen angehören müssen damit Microsoft deren Root CA als vertrauenswürdig einstuft, so wie auch Google und andere Browserhersteller das eigenmächtig entscheiden.
folgende Situation:
ich möchte für eine Software statt dem Native Client 11 den Zugang über den MS ODBC Driver 17 oder 18 konfigurieren.
Das ist mir auf einigen Systemen auch gelungen, und war z.B. die Lösung für ein anderes Problem "Certificate is not from a trusted Root CA". Was da "trusted" ist und warum weiß scheinbar nur Microsoft und sollte mit echten Zertifikaten von einer MS anerkannten Root CA nicht auftreten, und tritt auf wenn man seine RootCA "self signed" hat.
Aber...
auf einigen Systemen bleibe ich mit einem Fehler "invalid authorization specification" Fehler hängen, der laut Microsft den Fehlercode 28000 hat (Anmeldefehler) nur vermutlich aus irgendeiner Fremdsprache falsch ins Englische übersetzt. An der Authentifizierung liegt es aber nicht.
Wie debuggt man sowas?
Bisher konnte ich noch kein Muster erkennen, als Clientmaschinen - Windows 10, Windows 11 und Server 2008R2 kriege ich den Login hin, auf einem anderen Windows 10 und einem Server 2016 nicht.
Einziges Indiz wäre noch daß für den Datenbankzugriff ein leeres Kennwort verwendet wird... was mir noch aufgefallen ist, ist daß die GPOs teilweise fehlerhaft oder garnicht auf den Clients verarbeitet werden, auf einigen fehlte z.B. in der Registry der RootCA eintrag - aber der hat damit nichts zu tun und ändert nur eine Fehlermeldung "Certificate is not trusted" in "Certificate is from an untrusted Root CA"
Der ODBC Driver 17 und höher hat dafür eine Checkbox "Trust Server Certificate", die das Problem definitiv löst bzw umgeht, da ich den Treiber bisher nicht dazu bringen konnte, "unsere" RootCA zu akzeptieren - da das ein Inselnetz ohne Internetanbindung ist und in einer Dummydomäne beheimatet ist gibts nur eine Self signed Root CA.
Ich hab ein paar Mutmaßungen dazu gefunden, z.B. gibt es bei Microsoft eine Root Gruppe, der Unternehmen angehören müssen damit Microsoft deren Root CA als vertrauenswürdig einstuft, so wie auch Google und andere Browserhersteller das eigenmächtig entscheiden.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 61786533423
Url: https://administrator.de/forum/ms-odbc-driver-17-18-invalid-authorization-61786533423.html
Ausgedruckt am: 23.12.2024 um 20:12 Uhr
5 Kommentare
Neuester Kommentar
Hi,
hilft das ?
If you are using a self-signed certificate and the Force Encryption setting on the server to ensure clients connect with encryption, you will need to do one of the following (in order of recommendation):
Change to a certificate that is trusted as part of the client's trust chain.
Add the self-signed certificate as a trusted certificate on the client.
Change your client's TrustServerCertificate connection string setting (or connection property) to yes.
https://techcommunity.microsoft.com/t5/sql-server-blog/odbc-driver-18-0- ...
hilft das ?
If you are using a self-signed certificate and the Force Encryption setting on the server to ensure clients connect with encryption, you will need to do one of the following (in order of recommendation):
Change to a certificate that is trusted as part of the client's trust chain.
Add the self-signed certificate as a trusted certificate on the client.
Change your client's TrustServerCertificate connection string setting (or connection property) to yes.
https://techcommunity.microsoft.com/t5/sql-server-blog/odbc-driver-18-0- ...
es hilft bedingt... Windows Server erstellen bei der Installation ein Self singed Zertfikat. Das im Übrigen acuh vom MS SQL Server und vom IIS verwendet wird. Beim IIS muß man es explizit angeben, beim SQL Server ist die Verwendung implizit. Aber die Maschine hat ein richtiges Zertifikat von unserer Root CA.
Zunächst mal - wo ist der blöde SQL Server Manager? SQLServerManager15.msc ist dein bester Freund, der scih aber nicht im Startmenü zeigt. Fehler im Setup des MS SQL Server Developer/Standard auf Server 2016
https://learn.microsoft.com/en-us/answers/questions/166724/sql-server-co ...
Also einen Shortcut erzeugt und der zeigte mir... 1.) SQL Server fordert keine Verschlüsseling ein 2.) es ist kein Zertifkat konfiguriert. Also schickt er was und wo findet man das?
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/conne ...
Tja und im Ereignisprotokoll - Sytem gibts eine Binäransicht von dem Zertifikat.
Ist UTF8 oder 16 Bit Unicode ... "S E L F S I G N E D"
Daher die Fehlermelding "certificate not from trusted Root CA". Die ist falsch, müßte heißen "Self signed certificate rejected".
Auf diesem (eigenadministrierten) System kann ich das aber ändern
Also richtiges Zertifikat angegeben, aber will nicht.
Aber der Teufel steckt im Detail. Ich übe mich gerade in Selbstzensur, ansonsten kämen jetzt soviele Schimpfworte, daß man mich hier bannen würde.... Kackladen... das darf man wohl sagen. Sprich der SQL Server hat in seiner Qualität echt gelitten die letzten Jahre...
Unable to load user-specified certificate [Cert Hash(sha1) "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
Lol, installiert ist es. Aber während des Setups wrid man gefragt, ob der SQL Server unter "local system" laufen soll oder unter einem spezifischen Dienstekonto. Wählt man die Option für das Dienstekonto, dann kann das wiederum den Private Key nicht lesen.
Das kriegt man dann wie folgt hin: man muß im certlm.msc (manage computer certificates) rechte Maustaste auf das Zertifikat klicken , "manage private Keys" und dem Dienstekonto des MS SQL Servers Zugriff gewähren.
Und schon will der SQL Server, verschlüsselt, der ODBC Driver 18 mäkelt nicht mehr rum von wegen untrusted Root CA.
Aber die Applikation jammert immer noch rum. Der morgige Tag wirft schon mal seine Schatten vorraus, denn da ist Freitag der 13., ich hab heute morgen eine schwarze Katze gesehen und einen Mann mit einer Leiter.
Zunächst mal - wo ist der blöde SQL Server Manager? SQLServerManager15.msc ist dein bester Freund, der scih aber nicht im Startmenü zeigt. Fehler im Setup des MS SQL Server Developer/Standard auf Server 2016
https://learn.microsoft.com/en-us/answers/questions/166724/sql-server-co ...
Also einen Shortcut erzeugt und der zeigte mir... 1.) SQL Server fordert keine Verschlüsseling ein 2.) es ist kein Zertifkat konfiguriert. Also schickt er was und wo findet man das?
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/conne ...
Tja und im Ereignisprotokoll - Sytem gibts eine Binäransicht von dem Zertifikat.
Ist UTF8 oder 16 Bit Unicode ... "S E L F S I G N E D"
Daher die Fehlermelding "certificate not from trusted Root CA". Die ist falsch, müßte heißen "Self signed certificate rejected".
Auf diesem (eigenadministrierten) System kann ich das aber ändern
Also richtiges Zertifikat angegeben, aber will nicht.
Aber der Teufel steckt im Detail. Ich übe mich gerade in Selbstzensur, ansonsten kämen jetzt soviele Schimpfworte, daß man mich hier bannen würde.... Kackladen... das darf man wohl sagen. Sprich der SQL Server hat in seiner Qualität echt gelitten die letzten Jahre...
Unable to load user-specified certificate [Cert Hash(sha1) "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
Lol, installiert ist es. Aber während des Setups wrid man gefragt, ob der SQL Server unter "local system" laufen soll oder unter einem spezifischen Dienstekonto. Wählt man die Option für das Dienstekonto, dann kann das wiederum den Private Key nicht lesen.
Das kriegt man dann wie folgt hin: man muß im certlm.msc (manage computer certificates) rechte Maustaste auf das Zertifikat klicken , "manage private Keys" und dem Dienstekonto des MS SQL Servers Zugriff gewähren.
Und schon will der SQL Server, verschlüsselt, der ODBC Driver 18 mäkelt nicht mehr rum von wegen untrusted Root CA.
Aber die Applikation jammert immer noch rum. Der morgige Tag wirft schon mal seine Schatten vorraus, denn da ist Freitag der 13., ich hab heute morgen eine schwarze Katze gesehen und einen Mann mit einer Leiter.
Edit eine Lösung hab ich bis jetzt noch nicht.
- Invalid Authorization ist eine Meldung, die rein aus der Applikation bzw deren Code kommt, am SQL Server findet ein korrektes Login statt, im SQL Server Log steht nichts, im Ereignisprotokoll des Clients als auch des Servers nichts, sondern nur eine scheinbar durchgereichte Femlermeldung irgendeiner Microsoft Komponente.
- sie tritt nur mit SQL Server Authentifizierung auf, auch mit starken Kennwörtern
- Bei Windows Authentifizierung gegenüber dem MS SQL Server klappt es. Anmeldung am SQL Server erfolgreich.
- die Applikation extrahiert die Verbindungsparameter baut aber eine ADODB Connection auf, die an irtendeiner Stelle wohl mit dem OLEDB19 nicht klarkommt.
- Invalid Authorization ist eine Meldung, die rein aus der Applikation bzw deren Code kommt, am SQL Server findet ein korrektes Login statt, im SQL Server Log steht nichts, im Ereignisprotokoll des Clients als auch des Servers nichts, sondern nur eine scheinbar durchgereichte Femlermeldung irgendeiner Microsoft Komponente.
- sie tritt nur mit SQL Server Authentifizierung auf, auch mit starken Kennwörtern
- Bei Windows Authentifizierung gegenüber dem MS SQL Server klappt es. Anmeldung am SQL Server erfolgreich.
- die Applikation extrahiert die Verbindungsparameter baut aber eine ADODB Connection auf, die an irtendeiner Stelle wohl mit dem OLEDB19 nicht klarkommt.
Hallo GrueneSosseMitSpeck,
der Beitrag steht zwar auf gelöst, aber im letzten Eintrag steht, Du hast noch keine Lösung. Also keine Ahnung, ob Du die Anregung noch brauchst.
Weil Du oben geschrieben hast "Wie debuggt man sowas?": Ich würde das mit dem Profiler und den Audit Events angehen, Login, Login Failed, ...
Außerdem mal an einem Rechner anmelden mit SQL Server- und Windowsanmeldung, von dem aus das funktioniert und an einem, an dem das nicht funktioniert und dann in den Systemtabellen schauen, was drin steht, vor allem sys.dm_exec_sessions fällt mir da ein.
Gruß, Mad Max
der Beitrag steht zwar auf gelöst, aber im letzten Eintrag steht, Du hast noch keine Lösung. Also keine Ahnung, ob Du die Anregung noch brauchst.
Weil Du oben geschrieben hast "Wie debuggt man sowas?": Ich würde das mit dem Profiler und den Audit Events angehen, Login, Login Failed, ...
Außerdem mal an einem Rechner anmelden mit SQL Server- und Windowsanmeldung, von dem aus das funktioniert und an einem, an dem das nicht funktioniert und dann in den Systemtabellen schauen, was drin steht, vor allem sys.dm_exec_sessions fällt mir da ein.
Gruß, Mad Max
also wie debuggt man sowas...
- es gibt keinerlei Debugausgaben. Mit Debugview, Getlasterror Aufrufen und mit Process Monitor: keine Hinweise auch nicht in den ODBC Logs.
- Einzige Informationsquelle ist das Ereignisprotokoll, da System. Dort ist ein Eintrag vom "schannel". Man geht auf die "Detailansicht" und scrollt relativ weit runter, bis man auf "Binary / bytes" angekommen ist, dann werden die Hexcodes und die ASCII Codes sichtbar. Dort kann man sehen ob ein Selfsigned Zertifikat empfangen wurde oder eins von einer CA, wo das Herausgeberzertifikat der CA am Client fehlt.
Und die Situation hat sich grundlegend gebessert, am 14.2.2024 gab es ein Update für den ODBC Treiber "SQL SERVER" Client daß der nun auch Zertifikate und TLS 1.2 unterstützt (ab Windows 10 und ab Server 2019) und eins für OLEDB19, daß OLEDB nun endlich mal im Klartext sagt, was ihm nicht paßt.
- es gibt keinerlei Debugausgaben. Mit Debugview, Getlasterror Aufrufen und mit Process Monitor: keine Hinweise auch nicht in den ODBC Logs.
- Einzige Informationsquelle ist das Ereignisprotokoll, da System. Dort ist ein Eintrag vom "schannel". Man geht auf die "Detailansicht" und scrollt relativ weit runter, bis man auf "Binary / bytes" angekommen ist, dann werden die Hexcodes und die ASCII Codes sichtbar. Dort kann man sehen ob ein Selfsigned Zertifikat empfangen wurde oder eins von einer CA, wo das Herausgeberzertifikat der CA am Client fehlt.
Und die Situation hat sich grundlegend gebessert, am 14.2.2024 gab es ein Update für den ODBC Treiber "SQL SERVER" Client daß der nun auch Zertifikate und TLS 1.2 unterstützt (ab Windows 10 und ab Server 2019) und eins für OLEDB19, daß OLEDB nun endlich mal im Klartext sagt, was ihm nicht paßt.
