pg_hba.conf configuration for users managed by Active Directory and authenticated with LDAP
search cancel

pg_hba.conf configuration for users managed by Active Directory and authenticated with LDAP

book

Article ID: 393255

calendar_today

Updated On:

Products

VMware Tanzu Data Suite Greenplum VMware Tanzu Greenplum

Issue/Introduction

+ Below errors reported when trying to login to Greenplum database using a LDAP / LDAP secure protocol wherein users are defined in the Active Directory.

psql: error: could not initiate GSSAPI security context: Unspecified GSS failure.  Minor code may provide more information: Server not found in Kerberos database
FATAL:  LDAP authentication failed for user "username"

 + LDAP string for pg_hba.conf so that users managed by Active directory can able to login using a single application userid to Greenplum.

Environment

All greenplum versions.

Cause

The underlying issue could be direct connection to an AD/LDAP server versus Virtual IP.
In most cases VIP will be a load balancer of other AD servers, so we need to determine whether the issue is because of VIP or the AD server itself

Resolution

Recommendations to follow for a successful LDAP  group authentication:

  1. All entries in the pg_hba file must follow the `name=value` format; otherwise, `pg_hba.conf` file will not reload.
  2. The parameter `USER` in the pg_hba entry should be prefixed with a `+` followed by the group name, indicating that authentication is for members of that group.
  3. Depending on the type of communication we want between Postgres server and LDAP server, the ldapurl can be either
            - Standard-LDAP(ldap) that provides a unencrypted connection.
            - LDAP-over-SSL(ldaps) which provides an encrypted connection.
  4. `ldapbindpasswd` parameter in pg_hba should specify the password of the service account used to bind to the LDAP server for querying group memberships.
  5. `ldapbinddn` should specify the full DN of the service account that Postgres server would use to bind to the LDAP server.
  6. `ldapbasedn` should specify the base DN from which the LDAP search for users and groups will start.
  7. While using group-based authentication in LDAP, we would need to filter based on the user's membership in a specific group.`memberof` attribute is typically used to check if a user is a member of a group. This attribute is available in Active Directory by default, and in OpenLDAP, group membership may be represented by other attributes (e.g., memberUid or member).

 

For Active Directory:

ldapsearchfilter="(&(objectClass=user)(sAMAccountName=%u)(memberof=CN=YourGroup,OU=Groups,DC=example,DC=com))"

 

For OpenLDAP:

ldapsearchfilter="(&(objectClass=posixGroup)(memberUid=%u))"

Ensure that the LDAP server (e.g., OpenLDAP, Active Directory) is correctly configured and operational. This can be verified by running `ldapsearch` with same parameters as the pg_hba entry. For example,

ldapsearch -x -LLL -H ldap://<hostname> -D "<service_account_dn>" -b "<base_dn>" -w <password> "(&(objectClass=Person)(memberof=<group_dn>))"

 

Create roles for both users and group and assign permissions

CREATE ROLE <user>; 
ALTER ROLE <user> WITH LOGIN; 
CREATE ROLE <group>; 
GRANT <group> TO <user>;

Additional Information

Troubleshoot `LDAP authentication failed` issue:

  1. Check the most recent GPDB log for any LDAP-related errors. This would give an initial indication of whether the issue is due to a configuration error, binding failure, or any other type of error.
  2. For configuration-related errors, we can verify if there are any typos in the pg_hba file or ensure that the entry is as per the guidelines.
  3. If binding is not happening properly, it's likely that port is incorrect or `ldapbinddn` path is incorrect.
         - Ensure `ldapbinddn` is correct
         - If Standard-LDAP is configured over Active Directory, then port `3268` can be used instead of default port `389`.
         - If LDAP-over-SSL is configured over Active Directory, then port `3269` can be used instead of default port `636`.
           Additionally for LDAP-over-SSL, we need to make sure there are no certificate validation issues.
  4. If issue still persists, try swapping the hostname with the IP address in the ldapurl to help resolve any DNS or network-related issues. Sometimes swapping IP address to hostname can also resolve binding issue as Virtual IP can block certain ports.
  5. If binding is successful but authentication still fails, `ldapbasedn` can be modified to specify the complete path where the user resides, for example, 
    ldapbasedn="ou=users,dc=example,dc=com"

NOTE - Try both VIP and an IP (or URL) to of a particular AD server to figure out which one is causing the issue.

Powered by Wolken Software