Using OTP Tokens and 2FA with FreeIPA 4.0

On 2014-07-08 FreeIPA 4.0 was released. One of the most interesting new features is the support of two factor authentication (2FA). I was curious about how to set it up and get it running. Unfortunately the documentation does not tell much about the OTP setup.

What is OTP and 2FA? An overview
OTP stands for One Time Password and 2FA for two factor authentication. OTP is available since long time, in the beginning usually as a list of passwords printed on paper. It was enhancing security gradually but was an operational nightmare.

RSA then came up with harware tokens somewhere in the 1990this which made it much more usable. Also 2FA was introduced. the two factors are ownership (or possession) and knowledge. One needs to obtain a piece of hardware (Hardware Token or a smart phone with a software token) and knowledge (knowing the password).

Meanwhile a lot of competing tokens are on the market, as well as so called soft-tokens. Most (or all?) of the hardware tokens are proprietary, making system configuration a nightmare (RSA PAM modules and stuff). On the other hand, every proprietary solution comes with the support of Radius. There is a quite new definition of using a Radius proxy to use those tokens with Kerberos and connect them with IPA.

However, hardware tokens and Radius proxies have been out of scope for my initial test. Lets go for the simpler soft token way.

Installing FreeIPA 4.0
It is planed to include FreeIPA 4.0 in Fedora 21 which will be released later this year. For testing you can either use Fedora Rawhide 21 or Fedora 20 with an external Yum repository. I was choosing the later way.

wget https://copr.fedoraproject.org/coprs/pviktori/freeipa/repo/fedora-20-i386/pviktori-freeipa-fedora-20-i386.repo -O /etc/yum.repos.d/pviktori-freeipa-fedora-20-i386.repo

The rest of the installation is the same as with (Free)IPA2 and (Free)IPA3. Please have a look at my earlier Post

Enabling OTP
You can either enable OTP on a global scope or per user. At the moment I recommend it on a per-user base.

ipa user-mod username --user-auth-type=otp

If you want to enable users to authenticate with more than one method, user –user-auth-type={otp,password}

Adding a new user with OTP enabled will probably be possible in the future. There seems to be a bug, according to ipa user-add –help it is supposed to be working.

ipa user-add hwurst --first="Hans" --last="Wurst" --user-auth-type=otp

Adding a token
The best way for a user to add a token is probably the web interface. Lets call it self-service. The user first authenticates with username and the initial password set by the admin to set a new one. The OTP field can be ignored for the moment.

After authentication, the user can navigate to “OTP Tokens” on the top navigation bar and add a new token. This looks as following:

ipa-otpThe ID needs to be unique, this can case problems when users are adding the tokens by themself as people would tend to provide a simple ID by themself. When not providing an ID, one will be generated. The field Unique ID should IMHO not be available for ordinary users.

After adding the token, login via password only is not possible anymore (unless explicitly enabled with the user-auth-type).

After hitting “Add”, a QR code will be shown. This allows users to scan the code with the Smartphone app, such as FreeOTP and Google Authenticator.

The next step users needs to do is to sync the token. This can be done by returning to the login screen and clicking on “Sync OTP Token” right left to the Login button.

ipa-otp2With a generated Unique ID (=Token ID) its quite annoying to enter that ID. However, usually this only needs to be one once 🙂

 

 

 

 

Limitations

The release notes mentions that there are concerns about the scalability when using HOTP, where TOTP has a known issue that tokens can be reused, but only within a short timeframe.

I see another issue which is a kind of a chicken-and-egg problem: After adding a user, this user is able to login with its password only until a token has been added. This ability is needed to log in to the IPA WebUI to add the token at the first place. However, password-only access should be limited to the token add facility.

Conclusion

I’m pretty amazed how well it works as this is a brand new feature for FreeIPA. The involved engineers made a brilliant job! I’m looking forward to see this feature in Redhat IPA/IdM somewhere in the future as 2FA is an often requested killer feature in enterprise environments.

Read more

Have fun! 🙂

Intercepting proxies and spacewalk-repo-sync

More and more companies are using intercepting proxies to scan for malware. Those malware scanners can be problematic due to added latency.

If you using spacewalk-repo-sync to synchronize external yum repositories to your custom software channels and experience the famous message [Errno 256] No more mirrors to try in your log files, then you need to configure spacewalk-repo-sync.

Unfortunately the documentation for that is a bit hidden in the man page. You need to create a directory and create a file.

mkdir /etc/rhn/spacewalk-repo-sync/

Create the configuration item:

echo "[main]" >> /etc/rhn/spacewalk-repo-sync/yum.conf
echo timeout=300 >> /etc/rhn/spacewalk-repo-sync/yum.conf

You need to experiment a bit with the value of the timeout setting, 5min should be good enough for most environments.

/etc/rhn/spacewalk-repo-sync/yum.conf has the same options like yum.conf, have a look for more information in the man page.

Have fun 🙂

PAM and IPA authentication for RHN Satellite

If you have a larger installation on your site, you may wish to have a single source of credentials not only for common system services, but for your RHN Satellite too.

This will show you how to configure your RHN Satellite Server to use PAM with SSSD. SSSD, the System Security Services Daemon is a common framework to provide authentication services. Needless to say that IPA is supported as well.

Assumptions:

  • You have a RHN Satellite running on RHEL6
  • You have an IPA infrastructure running (at least on RHEL 6.2)

Preparations
First you need to install the ipa-client on your satellite:

yum -y install ipa-client

And then join the server to your IPA environment:

ipa-client-install -p admin

Configuring PAM as follows:

cat << EOF > /etc/pam.d/rhn-satellite
auth        required      pam_env.so
auth        sufficient    pam_sss.so 
auth        required      pam_deny.so
account     sufficient    pam_sss.so
account     required      pam_deny.so
EOF

Configure the RHN Satellite
Your Satellite now needs to be aware that there is the possibility to authenticate users with PAM against IPA.

echo "pam_auth_service = rhn-satellite" >> /etc/rhn/rhn.conf

If you have users in your IPA domain with usernames shorter than five characters, you will need to add one more line to be able to create the users in RHN Satellite:

echo "web.min_user_len = 3" >>   /etc/rhn/rhn.conf

After this change, restart your RHN Satellite

rhn-satellite restart

Configuring users
Now you can log in to your RHN Satellite with your already configured admin user and select the checkbox “Pluggable Authentication Modules (PAM)” on existing users and/or new users.

Things to be considered
It is strongly recomended to have at leat one user per organization (ususally a “Organization Administrator”) plus the “RHN Satellite Administrator” not having PAM authentication enabled. Despite of the easy implementation of redundancy with IPA, this is important for a fallback scenario when your IPA environment has some service interruptions due to mainenance or failure.

SSSD caches users credentials on the RHN Satellite system, but this is only true for users logged in at least once. The default value for offline_credentials_expiration is 0, which means no cache time limit. However, depending on your organizations scurity policy this value can vary. Please check the PAM section in /etc/sssd/sssd.conf

Further documents to read

Identity Management with IPA Part II – Kerberized NFS service

In part one I was writing how to set up an IPA server for basic user authentication.

One reason NFSv4 is not that widespreaded yet, is it needs Kerberos for proper operation. Of course this is now much easier thanks to IPA.

Goal for the part of the guide

  • Configure IPA to serve the NFS principle
  • Configure NFS to use IPA
  • Configure some IPA clients to use Kerberos for the NFS service

Requirements

  • A runing IPA service like discussed in Part I of this guide.
  • A NFS server based on RHEL6.2
  • One or more IPA-Client

Lets doit
First you need to add the NFS server and its service principal to the IPA server. On ipa1.example.com run:

[root@ipa1 ~]# ipa host-add nfs.example.com
[root@ipa1 ~]# ipa service-add nfs/nfs.example.com

Next, log on to you NFS server, lets call it nfs.example.com and install the needed additional software packages:

[root@nfs ~]# yum -y install ipa-client nfs-utils

You need to enroll you NFS-server on the IPA domain. Run the following on nfs.example.com:

[root@nfs ~]# ipa-client-install -p admin

The next step is to get a Kerberos ticket and fetch the entries needed to be added in the krb5.keytab

[root@nfs ~]# kinit admin
[root@nfs ~]# ipa-getkeytab -s ipa1.example.com -p nfs/nfs.example.com -k /etc/krb5.keytab

Before you proceed to your clients, you need to enable secure NFS, create an export and restart NFS:

[root@nfs ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@nfs ~]# echo "/home  *(rw,sec=sys:krb5:krb5i:krb5p)" >> /etc/exports
[root@nfs ~]# mkdir /home/tester1 && cp /etc/skel/.bash* /home/tester && chmod 700 /home/tester1 && chown -R tester1:ipausers /home/tester1
[root@nfs ~]# service nfs restart

Assuming you already have set up one or more IPA-client(s), it is stright forward to enable kerberized NFS on your systems. Log in to a client and run the following:

[root@ipaclient1 ~]# yum -y install nfs-utils
[root@ipaclient1 ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@ipaclient1 ~]# 

Lets have a look if you have been successful. First look up the users UID.

[root@ipaclient1 ~]# getent passwd tester1
tester1:*:1037700500:1037700500:Hans Tester:/home/tester1:/bin/bash
[root@ipaclient1 ~]# 

Lets mount that users home directory manually on a client:

mount -t nfs4 nfs.exmaple.com:/home/tester1 /home/tester1

To check if is working as expected, issue

[root@ipaclient1 ~]# su - tester1

Fire ls -lan and see if the UID matches the UID you got from getent. If you see UID 4294967294, then something went wrong, this is the UID for the user “nobody” when using NFSv4 on 64 bit machines.

Whats next?
You will figure out when I post part III of this guide 🙂

Have fun!