Guidance Needed for LDAPS (Port 636) Migration — ABP Zero v6.0.0 (.NET 5) Application #12632

1 Answer(s)

• 

  0

  oguzhanagir created 7 months ago

  Support Team

  Hi @tom.ohle

  Thank you for reaching out and providing such a detailed breakdown of your setup. Securing your infrastructure by enforcing LDAPS (port 636) and disabling standard LDAP (port 389) is a great proactive measure, and we are happy to help you navigate this transition for your ABP Zero application.

  Here are the answers to your questions, along with the recommended approach to ensure your application functions flawlessly under the new security policies.

  Will disabling LDAP (389) affect our application?

  If your application relies entirely on IIS Windows Authentication (Kerberos) and you have not explicitly enabled the ABP LDAP module in your core module's PreInitialize method (e.g., via Configuration.Modules.ZeroLdap().Enable(typeof(AppLdapAuthenticationSource));), ABP will not make any implicit internal LDAP binds or directory lookups.

  The mere presence of the Abp.Zero.Ldap NuGet package does not trigger active directory lookups. If you are exclusively using IIS for authentication and JWT generation, disabling port 389 will not break your current login flow.

  However, if your application does use the ABP LDAP module as an external authentication source (even as a fallback) to validate credentials or synchronize users, you will need to update your code to support LDAPS.

  Do we need code changes to support LDAPS (636)?

  Since you are on ABP v6.0.0, the native configuration setting for LDAPS (UseSsl) was introduced in a later version ([PR #6655](https://github.com/aspnetboilerplate/aspnetboilerplate/pull/6655/changes#diff-ab614034a21e9bfaa788d7d322ad37b48f0c528d68ef9feadd4bf0230198495eR148)).

  The good news is that you do not need to upgrade your ABP packages to support this. You can easily apply the logic from that PR directly in your v6.0.0 codebase by replacing the default LdapAuthenticationSource with a custom implementation.

  If you plan to utilize ABP's LDAP module under an LDAPS only environment, you should implement the following override:

  Step A: Create a Custom Authentication Source Create a new class that inherits from LdapAuthenticationSource and override the CreatePrincipalContext method to enforce the SecureSocketLayer context option.

  namespace Epl.Ldap
  {
      public class CustomLdapAuthenticationSource : LdapAuthenticationSource<Tenant, User>
      {
          private readonly ILdapSettings _settings;
  
          public CustomLdapAuthenticationSource(ILdapSettings settings, IAbpZeroLdapModuleConfig ldapModuleConfig) 
              : base(settings, ldapModuleConfig)
          {
              _settings = settings;
          }
  
          protected virtual async Task<PrincipalContext> CreatePrincipalContext(Tenant tenant)
          {
              // Note: Ensure your custom settings implementation supports GetUseSsl()
              var useSsl = await _settings.GetUseSsl(tenant?.Id);
              var contextType = await _settings.GetContextType(tenant?.Id);
              
              var options = useSsl
                  ? ContextOptions.SecureSocketLayer | ContextOptions.Negotiate
                  : GetDefaultOptionForStore(contextType);
  
              return new PrincipalContext(
                  contextType,
                  ConvertToNullIfEmpty(await _settings.GetDomain(tenant?.Id)),
                  ConvertToNullIfEmpty(await _settings.GetContainer(tenant?.Id)),
                  options,
                  ConvertToNullIfEmpty(await _settings.GetUserName(tenant?.Id)),
                  ConvertToNullIfEmpty(await _settings.GetPassword(tenant?.Id))
              );
          }
  
          private ContextOptions GetDefaultOptionForStore(ContextType contextType)
          {
              if (contextType == ContextType.Machine)
              {
                  return ContextOptions.Negotiate;
              }
  
              return ContextOptions.Negotiate | ContextOptions.Signing | ContextOptions.Sealing;
          }
      }
  }
  

  Step B: Register the Custom Source In your Core module's PreInitialize method (e.g., EplCoreModule.cs), ensure you register this new custom class instead of the default one:

  public override void PreInitialize()
  {
      // ... other configurations
  
      // Register your custom LDAPS compatible source
      Configuration.Modules.ZeroLdap().Enable(typeof(CustomLdapAuthenticationSource));
  }
  
  

  Recommended way to test LDAPS only

  Your proposed testing methodology is spot on. Here is our recommended approach to validate the setup:

  • Disable Port 389 on a Dev DC: Yes, blocking port 389 via Windows Firewall on an isolated Development Domain Controller is the standard and most effective way to simulate the upcoming network environment.
  • IIS Auth Isolation: If Windows Authentication is genuinely your only login method, the application will function normally because Kerberos operates independently of ABP's internal LDAP module. Testing this with port 389 blocked will give you 100% confidence.
  • Monitor Event Viewer: On your Domain Controller, open the Event Viewer and look for Event ID 2889 (Directory Services). This event logs insecure (plaintext) LDAP binds. If your application attempts to use port 389, it will be logged here. You want to see zero 2889 events originating from your application server.

  If you have any further questions or need additional assistance, please do not hesitate to reach out

  Markdown is supported

  Copy & paste or drag & drop images (max 30 MB per image)

  Save Cancel