December 12, 2014 at 11:25 am
hi there - i have a hyperlink in one of the columns (in tablix) in an ssrs report which points to some server where a dump of documents reside..the hyperlink is appended with a doc_id which helps locate that doc and to invoke it from that server..now this works fine if the ssrs report runs with the current windows logged in user and when the same logged in user is also set up beforehand on that document server where the ssrs hyperlink points to..and this was in dev env..
going ahead in a controlled env, there would only be one system a/c which will be set up on that doc server and regardless of who the logged in windows user is who runs the report; access to the docs on that doc server will only be given to that sys a/c..so i passed this same sys a/c (which is set up on that doc server) in the data source in report mgr --> credentials stored securely in report server..and thought that these credentials will be
picked while navigating to that doc server and the doc would be opened..but this doesn't seem to happen and it doesn't invoke the document...says invalid credentials..so i think it's picking my logged in credentials here and not the ones of the sys a/c that i entered in data source...(pls note here, the doc server url doesn't contain the report server / report manager url components..it's a different url and is used to only open the doc..so i don't think i can pass user credentials to that url like &dsu:Datasourcename=username&dsp:Datasourcename=password..may be i am wrong and i can pass? but don't think that's secure even if it's an option?)
alternatively, i thought this could be achieved by changing the execution account to this system a/c, under reporting services config mgr..but then we only have ssrs client tools installed..so can't change server settings..and just for this one requirement, nobody would accept my request to change the execution account...also don't know if changing exec account is even a solution for this?
i hope the question is clear..please give some work arounds..i'm stumped and not getting required help anywhere..
note: as another work around, i asked if a group can be set up on that doc server..and when all the users accessing the report are added to the group, they can open the doc after navigating from ssrs report...but the idea giving access to a group was rejected...they can only give access to this sys a/c...
December 12, 2014 at 1:11 pm
If I am understanding correctly, you are simply putting the link in the report and then the user running the report clicks the link and expects to get to the document it links to...
Whenever you click the link, your browser is going to treat it like any other URL on a web page - it's going to try to go to the target, and if that target is a network location with security, it's going to try to access it as whoever is logged into the OS.
I believe you could try making the link something like this: \\server\share /user:username password
However, I strongly urge you not to do that as it will basically reveal your system account's password to anyone who bothers looking at the URL; which sort of defeats the purpose of having one.
Honestly, the best answer is to tell your system admins that they need to create a security group that has access to the target folder, and have that group contain the names of the folks who'll be running the report. Or, put the files someplace public. I don't know of any way to access a secure folder with a specified account, via a link, that isn't going to involve passing the password as plaintext - and nobody wants that.
December 13, 2014 at 5:22 am
thanks v much for taking time out in replying..(sorry for my un-formatted post previously..i've now formatted it and slightly modified a couple of lines in the first para)
and yes, you've completely understood my question correctly...the link essentially opens up the document from the generated url (with the doc_id)..also, you said it right..the browser would pick up the logged in user if it's a network location / url (and in my case, it is a n/w location..) and therefore, as a work around, i entered this sys a/c under data source in the report mgr, but it doesn't work..could be because that's merely the credentials to connect to db and not related with browser sessions etc..
you said i can try appending user details in that url..any help (link etc) please in how to do that..i can't use this in the url - "&dsu:Datasourcename=username&dsp:Datasourcename=password"..because it's not a ssrs report that the navigation happens to..it's a different url but with http protocol..and also it's not a network / shared drive location..i know this approach of embedding pwd in clear text is foolish..but at least i'll have something to prove to the system admins / managers [ 🙂 ] before requesting them for a security group...
December 13, 2014 at 5:26 am
in addition to cphite's reply, i request other forum members also to help out if anyone has a work around please..
December 15, 2014 at 9:03 am
sqlprof123 (12/13/2014)
thanks v much for taking time out in replying..(sorry for my un-formatted post previously..i've now formatted it and slightly modified a couple of lines in the first para)and yes, you've completely understood my question correctly...the link essentially opens up the document from the generated url (with the doc_id)..also, you said it right..the browser would pick up the logged in user if it's a network location / url (and in my case, it is a n/w location..) and therefore, as a work around, i entered this sys a/c under data source in the report mgr, but it doesn't work..could be because that's merely the credentials to connect to db and not related with browser sessions etc..
you said i can try appending user details in that url..any help (link etc) please in how to do that..i can't use this in the url - "&dsu:Datasourcename=username&dsp:Datasourcename=password"..because it's not a ssrs report that the navigation happens to..it's a different url but with http protocol..and also it's not a network / shared drive location..i know this approach of embedding pwd in clear text is foolish..but at least i'll have something to prove to the system admins / managers [ 🙂 ] before requesting them for a security group...
If I recall correctly, IE stopped supporting this some time ago, though it might still work in other browsers. Of course, you might run into other problems trying to run your reports without IE. I'm not sure about the syntax; but if you Google around it's got to be out there somewhere.
And all of that aside, it's still a terrible idea to place the password to what I assume is an account with system wide access into a plain-text URL.
Talk to your management and tell them that if this report is going to work as intended, they need to grant access to those files to the people who run the report. Whether they do that via a security group, or individually, or by making the location public is up to them... But it makes absolutely no sense to me that management, or your admin team, would rather you pass credentials via the URL and create an obvious security hole for the sake of a report.
December 15, 2014 at 12:21 pm
thank you again cphite for coming back...
i can't agree more with your advice of not going by the credentials in the url option..it is definitely a stupid solution..(despite finding in how to do it..) and is a question on the security...
all your statements on giving a group / individual the required access make complete sense..hopefully the emphasis on these things changes their perception..it seems they can't provide a group, the needed access (that application doesn't support it perhaps..it only understands individual accounts)..and have to provide access to all the users individually..but then there's no way out..they have to do it..
hopefully it gets sorted... 🙂
kind regards...
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply