Certificates in IPA/IDM Explained

Certificates in IPA/IDM for Dummies

As described in the figure above, a certificate in it's simplest form 'certifies' the identity of a 'thing' attempting to access domain resources. I like to think of a certificate as a fingerprint or maybe a strand of a 'things' DNA.  Those 'things' can be machines or a person attempting to gain access to network resources.

As mentioned in a separate blog entry, IPA/IDM is comprised of and integrates several major components that all work together to manage resources and users - as a domain controller (DC).

(That blog entry can be found here: 

In this blog entry I will be examining the Certificate System.  

Given that IPA/IDM uses kerberos, why does IPA/IDM/Identity Manager need Certificates anyway?

Within an IPA/IDM domain, certain applications (ie. web based and others) and even machines have to use certificates often for SSL/TLS communication.  As an example, when a client - a workstation in this example - joins a domain there is communication between the client and the server.  This communication is encrypted using SSL/TLS which requires a certificate. 

As a reminder SSL/TLS are transport layer security protocols that encrypt communications over the network.

Let's take a quick look at this graphic which illustrates how certificates are exchanged when a client workstation joins an IPA/IDM Domain (click to see larger view):

Taken all together, IPA/IDM uses PKI (Public Key Infrastructure) to manage certificates.  Here is a working definition of PKI:

A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. ... In IPA/IDM PKI, a registration authority is usually called a CA.

IPA/IDM uses (2) separate but related components to establish a PKI: Dogtag and Certmonger.

Dogtag: The Dogtag Certificate System is an enterprise-class open source Certificate Authority (CA). 

• The Certificate Manager is a certificate authority (CA). It issues, renews, and publishes certificates. The Certificate Manager also creates and publishes certificate revocation lists (CRLs).

Certmonger: Automates the management of Certificates,  Requests new certificates from the CA when they are expired.

The certmonger daemon monitors certificates for impending expiration, and can optionally refresh soon-to-be-expired certificates with the help of a CA. If told to, it can drive the entire enrollment process from key generation through enrollment and refresh.

Put another way: certmonger tracks certificates so you don't have to!

And as mentioned, a big part of the reason for PKI in IPA/IDM is LDAP.  Communication with LDAP must be secure! The only way we get TLS communication with LDAP is via certificates/PKI.

Even the Apache based IPA/IDM Web UI uses certificates for secure communications

So within IPA/IDM the CA Server is managed/created by Dogtag; which should be installed as the default option.  The Dogtag CA can self-sign it's own CA certificate or you can send out the certificate to have it verified by a 3rd Party such as Verisign.

The certmonger daemon essentially manages certificates on the client side, again so you don't have to! It automatically communicates with the Dogtag CA Authority on the IDM server on the clients behalf and requests certificates when required. 

There really is no manual management of certificates when you use IPA/IDM.

IPA/IDM Identity Management - 2FA or 2 Factor Authentication and how and why you should be using 2FA/OTP

IPA/IDM Identity Management - 2FA or 2 Factor Authentication

Based on my many many years of IT experience, I'd estimate that most enterprises, domains and other applications and services do NOT take advantage of multi-factor Authentication - for most one-factor or single-factor authentication (1FA) seemed adequate and is the easiest for the end-user.

As a reminder, authentication is something you know that is associated with your identity.  Identity is who you are or what you are, and authentication is proving who or what you are.  That is most often accomplished by associating an identity with a secret that only the person (identity) knows such as a password.

Before we go any further though, let's take a look at a few authentication schemes:

0FA: Zero-factor authentication is something you and everyone else (potentially) knows - and that is your identity.  An example might be a linux system that does not have a root password set.  Or even a system with a root or admin password that still has the factory default root or admin password.  Don't do this!

1FA: Single-factor authentication is who you are (identity) + something you know such as a password.  Certainly a big improvement over 0FA.  An example of 1FA would be: my username + my password.  And hopefully the password is not shared.  Don't share passwords!

2FA: 2-Factor authentication is who you are + something you know + something you have. Something you have could be a RSA Token or in the case of IPA/IDM could be hardware like a programmable Yubikey or through an application such as FreeOTP Authenticator - check your vendor for all available options.

Regardless though of what is used for "something you have" - hardware or software tokens - they all perform the same purpose: To generate a one-time password or OTP.

Below are (2) examples of an OTP using a RSA key and FreeOTP (smartphone based).

Notice above that the OTP in both cases is a random string of 6 numbers, which is a typical OTP.

OTP's can be time based or request based.   In the case of time based the OTP's are constantly generated but have a TTL; while Request based OTP's are generated on request.

IPA/IDM uses Gnome Keyring to manage the usernames + password + OTP; which means for the most part implementing 2FA on IPA/IDM is a straightforward process and will likely be a completely web based configuration process. There are a few minor exceptions such as Yurikey which has to be added using command line interface (CLI).   

And in case you're wondering, YES the OTP device or application has to be synchronized with user accounts. The exact method of synchronization will vary depending on the token type selected, but often a QR code can be used to configure the token

QR Code:

In addition, IPA/IDM can use multiple token types, so that administrators are not limited to a single token type.

I won't go into this in great detail other than to say that IPA/IDM supports OTP's generated with the two (2) following algorithms:

• The HMAC-Based One-Time Password (HOTP) algorithm is based on a counter. HMAC stands for Hashed Message Authentication Code.
• The Time-Based One-Time Password (TOTP) algorithm is an extension of HOTP to support time-based moving factor.

Now let's take a look an example of logging into a workstation using 2FA:

In the above screen capture, a user would enter the following:

1. Their username

2. Their password

3. OTP

As noted above, the OTP would be either request based (on demand) or time based in which case the user would refer to their token for the current OTP.

Bottomline: If your information is worth protecting, step-up to 2FA now. It's never been easier or cheaper!

IPA/IDM - Thoughts on sudo and why IPA/IDM offers the most secure sudo solution available

IPA/IDM - Thoughts on implementing sudo

I'll start off by mentioning that IPA/IDM in general is freeware/OpenSource Linux based Identity Management software.  One of many very powerful features of IPA/IDM is that it allows for a very high degree of granularity.

What is granularity?  Granularity refers to the degree of access control; ranging from coarse grain control to fine grain control.  Let's take a look at an example:

Coarse Grain Control: Employees can access/login to a workstation at any time and access any storage shares.

Medium Grain Control: Employee can access/login to a workstation during business hours, but access any storage shares.

Fine Grain Control: Employees can only login during business hours and only access shares that relate to the projects they are working on.

Finer Grain Control: Employees can only login into certain workstations, only during business hours and can only access shares that relate to a project they are working on.

So what is sudo anyway?  sudo is a utility that allows a user to run a command as root or as another user.

All Linux systems have a sudo command-line utility; however in IPA/IDM the sudo utility is managed and stored in LDAP as part of the Identity Management Realm.

This is important because it means sudo can be centrally managed for all users and resources in the Realm from a central location.  In the case of sudo, IPA/IDM is a one-to-many solution; meaning NO sudo configuration files (ie. /etc/sudoers) are "pushed" to Realm clients.

It is also worth noting that the LDAP sudo implementation with IPA/IDM has a specialized schema (the LDAP database design) for sudo that greatly expands the capabilities of sudo within IPA/IDM; as compared to the command-line implementation of sudo.

As an example, the IPA/IDM sudo utility allows for host groups as well as nested groups, the standard command-line sudo utility does not.

Further, all sudo functionality can be managed via a web interface:

Now let's walk through the process of setting up sudo for a user and what options are available.

In this example, Babs Jenkins has contacted you - a system administrator - and has asked for root privileges on a Configuration Management server. Babs Jenkins needs to run a /bin/build command on this particular server daily. 

Next you login to the IPA Web interface and see that Babs Jenkins does indeed have an account in the domain (or Realm) and that the build server is a client in the domain.

1. The next step is to create a sudo rule called: build 

(Note this and the following steps are performed under the web based sudo menu)  

2. Next you specify who this rule is applied to, and in this step you select: Babs Jenkins

3. Now you select the host on which this rule applies to, which in this case is the Configuration Management Server.

4. Now specify the commands that sudo user is permitted to run on the specified host, which in this case will be:

/bin/ls

/bin/more

/bin/build

5. Finally you can optionally specify any additional command groups (pre-specified commands) and also as Whom.  That's right, you don't have to run the build command as root, a different user could also be specified!

After you have completed the above steps, Identity Management also provides an easy-to-use utility that allows the system administrator (SA) to test the rule.  Wow!

In the above example we have defined the following:

1. Who has access

2. The Commands the user has access to

3. What can be accessed (the specifi host)

4. Who the user will be running the command as

Finally, all sudo activity is logged under /var/log or within the audit facility.  

IPA/IDM Identity Management and Kerberos - A simple explanation of how it is used to Authenticate in an IPA/IDM Domain

IPA/IDM Identity Management - A simple explanation of how it is used to Authenticate

Kerberos is a Network Authentication Protocol (NAP) developed at MIT and released publicly in the 1980's.  Owing to it's Greek name Kerberos, there are (3) pillars of Kerberos: Client, Server (could be an app or other service or host) and a 3rd Party Key Distribution Center (KDC). 

Within these (3) pillars, Kerberos uses Tickets to validate the identity of users and other resources within the Kerberos Realm. A Kerberos realm encompasses any resource that can be accessed via a specific Kerberos KDC. The KDC has (2) primary components: An Authentication Server (AS) and a Ticket Granting Service (TGS). 

All Kerberos communications are encrypted using a variety of configurable Ciphers.

One very important feature of Kerberos: Passwords are never sent over the network!

Let's look at an example of a user logging into a Kerberos enabled client within a Kerberos Realm/Domain.

1. A user enters their username at a client workstation, which is transmitted to the AS within the KDC.  In addition to the username, several other pieces of info are transmitted to the KDC/AS including: IP of the client, the name of the KDC and the requested Time To Live (TTL) for Ticket Granting Ticket (TGT).

2. The username the client presented to see if it exists in the KDC Database - which in the case of IPA/IDM is the Directory Server. If the username is valid, the client will proceed to step 3, otherwise an error is generated and the authentication process must be restarted at Step 1.

3. The KDC/AS now responds by sending a Ticket Granting Ticket (TGT) to the workstation or client (which is a Kerberos Realm client).

The TGT itself contains several critical pieces of information, including: username, TGS name, TimeStamp, IP of client as well as other information.  

The TGT is encrypted with a session key known only between the KDC and user (also known as a principal) - this key is most often generated with the users password. IPA/IDM uses symmetric key cryptography when generating TGT's.

 A hash is then created based on the password the user entered, and that hash is used to decrypt the Session Key. 

4. If the password decrypts the Session Key, the client now creates an Authenticator which it sends back to the KDC along with the identity of the Kerberized resource that the client wants to access.

The Authenticator is used to decrypt the TGS Secret Key which if it does so successfully, will now grant access to Kerberized Realm resources by issuing a Service Ticket (ST) or de-crypted TGT to the user.

5. The client can now use this ST or de-crypted TGT to gain access to KDC Realm resources such as servers, storage, http/s apps, databases, files and even routers and printers or any other service that is Kerberized.

The ST will have a specified lifetime in which it can be used to gain access to Kerberized resources without having to re-authenticate.  In addition, Kerberos also allows for Single Sign-On (SSO) since an ST has a System Administrator defined lifetime.

One other point: Once the TGT is de-crypted on the TGS, the key pair can then be stored in a keytab.

Here is a working definition of a keytab:

A keytab is a file containing pairs of Kerberos principals and encrypted keys (which are derived from the Kerberos password). You can use a keytab file to authenticate to various remote systems using Kerberos without entering a password. However, when you change your Kerberos password, you will need to recreate all your keytabs.

Keytab files are commonly used to allow scripts to automatically authenticate using Kerberos, without requiring human interaction or access to password stored in a plain-text file. The script is then able to use the acquired credentials to access files stored on a remote system.

In other words, the keytab will allow a principal (user) or even a script to access domain resources without having to input a password.

Here is a graphic from Red Hat that illustrates the steps above in a slightly simpler form:

It's worth noting that Kerberos Authentication is nearly transparent to System Administrators and Users -> IPA/IDM does most if not all of the heavy lifting.

An Overview of IPA/IDM - Identity Management and why you should be using it in your Enterprise

An Overview of IPA/IDM - Identity Management and why you should be using it in your Enterprise

IPA/IDM is an Identity Management Solution that manages access to everything from users to groups to servers and other services.  The terms IPA and IDM are essentially interchangeable.  IPA stands for: Identity Policy Audit while IDM stands for: Identity Management. They refer to the exact same software product.

In short, IPA/IDM or Identity Management is for practical purposes a Linux Domain Controller much like Active Directory (AD).

IPA/IDM runs natively on Linux, but readily integrates with Windows environments as well - much like a trust between (2) Active Directory domains.

For much of the history of mixed use environments - those with a mix of Windows and Linux/Unix workstations and servers - these different environments were often managed as separate domains due to a lack of compatibility.  Often Windows domains would use Active Directory (AD) to manage users and network resources; and Unix/Linux environments would use tools such as Network Information System (NIS).

Everything from user accounts to host/DNS entries and access to network resources/shares was managed separately as distinctive environments.  This effectively doubled the amount of work required to manage the domains.

Today there are many tools available that unify Windows and Linux/Unix environments; some are commercial and others are freeware/opensource.

This article will focus on FreeIPA and it's variants from vendors such as RedHat, Fedora and CentOS.  Let's start with the basics:

In either case, IPA/IDM is a highly secure, highly granular and high availability access management software that in many cases is available for free.  IPA/IDM will allow administrators to unify Windows and Linux/Unix environments including user accounts, access to shares and name resolution (DNS) among other capabilities including Single Sign On (SSO) capabilities.

Managing users and other resources in the domain can most often be performed via command line or using a Web Based GUI Interface:

So what makes IPA/IDM so secure?

IPA/IDM uses a combination of technologies - including LDAP -  to provide highly secure Identity Management, including:

*Kerberos: A network authentication protocol which means passwords are never transmitted over the network.

*Certificates: Certificates are used to validate/certify the identity of IPA domain resources such as clients/hosts, 

*SSSD: System Security Services Daemon allows for remote authentication and interfaces with Name Switch Service (NSS) and PAM.  SSSD requires all communication channels to be encrypted.

*LDAPS: Fully ldaps compliant or use ldap:389 with TLS.

*Highly Granular: IPA/IDM allows for a very high degree of granularity including Role based Access (RBAC) and Host based Access (HBAC).  

*Centrally manage access to domain resources. No need to rdist files (very insecure) between systems.

*Full integration with SELinux

*Integrated Secure DNS

*Easy to establish a replica server.



The unification of Services

IPA/IDM unifies a number of services to make all of this security and manageability of users and resources work.  Please see the graphic below:

As a system administrator, most of these components that make up a IPA/IDM server are transparent; with minimal or zero intervention required.

As mentioned, it's very easy to unify Windows/Linux environments with a high level of security as IPA/IDM is well documented/supported and easy to install.