Trying to get AAD and Azure SQL Authentication Working - azure

I'm trying get integrated authentication working between my app, and azure SQL. The app is running on a VM that is joined to an Azure AD domain (Domain Services) on IIS.
I have followed this official MS document on setting up auth:
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication-configure (Note - we are not using managed instances for SQL).
1) The admin group has been added via the portal
2) The contained database user (also part of the admin group) has been created, per the doc.
3) The IIS application pool is running as the same user as well.
Attempts to connect to the site return this 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
[AggregateException: One or more errors occurred.]
System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) +4323177
System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification) +12865803
System.Threading.Tasks.Task`1.get_Result() +33
System.Data.SqlClient.<>c__DisplayClass134_1.<GetFedAuthToken>b__0() +39
System.Threading.Tasks.Task`1.InnerInvoke() +121
System.Threading.Tasks.Task.Execute() +47
[AggregateException: One or more errors occurred.]
Our web.config is using this as a 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';" />
We're hoping to be able to remove any mention of plain-text passwords within our web.config, and azure authentication should be able to provide that.
Any help would be appreciated!
EDIT:
In an attempt to start fresh, I migrated the application to another fresh Azure VM. This time, the process initially lead to this error:
Unable to load adalsql.dll (Authentication=ActiveDirectoryPassword). Error code: 0x2.
After installing the .dll, it then leads me to the same error I posted above. Not sure if this initial error could shed some light on the underlying problem.

The error message is "Integrated Windows authentication supported only in federation flow"
From the portal, if you select "Azure Active Directory" and then select "Custom Domain names"
Do you have a single line on the list with "Primary" Selected?
If that is the case, you could try adding a new custom domain, mark that as federated and then use a user from that domain for the integrated authentication.

Recheck if the VM is on-premise or on-cloud because if your machine is on-prem and it is a joined AD, you should see it as a device in Azure Active Directory. Otherwise, when the machine is not integrated with ADFS, you will end up with the exception message "Integrated Windows authentication supported only in federation flow".
There are two possibles solutions:
- Integrate the machine into ADFS
- Use Active Directory Password with a valid account on Azure Active Directory.
In my scenario, I couldn't move the machine so I use an AD account.

Related

Authenticating Sharepoint 2013 on-premise with Azure AD

Our client has an Azure AD containing all users in his company located in multiple locations around the world. He would like his users to be able to sign into our SP app using their Microsoft Accounts which are on Azure AD.
Obviously, since Azure AD uses SAML 2.0, and SharePoint uses Ws-Fed (which is similar to SAML 1.1), we need to convert these claims from 2.0 to Ws-Fed (or SAML 1.1).
This used to be done using Azure's Azure Control Services, which is going to be deprecated at the end of the year (2018), so there's no point in developing a solution that uses it.
As such, we found a number of guides here and here which detail how a Claims Provider Trust can be created between Azure AD and ADFS, and a Relying Party Trust be set up between AD FS and SharePoint.
In theory this works in the following way:
User logs into his Microsoft Account which is on the Azure AD, and the SAML 2.0 token with claims is sent from Azure AD to AD FS
All claims are passed to AD FS, since we configured our rules in this way (as instructed here)
AD FS converts these from SAML 2.0 to Ws-Fed (or SAML 1.1)
AD FS maps the necessary claims to the UPN (as instructed here) and sends the result to SharePoint
We seem to be encountering an issue in the conversion step.
We have debugged the process using Fiddler, to see requests to and from the AD FS server. Azure AD claims are successfully sent to AD FS, but an error is encountered when AD FS is issue new claims (supposedly in Ws-Fed or SAML 1.1).
The following is the stack trace from AD FS:
Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, UInt32 lifetime, Uri& replyTo)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
We've also done internal testing, whereby we logged in to the SharePoint site using the the local AD, in order to make sure that the setup between AD FS and SharePoint is correct. This worked as expected, and SharePoint received the claims as configured in step 4.
Any help with the "conversion" process from SAML 2.0 to Ws-Fed (or SAML 1.1) would be greatly appreciated.
Help me Obi-Wan Kenobi, you're my only hope!
Set AD FS' PreventTokenReplays param to false
In our case, this is what had us stuck for days. There was no mention of this anywhere that we read, and we only found out about it after going to the AD FS server's event viewer and going through the logs.
Open up PowerShell, and add the AD FS snapin using the following:
Add-PSSnapin Microsoft.Adfs.PowerShell
Then, get your AD FS properties, using the following:
Get-adfsproperties
Check the value for the PreventTokenReplays param. If it's set to false, you should be good.  If it's set to true, then flip it to false using the following command:
Set-adfsproperties -PreventTokenReplays $false
Now, you'll need to restart your AD FS service. Just go to services.msc, find AD FS 2.0 Windows Service, right click it, and hit restart.
Configuration Overview
Create a new Azure AD tenant and namespace.
Add a WS-Federation identity provider.
Add SharePoint as a relying party application.
Create a rule group for claims-based authentication.
Configure the X.509 certificate.
Create a claim mapping.
Configure SharePoint for the new identity provider.
Set the permissions.
Verify the new provider
You can follow this blog for step by step process
https://www.sharepointcollabs.com/2017/03/using-microsoft-azure-active-directory.html

Can not connect to Azure SQL Server using Active directory integrated authentication in AppService

We have web application deploy on Azure App Service. Our database is also on Azure which is configured to use AAD authentication (We have assigned AAD Admin).
We are using below connection string in web app to connect to this server and database using below connections string.
Data Source=xxxxxxx.database.windows.net;Initial
Catalog=xxxxxxx;Persist Security Info=False;Authentication=Active
Directory Integrated
Please note: This connection string is working fine when using thru local system. But getting below error when we use this conn string in Azure App Service:
Failed to authenticate the user NT Authority\Anonymous Logon in Active
Directory (Authentication=ActiveDirectoryIntegrated). Error code
0x4BC; state 10 The format of the specified domain name is invalid
According to your description, I found you used the Active Directory integrated authentication.
To use integrated Windows authentication, your domain’s Active Directory must be federated with Azure Active Directory. Your client application (or a service) connecting to the database must be running on a domain-joined machine under a user’s domain credentials
If you published the web app to Azure, Azure's web app server will not be in your domain’s Active Directory. So the SQL server will not pass the auth.
I suggest you could try to use Active Directory password authentication instead of the Active Directory integrated authentication.
Replace the connection string as below use azure AD user name and password. It will work well.
Server=tcp:brandotest.database.windows.net,1433;Initial Catalog=bradnotestsql;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Authentication="Active Directory Password";
Since the accepted answers are a bit dated, if you are out here in 2020 or later, the correct way for setting up integrated authentication is as follows:
(excerpted from here, the asp.net standard implementation)
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi
add the Microsoft.Azure.Services.AppAuthentication nuget package.
modify your web.config by adding: (in configSections)
<section name="SqlAuthenticationProviders" type="System.Data.SqlClient.SqlAuthenticationProviderConfigurationSection, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
(and then)
<SqlAuthenticationProviders>
<providers>
<add name="Active Directory Interactive" type="Microsoft.Azure.Services.AppAuthentication.SqlAppAuthenticationProvider, Microsoft.Azure.Services.AppAuthentication" />
</providers>
</SqlAuthenticationProviders>
It's important to pay attention to the name you use there. Then... your connection string will look like:
<add name="MyEntities" connectionString="metadata=res://*/Data.MyDB.csdl|res://*/Data.MyDB.ssdl|res://*/Data.MyDB.msl;provider=System.Data.SqlClient;provider connection string="server=tcp:MyDB.database.windows.net;database=MyDB;UID=AnyString;Authentication=Active Directory Interactive;"" providerName="System.Data.EntityClient" />
The important notes are that the name you specify in the SqlAuthenticationProviders section must be the exact same name you use in the connection string for Authentication.
The other important note is that, coming from your old connection strings, you have to change Data Source to be Server, and Initial Catalog to be Database. UID=AnyString is necessary, or an exception is thrown.
Failure to follow these steps exactly will net you a lovely error:
System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> AdalException: The format of the specified domain name is invalid.\r\n at ADALNativeWrapper.ADALGetAccessToken(String username, IntPtr password, String stsURL, String servicePrincipalName, ValueType correlationId, String clientId, Boolean* fWindowsIntegrated, Int64& fileTime)\r\n at System.Data.SqlClient.ActiveDirectoryNativeAuthenticationProvider.<>c__DisplayClass2_0.b__0()\r\n at System.Threading.Tasks.Task`1.InnerInvoke()\r\n at System.Threading.Tasks.Task.Execute()\r\n --- End of inner exception stack trace
At the first the error doesn't make sense, but once you see that the parameters were renamed from Data Source to Server, it does make sense.
Maybe all you need to use is token (certificate) authentication as explained on below resource:
https://github.com/Microsoft/sql-server-samples/tree/master/samples/features/security/azure-active-directory-auth/token
Try to register your application with Azure Active Directory as explained on that resource.
Hope this helps.

Credentials manager for Azure Data Factory not working

Good day!
I am working on moving files via Azure Data Factory from on-prem file store and/or ftp site to Azure Blob storage using Copy Data activity. When setting security access, I am using credential manager. However, when clicking 'Set credential' a string 'Preparing...' shows for a split moment, and then nothing happens and box is left blank. What is exactly credentials manager? Is is a separate application, which needs to be installed or Windows credentials manager available via Administrative tools? I used IE for this. In Chrome it tries to install ClickOnce app, which fails to install with this error log (googling it reveals nothing). Does anyone know the solution?
IDENTITIES
Deployment Identity : CredentialsManager.application, Version=1.1.6273.1, Culture=neutral, PublicKeyToken=c3bce3770c238a49, processorArchitecture=msil
APPLICATION SUMMARY
* Online only application.
* Trust url parameter is set.
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of C:\Users\YToropov\Downloads\CredentialsManager.application resulted in exception. Following failure messages were detected:
+ Deployment and application do not have matching security zones.
COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.
WARNINGS
There were no warnings during this operation.
OPERATION PROGRESS STATUS
* [4/5/2017 5:50:08 AM] : Activation of C:\Users\YToropov\Downloads\CredentialsManager.application has started.
* [4/5/2017 5:50:08 AM] : Processing of deployment manifest has successfully completed.
* [4/5/2017 5:50:08 AM] : Installation of the application has started.
ERROR DETAILS
Following errors were detected during this operation.
* [4/5/2017 5:50:08 AM] System.Deployment.Application.InvalidDeploymentException (Zone)
- Deployment and application do not have matching security zones.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.DownloadManager.DownloadApplicationManifest(AssemblyManifest deploymentManifest, String targetDir, Uri deploymentUri, IDownloadNotification notification, DownloadOptions options, Uri& appSourceUri, String& appManifestPath)
at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState, ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp)
at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState, ActivationDescription actDesc)
at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.
You may need to clean this folder and try again by using IE11.
C:\Users{account}\AppData\Local\Apps\2.0
if it still not work, you may need to reset the internet options.
Instead of trying to use the credentials manager, can I suggest you create your data factory in Visual Studio. Then simply deploy it to Azure with different sets of configuration files.
Check out this blog post on how.
https://www.purplefrogsystems.com/paul/2017/01/using-azure-data-factory-configuration-files/
This way credentials do not need to be copied into any portal blades and can be handled using other tools. Plus source controlled.
The JSON strings will also be masked if viewed via the Author and Deploy blade.
Plus any changes can be dealt with locally and your on prem linked service in ADF just redeployed.
Hope this helps.
The credential manager is a .NET ClickOnce application running on your OnPrem machine. When using the credential manager to set the username/password, it directly talks to the Gateway so there is no username/password data transfer over the wire. If you use "by web browser" option, the encrypted username/password will be transferred over the wire with a post request and then gets pushed to Gateway. In both options credentials are encrypted, but the Credential Manages saves the roundtrip through public network.
The reason why you get this error is because Chrome by default does not support the .NET ClickOnce application. It should work if you are using IE or Edge.
For this to work on Chrome, you can add an extention to enable ClickOnce application support in Chrome, like the below one
https://chrome.google.com/webstore/detail/meta4-clickonce-launcher/jkncabbipkgbconhaajbapbhokpbgkdc?hl=en
Solution: Clear the oneClick cache and try to install the application again. Here is the way to clear oneClick cache
From command line run: rundll32 dfshim CleanOnlineAppCache
If it doesn’t work, delete the real folder:
Windows Vista/7/8/10
C:\users[username]\AppData\Local\Apps\2.0\
Windows XP/2003
C:\Documents and Settings\username\LocalSettings\Apps\2.0\
for more information, you can look at this. it may be helpful.
http://codeketchup.blogspot.sg/2013/06/how-to-fix-deployment-and-application.html
======================================================
security zone

Can not access Azure SQL database after moving Azure API app to custom domain

I moved my API from free plan app service to a basic plan app service with custom domain and SSL certificate.
1) I see that my API app's status is "running", Authentication (AAD) is working properly
2) if I open it's api definition (i.e. */swagger/docs/v1) it IS working
3) If i try a request that does not try to access backend Azure sql db, then it is working correctly
4) If I use a request that call backend Azure SQL db (it worked before moving API to custom domain) it fails with this error:
{"The underlying provider failed on Open., StackTrace: at
System.Data.Entity.Core.EntityClient.EntityConnection.Open()\r\n at
System.Data.Entity.Core.Objects.ObjectContext.EnsureConnection(Boolean
shouldMonitorTransactions)\r\n at
System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func1
func, IDbExecutionStrategy executionStrategy, Boolean
startLocalTransaction, Boolean releaseConnectionOnSuccess)\r\n at
System.Data.Entity.Core.Objects.ObjectContext.<>c__DisplayClass651.b__63()\r\n
at
System.Data.Entity.Infrastructure.DbExecutionStrategy.Execute[TResult](Func1
operation)\r\n at
System.Data.Entity.Core.Objects.ObjectContext.ExecuteStoreQueryReliably[TElement](String
commandText, String entitySetName, ExecutionOptions executionOptions,
Object[] parameters)\r\n at
System.Data.Entity.Core.Objects.ObjectContext.ExecuteStoreQuery[TElement](String
commandText, ExecutionOptions executionOptions, Object[]
parameters)\r\n at
System.Data.Entity.Internal.InternalContext.<>c__DisplayClass141.b__13()\r\n
at System.Data.Entity.Internal.LazyEnumerator1.MoveNext()\r\n at
System.Collections.Generic.List1..ctor(IEnumerable1 collection)\r\n
at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)\r\n
at
P..Repositories.DataAccessLayer.DbContexts.P..DbContext.GetP..Dtos()\r\n
at
P..Repositories.Repositories.P..Repository.P..Repository..ctor()\r\n
at P..API.Controllers.A..Controller.Get()"}]}
Only thing I've found so far suggests that my API can not access Azure SQL because of firewall rules, but that doesn't sound as an option, since I just assigned a custom domain to my app, I believe it is in the same "place" in Azure... and I did not manage so far to find any suggestions regarding Azure SQL db connections when migrating API to custom domains...
Any ideas?
It turns out, that by some strange reason, after moving to custom domain - publishing settings, AzureDatabase connection string had a non-existent (seams like "generated" name -> Api name with added postfix _db) database name. When I changed it to the real db name, everything started to work again...
P.S. I guess unchecking "use this connection string at runtime (update destination web.config)" would give the same result, since web.config holds the right connection string.

Sharepoint: COM exception thrown when navigating to the root of a new site collection

After a fresh install of WSS 3.0 and creation of a new web application and site collection, I receive the following error when I navigate to the newly create site:
[COMException (0x80070005): Access is denied.
]
System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) +557
System.DirectoryServices.DirectoryEntry.Bind() +44
System.DirectoryServices.DirectoryEntry.get_IsContainer() +42
System.DirectoryServices.ChildEnumerator..ctor(DirectoryEntry container) +36
System.DirectoryServices.DirectoryEntries.GetEnumerator() +36
Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.System.Web.IHttpModule.Init(HttpApplication app) +699
System.Web.HttpApplication.InitModulesCommon() +124
System.Web.HttpApplication.InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers) +1162
System.Web.HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context) +312
System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context) +133
System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +196
Seems to me like the application pool account does not have rights to do lookups in your Active Directory.. try running them using a domain account instead of network service.
What type of install do you choose for WSS (e.g. Standalone or Farm)?
As the installation is failing on DirectoryEntry.Bind it looks like an Active Directory issue. Is everything OK with your service accounts? Have you checked Event Viewer for any errors?
You should NEVER use Network Service as the app pool account, It is a user known only on themachine the site is ran on. Create an Active Directory user in your domain to run the app pool under. Then, in the Central Admin website under Operations -> Security Configuration -> Service Accounts set the new user for the app pool

Resources