I tried Generic type service connection, which seems to support only basic authentication (username/password).
Appreciate any guidance!!
Service Connection Screenshot
We don't currently support MFA with the connector.
You could take a look at official doc here-- Manage Conditional Access to Azure DevOps
Azure DevOps enforces the policy for usage of personal access tokens
(PATs), alternate authentication, OAuth, and SSH keys.
For third-party client flow, like using a PAT with git.exe, we only
support IP fencing policies - we don't support MFA policies.
Related
i am implementing CI/CD pipeline that needs to register an AAD Application with permissions to read/write into Site collections, this would mean that the pipeline itself need to have permission to 'Sites.FullControl.All'. I want to understand from the security perspective, if this is desirable, i.e., a pipeline having FullControl access to a SharePoint tenant. What are the recommended practices w.r.t. this, will the application registration in such scenarios be manually done by Ops team?
According to your description, it seems that you want to use the service connection in the Azure CI/CD pipeline.
We can create a service connection with Service principal (automatic) or Service principal (manual).
Use the following parameters to define and secure a connection to a Microsoft Azure subscription using Service Principal Authentication (SPA) or an Azure managed Service Identity.
Automated subscription detection. In this mode, Azure Pipelines
queries Azure for all of the subscriptions and instances to which you
have access. They use the credentials you're currently signed in with
in Azure Pipelines (including Microsoft accounts and School or Work
accounts).
If you don't see the subscription you want to use, sign out of Azure Pipelines and sign in again using the appropriate account credentials.
Manual subscription pipeline. In this mode, you must specify the
service principal you want to use to connect to Azure. The service
principal specifies the resources and the access levels that are
available over the connection.
For more information, you could refer to Azure Resource Manager service connection.
I have an Azure DevOps server on-premises and I have written a small application that simply queries its API to get information from the Azure server. There is no authentication at the user level, since the application only displays information and does not POST/PUT/DELETE.
To query the API, I have used my PAT (personal access token), but this is not ideal. I have read that on the cloud version of Azure, you can just register the application to do it, but I have not found the same functionality for the on-premises version.
Am I missing something? Is the only alternative creating a technical user on the LDAP and get a PAT for it?
Is the only alternative creating a technical user on the LDAP and get
a PAT for it?
Yes, you are right.
Authorize access to REST APIs with OAuth 2.0
So 'App auth' is only supported in Azure DevOps Services (VSTS), not supported in Azure DevOps server (TFS).
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
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.
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.