Error Detection and Correction Suite for Freeipa Infrastructure

MASARYK UNIVERSITY

FACULTY OF INFORMATICS

Error detection and correction suite for FreeIPA infrastructure

BACHELORTHESIS

Tomáš Babej

Brno, spring 2015 Declaration

Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Tomáš Babej

Advisor: Ing. Mgr. et Mgr. Zdenˇek Ríha,ˇ Ph.D.

i Acknowledgment

I would like to express my gratitude towards everybody who supported my during writing of the thesis. I want to thank Ing. Mgr. et Mgr. Zdenˇek Ríha,ˇ Ph.D. for his help and patient, prompt responses during supervision of my thesis. Additionally, I’m grateful for the support and technological help received from the FreeIPA developers, namely Ing. Petr Špaˇcek,Ing. Martin Košek and MSc. Alexander Bokovoy.

ii Abstract

The aim of this thesis is to implement a pluggable troubleshooting tool that collects and analyzes information about FreeIPA deployment. The thesis provides a detailed view on the architecture of FreeIPA servers and clients, their interaction and the technologies they are based on. Afterwards, high- level design and implementation details are featured, which serves as a guide for further extension by FreeIPA developers.

iii Keywords

FreeIPA, LDAP, Kerberos, PKI, Cockpit, troubleshooting, pluggable, tool

iv Contents

1 Goal of the Thesis ...... 1 2 Foundational technologies ...... 3 2.1 Lightweight Directory Access Protocol ...... 3 2.1.1 Directory services ...... 3 2.1.2 Structure of a LDAP directory ...... 4 2.1.3 LDAP protocol ...... 6 2.1.4 Replication ...... 6 2.2 Kerberos ...... 7 2.2.1 Basic properties ...... 7 2.2.2 Kerberos terminology ...... 8 2.2.3 Protocol ...... 9 2.2.3.1 The Needham–Schroeder Protocol ...... 9 2.2.3.2 Kerberos v4 ...... 10 2.2.3.3 Kerberos v5 ...... 12 2.3 PKI infrastructure ...... 12 2.3.1 Digital certificate ...... 13 2.3.2 Certificate authority ...... 14 3 FreeIPA ...... 15 3.1 High level functionality ...... 15 3.2 Server Architecture ...... 16 3.2.1 Backend ...... 16 3.2.2 Authentication component ...... 17 3.2.3 Certificate authority ...... 18 3.2.4 DNS server ...... 19 3.2.5 NTP server ...... 20 3.2.6 Samba server ...... 20 3.2.7 Management framework ...... 20 3.3 Client architecture ...... 22 3.3.1 SSSD ...... 22 3.3.2 Certmonger ...... 23 3.4 Common issues ...... 23 4 Implementation ...... 25 4.1 Goals ...... 25 4.2 Overview ...... 25 4.2.1 Local data collection ...... 26 4.2.2 Remote data collection ...... 26 4.2.3 Presentation layer ...... 27

v 4.3 Details ...... 28 4.3.1 Core ...... 28 4.3.2 Plugin class hierarchy ...... 29 4.3.3 Reporter plugins ...... 29 4.3.4 Doctor plugins ...... 31 4.4 Cockpit integration ...... 32 4.5 Next development ...... 33 5 Conclusion ...... 35

vi 1 Goal of the Thesis

Nearly every organization, independent on its size, needs at one point to authenticate and authorize its members. While mechanisms for authentication and authorization have historically been document or human based, with the large number of information systems in use, the burden of this problem is being shifted to computers. As most complex software solutions available today, the authentication and authorization systems have evolved from simple ideas. The authentication and authorization in Unix based systems was localized and insecure at first, as can be seen from the fact that even passwords used to be stored in system configuration files in a plain text form. [18] Since then this area, which is also referred to as Identity Management, has grown in complexity. The need to solve these problems encouraged the development and several related technologies were developed. Centralization of the identity information became easier with directory services, such as Lightweight Direc- tory Access Protocol (LDAP) servers. Public key encryption in the form of digital certificates became more widespread and new network authentication and authorization protocols, such as Kerberos, were developed. This improvement in security came with a cost of increased burden on system administrators, who now have to setup and manage systems much more complex than those in the past. Deployment of the these systems requires domain-specific knowledge in multiple areas, and therefore is prone to misconfiguration and security errors. FreeIPA is a community software project that aims to solve the still- growing need of centralized solution for authentication and authorization in the Linux environments. It integrates several already time-proven technologies (such as aforementioned LDAP, Kerberos, DNS or CA) in one com- prehensive software bundle with automated installation and common management framework. However, given the sheer complexity of the system, various system misconfigurations can still throw user off the track. Since FreeIPA project provides most value for less knowledgeable system administrators, the hunt for the solution often becomes painful, given their lack of expertise. To improve the usability of the project, this thesis aims to create a pluggable tool for collecting information about the FreeIPA deployment, and analyz- ing this information so that common misconfiguration and pitfalls can be avoided automatically. In the second chapter, we shall elaborate on technologies that collec-

1 1. GOALOFTHE THESIS tively create the foundation of the FreeIPA server, thus giving the reader a necessary insight that will be required to understand the next chapters and the inherent problems of the FreeIPA misconfiguration. The third chapter will focus on the architecture of the FreeIPA server and clients and their capabilities, thus enhancing the relevant domain specific knowledge. Con- sequently, we explore the most frequent and important misconfiguration problems and the implementation of the diagnosis tool itself.

2 2 Foundational technologies

This chapter aims to enlighten the reader with the entry level knowledge necessary to understand the technologies that FreeIPA project bundles and their interaction. Due to the complexity of the topic presented, basic con- cepts, such as principles of symmetric encryption will be assumed as known to the reader. If necessary, pointers to the sources with additional explana- tion will be provided. Topic that will be presented have been carefully selected based on their impact on the inner workings of the FreeIPA server. • Lightweight Directory Access Protocol, LDAP,as the backend database FreeIPA uses to store most of the information

• Kerberos, as the main network authentication protocol used in FreeIPA

• Public Key Infrastructure (PKI)

2.1 Lightweight Directory Access Protocol

Lightweight Directory Access Protocol is a network application protocol that provides access to directory information services, which will be defined in the next subsection. It was developed as a conjoined effort of Uni- versity of Michigan and private sector companies to provide a lightweight alternative to its predecessor, X.500 Directory Access Protocol (DAP), which required the usage of OSI protocol stack. LDAP protocol originally supported a subset of the DAP’s functionality, which was defined by a series of computer networking standards called X.500, hence it was also referred to as X.500-lite. The most current version of the protocol is LDAPv3, developed by the Internet Engineering Task Force, and therefore it has been published in its standard track publication Requests for Comments (RFC). Its current specification is RFC 4511, however, many extensions to the LDAPv3 have been published, such as RFC 4530 or RFC 5020.

2.1.1 Directory services A directory service is a software system that serves to store and organize data. Unlike traditional relational databases, directory services store data of more descriptive nature, which are attribute based, concise and only relevant to the particular entry where they are stored. Read operations in directories are optimized at cost of write operations, since majority of the re-

3 2. FOUNDATIONALTECHNOLOGIES quests are usually value lookups or search operations. For this reason, data is often made redundant within the directory, if it helps performance. [1] Directory services can be very flexible, ranging from specialized directories, that allow only certain data and node types, to very generic ones, that allow a broad range of potentionally extensible data types. A real life example of the former type of the directory service is a telephone directory, where the only node type is a name and data type are the telephone numbers. An example of the latter would be a Domain Name Service, as the nodes within DNS can store values containing not only IP addresses, but also domain aliases, key fingerprints or certificates.

2.1.2 Structure of a LDAP directory

Directory information services, such as LDAP server, follow the X.500 model. Entries are stored in a hierarchically structured trees, each within the LDAP’s directory namespace, which is often referred to as sufﬁx. Sufﬁx usually cor- responds to the DNS domain name. This allows to properly map the LDAP directories to their corresponding DNS zones in the hierarchy.

Figure 2.1: Example of a LDAP directory structure

4 2. FOUNDATIONALTECHNOLOGIES

Each entry in the directory can contain only an allowed set of attributes, which are specified by the entry’s objectclasses. The objectclasses for the given entry are specified in a special attribute called objectclass. Each objectclass has a number of properties, such as its object identifier (OID), type, superclasses, mandatory attributes it enforces and optional attributes it allows. Objectclasses themselves are defined in the server schema. Server schema specifies the inner structure of the entries in the directory: it lists all the possible objectclasses, their types and mutual rela- tionships. It also defines the attributes themselves, their allowed syntax and matching rules. attributeTypes: (2.16.840.1.113730.3.8.3.4 NAME ’fqdn’ DESC ’FQDN’ EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN ’IPA v2’ ) objectClasses: (2.16.840.1.113730.3.8.4.1 NAME ’ipaHost’ AUXILIARY MUST ( fqdn ) MAY ( userPassword $ ipaClientVersion $ enrolledBy $ memberOf $ userClass $ ipaAssignedIDView ) X-ORIGIN ’IPA v2’ )

Figure 2.2: Objectclass deﬁnition along with its attribute type speciﬁcation

One of the attributes in the entry is always specified as the naming attribute. This is usually the user/group name, or host’s fully qualified domain name. The chain of names of entries, from root to the given entry, concatenated with the directory suffix is stored as Distinguished Name (DN) attribute. This attribute therefore represents the absolute position of the entry within the directory. dn:cn=editors,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectClass: nestedGroup objectClass: ipaobject objectClass: ipausergroup objectClass: posixgroup objectClass: groupofnames objectClass: top cn: editors gidNumber: 1738000002 ipaUniqueID: 6e5da4a2-f3fe-11e4-9dd0-001a4a222119 description: Limited admins who can edit other users

Figure 2.3: An example of a LDAP entry in LDAP Data Interchange Format format

5 2. FOUNDATIONALTECHNOLOGIES

2.1.3 LDAP protocol

LDAP protocol allows a number of operations, which can be divided into three main categories:

1. Operations to query information from the directory: searching for entries, comparing attribute values

2. Operations that perform modiﬁcations in the directory: adding, mod- ifying, renaming and deleting the entry.

3. Operations that are related to the protocol itself: binding (authen- ticating), unbinding, abandoning previous request, initiating TLS connection

2.1.4 Replication

Since LDAP directories often store critical information in one centralized point, it is important to create redundant copies of the stored data on multiple physical machines, to prevent the problem of single point of failure. Having multiple machines with the directory data is also advantageous from the performance perspective. Speciﬁcation of the LDAP protocol does not state how the replication should be performed, however, practically all implementations of LDAP directory servers support this feature. [1] There are two main types of the replication models. First is a single- master model, where one LDAP directory server contains the authoritative information in the directory. Therefore only the master directory server is writable, all the other directory servers (which are also referred to as replicas) are read-only. This model has the obvious advantage of having no possibility of data collision due to concurrent write operations on multiple servers on the same entries. However, the main drawback is the fact that all the expensive write operations are centralized on one machine. The second type is a multi-master model. In this setup, all of the LDAP directory servers contain writable copies of the replicated subtree. In such setup, no server holds the authoritative information, and therefore this replicas are being referred to as loosely synchronized. All the changes performed on any server are replicated via the replication agreements to all the other servers. This introduces the possibility of data collisions, where the same entry is modiﬁed on two different replicas. However, it removes the need to rely on one single writable server, and therefore is often preferred.

6 2. FOUNDATIONALTECHNOLOGIES

2.2 Kerberos

Kerberos is a network authentication protocol. From a network architecture aspect, it is based on a client-server model. Its notable feature is the introduction of the notion of tickets, which allow nodes to communicate and mutually authenticate in a secure way even over insecure networks. It extensively uses symmetric cryptography to protect transmitted messages from eavesdropping and replay attacks. It leverages a trusted third party to provide a mutual authentication with single-sign-on capabilities to the nodes within its network. Kerberos protocol has been developed at the Massachusetts Institute of Technology as part of the Project Athena. It is named after three headed guard dog from Greek mythology. Currently released in version 5, it is freely available under BSD-like license.[8]

2.2.1 Basic properties

Kerberos protocol can also be concisely deﬁned as a secure, single-sign- on, trusted, third-party mutual authentication service. This deﬁnition suc- cinctly captures four important properties of the Kerberos protocol.[2]

• Security of the Kerberos protocol stems from the fact that passwords are never transmitted over the network in the plaintext (unlike basic HTTP auth). Instead, it leverages tickets, which are cryptographic messages that provide user with a time-limited means of authentication, and therefore of gaining access to a given network resource.

• Single-sign-on is a property of the system, which ensures that the end users are prompted for password at most once per login session, even tough they access all Kerberized network resources. Authen- ticated user’s credentials are presented to any network resource he requests, behind the scenes, without any need for human interven- tion.

• Part of authentication mechanism in the Kerberos protocol involves communication with a centralized authentication server (AS), which is called Key Distribution Center (KDC). This represents a third party entity that all participants in the protocol trust.

• At the end of Kerberos authentication mechanism, both parties have cryptographically proved to each other their identity. This property

7 2. FOUNDATIONALTECHNOLOGIES

is referred to as mutual authentication, since no side of the channel can be impersonated by an adversary.

2.2.2 Kerberos terminology

This section aims to introduce few Kerberos specific terms, which will be intermittently used in the rest of the thesis. We have defined the Kerberos as a network authentication protocol, in which all the participating nodes have to rely on a trusted third party in the form of Key Distribution Center. The set of nodes that rely on the same Key Distribution Center constitutes a Kerberos Realm. The Kerberos Realm can be a arbitrary string, however, since the scope of Kerberos realm it often coincides with the DNS hierarchy, it is a convention to set it to the upper- cased version of the corresponding DNS domain.[2] Kerberos principal is a unique identifier which is assigned to every communicating node in the network. Uniqueness here refers to uniqueness across multiple realms, hence each principal has two parts - one that identifies the particular Kerberos realm, and one that identifies the given node within it.

[email protected]

Figure 2.4: An example of a user Kerberos principal

In practice, since the communicating nodes are either users or services they access within the network, there are two types of Kerberos principals in use - user principals and service principals. An example of user principal is demonstrated in the Figure 2.4. The service principal has usually the form of service_name/host.fqdn@REALM, since multiple services can be run on the same host. Each principal has an associated long-term Kerberos key, which is known to the end user or service and the Key Distribution Center itself. This key is either derived from the user’s password or randomly generated. After authentication to the Key Distribution Center, user obtains a Ker- beros ticket, which is a form of time-limited credentials within the Kerberos network, that can be used to verify the user’s identity. To obtain a ticket to any service in the network, the user must ﬁrst be issued a Ticket Grant- ing Ticket (TGT), that permits him to obtain tickets to access other services within the network during the lifetime of that particular TGT. The tickets to access services within the network are referred to as service tickets.

8 2. FOUNDATIONALTECHNOLOGIES

2.2.3 Protocol 2.2.3.1 The Needham–Schroeder Protocol The Needham-Schroeder symmetric key protocol serves to establish a shared session key between two communicating parties on the network using a trusted third-party. Kerberos protocol was built by improving and extend- ing the Needham-Schroeder protocol[2, Section 3.1], hence it will be brieﬂy introduced here. We start by listing the assumptions using the generic security protocol notation. Suppose that the communication is initiated from Alice (A) to Bob (B), while S is a server which is known to and trusted by both participants. Each of the communicating parties have established secret long-term keys KAS and KBS with the server prior to this exchange.

Figure 2.5: Needham-Schroeder protocol exchange

1. A → S : A, B, NA Alice starts the authentication protocol by identifying herself (A) and Bob. Random nonce NA serves just as a request identiﬁer. Note that this message is sent in plain-text.

2. S → A : {NA,KAB,B, {KAB,A}KBS }KAS Server responds by generating random a shared session key KAB. This key is unrelated to long-term keys KAS and KBS. The message sent back to Alice is encrypted under Alice’s long-term key and in- cludes the shared session key, Bob’s identity, the request’s nonce and

9 2. FOUNDATIONALTECHNOLOGIES

a message for Bob, encrypted under Bob’s long term key. Message contains both the shared session key they will use to communicate and the Alice’s identity.

3. S → A : {KAB,A}KBS Alice forwards the encrypted message from KDC to Bob, who decrypts it to obtain the shared session key and Alice’s identity. Since the message is encrypted under Bob’s long-term key, which is known to S and Bob only, successful decryption serves as a proof that the data was generated by S.

4. B → A : {NB}KAB At this step of the protocol, Bob needs Alice to prove her identity (since step 3 could be replayed by an adversary that does not hold the session key, but intercepts the message). To accomplish this, he sends her a random nonce encrypted under their shared session key.

5. A → B : {NB − 1}KAB Alice decrypts the message, she performs a simple operation on the nonce. She sends the modiﬁed version, encrypted under the shared session key back to Bob, thus proving she has the session key KAB.

This concludes the exchange. It should be noted that during the protocol, the long-term key of either party, nor it’s derived version, such as hash, has not been transmitted over the network.

2.2.3.2 Kerberos v4

Kerberos v4 is the ﬁrst public version of the Kerberos protocol, released by MIT. Internally, versions 1-3 have been developed. Kerberos 4 is based on and improves upon the previously described Needham-Schroeder symmetric key protocol. First, let us discuss the simi- larities:

• User and service principals are mapped to node identities

• Trusted third-party in the form of the server is the Key Distribution Center

• Message used in the step 3 by Alice to share the secret session key with Bob is the precursor of a Kerberos ticket

10 2. FOUNDATIONALTECHNOLOGIES

However, there are important differences between the two protocols as well. In the original Needham-Schroeder protocol, the steps 4 and 5 were added to prevent the possibility of man in the middle attack between the client and the service, and also to rule out the possibility of a replay attack of the session key. However, this exchange proved inefﬁcient, since it decreases the performance of the system (requires two additional exchanges), and more importantly, has been proven susceptible to a reply attack if a older value of the session key has been compromised. Kerberos v4 ﬁxes this issue by adding a encrypted client timestamp under the shared session key to the message. By decrypting the timestamp, service can verify that user holds the shared session key and that the key is not a older one being replayed. However, this requires all communicating parties to have network time synchronized. Kerberos protocol enforces maximal time skew of 5 minutes.

Figure 2.6: Simpliﬁed Kerberos protocol exchange

The second, more signiﬁcant change, is that Kerberos v4 enables single- sign-on for users within it’s network. In Needham-Schroeder, if an user wants to access two different network services, he will need to enter his password twice, if his long term key is derived from his password. Ker-

11 2. FOUNDATIONALTECHNOLOGIES beros v4 however, introduces the concept of Ticket Granting Ticket, which allows the user to obtain tickets for other services. Logically, the Key Distri- bution Center is split into two subentities: • Authentication Server, which receives the requests for authentication from clients, and returns the TGT • Ticket Granting Server, which issues tickets for users to access other services, if presented with TGT With this distinction, Kerberos v4 protocol is able to provide users authenticated access to the network services without need to provide credentials repeatedly by human interaction. It is worth noting that all tickets in Ker- beros v4 protocol have limited time stamp - which is usually between 8 - 24 hours. This provides a mechanism for users to verify their identity periodi- cally and narrows the window of vulnerability in the case of attacker using the stolen credentials.

2.2.3.3 Kerberos v5 Kerberos v5 is an evolution of Kerberos v4 protocol, from the perspective that it provides a superset of features of Kerberos v4. It is described by RFC 4210, and compared to its previous version, it introduces a number of extensions and improvements. The old Kerberos v4 protocol was rigid in that sense that many of the fields have had specified, fixed, sizes. This prevented security measures, such as increasing the shared key size. Kerberos v4 uses single-DES encryption keys, which have key size of 56 bits and are therefore considered insecure with the current computational power available. As of 2008, DES keys have been broken in less than a day. The added extensibility allowed the introduction of several new features. Among the most important is the credentials delegation, which allows users to use their credentials on the remote machines they’re logged into. Kerberos v5 also strengthens the security mechanisms, as it introduces pre-authentication, support for one time passwords or elliptic curve cryptography.

2.3 PKI infrastructure

The public key infrastructure has developed around the concept of asymmetric encryption. In asymmetric encryption scheme, each communicating party has a key pair - a public and a private key. Messages encrypted

12 2. FOUNDATIONALTECHNOLOGIES with an individual’s public key can only be decrypted with his private key. Therefore, to ensure safe and secure communication, two conditions must be fulfilled - private key must be kept secret, and public key must be ex- changed (or published) in such a way, that its ownership is verified. Public key infrastructure attempts to address the latter problem using a trusted third party. It consists of software (and hardware) elements that this trusted third party can leverage to verify the ownership of a public key and its integrity. To achieve this, identity proofs called digital certificates are created to map the public keys to their respective entities. Trusted third parties that verify the identity of the subjects and issue digital certificates mapping them to their public keys are called Certificate Authorities.

2.3.1 Digital certificate Digital certificate is a electronic data structure containing a public key and the identity of its owner. The certificate itself contains additional fields, such as validity period, or digital signature of the entity that verified the ownership. If that entity that is trusted by the client, the certificate is considered verified. Currently, most common type of a digital certificate is X.509 version 3, defined in RFC 3280. The certificate defines following fields:

• Certiﬁcate

– Version, containing the version of the encoded certificate (3 for X.509v3 with extensions). – Serial Number, positive integer assigned by the CA to each certificate, unique within the set of certificates issued by that CA. – Algorithm ID, algorithm identifier for the algorithm used by the CA to sign the certificate. – Issuer, non-empty distinguished name the entity who has signed and issued the certificate, such as CN=Certificate Authority, O=MyCompany. – Validity, defining the time interval during which the certificate is considered valid. ∗ Not Before ∗ Not After – Subject, the identity of the entity being certified.

13 2. FOUNDATIONALTECHNOLOGIES

– Subject Public Key Info ∗ Public Key Algorithm, algorithm, with which is the public key used, such as RSA or Diffie-Hellman ∗ Subject Public Key, actual contents of the public key of the certified entity. – Issuer Unique Identifier (optional) – Subject Unique Identifier (optional) – Extensions (optional)

• Certificate Signature Algorithm, defines the algorithm used to sign the certificate.

• Certiﬁcate Signature , actual signature of the certiﬁcate.

2.3.2 Certificate authority Certificate authority is the trusted third party entity, that issues digital certificates and verifies the identity of its subject. The subject in question must prove the ownership of the private key and his identity. Consequently, it will be issued a digital certificate by the CA, which, in turn, will make the issued certificate trusted by all the clients that trust the issuing CA. Additionally, CA performs other functions that relate to the management of the certificates. Since issued certificates need be in certain cases, such as private key being compromised, revoked, Certificate Authorities keep a Certificate Revocation List (CRL). This list enumerates serial numbers of certificates that had been invalidated, and therefore are no longer to be trusted by the clients. However, this requires clients to download the CRL lists and keep them updated. As an alternative, CA might also support the Online Certificate Status Protocol (OCSP), which can be used to obtain the revocation status of a given certificate directly. From the standpoint of the hierarchy, Certificate Authorities can also sign certificates of other Certificate Authorities, therefore creating a trusted chain of Certificate Authorities. Certificate is considered valid as long as there exists a trusted path from the subject to the trusted (also called root) certificate authority.

14 3 FreeIPA

FreeIPA is a directory and authentication server (also referred to as Domain Controller), that is primarily targeted at Linux and Unix workstations. In a centralized manner, it stores identity information, policies related to those (and external) identities and performs authentication and authorization for users and services within the domain. It integrates a large number of existing open source components, such as 389 Directory server, MIT Kerberos, or Dogtag Certiﬁcate System into one cohesive solution, with additional management framework and con- ﬁguration tools. Modern versions of FreeIPA are also capable of establish- ing a cross-realm Kerberos trust with Microsoft Active Directory domains, hence bridging the gap in traditional deployments where Active Directory is widely used.[6, Chapter 8] FreeIPA upstream project was started in 2007, and FreeIPA version 1.0 was released in 2008. Currently, the latest released version is 4.1.4. [9]

3.1 High level functionality

To provide a better overview of the FreeIPA domain capabilities, we enu- merate the most important features of a FreeIPA server.[7, 9] • Identity management

– Storage and management of identities of users, services and hosts in the domain. – Group management for the users and hosts via user groups and hostgroups (or netgroups). – Accessing third party identities from Active Directory.

• Centralized storage and management of identity related information

– Integrated DNS server for FreeIPA DNS domain. – Certiﬁcate management and automated renewal of expired cer- tiﬁcates.

• Policy enforcement

– Host Based Access Control, ﬂexible rules that specify users that can access particular service, and on which hosts.

15 3. FREEIPA

– Role Based Access Control, that allows ﬂexible delegation of administrative rights among FreeIPA users. – Centralized storage and enforcement of sudo rules. – Mapping of FreeIPA users to their SELinux user identities. – Support for 2-factor authentication using one time passwords.

• Accessibility and usability

– Single sign on capabilities, due to the use of Kerberos. – Common server and client installer – Web and command-line user interface

3.2 Server Architecture

The interaction of particular FreeIPA components is complex, both on server and client side. This section explains the most important building blocks of the FreeIPA domain and their functions. The following ﬁgure visualizes the interaction between the components.

3.2.1 Backend

Each FreeIPA server has a number of mandatory and optional components. As the backend, FreeIPA uses LDAPv3 compliant server 389 Directory server. The majority of other components use FreeIPA’s LDAP database to store long-term identity, authentication and authorization related data.[6, Section 1.2.2] The usage of LDAP server as a backend enable FreeIPA to provide higher data redundancy and load balancing by deploying multiple replicas of the original FreeIPA server. FreeIPA currently only allows replicas in a multi-master environment. Since all policy, identity or conﬁguration data is stored in the LDAP directory, access to certain parts of the tree is restricted. Depending on the conﬁdentiality of the data involved, parts of the tree are open (such as group entries) to anonymous searches, while others are available only to authenticated or privileged users (entries in the DNS subtree). FreeIPA extends the native 389 Directory Server’s functionality with a number of plugins. Notable examples are ipa_lockout LDAP bind plugin, which prevents external attackers from brute-forcing user passwords using LDAP BIND operation by locking them out after a number of consequent

16 3. FREEIPA

Figure 3.1: Simpliﬁed schema of architecture of FreeIPA. Mandatory parts in red, optional server parts in blue. unsuccessful attempts or schema compatibility plugin, which creates a al- ternate tree containing user entries in the RFC 2307bis schema, thus allow- ing certain legacy systems to leverage the user identity information stored centrally in FreeIPA.[10] Standard LDAPv3 protocol (and related tools, such as modify) can be used to communicate with the FreeIPA’s LDAP server and modify the data stored there, however, such practice is discouraged for regular admin pur- poses due to the complexities involved. FreeIPA bundles a CLI and WebUI management framework that provide a higher-level abstraction layer.

3.2.2 Authentication component

Authentication services for the FreeIPA realm are provided by the Kerberos KDC. [6, Section 1.2.1] FreeIPA uses MIT Kerberos 1.11, which builds on Kerberos v5 protocol. FreeIPA’s integrated Kerberos KDC sources all the user and service identity information from the LDAP directory. Additionally, the same LDAP backend is used to store the Kerberos speciﬁc data, such as Kerberos keys, policies and conﬁguration. To achieve this, FreeIPA uses a custom ipa-kdb

17 3. FREEIPA plugin for Kerberos. The plugin also enhances KDC with additional functions, such as creation, veriﬁcation and signing of the MS-PAC extensions, which is required for the integration with the Active Directory domains using the cross-realm trusts.[11] Primary usage of Kerberos as the authentication protocol allows FreeIPA to provide single-sing on capabilities while keeping the environment very secure. Furthermore, FreeIPA extends the MIT KDC to allow the usage of FreeIPA managed one-time passwords (OTP), thus enabling a 2-factor authentication. It should be noted that FreeIPA allows usage of regular LDAP binds for authentication in legacy cases. In this setup, one time passwords support is also available.[15]

3.2.3 Certificate authority Since not every protocol leverages Kerberos to establish secure sessions, namely HTTP, IMAP, SMTP or VPN, FreeIPA bundles a Dogtag Certificate System server to sign and publish certificates for FreeIPA hosts and services. This feature of FreeIPA is also referred to as PKI service. [6, Section 1.2.3] It can also provide other traditional CA functions, such as certificate revocation list (CRL) for publishing the list serial numbers of certificates that have been revoked, or online certificate status protocol (OCSR) that is used to obtain the revocation status of a certificate.[12] Current version used by FreeIPA is Dogtag 10.2. Dogtag Certificate System is configured to store date in the FreeIPA’s LDAP directory, under the o=ipaca suffix. This subtree is replicated to other FreeIPA replicas. All of the certificates that were issued by FreeIPA for hosts and services have limited validity, and therefore need to be renewed after their expiration. A client side daemon Certmonger, which will be described in the FreeIPA client section, ensures that certificate renewal is performed in time. However, introducing a new certificate authority can be difficult in existing deployments. For this reason FreeIPA supports three levels of incor- porating into existing CA infrastructure[7, Section 3.4]:

1. FreeIPA will use a self-signed CA certificate for its PKI service. This has the major disadvantage of additional configuration costs on each host in the FreeIPA domain, as they need to be configured to trust the certificate.

2. Signing the FreeIPA’s CA certiﬁcate by existing, trusted, external

18 3. FREEIPA

Figure 3.2: Three types of FreeIPA CA blending in existing infrastructure

CA. FreeIPA will provide the user with a certiﬁcate signing request (CSR) so that the FreeIPA’s CA certiﬁcate can be correctly chained into the already existing PKI infrastructure.

3. Setting up FreeIPA without CA. Since SSL certiﬁcates for securing HTTP and LDAP protocols are necessary, they will be required during the installation and need to be signed by an external trusted CA.

3.2.4 DNS server

Properly managed DNS zones are crucial to identifying machines on the network. FreeIPA provides a optional DNS server to simplify DNS management for machines within the FreeIPA realm. The recommended setup is to delegate the corresponding FreeIPA’s DNS zone to the FreeIPA managed DNS server. This provides simpliﬁed management in the form of automated creation of records in the FreeIPA DNS zone, such as A and PTR records for FreeIPA managed hosts, or SRV records for LDAP, Kerberos or PKI services. However, this is not required, and admins can continue to use existing DNS infrastructure provided they create the necessary records themselves.[13] FreeIPA’s internal DNS server is a instance of BIND 9, developed by Internet Systems Consortium.[17] It is enhanced by backend bind-dyndb- ldap plugin, which stores all zone related data in the separate LDAP tree cn=dns within FreeIPA’s directory server.

19 3. FREEIPA

3.2.5 NTP server

Synchronized network time on all the hosts is a necessary requirement for the FreeIPA domain, since Kerberos cannot handle a time skew greater than 5 minutes between any two hosts. For this reason, FreeIPA sets up a NTP server on each master. The speciﬁc implementation is ntpd, which is a fully compliant implementation of NTP server according to the Network Time Protocol version 4. Administrators are not required to run this speciﬁc implementation on their servers, however, having a NTP daemon on each master is recommended. Presence of NTP server allows machines to synchronize time directly with the local time of the KDC. NTP synchronization is setup on each client as a requirement of host joining the FreeIPA domain.

3.2.6 Samba server

Samba is an open-source implementation of several Microsoft networking protocols, such as Network Basic Input Output System (NetBIOS), Server Message Block (SMB, also referred to as Common Internet File System, CIFS) or Microsoft Remote Procedure Call (MS-RPC). It provides ﬁle and print services for Microsoft Windows clients as well as interoperability with Active Directory and Windows NT domains. Samba was initially released in 1992, and still actively developed (current stable release is 4.2.0). It is available on most Unix-based systems, such as Linux, AIX, Solaris or BSD.[5] To allow establishment of cross-realm trusts with existing domains con- trolled by Microsoft Active Directory, FreeIPA provides a option to setup internal Samba server. It is necessary since AD domain controllers require access to MS-RPC services such as NetLogon, which Samba server imple- ments. FreeIPA enhances the internal Samba server by setting up ipasam backend, which allows Samba accessing and storing data within FreeIPA’s LDAP directory.[16]

3.2.7 Management framework

To achieve its main goal, which is simpliﬁcation of administration of Iden- tity Management systems, FreeIPA exposes a command-line interface (CLI) as well as and web user interface (WebUI).[7] Both interfaces provide a different frontend to the same IPA management framework, which runs as Web Server Gateway Interface application running on a internal Apache 2

20 3. FREEIPA instance. To allow authentication using Kerberos, Apache 2 module mod_auth_kerb is enabled and conﬁgured.

$ ipa user-add adent --first Arthur --last Dent ------Added user "adent" ------User login: adent First name: Arthur Last name: Dent Full name: Arthur Dent Display name: Arthur Dent Initials: AD Home directory: /home/adent GECOS: Arthur Dent Login shell: /bin/sh Kerberos principal: [email protected] Email address: [email protected] UID: 1354000003 GID: 1354000003 Password: False Member of groups: ipausers Kerberos keys available: False

Figure 3.3: FreeIPA command line interface

It provides XML-RPC and JSON-RPC interfaces for executing commands on the FreeIPA master. Additionally, Python libraries are available to run the management commands from user scripts. More than 300 commands are provided, ranging from ordinary user life cycle management, such as ipa user-add or ipa user-del, to more complex commands as ipa trust-add, which establish a cross-realm Kerberos trust with an Active Directory domain. Management system can be accessed from any client machine that is member of the FreeIPA domain. Since user authentication to the management framework is performed using Kerberos, hence administrators are required to authorize themselves to KDC and obtain ticket prior to executing any FreeIPA management commands. Additionally, web interface can be accessed using a form-based authentication on machines that aren’t con- ﬁgured to work with Kerberos, in which case the ticket is obtained on the server side on behalf of the user, which needs to log in using his Kerberos password.

21 3. FREEIPA

Figure 3.4: FreeIPA web user interface

3.3 Client architecture

3.3.1 SSSD

System Security Services Daemon (SSSD) is a mandatory part of each non- legacy FreeIPA client. Its purpose is to provide access to different identity and authentication mechanisms for local services on the system. SSSD supports different remote identity providers, such as LDAP directory, FreeIPA domain or Active Directory.[7, Section 1.2.5] In addition, SSSD also performs caching of the identity and policy information on the client system, thus reducing the necessary load on the FreeIPA domain servers (or any other identity provider). Optionally, it can permit ofﬂine authentication of the users that are present in the cache, thus creating a workaround for system downtime. SSSD can obtain the variety of the data using only one socket, which is not possible with traditional, multi-daemon solutions. System Security Services Daemon accomplishes system authentication and authorization with custom modules for Name Switch Services (NSS) and Pluggable Authentication Modules (PAM). It can replace or enhance local databases, like passwd, group or shadow with network provided data. On the client machine, SSSD also performs authorization by enforcing Host Based Access Control (HBAC) rules or centralized rules for sudo, in case of being conﬁgured with FreeIPA provider. It can also perform mapping of

22 3. FREEIPA user identities to SELinux users on the system. SSSD being developed in close relationship with FreeIPA and the projects share similar development history. Current stable version of SSSD is 1.12.4.[19]

3.3.2 Certmonger The certmonger daemon is a Desktop-Bus (D-Bus) based service, which tracks and monitors certificates on the client in the networks that leverage public-key infrastructure (PKI). It checks for approaching expiration date, and if configured, it can perform automated certificate renewal with the certificate authorities. It has capabilities to supervise the entire enrollment process, including the key generation, enrollment and periodic renewal itself.[6, Appendix B] Certmonger supports flat files, like those used by OpenSSL, or with Net- work Security Services (NSS) databases. It can be configured to work with any Simple Certificate Enrollment Protocol (SCEP) Certificate Authority, such as FreeIPA’s Dogtag.

3.4 Common issues

During research of the most common issues during the evaluation part of the thesis, two main sources were used - the pre-existing Troubleshooting pages provided by the FreeIPA community[14], and freeipa-users mailing list1, which serves as a mail based support forum for users. Messages from up to year 2013 were considered. While individual problems in the mail threads were mostly different, a majority of them could detected by automated means without a great effort. To demostrate this, few selected issues are enlisted.

• Time skew between any two hosts in the realm causes authentication failures. Detection can be performed by comparing the local time in UTC for all the machines in the domain.

• Missing SRV records for IPA domain or missing A/AAAA records for any host in the domain. Can be detected using DNS lookups from multiple hosts.

• Stale keytab ﬁle with non-updated Key Version Number. An at- tempt to obtain TGT with such keytab will reveal the issue.

1. Archive available at https://www.redhat.com/archives/freeipa-users/

23 3. FREEIPA

From the description of the issues above it follows that it is feasible for them to be detected using relatively small set of instructions, if a tool is provided with such capabilities is provided. Often, even generation of the instructions needed to ﬁx the problem is possible. This realization served as conﬁrmation of the value and usability of the practical part of the thesis, which will be described in the next section.

24 4 Implementation

This chapter will concern itself with the discussion regarding the implementation of the practical part of the thesis, the IPA diagnostics tool. The purpose of the diagnostics tool is to provide automated mechanisms to aid user problem troubleshooting of the FreeIPA. As such, the diagnostics tool needs to collect the information about the system, which can be then presented to a human expert, who can analyze it, and provide feedback. Additionally, the tool should be able to take some of that responsibility too, by providing automated checks and possible explanations for failures.

4.1 Goals

Prior to the implementation phase, several goals for the development of the tool were established. First, it was determined it is necessary to make sure the tool pluggable, to ensure easy extensibility by the community developers, who are often not too familiar with the code base. In addition, this would enable simplified distribution of any unofficial additions, since they can be distributed as individual files, rather than stray patches. Second, the outward simplicity was marked as desired. Even if the inner mechanisms of the tool may be intricate, such complexity should not be presented to the end user to avoid the need to overcome a steep learning curve in order to use the diagnostics tool. Furthermore, since not every administrator has high experience with using command line based applications, to increase the set of possible users a simple web user interface should be provided.

4.2 Overview

The IPA diagnostics tool is exposed to user as a single ipa-diag command. Internally, however, it is composed of several parts, which can be divided into two main categories - the diagnostics core and the pluggable data collection and evaluation modules.

• IPA diagnostics core

– User interface, which handles command-line interface and interaction with the user.

25 4. IMPLEMENTATION

– Diagnose runner, class that manages plugin execution and result evaluation, both locally and from remote FreeIPA client machines. – Plugin proxy, that provides a simpliﬁed interface to access plugins and their applicable subsets. – Output handler which manages the generation of the output depending on the current mode.

• Data collection and evaluation plugins

– Plugins that handle system information collection, referred to as reporters. – Plugins that evaluate collected information, referred to as doctors.

4.2.1 Local data collection

Even though the IPA diagnostics tool has capabilities to collect information from remote host, on each host has to run the local data collection and evaluation first. This process is invoked by executing the ipa-diag command. It starts by processing the command line options and initializing the diagnosis framework. Depending on the level of permissions of the user (whether he has root credentials or just a regular administrator), the type of the machine (server or client) and the services being available on the host (such as Dogtag Certificate Authority, DNS server or Samba server), a applicable subset of Reporter and Doctor plugins is filtered by plugin proxy. After initialization of the plugin proxy, local diagnosis itself starts. First, all applicable Reporters are run to collect the information about the host. This information is then aggregated and evaluated by the Doctor plugins, which can also perform additional checks and provide feedback to the user if a known problem was detected. After collection of the local data, the collection of diagnosis results from other hosts is performed, if specified by the user.

4.2.2 Remote data collection

To evaluate potential problems happening in the FreeIPA deployment, collected information from one FreeIPA master, even though it has access to the shared replicated LDAP tree, might not be sufﬁcient. A good example

26 4. IMPLEMENTATION of this predicament is the necessity of keeping the network time of the machines in the FreeIPA realm synchronized, demanded by the requirements of the Kerberos v5 protocol. This problem, and many others, cannot be re- liably detected and addressed unless (potentionally) information from all the hosts in the FreeIPA domain can be collected. To address this issue, IPA diagnostics tool can optionally perform a diagnosis on every host in the realm, and collect the resulting data for further processing. It provides additional pluggable interface for DomainReporters and DomainDoctors that operate upon data collected from all the hosts that have been reached. This allows the developers to aggregate the data in a concise form, present it to the user and evaluate the presence of potential domain-wide issues. To avoid the cost of additional conﬁguration on the administrators, and to prevent increasing the attack surface, the data collection is performed over Secure Shell protocol using the credentials of the user performing the diagnosis on the current host. An implementation of a custom protocol to collect the data has been considered as well, however, this approach has multiple deﬁciencies. First, it requires a presence of a client-side daemon that would anticipate incoming connections over this protocol. This could be mitigated by usage of supervisor process (such as systemd), which would listen on the desired port and use socket activation to start diagnosis on demand. However, it would it mean a decreased portability of the tool. Second, since performing diagnosis requires very high credentials (potentionally at the level of the Directory Manager in LDAP, and that of root on a system level), a careful authentication and authorization framework would need to be implemented. Despite our best intentions, this would bring increased security risk, and decrease the adoption of the tool among FreeIPA users.

4.2.3 Presentation layer

If we neglect the possibility of increasing verbosity levels and displaying debugging information on standard output, IPA diagnostics tool offers two basic modes of operation regarding the presentation layer. Depending on whether the ipa-diag tool has been invoked with of the usage of –json-only command line option, IPA diagnostics tool will either produce richly for- matted command line output, or terse, machine-friendly output in JavaScript Object Notation (JSON) for further processing. The JSON data format was chosen due to simplicity, language-independence and good support in Python, JavaScript and other languages.

27 4. IMPLEMENTATION

$ sudo ipa-diag --advice --domain Collecting reports: [####################] 13/13 Performing checks: [####################] 7/7 Collecting remote data: [####################] 2/2 Collecting domain reports: [####################] 1/1 Performing domain checks: [####################] 0/0 ======IPA Diagnostics report ======------System information ------CA: Enabled: True Config: Default SELinux user map: unconfined_u:s0-s0:c0.c1023 Migration mode enabled: False DNS: Enabled: True LDAP: Extra plugins: IPA SIDGEN, ipa_extdom_extop, ipa_cldap, ipa-sidgen-task List of current hosts replicas: diag2.ipa.test Missing plugins: Number of enabled plugins: 76 Number of replication agreements: 1 Process size: 1714724 kB System: Hostname: diag.ipa.test Time in UTC: 20150518T002306Z Trusts: Enabled: True ------System health check ------DNS: IPA domain service records correct: [Pass] IPA masters A records resolvable: [Pass] IPA masters AAAA records resolvable: [Fail] diag2.ipa.test., diag.ipa.test. LDAP: Check replica readability: [Fail] diag2.ipa.test unreachable Number of replication agreements: [Pass] System: Obtain host TGT: [Pass] Trust: Verify IPA LDAP SRV records: [Pass]

------Domain information ------General: Number of masters reached: 1

------Remediation advice ------Check replica readability: Remote replica LDAP is unreachable but local LDAP service is. Please check that LDAP service on remote replica is running and firewall open on port 389.

Figure 4.1: Human friendly output of diagnosis tool, including generated advice.

4.3 Details

4.3.1 Core

The core of the IPA diagnostics tool is composed of all the parts that are not directly collecting the information about the FreeIPA deployment or evalu- ating it. Therefore the core has to handle the interaction with the user, load-

28 4. IMPLEMENTATION ing of the dynamic pluggable parts and the logistics of the analysis itself. Each of these functions, to adhere with the Single Responsibility Principle 1, is performed by a separate class in the framework. The main class that handles the interaction of the user, including pars- ing the command line arguments, is the IpaDiagnose class. Since it is run ﬁrst when the ipa-diag is invoked, it handles creation of remaining helper classes and executes the main body of the tool. The ﬁltering and storage of references to the dynamic plugins is handled by the DiagnosePlugin- Proxy. The diagnosis itself, including the local collection and evaluation of the data as well as of the data from remote hosts, is performed by the Diag- noseRunner class. The last remaining main class, DiagnoseOutputHandler takes care of the generation of both machine and human readable output.

4.3.2 Plugin class hierarchy

One of the goals of the thesis is to ensure that data collection and evaluation performed by the tool is fully and easily extensible. To achieve this, IPA diagnostics tool provides 4 different base classes for diagnostics plugins - Reporter, Doctor, DomainReporter and DomainDoctor. To mount the plugins, IPA diagnose tool leverages FreeIPA’s pluggable API and creates a new API instance containing of diagnostics-related plugins. Majority of the framework code in the plugin base classes was refac- tored into parent classes and has default implementations. This ensures very terse and simple implementations of the diagnostics plugins themselves, and practically boils down to creating a base class with one method. Therefore we consider the entry barrier for additional contributions very low.

4.3.3 Reporter plugins

The Reporter plugins are the data collection workers. The focus of each Re- porter plugin is to collect one piece of factual information about the system, and they have no capabilities to pass on evaluate of the data to the user. In- terpretation of the data is supposed to happen by the user himself, or with a respective Doctor plugin. Each Reporter plugin is derived from a class which inherits from BaseRe- porter - either Reporter or DomainReporter. Depending on its parent class

1. See http://www.objectmentor.com/resources/articles/srp.pdf for more information.

29 4. IMPLEMENTATION

Figure 4.2: Plugin class hierarchy

Figure 4.3: UML diagram of the Reporter class and its base classes the reporter will either gather data for each host, or only after the data for all the checked hosts is collected. The following figure demonstrates a creation of a new local Reporter plugin. A Reporter plugin is an instance of Reporter class. Since Reporter.report is an abstract method, any new plugin needs to reimplement it, and additionally set several attributes related to the classification of the reporter. To allow greater ease of development, reporters have access to the FreeIPA server’s API and LDAP connection. Since majority of the FreeIPA configuration is available either via direct LDAP searches or by executing IPA commands, this optimization improves performance, since it is not necessary for each plugin to establish a new connection to the LDAP server.

30 4. IMPLEMENTATION

Additionally, reporters can leverage the Reporter.is_applicable() method or client_only/server_only ﬂags to further prevent their execution in environments where it does not make sense.

1 import socket 2 from ipadiag.pluggable import Reporter, register 3 4 @register() 5 class hostname_reporter(Reporter): 6 """ 7 Reports the machine’s hostname using socket.gethostname() call. 8 """ 9 10 11 group= ’System’ 12 cli_name= ’Hostname’ 13 14 def report(self): 15 return socket.gethostname()

Figure 4.4: Reporter plugin that returns the hostname of the host.

4.3.4 Doctor plugins

Doctor plugins are entities that verify assumptions about FreeIPA deployment, and depending on the result of the veriﬁcation, provide feedback for the user. As with reporters, there are two types of doctor plugins (inheriting either from Doctor or DomainDoctor) depending on the whether they need local or domain-wide data for their evaluation. Doctor and DomainDoctor classes have very similar interface as the Re- porter and DomainReporter classes described in the previous section, since they share a common ancestor. For the sake of brevity, class diagram with details is excluded. In addition to assumption veriﬁcation result, doctors can generate feedback with remediation advice to solve to problem, as seen by the following example, which demonstrates a doctor, that checks IPA master for it’s abil- ity to connect to the LDAP service of its replicas.

31 4. IMPLEMENTATION

1 @register() 2 class check_masters_readability(Doctor): 3 """ 4 Tries to access LDAP service on each host 5 it has replication agreement with using 6 the DS keytab. 7 """ 8 9 group= ’LDAP’ 10 cli_name= ’Check replica readability’ 11 requires_root= True 12 server_only= True 13 14 def check(self, reports): 15 # Generated a named temporary file, which is deleted 16 # when the object is destroyed 17 ccache= tempfile.NamedTemporaryFile() 18 self.temp_ccache_env={’KRB5CCNAME’: ccache.name} 19 20 # Obtain a ticket using a DS keytab 21 # The root permissions are necessary for access 22 # to this file 23 result= self.run([’kinit’, 24 ’-kt’, ’/etc/dirsrv/ds.keytab’, 25 ’ldap/%s’% api.env.host], 26 env=self.temp_ccache_env, 27 raiseonerr=False) 28 if result.returncode !=0: 29 raise DiagException("Unable to kinit using DS keytab.", key="kinit-unable") 30 ... 31 32 # Check if we can read all the replicas we have replication agreement 33 # with 34 for replica in replicas: 35 result= self.check_host_ldap_readability(replica) 36 if result.returncode !=0: 37 raise DiagException("%s unreachable"% replica, 38 key="replica-unreachable") 39 def get_advice(self, key): 40 if key == ’master-unreachable’: 41 return ("Local LDAP service is unreadable using the DS keytab. " 42 "Check if the dirsrv process is running and firewall " 43 "open.") 44 ... 45 elif key == ’kinit-unable’: 46 kvno_command= "# kvno -k /etc/dirsrv/ds.keytab ldap/ %s"% api.env.host 47 return ("Unable to kinit using DS keytab. Check Kerberos server. " 48 "Additionally, keytab kvno of /etc/dirsrv/ds.keytab " 49 "might be stale. Check with: %s"% kvno_command)

Figure 4.5: A complete Doctor implementation with advice generation (code shortened).

4.4 Cockpit integration

Cockpit is a interactive admin interface for servers, accessible remotely through a web browser. It provides a web frontend to common command-line administration tools and is able to perform tasks as measuring current resource usage, disk partitioning, log inspection or service management. From the identity management perspective, Cockpit is very lightweight, as it del- egates the authentication and authorization to the PAM modules present on the system. This allows users to log in with their usual credentials. The communication between the browser and the server happens over a

32 4. IMPLEMENTATION custom encrypted web socket protocol using a Cockpit Host Bridge, which runs on the host and executes and spawns processes on behalf of the web user interface.[4] Cockpit project is very open to integration and provides a pluggable interface for creating new tools in the Cockpit user interface. A new tool can extend the Cockpit by copying its ﬁles in the /usr/share/cockpit/ directory. This approach was chosen to integrate with Cockpit, as it can be performed fully without altering the sources of the Cockpit project. By bundling the plugin with the FreeIPA packages, maintainers can ensure it will appear in the interface only when FreeIPA is installed on the server. Since Cockpit provides a mechanism to execute arbitrary commands on the host system with the privileges of the currently logged-in user, it can be leveraged to execute the IPA diagnostics tool and process the results in the web user interface. To obtain the raw results, ipa-diag is invoked with the usage of the –json-only ﬂag over the cockpit.spawn() API, which channels the output of the command to browser.[3] After the results are collected, JSON is parsed and results are displayed in an interactive table.

Figure 4.6: Cockpit integration screenshot

4.5 Next development

From the very nature of the tool it follows that it was optimized for organic growth of the set of plugins by the community. The initial implementation in the thesis covers the basic reporters and doctors, however, a larger set

33 4. IMPLEMENTATION of plugins with sound use cases is feasible. The possibilities of simpliﬁed troubleshooting should encourage such development. The diagnosis tool is currently (as whole FreeIPA project) only Python 2 compatible. For Python 3 transition, porting would be required. Addition- ally, the development of the FreeIPA project progressing, new plugins will need to be developed to cover the added functionality provided by the new features. Regarding UI improvements, the Cockpit plugin can be embedded in- side FreeIPA’s own web user interface. This thesis did not pursue this goal, since it’s already being worked on by the community.2

2. See https://fedorahosted.org/freeipa/ticket/4891 for more details.

34 5 Conclusion

The goal of this thesis was to investigate the architecture of the FreeIPA identity management project and design an easily extensible tool that de- tects the most common user misconfigurations to help user troubleshooting. After initial introduction to the problem domain in the first chapter, the foundation technologies of the main building blocks of the FreeIPA project were described - LDAP as the main backend service of the FreeIPA server, Kerberos, as the main network authentication protocol and PKI key infrastructure due to its importance in encryption and identity verification. In the third chapter, the architecture of the FreeIPA project was studied in more depth. Components that comprise FreeIPA servers and clients were studied, as well as their mutual interaction. Subsequently, the focus was shifted to common configuration failures, which were identified by research. The fifth chapter mostly concerns itself with the implementation of the IPA diagnostics tool. Both high-level overview of the design and the implementation details are covered. From the practical standpoint, the IPA diagnostics tool was developed, with the focus on both the easy extensibility and simple user interface. A straightforward command line interface was developed. Additionally, tool can be accessed using a web user interface thanks to the integration with the Cockpit project. A basic set of plugins for the tool was designed and developed in the implementation part of the thesis. However, not every misconfiguration or issue is covered. It should be noted that the focus of the thesis is rather on the creation of the easily extensible plugin system, as even a huge set of plugins would not stand the test of time, due to the relatively rapid development of the FreeIPA project. Hopefully, due to its usefulness, the capabilities of IPA diagnostics tool will be continually enhanced and maintained by the community of users and developers.

35 Bibliography

[1] Brian Arkills. LDAP Directories Explained: An Introduction and Anal- ysis. Addison-Wesley Professional. 2003. ISBN:020178792X.

[2] Jason Garman. Kerberos: The Deﬁnitive Guide. O’Reilly & Associates, Inc. Sebastopol, CA, USA. 2003. ISBN:0596004036.

[3] Cockpit Project. Documentation for Cockpit 0.48: API. 2015. URL:http://files.cockpit-project.org/guide/ api-cockpit.html (visited on 2015-02-15).

[4] Cockpit Project. Documentation for Cockpit 0.48: Cockpit Bridge. 2015. URL: http://files.cockpit-project.org/guide/ cockpit-bridge.8.html (visited on 2015-04-25).

[5] Chris Hertel, Samba Team. Samba: An Introduction. 2001. URL:https://www.samba.org/samba/docs/SambaIntro. html (visited on 2015-04-14).

[6] Ella Deon Lackey. FreeIPA: Identity/Policy Management. 2012. URL:http://docs.fedoraproject.org/en-US/Fedora/18/ html/FreeIPA_Guide/index.html (visited on 2015-03-02).

[7] Ella Deon Ballard, Tomáš Capek,ˇ Aneta Petrová. Linux Domain Identity, Authentication, and Policy Guide. 2015. URL:https: //access.redhat.com/documentation/en-US/Red_ Hat_Enterprise_Linux/7/html-single/Linux_Domain_ Identity_Authentication_and_Policy_Guide/index. html(visited on 2015-02-10).

[8] MIT Kerberos. Kerberos: The Network Authentication Protocol. 2015. URL:http://web.mit.edu/kerberos/ (visited on 2015-05-07).

[9] FreeIPA Project. FreeIPA documentation. 2015. URL: http://www. freeipa.org/page/Main_Page (visited on 2015-04-05).

[10] FreeIPA Project. FreeIPA documentation: Directory Server. 2015. URL: https://www.freeipa.org/page/Directory_Server (visited on 2015-04-14).

[11] FreeIPA Project. FreeIPA documentation: Kerberos. 2015. URL: http: //www.freeipa.org/page/Kerberos(visited on 2015-02-18).

36 5. CONCLUSION

[12] FreeIPA Project. FreeIPA documentation: PKI. 2015. URL: http:// www.freeipa.org/page/PKI (visited on 2015-05-10).

[13] FreeIPA Project. FreeIPA documentation: The DNS Component. 2015. URL:http://www.freeipa.org/page/DNS (visited on 2015-01- 06).

[14] FreeIPA Project. FreeIPA documentation: Troubleshooting. 2015. URL: http://www.freeipa.org/page/Troubleshooting(visited on 2015-02-15).

[15] FreeIPA Project. FreeIPA development designs: OTP. 2015. URL: http://www.freeipa.org/page/V4/OTP (visited on 2015-05-11).

[16] FreeIPA Project. FreeIPA development designs: IPAv3 Architecture. URL: https://www.freeipa.org/page/IPAv3_Architecture (visited on 2015-04-05).

[17] Internet Systems Consortium, Inc. History of Bind. 2015. URL: https: //www.isc.org/history-of-bind/ (visited on 2015-01-27).

[18] Robert Morris, Ken Thompson. Password Security: A Case History. Communications of the ACM. 1979. URL: http://www.cs.yale. edu/homes/arvind/cs422/doc/unix-sec.pdf (visited on 2015- 02-11).

[19] SSSD project. SSSD - System Security Services Daemon. 2015. URL: https://fedorahosted.org/sssd/ (visited on 2015-03-17).