Active Directory Ldap Authentication Users Ou Subquery

Active Directory Ldap Authentication Users Ou Subquery — a configuration and setup topic from the APG vNext support community.

Key Configuration Points

• IIS App Pool: .NET 4.0 Integrated Pipeline mode is required.
• Connection String: Verify SQL Server name, database, and credentials in web.config.
• File Permissions: App pool identity needs read/write on the upfiles folder.
• URL Rewriting: Install IIS URL Rewrite 2.0 module for clean SEO-friendly URLs.
• Full-Text Search: Enable SQL Server Full-Text Indexing for forum search.

More Help

• Installation Guide
• Upgrade Guide
• Support Forum

Active Directory LDAP Authentication with OU Subquery Filtering in APG vNext

When integrating APG vNext with Active Directory via LDAP, a common requirement is to limit authentication to users in a specific Organisational Unit (OU) or set of OUs — rather than the entire directory. This is essential in enterprise environments where the AD contains thousands of service accounts, disabled accounts, or accounts from other departments that should not have forum access.

The Problem with a Flat BaseDN

The default LDAP configuration uses a BaseDN that covers the entire domain (DC=company,DC=com). This means any enabled AD account can authenticate to the forum. For most enterprise deployments, this is too broad. The fix is to scope the LDAP query to a specific OU and optionally add a subquery filter to further restrict access.

Scoping to a Specific OU

<!-- Restrict authentication to IT department OU only -->
<appSettings>
  <add key="APG.LDAP.BaseDN"
       value="OU=IT,OU=Employees,DC=company,DC=com" />
  <add key="APG.LDAP.Scope"    value="Subtree" />
  <add key="APG.LDAP.Filter"   value="(&(objectClass=user)(enabled=TRUE))" />
</appSettings>

The Subtree scope searches the specified OU and all child OUs beneath it. Use OneLevel if you want to exclude child OUs.

Advanced OU Subquery Filtering

For complex AD structures where allowed users are spread across multiple OUs, use an LDAP filter with OR conditions rather than changing the BaseDN:

<!-- Allow users from IT or DevTeam OUs only -->
<add key="APG.LDAP.Filter"
     value="(&(objectClass=user)(|(memberOf=CN=IT-Staff,OU=Groups,DC=company,DC=com)
                                  (memberOf=CN=DevTeam,OU=Groups,DC=company,DC=com)))" />

This approach uses AD group membership as the access criterion rather than OU location — more flexible and easier to maintain as your organisational structure changes.

Testing the LDAP Filter

Before deploying, validate your filter using the ldapsearch command (Linux) or LDP.exe (Windows):

# ldapsearch test (Linux/macOS)
ldapsearch -H ldap://dc.company.com   -D "[email protected]" -W   -b "OU=IT,OU=Employees,DC=company,DC=com"   "(&(objectClass=user)(enabled=TRUE))"   sAMAccountName displayName mail

Confirm the result list matches exactly the users who should have forum access before enabling LDAP authentication in APG vNext.

Troubleshooting Common LDAP Issues

Authentication Succeeds but Profile Fields Are Empty

APG vNext maps AD attributes to forum profile fields. If email or display name is blank after LDAP login, the attribute mapping is misconfigured:

<add key="APG.LDAP.AttributeEmail"       value="mail" />
<add key="APG.LDAP.AttributeDisplayName" value="displayName" />
<add key="APG.LDAP.AttributeUsername"    value="sAMAccountName" />

Handling LDAP Authentication Failures

"Invalid credentials" Even with Correct Password

This almost always indicates the service account used by APG vNext to bind to LDAP (APG.LDAP.ServiceUser) doesn't have read access to the user entry being authenticated. Verify the service account has at minimum Read All Properties permission on the OU containing forum users:

# PowerShell: check service account permissions on the OU
Get-Acl -Path "AD:OU=IT,OU=Employees,DC=company,DC=com" |
    ForEach-Object { $_.Access } |
    Where-Object { $_.IdentityReference -like "*svc-apg*" } |
    Select-Object ActiveDirectoryRights, AccessControlType

Intermittent LDAP Timeouts

If LDAP authentication works most of the time but occasionally times out (especially under load), the cause is usually the LDAP connection being closed by a network firewall's idle timeout. Configure LDAP keepalive:

<!-- APG vNext LDAP connection pool settings -->
<add key="APG.LDAP.ConnectionTimeout" value="30" />   <!-- seconds -->
<add key="APG.LDAP.EnablePooling"     value="true" />
<add key="APG.LDAP.PoolMinSize"       value="2" />
<add key="APG.LDAP.PoolMaxSize"       value="10" />
<add key="APG.LDAP.PoolIdleTimeout"   value="120" />  <!-- seconds -->

Users Can Log In But Group Memberships Are Not Synced

APG vNext syncs group memberships at login using the memberOf attribute. If AD groups are not being reflected in APG vNext user groups, verify that the service account can read the memberOf attribute, and that the group names in APG.LDAP.GroupMap.* match the exact CN of the AD groups (case-sensitive).

Securing the LDAP Connection with TLS/SSL

Plain LDAP (port 389) transmits credentials in cleartext. For production environments, use LDAPS (port 636) or StartTLS to encrypt the connection:

<!-- Use LDAPS (port 636) -->
<add key="APG.LDAP.Server"    value="ldaps://dc.company.com:636" />
<add key="APG.LDAP.UseSSL"    value="true" />
<!-- If using a self-signed certificate on the DC: -->
<add key="APG.LDAP.IgnoreCertErrors" value="false" />
<!-- Set to true ONLY during testing with self-signed certs;
     always false in production -->

Ensure the domain controller's TLS certificate is issued by a CA that the APG vNext server trusts (either the enterprise CA or a public CA). An untrusted certificate with IgnoreCertErrors=false will cause all LDAP authentications to fail silently.

LDAP vs. ASP.NET MembershipProvider for APG vNext

APG vNext supports two distinct approaches to Active Directory integration: the built-in LDAP integration (APG.LDAP.Enabled=true) and using the .NET ActiveDirectoryMembershipProvider as a custom provider. The LDAP integration is simpler to configure and supports OU subquery filtering natively. The ActiveDirectoryMembershipProvider approach gives more control over password change and reset flows but does not support the OU filter syntax directly — it requires a single flat BaseDN. For most deployments, the built-in LDAP integration is the recommended approach.

Related Resources

• Active Directory MembershipProvider Integration
• Achieving Single Sign-On
• Single Sign-On Implementation Guide
• Knowledge Base
• Support Forum

Looking for more help? Browse the support forum or check the Knowledge Base.