When I try to create a SQL Server Login by saying
CREATE LOGIN [ourdomain\SQLAccessGroup] FROM WINDOWS;
I get this error
The server principal 'ourdomain\SQLAccessGroup' already exists.
However, when I try this code
DROP LOGIN [ourdomain\SQLAccessGroup]
I get this error
Cannot drop the login 'ourdomain\SQLAccessGroup', because it does not exist or you do not have permission.
The user that I am executing this code as is a sysadmin. Additionally, the user ourdomain\SQLAccessGroup does not show up in this query
select * from sys.server_principals
Does anyone have any ideas?
We are still struggling to understand the HOW of this issue, but it seems that [ourdomain\SQLAccessGroup] was aliased by a consultant to a different user name (this is part of an MS CRM installation). We finally were able to use some logic and some good old SID comparisons to determine who was playing the imposter game.
Our hint came when I tried to add the login as a user to the database (since it supposedly already existed) and got this error:
The login already has an account under a different user name.
So, I started to examine each DB user and was able to figure out the culprit. I eventually tracked it down and was able to rename the user and login so that the CRM install would work. I wonder if I can bill them $165.00 an hour for my time... :-)
is this when you are restoring from a backup or something? I've found that the following works for me in situations when I'm having problems with user accounts in sql
EXEC sp_change_users_login ‘Auto_Fix’, ‘user_in_here’
This happened to me when I installed SQL Server using a Windows username and then I renamed the computer name and the Windows username from Windows. SQL server still has the old "Computername\Username" in its node of Server->Security->Logins.
The solution is to go to Server->Security->Logins and right-click -> rename the old Windows user and use the new MachineName\Username.
I faced similar issue and i believe the issue was as a result of trying to recreate a login account after deleting an existing one with same name.
Just go through the various databases on the server using SQL Studio.
Example steps:
DBName ->Security->users
at this level for each of the databases, you may see the name of the user account there. Delete all occurrence in each Database as well as its occurrence in the top level Security settings at
Security->Logins
When done, try recreating the login account again and you should be fine.
I had the same story as Shadi.
On the top I can add that it can be also done by query:
ALTER LOGIN "oldname\RMS" WITH name="currentname\RMS"
Related
Our business has just changed Active Directories and the domain changed, from "YMS" to "YMSNET". So I used to be able to log in with "YMS\tkol" and I can now log in with "YMSNET\tkol" (these usernames and domains are faked for the purpose of example), but when I log in as that now, I can't actually expand any of the databases or look at any of the tables, I can just see a list of the database names. When I try to expand a database in the UI it says "This database is not accessible (Object Explorer)."
Now I have another user, called "sqluser", and I keep trying to use that user to log in as well by changing the Authentication Method to SQL Server Authentication rather than Windows Authentication. But I get Microsoft SQL Server, Error: 4064
Now I know this sqluser user exists and the password is correct, because I can authenticate to the server and successfully interact with the tables from an external process on a separate computer on the same network (node.js, package mssql). And I used the query on the accepted answer on this question, and found my sqluser is there, with roles db_accessadmin, db_ddladmin, db_owner. And yet it still won't let me log in with that user in the SQL Server Management Studio UI
How can I get this working again and log in with my sqluser account? Or add the appropriate permissions for my YMSNET\tkol account?
--- edit ---
My first idea is that, because I can log into the UI with YMSNET\tkol, but I can interact with the databases externally with sqluser, that there is some query or command I can run with sqluser that will add permissions for YMSNET\tkol so that that user can now look at all the databases and tables. I don't know which commands I'd run for that.
It can be because your account's default database is mapped to some another db which is not available for you, for instance, you have no permissions there, or that database not exists anymore etc.
Your organization DBA can fix it by:
ALTER LOGIN [sqluser] WITH DEFAULT_DATABASE = [rightDB]
Default db name can be checked by:
select default_database_name from sys.server_principals
where name = 'sqluser'
This property can be overridden by opening "Options" of SSMS connection window and specifying it explicitly:
I am trying to create users on a SQL server from an Active Directory group as an application I am working with does not natively support Windows authentication and relies upon individual logins being created on the SQL server, as application level permissions are managed in the application rather than using SQL roles. Due to this, each user that is to access the application needs their own user creating against the SQL instance that the applications database is on, so that the user can then be assigned individual permissions within the application.
I am reading the list of users from the Active Directory group we have designated using the following;
exec master..xp_logininfo 'domain\groupname', 'members'
This returns output similar to the following;
account name type privilege mapped login name permission path
DOMAIN\USER user user DOMAIN\USER DOMAIN\GROUPNAME
For the most part, the users returned in this list can be created on the SQL instance without any drama. I am creating the users as SQL accounts using sp_grantlogin in the first instance, before moving on to allow each new login access to the application database. However, a handful of users are being reported as not existing. I get the following error as a result of running sp_grantlogin;
Msg 15401, Level 11, State 1, Procedure sp_grantlogin, Line 49
Windows NT user or group 'DOMAIN\USER' not found. Check the name again.
Obviously in the above error message, I have removed the actual username. Why would xp_logininfo return a user that cannot be created with sp_grantlogin? Is there anything obvious that I am missing?
This just means that the user is not in the Administrator group. If your problem is like mine where your Active Directory in on a different Virtual Machine, and your SQL Server on another. And you have joined Active Directory Domain to your SQL Server Virtual Machine, then you have to do the following on your SQL Server Virtual MAchine.
Navigate to Tools --> Computer Management.
The windows opens, Expand System Tools --> Local Users and Groups.
Click on Groups and you should see a list of groups to the right
column of the window.
Double click Administrator, a new window opens and you will notice that the linked User is not under there.
Click Add, new window opens. Here, under location, you may chose to change
location of your domain.
Click Advanced, a log in prompt opens, simply log in with you administrator Virtual Machine account.
Click Find Now with all fields as is. From a list of users presented, double click the user imported from Active Directory and click Ok.
Do you change the case of the login name before using sp_grantlogin?
If you have a case sensitive server collation, then the case of the AD user nneds to be specified in exactly the right case.
You can find the server collation by doing:
select serverproperty('collation')
If you do have a case sensitive server collation, and you don't mess with the case, there is probably a mismatch with what xp_logininfo is returning and the actual case in AD. In which case, try creating the user with variations on the case.
If none of this applies, look into the account. Is it disabled, can you log in with it, etc.. If suser_sid() returns null, then there must be some kind of problem with it.
I can give you my advice from doing this in Windows 7 although it may not be relevant.
The problem I had was that I had renamed the user account in the Windows UI. The name appeared correctly in Windows, and I used the new name to log on. But behind the scenes it was still using the old name which was what SQL Server was looking for.
I struggled with this for HOURS before I finally worked it out!!
I have also faced this error for users, who was:
created in AD
granted some SQL permissions
renamed in AD
Then I try to add this new, renamed user account name to the same server/database, error Msg 15401, Level 11, State 1, Procedure sp_grantlogin, Line 49 appears.
I have followed steps in http://support.microsoft.com/kb/324321/en-us and this command returned old user account name befor rename:
SELECT name FROM syslogins WHERE sid = SUSER_SID ('YourDomain\YourLogin')
it returned
YourDomain\OldLogin
after executing
exec sp_revokelogin 'YourDomain\OldLogin'
problem was fixed, sp_grantlogin now works ok.
PS as another test method I suggest running sp_grantlogin remotely, from another server. It may succeed to.
I had a very similar case, the same error code 15401, but in this case what I was doing was adding users from the Domain, into a group in the server where I had SQL; so then just add the group to SQL engine with the same ROLE.
USE [master]
GO
CREATE LOGIN [localhost\Administrators] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
Msg 15401, Level 16, State 1, Line 3
Windows NT user or group 'localhost\Administrators' not found. Check the name again.
Then in the link PRB: Use BUILTIN\Group to Grant Access to Predefined Windows NT Groups
I found the issue, so the solution was:
USE [master]
GO
CREATE LOGIN [BUILTIN\Administrators] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [BUILTIN\Administrators]
GO
Command(s) completed successfully.
I believe this is great to diminish the number of login accounts, and have a more manageable number of users assigned to the roles in the SQL server.
If you're using a non-English language, or have been using one on your machine, you might have to localize the user details you're trying to use.
E.g. [NT AUTHORITY\Network Service] on a Swedish machine is [NT INSTANS\Nätverkstjänst].
Spent hours trying to figure out why BUILTIN\, NT AUTHORITY\, <MachineName>\ etc. didn't work.
My issue was the length of the login. In Domain\User syntax, Windows uses the so called pre-Windows 2000 syntax. That syntax limits the length of the username to 20 characters. You have to truncate the username to the first 20 characters and then it should work, like so:
Domain\Abcdefghijklmnopqrstuvwxyz
Becomes
Domain\Abcdefghijklmnopqrst
I need to copy a SQL Server Express database from one one server to another (virtual) server.
I know how to do this for the database itself - with a backup and restore. I have also looked at this and this which show how to script this - that's great.
However, I also need the permissions to go with it but can't figure out how to do that.
Any pointers would be warmly welcomed.
The logins need to exist already on the destination server, but once they exist, you can wire-up the logins back to the users with a script like this:
sp_change_users_login 'Update_One', 'user-name', 'login-name'
More information on sp_change_users_login can be found on MSDN
Logins are at a server level. Users are at a per-database level. Generally I keep the login name and user name the same to avoid confusion, but they can be different. The Users define the permissions within the database and you've not lost them, just the link to the login.
As an alternative to sp_change_users_login
ALTER USER username WITH LOGIN = newlogin
I executed the task Take offline of a SQL Server 2008 R2 database.
I cant bring it online!
I tried with
USE master;
GO
ALTER DATABASE [DBNAME] SET ONLINE
I get an error.
User does not have permission to alter database 'DBNAME', the database
does not exist, or the database is not in a state that allows access
checks.
I also tried using the task Bring online and I get the exact same error.
Can anyone help me asap?
I think you're going to need to login with the SA account, or some other account with sysadmin privileges, and then run your code to put it back online. While you're in there, add sysadmin to your account, too. If you don't own the database, you may need to talk to someone else to get the SA password, or ask them to do it for you. Unless you don't have the SA password or it's been dumbed down for security reasons.
Your error is too generic to be usable. Do you actually have the rights to alter the database (I guess you do if you managed to bring it offline)? Can you access teh SQL logs (accessible in the tree via Management > SQL Server logs)? Are you sure the user who is executing the script is the one you expect?
Also, you can try any of the following
* restart the service then retry
* Use the mouse GUI o bring it online (right click on the DB, Tasks, Bring Online)
Had same problem, same error. Even logged on as SA and returned same error. On both problem database the owner was not SA.
Solved by attaching the database. This gives you the opportunity to rename the database was well assign an owner. Assigned owner as SA.
Detached failed database the renamed the newly attached database to the original name.
A lesson in always give SA ownership of new databases.
I'm installing an SQL database and our application on a single PC. Under Vista this needs to be installed by an administrator account, but this means that the regular user account(s) can run our program, but it can't access the database it needs.
What I need is a simple way of allowing all NT logins on the PC to have access to the database.
I thought I'd solved it: In SSMS I can manually assign db_datareader/writer roles to BUILTIN\Users, and it works perfectly.
However, if my installer programmatically executes the following, it doesn't work:
USE [OurDatabase]
GO
EXEC sp_addrolemember N'db_datawriter', N'BUILTIN\Users'
GO
EXEC sp_addrolemember N'db_datareader', N'BUILTIN\Users'
GO
The users get assigned the roles, but they still can't access the database. The only difference I can see in SSMSE is that in the latter case, they also gain ownership of a new "BUILTIN\Users" schema, which I suspect may be screwing things up. Clearly SSMS does something slightly different...
Can anyone suggest a way to get this working programmatically?
In OurDatabase, what user is mapped to the login? Do you see a difference in the SSMS method vs. programmatic? What is the default schema for the user mapped to the group login when it works?
What about setting the application only to run as administrator on vista?
Ah, it appears that SSMS also does a
CREATE USER [BUILTIN\Users] FOR LOGIN [BUILTIN\Users]
on the database if the user doesn't exist.
I was twiddling the permissions on and off several times while trying to work out what to do, and on subsequent attempts the user already existed so SSMS didn't bother with the CREATE command. So when I finally figured out what I needed to do, I was getting an incomplete (for my needs) script out of it.
This wasn't obvious because the effects of this command are not seen in the user properties; they appear in the User Mapping in the Server Security\Logins section of SSMS.
Thanks to Aaron (the mention of logins had me looking at the Security\Logins page and I spotted the difference in the mappings there)