PowerShellでOffice365の日次管理タスクを実行する

※この投稿は PowerShell Advent Calender に参加しています。

Office 365は、ポータルとExchange OnlineについてPowerShellで接続して操作を行なうことができます。

今回は、スクリプトを利用してOffice365の管理者が定期的に実行する作業を自動化して、朝コーヒー飲む時間分くらいは節約できるようにしてみたいと思います。

まずは、タスクから自動で実行して接続するために、認証情報をファイルに保存します。
(以下、admin@example.onmicrosoft.com を管理者アカウントとして想定)

$LiveCred = Get-Credential
$LiveCred.Password | ConvertFrom-SecureString | Set-Content $Env:Windiradmin_example.pass

今回はテスト用にWin直下に放り込んでますが、常用する際はちゃんとアクセス権を設定して保護して下さい(一応暗号化はされてますが)。

まずは、パスワードファイルからパスワードを読み込み、Office365管理ポータルとExchange Onlineに接続します。普段の作業用には、ここまでのショートカット作っておくと楽です。

Import-Module MSOnline
$password = Get-Content $Env:Windiradmin_example.pass | ConvertTo-SecureString
$LiveCred = New-Object System.Management.Automation.PSCredential "admin@example.onmicrosoft.com",$password
Connect-MsolService -Credential $LiveCred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

まずはOffice365管理ポータルから、サブスクリプションの利用状況を取得します。作成すべきアウトプットによって出力先は変えればいいかと思いますが、まずはcsvファイルに日付付きで出力してみようと思います。

Get-MsolAccountSku | select @{name="名前";exp={$_.SkuPartNumber `
 -replace "DESKLESSPACK","Office365 プランK1" `
 -replace "DESKLESSWOFFPACK","Office365 プランK2" `
 -replace "LITEPACK","Office365 プランP1" `
 -replace "STANDARDPACK","Office365 プランE1" `
 -replace "STANDARDWOFFPACK","Office365 プランE2" `
 -replace "ENTERPRISEPACK","Office365 プランE3" `
 -replace "ENTERPRISEWITHSCAL","Office365 プランE4" `
 -replace "EXCHANGEENTERPRISE","Exchange プラン2" `
 -replace "EXCHANGEDESKLESS","Exchange KIOSK" `
}},`
@{name="有効";exp={$_.activeUnits}},`
@{name="期限切れ";exp={$_.SuspendedUnits}},`
@{name="割り当て済み";exp={$_.ConsumedUnits}} `
| Export-Csv -Encoding UTF8 -NoTypeInformation $env:tmpo365_subscription_$(Get-Date -Format "yyyyMMdd").csv

SkuPartNumberにそれぞれプランに対応する文字列が入っているのですが、ちょっとまだ判明していないプランが有るので分かる範囲で。

続いては、Exchange Onlineに接続してメールボックスの利用状況を見てみたいと思います。オンラインヘルプの Windows PowerShell を使用してメールボックス サイズとメールボックス クォータを表示する 辺りに詳しいサンプルがありますので、こちらを参考にします。(ただ、私の環境だとサイズの計算のところで上手く値の変換とかしてくれなくて動かなかったので、サンプルは末尾のように一部変更する必要がありました。)

まず、後からExcelで加工できるように、一度csvファイルに出力します。

Get-Mailbox -ResultSize Unlimited `
| ? {$_.RecipientTypeDetails -eq "UserMailbox"} `
| Get-MailboxStatistics `
| Export-Csv -Encoding UTF8 -NoTypeInformation $env:tmpo365_mailboxstat_$(Get-Date -Format "yyyyMMdd").csv

本当はこの時点でsortとかできると良いのですが、Office365で出力した物が、Exchange2010とかと違ってToMBとかの変換が利かないようなので、文字列を数値に変換してからソートしてます。

Import-CSV $env:tmpo365_mailboxstat_$(Get-Date -Format "yyyyMMdd").csv `
| select DisplayName,ItemCount,@{name="MailboxSize";exp={$_.TotalItemSize.Split("(")[1].Split(")")[0].Split(" ")[0].Replace(",","")}} `
| sort {[int] $_.MailboxSize} -descending `
| select DisplayName,@{name="Alias";exp={(Get-Mailbox $_.DisplayName).Alias}},@{name="Mail";exp={(Get-Mailbox $_.DisplayName).PrimarySmtpAddress}},ItemCount,MailboxSize `
| Export-Csv -Encoding UTF8 -NoTypeInformation $env:tmpo365_mailusage_$(Get-Date -Format "yyyyMMdd").csv

とりあえず、こんな感じの物を office365_daily.ps1 として保存しておきます。そして、これをタスクスケジューラーに登録します。「ユーザーがログオンしているかどうかにかかわらず実行する」「最上位の特権で実行する」を選択します。

操作では、直接ps1ファイルを指定するとメモ帳がバックグラウンドで立ち上がって終わりという悲しい事態になるので、プログラム「C:WindowsSystem32WindowsPowerShellv1.0powershell.exe」引数の追加「-Command <先ほど作成したps1ファイル>」

で、トリガーで「毎日4:02に起動」とか設定しておくと、デイリーのレポートを自動的に生成してくれます。

本当はWebページに接続して、ポータルからメンテナンス予定や故障発生レポート、FOPEから前日のトラフィックレポートなどを自動取得したり、結果をメールで送信したりするのも作りたかったのですが、認証系が少し面倒そうなので今回は軽めの所からやってみました。

【参考】オンラインヘルプのサンプルの要修正場所

すべてのメールボックスのサイズとクォータの状態を表示する

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName,StorageLimitStatus,@{name="TotalItemSize (MB)";expression={[math]::Round(($_.TotalItemSize.Value.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}},@{name="TotalDeletedItemSize (MB)";expression={[math]::Round(($_.TotalDeletedItemSize.Value.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}},ItemCount,DeletedItemCount | Sort "TotalItemSize (MB)" -Descending | Export-CSV "C:My DocumentsAll Mailboxes.csv" -NoTypeInformation

メールボックス クォータを超過したメールボックスのみを表示する

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | where {$_.StorageLimitStatus.ToString() -ne "BelowLimit"} | Select DisplayName,StorageLimitStatus,@{name="TotalItemSize (MB)";expression={[math]::Round(($_.TotalItemSize.Value.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}},@{name="TotalDeletedItemSize (MB)";expression={[math]::Round(($_.TotalDeletedItemSize.Value.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}},ItemCount,DeletedItemCount | Sort "TotalItemSize (MB)" -Descending | Export-CSV "C:My DocumentsExceeded Quotas.csv" -NoTypeInformation

【動画】 Office365にAD FSでシングルサインオンする

「Office365はIDを入力する必要があるからシングルサインでは無いって聞いたけど、どうなの?」という話をたまに聞くので、意外とAD FSの環境を実際に触って動きを見た人って少ないのかなと思い、適当にキャプってみました。

ブラウザアクセス(Office365ポータル、Outlook Web Access、SharePoint Online)

少し画質が粗いので、まだ少しましなFacebook動画の方も載せておきます

ADFSサーバのIEのゾーンの設定は自動認識される場合が多いですが、環境によって(例えば、example.localがAD名だった場合で、ユーザアカウントにはexample.comのUPN名を割り当てている場合)イントラネットゾーンとして認識されない場合、プロンプトが表示されてしまいシングルサインオンできませんので、https://sts.example.comなど、明示的に指定することをお勧めします。

また、*.outlook.comなどは無くてもログインはできるのですが、ログアウトの処理が実施できない(サインアウトを押しても元の画面に戻ってきてしまうなど)などの不具合がでることがありますので、「このゾーンには全てサーバの確認(https:)を必要とする」のチェックボックスを外した上でhttp、httpsともに設定できるようプロトコル指定無しで記載します。

 

メーラー(Outlook、Thunderbird:IMAP)

Facebook動画

Lyncクライアント

Facebook動画

Office365の接続確認ツール(RCA)

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)

(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サービスが必要。

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

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の顔写真だけは、少し時間がたっても更新されなかったので、もう少し様子を見てみようと思います。

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

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 デスクトップ アプリケーションのセットアップと構成」を実行することにより正常な状態に戻りました。

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

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の入力画面がポップアップしてきて、指定のアカウントでログインができるようになります。

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

Chrome on Win7のSSOをAD FS側の設定で実現する

FirefoxでのOffice365へのシングルサインオンの記事では、各クライアントサイドのセキュリティ設定の緩和によって、シングルサインオンの機能を実現しました。ただ、この手法は全クライアントにレジストリの変更を強いることになるので、あまりスマートな実装ではございません。

今回、サーバサイドの設定変更でシングルサインオンが出来ないか試してみたいと思います。

Continue reading

FirefoxでのOffice365へのシングルサインオン

 Office365の リリースノート にも記載がありますが、Windows7もしくは「認証に対する保護の強化」をインストールしたXP,Vistaにおいて、FirefoxやChromeでAD FS環境でのシングルサインオンを実施しようとするには少し設定変更が必要になります。(7/2追記修正)

試しにアクセスをしようとしてみると、

Continue reading

Office365 beta版との相違1

Office 365が商用リリースされましたね。6/29現在、日本語版の提供はまだですが、英語版の方はサービス詳細が提示されました。

Office 365 for Enterprise Service Descriptions

とりあえず軽く流し見した中で、サービス仕様の変更が有ったところを簡単に表記しますと、

Continue reading