Identity Provisioning to Masaryk University IT Services Based on Microsoft Environment

Masaryk University Faculty of Informatics

Identity provisioning to Masaryk University IT services based on Microsoft environment

Master’s Thesis

Bc. David Štencel

Brno, Spring 2019

Masaryk University Faculty of Informatics

Identity provisioning to Masaryk University IT services based on Microsoft environment

Master’s Thesis

Bc. David Štencel

Brno, Spring 2019

This is where a copy of the official signed thesis assignment and a copy ofthe 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. 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.

Bc. David Štencel

Advisor: Mgr. Kamil Malinka, Ph.D.

Acknowledgements

I would like to thank my advisor Mgr. Kamil Malinka, Ph.D. for his professional guidance and experience. Also, I would like to thank Jan Izydorczyk, Mgr. Slávek Licehammer, and the rest of the Office 365 team at ICS for their collaboration, support, and patience during the creation of this master’s thesis. Finally, I would like to thank my family for all their support during my whole studies.

iii Abstract

The aim of the thesis is to design and implement an interconnection of university identity management system Perun with services running in Microsoft environment. Resultant PowerShell scripts utilizing OpenSSH and PowerShell remoting allow data transmission from Perun to Windows hosts and launching service provisioning scripts. The thesis covers Active Directory and Office 365 as example target services, and a revised PowerShell web proxy that adjusts additional object settings within university Office 365.

iv Keywords

identity management, identity provisioning, Perun, Windows, services, Active Directory, Office 365, OpenSSH, PowerShell connector, PowerShell web proxy

Contents

Introduction 1

1 Motivation 3

2 Current environment 5 2.1 Perun at MU ...... 5 2.2 Active Directory at MU ...... 7 2.3 Azure Active Directory and Office 365 at MU ...... 7

3 Analysis 13 3.1 Requirements ...... 13 3.2 Windows remote management ...... 14 3.2.1 PowerShell remoting ...... 14 3.2.2 OpenSSH in Windows Server ...... 16 3.3 Active Directory ...... 17 3.4 Azure Active Directory and Office 365 ...... 18 3.5 Message queueing ...... 18 3.5.1 RabbitMQ ...... 19 3.6 Group Managed Service Accounts ...... 21

4 Design 23 4.1 Active Directory ...... 25 4.2 Azure Active Directory and Office 365 ...... 25 4.2.1 PowerShell web proxy ...... 27

5 Proof of concept 31 5.1 Perun - data generation ...... 32 5.2 Protocol translator ...... 32 5.3 Perun connector ...... 33 5.3.1 AD service ...... 34 5.3.2 AADC service ...... 34 5.3.3 O365 service ...... 34 5.4 PowerShell web proxy ...... 35 5.4.1 REST API ...... 35 5.4.2 RabbitMQ ...... 35 5.4.3 Queue listener and O365 module ...... 35

vii 5.4.4 PowerShell service ...... 36 5.5 Logging and monitoring ...... 37 5.6 Testing ...... 38 5.7 Deployment ...... 39

Conclusion 43

A Electronic appendices 47

Bibliography 49

viii Introduction

In large organizations, keeping uniform up-to-date identity information across all IT services that consume them is a challenge. At Masaryk University, at least ninety thousand1 users and groups from various sources are managed. This data often alters when people graduate, change their fields of studies, work groups, or workplaces. As a centralized solution, an identity management system can be used to gather information from the Office for studies, economic or HR systems, and to propagate it to connected services. At the university, the identity management system called Perun2 [1] gradually replaces its out-dated predecessor. The identity provisioning procedures vary from service to service. To unify the process and support a wide range of services, Perun misses a generic component that would interconnect the new identity management system with Windows machines which host target services. The thesis aims to design a mean of communication between Perun and Microsoft services. It focuses on identity provisioning to Microsoft Active Directory and Microsoft Office 365 as an example target services that represent important systems for the university operations. The first chapter introduces the motivation of the thesis and defines high-level issues that the current environment faces. In the second chapter, I describe the current architecture of identity management at MU with a focus on Active Directory and Office 365, and more specific problems to be covered in the solution. Chapter three is dedicated to the requirements, analysis of methods of remote Windows management, identity provisioning to Active Directory and Office 365, a concept of message queueing used inthe management of Office 365 at the university, and a secure approach of managing Windows service accounts in a domain. Chapter four covers the design of a Perun-Windows connector and the identity provisioning to Active Directory and Office 365 that builds upon the knowledge of the environment and the performed analysis.

1. The number of user and group objects managed by the identity management system at MU called Perun. 2. https://perun-aai.org

1 A proof of concept described in chapter five follows. It includes implementation and testing of the module interconnecting Perun and Windows hosts. It also incorporates scripts for identity provisioning to Active Directory and Office 365, and deployment instructions to run the proposed solution in the production environment.

2 1 Motivation

Masaryk University is a large environment with a great number of users, and also it is very dynamic. Currently, in 2019, there are over two thousand user groups1 and eighty-nine thousand user accounts2 including students, employees, and guest users who often change their fields of studies, workplaces or project partnerships. To provide services that are available to authorized users, and to make sure that every one of them has the proper attributes filled, licenses, rights and permissions assigned for required systems and applications, a centralized identity and access management system is needed. At the university, an identity and access management system called Perun has been deployed that should replace its predecessor. It runs on Linux hosts. It gathers identity information from various sources, processes it and sends it to the connected systems. Linux based services are usually managed natively through an SSH connector and provisioning scripts on the service host. Another Linux and Windows services rely on standard file transfer protocols, LDAP [2], or own service APIs. However, some Microsoft-based services are not compatible with any of the listed channels, or they have special requirements. For these use-cases, there is no universal Windows connector available. The university operates Microsoft Office 365 (O365) [3] that already relies on Perun and represents one of the services with extra demands. The original design depends on Perun’s responsibility for filling an instance of Microsoft Active Directory (AD) [4] via LDAP with a por- tion of attributes, and scheduled AD synchronization to O365 Azure Active Directory (AAD) [5]. Asynchronously, Perun calls a web proxy to set other object properties in O365. Although the system has been working fine, it needs to be revised because of the inefficient communication model, unsuitable accountability distribution and resulting bad manageability, and complex implementation of the web proxy. Perun using two data channels is the root problem. The issues are put in context and discussed in more detail in section 2.3.

1. The number of group objects managed by the identity management system at MU called Perun 2. The number of user objects managed by the identity management system at MU called Perun. Fifty-four thousand of them are active users.

3 1. Motivation

The goal is to offer centralized identity management with unified provisioning procedures for a wide range of services running on Linux and Windows. The consolidation of heterogeneous identity management approaches involves implementation of a reusable Perun connector for Windows services. The connector would lead to connecting new services to the central management and relieving Perun of excess functionality.

4 2 Current environment

This chapter aims to give an idea of the concept of the identity management at MU and weak spots in the current setting of the O365 service. The design is depicted in figure 2.1. It covers internal and federated identities of university students, employees, and guest users. The data sources distinguish individuals, groups, and other sources of attributes. Connected services consume the consolidated data from the central identity management system.

Figure 2.1: The concept of identity management at MU.

2.1 Perun at MU

Perun [1] manages organizational identity and access rights information, one running instance can be shared between several virtual institutions. It is being developed by CESNET1, CERIT-SC2, and students of Masaryk University. It was originally dedicated for managing users and services in distributed environments like computational and storage grids, so it is a robust and scalable solution.

1. https://www.cesnet.cz 2. https://www.cerit-sc.cz

5 2. Current environment

At MU, in addition to its own data sets, Perun collects information from: ∙ IS MU3 – the university information system providing Office for studies agenda, course information and study materials, e- learning, or communication tools. ∙ Inet MU4 – a system for accessing personal, economic, account- ing, and HR data, and operational services. ∙ External systems – other independent internal systems. ∙ Guest Manager – a component responsible for guest management. Future version of Guest Manager will support federated identities such as eduID, Facebook, or Google. ∙ Cyclop – a component managing user life cycles for some services, O365 included. Based on defined attributes and rules, it may manage account creation and disabling, licensing or user assignment to groups. The component is in the final phase of deployment testing. The high-level architecture is quite straightforward. Perun gathers data from various sources and processes it. In case of a change, it sends the modified data in a proper format to one of the following recipients: ∙ A service administrator via e-mail for manual provisioning. ∙ The end-service itself via LDAP, a file transfer protocol, or the service API, if it is supported. ∙ A connector at the end-service host via an SSH channel. The connector launches provisioning scripts dedicated for the target service. The third approach gives the administrators of the end service the full control over an automated provisioning tool. But currently it is limited to Linux-based services only.

3. https://is.muni.cz 4. https://inet.muni.cz

6 2. Current environment

Described general push mechanism and SSH channel are prefer- able ones. On the other hand, LDAP also represents a supported pull mechanism, so a service alone can pull the configurations from Perun.

2.2 Active Directory at MU

Microsoft Active Directory (AD) is a directory service that stores hier- archical information about objects such as users, groups, or computers. It provides authentication and authorization services or it can dissem- inate group policies settings throughout the network. To access and manage the data it implements LDAP protocol. The university employs several directories from which the following two are central. UCN.MUNI.CZ along with its child domains contains users, computers and group policies used to manage on- premises services. Identities to the directory are provisioned by Pe- run and Perun’s predecessor called AccountManager. AD with the IDENTITIES.MUNI.CZ domain and user and group objects is filled by Perun only and synchronized to the Microsoft cloud as discussed in the next section 2.3. Other domains and directories managed by separate groups can be found across various faculties.

2.3 Azure Active Directory and Office 365 at MU

Microsoft Office 365 (O365) is a suite of office applications, tools,and cloud services that support communication, storing data, team collaboration and sharing information. To provide the O365 service, identity information needs to be provisioned to Azure Active Directory (AAD) – a multi-tenant5, cloud-based directory, and identity management service. The following two configurations are at disposal. Firstly, purely cloud identity management stores all the information in Azure. Sec- ondly, the hybrid solution [6] builds upon the synchronization of the on-premises AD data to AAD. In some of the hybrid scenarios, no user passwords or password hashes are stored in the cloud, users can authenticate to AD or another identity provider, and the whole service

5. A tenant refers to an instance of an O365 or Azure subscription representing an organization. 7 2. Current environment is still available. The key component responsible for syncing users, groups and contacts is called AAD Connect (AADC) [7]. The university disposes of O365 license plans for students, employees, and university guest partners. Alumni users have restricted licenses. Historically, O365 accounts were optional, but thanks to the long-term strategy of unification and centralization, since February 2017 everyone has had one. Users migrate or forward their e-mails from faculty on-premises e-mail solutions to Exchange Online. Indi- viduals benefit from the cloud storage OneDrive for Bussiness. Teams take advantage of shared workspaces in SharePoint or O365 groups. The organizational social site Yammer serves as one of the official university communication channel. O365 had become a significant university service.

Figure 2.2: The original O365 identity architecture schema.

The figure 2.2 depicts the original design of the O365 identity management at MU authored by Mgr. Martin Čuchran [8]. It is a scalable solution that fairly deals with performance issues of remote O365 interface calls. It considers Microsoft best practises, requirements for Single Sing-On authentication, and the university password policy (p.19, [8]).

8 2. Current environment

It relies on Perun’s responsibility for identity provisioning to AD, AADC that synchronizes information from AD to AAD, and a separate functionality of PowerShell-based6 web proxy which sets other required parameters in parallel that cannot be set by Perun via LDAP. AADC synchronization routine starts automatically each thirty minutes. Perun provisions identities to AD and immediately starts to send requests to the PowerShell web proxy. Since it take some time until the objects appear in AAD and are available in O365, the requests are not often fulfilled and Perun needs to resend them. That resolves into resource depletion. From the perspective of the O365 service, Perun is a black box with significant service impact. Because of log inaccessibility and control logic on Perun‘s side, debugging and monitoring of such system complicates O365 administrators‘ work when something goes wrong or needs to be checked.

Figure 2.3: The original PowerShell web proxy architecture schema.

Based on the updated data from identity sources, Perun computes and pushes a list of changes to AD. Perun also communicates with a

6. A task-based command-line shell and scripting language built on .NET framework. 9 2. Current environment

PowerShell web proxy. Figure 2.3 captures the original PowerShell web proxy architecture. Perun generates a set of commands for PowerShell web proxy that is sent via an ASP .NET REST API to process. Windows Server feature Network Load Balancing (NLB) [9] spreads the payload between several identical independent nodes for better performance. It also increases service availability in case of a node failure. The API call is translated into PowerShell script call and put into a Microsoft Message Queueing (MSMQ) [10] queue. Tens of O365 PowerShell independent sessions are managed with a software semaphore to pick up and execute the commands from the queue. When the script finishes, it sends a response message to the output queue fromwhere it is accessible via REST API to clients. Inet uses the REST API to obtain and set user information in O365. The PowerShell web proxy is also used for gathering service statistics. The functionality is being added over time. The implementation of PowerShell web proxy suffers from code complexity and resulting hidden mistakes and imperfections that cause process restarts, invalid process exiting, or failing concurrent access to the message queue. There is no superordinate process manager but every PowerShell instance checks the number of running peers and starts new ones if needed. Due to the destructive message read of MSMQ, occasionally the system needs to face data loss. MSMQ restricts a message size to 4 MB [11] that could be limiting in the future web proxy utilization. PowerShell instances that execute requests for the O365 service need to cope with message management logic and burden the host excessively. If the execution fails because of slow change propagation to O365, Perun detects the temporary error and sends an identical request again. This repeatedly happens while provisioning new users. Considering Perun sending a collection of data, the current implementation cannot deal with batch processing. The setting on the REST API does support password authentication only in contrast with the preferred certificate authentication.

To conclude the chapter, Perun is the central identity management system that pushes consolidated data to target services. However, It misses a generic connector for Windows-based services.

10 2. Current environment

O365 architecture relies on identity provisioning via two separate channels that causes resource depletion and management difficulties. To resolve the issues, the newly emerging Perun-Windows connector could be used to phase the process. To propagate some settings to O365, a PowerShell web proxy is used. It became cumbersome to manage, it does not support batch processing, so its core functions needs to be revised.

3 Analysis

The following chapter consists of four logical parts. The first one states system requirements, the second one discusses remote management capabilities of Windows systems, the thirds one inspects means of identity provisioning to AD and O365, and the last one is dedicated to the topic of message queueing and some particular aspects of the PowerShell web proxy.

3.1 Requirements

The goal is to design a secure, scalable solution that would be module- based and easy to modify and adapt for newly incoming demands from various providers of services based on Microsoft technologies. The requirements were put together with a member of ICS MU1 identity management team. Specifically, the thesis needs to cover:

∙ Connector running on a Windows machine that can receive data from Perun and launch modules for identity provisioning to services. Other demands include checking of data version and target hostname, prevention from concurrent runs, ability to enable or disable data propagation and to run optional code fragments before and after the service is provisioned.

∙ In particular, a service module for AD and O365 should manage organizational units, user accounts, and user groups.

∙ With respect to diverse production environments, the connector needs to be compatible with Windows Server 2012, 2016, 2019.

The following demands consider the O365 service including the Perun connector with the O365 module and the redesign of the Pow- erShell web proxy.

∙ Utilize the new Perun connector to separate Perun’s data collect- ing function and O365 provisioning responsibilities.

1. https://www.ics.muni.cz

13 3. Analysis

∙ To support university unified authentication in O365, the architecture needs to utilize AADC to synchronize additional attributes from AD to AAD (p. 19-22, [8]).

∙ Preserve and update the PowerShell web proxy and its REST API with certificate authentication.

∙ Support batch processing of bulk requests to decrease the number of the REST API and the O365 service calls.

∙ Separate core functions of the PowerShell web proxy.

∙ Assure the system scalability, security, and data integrity.

3.2 Windows remote management

This section concerns with available communication channels for Pe- run and Windows hosts. There are several ways how to access, manage, or provision a service on a remote Windows machine. The methods include an implementation of the Remote Desktop Protocol (Remote Desktop Services [12]) which provides a GUI to connect to an application-running server over a network. Graphical interface is not suitable for automatized processes. Another options are PowerShell remoting discussed in the subsection 3.2.1, or SSH connection described in the subsection 3.2.2.

3.2.1 PowerShell remoting

Powershell is a task automating tool providing command line interface and scripting capability. It is a Windows pre-installed feature that allows administrators to manage computers and access their resources. Its optional open-source cross-platform Core version [13] supports modern versions of Windows, Linux, and macOS. PowerShell Core is less powerful than the standard version since it relies on newer .NET Core framework opposite to the traditional .NET Framework.

14 3. Analysis

Thanks to the PowerShell remoting one can run commands or scripts on multiple machines in parallel using Windows Management Instrumentation2, Web Services-Management3, or SSH. Microsoft implementation of the Web Services for Management protocol is called Windows Remote Management (WinRM). WinRM service allows users to securely manage computers using HTTPS, AES cryptography, and certificate authentication. Eligible users need tobe members of the local Administrators group or the Remote Management Users group. Properties of the SSH subsystem on Windows machines is covered in section 3.2.2.

Just Enough Administration To alter service data Perun usually requires administrator privileges. If Perun utilizes standard PowerShell remoting, it will gain full access to the host. PowerShell provides a feature that can help build trust in Perun that would not intervene even by accident into other system settings and applications. Just Enough Administration (JEA) [14] is a Microsoft security tech- nology that enables reducing the number of administrators on Win- dows machines by limiting user privileges and using virtual accounts with temporarily elevated rights when remotely managing computers via PowerShell. Besides, it provides event logging and session transcription. It is available in PowerShell 5 and Windows Management Frame- work 5.1 [15]. Older Windows versions might require an upgrade of these components. The implementation requires the generation of two files. A role capabilities file specifies all the commands, functions, modules, variables, assemblies, and external programs that should be available to the connecting users. A PowerShell session configuration file dictates who can access the computer using JEA and which roles are available to them. The

2. An infrastructure for data management and operations on Windows-based operating systems. 3. A SOAP-based protocol for managing servers, devices, applications, and various Web services.

15 3. Analysis

NoLanguage mode setting ensures that connected user cannot make use of standard PowerShell language constructs such as object comparison, default global variables, variable declaration, or automatic expression completion. RestrictedRemoteServer session type allows only a basic set of commands like listing available commands and getting their manuals or exiting the remote session. The last step of making the JEA profile available involves registra- tion of the session configuration file. Access control list of the default microsoft.powershell JEA configuration should be verified and dis- abled for untrusted users.

3.2.2 OpenSSH in Windows Server The standard communication channel for Perun and its connected services is SSH. OpenSSH is a set of tools for secure remote communication over SSH protocol. It enables remote log-in, remote file transfer, or public and private key management. In December 2018, Microsoft PowerShell Team announced the availability of the OpenSSH implementation as a supported feature in Windows Server 2019 and Windows 10 1809 [16]. The service is based on a client-server architecture. The client is the user system; the server is the remotely managed system. User can choose the default shell that starts with the SSH session, PowerShell for instance. When PowerShell Core installed on both client and server, one can utilize PowerShell remoting over SSH [17]. JEA is not supported yet. Native Microsoft’s SSH support is a crucial aspect in the selection of a communication channel between Perun and Windows machines. Using a third party SSH implementation with no guarantees or SLAs on fundamental system services would not be far-sighted.

One more possibility of advanced remote management of a Windows- based service comprises of a file transfer protocols like Server Message Block [18] that copies files to a Windows machine which a scheduled or triggered job can process. Rarely a scheduled job may access data that has not been completely transferred yet and cause an error. This approach currently implements one of the print services at MU. The

16 3. Analysis

main reasons for not taking the model into account are issues related to concurrent file access and reduced management and monitoring capabilities in comparison with permanent SSH or WinRM sessions. Difficult and unreliable failure detection and its reporting, orresult confirmation and run state determinism from the managing party exemplify the problem.

To summarize this section, the graphical interface is not suitable for non-interactive remote management, Perun and other Linux systems support SSH communication natively, and so do the latest Windows, all Windows support PowerShell remoting by default. Perun connects to a majority of services via SSH sessions.

3.3 Active Directory

There are several alternatives to LDAP [2] to automate AD query and management.

∙ Microsoft Active Directory Module for Windows PowerShell [19] is a set of commands that allows administrators to manage AD domains, AD Lightweight Directory Services configuration sets, and Active Directory Database Mounting Tool instances. For remote management from a non-controller computer, an Remote Server Administration Tools (RSAT) package is available.

∙ Active Directory Service Interfaces (ADSI) [20] is a set of interfaces for accessing directory services features and other network resources in distributed environments.

∙ .NET classes [21] encapsulate ADSI objects and performs queries against the AD hierarchy using LDAP that is the only system- supplied protocol supported by ADSI.

Since the PowerShell AD module is the most broadly used, the code is easy to write, follow and maintain; it is the preferred approach of all.

17 3. Analysis 3.4 Azure Active Directory and Office 365

The topic of identity provisioning to AAD and O365 already covered Mgr. Martin Čuchran [8] in his thesis in 2017. The chosen design builds upon AADC that periodically synchronizes changes between AD and AAD. There are other settings like e-mail forwarding, anti-spam settings, or default regional settings that need to be applied in a separate channel. Three options to communicate changes and settings with O365 include a web GUI4, Graph API [22], or PowerShell remoting [23]. As the most powerful, PowerShell is the leading approach. How- ever, there a few limitations that need to be considered [24]. They include quotas and throttling at the user level in the number of transac- tions, number of concurrent calls, or number of simultaneous sessions per administrator. Currently, the PowerShell web proxy introduced in section 2.3 provides the functionality using preauthenticated sessions in parallel. But based on the analysis and requirements it will be updated.

3.5 Message queueing

In the section 2.3 I mentioned utilization of the MSMQ queue in the current PowerShell web proxy design. A message queue is a module for asynchronous inter-process communication. It stores messages from publishers and routes them to subscribers (consumers) who read them when available. When deploying a queue one can benefit from: ∙ Asynchronous messaging. ∙ Dependencies decoupling. ∙ Redundant resources consuming data from the queue. One can meet the performance requirements, prevent data loss, and cope with traffic spikes. ∙ Transaction ordering and prioritization, management of concurrent service instances.

4. https://portal.office.com

18 3. Analysis

The MSMQ queue itself turned out unsuitable as explained in section 2.3. It is strictly Microsoft oriented and it does neither support nondestructive read nor reliable message delivery. The maximum 4 MB message size is also limiting for future extensions. The Power- Shell web proxy had to separately implement concurrent queue access mechanism, message prioritization, error handling, or a message search procedure. The current architecture misses proper fail-over capability that would prevent message loss when a node crashes. There are many alternative solutions [25] like RabbitMQ [26], Ac- tiveMQ [27], or stream-oriented Apache Kafka [28]. Antoine Duprat shared his experience with choosing a message queue with similar requirements [29] that resulted in the testing of RabbitMQ. After re- search and a discussion with a member of a development team of ICS MU, I focused on RabbitMQ.

3.5.1 RabbitMQ RabbitMQ [26] covers all of the desired functionality. It is written in Erlang [30] that is used to build soft real-time systems with high availability requirements. It extends the AMQP protocol [31]. It features message delivery acknowledgment, advanced routing management capabilities, cluster deployment for high availability and throughput, data encryption, various authentication and authorization methods featuring LDAP, certificates, or IP address ranges. A maximum message size will be limited to 512 MB in version 3.8 [32]. There are also plugin extensions, HTTP API and command line user interface for management and monitoring, mature user community and sufficient documentation at one’s disposal. RabbitMQ provides application libraries for many programming languages including Perl and .NET. There are also available community PowerShell modules for RabitMQ clients [33] and management [34]. But concerning the anticipated implementation complexity, they would not be suitable for the purpose of this thesis. Messages are sent to an exchange which routes them to zero or multiple bound queues. Consumers can pull a single message one-by- one from a queue, or the queue pushes messages to consumers when available. To assure reliable delivery queues accept positive and negative acknowledgments. Positive acknowledgment causes processed

19 3. Analysis message removal from the queue; negative acknowledgment makes the queue to pass the message to another consumer. Unroutable or rejected messages may be returned to the publisher, dropped, or sent to a ’dead letter queue’ and processed in their way [35]. A logical grouping of running RabbitMQ instances that share users, queues and other runtime parameters, is called a broker or a cluster [36]. Nodes can join and leave a cluster dynamically. To join a cluster, nodes need different DNS-resolvable hostnames and common minor version of Erlang. By default, no queues are mirrored (copied) between cluster members but still reachable from any one of them. So a client can contact any joined node and obtain any data. When a node fails or restarts, clients can reconnect to the rest of the members. Non-mirrored data may become available after node restoration. Mirrored cluster retains all the data and full functionality. Every mirrored queue relies on a master and one or more mirrors. The master is hosted on a so- called master node. All operations for a given queue are first applied to the queue’s master node and then propagated to mirrors. This setting significantly affects client response time. Clients should be connected to the master for the best performance to avoid extra traffic routing that can even halve the message rate. Concerning cluster communication overhead, a single-node broker would deliver the highest throughput. But mirror queues brings desired high availability.

Deploying RabbitMQ would cover all functional requirements and simplify the current code including message and queue management, message prioritization, or concurrent queue access. Also, using Ra- bitMQ would reduce resource depletion and easier consumer scaling due to the fact that queue consumers do not have to reside on the same node with the queue or a RabbitMQ instance. RabbitMQ suits the concept of the PowerShell web proxy better than stream processing approach of Apache Kafka, it supports .NET clients in opposite to other competitors [27] [28], and it is not difficult to deploy and manage.

20 3. Analysis 3.6 Group Managed Service Accounts

In the current PowerShell web proxy design, the message queue listeners run under a dedicated domain account. The following concept may increase system security. Group Managed Service Accounts (gMSA) [37] are domain objects derived from computer accounts that reside in a distinguished organizational unit called Managed Service Accounts. They are designated to run services but cannot be used to log-on interactively. Windows operating system automatically changes passwords for these accounts every thirty days. To securely retrieve the current password a host needs to contact the Microsoft Key Distribution Service on a domain controller. To install and use a gMSA on a host, RSAT5 needs to be installed, and access to the host needs to be explicitly granted to the gMSA. Otherwise, it can be manipulated with as any other user account.

5. Remote Server Administration Tools (RSAT) is a PowerShell module for remote server management.

4 Design

This chapter derives from the analysis in chapter 3 and is devoted to the design of the identity provisioning from Perun to Microsoft environment. It focuses on AD, AAD, and O365. The figure 4.1 represents the mean of communication between Perun and Windows and Linux services. The preferred communication protocol by Perun is SSH. On the opposite side of Perun resides a reusable connector. It provides connectivity and functions to manage target services.

Figure 4.1: The identity provisioning schema.

All Windows machines may be managed remotely by via Power- Shell. Linux systems and new Windows natively support OpenSSH. For endpoint systems that do not support SSH, a proxy is implemented. It serves as a protocol translator, from SSH to PowerShell’s WinRM. That is the case of Windows Server 2016 and older.

23 4. Design

The new Perun connector for Windows works similarly to an existing connector for Linux [38]. I chose PowerShell as the underlying platform because of its nat- ural compatibility with Windows OS and Windows services and its capabilities discussed throughout the sections 3.2, 3.3, and 3.4. Al- ternatively, PowerShell Core could be used, but it would not bring any new features for Windows hosts. On the other hand, It would be an interesting option for services running on multiple platforms simultaneously. The workflow starts with Perun generating an updated batch of data and sending it to the connector. If it is connected via the proxy, the data is relayed to the destination server via a newly established PowerShell session. The communication between the proxy and the server is secured by provided SSL certificates. To prohibit the available session misuse, SSH and PowerShell provide appropriate tools. An SSH connection can be configured, so it allows only a specified command to run – that is the connector script. PowerShell supports JEA configurations with a similar effect as described in section 3.2.1. When the connector receives the data, it stores it in a temporary directory and validates the input. It checks the data source and the destination and the given target service name. Then the service scripts are launched. Administrators of the target service can fill-in some scripts that run before or after the main script. This way they can manage the service during the synchronization and alter the settings, add some custom objects, or back-up important data. In the future version of Perun’s implementation, it will support both full state synchronization and delta batch increments. Currently, it pushes the whole state information. The process script should anticipate that and processes all the input data. In case of a great number of objects on the input, due to attribute comparison and communication with external service like O365, the script takes naturally much longer time to finish. As a result, compared to incremental processing, synchronization cycles need to be longer which results in slower change propagation. When the delta synchronization feature is not supported by the identity management system and should be moved to the service scripts, an additional attribute per object would be needed in the data set indicating that it has changed. It could be a time stamp of

24 4. Design

the last object change or its hash. On the script side, however, a hash table with the last known state information would be necessary. This approach would lead to new challenges concerning error handling and consistency assurance. It would increase the scripts’ complexity and might not decrease the processing time at all.

4.1 Active Directory

AD is one of the Perun target services. Usually, LDAP is a sufficient tool for identity provisioning to AD. However, O365 requires a different approach. The service script launched by the connector processes the dedicated data and creates, updates, or removes users, user and license groups, and organizational units. It is supposed to run directly on a domain controller. To do so, it requires to be run under a domain administrator account. Since UCN AD and IDENTITIES AD run on Windows Server 2016 which does not include OpenSSH, the protocol translator is needed. Systems supporting OpenSSH can be connected via SSH directly. Fig- ure 4.2 captures both scenarios.

Figure 4.2: AD provisioning schema.

4.2 Azure Active Directory and Office 365

The required connector ought to be responsible for identity processing and distribution to AD, AAD of O365, and setting additional attributes in O365. According to the new design depicted in figure 4.3, Perun communicates with the connector only. The O365 service script can be seen as an extension to the basic AD service script. After altering user

25 4. Design information in AD, an AADC synchronization cycle is triggered. When successfully finished, the setting of other O365 objects and parameters via the PowerShell proxy may begin. In comparison with the previous design, Perun does not send data directly to AD via LDAP; it does not call the PowerShell web proxy while an AADC synchronization cycle is running. The tasks are phased, Perun provides data and service administrators can manage the process of identity provisioning. With a domain administrator privileges, the AD script would be able to start and check the state of AADC itself. However, when utilizing the protocol translator, a second-hop problem arises [39] that prevents from chained remote sessions. The available solutions involve maintaining an elevated account credential locally on the Domain Con- troller, passing it through the remote session, or using a gMSA1 and a JEA configuration only if all the computers resides in the same domain. None of the approaches were found suitable. As a result, to operate AADC the PowerShell web proxy is used as described in the following subsection 4.2.1.

Figure 4.3: The new O365 identity architecture schema.

1. See section 3.6.

26 4. Design

4.2.1 PowerShell web proxy Similarly to the previous design, the new PowerShell web proxy consists of three parts – a web REST API, a RabbitMQ broker and a set of PowerShell processes, as shown in the figure 4.4. The main distinction lies in clearer responsibility distribution between participating modules. The REST API mediates the functionality of the proxy to clients, the RabbitMQ queue routes and distributes messages, a PowerShell service monitors running PowerShell queue listeners which consume messages and run end scripts that manage O365 service. As a result, the system is even more scalable, more manageable, more reliable, and sustainable.

Figure 4.4: The new PowerShell web proxy architecture schema.

The REST API authorizes HTTPS calls, validates the syntax and translates the requests into messages that are sent to the main message queue. Every request is tagged with a globally unique ID. Based on the type of request, a message priority is also determined. Besides the singleton main message queue, a response queue is created with every new request. All the queues are durable, which means they are stored on a disk drive and can survive a node restart or a crash. Every message can be identified by a response queue name that is determined at the time of the request arrival. A PowerShell service maintains tens of PowerShell processes waiting for new messages to appear in the main queue. When it happens,

27 4. Design the queue distributes requests in a Round-Robin fashion to available consumers. The PowerShell listeners are authenticated and connected to remote sessions of the O365 services. When a new message arrives, it executes it as a command within the custom-built O365 PowerShell module. If a consumer fails while processing a message, an acknowledgment is not sent back to the source queue, and it is re-assigned to another listener. The process output is sent back to the response queue. If a specified timeout is met, the response gets automatically back to the caller. Otherwise, the client can retrieve the result from the response queue manually via the REST API. Once the data is collected, the response queue ceases to exist. The response queues are subjects to a Time-To- Live policy which ensures that uncollected queues do not stay in the system forever. The API also accepts batches to process. It generates unique requests to the main queue that are performed individually. However, they share the same response queue. The client can check the number of responses in the output queue and collect it at once when ready. In such complex system, error handling may be complicated. To be able to respond to various types and sources of errors, the PowerShell web proxy differentiates:

∙ Terminating errors of the REST API, RabbitMQ, or internal communication fails causing the service inaccessibility.

∙ Terminating errors of a listener, module code errors, or unhan- dled O365 interface modifications resulting in accepting data but not processing it by stopping the PowerShell service only.

∙ Temporary errors of listeners and scripts caused by broken remote sessions or slow change propagation to O365.

The flaw of a broken connection from a listener to the O365 service can be resolved by the queue passing the message being process to another listener and reconnecting the listener. Ordinarily, an end script might try to query a user that has been synchronized to AAD but has not been assigned a full license set which raises an error. This use case can be detected, and the solution covers requeueing the request message with some delay.

28 4. Design

Figure 4.5: The new clustered PowerShell web proxy architecture schema.

The basic queue design of a single node can be extended with a second node and mirroring all of the queues to support high availability as shown in figure 4.5. Even though the estimated performance drop, it would provide the failover capability and support seamless host restarts when needed. NLB cluster assures the REST API availability via a single IP address. On the other hand, to provide the best performance, the architecture would consist of a single machine dedicated to the REST API and RabbitMQ and separate multiple machines running the PowerShell service with RabbitMQ listeners. When more computation power is needed, the machines where REST API, RabbitMQ and a base set of listeners run, can be extended by other computers arranging extra sets of queue consumers. In the university environment, OpenStack2 for simple virtual machine deployment is available and could be used as shown in figure 4.6. In such a situation, it is convenient to minimize the number of PowerShell listeners on nodes with RabbitMQ. The reason is to save some compu-

2. https://www.openstack.org

29 4. Design

Figure 4.6: The new PowerShell web proxy architecture schema with an OpenStack extension. tation resources for REST API and the message handling overhead by moving the heaviest computations to other hosts. If NLB over RabbitMQ cluster hosts deployed, listeners do not need to keep a list of cluster members and implement reconnection logic if a node fails. With a single node (local) deployment, there is no need to cope with RabbitMQ-consumers authentication and authorization.When connecting other PowerShell hosts to the queue, a simple IP range authentication can be utilized with the assumption that hosts belong to a closed network range dedicated for this purpose. If it is not a possible scenario, certificate authentication and SSL data encryption could be used.

30 5 Proof of concept

The proof of concept comprises of an implementation and deployment in a test environment of the SSH-WinRM protocol translator, Perun connector, service scripts for AD, AADC and O365, and reimplementation of the core functions of the PowerShell web proxy running on a single node with ten queue listeners. Clustered deployment with NLB and OpenStack machines is out of the scope of the thesis. For the connector and service scripts implementation I could have proceeded from Perun management scripts written in Perl [38] that gave me an idea of some object relations and system complexity. For testing purposes, I made use of an existing development environment and supplemented it with three more machines, so it consists of:

∙ New Windows Server 2019 with an Ubuntu subsystem that imitates Perun host.

∙ New Windows Server 2019 Core working as the protocol translator machine.

∙ Existing Windows Server 2016 domain controller hosting DEV- IDENTITIES AD.

∙ Existing Windows Server 2016 running AADC propagating changes from DEV-IDENTITIES AD to a testing O365 tenant.

∙ New Windows Server 2019 that serves as the new PowerShell web proxy.

∙ Testing O365 tenant MANDRAGORA.MUNI.CZ with AAD.

Besides the listed machines, for future integration tests and implementation, development Perun and Inet instances are also available. The test environment architecture matches exactly the schema in figure 4.3. In the testing environment, I used self-signed certificates generated via PowerShell. The Set-CertAuthentication script includes an

31 5. Proof of concept example with the certificate format. Since the hosts lie in a restricted network with controlled access and only a small group of administrators manage them, the self-signed certificates do not pose trust issues. In the production environment, certificates issued by a commercial or custom certificate authority (CA) should be used. CA simplifies new certificate deployment and allows its revocation.

5.1 Perun - data generation

At Perun’s side, a change of identity data format would be needed. Example data for AD and O365 is part of the implementation source files. Previously used LDIF data format, dedicated for AD, is difficult to parse in PowerShell in contrast with JSON. JSON is also standard format for REST API call payloads and other services. The development team of ICS MU will provide the modification. Perun sends the up-to-date JSON data encoded to Base64 through the established SSH channel to the protocol translator or the target connector directly. The Base64 encoding increases the input size by the factor of 4/3. However, it is acceptable and turned out necessary because of various character encoding and line endings which collide on the verge of Linux and PowerShell data pipelines and that were not straightforward to unify and resulted in corrupted data. When sending a byte array, the PowerShell pipeline reader was not capable of casting and routing the input to a script. Since PowerShell pipeline expects an object as the input, sending raw binary data resulted with nonsense output as well. Thanks to the command="%CONNECTOR% " prefix in front of a SSH key in authentication_keys1 file it is possible to restrict the SSH call just for a single command that automatically launches the protocol translation or the connector’s script.

5.2 Protocol translator

The protocol translator perun_mw searches the name of the target connector in its configuration file, loads an appropriate client certificate

1. By default located in C:\Users\username \.ssh

32 5. Proof of concept

thumbprint, checks the certificate validity, and then connects to the connector via WinRM through the secure HTTPS. It is convenient to increase the maximal 10 MB transfer file size limit on the remote host. Thanks to a setup session configuration at the remote host utilizing JEA, the connector call allows initiating just the specified connector script. No data is stored on the protocol translator host.

5.3 Perun connector

Using the protocol translator or connecting directly through SSH, the connector acts the same way. The connector script accepts the input Base64 encoded ZIP file, decodes it, extracts it to a temporary folder and validates the contained files. It checks the file versions and the target service name on awhite list whether it is enabled. Possible concurrent runs of the connector are monitored by software locks labeled with corresponding service names. Before and after the service script runs, an optional custom script code provided by the target service owner can be launched. At the end of the script, it deletes all temporary files and closes the connection. During the implementation of the protocol translator and the connector, I encountered an error of wrong access to the console output buffer with no obvious reason. The full error message can be seenin figure 5.1. It did not have any bad visible side effects. The source ofthe error was the command Invoke-Command calling a remote PowerShell procedure. It turned out that the error cause possibly long-running commands running on the remote computer (Expand-Archive for extracting files from an archive, Import-Module for adding sets of commands into a session, etc.) that show a current progress bar in the console window. This feature is not apparently compatible with SSH sessions that do not accept inputs from a terminal – run without user interaction. To resolve the issue, I set the global preference variable ProgressPreference to ’SilentlyContinue’ which suppresses the progress output. The setting is effective for the whole context of the connector.

33 5. Proof of concept

Figure 5.1: The remote session error message.

5.3.1 AD service

AD service script process-ad is responsible for creating users and up- dating their attributes. It also handles directory organizational units, and user groups and their members. To manage large sets of objects, filters and hash tables are used extensively. It can be easily supplemented with handlers for other objects like computers or contacts. The script configuration file contains base organization unit paths, object filters, and names of attributes to process.

5.3.2 AADC service

AADC service script process-addc communicates with PowerShell web proxy via the REST API, so it runs a new AD synchronization cycle. If one instance is already running, the script waits until it ends. Nevertheless, this situation should not happen since the connector holds a software lock for the service. After a cycle is started, the script checks its status until it finishes and then returns the result.

5.3.3 O365 service

The process-o365 script currently implements setting user mailboxes and mail-enabled groups. It can be extended for other objects. Accord- ing to the Perun input, it generates a batch request and sends it to the PowerShell web proxy. Next, it checks the number of messages in the response queue. When the count equals the expected state, it downloads all of them in bulk. The process-o365_full script wraps up AD, AADC, and O365 scripts. It obtains a valid certificate to call the PowerShell web proxy, launches AD, AAD, and O365 processing, and returns the results.

34 5. Proof of concept 5.4 PowerShell web proxy

5.4.1 REST API The REST API was rebuilt based on modern ASP .NET Core 2.2 and ran as an IIS service. The authorization is based on the certificate mapping [40]. The API validates the incoming payload and puts it with a predefined priority to the main queue of the PowerShell web proxy. On the other hand, a client can collect data from response queues that are identified by GUIDs assigned with the original request.

5.4.2 RabbitMQ RabbitMQ required an extra management plugin [41] to be installed. It provides an HTTP API used for monitoring purposes described in the section 5.5. Part of the RabbitMQ setting comprises an error mitigating mechanism. It covers temporary fails of scripts that can be solved by delay- ing the execution of the request with several possible retries. When a queue listener detects a temporary error message in the script output, it rejects the input message. The main message queue routes such messages to a defined secondary queue. The secondary queue applies a Time-To-Live policy that expired messages returns back to the main queue. The messages carry a counter how many times it has been rejected, so the number of attempts can be bounded by listeners. To implement this in RabbitMQ the x-dead-letter-exchange property of the main queue needs to point to the exchange2 of the secondary queue and vice versa. The rest of the queue and message settings are managed by the consumers.

5.4.3 Queue listener and O365 module PSWS-Listener imports RabbitMQ client library and all its components, O365 custom scripts included. Next, it obtains an O365 administrator account from a pool (a set of XML files with secured authentication data) and creates sessions to O365 and its services. Based on

2. Component of RabbitMQ that routes messages to zero or more bound queues.

35 5. Proof of concept experience of the O365 team, one account can be used at most three times at a time; else it usually gets restricted and throttled by O365. On the other hand, limiting the number of administrator accounts is the best practice. Then the listener connects to the main message queue, test the Exchange Online session connectivity, and waits for a request. When it comes, the listener tries to execute the message that needs to carry the name of a command and its parameters. The listener is ought to run in a non-interactive mode that is enforced by the PSWS service script when launching a PowerShell instance. To forbid a credential pop-up window, the ConsolePrompting key in the registry3 must be set to TRUE on the hosting machine. Otherwise, the consumer gets stuck and unmanageable. If the command fails due to a broken connection, it automatically nacks the message and reconnects. To be able to convert O365 script from the current PowerShell web proxy, minor changes including log function renaming and changing the output data format are needed. Script migration would be suitable for cleaning the code and refactor it.

5.4.4 PowerShell service The previous version of the PowerShell web proxy keeps the number of its PowerShell instances in the following way. In the beginning, a single process is started. After it loads all assemblies, it checks if the pre-configured number of fellow instances is running. If not, it launches another one. After it takes care of a message from the queue, it repeats the instance check. To make all listeners stop, the same count of ’exit’ messages needs to be sent to the queue. To easily install, start, restart, stop, and manage the PowerShell listeners in the new PowerShell web proxy, I took advantage of Jean- François Larvoire’s template project [42]. It implements a Windows service that utilizes a PowerShell script [43]. The advantages include:

∙ Integration with native Windows Service Control Manager (SCM) [44].

3. HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds

36 5. Proof of concept

∙ Automatic service starts. Reliable service terminations and restarts. PowerShell support for these tasks.

∙ Included event logging.

SCM anticipate an executable file to run it as a service. It needs to implement the .NET ServiceBase class that includes OnStart, or OnStop handlers for example. The script contains such C# code snip- pets that are compiled when installing the service. I modified the template, so the format of the file log corresponds with the rest of the implemented components. I also added the main code that every 10 seconds checks the number of running PowerShell processes and starts new ones if necessary. To run the service and to list all running PowerShell processes under a specific user account, a local administrator account is needed. To remotely manage the machine hosting AADC via PowerShell, a member account of the AADCSyncAdmin and RemoteManagementUsers is required. To avoid storing credentials of such an account, I deployed gMSA introduced in section 3.6. The installation covers a template script Set-gMSA. At last, the gMSA account needs to be set as a login account in the service settings. The name of the account needs to end with a dollar sign ($). Hard stops and restarts do not harm the message processing thanks to the durability of the messages and the queues.

5.5 Logging and monitoring

One of the unifying aspects of the whole system comprises logging. It was essential to keep the same logging format throughout the whole system including protocol translator, connector, service scripts, Power- Shell REST API, PowerShell process manager, RabbitMQ listener, and O365 module scripts. To keep the information consistent it was necessary to configure common domain time synchronization server on non-domain machines. The perun_probe script can for the monitoring purposes parse the latest log files and summarize the results. RabbitMQ-Probe calls Rab-

37 5. Proof of concept bitMQ HTTP API to collect the number of queue consumers, message counts, or message rates. At the university, two service surveillance systems are in use. Na- gios4 and newly deployed Icinga5 works similarly. Both of them periodically call scripts (or listens for results) on the monitored hosts that run monitored services. Those probes gather health and statistical information and send it back to the monitoring center that automatically notifies administrators when something goes wrong or reaches a critical value.

5.6 Testing

Unfortunately, because the ICS MU development team was dedicated to other projects with higher priority, I could not test the whole developed system with Perun generating and sending the data. So I generated sample data with the user, group, organizational unit, and configuration information designated for IDENTITIES AD and university testing O365 tenant. Script Start-PerunSyncCycle can be used to convert the archive with data into the Base64 format and send it to the protocol translator or the connector. I was able to interconnect a Linux subsystem with the Perun connector running on the domain controller via the protocol translator, successfully import data to AD, start an AADC synchronization cycle, and utilizing the PowerShell web proxy to finish the setting of user mailboxes and groups. I proceeded with several more data sets with altered object attributes and changed group membership. One thousand users, one hundred groups, and five organizational units took forty seconds to create in AD and thirty minutes in O365 with ten opened sessions. Most of the time consumed message delay- ing and waiting till objects were completely ready in O365. It doubled the theoretical computation time. Update operations took thirty seconds for AD and fifteen minutes for O365. Nevertheless, time mea- surements depend on the service load.

4. https://www.nagios.org 5. https://icinga.com

38 5. Proof of concept

The future testing should cover clustered deployment and multiple listener hosts with proper performance testing to decide the optimal number of PowerShell consumers and individual nodes.

5.7 Deployment

The following scripts contains installation instructions with examples:

∙ Install-OpenSSH.ps1

∙ Set-OpenSSHKeyMngmt.ps1

∙ Set-CertAuthentication.ps1

∙ Set-SSLRemoting.ps1

∙ New-JEAConfig.ps1

∙ Set-gMSA.ps1

∙ PSWSService.ps1

Starting the identity provisioning via the Perun connector of an example production service, which is IDENTITIES AD running on Windows Server 2016, would require the following steps.

∙ Create a protocol translator host.

∙ Install OpenSSH on the protocol translator host.

∙ Copy the protocol translation script to the protocol translator host. Copy Perun connector and service scripts on the domain controller.

∙ Create a service domain administrator account to run the connector.

∙ Enable PowerShell remoting and set certificate authentication and SSL connection between the protocol translator and the domain controller.

39 5. Proof of concept

∙ Generate a JEA configuration and register it on the domain controller.

∙ Alter the protocol translator configuration file.

∙ Alter Perun data generation format accordingly.

∙ Distribute Perun public SSH key to the protocol translator.

∙ Stop the Perun service using LDAP to communicate changes to AD.

∙ Run a synchronization cycle via the Perun connector.

Running a service on Windows Server 2019 would not require setting the PowerShell remoting and JEA configuration. The procedure would look like:

∙ Install OpenSSH on the service host.

∙ Copy Perun connector and service scripts on the service host.

∙ Alter Perun data generation format accordingly.

∙ Distribute Perun public SSH key to the host.

∙ Run a synchronization cycle via the Perun connector.

To extend the AD service with the functionality of the PowerShell web proxy for O365 service and AADC synchronization some additional steps are needed:

∙ Create the PowerShell web proxy host.

∙ Install .NET Core, IIS, Erlang, RabbitMQ and its .NET client library on the PowerShell web proxy host.

∙ Copy PowerShell web proxy source files to the host.

∙ Configure REST API with the certificate mapping inIIS.

∙ Install the PowerShell web proxy service.

40 5. Proof of concept

∙ Generate O365 admin account pool.

∙ Create a gMSA account and add it to the AADCSyncAdmin and RemoteManagementUsers groups on the production AADC host.

∙ Run the PowerShell web proxy service as the gMSA account.

∙ Stop periodic AADC synchronization cycles.

∙ Run a synchronization cycle via the Perun connector.

Conclusion

The thesis concerns the topic of identity provisioning to Microsoft- based services from the university identity management system called Perun. Especially, it focuses on two target services – on-premise Mi- crosoft Active Directory and cloud Microsoft Office 365. The first goal was to create a reusable Perun connector to coverall potential Microsoft-based services. The second one was to move the current surplus responsibilities from Perun to the target service hosts and their administrators. As a proof of concept, I was ought to deploy the outputs of the thesis to provision identities to Active Directory and Office 365. According to the assignment, after I examined the current environment and identity provisioning architecture and identified their weak spots in chapter 2, I defined thesis outputs and requirements and analyzed Windows remote management capabilities together with possibilities of Active Directory and Office 365 provisioning and two more related topics in chapter 3. The following design chapter 4 derived from the previous chapters and introduced a Perun connector, its application for Active Directory and Office 365, and a redesigned PowerShell web proxy for the Office 365 service. The solution covered: ∙ Generic Windows connector compliant with the requirements that can receive data from Perun and run scripts to serve an arbitrary target service running on the Microsoft platform. ∙ Protocol translator that supports connector’s compatibility with older versions of Windows Server with no built-in SSH implementation and translates an SSH connection to PowerShell WinRM to transport data from Perun. Windows Server 2019 and newer can communicate via an SSH session directly. ∙ Service scripts that provision organizational unit, user, and group information to Active Directory and Office 365 with Azure AD Connect attribute synchronization. ∙ Redesign and reimplementation of the current PowerShell web proxy that is an essential component of the identity architecture of the Office 365 service at MU. Its REST API supports

43 5. Proof of concept

batch request processing and certificate authentication. Thanks to the replacement of the core message queue component and responsibility separation, the changes resulted in code reduction, increased system reliability, data integrity, failover capability, and simplified performance scalability.

Last chapter described the system implementation in a test environment in detail and resulted in successful testing that incorporated of sample user and group data synchronization via the connector and the PowerShell web proxy to Active Directory and Office 365. Chapter 5 ends with a system deployment plan. The future plans and considerations include:

∙ Full integration and testing of the connector and the PowerShell web proxy within the development environment for O365. Pro- duction deployment comes later.

∙ Integrating all introduced components with a central university log collector.

∙ Establishing a certificate authority, designing a semi-automated certificate distribution system.

∙ Pilot deployment of the connector for a print service and a geo- graphic information system at MU.

∙ Further analysis of UCN AD and its dependencies. Consider- ing consolidation of AD instances, building AD trusts, or AD Federated Services [45] deployment.

∙ Migration of scripts from the current PowerShell web proxy to the new one. Includes code refactoring and making it idempo- tent.

∙ PowerShell web proxy cluster deployment and utilizing Open- Stack virtual hosts.

44 5. Proof of concept

∙ Introducing a concept of automated deployment of a new command at the PowerShell web proxy REST API.

∙ Accessing the REST API for local administrators at the faculties to be able to perform advanced actions in O365 via PowerShell. That would involve the implementation of modern authentication using university unified authentication and authorization per REST call to delegate admin rights.

A Electronic appendices

∙ Windows connector for Perun together with an SSH-WinRM translation script and example setup scripts for OpenSSH on Windows, WinRM over SSL, certificate authentication for WinRM, and Just Enough Administration.

∙ PowerShell web proxy service script and its dependencies, Visual Studio REST API project, and example setup script for Group Managed Service Accounts.

Bibliography

1. PROCHÁZKA, M.; LICEHAMMER, S.; MATYSKA, L. Perun — Modern approach for user and service management. In: 2014 IST-Africa Conference Proceedings. 2014. Available from DOI: 10.1109/ISTAFRICA.2014.6880654. 2. Lightweight Directory Access Protocol (LDAP): The Protocol [online]. Nov- ell, Inc., 2006 [visited on 2018-12-27]. Available from: https : / / tools.ietf.org/html/rfc4511. 3. Office 365 Service Descriptions [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us / office365 / servicedescriptions / office - 365 - service - descriptions-technet-library. 4. Active Directory Domain Services Overview [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/ en-us/windows-server/identity/ad-ds/get-started/virtual- dc/active-directory-domain-services-overview. 5. What is Azure Active Directory? [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/azure/active-directory/fundamentals/active-directory- whatis. 6. What is hybrid identity? [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/azure/ active-directory/hybrid/whatis-hybrid-identity. 7. Azure AD Connect sync: Understand and customize synchronization [online]. Microsoft, 2017 [visited on 2018-12-27]. Available from: https: / / docs . microsoft . com / en - us / azure / active - directory / hybrid/how-to-connect-sync-whatis. 8. ČUCHRAN, Martin. Integration of Masaryk University identities to Mi- crosoft Office 365 cloud environment [online]. 2017 [cit. 2018-12-25]. Available also from: https://is.muni.cz/th/kmozy/. Master’s thesis. Masaryk University, Faculty of Informatics, Brno. Supervised by Kamil MALINKA.

49 BIBLIOGRAPHY

9. Network Load Balancing [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/cs- cz/windows-server/networking/technologies/network-load- balancing. 10. Message Queuing (MSMQ) [online]. Microsoft, 2016 [visited on 2018-12-27]. Available from: https://msdn.microsoft.com/en- us/library/ms711472(v=vs.85).aspx. 11. Resource Management in MSMQ Applications [online]. Microsoft, 2006 [visited on 2018-12-27]. Available from: https://docs.microsoft. com/en-us/previous-versions/ms811056(v=msdn.10). 12. Remote Desktop Protocol [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/windows/desktop/termserv/remote-desktop-protocol. 13. PowerShell [online]. Microsoft, 2019 [visited on 2019-01-27]. Available from: https://github.com/PowerShell/PowerShell. 14. Just Enough Administration [online]. Microsoft, 2017 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/powershell/jea/overview. 15. Windows Management Framework [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/powershell/wmf/overview. 16. Windows Server 2019 Includes OpenSSH [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://blogs.windows.com/ buildingapps/2018/12/11/windows- server- 2019- includes- openssh. 17. PowerShell Remoting Over SSH [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/powershell/scripting/learn/remoting/ssh-remoting-in- powershell-core?view=powershell-5.1. 18. Microsoft SMB Protocol and CIFS Protocol Overview [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https : / / docs . microsoft . com / en - us / windows / desktop / fileio / microsoft - smb-protocol-and-cifs-protocol-overview.

50 BIBLIOGRAPHY

19. ActiveDirectory [online]. Microsoft, 2018 [visited on 2018-12-27]. Avail- able from: https://docs.microsoft.com/en- us/powershell/ module/addsadministration. 20. Active Directory Service Interfaces [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us / windows / desktop / adsi / active - directory - service - interfaces-adsi. 21. System.DirectoryServices Namespace [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/dotnet/api/system.directoryservices. 22. Overview of Microsoft Graph [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/graph/overview. 23. Manage Office 365 with Office 365 PowerShell [online]. Microsoft, 2017 [visited on 2018-12-27]. Available from: https://docs.microsoft. com/en-us/office365/enterprise/powershell/manage-office- 365-with-office-365-powershell. 24. Resource Limits [online]. Microsoft, 2018 [visited on 2018-12-27]. Avail- able from: https : / / docs . microsoft . com / en - us / office365 / securitycompliance/office-365-resource-limits. 25. Message Queue [online]. stackshare, 2019 [visited on 2019-01-27]. Avail- able from: https://stackshare.io/message-queue. 26. RabbitMQ Features [online]. Pivotal Software, Inc., 2019 [visited on 2019-01-27]. Available from: https : / / www . rabbitmq . com / #features. 27. Flexible & Powerful Open Source Multi-Protocol Messaging [online]. Apache Software Foundation, 2019 [visited on 2019-01-27]. Available from: http://activemq.apache.org. 28. Apache Kafka [online]. Apache Software Foundation, 2017 [visited on 2019-01-27]. Available from: https://kafka.apache.org. 29. How to choose a Message Queue [online]. Antoine Duprat, 2018 [visited on 2019-01-27]. Available from: https://medium.com/linagora- engineering/how-to-choose-a-message-queue-247dde46e66c.

51 BIBLIOGRAPHY

30. Build massively scalable soft real-time systems [online]. Erlang/OTP, 2019 [visited on 2019-01-27]. Available from: https://www.erlang.org. 31. AMQP 0-9-1 Model Explained [online]. Pivotal Software, Inc., 2019 [visited on 2019-01-27]. Available from: https://www.rabbitmq.com/ tutorials/amqp-concepts.html. 32. Reduce max message size to 512MB [online]. Pivotal Software, Inc., 2018 [visited on 2019-01-27]. Available from: https : / / github . com / rabbitmq/rabbitmq-common/pull/289. 33. PSRabbitMq [online]. Chris Duck, Warren Frame, 2018 [visited on 2019-01-27]. Available from: https : / / github . com / RamblingCookieMonster/PSRabbitMq. 34. RabbitMQTools [online]. Mariusz Wojcik, 2014 [visited on 2019-01-27]. Available from: https : / / github . com / mariuszwojcik / RabbitMQTools. 35. AMQP 0-9-1 Model Explained [online]. Pivotal Software, Inc., 2019 [visited on 2019-01-27]. Available from: https://www.rabbitmq.com/ tutorials/amqp-concepts.html. 36. Highly Available (Mirrored) Queues [online]. Pivotal Software, Inc., 2019 [visited on 2019-01-27]. Available from: https://www.rabbitmq. com/ha.html. 37. Group Managed Service Accounts Overview [online]. Microsoft, 2016 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/ en-us/previous-versions/windows/it-pro/windows-server- 2012-R2-and-2012/hh831782(v%5C%3dws.11). 38. Perun services [online]. CESNET, CERIT-SC, 2019 [visited on 2019-01-27]. Available from: https://github.com/CESNET/perun- services. 39. Making the second hop in PowerShell Remoting [online]. Microsoft, 2017 [visited on 2018-12-27]. Available from: https://docs.microsoft. com / en - us / powershell / scripting / learn / remoting / ps - remoting-second-hop?view=powershell-6.

52 BIBLIOGRAPHY

40. Configure IIS to use your self signed certificates with your application including IIS client certificate mapping authentication [online]. Elizabeth Andrews, 2014 [visited on 2019-01-27]. Available from: https:// blog.jayway.com/2014/10/27/configure- iis- to- use- your- self-signed-certificates-with-your-application/. 41. Management Plugin [online]. Pivotal Software, Inc., 2019 [visited on 2019-01-27]. Available from: https : / / www . rabbitmq . com / management.html. 42. System Tools Library [online]. Hewlett Packard Enterprise, 2017 [visited on 2018-12-27]. Available from: https://github.com/JFLarvoire/ SysToolsLib/blob/master/PowerShell/PSService.ps1. 43. Writing Windows Services in PowerShell [online]. Jean-François Larvoire, 2016 [visited on 2018-12-27]. Available from: https : //msdn.microsoft.com/en-us/magazine/mt703436.aspx. 44. Service Control Manager [online]. Microsoft, 2018 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/en- us/windows/desktop/Services/service-control-manager. 45. AD FS Scenarios for Developers [online]. Microsoft, 2017 [visited on 2018-12-27]. Available from: https://docs.microsoft.com/cs-cz/ windows-server/identity/ad-fs/overview/ad-fs-scenarios- for-developers.