I am trying to deploy a dacpac to a database in Azure SQL server using a release pipeline in azure devops. I was able to deploy a dacpac to one database successfully by adding Azure Object Name as db_owner of that database.
I repeated the same step for a different dacpac, but I am getting an error saying the access failed.
2022-04-06T21:54:52.4823080Z Initializing deployment (Start)
2022-04-06T21:55:49.0595299Z Initializing deployment (Failed)
2022-04-06T21:55:49.0721494Z Time elapsed 0:00:57.89
2022-04-06T21:55:49.2784337Z ##[error]*** An error occurred during deployment plan generation. Deployment cannot continue.
2022-04-06T21:55:49.2883974Z ##[error]Login failed for user '<token-identified principal>'.
using service principal as authentication (using SPN of service connection for the service principal)
DB server : xyz
DB databases : xyz.a xyz.b
a is successful, but b fails on same release pipeline.
it seems like access token was successfully grabbed in the script.
Some dacpac deployments were successful because the dacpacs had permissions that were included in the SG which was set as the AAD Admin of the SQL servers.
The dacpacs which had permissions which were not included in the AAD Admin SG were failing. The solution was to drop the permission objects using the sqlpackage.exe flag:
/p:ExcludeObjectTypes=Users;ServerRoleMembership;ServerRoles;DatabaseRoles;RoleMembership;Users;Permissions
Related
I have a SQL Server 2019 with SSIS and I want to execute SSIS packages using SQL Agent jobs with proxy domain accounts.
Currently my sample SSIS packages are failing, all simply stating "Unexpected termination", with no additional errors in Basic or Verbose logging modes. Packages are doing various tasks, working with both local and remote files, all permissions to read/write to folders and files are set.
In the Event Viewer I can see the "The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID" for my proxy account.
Adding the proxy accounts to local Administrators group on VM solves the issue, but I would like to evade doing this.
Instead I have:
added permissions for my proxy accounts in Component Services/DCOM Config/Microsoft SQL Server Integration Services 15.0/Launch and Activation + Access + Configuration permissions
added proxy accounts to Distributed COM Users group. (basically following the SSIS Service MS Documentation these two solve the COM Server error)
granted local permissions to proxy accounts (Log on as a batch job, Log on as a service, Allow log on locally)
but I'm still ending up with Unexpected termination with no further errors/warnings and no further errors/warnings in event viewer as well.
Can anyone advise me what other (Windows) permissions am I missing so I don't have to resolve it using local Administrators group? Or where else I might find additional logs to search for errors?
I've been trying to deploy a database via a pipeline from Azure DevOps to an Azure resource group.
I have an ARM template for my database server in my Repo along with my DACPAC file.
In my release pipeline I first deploy the database server with an admin user defined in the ARM template to my resource group.
Then I use the "Azure SQL DacpacTask" to deploy the database schema. Here I give the admin credentials and it works flawlessly.
The issue is that the customer doesn't want it deployed as a DACPAC but rather an SQL script. They've given me a "CREATE TO..."-script from their database, created inside MS SQL Studio, which is also in my Repo.
The "Azure SQL DacpacTask" inside my release pipeline has an option for using an SQL file instead of DACPAC, but it doesn't work for me.
But no matter how I do it, my pipeline fails when running the "Azure SQL DacpacTask" and all I get, even in debug-mode is "Login failed for user '***'".
I can connect to the SQL Server through MSSQL Studio on my local machine using the admin credentials defined in my ARM template.
I've tried by adding the agent's IP before running the SQL script, but with no success.
Can anyone point me in the right direction or maybe tell me what I'm doing wrong? Why is it that it keeps failing to log in?
They want it deployed with little to no human interaction. Is it doable only through the ADO pipeline?
EDIT
Additional info:
I have tried with hardcoded password and user with no luck.
If I manually create a database and then try to deploy one via script and pipeline, it fails because a database already exists, and not because of a failed login.
I've setup Audit in Azure which generates 2 files with little to no info. I'm not sure what I'm looking at.
I have a C# dotnet core 3.1 Azure Function App (named func-utrngen-dev-001) that I'd like to configure to authenticate to a Sql Azure database via managed identity.
Steps Taken:
Created the AAD admin for sql server account
Used that account to open a connection to the sql server
Ran the following to created a "contained user" of the same name as the azure function app
CREATE USER [func-utrngen-dev-001] FROM EXTERNAL PROVIDER
ALTER ROLE db_datareader ADD MEMBER [func-utrngen-dev-001]
ALTER ROLE db_datawriter ADD MEMBER [func-utrngen-dev-001]
Ensured that "Allow Azure services and resources to access this server" is set to "Yes" from the Azure Portal under the Sql Server\Security\Firewalls and virtual networks blas
Ensured that System assigned\Status is set to "On" on the function app's Identity blade
When the function app attempts to authenticate, I get the following error:
Login failed for user '<token-identified principal>'
So I installed Microsoft's "MSI Validator" tool and ran through the steps described here.
I ran the following from the Powershell window of a Kudu session:
./msi-validator.exe test-connection -r sql -e "Data Source=sql-utrngen-dev-001.database.windows.net;Initial Catalog=utrngen;"
It successfully obtained a token but then failed with the same error as my function app:
Unable to connect to SQL. Exception : Login failed for user
'<token-identified principal>'
I ran select * FROM sys.fn_get_audit_file(path to tsql audit blob) but the results only showed activity from my account logged into SSMS
What should I try next?
The fix was to give the correct name for the database 🤦♂️. More haste less speed
I am trying to publish Azure SQL database using Azure SQL Dacpack task in Azure pipelines within an agent job. The authentication type I am using to publish is Service Principal.
I have added service principal as a contained DB user in the Azure SQL database and have given db owner permissions to service principal. When Service principal is a member of Active Directory Admin of Azure SQL Server, the deployment works fine. But , when Service principal is not a member of Active Directory Admin of Azure SQL Server , the deployment fails.
The error that I get is:
Unable to connect to target server . Please verify the connection information such as the server name, login credentials, and firewall rules for the target server. + Login failed for user '< token-identified principal>'. The Azure SQL DACPAC task failed. SqlPackage.exe exited with code 1.
Security team in my organization is not allowing me to have SP as Active Directory Admin of Azure SQL Server.
Azure SQL database only allow server admin/AD admin account to restore/backup the database. That's the permission limit and we can't change it.
Like you said, only if the service principal is a member of Active Directory Admin of Azure SQL Server, the account has the permission restore the database from .BACPAC file.
HTH.
I have an extremely simple SSIS package on my SQL Server 2017 database instance, running via an agent job. I have created a credential and proxy account to run the integration service job. If the job owner is 'sa' the job will run fine. however if I change the job owner to the service account I need to have I get the following error:
The job failed. Unable to determine if the owner (THE_FUND\xyz_svc) of job MYPITAJob has server access (reason: Could not obtain information about Windows NT group/user 'THE_FUND\xyz_svc'<c/> error code 0x5. [SQLSTATE 42000] (Error 15404)
Additionally the service account is a local admin on the server, and sysadmin in sql server in an attempt to remove possible permission issues.
I created a credential using the service account as its identity. Then created a proxy account under SSIS Package Execution referencing the credential i created.
Would love to know what I am missing.
As it turns out the issue was related to Active Directory. The service account had no registered OU. Once the service account was removed, and recreated the OU was populated and everything with the SQL Server jobs started working. I guess sometimes SQL Server is not to blame. Once SQL Server was able to find the information it needed from AD, problem solved.