{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/active-directory-ldap-signing-bind-discovery/", "item": { "id": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/", "slug": "active-directory-ldap-signing-bind-discovery", "url": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery.md", "json": "https://update.dsesecurity.com/api/v1/posts/active-directory-ldap-signing-bind-discovery/" }, "title": "Find unsigned LDAP binds before requiring signing", "summary": "Requiring LDAP signing rejects unsigned SASL binds and cleartext simple binds; Microsoft provides summary and detailed directory events to find dependent clients before enforcement.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:35:08+00:00", "modified_at": "2026-08-25T21:43:55+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 495, "potentially_affected": "Active Directory Domain Services and AD LDS environments with applications, appliances, scripts, or identity systems that bind over LDAP.", "dse_recommendation": "Collect bind events across every directory server, map each client and identity to an owner, migrate to signed SASL or protected TLS as supported, and enforce only after extended clean observation.", "primary_source": { "name": "How to enable LDAP signing in Windows Server", "url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: Requiring LDAP signing on Windows directory servers rejects SASL binds that do not request integrity and simple binds sent over an unprotected connection. Microsoft warns that dependent clients stop working. Use directory events to discover and remediate those clients before enforcement.

\n

Source fact: what Microsoft documents

\n

Microsoft’s LDAP signing guide explains that unsigned LDAP traffic is susceptible to replay and man-in-the-middle modification. A directory server configured to require signing rejects unsigned SASL binds and LDAP simple binds performed over a non-SSL/TLS connection.

\n

Microsoft documents Event ID 2887 as a daily summary when such binds are detected but permitted. More detailed LDAP Interface Events logging can produce Event ID 2889 with the client IP address and attempted identity for each problem bind. When the server rejects problem binds, Event ID 2888 summarizes rejected attempts. The page recommends configuring clients to stop using the unsafe bind patterns and observing an extended period without detection before requiring signing. It includes Group Policy, AD LDS, and ldp.exe verification procedures.

\n

What the source does not establish

\n

One quiet domain controller does not prove the forest is ready. Rare monthly jobs, disaster-recovery systems, isolated networks, load-balanced directory clients, or applications pointed at another server may be missed. LDAP signing provides integrity; it is not the same as TLS encryption or LDAP channel binding. An IP address in an event does not identify the application owner, and a successful bind does not prove least-privilege directory access.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

The following steps are DSE recommendations based on the cited source.

\n
    \n
  1. Enable the documented discovery logging on all relevant directory servers for an approved, time-bounded period and protect the resulting identity and IP data.
    2. \n
  2. Map every problem bind to an application, owner, identity, server, bind type, business purpose, and supported remediation.
    3. \n
  3. Configure clients for signed SASL or an appropriately protected TLS path according to vendor support. Correct certificate trust and name validation where TLS is used.
    4. \n
  4. Observe an extended clean period that covers low-frequency workloads, then stage the server requirement with rollback criteria.
    5. \n
  5. Monitor rejected-bind events and application health after enforcement; do not permanently weaken the server for an unidentified client.
    6. \n
\n

Verification and evidence

\n\n

Official references

\n", "content_text": "Bottom line: Requiring LDAP signing on Windows directory servers rejects SASL binds that do not request integrity and simple binds sent over an unprotected connection. Microsoft warns that dependent clients stop working. Use directory events to discover and remediate those clients before enforcement.\nSource fact: what Microsoft documents\nMicrosoft’s LDAP signing guide explains that unsigned LDAP traffic is susceptible to replay and man-in-the-middle modification. A directory server configured to require signing rejects unsigned SASL binds and LDAP simple binds performed over a non-SSL/TLS connection.\nMicrosoft documents Event ID 2887 as a daily summary when such binds are detected but permitted. More detailed LDAP Interface Events logging can produce Event ID 2889 with the client IP address and attempted identity for each problem bind. When the server rejects problem binds, Event ID 2888 summarizes rejected attempts. The page recommends configuring clients to stop using the unsafe bind patterns and observing an extended period without detection before requiring signing. It includes Group Policy, AD LDS, and ldp.exe verification procedures.\nWhat the source does not establish\nOne quiet domain controller does not prove the forest is ready. Rare monthly jobs, disaster-recovery systems, isolated networks, load-balanced directory clients, or applications pointed at another server may be missed. LDAP signing provides integrity; it is not the same as TLS encryption or LDAP channel binding. An IP address in an event does not identify the application owner, and a successful bind does not prove least-privilege directory access.\nApplicability questions\n\nWhich AD DS domains, read-only domain controllers, AD LDS instances, sites, and network segments receive LDAP?\nWhich applications, appliances, physical-security products, scripts, and service accounts bind to them?\nDoes each client use signed SASL, simple bind over TLS, unsigned SASL, or cleartext simple bind?\nDoes the observation period include month-end, certificate renewal, failover, recovery, and dormant integrations?\nIs LDAP channel binding being assessed separately where TLS and applicable authentication are used?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nEnable the documented discovery logging on all relevant directory servers for an approved, time-bounded period and protect the resulting identity and IP data.\nMap every problem bind to an application, owner, identity, server, bind type, business purpose, and supported remediation.\nConfigure clients for signed SASL or an appropriately protected TLS path according to vendor support. Correct certificate trust and name validation where TLS is used.\nObserve an extended clean period that covers low-frequency workloads, then stage the server requirement with rollback criteria.\nMonitor rejected-bind events and application health after enforcement; do not permanently weaken the server for an unidentified client.\n\nVerification and evidence\n\nPreserve discovery scope, logging level, observation dates, event exports, and client-remediation register.\nRecord successful vendor-supported bind tests after remediation without exposing credentials.\nUse the documented negative test to prove an unsigned simple bind is rejected after enforcement.\nConfirm all directory servers have the intended effective policy and no unexpected rejection events persist.\n\nOfficial references\n\nHow to enable LDAP signing in Windows Server — Microsoft", "content_markdown": "Bottom line: Requiring LDAP signing on Windows directory servers rejects SASL binds that do not request integrity and simple binds sent over an unprotected connection. Microsoft warns that dependent clients stop working. Use directory events to discover and remediate those clients before enforcement.\n\n## Source fact: what Microsoft documents\n\nMicrosoft’s [LDAP signing guide](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server) explains that unsigned LDAP traffic is susceptible to replay and man-in-the-middle modification. A directory server configured to require signing rejects unsigned SASL binds and LDAP simple binds performed over a non-SSL/TLS connection.\n\nMicrosoft documents Event ID 2887 as a daily summary when such binds are detected but permitted. More detailed LDAP Interface Events logging can produce Event ID 2889 with the client IP address and attempted identity for each problem bind. When the server rejects problem binds, Event ID 2888 summarizes rejected attempts. The page recommends configuring clients to stop using the unsafe bind patterns and observing an extended period without detection before requiring signing. It includes Group Policy, AD LDS, and ldp.exe verification procedures.\n\n## What the source does not establish\n\nOne quiet domain controller does not prove the forest is ready. Rare monthly jobs, disaster-recovery systems, isolated networks, load-balanced directory clients, or applications pointed at another server may be missed. LDAP signing provides integrity; it is not the same as TLS encryption or LDAP channel binding. An IP address in an event does not identify the application owner, and a successful bind does not prove least-privilege directory access.\n\n## Applicability questions\n\n- Which AD DS domains, read-only domain controllers, AD LDS instances, sites, and network segments receive LDAP?\n\n- Which applications, appliances, physical-security products, scripts, and service accounts bind to them?\n\n- Does each client use signed SASL, simple bind over TLS, unsigned SASL, or cleartext simple bind?\n\n- Does the observation period include month-end, certificate renewal, failover, recovery, and dormant integrations?\n\n- Is LDAP channel binding being assessed separately where TLS and applicable authentication are used?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\n- Enable the documented discovery logging on all relevant directory servers for an approved, time-bounded period and protect the resulting identity and IP data.\n\n- Map every problem bind to an application, owner, identity, server, bind type, business purpose, and supported remediation.\n\n- Configure clients for signed SASL or an appropriately protected TLS path according to vendor support. Correct certificate trust and name validation where TLS is used.\n\n- Observe an extended clean period that covers low-frequency workloads, then stage the server requirement with rollback criteria.\n\n- Monitor rejected-bind events and application health after enforcement; do not permanently weaken the server for an unidentified client.\n\n## Verification and evidence\n\n- Preserve discovery scope, logging level, observation dates, event exports, and client-remediation register.\n\n- Record successful vendor-supported bind tests after remediation without exposing credentials.\n\n- Use the documented negative test to prove an unsigned simple bind is rejected after enforcement.\n\n- Confirm all directory servers have the intended effective policy and no unexpected rejection events persist.\n\n## Official references\n\n- [How to enable LDAP signing in Windows Server](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server) — Microsoft" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/", "url": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Find unsigned LDAP binds before requiring signing", "item": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/#article", "identifier": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/", "url": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/", "headline": "Find unsigned LDAP binds before requiring signing", "description": "Requiring LDAP signing rejects unsigned SASL binds and cleartext simple binds; Microsoft provides summary and detailed directory events to find…", "abstract": "Requiring LDAP signing rejects unsigned SASL binds and cleartext simple binds; Microsoft provides summary and detailed directory events to find dependent clients before enforcement.", "articleBody": "Bottom line: Requiring LDAP signing on Windows directory servers rejects SASL binds that do not request integrity and simple binds sent over an unprotected connection. Microsoft warns that dependent clients stop working. Use directory events to discover and remediate those clients before enforcement.\nSource fact: what Microsoft documents\nMicrosoft’s LDAP signing guide explains that unsigned LDAP traffic is susceptible to replay and man-in-the-middle modification. A directory server configured to require signing rejects unsigned SASL binds and LDAP simple binds performed over a non-SSL/TLS connection.\nMicrosoft documents Event ID 2887 as a daily summary when such binds are detected but permitted. More detailed LDAP Interface Events logging can produce Event ID 2889 with the client IP address and attempted identity for each problem bind. When the server rejects problem binds, Event ID 2888 summarizes rejected attempts. The page recommends configuring clients to stop using the unsafe bind patterns and observing an extended period without detection before requiring signing. It includes Group Policy, AD LDS, and ldp.exe verification procedures.\nWhat the source does not establish\nOne quiet domain controller does not prove the forest is ready. Rare monthly jobs, disaster-recovery systems, isolated networks, load-balanced directory clients, or applications pointed at another server may be missed. LDAP signing provides integrity; it is not the same as TLS encryption or LDAP channel binding. An IP address in an event does not identify the application owner, and a successful bind does not prove least-privilege directory access.\nApplicability questions\n\nWhich AD DS domains, read-only domain controllers, AD LDS instances, sites, and network segments receive LDAP?\nWhich applications, appliances, physical-security products, scripts, and service accounts bind to them?\nDoes each client use signed SASL, simple bind over TLS, unsigned SASL, or cleartext simple bind?\nDoes the observation period include month-end, certificate renewal, failover, recovery, and dormant integrations?\nIs LDAP channel binding being assessed separately where TLS and applicable authentication are used?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nEnable the documented discovery logging on all relevant directory servers for an approved, time-bounded period and protect the resulting identity and IP data.\nMap every problem bind to an application, owner, identity, server, bind type, business purpose, and supported remediation.\nConfigure clients for signed SASL or an appropriately protected TLS path according to vendor support. Correct certificate trust and name validation where TLS is used.\nObserve an extended clean period that covers low-frequency workloads, then stage the server requirement with rollback criteria.\nMonitor rejected-bind events and application health after enforcement; do not permanently weaken the server for an unidentified client.\n\nVerification and evidence\n\nPreserve discovery scope, logging level, observation dates, event exports, and client-remediation register.\nRecord successful vendor-supported bind tests after remediation without exposing credentials.\nUse the documented negative test to prove an unsigned simple bind is rejected after enforcement.\nConfirm all directory servers have the intended effective policy and no unexpected rejection events persist.\n\nOfficial references\n\nHow to enable LDAP signing in Windows Server — Microsoft", "datePublished": "2026-08-25T21:35:08+00:00", "dateModified": "2026-08-25T21:43:55+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Find unsigned LDAP binds before requiring signing" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Playbook", "Important priority" ], "genre": "Playbook", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 495, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "How to enable LDAP signing in Windows Server", "url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server" } } ] } }