AAD ConnectでExchange属性が同期されない(その2)

先日の記事を投稿したところ、友人より「GUIだと手順が面倒だし、美しくない」と優しいコメントを頂きましたので、PowerShellで書き直してみました。

これだと既存のコネクタが一時的にDisableになったりしませんし、後から自分で追加したカスタムルールということが明示できるので今後のソフトウェアのアップデートなどの際に分かりやすいかもしれません。

※こちらのスクリプトはExchangeスキーマを拡張していない環境では実施しないで下さい(参照先のルールが存在しませんので)。また、マルチドメイン環境には対応していません。

# Get Connector ID
$conID = (Get-ADSyncConnector | ? {$_.Type -eq "AD"} | select -first 1).Identifier.Guid

New-ADSyncRule `
  -Name 'Custom rule from AD(Exchange)' `
  -Description 'User object with Exchange schema in Active Directory. (without mailNickname)' `
  -Direction 'Inbound' `
  -Precedence 200 `
  -SourceObjectType 'user' `
  -TargetObjectType 'person' `
  -Connector $conID `
  -LinkType 'Join' `
  -SoftDeleteExpiryInterval 0 `
  -ImmutableTag 'Custom rule from AD(Exchange)' `
  -OutVariable syncRule

# Get attribute flow mapping from existing rule "In from AD - User Exchange"
$AttributeFlowMappings = (Get-ADSyncRule | ? {$_.Name -eq "In from AD - User Exchange"}).AttributeFlowMappings
foreach ($mapping in $AttributeFlowMappings){
  Add-ADSyncAttributeFlowMapping -SynchronizationRule $syncRule[0] $mapping
}

New-Object `
  -TypeName 'Microsoft.IdentityManagement.PowerShell.ObjectModel.ScopeCondition' `
  -ArgumentList 'mailNickname','','ISNULL' `
  -OutVariable condition

Add-ADSyncScopeConditionGroup `
  -SynchronizationRule $syncRule[0] `
  -ScopeConditions @($condition[0]) `
  -OutVariable syncRule

Add-ADSyncRule -SynchronizationRule $syncRule[0]

 

DirSyncのAADConnectへのアップグレードが失敗する(その2)

前回の投稿では、古いバージョンのディレクトリ同期ツールからAAD Connectへのアップグレードの際にエラーが出ないようにする手順について紹介させて頂きました。

しかしながら、気づかずにこちらを実施せずアップグレードをしてしまうと、結構悲惨な状態になります。[問題が発生したため、統合を完了できません – Syncronization Serviceをインストールできません。詳細については、イベントログを参照して下さい。]と表示され、アップグレードが失敗します。

ログを確認すると、

[21:38:17.249] [ 12] [ERROR] PerformConfigurationPageViewModel: Caught exception while installing synchronization service.
Exception Data (Raw): System.Exception: Synchronization Service をインストールできません。詳細については、イベント ログを参照してください。 ---> System.DirectoryServices.AccountManagement.NoMatchingPrincipalException: Group 'FIMSyncAdmins' was not found.
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.AccountManagementAdapter.GetGroupBySamAccountName(String groupSamAccountName)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SynchronizationServiceSetupTask.<>c__DisplayClass9.<ValidateOrCreateSyncServiceGroups>b__8()
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ActionExecutor.Execute(Action action, String description)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SynchronizationServiceSetupTask.InstallCore(String logFilePath, String logFileSuffix)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ActionExecutor.ExecuteWithSetupResultsStatus(SetupAction action, String description, String logFileName, String logFileSuffix)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.Install()
   --- 内部例外スタック トレースの終わり ---
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.ThrowSetupTaskFailureException(String exceptionFormatString, String taskName, Exception innerException)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.Install()
   場所 Microsoft.Online.Deployment.OneADWizard.Providers.EngineSetupProvider.SetupSyncEngine(String setupFilesPath, String installationPath, String sqlServerName, String sqlInstanceName, String serviceAccountName, String serviceAccountDomain, String serviceAccountPassword, String groupAdmins, String groupBrowse, String groupOperators, String groupPasswordSet, Int32 numberOfServiceInstances, ProgressChangedEventHandler progressChanged, NetworkCredential& serviceAccountCredential, SecurityIdentifier& serviceAccountSid)
   場所 Microsoft.Online.Deployment.OneADWizard.Runtime.Stages.InstallSyncEngineStage.ExecuteInstallCore(ISyncEngineInstallContext syncEngineInstallContext, ProgressChangedEventHandler progressChangesEventHandler)
   場所 Microsoft.Online.Deployment.OneADWizard.Runtime.Stages.InstallSyncEngineStage.ExecuteInstall(ISyncEngineInstallContext syncEngineInstallContext, ProgressChangedEventHandler progressChangesEventHandler)
   場所 Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.PerformConfigurationPageViewModel.ExecuteSyncEngineInstallCore(AADConnectResult& result)

と表示されており、FIMSyncAdminsグループが存在しない為に発生したエラーだということが推測されます。

しかしながら、FIMSyncAdminsグループを作成後に[再試行]をクリックしても、[指定されたファイルが見つかりません。]というエラーが表示されて、続行できません。参照されたログファイルを見ても、続きを実施する方法は分かりません。

しかも都合の悪いことに、前のバージョンのディレクトリ同期は既にアンインストールされており、切り戻しもできません。再度インストーラーを走らせると新規インストールになってしまいます。

全てデフォルト設定で利用していた場合はそれで良いかもしれませんが、同期フィルタなどを設定していた場合はどんな設定をしただろう…?って途方に暮れてしまうこともあるかと思います。

根気強くログファイルを見ていくと、見つけました!

[21:27:25.520] [ 10] [INFO ] AnalyzeDirSyncInstallation: Backing up DirSync upgrade settings to C:\Users\syncadm\AppData\Local\AADConnect\DirSyncSettings20161214-212725.xml.

どうやら、Appdata\Local\AADConnect配下に作業ファイルとして古い設定データがxmlで保存されているようです。(syncadmはAAD Connectのインストールを実行したユーザー名ですので、皆さんの環境に合わせて読み替えて下さい)

※OUの除外設定などもきちんと残っています。

これさえ分かれば、後は並列デプロイと同じ方式で移行を継続できます。

PS C:\> cd "C:\Program Files\Microsoft Azure Active Directory Connect\"
PS C:\Program Files\Microsoft Azure Active Directory Connect> .\AzureADConnect.exe /migrate

設定ファイルをインポートする画面が出ますので、先ほどのフォルダ配下の.xmlファイルを指定します。また、[既存のサービスアカウントを使用する]のチェックボックスを外して[次へ]を選択します。
 

ここから先は通常のアップグレードと同じです。Azure ADの管理者アカウントの情報を入力し、次にオンプレミスのActive DirectoryのEnterprise Adminsのアカウント情報を入力し、最後に[インストール]を実施します。

これでインストールは完了です。インストール後の状態は、ステージングモードというエクスポートのみ行わない状態になっています。

MIISClientなどで既存のフィルタがきちんと移行されているかを確認(新しいMIISClientのパスはC:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exeです。実行には一度ログオフが必要です)した後に、ステージングモードを解除します。

Azure AD Connectを起動し、[構成][ステージングモードの構成][次へ]を選択。Azure ADの管理者情報を入力、[ステージングモードを有効にする]のチェックボックスを外して[次へ]をクリックし、最後に[構成]をクリックします。
 

これで、無事AAD Connectの環境に移行できました。

良いAADライフを!

AAD Connect更新時のSfB属性

AAD ConnectでExchange属性が同期されない の記事でオンプレミスのExchange関連のスキーマについて記載させて頂いた所、Skype for Business(Lync)関連のスキーマについてはどうなのかと質問を頂きましたので、簡単に調べた範囲で記載したいと思います。

オンプレミスのADスキーマがSkype for Business(Lync)用の拡張がされていた場合、以下の3つの同期ルールが作成されます。

・In from AD – User Lync
対象:user
以下の属性を同期する:
msRTCSIP-ApplicationOptions
msRTCSIP-DeploymentLocator
msRTCSIP-Line
msRTCSIP-OrganatorSid
msRTCSIP-OwnerUrn
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
msRTCSIP-OptionFlags

・In from AD – InetOrgPerson Lync
対象:inetOrgPerson
以下の属性を同期する:
msRTCSIP-ApplicationOptions
msRTCSIP-DeploymentLocator
msRTCSIP-Line
msRTCSIP-OwnerUrn
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
msRTCSIP-OptionFlags

・In from AD – Contact Lync
対象:contact
以下の属性を同期する:
msRTCSIP-DeploymentLocator
msRTCSIP-Line
msRTCSIP-PrimaryUserAddress
msRTCSIP-OptionFlags

20161214_01

msRTCSIP-OrganatorSid 以外の属性では、既存のディレクトリ同期ツールにおいては無条件で(存在する場合)同期されていました。

msRTCSIP-OrganatorSid については、リソースフォレストモデルでの展開の際に利用されるものですので、AAD Connectから新規で追加された同期ルールになります。

従いまして、Exchangeの様に特に同期する対象を限定するスコープなど設定されていないため、アップグレード前後で同期属性が変化することは、Skype for Business Serverをリソースフォレストモデルで展開していない限りはないと言えます。

AAD ConnectでExchange属性が同期されない

ディレクトリ同期(AAD Sync含む)を利用する環境下において、Exchange Onlineで利用されるユーザーなどの情報は全てオンプレミスのActive Directoryから同期され、管理されます。

このため、アドレス帳非表示やふりがななど、メールボックスの動作を制御する一部の属性はオンプレミス側で設定し、同期する必要があります。オンプレミスにExchange Serverが無い場合は、その設定用にスキーマ拡張のみして属性を設定するというTIPSは比較的昔から存在していました。
20161210_01

こういった環境のユーザーがAAD Connectに移行すると、アドレス帳非表示の設定が消えるなどの影響が出る可能性があり、注意が必要です。

なぜかと言いますと、AAD Connectはマルチフォレスト(特にリソースフォレストモデルのExchange環境)のサポートを行うために、デフォルトの同期ルールが以前と変わっています。

具体的には、ユーザーの属性を取得する際に、Exchange関連の属性は[mailNickname]が存在するフォレストから取得するようになっています。

従来:
Azure Active Directory に同期した属性値のリスト

AAD Connect:
Azure AD Connect Sync: 既定の構成について

MailNicknameは、Exchangeにおける[Alias]として利用されている物であり、Exchange関連のオブジェクトであれば必須のパラメータとなっています。しかし、ADSIエディタなどでアドレス帳非表示を制御するmsExchHideFromAddressListsなどの属性を加える運用を行っている場合、mailNicknameには値が入っていないというケースが多くあります。

PowerShellから、Exchange属性であるmsExchHideFromAddressListsを同期しているルールを確認すると、[In from AD – User Exchange]というルールで同期されており、そのフィルタの条件はmailNicknameがNOTNULLということが分かります。
20161210_02

Get-ADSyncRule | ? {$_.AttributeFlowMappings -like "*msExchHideFromAddressLists*" -and $_.SourceObjectType -eq "user"} |  ft Name,Identifier
(Get-ADSyncRule -Identifier [上記で表示されたID]).ScopeFilter.ScopeConditionList

同様に、ルールエディタからも確認ができます。
20161210_03 20161210_04

※このルールはExchangeのスキーマ拡張がされていない環境では作成されません。また、マルチフォレスト、マルチドメイン環境では複数作成されます。

さて、では対応するためにどうしていけばいいかですが、アプローチとしては2つあります。

  1. [In from AD – User Exchange]のデフォルトルールを変更し、mailNicknameによる条件フィルタ自体を削除する
  2. [In from AD – User Exchange]をコピーして新たなルールを作成し、条件をmailNickname = NULLにする

いずれも、全ユーザーに対してExchange関連属性を設定するという意味では同じですが、今後ソフトウェア更新をした際にデフォルト設定が変わる可能性があるリスクを考えると2番の方がメンテナンス性は良いかと個人的には考えてます。(1で実装する場合も、実際には元の設定は無効化し、コピーしたルールに手を加えます)

手順ですが、Syncroniztion Rule Editorを管理者として起動し、[In from AD – User Exchange]のEditを選択する。この際、[YES:既存のルールのコピーを作成し、オリジナルのルールを無効化する][No:既存のルールの変更を続ける]の確認が表示されるので、[はい(Y)]を選択する。
20161210_05 20161210_09

Precedenceに既存と重複せず、元のルールより低い(数値の大きい)値を設定する。(ここでは200とした。)Scoping Filterの項目を開き、プルダウンのISNOTNULLをISNULLに変更する。
20161210_06 20161210_07

もう一度[In from AD – User Exchange]の[Edit]を選択し、今度は[いいえ(N)]を選択してオリジナルのルールを開く。[Disabled]のチェックを外して保存。
20161210_08

なお、既定の構成に手を加える場合は、以下の記事を一読されることをお勧め致します。 Azure AD Connect Sync: 既定の構成を変更するためのベスト プラクティス

DirSyncのAADConnectへのアップグレードが失敗する

ディレクトリ同期ツールをAAD Connectにインプレースアップグレードする際、以下のような画面が出てアップグレードに失敗することがあります。
gw-00003 gw-00004

参照されるログファイルを確認すると、以下のエラーが記録されています。

[11:27:39.819] [ 18] [ERROR] PerformConfigurationPageViewModel: Caught exception while installing synchronization service.
Exception Data (Raw): System.Exception: Synchronization Service をインストールできません。詳細については、イベント ログを参照してください。 ---> System.DirectoryServices.AccountManagement.NoMatchingPrincipalException: Group 'FIMSyncAdmins' was not found.
 場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.AccountManagementAdapter.GetGroupBySamAccountName(String groupSamAccountName)

FIMSyncAdminsグループが見つからないというエラーです。確かに、FIMSyncAdminsグループができたのはパスワード同期が実施できるようになった辺りのバージョンなので、ローカルには存在していませんでした。
gw-00006

グループが無いのがエラーの原因と記載されていますので、単純にメンバーは空で良いのでグループを作ってみます。(説明はMIISAdminから適当にコピーしましたが、無くても問題ないです)
gw-00007

これでインストールを行ったところ、問題なく実施ができるようになります。
gw-00009

ちなみに、FIMSyncAdminsグループにはオンプレミスのADとディレクトリ情報をやり取りするアカウント AAD_<nnnnnnnnnnnn>とAAD Connectのインストールに利用したアカウントがデフォルトでメンバーとして登録されます。

また、Microsoftから提示されている標準手順のうち、並列デプロイの方式を利用してもアップグレードは可能ですので、オブジェクトの数や作業の手間などを考えて、どうアップグレードするか決めるといいと思います。

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) のアップグレード

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の際の記事になります)

 

ADFSでOneDrive for Businessのアクセス制御

Office 365の導入を検討しているユーザーから良く聞かれることの一つに、「会社のネットワークの中からだけOffice 365が利用できるようにできるか」ということがあります。

Microsoftやベンダの立場としては「AD FSで制御できます」と答えるべき所だとは思うのですが、この時点でのこの回答は正しくも有り、そして間違ってもいます。私は、そういった場合「AD FSで認証に関する制御を行う事ができますが、それで要望されていることを満たすかどうかはお客様の要件次第です」と回答しています。

これは、AD FSを利用したOffice 365へのアクセスの仕組みが、「認証」「認可」に役割が分かれていることに関係します。AD FSは「認証」を行い、Office 365(の各アプリケーション:例えばOneDrive for Business)は「認可」を行います。

AD FSでは、認証を行う時にID/PASSが合っているということの他に、条件を付けることができます。例えば、今回のケースでは「アクセス元が社内ネットワークからである」というという条件を加えることができます。これにより、インターネットからのアクセスでは「認証」されることがないので、Office 365の利用を制御できることができます。

これなら要件が満たせるのでは?ということになりますが、これは1つ観点が抜けています。Office 365では、AD FSで認可を受けてきているということは認識してますが、それがどういった条件の下で認可を受けてきたかどうかは情報として要求しておらず(アカウント名とImmutableIDというユーザーを一意に識別する特別な符号のみ)、認識しません。この為、今アクセスしてきているユーザーのアクセス元が社内ネットワークからであるかどうかは分からないのです。

具体的に言うと、一度社内ネットワーク内でAD FSで認証し、Office 365にアクセスした後に、そのままの状態(例えば、ブラウザを開いたまま)でその端末を外に持ち出した場合、アクセスが一定期間継続できてしまうのです。

これでどの程度の期間アクセスが継続できるのか(再度認証が必要になるのはどういった条件か)というのはOffice 365側で決められているので、AD FS側で制御することができません。タイトルに戻るのですが、OneDrive for Businessのスマートフォン用アプリでは、私が試した限り一度AD FSで認証をかけるとその後AD FSに認証されるというケースはほぼ無いように見えます。(常時接続するので、アイドルタイムアウトしない為ではないかと思いますが)

従来の考え方ですと、そもそも社内端末を社外に持ち出して使うこと自体認められていないので問題ないという形になったのかもしれませんが、今後BYODやスマートフォンなどからの利用が進んでいくと、端末が社内NW、社外NWと行き来したりするというケースは普通に出てきます。

こういったケースが併用される環境では、IPアドレスをベースにしたアクセス制御よりはMDM(モバイルデバイス管理)などで端末単位での認証をしていく方が現実的になっていくのかもしれませんね。

Windows Server 2012 R2のADFSを使う10(+1)の理由

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

Windows Server 2012 R2がリリースされて1年が経ちました。Windows Server 2008 R2などでAD FS環境を作られている方も多いかと思いますが、今日は、Windows Server 2012 R2のAD FS環境に乗り換えるメリットや注意点などを簡単にまとめてみたいと思います。

  1. 最新のソフトウェアバージョンであるから
    • Office 365を利用する上で、それと連携する環境はたとえServer OSであっても随時バージョンアップし、新しい物に追従していく必要があります
    • Windows Server 2008 R2のAD FSは、現在はサポート範囲には入ってますが、既に新機能は提供されておらず、次期Server OSが公開されるといずれサポート外になってしまいます
  2. デバイス認証(DRS)が利用できるから
    • 利用できるクライアント環境には制限があるものの、新機能であるWorkplace Joinを利用すると、Active Directoryに所属していないデバイスを登録し、デバイス認証によるログインを実施することができるようになります
    • デバイス認証の要否もAD FSのクレームルールとして記載できますので、より柔軟なアクセス制御が実施出来るようになります
  3. 多要素認証が利用できるから
    • AD FS自体がアドインの多要素認証を意識した設計になりました
    • 従来は、AD FSの処理の外(PhoneFactorであれば、AD FS ProxyのIISのフォーム認証の部分)で追加認証を実施してましたが、AD FSの処理の内部で利用することにより、ある条件下のみでの多要素認証の要求など、柔軟な処理が実施できるようになります
  4. AD FSサービス用のユーザーアカウントが不要だから
    • グループの管理されたサービスアカウント(gMSA)というサービス実行専用の特殊アカウントが利用できるようになりました。これにより、AD FSサービスの実行用に特別な管理者アカウントの管理は不要です
    • 管理権限を保有し、実効上パスワードの無期限化が必要、かつAD FS Proxy経由の無差別攻撃などでロックアウトし、AD FSがサービス停止する危険性など、従来の運用上のリスクから開放されます
  5. パッシブフェデレーションでも接続情報を取得できるから
    • 従来、ブラウザからのアクセス(パッシブフェデレーション)ではアクセス元のIPやクライアント種別などの情報が取得できませんでしたが、これが取得できるようになったことで、より外部アクセスに関しての細かなアクセス制御が実施できるようになりました
  6. 外部アクセスへのアカウントロックアウトの対応ができるから
    • Exchange OnlineのアクセスにAD FSを利用している場合、外部から攻撃を受けたり、パスワード変更後に設定未変更のスマートフォンなどの端末からのアクセスでオンプレミスのActive Directoryアカウントがロックアウトすることがありました
    • AD FS Proxy経由でのアクセスについてAD FSの処理でロックアウトを実施することができるようになりました。これでアタックをうけてもActive Directoryアカウントには影響を与えません
  7. リバースProxy機能を持つWAPが利用できるから
    • Windows Server 2008 R2のAD FS Proxyは、AD FSへの要求をフォワードすることしかできませんでした
    • Windows Server 2012 R2はWeb Application Proxy(WAP)として新たに構成され、AD FS以外にもより汎用的に各種社内Webアプリケーションをインターネットに公開(もちろん、AD FSを利用して認証させることもできます)できるようになりました
  8. サインイン画面がカスタマイズできるから
    • 標準機能としてサインイン画面に会社名やロゴを入れたり、問い合わせ先などのリンクを入れたりできるようになりました
  9. 内部/外部の認証方式の方式をカスタマイズできるから
    • 従来はweb.configなどをいじって対応する必要のあった認証方式の変更がGUIから簡単に実施できるようになりました
    • 例えば、イントラからの認証をWindows認証からAD FS Proxyと同じフォーム認証に変更できます。イントラ内に複数のADフォレストが存在する環境や、PCのログインユーザーとOffice365へのログインユーザーの情報が異なる場合などに活用できそうです。
  10. AlternateLoginIDが利用できるから
    • 従来、認証で利用する情報はUPNに固定されていました。このため、contoso.local をActive Directoryのドメインとして利用している場合などは各ユーザーのUPNを変更する必要がありました
    • AlternateLoginIDの設定の有効化により、ログイン要求が来てそのUPNが見つからなかった場合、指定したUPN以外の一意な項目(例えばmailなど)をキーとしてユーザーを検索し、そのユーザーへの認証要求として取り扱えるようになりました
  11. カリスマトレーナーによるトレーニングがあるから

良い事ばかり並べましたが、勿論新しいバージョンになったことで新たに考慮しなくてはならなくなったことや運用上の注意点なども出てきてます。この辺は後日またまとめてみたいと思います。