ARRからのアクセスでSchannel 36871

Forefront TMGがサポート切れとなり、Microsoftが提供しているIISモジュールであるARR(Application Request Routing)を利用してExchange ServerのOWAやActiveSyncなどをインターネットに公開されている方も多いかと思います。

ある特定の環境下でARRを利用していると、ある時からARR上にSchannel 36871(内部エラー:10013)が記録され続け、そのままアクセスできない状態が続くことがあります。
20160501_02

10013のエラーコード自体は、サーバ側から返された利用可能な暗号化スイートの一覧にクライアント側で対応した物が無いという物なのですが、Schannelの設定はARRのクライアント側もExchangeのCASのサーバ側も同じに設定していますし、そもそも通常時は利用できているのでそういったことは無いのではと推測しました。

色々と検証したところ、以下のような事が分かって来ました。

  • 発生する環境は、SSL3.0を無効化した環境
  • 発生するタイミングは接続先のCASが起動してきたタイミング
  • ヘルスチェックを有効化している環境もしくは、アクセスが多いタイミングで発生する可能性が高い
  • 一度発生すると出続ける

以上のことから、Exchange Server側でIISが立ち上がりきる前にARRからアクセスし、TCPセッションの確立自体は成功したものの、その後のSSL通信の確立に失敗した為に発生。かつARRは都度セッションを張るのでは無く、一度張ったセッションを再利用し続ける仕様の為に発生している可能性が高いと思われます。

こちらを解消するためには、ARR側のOSを再起動しても勿論直りますが、一番簡単なのはARRのアプリケーションプールをリサイクルすることにより、完全に立ち上がったCASに対してセッションを張り直して貰うことです。

あとは、これを自動的に事象発生時に実行して貰うように、以下の様なスクリプトを作成してタスクスケジューラでイベントログをトリガーにして起動すれば自動的に復旧してくれます。
20160501_03

Import-Module WebAdministration
$SysDate = Get-Date -Format "yyyy/MM/dd HH:mm:ss"
$HostName = hostname

"$SysDate $HostName ARR Recovery Script Start" | Out-File C:\scripts\recovery_arr\recovery_arr.log -encoding default -append
$site = "Default Web Site"
$pool = (Get-Item "IIS:\Sites\$site"| Select-Object applicationPool).applicationPool
Restart-WebAppPool $pool
sleep 300

$SysDate=Get-Date -Format "yyyy/MM/dd HH:mm:ss"
"$SysDate $HostName ARR Recovery Script End" | Out-File C:\scripts\recovery_arr\recovery_arr.log -encoding default -append

このイベントログは発生すると大量に出続けるので、同時起動を無しに設定し、スクリプト中で5分間のwaitを入れていますが、この値は環境により調整して下さい。WebアプリケーションプールはDefault Web Siteのみの想定です。別の発生要因により直らなかった場合はアラートを出すなどの処理を加えても良いかもしれません。

DirSync、AADSyncのサポート切れ

Office 365とオンプレミスのActive Directoryを同期させるツールは標準で「ディレクトリ同期(DirSync)」「Azure AD Sync(AADSync)」「Azure AD Connect(AADConnect)」の3つの種類があります。

予てよりAADConnectに統合する旨の情報は流れておりましたが、遂に今朝、古い同期ツールを利用しているユーザーに対して以下のようなメールが届きました。

20160414_01

利用の継続のためには、2017年4月13日まで(通知から1年)にAADConnectにアップグレードしろということです。

幸い、32bit版のサポート切れに伴う64bit版への移行の際と違い、Server OSの要件が変わらないのと、ディレクトリ同期ツール自体が3時間に1度しか同期せず、比較的サービス断を伴う作業がしやすいので、そこまで障壁は高くないですね。

公開情報は以下にありますが、こちらでも何か注意点など見つかったら報告します。

Azure AD Connect: Windows Azure Active Directory 同期 (DirSync) のアップグレード

Exchange 2013 CU12の管理シェルの変更点

先日の投稿の続編です。

Exchange Server 2013 CU11から、Exchange管理シェルの接続先が自身のメールボックスのサーバに変更になった旨告知がありました。

その後ですが、CU12の公開に合わせて以下のような告知がありました。

Exchange 2013 CU12 および Exchange 2016 でのリモート PowerShell のプロキシ転送時の処理

しかし、CU11 に実装された変更により、オンプレミス環境のリモート PowerShell では予想外の問題が複数発生しました。これらの問題について詳細にコードを見直した結果、CU11 に実装された変更を取り消し、Exchange 2013 CU12 のリリース時に従来のサーバー バージョンによるルーティングを使用するように戻すことになりました。

Oh, 色々とスクリプトを修正していたのですが…。

まあ、Microsoft側も速い判断で良かったと思います。ということで、CU12以降を入れれば元通りということになりました。

 

Exchange 2013 CU11の管理シェルの変更点

昨年末ごろから、Exchange 2013の管理系の自作スクリプトが失敗する様になったという話を色々な所で耳にするようになりました。

Exchange Server 2013のコンソールからExchange管理シェルのプログラムを起動すると、黄色い字で「○○○(サーバ名)に接続しています/接続しました」と表示されます。

ただ、実際には別のサーバに接続しているケースがあります。例えば、下のスクリーンショットではmbxcas02ではなくmbxcas01に接続していることが、Get-ExchangeCertificateコマンドレットの実行結果からお分かり頂けると思います。
20160411_01

これは、Exchange Server 2013のCU 11から実装されたExchange管理シェル(EMS)の仕様変更に依るものです。

Exchange 管理シェルとメールボックスのアンカー設定

簡単に説明すると、今まではExchange管理シェルは接続した先のサーバにそのまま接続されていましたが、Exchange 2013 CU11からはCAS(クライアントアクセスサーバ)に接続した場合自分のメールボックスの存在するメールボックスサーバ(メールボックスを持たないアカウントの場合は調停メールボックスの存在するサーバ)に接続するようになりました。
20160411_02

なので、ローカルサーバへのオペレーションだと思って実行しているコマンドは違うサーバに対して実行されてしまうことがあります。接続先のサーバが異なるADサイトに存在をしている場合、AD情報の同期タイミングも考慮しなければいけません。

なお、CASの役割がインストールされていないサーバ(メールボックスのみやエッジトランスポートサーバ)の場合は影響ありません。

基本的な対処策としては、例えば Get-ExchangeCertificate であればGet-ExchangeCertificate -Server (hostname)などとして、明示的に実行先のサーバを指定するようにするという形になります。

いままで通りでやりたい場合は、PowerShellを管理者権限で立ち上げたあと、

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

と実行すれば今までと同じ感覚で利用できますので、私なんかは.ps1スクリプトにしてデスクトップに置いておいてます。

Office 365とIPv6

この投稿はOffice 365 Advent Calendar 2015に参加しています。

2011年4月にAPNICのIPv4アドレス在庫が枯渇し、今年の9月には遂にARINでもIPv4アドレスが枯渇し、IPv6への移行がいよいよ喫緊の課題となってきました。

特に、サービスを提供するServer側においては従来提供しているIPv4の他、IPv6にも対応したIPv4/v6デュアルスタックでのサービス提供が求められております。
Microsoftにおいても様々な分野でIPv6対応を進めており、以前の投稿で紹介した通り、Office365もIPv6での提供が進んでいます。

今回は、Office365側でIPv6化が進んでいく中で、接続ができない、接続が遅いなど、いくつかトラブルになる事例などがありますので紹介します。

日本リージョン開設に伴い、Exchange Onlineの接続先である outlook.office365.com のDNS解決は日本エリアでは、以下の様にAPACに収容されていた際に比べて数が多く、IPv6が9個、IPv4が9個返ってきます(執筆時)
20151205_01

Windowsをはじめ、多くのOSではIPv4よりIPv6の利用の方が優先的に利用されるように設計されています。
しかしながら、特に企業ネットワークなどではIPv6での通信が十分にサポートされていない設計のまま、IPv6意図せず有効化されているといるケースもあります。

この場合、IPv6の接続が失敗した後にIPv4での接続を試みるために、Office365への最初の接続が遅くなったように見えます。回避をするためには、IPv6の優先度をIPv4より下げる(こちらが推奨されている)もしくはIPv6を無効化するという形になります。

また、Proxyとして以前のバージョンのsquidをそのまま利用している環境では、DNSラウンドロビンで複数返ってきたIPからいくつまで接続を試みるかという forward_max_tries というパラメータがデフォルトで10の状態なので、IPv6で既に9個使ってしまっていて残り1の状態です。現在はまだそのラスト1回で接続できればOKなのですが、将来的に増設された場合は完全にIPv6のみで試行が終わってしまうことになります。

こちらのケースでは、IPv6の優先度を下げるか、もしくは forward_max_tries を25など、outlook.office.comのDNSの名前解決で返ってくる数よりある程度多く設定することにより回避可能です。

 

Office 365のIPv6のサポート状況は、以下のページで随時最新情報が提供されますので、定期的にチェックされることをお勧め致します。

(現時点のトピックとしては、Exchange OnlineはデフォルトでIPv4/v6のデュアルスタック、SharePoint OnlineとSkype for Business OnlineではMicrosoftでのリクエストベースでの有効化となっているという位でしょうか。)

Office 365 サービスでの IPv6 サポート

Exchange 2010でドメインコントローラに接続できない

Exchange Server 2010で、ある日突然CASやメールボックスサーバがMSExchange ADAccessの2130,2102,2103など、いずれもドメインコントローラに接続できない旨のエラーが出てサービスが利用できなくなる事があります。
20151028_05

事象自体はOS再起動をすると治るのですが、たまに発生する割には、出る環境と出ない環境が決まっていて変だなと思って調査をしたのでそのメモを。

まず、この事象に陥ってもRDPでサーバに接続できます。でも、なぜかドメインコントローラに接続ができない、詳しく言うと、ドメインコントローラの名前解決のDNSに失敗します。nslookupでDNSサーバに接続しようとしても接続できません。
20151028_06

もっと調べると、この状態ですがTCPやICMPの通信には影響を及ぼさない(なのでRDP接続はできる)のですが、UDPでのみ通信ができないという状態だということが分かりました。

ここで、セッションの状態を見てみようとnetstat -anoを打ってみます。20151028_08 20151028_01

と、延々と続くUDPの待ち受けポート。どうやらこいつが原因のようです。TCPの動的ポート枯渇というのは497日問題で良く聞いた話ですが、UDPにも動的ポートがあります。どうやらこれが枯渇しているようです。
20151028_04

netstatの結果より調べたプロセスを特定します。タスクマネージャーを開き、必要に応じて更に列の選択でコマンドラインを表示させます。(w3wp.exeの場合、ワーカープロセスの特定に使います)
20151028_09

こちら場合によっていくつかケースがあるのですが、多くの場合はCASはOWAかExchangeServicesのIISのワーカープロセス、メールボックス(特にパブリックフォルダを有している)の場合はRPC Client Accessが多いです。
20151028_02

サービスの再起動か、ワーカープロセスの場合はIISマネージャーから、被疑アプリケーションプールのリサイクルを実施します。
20151028_03

これでしばらく待つとMSExchange ADAccessが自動的にドメインコントローラを見つけてくれ、動作が再開します。

 

そもそもの原因なのですが、どうやら上記を初めとする一部のExchangeアプリケーションが全ドメインコントローラに接続できないタイミングで、そのアプリケーションでリークが発生。UDPの動的ポートが掴みっぱなしになり、そのポートが徐々に溜まっていき、16000超の領域を全部埋め尽くすと、今回の様な事象になるようです。

確かに、検証環境でADが1台しかなかったり、複数台有ってもメンテナンスの時などに一定時間(例えば15分)とか開けずに1台目のドメインコントローラが上がってきたタイミングですぐに2台目を再起動するなどの運用をしている環境でたまに発生していました。

特に直す気配も無さそうなので、対策としては

  1. 常時最低1台はMSExchange ADAccessからドメインコントローラに接続できているようにする
  2. UDPの動的ポートの数を増やす
  3. UDPのポート数を監視(1万くらいになったら対象プロセスを再起動)

とかになりますね。

MVPの受賞分野が変わりました

2015.10に、MVPの制度が一部変更になり、受賞分野が再編されました。

今までは、主に各プロダクトをキーとした専門分野(エクスパタイズ)という単位で設定されていた物が、より大きな括りでカテゴリーとして再編されました。

これに伴い、Office 365分野で受賞していた私も自動的にOffice Servers and Servicesというカテゴリーでの受賞となりました。

これからは、Office 365だけではなくオンプレミスの製品についてもより多く情報を伝えて行けるように頑張っていきたいと思います。

Microsoft MVPアワード再受賞しました

Microsoft MVPアワードをOffice 365の技術分野において再受賞しました。

(MVPアワードについて知りたい方はこちら

MVP_Logo_Horizontal_Secondary_Blue286_RGB_300ppi

初受賞が2012年になりますので、4年連続で頂いた形となります。これも、Office 365勉強会に来てくれた参加者の方や本blogを読んで頂いた皆さま、Office 365コミュニティで情報交流をさせて頂いている皆さまのおかげだと感謝しております。

日本DCも開設され、Windows 10やOffice 2016、ExchangeやSharePointの新バージョンや周辺のオンラインサービスの拡充など、Office 365にとって更に重要な年になってくると思いますが、これからのOffice 365の普及やUsageなどの向上のお役に立てればと思います。

AD FS 3.0におけるスイッチオーバー

複数台のAD FSにおいて冗長化を行う場合、AD FSファームを構成して冗長化を行います。

今回は、運用中においてサーバの障害やメンテナンスなどでAD FSファームのスイッチオーバーが必要になる際の手順などについて書きたいと思います。

まずは、おさらいとしてAD FSファームについて記載します。AD FSは、1台のプライマリAD FSサーバと複数台のセカンダリAD FSから構成されるAD FSファームを構成できます。

AD FSファームを構成すると、セカンダリは自身のデータベースに対する直接の書き込み(設定変更)を禁止し、指定したプライマリサーバからその情報を同期します。デフォルトでは、300秒(5分)に1度その設定をポーリングします。20150724_01

Windows Server 2012 R2のAD FSファームは、証明書利用者信頼(Relying Party trusts)が5以下の場合は最大10台、それ以上の証明書利用者信頼の場合は最大5台のAD FSサーバでの構成がサポートされます。

Office 365のみを利用する環境であれば、「Device Registration Service」「Microsoft Office 365 Identity Platform」の2つが証明書利用者信頼として登録されることになりますので、10台で構成すれば10万を越えるような大規模な環境でも理論上は構成できることになります。(実際の環境では、DR環境にある別のデータセンタのAD FSサーバの台数も含めての台数になるので、もう少し収容ユーザー数は少なりますが)

また、構成可能なオブジェクト数は要求プロバイダー信頼と証明書利用者信頼で最大100がサポートされています。実環境としては使い切ることは無さそうですね。

さて、こんなケースを考えてみます。プライマリ AD FSのfs01が故障しました。復旧までにはかなり時間がかかる見込みです。この状態でも、ユーザーからfs02への認証要求は通常通り継続できますので問題は無いのですが、fs02はセカンダリなので設定変更などのオペレーションを実施することができません。

AD FSの設定変更を可能にするために、fs02をプライマリに昇格させようと思います。
20150724_02

fs02をプライマリに昇格させるには、fs02でPowerShellを起動して、以下のコマンドを実行します。

Set-AdfsSyncProperties -Role PrimaryComputer

前述の通り、クラスターなどとは違ってAD FSファームのプライマリやセカンダリはDBの同期のためだけに利用されている物になりますので、これだけで完了します。

続いて、fs03など更に別のセカンダリが存在している場合は、今までfs01に向けてポーリングしていた物をfs02からポーリングするように設定する必要があります。fs03などでプライマリのFQDNを指定した以下のコマンドを実行してポーリング先を変更します。

Set-AdfsSyncProperties -PrimaryComputerName fs02.contoso.com

これで、fs02へのプライマリの役割のスイッチオーバーが完了です。

さて、この状態でようやくfs01の故障対応が完了してサーバが立ち上がってきたとします。fs01の設定は以前のままになりますので、立ち上がってきた状態は以下の感じになります。
20150724_03

このままスイッチバックをすると、fs01は故障発生前の古い情報のままになってしまいますので、まずはfs02のセカンダリとして設定して情報が同期されるのを待ちます。

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName fs02.contoso.com

最後に、fs01に再度スイッチバックを行います。

<fs01>
Set-AdfsSyncProperties -Role PrimaryComputer

<fs02>
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName fs01.contoso.com

<fs03など>
Set-AdfsSyncProperties -PrimaryComputerName fs01.contoso.com

AD FSファームの仕組み(静的なDB同期)が分かってしまえば挙動については比較的単純なのでご理解頂けると思います。

AD FS 3.0におけるSSL証明書更新

Windows Server 2012 R2に搭載されているAD FS 3.0も、だいぶ導入が増えてきたように思えます。最初の方に導入された方は導入から1年経過してSSL証明書の更新などを迎えられているユーザーもいらっしゃるかと思います。

今回は、あまり公開されている情報も無く、トラブルも多く聞かれているので、AD FS 3.0のSSL証明書更新についてまとめていきたいと思います。(なお、こちら基本的には以前勉強会で実施したLT「ADFSの証明書入れ替えではまった話」をブラッシュアップした物になります)

まずは、AD FSならびにWeb Application Proxyの各サーバに新しい証明書をインポートします。Windows Server 2012 R2から、AD FSの動作にはIISは利用されなくなったので必要に応じて別の環境で作成してエクスポートした物を利用します。
20150707_01 20150707_02 20150707_03 20150707_04 20150707_05 20150707_06

基本的にはローカルコンピュータにインポートして、インポート先を自動的に証明書ストアを選択するとしておけば、MMCで確認すると[証明書(ローカルコンピュータ)]-[個人]-[証明書]に表示されると思います。
20150707_16

これで準備は完了です。

 

1.AD FS #1のSSL証明書更新(Set-AdfsSslCertificate)

AD FS#1(AD FSファームを構成しているプライマリ機をAD FS#1と便宜上表記します)において、PowerShellを起動します。

まず、新しい証明書のThumbprintを取得します。調査方法は色々ありますが、オフィシャルで案内されている証明書管理ツールからだとスペースが入ったりして面倒なので、dir(これはGet-ChileItemのエイリアスです)コマンドで表示してしまうのが一番楽です。有効期限や発行元などの情報を元に、新しい証明書を特定してThumbprintをメモ帳などにコピーします。

Get-ChildItem cert:\LocalMachine\My\ | FL

20150707_08

続いて、こちらの情報を指定してSet-AdfsSslCertificateコマンドレットを実行します。この瞬間、AD FS#1の通信は新しい証明書に切り替わりますので、テストクライアントにHostsを設定するなどして、切り替わり後の証明書に問題がないことはこのタイミングで見ておいた方が良いでしょう。

Set-AdfsSslCertificate -Thumbprint 新しい証明書のThumbprint

20150707_09

このコマンドは、主にAD FS管理ツールによって実施されない2つのことを実施しています。特に後者の方は手動でやると面倒なので、コマンド 1発で済ませられるのは便利ですね。

  • SSL証明書のバインドの変更(手動の場合netshコマンドで変更する)
  • SSL証明書の秘密鍵に対してAD FSサービスがアクセスできるよう権限設定を行う(手動の場合証明書管理ツールから変更する)

いきなり証明書を切り替えるのには若干違和感はありますが、1番の工程より先に3番の工程を実施した場合、セカンダリ側のAD FSで秘密鍵へのアクセス権限の問題でAD FSの133番のエラーが出ます。
20150707_13

2.AD FS#2以降のSSL証明書更新(Set-AdfsSslCertificate)

同様の操作を、AD FS#2(#3や#4などがある場合はそちらも)についても行います。

3.AD FS#1でAD FSのサービス通信証明書の変更(Set-AdfsCertificate -CertificateType Service-Communications)

続いて、AD FSのサービス通信証明書を変更します。従来でいうSSL証明書の入れ替えの作業の工程です。GUIから実施してもいいですが、せっかくWindows Server 2012 R2の環境なのでPowerShellから実施してみます。

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint 新しい証明書のThumbprint

20150707_10

ファーム内の各サーバでAD FSサービスを再起動するように指示がありますので、順に行います。

4.AD FS#1でAF FSサービスの再起動

最初にプライマリを実施します。

5.AD FS#2以降でAD FSサービスの再起動

続いてセカンダリ。セカンダリは5分おきにプライマリに設定変更をポーリングしてますので、念のため5分程度待ってから実施します。

これで基本的な項目は完了です。

6.全AD FSでKB2973873の再対応

Lync MobileなどからAD FS接続ができないという問題(KB2973873)のために、netshでSSL証明書のバインドを手動で修正している場合は、こちらの方はSet-AdfsSslCertificateコマンドレットでは差し替えてくれないので手動で差し替えます。
20150707_11

コマンドは最初に設定した際と同じくnetshコマンドで行いますが、上書きができないので削除~再指定を行います。AD FSのAppidは確認した限りでは固定の様ですが、エラーが出たら上記のKBをご確認いただき適宜修正下さい。

netsh
HTTP
DELETE SSLCert IPPORT=0.0.0.0:443
ADD SSLCert IPPORT=0.0.0.0:443 Certhash=新しい証明書のThumnbprint Appid={5d89a20c-beab-4389-9447-324788eb944a}

20150707_12

7.Web Application Proxy #1のSSL証明書更新(Set-WebApplicationProxySslCertificate)

続いて、WAP(旧AD FS Proxy)側に移ります。こちらもまずは各コンピュータのSSL証明書の差し替えから入ります。コマンドレット名が変わりますが基本的には同じです。

Set-WebApplicationProxySslCertificate -Thumbprint 新しい証明書のThumnbprint

20150707_14

8.Web Application Proxy #2以降のSSL証明書更新(Set-WebApplicationProxySslCertificate)

7番と同様です。

9.Web Application Proxy のアプリケーションの設定更新

Web Application Proxyで公開されているアプリケーション(通常はAD FSのみになりますが)について、外部証明書として設定されている証明書を差し替えます。Set-WebApplicationProxyApplicationに必要な引数はGUIDで入力が面倒なので、Get-WebApplicationProxyApplicationしたものをそのままパイプしてしまう方が楽ですね。

Get-WebApplicationProxyApplication | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint 新しい証明書のThumnbprint

20150707_15

10.全Web Application ProxyでKB2973873の再対応

6番と同様の工程をWAP側でも実施します。

 

という訳で、今回はAD FS 3.0のSSL証明書の入れ替えについてご紹介しました。IISが無くなった分、AD FS 2.0と比較して少し面倒ですが、手順さえ確立できれば後は作業です。

それにしても、AD FSは証明書関係は色々ありますね…、鬼門でしょうか。

関連記事: ADFS証明書の更新について (2008 R2の際の記事になります)