What Are the Certificate Requirements for Defender for Identity
Defender for Identity uses self-signed certificates made during setup. Certificates keep communication safe and help watch your Active Directory. If you do not handle certificates well, attackers can use weak templates or settings. They might get more power than they should. You could have problems like people getting in without permission or gaining extra rights.
Bad certificate templates let attackers get more power.
Attackers can ask for certificates with wrong settings and become Domain Admins.
Running AD CS assessment tools often helps find and fix these problems.
Key Takeaways
Defender for Identity uses self-signed certificates by default. These certificates help keep sensor communication safe. They renew on their own and make setup easier.
You need good certificate templates and strong cryptographic keys. The keys should be 2048 bits or more. This stops attackers from getting in without permission.
AD CS sensors need special hardware, software, and network settings. You must use Windows Server 2016 or newer. You also need high-performance power settings.
Check certificate templates, permissions, and renewal dates often. This helps you avoid security problems. It also keeps sensors working well.
Turn on auditing and watch for alerts. This helps you find strange certificate use early. It makes your network safer.
Certificate Types
Self-Signed Certificates
When you set up Defender for Identity sensors, self-signed certificates are used by default. These certificates help the sensors talk safely to the Defender for Identity cloud service. The sensor makes its own certificate when you install it. You do not have to ask for or handle these certificates yourself. Each certificate works for two years. The Sensor Updater service renews them on its own. You do not need to update them by hand. This process uses two checks to keep the sensor working and safe.
Tip: Self-signed certificates make setup simple. You do not need a certificate authority or extra files.
AD CS Sensor Certificates
Defender for Identity now works with sensors for Active Directory Certificate Services (AD CS). These sensors help you watch certificate use and find risky actions. You need to meet some rules before you add an AD CS sensor.
Your server must use Windows Server 2016, 2019 (with updates), or 2022.
You need at least 2 CPU cores, 6 GB RAM, and 6 to 10 GB of disk space.
The Npcap driver installs with the sensor.
Set your server’s power to High Performance for best results.
Make sure your server can reach Defender for Identity cloud services. You can use a proxy, ExpressRoute, or let Azure IP addresses through your firewall.
You must install the Certification Authority Role Service on your AD CS server. Only online AD CS servers need sensors. Offline servers do not need sensors. You cannot use the local service account for sensor domain connections. You must set up a Directory Service Account (DSA). You can use a Group Managed Service Account (gMSA) for better safety and easier password work, or a normal user account if you need to. Make sure you give the DSA the right permissions and test them. You also need to turn on auditing on your AD CS server so Defender for Identity can collect events.
Note: Using gMSA helps your sensor run well. You do not have to change passwords by hand, so there is less risk of downtime.
Technical Specs
Supported CAs
Defender for Identity sensors work with AD CS servers that have the Certification Authority Role Service and are online. You do not need sensors on offline AD CS servers. Supported certificate authorities are managed by AD CS servers with this role turned on. There is no list of exact certificate authority names. The rule depends on the server’s role and if it is online.
Note: Only online AD CS servers with the Certification Authority Role Service can use Defender for Identity sensors.
Key Length and Algorithms
You must use strong cryptographic keys for certificates. The smallest key you can use is 1024 bits. Longer keys are safer. Most groups pick 2048 bits or more for better safety. Always check the key length when you make or ask for a certificate.
Recommended key length: 2048 bits or higher
Use secure algorithms like RSA with SHA-256 or stronger
Do not use old algorithms like SHA-1 or RSA-512
Weak or old algorithms can cause security problems. Attackers can break weak encryption and get secret data. Use certificate inventory tools to find and replace weak certificates. This helps you follow rules and avoid problems.
Subject Name and SAN
Certificates for Defender for Identity sensors need the right Subject Name and SAN fields. The Subject Name can be empty or set as a Common Name. The SAN extension must be there and use OID 2.5.29.17. Each SAN DNS name should look like "dns=FQDN" and use "&" to join more names.
Here is a summary of the rules:
Subject Name can be empty or set as CN.
Write each SAN DNS name as
dns=FQDN(likedns=server01.contoso.com&dns=server02.contoso.com).Use certreq.exe to make the certificate signing request with the right SANs.
Set KeyUsage, KeySpec, KeyLength, and EnhancedKeyUsageExtension OID 1.3.6.1.5.5.7.3.1 (Server Authentication) in the template.
Do not turn on the unsafe EDITF_ATTRIBUTESUBJECTALTNAME2 setting on your CA. This stops users without permission from adding any SAN values, which could let them pretend to be someone else.
Tip: Microsoft says to turn off the EDITF_ATTRIBUTESUBJECTALTNAME2 setting. Run
certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2and restart the certificate service to make this change.
Hardware and Network Prerequisites
You need to meet some hardware and network rules before you use Defender for Identity sensors. The table below shows the main things you need:
For network, you can use a proxy, ExpressRoute, or firewall rules that let Azure IP addresses through. Open the needed ports, like TCP 443 for SSL, and check DNS and Netlogon ports. Always make sure your network lets sensors reach the Defender for Identity cloud service.
Tip: Test your network with PowerShell before you start. Work with your network team to allow the right URLs and ports.
Configuring Defender for Identity Certificates
Request and Install
If you do not use self-signed certificates, you must get and set up certificates for Defender for Identity sensors. First, make a certificate signing request (CSR) with certreq.exe. You need to add the right Subject Name and SAN fields in your request. The SAN field should have all DNS names for your sensor. After making the CSR, send it to your company’s certificate authority. When you get the signed certificate, put it on the sensor server. Make sure you set KeyUsage and EnhancedKeyUsage for server authentication. Check that the certificate uses a strong key length, like 2048 bits or more.
Tip: Always check the certificate template before you ask for a certificate. This helps stop weak templates that attackers could use.
Common Pitfalls
Many groups have trouble when setting up certificates for Defender for Identity sensors. Wrong settings can make security weaker and sensors less useful. The table below lists common mistakes and what they cause:
You should check certificate templates and CA settings often to avoid these problems. Defender for Identity sensors need correct settings to find bad certificate use. You can help sensors by turning on advanced auditing and watching for template changes. Microsoft Secure Score can help you find and fix certificate problems. Keeping sensors updated and working right gives you better protection.
Note: If you miss audit data, like subject alternate names, it can hurt detection. Send important events to Microsoft Sentinel for better tracking.
Certificate Management
Renewal and Expiry
You must keep track of certificate renewal and expiry to stay safe. Most certificates expire in 180 days. If you forget to renew them, attackers might use old or long-lasting certificates. They could get into your network without anyone seeing them. Here are some key things to know about certificate renewal and expiry:
Certificates last for 180 days. Make sure to renew them early.
If you do not change certificates, attackers can steal them and get in.
Expired certificates help attackers hide and not get caught.
Set rules to control how long certificates last and make sure you change them often.
Watch for expired certificates to stop people from getting in or getting more power.
To avoid problems when renewing, plan the time well. Pick a time to renew, like 10 days before they expire, and tell your team about any downtime. Use tools that renew certificates automatically so you do not make mistakes. Try to renew certificates when fewer people are using the system to keep things running well.
Security Best Practices
There are good ways to keep certificates safe. Upload root or intermediate certificates to make trust anchors. Make sure all client certificates come from the right certificate authority. Turn on and check certificate revocation lists (CRL) to see if certificates are still good. Use managed PKI tools to handle certificate jobs like giving out, renewing, and taking back certificates. Automation keeps you up to date and cuts down on mistakes.
Treat your certificate servers as important. Make them stronger against attacks. Turn off templates you do not use and limit who can give out certificates. Watch certificate requests for anything strange. If you find a bad certificate, take it back right away. Connect your monitoring tools to spot bad certificate use and act fast.
Tip: Check your certificate templates and permissions often. This stops attackers from using weak templates to get more rights.
You should know the main certificate rules to keep things safe. Here are the most important things:
The AD CS sensor helps you see risky certificate actions, like when someone gives out certificates without permission or changes settings.
If you put AD CS on a domain controller, the sensor works as a Domain Controller Sensor. You do not need to do anything extra.
For a special AD CS server, add its computer object to the gMSA group. This lets the sensor start up.
The sensor sends alerts if it finds strange certificate use. It also helps you make your setup stronger.
Checklist:
Make sure the sensor type fits your server role
Put the right accounts in security groups
Check alerts and audit logs often
Keep looking at your certificate settings and sensor alerts. This helps you find problems early and keeps your network safe.
FAQ
What certificates does Defender for Identity use by default?
Defender for Identity uses self-signed certificates for its sensors. These certificates keep the sensors and the cloud talking safely.
What hardware do you need for Defender for Identity sensors?
You need a server with 2 CPU cores or more. The server also needs 6 GB RAM and 6 GB disk space. Set the power to High Performance so sensors work well.
What happens if a certificate expires?
If a certificate expires, the sensor might stop working. It could also lose its connection to the cloud. You should renew certificates before they expire to stay safe.
What certificate authorities work with Defender for Identity?
Defender for Identity works with AD CS servers that have the Certification Authority Role Service turned on. Only online servers with this role can use sensors.