none
Reporting Service - Zugriffstrategie RRS feed

  • Frage

  • Hallo zusammen,

    ich brauch mal bitte Euren Rat und Kenntnisse.

    Wir haben bei einem Dienstleister einen SQL Server und einen Report Server. Diese sind getrennt. Die Domäne von uns wird zum Dienstleister  - ich sag jetzt mal - gespiegelt.

    Wie kann ich jetzt Zugriff auf einen Bericht mittels Windows Authentifizierung lösen, das er von Standort A zum Standort B Reportserver geht und auf die Daten des SQL Servers Standort C zugreift. Kerberos ist NICHT aktiviert. Ich meine nämlich das das dann so gar nicht geht und nur zu einem Computer weitergeleitet werden kann?

    Die zweite Frage wäre dann, wenn wir einen extra BerichtUser haben, dann würde dieser für jeden User die gleichen Berichtsdaten ausgeben? Und muß dieser dann im SQL Server als User im Bereich Sicherheit auf der SQL Datenbank hinterlegt werden?

    Ich habe zwar das MS Press SQL Reporting Buch, aber ganz schlau wird ich da nicht draus...

    Vielen Dank schon mal

    Gruß Daniel

    Dienstag, 3. Juni 2014 07:35

Antworten

  • Vielen Dank für die Antworten.

    Ja das ist ein replizierter Domaincontroller. Zumindest hab ich die Info so von der Fachabteilung bekommen :-)

    Da bei uns Keberos nicht im Einsatz ist, denk ich werden wir die Lösung nehmen, das jeder Mitarbeiter im Bericht noch einmal seine Username und sein Passwort eingibt.

    Einen Bericht über einen BerichtUser ist bei uns aus Datenschutzgründen leider nicht zulässig.

    Vielen Dank für die Antworten und einen guten Start in den Tag

    Gruß Daniel

    Mittwoch, 4. Juni 2014 06:04

Alle Antworten

  • Also, hier stecken ja offensichtlich zwei Fragen drinnen

    Ich bin mir nicht im klaren, was "ich sag jetzt mal - gespiegelt" genau ist. Replizierter RODC/Domaincontroller?

    Auf jeden Fall liegt hier wohl ein Double-Hop-Szenario vor.
    Also idealerweise Kerberos implementieren oder notfalls mit SQL Authentifizierung zur Datenquelle arbeiten

    Die zweite Frage wiederum scheint auch aus 2 Fragen zu bestehen:

    Ja, ein Nutzer muss auch als solcher im SQL Server und der Datenbank hinterlegt werden. Da es nur "einer für alle" ist, sehen auch alle die selben Berichtsdaten. Es sei denn:

    Wenn man Nutzerabhängige Daten anzeigen möchte, muss man den eingeloggten User mittels des integrierten Berichtsparameter User!UserID an die Datenbankabfrage durchreichen und dort zB in einer WHERE-Klausel verwenden. Dafür hat man dann i.d.R. eine Tabelle in der Datenbank, die diese Windows-ID einem Nutzernamen zuordnen kann.


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Dienstag, 3. Juni 2014 10:54
  • Die dritte Möglichkeit für die Datenquelle wäre ein Windows-Login fix für alle zu hinterlegen. Dann könnte man auch ohne SQL-Logins auskommen. Schöner ist aber Kerberos zu verwenden.

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Dienstag, 3. Juni 2014 13:40
    Beantworter
  • Vielen Dank für die Antworten.

    Ja das ist ein replizierter Domaincontroller. Zumindest hab ich die Info so von der Fachabteilung bekommen :-)

    Da bei uns Keberos nicht im Einsatz ist, denk ich werden wir die Lösung nehmen, das jeder Mitarbeiter im Bericht noch einmal seine Username und sein Passwort eingibt.

    Einen Bericht über einen BerichtUser ist bei uns aus Datenschutzgründen leider nicht zulässig.

    Vielen Dank für die Antworten und einen guten Start in den Tag

    Gruß Daniel

    Mittwoch, 4. Juni 2014 06:04