SQL USER_NAME() windows authentication - sql-server

When I logged in sql management studio with windows authentication and I run
SELECT USER_NAME()
I see the result as dbo.
I would of thought that it would showed my user ....
I more looking at the explaination to as why it returns dbo

Use this instead
SELECT SUSER_NAME()
USER_NAME: Returns a database user name from a specified identification number.
SUSER_NAME: Returns the login identification name of the user.

Try:
SELECT SUSER_SNAME()

i had similar problem, the problem is due to the way user id is created.
choose the login id under security -> right click properties -> Server Roles. Ensure you click only "Public" no "sysadmin"

Related

Rename security group in AD, and mapped SQL login

Example:
Lets say I have a group named group_01, the group is mapped to a SQL Server an given some rights on some stuff.
When I rename the group in Active Directory to any value, lets say group_01_OLD.
The group name wont change in SQL Server, it's still group_01
Is this normal behavior? Can I force SQL to rename the group when renamed in AD?
An full answer is buried in the comments here: https://dba.stackexchange.com/questions/13766/user-windows-login-name-has-been-changed-in-ad-yet-session-in-sql-2008-profiler
Basically, a reboot of the whole server should pick up the change (assuming replication to all the DCs has already happened).
If you can't do that, you could try manually updating the name of the login:
ALTER LOGIN [domain\group_01] WITH NAME = [domain\group_01_OLD];
To complement Gabriel’s answer. Given your scenario (you have granted permissions to the group group_01 ), you must change the name in SQL using the ALTER LOGIN command
ALTER LOGIN [domain\group_01] WITH NAME = [domain\group_01_OLD];
The reason for this is that SQL Server looks for a matching login catalog views (i.e. sys.server_principals) within SQL itself before asking AD.
NOTE: When you rename a Windows login, SQL Server will verify that the new name matches the SID to verify that the login renaming is valid.
-Raul Garcia
A reboot do not fix anything as far as I've experienced. SID is of course the same but besides the change of login with...
ALTER LOGIN [domain\previousgroupname] WITH NAME = [domain\newgroupname];
...you also need to change Security\Users for each database the login has a role in, if you want the change reflected everywhere and not having mismatches between logins and users. Can be done using Management studio, editing the group at Security\Logins and Mapping. Untick database, tick and choose role again. Or using ALTER USER but that's just a lot more typing.
USE [db]
ALTER USER [domain\previousgroupname] WITH NAME=[domain\newgroupname];

What is the difference between SYSTEM_USER and USER in SQL server?

I am very new to databases and confused between the keywords SYSTEM_USER and USER in MSSQL. The definitions say that they return the username in the current context. but the instance I have running returns 'dbo' for USER and 'sa' for system user.
Can somebody highlight the exact difference between the two?
SYSTEM_USER: returns Server Login name that was used to login to the instance (either SQL Server login or AD/Domain/Windows user-name).
USER, CURRENT_USER, USER_NAME(), or SESSION_USER: these all return Database User principal, which is (by default) dbo if you are db-owner or logged in as a sysadmin or sa (not to be confused with the dbo schema or the DB_Owner of current database in use).
Examples:
SELECT SYSTEM_USER --> myDomain\user.name
----------------------------------------------
SELECT USER --> dbo
SELECT CURRENT_USER --> dbo
SELECT USER_NAME() --> dbo
SELECT SESSION_USER --> dbo
----------------------------------------------
Note: USER_NAME([user_id]) can additionally take an int-user-id, default arg is 1, i.e.: USER_NAME(1) would be same as USER_NAME().
SYSTEM_USER to return the current system user name.
USER to return the database user name.
According to difference between SYSTEM_USER and USER:
If the current user is logged in to Microsoft® SQL ServerT using
Windows Authentication, SYSTEM_USER returns the Windows 2000 or
Windows NT 4.0 login identification name
for example, DOMAIN\user_login_name.
However, if the current user is logged in to SQL Server using SQL
Server Authentication, SYSTEM_USER returns the SQL Server login
identification name,
for example, sa for a user logged in as sa

IS_ROLEMEMBER erroneously returns 0 for database role members?

Running a local instance of SQL Server 2012.
I have created a custom role:
CREATE ROLE [my_user] AUTHORIZATION [dbo]
For all my users (local Windows users and SQL users), I have specified this role for my database (under the User Mappings setting). Thus, the following query should return 1:
SELECT IS_ROLEMEMBER('my_user')
For my Windows-authenticated users it does indeed return 1, but as soon as I'm logged on as an SQL user, it returns 0. I have triple-checked that the SQL user does indeed have this role. What am I missing here?
Update
Performed some more testing. This certainly is weird behavior. I performed these steps:
On my local SQL Server I created a database test with user sa. Role my_user added.
Logged on as sa in the Management Studio and added MYDOMAIN\MyUser to this role.
Re-logged on with Windows Authentication and executed IS_ROLEMEMBER('my_user'). Returns 0.
Tried the query using both sa (specifying the username) and the Windows user. Same problem.
Tried restarting the SQL Server, just in case.
This makes no sense! If I right-click the role I can see that my Windows user is indeed a member of it. The IS_ROLEMEMBER function is flawed! When I run the following query, it shows that my user is indeed a member of the database role:
SELECT
USER_NAME(memberuid), USER_NAME(groupuid)
FROM
sys.sysmembers
WHERE
USER_NAME(groupuid) = 'my_user'
This also shows my membership:
select r.name as role_name, m.name as member_name from sys.database_role_members rm
inner join sys.database_principals r on rm.role_principal_id = r.principal_id
inner join sys.database_principals m on rm.member_principal_id = m.principal_id
Some additional information:
I'm on a domain, but currently disconnected. I have seen this problem when connected too though.
Running Windows 8.1 64-bit.
Update 2
If I explicitly specify the principal as some have suggested, I get this error (executing as sa):
SELECT IS_ROLEMEMBER('my_user', 'MYDOMAIN\UserX')
Msg 15404, Level 16, State 19, Line 1
Could not obtain information about Windows NT group/user 'MYDOMAIN\UserX',
error code 0x54b.
Could it be that IS_ROLEMEMBER experiences the same problem, but does not print the error?
I just had this same issue... I found that the user in question had server roles also assigned to them. When I removed all server roles except 'public', suddenly the is_rolemember query started correctly reporting a 1 instead of the zero..... I tested this back and forth a few times to confirm.
Also had this issue. Turns out I had to remove sysadmin server role, then it worked.
This is taken from: https://learn.microsoft.com/en-us/sql/t-sql/functions/is-member-transact-sql
Members of the sysadmin fixed server role enter every database as the dbo user. Checking permission for member of the sysadmin fixed server role, checks permissions for dbo, not the original login. Since dbo can't be added to a database role and doesn’t exist in Windows groups, dbo will always return 0 (or NULL if the role doesn't exist).
Try specifying the principal explicitly.
SELECT IS_ROLEMEMBER('my_user', 'SqlLogin')
I tested this and it returned 1.
CREATE DATABASE TestDatabase;
GO
USE TestDatabase;
GO
CREATE ROLE TestRole AUTHORIZATION dbo;
GO
CREATE USER TestUser WITHOUT LOGIN;
GO
EXEC sp_addrolemember 'TestRole', 'TestUser';
GO
SELECT IS_ROLEMEMBER('TestRole', 'TestUser');
GO

When is IS_MEMBER set in Sql Server?

I am trying to get IS_MEMBER working in a UDF in Sql Server 2005.
I have a windows group "Domain\TestGroup".
I allocate my Login "Domain\Kieran" to it.
select SUSER_NAME();
gives "Domain\Kieran"
but
select IS_MEMBER('Domain\TestGroup');
returns NULL.
The NULL answer from IS_MEMBER means that SQL Server does not recognise the Windows group.
It looks at the login token from your connection. It does not query Active Directory.
From the BOL link:
IS_MEMBER determines Windows group
membership by examining an access
token that is created by Windows. The
access token does not reflect changes
in group membership that are made
after a user connects to an instance
of SQL Server.
So, even though doamin\kieran is in the group you'll probably need to log out and back in so your login token is updated with the group membership.
It should all work in your UDF (unless you have EXECUTE AS USER or OWNER in the UDF)
Ah. I think I see the problem.
My login is in builtin\Administrators which is a member of the server fixed role sysadmin.
Therefore I'm a member of sysadmin, which means I'm dbo and won't see any role or group information.
Check your ERRORLOG and see if there is any error indicating that the SQL Server service cannot connect to the 'domain' Active Directory.

Sql Server 2005 how to change dbo login name

I have a database with user 'dbo' that has a login name "domain\xzy". How do I change it from "domain\xzy" to "domain\abc".
I figured it out. Within SQL Management Studio you have to right-click on the database -> Properties -> Files -> Owner field. Change this field to the login name/account that you want associated with the "dbo" username for that database. Please keep in mind that the login name/account you choose must already be setup in the sql server under Security -> Logins
If you are trying to remap a login to a db user you can use sp_change_user_login
exec sp_change_user_login 'Update_One', 'user', 'login'
PhantomTypist gives a good answer using the GUI. For achieving the same result with TSQL, you can use this code:
USE [My_Database_Name]
GO
EXEC dbo.sp_changedbowner #loginame = N'domain\abc', #map = false
GO
This is a Windows login, not a SQL Server login, so you cannot 'change' the login name since it is linked to the user account in Active Directory.
Create a new Server Login (Windows) mapped to the new windows user (and remove the old one if necessary). Then in login's Security > User Mapping, permission that login to the appropriate database as user 'dbo' (or assign to the db_owner role)

Resources