MASARYK UNIVERSITY

FACULTY OF INFORMATICS

freeipa-manager

BACHELOR'S THESIS

Kristián Leško

Brno, Fall 2019

MASARYK UNIVERSITY
FACULTY OF INFORMATICS

freeipa-manager

BACHELOR'S THESIS

Kristián Leško

Brno, Fall 2019

This is where a copy of the official signed thesis assignment and a copy of the
Statement of an Author is located in the printed version of the document.
Declaration

Hereby I declare that this paper is my original authorial work, which

I have worked out on my own. A l l sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed i n complete reference to the due source.

Kristián Leško

Advisor: doc. R N D r . Vlastislav Dohnal, Ph.D.

i
Acknowledgement

M y gratitude goes to M i c h a l "Blesk" Marciniszyn, the author of the

original idea behindfreeipa-manager,and to the rest of our team at
GoodData for their patient guidance and support.

iii
Abstract

The goal of this work is to facilitate an improvement i n identity man-

agement and access control processes i n a corporate environment.
The thesis implements a tooling for verification and application of
access control structures i n a FreelPA server, providing a possibility
of clean access rule design and better review and audit options. The
implemented software serves for synchronization of access control
entities between an authoritative configuration source and the server.

iv
Keywords
FreelPA, identity management, L D A P , R B A C , access control

v
Contents
Introduction 1

1 Identity management (IdM) 3

1.1 Motivation 3
1.2 Concepts 4

2 IdM technologies overview 5

2.1 Directory service 5
2.2 LDAP 6
2.3 Common IdM solutions 6
2.4 Existing solutions evaluation 8

3 FreelPA 9
3.1 Features 9
3.2 Entity representation 11
3.3 Usage at GoodData 12

4 GoodData requirements 15
4.1 Entity structure management 15
4.2 Backup and restore capabilities 16
4.3 Inter-team cooperation 17
4.4 Audit 18

5 freeipa-manager implementation 19
5.1 Brief history 19
5.2 Design decisions 20

5.3 Features 22

Conclusion 27

Bibliography 29

vii
Introduction

Identity management and access control are highly important topics

i n virtually all corporate environments. Various solutions, or com-
binations thereof, are utilized by companies, and there are frequent
impulses to improve the processes and approaches i n these areas.
This thesis documents my arrival at one such company where
improvement in the practicality of identity management was desired,
and the opportunity I was offered to create a solution that w o u l d
simplify the lives of those managing user access to company resources.
The first part of this thesis introduces the problem of identity
management as a whole, evaluating the various existing solutions
w i t h their advantages and disadvantages. Later, I move on to the
specific description of FreelPA, w h i c h is the tool used as part of the
identity management solution at GoodData, and which serves as the
basis for the tooling I have implemented.
The fourth chapter then describes the state of affairs at GoodData
before the described tooling came to be, the limitations of the FreelPA
software encountered, as well as the painfulness i n the specific use
cases that became the driving factor for the changes that I was assigned
to implement.
In chapter five, I elaborate on the tooling I created to tackle the chal-
lenges faced by my colleagues responsible for identity management
tasks, outlining the challenges encountered during implementation
and the deployment process. I then move on to describe the specific
changes implemented i n the scope of this thesis that further improve
the tool and help bring it to a more practical and useful state.
The thesis wraps up by recounting the plans for further develop-
ment of the tool i n the future, along w i t h the skills and experience
that I have had the chance to obtain via participation i n this project,
the largest one entrusted to me to date.

1
1 Identity management (IdM)

Identity management (IdM) can be defined as the collection of pro-

cesses utilized to grant, verify, and revoke identity representations, or
credentials, of users of a computer system [1]. The term computer sys-
tem should be understood more broadly in this context; for instance, a
system of cards managing users' access to an office building constitutes
an identity management system although it may not be considered a
computer system i n the intuitive sense.
Various environments may call for the need to employ an identity
management system, such as user management i n a public web ap-
plication or access control of employees to different services inside a
company. A s foreshadowed i n the introduction, this thesis w i l l focus
on the latter described example, i.e. private identity management i n a
business context.

1.1 Motivation

The most fundamental goal of identity management is to ensure that

a system can differentiate its users and provide the appropriate level
of access to each of its resources to desired users only.
Some small-scale companies may be able to function without an
explicit identity management system, allowing each user to access
all available resources without any k i n d of limits or authentication
and relying on informal agreements to prevent malicious behavior.
However, as the size of a company and the importance of its resources
grows, this primitive level of access control (or absence thereof) is not
sufficient anymore; the risks that such an approach w o u l d cause are
not acceptable to most enterprises.
Additionally, resources managed by a company may not be limited
to a secure perimeter not accessible from outside. External services
(e.g., e-mail, version control repository hosting, cloud software, etc.)
may be utilized by the company as well; and since virtually all such
systems require authentication of users, it follows that identity man-
agement on the part of the company is a necessity.

3
i . IDENTITY M A N A G E M E N T ( I D M )

1.2 Concepts
A vast majority of enterprises adhere to a handful of security princi-
ples to ensure adequate protection of their resources from possible
damages caused by users, either by negligence or malicious behavior.

1.2.1 Least privilege

The principle of least privilege states that each user should only be
granted access to systems they necessarily require to carry out their
assigned work. The goal is to stop users from damaging the company
systems by not granting them extra powers they might abuse [2]. A d d i -
tionally, the application of this principle may prevent situations where
a user might accidentally access and break a system they do not use
as part of their work.

1.2.2 Segregation of duties

The related concept of segregation of duties is the idea that no single user
should possess so much power that abusing it would be detrimental to
the company [3]. This implies defining processes such as code review,
where each change to the produced software made by one user needs
to be verified by another one, or distribution of access to critically
important systems to different groups of users.

1.2.3 Role-based access control

Closely related to the principles defined above, role-based access control

(RBAC) is the idea is that access assigned to every user is based on
their role or position inside the company [4]; for instance, there is
a predefined set of access rules for a regular user, another set for a
manager, another for the director, and so on.
In common identity management solutions, this access control
paradigm may be implemented using nested user groupings to repre-
sent both the top-level user roles and other levels of access granularity.
A specific example of such a group structure w i l l be provided later, i n
Chapter 4.

4
2 IdM technologies overview

This chapter presents an overview of industry-standard identity man-

agement technologies and their usage i n the major I d M deployment
solutions. The focus has been placed on solutions with close relevance
to the topic of this work due to their technological proximity to FreelPA
or their possible role as target platforms for future expansion of the
implemented tool.
A s FreelPA itself holds a central role to the theme of this work, a
separate following chapter is dedicated to its description and analysis.

2.1 Directory service

A director}/ service, also k n o w n as name service, is an application pro-

v i d i n g the possibility to store and retrieve structured data records.
Its concept based on pre-computer era paper telephone directories
where one might look for a telephone number based on a person's
name, directory services enable storage and retrieval of resources i n a
hierarchical structure based on their pre-assigned names. A directory
service may be provided by a single server but distributed solutions
are most commonly preferred.
In the context of identity management, a directory service is gen-
erally used to store user records serving as source of truth for authen-
tication purposes. Various relevant types of data can be stored i n a
directory server apart from user information, such as representation
of relationships between resources. This allows usage of directory
servers for authorization by specifying groupings and access rules
between defined resources.
Widespread directory service implementations i n use today i n -
clude Microsoft-developed Active Director}/ , the open-source 389 Di-
1

rectory Server and Apache Directory . M a n y solutions aggregate ad-

2 3

ditional relevant services i n their distributions, such as a Kerberos

authentication server or a domain name service (DNS).

1. https://docs.microsoft.com/en-us/previous-versions/windows/
it-pro/windows-2000-server/bb727030(v=technet.10)
2. h t t p s : / / d i r e c t o r y . f e d o r a p r o j e c t . o r g /
3. h t t p s : / / d i r e c t o r y . a p a c h e . o r g /

5
2. I D M TECHNOLOGIES OVERVIEW

2.2 LDAP
Lightweight Directory Access Protocol (LDAP) is the chief protocol cur-
rently used for access to directory servers. Based on the older family of
X.500 protocols, L D A P was originally created as their lightweight al-
ternative allowing T C P / I P usage but has since evolved to a standalone
format [5].
L D A P stores resources i n a hierarchical structure identified by their
distinguished names (DN), constructed from a pre-defined attribute of
an entry and its path inside the directory tree. The entries have an
attribute-value format:

dn: cn=user1,cn=users,dc=domain,dc=com
cn: u s e r l
name: Firstname
sn: Lastname
phone: +123 456 789

This entry represents a user with a relative distinguished name, or

RDN, of cn=userl i n a subtree of the directory called cn=users; the
top-level part of each directory path is a domain composed of domain
components (in this example, dc=domain and dc=com).
In a similar fashion to relational databases, L D A P allows definition
of schemas placing constraints on data that may be stored in a given di-
rectory or a specific subtree therein [6]. Rich options of entry attributes
and data type restriction are available, permitting applications that
utilize L D A P to ensure consistency and expected format of data.
L D A P clients provide CRUD-style commands Idapadd, Idapsearch,
Idapmodify and Idapdelete for manipulation of directory entries. Most
of the directory server implementations in use today, including those
mentioned i n the previous section, are based on a version of this
protocol.

2.3 Common IdM solutions

2.3.1 OpenLDAP

O p e n L D A P is an open-source implementation of L D A P , providing

a stand-alone server called slapd and related libraries for client-side

6
 2. I D M TECHNOLOGIES OVERVIEW

applications . It may serve as a basic deployment of directory services,

mostly for simple applications.
However, there are several downsides to O p e n L D A P , the major
one being that it is a bare L D A P server requiring any extra necessary
services, such as Kerberos authentication or domain name services,
to be setup separately. This causes many administrators to prefer
full-stack solutions, such as Active Directory for Windows platform
deployments or FreelPA for Linux ones [7]. Some users also criticize
the project's slow approach to bugfixes and further development.

2.3.2 Active Directory

Microsoft-developed Active Directory (AD) is one of the most com-

monly utilized directory solutions, and can be considered an industry
standard. Although based on the Windows ecosystem, clients of other
platforms, such as Linux, can also be enrolled into and managed by
an A D domain [8].
Active Directory also natively integrates the MIT Kerberos authen-
tication server [9], useful for single sign-on user workflows, while also
supporting the L D A P protocol for client connections.

2.3.3 Cloud IdM solutions

In the recent past, several cloud directory services solutions have

emerged, w i t h the fundamental goal of avoiding costs and technical
difficulties stemming from the implementation and maintenance of
a self-hosted directory server or another identity management stack.
Various solutions are offered by vendors at differing price levels, some-
times including a free-of-charge option.
Microsoft offers Azure Active Directory as a cloud alternative to 5

locally deployed A D directory services. Apart from single sign-on and

other standard identity management features, it offers the possibility
of login integration w i t h other products of the company, such as the
Office 365 production suite, as well as external cloud applications. The

4. http://www.openldap.org/doc/admin24/
5. h t t p s : / / d o c s . m i c r o s o f t . c o m / e n - u s / a z u r e / a c t i v e - d i r e c t o r y /
fundamentals/active-directory-whatis

7
2. I D M TECHNOLOGIES OVERVIEW

term "identity as a service", or IDaaS, is used to market the product's

core features.
Another major online directory service provider seems to be Jump-
Cloud , offered under the designation of "directory as a service" (DaaS).
6

In an analogical way to the local I d M solutions or the Azure A D , it of-

fers a cloud version of an L D A P directory capable of enrolling hosts of
various platforms. The company markets a geographically distributed
network of L D A P servers allowing performance-oriented integration
w i t h self-hosted or as-a-service applications.
The number of available cloud identity services providers can be
expected to grow i n the future as the move away from technologi-
cally difficult in-house deployments of directory servers and similar
solutions becomes the standard i n the industry.

2.4 Existing solutions evaluation

At GoodData, FreelPA has been used as the primary I d M provider

for years. In the recent past, several of the solutions described above
have been analyzed as prospective FreelPA replacements i n order
to optimize maintenance costs and user experience. After extensive
decision process, it was concluded that none of the possible alternative
products would bring advantages that would offset the major required
migration effort i n a significant way.
The primary requirement for an identity system improvement was
the support for automated provisioning of access configuration, and
no available solution was identified as providing such ability. This led
the team maintaining FreelPA to decide for the implementation of a
tooling functioning on top of FreelPA, w h i c h is documented i n this
thesis.
A further analysis of the major identity management requirements
at the company that contributed to this decision is provided i n Chap-
ter 4.

6. https://jumpcloud.com/product/

8
3 FreelPA

FreelPA is a collection of applications used for identity management

and access control purposes [10], developed by Red Hat and primarily
targeting Red Hat Enterprise Einux and related platforms, such as Fedora
or CentOS L i n u x distributions. In terms of offered functionality, it
may be considered an open source alternative to Microsoft's Active
Directory, described i n the previous chapter.
This chapter seeks to analyze the major features of FreelPA w i t h
respect to the purpose of this work, and to present the logic behind
its representation of the managed entities. It then transitions to a
description of the specifics of how the tool has been deployed and
utilized at GoodData i n the lead up to the conception of this work.

3.1 Features

3.1.1 Directory server

Identically to previously presented solutions, a directory service lies at

the core of FreelPA, making use of the 389 Directory Server implemen-
tation . This L D A P server supports multi-master architecture, w h i c h
1

allows deployment of several equally authoritative FreelPA servers in

a single domain, providing advantages such as redundancy and load
balancing.
FreelPA uses the directory server to store representations of its
entities, such as users, as well as its internal configuration . However, 2

L D A P also serves as a data backend for its other components, including

the integrated domain name server and certificate server.

3.1.2 D o m a i n name service

W i t h the stated purposes of FreelPA deployment simplification and

avoidance of the notoriously difficult setup of D N S , the solution pro-
vides an integrated D N S server . This close coupling of name services
3

1. h t t p s : / / d i r e c t o r y . f e d o r a p r o j e c t . o r g /
2. https://www.freeipa.org/page/Directory_Server
3. https://www.freeipa.org/page/DNS

9
3. F R E E I P A

w i t h the rest of the I d M infrastructure enables FreeIPA servers to

automatically maintain their D N S records, which streamlines the con-
figuration of Kerberos authentication, for example.
Although, according to documentation, FreeIPA explicitly discour-
ages using provided D N S server for purposes other than deployment
of FreeIPA servers themselves, there is an ability for clients to maintain
their o w n D N S records on the server using the Linux nsupdate utility.
D N S is not a vital component of FreeIPA; DNS-less installation
of the server is possible w i t h the usage of an external name server
solution.

3.1.3 Kerberos authentication server

Kerberos is a single sign-on protocol based on the principle of users

being granted a credential, called ticket, for each resource they access
on the basis of only having entered a password a single time at the
beginning of a session. FreeIPA implements the MIT Kerberos version
of the protocol . 4

3.1.4 Certificate server

FreeIPA may be configured to contain a certificate server . Hosts en-

5

rolled to the directory can then obtain certificates from the server
and use them for SSL verification purposes (such as when deploying
a web server on a host). The server supports granting, renewal and
revokation of certificates.
The certificate server may either function as a certificate authority
(CA) w i t h a self-signed certificate, or it can be provided a certificate
from an external authority. A FreeIPA domain may also be configured
in a CA-less mode where no certificate management occurs.

3.1.5 Web user interface

Native inclusion of a web U I i n FreeIPA can be considered one of

the most visible advantages of the solution compared w i t h others,
such as Active Directory. The interface provides self-service profile

4. https://www.freeipa.org/page/Kerberos
5. https://www.freeipa.org/page/PKI

10
 3. F R E E I P A

information and password change operations for regular users i n

the domain. Administrators can perform a majority of operational
tasks using the U I as well, although some specific actions may only
be available via provided command-line utilities on FreeIPA servers.

3.2 Entity representation

In the context of access control provided by FreeIPA, an entity is an

internal representation of a resource participating in the access control
process that is stored i n the contained directory server. The exact
location of an entity i n the directory tree is derived from its type and
name. A brief description of the entities relevant to the implemented
tool follows.

3.2.1 Users and hosts

Users and hosts (or servers) form the most basic level of entities, with
access to hosts being the ultimate objective of the provided access
control services and users being the receivers of this access.
Both user and host entities generally need to be created by a system
administrator; an initial password is generated during the creation
process. Users can then perfom a self-service change this credential via
the web U I , while the ipa-client-install utility is used on hosts, w h i c h
switches the host to Kerberos authentication for any future operations.
A host can additionally be defined to be managed by another host,
which grants the latter host the power to represent the former one for
some applications.

3.2.2 Services

Services are an abstraction on top of FreeIPA hosts, allowing them

to gain SSL certificates or Kerberos keytabs. Service names have the
format of s e r v i c e / h o s t ; e.g., HTTP/hostl. example. com.
In SSL certificates, only the hostname is embedded i n a certificate,
and the service name serves only for distinction (for example, i n case a
host may need several different certificates to be issued). When using
Kerberos authentication, on the other hand, the whole service name
can be checked against to verify identity of the client.

11
3. F R E E I P A

3.2.3 Groups
There are two types of groups supported by FreeIPA: user groups
(called simply groups in FreeIPA terminology) and host groups (called
hostgroups). Groups represent an arbitrary logical grouping of entities
of a given type, and can also be nested to represent more complicated
relationships between entities. Host groups are purely internal to
FreeIPA and serve only for the purpose of defining access control
rules, while user groups can also be configured to receive a POSIX
group ID and exist as regular user groups on client machines.

3.2.4 Rules

Rules represent a mapping of granted access between users and hosts

(or groups thereof). FreeIPA defines two kinds of rules: host-based
access control (commonly abbreviated to HBAC), defining which users
can connect to which hosts, and sudo rules to outline which users can
use administrative (sudo) commands on the target machine.
H B A C rules can be defined to restrict the services one can use
to connect to a target node (such as ssh or http); these service limita-
tions are represented by a separate entity type, called HBAC services
(abbreviated as hbacsvc). Sudo rules support defining limits on the
commands that a given user may execute w i t h sudo or the user that
the commands may be r u n under.

3.2.5 Other entity types

There is a small number of other entity types in FreeIPA, such as roles,

permissions or privileges. The chief purpose of these entity types is to
define rules governing the administrative access to FreeIPA itself, and
as such, they are of little relevance to the topic of this work.

3.3 Usage at GoodData

FreeIPA has been used for some areas of identity management i n

GoodData for years, with the first deployment taking place as far back
as 2012. We utilize two separate FreeIPA domains, each to govern
resources w i t h a different level of sensitivity.

12
 3. F R E E I P A

We have identified four distinct varieties of FreeIPA users i n our

company, each w i t h a different set of use cases. The workflows de-
scribed here document the state before the deployment of the freeipa-
manager tool.

3.3.1 Deployment team

This team is responsible for the deployment and maintenance of the

machines hosting our FreeIPA clusters, as well as the FreeIPA applica-
tion itself and any related proprietary toolings. Its competences also
include the design of the entity structure i n each FreeIPA domain.
As the developer of freeipa-manager, I have myself been part of this
team since the beginning of my career at the company.

3.3.2 User management team

The user management team is i n charge of managing user accounts,

granting users access to company's resources and various related tasks,
such as resets of forgotten passwords for users.
The members of this team used FreeIPA exclusively via its web
interface; their operations were limited to creation, updates and dele-
tion of users, as well as assigning of users into groups. The team also
cooperated on the group structure design w i t h the deployment team.

3.3.3 Security and compliance team

The security team is responsible for the formal approvals of each

access granted to the company's protected resources, as well as audit
of the state of our identity management and the security review of
our systems.
The interaction of this team w i t h FreeIPA chiefly consisted of log
review.

3.3.4 Regular users

Other employees of the company interact w i t h FreeIPA i n a limited

way, their actions mostly being restricted to self-service password
changes i n the web UI.

13
4 GoodData requirements

In context of the various FreelPA use cases as described above, this

chapter seeks to list the major issues faced i n our deployment that
drove the decision to implement a separate identity management tool.

4.1 Entity structure management

Our platform's structure and growing size required the deployment

team to gradually rework and amend the structure of our FreelPA
groups; we now manage a fairly extensive group set containing hun-
dreds of groups i n two separate FreelPA domains (plus one testing
domain). Because of the manner in which this structure came to exist
- adding new entities whenever needed (e.g., for each new service to
which we needed to manage access), without having a clear high-level
design to follow - the resulting group set was immensely opaque and
very difficult to make sense of even for long-term members of the
team, to say nothing of new colleagues that needed to be introduced
to the process.
Role-based access control was a core principle behind our com-
pany's access redesign. We decided to implement the paradigm by
mapping the abstract access requirements to three levels of user group-
ings, differentiated by naming convention:
1. primitive groups - atomic access units, representing one specific
access to one service i n one location;
2. aggregate groups, aggregating primitive access groups of the
same service across several environments or geographical loca-
tions; and
3. role groups - top level of abstraction; groups granted directly
to users and containing several aggregate groups representing
services that a given role has access to.
Under this structure, there may be primitive groups such as primitive-
servicel-DC-full-access (where D C may have different values for each
datacenter's instance of the service) aggregated into aggregate-servicel-
full-access; a group like role-regular-developer may then be a member of
this aggregate group, granting regular developers access to servicel i n
each datacenter.

15
4. G O O D D A T A REQUIREMENTS

Since the FreelPA application only enabled v i e w i n g the created

entities on a one-at-a-time basis, w i t h no option to overview their
structure as a whole, it was not practicable to create and maintain such
a clear entity design without developing an additional tooling. More-
over, any one engineer being able to edit the objects inside FreelPA on
their o w n , without any requirement of a review from another team
member, made technical enforcement of any eventually developed
entity design impossible.
This was one of the major driving forces behind the decision to
develop the freeipa-manager tool; storing the whole entity structure in
a version control system and enforcing code review for any changes
therein would enable us to untangle the complicated network of entity
relationships that we had developed, and allow us to transform the
structure into a more logical and practical one.

4.2 Backup and restore capabilities

Improvement of the backup and restore process of our FreelPA de-

ployment for various scenarios, including disaster recovery, upgrades
to new versions and others, was also of interest w h e n deciding to
develop freeipa-manager.
Even though the FreelPA application itself offers fairly extensive
backup and restore capabilities [11], the usage thereof may not be
practical i n our scenarios, mostly because:
• the target state of such a restore is not immediately clear and
visible, and
• it is not easily possible to choose w h i c h parts of the system
should be restored.
While a backup is usually time-stamped, we are not able to examine
the state of the objects therein without undertaking the actual restore
process. Additionally, we cannot select only specific parts of the backup
to restore, as the process restores the backup as a whole. This might be
impractical i n some use cases, such as copying a certain entity subset
to a separate FreelPA installation for testing purposes, without the
need to copy the rest of entities or the state of other components of
the original FreelPA server.

16
 4. G O O D D A T A REQUIREMENTS

O n the other hand, once we keep the entity state in a place separate
from the FreelPA installation itself, such as a version control repository,
we can proclaim this repository to be the authoritative source of entity
configuration. Implementing an interface to store entities from FreelPA
to this repository, as well as pushing them back to the server, enables
us to handle the aforementioned use cases more efficiently
It is important to note that freeipa-manager does not make all pur-
poses of FreelPA's built-in backup functionality obsolete. The main
reason is that the tool only works with representation of entities, while
ignoring other components of FreelPA, such as certificates or D N S
records. Therefore, it still makes sense to maintain regular backups
of a FreelPA installation even where this tool is employed for entity
pulling.

4.3 Inter-team cooperation

As described in the previous chapter, several separate groups of people

i n the company are responsible for interaction w i t h specific compo-
nents of our FreelPA interface. Management of the structure of entities
as described above is a specific area where the responsibilities of two
teams previously intersected. Specifically, the user management team
was responsible for managing user accounts including their member-
ship i n groups, and some parts of the group structure itself, while
the deployment team managed the rest of the groups, as well as the
remainder of the entity types, such as H B A C and sudo rules.
While this division made sense at the time (e.g., the second team
managed groups governing access to systems that the first team lacked
technical knowledge about), it made transparent management of the
entity structure all the more impossible. Even if the shortcomings
of the process described i n the first subsection could possibly be
overcome by direct personal communication of people managing the
FreelPA entities, introducing the additional complexity of colleagues
from a different team, based i n a different geographical location, ex-
ecuting simultaneous changes to the entity structure prevented my
predecessors i n the company from being able to define and adhere to
a clear structure and set of rules for entity management.

17
4. G O O D D A T A REQUIREMENTS

W i t h freeipa-manager, the user management team w o u l d still be

able to manage users v i a the FreelPA web interface (according to
their personal preference), but these changes w o u l d n o w be synced
to a GitHub repository that would also govern the rest of the entities
via p u l l requests. This way, no editing conflicts w o u l d arise between
teams (nor inside teams, for that matter, since only a single member
of the user management team is currently responsible for user entity
management), and all changes made to the structure on the part of
the deployment team w o u l d be subject to code review as described
above.

4.4 Audit

Lastly, one of the strong requirements for an identity management

system was to provide a consistent and easily available audit trail
of performed actions for the purposes of security review. While we
have been collecting logs of commands executed since before the
introduction of freeipa-manager, an added benefit provided by the tool,
in conjunction with the version control of its entity config, is the ability
to review the entire state of the entity structure at any given time point
in history. Although the granularity of such snapshots depends heavily
on the frequency of entity dumps i n the pull usage mode, the standard
push mode of operation offers the full audit benefits, especially when
coupled w i t h a reasonable commit policy where each change is well
described and justified i n the commit message.
The change brought about i n this area has most been welcome by
the non-technical users, such as those i n the security team who need
to review the changes i n the granted access; the transition from linear
log messages to a complete entity structure snapshot repository can be
considered a major user experience improvement for such use cases.

18
5 freeipa-manager implementation

This chapter describes the timeline of the implementation progress,

the major design decisions that were required to be performed, as well
as the prominent features of the implemented tooling.

5.1 Brief history

The implementation of the tool commenced i n A p r i l 2017 w i t h the

introduction of the basic code structure and the support for the man-
agement of five basic entity types: users, user groups, host group,
H B A C rules and sudo rules .1

The tooling initially only supported pushing entities to the FreelPA

server; server-side entity change tracking i n the configuration files
was not possible until August 2017 . 2

We performed first attempts at deploying the tool in a non-testing

enviroment i n the autumn of the same year, fixing the tool's bugs
and inadequacies i n an agile manner as they were encountered i n
the process; this included, for example, a refactor of the way settings
are passed to the tool , or the introduction of an auxiliary tooling for
3

automated creation of GitHub pull requests with changes pulled from

the FreelPA server . 4

Having successfully resolved the initial painful aspects of the de-

ployment, the tool has been i n our service i n two separate FreelPA
domains since the end of the year 2017. There have since been occa-
sional changes therein, such as addition of support for additional entity
types or for entity configuration templating , both implemented by
5 6

my colleague and fellow student Tomas Bouma.

1. https://github.com/gooddata/freeipa-manager/commit/8e84e70
2. https://github.com/gooddata/freeipa-manager/commit/3a6d5f9
3. https://github.com/gooddata/freeipa-manager/commit/c231000
4. https://github.com/gooddata/freeipa-manager/commit/3f8196b
5. https://github.com/gooddata/freeipa-manager/commit/4a68432
6. https://github.com/gooddata/freeipa-manager/commit/5ea4f74

19
5. freeipa-manager IMPLEMENTATION

5.2 Design decisions

This section documents the most impactful decisions affecting the
final form of the implemented tooling. W h i l e some of the design
principles listed here may have already been mentioned i n passing in
the previous text, given their central role i n defining and explaining the
purpose of the tool, the target of this section is to explain the reasoning
and outcomes of the related design decisions i n more detail.

5.2.1 Interfacing LDAP vs. FreelPA API

One of the most important design decisions made in the development

process, as well as the one that took the most effort to sort out, was
the question of which interface to utilize for the tool's communication
w i t h the FreelPA server - direct connection to the L D A P server or
FreelPA A P I .
The initial idea was to use L D A P as the underlying storage service,
w h i c h was deemed to provide better performance of operations on
the entities. However, attempts at implementing such an approach
quickly discovered its drawbacks, stemming from FreelPA apparently
not having been designed for such a manner of usage; for instance,
creating a new user directly v i a L D A P d i d not generate their POSIX
user and group ID values, w h i c h is done automatically w h e n this
operation is performed using the A P I of FreelPA.
If we therefore desired to keep using the L D A P interface for the
freeipa-manager tool, we would have to re-implement the ID-generating
functionality on our part, w h i c h w o u l d be non-trivial. After deliber-
ation, it was agreed that the need to duplicate FreelPA features was
not worth the potential performance increase, and we decided to use
FreelPAs A P I instead.

5.2.2 Managed entity types

Another vital component of the freeipa-manager design was the def-

inition of the subset of FreelPA's entity types whose tracking and
management would be supported.
One possibility explored early i n the process was to treat all entities
uniformly, defining a universal "entity" representation to work with.

20
 5. freeipa-manager IMPLEMENTATION

However, this d i d not prove viable due to the high level of differences
in the nature of the particular entity types. It therefore followed that
each entity type we wished to represent i n the tool would have to be
implemented separately, which meant that a compromise was needed
between investing resources into implementation and the practicality
of being able to manage each particular entity type using the tooling.
For the initial deployment of the tool, a set of five entity types -
users, user groups, host groups, H B A C rules and sudo rules - was
selected for implementation. It might intuitively be expected that hosts
would be a logical addition to this entity type set; however, due to the
dynamic nature of our hosts' lifecycle, we decided early on that we did
not w i s h to represent them i n the freeipa-manager config; we merely
chose to use separate measures to ensure that hosts are assigned to
the correct host groups when deployed, and to manage the access to
them on the host group level only.
The support for other entity types, such as services and roles, was
implemented later in the development process . Since the purpose of
7

these entity types was somewhat perpendicular to our main access

management objectives, their implementation's goal was chiefly to
further improve the operational experience of managing our FreelPA
installations once the base expectations placed on the freeipa-manager
tooling had already been fulfilled.

5.2.3 Pull and push mode

The decision regarding the mode of the tool's operation was a ma-
jor turning point i n its design. A s described earlier, there were four
different groups of FreelPA users i n our company at the time of i m -
plementation. Varying use cases and difficulties i n their adaptation
to process changes required us to find compromises i n the way we
planned to deploy and use freeipa-manager, even causing us to imple-
ment two separate manners of the tool's operation - the push and pull
modes.
The ideal goal behind the tool's conception was to proclaim its
configuration files as the source of truth about FreelPA entities, and
to utilize it to fully manage those entities i n the given FreelPA instal-

7. https://github.com/gooddata/freeipa-manager/commit/4a68432

21
5. freeipa-manager IMPLEMENTATION

lation. This goal is now encompassed by the push mode of operation.

However, some of the users of FreelPA i n the company preferred to
continue using the FreelPA web interface, namely for user manage-
ment operations.
For this reason, our deployment of freeipa-manager utilizes a mixed
mode of operation where:
• user entity management, including users' membership in groups,
is managed manually via FreelPA web U I and tracked i n the
configuration repository by automated daily pull requests - the
pull mode; and
• all the other entity types are configured in a Git repository and
managed by freeipa-manager - the push mode.

5.3 Features

This section documents the major features and capabilities of the

implemented tool while outlining the specifics and limitations thereof.

5.3.1 Configuration repository structure

Instances of every entity type are expected to be placed in a dedicated

subfolder of the configuration repository path, with every entity being
defined i n a separate file. A sample structure of entity configuration
files might resemble the following one:
freeipa-manager-config/
domainl/
users/
user_one.yaml
user_two.yaml
user_three.yaml

groups/
group_one.yaml
group_two.yaml

domain2/

22
 5. freeipa-manager IMPLEMENTATION

5.3.2 Entity configuration format

The tooling utilizes the YAML format for the definition of entities
8

and for its settings file. A simple key-value format is utilized.

The name of an entity should be the only key at the top level of the
mapping i n a configuration file, w i t h the entity's attributes placed in
a nested mapping underneath. For instance, a user entity definition
may be defined as follows:

user.one:
f irstName : User
l a s t N a m e : One
email: user.oneOexample.com
memberOf:
group:
- group-one
- group-two
- group-three
The name of the attributes generally follows the relevant L D A P schemas
utilized by FreelPA for the definition of each entity type. However,
some of the more obscure namings have been replaced by more read-
able ones (e.g., L D A P ' s sn attribute, standing for surname, has been
replaced by lastName) and are automatically mapped to the correct
L D A P keys.
A vast majority of the possible attributes are optional, mirroring
the requirements of FreelPA; namely, only the first and last name must
be specified while all other entity types' attributes may be omitted.
The definition of the config schema for each entity type can be
found i n the ipamanger.schemas module of the implemented tool . 9

In addition to the supported attributes, each entity can additionaly

possess an extra attribute with the name metaparams, which may hold
an arbitrary mapping of keys and values. This attribute has no effect on
the entity's state i n FreelPA and can be used to store extra information
about the entity.

8. https://yaml.org
9. https://github.com/gooddata/freeipa-manager/blob/0d40e64/
ipamanager/schemas.py

23
5. freeipa-manager IMPLEMENTATION

5.3.3 Entity membership representation

Representation of membership relations between entities takes on a
specific format in order to provide a more readable config representa-
tion of an entity.
There are two kinds of relationships between entities represented:
• memberOf relations between users, hosts and groups thereof,
and
• memberHost and memberMser relations between H B A C and sudo
rules and their members.
Users (which can be members of user groups) and user and host
groups (which may only be members of entities of the same type)
may have the memberOf attribute specified i n their config, listing the
groups of w h i c h a given entity is a member. A user's membership
definition may look like this:

user.one:

memberOf :
group:
- group-one
- group-two
- group-three
H B A C and sudo rules, on the other hand, require a memberHost and
memberMser attributes to be specified, such as the following:

rule.one:
memberHost : h o s t g r o u p l
memberUser : u s e r g r o u p 2
For historical reasons arising from our deployment's specific needs
when developing the tooling, the membership possibilities offered are
stricter than allowed by FreelPA:
• users are only allowed to be members of user groups, and not
of other entity types like H B A C and sudo rules;
• H B A C and sudo rules can only have exactly one host group
and one user group as members (as opposed to any number
allowed by FreelPA).

24
 5. freeipa-manager IMPLEMENTATION

In addition to direct membership of one entity in another, FreelPA

is also able to represent indirect membership of entities, e.g., when a
user achieves membership i n a group by being added into a different
group. These nested relationships are not represented i n the entity
configuration files; only the direct membership information is stored
in the memberOf attribute.

5.3.4 Configuration integrity verification

The ipamanager.integrity_checker m o d u l e provides rich possibilities

10

of verifying the logical integrity of the defined entity structure.

The module, for instance, allows checking whether each entity
type is only a member of entities of the allowed type. It also sup-
ports verification of the absence of any circular membership relations
between entities (e.g., a groupl being a member of group2 and vice
versa), w h i c h would be i n violation of FreelPA constraints.
The system of labels presents an additional way to define con-
straints on entities. Under this system, a user group can be assigned a
meta-parameter w i t h the name labels, containing a list of values. A n y
user that should be a member of this group must then have at least the
same set of labels defined i n their own corresponding meta-parameter;
for example, if a group contains labels l a b e l l and l a b e l 2 , any mem-
ber user must also have at least these two labels. This can be used to
represent security limits on groups w i t h higher level of protection or
similar.
The labels are not checked by the aforementioned module; the
described functionality is available i n ipamanger.tools.query Jool . 11

5.3.5 Change application preview

The tooling also supports preview of changes to be applied to a FreelPA

server, also known as a dry run, as part of both its push and pull mode.
For the push mode, an explicit - f o r c e parameter must be provided
for any changes to be performed. In its absence, the tool only lists the

10. https://github.com/gooddata/freeipa-manager/blob/0d40e64/
ipamanager/integrity_checker.py
11. https://github.com/gooddata/freeipa-manager/blob/0d40e64/
ipamanager/tools/query_tool.py

25
5. freeipa-manager IMPLEMENTATION

entity modification commands that w o u l d be executed against the

FreelPA A P I .
Since rewrite of local configuration files (that are additionally as-
sumed to be cloned from a remote repository) is considered to be less
risky than accidental execution of commands against a live server,
dry r u n is not the default for the pull mode but can be invoked by
the - d r y - r u n parameter to only list entities that have changed on the
server instead of pulling the changes.

5.3.6 Change monitoring

freeipa-manager has the possibility of dispatching a result of the per-

formed actions to an external monitoring application. The ipaman-
ager.alerting m o d u l e provides an interface for defining alerting p l u -
12

gins that collect the logging messages and forward them to another
service.
Currently, the only implemented p l u g i n allows dispatching the
tool's runtime status and logs to a server using the NSCA protocol . 13

12. https://github.com/gooddata/freeipa-manager/tree/0d40e64/
ipamanager/alerting
13. https://github.com/NagiosEnterprises/nsca

26
Conclusion

The objective of streamlining the identity management-related opera-

tions at GoodData has been fully achieved w i t h the usage oifreeipa-
manager. The implemented tool supports rich options of FreelPA entity
definition, automation of access granting, and monitoring of changes.
It has been a key component enabling us to implement role-based
access control, and as such, it has helped make our access control
process more transparent and easier to understand and maintain.
Possible future development might include extending the tool
to support interfacing L D A P servers directly, w h i c h w o u l d make it
largely independent of the utilized identity management solution;
although the original design decision was to use the FreelPA A P I , the
situation and our requirements might change in the future, prompting
us to also couple the tooling w i t h other solutions than FreelPA.

27
Bibliography

1. E L I S A B E R T I N O A N D K E N J I T A K A H A S H I . Identity Manage-
ment : Concepts, Technologies, and Systems. Boston, M A : Artech
House, Inc., 2010. ISBN 978-1-60807-039-8.
2. TIAN PUYANG, QINGNI SHEN, Y A N G LUO, W U LUO A N D
Z H O N G H A I W U . M a k i n g least privilege the low-hanging fruit
i n clouds. 2017 IEEE International Conference on Communications
(ICC). 2017. ISBN 978-1-4673-8999-0. ISSN 1938-1883.
3. N I C K S Z A B O . Patterns of Integrity - Separation of Duties [on-
line]. 1994 [visited on 2019-05-19]. Available from: http :
//www. f on. hum. uva. n l / r o b / C o u r s e s / I n f ormationlnSpeech/
CDR0M/Literature /L0Twinterschool2006/szabo . best . vwh .
net/separationofduties.html.
4. DAVID FERRAIOLO, D. R I C H A R D K U H N A N D R A -
M A S W A M Y C H A N D R A M O U L I . Role-based Access Con-
trol. 2nd ed. Boston, M A : Artech House, Inc., 2007. ISBN
9781596931138.
5. B R I A N A R K I L L S . LDAP directories explained: an introduction and
analysis. Boston, M A : Addison-Wesley, 2003. ISBN 0-201-78792-X.
6. N E I L W I L S O N . Understanding LDAP Schema [online] [visited on
2019-10-24]. Available from: https : / / l d a p . com/understanding-
ldap-schema/.
7. R E D D I T . openLDAP, freelPA, AD, whats the difference? [online]
[visited on 2019-10-23]. Available from: https : //www. r e d d i t .
com/r/linuxadmin/comments/5yelvt/openldap_freeipa_ad_
whats_the_difference/.
8. R E D HAT, INC. Ways to Integrate Active Directory and Linux Envi-
ronments [online] [visited on 2019-10-23]. Available from: h t t p s :
/ / access . redhat . com / documentation / en - us / red _ hat _
e n t e r p r i s e _ l i n u x / 7 / html / windows _ i n t e g r a t i o n _ guide /
introduction.
9. MIT. Kerberos: The Network Authentication Protocol [online] [vis-
ited o n 2019-10-23]. Available from: https : / /web . mit . e d u /
kerberos/.

29
BIBLIOGRAPHY

10. R E D H A T , I N C . FreelPA: Audience and Purpose [online] [visited

on 2019-10-24]. Available from: h t t p s : / / d o c s . f e d o r a p r o j e c t .
o r g / e n - U S / F e d o r a / 18/html/FreeIPA_Guide/Pref ace . html#
audience-fedora.
11. FREEIPA C O M M U N I T Y . Backup and Restore [online] [visited on
2019-06-10]. Available from: https : //www. f r e e i p a . org/page/
Backup_and_Restore.

30