Haben hier einen sehr merkwürdigen Fehler auf einem WTS:
Seit dem 14.0er Update startet bei EINEM User der DATEV Arbeitsplatz nicht (Splashscreen kommt kurz, danach passiert nichts mehr, kein Fehler)
WINDVSW1 ist da, Zugriff ist vorhanden. SQL Manager findet auch die Datenbank, aber er meldet, dass der angemeldete User kein Zugriff darauf hat.
Ein Vergleich der SIDs zeigte tatsächlich, dass Windows sich mit einer SID an der Datenbank anmeldet, welche nicht in DATEV angelegt ist und daher seit 14.0 keinen Zugriff mehr hat. (https://apps.datev.de/dnlexka/document/1018556) d.h. das Problem bestand vermutlich schon früher, ist aber nicht aufgefallen.
Angemeldet und in DATEV verknüpft ist der User SIVER5-PC, der Zugriff auf die DB soll aber unerklärlicherweise mit 1613 aka SIVER5 stattfinden, was nicht funktioniert.
Haben den User bereits in DATEV gelöscht und neu angelegt.
Hat jemand eine Idee?
Und mit welchem Benutzernamen hat sich der Anwender am TS angemeldet? Beide sind im AD angelegt und gültig, in DATEV ist vermutlich das falsche AD User Object mit dem DATEV Nutzer verknüpft. Oder ist "Siver5-PC" gar ein Computerobject?
Angemeldet ist er als SIVER5-PC und genau der AD User ist auch mit dem Datev-User verknüpft, das sollte demnach passen.
Nein, kein Computerobjekt, beides sind gewöhnliche AD-User, welche aber nichts miteinander zu tun haben.
Hallo,
in einem anderen Zusammenhang gibt es ähnliche Probleme wenn im "Windows Tresor" bzw. "Windows Anmeldeinformationen" etwas hinterlegt ist. Prüfen Sie am betroffenen User in der Anmeldeinformationsverwaltung ob für den SQL Server ein andere Anmeldung hinterlegt ist.
Wenn man im Windows Explorer ein Netzlaufwerk verbindet mit einem anderen User dann merkt sich Windows das in diesen Anmeldeinformationen, und verwendet diese auch weiterhin um sich an dem Ziel-Rechner anzumelden. Evtl. ist das hier auch das Problem?
Ein ähnliches Problem gibt es bei der Anmeldung am Kommunikationsserver im Umfeld der Webservicekommunikation, siehe Ursache 2 vonwww.datev.de/info-db/9228416. Aber ob sich das auch bei SQL Anmeldungen auswirkt weiß ich leider nicht, aber einen Versuch ist es wert.
Gruß
Stefan Schneider
Wir konnten uns am Montag bereits mit einem Workaround behelfen, mit dem der Kunde auch zufrieden war (hatte im Eifer des Gefechts leider vergessen, das hier zu posten):
Dummy Datev-User angelegt und mit dem anderen AD-User verknüpft, damit die SQL Datenbank den AD-User kennt, mich dem sich der eigentliche User fälschlicherweise anmelden möchte. Danach hat es sofort funktioniert und der Kunde hat sich aus wirtschaftlichen Gründen gegen weiteres Troubleshooting entschieden. Nicht schön aber selten 😄
Habe ihm die Info mit den Anmeldeinformationen aber weitergegeben und er wird bei Gelegenheit testen, ob dort eventuell ein falscher Eintrag sitzt.