※こちらの記事は2020年8月17日にnote版「ラック・セキュリティごった煮ブログ」と同じ内容です
デジタルペンテストサービス部のしゅーとです。
普段は IoT ペネトレーションテスト、情報システムペネトレーションテスト、ゲームセキュリティ診断など攻撃者がやりそうなことをなんでもやっています。
ペンテスターのみなさん、検証用のActiveDirectory環境の構築はどうやっていますか？
我々のようなペネトレーションテスターにとって、攻撃を検証するために何度も AD の構築が必要となります。
もちろんセキュリティ業務とは関係なくても、何度も構築せざるを得ないエンジニアもいると思います。
数回くらいは勉強のために手動で構築してもいいですが、作業になってくるとどうしても苦痛になってきます。
そこで便利なのが AutomatedLab ！
github.com
AutomatedLab (略称AL) は Microsoft が開発した Windows 環境の自動構築フレームワークです。
これを用いることで、さまざまな AD 環境のラボが作れます。
ローカルのHyper-V環境のほか、Azure 上に構築することも可能です。
そして個人的に一番強力だと思っているのが、ラボの構築スクリプト(ps1)を他の人に渡すことで、スクリプトを貰ったひとも同じ環境を構築できる点。
これは研修用途に最適だと思います。
（他には Datacenter エディションのライセンス買って1台のラックサーバにHyper-V入れてトレーニング案件とかするといいと思います）
エンジニアたるもの自動化せよ！ということで、AutomatedLab を利用して理想の ActiveDirectory 環境を自動で構築しましょう！
デモ: AutomatedLab の力を見よ！
ALをセットアップした状態で、以下の PowerShell スクリプトを管理者権限で実行してみます。
New-LabDefinition -Name Lab1 -DefaultVirtualizationEngine HyperV Add-LabMachineDefinition -Name DC1 -Memory 1GB -OperatingSystem 'Windows Server 2019 Standard Evaluation (Desktop Experience)' -Roles RootDC -DomainName contoso.com Add-LabMachineDefinition -Name Client1 -Memory 1GB -OperatingSystem 'Windows 10 Enterprise Evaluation' -DomainName contoso.com Install-Lab Show-LabDeploymentSummary -Detailed
これを実行すると、Hyper-V 上に仮想マシンが作成され、結果的にこうなります。
たった4行で、Windows Serverと Windows10 がインストールされ、Active Directory を構築し、クライアントの Windows10 がドメインに加入した状態になるのです。
この自動化、ワクワクしませんか？
セットアップ
さっそくセットアップしましょう。残念ながら、仮想マシンを動かすためマシンスペックは必要です。OS の ISO ファイルのダウンロードも必要なので、最初から始めるひとは少し時間がかかります。
必要なもの
潤沢なメモリ、ストレージ、プロセッサが必要です。仮想マシンを複数台同時に動かしても問題ない環境で動かしてください。
同時に動かす仮想マシンにもよりますが、メモリは最低8GB。仮想マシン数により 16GB や、32GBを推奨します。
ストレージは SSD で。特にNVMe SSD であれば構築時間が短くて済みます。
下準備
以下を有効にしておきます。
・BIOS画面にて Intel VT-X / AMD-Vの有効化
・Windowsの機能の追加と削除にて Hyper-V 関連機能の有効化
VMWare など他の仮想化ソフトウェアとの衝突について
VMWare WorkStation は Windows10 2004 にて Hyper-V プラットフォームに対応しています。
並行して使いたい方は Windows10 2004 にアップデートしてください。
2004 以前だと仮想化ソフトウェアをアンインストールするしかないです。
VirtualBox も Hyper-V プラットフォームに対応しているようです。
インストール
AutomatedLabのインストール
Powershell を管理者権限で起動し、以下のコマンドを実行します。
なお、msi を利用したインストールは必要なモジュールを全てインストールできない場合があるようで、私的には推奨しません。
Install-Module AutomatedLab -Force -AllowClobber
なお、コンピュータに NuGet が入っていない場合、NuGet のインストールを促されるため、指示に従いインストールします。
LabSourcesのインストール
AutomatedLab がインストールできたら LabSourcesをインストールします。
LabSources とは Lab を配置するフォルダのことです。
> New-LabSourcesFolder
※別ドライブにインストールしたい場合は -DriveLetter で指定します。
(「-DriveLetter D」 など)
AutomatedLabのコマンド実行時のエラーが表示された場合
このコマンドをはじめ、AutomatedLabのコマンドを実行しようとすると以下のエラーが発生する場合があります。
'New-LabSourcesFolder' コマンドはモジュール 'AutomatedLab' で見つかりましたが、このモジュールを読み込むことができませんでした。
これは Powershell のセキュリティ実行ポリシーによるものであり、これを解決するには2つの手段があります。
１．永続的に実行ポリシーを緩和する
２．Powershell ウインドウを実行する際に毎回「-Exec bypass」
オプションを指定して一時的に実行ポリシーを緩和する
※この場合、ALを利用する際は毎回
「Import-Module AutomatedLab」を実行する必要がある
実行ポリシーは2のとおり実行時に一時的に変更できますが、この先 Powershell ISE でラボ構成を作成するとき、2 だと実行ポリシーに阻まれ実行ができなくなるので、恒常的に変更できる 1 を行いましょう。
Set-ExecutionPolicy Unrestricted
※管理者権限で実行すること
セキュリティ上不安な方は、AL を使わなくなったら Restricted ポリシーに戻しておきましょう。
AutomatedLab初回実行時の診断情報の送信可否
初回実行をすると、以下のようなことを聞かれます。
Opt in to telemetry?
診断情報を送信するかどうかです。YesかNoの好きな方を選んでください。
ISO ファイルのダウンロード
AL は ISO イメージに install.wim という構成ファイルが含まれている場合に利用可能です。
Windows メディア作成ツールを利用してダウンロードした Windows10 Pro などの ISO ファイルは wim ファイルが含まれていないため、そのままでは使えません。試用版の ISO ファイルなら install.wim が含まれるので、検証用途ならこれを使いましょう。
各 OS の試用版 ISO ファイルは以下のとおりです。
・Windows Server 2019
https://www.microsoft.com/ja-jp/evalcenter/evaluate-windows-server-2019
・Windows 10 Enterprise
https://www.microsoft.com/ja-jp/evalcenter/evaluate-windows-10-enterprise
なお、これらは 全て英語版(US) を用意してください。残念ながら AL は日本語環境に対応していません。アーキテクチャは自由ですが、今回は x64 を利用します。
※ISO ファイルをダウンロードするには氏名・会社名・電話番号を入力する必要があります。
ISO ファイルをダウンロード後、ALの LabSources フォルダ内のISOsフォルダに配置します。
LabSources フォルダはデフォルトでは C ドライブ直下に作成されています。
配置後、Powershell にて Get-LabAvailableOperatingSystem コマンドを用いてISOファイルが認識されていることを確認しましょう。
PS C:\WINDOWS\system32> Get-LabAvailableOperatingSystem |ft OperatingSystemImageName 20:30:25|00:48:57|00:48:57.052| Scanning 2 files for operating systems Found 5 OS images. OperatingSystemImageName ------------------------ Windows 10 Enterprise Evaluation Windows Server 2019 Standard Evaluation Windows Server 2019 Standard Evaluation (Desktop Experience) Windows Server 2019 Datacenter Evaluation Windows Server 2019 Datacenter Evaluation (Desktop Experience)
これで基本的なセットアップは完了です。
ラボを作成してみよう
・所要時間:10-20分 (マシンスペックにより異なります)
いよいよラボの実習です！
LabSources に Sample Scripts が存在しているので、これらを見ながら作ることでだいたいのやり方はわかるようになります。
チュートリアルはGithubのWikiが参考になります。
https://github.com/AutomatedLab/AutomatedLab/wiki
また、充実したドキュメントは以下のURLにあります。ただし最新ではない模様なので注意です。
（最新情報はGet-Helpを使うか、リポジトリのコードを読むしかない）
https://automatedlab.org/en/latest/
今回は試しに1台の Windows Server 2019 をインストールしてみます。
まずはWindows Powershell ISE を管理者権限で実行します。
次に画面左上に位置するps1ファイルを作成するペインで、以下の文字列をコピペしましょう。
# TestLabというラボを作るよという宣言 # これから設定するものは全て、「Install-Lab」コマンドを実行することで適用される # DefaultVirtualizationEngineはHyperV。これは必須のオプション。 New-LabDefinition -Name TestLab -DefaultVirtualizationEngine HyperV ## Windows Server 2019のマシンを作成 # Powershellは末尾にバッククオート(`)を置くことで長いコマンド列を複数行に分割可能。 # -OperatingSystem: Get-LabAvailableOperatingSystem で出てきたOperatingSystemImageNameの名前を用いる Add-LabMachineDefinition ` -Name ws2019 ` -Memory 2GB ` -OperatingSystem 'Windows Server 2019 Standard Evaluation (Desktop Experience)' # ラボ設定を適用し作成する Install-Lab # デプロイ結果を表示する Show-LabDeploymentSummary -Detailed
エディションは試用版なら Standard でも Datacenter でも特に変わりません。そのまま商用利用したい場合はライセンスを購入したときのためにDatacenterで作っておくと都合がいいです。
メモリはデスクトップエクスペリエンスでも 1GB で動きますが、2GB の方がセットアップが早くなります。
張り付けたら、画面上の▶を押してスクリプトを実行しましょう。
実行するとラボの構築が始まります。
OSごとにベースイメージを作成するので、初回は時間がかかります。2回目以降はその分早いです。
しばらく待つと、ラボの構築が完了し、Show-LabDeploymentSummary の結果が表示されます。
マシン定義時にアカウント名やパスワードなど指定していない場合はデフォルトで定義された情報が用いられます。
Summary にあるように、デフォルトでは管理者アカウントは「Administrator」、パスワードは「Somepass1」が設定されます。
ネットワーク設定も同様であり、デフォルトでは192.168.0.0/16の範囲でホストのネットワークと衝突しないように192.168.[0-255].0/24 のサブネットをもつネットワークが作成されます。
この設定ではインターネットに接続されていませんが、マシンに接続して色々なことができます。
マシンに接続
PowerShell ISE 下部のシェルプロンプトでコマンドを打っていきます。画面右枠のコマンドウインドウがキーボード入力を奪うときがあるので、コマンドウインドウは閉じておいたほうがいいかもしれません。
RDP接続
Connect-LabVM コマンドを利用すると RDP 接続ができます。
> Connect-LabVM ws2019
ユーザ名に「Administrator」、パスワードに「Somepass1」を入力してください。
「リモートデスクトップ接続」(mstsc) を直接使ってもいいです。コマンドラインで叩くなら以下。
> mstsc /v:ws2019
ラボマシンとの Powershell セッションを確立
ラボマシンはデフォルトで WinRM が有効になっているため、PSSession が利用可能です。
Enter-LabPSSession を使うことで、 AL が認証情報を利用しセッションを確立してくれます。
> Enter-LabPSSession ws2019 [ws2019]: PS C:\Users\Administrator\Documents> whoami ws2019\administrator
ラボマシンに Powershell コマンドレットを実行させる
Invoke-LabCommand で任意のコードが実行できることを確認しましょう。
> Invoke-LabCommand -ComputerName ws2019 -ScriptBlock {Write-Host (whoami)} 19:21:19|00:03:09|00:00:00.000| Executing lab command activity: '<unnamed>' on machines 'ws2019' 19:21:19|00:03:09|00:00:00.009| - Waiting for completion ws2019\administrator 19:21:29|00:03:19|00:00:10.159| - Activity done
Invoke-LabCommand はラボマシンを指定し、ScriptBlock を使って任意のPSコード、OSコマンドを実行できます。今回は whoami コマンドを Write-Host コマンドレットを使って結果を標準出力させました。
この時点ではあまり使い道はありませんが、ラボインストール後の後処理をするときに時々使います。
ドメイン環境を作成する
・所要時間: 30-40分
次は SampleScripts の Introduction フォルダにある「04 Single domain-joined server.ps1」をもとに、Windows Server 2019 をインストールしドメイン環境の設定をするスクリプトを作成し、構築してみます。
ついでに今回はドメイン管理者のパスワードをAdd-LabDomainDefinitionで設定してみました。
以下のスクリプトを PowerShell ISE に張り付け、実行しましょう。
※長いように見えますが、殆どがコメントです(Tips)。
# 既にLabが存在していれば削除 # マシンの名前空間は全ラボで共通なので、既存ラボを残しながら作る場合は重複しないように注意。 Remove-Lab # TestDomainLabというラボを作るよという宣言 # これから設定するものは全て、「Install-Lab」コマンドを実行することで適用される # DefaultVirtualizationEngineはHyperV。これは必須のオプション。 New-LabDefinition -Name TestDomainLab -DefaultVirtualizationEngine HyperV # DomainNameは複数マシンで使うので、変数にしておく。 $TestDomain = 'al.corp' ## ドメイン管理者ユーザの情報。 $DomainAdminUser = "aladmin" $DomainAdminPassword = "P@ssword123!" ## ラボ構築のためのOSインストール時のユーザアカウントを設定（キッティング用ローカルユーザ）。 # Set-LabInstallationCredential はラボ内で全て共通になる。途中で上書きも可能。 # ドメインコントローラの場合は Set-LabInstallationCredential と Add-LabDomainDefinition を二つとも同じ情報で一致させる必要がある。 # ただそうすると、DC以外のマシンでドメイン管理者アカウントと同じ情報の"ローカル管理者アカウント"ができてしまう # そのためちゃんとしたラボを構築するときは、DC以外はAdd-LabMachineDefinition の -InstallationUserCredential オプションでキッティング用ローカルユーザを指定したほうがいい。 Set-LabInstallationCredential -Username $DomainAdminUser -Password $DomainAdminPassword # ドメイン管理者アカウントを設定 Add-LabDomainDefinition -Name $TestDomain -AdminUser $DomainAdminUser -AdminPassword $DomainAdminPassword ## ドメインコントローラを作成 # Powershellは末尾にバッククオート(`)を置くことで長いコマンド列を複数行に分割可能。 # -Roles :そのマシンの役割を示す変数を指定。DCやSQLServerなどは色々な設定が必要だが、ALは大体の設定をRoleという形で事前定義してくれている。 # 単一、あるいはフォレストルートのドメインコントローラは RootDC ロールを用いる。 # Role一覧はドキュメントのAbout Roles項を参照のこと。 # -DomainName: ドメイン名。今回はAutomatedLabにちなんだ名前にしてみた。同じドメインに属したいなら各マシンを同じDomainNameにする。 # 今回の OS はデスクトップエクスペリエンスではないもの。動作を軽くしたい場合はこちらがオススメ。 Add-LabMachineDefinition ` -Name DC1 ` -Memory 2GB ` -OperatingSystem 'Windows Server 2019 Standard Evaluation' ` -Roles RootDC ` -DomainName $TestDomain ## クライアントであるWindows10マシンを作成 (実はクライアントもWS2019にした方がセットアップは早い) Add-LabMachineDefinition -Name Client1 -Memory 2GB -OperatingSystem 'Windows 10 Enterprise Evaluation' -DomainName $TestDomain # ラボ設定を適用し作成する Install-Lab # デプロイ結果を表示する Show-LabDeploymentSummary -Detailed
コメントにあるように Install-Lab コマンドを行うことで作成が始まります。Install-Lab を行うまでは構成を変更し放題で、論理バグを発見できます。
可能なら何度も色々構成をこねくり回してから最後に Install-Lab を付加して実行した方が、毎回時間がかかるデプロイを繰り返すよりも時間的な効率は良いです。ただやってみないとわからないことも多いので、慣れないうちはスクラップアンドビルドでガンガン作っていきましょう
結果、30分くらいでできました。
スクリプトのコメントでも書いた通り、Set-LabInstallationCredential の影響でClient1でドメイン管理者アカウントと同じ情報のローカル管理者ができています。
これを避けるには Add-LabMachineDefinition のオプションでキッティング用ローカル管理者アカウントを設定すべし。
クライアントも al.corpドメインに所属しています。
また Domain Admins に、構築スクリプトで設定した「aladmin」が含まれています。
[DC1]: PS C:\Users\aladmin\Documents> net group "Domain Admins" /domain Group name Domain Admins Comment Designated administrators of the domain Members ------------------------------------------------------------------------------- Administrator aladmin The command completed successfully.
ドメイン設定や Windows10 のセットアップのため時間がかかりましたが、2台のマシンを一からセットアップしてドメイン設定まで完了するまでにわずか30分、コーヒーを飲んで待てば終わるというのはとても楽です。
Enter-LabPSSession や Connect-LabVM を使いながら確認してみましょう。
ユーザアカウントなどの設定は？ → 頑張りましょう
残念ながら AL が簡潔に書けるようにカバーしているのはマシンの自動セットアップです。
マシン構築後のユーザアカウントやグループ追加、グループポリシーなどの追加セットアップは頑張って PowerShell を書くことになります。
ユーザアカウントに関しては、ドメインコントローラで New-ADUser コマンドレットを使って簡単に追加できます。
PostInstallationActivity
AL にはマシン構築後に、該当仮想マシン内で自動的にスクリプトを実行する「PostInstallationActivity」機能があります。
PostInstallationActivity は、各マシンの定義のオプションに記述できます。C:\LabSources\PostInstallationActivities に TestLab フォルダを作成し、以下のスクリプトを PrepareDomain.ps1 として TestLab フォルダ内に保存しましょう。
Start-Transcript C:\Windows\Temp\postinstall.log -append $users = @() $users += @{Name = "abe"; Password = "P@ssword1"} $users += @{Name = "iijima"; Password = "P@ssword2"} $users += @{Name = "usui"; Password = "P@ssword3"} ForEach ($user in $users){ $securePassword = $user.Password | ConvertTo-SecureString -AsPlainText -Force New-ADUser -Name $user.Name ` -AccountPassword $securePassword ` -PasswordNeverExpires $true ` -Enabled $true } Write-Output "Useradd done." Stop-Transcript
これは見ての通り、適当にユーザ名パスワードを配列に入れて、それらを順に New-ADUser に追加するスクリプトです。
・デバッグしやすいようにStart-Transcriptを使うとよいです。
・ちなみに私はドメインごとに csv でユーザ・グループ・OUを管理できる
ようにしています。
・デフォルトはパスワードの複雑性要件が有効になっているので、脆弱な
パスワードを設定する場合はグループポリシーを変えておく必要が
あります。
次に、先ほどの構築スクリプトのドメインコントローラのところに PostInstallationActivity オプションを追加します。
$postInstallActivity = Get-LabPostInstallationActivity ` -ScriptFileName PrepareDomain.ps1 ` -DependencyFolder "C:\LabSources\PostInstallationActivities\TestLab" # Domain Contoller Add-LabMachineDefinition ` -Name DC1 ` -Memory 1GB ` -OperatingSystem 'Windows Server 2019 Standard Evaluation' ` -Roles RootDC ` -DomainName $TestDomain ` -PostInstallationActivity $postInstallActivity
$postInstallActivity 変数に、 Get-LabPostInstallationActivity コマンドレットのオプションとしてスクリプトの場所と保存フォルダを教えて、また改めてラボ構築を行います。
インストール後、以下のようにちゃんとユーザができていることが確認できます。
構築後の注意点
私が構築した中で、デフォルト状態で以下のセキュリティ上の懸念点を確認しました。CTFっぽい環境を構築して他人にやってもらうなら、これらを事前に対処してください。
・C:\unattend.xml にキッティングユーザの認証情報が含まれる
・AutoLogon がデフォルトで有効で、それに伴い
HKLM\SECURITY\Policy\Secrets\DefaultPassword にパスワードが含まれる
・キッティングに使ったローカル管理者が有効
・WinRM が有効
・UAC が無効
・Windows Firewall が無効
いかがでしょうか。全自動で AD を構築する喜びを共有できたらこれ以上にうれしいことはありません。
私は自動化が楽しくて、構築スクリプトとPostInstallationActivity をたくさん書いて、下の図のような脆弱環境を全自動 2 時間でセットアップされるものを作成しました。
2つのフォレストを作成し、MSSQL の Database Link をつないだり、Kerberoastable や ASReproastable だったり、 RestrictedAdmin なマシンで Pth で RDP できたりと、AutomatedLab（と沢山のPowerShell）でこういった複雑な環境も作れます。
特定マシンに常に NTLM ハッシュが残るように工夫するのも大変でしたが面白かったです。
他にも仮想マシンをインターネット接続させる方法などもありますが、長くなるのでここでは割愛します。それらの内容も SampleScripts フォルダに例があるのでぜひ確認してください。
私はルータマシンに Squid を入れることで、プロキシ経由じゃないとインターネットに疎通できないようにして、 C2 フレームワークの検証を楽しんでいます。
最後に、よく使う AL コマンド集を記載して終わります。
ーーー
よく使うコマンド集
全てのヘルプは下記のRead the Docs に存在します。
https://automatedlab.org/en/latest/
ここではよく使うコマンドを紹介します。
ラボ全体
ラボの一覧を表示
Get-Lab -List
すでにインストールされているラボのリストを表示する。
表示されたラボは、Import-Labコマンドでセッションをインポートできる。
ラボセッションの復元
Import-Lab [ラボ名]
インストールされたラボのセッションを復元する。構築したときの PowerShell ウインドウを閉じたあと、ラボを再度操作するために必要。
Powershell セッションにラボ情報がインポートされるので、マシンの停止・起動、情報の取得や、接続、スナップショットの操作が可能になる。
ラボマシンの一覧
Get-LabVM
ラボのマシン情報を表示する。
ラボインストール時の詳細情報の取得
Show-LabDeploymentSummary -Detailed
インストール時の管理者ユーザのパスワードも含め、マシンの名前やネットワーク情報を全て表示する。
マシンの停止と開始
一時停止
Save-LabVM [-Name <コンピュータ名> | -All ]
引数はコンピュータ名だが、「-All」を使うことでラボマシン全てが適用される。
メモリなどのステートが保存される。開始すると、そのまま元の状態に戻る。
停止
Stop-LabVM [-Name <コンピュータ名> | -All ]
引数はコンピュータ名だが、「-All」を使うことでラボマシン全てが適用される。
シャットダウンシグナルが送信される。
開始
Start-LabVM [-Name <コンピュータ名> | -All ]
引数はコンピュータ名だが、「-All」を使うことでラボマシン全てが適用される。
スナップショット
スナップショットの作成
Checkpoint-LabVM [-ComputerName <コンピュータ名> | -All] -SnapshotName <スナップショット名>
引数はコンピュータ名だが、「-All」を使うことでラボマシン全てが適用される。
- Snapshotname でスナップショット名を指定する。必須。
> Checkpoint-LabVM -All -SnapshotName InitialSetup
※これを実行したのにGet-LabVMSnapshotでもHyper-Vマネージャでもスナップショット(Checkpoint)が表示されない場合は、空き容量が少ないなどで作成に失敗している可能性がある。Hyper-Vマネージャで試しに作成してみて、得られたエラー内容を確認しよう。
スナップショットの確認
Get-LabVMSnapshot [-ComputerName <コンピュータ名>]
何も指定しなければ全てのラボマシンの情報が出る。
> Get-LabVMSnapshot SnapshotName CreationTime ComputerName ------------ ------------ ------------ InitialSetup 2020/03/19 0:04:06 ws2016 second 2020/03/19 0:05:55 ws2016
スナップショットの復元
Restore-LabVMSnapshot [-ComputerName <コンピュータ名> | -All] -SnapshotName <スナップショット名>
引数はコンピュータ名だが、「-All」を使うことでラボマシン全てが適用される。
- Snapshotname でスナップショット名を指定する。必須。
> Restore-LabVMSnapshot -All -SnapshotName InitialSetup
マシン接続
ラボマシンとのPowershellセッションを確立
Enter-LabPSSession -ComputerName <コンピュータ名>
PSRemoting による Powershell セッションが確立される。 認証情報は、ラボマシンがドメインに属している場合、ラボ構築時に使用したキッティング用 Domain Admins ユーザが使用される。
ドメインに属していない場合はローカルのキッティング用ユーザの認証情報が使用される。
ラボマシンに RDP 接続
Connect-LabVM -ComputerName <コンピュータ名>
Windows標準のリモートデスクトップクライアント (mstsc)を使うのも可。
mstsc /v:<コンピュータ名>
その他
任意の資格情報で PSRemoting セッションを確立
$sess = New-LabPSSession -ComputerName <コンピュータ名> -Credential <PSCredential>
任意の資格情報で PS セッションを確立できる。これは、ラボのインストール後にドメイン管理者のパスワードを変更した場合に効果を発揮する。
ラボはインストール後にパスワードが変更されたことを検知することができず、ログインに失敗してしまう。
返り値の PSSession を利用して、以下のようにラボマシンに対して PS セッションを開くことができる。
Enter-PSSession -ComputerName <コンピュータ名> -Session <PSSession>
ファイル転送 (ホスト->ラボマシン)
Copy-LabFileItem -ComputerName <コンピュータ名> -Path <ホストコンピュータの送信元ファイル/ディレクトリ> -DestinationFolderPath <ラボマシンの送信先フォルダ>
ホストコンピュータからラボマシンにファイルを転送する。
ラボ構築時の管理者ユーザの認種情報が使われる。ファイル/フォルダは全て読み取り専用の属性を付与して配置される。
ファイル転送2 (ホスト->ラボマシン)
Send-File -SourceFilePath <ホストコンピュータの送信元ファイル> -DestinationFolderPath <ラボマシンの送信先フォルダ> -Session <PSSession> Send-Directory -SourceFolderPath <ホストコンピュータの送信元ディレクトリ> -DestinationFolderPath <ラボマシンの送信先フォルダ> -Session <PSSession>
任意の PSSession 情報を利用してラボマシンにファイルを送信する。
ラボのインストール後にドメイン管理者のパスワードを変更した場合に効果を発揮する。
ファイル転送 (ラボマシン->ホスト)
Receive-File -SourceFilePath <ラボの送信元ファイル> -DestinationFolderPath <ホストコンピュータの送信先フォルダ> -Session <PSSession> Receive-Directory -SourceFolderPath <ラボの送信元ファイル> -DestinationFolderPath <ホストコンピュータの送信先フォルダ> -Session <PSSession>
任意の PSSession 情報を利用してラボマシンからファイルを受信する。
ラボのインストール後にドメイン管理者のパスワードを変更した場合に効果を発揮する。
ーーー
まだまだ書き足りないですが、とりあえずここまで書いておけば使ってくれるひとが出てくると信じています。
みなさんも AutomatedLab でAD検証生活を楽にしましょう！
