Microsoft 365 (Azure AD)でSSOを構成してみたよ
M365先生「君、わしと契約中のプランでSSO利用できるの知っとった？」
私「なんやて」
発端
こんばんは、しがない情シスです。
今回はMicrosoft365のバックに控えるAzureADを利用してSSOを構成したお話です。
つい2年前に365触り始めた情シス初心者が、どうにかこうにかSSOを構築できた備忘録的なお話でもあります。
（色々粗があるのは目をつぶってください）
職場にMiscrosoft365が導入されているのですが、イマイチ活用されていない感が強いので、ずっと「なんでや…」と悶々としておりました。
それもそのはず、そもそも導入を決めた人がOffice365（Microsoft365の旧称）は便利なオフィススイートのサブスクリプションという認識で止まっており、単なるWordとかExcelの塊としての運用しか想定していなかったようです。
何と勿体ない。
とはいえ、色々出来そうだけど現環境でどれほどのことができるのか…と悶々としているときに、mathken029さんの以下の記事を拝読しました。
こちらで紹介されてるんですが、中小企業向けのBusinessBasicプランですらSAMLが利用できるんですねー。
知らんかった…。マジで感謝です…。
つまり、へーしゃのこの環境でIdpでSSOな構成が出来ると…？
なんかやる気出てきました！！
IDまわりをちゃんとしよう
まず前提としてなんですが、私の管理してる環境は以下の状態でした。
・Microsoft365BusinessStandardプラン契約済み
・カスタムドメイン追加済み
AzureADに関しては基本的な設定だけされてて、あとはほぼバニラでした。
どうもあんまりカスタムするという運用がなされてなかったようです。
なんか前任者がAzureADについて特に認知していなかったようで、特に引き継ぎも情報も何もなかったんですよね。
だから全部手探りです。初見でふしぎなダンジョンに潜るようなものですが、ネットで攻略チャートを読めるので随時紐解きながら進みます。
まずはこいつをIdpとして使える形に整備していきます。
といっても原則としてユーザー毎にアカウントが割り当てられてて、一定の命名規則に従ってアカウントは発行されてました。
ただ、いくつか「なんでこんな運用してるんだ」みたいなアカウントもあった（アイデンティティとして成立してない運用）ので、アカウントは棚卸して最新の状態に整備し、該当ユーザーにも状況を説明して運用を変更していきました。
この辺は地味な説明と、アドレス変更だのエイリアス設定だのライセンス整理だの、ID整備作業の連続でした。
アイデンティティをアイデンティティたらしめるよう設定・整備しないとIdp、ひいてはSSOは有効に機能しませんよね。
SSOの設定
実はこっそりID整備前に自分のアカウントで動作検証はしてました。
なので実際は順序逆になりますが、細かいことは気にしない。
グエッヘッヘ、べんり機能を一足先に検証できるのは情シスの特権だなぁ！（ひどい）
まずはAzureADで連携先のSaaS情報を登録して、SSOができる環境を構築していきます。
構築手順はこのあたりの記事を参考にさせていただきました。
えーと、手順に沿って、アプリケーションを追加して。
認証ページのURLをコピペして。
証明書を発行して…。
…はて、ユーザー識別子って何を設定するんだろうか？？？
ハマったポイント：ユーザー識別子
これはSSOを後になってから構築しようとしたときのポイントかもしれません。
まずSSOを利用したい場合、AzureAD（Idp）とSaaS（SP）どうしを紐づける一意の情報が必要になります。
これが仮にAzureADとSaaSでおんなじアカウント・ID（メールアドレス）を使っているとしたら、AzureADさんのおすすめの既定値でオッケーだと思います。（確かEmailとか）
ただ、へーしゃの場合は365のアカウントを持たない非IT人員もおり、SSO連携先はそれらの人たちを含む全社員が利用するSaaSでした。
365側のアカウントは当然「メールアドレス」に該当する文字列です。
SP側ではIDとして「従業員コードに該当する文字列」が割り当てられていました。
このため、デフォルトでIdp側にSPの識別子に1:1で対応する識別子が存在しないことになります。
拡張属性というものが任意の識別子として設定できるようですが、ちょっと面倒そうなので他に何かよさげなものがないものかなー、と…。
ムッ、「employeeid（従業員ID）」ですと？
私のケースではSaaS側でのユーザーIDが「従業員コード」で割り振られているので、AzureAD側の「empliyeeid」を同一の物に設定してやればユーザーの識別は可能ということになります。
AzureADのユーザープロパティを開くと…ありましたね！
さて、問題はAzureADのこの空欄に従業員IDを登録していく必要があるのですが…。
うん、件数多くないし手打ちコピペでいっか！（思考放棄脳筋プレイ）
動作テスト
同一の識別子が設定出来たらあとはテストするだけです。
ここまできたらあとは難しいことは無いでしょう。
SP側のログインページを開いて、SAML認証が働いてリダイレクトされてログインが出来たら成功です。
あ、もちろん事前にIdp（AzureAD）にサインインしておく必要はありますね。
念のためアカウントページなりを一回開いて、サインイン済みであることを確認しましょう。
おわりに
M365も入ってる、SaaSも利用してる、そんでもって後になってからSAMLでSSOしたい、という時のSSO構築してみた手順でした。
SSOの設定手順はそれこそMicrosoftからも各SaaSからも公開はされているのですが、「じゃあ具体的に識別子どうしたらええんよ」っていう質問に関しては「おま環だから自分で考えれ」と言わんばかりに情報がありませんでした。
当然ですよね。会社の数だけ環境があります。
一般的にはM365のアカウントに寄せていくのが正解というか楽な方法だと思います。
もしこれからSSOを含めてM365を利活用したい！っていう場合はまず最初にID管理の方法を事前に練ってから進めるとスムーズでしょう。
私の場合後から考えて辻褄合わせることになったからウンウン悩みました。
でもSSOできるのは流石ですね。SAML万歳。AzureAD万歳。
私自身、SaaSとかIDaaS運用するのって現職になってからが初めてでした。超初心者です。
正直「SSOってOktaとかそういうの入れないと出来ないのでは…？」って思ってました。
シンプルにSAML認証によるSSOだけなら、M365のベーシックなプランでも出来ますし、ランニングコストかけずに利便性が上がるって分かったのはすっごく良かったです。
これからもM365さんをいい感じに駆使して、ちょっとずつ効率改善していきたいものです。
この記事が気に入ったらサポートをしてみませんか？