会社からオンプレADを消しました ~事前準備編~

俊介

俊介

こんにちは、俊介です。 みなさんはオンプレADを利用して業務をなさっていますか? コロナ禍が続いている中、リモートワークに伴いIDをクラウドで保管することが主流になってきましたね。 今はOktaやAzure ADなどが広まった中、オンプレADが必要無くなってきてる会社様も増えてきてると思います。

そこで弊社はオンプレADを消して、OktaとAzure ADを連携してしまおうとなりました。 今回はそんな記事を書いてみようかなと思っています。 詳しくは、はじめにとゴールにて書いていきます!

はじめに

今回のブログはADを社内から消して、Azure ADとOktaを連携していくまでのシナリオをブログに書いていきます。 ボリュームが大きいので、3つのブログに分けて書いていこうと思います。

本記事は一番最初の事前準備について書いていこうと思います。

ゴール

現在はOktaもAzure ADもオンプレADから同期させています。 これからはOktaからAzure ADを連携して同期させて運用させていくのがゴールです。

Before

オンプレADが存在している図。左下の赤枠部分がなくなります。

After

オンプレADを無くした図

事前準備&理解

オンプレADに依存しているシステムが無いか確認する

理由としてオンプレADを消すことによって、今までアカウント情報をオンプレADから見てた場合、システムにログイン出来なくなるからです。 なので、まずはオンプレADに依存しているシステムが何があるのかを調べる必要があります。 幸い弊社は基本的にOktaで認証をしていたので、特に退避策を実行しなくて良かったです(良かった…

実際に切り離し終わった時にアカウント情報のマスタがOktaになるのか確認する

最初は単純にOktaからオンプレADを切り離したら、PasswordなどのマスタがOktaに切り替わると思っていました。 ですが実際に検証をしてみると、それだけでは切り替りませんでした。 原因としては弊社はOktaとオンプレADの連携する際に「Delegated Authentication」を設定していました。 簡単に言えば、アカウント情報はオンプレADの情報を見ろよ!です。 下記OktaとオンプレADの連携の設定画面です。

かつ一番辛いのは、Oktaにログイン出来なくなり他のシステムが利用出来なくなってしまいます… 理由は単純。Oktaはさっきの手順通りオンプレADにアカウント情報を見に行くように設定しているので、切り離しをやってもOktaにはPasswordを持っていません… なので、弊社環境を例にすると、プラスで作業が必要になります。 それはPasswordリセットをする事です! Okta側でOktaのPasswordリセットしてあげることによってマスタがOktaになり、ログインすることが可能になります。

切り離しの際にユーザー単位でやるのかグループ単位で出来るのか確認する

作業当初はグループ単位(AD全体)で切り離しが出来ないか調べていました。 弊社は人数も20弱というユーザー数でしたのでどちらでも良かったんですが、1000人規模の会社様もいたりしますよね? そんな中ユーザー単位でポチポチしてたら気が遠くなります… なので当初はグループ単位で出来ないか調べていました。

しかし、Oktaの公式ドキュメントにはグループ単位での実施は書いていなかったので、ドキュメントに従ってユーザー1人1人の切り離しを行いました。

OktaとAzure ADを連携する際にライセンス周りやロール権限などの扱いがどうなるのか確認する

Okta側で設定しないと、Azure ADでユーザーに紐づけたライセンス周り、ロール権限それらが剥奪されることが分かりました。 設定の詳細などは、実践編のブログで書きたいと思います。

終わりに

今回はADを無くす上で事前に準備する事であったり理解をしておくポイントを書きました。 冒頭にも話した通り今回のシナリオは3つのブログに分けて書きます。

次回はOktaとADの切り離しについて実施編を書いていこうと思います。 実施編では、困った点/注意した方が良い点なども書いていきますので参考になればと嬉しいです。 それでは次のブログで。

この記事をシェア