4. Der SSPI-Kontext kann nicht generiert werden - ??????

Der SSPI-Kontext kann nicht generiert werden - ??????

  • P

    Hallo

    Ich habe mit c# und ADO.NET ein kleines Programm geschrieben welches von Rechner A aus Daten von einer DB (SQL Server) vom Rechner B ausliest.

    Prinzipiell funktioniert das.

    Wenn ich nun keine Verbindung mehr zum Domönencontroller habe (Rechnername und IP in host datei einegtragen) bekomme ich folgenden Fehler zurück:

    Der SSPI-Kontext kann nicht generiert werden

    Was bedeutet dieser Fehler?
    Und was kann ich tun um auch ohne den DC die Daten abrufen zu können?

    Gruß

    0
  • P

    Hier der Quellcode

    Console.WriteLine("start\t");
            string connectionString = "Data Source=Rechner-B;Initial Catalog=Testpr08;" + "Integrated Security=true";

            // Provide the query string with a parameter placeholder
            string queryString = "SELECT testcolumn from dbo.testtable";

            // Create and open the connection in a using block. This
            // ensures that all resources will be closed and disposed
            // when the code exits.
            using (SqlConnection connection = new SqlConnection(connectionString))
            {
                // Create the Command and Parameter objects.
                SqlCommand command = new SqlCommand(queryString, connection);
                //x command.Parameters.AddWithValue("@pricePoint", paramValue);

                // Open the connection in a try/catch block. 
                // Create and execute the DataReader, writing the result
                // set to the console window.
                try
                {
                    connection.Open(); 
                    SqlDataReader reader = command.ExecuteReader();
                    while (reader.Read())
                    {
                        Console.WriteLine("\t{0}",reader[0]);
                    }
                    reader.Close();
                    connection.Close();
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.Message);
                }
                Console.WriteLine("ende");
                Console.ReadLine()
    0

  • physikus schrieb:

    Der SSPI-Kontext kann nicht generiert werden

    Was bedeutet dieser Fehler?

    Na komm, versuch bloss nicht dir selbst eine Antwort zu ergoogeln.
    Davon abgesehen denk einfach mal nach... Rechner B will ein Domänen-Konto anmelden, der Domain Controller antwortet aber nicht. Könnte das vielleicht Probleme machen?

    Und was kann ich tun um auch ohne den DC die Daten abrufen zu können?

    Na z.B. SQL Server Accounts verwenden.

    0
  • ?

    Ich glaube er ist bei Google gebannnt.

    0
  • P

    Hallo

    AUf die google Idee binn ich auch schon selbst gekommen.
    zb http://support.microsoft.com/kb/925744/de
    aber so richtig klar ist es mir nicht. Insbesondere warum der DC notwendig is wenn doch die Namensauflösung funktioniert.

    AUch das mit dem SQL Server Account habe ich versucht. Allerdings auch ohne erfolg.

    Gruß

    0

  • physikus schrieb:

    Hallo

    AUf die google Idee binn ich auch schon selbst gekommen.
    zb http://support.microsoft.com/kb/925744/de

    Äh. Ja. Das hat mit deinem Problem ja nix zu tun.

    aber so richtig klar ist es mir nicht. Insbesondere warum der DC notwendig is wenn doch die Namensauflösung funktioniert.

    Das hat doch mit Namensauflösung nix zu tun. Du könntest ja genau so gut die IP des SQL Servers in den Connection-String schreiben, DAS ist ja nicht das Problem.

    Du willst dich mit nem Domänen-Account einloggen.
    Der SQL Server will dann natürlich prüfen ob dein Account OK ist (Passwort stimmt, Account nicht gesperrt etc.)
    Und dafür braucht er halt einen Domain-Controller.

    Jetzt könnte man denken "aber ich bin doch schon lokal angemeldet, das muss ja reichen". Tut es aber nicht, weil der SQL Server nicht einfach irgendeiner Workstation vertrauen kann, die meint dass bei ihr User X angemeldet wäre, und das sei schon OK.

    Die Workstation schickt also nochmal die nötigen Informationen an den SQL Server, und der fragt beim Domain-Controller nach ob das OK ist. Da der Domain-Controller aber nicht läuft, kann der SQL Server das nicht, und verweigert natürlich das Login.

    BTW: Workstations merken sich das letzte Passwort (bzw. den Hash) der letzten paar Domänen-Accounts die sich lokal angemeldet haben, damit man sich auch ohne DC lokal anmelden kann. Der SQL Server tut das soweit ich weiss nicht, und da der SQL Server der Workstation wie gesagt nicht einfach so vertrauen kann, verweigert er in so einem Fall den Zugriff.

    Das ist auch nicht wirklich SQL-Server spezifisch. Mit File-Servern, IIS oder ganz allgemein irgendwelchen Services die Domänen-Accounts zur Authentifizierung verwenden ist es das selbe: es geht nix, wenn der DC nicht läuft (bzw. nicht erreichbar ist).

    AUch das mit dem SQL Server Account habe ich versucht. Allerdings auch ohne erfolg.

    Schalte den SQL-Server auf "mixed mode" Authentication um, leg einem SQL-Server User an, gib ihm Rechte die Datenbank zu verwenden und stell eine Verbindung mit dem SQL-Server User her ("username=x;passwort=y;" statt "Integrated Security=true").
    Dazu gibt's aber auch nur ca. 100.000 Beschreibungen im Inet, ich weiss nicht wie man es schaffen kann das nicht zu schaffen.

    0
  • P

    Die Workstation schickt also nochmal die nötigen Informationen an den SQL Server, und der fragt beim Domain-Controller nach ob das OK ist.

    Das habe ich auch so verstanden, bzw hab mir das schon gedacht.

    Zitat:
    AUch das mit dem SQL Server Account habe ich versucht. Allerdings auch ohne erfolg.

    Schalte den SQL-Server auf "mixed mode" Authentication um, leg einem SQL-Server User an, gib ihm Rechte die Datenbank zu verwenden und stell eine Verbindung mit dem SQL-Server User her ("username=x;passwort=y;" statt "Integrated Security=true").
    Dazu gibt's aber auch nur ca. 100.000 Beschreibungen im Inet, ich weiss nicht wie man es schaffen kann das nicht zu schaffen.

    Das hatte ich eigentlich auch so gemacht, mit dem einzigen Unterschied: "Integrated Security=true" habe ich nicht etfernt und es hat nicht funktioniert. Liegt es wirklich daran?

    In der Zwischenzeit habe ich meinen DB Server (läuft auf VM) als DC hochgezogen. Nun habe ich auch auf meiner Testumgebung einen DC und habe das Problem umgangen.

    Da jetzt der DB Server auch DC ist kann ich nur leider nicht mehr einfach testen ober es nun auch ohne DC funktionieren würde wenn ich "Integrated Security=true" weg lasse.

    Trotzdem Danke an alle!!

    0
Anmelden zum Antworten