I am automating my Azure Active Directory application.
If I look at the manifest in Azure I can see a lot more items than are available in the Terraform => azuread_application.
For example, I want to set the oauth2Permissions:
Or I want to set the accessTokenAcceptedVersion to 2 here:
But Terraform only seems to export these items:
So, the reason for this question is, what is best practice for creating an Azure AD Application Via Terraform?
Is the azuread_application one of those resource (like a azurerm_function_app) where some things are just not available to do via Terraform
Or am I expected to use Terraform in combination with a script like PowerShell?
Thanks in Advance.
some of the things are not possible with terraform, nothing you can really do about that except implementing it yourself and submitting a PR. You can use terraform in combination with powershell\az cli script to perform configurations that are not possible with it yet.
Related
I create successfully a ServicePrincipal (SP) in AzureAD and able to do a lot of stull like {Connect to Azure, Create resource, etc...}
I need my SP to use command Get-AzNetworkServiceTag but it always return empty values.
When I try command command Get-AzNetworkServiceTag with my own account I get expected result. I believe problem come from permission and your help is very welcome to set least privilege.
My current permissions looks like:
Do you know which one should I use ?
Alternative question is what is best practices to determine permissions based on powershell command ? Although permissions could name to determine there is so many that it's difficult to choose correct one. Thanks you.
The command Get-AzNetworkServiceTag essentially calls the Azure Management REST API - Service Tags - List, it is not related to Azure AD, to solve the issue, you need to assign the Azure RBAC role(not Azure AD admin role) to your service principal.
To solve the issue, the easiest way is to assign the built-in role e.g. Reader, Contributor to your service principal at the subscription scope. But if you want to the
least privilege, your option is to create a custom role then use it, you could follow the steps below.
1.Navigate to your subscription in the portal -> Access control (IAM) -> Add -> Add custom role, follow the screenshots.
Then skip the Permissions, in the JSON, click Edit, add Microsoft.Network/*/read to actions -> Next and create it.
After creating the custom role, wait for a while, navigate to the Access control (IAM) -> add the custom role to your service principal.
In conclusion, the Microsoft.Network/*/read action permission is the least privilege in this case, after giving the role, it will work fine.
Alternative question is what is best practice to determine permissions based on powershell command?
You just need to know what does the command do, then find the operation in the Azure resource provider operations, in this case, there is no such operation like Microsoft.Network/serviceTags/read, so we need to use Microsoft.Network/*/read at least.
You are facing this issue because Powershell cmdlet works differently than compared to MS Graph. Instead of permissions, Powershell require roles to do this operations. Please add Global Administrator role to your service principle and then try the Connect-AzAccount so that, the issue will be fixed.
For more details, you may refer to Assigning administrator roles in Azure Active Directory.
When I try querying extensionAttribute with Graph API (Hybrid Exchange), I cannot get any value.
E.g., if I try: https://graph.microsoft.com/v1.0/users/<userid or upn>?$select=extensionAttribute2, I cannot see the value even I know it’s there.
Do you know how to get it properly (or a workaround)?
Thank you
Are these values synced to Azure Active Directory? All properties for the AAD User can be found in the Microsoft Graph API docs here : https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0
It sounds like these are being synced from an AAD Connect environment, so it's most likely you are trying to get the onPremisesExtensionAttributes.
Per the description:
Contains extensionAttributes 1-15 for the user. Note that the individual extension attributes are neither selectable nor filterable. For an onPremisesSyncEnabled user, this set of properties is mastered on-premises and is read-only. For a cloud-only user (where onPremisesSyncEnabled is false), these properties may be set during creation or update.
I suggest taking a look more thoroughly through the documentation in regards to this. In addition to that, as you mentioned Exchange, note that the custom attributes from exchange are the same as the extension attributes. For more info on this see : https://github.com/microsoftgraph/microsoft-graph-docs/issues/5950
This is a separate sort of "Extension Attribute" but I figured I would include this in the answer as well. There is a different extensibility section for the Microsoft Graph, and the docs on this can be found here : https://learn.microsoft.com/en-us/graph/extensibility-overview
If you see information on these extensions, know that this is separate from the on-prem extensions.
I have a script which (among many other things) creates a service principal in our corp AAD instance. Since I've collected a good number of service principals during my time here, it would be nice to distinguish them visually using a photo. Is there any way to do this via script? I've found Set-AzureADUserThumbnailPhoto but it doesn't seem to work for AAD applications.
You are looking for Set-AzureADApplicationLogo, when you use it set the logo of the AD App(app registration), its service principal(enterprise application) logo will also change.
Set-AzureADApplicationLogo -ObjectId <app-objectid> -FilePath C:\Users\joyw\Desktop\pic.jpg
I’m seeing some inconsistent behavior between two different subscriptions when trying to create an Indexer for an Azure Search service through the Azure Portal.
I was able to successfully build the indexers in our test/ppe subscription (Microsoft) using a Cosmos DB collection as a source and the data was matched 1:1 using Edm.ComplexType and Collection(Edm.ComplexType):
Complex Types showing up in dropdown
After I verified things were working as expected, I moved to our prod subscription (AME.GBL) to do the same; however, this ability to add/edit complex types seems to be missing:
Complex Types not showing up in dropdown
Is there a reason why this ability to add complex types is available in one of our subscriptions but not the other?
Is there a feature gate in place for this ability to add/edit Complex types for an index and if there is, would it be possibly to manually override it for a given subscription ID?
Thank you!
Bradley - You are correct that in this case the Complex Type detection feature via the portal 'Import Data' workflow is currently only available via the internal Microsoft portal experience. However, this feature will be deployed publicly world-wide very soon and we are targeting 5/1/2019 for global availability via the portal. If you need to create this index with Complex Types beforehand you can use the API to set the index schema with the complex types directly.
I have a project requirement where I need to authenticate against ActiveDirectory in a remote/disconnected WPF application.
There is probably several ways to attempt to do this, but what would be the best approach using ActiveDirectory's MembershipProvider?
I need to:
Authenticate that the user exists.
obtain the AD user's groups and roles.
This needs to happen from a remote location, outside of the network Active Directory resides on.
From within a WinForms or WPF application you can now take advantage of "Client Application Services" (thanks MS for a very generic name, searching for help is now very painful!).
This allows you to connect to a WCF service that can validate the logins. The link above has a walkthrough that shows how easy it is to get it all working, once you have a working app you can modify your config to point to a different MembershipProvider and/or RoleProvider.
It's worth noting that the out-of-the-box solution includes a MembershipProvider named ActiveDirectoryMembershipProvider, but there's no RoleProvider for Active Directory.
If you do require the ability to get Roles (or Groups) and you are working with .NET 4.0 then you can take advantage of the new Active Directory API added that makes everything much easier, namely System.DirectoryServices.AccountManagement. For the most basic of Membership and Role services you'll want to have the following to create your own basic MembershipProvider and RoleProvider:
MembershipProvider.ValidateUser() - should use PrincipalContext.ValidateCredentials()
RoleProvider.GetAllRoles() - use a new GroupPrincipal() as a source to a new PrincipalSearcher()
RoleProvider.IsUserInrole() - use UserPrincipal.FindByIdentity() method to get a user, use GroupPrincipal.FindByIdentity() to get the group, then use the IsMemberOf() method on the user to see if they're a member of the group.
You can implement as little or as much of the API as needed, you should find everything you need in the new AccountManagement namespace to do this.