I created an Azure Function to load data from Eudonet CRM to my Azure SQL Database. I have two databases :
named Datawarehouse
named Datawarehouse-Dev
Both databases are identical and are in the same server.
When I load data directly to "Datawarehouse" the copy works fine, but when I change the database name to "Datawarehouse-Dev", I receive the following errors :
Index #0 Message: Login failed for user 'AzureFunction'. LineNumber: 65536 Source: Core .Net SqlClient Data Provider Procedure: Error Code:18456
-- Sql server error. If error code <17: => check sql transac code (user error). Else: => software or hardware errors (check availability of database)
Login failed for user 'AzureFunction'.
If anyone has an idea on where the problem could come from I would be very grateful and I also don't understand why there is an authentification error since they're both in the same server and are accessed with the same user/password.
Thanks in advance
Though #adnane already resolved the issue after using the connection string directly into Function application setting instead of storing it into Vault. This approach might compromise the application security because using connection string directly might expose it to unauthorized person.
Azure Key Vault is a good place to keep our application credentials in a secured and centralized manner. Moving the secrets to Key Vault becomes even more important while our Azure solution is growing.
In case, if anyone still looking for the solution by storing the connection string in Azure Key Vault and then using it in the Function, please follow the below steps.
Firstly, open the Azure Key Vault service and from the Settings menu select Access policies. Then select + Add new access policy.
Then choose Select principal and search for the name of the Function App as shown in below example.
Once your principal is selected choose the Secret permissions menu. In this case, we’ll only need to get the secret from the Key Vault (concretely read our connection string). Therefore, check Get permission only and then select OK.
At the end, select Save to store the new functionapp-demo-mw access policy.
ADDING SECRET TO AZURE KEY VAULT
Adding a secret to Azure Key Vault is straightforward. From the Key Vault, Settings menu select Secrets and then select + Generate/Import secret.
For Key Vault secret two values are required – name and the value. In this case we’ve called our secret OrderManagementDbConnectionString and as a value we put our SQL Database connection string. Select Create to save the secret.
By default, the secret is Enabled so it’s ready to use. Once the secret is created, we’ll need to get its URI (a unique location identifying the secret). Go to the Settings menu and select Secrets. We’ll find here our recently added secret (OrderManagementDbConnectionString). Select the secret and we’ll see it’s the only version in the list.
Select the current version of secret and copy its secret identifier. The identifier is an URI with pattern : https://<url_of_the_key_value>/<secret_name>/<secret_version>.
GETTING SECRET FROM KEY VAULT IN AZURE FUNCTION APP
Go back to the Azure Function App (functionapp-demo-mw) and on the Overview tab, select Configuration in Configured featured section.
Well, Select + New application settings. Put a name that describes the new setting (we’ve put OrderManagementConnectionString). At the end of the last year, Microsoft has added an option of sourcing Key Vault secrets directly from App Settings. This simplifies a lot the way how the secrets were used before. So, set the value of the setting to a secret reference in the following format:
#Microsoft.KeyVault(SecretUri=**secret_uri_with_version**)
We just need to replace secret_uri_with_version with the value we’ve previously copied from the secret in Azure Key Vault.
In Azure Function, you’ll just retrieve the value from the application settings and work with it the same way as it was directly a connection string stored in application settings.
// get value from appliction settings
var connectionString = Environment.GetEnvironmentVariable("OrderManagementConnectionString");
// create connection
SqlConnection connection = new SqlConnection(connectionString);
Using SQL Server 2017 I followed this article to apply Always Encrypt tech:
https://www.codeproject.com/Articles/1110564/Always-Encrypted-feature-in-SQL-Server
Which is simply says:
Create Column Master key.
Create Column Encryption key.
Encrypt the
columns using the latter.
The certificate that being used for step 1. was generated using the wizard and saved in:
Key Store: Windows Certificate Store - Local Machine
I created very simple console app that is using EF to try to get data from the table that I encrypted the column in.
I added to connection string this: column encryption setting=Enabled.
When I try to get the data:
using (MyEntities en = new MyEntities())
{
var x = en.TableHasColEnc.ToList();
}
I get this error:
'Failed to decrypt column 'X'.
Failed to decrypt a column encryption key using key store provider: 'MSSQL_CERTIFICATE_STORE'. The last 10 bytes of the encrypted column encryption key are: 'XX-XX-XX-XX-XX-XX-XX-XX-XX-XX'.
Certificate with thumbprint '...' not found in certificate store 'My' in certificate location 'LocalMachine'. Verify the certificate path in the column master key definition in the database is correct, and the certificate has been imported correctly into the certificate location/store.
Parameter name: masterKeyPath'
What I got that the user that is running this app is not able to access that location to get the certificate, but why ?
If I ran the app as Admin it'll work normally.
I opened mmc and checked Certificates (Local Computer) and found the certificate that has been used in step 1. and it looks like it's correctly in local machine not current user.
Why I'm getting this error and how to solve it ?
This answer helped me to solve the problem:
How to give ASP.NET access to a private key in a certificate in the certificate store?
The idea is to grant the user who's gonna run the app (or in case of web app the IIS application pool user) the permission to be able to read private keys.
In the correct answer explains how to grant IIS user the permission, you can do the same for who ever is running your app.
UPDATE
If your app is on one server and the DB is on another (so your Encryption Certificate most probably on DB's server) you need to export and then import that certificate from DB's server to your app server and give the user who is running your app the permission to use the private key of this certificate.
I've get a fresh install of SQL Server 2012 and do not want to use integrated security. Instead I'd like to use SQL Server authentication, where I create logins in SQL server and assign passwords. However, this option doesn't seem to be available (see screen snapshot below). Every option available to me under "User Type" (other than those that aren't related to accounts at all) want me to map to existing Windows Domain accounts.
In the old days, I'd specify a desired login name and be prompted for a password to go along with it, and I'd be done. Now there's no option to specify a password--I'm forced to map my new login to an existing
windows domain account. Not what I want. What am I missing here? Thanks in advance.
** edit ** New screen snapshots added after RB's comment. I did indeed have an option disabled that would allow BOTH Windows and SQL Server authentication modes, but it's turned on now. After doing so and restarting SQL Server, it is NOT making a difference:
Here is what I am presented with when I try to create a new user. None of these options simply allow me to create a login and password in the context of SQL server (well, one allows creation of a login with no password at all... useless!) All others are linked to existing Windows logins. Ideas?
Let's do this in a way that doesn't require pictures and right-clicking.
CREATE LOGIN [yourUserName] WITH PASSWORD = 'someStrongPassword';
CREATE USER [yourUserName];
I'm running an IIS 7 Website with an AppPool of Integrated Pipeline Mode.
The AppPools does NOT run under NetworkService, etc.. identity (by purpose), but uses its own AppPool Identitiy (IIS AppPool\MyAppPool).
This is a so called service account or virtual account.
(a user account, which is not a full account...)
I'd like to give this service account (IIS AppPool\MyAppPool) permissions to connect to my SQL Server 2008 Express (running in Mixed Auth. Mode).
While SQL Server can add any normal user account, the IIS AppPool\MyAppPool virtual account cannot be added to the valid logons (SQL Server says, that the account cannot be found).
Is there any trick, anything I need to enable to make the virtual accounts work?
(the w3wp.exe process runs under this identity according to taskmgr, but I cannot use the account in NTFS security either...)
Thanks for your help!
The "IIS APPPOOL\AppPoolName" will work, but as mentioned previously, it does not appear to be a valid AD name so when you search for it in the "Select User or Group" dialog box, it won't show up (actually, it will find it, but it will think its an actual system account, and it will try to treat it as such...which won't work, and will give you the error message about it not being found).
How I've gotten it to work is:
In SQL Server Management Studio, look for the Security folder (the security folder at the same level as the Databases, Server Objects, etc. folders...not the security folder within each individual database)
Right click logins and select "New Login"
In the Login name field, type IIS APPPOOL\YourAppPoolName - do not click search
Fill whatever other values you like (i.e., authentication type, default database, etc.)
Click OK
As long as the AppPool name actually exists, the login should now be created.
CREATE LOGIN [IIS APPPOOL\MyAppPool] FROM WINDOWS;
CREATE USER MyAppPoolUser FOR LOGIN [IIS APPPOOL\MyAppPool];
You can solve like this,
Open "Applications Pools",
You should right click that you have choosed application pool. Then choose
"Advanced Settings".
Click three point on the Identity tab then you should choose "LocalSystem" from field of "Built-in-account"
If you do this way, you don't need to create a user in database.
If you're going across machines, you either need to be using NETWORK SERVICE, LOCAL SYSTEM, a domain account, or a SQL 2008 R2 (if you have it) Managed Service Account (which is my preference if you had such an infrastructure). You can not use an account which is not visible to the Active Directory domain.
As a side note processes that uses virtual accounts (NT Service\MyService and IIS AppPool\MyAppPool) are still running under the "NETWORK SERVICE" account as this post suggests http://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx. The only difference is that these processes are members of the "NT Service\MyService" or "IIS AppPool\MyAppPool" groups (as these are actually groups and not users). This is also the reason why the processes authenticate at the network as the machine the same way NETWORK SERVICE account does.
The way to secure access is not to depend upon this accounts not having NETWORK SERVICE privileges but to grant more permissions specifically to "NT Service\MyService" or "IIS AppPool\MyAppPool" and to remove permissions for "Users" if necessary.
If anyone has more accurate or contradictional information please post.
Look at: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
USE master
GO
sp_grantlogin 'IIS APPPOOL\<AppPoolName>'
USE <yourdb>
GO
sp_grantdbaccess 'IIS APPPOOL\<AppPoolName>', '<AppPoolName>'
sp_addrolemember 'aspnet_Membership_FullAccess', '<AppPoolName>'
sp_addrolemember 'aspnet_Roles_FullAccess', '<AppPoolName>'
This may be what you are looking for...
http://technet.microsoft.com/en-us/library/cc730708%28WS.10%29.aspx
I would also advise longer term to consider a limited rights domain user, what you are trying works fine in a silo machine scenario but you are going to have to make changes if you move to another machine for the DB server.
I figured it out through trial and error... the real chink in the armor was a little known setting in IIS in the Configuration Editor for the website in
Section: system.webServer/security/authentication/windowsAuthentication
From: ApplicationHost.config <locationpath='ServerName/SiteName' />
called useAppPoolCredentials (which is set to False by default. Set this to True and life becomes great again!!! Hope this saves pain for the next guy....
In my case the problem was that I started to create an MVC Alloy sample project from scratch in using Visual Studio/Episerver extension and it worked fine when executed using local Visual studio iis express.
However by default it points the sql database to LocalDB and when I deployed the site to local IIS it started giving errors some of the initial errors I resolved by:
1.adding the local site url binding to C:/Windows/System32/drivers/etc/hosts
2. Then by editing the application.config found the file location by right clicking on IIS express in botton right corner of the screen when running site using Visual studio and added binding there for local iis url.
3. Finally I was stuck with "unable to access database errors" for which I created a blank new DB in Sql express and changed connection string in web config to point to my new DB and then in package manager console (using Visual Studio) executed Episerver DB commands like -
1. initialize-epidatabase
2. update-epidatabase
3. Convert-EPiDatabaseToUtc
For the ApplicationPoolIdentity, add a login/user in MSSQL as IIS_IUSRS which is corresponding to the default pool.
So far, after creating DB with all the schema, all I have done so for was accessing them (tables) by reference through ConnectionStrings.
Now, twice, I've read that it's better to create a DB user and access the DB trhough that user by including him in the connectionString.
I'd like to know why so?
Thank for helping
Your question isn't that clear. It seems that you're asking if it is better to use windows security ("Integrated Security=SSPI" in the connection string) or a username/password ("User ID=myUsername;Password=myPassword;").
Its always better to use windows security. Having login information within the connection string is a security risk. Its in cleartext (unless you take some complicated steps to secure that section), and is sent across the wire as cleartext unless you set up a trusted connection between application and server.
Is it better to "create a db user and access the db trhough that user by including him in the connection string?" No. Its better to create a sql server login for user's windows identities and let them use those credentials to access the server.
You do this if you wish to connect as a specific user, rather than (for example) just using the context of the current user which your application is running under. However, if you use SQL Server authentication (i.e. username and password), you'd need to provide that password in the connection string, which is something of a security problem.
If the application has a group of anonymous users (or manages users/passwords itself) then its better to use a Windows login and run the application under a service account (which has minimal required access to the database).
If you're running an interactive application on the desktop, you should let those users connect to SQL server in their own context, by adding them to SQL Server with the required rights (e.g. db read/write , remove any higher functions). Obviously you would use groups to make administration simpler rather than adding individual users.