Secure authentication between Azure Logic App and Function Apps has been possible for a while. What's less clear is whether we can automate the setup of this as part of an Azure Resource template deployment. So, that leaves us with only one option - let's find out!
Azure API Management and resource manager templates are not natural bedfellows, as I recently discovered. Although it's possible to get them working alongside each other, there is a bit of trial and error involved. That's why I thought I'd share my recent experiences working with them both.
If you are building applications leveraging Azure Active Directory, you may already be aware of the new OAuth 2.0 V2 endpoints to use when generating access tokens. And, although it requires a refactor, it’s possible to utilise them today when connecting to Dynamics 365 / the Common Data Service.
Are you considering enabling Security Defaults on your Azure Active Directory tenant? If so, you may want to think twice before flipping that button so that you can prepare for the potential disruption involved...
Application users within Dynamics 365 / the Common Data Service arguably provide a far superior option when compared to traditional service accounts with a user name and password. In today's post, we'll dive and find out more about them.
The Dynamics 365 / Common Data Service Web API allows developers to leverage a wide variety of functionality, from almost any conceivable location - such as, for example, an Azure Data Factory V2 pipeline. With this in mind, let’s dive in and see how to achieve this.
If developers cannot deploy their code locally, then there’s a significant problem here that needs addressing. That’s why, in the context of SQL Server database development, the use of a publish profile becomes almost essential, by allowing you to ignore problematic components, such as Active Directory scoped user credentials.
OAuth authentication, especially involving the Common Data Service or Dynamics 365, is a subject you may not grasp fully the first time around. The technical setup required can be tricky to understand or even implement at all, meaning you find yourself dealing with error codes such as AADSTS65001.
A few weeks ago, I did a post on the process involved when migrating Microsoft Azure Cloud Solutions Provider (CSP) subscriptions across tenants. Having done some actual work relating to this since then (shock horror!), I thought I'd follow up with a new post, sharing some additional thoughts and lessons learned.
We saw a few weeks ago how to utilise Azure Active Directory (AAD) Security Groups to manage Azure SQL database access at scale. When using this feature, you must ensure database changes are deployed out using an AAD administrator account or similar, a task which may be difficult to achieve in an Azure DevOps Pipeline.