April 12, 2016 at 7:05 am
Hi All,
Whenever I change a server login's database user mapping, everything seems to work fine, but then when I reopen the login's properties none of the changes that I made persist. I've tried this through the GUI, T-SQL, at the server level - login - properties - user mapping, and at the database level - role - properties - membership. No matter what I try (GUI or scripting) nothing errors, everything completes successfully, but the changes are not made. Some online research points to not being able to drop a user from a role if that user is the dbo, but this is not the dbo user.
Any thoughts on what might be happening would be greatly appreciated.
Thanks,
JimiHaze
April 12, 2016 at 7:14 am
its sounds very much like the database user already exists and is orphaned.
Please post the results of the following
USE [yourdb]
select sid AS LoginSID from master.sys.server_principals
where name = 'theuser'
select sid AS DBUserSID from sys.database_principals
where name = 'theuser'
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 12, 2016 at 7:35 am
LoginSID : 0x010500000000000515...
DBUserSID: returned nothing
April 12, 2016 at 7:51 am
In that case, please will you post the exact script you ran to get that result, along with the script you ran when attempting to change the mapping. You can obfuscate login names and any other details if you need to, as long as you're consistent in what you post.
Thanks
John
April 12, 2016 at 8:16 am
Certainly. Here's one that I've tried running a few times:
USE [myDB]
GO
ALTER ROLE [DBRole] DROP MEMBER [DOMAIN\serviceAcct]
GO
[DOMAIN\serviceAcct] is what I used for 'where name = ' in the post above.
Thanks,
JimiHaze
April 12, 2016 at 8:23 am
JimiHaze (4/12/2016)
LoginSID : 0x010500000000000515...DBUserSID: returned nothing
you set [yourdb] and the user name string before executing?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 12, 2016 at 8:25 am
Yes, I changed all of your examples into what I needed.
April 12, 2016 at 8:35 am
JimiHaze (4/12/2016)
Yes, I changed all of your examples into what I needed.
does the login own the database by any chance
select suser_sname(owner_sid), name
from sys.databases
where database_id = db_id('yourdb')
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 12, 2016 at 11:33 am
The owner of the database is [sa].
April 13, 2016 at 2:14 am
Perhaps your login is mapped to a database user with a different name? Please run this:
USE MyDB
SELECT u.name
FROM sys.server_principals l
JOIN sys.database_principals u ON l.sid = u.sid
WHERE l.name = 'DOMAIN\serviceAcct' -- don't include the square brackets here
John
April 13, 2016 at 7:22 am
Running that query returns the same name as the login that I put in for l.name
Thanks,
JimiHaze
April 13, 2016 at 7:33 am
In that case, Perry's script should return the same SID twice. Something strange is going on. You'll need to talk us through exactly what you're doing, please, perhaps with screenshots or queries and results that show role membership and so on.
John
April 13, 2016 at 9:19 am
I did another test by dropping the user and re-creating them in the database. This will - of course - remove them from the role. However, when I add them back into the other DB roles that they are supposed to be in, they get automatically added to the role that I do NOT want them in. Should I be looking for some sort of trigger that automatically adds them if they are in a certain role?
Thanks,
JimiHaze
April 13, 2016 at 9:26 am
Yes, check for triggers. If you don't find anything, try an extended events session to capture user creation, role membership changes and so on. That might give you a clue to what's going on.
John
April 13, 2016 at 11:23 am
There are no database triggers present that would cause this to happen. Also, I'm not quite sure what events I should be capturing in the Extended Events Session to be able to see the changes taking place. I've done some research, but nothing is leading me to the answer there.
Thanks,
JimiHaze
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply