Login failed for user <null>

Hello,
I have RS (client and server components) installed on a test machine
(Win2k), with the SQL-Server database on a remote machine. I'm able to create
reports, preview them with data, and deploy them with no issues. However,
when I try to execute any of them from the Report Manager, I get: "Login
failed for user '(null)'. Reason: Not associated with a trusted SQL Server
connection".
The connection object is set up in the Report Manager as a shared data
source, with the credentials stored in the report server, the credentials I'm
using have access to the database, and I have the "Use as windows credentials
when connecting to the datasource" check box checked (the database uses
Windows authentication).
Between all of the logins/security settings in use by IIS, the Windows
Services, the database, aspnet, etc. I'm at a loss as to where the issue
might lie. Any thoughts?
Thanks in advance!
BrianI had similar problems as recently as last week.
Are the SQL Server box and the RS box in the same domain ?
My setup is similar to yours but on Win2003 on both sides. and problem
was due to i dint have them in the same domain.
So i created an SQL Account with admin credentials and then
Checked the "use windows and SQL Auth" in the SQL server and configured
RS to use SQL credentials.
this is NOT the most secure solution, but i am able to move forward.
Hope this helps
Bofo|||Yes, both computers are on the same domain. The strange thing is, when I
change the data source properties (from within Report Manager) to 'Windows NT
Integrated Authority' everything runs fine...unfortunately it doesn't seem
that you can create subscriptions to reports unless you're saving the
credentials.
Doesn't seem like it should be this difficult :)
"Win2003InstallIssues" wrote:
> I had similar problems as recently as last week.
> Are the SQL Server box and the RS box in the same domain ?
> My setup is similar to yours but on Win2003 on both sides. and problem
> was due to i dint have them in the same domain.
> So i created an SQL Account with admin credentials and then
> Checked the "use windows and SQL Auth" in the SQL server and configured
> RS to use SQL credentials.
> this is NOT the most secure solution, but i am able to move forward.
> Hope this helps
> Bofo
>|||I think you found it out by trial and error, though just FYI, stored
credentials are required if you want to support subscriptions.
--
Adrian M.
MCP
"bmcelhany" <bmcelhany@.discussions.microsoft.com> wrote in message
news:E2B8822B-8437-4E7C-878A-0D0A8A011EFD@.microsoft.com...
> Yes, both computers are on the same domain. The strange thing is, when I
> change the data source properties (from within Report Manager) to 'Windows
> NT
> Integrated Authority' everything runs fine...unfortunately it doesn't seem
> that you can create subscriptions to reports unless you're saving the
> credentials.
> Doesn't seem like it should be this difficult :)
> "Win2003InstallIssues" wrote:
>> I had similar problems as recently as last week.
>> Are the SQL Server box and the RS box in the same domain ?
>> My setup is similar to yours but on Win2003 on both sides. and problem
>> was due to i dint have them in the same domain.
>> So i created an SQL Account with admin credentials and then
>> Checked the "use windows and SQL Auth" in the SQL server and configured
>> RS to use SQL credentials.
>> this is NOT the most secure solution, but i am able to move forward.
>> Hope this helps
>> Bofo
>>|||If you are connecting to Report Manager using Win Auth, and the data source
connects to the remote DB using Win Auth, you may need to enable Kerberos.
Depending on how your domain is configured, Windows credentials can be
passed across one computer connection before they expire. A user connection
to a report server counts as the first connection. If the user opens a
report that retrieves data from a remote server, that login counts as a
second connection and will fail if you are using Windows Authentication and
Kerberos is not enabled.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rswork/htm/rms_datasources_v1_87e9.asp
--
Adrian M.
MCP
"bmcelhany" <bmcelhany@.discussions.microsoft.com> wrote in message
news:717CD26C-F4E2-426B-80E7-4E2CB99CA11E@.microsoft.com...
> Hello,
> I have RS (client and server components) installed on a test machine
> (Win2k), with the SQL-Server database on a remote machine. I'm able to
> create
> reports, preview them with data, and deploy them with no issues. However,
> when I try to execute any of them from the Report Manager, I get: "Login
> failed for user '(null)'. Reason: Not associated with a trusted SQL Server
> connection".
> The connection object is set up in the Report Manager as a shared data
> source, with the credentials stored in the report server, the credentials
> I'm
> using have access to the database, and I have the "Use as windows
> credentials
> when connecting to the datasource" check box checked (the database uses
> Windows authentication).
> Between all of the logins/security settings in use by IIS, the Windows
> Services, the database, aspnet, etc. I'm at a loss as to where the issue
> might lie. Any thoughts?
> Thanks in advance!
> Brian|||Right, I definitely need to support schedules/subscriptions, so stored
credentials are my only option...unfortunately I can only get the reports to
work using Windows NT Integrated Security. Here are the various data source
settings I've tried:
Assumptions: all RS components are installed on one machine (no SQL Server)
with the database on another machine within the same domain. The SQL Server
uses Windows authentication. Both the 'Reports' and the 'ReportServer'
virtual directories are using anonymous authentication.
1) Windows NT Integrated Security: the reports run perfectly, however I am
unable to schedule any of them.
2) Credentials stored in the report server: I get a "login failed for user
'bmcelhany'. Reason: not associated with a trusted SQL Server connection"
error.
3) Credentials stored in the report server with the "Use as Windows
credentials when connecting to the data source" check box checked: I get a
"login failed for user 'null'. Reason: not associated with a trusted SQL
Server conenction" error.
Any thoughts?
"Adrian M." wrote:
> I think you found it out by trial and error, though just FYI, stored
> credentials are required if you want to support subscriptions.
> --
> Adrian M.
> MCP
> "bmcelhany" <bmcelhany@.discussions.microsoft.com> wrote in message
> news:E2B8822B-8437-4E7C-878A-0D0A8A011EFD@.microsoft.com...
> > Yes, both computers are on the same domain. The strange thing is, when I
> > change the data source properties (from within Report Manager) to 'Windows
> > NT
> > Integrated Authority' everything runs fine...unfortunately it doesn't seem
> > that you can create subscriptions to reports unless you're saving the
> > credentials.
> >
> > Doesn't seem like it should be this difficult :)
> >
> > "Win2003InstallIssues" wrote:
> >
> >> I had similar problems as recently as last week.
> >>
> >> Are the SQL Server box and the RS box in the same domain ?
> >>
> >> My setup is similar to yours but on Win2003 on both sides. and problem
> >> was due to i dint have them in the same domain.
> >>
> >> So i created an SQL Account with admin credentials and then
> >> Checked the "use windows and SQL Auth" in the SQL server and configured
> >> RS to use SQL credentials.
> >>
> >> this is NOT the most secure solution, but i am able to move forward.
> >> Hope this helps
> >> Bofo
> >>
> >>
>
>|||Have you tried the userid-pw login from the Visual Studio IDE? Also - the
obvious question - is mixed mode security enabled on SQL Server?
"bmcelhany" <bmcelhany@.discussions.microsoft.com> wrote in message
news:8D8CB6D4-8FE2-4E03-99AD-BFAFAB4B9B98@.microsoft.com...
> Right, I definitely need to support schedules/subscriptions, so stored
> credentials are my only option...unfortunately I can only get the reports
to
> work using Windows NT Integrated Security. Here are the various data
source
> settings I've tried:
> Assumptions: all RS components are installed on one machine (no SQL
Server)
> with the database on another machine within the same domain. The SQL
Server
> uses Windows authentication. Both the 'Reports' and the 'ReportServer'
> virtual directories are using anonymous authentication.
> 1) Windows NT Integrated Security: the reports run perfectly, however I am
> unable to schedule any of them.
> 2) Credentials stored in the report server: I get a "login failed for user
> 'bmcelhany'. Reason: not associated with a trusted SQL Server connection"
> error.
> 3) Credentials stored in the report server with the "Use as Windows
> credentials when connecting to the data source" check box checked: I get a
> "login failed for user 'null'. Reason: not associated with a trusted SQL
> Server conenction" error.
> Any thoughts?
> "Adrian M." wrote:
> > I think you found it out by trial and error, though just FYI, stored
> > credentials are required if you want to support subscriptions.
> >
> > --
> > Adrian M.
> > MCP
> >
> > "bmcelhany" <bmcelhany@.discussions.microsoft.com> wrote in message
> > news:E2B8822B-8437-4E7C-878A-0D0A8A011EFD@.microsoft.com...
> > > Yes, both computers are on the same domain. The strange thing is, when
I
> > > change the data source properties (from within Report Manager) to
'Windows
> > > NT
> > > Integrated Authority' everything runs fine...unfortunately it doesn't
seem
> > > that you can create subscriptions to reports unless you're saving the
> > > credentials.
> > >
> > > Doesn't seem like it should be this difficult :)
> > >
> > > "Win2003InstallIssues" wrote:
> > >
> > >> I had similar problems as recently as last week.
> > >>
> > >> Are the SQL Server box and the RS box in the same domain ?
> > >>
> > >> My setup is similar to yours but on Win2003 on both sides. and
problem
> > >> was due to i dint have them in the same domain.
> > >>
> > >> So i created an SQL Account with admin credentials and then
> > >> Checked the "use windows and SQL Auth" in the SQL server and
configured
> > >> RS to use SQL credentials.
> > >>
> > >> this is NOT the most secure solution, but i am able to move forward.
> > >> Hope this helps
> > >> Bofo
> > >>
> > >>
> >
> >
> >