Forum Discussion
Solved
Improving AD security and enabling new features
Dear Community,
We are in the process of enabling new security features in our AD environment. We want to enable following:
- Disabling Kerberos Weak Encryption i.e. (DES )
- How to hide sensitive identifiers in Active Directory Object Descriptions
- Enforce LDAP signing by configuring Group Policy settings to require signing and validating it using PowerShell or the GPMC.
- Enabling LAPS - LAPS Local Administrator Password Management
- what are the best practices to do above and what be the side effects when we enable above settings?
hi Seema_Kanwa655 You’re essentially hardening your Active Directory (AD) environment by disabling legacy/weak protocols and enforcing modern controls. Here are the some pros and cons for your reference. You can decide best fit as per requirement.
a.Disabling Kerberos Weak Encryption (DES)
Pros
- Inventory first: Run a report of accounts or services still using DES (e.g., klist, event logs, or PowerShell: Get-ADUser -Filter {KerberosEncryptionType -band 1}).
- Stage rollout:
- Enable logging (Audit Kerberos Authentication Service) → detect usage.
- Reconfigure service accounts to use AES128/256 encryption (Set-ADUser -KerberosEncryptionType).
- Only then disable DES at the domain level (Network security: Configure encryption types allowed for Kerberos GPO).
- Test in pilot OU before domain-wide enforcement.
Cons
- Services or apps that still rely on DES will fail authentication.
- Older non-Windows systems, or custom apps coded against DES, will break.
- Legacy devices (old copiers, apps, SAP, etc.) may need patches or reconfiguration.
b.Hide Sensitive Identifiers in AD Object Descriptions
Pros
- Don’t store secrets in AD descriptions (e.g., passwords, server purposes, network diagrams).
- Use Group Policy Preferences, Intune tags, or AD attributes designed for metadata instead.
- Implement Access Control Lists (ACLs) so only admins can read descriptions if necessary.
- Audit existing descriptions with PowerShell to detect sensitive data.
Cons
- Low technical impact—more of a process/awareness change.
- If some scripts or apps parse AD descriptions for info, they may need updating.
c.Enforce LDAP Signing
Pros
- Configure Domain Controller: LDAP server signing requirements → set to Require signing.
- First, enable audit mode (None but log events) → check if any apps/servers still bind without signing.
- Update apps to use LDAPS (TCP 636) or LDAP with StartTLS.
- Validate by running:
- Get-WinEvent -LogName DirectoryService -FilterXPath "*[EventData[@Name='EventID']='2889']"
(shows unsigned LDAP binds)
Cons
- Older apps that use simple binds without SSL will break.
- Non-Windows apps/devices may need reconfiguration to LDAPS.
- Requires DCs to have valid TLS certificates (AD CS or public CA).
Over all pros
- Phased approach: Enable auditing/logging first, then enforce.
- Pilot group: Test with a small set of OUs and IT-owned devices before global rollout.
- Communication: Notify app owners & infra teams—especially for LDAP and DES changes.
- Fallback plan: Document rollback steps (e.g., re-enable DES temporarily if a critical app breaks).
- Monitoring: Enable event log forwarding / SIEM alerts for failures post-change.
2 Replies
hi Seema_Kanwa655 You’re essentially hardening your Active Directory (AD) environment by disabling legacy/weak protocols and enforcing modern controls. Here are the some pros and cons for your reference. You can decide best fit as per requirement.
a.Disabling Kerberos Weak Encryption (DES)
Pros
- Inventory first: Run a report of accounts or services still using DES (e.g., klist, event logs, or PowerShell: Get-ADUser -Filter {KerberosEncryptionType -band 1}).
- Stage rollout:
- Enable logging (Audit Kerberos Authentication Service) → detect usage.
- Reconfigure service accounts to use AES128/256 encryption (Set-ADUser -KerberosEncryptionType).
- Only then disable DES at the domain level (Network security: Configure encryption types allowed for Kerberos GPO).
- Test in pilot OU before domain-wide enforcement.
Cons
- Services or apps that still rely on DES will fail authentication.
- Older non-Windows systems, or custom apps coded against DES, will break.
- Legacy devices (old copiers, apps, SAP, etc.) may need patches or reconfiguration.
b.Hide Sensitive Identifiers in AD Object Descriptions
Pros
- Don’t store secrets in AD descriptions (e.g., passwords, server purposes, network diagrams).
- Use Group Policy Preferences, Intune tags, or AD attributes designed for metadata instead.
- Implement Access Control Lists (ACLs) so only admins can read descriptions if necessary.
- Audit existing descriptions with PowerShell to detect sensitive data.
Cons
- Low technical impact—more of a process/awareness change.
- If some scripts or apps parse AD descriptions for info, they may need updating.
c.Enforce LDAP Signing
Pros
- Configure Domain Controller: LDAP server signing requirements → set to Require signing.
- First, enable audit mode (None but log events) → check if any apps/servers still bind without signing.
- Update apps to use LDAPS (TCP 636) or LDAP with StartTLS.
- Validate by running:
- Get-WinEvent -LogName DirectoryService -FilterXPath "*[EventData[@Name='EventID']='2889']"
(shows unsigned LDAP binds)
Cons
- Older apps that use simple binds without SSL will break.
- Non-Windows apps/devices may need reconfiguration to LDAPS.
- Requires DCs to have valid TLS certificates (AD CS or public CA).
Over all pros
- Phased approach: Enable auditing/logging first, then enforce.
- Pilot group: Test with a small set of OUs and IT-owned devices before global rollout.
- Communication: Notify app owners & infra teams—especially for LDAP and DES changes.
- Fallback plan: Document rollback steps (e.g., re-enable DES temporarily if a critical app breaks).
- Monitoring: Enable event log forwarding / SIEM alerts for failures post-change.
Thankyou for your reply Surya. Let me go through your reply.
