cilgo

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 ;)

OK. Vielen Dank!

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!

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?

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?!?

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.

Hallo, 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.

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

Hoppla, heute nochmal getestet und siehe da .... mit Firefox erreiche ich den URL ohne Suffix (http://sbs). Ist also ein Browserproblem. Hat jemand eine Ahnung ob es mit den Gruppenrichtlinien zusammenhängt? Gruß, Carsten

Ich habe den IIS nicht angepasst. Es wird auch nicht mit SharePoint gearbeitet. Insofern hat der IIS seine Standardkonfiguration "out of the box". Die Logs gucke ich mir dann an wenn ich wieder beim Kunden bin...

Habe ich schon. Mit dem (portable) Firefox hatte ich das Problem ebenfalls...

Hallo nobex, nein. Auch wenn ich den Proxy abschalte komme ich ohne vollen Domänennamen nicht daruf. Gruß, Carsten

Hallo liebe Kollegen, ich habe ein merkwürdiges Verhalten eines SBS Premium R2 Servers (W2K3 SP2, ISA 2004 SP3): Sagen wir ich habe eine domäne: domäne.local (nur ein Beispiel, sie heißt natürlich anders) Der Server lautet: sbs.domäne.local Der DNS löst alle Clients sauber auf. Ein nslookup auf sbs ergibt die richtige IP und ein nslookup auf sbs.domäne.local löst den Namen ebenfalls sauber auf. Verhalten vom Server und von Clients aus getestet. Gleiches gilt für companyweb. Wenn ich am Client im IE http://sbs'>http://sbs oder http://companyweb'>http://companyweb eingebe bekomme ich keine Verbindung zur Intranetseite (der Domänen-Suffix wird schinbar nicht ergänzt). Unter http://sbs.domäne.local bzw. http://companyweb.domäne.local wird allerdings eine Verbindung aufgebaut. Am Server funktionieren allerdings beide Versionen (mit und ohne Suffix). Die Clients laufen wegen des ISA natürlich über den PROXY. Wegen des Proxy's habe ich auch schon versucht diesen für die lokalen Adressen http://sbs und http://companyweb zu umgehen. Ohne Erfolg. Mein erster Verdacht: DNS-Suffix. Sowohl der verbindungsspezifische Suffix als auch die DNS-Suffixsuchliste enthalten aber über DHCP die Einträge domäne.local (Bereichsoptionen im DHCP [015 DNS Domain Name]). Auch eine Änderung des primären DNS-Suffix in den Netzwereinstellungen TCP/IP ergeben keine Besserung.... Nächster Verdacht: WINS / NetBIOS: In den Netzwereinstellungen des Clients also NetBIOS über TCP/IP aktivieren nochmal manuell eingestellt: keine Besserung Außerdem spricht gegen ein Fehler im NetBIOS, dass die Freigeben unter \\DOMÄNE\Freigabe funktionieren.... Der ISA zeigt im Protokoll keine Blockierungen .... nur die Blockierung von NetBIOS-Datagrammen von diversen Clients. Das sagt mir allerdings z.Zt. noch nichts. Außerdem scheinen diese immer an eine Broadcast-Adresse x.x.x.255 zu gehen. Irgendwie habe ich trotzdem den ISA im Verdacht. Ich bin ratlos und freue mich über jede Idee.. Viele Grüße und Dank an alle die hier mithelfen. Die Suche in diesem Forum hat schon so manches Mal geholfen... Gruß, Carsten

Hallo, ich bin neu hier und hoffe auf Eure Hilfe: 1. Ich habe auf einem SBS-Server parallel die SharePoint Services 3.0 installiert (nach Empfehlungen von MS). Im internen Netz ist die neue website auch erreichbar. Die site ist ssl-verschlüsselt. Über den Remote Webarbeitsplatz erreiche ich die Seite aber nicht. Was muss ich tun damit ich die neue website wie das companyweb unter dem Remote Webarbeitsplatz erreiche? 2. Frage: Wo kann ich die Willkommensseite des SBS ändern (die 1. Seite nach der Anmeldung)? Die Seiten sind ja getrennt nach Admin- und Userrechten... Vielen Dank im Voraus, Carsten