Why do some AD/LDAP integrated applications require a service account and not others?

user_2661826 0
Viewed 54

I'm building a simple LDAP flask integrated api, and typically I've seen the pattern of:

# Base
app.config["LDAP_HOST"]             = os.getenv("LDAP_HOST")
app.config["LDAP_DOMAIN_NAME"]      = os.getenv("LDAP_DOMAIN_NAME")
app.config["LDAP_USERNAME"]         = os.getenv("LDAP_USERNAME")
app.config["LDAP_PASSWORD"]         = os.getenv("LDAP_PASSWORD")

@auth.verify_password
def verify_password(username, password):
    if session.get('username'):
        return True

    if not username and not password:
        return False

    try:
        # Simple LDAP wrapper
        sad = Simple_AD(
            server_name     = app.config["LDAP_HOST"] , 

            # Option 1 - With dedicated service account
            username = app.config["LDAP_USERNAME"],
            password = app.config["LDAP_PASSWORD"],

            # Option 2 - Binding with the user's actual creds provided in the basic auth request itself
            username = username
            password = password
        )
        ldap_user = sad.get_aduser(samaccountname=username)
        if ldap_user:
            session['username'] = username
            return True
    except:
        return False

My question is why do some applications use a dedicated service account when doing the LDAP bind, when I can easily bind with the actual user's provided credentials?

I can understand some edge case limitations like:

  • User doesn't have full access to the directory
  • AD/LDAP audit logs will show user instead of service account

Besides these minor things, is there a reason to maintain a dedicated username/password JUST for ldap binding itself?

Not having to maintain ANOTHER service account is generally what I'd be after here.

Thanks!

ldap active-directory
1 Answers

In general, in order to bind to LDAP you would need a DN, not a plain username. When user accounts are distributed among different OUs, it may not be trivial to guess what is the actual DN based on plain username, and searching LDAP may require authentication on its own (as in case of AD). Since users tend to log in as username, not as CN=username,OU=usersDepartment,DC=domain,DC=com, application may use its own service account to first invoke LDAP search to find a DN for username, which will then be used to bind.

Active Directory will let you also bind using userPrincipalName instead of DN, so it might be helpful to attempt to bind as username@domain.com instead of username. Either users can be instructed to log in this way or the application can add @domain.com part upon binding attempt if feasible.

The other case when application might need to use its own service account would be when the user's password is not available and the application still needs to read some user information from LDAP. Common case would be getting information in some background process (when no current user is logged in) or when the user authenticates to the application using application-specific token or API key instead of LDAP password; the application may want to verify e.g. user's group membership upon such access and for that it would need to have its own set of credentials, since user's provided authentication would only be good for the application itself and not for LDAP server.

user_25923090
Related