The new built-in admin consent workflow within AzureAD Enterprise Application is amazing!
This feature will give you the control that you need to take care of your companies sensitive information like user id`s, files, email accounts etc.
Did you know that malicious applications is often a start of a sophisticated phising attack?
If a malicious application get`s the right permissions it could be a bad situation for your company!
Just have a look at this random application and what that app can retreive, other also gives a complete user list of all the employees back to the app developers.
In this case ALL files that this user has access to does this app now have access to read – meaning that`s there is no secrets anymore..
So to be able to block and and have controll over the applications that get`s granted to your AzureAD tenant you should use the new “Admin Consent Workflow” within AzureAD. This feature is in preview at the moment but I highly recomend using it.
It takes two minute to configure and after it`s configured the users see`s this when trying to connect a thirdparty application to your tenant
After this request is sent – the admin that is configured within the workflow get`s an approval email and can easlly approve consents đ
The configuration looks like this:
Please have a look at the official documentation and enable it for your deployment!
So in this fourth
blog post in my series S for Security in EMS we will og deeper in Advanced
Threat Analytics included within EMS.
So what is Advanced
Threat Analytics?
Well, it`s an
on-premises platform that helps protect your enterprise from multiple types of
advanced targeted cyber attacks and insider threats.
Why is this a
important toolset to have on your hybrid environment?
Well, since you have
an hybrid environment you are lacking a system to detect abnormal behavour like
password sharing, lateral movements and so on and Malicious attacks like
Pass-the-Ticket, Pass-the-Hash and several other attack vectors.
Advanced threat
analytics uses machine learning and user usage analytics discover abnorman
activities and suspicious activities.
Within Advanced
Threat Analytics we can also get insights on Security Issues and risk within
our on-premises environment like broke trust between machines and domain
controlelrs, weak protocols used by our users and systems and much more!
All these actions and insights can be viewed from the Advanced Threat Analytics Dashboard
This is just a smal insight on what ATA can do for you!
Let`s start off
with the EMS E3 package and that will give you access and user rights to use
Azure AD Premium P1 features.
So do you need
it?
Well, Azure AD Premium P1 gives you capabilities for your hybrid users to access both on-prem and cloud resources. The synchronization also provides write-back capabilities so self-service password reset for on-prem users can be achieved. Along with advanced features as Dynamic groups, self-service group management and “Microsoft Identity Manager” (on-prem identity and access management).
And one more
important feature which is one of the most powerfull regarding securing your
cloud services is “Conditional Access”. Yes we have “Security
Defaults” witch is a free service but if you need to do some exclutions
you need to upgrade to Azure AD Premium P1 to gain “Conditional
Access” features.
Over to EMS E5 –
that gives you several additions to the P1 license with all the Azure AD P2
features.
Those features
are at the time “Azure Identity Protection” and “Priviledged
Identity Management”
When going to P2
i will say that PIM is the feature you want to configure right the way as this
gives you access management in a whole new level. Users who have been givven
additional roles within your AzureAD does not have the role active at all time
lowering the attack vector for users. When users need to use their priviledge
roles they have to activate it and by adding a second factor to the activation
your priviledge roles are more secure! Hey, you can also add approvers to roles
so that a second person need to approve the request.
Many options on
this part as you see!
As this blogg post is in a series of several posts please stay tuned for the next service within EMS and this blog post series “S for security in EMS”
So lets talk about
“Security Defaults” a bit, this new feature in AzureAD who replaces
“Baseline policies: ” in the Conditional Access pane within Security
in AzureAD.
First of all – the
baseline policies where in preview and could be changed before the feature went
GA so we cant blame anyone of the service changing before production.
The Baseline
policies gave us remediaton of MFA and and blocking of legacy authentication
within 4 policies that everyone could use within Conditional Access, these four
policies where free so no cost and that sweet!
Baseline Policy: Require MFA for admins (Preview)
Enabled MFA to all administrator roles within AzureAD
Baseline Policy: End user protection (Preview)
Enabled MFA registration to all users and required MFA for users with leaked password or other risky signins.
Baseline Policy: Require MFA for Service Management (Preview)
Require MFA for accessing the Azure Portal, Azure PowerShell modules or Azure CLI
Blocked the usage of legacy authentication on all services (such as pop, IMAP, native android clients etc.
For a good time now
we cound enabled one or more of those 4 baseline rules – but that ends! At
February 29th 2020 Microsoft will discontinue the use of Baseline policies so
if you are using some of them you need to enable Security Defaults in AzureAD.
Head into
portal.azure.com -> Properties -> Security Defaults and enable it.
Please not that if
you have license for using Conditional Access (Azure AD Premium P1) you cannot
a Conditional Accessrule without disabling Security Defaults.
And if you have
Azure AD Premium P1 you should be creating the Conditional Access rules
manually and that gived you several advantages such as exclude users, pinpoint
to some cloud apps or exclude them and set other requiremets aswel.
Best practice says that you should always have a “Break the glass administrator” account who is excluded from all the Requirements – but please note! That account need to be monitored and high security alerts should be raised every time the account is used.
Now and then we get
errors in our Azure AD Connect syncronization, or that said – my customers get
errors.
And every now and
then there is a error wich are not easy to spot what can be wrong.
In this case the
sollution was not that easy – but when you think of it, it makes kind of sense
sort of.
So this is the Error
i got.
Looking into Azure
AD Connect it throwed a error on syncronization.
After some
investigation back and forth i with the GUID who did not match the Azure AD
Sync error – i found out that a deleted group was configured as a licensing
group within Azure AD. Therefor when it was deleted from On-prem AD it could
not be deleted in Azure AD since it still was in use.
By removing it from
the license sku it removed it self on next sync.
More and more
organizations is taking advantage of using MFA for their users and there is no
reason for them not to since it`s free for all Office 365 users and also for
all Azure AD users if you are not using the Office 365 services. But after you
enable it for your users, are you sure everyone is enabled?
You may have seen at
the Secure Score that not all users are registred for MFA, and if you do so you
have users with no MFA! So these users may be victims for bruteforce attacks so
it`s super important to remediate all users to see how everything is configured!
Some of the users with no MFA maybe legit and should not have it.
So let`s dig into
the materials for a second or two.
First thing is that there is a “Secure Score” check for MFA registered users that will show you how many of your users which are not registered (if any)
If you have any
users in that list it would not show who the users are so we need to go deeper
in the material to retreive this status.
So to get the list of users who don`t have setup MFA you need to run this PowerShell command with the AzureAD PowerShell module loaded.
And now that we have
found all users we can check them out why they don`t use MFA and make sure that
they use it đ
Further on we can check what method users are using when authenticating with MFA. For this I use this script located in Technet PowerShell archives HERE
If you have deployed MFA the Conditional Access way (recommended) you will see that the MFA status on all user are set to “Disabled” but the method is set to what the user are using.
So in the previously
post I went through how to activate MFA for Administrator roles i a really
simple and effective way.
In this post we will
focus on activating MFA for all regular users. And first off all we need to
evaluate who should be activated first or should we activate on all users at
the same time and do a evaluation on service accounts! If we enable MFA on for
example a serivce account used for scan to email on “multi functional
printers” or on a mailbox account witch are used on a thirdparty
ticketingsystem (POP/IMAP) we could break those service by just enabling MFA on
all users.
My recomandation is
when you are more then 30 users in your company you should select a few
ambasadeurs who is getting the MFA activated first and can therefore be the
power users who can help others with the registration if there is any hick-ups
(should not be many).
And to activate MFA
for end users I highly recomend to use Conditional Access for
all users and exclude a AzureAD Group which contains a “Break the glass Admin” and other service accounts.
All cloud apps (no exeptions)
Grant Access – but require MFA
Easy like that! And
It`s a realy quick solution for your company.
Drawback here is
that you need “Azure AD Premium P1” licenses to use Conditional
Access and a second drawback is that it`s not scored at the Microsoft Secure
Score.
You problably heard about multifactor authentication by now, but have you enabled it in your environment?
If not! Please do so at once! I will in this short blogpost give you the direction to get started with MFA in Azure AD.
So let`s just jump right into it.
First things first â protect your admin accounts!
With admin accounts i mean a account who has a additional role assigned other then beeing a regular user and to mitigate these users we will enable a Conditional Access who is requires MFA for all administrator accounts
So navigate to Azure Active Directory in portal.azure.com
Dive into “Security” -> “Conditional Access”
Click the “Baseline policy: Require MFA for Admins (Preview) and choose to use it immidiatly
So now you have successfully enabled MFA for all your admins! Great work đ
To make it easier for yourself you can now change the MFA verification from the default SMS to Authenticator app by visiting https://aka.ms/mfasetup and add the Authenticator app as a preffered method.
Next up is to enable it for all your users and that i will cover in the next blog post – Stay tuned for “Get started with MFA – Part two” đ