double-hop authentication for SSRS and ASP

I'm not an expert - but:
Yes - this is the classic double-hop scenario. I live with it everyday.
A lot depends on the Windows versions of the servers:
Windows 2000 - this requires Kerberos or the use of network service
accounts used between servers (or if the back-end service is SQL - SQL
logins).
Windows 2003 - you can use the Protocol Transition features to delegate
credentials without Kerberos.
See:
http://technet2.microsoft.com/WindowsServer/en/library/dac7ecea-7c82-43c0-847b-3a1a81454cfe1033.mspx
Difficult to help without more details, but if your using Windows 2000
servers and NTLM only, you will need to create a service account for
the Front End server to communicate with the Back End.
In a typical Web Server (A) talks to Application Server (B) that talks
to SQL Server (C) scenario...
1) Web Site (A) uses NTLM authentication and ASP(.NET) code to
impersonate <user>.
2) App Server B serves use NTLM authentication to grant access to
<user>, but is not allowed to pass these credentials to C. So either:
a) the DCOM or .NET services on B are configured to run under a
service account <_service1> which has access rights on the SQL Server
(C) and necessary Databases objects
or
b) the services on B use SQL authentication to login and access (C).
Note: If you use this approach, and you need to audit for security; you
should log accesses to C on server B - so that you know who really was
accessing C (All C sees is the same user, all the time).
If your using Windows Server 2003, you can use delagation as explained
in the links I provided earlier.
punjab_tom@.hotmail.com wrote:
> Sleepy
> can you please tell more? my english is poor
> I have had security problems with Services of Reporting; I can see
> 'user is null' even though we are using NT Authentication.
> Tom
>
|||Hi,
I have a very similar problem. I've been through a lot of articles, but
something is still missing.
This is my setup:
All servers are Windows Server 2003.
IE6 connects to IIS using basic authentication. In ASP.NET code, using Win32
LogonUser, I impersonate a domain user and then make a call to the database
server. For some reason the impersonated user is not delegated to SQL server.
This is how I configured everything so far:
Created a domain account for the aspnet worker process (edited
machine.config on IIS server and edited <processmodel>:
<processModel enable="true" userName="domain\ASPNETuser" password="xxx"/>
The ASPNETuser is set to be Trusted for Delegation on the domain controller.
The IIS server is set to be Trusted for Delegation on the domain controller.
The users that are to be impersonated are NOT set as sensitive on the domain
controller.
The connection string to SQL looks like:"server=sqlserver;initial
catalog=dbname;integrated security=SSPI".
When connecting to the database, I get "Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'".
What am I missing? How do I know the Kerberos is working.
"SleepyLab" wrote:

> Difficult to help without more details, but if your using Windows 2000
> servers and NTLM only, you will need to create a service account for
> the Front End server to communicate with the Back End.
> In a typical Web Server (A) talks to Application Server (B) that talks
> to SQL Server (C) scenario...
> 1) Web Site (A) uses NTLM authentication and ASP(.NET) code to
> impersonate <user>.
> 2) App Server B serves use NTLM authentication to grant access to
> <user>, but is not allowed to pass these credentials to C. So either:
> a) the DCOM or .NET services on B are configured to run under a
> service account <_service1> which has access rights on the SQL Server
> (C) and necessary Databases objects
> or
> b) the services on B use SQL authentication to login and access (C).
> Note: If you use this approach, and you need to audit for security; you
> should log accesses to C on server B - so that you know who really was
> accessing C (All C sees is the same user, all the time).
> If your using Windows Server 2003, you can use delagation as explained
> in the links I provided earlier.
>
> punjab_tom@.hotmail.com wrote:
>

Dose Perspective to an extent improve the cube process performance?

Hi, all experts here,

Thank you very much for your kind attention.

Would please any expert here give me any guidance and advice that if a Perspective of a cube really improve the performance of the process in terms of process speed.

Thank you very much in advance for any guidance and advice for that.

With best regards,

Yours sincerely,

Perspectives don't affect cube processing in one way or another. Think about Perspective vs. Cube as about View vs. Table.|||

Hi, Mosha, thank you very much for your guidance.

So is it in a way like views for tables make retriveving data faster from a perspective rather than a large cube as what views meant to tables. Dose that sense perspective mean to cube (besides in a way to well organize information in cube for specific perspective)? Thanks a lot.

With best regards,

Yours sincerely,

|||Retrieving data from perspective will have exactly same performance as retrieving data from the cube. Perspective is mostly just a way to hide some dimensions/measures/actions/calculated members to have less cluttered and more focused view on the cube. But all the queries go against the cube.|||

Hi, Mosha, thank you very much for your guidance.

With best regards,

Yours sincerely,

Dos and Donts of SQL

Well guys this may be the wrong place but an earlier post by an
"expert" about how a table was poorly designed has piqued my interest.
The question is this. What are the do's and don'ts of sql development?

Please list what you consider to be good and bad practices in general
and/or specific or list links to resources that would be considered
under this topic.

When I consider best practices myself of course there is always the
standards of 3nf and such but what about when it comes to standard
table structures and field sizes for say a Name (first, last, etc) and
contacts table. What about naming conventions and common entities and
structures.

It seems to me that every SQL Developer that enters this field starts
out with the basics of how the technology works and a little of the
practices. Yet from there I see many different directions that they
go.

To start this conversation out let me propose some things that I have
questions about. Feel free to expand and add to this list.

1. What would you consider the standard/best way to represent a
gender.

2. Field Size for Names and address First/Last Etc.

3. Include or don't include City/State in an address/contact list.

4. Structure of a Generic Contact list.

5. Practices for dealing with pictures and documents as well as
related table structures.

6. Level of normalization to aim for. (My minimum is 3 but I
generally hit Boyce Codd myself)

7. What datatypes to avoid and why.

Two requests.
1. Keep it polite.
2. Be constructive and complete.Just as I was posting this I saw a link to a fine articles on the best
practices. Here it is

http://vyaskn.tripod.com/coding_conventions.htm|||Want to wait a bit for my next book, SQL PROGRAMMING STYLE to come out?

1. What would you consider the standard/best way to represent a
gender. Use the ISO codes, since they are standards, of course.

2. Field [sic] Size for Names and address First/Last Etc. Use the USPS
model, which is based on a five line, 3.5 inch label with 10 pitch type
on it.

3. Include or don't include City/State in an address/contact list.
Include it since you need it to mail anything.

4. Structure of a Generic Contact list. Unh? That is not a question.

5. Practices for dealing with pictures and documents as well as
related table structures. Use tools intended for them. There are
several good textbases. I have not worked with graphic search tools.

6. Level of normalization to aim for. (My minimum is 3 but I
generally hit Boyce Codd myself) if you use an ORM model instead of
ER, you will get to 5NF.

7. What datatypes to avoid and why. Anything proprietary because it
will not port, cannot be guaranteed to be consistent from one release
to the next, etc.|||Well CELKO said me a copy to review and I'll be happy to read it :)
However many people's first target for questions and advise is the
internet and usegroups like this.
This is a resource that we need to continue to support and add to.
Since it is a resouce for all of us. Not just those with a specific
book on their shelf. (not to down play your book which I actually may
go get or look at after it's published) Good luck with the book in the
meantime.|||I had a comment on the normalization. We have a reporting database that is
updated nightly. It runs on a little server for only management accesses.
If I normalized this database, reports would run 10 minutes. I normally
build non-normalized tables for the reports and they run in a couple of
seconds. Therefore, my point is normalization really depends on the desired
application.

"Dan Gidman" <danatcofo@.gmail.com> wrote in message
news:1113403304.346956.186420@.g14g2000cwa.googlegr oups.com...
> Well guys this may be the wrong place but an earlier post by an
> "expert" about how a table was poorly designed has piqued my interest.
> The question is this. What are the do's and don'ts of sql development?
> Please list what you consider to be good and bad practices in general
> and/or specific or list links to resources that would be considered
> under this topic.
> When I consider best practices myself of course there is always the
> standards of 3nf and such but what about when it comes to standard
> table structures and field sizes for say a Name (first, last, etc) and
> contacts table. What about naming conventions and common entities and
> structures.
> It seems to me that every SQL Developer that enters this field starts
> out with the basics of how the technology works and a little of the
> practices. Yet from there I see many different directions that they
> go.
> To start this conversation out let me propose some things that I have
> questions about. Feel free to expand and add to this list.
> 1. What would you consider the standard/best way to represent a
> gender.
> 2. Field Size for Names and address First/Last Etc.
> 3. Include or don't include City/State in an address/contact list.
> 4. Structure of a Generic Contact list.
> 5. Practices for dealing with pictures and documents as well as
> related table structures.
> 6. Level of normalization to aim for. (My minimum is 3 but I
> generally hit Boyce Codd myself)
> 7. What datatypes to avoid and why.
> Two requests.
> 1. Keep it polite.
> 2. Be constructive and complete.|||>> I normally build non-normalized tables for the reports .. <<

This is a "Data Warehouse" versus "OLTP database"; you can do this only
because the warehouse is loaded from a normalized production database
and then is never updated while in use. A data warehouse is a very
different game. Even teh quereis are different.