Quantcast
Channel: Always on the clock
Viewing all 434 articles
Browse latest View live

Azure ADドメイン参加を簡単にする

$
0
0

皆さんこんにちは。国井です。

オンプレミスのActive Directoryでもそうだと思いますが、クライアントコンピューターに対するドメイン参加の設定って、面倒ですよね?
特に、Azure ADのドメイン参加ともなれば、さらにハードルが上がります。そこで、今日はAzure ADのドメイン参加を簡単に行える方法について紹介します。
具体的には、Azure ADドメインの参加を行うにあたり、面倒だなと思うポイントとその解決策を紹介します。では、ひとつずつ潰していきましょう。

その1:管理者ユーザーアカウントでデバイス登録できない

オンプレミスのActive Directoryでは、管理者アカウントを使ってドメイン参加をすれば、登録できるデバイスの数に上限はありませんでした。(ちなみに、オンプレミスActive Directoryでは一般ユーザーを使って登録できるデバイスの上限数は10台です)
一方、Azure ADではユーザーを利用して登録できるデバイスの上限は20台という設定があります。これは、管理者ユーザーであろうと同じです。
つまり、会社のPCをドメイン参加させるときに、オンプレミスActive Directoryだったら1つのアカウントでいくらでもドメイン参加できるのに、Azure ADに参加させる場合はPCごとにドメイン参加に使用するアカウントを変えなければならないという問題が起きます。

2017-05-28 (1)

この問題は、Azure ADに登録できるデバイスの上限数の設定変更で解決しましょう。
Azure 管理ポータルから[Azure Active Directory]-[ユーザーとグループ]-[ユーザーごとのデバイスの最大数]から、1ユーザーあたりが登録できるデバイスの上限数は設定できます。デフォルトでは、20に設定されているので、これを無制限にしましょう。

その2:1台ずつドメイン参加の設定をしなければならない

オンプレミスのActive Directoryでもそうですが、ドメイン参加の設定は各クライアントごとに行う必要があります。1台ずつ設定しなければならないのは仕方がないにしても、少なくともクライアント側での設定は少なくしたい。
そんな時には、Windows 10 Ver.1703を使いましょう。Windows 10 Ver.1703からはAzure ADにアクセスするためのトークンを取得し、そのトークンを使ってドメイン参加させる、という自動化がサポートされています。

「トークンを取得する」と言っても、難しいことはなく、Windows ADKの中に含まれるWindows ICDを使えば、ウィザードベースでトークンの取得ができます。

では見てみましょう。

まず、Windows ADK をマイクロソフトのWebサイトからダウンロード・インストールし、Windows イメージングと構成デザイナー (Windows ICD)を起動します。
Windows ICDから[デスクトップデバイスのプロビジョニング]をクリック

image

ウィザード画面で、デバイスに設定するコンピューター名や、接続するネットワークの設定などと一緒に、[アカウントの管理]画面の中に[Azure ADに登録]の選択肢があります。
[Azure ADに登録]を選択して、[一括トークンの取得]をクリックすると、

image

Azure ADのユーザー名/パスワードを入力する画面が表示され、

image

WCDの許可を承諾すると、トークンが取得できます。
image

アカウントのWindowsへの追加は、この一連の登録とは直接関係ないので、ここでは[今はしない]をクリックしておきます。

image

トークンの取得ができ、この画面に戻ってきたら、後は[次へ]を繰り返しクリックして出来上がり。

image

最後に[作成]をクリックすると、拡張子.ppkgを含むファイル群が作られます。

image

ファイルは色々できますが、必要なのは.ppkgファイルだけなので、これをUSBメモリに入れてプロビジョニングパッケージを適用します。

プロビジョニングパッケージを適用するときは、既に使用中のコンピューターであれば、
[設定]アプリから[アカウント]-[職場または学校にアクセスする]-[プロビジョニングパッケージを追加または削除する]からパッケージを追加します。
(スクリプトで実行するときは、C:\ProgramData\Microsoft\Provisioningフォルダーにppkgファイルをコピーするだけでも動作しますよ)
追加したら、一度再起動します。

image

一方、OSを初期化(またはインストール)したタイミングでプロビジョニングパッケージを適用する場合であれば、OOBEと呼ばれる初期設定のウィザード画面でUSBメモリを挿すとプロビジョニングパッケージの適用が始まります。
もし表示されない場合は、Windowsキーを5回押すと、こんな画面が表示されて、プロビジョニングパッケージの適用を開始できます。
image

いずれの方法の場合も、プロビジョニングパッケージの適用が完了し、コンピューターを再起動すると、自動的にAzure ADに参加し、Azure ADユーザーのアカウントを使って Windowsのサインインができるようになることがわかります。

image

このようにAzure ADのドメイン参加の設定は、1台ずつ手動で設定するのではなく、プロビジョニングパッケージをあらかじめ作っておき、作ったプロビジョニングパッケージを適用するだけで、ドメイン参加が完了します。

いかがでしたか?
Azure ADドメインにデバイスを参加する機会自体、まだそれほど多い無いかもしれないですが、クラウドにシフトしていくにつれ、使う機会も増えてくると思うので、今のうちから使い方をマスターしておくといいと思います。


【ひとり情シスのためのWindows Server逆引きデザインパターン】が発売されます

$
0
0

「よく、オレなんかに任せようと思うよな..」
おそらく、ひとり情シスの方々の共通の意見ではないかと思います。
かくいう私もそのひとりでした。
私の場合は入社2年目に、ある事業所のサーバーの面倒を見る管理者に任命され、そのときの引継ぎ事項といえば、ドメインユーザーの作り方とアクセス許可の設定方法だけ。
(先輩、今だから言うけど、そのアクセス許可設定、間違ってるよ)
そんないい加減な引継ぎだったので、結局、何をすればいいのかよくわからない。

当時、クライアントPCにはWindows 95が使われていた時代で、WindowsがフリーズしたらCtrl+Alt+Deleteを押して再起動するというのは常套手段でした。
そのため、管理を任された初日からWindows Serverのログオンに戸惑うわけです。
だって「Ctrl+Alt+Deleteを押してログオンしてください」って表示されるんですよ!
「Ctrl+Alt+Deleteを押してログオンしてください」って何かの冗談じゃないのか?
そんなことして大丈夫なのか?
大事なサーバーが再起動しちゃうんじゃないのか?
サーバーの管理どころか、ログオンすらできないダメ管理者の私がそこには居たのです。

そんな私でも、人並みにサーバー管理ができるようになったのは、書店に並ぶ、様々なWindows Serverの書籍の存在があったからこそだと思います。
だから、いつか自分も同じような境遇の人のために役立つような書籍を出したい!というのは長年の目標でもありました。
そんな折、エクスナレッジさんからお話をいただき、
今回、ひとり情シスの方を対象にしたサーバー管理の書籍
ひとり情シスのためのWindows Server逆引きデザインパターン」を私の会社の同僚である、新井慎太朗さんと一緒に書かせていただくことになりました。

 

この書籍では私の経緯を踏まえて、次のような人のために書きました。

・他の業務とIT担当としての業務を兼任で仕事をするような方(もちろん
「ひとり情シス」)が、サーバー管理として何をすればよいかわからない方

・ITシステムの構成を変えなければならないのだけど、クラウドとか、
仮想化とか、色々選択肢がありすぎて、何を選択すればいいかわからない方

・会社のシステムはSIerの人に任せているんだけど、
少なくともSIerの人と会話ができる程度の知識は身に着けたい方

以上のような方(つまり、普段このブログを見に来るような方とは全然違う方々)を対象に、ファイルサーバーを作りたい、ユーザー管理をしたい、パッチ管理をしたい、など、
やりたいことに合わせて、
マイクロソフトのテクノロジーを使うとどのように解決できるか?
どうやって設定すればよいか?
使うときのメリット・デメリット・注意点は何か?
を10ページ程度の読みきりサイズでまとめました。

図版も多用して、少しポップな感じに仕上げているので、自分の読みたいところから気軽に読み始めることができるのが特徴です。

amazon.co.jpでは2017年6月18日発売ですが、一部書店では既に店頭に出ているそうなので、ぜひお手に取ってみていただければと思います。

PowerShellからAzure DNSのレコードを操作

$
0
0

皆さんこんにちは。国井です。

マイクロソフトさんからMicrosoft MVPという賞を2006年からいただいておりましたが、
今年もいただくことができました。これで12回目なのですが、この12年の間に周りにいるMVPさんの顔ぶれも結構変わった気がしますし、同じことをずっと続けていくって、案外大変なことなんだなって思います。
私の場合はどうかって?自分の会社で好き勝手にやっているので、このブログと共に、この命ある限り続けますよ!

今日はAzure DNSレコードの操作をPowerShellから行うという、備忘録な感じの話です。
Azure ADやOffice365を検証環境で使っていると、DNSレコードを登録する機会というのは少なからず出てくると思います。ADFSの検証環境を何度も作ってしまうような強者であれば、お名前ドットコムなどで取得した独自ドメインをお持ちで、なおかつDNSにはAzure DNSを使うという人もいるでしょう。そんなときに覚えておきたいのが、Azure DNSをPowerShellから一括で登録・削除する方法。

以下に記しておきますので、ご入用の際はコピペして使ってください。
言うまでもないかもしれませんが、AzureをPowerShellから操作するときは、
Azure PowerShellを事前にインストールしておくこと、
Login-AzureRMAccount
Select-AzureRMSubscription -SubscriptionID <サブスクリプションID番号>
のコマンドレットを実行しておくことを忘れないでください。

Azure DNSレコードの登録

ドメイン確認用のTXTレコードを登録する場合だったら、このように実行します。

$rs = Get-AzureRmDnsRecordSet -name “ドメイン名(sub.adfs.jpだったら、subの部分を指定)” -RecordType TXT -ZoneName “ゾーン名(例:sub.adfs.jpだったら、adfs.jpの部分を指定)” -ResourceGroupName “リソースグループ名”
$rs.Records[0].Value = “MS=msで始まるレコード”
Set-AzureRmDnsRecordSet -RecordSet $rs

また、Office365用のレコードを登録する場合はこちら。

#各種情報の設定
$recordname=”ドメイン名(sub.adfs.jpだったら、subの部分を指定)”
$domainname=”ゾーン名(例:sub.adfs.jpだったら、adfs.jpの部分を指定)”
$MXdomainname=”ゾーン名を-で区切って表記 (例:adfs.jpだったら、-adfs-jpと表記)”
$IP=”WAPのIPアドレス”
$RG=”リソースグループ名”

#Aレコードの登録
$rs = New-AzureRmDnsRecordSet -Name $recordname -RecordType A -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Ipv4Address $IP
Set-AzureRmDnsRecordSet -RecordSet $rs

#MXレコードの登録
$ExchangeOnlineName=$recordname + $MXdomainname + “.mail.protection.outlook.com”
$rs = New-AzureRmDnsRecordSet -Name $recordname -RecordType MX -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Exchange $ExchangeOnlineName -Preference 5
Set-AzureRmDnsRecordSet -RecordSet $rs

#TXTレコードの登録
#ドメイン登録用レコードは使い終わった後に削除している前提です
$rs = Get-AzureRmDnsRecordSet -name $recordname -RecordType TXT -ZoneName $domainname -ResourceGroupName $RG
$rs.Records[0].Value = “v=spf1 include:spf.protection.outlook.com -all”
Set-AzureRmDnsRecordSet -RecordSet $rs

#CNAMEレコードの登録
$ASName=”autodiscover.” + $recordname
$SIPName=”sip.” + $recordname
$LyncName=”lyncdiscover.” + $recordname
$MSOIDName=”msoid.” + $recordname
$rs = New-AzureRmDnsRecordSet -Name $ASName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “autodiscover.outlook.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $SIPName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “sipdir.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $LyncName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “webdir.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $MSOIDName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “clientconfig.microsoftonline-p.net”
Set-AzureRmDnsRecordSet -RecordSet $rs

#SRVレコードの登録
$SIPTLSName=”_sip._tls.” + $recordname
$SIPFedName=”_sipfederationtls._tcp.” + $recordname
$rs = New-AzureRmDnsRecordSet -Name $SIPTLSName -RecordType SRV -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs –Priority 1 –Weight 100 –Port 443 –Target “sipdir.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $SIPFedName -RecordType SRV -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs –Priority 1 –Weight 100 –Port 5061 –Target “sipfed.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs

Azure DNSレコードの削除

(ドメイン確認用の)TXTレコードを削除する場合だったら、このように実行します。

$dns=Get-AzureRmDnsRecordSet -RecordType TXT -ZoneName “ゾーン名(例:sub.adfs.jpだったら、adfs.jpの部分を指定)” -ResourceGroupName “リソースグループ名”
$dns | Where-Object {$_.Name -match “ドメイン名(sub.adfs.jpだったら、subの部分を指定)”} | Remove-AzureRmDnsRecordSet -Force

以上です。他のサイトでも見かけることができるような内容だと思いますが、必要であれば、使ってみてください。

Azure ADのサインイン履歴をPower BIで可視化した場合の実力をチェック

$
0
0

皆さんこんにちは。国井です。
先日、たまたまPower BIを利用する機会があり、ソースにAzure Active Directoryを選択できることを知り、追加してみました。
Azure ADのログを可視化するサービスは色々あるけど、Power BIとの組み合わせの場合、どんな特徴があるのか、探っていくことにします。

まずは実装

Power BIはOffice365の管理ポータルからライセンスを購入する画面から追加できます。
追加すると、Office365のランチャーからPower BIを選択できます。
Power BIを起動したら、[Microsoft AppSource]からサービスの[取得]をクリックします。

取得可能なサービスの一覧から[アプリ]-[Azure Active Directory Activity Logs]をクリック

Azure ADに接続します。ログ収集を行うテナントのドメイン名を入力し、

OAuth2を選択してサインインすると、OAuthではおなじみの画面が出てきます。

OAuthによる認可が完了すると、Azure ADのログを取り込み、Power BIで可視化してくれます。

可視化されるものは?

では、可視化された結果を見ながら特徴を見ていきましょう。
まず、最初に抑えておきたいのはPower BIに取り込まれるのは、サインイン履歴であって、監査ログ(管理作業の履歴)ではないってこと。ですので、管理者権限が乗っ取られた場合については、Power BIで見るべきところは、もうありません。

画面に目を移すと、画面左上で日付ごとのサインイン状況やアプリへのアクセス状況の統計が確認できます。これは導入したAzure ADが使われているか確認するときに役立ちそうですね。

次に、画面右上のサインイン場所について。IPアドレスをベースにした地図へのプロット結果が表示されますが、一覧が表示されるだけで、Azure AD Identity Protectionのようなアノーマリーを見つけてくれるわけではありません。この辺は可視化に特化しているツールであって、異常検出ではないことがはっきりわかります。
あと、こういう地図が出てくるときには、いつもお話ししていることですが、地図は参考程度に見ておいたほうがよいです。実際、東京にいるときにテザリングでネットに接続すれば、接続した場所が大阪って出ることもよくあるぐらいなので。。

画面をスクロールすると、接続時のアプリ(ブラウザー種類)や、OS種類、さらにはAzure AD経由でアクセスしたアプリ(クラウドサービス等)を確認できます。これらはAzure ADに接続したときのパケットからHTTPヘッダーのUser-Agentを参照しています。

こうした結果を見ていたら、アプリの一覧に「busbuy.live-int.com」という見慣れないアプリ(URL)がありました(Best Buyの間違い??)。クリックして、詳細を表示すると、ご覧のとおりの結果をご覧になれます。サイトのIPアドレスが表示されているので、このIPアドレスを検索エンジンでさらに調べてみると、Microsoftが所有しているらしいとの結果が確認できました。(ということはマイクロソフトが利用しているアプリということなのかな?)

調査はここまでで止めてしまいましたが、少なくとも怪しいサービスではないことはわかりました。このように、Power BIでは良いものも、悪いものも含めてフラットに表示してくれるので、その中から不正アクセスを見つけることができるかが大きなポイントになります。それを自動化したいということであれば、Azure AD Identity Protectionを使う、そんな使い分けになると思います。

じゃあ、どんなときに有効なの?

私なりの解釈では、Azure ADが会社のルールに沿って使われているか、コンプライアンス上の要件に沿って使われているかを確認するためのツールだと思います。Azure AD自体、これから導入するという会社が多いだろうから、既に無法地帯というAzure ADは無いだろうけど、今後、誰が管理しているのだかわからないようなAzure ADも(残念ながら)出てくるのではないかと思います。その時に、Power BIで可視化し、自分たちの会社の状況を知り、不正アクセスがあったかどうかはともかく、まずはAzure ADをマトモな使い方に戻していきましょう。というアクションにつなげていくことができるのではないかと考えています。

あと、Power BIが収集するログはクラウドに保存されているものだけが対象です。よくトレーニングで30日以上経過したログ(Azure AD Freeの場合は7日)はクラウドから削除されるので、事前にローカルにダウンロードしておきましょうとお話ししていますが、ローカルにダウンロードしたログはPower BIの対象ではありません。もし、それを可視化の対象にしたければ、ExcelからPower BIを実行するなどの工夫が必要になります。

【Azure AD】条件付きアクセスにある「ドメイン参加」の条件

$
0
0

皆さんこんにちは。国井です。
新しいAzureポータルサイトでは、Azure ADの機能に「条件付きアクセス」と呼ばれる、Azure ADに関連付けられたアプリへのアクセスを細かく制御してくれる機能が追加されています。
条件付きアクセスのアクセス制御機能の詳細については、色々なところで解説もあるでしょうから、そちらに譲ることにして、ここではアクセス制御の機能の中にある「ドメインに参加しているデバイスが必要です」という項目に注目してみたいと思います。
実は「ドメインに参加しているデバイスが必要です」という項目、とてもよくご質問をお受けするところで、
ドメインってAzure ADドメインのこと?それともオンプレADドメイン?
オンプレADドメインだったら、どうやってドメイン参加しているって識別するの?
などなど、よく聞かれるところです。

image

ひとつずつ整理していきたいと思いますが、
まず、上の画面にもある「ドメインに参加しているデバイスが必要です」という項目が指す、
ドメインとはオンプレミスのActive Directoryドメインのことです。

次にドメイン参加しているって、どうやってAzure ADが識別するか?ですが、
残念ながら、本当にActive Directoryドメインに参加しているだけでは識別されません。

そのため、条件付きアクセスで、私のデバイスがActive Directoryドメインに参加してますって、識別させるには、Azure ADにそのことをお知らせ(=つまり、デバイス登録)しなければなりません。

そのデバイス登録の方法が次のようなやり方になります。

Step1:サービス接続ポイントを設定

サービス接続ポイントとは、クライアントコンピューターがAzure AD のテナント情報を検出するための設定で、これを設定しておくことで、Windows 10コンピューターはAzure ADに接続できるようになります。
サービス接続ポイントの設定は、Azure AD ConnectをインストールしたコンピューターからPowerShellを起動し、

Import-Module -Name “C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1”

$aadAdminCred = Get-Credential

Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [オンプレADドメイン名\管理者アカウント] -AzureADCredentials $aadAdminCred

以上のコマンドレットを実行するだけ。
たまに、Import-Moduleの行で失敗することがありますが、そのときはAAD Connectをインストールしたサーバーを一回再起動しましょう。

Step2:グループポリシーでデバイス登録するように設定

Azure AD へのデバイス登録は本来、コンピューターごとに行う必要があるのですが、
お使いのPCがWindows 10であれば、グループポリシーで「デバイス登録しなさい!」という命令を送り込んで、自動的にデバイス登録を行うように設定できます。
設定項目は、コンピューターの構成>ポリシー>管理用テンプレート>Windowsコンポーネント>デバイスの登録>ドメインに参加しているコンピューターをデバイスとして登録する
このポリシー設定を有効にすればOKです。

image

Step3:デバイス登録の確認

デバイス登録はグループポリシーが適用されたタイミングで自動的に行われます。ただし、登録にはタイムラグがあるため、実際に確認できるようになるまでには少し時間がかかります。
登録確認には、Azure AD 用 PowerShellモジュールを使って、Get-MsolDevice –Allというコマンドレットを実行します。正しく登録できていれば、下の画面のようにデバイス名が表示されるはずです。
(Azure AD 用 PowerShellモジュールを使うときは必ず最新版を入れて確認してくださいね。)

image

このときに重要なポイントは、誰ユーザーがデバイスを登録したか?ってこと。
デバイスは登録さえすれば、誰でも条件付きアクセスを通過できるわけではなく、
デバイス登録を行ったユーザーがアクセスしなければ、いくら登録されたデバイスであっても「ドメインに参加しているデバイス」とはみなされません。
今回のケースでは、グループポリシーでデバイス登録しているので、デバイス登録したユーザーはグループポリシーが適用されたタイミングでサインインしていたユーザーということになります。
該当するユーザー(=グループポリシーが適用されたタイミングでサインインしていたユーザー)でサインインしている状態から、設定アプリを開き、アカウント>職場または学校にアクセスするにアクセスすると、[Azure ADに接続済み]の表示が確認できます。

image
これ、とっても重要なポイントなので、必ずチェックしておいてください。

さあ、確認の時間!

ここまでのことができたら、確認を行います。
ここでは、Exchange Online へのアクセスを制御する条件付きアクセスを設定し、

image

ドメインに参加しているときだけアクセスを許可するように設定します。

image

これで、Windows 10コンピューターから該当するユーザーでサインインし、Exchange Onlineに接続すると、アクセスできることが確認できます。一方、該当するユーザー以外でアクセスすると、デバイス登録していないとみなされるので、

image

ご覧のように条件付きアクセスの機能によってブロックされます。

■ ■ ■

いかがでしたでしょうか?
この機能、便利なんですけど、Windows 7で使えるの?とか、ADFS環境でも使えるの?とか、いろいろ出てくると思います。細かな条件については本家サイトで紹介しているので、ご覧になってみてください。

【参考】Azure Active Directory への Windows ドメイン参加済みデバイスの自動登録の構成方法
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup

【Azure AD】条件付きアクセスにある「ドメイン参加」の条件–ADFS編

$
0
0

皆さんこんにちは。国井です。

前回、条件付きアクセスに「ドメイン参加」の条件について紹介しました。
その中で、Active Directoryドメインに登録しているデバイスであることをAzure ADに
お知らせするために、Azure ADにデバイスを登録しなければならないという話をしました。

そのデバイス登録についてですが、Azure ADにデバイスを登録するときには、
Azure ADで認証を行い、認証が成功するとデバイスの登録が行われます。
(この図、間違っていたら、どなたかご指摘いただけるとありがたいです。)

一方、ADFSを利用している場合には、Azure ADで認証は行わないため、
私はデバイス登録を行いたい。でも、AD/ADFSを通じて既に認証は済ませているから、
Azure ADでの認証プロセスを省略してデバイスを登録させてほしい

というお願いをしなければなりません。

そのため、ADFSを利用している環境で、Azure ADの条件付きアクセスの「ドメインに参加しているデバイスが必要です」を利用する場合には、ADFSから発行されるクレームにデバイス登録を行うための情報(厳密に言うと、Azure ADデバイス登録サービスにデバイスを登録するためのアクセストークンをもらうための情報)を追加して、Azure ADにデバイスを登録するように依頼をします。
ADFSサーバー上で設定するAzure ADデバイス登録のためのクレームルールは証明書利用者信頼の[発行要求規則]から次の3つのルールを作成します。
(発行変換規則のうち、最初の2つはデフォルトの規則で、順序3~5が自動登録のために追加している規則です)

それぞれの規則で登録されている内容について、ざっくり見てみます。
まず、順序3ではaccounttypeクレームにDJという値をセットするというルールです。DJは「Domain Join」の略で、ドメインに参加済みのデバイスという意味です。

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(Type = “http://schemas.microsoft.com/ws/2012/01/accounttype”, Value = “DJ”);

次に順序4に登録されている規則は
onpremobjectguidクレームにobjectGUID値をセットするというルールです。

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “-515$”,Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”] && c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”,  Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/identity/claims/onpremobjectguid”), query = “;objectguid;{0}”, param = c2.Value);

最後に順序5に登録されている規則は
primarysidクレームの内容をパススルーでセットする(つまりコンピューターアカウントのSIDをクレームの値として登録するってこと)というルールです。

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]&& c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(claim = c2);

以上の設定を済ませ、グループポリシーが適用されると、ADFSで発行されたクレームをもってAzure ADにアクセスします。そして、クレームに記述されたobjectGUID値と同じ値を持つデバイスの情報は登録可能な状態となり、後にAzure AD Connectからディレクトリ同期が実行されることによって同一objectGUID値を持つドメイン参加のデバイスの情報がAzure ADに登録されます。
その様子はGet-MsolDeviceコマンドレットの他、Azure ADのSynchronization Service Managerからも確認できます。

クレームルールをADFSサーバーで書かなければならないのが面倒ですが、マイクロソフトさんのWebサイトにはクレームルール作成を自動化するスクリプトも置いてあるので、参考にしてください。

■Azure Active Directory への Windows ドメイン参加済みデバイスの自動登録の構成方法
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup

先進認証利用時のADFSによるアクセス制御について

$
0
0

皆さんこんにちは。国井です。

最近はOffice 2016, 2013を利用する企業も増えてきており、Office 365へのアクセスにADFSを利用している場合であれば「先進認証」を活用される企業も増えてきていると思います。
先進認証はブラウザーからSSOするときと同じように、パッシブプロファイルっぽいSSOアクセスを実現するものですが、認証・認可によってクライアントが受け取るトークンはブラウザーとは異なるものになります。

ブラウザーのSSOの場合はブラウザーを再起動すれば、改めて認証・認可を行い、トークンを発行しますが、Outlookなどのアプリケーションからの先進認証によるSSOの場合は一度トークンを発行すると、長い期間キャッシュを持つことになります。
そのため、ADFSサーバーでアクセス制御の設定を行っても、キャッシュを利用してしまうため、そもそもADFSサーバーにアクセスすることがなくなり、結果的にアクセス制御設定を無視してアクセスできてしまうという課題があります。

このような課題を乗り越えて、毎回ADFSサーバーにアクセスし、アクセス制御設定をチェックしてほしいという場合には、キャッシュを明示的に削除しなければなりません。
そこで今回は先進認証を利用しているケースにおいて、キャッシュを明示的に削除する方法について紹介します。

【基本】先進認証利用時のトークン

ADFSを利用している環境で、先進認証を利用している場合、Azure ADでは主に2種類のトークンを発行します。

・リフレッシュトークン
・アクセストークン (ベアラー)

まず、リフレッシュトークンはユーザー単位で発行されるトークンで、ざっくり言うとユーザー認証に成功したことを示すトークンです。トークンは14日間キャッシュされ、継続して利用していると最長で90日キャッシュされる、非常に長い有効期限に設定されていることが特徴です。リフレッシュトークンの情報はコントロールパネルの資格情報マネージャーから確認できます。
(ユーザー単位の発行だそうなんですが、実際には複数の資格情報が確認できます。なぜ?)

image

続いてアクセストークンは、Office 365の各サービスにアクセスするためのトークンで、有効期限は1時間と短く設定されています。
発行されたトークンの情報はレジストリの
HKEY_CURRENT_USER\Software\Microsoft\Office\
<バージョン番号>\Common\Identity\Identities\ <GUID>¥<GUID>\TicketCache
に保存されます。下の画面を見るとわかるように、サービス種類ごとに別々のトークンが発行されます。

image

予約時に発行されたチケットとボーディングチケット

最近は少なくなりましたが、航空券って予約した時に発券されるチケット(今はeチケットなどと呼ばれている、アレです)と、搭乗当日にカウンターで発行されるチケット(ボーディングチケット)の2種類がありました。私は数年ほど前、アメリカ ワシントンの空港で予約した時に発券されたチケットをもとにカウンターでボーディングチケットを発券してもらい、乗り場に向かいました。ところが、海外で様々なトラブルを引き起こす私のことなので、ボーディングチケットを乗り場に向かう最中に無くしてしまいました。
そこで私はゴリ押しでボーディングチケットなしで乗ろうと思い、
国井:「オレ、国井だけど、乗せてくれ」
係員:「は?何言っているの?だったら、予約した時のチケットを見せろ」
国井:「はい、どうぞ」
係員:「OK。ボーディングチケットを再発行しといたよ」
え、予約した時のチケットがあったら、ボーディングチケットって再発行されるの??
予約した時のチケットとボーディングチケットって、
アクセストークンが使えなくなったら、リフレッシュトークンを使ってアクセストークンを再発行する、リフレッシュトークンとアクセストークンの関係みたいですね。
何が言いたいかと言えば、どちらもチケット(トークン)がなくなったからといって、最初から手続きをやり直さなくてもいいってことです。

2つのトークンの関係は以下のMSさんのブログでも紹介されているので合わせて参考にして欲しいのですが、ユーザー認証後に受け取るデータがリフレッシュトークン(ブログ内ではauthentication_codeと表現)、authentication_codeをもとにOffice365にアクセスするための認可情報をアクセストークン(ブログ内ではOAuth JWTトークンと表現)と、パケットフローと共に紹介されております。

Office 製品の Office 365 モダン認証フローと認証キャッシュについて
https://blogs.technet.microsoft.com/sharepoint_support/2016/08/01/modern-authentication-flow-and-cache-of-office-to-office-365/

話が長くなりましたが、
以上のことから、Officeアプリから先進認証でOffice 365にアクセスした場合、最初だけADFSサーバーを利用した認証・認可を行うけれど、それ以降は14日~90日間はADFSサーバーを使うことがなくなることがわかります。
(事実、ADFSサーバーにはトークン発行のログが一切記録されません)

先進認証のキャッシュを削除する

先進認証のキャッシュを残さないようにして、ADFSサーバーによるアクセス制御をチェックさせるには、上記の場所からキャッシュを消せばいいのです。
消し方は次のとおりです。
アクセストークンの削除は次のコマンドレットを実行します。

cmdkey /list | where {$_ -match 'LegacyGeneric'} | foreach { cmdkey /delete "$($_.split()[-1])" }

一方、リフレッシュトークンの削除は以下のとおり。

reg delete HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\
<バージョン番号>\Common\Identity\Identities\
<GUID>\<GUID>\TicketCache

両方をクライアントコンピューターから削除したうえで、Outlookを起動すると、きちんとADFSサーバーにアクセスし、アクセス制御をチェックしたうえで、トークンが発行されます。
ADFSサーバーのイベントビューアを見ると、イベントID 1200のログ(Windows Server 2016の場合)がセキュリティログに記録されることが確認できます。

image

UserAgentの項目を拡大してみると、Microsoft Outlookって書いてあることがわかります。
(ちなみにSkype for Business クライアントの場合、それとわかるUserAgent文字列を残さないんですよね。。)

image

■ ■ ■

もうひとつの方法として、
Azure AD側で発行するトークンの期間をカスタマイズすることで、キャッシュをいつまでも使わず、トークン発行を頻繁に行うように構成することができます。

Azure Active Directory における構成可能なトークンの有効期間
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-configurable-token-lifetimes

本文中にもありますが、設定にはAzure AD Premium P1のライセンスが必要になるので、注意してください。

 

【おまけ】Skype for Business Onlineの先進認証設定

Exchange Onlineと同様にSkype for Business Onlineで先進認証を利用する場合も事前設定が必要ですので、https://www.microsoft.com/ja-jp/download/details.aspx?id=39366 からダウンロードしたツールを使って、以下のコマンドレットを実行しておいてください。

Import-Module SkypeOnlineConnector
$sfbsession=New-CsOnlineSession
Import-PSSession $sfbsession
Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

 

【余談】SharePoint Onlineへの先進認証
SharePoint Onlineへのアクセスに先進認証を利用する場合、SharePoint Online側で行うべき設定は無いのですが、先進認証を利用している/いないでアクセス制御ができるようです。

image

 

【参考】
Office365 先進認証についての検証
https://sharedtechv.wordpress.com/2017/01/23/office365-%E5%85%88%E9%80%B2%E8%AA%8D%E8%A8%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E6%A4%9C%E8%A8%BC/

ユーザーアカウント管理
https://technet.microsoft.com/ja-jp/library/office-365-user-account-management.aspx

Azure AD PowerShell v2チートシート

$
0
0

皆さんこんにちは。国井です。
Azure ADのPowerShellもVersion 2が出てきており、
そろそろ実務でも使う機会が出てきているので、このあたりで一度、主なコマンドレットをまとめておきたいと思います。(というか、自分用?)

■まずはAzure AD PowerShell v2の実装
以下のサイトでも紹介されているように、Install-ModuleコマンドレットでAzure AD PowerShell v2はインストールできます。
びっくりするくらい面倒な操作は一切不要。便利な世の中になったものですね。
https://www.powershellgallery.com/packages/AzureAD/2.0.0.115

Install-Module -Name AzureAD -RequiredVersion 2.0.0.115

■Azure AD に接続
ここからはAzure AD PowerShell v1と比較しながら見ていきましょう。
まずAzure ADをPowerShellから操作するときは接続操作が必要です。
(上段がv1の操作、下段がv2の操作です)

$cred = Get-Credential
Connect-MsolService -Credential $cred

$cred = Get-Credential
Connect-AzureAD -Credential $cred

■ユーザー一覧の確認
こちらはAzure ADのユーザー一覧を参照するときのコマンドレットです。

Get-MsolUser

Get-AzureADUser

■CSVファイルに基づくユーザーの作成
ユーザーを作成するときは、v1だとNew-MsolUser、v2だとNew-AzureADUserコマンドレットを使うのですが、CSVファイルで作成しておいたユーザー一覧を流し込んで作成するときは以下のとおりになります。ちなみに、v1とv2では必須パラメーターが異なるので、用意しておくべきCSVファイルも異なってきます。
例えば、v1だとCSVで指定したパスワードをそのまま流し込むことができたり、ライセンスの割り当てができたりするのですが、v2だとパスワードは事前にMicrosoft.Open.AzureAD.Model.PasswordProfileというオブジェクトを呼び出して、パスワードを登録しなければならないなど、v1に比べると面倒なことが増えてます(必須パラメーターも増えてますし)。

username,displayname,location,password,AccountSkuId
kunii@adfs.jp,国井傑,JP,P@ssw0rd,contoso:ENTERPRISEPACK

Import-Csv -Path <CSVファイルのパス> | foreach {New-MsolUser -DisplayName $_.displayname-UserPrincipalName $_.username -UsageLocation $_.location -LicenseAssignment $_.AccountSkuId -Password $_.Password}

username,displayname,location,mailnickname
kunii@adfs.jp,国井傑,JP,kunii

$PasswordProfile=New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$PasswordProfile.Password="P@ssw0rd"
Import-Csv -Path <CSVファイルのパス> | foreach {New-AzureADUser -DisplayName $_.displayname -UserPrincipalName $_.username -UsageLocation $_.location -MailNickName $_.mailnickname -PasswordProfile $PasswordProfile -AccountEnabled $true}

■グループ一覧の確認
こちらはAzure ADのユーザー一覧を参照するときのコマンドレットです。

Get-MsolGroup

Get-AzureADGroup

■新しいグループの作成
v1ではグループを作成するときにグループ名だけ指定すれば出来上がりですが、v2ではメールが有効なグループ(Office 365のグループ)にするか?、セキュリティが有効なグループにするか?など指定しなければならないパラメーターが増えています。

New-MsolGroup -Displayname <グループ名>

New-AzureADGroup -DisplayName <グループ名> -MailEnabled $false -SecurityEnabled $true -MailNickName <メールニックネーム>

■グループにメンバーを追加
グループにメンバーを追加するときには、ユーザーの属性をベースに自動的にメンバーを追加・削除できるようにしたいですよね?Azure AD Premiumを買えば、そんな問題はすぐに解決できるのですが、地道にPowerShellでやりたい人はこちらからどうぞ。
ちなみに、例文では[利用場所]属性がJPだったら、、という条件の時にグループのメンバーになるように設定しています。

Get-MsolUser | Where-Object {$_.usageLocation -match "JP"} | Add-MsolGroupMember -objectid <グループ名>

$group=Get-AzureADGroup |Where-Object {$_.Displayname -match <グループ名>}
Get-AzureADUser | Where-Object {$_.usageLocation -match "JP"} | foreach{Add-AzureADGroupMember -ObjectID $group.ObjectID -RefObjectID $_.ObjectID}

■ライセンスの確認
ライセンス割り当てをするときは、ライセンス名を確認しておかないといけません。なので、こちらのコマンドレットでどうぞ。

Get-MsolAccountSku

Get-AzureADSubscribedSku

■ユーザーにライセンスを割り当て
確認したらライセンスを割り当てるときは、v1だとSet-MsolUserLicense、v2だとSet-AzureADUserLicenseコマンドレットを使います。ただ、v2の場合、Get-AzureADSubscribedSkuコマンドレットで確認したライセンス名をそのまま指定することはできず、型の変換をする必要があります。

Set-MsolUserLicense -userprincipalname "<ユーザー名>" -addlicenses test:ENTERPRISEPACK

# 型の定義
$license = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$licenses = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses

# $licenseに追加するライセンスのSKU IDを登録
$license.SkuId = '<SKU ID>'
$licenses.AddLicenses = $license

# $licensesに削除するライセンスのSKU IDを登録
$licenses.RemoveLicenses = '<SKU ID>'

# ライセンスを割り当て
Set-AzureADUserLicense -ObjectId "<ユーザー名>" -AssignedLicenses $licenses

■パスワードのリセット
おひとり様のパスワードリセットだったらブラウザーから操作したほうが簡単だと思いますが、念のため。

Set-MsolUserPassword -UserPrincipalName "<ユーザー名>" -NewPassword "P@ssw0rd" -ForceChangePassword $false

$password=ConvertTo-SecureString -AsPlainText -String "P@ssw0rd" -Force
Set-AzureADUserPassword -ObjectId "<ユーザー名>" -Password $password -ForceChangePasswordNextLogin $false

■ユーザー一律のパスワードを再設定
ユーザー全員のパスワードを一律で設定する場面というのは、Office 365の管理画面からCSVファイル経由でユーザーをまとめて作成した時なんかが考えられます。Office 365の管理画面からCSVファイル経由でユーザーを作成すると、パスワードはランダムなものが割り当てられてしまうので、それをしたくない時なんかに使うことになります。
v2の場合、Set-AzureADUserPasswordコマンドレットから平文のパスワードを指定できないので、事前にConvertTo-SecureStringコマンドレットを使ってパスワードを暗号化(変換)しています。

Get-MsolUser | Set-MsolUserPassword -NewPassword "P@ssw0rd" -ForceChangePassword $false

$password=ConvertTo-SecureString -AsPlainText -String "P@ssw0rd" -Force
Get-AzureADUser | Set-AzureADUserPassword -Password $password -ForceChangePasswordNextLogin $false

■Azure ADのポリシー作成
Azure ADのポリシーが何か?という話は別の機会にすることにして、具体的に利用する場面はADFSサーバーから発行されるトークンのライフタイムを短くしたいときなどに使います。詳しくは以下のサイトでご覧ください。(このコマンドレットはv2限定です)
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-configurable-token-lifetimes

New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1, "MaxAgeSingleFactor":"until-revoked"}}') -DisplayName "OrganizationDefaultPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"

■Azure ADのポリシーに値を設定
作成したポリシーに値を設定していくコマンドレットです。

Set-AzureADPolicy -Id <ObjectId FROM GET COMMAND> -DisplayName "OrganizationDefaultPolicyUpdatedScenario" -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSingleFactor":"2.00:00:00"}}')

■Azure ADから切断
v1にはなかった、Azure ADの切断もv2なら用意されています。今までだったらコンソール自体を終了することでしか切断できなかったので、なにげにうれしい。

Disconnect-AzureAD

v2のコマンドレットを使ってオブジェクトを指定するときはユーザー名やグループ名ではなく、オブジェクトIDで指定します。ところが、オブジェクトIDの代わりにユーザー名やグループ名を指定しても問題ないコマンドレットもあるんですよね。ですので、今回のチートシートにはオブジェクトIDを使わなくて良いものに関しては、できるだけユーザー名やグループ名を指定するようにしました。

アプリケーション管理系のものとかが含まれていませんが、順次増やしていけたらと思います。

■参考資料 (今日、紹介できなかったアプリケーション管理系のものが掲載されています)
https://vincentlauzon.com/2017/02/02/automating-azure-ad/
https://blogs.msdn.microsoft.com/edutech/administration/script-bulk-assign-users-to-saas-application-using-graph-api-adal/


【Q&Aコーナー】ディレクトリ同期の非アクティブ化

$
0
0

皆さんこんにちは。国井です。

今日は、いつもよく聞かれる「ディレクトリ同期の非アクティブ化」について。
Azure AD Connectによる同期を行うときの前提条件であるディレクトリ同期のアクティブ化ですが、反対にディレクトリ同期をやめたいときには非アクティブ化を行う必要があります。
ユースケースとして、検証環境などで過去にディレクトリ同期を行ったユーザーを一度すべて削除して、一から(別の)Active Directoryドメインのユーザーを同期しなおしたいというときなんかに使ったりします。
A.comドメインとAzure ADで同期して、
検証が終わったから、今度は
B.comドメインとAzure ADで同期して、
検証が終わったから、今度は
C.comドメインとAzure ADで同期して、、
って繰り返すときに、その都度非アクティブ化を行い、Azure ADドメイン内のユーザーを削除しておかないと前の検証で使っていたユーザーがどんどんたまっていきます。
それを放置すると、こんな感じに同じ名前のユーザーが複数できてしまうなどの怪奇現象?も起こったりします。

image

だからこそ、非アクティブ化って必要なわけであり、今まではAzureクラシックポータル(https://manage.windowsazure.com/)から非アクティブ化って設定できたのですが、新しいポータルサイトではなくなってしまったんですよね、ディレクトリ同期の非アクティブ化。

Azure AD Connectをインストールすることにより、自動的にディレクトリ同期のアクティブ化が設定されますが、検証環境などでディレクトリ同期の環境を一度リセットしたいときにはAzure AD PowerShellツールから次のコマンドレットを実行して非アクティブ化を行ってください。

Set-MsolDirSyncEnabled -EnableDirSync $false

非アクティブ化コマンドレットはAzure AD PowerShell v2には用意されていないようなので、ご注意を。

【Q&Aコーナー】削除済みAzure ADユーザーの復元

$
0
0

皆さんこんにちは。国井です。
今日は先日いただいたご質問にお答えします。

オンプレミスのActive DirectoryではActive Directoryごみ箱なるものがあり、これを利用することによって削除されたユーザーは復元できる機能があったかと思います。一方、Azure ADの場合は?というと、Azure ADの管理ポータル画面にごみ箱的なものはないんです。
そのため、Office 365管理センター画面(https://portal.office.com/adminportal/)から[ユーザー]-[削除済みのユーザー]を選択して削除されたユーザーの復元を行います(ただしパスワードは再設定が必要)。

image

それから削除済みAzure ADユーザーの復元はPowerShellから削除するコマンドレットもありませんが、グループの場合はRestore-AzureADMSDeletedDirectoryObjectコマンドレットを利用することで復元できます。

一方、同期ユーザーの場合は同期元であるオンプレミスのActive Directoryで一元管理されるので、
オンプレミスのActive Directoryでユーザーが削除されますし、
オンプレミスのActive Directoryでユーザーが復元されます。

だからこそ、オンプレミスのActive Directoryではごみ箱機能を事前に有効化しておくことが重要になります。

Azure AD ConnectからSourceAnchorを変更

$
0
0

皆さんこんにちは。国井です。
Azure AD Connectって、結構頻繁にアップデートを繰り返していて、
特に最近ではobjectGUID以外の属性をSourceAnchor(ソースアンカー)に設定できるようになっていることもあり、Azure AD Connect自体のアップグレードを行いたいというニーズも出てきているのではないかと思います。
そこで、今日はAzure AD Connectを実行し、ソースアンカーを変更する方法について見てみたいと思います。

【おさらい】SourceAnchorってなに?

Azure AD Connectでディレクトリ同期を行うと、Active Directory(オンプレミスAD)のユーザーとAzure Active Directory(Azure AD)のユーザーは同期されますよね。
同期されたユーザーは、オンプレミスADのAというユーザーと、Azure ADのAというユーザーが同じユーザーであるということを何かしらの形で情報として持っていなければなりません。そこで使われるのがSourceAnchorです。
SourceAnchorで指定された属性が同じであれば、同一ユーザーとみなします。
SourceAnchorという属性はディレクトリ同期時にAzure AD Connectの中に格納される属性の名前で、
オンプレミスADのobjectGUID属性 (厳密にいえば、objectGUID属性をBase64でエンコードした値) を同期したものをAzure AD Connect内でSourceAnchor属性として持ち、
SourceAnchor属性をAzure ADに同期するとImmutableID属性として持ちます。
以上のことから、オンプレミスADのobjectGUID属性とAzure ADのImmutableID属性が同じであれば、同一ユーザーとみなすということになります。
(何度も言いますが、厳密はobjectGUID属性をエンコードした値がSourceAnchorですが、ここでは話を分かりやすくするために、objectGUIDの値そのものを使って説明しています)

image

objectGUIDじゃダメですか?

SourceAnchorに使われるobjectGUID属性は他のユーザーとは異なる一意な属性であり、オブジェクト作成時に生成されたら、永続的に保持されるため、オンプレミスADとAzure ADの間でオブジェクトマッピングをしやすいという理由からSourceAnchorとして採用されていました。
しかし、ADMTなどのツールでユーザーを別フォレストに移行すると、移行先でobjectGUIDは新しい値が設定されてしまうという問題が起きます。

このような問題を解決するために、Azure AD Connectでは新しくms-DS-ConsistencyGuid属性をSourceAnchorとして採用するようになりました。ms-DS-ConsistencyGuid属性はユーザー作成時のobjectGUID属性を格納する属性で、フォレスト間でのユーザー移動があってもobjectGUID属性とは異なり、ms-DS-ConsistencyGuid属性が変更されることはありません。そのため、最近のAzure AD ConnectでもobjectGUID属性からms-DS-ConsistencyGuid属性にSourceAnchorを変更する設定が用意されています。

Azure AD Connectを使ってSourceAnchorを変更する

既にAzure AD Connectを使っている会社でSourceAnchorを変更する場合は、Azure AD Connect自体をアップグレードしてから、SourceAnchorを変更します。
Azure AD Connectのアップグレードと言っても、アップグレード自体は特別な操作など必要なく、前のバージョンのAzure AD Connectがインストールされているサーバーに新しいバージョンのAzure AD Connectをインストールするだけ。

image

ウィザード自体もAzure AD管理者の資格情報を入力さえすれば完了。

image

だけど、アップグレード完了時点では、sourceAnchorはobjectGUIDのままなので、デスクトップ画面においてあるAzure AD Connectのショートカットを実行して、再度ウィザードを実行します。
ウィザード画面から[ソースアンカーの構成]を選択して、

image

ウィザードをただ単純に進めるだけで、ソースアンカー属性がobjectGUIDからms-DS-ConsistencyGuidに変更されます。

image

image

以上の操作により、ソースアンカー属性にms-DS-ConsistencyGuidが使われるようになります。
なお、ADFSを使っている場合、発行変換規則が作り替えられます。
というか、デバイス登録用にカスタムで作った変換規則が消されてる!
(アップグレード前はバックアップ必須ですね)

image

ちなみに作られた規則は以下のとおりです。
こちらが最初の規則

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);

 

こちらが2番目の規則

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

皆さまにとって、この操作を行う機会が出てくるか、わかりませんが、お役に立てれば幸いです。

【参考】
Azure AD Connect: 設計概念
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-design-concepts#using-msds-consistencyguid-as-sourceanchor

Azure AD (Office 365) 上のユーザーをオンプレミス Active Directory ユーザーと紐付ける方法について
https://blogs.technet.microsoft.com/jpntsblog/2017/03/22/azure-ad-hardmatch/

ADFS Rapid Restore ツールでADFSサーバーのバックアップ

$
0
0

皆さんこんにちは。国井です。

ADFSはSAML2.0に対応したWindows Server 2008のバージョン以降、利用する企業が随分と増えました。そうすると今度はADFSサーバーの運用をどうするか?という話が出てきます。色々と決めるべき事柄があると思いますが、中でも重要なのはバックアップではないかと思います。ベアメタルでバックアップしてしまえばよい、という考え方もあるでしょうが、一方でADFSに関わるコンテンツだけを独立してバックアップしておきたいというニーズもあるでしょう。
そんなときにおすすめなのが、ADFS Rapid Restoreツール。

Windows Server 2016と2012 R2のバージョンのADFSに対応する、このツールはPowerShellのコマンドレットを1つ実行するだけでバックアップ/復元ができてしまう優れもの。とっても簡単なので、わざわざ紹介するまでもないのですが、意外とハマリポイントもあるので、動きを見てみましょう。

インストール

マイクロソフトのWebサイトからダウンロードして、インストールするだけ。
ウィザード自体もNextボタンを連打していれば、インストール完了です。

バックアップの実行

PowerShellから実行するのですが、最初にモジュールをロードするコマンドレットを実行し、

import-module 'C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll'

その後、以下のコマンドレットでバックアップを実行します。

Backup-ADFS -StorageType "FileSystem" -StoragePath "C:\testExport\" -EncryptionPassword "password" -BackupComment "Clean Install of ADFS (FS)" -BackupDKM

このコマンドレットでは、C:\testExportフォルダーにADFSサーバーのコンテンツをまとめてバックアップしてくれって命令を出しています。(フォルダーは事前に作っておいてください)
ちなみにマイクロソフトのWebサイトによれば、以下のコンテンツがバックアップされるそうです。

・ADFS構成データベース (WIDまたはSQL Serverに保存されているものです)
・ADFSサーバーのフォルダーに保存されている構成ファイル
・トークン署名証明書とその秘密キー
・SSL証明書とその秘密キー
・カスタマイズされた属性ストアなどのカスタム認証プロバイダー

バックアップでは、トークン署名証明書をバックアップしないなど、オプションを指定できます。バックアップのオプションに関しては、公式サイトでご確認ください。
(公式サイトの中でDKMという言葉が出てきますが、トークン署名証明書のことだとおもっていただければ、よいでしょう。もうちょっと細かく言うと、DKM=Distributed Key ManagerはADFSサーバーのトークン署名証明書などの証明書が格納されるActive Directoryのコンテナーのことです)

バックアップデータは、指定したフォルダー内に日付を付けたフォルダーが作成され、その中に保存されます。保存されるデータはこんな感じ。

バックアップデータはAES256で暗号化されているので、ファイルを開いても、何も面白いことは書いてありません。

リストア

これまた簡単で、Import-Moduleでモジュールをロードしてからリストアのコマンドレットを実行するだけ。

Restore-ADFS -StorageType "FileSystem" -StoragePath "C:\testExport\" -DecryptionPassword "password" -RestoreDKM

指定したフォルダーに格納されているファイルを読み取って、自動的にリストアしてくれます。ただし、リストア後のADFSサービスの起動は行ってくれません。これは、リストア後に手動で行う作業ができるようにするためです。これは気を付けたいポイントですね。
あと、リストアもオプションが色々ありますが、公式サイトで確認してください。

実際に実行してみた

私の環境では、こんな感じで実行してみました。

おいおい、よく見たらバックアップ失敗してるじゃないですか!
SSL証明書エクスポートできないって、オレ、Administratorだよ!
同じ境遇にある人はそう思うのではないかと思います。
しかし、SSL証明書ってインポートするときに、エクスポート不可能な状態でインポートしてしまうと、いくらAdministratorであろうとバックアップ時にエクスポートできなくなってしまうのです。(以下は手動でエクスポートしようとしたときの画面)

エクスポート不可能な状態で証明書をインポートしてしまったら最後、秘密キーへのフルコントロールアクセス許可があろうと、エクスポートはできなくなってしまいますので、その場合には、SSL証明書のリストアだけは手動で行う必要が出てきます。

あと、言い忘れたことなど

・ログは%localappdata%\ADFSRapidRecreationToolフォルダーから確認できます。
・2012 R2のバックアップデータを2016に復元できないので、アップグレードには使えません。
・リストア時のオプションを使えば、異なるサーバーへの復元や使用するデータベースの変更(WID→SQL、SQL→WID)ができます。

色々なシナリオを考えてみると、色々なオプションを使うことになるのでしょうが、
それについては、また別の機会に触れてみたいと思います。

Windows Server 2016 ADFSサーバーによる証明書認証

$
0
0

皆さんこんにちは。国井です。
だいぶ前の話になりますが、Azure ADの概念実証(PoC)に利用可能なプレイブックがマイクロソフトさんから公開されました。

■Azure Active Directory の概念実証戦略: 概要
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-playbook-building-blocks#generic-ldap-connector-configuration

PoCの項目の中に「証明書ベースの認証を構成する」というのがありますが、Azure ADだけで実現する内容ではなく、実際にはADFSサーバーを使っています。最近、ADFSサーバーで証明書を使うシナリオはWindows Hello for Businessが絡んでくる関係で、色々なパターンがあるのですが、ここで解説しているシナリオはADFSでシングルサインオンするときに、証明書を使った多要素認証を行うパターンを紹介しています。
(以下の図では、ADFSサーバーにアクセスしてからの流れだけを紹介しています)

 

ADFSを使った証明書認証は以前にも「ADFSによる多要素認証の設定」で紹介させていただいたのですが、だいぶ時間が経過していることやQ&Aサイトなどで「国井のブログを見たとおりに設定したけど、うまくいかない」などの書き込みを見かけることがあり、
Windows Server 2016バージョンを改めて、まとめておこうかなと思ったわけです。

■ ■ ■

Windows Server 2016の証明書認証の設定は、以前のバージョンと同じく多要素認証の設定で証明書認証を利用するように定義します。
ADFS管理ツールから[サービス]-[認証方法]から[多要素認証方法の編集]で証明書認証を選択します。

image

また、同じ画面から[プライマリ認証方法の編集]で証明書認証を利用するように設定します。

image

その他、多要素認証を使うときは、証明書利用者信頼のアクセス制御ポリシーで、MFAを利用するようなポリシーを選択しておきます。

image

ADFSサーバーの設定はこれだけ。

一方、認証局の設定は基本的に「ADFSによる多要素認証の設定」で紹介した

・証明書サービスのインストール
・クライアントコンピューターへのユーザー証明書のインストール

の2つの項目通りに設定していただければ結構です。
このときに、認証局の設定ミスあるあるとして、

・CRLを発行・公開していない
image

・物理的にアクセスできない場所をCRLのパスとして指定している
(CDPとAIAにLDAPのパスがデフォルトに入っていますが、LDAPってFWの外からアクセスできないですよね)
image

などがあります。このあたりをちゃんとチェックしておきましょう。

以上が出来上がれば、証明書認証の設定は完了です。実際にOffice365のサイトにアクセスしようとすると、ADFSサーバーによるSSOプロセスの中で証明書認証が実行され、証明書を持っていれば勝手にサインインが完了し、証明書を持っていなければ認証エラーになります。

image

また、Windows Server 2016からの機能として、Webアプリケーションプロキシ経由のアクセスに証明書認証だけを使ったアクセス方法というのがあります。

image

ADFS管理ツールのプライマリ認証方法の設定で、エクストラネットの認証方法に[証明書認証]だけを選択することで、Webアプリケーションプロキシ経由のアクセスにユーザー名/パスワードを使わず、証明書だけを使って認証することができるようになります。今までのADFSって、Webアプリケーションプロキシを経由することで必ずユーザー名/パスワードを入れていたので、「なんだよ、シングルサインオンじゃないじゃん」って言ってた人もいると思います。しかし、Windows Server 2016からは場所を問わず、ユーザー名/パスワードを入力することなく認証を済ませることができるようになるのです。

ADFSが必要な理由 ~ 2017年版

$
0
0

皆さんこんにちは、国井です。

ADFSサーバーは長らくOffice 365のシングルサインオンを実現するために欠かせない機能として、多くの企業で導入されてきました。しかし、最近ではAzure AD Connectのパススルー認証やパスワードハッシュ同期+SSOを利用することで、ADFSサーバーを利用しなくてもシングルサインオンは実現できるようになっています。また、クレームルールを使ったアクセス制御についても、Azure ADの条件付きアクセスを利用することによって、その代替になりつつあります。

そうすると、私たちの中でギモンが生まれます。

ADFSって必要なの?

もちろん必要なければ消えてなくなるだけなのだけど、実際にはそうでもなさそうです。
そこで記念すべき400回目の投稿となる今回は、ADFSが必要となるケースを私なりに考えてみました。

ハイブリッド構成

Exchange ServerとExchange Online、Skype for Business ServerとSkype for Business Onlineなど、オンプレミスとクラウドでサービス間連携を行う場合、1つのIDでオンプレミスとクラウドの両方をシームレスにアクセスできる必要があります。その場合、ADFSを使って認証はActive Directoryに一元化し、クラウドへのアクセスはADFSを使って橋渡しをしてあげるような仕組みが必要となります。

ハイブリッド構成は恐らくADFSサーバーを利用する最有力な理由になるのではないかと思います。

Windows Hello for Business のオンプレミス展開・ハイブリッド展開

Windows Hello for Business(WHfB)は、Windows Helloを使って行う認証(つまりパスワードを使わない認証)方法で、Azure ADにアクセスするための機能ですが、WHfBはオンプレミス展開、またはハイブリッド展開を実装することで、オンプレミスのActive DirectoryにサインインするときにWHfBを使うことができます。
このとき、WHfBによる認証を行うためのインターフェイスとして動作するのがADFSサーバーで、顔認証などによるWindows Helloでの認証結果をADFSサーバーが受信し、その内容に基づいてADFSサーバーが代理でActive Directoryにサインインする、というようなアクセスを行います。
また、WHfBほど複雑な実装をしなくても、単純に証明書を使った認証でパスワードを入れなくても良いようにしたい、というときにもADFSサーバーは役立ちます。

最近は、パスワードを使って認証を行うこと自体が脆弱だといわれる時代なので、こうした認証・認可の実装は今後、重要になってくるかもしれないですね。

詳細なアクセスログの収集

Azure ADにサインインしたときにもログって収集できますが、ADFSサーバーを利用しているときのようなトークンの中に含まれる内容まで詳細にログを記録してくれるわけではありません。また、Azure ADに記録されるログは最大で1か月しか保存してくれないので、長期的に、そして詳細な内容をログとして残しておきたいというときにオンプレミスのActive Directory+ADFSサーバーという選択肢は考えられると思います。

これは、IdPをオンプレミスに持つか、クラウドに持つか、という議論にもつながってくる話だと思います。

社内IPに基づくクレームルール

最後はオマケです。
Azure ADを使ってアクセス制御を行う場合、IPアドレスベースのアクセス制御ができますが、この設定はグローバルIPアドレスをベースにしたアクセス制御を行います。
それに対して、ADFSサーバーによるクレームベースのアクセス制御では、プライベートIPアドレスをベースにしたアクセス制御を行います。もし、社内のIPアドレスのうち、特定のIPアドレスからのみアクセスを許可したい、のようなニーズがある場合にはADFSサーバーが必要になってくると考えられます。

■ ■ ■

いかがでしたか?
これからADFSサーバーを導入しようか考えている会社はまだしも、
既にADFSサーバーを導入している会社において、Azure ADのほうが良さそうだという短絡的な理由で、ADFSサーバーをやめてしまうと「やっぱり必要だった」というときに目も当てられません。ですので、必要なケース、そうでないケースをきちんと見極め、必要な場合にADFSサーバーを利用するようにしたいですね。

Windows Server 2016 ADFS × Azure MFAで多要素認証

$
0
0

皆さんこんにちは。国井です。

今日はOffice 365 Advent Calendar 2017に参加して、本投稿を書いています。

■Office 365 Advent Calendar 2017
https://adventar.org/calendars/2585

Office 365へのサインインのうち、50%がADFSサーバーを使ったサインインだといわれているので、そのADFSサーバーへのサインインをAzure ADの多要素認証と組み合わせて強化していく方法について見てみたいと思います。

ADFSサーバーで多要素認証を実装すると言ったら、基本的に証明書認証一択だったと思いますが、Azure AD Premium P1で提供されるAzure MFAを組み合わせると、Azure MFAの電話認証等がADFSサーバーでも利用できるようになります。

この設定自体は以前からあったのですが、Azure ADで提供されるツールをインストールするなどの作業がなくなったので、簡単に利用できるようになりました。
(以前提供していたツールって、インストール後のウィザードが複雑すぎて何をすれば正解なのか、よくわからなかったりして、実装には色々と苦労させられてたんですよね..)

ではさっそく、簡単になったAzure MFAをWindows Server 2016と組み合わせて設定する方法について実装方法をみていきましょう。

準備

Azure AD Premium P1以上のライセンスとADFSサーバーによるAzure ADシングルサインオン環境が必要です。
実はこれが一番のハードルだったりします。。

Azure MFAを利用できるようにするための初期設定

Azure MFA用の証明書の作成、証明書とAzure MFAのアプリIDを組み合わせてSPNを作成、ADFSと関連づける設定、この3つをPowerShellで実行します。

$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID <ドメイン名>
New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64
Set-AdfsAzureMfaTenant -TenantId <ドメイン名> -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720

Azure MFAのアプリIDは981f26a1-7f43-403b-a875-f8b09b8cd720って決まっているので、そのまま入力するだけ。TenantIdにはAzure AD Connectのコネクタスペースの名前が入りますが、それはすなわちActive Directoryのドメイン名になります。

Azure MFAの利用開始

Windows Server 2016のADFSサーバーで管理ツールを開き、以下の設定を行います。

1.[サービス]-[認証方法]から[多要素認証方法の編集]を開き、[Azure MFA]を有効にします。

image

2.[証明書利用者信頼]からMicrosoft Office 365 Identity Platformのアクセス制御ポリシーを開き、[すべてのユーザーを許可し、MFAを要求]を選択します。

image

以上で設定は終わりです。
ちなみに、[サービス]-[認証方法]から[プライマリ認証方法の編集]を開いて、[Azure MFA]を使うように設定する必要はありません。

ユーザーの設定

多要素認証方法を選択しておく必要があります。
多要素認証方法の設定はAzure ADに直接保存されるので、Azure ADが提供する多要素認証の初期設定サイト(https://aka.ms/mfasetup)にアクセスし、電話番号などを設定してもらいます。

アクセスしてみる

Office365のサイトにアクセスしようとすると、ADFSサーバーのURLにアクセスしたとたん、事前に設定した多要素認証の方式に従い、電話またはアプリを使った認証が始まります。

image

ちなみに、社外からアクセスするときにパスワードを入力しないで、Azure MFAだけを使うように設定することも可能です。

この設定自体、それほど複雑なものではないと思いますが、これがWindows Hello for Businessのハイブリッド展開を行う上で欠かせない設定要素になりますので、覚えておきましょう。

明日のAdvent Calendarは@teracwoさんです。お楽しみに。

■参考
Configure AD FS 2016 and Azure MFA
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa


2017年に最も読まれた投稿ランキング

$
0
0

皆さんこんにちは。国井です。

当ブログでは毎年最初の投稿で最も読まれた投稿ランキングを紹介しているのですが、
今日はその2017年版をご紹介します。

第1位 【101シリーズ】パフォーマンスモニタ徹底攻略 ~ パフォーマンスの確認編
4年連続第1位になったのは、Windows Serverのパフォーマンスモニタの活用方法を解説した投稿です。ちなみに、101シリーズのイベントビューア編も書きたいって、去年も、一昨年も言っていましたね。。こちらは、ある会社さんから企画をいただいているので、そちらで書くことになると思います。だから今年こそはリリースされると思います。お楽しみに。

第2位 ADFSとは?フェデレーションとは?を知る方法
ID連携に関する知識を身に着けるための第一歩と思って書いた、大昔の記事。あまりに色々な人に読まれた投稿なので、最近ではニュージーランド出身のアンドリューって、どんな人?とか聞かれるようになってきました。ここには書けない武勇伝がいっぱいあるので、知りたい人は直接お会いした時にお話しますね。

第3位 忘れたAdministratorパスワードを変更する方法
Google検索の結果から入ってくる人が多いのですが、検索キーワードとか見ていると、正直、もう消したい投稿なんです。

第4位 【101シリーズ】パフォーマンスモニタ徹底攻略 ~ 基礎編
この投稿も、このブログの人気記事。言い方を換えると、他に読むパフォーマンスモニターの記事が少ないってことでもあるんですよね。。何年経っても。

第5位 Azure AD Connectを利用したOffice 365×ADFS設定
ADFSのインストールと言えば、Azure AD Connect!ってことで、この投稿が読まれているんでしょうけど、正直Azure AD ConnectでADFS入れるの、お勧めできないんですよね、個人的に。

ということで、1位から5位まで結果は2016年と全く同じ。バズる内容を書いていないからとかツッコミを受けそうですが、バズり狙いとか、あんまりやりたくないんですよね。

Google検索結果とかで入ってきてもらって役に立った!
違うことで検索したら、また同じブログに来て役に立った!!
何を検索しても結局、このブログに来て役に立った!!!

ってなってもらえるのが、見ている人にとっても、私にとっても一番の喜びなんで、これからも地道にやっていこうと思います。
それでもって、イルミネートジャパンさんで開催している「Office 365とクラウドサービスの認証ベストプラクティスコース」やトレノケートさんで開催している「Azure Active Directory を使用した認証基盤の構築」などの私が登壇しているコースに来てくださるとうれしいです(笑)。

2018年は「ADFSが必要な理由 ~2017年版」でも書いたように、ADFSの立ち位置が大きく変化していく年になるのではないかと思っています。
ですので、Azure ADのシングルサインオンとか、ADFSのWindows Hello for Business対応など、このブログでも少しずつ紹介できたらと思っています。

あと、いつも言っていることですが、「受講者(読者)の次のアクションにつながるトレーニング」を目標に、様々な情報発信をしていきますので、今年もどうぞよろしくお願いいたします。

PowerShellからAzure ADレポートのエクスポート

$
0
0

皆さんこんにちは。国井です。

Azure ADの研修サービスを提供させていただく中で、
色々なお客様からのご要望の多い
「最大で30日しか保存されないレポートをどうするか?」問題。

以前、私はPowerShellスクリプトを作ってローカルにダウンロードしておきましょうという投稿を書いたのですが、そのときに書いた内容もクラシックポータルでの作成方法だったので、今回改めて新しいポータルサイトでの作り方を見ておくことにしたいと思います。
#途中まで書いたところで、MSさんの公式サイトにも同じような内容が掲載されていたことに気がつきました。。そのため、内容がかぶってしまっているところが一部あるので、ご了承ください。

■Azure Active Directory サインイン アクティビティ レポート API のサンプル
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-reporting-api-sign-in-activity-samples

前提条件:ADALライブラリのロード

以前の投稿「PowerShellでAzure ADの情報を収集」に書いた通りです。こちらを参考にしてください。

Azure ADのアプリを作成

Azure ADでは、外部(ここでいう外部とはPowerShellのスクリプトのことです)からAzure ADにアクセスする場合、Azure ADのアプリを作成し、外部からのアクセスを受けられるようにしておく必要があります。
そのため、まずはAzure管理ポータルにアクセスし、Azure ADの画面から[アプリの登録]を利用して新しいアプリを作成します。
ここでは、名前を「PSAccess」、アプリケーションの種類を「Webアプリ/API」、サインオンURLを「http://localhost」としておきます。
なお、サインオンURLに入れるURLは実際にアクセスするものではないので、なんでもいいです。

アプリの登録からアプリを作成したら、[設定]-[必要なアクセス許可]を開き、PowerShellからアクセスしたときに、どこまでのアクセスを許可するか設定します。
[追加]ボタンを押して、

[アクセスの有効化]からRead directroy dataを許可するように設定します。
保存したら、前の画面に戻って[アクセス許可の付与]ボタンを押すことも忘れずに。

これでログにアクセスするためのアクセス許可が割り当てられた状態になります。
あとは、アプリの登録の[設定]画面から
[キー]にアクセスしてキーを発行することと、

image
[プロパティ]にアクセスしてアプリケーションIDを確認しておいてください。

image

PowerShellスクリプトの実行

ここまで設定したら、「Azure Active Directory サインイン アクティビティ レポート API のサンプル」サイトからPowerShellスクリプトをコピーして、
PowerShell画面に貼り付けます。
このとき、<clientId>欄にアプリケーションID、<clientSecret>欄にキーの値、<tenantDomain>欄にドメイン名(***.onmicrosoft.com)をそれぞれ入力します。

※本校執筆時点では、スクリプトの6行目にある

$ daterange # For example, contoso.onmicrosoft.com

の行はまるごと削除しておかないとエラーになるのでご注意を。

実行すると、カレントディレクトリにjsonファイルが保存され、ファイル内にアクセスログが書き込まれます。

image

CSV形式で結果を出力したい

とっても便利なスクリプトファイルですが、出力がjsonファイルじゃなくて、CSVで欲しいんだよな。。という要望もあるかと思います。
その場合は、スクリプトの30行目を

$myReport.Content | Out-File -FilePath SigninActivities$i.json –Force

から

($myReport.Content | ConvertFrom-Json).value | ConvertTo-Csv -NoTypeInformation | Out-File -FilePath SigninActivities$i.csv -Force

と書き換えてあげればOKですよ。

image
このログによると、city=Tokyo,state=Saitamaと表示されているので、東京は埼玉の属国になったそうです。

期間を絞って出力したい

デフォルトのスクリプトでは、過去7日間の結果が出力されているようになっているけど、それは8行目の

$7daysago = "{0:s}" -f (get-date).AddDays(-7) + "Z"

で定義されているので、(-7)部分を書き換えてあげればOKです。例えば30日分なら

$7daysago = "{0:s}" -f (get-date).AddDays(-30) + "Z"

とすればよいでしょう。ちなみに$7daysagoは変数なので、$30daysagoと変更するなら、すべての項目を変更するように。

色々なログを出力したい

クラシックポータル時代のAzure ADレポートを見たことがある人ならご存知だと思いますが、どのアプリケーションへのアクセスがあったかをアプリケーション単位で表示するログとかありましたよね?あれもスクリプトをちょっといじれば表示できます。
下のPowerShell画面は、

$url = 'https://graph.windows.net/' + $tenantdomain + '/activities'

として、Invoke-WebRequestコマンドレットを実行した結果ですが、
/activities配下には、サインインイベントのsigninEvents以外にも、
管理者作業の結果のログであるauditとか、
アプリへのアクセス結果を出力するsigninEventsAppSummaryなど、
色々なものが用意されていることがわかります。

image

このことを踏まえて、21行目の

$url = "https://graph.windows.net/$tenantdomain/activities/signinEvents?api-version=beta&`$filter=signinDateTime ge $7daysago"

部分を

$url = "https://graph.windows.net/$tenantdomain/activities/signinEventsAppSummary?api-version=beta"

と書き換えればOKです。ちなみにオリジナルのスクリプトにあった
$filter=signinDateTime ge $7daysago部分は
7日前までのログを取ってきなさいという意味ですが、signinEventsAppSummaryログにsigninDateTimeという属性はそもそも存在しないので、betaから後ろの部分は削除してあります。
それでもって、取得したデータがこちら。

image

アクセスしたアプリケーションとアクセスした回数が表示されるのですが、アプリケーションIDで表示されてしまうので、どのアプリケーションにアクセスしたか、わかりにくいのですよね。。

■ ■ ■

いずれにしても、色々なログがPowerShellからとってこれるので、Azure AD管理者の方はぜひ使いこなせるようになっていただければと思います。

■参考:Azure Active Directory Identity Protection と Microsoft Graph の基本
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-identityprotection-graph-getting-started
■参考:Get Office365 usage reports from the Microsoft Graph using Windows PowerShell
https://blogs.technet.microsoft.com/dawiese/2017/04/15/get-office365-usage-reports-from-the-microsoft-graph-using-windows-powershell/

ADFS 2.xをWindows Server 2016へ移行

$
0
0

皆さんこんにちは、国井です。
Windows Server 2008のサポート期限切れが近づくにつれて問い合わせが多くなってくるWindows Server 2008で作成したADFS環境をどうやってWindows Server 2016へ移行するか?という話題。

Windows OS全般に言えることですが、基本的に2世代前からのアップグレードはマイクロソフトとしてサポートされることはなく、ADFSも例外ではありません。

2008→2012のアップグレードドキュメント
https://technet.microsoft.com/ja-jp/library/dn486819(v=ws.11).aspx

2012→2016のアップグレードドキュメント
http://azuread.net/2017/02/22/windows-server-2016%E3%81%AEadfs%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%89/

というわけで、2008→2016の移行は、アップグレードウィザードみたいな既存の仕組みは全くないので、自分で移行(というか、再構築)していかなければなりません。

では、設定を見てみましょう。

既存環境の設定の確認

まず、移行前と移行後で同じパラメーターで動作させる必要があるので、既存の環境から次のパラメーターを確認しておきます。

・フェデレーションサービス名
・フェデレーションサービスの表示名
・フェデレーションサービスの識別子

次に、サービス通信証明書は移行先でも同じものを使いますので、ADFS管理ツールからエクスポートしておきます。

最後に、証明書利用者信頼などの設定はWindows Server 2016のセットアップディスクの中にあるPowerShellスクリプトを使ってエクスポートすることができます。

エクスポートコマンド
cd <セットアップディスクのドライブ>\support\adfs
export-federationconfiguration.ps1 -Path <エクスポートデータの保存先パス>

Active Directoryスキーマの拡張

ADFSをWindows Server 2016にするってことは、Active DirectoryドメインコントローラーもWindows Server 2016にする可能性が高いと思います。ドメインコントローラーを以前のOSからアップグレードしている場合は、スキーマが古いままになっているので、スキーマもアップグレードしておきます。

スキーマのアップグレードコマンド
cd <セットアップディスクのドライブ>\support\adprep
adprep /domainprep
adprep /forestprep

ADFS 2016の実装

Windows Server 2016のADFS (ADFS 2016と勝手に呼ぶこととする)をインストールします。インストールするときは、ADFS2.xからのサーバー入れ替えになるので、既存のADFSサーバーはシャットダウンしておきます。

ADFS 2016のインストールでは、インストールウィザード中に前の手順で控えておいたパラメーターを入力します。また、サービス通信証明書もインストールウィザード中に入れることになりますが、これも前の手順でエクスポートしておいたものを入れましょう。
これができれば、ADFS 2016環境の出来上がり。

ただし、トークン署名証明書は新しいものに変わってしまっているので、証明書を入れ替える時のステップを実行する必要があります。証明書の入れ替え方法はMSさんのサイトを参考にするとよいでしょう。

AD FS の証明書更新手順(トークン署名証明書、トークン暗号化解除証明書)
https://blogs.technet.microsoft.com/jpntsblog/2016/12/19/ad-fs-%E3%81%AE%E8%A8%BC%E6%98%8E%E6%9B%B8%E6%9B%B4%E6%96%B0%E6%89%8B%E9%A0%86%EF%BC%88%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E7%BD%B2%E5%90%8D%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%80%81%E3%83%88%E3%83%BC/

最後に、前の手順でエクスポートしたデータをインポートしましょう。こちらも同じくWindows Server 2016のセットアップディスクの中にあるPowerShellスクリプトを使ってインポートします。

インポートコマンド
cd <セットアップディスクのドライブ>\support\adfs
import-federationconfiguration.ps1 -Path <エクスポートデータの保存先パス>

これでサービスを再起動すれば、設定を読み取って動作し始めるようになります。

ADFSプロキシの移行

ADFSプロキシ(現Webアプリケーションプロキシ)は、ほとんどサーバー固有の情報を持たないので、作り直してしまったほうが簡単です。作り直すときは、前の手順でエクスポートしておいたサービス通信証明書があれば十分です。

■ ■ ■

トークン署名証明書は作り直さないで移行するオプションなどありますが、細かな話はADFSトレーニングの中で聞いていただければと思います。

徹底攻略MCP問題集70-740対応が発売されました

$
0
0

皆さんこんにちは。国井です。

2018年2月17日頃から2月19日までブログへのアクセスが途絶えていました。アクセスしていただいた方、すみませんでした(プラグインの自動アップデート、怖い…)。

さて、今日はお知らせです。
私の会社の同僚である、新井慎太朗さんのお手伝いとして執筆させていただいた、「徹底攻略MCP問題集 Windows Server 2016[70-740:Installation, Storage, and Compute with Windows Server 2016]対応」が2018年2月19日に発売されました。

Windows Server  2016のMCP試験の中でも入門編的な位置づけですが、コンテナなどの新技術はもちろんのこと、ADFSなどの当ブログではおなじみの内容など、試験範囲を網羅しています。これから初めてMCP試験を受ける人に向けて執筆しましたが、MCP試験ご無沙汰の方でも今までのWindows Serverをご存知の方であれば、解ける問題も多いと思うので、ぜひお手に取ってみていただければと思います。

永続的なシングル サインオン

$
0
0

皆さんこんにちは。国井です。

今日はご質問いただいた内容について。
最近(と言っても随分前ですが)、Azure ADのサインイン画面が変わりましたが、それに合わせてADFSサーバーのフォーム認証画面もAzure ADっぽくすることができるようになりました。
これについてはMVPふじえさんが紹介してくださっているので、そちらを参考にされるとよいと思います。

■[AD FS]ログイン画面をAzure ADの新UIライクにカスタマイズする
http://idmlab.eidentity.jp/2017/11/ad-fsazure-adui.html

実際に設定してみた画面がこちら。Azure ADのサインイン画面に似ているようでちょっと違いますかね。

image

一方、新しいAzure ADのサインイン画面で印象的なのはこの画面ではないかと思います。

image

この画面で、サインインの状態を維持するように設定すると、永続Cookieと呼ばれるCookieが作成され、ブラウザーを閉じてもサインインの状態が維持されます。
これと同じことをADFSサーバーのサインイン画面でも出したいと思っても、残念ながら既定で設定画面がないため、設定できません。
もし、ADFSサーバーからサインインを行い、永続Cookieを発行させたい場合、Set-AdfsPropertiesコマンドレットを使って、

Set-AdfsProperties -EnableKmsi $true

のように実行すれば、サインイン画面は次のように変化します。

image

この画面で、[サインアウトしない]にチェックをつければ、永続Cookieが発行され、24時間サインインしたままの状態が継続されます。
ちなみに24時間有効という設定自体も

Set-AdfsProperties –KmsiLifetimeMins <分数>

で設定可能です。

■参考:AD FSシングルサインオン設定
https://msdn.microsoft.com/ja-jp/library/mt148493(v=ws.11).aspx

デフォルトでは、セッションCookieが有効ですが、この1行をクレームとして入れておくことによって、Cookieを使いまわし、永続的にサインイン状態を保つことができます。これにより、Azure ADでの認証・認可プロセスも省略されるため、条件付きアクセスで多要素認証を設定するようにしてあっても多要素認証は行われなくなります。

c:[Type == “http://schemas.microsoft.com/2014/03/psso”] => issue(claim = c);

Viewing all 434 articles
Browse latest View live