Configure SSSD to work on IPv6-only Hosts

SSSD is used for the client side of IPA and other centralized Identity Management Services. Unfortunately it does not behave as it should. The default is to look up first IPv4 addresses and if that fails IPv6 should be used. Well, if IPv4 fails, the whole request fails and you got weird error messages when joining an IPA domain.

As the pool for IPv4 addresses is depleted, IPv6 is getting more and more important. Thus, IPv6-only hosts are on the rise.

Here is an example error message from the IPA client.

[root@ipv6host ~]# ipa-client-install
[output ommited] 
SSSD enabled
Configured /etc/openldap/ldap.conf
Unable to find 'admin' user with 'getent passwd'!
Unable to reliably detect configuration. Check NSS setup manually.
[output ommited]

The host itself gets properly joined to the IPA domain and authentication works with Kerberos but you can not log in because SSSD fails.


Configure SSSD to only use IPv6. This is done in /etc/sssd/sssd.conf

lookup_family_order = ipv6_only
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain =
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname =
chpass_provider = ipa
ipa_server = _srv_,
ldap_tls_cacert = /etc/ipa/ca.crt
services = nss, sudo, pam, ssh

domains =
homedir_substring = /home








At the moment there is no solution yet (just the workaround described), but its addressed at the SSSD project team, as you can see in and

Happy IPv6-ing 🙂

Secure your system with SELinux

SELinux Logo

SELinux Logo

Introduction to SELinux

SELinux is well known as the most sophisticated Linux Mandatory Access Control (MAC) System. If you install any Fedora or Redhat operating System it is enabled by default and running in enforcing mode. So far so good.

Its available for many years and its not rocket science to use it. This article is supposed to give you some hints how to make your system even more secure and how to solve some troubles SELinux may have on your system.


Linux and traditional Unix systems are using DAC (Discretionary Access Control). Every user can change access rights to its own files. SELinux is a MAC (Mandatory Access Control) System where access rights are ruled by system wide policies. This can cause confusion when access is denied to a resource. Be aware that DAC will kick in before SELinux policies do. So if access to a resource is denied, please check access rights first. In such a case you will not see any AVC denials in your logs. The return code (EACCES) is the same.


There is plenty of information available in the man pages. Some of the configuration file examples also contains additional information.

server:~# man -k selinux

Gives a good overview

Stick to Standards

Sofware installed from a RHEL or Fedora repository is usually not a problem at all, as long as you are using standards for config files, data, ports etc. Stick to the standards wherever possible. I.e. It does not make any sense to store websites in /opt instead of /var/www/html

Standards do not work for you?

If you can not stick to the standards for whatever reason, you can adjust a lot of settings with semanage.

Adding an allowed TCP Port for Apache

If you want to run your Apache httpd on port 8010, Apache will not start and a SELinux AVC denial is filed. To check which ports are allowed for Apache run:

server:~# semanage port -l|grep http_port_t
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000

There is nothing like 8010

You can simply add port 8010 to the allowed ports by running

server:~# semanage port -a -t http_port_t 8010 -p tcp

Check again:

server:~# semanage port -l|grep http_port_t
http_port_t                    tcp      8010, 80, 81, 443, 488, 8008, 8009, 8443, 9000

VoilĂ !

Using a non-standard location for HTML files

Lets assume you want to store your HTML files in /opt/srv. To do so, you need to change the file context of that path and restore the file context afterwards.

server:~# semanage fcontext -a -t httpd_sys_rw_content_t '/opt/srv(/.*)?'
server:~# restorecon -R -v /opt/srv

Make use of Boolean variables

There are plenty of bool variables which simple allows to turn on or off a particular protection.

To get a list of defined bools, run

server:~# getsebool -a

You may want to pipe it to less or grep for a search pattern.

As an example, the default behavior is that a web application running in the httpd_t context will not be allowed to send emails. That helps greatly to prevent a vulnerable web application to send out SPAM. Well, if you want to operate a web mail service Apache must be able to send emails. No big deal:

server:~# setsebool -P httpd_can_sendmail on


The are some CLI (and GUI) tools available to troubleshoot AVC denials. The most important is sealert. Here is an example of an AVC because of a mislabled file in /var/www/html

sealert -a /var/log/audit/audit.log
SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/www/html/test.html
*****  Plugin restorecon (99.5 confidence) suggests   ************************
If you want to fix the label. 
/var/www/html/test.html default label should be
Then you can run restorecon.
# /sbin/restorecon -v /var/www/html/test.html

As you can see, sealert already provides you a hint how to fix the problem. In more complex cases, audit2why and audit2allow will help you. You simply grep for the misbehaving process:

server:~# grep httpd /var/log/audit/audit.log |audit2allow -m my_local_module

Review the result to check if it makes sense (ensure your grep statement does not catch too much). If you’re confident its okay, run the same command again with a capital M as parameter. It will create you a Local Policy Module which can be inserted:

server:~# grep httpd /var/log/audit/audit.log |audit2allow -M my_local_module
server:~# semodule -i my_local_module.pp

Temporary mitigation of SELinux troubles

If sealert and audit2allow can not immediately solve your problems and you quickly need to get your service up and running again, temporary put your system in permissive mode.

server:~# setenforce permissive

It will stay in pemissive mode until you reboot your system.

Permissive mode does not enforce the SELinux policies, it just logs AVC denials and help you to solve the problems without any service interruption. Be aware: This is a temporary quick fix, not a solution.

Put the affected domain only into permissive mode

If all your investigation did not help, all answers from support did not helped (very unlikely) you can put a particular domain into permissive mode. The rest of the policies are still in enforcing mode, your system still have some protection.

As an example, you can put the Apache module into permissive mode:

server:~# semanage permissive -a http_t

Hardening your System

Most people are not aware of the fact that when a system is in enforcing mode a malicious user with root access can manipulate policies or put SELinux into permissive mode.

There is a method to prevent this: Lock down your system

server:~# setsebool -P secure_mode_policyload on

Be aware: Once active nothing can not be changed during runtime, you need to reboot your system and provide selinux=1 enforcing=0 as grub boot parameter to be able to change any SELinux settings.

Have some fun!

Download “The SELinux Coloring Book” and learn more 🙂

Further reading

Have fun 🙂

Install and configure DKIM with Postfix on RHEL7

Signed Email


DKIM (Domain Keys Identified Mail) is a measure against email spoofing, Phishing and SPAM mails. Its easy to implement as you will learn in this article.

DKIM signs emails on the outgoing SMTP server, the receiving SMTP can verify the signature by looking up the mail._domainkey TXT DNS record of the respective domain to check if the email originates from that domain or if it is forged.

This howto can be used to implement DKIM on a SMTP server responsible for both, in- and out-going mails.

It has been standardized in 2007 as the successor of DomainKeys introduced by Yahoo in 2004. The latest standard revision is defined in defined in RFC 6376.


  • A running Postfix SMTP server
  • Access to the RHEL 7 Optional Software Channel/Repo (rhel-x86_64-server-optional-7)
  • EPEL repository available

Installing the Software

The dependencies will be installed automatically

mail:~# yum -y install opendkim

Enable DKIM on system startup

mail:~# systemctl enable opendkim.service

Configure OpenDKIM

Add/Uncomment the following lines in /etc/opendkim.conf

Socket inet:12341@localhost # Choose any free services number
Mode    sv
KeyTable        /etc/opendkim/KeyTable
SigningTable    refile:/etc/opendkim/SigningTable
InternalHosts   refile:/etc/opendkim/TrustedHosts
SignatureAlgorithm      rsa-sha256


In this file you configure a whitelist which domains and/or IP addresses are considered as trusted. This is usually just localhost.


Here the definition of your private key is set up


Here comes the definitions of email address patterns


Create the keypair

mail:~# mkdir /etc/opendkim/keys/
mail:~# cd /etc/opendkim/keys/
mail:~# opendkim-genkey -s mail -d
mail:~# chown opendkim:opendkim mail.private

The file /etc/opendkim/keys/ contains the public key which must be added to a DNS server authoritative for the domain. It looks as following:

mail._domainkey IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9grq0kphBEtp9biB09/X0rS42s87yHbxq4DsR0SYBNGTdendDzsFaGZeQMu0bGkY488Jm2OjmT4vXBy7FvTdqFIUKvKWXl0uKbH6nn0NcJe/Q71YnmNsGI1/EFa+YXIHqdbUjCVoQOzXQ1UiB+jZiw/G0Hhs45FW9sR8LFwaj6QIDAQAB" )  ; ----- DKIM key mail for

If you are running (Free)IPA or Redhat Identity Management responsible as a DNS server, do the following:

[root@ipa1 ~]# ipa dnsrecord-add --txt-rec="p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9grq0kphBEtp9biB09/X0rS42s87yHbxq4DsR0SYBNGTdendDzsFaGZeQMu0bGkY488Jm2OjmT4vXBy7FvTdqFIUKvKWXl0uKbH6nn0NcJe/Q71YnmNsGI1/EFa+YXIHqdbUjCVoQOzXQ1UiB+jZiw/G0Hhs45FW9sR8LFwaj6QIDAQAB" mail._domainkey

Configure Postfix

Thanks to Postfix Milter Implementation its a nobrainer to configure postfix:

mail:~# postconf milter_protocol=2
mail:~# postconf milter_default_action=accept
mail:~# postconf smtpd_milters=inet:localhost:12341
mail:~# postconf non_smtpd_milters=inet:localhost:12341

Restart the Services

mail:~# systemctl restart opendkim.service
mail:~# systemctl restart postfix.service


Write an email to to test your set up. A few seconds later you will get an automated response which shows the results.

Do not get confused by DomainKeys check: neutral in the test results, they are for the legacy Yahoo DomainKeys. The important stuff is DKIM.

You can also write your self an email and check the source of it, it will be looking simulat to this:

Return-Path: <>
Received: from (unknown [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	(Authenticated sender:
	by (Postfix) with ESMTPSA id 3D1CFA34
	for <>; Sun, 19 Feb 2017 17:20:37 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 3D1CFA34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail;
	t=1487521237; bh=asdfasdfasasdfasfasdfsadfsdaf=;
From: Joe Doe <>
Subject: test

Read further

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.