OpenID and SAML authentication with Keycloak and FreeIPA

Not every web application can handle Kerberos SSO, but some provide OpenID and/or SAML. There is how Keycloak comes into the game. You can use Keycloak to federate users from different sources. This guide shows how to integrate Keyclock and FreeIPA to authenticate users in WordPress. On clients that are enrolled in IPA, this even works without a password, a Kerberos ticket is good enough to log in.

What is Keycloak

Keycloak is the upstream project for Red Hat SSO. It is a JBoss application that can federate users from various LDAP servers such as 389-Server, OpenLDAP and also MS Active Directory. It provides Single Sign On (SSO) for web application capabilities with OpenID and SAML2.

A very nice feature is the capability of using Kerberos tickets from clients that makes password based authentication obsolete.


I’ll describe how to set up the commercially supported products provided by Red Hat, namely RHEL8 and Red Hat SSO. It is expected to work as well with the upstream projects, but please be aware that upstream products never provide formal commercial support.

  • A base installation of RHEL8
  • A subscription for RHEL8 and JBoss EAP
  • A configured and working FreeIPA/Red Hat IdM environment (optional)
  • An instance of WordPress or any other OpenID enabled Webapplication (optional)

The system requirements for a very basic setup are rather small. 2 Gbyte of RAM and 50 Gbyte of disk is more than enough.

Be aware that Red Hat SSO comes with a basic Database called H2. That is not suited for larger production environment. For production environments, user PostgreSQL instead. For better scalability and availability you also should consider to create a cluster of SSO instances using the same shared Database. External Database and Clustering is out of scope in this document, it may be covered in a later article.

This setup is also using a Letsencrypt x509 certificate and makes use of an Apache HTTP based reverse Proxy for better handling of certificates and access control.


Ensure you have the following yum repositories available:

  • JBoss Enterprise Application Platform 7.2 RHEL 8 RPMs x86_64
  • Red Hat CodeReady Linux Builder for RHEL 8 x86_64 RPMs x86_64 8
  • Single Sign-On 7.3 for RHEL 8 x86_64 RPMs x86_64
subscription-manager repos --enable=jb-eap-7.2-for-rhel-8-x86_64-rpms --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=codeready-builder-for-rhel-8-x86_64-rpms

The next step is to install the yum packages needed

yum install rh-sso* httpd mod_ssl socat

Install the acme shell script for Letsencrypt certificate handling:

curl | sh

Enable firewall

It is recommended to make use of an host based firewall, its simple:

# HTTP is used for letsencrypt only
firewall-cmd --add-service=http --permanent

# Needed for the reverse proxy
firewall-cmd --add-service=https --permanent
firewall-cmd --reload

Reverse Proxy configuration

Apply the following patch to make Red Hat SSO aware of the proxy usage:

--- /etc/opt/rh/rh-sso7/keycloak/standalone/standalone.xml.orig 2019-04-02 03:31:07.480115492 +0000
+++ /etc/opt/rh/rh-sso7/keycloak/standalone/standalone.xml      2019-04-02 03:32:45.946964803 +0000
@@ -464,7 +464,8 @@
         <subsystem xmlns="urn:jboss:domain:undertow:7.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
             <buffer-cache name="default"/>
             <server name="default-server">
-                <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
+                <!-- <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/> -->
+               <http-listener name="default" socket-binding="http" proxy-address-forwarding="true" redirect-socket="proxy-https" />
                 <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
                 <host name="default-host" alias="localhost">
                     <location name="/" handler="welcome-content"/>
@@ -575,6 +576,8 @@
         <socket-binding name="https" port="${jboss.https.port:8443}"/>
         <socket-binding name="txn-recovery-environment" port="4712"/>
         <socket-binding name="txn-status-manager" port="4713"/>
+       <!-- added for reverse proxy -->
+       <socket-binding name="proxy-https" port="443"/>
         <outbound-socket-binding name="mail-smtp">
             <remote-destination host="localhost" port="25"/>

Enable and start the Apache HTTPd

systemctl enable httpd
systemctl start httpd

Obtain a certificate --issue -d -w /var/www/html

Install the certificate

/root/ --install-cert -d \
--cert-file      /etc/pki/tls/certs/sso.example.cert  \
--key-file       /etc/pki/tls/private/  \
--fullchain-file /etc/pki/tls/certs/fullchain.pem

Configure Apache

Edit /etc/httpd/conf.d/ssl.conf and change the certifcate configuration to point to the Letsencrypt certificates:

SSLCertificateFile /etc/pki/tls/certs/fullchain.pem
SSLCertificateKeyFile /etc/pki/tls/private/

Reverse Proxy config

ProxyPreserveHost On
SSLProxyEngine On
SSLProxyCheckPeerCN on
SSLProxyCheckPeerExpire on
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
ProxyPass /
ProxyPassReverse /

Ensure Apache is allowed to do network connections:

setsebool httpd_can_network_connect on -P

Restart Apache HTTPd

systemctl restart httpd

Final steps for Red Hat SSO

Enable and start Red Hat SSO

systemctl enable rh-sso7.service
systemctl start rh-sso7.service

To be able to login in into SSO, you need to create a local user.

/opt/rh/rh-sso7/root/usr/share/keycloak/bin/ -u admin

You are now able to log in to Red Hat SSO with your favorite browser.

Integration with Red Hat IdM

Ensure your SSO server is enrolled in the IPA domain. There is some preparation work to do such as creating a Kerbros Service Principal for the HTTP server and fetch the Kerberos Keytab.

Create the Kerbros Service Pricipal

ipa service-add HTTP/

Fetch the Keytab

ipa-getkeytab -p HTTP/ -s -k /etc/krb5-keycloak.keytab

Set correct permissions for the Keytab

chown root /etc/krb5-keycloak.keytab
chgrp jboss /etc/krb5-keycloak.keytab
chmod 640 /etc/krb5-keycloak.keytab

User federation

User federation with IPA is the second important step. It is slightly different to the nomal LDAP federation.

Point your bowser to and click on “Add provider” and select LDAP. Fill out the form as follow:

“Edit Mode” READ_ONLY
“Vendor” Red Hat Directory Server
“Username LDAP Attribute” uid
“RDN LDAP attribute” uid
“UUID LDAP attribute” ipaUniqueID
“User Object Class” inetOrgPerson, organizationalPerson
“Connection URL” ldaps://
“Users DN” cn=users,cn=accounts,dc=example,dc=com
“Authentication Type” simple
“Bind DN” uid=binduser,cn=sysaccounts,cn=etc,dc=example,dc=com
“Bind Credential” your super secret password

“Allow Kerberos authentication” to On
“Kerberos Realm” EXAMPLE.COMA
“Server Principal” HTTP/
“Keytab” /etc/krb5-keycloak.keytab
“Use Kerberos For Password Authentication” On

Or have a look at the screenshot

SSO-IdM Federation

The next step is more or less cosmetic, the mapping of attributes. Go to the newly created federation provider and click in th “Mappers” tab, click on “First Name” and change “LDAP Attibute” to “givenName”.

Thats it.

Registering a client

Point your browser to

Choose a client ID, i.e. “wordpress” and provide the Root URL, i.e.

Creating a initial access token

Point your browser to and click on save.

You will get the token displayed. Be aware that this token shows only once, copy and paste it to a secure place.

Enable WordPress for OpenID and connect it to Red Hat SSO

Point your brower to to search for the Plugin “OpenID Connect Generic” and click on “Install Now”.

OpenID Setup

Point your browser to

Fill in the form as shown in the below screenshot. The “Client ID” and “Client Secret Key” corresponds to the previously defined ID and “initial Access Token” defined in Red Hat SSO before.

SSO in WordPress

Click on “save”, log out, log in again and client on the “Login with OpenID Connect”. You will get redirected to the Red Hat SSO login form, or in case you have a Kerbros Ticket, your are automatically logged in to WordPress.

Be aware that every user in Red Hat IdM will be able to login to WordPress in the role “Subscriber”. You need to promote them to another role manually.

This Guide is only about authentication, not about authorization. This will be covered in a separate article somewhere in the future.

Feedback is always welcome. Have fun 🙂

Integrate Dovecot IMAP with (Free)IPA using Kerberos SSO

Dovecot can make use of Kerberos authentication and enjoying Single-Sign-On when checking emails via IMAP. This post shows you how you enable this feature. With IPA its rather simple to do so.

First enroll your mail server to the IPA domain with ipa-client-install as described in various previously posted articles.

Creating a Kerberos Service Priciple

Ensure you have a Kerberos ticket as admin user

ipa1:~# kinit admin
Password for admin@EXAMPLE.COM: 
ipa1:~# ipa service-add imap/
Added service "imap/"
  Principal name: imap/
  Principal alias: imap/
  Managed by:

Fetch and install the Kerberos Keytab for Dovecot

Log in to your mailserver and get a Kerberos ticket as well:

mail:~# kinit admin
Password for admin@EXAMPLE.COM: 

Fetch the Keytab:

mail:~# ipa-getkeytab -s -p imap/ -k /etc/dovecot/dovecot-krb5.keytab
Keytab successfully retrieved and stored in: /etc/dovecot/dovecot-krb5.keytab

A common mistake is to have the wrong ownership and access rights on the keytab file.

mail:~# chown dovecot:dovecot /etc/dovecot/dovecot-krb5.keytab
mail:~# chmod 600 /etc/dovecot/dovecot-krb5.keytab

Edit the following lines in /etc/dovecot/conf.d/10-auth.conf

auth_krb5_keytab = /etc/dovecot/dovecot-krb5.keytab
auth_mechanisms = plain gssapi login
auth_gssapi_hostname =
auth_realms = EXAMPLE.COM
auth_default_realm = EXAMPLE.COM

A note about auth_mechanisms: Usually you dont want to use Kerberos only authentication but plain (over TLS/SSL) as well.


In /var/log/maillog check if you see messages similar to this:

Feb 19 11:43:25 mail dovecot: imap-login: Login: user=, method=GSSAPI, rip=, lip=, mpid=5195, TLS, session=<asdfasdfasdf>

How about LDAP?

Since identity lookup is done with sssd, LDAP integration is not needed in such a case, there is not benefit using LDAP.

FreeIPA and Selective 2FA with Kerberos Authentication Indicators

One of the major new features in FreeIPA 4.4 is the introduction of Authentication Indicators in Kerberos tickets. This allows you to selectively enforce 2FA.


Usually a Linux environment consists on a lot of different services. Some of them are security sensitive such as payroll systems while others are more relaxed such as simple Intranet Webservers.

Some services do not nicely play with 2FA, see /2015/04/09/2fa-with-free-ipa-the-good-the-bad-and-the-ugly/. With Authentication Indicators you can allow users accessing this services without 2FA while deploying 2FA on all other services.

One of the obstacles for 2FA is user acceptance. With selective 2FA you can enforce it on the critical servers and/or services only.


At the moment, selective 2FA with Authentication Indicators is only working with Fedora 24 and 25. There is no support (yet) for RHEL and its EL clones such as CentOS. Support for Authentication was added in SSSD 1.14, please also see the Release notes for SSSD 1.14.

At the moment, users on RHEL clients always need to provide the second factor. This probably will change for RHEL 7.3. Please also see Bugzilla #1290381. It is already included in public Beta.

Testing the new release

FreeIPA 4.4.2 is available in Fedora 25 Beta. SSSD 1.14 is available on Fedora 24 and newer and in RHEL 7.3 Beta.

Installing FreeIPA 4.4

Get Fedora 25 Beta and install four servers with it. (two replicas, two clients). Fedora 25 Beta can be downloaded here.

[root@ipa1 ~]# dnf -y install freeipa-server freeipa-server-dns

Dependencies will be resolved automatically.

Configure FreeIPA

For tests only, you can disable firewalld to avoid connectivity problems.

[root@ipa2 ~]# systemctl stop firewalld
[root@ipa2 ~]# systemctl disable firewalld

Note: the –allow-zone-overlap is only needed if you make tests with existing DNS domains such as Usually you should not use this parameter to not violate the highlander principle.

[root@ipa1 ~]# ipa-server-install --subject="O=EXAMPLE.COM 2016101501" --allow-zone-overlap --setup-dns --forwarder= --forwarder= 

Install a replica

The second replica is first set up as a normal IPA Client and will then be promoted to be a replica.

Be sure you point your DNS to the first replica to allow detection of SRV DNS entries to correctly setup the client.

[root@ipa2 ~]# dnf -y install freeipa-server freeipa-server-dns 

Now setup the replica as a client

[root@ipa2 ~]# ipa-client-install

Get a Kerberos Ticket as admin user

[root@ipa2 ~]# kinit admin

Promote to be a replica

[root@ipa2 ~]# ipa-replica-install --setup-dns --setup-ca --forwarder= --forwarder=

Enroll two or more clients

For our tests we need some clients, enroll some

Enable 2FA Authentication

As a default, 2FA is not enabled, lets change that

[root@ipa2 ~]# ipa config-mod --user-auth-type={password,otp}

Add some users

Add one or more users and set a password. Log in and set a new valid password

To be able to authenticate with both, Password only and 2FA, we need to provide that information when creating a new user. You also need to set an initial password.

[root@ipa2 ~]# ipa user-add --user-auth-type={password,otp} --first Joe --last Doe --shell=/bin/bash jdoe
[root@ipa2 ~]# ipa passwd jdoe

Get a Kerberos Ticket for jdoe, you will be promted to set a new password.

[root@ipa2 ~]# kinit jdoe
Password for jdoe@EXAMPLE.COM: 
Password expired.  You must change it now.
Enter new password: 
Enter it again: 
[root@ipa2 ~]# 

Add a 2FA Soft token

You can assign yourself a soft token with the CLI or WebUI.

[root@ipa2 ~]# ipa otptoken-add jdoe
Added OTP token "jdoe"
  Unique ID: jdoe
  Type: TOTP
  Owner: jdoe
  Manager: jdoe
  Algorithm: sha1
  Digits: 6
  Clock interval: 30
  URI: otpauth://totp/jdoe@EXAMPLE.COM:jdoe?digits=6&secret=NOBAETXGLCVEW7BSINC6II4XLSPTFPDK&period=30&algorithm=SHA1&issuer=jdoe%40EXAMPLE.COM

████ ▄▄▄▄▄ ██  ▀▄▄▀▄▄█▄█ ▀█ ▄▀█▀█▀ ▄█▄█▄  ▀▀ █ ▄▄▄▄▄ ████
████ █   █ █  ▄▀▄█▀ ▄▀█▀██▄▄ ▀▀ ▀█▄ ▀   ▀▀█ ▄█ █   █ ████
████ █▄▄▄█ █  ▀▀▀  ▀█▄ ▀█▄ ▄▄▄ ▄▄▀▀▀▄▀▀▀▀ ▀███ █▄▄▄█ ████
████▄▄▄▄▄▄▄█ ▀▄▀ █ █ █ █▄▀ █▄█ ▀ ▀ ▀▄▀▄█▄▀ █ █▄▄▄▄▄▄▄████
████▄▀▄▄ ▄▄██▀▀███▄▄▄▀▄▀██    ▄█▀ ▀ ▄ ▀█ ▀██▄█ ▄▄ ▄██████
████ ▀  ▄▄▄▄ ▀▀█▄▀▄█ ▀▀ ▀▄▄█▄█▀  ▄▀▄ ▄█▄▄█▄█▄ ▀█▀██▄▀████
████▄▀ ▄▀▄▄▄████▄ ██ ▄█▀▀▄ ▄▄██ █ █▄█▄  ▄▄▄█▀▀ ▀▀█▀ █████
████  ▄▀▀█▄▄██▀▄██▀▄▄▀▄▀ ▄ ▄▀█▄ █ ▄███ ▄▀  ▀▄▀▀▄▀ ▀ ▄████
█████▄ █▀▀▄▄▄▄ █  ▀▄█▄▀█ ▄▀█▄▄▀▀ ▀█▄ ▄ ▄█    ▀█▀ ▄▄▄█████
████  ▄   ▄▀▄ █▀█ █▀██  ▄ ▀▄█▀▀▀▄▀ ▄▄▄█▄▀ █▄▀▀  ▀▄█ ▀████
████ ▀▀ ▄▀▄▀▄█▄ ▄  ▀▀ █▀ ▄███▀ ▄ ▄▀█ ▄█▄█▀█ ▄██ ██ ▄▀████
████▀▀   ▄▄▄  ▀ ▀  ██▀  ██ ▄▄▄  █▄█ █▄▄▄▄▀ █ ▄▄▄ ▀█  ████
████▀▀▀▄ █▄█ █▄██▄▄▄ ▀█▀ ▀ █▄█  ▀ ▀ ▄▄█▀█▀▄█ █▄█  ▄▄█████
█████▄█▄▄ ▄  █▀▀█     ▄ ▄▄ ▄ ▄▄▄▄█▀█ ▄▄▄▄███    ▄▄▄▀ ████
████▄███▀█▄ ▀ ▄▄▀▄▀▀ ▄█▄██▄▀▄█▄███▀██▀▄█ ▄▄▄ ██▀█▄▄▄█████
████ ▄▀▄██▄▄▄▄██▄▀▀   ▀▄█▀█▀█▀█▄▄█ ▀█ ▄█ █▀▀▀▄█▀▄ █▄ ████
████▀█▄█▀▄▄█▄▀ ▀ ▀█▄▄▄▀▀█ ▀█▀█▄▄█▄ ▀█▀██ ▄ ▄▀█▀ █ █▄ ████
████▀█▀█▀▄▄▄██ ▀▀██▀ ▀▀▀ ▄▀ ▄█▄▄█▄▄███▀▀ ▀ ▄▀▀▄▀▄▄██▀████
████▀▄██ ▀▄█▀█ ▀   ▀▀█▄▄▀▄ ▄▄▄██ ▄▀ ▀█▄█▄ ▄▄▀▄ ▀▄▄  ▀████
█████ ▀▀█▄▄▀ █  ▄▄█▄█▀ ███▄▄▄▄▄█ ▄ ▄█▄▄▄   ██▄▀▀   ▄▄████
████▄▄▄███▄▄▀█   ███▄▀▀█ ▄ ▄▄▄ ▄█▀  ██ ███▀  ▄▄▄ ▄██ ████
████ ▄▄▄▄▄ █▀█▄▄▄ ▄▀▄██▀▀▀ █▄█ ▀ █▀▄█▄▄ ██▄▀ █▄█ ▀▄█▀████
████ █   █ █ ▄█▀▄  █▄▄▄▀▀  ▄ ▄▄█▄▀▀ █  ▄ ▀▄█     ▄▀ ▀████
████ █▄▄▄█ █▄▀▄▀█▄  █ ▀▀ ▀▄█▀▄█ █▀▄▄██▀ ▄█▄▄ ▀█ █▄ █ ████

[root@ipa2 ~]# 

You can add this QR code with the FreeOTP or Google Authenticator

Enforcing 2FA on a host principal

To enforce 2FA on a host, alter the host configuration as follows:

[root@ipa2 ~]# ipa host-mod  --auth-ind=otp

You now can try to log in with one and two factors on that host and on some other hosts to see the difference.

Enforcing 2FA on a service

Enforcing of 2FA can also be done on a single (Kerberized) service.

[root@ipa2 ~]# ipa service-mod --auth-ind=otp http/

Further reading

There are plenty of documents available on the internet, here is a choice:

Have fun 🙂

Integrate IPA in your Web application i.e. WordPress

Tired of log in to your favorite Web application? Integrate it with IPA, kerberize it! This blog post will guide you trough the kerberization of WordPress running on RHEL7 or Fedora. The magic is done by mod_intercept_form_submit and mod_auth_gssapi


  • You have a running IPA or FreeIPA infrastructure
  • Your Kerberos REALM is EXAMPLE.COM
  • The hostname where your WordPress instance is running is
  • WordPress is installed in /var/www/html and ready to run
  • You are using a Linux Workstation with Kerberos, other client OS may or may not work
    • Result

      You can log in to your WordPress instance with a Kerberos enabled Web Browser and username/password with Browser not enabled. The access is restricted by HBAC (Host Base Access Control)

      Install the required software

      root@wptest ~]# yum -y install ipa-client mod_intercept_form_submit mod_auth_gssapi
      root@wptest ~]# setsebool -P allow_httpd_mod_auth_pam 1
      root@wptest ~]# wget

      Ensure the modules are loaded by Apache, please check the files in /etc/httpd/conf.modules.d/. The WordPress plugin is needed to enable WordPress to make use of the REMOTE_USER server environment. Unzip and place it in /var/www/html/wp-content/plugins/ and run restorecon to relabel the content to be able to use SELinux in enforcing mode.

      root@wptest ~]# unzip
      root@wptest ~]# mv http-authentication /var/www/html/wp-content/plugins/
      root@wptest ~]# restorecon -v -R /var/www/html/

      Enroll your Linux server

      Of course your server must be enrolled with IPA.

      root@wptest ~]# ipa-client-install

      Get your Kerberos Keytab

      First the Kerberos service principal must be created. Go to one of your IPA servers and add the principal.

      root@ipa1 ~]# kinit admin
      root@ipa1 ~]# ipa service-add HTTP/

      Go to the client, fetch the Kerberos Keytab and make it available for Apache

      root@wptest ~]# kinit admin
      root@wptest ~]# ipa-getkeytab -s -p HTTP/ -k /etc/httpd/conf/http.keytab
      root@wptest ~]# chown apache /etc/httpd/conf/http.keytab
      root@wptest ~]# chmod 600 /etc/httpd/conf/http.keytab

      Configure PAM

      We are going to create a PAM config file called “wordpress” as a requirement for the authentication method used. Remember, you need to use SSSD because want to make use of HBAC.

      cat << EOF >> /etc/pam.d/wordpress
      auth    required
      account required

      Hacking WordPress

      After the configuration of Apache, non-kerberized logins would not work anymore. This is probably not a scenario you want. You will still be able to log in with your IPA credentials, HBAC still works.

      The trick is that if Kerberos authentication fails, you will be redirected to a non-kerberized login page.

      [root@wptest ~]# cp /var/www/html/wp-login.php /var/www/html/wp-login2.php
      [root@wptest ~]# sed -i s/wp-login.php/wp-login.php /var/www/html/wp-login2.php
      [root@wptest ~]# restorecon -v /var/www/html/wp-login2.php

      Configure Apache

      The two different modules must be configured to get ready to use.

      Important to know: the parameters InterceptFormLogin and InterceptFormPassword are containing the name of the user and password input field name of the form, as defined in the HTML code. I.e. <input type=”text” name=”log” id=”user_login” …

      cat << EOF >> /etc/httpd/conf.d/intercept_form_submit.conf
      <LocationMatch ^/wp-login.php>
        InterceptFormPAMService wordpress
        InterceptFormLogin log
        InterceptFormPassword pwd
      <LocationMatch ^/wp-login2.php>
        InterceptFormPAMService wordpress
        InterceptFormLogin log
        InterceptFormPassword pwd

      The next configuration files is for the mod_auth_gssapi

      The interesting part is the ErrorDocument where you tell the browser to redirect to the previously created wp-login2.php form. Since that form is only protected by mod_intercept_form_submit there will be no Kerbros authentification and prompting the user for the username and password.

      cat << EOF >> /etc/httpd/conf.d/auth_gssapi.conf
      <Location "/wp-login.php">
        AuthType GSSAPI
        AuthName "Kerberos Login"
        GssapiCredStore keytab:/etc/httpd/conf/http.keytab
        GssapiCredStore client_keytab:/etc/httpd/conf/http.keytab
        GssapiDelegCcacheDir /var/run/httpd/clientcaches
        GssapiUseS4U2Proxy on
        Require pam-account wordpress
        ErrorDocument 401 '<html><meta http-equiv="refresh" content="5; URL=/wp-login2.php"><body><h1>Kerberos authentication did not pass</h1><h2>Make sure your browser is configured correctly and you got a Kerberos Ticket.</h2></body></html>'

      Configure the WordPress plugin

      Point your Browser to and set the following Parameters:

      • Allow WordPress authentication -> Enabled
      • Automatically create accounts -> Enabled
      • Email address domain -> Whatever the users domain is

      Now point your browser to And select the default role of the users being created when logging in the first time.

      Create a HBAC rule

      Usually you want to create a HBAC rule to i.e. allow only certain users or group(s) of users to log in.
      Some time ago I wrote an article on how to do so.

      Restarting Apache

      Now it is time to restart your Apache Server to activate the settings.

      [root@wptest ~]# systemctl restart httpd.service

      Configure Firefox

      To be able to use Kerberos with Firefox, you need to set a few options. Please point your browser to one of your IPA repliacas, i.e.”

      Useful Links

      Have fun 🙂 Feedback welcome..