In this blog post I will go through the process of installing the Azure Terraform plugin within Visual Studio Code.
The VSCode Azure Terraform extension is designed to increase developer productivity authoring, testing and using Terraform with Azure. The extension provides terraform command support, resource graph visualization and CloudShell integration inside VSCode. For more information visit the following link, Azure Terraform Extension
Launch Visual Studio Code
Click the extensions icon as shown in the screenshot below
3. Type Terraform in the search box and take a look at the various plugins available.
For now, I’ll only be installing extensions Azure Terraform and Syntax highlighting and autocompleting . You can also use keys Ctrl Shift and X to access the extensions area within Visual Studio Code
4. Allow the installs to complete
5. To verify the installations, type @installed in the search box as shown below.
Incase you’re wondering why the Azure Account extension was installed. When installing the Azure Terraform extension, Visual Studio Code will automatically install the Azure Account extension. Azure Account is a dependency file for the Azure Terraform extension, which it uses to perform Azure subscription authentications and Azure related code extensions.
Stay tuned for part 5 where I will go through the process of installing Git on my Windows device and enable in Visual Studio Code. I will also be setting up a GitHub account.
Git vs GitHub
– Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git will allow you create a local repository on your device and manage versions of your files. It runs locally but if required you could clone your local version to the GitHub repository. More info at Git
– GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere. More info at GitHub
Moving to Part 3, in this post I will go through the process of installing Visual Studio Code. Let’s get started.
What is Visual Studio Code? Visual Studio Code combines the simplicity of a source code editor with powerful developer tooling, like IntelliSense code completion and debugging. First and foremost, it is an editor that gets out of your way. The delightfully frictionless edit-build-debug cycle means less time fiddling with your environment, and more time executing on your ideas. For more information on Visual Studio Code click the following link Microsoft.
Following on from a previous post where I installed and configured Terraform, see How to Install Terraform, in this post I will continue my journey learning Terraform by going through the process of installing a useful tool known Azure command-line interface (Azure CLI).
The Azure command-line interface (Azure CLI) is a set of commands used to create and manage Azure resources. The Azure CLI is available across Azure services and is designed to get you working quickly with Azure, with an emphasis on automation. It’s a useful tool to have installed on my machine so let’s get started.
In this blog post I will go through the process of enabling a user sign-in and user risk policy within Azure Identity Protection located within the Azure Portal.
Risk detections in Azure AD Identity Protection include any identified suspicious actions related to user accounts in the directory.
User risk policy With the user risk policy turned on, Azure Active Directory detects the probability that a user account has been compromised. As an administrator, you can configure a user risk conditional access policy to automatically respond to a specific user risk level. For example, you can block access to your resources or require a password change to get a user account back into a clean state.
Identity Protection categorises risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, Microsoft say that each level brings higher confidence that the user or sign-in is compromised. For example, something like one instance of unfamiliar sign-in properties for a user might not be as threatening as leaked credentials for another user.
User sign-in policy Turning on the sign-in risk policy ensures that suspicious sign-ins are challenged for multi-factor authentication (MFA). Note that if MFA is not enabled for the user, access will be blocked.
Note: to make use of these features every user that benefits or is affected from a feature exclusive to the Azure AD P2 offerings needs a Azure AD P2 licence or a licence including Azure AD P2, for example 365 E5 – Source: Microsoft
Login to your Azure Portal (portal.azure.com
Search and click Azure AD Identity Protection
3. Below is a screenshot displaying both user risk policy and sign-in risk policies We’ll start with user risk policy
4. Click user risk policy and below are the parameters available
5. Click all users and below I can apply this policy to all users or target individuals or groups.
I can also exclude users or groups as shown in the screenshot below
Note: exclusions over ride inclusions, so if a user is in two groups, one excluded and the other included, the excluded will policy will take priority.
For the purpose of this demo, I will be leaving the default of all users
6. Next, move onto user risk which assesses the likelihood that the user account is compromised.
7. The below risks (High, Medium and above, low and above) are based on a Microsoft Algorithm. While Microsoft does not provide specific details about how risk is calculated, they say that each level brings higher confidence that the user or sign-in is compromised. For example, something like one instance of unfamiliar sign-in properties for a user might not be as threatening as leaked credentials for another user. For common questions, visit the following Microsoft article – Common Questions
I’ll be setting the user risk as High so I’m going to be looking for something that has been flagged as a high risk which means there is an account which has highly likely been compromised. Click Done
8. Next, I move onto Access located under Controls
9. Here is where we configure the action if the condition is met. For the purpose of this demo, I will click Allow access but will force the user to change the password. You could also block the user when a high risk is identified. Click done
10. Select On and click save
11. That’s the user risk policy set
Let’s move onto Sign-in Risk Policy
Click Sign-in risk policy
2. I’ll be leaving the default setting to apply the policy to all users
3. Next I click on Sign-in risk which is based on the likelihood that the sign-in is coming from someone else other than the user.
4. I set this to high and click done
5. Click access located under Controls
6. I click allow but the user will be forced to perform multi-factor authentication, click done
Note: If multi-factor is not configured for the user, the user will be blocked
7. Finally, I turn on the policy and click save
That’s both policies configured
To view risk alerts, click the options located under Report in the menu located towards the left.
Further down the menu, we have notify on users at risk detected alerts and weekly digest. Users in the Global administrator, Security administrator, or Security reader roles are automatically added to this list if that user has a valid email or alternate email configured. Microsoft attempt to send emails to the first 20 members of each role. If a user is enrolled in PIM to elevate to one of these roles on demand then they will only receive emails if they are elevated at the time the email is sent.
By default admins are alerted based on high risk alerts as shown below
In this blog post I will go through the process of preventing users in your organisation from allowing third party apps to access their Office 365 information, and require future consent operations to be performed by an administrator.
This is a recommended Microsoft action and you may come across an alert within the secure score section of your Azure Portal. The message is as follows:
Tighten the security of your services by regulating the access of third-party integrated apps. Only allow access to necessary apps that support robust security controls. Third-party applications are not created by Microsoft, so there is a possibility they could be used for malicious purposes like exfiltrating data from your tenancy. Attackers can maintain persistent access to your services through these integrated apps, without relying on compromised accounts. Policy in place: false.
Login to your Azure Portal (portal.azure.com)
Locate and click Azure Active Directory
Click Enterprise applications
4. Click User Settings
5. Switch Users can consent to apps accessing company data on their behalf to No
Users can consent to apps accessing company data on their behalf If this option is set to yes, then users may consent to allow applications which are not published by Microsoft to access your organisation’s data, if the user also has access to the data. This also means that the users will see these apps on their Access Panels. If this option is set to no, then admins must consent to these applications before users may use them.
6. After selecting No, the following message appears with instructions on managing LinkedIn account connections if required.
There is also a further warning that users can still consent to apps accessing the groups they own. I’ll cover this in step 7 below.
7. Further down you may also wish to disable Users can consent to apps accessing company data for the groups they own or limit to a certain group as show in the second screenshot below
Users can consent to apps accessing company data for the groups they own If this option is set to yes, then all users who are owners of a group may consent to allow third-party multi-tenant applications to access the data of the groups they own.If this option is set to no, then no user can consent to those application to access the data of the groups they own.If this option is set to limited, then only the members of the group selected can consent to those applications to access the data of the groups they own.
8. After disabling user access, you may wish to setup Admin consent. If this option is set to yes, then users request admin consent to any app that requires access to data they do not have the permission to grant. If this option is set to no, then users must contact their admin to request to consent in order to use the apps they need.
Users can request admin consent to apps they are unable to consent to: If this option is set to yes, then users request admin consent to any app that requires access to data they do not have the permission to grant. If this option is set to no, then users must contact their admin to request to consent in order to use the apps they need.
Select users to review admin consent: The selected users can review and act on new admin consent requests. Only users with the Global, Application, or Cloud application administrator role can grant admin consent, so only those users will be available for selection. Removing a user from the list of reviewers will not remove their role, so they will retain their admin privileges until their role is explicitly changed.
9. When ready, don’t forget to click the save button
Subscribe to new tech posts.
We will never send you spam email or forward your details to third parties.
This will close in 0 seconds