Introduction

Hello! I am rioma from KINTO Technologies' Development Support Division. I usually work as a corporate engineer, maintaining and managing the IT systems used throughout the company. We recently held a study session in the form of case study presentations and roundtable discussions, specializing in the corporate IT area under the title "KINTO Technologies MeetUp! - Sharing Four Cases for Information Systems Professionals by Information Systems Professionals." In this article, I will introduce the content of the case study presented at that study session, along with supplementary information.

Why We Chose This Topic

We had an idea to host our first ever study session, inviting professionals from outside our organization. Given that we had a project available that could serve as a presentation topic, I proposed focusing on the theme of transitioning to authentication infrastructures. Although the transition was technically from our sister company, KINTO, and their environment -not ours-, I believe I was able to provide a preliminary introduction to KINTO Technologies' corporate IT activities, encompassing our schedule and events occurring at that time. In this article, I will briefly supplement the information presented and provide a reintroduction of the content.

Premise

"Why was it necessary to switch to a new authentication infrastructure?" At KINTO, there were a lot of minor inconveniences and security issues surrounding the authentication infrastructure. After considering Microsoft Entra ID (formerly Azure AD), it appeared to be the optimal solution, so we decided to proceed with switching to Entra ID. Other reasons for this choice included the fact that KINTO Technologies' authentication infrastructure was already Entra ID, motivating us to implement it with the goal of enhancing collaboration, such as tenant integration, and the fact that we had the Microsoft E3 license but were not making the most of it. There were also significant advantages in terms of cost cutting.

On Switching Over

There were two considerations when making the switch. The first, to implement access policies which were previously controlled using certificates under similar conditions but without using certificates. The setting is based on conditional access, but as an overview, I was able to implement an access policy that is more robust and flexible than the existing one by combining settings such as "devices registered with MDM" as a condition and blocking any non-matching attribute values.

The second is a specification that passwords for all accounts are reset when switching. The specification had quite a strong impact, and I had to find a way to respond to it without affecting all our internal members. To address this, I changed the passwords for all accounts following a forced system reset, based on certain rules. Since the change rules were known beforehand, and detailed procedures after logging in were also deployed, the login process posed no issues, and there were only a few inquiries. *In fact, most people were using PINs instead of passwords to log in, so the announcement about the changed password was not particularly meaningful; instead, it led to a bit of confusion.

Trouble Surrounding Switching Work

While it is one of the most common cases in the development of procedure manuals, I received numerous comments that the explanation of the procedure manual and work outline was difficult to understand. This was almost 100% my fault. I was overly focused on explaining the risks and effects of such a big-impact work as switching authorization infrastructures, choosing words and explanations that proved challenging for those less familiar with such systems. As mentioned above, I only realized just before the switchover that one of the PC login patterns after the switchover was to log in with PINs. The login instruction that had been developed in advance of the switchover did not mention this at all. This created a puzzling situation for those accustomed to logging in with PINs. Fortunately, I managed to fix the materials on the last day and the day of the switchover, but the repeated revisions and reissues were time consuming and confusing. In addition, I noticed a design error during the switchover, and had to take the slightly unreasonable response of implementing the switchover procedure while correcting the design and procedure manual. I was relieved that the issue was not a fundamental part of the project. Please see the attached slides as there are more issues.

Conclusion

While there were some minor inquiries and suggestions, no critical issues such as extended downtime preventing work for extended periods occurred. Consequently, the switchover of the authentication infrastructure was successfully implemented. Later, I was very happy to hear from internal staff who said, "It's amazing that there were few inquiries or business impact despite the scale of the transition." I will continue to implement system changes/transitions in the future, and aim to better our internal environment based on this experience.