I have a web application, which is using a SQL Server 2005 database.
My problem is, that the application has no role management. So the application always accesses the database with one default user. But now I have to save and access a value only for the current user.
Is there any way to do this? Maybe something like a session on the web server? The best way would be, if there is any possibility to access the current session id of the web server from T-SQL.
Do anyone understand my problem? :)
Allows a system-supplied value for the current login to be inserted into a table
DECLARE #sys_usr char(30);
SET #sys_usr = SYSTEM_USER;
SELECT 'The current user is: '+ #sys_usr;
GO
from MSDN
In my opinion, it's better don't do this. Another way: send to stored procedure current user from web sever:
command.CommandText = "EXEC mySP #user";
command.Parameters.Add("#user").Value = ((YourOwnUserClass)Session["user"]).Name;
// or System.Web.HttpContext.Current.User.Identity.Name; to use built-in
// from web page it becomes this.User.Identity.Name;
If you are using Windows integrated authentication instead of SQL accounts:
Give schema object permissions to a Windows group, not a user. Then add all of your application users to this group.
Use the built-in SUSER_NAME() function to retrieve the underlying Windows user name (in loginDomain\userName format.
Related
For a trigger in SQL Server 2008R2 I need to know the user who inserted, updated or deleted the record.
As different users log in with the same connection string I do not know who is really logged in to the server (I use SQL authentication with the same UID and I grant access through the Access database!!).
I would like if possible to add a variable to the connection string such as Application Name=myrealusername but it seems that from Access VBA I cannot add this Parameter.
Does anyone know how to retrieve the real username who's logged in to pass the username to the trigger?
You could try recording the HOST_NAME() to capture the instance the query was executed from. If every user has it's own PC, it's probably one of your best guesses if you don't plan on using Windows Authentication.
More details: HOST_NAME() MSDN Documentation
Obviously the only real solution would be to use Windows Authentication.
You can use windows authentication and try using
select suser_name()
One of the users in our network needs access to one table of a sql server database. Since it's Windows Authentication, I created the user in Security\Logins and I've added the user in Security\Users for the database. I've also added the permissions.
Now I'd like to test it. How can I do this if I don't have this user's password? Obviously, he's not going to give it to me.
Thanks.
Execute As User = 'domain\Name';
-- Perform the test - use a Transaction if you need to test data modifications
Select * From schema.table;
Revert
ALTER LOGIN allows one to change the CHECK_EXPIRATION property associated with an account, but how does one get the existing value of this property for an arbitrary user?
You can get this data through the LOGINPROPERTY() system function:
select loginproperty('your_login_name', 'daysuntilexpiration');
If you want to see if the SQL logins is subject to expiration, just check sys.sql_logins:
select name, is_expiration_checked
from sys.sql_logins;
Note: As per the documentation on CHECK_EXPIRATION, this only applies to SQL logins, not Windows logins. If you need to get this expiration for Windows accounts, then I recommend you create programmatic logic (outside of SQL Server) to grab the login(s) from SQL Server, and then make AD calls to get expiration date. To do this with PowerShell, this seems to be a good blog post on a quick methodology.
Does anyone know if there is an easy way to bypass the standard windows authentication used to access published reports in the report website front end.
I know about the different authentication methods, RSWindowsNegotiate, RSWindowsKerberos, RSWindowsNTLM and RSWindowsBasic. I also know there is the custom authentication option where I have to go and create my own Login ASP.net page.
The issue is I am trying to set up a role for a user to limit what the user can see and do in the front end without adding another user to the windows active directory.
So the user must be able to log in with their own username and password and only be able to view what their permissions are set to.
Is there a simple way to do this?
I would not call it a simple way, but there is a way to do this. Check out this article on SQLServerCentral: How to Setup Report Parameters to Default Based On User Credentials
It describes the following steps to implement this:
create a report users table in your sql server database
create a UserID parameter
adapt your report queries to identify the user and use that
information to show only permitted data
We have a web application that uses forms authentication to authenticate a user based on a user table in the database. (I.e. no active directory or SQL server user accounts are involved here). The web application accesses the SQL server using a service account. However, for auditing, authorization and other purposes, our stored procedures need to know for which user any given operation is being executed.
In a previous life, I worked with a similar situation using an Oracle database. In this scenario, every time we opened a connection, we first called an Oracle build in procedure to set a connection scoped context variable. This variable contained the user id for the user that would be using the connection. Then all stored procedures that needed to know the current user would check the context variable.
Conceptually this worked a lot like pushing user information onto the CallContext before making a remote call.
My question is, is there any similar mechanism in Microsoft SQL server?
Obvioulsy, if I must, I can pass the UserId as an argument to every single stored procedure, but that is exactly what I am trying to avoid.
Use SET CONTEXT_INFO and CONTEXT_INFO(). See Using Session Context Information.
What you can do is create users within the database (without Server logins) and give them appropriate permissions. After that, what you do is an "execute as" statement and then the user context for your database calls will be as if the user called it. Example:
EXECUTE AS USER = 'user2';
EXECUTE usp_insert_stuff #params;
REVERT;
Downside: you have to set up SQL security and manage users
Upside: Users cannot connect directly to SQL Server and you get auditing.
Reference here:
http://msdn.microsoft.com/en-us/library/ms188354.aspx
See examples towards the bottom of the page.