OktaとMSの連携でImmutable IDという普遍的なはずなIDを吹っ飛ばした時の話

これを読んでる君は、Immutable IDをきっと吹っ飛ばしたからやってきたのでしょう...

という物語調はおいといて、OktaとMSの連携でしくじった時にしんどかった時の話(Immutable ID版)をします。

そもそもの話

まず一つ愚痴です。OktaとMS Office365のアプリテンプレートはあるんですが、Azure ADのみの構成の場合、これ非常にわかりにくいというか、とても初見殺しです。

なぜかというと、Okta上のドキュメントではPowerShellとAPIを利用した方法の2パターンあります。
Oktaでは今おすすめしているのはAPIの方
なので、APIを利用してみるかってなるのですが、こっちの方法のドキュメントは用意されてないんですよね。なんで？おすすめじゃないの？
ちなみにPowerShellは用意されてます。ただしAzure Active Directory Module for Windows PowerShellこれ使うことになるんで、今まで使ってないねって場合は、準備めんどいかも。PowerShell慣れてるならいいけど。

で、APIの話に戻ります。
今回は愚痴なので詳細な設定方法は詳しくは書きませんが、フェデレーションしたいドメイン以外のドメイン(なので今回はonmicrosoft.com)の管理者アカウントを連携を行なった後に

APIのコネクトを行います。

承諾を押すと、Azure AD上にOkta Microsoft Graph Clientという存在が爆誕します。

このAPIは、何するかっていうと、承認画面に記載されているようにAPI上でOktaがAzure ADが連携するハブになります。つまりここを設定しないとなんも起きない。

書いてないけど！

書いてないけど！

まぁ書いてないのはいいんです。ちゃんとよく見たらわかるから。

ただこのOkta Microsoft Graph Clientちゃんは検証を行う上で地雷に変わる瞬間があります。

検証する時は、必ずアプリケーションテンプレートの削除とclientは必ず削除しよう！

OktaとMSのSSOで一発でドーンとやる勢いのある人はなかなかいないと思います。なんだかんだでMSはいろんなところに影響があるので、最悪PCにログインできなくなりますからね。(やらかしました。)

で、ですよ本題はこっからです。

同じテンプレートを利用してActive、Deactiveなんていうのを繰り返していくと、Okta側もしっちゃかめっちゃかになっていくわけです。もっというと、Azure AD側で作ったClientもしっちゃかめっちゃかです。プロビジョニング設定とかしてみて、Update User Attributesをチェックつけてみちゃったり、外してみちゃったりを繰り返してしっちゃかめっちゃかにしてみたり。

結果どうなるかというと、実際に連携して、ユーザーをアサインした時に、ある値が取得できなくなります。そう！タイトルのImmutabale ID...

本来であれば

正しく行えていれば、ユーザーをアサインする時ユーザー選択時の画面ではImmutabale IDは表示されず、アサイン後のユーザーの詳細画面へ飛ぶとImmutabale IDが表示されているという状態が成功状態。

この時にImmutabale IDが表示されなかった場合は、他のユーザーでも試してみください。そしてそのユーザーでもダメだった場合、なおかつプロビジョニングを適用している場合はOkta上でユーザーを作成してMSにアサインしてみてください。
これでImmutabale IDが表示されていれば、無事既存のユーザーのImmutabale IDが吹っ飛んでる可能性が高くなります。

では、実際Immutabale IDが消えてるかどうか確認するんですが、これはMS側の世界線で確認していきます。

Active Directoryがある場合はADあるところでPowerShellを叩きます

get-MsolUser -ObjectID kumachankawaii@hoge.co.jp | Select ImmutableID

これでImmutabale IDが表示されなければドンマイです。
Azure ADのみって場合は、Azure cloudShellでこう

Get-AzureADUser -ObjectID kumachankawaii@hoge.co.jp | Select ImmutableID

無事、Imuutabale IDが吹っ飛んだことを確認したら、影響範囲を確認します。
全ユーザーをCSVで落とすと便利です。Oktaにドキュメントがあるので参考にどうぞ。ていうか、Oktaにドキュメントがあると言うことはこの事故はよくあるのだろうか・・・

How to get a list of Office365 immutable IDs using Poweshell

消えたImuutabale IDを付与していこう

Imuutabale IDがなくなると正直もうどうしようもないです。ライセンスが付与できないし、ロールももちろん付与できない。SSOなんてもちろんできない。

つまり死

なので付与します。

Set-AzureADUser -ObjectID kumachankawaii@hoge.co.jp | Select ImmutableID hogehoge

hogehogeに入る値は他と一緒じゃなければ基本OK
もうぴぇんってなりながら付与していくのみです。

入れてもSSOできないとかライセンスが付与できない場合は別の問題があるので切り分けを頑張ろう

結局何が問題だったのか

正直何がトリガーで私の場合Immutable IDが吹っ飛んだかはわかんないんですけど、検証をやりすぎたというかやりすぎの割にアプリケーションテンプレートを使いまわしたりとか、ちょっとしたことで手を抜いたのが原因だった気がします。

やるときは、0から設定をするくらいの気合いがね...OktaとMSのSSOでは必要だったと思います。

という、やらかした反省の話でした。

ちなみに、SSOできなくて死んだとき、Azure ADには緊急アクセス用管理者アカウントで入ってました。SSOの設定をする前に必ず作ろう。l

緊急アクセス用管理者アカウント

Azure AD で緊急アクセス用管理者アカウントを管理する

質問や間違ってるよなんてあったら、Twitterかこちらのコメントまでお願いします。

参考になったと思った人は私のAmazon乞食に協力ください
わたしのほしい物リスト