Azure Active Directory has the nice concept of applications and service principals to authenticate as an application e. g. for a CI platform or SaaS application.
Now there are multiple ways to create those like using MSOL with the cmdlet:
New-MsolServicePrincipal -DisplayName "My new API app" -Type password -Value $myClientSecret
This works perfectly fine (after I assign some roles to the service principal using Add-MsolRoleMember, I can access the Graph API). But I still have some questions:
Why does this cmdlet doesn't require to create the application first?
Does this cmdlet create both - an application and a service principal?
Why I don't see the application neither in the classic nor the new azure portal?
And maybe someone can answer me a fourth question: What is the difference between the above MSOL cmdlets and New-AzureRmADApplication + New-AzureRmADServicePrincipal cmdlet? When should I use which of them?
The ARM cmdlets and the new Azure AD v2 cmdlets both use the Azure AD Graph API.
However, New-MsolServicePrincipal does not. It calls out to https://provisioningapi.microsoftonline.com/provisioningwebservice.svc using SOAP. It is a legacy API and you should not be using it.
A service principal must always have an appId, that is the client id of the Application from which it was created.
The field appOwnerTenantId identifies from what tenant the app came from. It can be null. This is the case for MS internal applications like the Graph API, Azure Portals etc. But also service principals created with New-MsolServicePrincipal, and leaving out the appId.
So the answer to question 1 and 2 is: an Application is automatically created if none is specified. But I am not sure where it is created, as it is not available through the Graph API. It is a pure service identity. And the appId is different each time, so it is not just using some placeholder app.
As for question 3: the reason you don't see the Application in the portal is because it is not available through the Graph API, it is hidden somewhere. As for the Service Principal, a very specific magic tag is required for the principal to show up in the Enterprise Applications list. And AFAIK, you can't specify it with New-MsolServicePrincipal or New-AzureRmADServicePrincipal.
The answer to your fourth question is that the MSOL cmdlets use a legacy API, whereas the two newer options use the Azure AD Graph API. And the ARM cmdlets create an application that you can see in the Portal. They still create one you can't see in the Enterprise Applications list.
The behaviour of the different cmdlets differs when it comes to creating service principals without an app though:
New-MsolServicePrincipal: Creates the principal with some kind of hidden app, similar to MS internal apps (also sets servicePrincipalType=Legacy)
New-AzureRmADServicePrincipal: Creates an application for you and then creates the service principal (the app is visible in Portal, but the principal is only visible through the app's blade, because of missing tag)
New-AzureADServicePrincipal: Does not allow you to create it without providing an appId
If you want the principal to show up in the Enterprise Applications list as if you created it through the portal, you can provide the tag necessary with the v2 cmdlet:
New-AzureADServicePrincipal -Tags #("WindowsAzureActiveDirectoryIntegratedApp") -AppId ed5fa582-3991-4114-87da-30081c4105fb
The new v2 cmdlets are the best in my opinion, at least they allow you to create a service principal in a manner similar to what the Portal does. The ARM cmdlets are fine if your purpose is to create a service identity for using RBAC in the ARM API, as the principal is visible for that.
1 and 2 - probably it is using existing office 365 application in the tenant (I believe it is hidden)?
3 - Since you created a service principal, you need to look at enterprise applications in the Azure portal to see the service principals objects in your tenant (rather than the applications tab).
4 - this link
Application object
An Azure AD application is defined by its one and only application object, which resides in the Azure AD tenant where the application was registered, known as the application's "home" tenant. The application object provides identity-related information for an application, and is the template from which its corresponding service principal object(s) are derived for use at run-time.
Consider the application object as the global representation of your application (for use across all tenants), and the service principal as the local representation (for use in a specific tenant). The Azure AD Graph Application entity defines the schema for an application object. An application object therefore has a 1:1 relationship with the software application, and a 1:n relationship with its corresponding n service principal object(s).
Service principal object
The service principal object defines the policy and permissions for an application, providing the basis for a security principal to represent the application when accessing resources at run-time. The Azure AD Graph ServicePrincipal entity defines the schema for a service principal object.
Before an Azure AD tenant will allow an application to access the resources it is securing, a service principal must be created in the given tenant. The service principal provides the basis for Azure AD to secure the application's access to resources owned by users from that tenant. A single-tenant application will have only one service principal (in its home tenant). A multi-tenant Web application will also have a service principal in each tenant where an administrator or user(s) from that tenant have given consent, allowing it to access their resources. Following consent, the service principal object will be consulted for future authorization requests.
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'm wondering if there is a way to tell whether a given application retrieved via command Get-MgApplication is an App Registration or an Enterprise App.
Get-MgApplication is the cmdlet for App Registrations
Get-MgServicePrincipal is the cmdlet for Enterprise Applications
Microsoft generally refers to App Registrations as applications/application objects, and refers to Enterprise Applications as service principals/service principal objects. This is reflected in the cmdlet naming
See Application and service principal objects in Azure Active Directory
I'm trying to create a release pipeline in Azure DevOps. I created an App service resource in Azure and I want to deploy my web-app to this App service through my pipeline. For that I need to create an ARM service connection. Can you please help me with understanding the difference between the types of service connections? Thanks!
What is the difference between Service Principal (automatic) and Service Principal (manual) ?
What is the difference between service principal, managed identity and publish profile?
What is the difference between Service Principal (automatic) and Service Principal (manual) ?
Service Principal (automatic): It will create an AD App along with the service principal in Azure AD for you automatically and use it in the service connection.
Service Principal (manual): You need to create the AD App along with the service principal manually in Azure AD and configure it when you create the service connection.
What is the difference between service principal, managed identity and publish profile?
When you create an AD App(App Registration) in Azure AD, it will create a service principal for you automatically in your Azure AD.
The managed identity is essentially a service principal in your AAD managed by Azure, you can use it to access azure resources in the subscription.
The publish profile is a file used to publish your web app or web job, it includes a username and password, it uses the basic auth to deploy your web app, if you use service principal/managed identity, it uses Azure AD auth.
I created a KeyVault in my Azure subscription and a client application in one of my Azure AD directories. However, the client application is not registered in the default directory of the subscription.
When I run the following PowerShell cmdlet, it tries to look up the service principal in the default directory of the subscription and fails to find it.
PS > Set-AzureKeyVaultAccessPolicy -VaultName <vaultname>
-ServicePrincipalName <principal guid> -PermissionsToSecrets Get
I found an article describing how to change the default directory for a subscription in the management portal, but was wondering how to do the same using PowerShell.
The 'Select-AzureSubscription' cmdlet does not seem to support changing the default directory.
Nor does the 'Set-AzureKeyVaultAccessPolicy' support a parameter to indicate in which directory it should look.
Key Vault can only authorize applications (clients) registered in the directory associated with the Azure subscription, and the only way (currently) to change the 'home' directory associated with a subscription is through the Azure management portal.
I would imagine this is as designed behaviour, and can't imagine how / why it would change.
An Azure subscription has an Azure Active Directory attached to it, this is the directory it will use to authenticate against whenever someone tries to access resources.
While you can create trusts to other Active Directories simply creating an new AAD does not automatically enable that domain to be trusted by Azure.
Key Vault is designed to only be accessible to authenticated users, it is designed to provide secure data to those users. Since there is no authentication mechanism between the multiple directories you have created, there is no mechanism for Key Vault to determine who those directories belong to.
Key Vault needs to resolve a service principle through the Active Directory attached to the subscription it is running under (whether that is directly through that directory, or through another domain that it trusts). Anything else would create additional attack vectors and considerably weaken the product.
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.