ADFSのシングルサインオン環境において、外部からブラウザでアクセスすると、ADFS Proxy経由でのアクセスとなります。
　

この際、オペレーション上で少し気になる点がありました。

1. 前の画面でIDを入れたのに、再度最初から入力を促される
2. 前の画面では、username@domain.nameの形式で入力する必要があるが、移行先の画面では入力例がdomainusernameになっている

少し変だなとは感じつつも、まあデフォルトで埋め込まれている物だから仕方ないな…と思っていたのですが、ExchangeのMVPのMike Pfeifferからこれを解消するカスタマイズ方が紹介されています。

Useful Customizations to AD FS 2.0 when Deploying SSO with Office 365

詳しい手法については上記ページに任せようと思いますが（日本語環境でもほぼ一緒です）、こちらに従ってC:inetpubadfslsApp_GlobalResourcesCommonResources.ja.resxとC:inetpubadfslsFormsSignIn.aspx.csのファイルを書き換えます。
　

すると、違和感の無い画面表示になり、ユーザーIDの初期値に前の画面で入力した値（HTTPヘッダ中のGETパラメータのusernameに渡されている値から取得しています）が入力されるようになります。

セキュリティの問題で、メールアドレスのドメイン名とUPNドメイン名を分けている場合などは、UsernameExampleの値を実際の名前では無く「username@example.com」などに汎用化しても良いかもですね。

前回の投稿について、識者からいくつかコメントを頂きました。

• 自己証明書ではなく、サービス通信証明書をトークン暗号化・トークン署名でも使ったらどうか？

確かに、ADFS関連のトレーニングではこちらの手順についても教えて頂いた記憶がございます。更新時は手動で更新になってしまいますが、全部一緒のタイミングであれば更新し忘れも無いですし、証明書更新のためシステム少し止めますよと言っても理解が得られそうです。

何より面倒くさければ最初から3年間有効な証明書とか買ってしまえば済むことですしね。

• Office365なのに350日で利用出来なくなるのが問題なのだから、名前をOffice350にすれば良いのでは？

なるほどwww

というわけで、私の方でも少し対処を考えてみました。そもそも、ADFSの自己証明書の

1. 期間は365日
2. 切れる20日前に新しい自己証明書を発行（セカンダリに）
3. 2から5日経ったらセカンダリの証明書をプライマリに昇格させる

という値が問題になっているということです。こういった物は、きっとパラメーターになっていて、PowerShellなら設定出来るでしょうということで、PowerShellでGet-ADFSPropertiesコマンドを実行してみます。

すると、それっぽいパラメータがあります。

• CertificateDuration : 365
• CertificateGenerationThreshold : 20
• CertificatePromotionThreshold : 5

と言うわけで、証明書の期間を10年にして新しい自己証明書を発行してみます。

Set-AdfsProperties -CertificateDuration 3650
Update-ADFSCertificate -Urgent
Update-MsolFederatedDomain -DomainName contoso.com

これで、ADFSの自己証明書が10年に更新されました。ちなみに、通常はUpdate-ADFSCertificateはUrgentオプションを付けずに実行し、セカンダリの証明書として作成をします。プライマリに昇格するまでの5日間の間に、Update-MsolFederatedDomainコマンドにより新しい証明書をOffice365に転送します。

Office365側にも無事に転送され、10年として認識されていますようです。

と言うわけで、後で忘れそうな方は最初から延長してからADFS環境を組むのも良いかもしれません。

日経BPさんより、先週「ひと目でわかるADFS2.0 & Office365連携」が発売されました。

発表時に「ひと目でわかるADFS(仮)」というタイトルだったので、一部で「本当か！？」とささやかれておりましたが、無事発売となったようなので早速購入して来ました。

ページ数は220Pで、1章から6章までの章立てです。

1. 本書で学習する前に
2. 認証と認可（承認）
3. AD FS2.0の基本
4. AD FS2.0のインストールと構成
5. ローカルActive DirectoryとOffice365の連携
6. クライアントアクセスポリシー

内容のレベルについてはOffice365やADFSのトレーニング＋ハンズオンをくっつけたような感じで、トラブルシュートや運用系の部分は若干薄めですが、ADFSのさわりを扱うにはとてもよくまとまっている良い書籍かと思います。

ただ、良くも悪くも、各章ごとに知っておくべき事を必要十分な情報量を掲載しています。ADFSを触ったことのある人ならよく分かると思うのですが、認証/認可、RP/CPとか証明書まわりとか、重い部分が2章～3章に重なっており、ここをいかに華麗にマスター…さもなくばスルーするかがひと目で分かるポイントかと思います。

Office365でADFSをとりあえず利用する上では、殆ど選択肢無しのウィザード形式で実装できます。敢えて、4章から読み始めて仕組みでは無く効能・手順から入るようにするのも良いかもしれません。

Office365のディレクトリ同期ツールを利用すると、社内のActiveDirectoryの以下のオブジェクトをOffice365に（使用するしないに関わらず）同期してくれます。

こちらのMicrosoftのドキュメントをチェックすると、この同期のオブジェクト数には上限値が定められていて、それ以上はSRを上げて上限値を引き上げないといけないとあります。この閾値は20000と定められており、こちらはオンプレミスのAD上で「展開準備ツール(Deployment Rediness Tool)」を実行することにより、おおよその数値を知ることが可能です。

カウント対象となるのは以下のオブジェクトです。

• ユーザー
• グループ（配布グループ、セキュリティグループ）
• 外部連絡先

殆どのオブジェクトがオンプレミスで同期して利用している場合は問題にならないのですが、例えばExchangeの配布グループはOffice365側で作成（※セルフサービス型で利用したい為）など、ディレクトリ同期するオブジェクトの他に相当数のオブジェクトがクラウドID（非同期オブジェクト）で存在する場合、20000には達していないのに、以下の様なアラートが発生する場合があります。

Unable to add this user because the total number of allowed objects has already been reached.
 + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Quota  
ExceededExcption.Microsoft.Online.ADministration.Automation.NewUser

試しに、数十個のオブジェクトだけディレクトリ同期した環境にひたすらオブジェクト（ユーザー）を作っていくと、確かに20000弱（今回の場合は19960個目）のオブジェクトで上記のエラーが出ます。

また、これが発生するとディレクトリ同期ツールからオンプレミスで新規でできたオブジェクトを追加することはできません。どうやら、20000というクォータは同期したオブジェクトの数ではなく、Office365上で作成したオブジェクトも含む数値のようです。

皆様におかれましてはこうならないように、大規模環境の場合は、上記条件を考慮の上計画的にオブジェクト数を監視して、クォータ上限の引き上げを行って頂ければと思います。