Category Archives: Office365

Office365の接続確認ツール（RCA）

Posted on by • Posted in Exchange Online, Office365全般 • Leave a comment

Exchange Remote Connectivity Analyzer(ExRCA)の名前で提供されていたExchangeの接続確認ツールが、バージョンアップしてOffice365に対応しました。

機能追加になったのは、【Microsoft Single Sign-On(BETA)】になります。これによりAD FS環境での外部からの接続確認(要AD FS Proxyです)が実施できます。

IDとパスワードの他、了解事項のチェックボックスと認証用の文字列を入力します。認証文字は大文字小文字は区別しませんが、間違えるとパスワード欄がクリアされてしまって再入力になりますので、UだかVだか分からないとか微妙な文字列だった場合は認証コードの上側のボタンを押して文字列を再生成しましょう。

ちなみに、前に紹介したCOMODOのフリー証明書は、Windows Updateしていないコンピュータだと、ルートCAが信頼済みの証明書ルートに含まれないと警告が表示されますが、動作に問題はありません。

他にも、ActiveSyncやOutlookなどは、クラウドIDでも、AD FS Proxy経由となるフェデレーションIDでも接続確認が可能です。また、受信SMTP電子メールでは実際にメールの送信の試行を行い、MXレコードが正しく構成されているか、メールサーバへのメールの受信ドメインとして受け入れられるかを試験できます。ただし、以下は注意する必要があります。

  • テストの送信元となるIPアドレスは逆引きができないアドレスで、弾かれる可能性があります（65.55.150.160など）
  • MXレコードの応答がCNAMEレコード（Exchangeをはじめ、配送できないMTAが多い）でも試験が成功する

Office365を独自ドメインで利用する（プランP）

Posted on by • Posted in Office365全般 • Tagged • 10 Comments

（2012/2/4更新）メニューのスナップショットを現行の物に変更

Office365は、SOHO、小規模企業向けのプランP（IT スタッフまたは専門家のいない、従業員が 25 人未満の組織）と、中規模企業以上の規模の企業向けのプランEがございます。機能的に一部制約がある（例えば、AD FSは利用できない）などの話は聞いてましたが、どうやら独自ドメインでの運用に大きな違いがあるらしいということで、試用版の環境をお借りして検証を実施してみました。

①まず、管理メニューのドメインからドメインの追加を選択し、ドメイン名を入力します。
　

ドメインの確認方法について表示されますので、プルダウンメニューから一般的な手順を選択すると、認証用のDNSレコード情報が表示されます。
　

Office365で独自ドメインを利用するには所有確認の為の認証が必要となりますが、認証を行うには、ここで表示されるレコード（TXTレコードもしくはMXレコード）を、ユーザが管理しているDNSサーバに設定する必要があります。つまり、ユーザはドメインを取得するだけでなく、そのドメインのレコード情報を設定できるDNSサーバを用意する必要があります。

ここでは、ドメインの登録事業者の中で、無料でDNSホスティングを提供してくれていて、かつTXTレコードにも対応しているGMO Internetさんのお名前.comを利用してドメインを設定してみたいと思います。新規で取得したドメインという設定ですが、既存の場合にも適用できるようにいくつか工程を挟んでいきます。

②お名前.comにログオンした後に、ドメイン編集メニューからレンタルDNSレコード設定をクリックします。複数ドメインを管理されている場合は、Office365で利用したい独自ドメイン名を選択し、入力画面へ進むをクリックします。
　

ホスト名は空欄のまま、TYPEに【TXT】を、VALUEに【MS=msxxxxxxx】と上記で出ていた認証用のDNSレコードの値を入力し、追加をクリックします。レコード追加の項目に正しい値が入力されていることを確認し、下の【レンタルDNSレコード設定用ネームサーバ設定確認】のチェックボックスが入っていることを確認し、確認画面へ進むをクリックし、確認するをクリックします。
　

確認画面の後に、DNSレコードが登録されます。
　

ここで、登録が終わったと思ってすぐにOffice365の認証を行ってはいけません。実際に、私はここで急いでクリックをしてしまった結果、認証に24時間掛かってしまいました。というのも、画面では処理が完了したと出ていますが、実施をしている処理は実際には数分時間を要している様です。③GMO側で処理が終わると、数分後に完了通知のメールが来ます。nslookupコマンドで登録したレコードが確認できます。

重要な工程として、裏で同時にネームサーバの切り替え（DNSホスティング無し:ns1.onamae.com→DNSホスティング有り:01.dnsv.jp）が実施されているのですが、ここが失敗すると時間が掛かるポイントです。例えば今回の場合でいう365poc.infoのTXTレコード検索ですが、先に365poc.infoのDNSサーバがどこかが検索され、その情報が1日間キャッシュされます。つまり、切り替え前のns1.onamae.comに聞きに行ったことのあるサーバは、その後1日間は01.dnsv.jpに切り替わったことに気がつかずにns1.onamae.comにTXTレコードの値を検索に行き続けます。これは事前に設定でどうこうなる問題ではないので、この事態に陥ったらあきらめましょう。

もちろん、通常はOffice365で使うDNSで、初めて使うドメイン名のNSレコードの情報がキャッシュされていることはあり得ないので、正しく他の端末から検索が可能な状態になっていれば、失敗せずに行けるはずです。
　

C:> nslookup -type=ns example.com
C:> nslookup -type=txt example.com

④DNSが引けるようになったら、晴れて認証画面の方に戻り、確認ボタンをクリックすると、ドメイン名が認証されてOffice365で利用できるようになります。

さて、プランPではここで見慣れない処理の指示が表示されます。
「ドメインのレジストラの設定でネームサーバの設定をMicrosoftの指定のDNSに向けて下さい」

えっ？だってそうしたら今まで入れていたWebサーバ用のAレコードとか、DNSサーバ用のNSレコードとかはどうするの！？　いえいえ、心配有りません。Office365はそれら全ての機能を持っています。会社のオフィシャルホームページも移して来れますので、DNSサーバを切り替えるついでに、それ以外のホスティングとか全部解約してきて下さい。

…いえ、すいません、そんなことはありません。MicrosoftのDNSでも、ちゃんとホームページ用のAレコードなどは追加出来ますので、ご自身の環境向けにカスタマイズして下さい。⑤指示は無視してキャンセルし、管理メニューのドメインから独自ドメインのプロパティの表示を選び、DNSマネージャーを選択します。ちなみにこのメニューはプランPにしかありません。
 　

⑥現在のレコードが表示されてます。最初はOffice365で利用するDNS情報のみ表示されておりますので、⑦ホームページなどを既に外部で持っている場合はそのホストのAレコード（wwwや＠）を追加します。これで、メールの切り替えが完了したら、いつの間にか会社のホームページが見れなくなっていたなどの事象は解消できます。
　

DNSの切り替えを実施する場合、原則は移行先の新しいDNSサーバで古いサーバと同じ情報を投入してから切り替えを実施するのが定石です。なぜなら、レジストラ側で保持しているネームサーバの設定は、軒並み長めのTTLが設定されていることが多く、脅し文句では無く普通にインターネット上の情報が全て切り替わるまで1～数日かかります。ここはローカルのDNSサーバの設定では制御出来ない部分なので、移行期間は新旧どちらのサーバに見に来ても同じ動作になるように設定をします。

2011/7/19現在　digコマンドで調べたネームサーバのTTL（キャッシュ期間）
.com/.net : 2日
.org/.info/co.jp/or.jp/.me/.nu/.to : 1日
.biz : 2時間

まあ、普通のホストのレコードの変更や追加などとは違って、通常は切り替えることはほとんど実施しないので、発生頻度からすると変では無い事なのですが、この状態の中いきなり切り替えを勧めてくる（しかも、移行に必要なOffice365側の設定値はネームサーバを変えろという指示をキャンセルしてからでないと表示されない）Microsoftは凄いなぁ、と思いますけど。

また、ドメインを追加した直後は⑨Exchangeや⑩アンチスパム（FOPE）のドメインの追加処理が完了していない（最大1～2日程度かかるらしい）事があったり、ユーザのメールボックスの作成が完了してないことが考えられるので、先に準備やできる限りで試験を実施しておきましょう。

そして、ようやくネームサーバ切り替えの一歩手前という事で、旧サーバの方にも新サーバの設定を入れます。ちなみに、これによりMXレコードの切り替わりが発生しますので、この時点からメールはOffice365に届くようになります。設定はDNSマネージャーで表示できますので、それを入れます。ちなみに、Exchangeで必要なのが上3つ（最低限MXレコードだけは必要）、Lyncで必要なのが下2つ（どちらとも無くても手動でセットアップ可能）になります。

⑪今回は、お名前.comで新規に取ったドメインという前提なので、既存のドメイン情報にレコードを追加したいと思います。ただし、SRVレコードは作成が出来ない為、Exchange用のMX、CNAME、TXTレコードのみ追加します。確認が終わったら変更するボタンを押します。
　

さて、これでようやくネームサーバーを（ある程度）安全に切り替えることが出来そうです。さすがに私はこれをすっ飛ばしてとりあえず「ネームサーバー切り替えて下さい」と言える勇気はさすがに無いです。⑫ネームサーバ変更から、既存で設定されているサーバを削除してns1.bdm.microsoftonline.com、ns2.bdm.microsoftonline.comを設定します。担当者の名前や電話番号を入れる部分はGMOはwhois代行サービスもやっているので、適当に既存で設定されているGMOの値を入れます。
　

これで設定終了です。簡単にまとめると以下のような感じですかね。

①管理メニューから追加するドメイン名を入力し、認証に必要なTXTレコードを取得する。
②別ウィンドウでDNSホスティングサービス等のメニューに接続するなどして、①で取得したレコードを確認する。
③②で設定したTXTレコードや必要に応じて変更したNSレコードの変更が新規検索をした際に反映されている事を確認する。
④①の画面に戻り、認証を行う
⑤ネームサーバを切り替える指示が来るが、キャンセルする
⑥DNSマネージャーを開き、Office365利用に必要なDNSの情報を取得する
⑦DNSマネージャーから、既存のDNSサーバに設定されているレコードの情報をOffice365のDNSにも追加する
⑧既存DNSサーバのMXレコードのTTLを300秒等の小さい値に変えておく（メールの切り替えを実施する場合のみ）
⑨Exchange Onlineで各ユーザのメールボックスを作成する
⑩FOPE経由で追加するドメイン宛のメールが着信出来るかtelnetコマンドなどでSMTPコマンドを叩いてチェックする
⑪既存DNSサーバにOffice365利用に必要な情報を追加し、MXレコードをxxx.mail.eo.outlook.comに切り替える
⑫ドメインのレジストラから、ネームサーバをns1.bdm.microsoftonline.com、ns2.bdm.microsoftonline.comに変更する

また、参考までに軽く触った限りのプランPのドメイン周りの制約事項ですが、以下の感じです。これでも問題ないという事であれば、無料で使えるリソースですし、活用されるのも良いかもしれません。

  1. 追加できるレコードの種類はAレコードかCNAMEレコードのみ
  2. TTLは最短で1時間
  3. Office365で利用するドメインとしてサブドメインは登録自体が不可
  4. DNSサーバはMicrosoftが用意すると言っている割には最初の登録の際にユーザが設定可能なDNSサーバまたは他のDNSサービスが必要。

監査環境下でのExchange Onlineの退職者の処理

Posted on by • Posted in Exchange Online, シングルサインオンとディレクトリ同期 • Tagged • Leave a comment

Exchangeのプラン2では、長期間に渡るメールの監査・アーカイブへの対応を実施することが可能となっております。これは、「各ユーザのメールボックスの無制限のアーカイブ＋削除/変更したアイテムの保全＋監査ログ」という要素によって構成されており、情報の分散管理（各ユーザーのメールボックス）とその横断検索がキーとなっています。

ここで1点問題になってくるのが、退職者に関する処理です。ディレクトリ同期下において、退職したからと言ってローカルのAD上でアカウントを削除してしまうと、削除した情報がそのままクラウド側に同期され、ユーザが削除され、メールボックスが一定期間（30日）後にサーバ上から削除されます。

こうしてしまうと、退職前に何か仕掛けてから辞めていった人に対しての、さかのぼっての監査が実施できなくなってしまいます。とはいえ、永久的にメールボックスを残すということは、辞めた人の分も合わせてID単位の課金を続けなくてはいけなくなり、どんどん必要なサブスクリプションを追加していかなくてはならず、非現実的です。

退職者の情報は、ネットワーク管理者が必要な分のみ.PSTファイルに落として一定期間ローカル保存しておくという運用が一般的ですが、横断検索が出来なく無くなるなどの不便が生じますので、一定期間Office365にアカウントを残すという運用を考えます。

  1. 当該ユーザーのログオンを不可にする
  2. 当該ユーザーへのメールの配送を止める
  3. 配布グループから抜いたり、グローバルアドレス一覧の非表示化などの後処理

などが考えられますが、1.に関してはローカルのADでアカウントを無効化すれば、Office365へのアクセスも不可になります。（サブスクリプションは解放されないですし、普通にメールも配送され続けますが）

2.はExchange Online側のアクセス権で普段はメールを送ることが無い管理用アカウントなどだけからのメールを受け取るようにSet-Mailboxコマンドレットで-AcceptMessagesOnlyFromを指定しておくのが楽だと思います。PowerShellからの設定になりますので、Exchange Onlineに接続してから実行します。

3.については、Office365のExchange Onlineサービス説明によりますと、

管理者は、社内の Active Directory でオブジェクトに HideInAddressList 属性を設定して (ディレクトリ同期ツールを使用している場合)、またはリモートPowerShell を使用して、ユーザー、配布グループ、および連絡先をグローバル アドレス一覧で非表示にすることができます。

とあるので、2.でSet-Mailboxコマンドを実行するついでに実施してしまおうと思います。

おろ、ディレクトリ同期環境下ではローカルのみですか…困りましたねぇ。そう、勘の良い人ならお気づきだと思いますが、GALの表示を制御するmsExchHideFromAddressLists属性は、Exchangeをインストールする際のスキーマ拡張で実装される物で、オンプレミスでExchangeがないユーザの環境では設定自体ができません。もちろん、マニュアルに誤記されているHideInAddressListなんてのも有りません。

さて、考えられるのは2つ。ディレクトリ同期(ILM)をいじって、どこか使ってない属性からマッピングしてくるか、スキーマを拡張するかです。ホントは前者で行きたいですが、このmsExchHideFromAddressLists属性はBoolean（TRUEかFALSEを保持する）形式なので、対応した良さそうな物が見つかりませんでした。ということで、不本意ながらExchange2010SP1の評価版をサイトからダウンロードして、中身は使わずセットアップの準備コマンドだけを利用します。

今回はスキーマ拡張だけを行いますので、setup.com /PrepareSchemaを実行します。

完了すると、無事msExchHideFromAddressLists属性が設定できるようになります。Set-ADUserコマンドの場合、拡張属性なので以下のような感じでしょうか

Set-ADUser -replace @{msExchHideFromAddressLists=$True}



う～ん、高々アカウント削除だけの話なんですが、面倒ですね。

ジャーナルアーカイブがOffice365の中で使えればこんなこと考えなくても良いのでしょうけど。（今は他のEnterpriseVaultとかのアーカイブに飛ばして格納しないといけないので、NW帯域考えると現実的では無いですよねぇ…）

ディレクトリ同期で同期されない携帯番号

Posted on by • Posted in シングルサインオンとディレクトリ同期 • Leave a comment

Office365でディレクトリ同期を行うと、ローカルのActiveDirectoryのオブジェクトならびにその各属性がOffice365側に同期されます。情報の不整合を防ぐ為に、基本的にディレクトリ同期で転送されたオブジェクトの情報はOffice365側では編集できません。

ただ、ユーザーの管理から、よく見ると一カ所だけ編集できるところがあります。それは携帯電話の番号です。ここに番号を入れればひょっとして値を変えられるのでしょうか？

そう、ここに値を入れると、Office365側の属性が書き換わります。ただ、この情報はローカルのActiveDirectoryには反映されません（ディレクトリ同期が一方向同期なので）

また、こちらに一度でも値を入れたユーザは、ディレクトリ同期項目から携帯電話の番号が除外されます。

つまり、今後会社携帯の番号が変わったからといってローカルのADで携帯番号を入れても、それはOffice365側には伝わらず、完全に別々の物として扱われるようになります。（ディレクトリ同期ではエラーも無く更新が成功したように見えるのですが、完全に無視されます）

また、一度もOffice365側で変更されたことのないユーザーについては、他の属性同様通常通り同期されるようになります。どうしてなのかは理由が分からないのですが、途中までは携帯も編集不可項目だったように思えるので、ベータテストの途中からそういった仕様に変更されたのではないでしょうか。

最近の個人情報関係の意識の高まりもありますので、携帯電話の番号をWeb上に載せたくないという要望もあるでしょうから、ユーザーが自信の情報公開範囲を限定したいというニーズに応える為ということであれば考えられなくもないかなとは思いますが、どちらかというとActiveSyncやSMS（まだ使えないですが）とかの機能でどうしてもOffice365側でMobileの番号の編集権限がないと困る物が有るのではないかなと考えてます。

変更処理自体はユーザが勝手に出来てしまう処理なので、管理者側ではどうしようもない事かと思いますが、どうしても管理者が一元的に同期するよう制御したいのであれば、だいぶ力業になりますが、ADならびにOffice365へのPowerShell接続ができる端末から、以下のようなスクリプトを定期的に実行することにより、強制的にローカルのADの情報をOffice365に同期できるようになります。（タスクなどで自動実行にするにはCredentialを保存して自動ログインにするなどの変更が必要です）

$LiveCred = Get-Credential
Connect-MsolService -Credential $LiveCred
$ADUser = $ADUsers = $MSOLUser = $MSOLUsers = $null
$i = 0
$ADUsers = Get-ADUser -properties Mobile -filter * | Select-Object UserPrincipalName,Mobile,SamAccountName
$MSOLUsers = Get-MSOLUser | Select-Object UserPrincipalName,MobilePhone
ForEach($ADUser in $ADUsers) {
  $MSOLUser = $MSOLUsers | Where-Object {$_.UserPrincipalName -eq $ADUser.UserPrincipalName}
  if([string]::isNullOrEmpty($MSOLUser.UserPrincipalName)){
    Write-Host "Skip - Office365に作成されていません: "$ADUser.SamAccountName
  }
  elseif($ADUser.mobile -ne $MSOLUser.MobilePhone ){
    Write-Host "ADの情報でOffice365を上書きします【"$ADUser.UserPrincipalName"】"
    Write-Host " - ActiveDirectory:"$ADUser.mobile" の値でOffice365:"$MSOLUser.MobilePhone"の値を上書きます"
    Set-MsolUser -UserPrincipalName $MSOLUser.UserPrincipalName -MobilePhone $ADUser.mobile
    Write-Host " - 完了しました"
    $i++
  }
}
Write-Host "終了: 計"$i"件の携帯電話番号レコードを同期しました"
Write-Host "（何かキーを押してください）"
[console]::ReadKey()

一元的に情報を扱うというのもなかなか難しいですね。っていうかこういった仕様とか制限とか、変更するのは構わないが、できれば公開情報にして貰いたいなぁ。

こちらですが、恐らく2011.秋に実装された管理者向けパスワードのセルフリセットツールで利用するためにこう言った設定になったと推測されます。

顔写真を登録して少しでもOffice365を華やかにする

Posted on by • Posted in Office365全般, シングルサインオンとディレクトリ同期 • Leave a comment

Office365では、コミュニケーションの促進のため、それぞれのアプリケーションで各ユーザの顔写真情報を利用することができます。

登録していないデフォルトの状態だと、以下のように人型のアイコンのみ表示されていますが、これでは少し味気ないですよね。今回は、ここに顔写真を登録してみます。

Office365展開ガイドによると、アップロードには2つの方法が記載されてます。

  • エンド ユーザーが Microsoft Online Services ポータルの [ユーザー設定] 画面を使用して、自分の写真を手動でアップロードできます。
  • 管理者は、社内の Active Directory で ThumbnailPhoto ユーザー属性を指定できます。その結果、ディレクトリ同期ツールによって、自動的に、ユーザーの写真が Exchange Online、SharePoint Online、および Lync Online と同期されるようになります。

社員証などの写真を総務から貰って画一的に登録するのもいいですが、別人のようになっている人もいますよね。公開範囲が社内だけとはいえ、そもそも公開するしないか、どんな写真をアップするかまで各ユーザーに任せられるのが一番なので、ユーザーポータルからやってみましょう。

…ってあれ？　ディレクトリ同期を利用しているユーザは、パスワードの変更に加えて写真の変更のリンクも無いですね。どうやらローカルのADから同期する方法しかなさそうです。（クラウドIDを利用しているアカウントは以下のようにリンクが出ます）

やり方自体はExchange 2010などと同じで、ローカルのActive DirectoryのThumbnailPhotoにJPEGファイルを入れればいいですが、Binary属性で入れなければならないのでいざ1からやろうとすると結構面倒です。

ということで、今回はブチザッキ様が作成された素晴らしいアプリを利用します。こちらはログインしているユーザーが自身のADのThumbnailPhoto属性をGUIで変更できる物です。実行には.net Framaworkの4が必要になるようなので、早速インストールして利用してみます。

起動すると顔写真が登録されていない旨のメッセージが出ます。ファイルメニューからJPGファイルを選択すると、No Imageだった顔写真が更新されますので、編集メニューの【顔写真を更新】を選択してADに情報を登録します。

登録された情報をディレクトリ同期で即時同期を実施してOffice365に更新させます。念のためILMを起動して確認したところ、以下の通り無事にThumbnailPhotoがBINARYデータで更新されています。

しばらくすると、ポータルのプロフィールの画面が更新され、LyncやExchangeのプレゼンスの横の顔写真が無事更新されました。（Outlookの下の写真は、グローバルアドレス帳から連絡先フォルダに追加したら表示されるようになりました。）


SharePoint Onlineの顔写真だけは、少し時間がたっても更新されなかったので、もう少し様子を見てみようと思います。

Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトする

Posted on by • Posted in Exchange Online, シングルサインオンとディレクトリ同期 • Tagged , • Leave a comment

リクエストを頂いたので、Office365ポータルではなくExchange Online(OWA)もやってみます。

OWAのリダイレクトを設定すると、Office365に移行済みのユーザがオンプレミスのOWAにアクセスした際に、Office365側にリダイレクトをかけることができます。ただ、普通にhttps://outlook.com/owa/example.comなどにリダイレクトをかけても、

って感じで悲しくもサインイン画面に飛んでしまいます。

というわけで、前回同様サインインのURLを適当に解析してみて、一個一個省略可否を探って行きます。

2番煎じでつまらないですが、以下のURLでOWAにSSOできるようになります。

https://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26wreply%3Dhttps:%252F%252Foutlook.com%252Fowa%252F%253Fexsvurl%253D1

これをSet-OrganizationRelationshipで設定してあげれば上手くリダイレクトされる環境が作れそうです。

Office365にAD FSを利用して何とかシングルサインオンしてみる

Posted on by • Posted in Office365全般, シングルサインオンとディレクトリ同期 • Tagged , • Leave a comment

Office365は、ADFSを利用すると、シングルサインオン風にログインができます。

というのも、通常はログイン画面でログオンIDを手動で入力して、出てくるリンクをクリックするという手間が発生するからです。（ログオンIDは前回入力した値が保存できるので、毎回毎回入れなくても大丈夫ですが）

最初にポータル画面にアクセスすると、まず以下のような画面になります。Microsoft Online Service IDの欄に、AD FSで設定した普段利用しているActive Directoryのログイン名（user@domain形式）を入力します。

入力が終わると下のパスワード入力欄がグレーアウトし、新たに現れる「xxxxxにサインインする」というリンクをクリックすることにより、（4回くらいのリダイレクトを経て）Office365にログインされます。

これは、Office365のログインサイトは各ユーザ共通であり、ここのフォームでパスワードも入れて入力するアドレス（クラウドID）か、パスワードはOffice365側では持っておらずAD FSサーバにリダイレクトして認証処理を行うアドレスか（フェデレーションID）が最初の時点では判断が付かないからというのが原因です。

ここの@以下の値（realm）をポータル側でチェックして、フェデレーションドメインだった場合はリンクを出す処理をしています。

リンクをクリックした後のアクセスの流れですが、かなり端折って話をすると①Office365 ⇒ ②AD FS ⇒ ③Office365の順にアクセスをすることになります。が、前の記事にも書きましたが、ここで入力したメールアドレスは②の認証では実は利用されていません。

よって、①でログインIDを入力してサインインするをクリックするという工程は、実は省略しても良いのでは？と邪推してしまいます。という訳で早速実験してみましょう。「xxxxxにサインインする」のリンクをクリックして飛ぶurlを取得します。

https://sts.example.com/adfs/ls/cbcxt=out&vv=&username=hoge@example.com&mkt=&…

どうやら、入力したユーザ名や戻り先のサイトの情報を一緒に付けて送ってきているようです。urlエンコードしているみたいですが、%2526などのように二重でurlエンコードされている物も有りそうです。

とりあえずこれをデコードしつつ整理します。その後、1つ1つ省略してアクセスできるかどうかを試してみました。

結構省略できそうです。結果的に、以下のurlに社内のポータルサイトからリンクを張ってアクセスすることにより、シングルサインオン環境が実現できました。（無理無理感は有りますが…）

https://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wreply%3Dhttps:%252F%252Fportal.microsoftonline.com

※AD FSサーバのアドレス（上記の例だとsts.example.com）がイントラネットサイトとして認識されている必要がありますので、必要に応じてIEのゾーンの設定をする必要があります。

※手元の環境だと、これを使ってログインした後にOWAを表示させると画面表示が崩れるという事象が発生することがありましたが、その場合は「Office デスクトップ アプリケーションのセットアップと構成」を実行することにより正常な状態に戻りました。

Exchange OnlineをPowerShellで操作する2（社内にばらまいた不適切なメールを削除する）

Posted on by • Posted in Exchange Online • Leave a comment

前回に引き続き、GUIでは実施できなくてPowerShellでないと実行できないのに、少しリファレンスが少なく感じた機能を紹介します。

（Exchange Onlineサービス説明より）
また、管理者は、複数の組織の複数のメールボックスに送信された不適切な電子メール メッセージを検索して削除することができます。たとえば、機密の給与情報がすべての従業員に誤って電子メールで送信された場合、管理者はユーザーのメールボックスからその電子メールを削除できます。

個人的には良い機能ですが、役員には知られたくない機能ですね。「○○君、実はさっき間違えてこんなメールを社内に送ってしまったのだが…」とか(w

クライアントがOutlookを利用している場合は、すぐに送信済みボックスを開いて、取り消しメールを送れば済むことも有りますが、OWAを利用している場合や、そもそもそんなクライアントの機能を知っているような人はこんな事にはならないという話も。

という訳で、PowerShellを利用してこれに対応してみましょう。Search For and Delete Messages from Users’ Mailboxes あたりが参考になります。

まずは該当メールを特定します。該当メールを絞り込むため、なるべく多くの条件を聞き出します。「タイトル」「だいたいの送信日時」「送信者」「送信先（To）」「Cc」「添付ファイル名」などでしょうか。

ここでは、hoge@example.comさんが7/3の朝8:00くらいに社内ALLにばらまいた、タイトル「昨日は楽しかったよ」を削除することをしたいと思います。

前提として、この作業はユーザのメールボックスの中身を検索・操作する必要があるので、通常の管理者では持っていない特権を付与する必要があります（通常の管理者アカウントだとSearch-Mailboxコマンドレット自体が利用できません）。Mailbox Import ExportとMailbox Searchの権限が必要になりますが、ビルトインの役割グループには適した物が無いので、ここでは新規に作成して、管理者のアカウントに割り当てます。

そして、権限を割り当てられたユーザでExchange OnlineにPowerShellで接続します。接続が完了したあと、まずは対象のメールのみを取り出すクエリを作ります。この辺を参照に、今回の条件を-SearchQueryの条件の中にカンマ区切りで記載します。そして、-LogOnlyオプションを付けて実行します。

注意なのですが、Sent条件で指定する日付は、MM/DD/YYYY形式のUTC時間（日本の場合は-9時間した値）ですので、今回は7月2日として検索します。

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'昨日は楽しかったよ', Sent:07/02/2011" -TargetMailbox admin -TargetFolder SearchAndDelete -LogLevel Full -LogOnly

これにより、adminさんのSearchAndDeleteフォルダに、検索結果の詳細レポートが格納されます。こちらの情報（添付されているCSVファイル）などを元に、問題ないと判断したら、-DeleteContentオプションを付けて実行します。

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'昨日は楽しかったよ', Sent:07/02/2011" -DeleteContent

間違えて他のメールを削除してしまった時の為や、後々の為？に削除するメールのコピーを念のため取っておく必要がある場合は、先ほどのコマンドに-TargetMailboxと-TargetFolderオプションを付けて実行します。

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'昨日は楽しかったよ', Sent:07/02/2011" -TargetMailbox admin -TargetFolder SearchAndDelete -DeleteContent

こうすると、検索されたメールは削除されて、メールのコピーが先ほどレポートが格納されていたフォルダ配下に、ユーザ名-実行日時（UTC）-メールボックス名-フォルダ名の階層構造として格納されます。

ちなみに、上で実施した管理アカウントへの特権割り当てやそれを利用したメールボックス操作などは、当然ながら全て監査ログに記録されておりますので、後で何か有ったときの防衛のため、依頼主からの正当な申請に基づいて実施した旨、しっかりとエビデンスは残しておくことをお勧めします。

Exchange OnlineをPowerShellで操作する（共有メールボックス）

Posted on by • Posted in Exchange Online • Leave a comment

Office 365のExchange Onlineは、Exchange 2010同様PowerShellで各種操作が可能です。Exchange管理コンソール(EMC)が提供されていない分、細かい操作をしようとするとPowerShellでの操作が必須となります。

Exchange Onlineサービスの詳細などにも、「リモートPowerShellを利用して、～が可能です」という記載を多く見かけます。コマンド例などが記載していない物も多いので、いくつか紹介したいと思います。

  1. 複数人から利用できるメールボックス（共有メールボックス）を作成する
  2. Fromで通常利用するメールアドレスを変更する
  3. 他のFromアドレスでメールを送る（＝送信者アクセス権（SendAs）をユーザに与える）

まず、共有メールボックスはNew-Mailboxコマンドに-Sharedオプションを付けて作成します。共有メールボックスはサブスクリプションは必要ないのですが、（ログオン不可の）ユーザオブジェクトは作成されますので、AD FS環境で作成する場合は、フェデレーションドメイン以外（xxx.onmicrosoft.comドメインなど）で作成する必要があります。

New-Mailbox -Name "共有メールボックス1" -Shared -Alias share1

次に、share1@xxx.onmicrosoft.comのアカウントのFromで利用するアドレスとして、独自ドメインのshare1@example.comを利用するように設定します。Set-Mailboxコマンドの-EmailAddressesオプションに受信するアドレス一覧を指定します（メインで利用する物のみSMTP:で、他はsmtp:で記載します）。

$NewEmailAddresses = @()
$NewEmailAddresses += ("SMTP:share1@example.com")
$Temp = Get-Mailbox -Identity "共有メールボックス1"
$NewEmailAddresses += ($Temp.EmailAddresses -replace "^SMTP" , "smtp")
Set-Mailbox -Identity "共有メールボックス1" -EmailAddresses $NewEmailAddresses

次に、この共有メールボックスへのアクセス権を設定します。その共有メールボックスを開くために必要なFullAccess権はAdd-MailboxPermission権で、その共有メールボックスのアドレスでメールを送信できる権限をAdd-RecipientPermission（※Office365の場合はAdd-ADPermission -Extendedrightsでは有りません）コマンドで付与します。

New-DistributionGroup -Name "共有メールボックス1グループ" -Alias share1g -CopyOwnerToMember -ManagedBy "testuserone" -Type Security
Set-DistributionGroup share1g -HiddenFromAddressListsEnabled $true
Add-MailboxPermission -Identity "共有メールボックス1" -User share1g -AccessRights FullAccess
Add-RecipientPermission -Identity "共有メールボックス1" -Trustee share1g -AccessRights SendAs -Confirm:$False

これで準備は完了です…が、結構このコマンドを実行した後、クラウド内のActive Directoryに権限情報が行き渡るのに時間が掛かります。（手元の環境だと1時間掛かりました。）

作成した共有メールボックスの開き方ですが、Outlookの場合はアカウント設定の[電子メール][変更][詳細設定]から詳細設定タブの[メールボックス][追加]から作成した共有メールボックスを指定すると、自分のアカウントの下に追加されます。共有メールボックス宛に来たメールに返信すると、自動的にFromアドレスも共有メールボックスになります。

つぎに、OWAの場合ですが、まずアカウントごと開く場合は右上の自分のアカウント名のプルダウンメニューから[他のメールボックスを開く]で共有メールボックスを指定する方法があります。

この場合、その共有メールボックスのアカウントとしてそのまま操作できます。メールを作成する場合は自動的に共有メールボックスがFromアドレスとして設定されます。

また、メールボックスのカウント名を右クリックし、[他のユーザーの受信トレイを開く]から共有メールボックスを指定すると、自分のメールボックスと並べて共有メールボックスを開くことができます。ただし、Fromアドレスを共有メールボックスのアドレスでメールを作成する場合、Fromアドレスを毎回手動で指定してから送信する必要があります。

開く必要のあるフォルダの数や、用途（参照のみか実際に操作もするか）などに合わせて使い分けると良いと思います。

AD FS環境でログオンユーザ以外でログオン（非SSO）を行う

Posted on by • Posted in Office365全般, シングルサインオンとディレクトリ同期 • Tagged , • Leave a comment

AD FS環境だと、ポータルではログインIDを入れるのみでパスワードは入力せず、そのままイントラネットのAD FSサーバにリダイレクトされ、そこで認証されてOffice365へのアクセスが行われます。

これはこれで便利な機能なのですが、運用上、他のアカウントでOffice365へのアクセスを実施する必要が出てくる場合が有ります。例えば、外部受付用の共有アカウントでの作業や、退職者のバックアップ作業などの場合です。

testuseroneというアカウントでWindowsにログインしていて、shared-userというアカウントでOffice365に接続しようとするシチュエーションを考えます。まず、ポータルで、普通にログインをしようとしてみます。

あれ…testuseroneのアカウントのままログオンされてしまいました。

どうやら、AD FS側ではOffice365ポータルで入力したユーザアカウントの値は特に検証せず、Active Directoryにログオン出来るかどうかのみを判断してOffice365側にチケットを発行しているようです。

普通に解決しようとするなら、AD FSのクレーム発行ルールを変更して…ということになるのだとは思うのですが、まだ勉強不足なので、今回は他のやり方を考えてみます。

  • まず、FirefoxでのOffice365へのシングルサインオン で紹介したとおり、Firefoxはデフォルトではログイン情報をWebサイトに飛ばしませんので、共用アカウントでのログオンにはFirefoxを利用してID/PASS入力で入る。
  • または、IEもゾーンが「イントラネットサイト」に無い限りログイン情報を飛ばさないので、これを起動前に明示的に他「例：信頼済みサイト」に変更してあげて、終了後必要に応じて戻す
Option Explicit
Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
WSHShell.RegWrite "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsexample.comstshttps", 2, "REG_DWORD"

これで、一応ID/PASSの入力画面がポップアップしてきて、指定のアカウントでログインができるようになります。

う～ん、でもあまり美しくない。上手いやり方は無いものだろうか…