sidebarIdM実験室いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。後は、関連するニュースなどを徒然と。ベースに実験した結果ですので正式版で使える情報とは限りません。使った認証連携を設定してみました。ブチザッキさんで紹介されているので、基本的にはそちらを参照してもらえれば良いと思いますが、今回は以前紹介した制限事項の確認がポイントです。以前のポストで紹介した制限(前提)事項は以下の2点でした。DirectoryのUPN属性がインターネットから解決出来る必要がある→下手に.localドメインで社内ADを構築しているとかなり大幅な変更になるかも知れません。他のアプリケーションへの影響もあるでしょうし。FIM2010などの自動化ツールは必須かも知れません。Gateway)が認めてくれる必要があります。証明書の発行元はシビアです。結論から言いますと両方とも気にする必要はありますが回避することができます。簡単な方の2からお話しをしますが、こちらは実際には「ドメインの所有確認さえできれば良い」です。使う証明書が信頼できる証明機関からの発行であろうと自己署名の証明書であろうと関係ない、ということです。指定する値を設定することでドメインの所有確認を行います。属性を変更するのは非常に困難です。ここに記載されている方法でドメインにUPNサフィックスを追加することによって各ユーザのUPNを変更することができるようになります。結局は各ユーザのUPNを変更することにはなるので、他のアプリケーションへの影響などを十分にテストするか、今回紹介する方法でUPNを変えずに運用できる方法を検討することになりそうです。属性を変更することの影響度の調査などなかなかハードルが高い話になってしまいます。属性がどのように使われているのか?を理解する必要があります。<ドメインのFQDN>というコマンドレットを実行します。要求規則ルールを見ると以下のように設定がされています。クレームとしてトークンを発行していることがわかります。使うカスタムドメインのユーザ名を設定してこのルール1の要求規則を変更してやれば大丈夫、という話になります。いう環境で構築します。いう値が入ってしまいます。次にこの電子メールアドレス属性をクレームとして発行するように要求規則を変更します。上のルール1を以下のように変更します。認証連携が実現できます。この手法がサポートされるかどうかは全く別問題なので、実際に利用する際はその点をよく確認して環境を構築することをおすすめします。さんのコメント...こちらと別エントリで記載されているディレクトリ同期ツールの設定で、mail属性でWebにはアクセスできるようになりましたが、Lyncからは接続できませんでした。UPNを変更したら接続できたことから、LyncのサインインAPがUPNでアクセスに来ているのではと思っているのですが。さんコメントありがとうございます。Communicatorは試してなかったですね。オンプレミス版でもADに求める要件が結構シビアでしたし、ちょっと制限がありそうですね。認証連携を行う本が出ます。よりアクセス解析を行っています。品質向上のみを目的とし、個人の特定などを目的とはしておりません。中で公開されることはあります。問い合わせ不明点等は管理人までご連絡ください。本プライバシーポリシーは予告なく変更/削除することがあります。プライバシーに関するトラブルについては一切の責任を負いかねますのでご了承ください。