RedHat RHEL 9: New IPA (IDM) Features

Red Hat Enterprise Linux (RHEL) 9 introduces several new features related to Identity Management (IdM) using the IPA (Identity, Policy, and Audit) framework. Here are some of the new features:

1. Simplified installation and setup: RHEL 9 offers a simplified installation and setup process for IPA, making it easier for administrators to deploy and configure the IdM solution. Simplified dnf IPA install.
2. Enhanced password policies: IPA in RHEL 9 offers enhanced password policies, including support for password history, minimum password length, and complexity requirements.
3. Improved certificate management: RHEL 9 includes improved certificate management features, including support for certificate renewal and revocation, as well as automatic certificate enrollment for hosts and users.
4. Improved user and group management: RHEL 9 offers improved user and group management features, including support for nested groups, group-based access control, and the ability to manage users and groups from a single interface.
5. Enhanced auditing capabilities: RHEL 9 offers enhanced auditing capabilities, including support for log filtering and searching, as well as the ability to generate reports based on audit data.
6. Improved integration with Active Directory: RHEL 9 offers improved integration with Active Directory, allowing administrators to manage identities and access control across both Linux and Windows environments.
7. Enhanced high-availability capabilities: RHEL 9 includes enhanced high-availability capabilities for IPA, ensuring that critical IdM services are always available to users and applications.

Overall, these new features make IPA in RHEL 9 a powerful and flexible solution for managing identities, access control, and security across Linux and Windows environments.

FIPS 140-2: Data at Rest Encryption

FIPS 140-2: Data-at-Rest Encryption (D@RE)

No one ever got fired for encrypting their data!

Increasingly organizations are requiring data to be encrypted at rest to prevent data loss and theft.

Data-at-rest refers to data not actively being accessed stored on non-volatile storage such as a disk drive; and encrypting the data means the data is transformed in such a way that a third party cannot translate the data into a usable form.  Encryption is usually accomplished through use of a FIPS encryption module located on a disk drive.  These type of drives are known as self-encrypting drives (SED).  D@RE can also be accomplished by use of encrypting controllers which encrypt data as it is written to drives and decrypts as the data is retrieved.  Encrypting controllers do not require SED drives as they work with non-SED drives.

Data security and encryption is achieved through the use of a data encryption key (DEK).  In addition, the DEK (key) can also be encrypted often through the use of a RSA key for multilayer security.

Encryption can be applied to an entire disk or just to the file system. Because full disk encryption uses symmetric keys, a user will need to enter a passphrase when the system boots.  A pass phrase is not required for file system encryption.  

Benefits of D@RE

*Prevents access to the data on the disk if for some reason the disk is lost, stolen or inadvertenly falls into the wrong hands (via salvage, disk return, etc...)

*Can satisfy security or regulatory requirements

*It can prevent data access under certain circumstances (for example, the OS/boot disk can be unencrypted, but the data stored on different disks can be encrypted thereby preventing access to the actual data)

Limitations of D@RE

*Will not protect against intruders who gain privileged access

*Can reduce I/O performance

*Under some configurations, if a passphrase is lost or a key is lost the data is lost forever.

FIPS - An Ounce of Prevention...

An Ounce of Prevention...

FIPS and Data Storage - What you need to know

(FIPS = Federal Information Processing Standard)

In general FIPS defines cryptographic standards

1995: Modern FIPS Crypto standards are established (FIPS-140-1)

2001: FIPS 140-2 is established replacing FIPS 140-1 with up-to-date crypto standards and is the current standard as of 2020.

Within the FIPS 140-2 there are (4) levels of security requirements:

Level 1: The use of an approved crypto algorithm such as AES, 3DES, Diffie-Hellman, SHA, RSA and secret or public keys

https://docs.oracle.com/cd/E53394_01/html/E54966/fips-refs.html#OSFIPfips-certrefs-1

Level 2: Includes the use of level 1 encryption algorithms plus tamper evidence and role-based access
such that the user is authenticated to a certain role.

Level 3: All of the requirements of Level's 1 and 2 but also add's that tempering will likely result in damage to the device and in particular the crypto module.  Also requires identification of the user as well as key protection schemes such as storing keys in volatile memory.  Finally, these keys must use separate I/O ports from data.

Level 4: All of the Level 1,2,3  requirements plus upon detection of tampering the device is zeroed.  Also, protection against temperature or voltage irregularities  - any anomalies result in device zeroing


Do you really need to implement FIPS 140-2?

The answer is yes, even if at Level 1.  Look for FIPS 140-2 certification when buying new storage; most OEM's try to certify to Level 3..  Encryption helps protect against data compromise in cases where a disk is accidentally or needs to be returned to support or to reduce the costs of a data breach or even to meet regulatory requirements.

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.