Defender for Identity fundamentals
Defender for Identity (DFI) is an on-premises agent which observes the entire on-premises Active Directory activity and sends it to the cloud for further analysis and correlation through other products. See the architecture topology:
It is not directly developed to respond to events, but helps to understand emerging, sophisticated processes. The general strength of the product is, that it shares and links information with other Defender products (Endpoint, Office 365 and Cloud Apps) to create an incident with highly concentrated data sets on what happened.
Defender for Identity comes as Microsoft Enterprise Mobility + Security (EMS) E5 security product. See the official docs or M365maps. That means it is integrated in EMS E5, M365 E5 or a M365 E5 security step-up. Now me advice is, if you own any of these license plans do not hesitate to set up Defender for Endpoint.
Now of course Defender for Identity only comes to play, if you are in a hybrid state and host a local domain through Active Directory domain services. The commissioning of DFI is pretty straightforward and doesn't require any big planning.
Microsoft Defender for Identity portal
The Microsoft Defender for Identity portal is found in Microsoft 365 Defender, under Settings>Identities.
Beforce the integration Microsoft 365 happened, we had portal.atp.azure.com for only the product itself.
- To deploy DFI, we first must create and deposit a directory service account. We can choose between two scenarios, whereas I would always opt for a group managed service account (gMSA).
- Service account - regular account that you create with username + password
- Group managed service account (gMSA) - secured service account which is made exactly for such a scenario, where you don't know the password
Create group managed service account
This is the Powershell command to create a gMSA. Please replace svcDFI and the FQDN of your domain controller(s). (make sure the "$" stays at the last argument)
New-ADServiceAccount -Name svcDFI -DNSHostName AD01.exampledomain.com -PrincipalsAllowedToRetrieveManagedPassword AD01.exampledomain.com/$
- Next we are going to install the sensor on all of our domain controllers. Download the setup at DFI portal and copy the key.
- The installation of the executable can only be run if no reboot is pending and will need the key.
After successful installation, you should see a service named after it in the state of running:
If you have trouble with getting it to run, make sure the account is allowed to log on as a service.
- Finally check the state in the DFI portal. The sensor should show up in about 15 minutes after installation and should be up to date & running.
To properly operate with DFI, you should do a little extra configuration.
Define sensitive users/devices/groups
Usually every organization has sensitve type of users/devices or groups. Think about C-level or management accounts or the financial department. Devices may be dedicated business machines and with groups you can simplify this step. Please be aware that these are on-prem objects only, which can be added.
Honeytoken identites are highly restricted. Every attempt of use should generate an alert. Usually we add global administrators to this list.
One more thing to get done, is adding any Exchange servers of your environment, as they constitue a highly valuable asset.
It may is desired to globally exclude entities by any effects of DFI or its rules/policy triggers. You can add users/domains/devices and IP addresses.
Any good system should notify you about service health issues and alerts. Of course you can also add email recipient (e.g. SecOps mail address) for DFI. There is also the possibility to link it to your own syslog.
How it benefits your security posture
As you have seen Defender for Identity has a rather small feature set. Although the implementation should be considered for all hybrid environments, especially because it is so simple. The real profit you gain will be in detected alerts and incidents, that have involved identites and may include on-premises originated lateral movement that goes beyond the border of the cloud or just one product suite. Within the incident you will find a graph to understand the relations:
The integration to other Defender products is usually enabled by default when those are services are active/licensed. Although you will still find an option to enable or disable the integration: