リクルートのPCをhybridにjoinしてみた〜Microsoft Entra hybrid joinによるSSOの実現〜
山田麻以
この記事はリクルートICT統括室 Advent Calendar 2023 20日目の記事です。
はじめに
こんにちは!ICT統括室の山田 麻以です。
リクルートの認証基盤を運用管理するチームを担当しています。
この記事では、リクルートのActive DirectoryとMicrosoft Entra ID(旧Azure Active Directory)環境をMicrosoft Entra hybrid join(旧Hybrid Azure AD Join)化してSSOを実現した施策についてご紹介したいと思います。
プロジェクトの背景
まずはこのプロジェクトの背景から。
リクルートの認証基盤は目的別に分散管理されており、複数のオンプレADが乱立している状態でした。同一ユーザに対し複数ID/PWで管理されている状態だと、ユーザの利便性の低下やガバナンス観点でも適正な可視化やIDクリーニングが煩雑になるといった課題がありました。
その課題を解消すべく、Entra IDも含めて最終的に認証基盤の一本化を目指す、という目標を掲げ、まずその第一STEPとして「単一のID/PWによるSingle Sign-On(SSO)の実現」を行いました。
現状の構成は?
主要登場人物をご説明します。
① Microsoft Entra ID (旧Azure Active Directory)
② Microsoft Entra Connect (旧Azure AD Connect)
③ Entra ID連携用オンプレAD
④ PC等の端末認証用オンプレAD
ざっくり構成をまとめるとこんな感じです。
- ③Entra ID連携用オンプレADはID管理システムからユーザ情報を取り込み、②のEntra Connectを介してリクルートのユーザIDを①Entra IDへ同期している。ただし、ユーザのパスワードは同期していない。
- ④PC等の端末認証用オンプレADはID管理システムからのユーザ情報取り込みに加え、リクルートのPCやVDI等の端末認証等の役割を担っているが、②Entra Connectとの連携はされていない。
- ③と④はパスワード同期システムを介し、ユーザのパスワードは同期されている。
この構成で何が課題かというと、PC認証するユーザID/PWとEntra ID認証(Microsoft365等)するユーザID/PWが異なるため、認証の都度IDとPWの入力が必要になってしまいます。日々の業務でこの作業があるだけでユーザ側からしたらかなり手間になりますよね。
「あれ、このシステムへのログインはどっちのIDとパスワード使えば良いのかな?」と混乱するユーザもいます。
Microsoft Entra hybrid join準備のためにしたこと
SSOの実現のためにはMicrosoft Entra hybrid join(旧Hybrid Azure AD Join)を構成する必要があります。Entra hybrid joinを構成するために大きくは3つの対応を行いました。(細かい対応については省略…)
1.PC等の端末認証用オンプレADのPCオブジェクトのEntra ID連携
2.パスワードハッシュ同期の有効化(+αパスワードライトバックの構成)
3.PC等の端末認証用オンプレADユーザのUPN変更
まず1の対応では、Entra IDへ連携するため、Entra Connect上で端末認証用オンプレADとの接続を行い、PCオブジェクトが格納されているOUをEntra IDに同期をかけます。この対応を行うことで、Entra ID上でPCの管理が出来るようになります。
2の対応はEntra ID連携用オンプレADのユーザとEntra IDのユーザパスワードを同一のものにする対応です。実はこの対応がユーザ影響のあるもので、パスワードハッシュ同期を行うと、Entra IDのパスワードがEntra ID連携用オンプレADのユーザパスワードに上書きされてしまいます。対象となるユーザIDが当時でも約6万ID(!)あったため、かなりの影響になりますね!ユーザ混乱を避けるため、作業当日までに極力Entra ID連携用オンプレADとEntra IDのパスワードを揃えるようユーザ周知を行いました。
2+αのパスワードライトバックとはEntra IDからパスワード変更を行うと、オンプレAD側のパスワードに同期してくれる機能です。この機能を有効化すると、ユーザ自身でEntra IDのセルフパスワードリセット(以下SSPR)が可能となります。
※但しEntra ID上で多要素認証(MFA)が有効&設定されていることが条件となります。
Entra hybrid joinにおける必須対応ではありませんが、ユーザ利便性を上げるため実装を行いました。これまでユーザがパスワードを忘れてしまった場合、コールセンターに問い合わせて本人確認の上リセットを行ってもらうというフローだったのですが、ユーザ自身でSSPRを行うようになれば、問い合わせの手間も時間も短縮でき、コールセンター側の運用負荷も下げることが出来ます。
最後は3のPC等の端末認証用オンプレADユーザのUser Principal Name(UPN)を変更する対応です。UPNのデフォルトは[ユーザID]@[オンプレADのドメイン名]となっており、オンプレADに登録されているUPNがEntra ID上のUPNと異なるものだったため、オンプレADのUPNとEntra IDのUPNを一致させる必要があります。最後にこの対応を行うことでEntra hybrid joinが可能な状態となります。
UPNを変更する上で、懸念としてあったのが、PC等の端末認証用オンプレADを参照しているシステムへの影響です。ユーザのログイン名として利用される属性は、sAMAccountName([ユーザ名])かUser Principal Name([ユーザ名@ドメイン名])のどちらかになると思いますが、UPNを利用するシステムがあった場合影響が出てしまうという訳です。幸いUPNを利用しているシステムがなかったため、スムーズに実装することが出来ました。
Single Sign-Onを実現するためには?
では、これで晴れて全ての端末でSSOが出来るのでしょうか。
いいえ、違います!
先ほど説明した3つの対応はEntra hybrid joinを構成するための準備を完了するための対応で、この時点だと端末はEntra hybrid join未構成の状態なのです。
端末ごとにEntra hybrid join状態にすることと、PRT取得というものを行う必要があります。
PRT(プライマリリフレッシュトークン)取得とは?
Entra ID認証時に利用されるトークンの1種で、Microsoft Entra hybrid join等が構成されることにより、端末内に格納されます。PRTが発行されていることによって、M365やEntra IDに対しSSO接続が可能となります。
上記図の認証フローをご説明すると
①オンプレAD認証を行い端末にログイン(ユーザ作業)
②Entra IDへの認証(UPNを利用)
――――Entra Hybrid joinとしてEntra ID上に端末登録――――
③PRT発行し、端末へ配布
――――PRT取得――――
④SSO実現
このような流れになります。
実はこのプロジェクト推進中は新型コロナウィルス流行の影響で、全従業員に対しリモート勤務を推奨している期間でした。社外(社内NWに接続されていない状態)から端末へログインを行うと、オンプレAD認証を伴わないキャッシュログインにて端末認証をすることになります。コロナ禍の影響でEntra hybrid join構成&PRT取得が一向に進まないという状況になってしまいました。
さらに、後続予定しているプロジェクトにて、未構成のEntra hybrid join端末を期限までに撲滅する必要が出てきたため、そのフォローも行うことになりました。
これが結構大変で…。
結論をお話すると、現在はほとんどの端末がPRT取得まで完了済みです。
それまでの詳しい話を知りたい方は21日公開予定の記事をお楽しみに!
さいごに
本施策では「単一のID/PWによるSingle Sign-On(SSO)の実現」を行いましたが、実は私自身これまで"ユーザの利便性を上げる"という施策をしてこなかったんです。
どちらかというといかにユーザ利便性を損なわずにセキュリティを高めるかといったセキュリティ施策が多かったように思えます。
なので、今回この取組みをして(実際にSSPRの実現により成果も出て…!)前向きなフィードバックがある施策っていいな~なんて思いました。
ただ、このプロジェクトの目指すゴールは認証基盤の一本化です。まだまだ先が長い話なので、これからも焦らず腐らず前進していきたいと思います。
長くなりましたが、ここまで読んでくださりありがとうございました。
最後になりますが、リクルートICT統括室 Advent Calendar 2023では、リクルートの社内ICTに関する記事を投稿していく予定です。
もし興味があれば、ぜひ他の記事もあわせてご参照ください。