hey
I work in a SSRS environment; I also do some web dev.. and we keep on
having authentication problems getting a token to pass from one user to
the webserver; and then to the database server.
this is called 'double-hop' authentication.. right?
I'm of the understanding that I need to check 'trust for delegation'
and run SetSpn on the ServiceAccount for my database server for it to
be the recipient of a double-hop token.
Isn't that correct?
Ok.. now let's fast forward.. We got a bunch of SSRS Servers; and for
most of these; these guys put the SSRS Server on the same machine as
the database server.
Then they go to copy the report from the localserver to another; and
they bitch about how it doesn't have permissions.. it shows up and says
'user Null' or whatever-- it just sounds to me like a simple double-hop
problem.
I've tried to explain this to a half dozen clients over the years--
about the web authentication thing.. .because everywhere I go; people
use SQL authentication or they put the DB Server on the same machine as
the webserver.. or they make you launch the SSAS processing job from
the local machine.. instead of being able to connect from my desktop to
a SSAS machine to a 3rd machine- the db server.
It just seems to me like 99% of the companies out there dont know how
to do double-hop authentication.
And I just swear to god... everyone i tell this to theyre like 'well
were not a kerberos shop so we dont need to do that'
Does anyone have any REAL CLEAR guidelines for when we should use the
double-hop 'trust for delegation' and 'setspn' concept?
a) we DONT have kerberos
b) we have a half dozen servers and these guys put SSRS on the main db
server
(I assume it's because they dont speak double-hop)
c) at one of my last jobs; we had to terminal into the local db server
to do anything because we didn't have double-hop.. seemed like we were
throwing the baby out with the bathwater; giving people perms to the
terminal services on the db server; it just seems like overkill
d) I want to be able to go from DesktopA and hit ServerA and from
ServerA use a linked server to ServerB. That spells 'i need
double-hop' right?
thanks guys
-Susieyes I must do this also
my friend said that this was possible
susiedba@.hotmail.com wrote:
> hey
> I work in a SSRS environment; I also do some web dev.. and we keep on
> having authentication problems getting a token to pass from one user to
> the webserver; and then to the database server.
> this is called 'double-hop' authentication.. right?
> I'm of the understanding that I need to check 'trust for delegation'
> and run SetSpn on the ServiceAccount for my database server for it to
> be the recipient of a double-hop token.
> Isn't that correct?
> Ok.. now let's fast forward.. We got a bunch of SSRS Servers; and for
> most of these; these guys put the SSRS Server on the same machine as
> the database server.
> Then they go to copy the report from the localserver to another; and
> they bitch about how it doesn't have permissions.. it shows up and says
> 'user Null' or whatever-- it just sounds to me like a simple double-hop
> problem.
> I've tried to explain this to a half dozen clients over the years--
> about the web authentication thing.. .because everywhere I go; people
> use SQL authentication or they put the DB Server on the same machine as
> the webserver.. or they make you launch the SSAS processing job from
> the local machine.. instead of being able to connect from my desktop to
> a SSAS machine to a 3rd machine- the db server.
> It just seems to me like 99% of the companies out there dont know how
> to do double-hop authentication.
>
> And I just swear to god... everyone i tell this to theyre like 'well
> were not a kerberos shop so we dont need to do that'
> Does anyone have any REAL CLEAR guidelines for when we should use the
> double-hop 'trust for delegation' and 'setspn' concept?
> a) we DONT have kerberos
> b) we have a half dozen servers and these guys put SSRS on the main db
> server
> (I assume it's because they dont speak double-hop)
> c) at one of my last jobs; we had to terminal into the local db server
> to do anything because we didn't have double-hop.. seemed like we were
> throwing the baby out with the bathwater; giving people perms to the
> terminal services on the db server; it just seems like overkill
> d) I want to be able to go from DesktopA and hit ServerA and from
> ServerA use a linked server to ServerB. That spells 'i need
> double-hop' right?
> thanks guys
> -Susie|||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|||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
SleepyLab wrote:
> 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
>|||Which account is the Application Pool your Report Server virtual directories
running under?
If that runs as network service, you might want to try running it as the
domain user you've set up.
Or try using Integrated Security instead of basic authentication.
Kaisa M. Lindahl Lervik
"dawidg" <dawidg@.discussions.microsoft.com> wrote in message
news:8AB36908-AB90-4F46-B185-5F2E21A85E9D@.microsoft.com...
> 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:
>> > 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
>> >
>>
Sunday, March 11, 2012
double-hop authentication for SSRS and ASP
Labels:
asp,
authentication,
database,
double-hop,
environment,
microsoft,
mysql,
oracle,
server,
sql,
ssrs,
token,
user,
web
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment