I have a free trial account for Snowflake. I am trying to create storage integration. But after running the script I am getting below error :
SQL access control error: Insufficient privileges to operate on account ''
Even for the Account Admin role, above error is coming.
There are two places to set your role in the Snowflake original web UI (not Snowsight). You need to make sure you're changing to the ACCOUNTADMIN role for the right context:
If you're getting the error when running a SQL statement from the web UI, check your current role for the worksheet. You can click on the icon or role text to change it.
In this example, you can see that I've changed my role in the upper right to ACCOUNTADMIN, but that changes only my role for the button bar. I'm still using the SYSADMIN role when running SQL statements in a worksheet.
Also note that each worksheet has its own context, so changing worksheets could change your role if it's set differently on the worksheet you're opening.
In my case, I have faced this issue, but while using Terraform and specifying the provider configuration through environment variables. I was missing the SNOWFLAKE_ROLE to determine the role used while applying the Terraform configuration.
I ran into this error while running a deployment pipeline to an upper environment (code from DEV migrating to UAT). It's one of those weird situations where the logged-in user has to be able to perform multiple SQL actions which may require multiple role membership. In my case, I was running DDL 'Create' statements (as SYSTEMADMIN) and also needed to run some SQL commands which involved interacting with Snowflake Storage Integrations (which require the active role to be ACCOUNTADMIN).
USE SECONDARY ROLES ALL;
Use Secondary Roles -
https://docs.snowflake.com/en/sql-reference/sql/use-secondary-roles.html
Note that the set of roles is reevaluated when each SQL statement executes. If additional roles are granted to the user, and that user executes a new SQL statement, the newly granted roles are active secondary roles for the new SQL statement.
Including this at the top of each deployment script file removed the 'Insufficient Privileges' error and allowed successful execution of SQL scripts in my deployment pipeline.
BACKGROUND
The user is defined in Azure AD and in Azure SQL.
test.user#company.com is defined and active in Azure AD. I’m able to log in with this user in Azure portal.
I have created a contained database user with the clause "from external provider" in the Azure SQL database and added the user to the db_datareader system role. The commands commits without error. I have compared the Asset ID in Azure AD and the SID in database and they match. I have tried with different users.
I am able to login as an AD User assigned to the SQL servers assigned "Active Directory Admin"
SQL Server users also login without any issue
Login test in SSMS
I have set default database to the specific database I’m trying to log into (Options-Connect to database).
I have tried with different Authentication modes:
“Azure Active Directory – Universal with MFA” and
“Azure Active Directory – Password”
When I try to login with SSMS I get
Error: 18456, state 1, class 14.
When I query [sys].[event_log] it returns
[event_systype]= 4, [event_subtype_desc] = login_failed_for_user.
PROCESS FOLLOWED
I have a user defined in Azure AD. (test.user#company.com)
In my Azure SQL database, I have set an Active Directory administrator.
I have created a user in SSMS test.user#company.com with the following syntax:
CREATE USER [test.user#company.com] FROM EXTERNAL PROVIDER;
I have assigned the user to the db_datareader role with the following syntax:
ALTER ROLE db_datareader ADD MEMBER [test.user#company.com]
ISSUE: When I try to connect as test.user#company.com, the connection fails and I get this error:
Login Failed for user test.user#company.com
Details of error contains:
Error Number: 18456, State: 1, Class: 14
I have tried to find an answer on learn.microsoft.com, googled my ass off and found some useful resources on this, but none that actually helps me with pinpointing what to do to resolve the issue. If anybody have an Idea of what I'm doing wrong, ref "PROCESS FOLLOWED" I'd be forever grateful :)
I solved it by a workaround, setting up a new database.
I did not find the cause of the problem, but it must be related to database setup "DTU"-"Basic" or some setting that I have managed to set without remembering.
Anyways, my process works when I set up a new database with "DTU"-"Standard" Configuration.
It seems to be some kind of encoding problem. After almost giving up and using a different DB, I tried creating a new one, but without some special characters. And suddenly, it worked.
If you can't change your database's password, you can just edit the connection string in another editor and it works as well (Notepad, VS code, etc).
I am getting the error "SQL access control error: Insufficient privileges to operate on account 'XXXXXX'" when I try to create a role in Snowflake in order to get it connected to Segment.
I am following the Segment documentation here: https://segment.com/docs/connections/warehouses/catalog/snowflake/
And I am getting stuck when I run the command "CREATE ROLE "SEGMENT";"
Any help in how to get around this would be great. I am currently on the trial and was able to successfully create the data warehouse and database as per the segment instructions.
Thanks to Greg in the comments:
"An easy way to remember it is that the upper right role is for UI actions, while the lower one sets the context for the worksheet"
1) while I had the correct profile up here
2) once I clicked this
3) I did not have the right profile in here
After switching to ACCOUNTADMIN in 3) I was able to create the role.
screenshot of how I fixed it
I was trying to update one of the data source of my forena configuration. I first update the uri address. After I clicked Updated the forena module broke. I'm sure the problem is that one of the Data Source (the one I updated) can't connect to the database because I didn't update the password. But now, eveytime I click in Configure in my Data source I get the following error:
Fatal error: Call to a member function setAttribute() on a non-object
in
/opt/bitnami/apps/drupal/htdocs/sites/all/modules/forena/plugins/FrxPDO.inc
on line 63
Becuase of this error I can't correct the password.
The drupal log shows the following:
SQLSTATE[HY000] [1045] Access denied for user
'bitnami'#'54.204.20.212' (using password: YES)
I'm thinking there most be a config file somewhere in the htdocs directory but I can't find it.
Can somebody guide on how to fix this?
Thanks,
Claudia
Bitnami developer here,
It seems that bitnami user is trying to access to the dtabase. By default, bitnami user has not privileges to access to the drupal database.
Check in installdir/apps/drupal/htdocs/sites/default/settings.php
the user and the password of the drupal database. You could try execute the action with these parameters. By default, your database name should be bitnami_drupal, and your user bn_drupal.
You also can change the privileges for bitnami user:
$ /installdir/mysql/bin/mysql -u root -p
grant all privileges on bitnami_drupal.* TO 'bitnami'#'localhost' identified by 'not_easy_password'
If you want to create a new database, please follow this link:
https://wiki.bitnami.com/Components/MySQL#How_to_create_a_database_for_a_custom_application.3f
I hope it helps
David
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