Host based access control with IPA

Host based access control is easy with IPA/FreeIPA, very easy.

Lets assume you want to have a host group called rhel-prod, a usergroup called prod-admins and you want to let them access the servers in the rhel-prod group by ssh from any host that can reach the servers. Lets call the HBAC rule prod-admins.

You can either user the web GUI or use the command line interface.

Lets create the user group:

[root@ipa1 ~]# ipa group-add prod-admins --desc="Production System Admins"
Added group "prod-admins"
  Group name: prod-admins
  Description: Production System Admins
  GID: 1222000004
[root@ipa1 ~]# 

Add some users to the user group:

[root@ipa1 ~]# ipa group-add-member prod-admins --users=luc,htester
  Group name: prod-admins
  Description: Production System Admins
  GID: 1222000004
  Member users: luc, htester
Number of members added 2
[root@ipa1 ~]# 

And the hostgroup

[root@ipa1 ~]# ipa hostgroup-add rhel-prod --desc "Production Servers"
Added hostgroup "rhel-prod"
  Host-group: rhel-prod
  Description: Production Servers
[root@ipa1 ~]#

Add some servers as members of the host group

[root@ipa1 ~]# ipa hostgroup-add-member rhel-prod,
  Host-group: rhel-prod
  Description: Production Servers
  Member hosts:,
Number of members added 2
[root@ipa1 ~]#

Note: the servers are comma separated, without a space after the comma

Lets define the HBAC rule:

[root@ipa1 ~]# ipa hbacrule-add --srchostcat=all prod-admins
Added HBAC rule "prod-admins"
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
[root@ipa1 ~]#

Add the user group to the rule:

[root@ipa1 ~]# ipa hbacrule-add-user --groups prod-admins prod-admins
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
  User Groups: prod-admins
Number of members added 1
[root@ipa1 ~]#

Add the service to the rule:

[root@ipa1 ~]# ipa hbacrule-add-service --hbacsvcs sshd prod-admins
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
  User Groups: prod-admins
  Services: sshd
Number of members added 1
[root@ipa1 ~]#

And finally add the host group to the rule

[root@ipa1 ~]# ipa hbacrule-add-host --hostgroups rhel-prod prod-admins
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
  User Groups: prod-admins
  Host Groups: rhel-prod
  Services: sshd
Number of members added 1
[root@ipa1 ~]#

Of course you can enhance the rule by adding other services or restrict the access from particular hosts and so on.

Have fun 🙂

One year in Berlin, one year at Red Hat

In March 2011, I signed my contract with Red Hat and moved from Zurich to Berlin, as posted here in April 2011.

After one year it is time for a review of my “new life”. At once, a lot of things changed in my life: New Country, new City, new Appartment, new Job. Quite a lot of stuff.

At my former job, I had a notice period of three months which gaves me some time for the planing of the move. A lot of burocracy was waiting for me, both in Switzerland and in Germany.

Getting an appartment
The first challange was to get an appartment in Berlin. I went to Linux Tag 2011 in May to have a look to quite a few appartments. It was not that easy as I was told from different people. Gentrification is not only a problem in Zurich, but also in Berlin.

The chicken and egg problem. In order to get an appartment, you need a “Schufa-Auszug”, a paper that “certifies” your creditability. Usually it is only possible to get this paper when beeing a resident in Germany. How to get a resident without an appartment when you need a Schufa-Auszug to get an appartment when you need a residency in Germany and therefore need a Schufa-Auszug?

So I went to a Schufa-Shop and it took me 30min of explaining the clerk that the processes at real estate brokers ar completly idiotic but I need the paper. So I finally got the Schufa-Auszug with my old address in Zurich.

Finally I was able to sign a contract with a land lord. The appartment and its location is very nice and very close to the excellent public transport (although, Berliners grumble about the S-Bahn trains, it is excellent compared .i.e to Munich).
As you can see in the picture, it is close to Alexanderplatz, the new City center of Berlin, just two underground train stations away to the west. Two underground stations to the east, and I find myself in the Party Neighborhood (Kiez in Berlin-Speak) at Simon-Dach-Strasse. Walking south, crossing the Spree river and I find myself in the vibrant Berlin Club scene.

A special feature of the appartment is the roof top terrace where neighbors meet for partying. Quite uncommon for Germany: There are washing machines available, so I dont need to buy one. Also quite uncommon in Germany: The appartment has a kitchen, no hassle to buy the stuff.

Preparing the move
The usual stuff like getting rid of old stuff and putting the rest into moving boxes is straight forward, as well as finding the movers. More complex is the coordination of the due dates for all the stuff.

Paper work part one
Since Switzerland is not in the customs union of the EU, it adds more complexity. I need two papers: The stamped registration form of Berlin, and the stamped levaing form of Zurich.

Getting the first form is straight forward: Just do a online-reservation at the registration office (Meldeamt at Bezirksamt), getting there and walk out after 10 minutes. Myth busted: German bureaucracy is always complex

The latter one cost a shitload of money. You get it from the Zurich tax office, but only if you pay the guesstimated taxes upfront, in cash!. Of course this means you need to fill out a lot of forms upfront, what an annoyance. Myth busted: Swiss bureaucracy is alwas easy.

The next task was then to get a health insurance. Since a lot of Germans are living in Switzerland, I just some good advices upfront, easy stuff. Now it was time to cancel all contracts such as Internet access, mobile phone contract, insurances and getting new contracts in Berlin.

I had a early start at Red Hat, so I left Switzeland on 26th of June, went to a training in Farnborough, UK spending the weekend in London and getting straight to Munich for another training and finally arrived in Berlin on 05. July 2011. In fact I was homeless for 1.5 weeks, sleeping in hotels. The first two days my furniture has not yet arrived, sleeping on the floor in a sleeping bag.

Paperwork part two
Soon after the registration in Berlin, I got my tax payer ID number. I also needed to fill out a form with a rather complex title “Antrag auf Bescheinigung für den Lohnsteuerabzug” (something like application for a certificate for the income tax deduction). I needed to show up at the Finanzamt (Tax Office) and unlike the forms title suggests, it was painless.

Another important task was the application for change my Swiss driver license into a German one. The pitfall is that one needs to apply in the first six months after immigration or to jeoppardize the whole licese. Well I had to wait more than two months to get the license exchanged.

Left wing politicians do not like the word. From my point of view, foreigner should assimilate them reasonably. For me that was very easy since Switzerland and Germany has a lot in common. The same political and cultural values and – for northern Swiss people – the same language (well, kind of). Of course I needed to adapt my German getting rid of typical helvetisms which are not understood in Germany or understood in the wrong way which can annoy some Germans.

In meantime I got assimilated even better: I watch soccer matches 😉

The foreigner
Everyone is a foreigner, nearly everywhere (unknown quote). So yes, I’ living as a foreigner now.

Almost everyone welcomed me in Berlin and other German cities where I was working and I quickly got new friends. The average German is generally more open minded and cosmopolitan than the avarage Swiss (especially when comparing Berlin with Zurich)

When I’m looking back to Switzerland and see how some people treat Germans: Its a shame! I wish that this mind will change in Switzerland and Germans are treated the same friendly way as I’m treated in Germany.

Living in Berlin
The crazy thing about my working contract with Red Hat is: I got offered to be based on a choice of four locations where Red Hat has offices: Munich, Stuttgart, Frankfurt and Berlin. I have already visited the first three cities multiple times, but I was never in Berlin before, just heared its a nice city. Well, Munich is beatiful but expensive and the Airport is only reachable by air. Stuttgart is a bit boring, Frankfurt hmm… So I was taking the risk and choose to move to Berlin without much knowledge about the city.

Well, I’m now living in Friedrichshain, just north of Kreuzberg.

Berlin is cool! I mean: Really cool! I guess you can not find any other europeen metropolis which offers a greater diversity of culture, food and of course people. Going to clubs in Berlin on weekends is a delight. You can find clubs for almost every style of music.

Culinary: Well, the Currywurst and Döner Kebap was invented in Berlin, but this are not the real highlights. In the Simon-Dach-Kiez as well as near Alexanderplatz one will find restaurants with food from allover the planet. Thai, Vietnamese, Bulgarian, Chinese, Russian, Korean, Japanese, Italian… you will find them all. There are even Swiss restaurants, but I never made it yet.

Public transport: Awesome! A S-Bahn train every two to five minutes, same applies to underground trains. During the weekends, S- and U-Bahn are operating the whole night, without any idiotic night-surcharge, and of course there is a train every approx. 15min. From my point of view the public transport in Zurich looks like a really bad (but expensive) joke.

Long distance high speed ICE Trains are also awesome. Berlin-Hamburg (approx 300km) in 1:39h. Zurich-Geneva (approx 300km) in 2:43h

home sickness
The first few weeks have been very hard for me. Yes, I had home sickness. I left all my friends in Switzeland and I miss the beautiful old towns of Zurich and Winterthur as well as the mountains. What I really miss is the “third dimension”, it is all flat here, the highest elevation in Berlin are the Müggelberge (Berg means mountain, what a fool) with 114,7m above sealevel. Before I left Switzerland I was not aware about how beautiful the Alpes are, it was just a matter of course to always have them in sight.

In the last 12 months I have been visiting Switzerland three times. I have enjoyed those trips, visting my old frieds, having a BBQ country side and strolling trough the old towns of Winterthur and Zurich.

Whats the better country for a living? Germany or Switzerland?
This is a question I hear all the time. My answer is always the same: Neither of them are better, those countries are just different, but not that much.

My job as Senior Linux Consultant at Red Hat
When Red Hat approached me, I first was surprised, then I got a contract and I got it very fast 🙂

It is a very interessing and challenging job. As a consultant I’m visiting a lot of customers to help them with particular technologies in their projects. Every customers has its own processes and infrastructure, so I need to adapt very fast.I also travel a lot, customers are usually located in central europe, mostly in Germany. Somethimes it happens that I can travel a bit further, for example, my customer engagement in Kuala Lumpur, Malaysia was an impressive experience.

Travelling means to see a lot of different locations, that makes it even more interessting. The drawback is being only at home for the weekends.

At the end of the day, Red Hat was the best that could happen to me, a open source guy. Lots of nice and very competent and open minded collegues in a international team and the possibility to always get in touch with the latest and greatest technology in the open source world.

Having fun? Yes, sure…

Identity Management with IPA Part I

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.