"John Geddes" <john_g@alamode.com> wrote in message
news:eX2q$NR7EHA.4040@TK2MSFTNGP14.phx.gbl...
>I am trying to understand the basic security that RS uses.
>
> During install, a userid is used to install/create the databases. That
> userid is then tied to the basic services, like scheduling etc...
> Is this correct?
>
> Are all services using that first-supplied ID?
>
> After that when users run a report with a connection that has the
> credentials stored, are those the credentials used for the database
> access?
>
>
>
> I am currently using RS and have 2 shared connections (one to live dB and
> one to Test dB), both with stored credentials. Is is safe to assume that
> any report activity using that connection will show that userid?
>
> I just want to make sure I can track down problems when they arise.
>
> Thanks.
>

"Brian Welcker [MS]" <bwelcker@online.microsoft.com> wrote in message
news:bwelcker@online.microsoft.com:
> The credentials you supply when you install RS are completely seperate
> from
> the connections you use in your reports. They are only used so that the
> report server can talk to the reportserver (metadata) database. A report
>
> that is using stored credentials will use those credentials independent of
>
> the setup credentials.
>
> --
> Brian Welcker
> Group Program Manager
> Microsoft SQL Server
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "John Geddes" <john_g@alamode.com> wrote in message
> news:eX2q$NR7EHA.4040@TK2MSFTNGP14.phx.gbl...
> >I am trying to understand the basic security that RS uses.
> >
> > During install, a userid is used to install/create the databases. That
> >
> > userid is then tied to the basic services, like scheduling etc...
> > Is this correct?
> >
> > Are all services using that first-supplied ID?
> >
> > After that when users run a report with a connection that has the
> > credentials stored, are those the credentials used for the database
> > access?
> >
> >
> >
> > I am currently using RS and have 2 shared connections (one to live dB
> > and
> > one to Test dB), both with stored credentials. Is is safe to assume
> > that
> > any report activity using that connection will show that userid?
> >
> > I just want to make sure I can track down problems when they arise.
> >
> > Thanks.
> >

"John Geddes" <john_g@alamode.com> wrote in message
news:uxbucqR7EHA.2012@TK2MSFTNGP15.phx.gbl...
> Thanks... That makes sense. If I use one connection for all reports, the
> RS will show that one userid hitting the server.
>
> Can I find out the culprit, without DTSing the logs and querying them?
>
>
> "Brian Welcker [MS]" <bwelcker@online.microsoft.com> wrote in message
> news:bwelcker@online.microsoft.com:
>> The credentials you supply when you install RS are completely seperate
>> from
>> the connections you use in your reports. They are only used so that the
>> report server can talk to the reportserver (metadata) database. A report
>>
>> that is using stored credentials will use those credentials independent
>> of
>>
>> the setup credentials.
>>
>> --
>> Brian Welcker
>> Group Program Manager
>> Microsoft SQL Server
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "John Geddes" <john_g@alamode.com> wrote in message
>> news:eX2q$NR7EHA.4040@TK2MSFTNGP14.phx.gbl...
>> >I am trying to understand the basic security that RS uses.
>> >
>> > During install, a userid is used to install/create the databases. That
>> >
>> > userid is then tied to the basic services, like scheduling etc...
>> > Is this correct?
>> >
>> > Are all services using that first-supplied ID?
>> >
>> > After that when users run a report with a connection that has the
>> > credentials stored, are those the credentials used for the database
>> > access?
>> >
>> >
>> >
>> > I am currently using RS and have 2 shared connections (one to live dB
>> > and
>> > one to Test dB), both with stored credentials. Is is safe to assume
>> > that
>> > any report activity using that connection will show that userid?
>> >
>> > I just want to make sure I can track down problems when they arise.
>> >
>> > Thanks.
>> >
>
>