I have found myself in a little pickle. Having developed what is looking to be a really slick application using CSLA 2.1, I have encountered an issue that is potentially devastating...
I have implemented my application using CSLA based authentication - the need to manage application-based users/roles outweighed the windows method. However, my connection strings reflect a windows-authentication. This had been working fine ... until I needed to interact with another piece of 3rd party software, that is sent an instruction' to populate a row from within my application - by means of a username that it extracts from the function SUSER_SNAME()
My problem is, that when I call the stored procedure to do this, the user name being returned always appears to be "SQLADMIN"...
Any ideas where this username is being drawn from? Shouldn't the authentication reflect my username that is being validated in the domain?
My connection string looks like this...
connectionString="Data Source=SQLTEST;Initial Catalog=ResQ_Sandbox;Integrated Security=True" providerName="System.Data.SqlClient" />if I modify the connection string to use SQL authentication, the problem goes away - but we plan on deploying to over 100 users within the company, with a 'healthy' turnover of employees, so having individual app.configs isn;t going to work.
I'm running WinXP Pro - db is SQL Server 2005.
Your help or any suggestions would be greatly appreciated.
Thanks,
G.
I'm assuming you mean the name being returned from your stored proc is "SQLADMIN". On that basis, the reason you're getting "SQLADMIN" being returned is that it is the name under which all operations on SQL Server are apparently being handled. Regardless of the number of users of the app, there is a single connection to SQL Server for them all.
This article may be of some assistance even though it deals with creating audit trails: http://www.sqlservercentral.com/columnists/spustovit/easyauditingasharedaccount.asp
Thanks. But what is setting this characteristic?
I have a VB6 app, which calls the same proc, but "correctly" returns the windows login of the user - not a 'catch-all' userid?
Similarly the username returned by the 3rdparty VB app is returning the 'correct user' - not the catch-all...
If my connection string suggests a Windows-authenticated login when executing a proc, I would expect the result of suser_sname() to reflect the user that logged in...
I am verym very confused ... and at this point very concerned - I HAVE to idetify the user that's logged in...
Thanks,
G.
Thanks.
I have checked that - all of the connections show 'mydomain\SQLADMIN' as the user ...
This is very frustrating - first I have to determine if it's an expected behaviour - I don't understand why it would have changed ...
Thanks,
G.
sqladmin is in fact one of our domain admins - or rather machine admins (the sql server machines).
But don't understand why my connection would adopt this username when I start the app.
No other developers on this project so the code is mine.. and definitely no code invoke this userlogin...(all mineeeeeee!)..
G.
Profiler didn't show anything 'strange' other than all the transactions showed as mydomain\sqladmin...
I know of at least one other machine that we are testing on that has the same issue - I'm trying to hunt down a Win2k machine to try it on ....
It may be picking up the user elected when connecting to say Tools ...
Reading through some docs, it seems that Windows auth maps to a sql server domain user when connecting ... not absoultely sure what this means .. but am investigating...
I'm actually quite surprised it even lets me use windows auth, as I am definitely not a domain user...
Very strange... I'll keep you posted.
Thanks,
G.
Copyright (c) Marimer LLC