Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 12. Advanced LDAP Configuration

12.1. Overview
Copia collegamento

OpenShift Enterprise Advanced Lightweight Directory Access Protocol (LDAP) Configuration covers the following topics:

12.2. Setting up SSSD for LDAP Failover
Copia collegamento

12.2.1. Overview
Copia collegamento

OpenShift Enterprise provides an authentication provider for use with Lightweight Directory Access Protocol (LDAP) setups, but it can only connect to a single LDAP server. This can be problematic if that LDAP server becomes unavailable. System Security Services Daemon (SSSD) can be used to solve the issue.

Originally designed to manage local and remote authentication to the host operating system, SSSD can now be configured to provide identity, authentication, and authorization services to web services like OpenShift Enterprise. SSSD provides advantages over the built-in LDAP provider, including the ability to connect to any number of failover LDAP servers, as well as the ability to cache authentication attempts in case it can no longer reach any of those servers.

The setup for this configuration is advanced and requires a separate authentication server (also called an authenticating proxy) for OpenShift Enterprise to communicate with. This topic describes how to do this setup on a dedicated physical or virtual machine (VM), but the concepts are also applicable to a setup in a container.

12.2.2. Prerequisites for Authenticating Proxy Setup
Copia collegamento

  1. Before starting setup, you need to know the following information about your LDAP server.

    • Whether the directory server is powered by FreeIPA, Active Directory, or another LDAP solution.
    • The Uniform Resource Identifier (URI) for the LDAP server (for example, ldap.example.com).
    • The location of the CA certificate for the LDAP server.
    • Whether the LDAP server corresponds to RFC 2307 or RFC2307bis for user groups.

  2. Prepare the VMs:

    • proxy.example.com: A VM to use as the authenticating proxy. This machine must have at least SSSD 1.12.0 available, which means a fairly recent operating system. This topic uses a Red Hat Enterprise Linux 7.2 server for its examples.
    • openshift.example.com: A VM to use to run OpenShift Enterprise.
Note

These VMs can be configured to run on the same system, but for the examples used in this topic they are kept separate.

12.2.3. Phase 1: Certificate Generation
Copia collegamento

  1. To ensure that communication between the authenticating proxy and OpenShift Enterprise is trustworthy, create a set of Transport Layer Security (TLS) certificates to use during the other phases of this setup. In the OpenShift Enterprise system, start by using the auto-generated certificates created as part of running: 

    # openshift start \
    --public-master=https://openshift.example.com:8443 \
    --write-config=/etc/origin/
    Copy to Clipboard Toggle word wrap

    Among other things, this generates a /etc/origin/master/ca.{cert|key}. Use this signing certificate to generate keys to use on the authenticating proxy. 

    # mkdir -p /etc/origin/proxy/
# oadm ca create-server-cert \
    --cert='/etc/origin/proxy/proxy.example.com.crt' \
    --key='/etc/origin/proxy/proxy.example.com.key' \
    --hostnames=proxy.example.com \
    --signer-cert=/etc/origin/master/ca.crt \
    --signer-key='/etc/origin/master/ca.key' \
    --signer-serial='/etc/origin/master/ca.serial.txt'
    Copy to Clipboard Toggle word wrap
    Important

    Ensure that any host names and interface IP addresses that need to access the proxy are listed. Otherwise, the HTTPS connection will fail.

  2. Create a new CA to sign this client certificate: 

    # oadm ca create-signer-cert \
  --cert='/etc/origin/proxy/proxyca.crt' \
  --key='/etc/origin/proxy/proxyca.key' \
  --name='openshift-proxy-signer@UNIQUESTRING' \
    1 
    
  --serial='/etc/origin/proxy/proxyca.serial.txt'
    Copy to Clipboard Toggle word wrap
    1
    Make UNIQUESTRING something unique.

  3. Generate the API client certificate that the authenticating proxy will use to prove its identity to OpenShift Enterprise. 

    # oadm create-api-client-config \
    --certificate-authority='/etc/origin/proxy/proxyca.crt' \
    --client-dir='/etc/origin/proxy' \
    --signer-cert='/etc/origin/proxy/proxyca.crt' \
    --signer-key='/etc/origin/proxy/proxyca.key' \
    --signer-serial='/etc/origin/proxy/proxyca.serial.txt' \
    --user='system:proxy'
    Copy to Clipboard Toggle word wrap

    This prevents malicious users from impersonating the proxy and sending fake identities.

  4. Copy the certificate and key information to the appropriate file for future steps: 

    # cat /etc/origin/proxy/system\:proxy.crt \
      /etc/origin/proxy/system\:proxy.key \
      > /etc/origin/proxy/authproxy.pem
    Copy to Clipboard Toggle word wrap

12.2.4. Phase 2: Authenticating Proxy Setup
Copia collegamento

This section guides you through the steps to authenticate the proxy setup.

12.2.4.1. Step 1: Copy Certificates
Copia collegamento

From openshift.example.com, securely copy the necessary certificates to the proxy machine: 

# scp /etc/origin/master/ca.crt \
      root@proxy.example.com:/etc/pki/CA/certs/

# scp /etc/origin/proxy/proxy.example.com.crt \
      /etc/origin/proxy/authproxy.pem \
      root@proxy.example.com:/etc/pki/tls/certs/

# scp /etc/origin/proxy/proxy.example.com.key \
      root@proxy.example.com:/etc/pki/tls/private/
Copy to Clipboard Toggle word wrap

12.2.4.2. Step 2: SSSD Configuration
Copia collegamento

  1. Install a new VM with an operating system that includes 1.12.0 or later so that you can use the mod_identity_lookup module. The examples in this topic use a Red Hat Enterprise Linux 7.2 Server.

  2. Install all of the necessary dependencies: 

    # yum install -y sssd \
                 sssd-dbus \
                 realmd \
                 httpd \
                 mod_session \
                 mod_ssl \
                 mod_lookup_identity \
                 mod_authnz_pam
    Copy to Clipboard Toggle word wrap

    This gives you the needed SSSD and the web server components.

  3. Edit the /etc/httpd/conf.modules.d/55-authnz_pam.conf file and remove the comment from the following: 

    LoadModule authnz_pam_module modules/mod_authnz_pam.so
    Copy to Clipboard Toggle word wrap

  4. Set up SSSD to authenticate this VM against the LDAP server. If the LDAP server is a FreeIPA or Active Directory environment, then realmd can be used to join this machine to the domain. 

    # realm join ldap.example.com
    Copy to Clipboard Toggle word wrap

    For more advanced case, see the System-Level Authentication Guide

    If you want to use SSSD to manage failover situations for LDAP, this can be configured by adding additional entries in /etc/sssd/sssd.conf on the ldap_uri line. Systems enrolled with FreeIPA can automatically handle failover using DNS SRV records.

  5. Restart SSSD to ensure that all of the changes are applied properly: 

    $ systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap

  6. Test that the user information can be retrieved properly: 

    $ getent passwd <username>
username:*:12345:12345:Example User:/home/username:/usr/bin/bash
    Copy to Clipboard Toggle word wrap
  7. Attempt to log into the VM as an LDAP user and confirm that the authentication is properly set up. This can be done via the local console or a remote service such as SSH.
Note

If you do not want LDAP users to be able to log into this machine, it is recommended to modify /etc/pam.d/system-auth and /etc/pam.d/password-auth to remove the lines containing pam_sss.so.

12.2.4.3. Step 3: Apache Configuration
Copia collegamento

You need to set up Apache to communicate with SSSD. Create a PAM stack file for use with Apache. To do so:

  1. Create the /etc/pam.d/openshift file and add the following contents: 

    auth required pam_sss.so
account required pam_sss.so
    Copy to Clipboard Toggle word wrap

    This configuration enables PAM (the pluggable authentication module) to use pam_sss.so to determine authentication and access control when an authentication request is issued for the openshift stack.

  2. Configure the Apache httpd.conf. The steps in this section focus on setting up the challenge authentication, which is useful for logging in with oc login and similar automated tools.

    Note

    Configuring Form-Based Authentication explains how to set up a graphical login using SSSD as well, but it requires the rest of this setup as a prerequisite.

  3. Create the new file openshift-proxy.conf in /etc/httpd/conf.d (substituting the correct host names where indicated): 

    LoadModule request_module modules/mod_request.so
LoadModule lookup_identity_module modules/mod_lookup_identity.so
# Nothing needs to be served over HTTP.  This virtual host simply redirects to
# HTTPS.
<VirtualHost *:80>
  DocumentRoot /var/www/html
  RewriteEngine              On
  RewriteRule     ^(.*)$     https://%{HTTP_HOST}$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
  # This needs to match the certificates you generated.  See the CN and X509v3
  # Subject Alternative Name in the output of:
  # openssl x509 -text -in /etc/pki/tls/certs/proxy.example.com.crt
  ServerName proxy.example.com

  DocumentRoot /var/www/html
  SSLEngine on
  SSLCertificateFile /etc/pki/tls/certs/proxy.example.com.crt
  SSLCertificateKeyFile /etc/pki/tls/private/proxy.example.com.key
  SSLCACertificateFile /etc/pki/CA/certs/ca.crt

  # Send logs to a specific location to make them easier to find
  ErrorLog logs/proxy_error_log
  TransferLog logs/proxy_access_log
  LogLevel warn
  SSLProxyEngine on
  SSLProxyCACertificateFile /etc/pki/CA/certs/ca.crt
  # It's critical to enforce client certificates on the Master.  Otherwise
  # requests could spoof the X-Remote-User header by accessing the Master's
  # /oauth/authorize endpoint directly.
  SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem

  # Send all requests to the console
  RewriteEngine              On
  RewriteRule     ^/console(.*)$     https://%{HTTP_HOST}:8443/console$1 [R,L]

  # In order to using the challenging-proxy an X-Csrf-Token must be present.
  RewriteCond %{REQUEST_URI} ^/challenging-proxy
  RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC]
  RewriteRule ^.* - [F,L]

  <Location /challenging-proxy/oauth/authorize>
    # Insert your backend server name/ip here.
    ProxyPass https://openshift.example.com:8443/oauth/authorize
    AuthType Basic
    AuthBasicProvider PAM
    AuthPAMService openshift
    Require valid-user
  </Location>

  <ProxyMatch /oauth/authorize>
    AuthName openshift
    RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER
  </ProxyMatch>
</VirtualHost>

RequestHeader unset X-Remote-User
    Copy to Clipboard Toggle word wrap
    Note

    Configuring Form-Based Authentication explains how to add the login-proxy block to support form authentication.

  4. Set a boolean to tell SELinux that it is acceptable for Apache to contact the PAM subsystem: 

    # setsebool -P allow_httpd_mod_auth_pam on
    Copy to Clipboard Toggle word wrap

  5. Start up Apache: 

    # systemctl start httpd.service
    Copy to Clipboard Toggle word wrap

12.2.5. Phase 3: OpenShift Enterprise Configuration
Copia collegamento

This section describes how to set up an OpenShift Enterprise server from scratch in an "all in one" configuration. Master and Node Configuration provides more information on alternate configurations.

Modify the default configuration to use the new identity provider just created. To do so:

  1. Modify the /etc/origin/master/master-config.yaml file.

  2. Scan through it and locate the identityProviders section and replace it with: 

      identityProviders:
  - name: any_provider_name
    challenge: true
    login: false
    mappingMethod: claim
    provider:
      apiVersion: v1
      kind: RequestHeaderIdentityProvider
      challengeURL: "https://proxy.example.com/challenging-proxy/oauth/authorize?${query}"
      clientCA: /etc/origin/master/proxy/proxyca.crt
      headers:
      - X-Remote-User
    Copy to Clipboard Toggle word wrap
    Note

    Configuring Form-Based Authentication explains how to add the login URL to support web logins.

    Configuring Extended LDAP Attributes explains how to add the email and full-name attributes. Note that the full-name attributes are only stored to the database on the first login.

  3. Start OpenShift Enterprise with the updated configuration: 

    # openshift start \
    --public-master=https://openshift.example.com:8443 \
    --master-config=/etc/origin/master/master-config.yaml \
    --node-config=/etc/origin/node-node1.example.com/node-config.yaml
    Copy to Clipboard Toggle word wrap

  4. Test logins: 

    oc login https://openshift.example.com:8443
    Copy to Clipboard Toggle word wrap

    It should now be possible to log in with only valid LDAP credentials.

12.3. Configuring Form-Based Authentication
Copia collegamento

12.3.1. Overview
Copia collegamento

This topic builds upon Setting up SSSD for LDAP Failover and describes how to set up form-based authentication for signing into the OpenShift Enterprise web console.

12.3.2. Prepare a Login Page
Copia collegamento

The OpenShift Enterprise upstream repositories have a template for forms. Copy that to your authenticating proxy on proxy.example.com: 

# curl -o /var/www/html/login.html \
    https://raw.githubusercontent.com/openshift/openshift-extras/master/misc/form_auth/login.html
Copy to Clipboard Toggle word wrap

Modify this .html file to change the logo icon and "Welcome" content for your environment.

12.3.3. Install Another Apache Module
Copia collegamento

To intercept form-based authentication, install an Apache module: 

 # yum -y install mod_intercept_form_submit
Copy to Clipboard Toggle word wrap

12.3.4. Apache Configuration
Copia collegamento

  1. Modify /etc/httpd/conf.modules.d/55-intercept_form_submit.conf and uncomment the LoadModule line.

  2. Add a new section to your openshift-proxy.conf file inside the <VirtualHost *:443> block. 

     <Location /login-proxy/oauth/authorize>
  # Insert your backend server name/ip here.
  ProxyPass https://openshift.example.com:8443/oauth/authorize

  InterceptFormPAMService openshift
  InterceptFormLogin httpd_username
  InterceptFormPassword httpd_password

  RewriteCond %{REQUEST_METHOD} GET
  RewriteRule ^.*$ /login.html [L]
</Location>
    Copy to Clipboard Toggle word wrap

    This tells Apache to listen for POST requests on the /login-proxy/oauth/authorize and to pass the user name and password over to the openshift PAM service.

  3. Restart the service and move back over to the OpenShift Enterprise configuration.

12.3.5. OpenShift Enterprise Configuration
Copia collegamento

  1. In the master-config.yaml file, update the identityProviders section: 

    identityProviders:
- name: any_provider_name
  challenge: true
  login: true
    1 
    
  mappingMethod: claim
  provider:
    apiVersion: v1
    kind: RequestHeaderIdentityProvider
    challengeURL: "https://proxy.example.com/challenging-proxy/oauth/authorize?${query}"
    loginURL: "https://proxy.example.com/login-proxy/oauth/authorize?${query}"
    2 
    
    clientCA: /etc/origin/master/proxy/proxyca.crt
    headers:
    - X-Remote-User
    Copy to Clipboard Toggle word wrap
    1
    Note that login is set to true, not false.
    2
    Newly added line.

  2. Restart OpenShift Enterprise with the updated configuration.

    Note

    You should be able to browse to https://openshift.example.com:8443 and use your LDAP credentials to sign in via the login form.

12.4. Configuring Extended LDAP Attributes
Copia collegamento

12.4.1. Overview
Copia collegamento

This topic builds upon Setting up SSSD for LDAP Failover and Configuring Form-Based Authentication and focuses on configuring extended Lightweight Directory Access Protocol (LDAP) attributes.

12.4.2. Prerequisites
Copia collegamento

  • SSSD 1.12.0 or later. This is available on Red Hat Enterprise Linux 7.0 and later.

  • mod_lookup_identity 0.9.4 or later.

    • The required version is not yet available on any version of Red Hat Enterprise Linux. However, compatible packages (RPMs) are available from upstream until they arrive in Red Hat Enterprise Linux.

12.4.3. Configuring SSSD
Copia collegamento

You need to ask System Security Services Daemon (SSSD) to look up attributes in LDAP that it normally does not care about for simple system-login use-cases. In the case of OpenShift Enterprise, there is only one such attribute: email. So, you need to:

  1. Modify the [domain/DOMAINNAME] section of /etc/sssd/sssd.conf on the authenticating proxy and add this attribute: 

    [domain/example.com]
...
ldap_user_extra_attrs = mail
    Copy to Clipboard Toggle word wrap

  2. Tell SSSD that it is acceptable for this attribute to be retrieved by Apache. Add the following two lines to the [ifp] section of /etc/sssd/sssd.conf: 

    [ifp]
user_attributes = +mail
allowed_uids = apache, root
    Copy to Clipboard Toggle word wrap

  3. Restart SSSD: 

    # systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
  4. Test this configuration.

12.4.4. Configuring Apache
Copia collegamento

Now that SSSD is set up and successfully serving extended attributes, configure the web server to ask for them and to insert them in the correct places.

  1. Enable the module to be loaded by Apache. To do so, modify /etc/httpd/conf.modules.d/55-lookup_identity.conf and uncomment the line: 

    LoadModule lookup_identity_module modules/mod_lookup_identity.so
    Copy to Clipboard Toggle word wrap

  2. Set an SELinux boolean so that SElinux allows Apache to connect to SSSD over D-BUS: 

    # setsebool -P httpd_dbus_sssd on
    Copy to Clipboard Toggle word wrap

  3. Edit /etc/httpd/conf.d/openshift-proxy.conf and add the following lines inside the <ProxyMatch /oauth/authorize> section: 

    <ProxyMatch /oauth/authorize>
  AuthName openshift

  LookupOutput Headers
    1 
    
  LookupUserAttr mail X-Remote-User-Email
    2 
    
  LookupUserGECOS X-Remote-User-Display-Name
    3 
    

  RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER
</ProxyMatch>
    Copy to Clipboard Toggle word wrap
    1 2 3
    Added line.

  4. Restart Apache to pick up the changes: 

    # systemctl restart httpd.service
    Copy to Clipboard Toggle word wrap

12.4.5. Configuring OpenShift Enterprise
Copia collegamento

Tell OpenShift Enterprise where to find these new attributes during login. To do so:

  1. Edit the /etc/origin/master/master-config.yaml file and add the following lines to the identityProviders section: 

    identityProviders:
 - name: sssd
 challenge: true
 login: true
 mappingMethod: claim
 provider:
   apiVersion: v1
   kind: RequestHeaderIdentityProvider
   challengeURL: "https://proxy.example.com/challenging-proxy/oauth/authorize?${query}"
   loginURL: "https://proxy.example.com/login-proxy/oauth/authorize?${query}"
   clientCA: /home/example/workspace/openshift/configs/openshift.example.com/proxy/proxyca.crt
   headers:
   - X-Remote-User
   emailHeaders:
    1 
    
   - X-Remote-User-Email
    2 
    
   nameHeaders:
    3 
    
   - X-Remote-User-Display-Name
    4
    Copy to Clipboard Toggle word wrap
    1 2 3 4
    Added line.

  2. Launch OpenShift Enterprise with this updated configuration and log in to the web as a new user.

    You should see their full name appear in the upper-right of the screen. You can also verify with oc get identities -o yaml that both email addresses and full names are available.

12.4.6. Debugging Notes
Copia collegamento

Currently, OpenShift Enterprise only saves these attributes to the user at the time of the first login and does not update them again after that. So, while you are testing (and only while testing), run oc delete users,identities --all to clear the identities out so you can log in again.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat