Latest

LDAP

In this guide we will cover how to manually configure a 7.1 Appliance’s external authentication to work against LDAP. This provides LDAP users access to the Appliance UI as well as the REST API.

In these examples, the LDAP domain used will be example.com

Note: The SSSD and OpenLDAP configurations shown below are simply examples. Depending on the Ldap environment, Ldap directory server used, the configurations can widely differ. Many other options are available to the authconfig command as well as the sssd.conf configuration file.

The following reference are available for customizing SSSD for any LDAP directory:

# man authconfig
# man ldap.conf
# man sssd-ldap

Testing OpenLDAP

With SSL

For Configuring external authentication to Ldap, the sssd-ldap communication must be secured (SSL or Start TLS). So an SSL Certificate needs to be created.

The apacheds-cert.pem certificate file is used in the examples below.

Update the LDAP Directory Server to point to the keystore for the certificate. This is used for both SSL and Start TLS.

For SSL, update the /etc/openldap/ldap.conf accordingly to test:

SASL_NOCANON    on

URI             ldaps://ldap-example.com:10636
BASE            dc=example,dc=com
TLS_REQCERT     demand
TLS_CACERTDIR   /etc/openldap/cacerts
TLS_CACERT      /etc/openldap/cacerts/apacheds-cert.pem

Then try out a search:

# ldapsearch -x -H ldaps://ldap-example:10636 -LLL \
       -b "ou=people,dc=example,dc=com" -s sub     \
       "(objectclass=organizationalPerson)"

With User Bind DN and Password

You can also test the ldap directory by specifying a user Bind DN and password on the Ldap search command line as follows:

# ldapsearch -x -H ldap://ldap-example:389 -LLL                 \
       -b "ou=people,dc=example,dc=com" -s sub                  \
       -D "ui=:userid,ou=People,dc=example,dc=com" -w :password \
       "(objectclass=organizationalPerson)"

Configure SSSD

Configure the Operating System for SSSD based authentication against an LDAP server.

Note: SSSD must be configured to communicate with LDAP over SSL or Start TLS. Otherwise an authentication error will be returned to the Appliance login screen.

Configure SSSD based authentication against LDAP via SSL:

  # authconfig \
    --enablesssd                                \
    --enablesssdauth                            \
    --enablelocauthorize                        \
    --enableldap                                \
    --enableldapauth                            \
    --ldapserver=ldaps://ldap-example.com:10636 \
    --disableldaptls                            \
    --ldapbasedn=dc=example,dc=com              \
    --enablerfc2307bis                          \
    --enablecachecreds                          \
    --update

Update sssd.conf

Edit the different sections in /etc/sssd/sssd.conf for the Appliance as in the following example, customizing the main [domain/example.com] section for the particular Ldap installation.

Note: Starting with SSSD version 1.15.2, which will be available in CentOS version 7.4, SSSD will provide the domain name as a user attribute. The below examples show how to set ldap_user_extra_attrs and user_attributes to take advantage of this new feature. If running an appliance built with CentOS version prior to CentOS 7.4 do not include domainname for these attributes.

=>  [domain/example.com]
    autofs_provider = ldap
    id_provider = ldap
    auth_provider = ldap
    chpass_provider = ldap
    ldap_schema = rfc2307bis

    ldap_uri = ldaps://ldap-example.com:10636
    ldap_id_use_start_tls = False
=>  ldap_tls_cacertdir = /etc/openldap/cacerts
=>  ldap_tls_cacert = /etc/openldap/cacerts/apacheds-cert.pem

=>  ldap_pwd_policy = none

    ldap_search_base = dc=example,dc=com
=>  ldap_network_timeout = 3

=>  ldap_user_search_base = ou=people,dc=example,dc=com
=>  ldap_user_object_class = posixAccount
=>  ldap_user_name = uid
=>  ldap_user_uid_number = uidNumber

=>  ldap_group_object_class = groupOfNames
=>  ldap_group_search_base = ou=user_groups,dc=example,dc=com
=>  ldap_group_name = cn
=>  ldap_group_member = member

    cache_credentials = True
=>  entry_cache_timeout = 600

=>  ldap_user_extra_attrs = mail, givenname, sn, displayname, domainname

    [sssd]
=>  domains = example.com
    config_file_version = 2
=>  services = nss, pam, ifp
=>  sbus_timeout = 30
=>  default_domain_suffix = example.com

    [nss]
    homedir_substring = /home

    [pam]
=>  default_domain_suffix = example.com

=>  [ifp]
=>  default_domain_suffix = example.com
=>  allowed_uids = apache, root
=>  user_attributes = +mail, +givenname, +sn, +displayname, +domainname

Testing SSSD Updates

The best way to test manual SSSD updates is to query a user via the message bus system (D-Bus) API. When user attributes and groups are properly returned, that is a good indication that the External Authentication would succeed.

For the dbus-send command to succeed when run from command line, SELinux must be in permissive mode.

# setenforce 0

After each update to sssd.cond, restart the sssd service before testing the changes.

systemctl restart sssd

Example query of user attributes for user evmuser. This primarily validates the ldap_user_ attributes of sssd.conf.

# dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:evmuser array:string:mail,givenname,sn,displayname,domainname

Query groups of user evmuser. This primarily validates the ldap_group_ attributes of sssd.conf.

# dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:evmuser

With logging for each of the sssd.conf section in the appropriate /var/log/sssd/ log file. The log files of primary interest are:

Log File Type of debugging

/var/log/sssd/sssd.log

SSSD communication with processes

/var/log/sssd/sssd_example.com.log

sssd-ldap communication to the LDAP server

/var/log/sssd/sssd_ifp.log

Gathering user and group information from LDAP server

For each of the log file here, an debug level attribute (maximum value of 9) can be added to the appropriate sssd.conf section as follows:

    [ifp]
=>  debug_level = 9
    default_domain_suffix = example.com
    ...

When done testing, re-enable SELinux enforcing mode.

# setenforce 1

Note: When testing authentication on the Appliance, if updates are done in LDAP and not immediately seen when authenticating, then clean the SSSD cache as follows then retry:

# sss_cache -E

Configure Apache

Create the Apache configuration files

# TEMPLATE_DIR="/var/www/miq/system/TEMPLATE"
# cp ${TEMPLATE_DIR}/etc/pam.d/httpd-auth                         \
                    /etc/pam.d/httpd-auth
# cp ${TEMPLATE_DIR}/etc/httpd/conf.d/manageiq-remote-user.conf       \
                    /etc/httpd/conf.d/
# cp ${TEMPLATE_DIR}/etc/httpd/conf.d/manageiq-external-auth.conf.erb \
                    /etc/httpd/conf.d/manageiq-external-auth.conf

Update the Apache configuration file /etc/httpd/conf.d/manageiq-external-auth.conf as follows to specify the correct realm:

...

    <Location /dashboard/kerberos_authenticate>
      AuthType           Kerberos
      AuthName           "Kerberos Login"
      KrbMethodNegotiate On
      KrbMethodK5Passwd  Off
=>    KrbAuthRealms      example.com
      Krb5KeyTab         /etc/http.keytab
      Require            pam-account httpd-auth

      ErrorDocument 401  /proxy_pages/invalid_sso_credentials.js
    </Location>

...

Configure SELinux

For SSSD to Ldap, assure that non-standard Ldap ports (other than 389 or 636) are allowed:

# semanage port -a -t ldap_port_t -p tcp 10389
# semanage port -a -t ldap_port_t -p tcp 10636

Set appropriate SELinux permissions:

# setsebool -P allow_httpd_mod_auth_pam on
# setsebool -P httpd_dbus_sssd          on

Restart Services

# systemctl restart sssd
# systemctl restart httpd

Configure Administrative UI

Login as admin, then in Configure→Configuration→Authentication

  • Set mode to External (httpd)

  • Check: Get User Groups from External Authentication (httpd)

  • Do not check: Enable Single Signon since Kerberos is not configured against LDAP.

  • Click Save.

The above steps need to be done on each UI and WebService enabled appliance.

in Configure→Configuration→Access Control

  • Make sure the user’s LDAP group for the appliance are created and appropriate roles assigned to those groups.