MASARYK UNIVERSITY FACULTY OF INFORMATICS Û¡¢£¤¥¦§¨ª«¬­Æ°±²³´µ·¸¹º»¼½¾¿Ý Error detection and correction suite for FreeIPA infrastructure BACHELOR THESIS 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 authentica- tion 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 authenti- cation 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 infor- mation 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 authentica- tion 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 re- quires 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 tech- nologies (such as aforementioned LDAP, Kerberos, DNS or CA) in one com- prehensive software bundle with automated installation and common man- agement framework. However, given the sheer complexity of the system, various system mis- configurations can still throw user off the track. Since FreeIPA project pro- vides 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. GOAL OF THE 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 de- fined 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 sup- ported 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, devel- oped by the Internet Engineering Task Force, and therefore it has been pub- lished 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 rel- evant to the particular entry where they are stored. Read operations in di- rectories are optimized at cost of write operations, since majority of the re- 3 2. FOUNDATIONAL TECHNOLOGIES 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 direc- tories, 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 num- bers. 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 suffix. Suffix 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. FOUNDATIONAL TECHNOLOGIES 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 iden- tifier (OID), type, superclasses, mandatory attributes it enforces and op- tional 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.