Hook points for On-Prem Windows AD authentication #10529

4 Answer(s)

• 

  0

  AI-Bot created 11 hours ago

  Support Team ABP Agent

  • In ABP 8.3.3, there isn’t a built-in “intercept the call to ActiveDirectory” hook in the login pipeline for on-prem Windows AD / LDAP the same way there is for OIDC/OAuth external providers. The “AD server in settings” you mentioned is not enough by itself to make ABP automatically authenticate against AD and auto-provision users.
  • The supported/ABP-native place to plug in “authenticate elsewhere, then create/sign-in an ABP user” is the External Login pipeline (i.e., treat AD as an external identity provider). In practice for on-prem AD, you typically implement your own authentication handler/provider (LDAP bind / Kerberos / etc.), then sign in using ABP Identity by creating/finding an IdentityUser and issuing the normal ABP auth cookie/token.

  What to do (ABP 8.3.3, MVC, tiered)

  1. Do AD authentication in the Auth Server (or IdentityServer/OpenIddict host)

     • In a tiered solution, the “login happens” in the AuthServer/IdentityServer app (depending on your template/version).
     • Put your AD credential validation in the login flow there (e.g., custom login page model / custom action that validates username+password against AD).

  2. After AD says “OK”, create or find the ABP user and sign in

     • The “where to after this?” part is: create/find IdentityUser and sign in via ASP.NET Core Identity (so ABP can do permissions/auditing/tenancy/etc.).
     • Conceptually:
       • Look up user in ABP by username/email.
       • If not found, create it (and set email/name fields from AD if you have them).
       • Optionally add an external login record (provider name like "LDAP" and provider key like AD’s GUID/UPN) if you want it tracked like an external provider.
       • Then call the normal sign-in manager to issue the auth cookie / token.

  3. Do NOT expect “Register” to create AD accounts

     • ABP’s register page creates users in the ABP database/Identity store, not in AD.
     • If you need “registration” to mean “create in AD”, that is a separate provisioning process (and usually not allowed in many enterprises). You’d have to customize registration to call your AD provisioning logic.

  4. If you want automatic user creation on first login

     • Use the same logic in the login callback (after AD validation) to create the ABP IdentityUser record the first time that AD user signs in.

  Verified references (closest applicable ABP guidance)

  • ABP account module overview (login/registration are ABP Identity-based): https://abp.io/docs/latest/modules/account
  • ABP’s general statement about authentication capabilities (mentions AD/LDAP as an integration scenario, but not a built-in “hook point” API): https://abp.io/docs/latest/others/why-abp-platform

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel
• 

  0

  rwright-ruhealth created 2 hours ago

  Where in code do we start?

  If you want automatic user creation on first login

  Use the same logic in the login callback (after AD validation) to create the ABP IdentityUser record the first time that AD user signs in.

  Save Cancel
• 

  0

  rwright-ruhealth created 2 hours ago

  Another issue is it seems the AD being looked for is some generic AD, not windows AD. Many code changes for AD had to be made to finally authenticate. Even then, it seems something is missing. Shouldn't be this much work.

  Save Cancel
• 

  0

  enisn created 29 minutes ago

  Support Team .NET Developer

  Hi, Thanks for the follow-up. If you are using the built-in LDAP login in Identity Pro, the place to start is not the register page. The username/password login flow already calls the LDAP provider automatically:

  1. The login page posts the username and password.
  2. ABP calls SignInManager.PasswordSignInAsync(...).
  3. AbpSignInManager checks the registered external login providers.
  4. LdapExternalLoginProvider.TryAuthenticateAsync(...) performs the LDAP bind.
  5. If LDAP authentication succeeds, ABP creates or updates the IdentityUser and signs the user in. So, for your scenario, the main hook points are:

  • LdapExternalLoginProvider: customize how the username is normalized before authentication.
  • OpenLdapManager: customize how ABP searches the directory and reads user information. This is important because the built-in LDAP implementation is OpenLDAP-oriented by default (uid=..., cn=..., and (&(uid=...))). For Windows AD, you usually need a Windows AD-specific format such as DOMAIN\\user, user@domain, or a search based on sAMAccountName / userPrincipalName. So changing only the LDAP server settings is usually not enough. Also, the register page is not the correct place for LDAP provisioning:
  • normal registration creates a local ABP user
  • it does not create an AD account
  • for LDAP, ABP user creation happens after a successful LDAP login, or by using the Identity Pro external user import feature So the smallest practical next step is:

  1. Keep the login page as is.
  2. Replace OpenLdapManager for your Windows AD bind/search behavior.
  3. Replace LdapExternalLoginProvider so the username format matches your AD format.
  4. Make sure the AD user has a readable email value, because ABP needs that while creating the IdentityUser. If you mean true integrated Windows Authentication (IIS/Negotiate) rather than LDAP username/password, that is a different flow and goes through the external login callback path instead of the LDAP provider. If login succeeds but the ABP user is still not created, please share these details and we can narrow it down quickly:

  • the exact username format you are submitting (jsmith, DOMAIN\\jsmith, or jsmith@domain)
  • whether the AD user has the mail attribute populated
  • your custom username normalization / LDAP search filter changes
  • the exact exception or log entry right after the successful bind Best regards, ABP Support Team

  Save Cancel