Authorization windows - Invalid authorization specification

Hi, Experts.
Another problem with Reporting Services authentication:
We have a windows 2003 server + iis 6.0 +Reporting Setvices
whose reports access to a sql server windows 2003 (both are situated
in the same domain).
Since I must use stored credentials in order to create subscriptions
I've decided to put a user from domain windows in stored
authentication.
As the result I´ve obtain the following error:
Error al procesar el informe. (rsProcessingAborted) Obtener ayuda en
línea
No se puede crear una conexión al origen de datos Ventas.
(rsErrorOpeningConnection) Obtener ayuda en línea
Invalid authorization specification
The user I've chosen is the same that I use to design reports and to
access the sql server usually, so I don´t understand the cause of this
error.
Good. Seeing that it has not work I´ve changed the user to "sa" and
everything works fine.
The unique problem I have that according to the policy secuirty of the
company
it is forbidden to use the sa user in order to execute the reports.
Windows authentication is strongly recommended. Any idea?
Regards
Maciej KiewraHi, Experts.
The ServicePack is the real reason of my problem.
I´ve removed RS and I've installed it again (without applying service pack)
everything ok.
Then I've installed the servicepack and now "windows authentication" does not work.
I know that in the service pack 1 a new System Property has been add that
permits the windows authentication to be disabled, but this parameter is set
to true, so it is not a case.
It seems that Reporting Service is already very premature
Regards
Maciej Kiewra
mkiewra@.mail.fujitsu.es (Maciej Kiewra) wrote in message news:<bc86bf57.0504050912.36611411@.posting.google.com>...
> Hi, Experts.
>
> Another problem with Reporting Services authentication:
> We have a windows 2003 server + iis 6.0 +Reporting Setvices
> whose reports access to a sql server windows 2003 (both are situated
> in the same domain).
> Since I must use stored credentials in order to create subscriptions
> I've decided to put a user from domain windows in stored
> authentication.
> As the result I´ve obtain the following error:
> Error al procesar el informe. (rsProcessingAborted) Obtener ayuda en
> línea
> No se puede crear una conexión al origen de datos Ventas.
> (rsErrorOpeningConnection) Obtener ayuda en línea
> Invalid authorization specification
> The user I've chosen is the same that I use to design reports and to
> access the sql server usually, so I don´t understand the cause of this
> error.
> Good. Seeing that it has not work I´ve changed the user to "sa" and
> everything works fine.
> The unique problem I have that according to the policy secuirty of the
> company
> it is forbidden to use the sa user in order to execute the reports.
> Windows authentication is strongly recommended. Any idea?
> Regards
> Maciej Kiewrasql

Attn Bruce Johnson [MSFT] Re: RS do not follow PDF specification?

Bruce,
I am not sure if you read my reponse to your question in the old thread. So I am re-posting here the answer I got from the ActivePDF's support team. BTW, are there any plans at Microsoft to fix this?
Thanks.
Regards,
Alexander Korygin.
-----
Information from ActivePDF QA department:
A bug in SQL Server Reporting Services causes PDF's to be created with the startxref tag pointing to one byte short of the start of the xref table.
This causes Toolkit to fail to open the file because it isn't a valid PDF.
I've already submitted this issue to Engineering to see if they can come up with a fix to work around this issue until Microsoft can provide a fix for SQL Server Reporting Services, which, as I understand it is due mid this year.
You can work around this issue by opening the PDF in Acrobat, and doing a Save As, and Acrobat will repair the PDF.
-----
"Bruce Johnson [MSFT]" wrote:
> I did some research on this issue and there is a known bug that covers this
> issue. We would be interested in knowing what portion of the PDF
> specification you think is not being followed correctly.
>
> --
> Bruce Johnson [MSFT]
> Microsoft SQL Server Reporting Services
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Alex Korygin" <AlexKorygin@.discussions.microsoft.com> wrote in message
> news:2330E4E1-588E-4C1C-ACF0-B03378D80E97@.microsoft.com...
> > Hi,
> >
> > our company produces complex PDF reports for customers. One major
> requirement is to be able to merge the reports, rendered by Reporting
> Services SP1 web service in PDF format into existing documents. The problem
> is that the ActivePDF server can not open and merge the PDFs, produced by
> RS. The ActivePDF's tech support team says there is a problem with the
> Microsoft Reporting Tool not following the PDF specification. Can someone
> from MSFT confirm / refute this?
> > Thanks.
> >
> > P.S. I am quoting the ActivePDF response here:
> > ----
> > Looking further into this, the issue is with Microsofts reporting tool.
> It's not creating the PDF properly under PDF specs. Toolkit is not designed
> to fix PDF's that do not follow PDF Specs.
> >
> > Microsoft is apparently going to fix this issue with a Service Pack in the
> future. Until then Toolkit will not be able to work with these files.
> > ----
> >
> > --
> > Regards,
> >
> > Alex Korygin.
>
>
>I did see your earlier post. To the best of my knowledge the information you
provided is covered by an existing bug.
The fix for it will appear in a future release.
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Alex Korygin" <AlexKorygin@.discussions.microsoft.com> wrote in message
news:BCC32EEA-50A3-4FFC-828A-4B0ABDBF3698@.microsoft.com...
> Bruce,
> I am not sure if you read my reponse to your question in the old thread.
So I am re-posting here the answer I got from the ActivePDF's support team.
BTW, are there any plans at Microsoft to fix this?
> Thanks.
> Regards,
> Alexander Korygin.
>
> ----
--
> Information from ActivePDF QA department:
> A bug in SQL Server Reporting Services causes PDF's to be created with the
startxref tag pointing to one byte short of the start of the xref table.
> This causes Toolkit to fail to open the file because it isn't a valid PDF.
> I've already submitted this issue to Engineering to see if they can come
up with a fix to work around this issue until Microsoft can provide a fix
for SQL Server Reporting Services, which, as I understand it is due mid this
year.
> You can work around this issue by opening the PDF in Acrobat, and doing a
Save As, and Acrobat will repair the PDF.
> ----
--
>
> "Bruce Johnson [MSFT]" wrote:
> > I did some research on this issue and there is a known bug that covers
this
> > issue. We would be interested in knowing what portion of the PDF
> > specification you think is not being followed correctly.
> >
> > --
> > Bruce Johnson [MSFT]
> > Microsoft SQL Server Reporting Services
> >
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> >
> >
> > "Alex Korygin" <AlexKorygin@.discussions.microsoft.com> wrote in message
> > news:2330E4E1-588E-4C1C-ACF0-B03378D80E97@.microsoft.com...
> > > Hi,
> > >
> > > our company produces complex PDF reports for customers. One major
> > requirement is to be able to merge the reports, rendered by Reporting
> > Services SP1 web service in PDF format into existing documents. The
problem
> > is that the ActivePDF server can not open and merge the PDFs, produced
by
> > RS. The ActivePDF's tech support team says there is a problem with the
> > Microsoft Reporting Tool not following the PDF specification. Can
someone
> > from MSFT confirm / refute this?
> > > Thanks.
> > >
> > > P.S. I am quoting the ActivePDF response here:
> > > ----
> > > Looking further into this, the issue is with Microsofts reporting
tool.
> > It's not creating the PDF properly under PDF specs. Toolkit is not
designed
> > to fix PDF's that do not follow PDF Specs.
> > >
> > > Microsoft is apparently going to fix this issue with a Service Pack in
the
> > future. Until then Toolkit will not be able to work with these files.
> > > ----
> > >
> > > --
> > > Regards,
> > >
> > > Alex Korygin.
> >
> >
> >
>
>