Anwendungsmigration - SQL-Authentifizierung in Domäne nicht möglich - Active Directory, Selektive Vertrauensstellung
Einen wunderschönen guten Tag, liebe Administratoren und Anwender,
seit langem hilft mir administrator.de durch bestehende Beiträge mit zumeist sehr kompetenten Antworten bei meinen geschäftlichen IT-Störungen weiter.
Derzeit migrieren wir im Umfeld der medizinischen IT-Systeme diverse Anwendungen in eine neue Domänen-Struktur und die Clients von Windows XP auf Windows 7.
Bei insgesamt drei Anwendungen ist allerdings keine SQL-Authentifizierung möglich.
Einige der Anwendungen beherrschen leider nur die Methode der SQL-Authentifizierung (AD-Auth nicht möglich).
Hier die Ausgangssituation:
Domäne A enthält alle Benutzer.
Domäne B entält Fileshares, in denen die Applikationsdaten liegen.
Es gibt eine selektive Vertrauensstellung zwischen Domäne A und Domäne B.
Windows XP Clients befinden sich in Domäne A.
Windows 7 Clients befinden sich in Domäne B.
Anwender melden sich an dem Client immer mit ihrem Benutzer aus Domäne A an.
Zwei der drei Anwendungen können kein ODBC benutzen.
Hier die Problembeschreibung:
Wenn ein Anwender (oder ich als Administrator) sich nun mit seinem Benutzerkonto aus Domäne A an den Windows 7 Client anmeldet und die Anwendung startet, greift dieser beim Anwendungsstart auf die Dateifreigabe zu und startet mit seinem Benutzer die Anwendung. Die Anwendung nutzt den SQL-Treiber des Betriebssystems und greift direkt auf die Datenbank zu. Der Verbindungsaufbau funktioniert nicht und läuft auf einen Timeout.
Melde ich mich nun mit einem Account aus Domäne B an den Windows 7 Client an, funktioniert die SQL-Authentifizierung.
Ich persönlich tippe auf die selektive Vertrauensstellung oder Benutzer-Policies. Was ist eure Erfahrung? Hat jemand eine Idee? Wir sind hier langsam ziemlich ratlos.
Vielen Dank und viele Grüße
ikkerus (Sebastian)
seit langem hilft mir administrator.de durch bestehende Beiträge mit zumeist sehr kompetenten Antworten bei meinen geschäftlichen IT-Störungen weiter.
Derzeit migrieren wir im Umfeld der medizinischen IT-Systeme diverse Anwendungen in eine neue Domänen-Struktur und die Clients von Windows XP auf Windows 7.
Bei insgesamt drei Anwendungen ist allerdings keine SQL-Authentifizierung möglich.
Einige der Anwendungen beherrschen leider nur die Methode der SQL-Authentifizierung (AD-Auth nicht möglich).
Hier die Ausgangssituation:
Domäne A enthält alle Benutzer.
Domäne B entält Fileshares, in denen die Applikationsdaten liegen.
Es gibt eine selektive Vertrauensstellung zwischen Domäne A und Domäne B.
Windows XP Clients befinden sich in Domäne A.
Windows 7 Clients befinden sich in Domäne B.
Anwender melden sich an dem Client immer mit ihrem Benutzer aus Domäne A an.
Zwei der drei Anwendungen können kein ODBC benutzen.
Hier die Problembeschreibung:
Wenn ein Anwender (oder ich als Administrator) sich nun mit seinem Benutzerkonto aus Domäne A an den Windows 7 Client anmeldet und die Anwendung startet, greift dieser beim Anwendungsstart auf die Dateifreigabe zu und startet mit seinem Benutzer die Anwendung. Die Anwendung nutzt den SQL-Treiber des Betriebssystems und greift direkt auf die Datenbank zu. Der Verbindungsaufbau funktioniert nicht und läuft auf einen Timeout.
Melde ich mich nun mit einem Account aus Domäne B an den Windows 7 Client an, funktioniert die SQL-Authentifizierung.
Ich persönlich tippe auf die selektive Vertrauensstellung oder Benutzer-Policies. Was ist eure Erfahrung? Hat jemand eine Idee? Wir sind hier langsam ziemlich ratlos.
Vielen Dank und viele Grüße
ikkerus (Sebastian)
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 265078
Url: https://administrator.de/forum/anwendungsmigration-sql-authentifizierung-in-domaene-nicht-moeglich-active-directory-selektive-265078.html
Ausgedruckt am: 01.05.2025 um 17:05 Uhr
2 Kommentare
Neuester Kommentar
Es sei noch hinzuzufügen.
In Melde ich mich an Domäne A an, geht der Client mit Port 445 (Named Pipe) los, um sich zu Authentifizieren.
Melde ich mich an Domäne B an, geht der Client wie gewohnt mit Port 1433 (SQL) los, um sich zu authentifizieren.
Was muss ich tun, damit der User/Computer mit Port 1433 loszieht?
In Melde ich mich an Domäne A an, geht der Client mit Port 445 (Named Pipe) los, um sich zu Authentifizieren.
Melde ich mich an Domäne B an, geht der Client wie gewohnt mit Port 1433 (SQL) los, um sich zu authentifizieren.
Was muss ich tun, damit der User/Computer mit Port 1433 loszieht?
Neue Erkenntnis: Offensichtlich haben die Standard-Benutzer nicht genügend Rechte auf dem Fileshare, aus dem die Anwendungen gestartet werden.
Füge ich den Benutzer einer AD.Gruppe hinzu, die auf dem Fileshare lokaler Admin ist, nutzt der Benutzer am Client Port 1433.
Warum? :/ Anyone?
Füge ich den Benutzer einer AD.Gruppe hinzu, die auf dem Fileshare lokaler Admin ist, nutzt der Benutzer am Client Port 1433.
Warum? :/ Anyone?
