IE以外でADFSにSSOする(2012R2編)

以前の投稿で、IE以外からADFSにシングルサインオンしようとした場合に、いくつか設定変更をしない部分があるということを紹介しました。

Windows Server 2012 R2のADFSにおいても、デフォルトの状態だとIE以外からはシングルサインオンできません。イントラネットのポータルからIDを入力すると、ADFS Proxy経由でアクセスした際と同じフォーム認証の画面に飛んでしまいます。(以下、Chromeでの画面例)
スクリーンショット (84) スクリーンショット (83)

今回は、IE以外のブラウザからも入れるようにする方法を紹介します。

 

以前は、拡張認証の対応用にIISの設定を変更しましたが、Windows Server 2012 R2のADFSではそもそもIISを利用してません。この為、対応のための設定変更はADFSで実行します。

主に設定に関係するのはSet-ADFSPropertiesの以下のパラメータです。([ ]内はデフォルト値)

  • ExtendedProtectionTokenCheck [Allow]
  • WIASupportedUserAgents [MSAuthHost/1.0/In-Domain,MSIE 6.0,MSIE 7.0,MSIE 8.0,MSIE 9.0,MSIE 10.0,Trident/7.0,MSIPC,Windows Rights Management Client]

ExtendedProtectionTokenCheckは、拡張認証に対応している場合は利用を許可すると言う物ですが、昔調べた際はIE以外は対応しているブラウザが無かった為にWindows7では対応をしなくてはいけなかった物ですが、今回調べた限りではサードパーティのブラウザ側でも対応が進んでいるのか、特に設定変更の必要はありませんでした。

次に、WIASupportedUserAgentsのパラメータです。Windows Server 2012 R2のADFSは、このパラメータを見てシングルサインオンさせるかフォームベース認証にするかを判断しています。これを、ChromeやFirefox用にMozilla/5.0を設定してみます。ご利用の環境に合わせて “Safari/6.0”, “Safari/7.0” なども追加して頂ければ、と思います。

$old=(Get-AdfsProperties).WIASupportedUserAgents
$new=$old+"Mozilla/5.0"
Set-ADFSProperties -WIASupportedUserAgents $new

スクリーンショット (79)

Chromeは、IEの設定をそのまま見て動作してくれますので、特に何も無くシングルサインオンできるようになりました。
スクリーンショット (84) スクリーンショット (85)

ただし、Firefoxの場合は以下の様にID、PASSの入力画面がポップアップします。
スクリーンショット (86) スクリーンショット (87)

 

これは、以前の投稿でも紹介した通りADFSのFQDNをIEでの「イントラネット」に設定しないといけないのと同じ理屈でセキュリティ上の問題からです。

about:configで設定画面に入った後、network.automatic-ntlm-auth.trusted-urisの項目にADFSのFQDNを設定すれば以下の様にシングルサインオンできるようになります。
スクリーンショット (86) スクリーンショット (89)

注意点としては、ブラウザのバージョンアップによりUserAgentの値が変わった場合はシングルサインオンができなくなりますので、こちらの管理を運用の中でしていく必要があります。

他人のスケジュールを作成する

急な休暇が入った場合や会議室だけおさえて欲しいと頼まれた場合など、他の人や会議室メールボックスのカレンダーに予定を書きたいケースがあります。

こういったケースでは色々と皆さん工夫されて運用されているようなのですが、今回は私がやってる方法について書きたいと思います。

 

編集者の権限を他のユーザーに一般的に与えているような組織であれば勿論問題無いですが、デフォルト設定だと直接のカレンダーアイテムの作成はできません。
スクリーンショット (53)

仕方ないので、会議開催通知をとして自分を含めた会議を作成します。

スクリーンショット (54)

ただ、こうすると自分にも予定が入ってしまいます。とはいえ、自分の予定を削除しようとすると、相手先にも会議のキャンセル通知が行ってしまい、最終的な予定表の見た目はCanceled: と入ってしまいます。これだと折角入れたのにあまり意味が無いですよね。
スクリーンショット (55) スクリーンショット (56) スクリーンショット (57)

 

そもそも、これは「会議」という予定表アイテムの以下の様な特性によります。

  • 会議にはそれぞれ開催者が設定される
  • 開催者以外の参加者は会議アイテムのコピーのみを保持する
  • 開催者以外の参加者は仮の予定として予定が作成され、「承諾→正規の予定に」「辞退→削除」となる。
  • 会議室はデフォルトでは当該時間に予定が入っていない場合、自動的に承諾処理が実施される
  • 開催者は予定時間や場所を変更したり、参加者を変更、会議の削除をしたりできる
  • 開催者が会議を削除した場合、参加者全員の予定がキャンセルされる
  • それぞれの開催通知、変更通知、キャンセル通知はメールとして流れる

今回は、この辺のところを上手く悪用利用して、相手だけに予定を入れてみたいと思います。

まず、これを実施するには自分の他に1人協力者が必要です。今回は、例えばユーザーBの予定を入れる際に、隣の席のCさんに手伝って貰うことを想定します。
スクリーンショット (58)

まずは、先ほどのようにサッカー観戦で休んでるユーザーBに会議開催通知を送って仮の予定を作成します。
スクリーンショット (67)

その後、ユーザーCに一時的にすべてのアイテムに対しての削除権限を付与します。
スクリーンショット (68)

そして、ユーザーCに頼んで自分の入れたその予定を削除して貰います。Outlook 2010だと右クリックで削除ができた記憶があるのですが、2013だと右クリックからは会議キャンセル通知の(代理送信の)作成に推移してしまうため、Shift+DELキーを押してアイテムを完全削除します。これで、ユーザーAの予定表アイテムが削除されました。
スクリーンショット (69) スクリーンショット (70)

ユーザーAのOutlookに戻って予定表を見てみると、ユーザーBの予定は残っているのに、ユーザーAの予定表からはアイテムが削除されているのが分かると思います。
スクリーンショット (72)

簡単な流れは以下の通りです。(確認ができたら、付与した削除権限は元に戻しておきましょう。)
スクリーンショット (73)

 

感覚的に正規な動作では無い気がするので、Outlookへの更新プログラムの適用などで将来的に出来なくなってしまうかもしれませんが、比較的リーズナブルな手順なのでよろしければお試し頂ければと思います。

Office365からサインアウトできない

最近Office365を利用していると、いくつかの環境でこんな場面に出くわすことがあります。

①Office365から[サインアウト]をクリックする
スクリーンショット (45)

②一度サインアウト画面にリダイレクトされて…
スクリーンショット (41)

③あれ?元の画面に戻ってきた。
スクリーンショット (42)

こんな症状の時は、今までの経験則からすると大体原因は2つです。

1つ目は、最初にサインインしたURLが誤っていた(自社ドメインのCNAMEにoutlook.comを指定して利用していた)場合。2つ目は、サイトのゾーンの問題です。

今回は、正規の https://portal.office.com からログインしているので、1つ目では無いです。

そう、今回は、上記のURLが新しくポータル用のURLになった(他のURLから行っても勝手にリダイレクトされる)のに、それをブラウザ側の設定に対応させていなかったのが原因と推測されます。

というわけで、インターネットオプションの[セキュリティ][信頼済みサイト]に新しいURL https://portal.office.com を入れてみます。
スクリーンショット (43)

これで、サインアウトを実行すると…無事、サインアウトできるようになりました!
スクリーンショット (44)

 

URL変わると言われた時点で気づければ良かったのですが…。なかなかこう言うのは事象が出てからで無いと気がつかないですね。難しいっす。

プランEで独自ドメインを使う(お名前.com/SRV対応)

ドメインレジストラの大手であるお名前.comさんで提供しているレンタルDNSが遂にSRVレコードに対応しました!

私もいくつかのドメインで利用させて頂いておりますので、今回はそちらの設定方法をご紹介させて頂きます。

まず、Office 365管理センターでドメインのメニューを開きます。(左のような[ようこそ画面]が表示されている場合は、右下の[Office 365管理センターに移動]をクリックして移動します)
スクリーンショット (1)  スクリーンショット (3)

[ドメインの追加]から[手順1を開始する]をクリックし、追加したいドメイン名を入力します。
スクリーンショット (4) スクリーンショット (5) スクリーンショット (6)

ドメインの所有確認のページが表示されますので、[一般的な手順]を選択して認証に必要なDNSレコードを取得します。今回は、TXTレコードを利用して所有確認をしてみたいと思います。
スクリーンショット (7)

 

次に、お名前.com側の管理画面[ドメインnavi]にアクセスします。 今回はTXTレコードの追加なので、[ドメイン設定]のタブから、[ネームサーバーの設定][DNS関連機能の設定]をクリックし、[DNSレコード設定を利用する]の横の[設定する]を開きます。
スクリーンショット (8) スクリーンショット (9)

ドメイン名を選択して[入力画面へ進む]としてDNSレコードの設定画面に移ります。
スクリーンショット (10)

ここでは、先ほどOffice365の画面に表示されたTXTレコードの値を入力します。ホスト名は空のままでTYPEを[TXT]とし、TTLはデフォルトの3600のまま、VALUEに[MS=ms…]の値を入力し、[追加]をクリックします。
スクリーンショット (11)

下の方に、[DNSレコード設定用ネームサーバー変更確認]のチェックがありますが、現在別のDNSを利用していて移行する場合などは、他のDNSレコードもこの画面で移植が終わってから[確認画面へ進む]を押して次に進むようにして下さい。確認画面の内容で間違いなければ[設定する]を押します。これでドメインの所有確認用のDNSレコードの作成が完了しました。
スクリーンショット (12) スクリーンショット (13) スクリーンショット (14) スクリーンショット (15)

次に、元の画面に戻って確認ボタンをクリックすると、DNSの登録が完了していれば[(ドメイン名)を所有していることを確認しました。]と表示され、ドメインが追加されます。
スクリーンショット (16) スクリーンショット (17)

以前は、ここでDNSレコードの値などをキャッシュして比較的長時間(場合によっては48時間)確認までに時間がかかることが有ったのですが、今回何パターンか試した限りでは、ここの確認サーバではDNSのキャッシュされる期間がDNSサーバ側で設定した値より比較的短くチューニングされているのか、数分程で確認が取れるようになりました。

さて、次はOffice365サービスで独自ドメインを利用する為のDNSレコードの作成です。[手順2を開始する]をクリックし、[今はユーザーを追加しません][次へ]をクリックします。
スクリーンショット (18) スクリーンショット (19)

[手順3を開始する]をクリックし、[Exchange Online][Lync Online]にチェックが入っていることを確認して[次へ]をクリックします。
スクリーンショット (20) スクリーンショット (21)

ここで追加すべきDNSレコードの一覧が追加されます。(試した時点ではMXが1個、CNAMEが4個、TXTが1個とSRVが2個でした)
スクリーンショット (22)

 

元のお名前.comの管理者画面に戻って、先ほどTXTレコードを追加したのと同じように追加します。以下が入力例です。特にSRVレコードは記載方法が少し他に比べると面倒なのでお気を付け下さい。それぞれ入力後、[追加]をクリックします。

スクリーンショット (38)スクリーンショット (32)

また、先ほどドメイン名の所有確認したTXTレコードは今後は利用しませんので、この場で削除しておきましょう。消しても消さなくても動作には何も影響は有りませんが、ゴミが残ってしまっているのも気持ち悪いですし。確認画面で確認できたら[設定する]をクリックします。
スクリーンショット (33) スクリーンショット (34)

ドメイン名の所有確認の画面に比べると若干時間がかかるケースが多いですが、しばらく待つと、上記で入力した内容が正しければDNSレコードの確認が終了し、独自ドメインをOffice365で利用する事ができるようになります。
スクリーンショット (35) スクリーンショット (36) スクリーンショット (37)

 

以前の投稿で、SRVレコードの対応状況について少しお話ししましたが、当時はほとんどど存在していなかったSRVレコード対応のサービスも、お名前.comさんのような大手をはじめ、いくつか対応して来てくれているようで嬉しい限りです。

勉強会

先週・今週と2週連続で勉強会に登壇させて頂きました。ご参加頂きました方々、本当にどうもありがとうございました。

両方ともOffice365の運用を中心とした部分でお話をさせて頂きましたが、「サービス全般」と「ID連携システム」という、別々の切り口での話となった為資料も全部作り直し…同じテーマにしておけば良かったと少し後悔(w

ただ、両方とも奇しくも結論としては「サービスはどんどん進化していくので、頑張って着いていきましょう」ということになりました。

オンプレミスと違い、サービス側は(望む、望まないに関わらず)どんどん進化していくので、そこに接続するクライアントや連携するシステムは上手く着いていかないといけません。

そこで今までとの差分が出た場合でも、基本的にその差分を埋めるのはサービス利用者である自分たち自身です。サービスを上手く乗りこなしていけるよう、これからも横の繋がりを大事にしつつ、情報発信していければなと思います。

なお、当日の資料などはSlideShareにアップしてありますので、よろしければご覧下さい。(間違いの指摘なども頂けると嬉しいです)

  • SQLWorld★大阪#24
    • 題名:運用を見据えた失敗しないOffice365導入
    • スライド

 

  • .NETラボ 2014.6月勉強会
    • 題名:Office365のID連携の機能の移り変わりについて
    • スライド

 

同じような勉強会での講演や執筆依頼などについては、TwitterかFacebookあたりで要請頂ければ都合の着く範囲で対応させて頂きますので、お気軽にお問い合わせ頂ければと思います。

勉強会の予定

最近本業が忙しくてなかなかblogも書けていない状態ですが、いくつか勉強会の登壇予定がありますのでお知らせします。

【6/21】SQLWorld★大阪#24

  • 日時:2014年6月21日(土曜日) 13:00-17:00
  • 場所:市民交流センターひがしよどがわ 401 会議室
  • 内容:運用を見据えた失敗しないOffice365導入
    • Office365サービスの特徴を踏まえ、導入に向けてすべきことを具体例含めて紹介します。

【6/28】.NETラボ 勉強会 2014年6月 ~認証系を勉強する1日~

  • 日時:2014年6月28日(土曜日) 13:15-18:00 (開場:13:00、退出:18:00)
  • 場所:日本マイクロソフト 品川本社 31F/VIP Board Room
  • 内容:Office365の認証回りの仕様の移り変わりと運用上の苦労話
    • Office365の運用回りの中で、ADFS/DisSyncを中心にOffice365が出てから3年間での仕様変更と運用での対応など。 今までの経緯を踏まえた上で、これからのロードマップや柔軟な対応の必要性について話をします。

【8/2】第9回 Office365勉強会

  • 日時:2014年8月2日(土曜日) 13:00-18:00
  • 場所:日本マイクロソフト 品川本社 31F/セミナールームB
  • 内容:未定(時間が貰えれば何かライトニングトークしようと思います)

 

Exchange Online上のデータ暗号化

導入するユーザーの要件によっては、どうしてもオンプレミスのExchange Serverで立てないといけないケースもあるので、Exchange Onlineの仕様は定期的にチェックしてます。

ご存じかと思いますが、Exchange Onlineを初めとするOffice365のサービス仕様は昨年からファイル(.docxや.pdf)ではなくTechnet上でのオンラインベースでの公開に変更されています。

Exchange Online サービスの説明

2014-04-21版をチェックしていたところ、2013-09-09と比較して色々と変更が加わってました。今回はその中から1つ紹介します。

保存中のデータの暗号化 (BitLocker)

Exchange Server 2013 ○(管理者が有効にする必要がある旨の注記有り)
Exchange Online(全てのプラン) 

この項目、悪い言い方ですがRFPでOffice365外しをする際に利用される、かなりメジャーな仕様でした。今回こちらが実装されたようですが、ユーザーから見てあまり機能面で響く物では無いので特にアナウンスとしては無かったのでしょうか。

例えば他にも以下の様な「オンプレではできるがOffice365では出来ない物」が有りましたが、いずれも実装されていっており、機能要件としてマルバツ表作ってもほぼ差が出ない状態になってきています。

  • アドレス帳の分割(→アドレス帳ポリシーの機能実装)
  • パブリックフォルダ(→Onlineでも利用可能に。しかも無料)
  • 階層型アドレス帳(→Onlineでも有効化可能に)

 

が、いざ実際に導入フェーズになってみると、色々と機能一覧では出てこない非機能要件の面で差異が出てきて、時には問題になったりもします。

 

というわけで、来月のSQLWorldさんの勉強会ではその辺りの事を踏まえた上で、運用を踏まえたスムーズなOffice 365導入についてお話ししたいと思います。

SQLWorld★大阪#24 開催情報

向く組織、向かない組織、導入が決まったのであれば変えていくべきポイントなど、具体例含めて紹介したいと考えています。

Office365で階層型アドレス帳が利用可能に②

前回の投稿では、Office365で利用可能になった階層化アドレス帳のさわりをご紹介しました。

今回は、実際に利用していく上でいくつか考えていく必要のあることを中心にお話したいと思います。

1.階層として利用できるグループの種類について

Office365では、①メールが有効なセキュリティグループ ②配布グループ ③動的配布グループ という3つの種類のグループを利用する事ができます。

 

20140325_01

テストというグループの下にそれぞれの種類のグループを入れて、アドレス帳に表示しないオプションを入れてない物-1(デフォルト値)と入れていない物-2を作成しました。

動的配布グループはアドレス帳に表示しないオプションの選択や階層化アドレス帳として利用する為に必要な Set-Group -IsHierarchicalGroup $true 自体が入れられませんでしたが、とりあえずはグループメンバーに入れたままテストしてみます。
20140325_03

結論)階層化アドレス帳の階層グループには「メールが有効なセキュリティグループ」「配布グループ」が利用できる。利用する場合はPowerShellのSet-Groupコマンドレットで -IsHierarchicalGroup を $true に設定し、アドレス帳非表示の属性は有効化してはいけない。

2.複数組織にまたがるユーザー(兼務者)の扱いについて

階層化アドレス帳はグループ内のメンバーであるユーザーを再帰的な展開はせずにそのまま表示します。この為、例えば「Contosoグループ会長 兼 Fabrikam株式会社社長」などのユーザーを表現したい場合は、「Contosoグループ」「Fabrikam株式会社」の両方のグループのメンバとして登録すれば両方に表示されます。
20140325_04

ただし、注意が必要なのは右側の一覧画面の中で表示される「役職」についてはグループの情報では無く、各ユーザーに静的に設定された値が表示されますので、一般的には本務の方を役職欄に入れる形が多いかと思います。

3.同一グループ内の並び順について

ここが階層化アドレス帳の最大の特徴にして、日本から要望が上がって機能化したんだなとしみじみ思う点の1つです。日本人は、社員の一覧を表示する際に50音順では無く役職順に並ぶ事を美学としています。

この為、
20140325_05
こーんな並び方をしてた日には、酒井総務課長からけしからんというメールを頂く事にもなりかねません。

このため、階層化アドレス帳で表示させるユーザーやグループには、SeniorityIndex というパラメータを設定して明示的に偉さの順番を表現することができます。

例えば、社長440 常務430 部長320 課長 310 係長220 社員210 などと定めて、それを各社員にSet-User -SeniorityIndex で設定をしておけば、
20140325_06

といった表示となり、酒井総務課長も満足してくれます。また、複数の同一階層の組織の並び順(例えば営業部が前なのか総務部が前なのかなど)を行う際にも利用できます。

元から会社の人事システムなどでコードがあればそれで良いですし、なければ後から間に役職を足せるように適宜間を開けた数を振りましょう。(え?担当部長代理と担当課長とどっちが偉いかって? そんな事は人事の人にでも聞いて下さいw)

4.同一階層内での並び順について

同一階層で、同一SeniorityIndexの場合、もしくはその設定が無い場合、並び順はフリガナが設定してあればその順に、無ければASCIIコード順になります。

こちらもASCIIコード順だと特に日本語の環境の場合は視認性が悪くなりますので、フリガナを設定しておきましょう。コマンドはSet-User [ユーザー名] -PhoneticDisplayName [フリガナ]です。

5.その他

  • Outlook Web App(OWA) からは利用できません。Outlook 2010/2013のみです。OWAからも利用したい場合は、BBSさんのAddressLookなどのアドインを活用しましょう。
  • 階層型アドレス帳関連の設定は基本的にPowerShellからコマンドラインベースで行います。組織改編や人事異動は気合いで乗り切りましょう。(昔は管理ツールとかも出てたのですが
  • アドレス帳ポリシー(ABP)と併用することはサポートされていません(参考)。(※試した限りでは上手く階層が作れれば動きます。アドレス帳非表示設定になってると階層型アドレス帳に表示されないのと同じ理屈で、トップから表示させたい各階層のグループ&メンバーまで上手くアドレス帳ポリシーに則って分割できれば…。)

 

ADFSでの所属ADグループによる制御について

Office 365でADFSを利用するとActive Directoryのグループをベースとしたアクセス制御を実装することができます。

Microsoftのサイトなどに設定例などがいくつか記載されておりますが、今回、主に大規模な組織でこのルールを運用する場合、こちらのサンプルをそのまま利用すると一部書式の問題でセキュリティリスクに繋がると考えられる物があるためこちらで共有します。

クライアントの場所に基づいた Office 365 サービスに対するアクセスの制限
An ADFS Claims Rules Adventure

書式のサンプルは以下の通りです。グループ名ではなくSIDを利用するというのはActive Directoryなどでの管理と同じで、グループの名称を変更しても不変な値をベースとして制御しています。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD group"])

例えば、以下のSG1というセキュリティグループでアクセス拒否の制御をする場合は、
20140323_01

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-589771422-1504810464-123969929-1223"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

などとします。

ところが、ここで1点問題と考えられるのが、上記赤字で書いた部分の書式です。==は「等しい」ですが、=~は「含む」です。また、SIDはGUIDなどとは違い可変長で、末尾の数字はグループが作成される度にインクリメントされてどんどん数字が増えていきます。

つまり、グループの数がどんどん増えて行った場合、いずれはSIDが一桁上がって制御すべきグループのSIDを「含む」グループが作成される可能性があるということです。
20140323_02

これにより、特定グループのメンバーを拒否しようとしたら別のグループのメンバーが意図せず拒否されてしまったり、特定グループのみアクセス許可していたサービスが意図せず許可されてしまうということが起こる可能性があります。

もっとも、ユーザーが作成するグループのSIDは基本的に4桁(1100番台?)から作成されるので、これが問題になるのは5桁のSIDが作成されるような10000以上のグループがある大きな組織になりますが。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-589771422-1504810464-123969929-1223"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

とすることにより、意図した挙動とすることができます。

Office365で階層型アドレス帳が利用可能に①

Office365(Exchange Online)は、新機能の追加に加え、「パブリックフォルダ」「アドレス帳の分割」など、発表以降オンプレミスのExchange Serverでしかできない機能制約がどんどん解消されています。

今回、その中で特に日本のユーザーにとって要望が多かった階層型アドレス帳(HAB)がOffice365でも利用できるようになりました。

階層型アドレス帳というのは、階層構造の組織をそのままアドレス帳として表示させる物です。(特に日本の企業であればなじみやすいかと思います。)
スクリーンショット (38)

階層型アドレス帳を利用する手順は、大きく以下の2つになります。(その後、必要に応じて並び順などのカスタマイズを行いますが、これは次回の投稿で書きたいと思います)

  1. 階層構造として表示したいアドレスをグループとそのメンバーとして表現し、そのグループのIsHierarchicalGroupの属性をTrueにする
  2. Set-OrganizationConfigで階層構造の最上位となるグループを指定する

会社組織の場合は最上位は「全社」、企業グループの場合は「○○グループ」になります。今回は、Contoso株式会社とFabrikam株式会社から構成されるContosoグループでアドレス帳を作ってみます。

階層用のグループは専用で作成しても良いですし、既存で利用している組織グループがあればそれでも構いません。グループを作成してメンバーを構成したら、各グループにIsHierarchicalGroupのフラグをセットします。

Set-Group -identity [グループ名] -IsHierarchicalGroup $true

そして、最後に最上位のグループを指定します。(Enable-OrganizationCustomizationが必要とエラーメッセージが出た場合、事前に実行します。)

Set-OrganizationConfig -HierarchicalAddressBookRoot [最上位グループ名]

これで、Outlookからアドレス帳を開くと(OWAからは階層化アドレス帳は利用できません。Outlook専用です)、新たに「組織」というタブが表示されるようになります。

(設定前)
スクリーンショット (39)

(設定後)
スクリーンショット (36)  スクリーンショット (37)

次回は、階層化アドレス帳を実際に利用していく上でのTIPSをいくつか紹介したいと思います。

それにしてもどんどん便利になっていきますね。