none
Verbindung zu SQL2005/2008 Express nur in Domaine möglich RRS feed

  • Frage

  • Hallo zusammen,

    Wir entwickeln Warenwirtschaftssysteme, die bei einigen Kunden in zwei verschiedenen Modi auf demselben Rechner (Notebook) laufen:

    - in der Domaine mit Zugriff auf den zentralen SQL2005/2008
    - ohne Domaine (mobil) mit Zugriff auf einen local SQL2005/2008 Express

    Die Anmeldung erfolgt per RDO/ODBC (VB6-Anwendungen) über einen SQL-User.

    Problem:
    Wenn die Notebooks (WinXP / Win7) in der Domaine angemeldet sind, laufen beide Modi ganz normal, auch parallel.
    Ist ein Notebook nicht mit der Domaine verbunden (kein Netzkabel angeschlossen) bringt der Anmeldeversuch am lokalen SQL2005/2008 Express Fehlermeldungen wie 'Timeout abgelaufen' (Windows 2003 R2 Standard - Domaine) oder 'SSPI-Kontext kann nicht generiert werden' (Windows 2008 Standard - Domaine), Verbindung kann nicht hergestellt werden.
    Da das Problem vom Versionsstand der Domäne bzw. des AD abhängig zu sein scheint - in einer Win2000-Umgebung tritt es nicht auf - habe ich schon einige Versuche mit SPN-Einträgen bzw. SQL-DienstUsern gemacht, der jeweilige SQL hatte als ServiceUser schon einen DomaineUser, NetworkService, LocalSystem ...

    Meine Suchen bei MSDN & TechNet bringen mich nicht mehr weiter.
    Hat jemand eine Idee?

    Danke im voraus
    Gruß

    DevPK

    Dienstag, 2. Februar 2010 15:46

Antworten

Alle Antworten

  • Hallo DevPK,

    'SSPI-Kontext kann nicht generiert werden'

    Das hört sich für mich zunächst eher so an, als würde die Anmeldung doch nicht über einen SQL-User Account laufen, sondern über die Windows Authentifizierung.
    Sieh doch mal SSMS im Aktivitätsmonitor nach, mit welchem Account der User sich wirklich angemeldet hat.
    Poste auch mal den Connection-String für die Anmeldung.

    Bis SQL Server 2005 war es so, das der lokale Admin zugleich auch SQL Server Admin war. Wenn die User auf ihren Notebooks lokale Admin Rechte haben, dann hat auch die Anmeldung an den SQL Server über die Windowa-Auth immer geklappt.
    Mit SQL Server 2008 hat sich das geändert, da muss man die Mitglieder der SysAdmin Gruppe explizit festlegen.



    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Mittwoch, 3. Februar 2010 07:21
  • Hallo Olaf,

    das ist richtig, die Meldung 'SSPI-Kontext ....' kommt aus einigen meiner Versuche mit ODBC-Verbindungsargument = 'Trusted_Connection=yes'. In dem Fall kommen die Meldungen sowohl von einem WinXP- als auch von einem Win7-Rechner, beide verwenden SQL 2008 Express.

    das Code-Häppchen sieht so aus:

    Dim env As rdoEnvironment
     .
     .
     
       Set env = rdoEnvironments(0)
       If gbKDS_Prg_Aktivierung2 = True Then
          gsODBCConnect = "Trusted_Connection=yes"
       '   gsODBCConnect = "Trusted_Connection=True"
       Else
       '   gsODBCConnect = "UID=sa;PWD=KDSTeam_09"
          gsODBCConnect = "UID=" & gsKDS_UID & ";PWD=" & gsKDS_PWD
       End If
      
       Set gdbDBMS = env.OpenConnection(gsODBCService, rdDriverNoPrompt, False, gsODBCConnect)

    Du siehst, ich habe schon einige Versuche hinter mir, sogar mit SA. Alle Anmeldungen laufen, wenn der Rechner mit der Domain verbunden ist (Netzkabel), sogar wenn ich mich mit einer lokalen UID anmelde.

    Der verwendete SQL-User (gsKDS_UID & gsKDS_PWD) hat mittlerweile auch SysAdmin-Rechte.

    Danke vorerst mit
    Gruß

    Peter = DevPK

    Mittwoch, 3. Februar 2010 10:19
  • Hallo Peter,

    mit RDO habe ich noch nie gearbeitet, das Verhalten davon kenne ich nicht.

    Wenn ich es richtig sehe, verwendest Du eine vorhandene ODBC Verbindung, also eine, die über odbcad32.exe angelegt wurde.
    Dort kann man schon angeben, ob eine "Trusted_Connection" verwendet werden soll oder nicht.
    Sieh bitte mal nach, ob das bei der verwendeten so ist.

    Steht das dort drin, wird das vermutlich auch weit verwendet, egal ob Du eine SQL Account user id + pwd angibst oder nicht.
    Deswegen der Hinweis auf Aktivitätsmonitor oder Profiler - LoginEvents, um zu prüfen, ob die Anmeldung über Win oder SQL läuft.
    Sonst setze auch mal versuchsweise "Trusted_Connection=no", wenn der SQL Account genutzt werden soll.

    Wenn ich mich recht entsinne (ist sehr lange her), konnte man bei DAO als Parameter dbDriverComplete angeben (analog zu "rdDriverNoPrompt"), um den ConnectionString der ODBC Quelle zu überschreiben.

    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Mittwoch, 3. Februar 2010 11:57
  • Sieh Dir auch mal diese KB Artikel an
    http://support.microsoft.com/default.aspx/kb/811889
    http://support.microsoft.com/kb/843248

    http://blogs.msdn.com/sql_protocols/archive/2005/10/19/482782.aspx





    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    • Als Antwort markiert DevPK Montag, 15. Februar 2010 13:12
    Mittwoch, 3. Februar 2010 12:57
  • Hallo Olaf,

    mit RDO muss man auch nicht gearbeitet haben, das ist Vergangenheit, sollte man besser vergessen ... aber wer hört schon auf mich? ;-)

    Richtig, die ODBC-Verbindungen werden bei Installation der Anwendung manuell eingerichtet. Sie werden alle mit SQL Server-Authentifizierung definiert, dabei wird dieselbe UID zum Abruf zusätzlicher Konfigurationsoptionen angegeben - was auch klappt. Die Bestätigung durch odbcad32 klappt übrigens auch in den Situationen in denen der Connect aus der Anwendung nicht geht. Ein Beispiel für diese Konfigurationen (sind alle gleich):

     Microsoft SQL Native Client Version 09.00.4035

     Datenquellenname: SQLDBDKS
     Datenquellenbeschreibung:
     Server: PC19\SQLEXPRESS
     Integrierte Sicherheit verwenden: No
     Datenbank: DKSDIA                 -------
     Sprache: (Default)
     Datenverschlüsselung: No
     Vertrauenswürdiges Serverzertifikat: No
     Multiple Active Result Sets(MARS): No
     Spiegelserver:
     Zeichen konvertieren: Yes
     Abfragen mit langer Laufzeit protokollieren: No
     Protokolltreiberstatistik: No
     Ländereinstellungen verwenden: No
     ANSI-Anführungszeichen verwenden: Yes
     ANSI-Nullen, -Leerzeichen und -Warnungen verwenden: Yes

    Die Anmeldung über Kerberos-Authentication (Trusted_Connection) habe ich auch nur zum Test verwendet.
    Deinen Hinweis auf Aktivitätsmonitor oder Profiler werde ich auch noch anwenden, mein Problem dabei ist jedoch die Location der beiden Kundn, bei denen der Fehler auftritt: der eine sitzt in Zürich, der andere in Antwerpen. D.h. ich erreiche die Rechner nur über VPN/RDP, und auch das nicht jederzeit. In der problematischen Phase, also ohne Netzverbindung, erreiche ich sie gar nicht.

    In der mir zur Verfügung stehenden Entwicklungsumgebung - WinXP/Vista/Win7 in einer UraltWin2000 Domäne - tritt der Fehler übrigens nie auf. Allerdings habe ich z.B. auf einem Win7-Notebook den lokalen SQL2005 installiert (alle Service auf LocalSystem), BEVOR ich den Rechner in die Domaine genommen habe, SetSPI zeigt mir also auch keinen Eintrag - trotz LocalSystem. Die SQL-Server auf den problematischen Notebooks wurden alle auf DomainComputers installiert, hatten also von Anfang an die SSPI-API's zu Verfügung.

    Ein weiterer Hinweis auf eine mögliche Abhängigkeit der Anmeldung von AD-Methoden:
    Der Admin in Antwerpen hat bei seinen Tests auf dem Notebook alle Netzwerkverbindungen deaktiviert, der Anmeldeprozess kommt also gar nicht erst auf die Idee, nach einem AD auf einem DomaineController zu suchen - die Anmeldung (SQL 2k8 Express) mit SQL-User klappt sofort. LAN-Verbindung wieder aktiviert (ohne Kabel) - Anmeldung nicht möglich.

    Den DAO-Parameter dbDriverComplete gibts auch für RDO -> rdDriverComplete, damint klappt die Anmeldung ebenso wie mit rdDriverNoPrompt.
    Der Aufbau des ConnectStrings ist - glaube ich - auch nicht das eigentliche Problem, wenn die Rechner am Netz hängen gehts ja...


    Gruß
    Peter

    Mittwoch, 3. Februar 2010 13:58
  • Hallo Olaf,

    Dein zweites Posting habe ich erstmal übersehen :-(

    Den ersten Link habe ich schon seit Tagen augedruckt nebe mir liegen, der Fix aus dem zweiten Link (auch schon ausprobiert) lässt sich in der betreffenden Konfiguration nicht anwenden.

    Aber der dritte Link sieht sehr vielversprechend aus, werde die Lösung probieren.

    Danke und Gruß
    Peter

    Mittwoch, 3. Februar 2010 15:11
  • Hallo Peter,

    sonst fällt mir auch nichts mehr dazu ein, wird wahrscheinlich irgendeine einfache (blöde) Sache sein.
    Ich hatte mal regelmäßig Meldungen

    SSPI handshake failed with error code 0x80090324 while establishing a connection with integrated security; the connection has been closed.

    im Log gehabt, bis ich heraus gefunden hatte woran es lag: Die Uhrzeit des Clients ging gegenüber des Servers um über 5 Minuten nach und schon ist man als Client nicht mehr vertrauenswürdig ...


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Donnerstag, 4. Februar 2010 07:48
  • Hallo Olav,

    der dritte Link wars...
    TCP/IP sowohl im SQL2k8 als auch im NativeClient ausschalten und mit sa anmelden, dann geht's.

    Danke und Gruß
    Peter
    Montag, 15. Februar 2010 13:11