Jump to content

Windows-Authentifizierung SQL-Server geht nicht


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

ich habe bisher einen Windows 2003-Server als Domänencontroller mit SQL-Server 2005 darauf laufen. Die Clients melden sich im Netzwerk lokal (nicht in der Domäne) an (da Novell-Netz). Trotzdem funktioniert hier die integrierte Windows-Authentifizierung gegenüber dem SQL-Server.

 

Jetzt will ich einen weiteren SQL-Server ins Netz bringen, auf dem ebenfalls die Windows-Authentifierung genutzt werden soll. Dieser ist aber kein DC! Er ist allerdings als Member-Server in der Domäne.

 

Zu diesem Server bekomme ich vom Client nur eine Win-Auth hin, wenn der User sich in der Domäne anmeldet. Kann man das ändern? (Wenn ich den User lokal auf dem neuen Server habe, klappt die Authentifizierung, aber ich will die User natürlich aus der AD verwenden).

 

Scheinbar leigt es an dem ertsen Teil der Anmeldung gegenüber dem SQL-Server "Rechnername\User" statt "Domänenname\User". Aber warum klappt es auf dem DC und nicht auf einem Meberserver?

 

Folgende Fehler stehen im Anwendungsprotokoll (des neuen Servers):

 

Ereigniskennung 17806

Fehler beim SSPI-Handshake (Fehlercode 0x8009030c) beim Herstellen einer Verbindung mit integrierter Sicherheit. Die Verbindung wurde geschlossen. [CLIENT: IP-ADRESSE]

 

und

 

Ereigniskennung 18542

Fehler bei der Anmeldung für den Benutzer ''. Der Benutzer ist keiner vertrauenswürdigen SQL Server-Verbindung zugeordnet. [CLIENT: IP-ADRESSE]

 

Für Hinweise bin ich sehr dankbar!!

 

Viele Grüße,

 

Carsten

Link zu diesem Kommentar

Hallo Namensvetter

 

ich habe bisher einen Windows 2003-Server als Domänencontroller mit SQL-Server 2005 darauf laufen. Die Clients melden sich im Netzwerk lokal (nicht in der Domäne) an (da Novell-Netz).

Ja wie jetzt nun? Du hast ein AD, welches du nicht nutzt, da du ein Novell-Netz hast?

 

Dieser ist aber kein DC! Er ist allerdings als Member-Server in der Domäne

Der Novell- oder der AD-Domäne?

 

Vergleich mal deine Network Configurations der beiden SQL Server Installationen per MS SQL Server Configuration Manager. Sind die beide identisch konfiguriert was die zu verwendenden Protokolle angeht?

 

Weitere Infos zu deinen Eventlogeinträgen:

Windows Event ID 17806 from MSSQLSERVER

Link zu diesem Kommentar

Hallo,

 

Hallo Namensvetter

 

 

Ja wie jetzt nun? Du hast ein AD, welches du nicht nutzt, da du ein Novell-Netz hast?

 

 

Der Novell- oder der AD-Domäne?

 

Vergleich mal deine Network Configurations der beiden SQL Server Installationen per MS SQL Server Configuration Manager. Sind die beide identisch konfiguriert was die zu verwendenden Protokolle angeht?

 

Weitere Infos zu deinen Eventlogeinträgen:

Windows Event ID 17806 from MSSQLSERVER

 

OK, dann muss ich wohl weiter ausholen. Mein Fehler

 

Historisch gewachsen ist bei uns ein Novell-Netz (was auch tadellos funktioniert). Für den Zugriff auf eine Navision-Datenbank haben wir einen SQL-Server. Auch für Terminalserver setzen wir Win-Server ein. Somit hat also auch die AD bei uns eine Berechtigung.

 

Die beiden Verzeichnisdienste werden bei uns über DirXML synchronisiert. Somit gibt es jeden User auf beiden Seiten mit denslben Anmeldeinformationen. Softwareverteilung, Sicherheitsupdates, Gruppenrichtlinien werden über ZEN-Works (Novell) gesteuert und deshalb wollen wir die Rechner nicht noch zusätzlich in der Domäne haben.

 

Der neue Server ist Member-Server der AD-Domäne.

 

Die Konfiguration der SQL-Server ist identisch. Ich habe alles exakt gleich eingestellt. Über den Link hatte ich auch schon versucht fündig zu werden.... Ich habe auch schon ordentlich gegoogelt.... aber nix gefunden.

 

Vielen Dank für die schnelle Antwort.

Link zu diesem Kommentar

Ja,

 

alle Anmeldekennungen per Task übertragen. Einmal mit SID übertragen, einmal ohne. Dann (falls Übertragungs-Task fehlerhaft) nochmal die Kennungen frisch (manuell) erzeugt.

 

Ich versuch z. Zt. gar keine Anmeldung über Navision, sondern eine einfache Authentifiierung über ODBC per System-DSN.

 

Die SQL-Authentifizierung läuft ohne Probleme.

Link zu diesem Kommentar
alle Anmeldekennungen per Task übertragen. Einmal mit SID übertragen, einmal ohne.

Welche Anmeldekennungen hast du per Task übertragen? Die Navision-Anmeldekennungen oder?

 

Wie sieht es denn mit den Berechtigungen der AD-Konten bzw. dafür bereitgestellten AD-Gruppen auf den SQL Server und die jeweilige Datenbank aus? Sind die denn auf dem neuen Server auch korrekt berechtigt?

Link zu diesem Kommentar

Ich habe sowohl die SQL-Kennungen als auch die AD-Kennungen per Task übertragen. Die Berechtigungen für die Datenbanken sind mit übertragen worden, das habe ich überprüft und nochmals manuell getestet.

 

Ich habe auf dem neuen Server mal lokal ein Konto eingerichtet mit der Kennung wie in der AD. Wenn diese besteht kann ich mich per Win-Auth mit dieser Kennung anmelden! Scheinbar überprüft der Server erst lokale Anmeldenamen und dann erst die AD. Das würde erklären warum es auf dem DC funktioniert. Der hat ja keine lokalen Benutzer und behandelt die AD-User vielleicht deswegen wie lokale Nutzer?!?

Link zu diesem Kommentar
Ich habe auf dem neuen Server mal lokal ein Konto eingerichtet mit der Kennung wie in der AD. Wenn diese besteht kann ich mich per Win-Auth mit dieser Kennung anmelden! Scheinbar überprüft der Server erst lokale Anmeldenamen und dann erst die AD. Das würde erklären warum es auf dem DC funktioniert. Der hat ja keine lokalen Benutzer und behandelt die AD-User vielleicht deswegen wie lokale Nutzer?!?

 

Gut möglich. Aber das müsste sich recht leicht verifizieren lassen. Joine mal einen Testrechner in deine AD-Domain, melde dich mit dem User an der Domain an und verbinde dich dann an den SQL Server. Das sollte ja dann gehen oder?

Link zu diesem Kommentar

Ja, das geht. Der Rechner / User muss in der Domäne angemeldet sein.

 

Ich hätte es aber gerne funktionstüchtig ohne den Rechner in die Domäne aufzunehmen.

 

Aus meiner Sicht habe ich 3 Möglichkeiten:

1) Rechner in Domäne und User gegen beide Verzeichnisdienste authentifizieren

2) Authentifizierung ändern, so dass der SQL-Server nur den Anmeldenamen gegen die AD authentifiziert (ohne Präfix Domäne\), etwa über Gruppenrichtlinien Sicherheit o.ä.

3) zweiten Server auch zum Domänencontroller machen

 

1) will ich nicht, 2) falls überhaupt machbar zu aufwendig und 3) sinnvoll?

 

Ich habe bereits die AD auf einem 2. Server. Oder ist die Last so vernachlässigbar, dass SQL und DC auf der neuen Kiste laufen können?

Link zu diesem Kommentar

Ich hätte es aber gerne funktionstüchtig ohne den Rechner in die Domäne aufzunehmen.

 

Sagen wir so: wer das eine liebt, muss das andere mögen. Du kannst nicht erwarten, das du ne AD-integrierte Anmeldung machen kannst, ohne das du deine User gegen das AD authentifizierst. Oder wie siehst du das?

 

Einzige sinnvolle Alternativen die ich sehe:

1.) Umstellung auf SQL-Authentifizierung und Einrichtung der entsprechenden User

2.) Konsequente Nutzung der AD-Authentifizierung, wenn du gegen SQL arbeiten willst. Ansonsten können sich ja die Nutzer weiterhin an Novell anmelden.

1) Rechner in Domäne und User gegen beide Verzeichnisdienste authentifizieren

Siehe auch meine Variante 1

2) Authentifizierung ändern, so dass der SQL-Server nur den Anmeldenamen gegen die AD authentifiziert (ohne Präfix Domäne\), etwa über Gruppenrichtlinien Sicherheit o.ä.

unrealistisch, das das möglich ist. Dafür ist es ne Windows-integrierte Anmeldung und keine Verwendung von lokalen Benutzern

3) zweiten Server auch zum Domänencontroller machen

technisch möglich, aber ich rate dir dringend davon ab.... Selbst bei deinem ersten Server in der Kombination DC und SQL musste ich den Kopf schütteln...

 

 

Ich glaube im großen und ganzen solltest du dein Gesamtkonzept überdenken...

Link zu diesem Kommentar
Sagen wir so: wer das eine liebt, muss das andere mögen. Du kannst nicht erwarten, das du ne AD-integrierte Anmeldung machen kannst, ohne das du deine User gegen das AD authentifizierst. Oder wie siehst du das?

 

 

technisch möglich, aber ich rate dir dringend davon ab.... Selbst bei deinem ersten Server in der Kombination DC und SQL musste ich den Kopf schütteln...

 

 

Ich glaube im großen und ganzen solltest du dein Gesamtkonzept überdenken...

 

Im ersten Punkt gebe ich Dir Recht. Ich will nur den Aufwand möglichst gering halten.

 

Warum rätst Du von der Kombination ab? Wo ist das Problem?

 

Mein Gesamtkonzept ist schon schlüssig. Die Kombination eDirectory/AD ist nicht immer einfach. Ich brauche die AD ja nur zur Authentifizierung. Sonst liegen die Funtionalitäten brach (Gruppenrichtlinien etc).

 

Das Netz ist ein Novell-Netz (bitte nicht steinigen...) und das bleibt auch so.

 

Übrigens: Danke für Deine schnellen Antworten!

Link zu diesem Kommentar
Das Netz ist ein Novell-Netz (bitte nicht steinigen...) und das bleibt auch so.

Gleich vorab: Hier wird niemand für seine Infrastruktur gesteinigt. Von daher keine Angst... ;)

 

Ich brauche die AD ja nur zur Authentifizierung.

Richtig, aber dazu musst du sie auch nutzen, sprich die Computer und die User da reinbringen, damit die Authentifizierung überhaupt geht. Wie sich grade zeigt, geht die ja nur auf dem SQL+DC, dort aber auch nur "aus Glück" würde ich meinen...

 

Warum rätst Du von der Kombination ab?

Warum ich davon abrate? Weil ich ein Freund klarer Strukturen bin, und Serverrollen gerne so verteile, das ich keine "artfremden" Kombinationen bekomme. Sprich ein DB-Server ist und bliebt ein DB-Server, aber nix mehr... Und ein DC bekommt bei mir die "typischen" DC-Dienste, wie AD, DNS, DHCP und macht auch nur das...

 

Liegt aber auch eher daran, das ich bei meinen Kunden in recht großzügigen Umgebungen arbeiten kann und nicht bei einem KMU mit sehr begrenzten IT-Mitteln kämpfen muss. Es gibt sicher keine technischen Gründe, welche von dieser Kombination abraten lassen, sondern eher persönliche Einstellungen und Meinungen.

Link zu diesem Kommentar

Ich weiss noch nicht genau.

 

Ehrlich gesagt neige ich dazu ihn zum DC zu machen. Die Last ist sicherlich kein Problem. Ich sehe den DC eher als zusätzliche Sicherheit für die AD (wegen der Replikation). Andererseits gebe ich Dir Recht, dass dadurch die Struktur "unsauberer" wird (und wegen der vielen Dienst auf der Kiste auch in diesem Punkt evtl. unsicherer). Ich bin es eigentlich gewohnt, dass ein Server mehrere Dienste gleichzeitig ausführen kann.

 

Wenn ich einen IIS / SharePoint auf einem DC installiere, hätte ich sehr große Probleme mit der Kombination. Aber der SQL steht nicht im öffentlichen Netz.

 

Du hast schon Recht, dass wir uns hier nicht für jeden Dienst einen eigenen Server hinstellen können.

 

Als letztes Argument hätte ich noch den Aufwand alle Arbeitsstationen in die Domäne zu holen und dies auch mit entfernten Standorten ohne DC, die über Terminalserver arbeiten. Außerdem müsste ich die doppelte Authentifizierung über den Novell-Client noch einrichten (geschweige denn von der Schulung der Mitarbeiter wann Sie sich gegen die AD / eDir anmelden sollen. Die Novell-Authentifizierung reicht hier völlig. Es ist sicherlich auch ein Schuß bequemlichkeit dabei ;)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...