I am creating a logic app that will trigger when a form request is submitted.
The MS Form connector requires me to sign in. This is acceptable during development, but we have a lot of logic apps and so use DevOps to automate deployment.
With the current connector, after deployment we still have to:
manually open the logic app in the portal.
connect using authorized credentials.
save the logic app.
This manual process completely defeats the point of using DevOps with Logic Apps.
Its a similar issue when using the Outlook connector.
Is there a way to supply server principal credentials to these connectors, so that they are correct at deployment time and require no manual intervention?
It seems that it's not supported to login on MS Forms connector with service principal. Connectors that can use service principal authentication will have "Connect with Service Principal" option, like Azure Data explorer. You can give your voice on this feedback to promote this feature.
API Connections with OAuth authentication, like Office 365 and Microsoft Team connectors etc, require manual consent. Unfortunately, at this point in time, authentication for those cannot be fully automated.
Here is a ticket you can refer to.
Related
I am junior admin managing ADO 2020 on Prem . We have a developer who is able to create a work item in a board under a collection/project when logged in using ADO .
The developer is trying to automate work item creation using Power Automate . He is giving the correct information in Power Automate at the required fields. When trying to create a work item, he gets this error
Details: {"$id":"1","innerException":null,"message":"TF400813: The user '157adfsd-912f-4244-xxxx-b45fcasda\\firstname.lastname#domainname.com' is not authorized to access this resource.","typeName":"Microsoft.TeamFoundation.Framework.Server.UnauthorizedRequestException, Microsoft.TeamFoundation.Framework.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=acdb03fxxxxxxsdfdsdse","typeKey":"UnauthorizedRequestException","errorCode":0,"eventId":3000}
Question : From ADO 2020 side, is there any kind of permission I need to provide to the developer ? I am not 100 % sure why we get this error as the developer is manually able to create a work item.
To my understanding, Power Automate connects to Azure DevOps Services (that is, the cloud-hosted version of Azure DevOps) via OAuth, and when you are creating Power Automate flow for Azure DevOps, the tool tip when selecting an organization tells you to make sure that the Third Party application access via OAuth is enabled.
I don't think that the OAuth 2.0 authentication (https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops) is available for the on-premises version, so you might be out of luck there.
There is an answer to similar question in Power Automate-forum suggesting that the integration might be possible via installing an on-prem data gateway, but wouldn't really know if it's feasible.
https://powerusers.microsoft.com/t5/Connecting-To-Data/Power-Automate-with-Azure-Devops-Server-On-Premise/td-p/658618
I'm wondering what is the correct way to grant service accounts access to AzureDevOps. Ex: access to source code, API's, etc.
Since "Basic Authentication" was deactivated, I've been using personal access tokens but it seems awkward to login using a service account, generating the PAT, and so on. Also, since they are limited in time, we have to ensure renewal schedules/reminders for each connexions.
I am on the wrong track? Is there a more "natural" way to do it? Is SSH more adapted for this?
I've found this guide which helps but I can't find how (for example) granting a third-party application access to a project's repository.
https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/authentication-guidance?view=azure-devops
PS: Service Connections and Service Hooks are not what I'm looking for.
What you are looking for probably is OAuth 2.0 Client Credentials Flow for Azure DevOps. Unfortunately Client Credentials Flow is not yet supported on Azure DevOps. See this thread Client Credentials Flow for Azure DevOps.
But, You can check out OAuth 2.0 auth code flow,which is now supported on Azure Devops. Please check out this detailed tutorial Authorize access to REST APIs with OAuth 2.0. This is an example to implement OAuth 2.0 auth code flow.
There are also Codes samples provided in above web link you mentioned in the question. You can checkout these samples to learn their authentication mechanism, and choose one that suits you most.
I am starting to work with Dynamics 365 Portal add-on (Online, not on-prem), which I've configured to use an external authentication provider in the form of Identity Server with OpenId Connect. The problem with this is that I don't have access to the under-the-hood portal authentication process, there's just a few basic config settings and users can authenticate using the external IdP. I can't access roles, claims, or any custom info that might come back as part of the OpenId Connect user's profile (userinfo object response). I need to get at that data to customize the portal user experience. I've looked through whatever documentation I could find on the portal but can't find anything. Am I missing something or is it just not possible to access that info and customize the portal login process? Since it doesn't seem possible to do anything server-side within the portal because it's Online, can I do anything client-side within the portal to get the OpenID access token and call the UserInfo endpoint with that?
I had a case open with Microsoft and finally got an answer from them: In Dynamics CRM Online with the Online Portal add-on, there is currently no way to access anything coming back from an external identity provider. So for example, if you've configured the portal to use an external identity provider such Google, Facebook, etc, or like in my case an Identity Server instance with OpenId Connect, you can't access the claims or any other info coming back from the provider.
UPDATE:
I got another response from Microsoft support: they have confirmed their dev teams are working on making this available but don't have an ETA yet. At least it's on their radar.
After implementing the integration of Azure Active Directory and some other could applications like Salesforce, and syncing On-Premise Active Directory data by using Azure AD Connect, now I could auto login Salesforce and other cloud apps with Single Sign-On by using the credentials I used for desktop logon, but I still need to key in the credentials once when accessing Azure Applications page (Azure Portal).
Is there any configuration in Azure I can change to support auto-login by using the Windows credentials, so that once I log into my encrypted machine, I could auto login the Azure Applications page (the Azure portal) without key in password again? If Azure does not support no sign-on, what's the best way to do some development to support no sign-on?
Any post or suggestion will be appreciated!
You can always try to authorize users using Graph API. Maybe this will be helpfully: https://github.com/devkimchi/Graph-API-App-Only-Web-API-Sample
I had a similar issue when using ADFS for federated identity and the following article helped, not sure if it applies to Azure AD Connect but it might give you some useful info.
https://support.microsoft.com/en-us/kb/2535227
Thanks thedev and dawidr for your reply.
Finally I found a solution which might achieve the No Sign-On. AAD supports federation authentication, so just try to integrate the ADFS and AAD by using Azure AD Connect to implement the federation identify with On-Premise AD, then no more password key-in when accessing the Azure Applications. I don't have a proxy server with public IP so it's just a solution in my mind without verification.
I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.