SUSE Software Solutions Germany GmbH

A very special year for SUSE

2020 was a very special year for SUSE-not because of the Corona pandemic and its challenges, such as home office regulations, or the OpenVPN server migrations during the lockdown. The key change was SUSE’s independence from the parent company, which brought many liberties, but also new responsibilities.

For example, SUSE and the SUSE development team were responsible for building new departments, creating new infrastructures, and installing and configuring new IT services that had previously resided with the parent company. The migration of these services, the expansion of the IT stack, and the introduction of a new Identity Management System (IDM) paved the way for SUSE’s technical independence from the parent company.

Univention Corporate Server (UCS) as new IDM for community account management

SUSE needed a new IDM to manage user accounts for the approximately 50 services it uses, such as the Bugzilla bug tracking system for submitting and processing bug reports or the Open Build Service (OBS) for uploading and compiling source code. The Open Source solution Univention Corporate Server (UCS) from Univention was chosen because it met all of SUSE’s requirements for a new IDM.

An initial rough estimate was that there would be up to 87,000 user accounts, distributed among SUSE employees (1,800), partners (5,000) and the openSUSE community (80,000). Instead, the SUSE development team found 2.1 million user accounts in the parent company’s legacy system. However, the legacy IDM could not identify which of these accounts were active and which were inactive-that is, which accounts had data entered into the systems. This made it difficult for the SUSE development team to optimize and filter user accounts prior to migration. “A nice challenge,” Daniel Schmidt sums up the initial situation before the migration.

The challenge of migrating user accounts

The biggest challenges in migrating the user accounts were the sheer number of accounts and the high demands placed on the migration. The migration from Novell AccessManager to UCS, a Common Criteria-certifiable system, had to be completed in just six weeks with minimal downtime. A pair of replica directory nodes was to be placed in each of the local data centers (Nuremberg, Prague, Provo, and Beijing) so that services from the other regions could authenticate to them and a high-availability system could be created.

The primary directory node was also to be located in Nuremberg, as well as a backup directory node that would be replicated to another data center in Prague. In addition, password hashes could not be transferred for data protection reasons, and Novell AccessManager was a product that no longer existed.

UCS architecture with two additional replicas in the DMZ

Before the actual migration, the developers made some optimizations in the existing system and a subsequent filtering of the user accounts. For example, the number of user accounts was reduced from 2.1 million to 200,000, because only this many users had also entered data, source code and contributions into SUSE’s systems.

Although only about 1/8 (25,000) of the 200,000 users are regularly active, a “take-over” of the filtered users, i. e. the takeover of logins of inactive users by new users,had to be prevented at all costs. Otherwise, these new users would have been able to access other users’ contributions.

To do this, SUSE used tools it had written itself, which enabled the developers to check which users had stored which data in which services. In addition, a custom Python tool was developed for the step-by-step import of users into UCS, as well as a migration proxy that could log on to the old Novell Access Manager and the new Univention server.

For the migration itself, the LDAP schema of the Novell Access Manager was replicated to save time, as this meant that no data conversion had to be performed and only minimal adjustments had to be made in the systems. Finally, a pre-import of the 200,000 user accounts in an inactive state was implemented. During the subsequent migration, the corresponding user account was then activated.

Getting there one service at a time

Rather than migrate all services in one fell swoop, SUSE opted for a gradual migration, starting with large services such as Bugzilla, which had a particularly large number of user accounts. This sped up the migration process. It also gave them the flexibility to respond to problems as they arose and take them into account when migrating other services.

First, the migration proxy was brought online and extensively tested by the development team. Then, Bugzilla was the first service to be migrated by forcing all users of that service to log in to the migration proxy. Once logged in, the password entered was verified by the old system and, if successful, passed to the Univention server via the API.

The server activated the account, issued a token and redirected the user to a self-service password reset. After that, each user effectively had two community accounts: One in the old system for services that had not yet been migrated, and one in the new UCS system for services that had already been migrated. The other services were then successfully migrated in the same way.