I've been trying to get to through this issue for some time now, and unfortunately, I'm hitting a wall.
We have Azure AD configured with Azure Domain Services. VM's are joined to this domain. We also have Azure SQL Database that we're attempting to connect to from the IIS application running on the VM.
I've followed the official MS docs on this (https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication-configure) that helped verify Azure AD identities can connect to the Azure SQL DB (I can connect via SSMS to Azure SQL using an Azure AD Admin user. I can then use that ID to generate other contained users, which I have done).
The problem exists when I attempt to authenticate with the database with Active Directory Integration in my connection string. I get two errors, which i'm going to include below.
Now, I have not been able to get past the last one (stating that federation is needed), and in fact, have read numerous things (albeit nothing directly from MS) that says this is simply not supported and that I need to create a federation to get this working, which just seems completely unreasonable given that this is an Azure-only environment.
Connection string included below as well.
I've tried various iterations of that connection string to no avail. If anyone can provide some insight into this, I'd appreciate it greatly!
One last thing, the IIS application pool is running as a user that is both part of the AAD Domain group on Azure AD, and a contained user created on the DB.
Thanks!
I've tried various iterations of the connection string that include removing much of the additional params on the connection string, and the quotes.
I've tried different users on the application pool
End goal is to remove all plain-text PW's from appearing within the connection string to Azure SQL.
First error:
Unable to load adalsql.dll (Authentication=ActiveDirectoryPassword). Error code: 0x2.
Second Error:
[AdalException: Integrated Windows authentication supported only in federation flow.]
ADALNativeWrapper.ADALGetAccessToken(String username, IntPtr password, String stsURL, String servicePrincipalName, ValueType correlationId, String clientId, Boolean* fWindowsIntegrated, Int64& fileTime) +829
System.Data.SqlClient.<>c__DisplayClass2_0.<AcquireTokenAsync>b__0() +132
System.Threading.Tasks.Task`1.InnerInvoke() +121
System.Threading.Tasks.Task.Execute() +47
Connection String:
name="LocalSqlServer" connectionString="Server=tcp:XXXXX;Initial Catalog=XXXXX;Persist Security Info=False;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Authentication='Active Directory Integrated';" />
Related
I'm attempting to query a remote machine with the PowerShell cmdlet: Get-WmiObject and using credentials for a user in Azure AD that has the Azure AD joined device local administrator role and the IAM role assignment of Virtual Machine Administrator Login on the remote machine.
When I run the following command:
Get-WmiObject -Class Win32_Process -Namespace "root/cimv2" -ComputerName <remote_computer_local_ip> -Impersonation Impersonate -Credential AzureAD\<username>
I receive the following error message:
Get-WmiObject : A security package specific error occurred. (Exception from HRESULT: 0x80070721)
Is the ability to run remote WMI queries supported when using an Azure AD user?
Remote machine specs:
Windows Server 2019 Datacenter
10.0.17763 Build 17763
Other troubleshooting notes:
I'm able to sign to the remote machine with the same user and have followed the steps in the https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-vm-sign-in-azure-ad-windows document
When running the same command on the remote machine locally it properly returns the Win32_Process data
If I use the local administrator credentials on the remote command it also works which suggests that remote WMI is working
Both computers are Azure AD joined and show AzureAdJoined : YES from the dsregcmd /status command
I've attempted to use the Computer Name, Local IP, and FQDN and they all yield the same result
After talking with Microsoft support about this issue, it seems that the error stems from the different authentication methods between a local user account and an Azure AD account.
It seems it is not supported as they are using different authentication protocols.
Azure AD user uses OAuth and the security error is due to Kerberos.
Here is the reference article for more details: Authentication protocols in Azure Active Directory B2C | Microsoft Docs
They have also mentioned that there is no current information on whether or not this will be supported in the future and have recommend checking Azure updates for future product updates.
It could happen for number of reasons. Please check if any of these in your case is the one.
When You try to setup a WMI session when:
a. There are more than one computer accounts with the same name in play and one of those stale computer accounts resides in the same domain as your user account
b. Or when servers operating reside in the same AD DS forest but in different domains.
When server is not able to find the user object due to password credentials that may be stored as cache from previous login.
Incorrect time on machines/server that doesn’t match.
If firewalls are enabled for server which may restrict the access.
possible work arounds
Try azuread\user#mydomain.com or user#mydomain.com or domainame\username format to login or Try taking out the domain and adding it back again.
The local PC and remote PC must be in the same Azure AD tenant.
Run AAD delta Sync to make sure everything is Synced and make sure of internet connectivity and network.
Try if you can turn off firewall.
References:
remote access - AAD- Server Fault
rdp -Azure AD Joined - Server Fault
«0x80070721 | exchange12rocks.org)
A security package specific error occurred | Microsoft Docs
I have configured my WebAPI to get Azure Storage connection string out of Azure KeyVault using Managed Identity.
For that, I have created an Azure AD dedicated user, which is given permission to get/list secrets from Azure KeyVault. I then assigned this user to my AZURE_USERNAME environment variable and I have configured Visual Studio to use this account.
It all works fine as long as I run the WebAPI in IIS Express when I debug from Visual Studio. However I want to run the WebApi from my local IIS when I debug in Visuall Studio.
What am I missing here ? I suspect it is because local IIS does not run with the configured user above, but what would be the workaround ?
The error I get is
AzureServiceTokenProviderException: Parameters: Connection String: [No connection string specified], Resource: https://vault.azure.net, Authority: https://login.windows.net/some_id. Exception Message: Tried the following 3 methods to get an access token, but none of them worked.
In the end I created a dedicated service principal in azure ad which is then added to my applications's users. This service principal is referenced by the environment variable on the dev machine.
I have made progress on this and it is now working in local IIS but...
to make it work, I added the following environment variables:
as documented here
However it means this only works for ONE Service Principal at a time. What if I want all of my local WebApi running at the same time (which is the case) in the local IIS. How can I handle that with DefaultAzureCredential ?
Another solution is to create an AzureServiceTokenProvider instance by passing a connection string parameter that will specify the tenant and application secret.
var azureServiceTokenProvider = new AzureServiceTokenProvider("RunAs=App;AppId=2ad1fe1f-d93f-4973-a1e5-e7019638b90a;TenantId=your-tenant-here.onmicrosoft.com;AppKey=your-app-secret-here");
In such a way there is no more need to use the environment variables.
Check it here
I have successfully setup a Linked Service in Azure Data Factory that uses a Key Vault for the connection string which includes the user/pwd and connects to the Azure SQL DB as desired. However, I can only do this when I use the "admin" account. The string below works.
Server=tcp:database1.database.windows.net,1433;Initial Catalog=DB;Persist Security Info=False;User ID=Admin;Password=Pa$$w0rd;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
I created a new login/user and granted the necessary permissions. I know because I can connect using the new login via remote SSMS or by adding the credentials directly in the linked service in Azure. (e.g. hard coding the user/pwd in the connection string in the linked service)
Unfortunately, when I switch to using the key vault connection string, I get the generic SQLErrorNumber 18456 for the newly created user. I know the credentials are correct, I know I can connect via the Key Vault (when using the elevated admin account), I just cannot use the Key Vault connection string when using the new user.
Server=tcp:database1.database.windows.net,1433;Initial Catalog=DB;Persist Security Info=False;User ID=Username;Password=Pa$$w0rd;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
If using Azure SQL with Data Factory look at using Managed Service Identity That way you'd add the name of the Data Factory directly to the SQL DB and no need for a username and password. Plus can assign permissions directly on the user.
Only downside is if DataFactory get's wiped out and redeployed the user will need to be dropped and recreated since it is using a thumbprint to recognize the Identity, this isn't the case with all resources and MSI auth.
For your specific case check to make sure the SQL server is allowing Azure Services and resource to Access the sever by going to "Firewalls and virtual networks" and make sure it is turned on:
We have a Key Vault in a resource group in an Azure instant.
We have a user in the US (ME) and a user in different country (FU).
Both of use have many things in common, namely:
Using same version of VS 2017.
Running the exact same code.
Our VS user account is the same (a user in our Azure AD instance).
We are using a Managed Identity
If I run the code in US (logged in in VS as the FU), I am able to read the secret and display on the screen.
If the FU(logged in in VS as the FU but in another country), when he runs the code it throws the following exception
Operation returned an invalid status code 'Unauthorized'
The line of code that throws the error is:
var secret = await keyVaultClient.GetSecretAsync("https://XXXXXXX.vault.azure.net/secrets/username")
.ConfigureAwait(false);
We have both installed Azure CLI 2.0.
However, I found these stipulations at this site.
Your on-premise active directory is synced with Azure AD.
You are running this code on a domain joined machine.
Neither of these are true in our case.
Possibly a good test of these would for our vendor to allow me to remote into his machine and put my identity on VS and then run the code.
If we still get the error, then it is very likely this is our problem.
The above link said we could "Run the application using a service principal in local development environment"
Would that fix the problem???
I am fairly new to Azure and C#. Any help would be greatly appreciated!
I'm sitting in a project where I will move from TFS to VSTS so we do have a working release definition.
But when I try deploying a service fabric cluster i get the following error:
2018-08-28T09:02:59.8922249Z ##[error]An error occurred attempting to acquire an Azure Active Directory token. Ensure that your service endpoint is configured properly with valid credentials. Error message: Exception calling "AcquireToken" with "3" argument(s): "AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access '< service principle Id >'.
Trace ID: < guid1 is here >
Correlation ID: < guid2 is here >
Then I go to the azure portal -> AAD -> Sign In -> look up my specific sign in (based on correlation Id) and there it state that Sign-in status is Success
Considering this works for our TFS instance i assume the service principle is correctly set up. But since the build/deploy agents is now on a VM in azure instead of on prem for TFS, is there anything i need to change?
Traffic should be OK, i can navigate to the https-adress to the cluster from the VM with agents.
I've tried google it, but to no success so hopefully someone can point me to the right direction where to look.
And in portal, 'MFA is required' is no, so multi factor should not be neccesary.
Just try using certificate based authentication instead of using AAD Authentication in the service endpoint configuration.
Reference the same issue here: https://github.com/Microsoft/vsts-tasks/issues/7714
If that still not work, just try to create a new endpoint, then try it again.