Posts Tagged ‘LDAP’

2FA with (Free) IPA. The good, the bad and the ugly

Thursday, April 9th, 2015

Two factor authentication (2FA) is more and more emerging which is good to enhance security. Since the release of IPA4 it comes with 2FA included.

Over time I made a lot of experiments and experience I wanted to share with you. Its is easy to set up and maintain as long as you use it only for system authentication. If you are using such things as webmail, it fails. This post shows you the capabilities as they are of today. Almost all bad issues apply not only to Fee(IPA) but 2FA in general.

The good
All your systems are Fedora 21, RHEL 7.1 or Ubuntu 14.02 all is working fine as the included SSSD is new enough to handle 2FA. All kerberized services can be used with 2FA w/o logging in again during the validity of your Kerberos ticket. Very convenient, very secure.

3rd Party applications can use LDAP authentication (Depending on the usecase)

The bad
Systems with older distributions such as RHEL6.6 come with a SSSD version which is to outdated to handle kerberized 2FA at all. This will probably change soon.


  • Use LDAP authentication (See later on)
  • Use a Jump host with a recent Linux distribution

If you are logging in to your workstation with a local user, you can not grab a Kerberos ticket with kinit and use this ticket further on. (i.e for ssh logins on remote server, mail etc.)


  • Switch to a IPA managed user if your workstation is recent enough.
  • Use a Jump host with a recent Linux distribution
  • Wait until krb5-PAKE is in place, software is being developed, see and
    • The ugly

      Looks like most mobile applications such as the IMAP client in Android do not prompt for the password, they expect it configured. Needless to say that you can not reconfigure the password each time you want to check your emails with your phone.


      • 3rd party email app? One that prompts for the password if needed
      • Configure IPA to accepts password and 2FA which lets the user choose to either use the password only or 2FA. Needless to say that this makes 2FA less useful as people tend to be lazy
      • Turn off 2FA in IPA and use a Yubikey with a static password (spit password). This is not a real 2FA it is a single password split in two. Password change is a horror.
      • Accessing Webmail clients (I tested roundcube mail) causes headaches as well. They authenticate the users with IMAP and use this credentials to access the mail storage. As the second factor is a one time password (OTP) this will result in failure to retrieve mails after logging in.

        Workaround: Same as for mobile applications. I would appreciate if someone can point me to a webmail software which can handle this.

        Offline usage

        One sentence: Offline usage does not work because it can not work.


        • Create a local user and use a Yubikey and configure it with a static password (split password). This is not a real 2FA it is a single password split in two. Password change is a horror.
        • Install a IPA server on your Notebook 😉 This will scale up to 18 Notebooks (plus two replicas in the datacenter) but introduce a lot of other problems, so: Not seriously to be considered.

        LDAP Authentication as a Workaround
        Configure PAM/SSSD to use LDAP authentication for your users. IPA comes with a very nice feature called ipa-advise.

        [root@ipa1 ~]# ipa-advise config-redhat-nss-pam-ldapd
        # ----------------------------------------------------------------------
        # Instructions for configuring a system with nss-pam-ldapd as a IPA
        # client. This set of instructions is targeted for platforms that
        # include the authconfig utility, which are all Red Hat based platforms.
        # ----------------------------------------------------------------------
        # Schema Compatibility plugin has not been configured on this server. To
        # configure it, run "ipa-adtrust-install --enable-compat"
        # Install required packages via yum
        yum install -y wget openssl nss-pam-ldapd pam_ldap authconfig
        # NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was
        # introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not
        # be able to interoperate with IPA server 3.x.
        # Please note that this script assumes /etc/openldap/cacerts as the
        # default CA certificate location. If this value is different on your
        # system the script needs to be modified accordingly.
        # Download the CA certificate of the IPA server
        mkdir -p -m 755 /etc/openldap/cacerts
        wget -O /etc/openldap/cacerts/ipa.crt
        # Generate hashes for the openldap library
        command -v cacertdir_rehash
        if [ $? -ne 0 ] ; then
         wget "" -O cacertdir_rehash ;
         chmod 755 ./cacertdir_rehash ;
         ./cacertdir_rehash /etc/openldap/cacerts/ ;
         cacertdir_rehash /etc/openldap/cacerts/ ;
        # Use the authconfig to configure nsswitch.conf and the PAM stack
        authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap:// --ldapbasedn=cn=compat,dc=example,dc=com
        [root@ipa1 ~]#

        The output actually reflects your environment, will be replaced with your domain, its copy-paste ready. I love this feature :-) For other Linux systems, run ipa-advise without parameters to see which advises are available.

        2FA works well, convenient and secure in a datacenter and office environment. Notebooks are fine as well as long as there is a network connection available. The mobile world (Smartphones and Tablets) is not yet ready for 2FA. Some issues can be worked around (with some drawbacks) while others render 2FA not usable at all (offline usage).

        Hopefully there will be some smart solutions available for mobile usage soon, as mobile usage causes the most of the security headaches.

Providing SRV and TXT records for Kerberos and LDAP with dnsmasq

Wednesday, March 26th, 2014

What if you have an application such as OVirt/RHEV-M that relies on DNS services records and you dont have the possibility to add them to the DNS servers because the DNS admins do not like to do its job?

Fake them! DNSMasq is your friend :-) Install dnsmasq on the server in question and configure /etc/resolv.conf to query first dnsmask on localhost.

yum -y install dnsmasq
chkconfig dnsmasq on

Assuming your subdomain is called and your ldap and kerberos providers are and, configure dnsmasq as following:

cat << EOF >> /etc/dnsmasq.conf

Add the follwing line to /etc/resolv.conf and make sure is the first DNS server to be queried.


Start dnsmasq and have fun :-)

service dnsmask start

Identity Management with IPA Part I

Saturday, December 17th, 2011

Red Hat released RHEL 6.2 on December 6th. From my point of view, the greatest news in the release is that IPA (or now called Identity Management) is now fully supported and available in the RHEL 6 base channel without additional subscription costs.

Upstream project is freeIPA and is available trough the default Fedora repos.

About central Identity Management
IPA stands for Identification, Auditing, Policy. The focus in this article is on identification of users.

In the past, there have been a lot of solutions available to centrally manage users and its access to services. Just to name a few: LDAP, Kerberos, PAM, MS Active Directory, Novell Directory Server and countless others. All of those solutions have one in common: They are very powerful and very complex to set up and maintain. Because they are so complex, a lot of system administrators just do not use them and distribute SSH-keys, user credentials etc. by script without real central management, the nightmare of every security officer.

What is IPA?
The missing solution was a glue of LDAP and Kerberos which is easy to install and maintain, redundant and scalable from small office environments up to large enterprise installations. here it comes: IPA, which makes system administrators and security managers friends again.

IPA comes with a powerful CLI and a web interface for people that are afraid of a shell.

One of the cool stuff in IPA is its multi-master replication feature and automatic fail over facility. The clients are able to look up IPA servers with SRV DNS records, which are – of course – handled by IPA.

Lets do some stuff
One thing is just writing about how cool IPA is, but lets set up a high available centrally managed identity management system. This guide is written for RHEL 6.2 IPA-Servers and clients but should also work with freeIPA and Fedora 15 and later (Let me know if you have some issues).

Requirements are straightforward:

  • 1Gbyte of RAM
  • approx. 6Gbyte of disk (including operating system)
  • NTP
  • DNS entries for all IPA servers (including PTR records)
  • Fully updated RHEL 6.2 GA
  • Firefox on the IPA servers if you want to use the web interface

NTP is very important since Kerberos is quite picky about synchronized system time. Ensure it is configured and running on all involved servers.


  • IP network is
  • Domain is
  • Kerberos realm is EXAMPLE.COM
  • IPA-Server 1 is
  • IPA-Server 2 is
  • IPA-Client 1 is
  • IPA-Client 2 is
  • All passwords used are “somepassword” (needles to tell you to choose your own passwords
  • Main DNS is at
  • IPA-Clients are using and as there DNS servers.

Installation of the first IPA Server

yum -y install ipa-server bind-dyndb-ldap firefox xorg-x11-xauth

You are now ready to set up IPA. There are just a couple of questions, the non-default answers for this example are in red.

[root@ipa1 ~]# ipa-server-install --setup-dns --forwarder=
The log file for this installation can be found in /var/log/ipaserver-install.log
This program will set up the IPA Server.

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the Network Time Daemon (ntpd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)
  * Configure DNS (bind)

To accept the default shown in brackets, press the Enter key.

Existing BIND configuration detected, overwrite? [no]: yes
Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form

Server host name []:

Warning: skipping DNS resolution of host
The domain name has been calculated based on the host name.

Please confirm the domain name []:

The IPA Master Server will be configured with
IP address:
Domain name:

The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.

Please provide a realm name [EXAMPLE.COM]:
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password: somepassword
Password (confirm): somepassword

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password: somepassword
Password (confirm): somepassword

Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name []:
Using reverse zone

The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring ntpd
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
done configuring ntpd.
Configuring directory server for the CA: Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
done configuring pkids.

Lot of output omitted

Configuring named:
  [1/9]: adding DNS container
  [2/9]: setting up our zone
  [3/9]: setting up reverse zone
  [4/9]: setting up our own record
  [5/9]: setting up kerberos principal
  [6/9]: setting up named.conf
  [7/9]: restarting named
  [8/9]: configuring named to start on boot
  [9/9]: changing resolv.conf to point to ourselves
done configuring named.
Setup complete

Next steps:
        1. You must make sure these network ports are open:
                TCP Ports:
                  * 80, 443: HTTP/HTTPS
                  * 389, 636: LDAP/LDAPS
                  * 88, 464: kerberos
                  * 53: bind
                UDP Ports:
                  * 88, 464: kerberos
                  * 53: bind
                  * 123: ntp

        2. You can now obtain a kerberos ticket using the command: 'kinit admin'
           This ticket will allow you to use the IPA tools (e.g., ipa user-add)
           and the web user interface.

Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password
[root@ipa1 ~]#

You now need to get a Kerberos ticket:

[root@ipa1 ~]# kinit admin
Password for admin@EXAMPLE.COM:
[root@ipa1 ~]#

Fire up firefox and point it to and follow the link provided in the error message. You will see the instructions needed to use Kerberos as authentication method. When importing the cert into Firefox, REALLY check all three boxes!

Afterwards you are automatically logged in, if you got your Kerberos ticket before (kinit admin)

Setting up a Recplica
For now, we one IPA server. If it failes, no one can log in to any system anymore. This is of course unacceptable and needs to be changed. So lets set up a replica to add high availability to our central identity management system.

Log in to and fire up ipa-replica-prepare to collect the data needed for the replica.

Non-default answers are coloured red

[root@ipa1 ~]# ipa-replica-prepare

Directory Manager (existing master) password: somepassword

Preparing replica for from
Creating SSL certificate for the Directory Server
Creating SSL certificate for the dogtag Directory Server
Creating SSL certificate for the Web Server
Exporting RA certificate
Copying additional files
Finalizing configuration
Packaging replica information into /var/lib/ipa/
[root@ipa1 ~]#

/var/lib/ipa/ keeps all the information needed to set up the replica. You need to copy it by i.e scp to

Now log in to and fire up ipa-replica-install

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

Directory Manager (existing master) password: somepassword

Run connection check to master
Check connection from replica to remote master '':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: port 80 (80): OK
   HTTP Server: port 443(https) (443): OK

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@EXAMPLE.COM password:

Execute check on remote master
Check connection from master to remote replica '':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: port 80 (80): OK
   HTTP Server: port 443(https) (443): OK

Connection from master to replica is OK.

Connection check OK
Configuring ntpd
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
done configuring ntpd.
Configuring directory server: Estimated time 1 minute

Lot of output omitted

Using reverse zone
Configuring named:
  [1/8]: adding NS record to the zone
  [2/8]: setting up reverse zone
  [3/8]: setting up our own record
  [4/8]: setting up kerberos principal
  [5/8]: setting up named.conf
  [6/8]: restarting named
  [7/8]: configuring named to start on boot
  [8/8]: changing resolv.conf to point to ourselves
done configuring named.
[root@ipa2 ~]#

On ipa2, you need a Kerberos Ticket as well:

root@ipa2 ~]# kinit admin

Some adjustment
Unfortunately the default shell for new users is /bin/sh, which should probably be changed.

ipa config-mod --defaultshell=/bin/bash

Testing the replication
Log in to and add a new user:

ipa user-add tester1
ipa passwd tester1

You now can check if the user is really available on both servers by firing a ldapsearch command:

ldapsearch -x -b "dc=example, dc=com" uid=tester1

Compare the results of both servers. If they are the same, you have been successfully set up you two-node replicated high available IPA server.

What if is not available when I need to add a new user?
Simple answer: There is one way to find out….

Shut down
Log in to and add a new user:

root@ipa2 ~]# ipa user-add tester2

Start up again and run a ldapsearch again:

ldapsearch -x -b "dc=example, dc=com" uid=tester2

Set up a IPA-Client
Whats a centrally managed Identity Management server worth without a client? Nada! Lets set up a RHEL 6.2 server as a client:

[root@ipaclient1 ~]# yum  install ipa-client

After installation the setup program needs to be fired up. Non-default answers are coloured red

[root@ipaclient1 ~]# ipa-client-install -p admin
Discovery was successful!
DNS Domain:
IPA Server:
BaseDN: dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
Password for admin@EXAMPLE.COM: somepassword

Enrolled in IPA realm EXAMPLE.COM
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm EXAMPLE.COM
Warning: Hostname ( not found in DNS
DNS server record set to: ->
SSSD enabled
NTP enabled
Client configuration complete.
[root@ipaclient1 ~]# 

Testing the login
Log in to your client, you will need to change your password first:

[luc@bond ~]$ ssh -l tester1
tester1@'s password: 
Password expired. Change your password now.
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user tester1.
Current Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
Connection to closed.
[luc@bond ~]$ ssh -l tester1
tester1@'s password: 
Last login: Sat Dec 17 19:40:10 2011 from
Could not chdir to home directory /home/tester1: No such file or directory

In this case we do not have a home directory for the user tester1. NFS automount of home directories will be discussed in Part II oder III of this guide.

Now log out of and shut down to check if it is working when one IPA server failed. Needless to say that it is working… (okay, there is a delay of a few seconds)

IPA is not that powerful like MS Active Directory or Novell Directory. There is no support (and most probably there will never be) for multiple and or custom LDAP schemata to keep it simple and easily maintainable, this actually makes the drawbacks into a feature . If you need such features like custom LDAP schemata, you may have a look to RHDS.

Never in the past of information technology is was easier to set up and maintain a centrally managed identity management system. In just a few minutes of work you will have a basic set up of a highly available fault tolerant and scalable identity management server.

Outlook to Part II of this guide
IPA does not only allow users to be authenticated, but also to restrict them to use particular services only an particular systems. Thanks to Kerberos, it also provides single-sign-on capabilities without providing a password.

As soon as I get some time I’ll write about the following topics:

  • Passwordless (and key-less) SSH logins
  • Kerberized web applications
  • Centralized sudo management

Having fun?
Yes definitively , I have fun with IPA, and as a Linux consultant I expect a lot of work waiting for me.

Spice and RHEV, a RHCE goes MCSE

Tuesday, January 11th, 2011

I’m currently working in a project which includes some virtual Linux desktops. The desktop of choice is RHEL6.

How to bring a Linux desktop via WAN to a thin client? VNC -> are you nuts? Remote X11 over SSH -> WAN = no go. NX -> another vendor involved. SPICE -> Spicy! But: Spice over WAN? To be tested…

SPICE is the protocol used by RHEV (Red Hat Enterprise Virtualization). Some time ago I had the chance to test this stuff @Red Hat in Munich. The experience was nice, it is comparable to vSphere, but it only works with MS Internet explorer due to ActiveX and .Net stuff.

The management software needs to be installed on a Windows 2008R2 server. The database to be used is – you guess it – MS SQL. Users are authenticated either by Active Directory (Not generic LDAP!) or local Windows Users. Holy cow!

At first, when I got this product presented by Red Hat I was LOL. Now, it seems that I need to refresh my Windows knowledge because it seems to be the only product capable to provide enterprise ready Linux desktop virtualization. I’m crying :-(

At least the hypervisor used is not MS HyperV, it is KVM based on RHEL5, to replaced with RHEL6 in the future.

There is some light at the end of the tunnel: Red Hat is working on a replacement of the Windows-bound stuff. It will be replaced with some JBOSS and Java stuff. The database will probably be PostgreSQL. It will take some time to develop it before it will be ready for production.

Since Red Hat is opensourcing all (or most) of its products, it would be great to get in touch with the upstream project (release early, release often).

In meantime I need to build up knowledge about Windows Server 2008R2, Active Directory, MS SQL Server and DotNet.

Having fun?

Set up a Red Hat Directory Server and Kerberos Part I

Thursday, November 5th, 2009

Kerberos and LDAP are today’s way of single sign on. It is platform independent and supported by a wide range of applications.

Together with the Red Hat Directory Server (also available as CentOS Directory Server and 389 Directory Server from Fedora) you can build a neat identity management infrastructure.

Setting up the Directory Server
However there are some pitfalls when installing such a integrated solution. Installing redhat-ds is quite easy, just ensure you define your planned LDAP Namespace and default LDAP Suffix before running If you plan to setup a replica, run the script with the -k parameter: -k. The servers configuration will be saved as /tmp/setup*.inf and can be used to setup the replica after changing the FullMachineName and ServerIdentifier.

In my example I used the DN “cn=Directory Manager. As base I used dc=ldap,dc=example,dc=com. This is the Internet Domain Suffix style of naming an LDAP space. The older X500 style should not be used anymore.

Have a look to man openldap.conf to see how to shorten your CLI entries such as ldapsearch -x.

Setting up Kerberos
After setting the right configurations in your /etc/krb5.conf (the sample content is self-explanatory) and its distribution, you need to initialize your key store database. This is to be done with kdb_util as follows:

[root@server]# kdb5_util create -r EXAMPLE.COM -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

Keep in mind! Kerberos Realms are all uppercase to distinguish them from DNS names!

In the config file for the Key Distribution Center /var/kerberos/krb5kd/kdc.conf add the following in Realm Stanza: default_principal_flags =+ preauth. This will enhance security or your Kerberos Infrastructure. Also change the example Realm to what you are going to plan to use. In /var/kerberos/krb5kd/ kadm5.acl you can define the ACLs for e.g. admins or service desk employees etc. Also check the correctness of the Realm.

Feed the keystore

Now it is time to feed the database with the first principal: root. We also can create our first host principal at the same time.
Fire up kadmin.local. The kadmin.local app accesses directly the DB files on the server. Its should only be used on initial setup. Later on you will have kadmin which also works on the net, of course with Kerberos authentication.

[root@server ~]# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc root/admin
WARNING: no policy specified for root/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "root/admin@EXAMPLE.COM":
Re-enter password for principal "root/admin@EXAMPLE.COM":
Principal "root/admin@EXAMPLE.COM" created.
kadmin.local:  addprinc -randkey host/
WARNING: no policy specified for host/; defaulting to no policy
Principal "host/" created.
kadmin.local:  q
[root@server ~]#

After starting the kadmin and kdc services you can access the admin server with the normal kamin tool.

service kadmin start
chkconfig kadmin on
service krb5kdc start
chkconfig krb5kdc on

Now we need to create a host principal for each to be kerberized host and store it in its keytab.

End of Part I

What comes in Part II?

  • LDAP Service Principal
  • Getting Kerberos and LDAP working together
  • Migrating users from /etc/passwd to LDAP
  • Playing with PAM

Have fun!