DEV Community: ryanc

AWS Managed ADのユーザーをGoogleに同期する

ryanc — Wed, 30 Jun 2021 02:19:42 +0000

AWS Managed AD x AWS SSOでGoogle Workspaceにログインするの記事で、AWS Managed Microsoft ADとAWS SSOを利用し、Google Workspaceにシングルサインオンする方法を紹介した。

シングルサインオンをセットアップしただけなので、この時点ではユーザーの同期（プロビジョニング）は行われていない。つまり、AD側でユーザーを作成したり削除したりしたら、Google側でも同じ操作をしてあげなければならない。

認証はシングルサインオンで行うのでパスワード管理を別々にする必要はないとしても、これじゃ大規模組織のユーザー管理は非現実的だ。なので、ユーザー同期もセットアップしてみる。

GoogleはGoogle Cloud Directory Sync（GCDS）というツールを提供しているため、これを利用する。

設定手順はこちらのGoogleのドキュメントの通りでOK。
https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-synchronizing-user-accounts

なお、単純に同期を設定する前に、当然ADとGoogleでは設計思想が異なるしユーザー同期においても色々と検討すべきことがある。かなり長いが、こちらの概要のドキュメントをしっかり読んでおくことをおすすめする。
https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-introduction

今回は、GCDS専用のEC2インスタンスをt2.mediumでたててそこにC\GCDSインストールした。ユーザー同期用に利用するAD側ユーザー（手順内では「gcds」）は特に管理者権限を与えなくても大丈夫だったので、AWS Managed ADでも特に問題なく利用できる。

唯一Googleのドキュメントの手順に加えて要検討だったのは「ユーザーのプロビジョニング」→「ユーザーマッピングの構成」の中のユーザーの「Search Rule」だ。

ここではBase DNを空にしているが、AWS Managed ADはゼロから構築したADとは少しOU構造が異なるので、内部システム用アカウント等を誤って拾わないように、Base DNはAWS Managed ADのユーザーに割り当てられたOUのDNを設定した。

※今回は、NETBIOS名「CREATIVE」を指定しているので、DNは「OU=CREATIVE,DC=your-domain,DC=com」という感じになっている

DNの書き方が分からない人は、こういうやりかたで確認できる。

Active Directory Users and Computersの管理画面から、Advanced Features（詳細設定）を表示させるよう設定する。

AWS Managed ADで管理されるOUがNETBIOS名で表示されているはずなので（この例では「CREATIVE」）、これを右クリックしてプロパティを表示。

Attribute Editorタブで、distinguishedNameを探して、その値を控えればそれがDNだ。

そんなこんなで、GCDSの設定も終わり、AD側で新たに作成したユーザーが問題なくGoogleにも作成されたことを確認できた。

あとはこれをまたドキュメントの手順通りに定期実行されるように設定すれば、自動化完了。

AWS Managed AD x AWS SSOでGoogle Workspaceにログインする

ryanc — Mon, 28 Jun 2021 02:38:18 +0000

Google Workspace（旧G Suite）のアプリケーションを使いたいけど、ユーザー管理はActive Directoryで行いたいというケースもあるだろう。

言い換えると、ADを認証プロバイダー（Identity Provider、IdPとも書く）として利用し、Google Workspaceをそれと連携するカスタムSAMLアプリケーションとして登録するということになる。

ADFSをたてて連携させたり、ADのユーザーをGoogleと同期させる方法もあるようだがAWS Managed Microsoft AD（以下AWS Managed AD）を使っている場合は、少し面倒だ。前者はできると思うが、後者に関しては未確認。

そこで、AWSのシングルサインオンサービスのAWS SSOを利用すればサーバーをたてて何かしらインストールする必要なく、その辺りのフェデレーションをやってくれるので楽に連携できる。

AWS Managed ADを構築していて、ちゃんと機能している
AWS SSOを有効にさせてある（セットアップはしていなくても良い）上記の2つのことを前提に、Google Workspaceとの連携をしてみるとする。

なお、当たり前だが、しっかりユーザーのフェデレーションを行うためにはGoogle側のユーザーとADのユーザーは同じドメイン名を利用している必要がある。組織が持っているちゃんとしたパブリックドメインを利用するということだ（.localではだめなので、ADのドメインが.localならパブリックドメインでalternative UPNを追加しておくこと）。

AWS Managed ADでは、パブリックドメインであっても.localであってもディレクトリを作成する際に検証がはしるということはないのだが、Google側はちゃんと自分が持っているドメインじゃないとカスタムドメインとして利用できないので注意。

まずはAWS SSOの画面から、認証プロバイダーを設定する。

Active DirectoryをIDのソースに指定した上で、ディレクトリの一覧から、正しいAWS Managed ADを選択する。

設定が完了すると、こんな状態になっているはず。

次に、Googleのアプリケーションを追加する。

左側ナビゲーションの「アプリケーション」を選択し、新規アプリケーションの追加からG Suiteを検索する。ここはまだ名前が更新されてなくて旧名称のG Suiteになっているのね。

アプリケーションの追加時に、設定画面にていくつか情報を控える必要がある。

AWS SSO サインイン URL
AWS SSO サインアウト URL
をコピーしておいて、
AWS SSO 証明書
をダウンロードしておく。

他に、「アプリケーションのプロパティ」と「アプリケーションメタデータ」の設定が必要だが、

「アプリケーション開始 URL」：https://www.google.com/a/<自分のドメイン名>

「アプリケーション SAML メタデータファイル*」は手動でのメタデータ入力に切り替えた上で、

「アプリケーション ACS URL*」：https://www.google.com/a/<自分のドメイン名>/acs
「アプリケーション SAML 対象者*」：google.com/a/<自分のドメイン名>

にそれぞれ設定する。何を設定するかを説明してくれるGoogleのヘルプページがあるが、ここでは省くとする。

次に、ちょっと作業場所を変えて今度はGoogle側でSSOの設定とユーザー作成を行う。

組織の管理者としてGoogle Admin画面にログインし、セキュリティ→シングルサインオンの設定に進む。設定が2つあるが、

「SAMLアプリケーションに対するシングルサインオン（SSO）の設定」は、今回とは逆のシナリオで使うものだ。つまり、Google側が認証プロバイダーとして、AWS管理コンソール等にログインしたい場合。

「サードパーティの ID プロバイダを使用したシングルサインオン（SSO）の設定」が、今回使うものなので間違いのないように。

見ていただければもうお分かりだと思うが、先程AWS SSO側で控えた情報をこちらにセットする。

「ログインページのURL」：AWS SSO サインイン URL
「ログアウトページのURL」：AWS SSO サインアウト URL
「確認用の証明書」：AWS SSOからダウンロードした証明書
「ドメイン固有の発行元を使用」：チェックを入れる

設定が完了したら、保存を行う。

次は、Google側のユーザーにADと同じメールアドレスのユーザーが存在していることを確認し、まだないのであれば作成しておく。

※この例では、ユーザーの自動同期（プロビジョニング）は行っていない

再度AWS SSOに戻り、アプリケーションにユーザーの割当を行う。

さきほど追加したアプリケーションの「割り当て済みユーザー」タブから、「ユーザーの割り当て」を選択し、アプリケーションを利用させたいユーザーやグループを割り当てる。

ここまで終わったら、直接AWS SSOのポータル画面からログインしてみる。

アプリケーション一覧に、ちゃんとG Suiteがある。

G Suiteのアイコンを選択すると、ちゃんとシングルサインオンできた。

Systems Manager Run CommandでAWS Managed Microsoft ADを操作する

ryanc — Tue, 11 May 2021 03:06:20 +0000

AWS Managed Microsoft AD（以下Managed AD）を管理するには、リモート管理ツールをインストールした管理用サーバー（または踏み台サーバー）が別途必要なのが世の常だが。。オペレーションを自動化したい、またはサーバーにリモートデスクトップすることなくPowerShellコマンドレットを実行してぱぱっとやっちゃいたい、と思うこともあるだろう。

そう、まさにSystems Manager Run Commandで普通のWindows Server EC2インスタンスに対してできるように。

ただ、これにはハードルが2つある。

①Managed ADのドメインコントローラーはEC2インスタンスじゃないので、Run Commandのターゲットに指定できない

②Run Commandはインスタンスのローカルシステムアカウントとして実行されるのだが、ドメインコントローラーに対する操作はそれなりの権限を持った「ドメインユーザー」として実行する必要がある

①に関しては、直接ドメインコントローラーに対してではなく、同じドメインに属している別のEC2インスタンスに対して実行し、そのコマンド自体がドメインコントローラーに対して操作を実行するという構図にしよう。

結局踏み台必要じゃないか！
というツッコミは華麗にスルーして、「でもリモートデスクトップする必要はないし、Run Commandが実行できる条件さえ整っていればどのサーバーでもいいよ」とつぶやいてみる。

ちなみに、PowerShell CoreをLambda関数に載せて完全にサーバーレスでできたら美しいだろうな。。しかしAD関連をPowerShell Coreでやるのはかなりややこしくなるのでここでは原始的に踏み台サーバーを使うとしよう。

②に関しては、実行したいコマンドレットに依存するが、別のユーザーとして実行する機能を活用する。詳しくは実際の実行サンプルにて。

用意するもの：
a. ドメインユーザーの認証情報を保存したSecrets Managerシークレット

b. Secrets Managerシークレットを参照できるEC2インスタンスプロファイル

c. Systems Manager Run Commandを実行でき、かつManaged ADのドメインに参加しているWindows ServerのEC2インスタンス

d. Systems Manager Run Commandドキュメント

a.とb.は、この投稿と作成の仕方は同じなのでどうぞご参考に。

c.は各自調達しましょうね。

d.を次のように作成してみた。

今回は、ちょっとややこしいDNSフォワーダ設定をしてみるとしよう。

柔軟性のあるドキュメントにしたいので、パラメータを次のように設ける。

DomainController1: DNSサーバーのIPアドレス（その一）
DomainController2: DNSサーバーのIPアドレス（その二）
DNSForwardDestination: DNSフォワード先のIPアドレス
UserCredentialSecretID: ドメインユーザーの認証情報が格納されているSecrets ManagerシークレットのID

Managed ADのDNSサーバーはドメインコントローラー上にあるので、Directory Serviceの管理コンソールからIPアドレスを確認できる。

以下、Run Commandドキュメント。

---
schemaVersion: "2.2"
description: "Overwrites DNS Forwarder settings"
parameters:
  DomainController1:
    type: String
    description: "コマンド実行する対象のDNSサーバーのIPアドレス（その一）"
  DomainController2:
    type: String
    description: "コマンド実行する対象のDNSサーバーのIPアドレス（その二）"
  DNSForwardDestination:
    type: String
    description: "設定したいDNSのフォワード先IPアドレス"
  UserCredentialSecretID:
    type: String
    description: "AD参加に利用するユーザー認証情報を保持するSecrets ManagerシークレットID"
mainSteps:
- action: "aws:runPowerShellScript"
  name: "addDnsForwarder"
  inputs:
    runCommand: 
    - $secretManager = Get-SECSecretValue -SecretId "{{UserCredentialSecretID}}"
    - $secret = $secretManager.SecretString | ConvertFrom-Json
    - $username = $secret.Username
    - $password = $secret.Password | ConvertTo-SecureString -AsPlainText -Force
    - $credential = New-Object System.Management.Automation.PSCredential($username,$password)
    - $cimsession = New-CimSession -Credential $credential
    - Write-Output "Overwriting DNS Forwarder setting  ----"
    - Add-DnsServerForwarder -CimSession $cimsession -ComputerName {{DomainController1}} -IpAddress {{DNSForwardDestination}} -PassThru
    - Add-DnsServerForwarder -CimSession $cimsession -ComputerName {{DomainController2}} -IpAddress {{DNSForwardDestination}} -PassThru

各パラメータをうまく当てはめて、PowerShellでAdd-DnsServerForwarderコマンドレットを実行するだけ。

実際にこのドキュメントをRun Commandで実行してみて、問題なくDNSフォワーダの設定が入ったことを確認。よかった。

ドキュメントにしてしまえば、EventBridgeで定期実行するとか、アドホックでAWSコンソールから実行するとかもできるので、サーバーにログインする必要がなくなり便利だしセキュリティも向上する。

ちなみに、ここでポイントになるのがAdd-DnsServerForwarderを「ドメインユーザー」として実行できるかという話。

このコマンドレットは-CimSessionスイッチがあるので、他のユーザーとしてのセッションとして実行することができる。他にも-Credential等のスイッチを持っているコマンドレットならできるが。。そういったスイッチを持っていないコマンドレットだと一気にややこしくなる。

ということで今日は以上。

EC2インスタンス作成時にホスト名変更＆AD参加する（RunCommand編）

ryanc — Wed, 21 Apr 2021 02:03:30 +0000

前回のUserData編に続き、達成したい目的は同じく下記のままで、

①（AWS Managed ADではない）ADに参加
②ホスト名を、自分がつけたNameタグの値に揃える

やり方をUserDataではなくもうちょっと柔軟なSystems Manager RunCommandを利用する方法を試していこうと思う。

Systems Managerを利用すると、もちろんできることの幅は非常に広がるのだが、その代わりSSMエージェントのインストールとインスタンスプロファイルの設定等、必要条件を満たす必要はある（Amazon提供のAMIならエージェントは最初から入っているので楽）。

インスタンスプロファイルに必要なIAM権限と、シークレットマネージャーへのADユーザー認証情報の登録等は前回同様なので省略する。

Systems Managerの「ドキュメント」を開き、「Create Document」からCommand or sessionタイプを選択する。

ドキュメントの詳細はこんな感じで作成する。

ドキュメントタイプはコマンドドキュメントになる。

肝心なコマンドのコンテンツだが、前回のPowerShellスクリプトをそのまま流用して、大事そうなパラメータが指定できるようにだけ少し手を入れてYAML形式にしてみた。

---
schemaVersion: "2.2"
description: "Join AD and rename host with instance tag"
parameters:
  DomainName:
    type: "String"
    description: "参加するADドメインのDNS名"
  UserCredentialSecretID:
    type: "String"
    description: "AD参加に利用するユーザー認証情報を保持するSecrets ManagerシークレットID"
  HostnameTag:
    type: "String"
    description: "ホスト名を定義するタグ名（デフォルトはName）"
    default: "Name"
mainSteps:
- action: "aws:runPowerShellScript"
  name: "example"
  inputs:
    runCommand:
    - $secretManager = Get-SECSecretValue -SecretId {{UserCredentialSecretID}}
    - $secret = $secretManager.SecretString | ConvertFrom-Json
    - $username = $domainName + "\" + $secret.Account
    - $password = $secret.Password | ConvertTo-SecureString -AsPlainText -Force
    - $credential = New-Object System.Management.Automation.PSCredential($username,$password)
    - $instanceID = Get-EC2InstanceMetadata -Category InstanceId
    - $nameTag = Get-EC2Tag -Filter @{Name="resource-id";Value="$instanceID"},@{Name="key";Value="{{HostnameTag}}"}
    - $newName = $nameTag.Value
    - Add-Computer -DomainName "{{DomainName}}" -NewName "$newName" -Credential $credential -Passthru -Force -Restart

（パラメータ値は{{}}で囲む）

これで実際にRun Commandで実行する際には、こんな感じでパラメータを指定できるしEC2インスタンスの初回起動時じゃなくてもいつでも実行でき、たくさんのインスタンスに対しても一気に実行できるので一気に柔軟性が増す。

一々パラメータ設定が面倒であれば、デフォルト値をセットしてしまえば良し。

実際にやってみたが問題なく動作した。

今回は以上。次Chef好き向けにOpsWorksでやってみようかと思う。

※イラストはこちらからご提供いただきました：
Computer vector created by macrovector - www.freepik.com

EC2インスタンス作成時にホスト名変更＆AD参加する（UserData編）

ryanc — Mon, 19 Apr 2021 13:18:48 +0000

検証環境でWindows Serverをたくさんたてるのだが、
①（AWS Managed ADではない）ADに参加
②ホスト名を、自分がつけたNameタグの値に揃える
これはだいたい必ずやる。②に関しては、自動的につけられるランダムなホスト名だと分かりづらいので早々に自分がつけたい名前にしておきたいという意図。

これを一々手動でやるのはとても面倒なので（再起動も発生するし）、もちろん自動化したい。自動化する方法は色々あるが、今回は一番原始的（？）UserDataスクリプトを利用する方法を使ってみる。

ちなみにUserDataスクリプトはインスタンス作成時の一回しか実行されないので、少々柔軟性にかけるし、何かしらの問題でスクリプト実行が失敗したら手動で直さないといけない。とはいえアドホックでやるには簡単な方法だし楽な場合もある。

AWS Managed ADを使う場合は、インスタンス作成時に簡単に指定できちゃうのだが、EC2上に構築したADや、オンプレのAD等の場合はこういう方法を使う必要がある。

ドメイン参加にはその権限を持ったドメインアカウントが必要なのだが、その認証情報をスクリプトにハードコードしたくはないのでSecrets Managerを使うとしよう。

「その他シークレット」のタイプで作成。
参加するドメインはonprem.example.comという設定だ。

こんな感じでドメインアカウントのユーザー名とパスワードを設定しておく（もちろん、コンピュータをドメイン参加させる権限のあるアカウントを使ってね）。

onprem.example.com/DomainJoinという名前でシークレットを作成した。

ここから先は、EC2インスタンスプロファイル（IAMロール）にこの2つの権限が必要になってくる。
①さきほど作成したシークレットonprem.example.com/DomainJoinを読み取る権限
②EC2のタグを読み取る権限（Nameタグの値を読み取って、ホスト名に使う必要があるので）

こんな感じのポリシーを最低限追加しておく必要あり。

"Statement": [
        {
            "Sid": "ReadTag",
            "Effect": "Allow",
            "Action": "ec2:DescribeTags",
            "Resource": "*"
        },
        {
            "Sid": "SecretsMgrRead",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "arn:aws:secretsmanager:<リージョン>:<AWSアカウント番号>:secret:onprem.example.com/DomainJoin-tewFSS"
        }
    ]

secretsmanager:GetSecretValueアクションの権限で指定するResourceの値は、さきほど作成したシークレットのARNを代入する。Secrets Managerで簡単に確認できる。

これで準備が揃ったので、こういうスクリプトをUserDataに貼り付けて、Windows ServerのEC2インスタンスをたてる。
※AWS Tools for PowerShellを使うので、Amazonが提供する標準Windows ServerのAMIを使っていることを想定。自前のAMIを使うのであれば、AWS Tools for PowerShellをイメージにあらかじめ入れておく必要あり。

<powershell>
# ドメイン名とシークレット名を定義
$domainName = "onprem.example.com"
$secretName = "onprem.example.com/DomainJoin"

# シークレットの値をとってくる
$secretManager = Get-SECSecretValue -SecretId $secretName

# シークレットの値をオブジェクトに入れる
$secret = $secretManager.SecretString | ConvertFrom-Json

# ドメイン参加用認証情報を作成
$username = $domainName + "\" + $secret.Account
$password = $secret.Password | ConvertTo-SecureString -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($username,$password)

# EC2インスタンスメタデータからインスタンスIDを取得し、続けてNameタグを取得
$instanceID = Get-EC2InstanceMetadata -Category InstanceId
$nameTag = Get-EC2Tag -Filter @{Name="resource-id";Value="$instanceID"},@{Name="key";Value="Name"}
$newName = $nameTag.Value

# ドメイン参加を実施
Add-Computer -DomainName "$domainName" -NewName "$newName" -Credential $credential -Passthru -Force -Restart
</powershell>

これで、EC2インスタンス作成と同時にドメイン参加・ホスト名変更までできた。ローカルアドミンのパスワードを一度も復号化する必要なくドメインアカウントでログインできるので便利。

ちなみに、ドメイン参加のためにはドメインコントローラーを名前解決できる必要があるので、
①Route 53 Resolverのアウトバウンドエンドポイントを作成し、ルールでADドメインの名前は、ADのDNSサーバーにルーティングさせる
②DHCPオプションセットを設定しておく
③UserDataスクリプトに、DNS設定をADに向けるように設定する操作を追加する
のどれかをする必要はある（他にも方法あるかも）。
私の場合は、①を設定しているので他の設定は特に不要。

次回にはSystems Manager Automationを使う方法かChefを使う方法を試そうかなと思う。

※イラストはこちらからご提供いただきました：
Computer vector created by macrovector - www.freepik.com

CloudWatch LogsでWindows Defenderのログを収集する

ryanc — Fri, 16 Apr 2021 06:47:42 +0000

Amazon CloudWatch LogsにCloudWatch統合エージェントをインストールしてイベントログを収集する方法は、公式ドキュメントやその他ブログ記事もたくさんあり、そのまま従えば良いのだが、一番よくあるSystem、Application、Securityのログ以外にちょっとマニアックなもの（今回はWindows Defender）のイベントログをとるには、エージェントのconfigはどう書けばいいのか質問を受けたことがある。

まあ色々試せば誰でも発見できると思うが、あまり記事も見かけないし忙しい人達が自分で試す手間も減らしたいので、共有しようと思う。

configに使うevent_nameが、SystemやSecurityだとそれぞれそのまま記載すればいいのだが、それ以外のマイナーなイベントログだと何を指定するか知る必要がある。その確認方法は下記の通り。

Windows Serverで、compmgmt.mscを実行し、イベントビューアを展開する。

Windows Defenderのログは、Applications and Services Logs → Microsoft → Windows配下にある。

あった。

右側のペインのOperationalを右クリックし、プロパティを表示する。基本的にこのOperationalログが必要なもののようだ。

プロパティウィンドウで表示されているFull Nameが、必要なevent_nameに相当するので、これをコピーする。この場合はMicrosoft-Windows-Windows Defender/Operationalだった。

つまり、CloudWatchのconfigの中でこのイベントログの拾い方の定義は下記のように記述すれば良い。

{
"event_format": "xml",
"event_levels": [
"INFORMATION",
"WARNING",
"ERROR",
"CRITICAL"
],
"event_name": "Microsoft-Windows-Windows Defender/Operational",
"log_group_name": "WindowsDefender",
"log_stream_name": "{instance_id}"
},

例えばEvent ID 5007でフィルターしたい、という場合はCloudWatch Logsのフィルターパターンで下記のようにパターン定義すれば良いということになる。

問題なくWindows DefenderのログがCloudWatch Logsに連携されていることを確認した。

こんな感じで、どんなWindowsイベントログでもCloudWatchに連携できるはず！

Amazon FSx for Windows File Serverで隠し共有フォルダを作る

ryanc — Thu, 15 Apr 2021 13:30:21 +0000

Windowsのファイルサーバーで隠し共有フォルダを作ることは簡単だ。Amazon FSx for Windows File Serverでもできないわけがない。うん。
でもまだしたことがなかったので、一応試してみた。

まずAWS管理コンソールから、FSxファイルシステムのDNS名を確認する。

そして同じADに所属しているWindows Serverからfsmgmt.mscを起動する。

「操作」→「別のコンピューター」を選んで、FSxファイルシステムのDNSの名を入力する。

ちゃんと権限を持っているユーザーであれば、接続して現在の共有フォルダの一覧を確認できる。

次に、共有フォルダ用のファイルを格納するための物理フォルダを新たに確保するとしよう。secretと名付けたフォルダをD:\直下に作る。
これは、普通に\\FSxのDNS名\D$でD:\のウィンドウを開き、その下に新規フォルダを作れば良い（もちろんコマンドプロンプトかPowerShellで、フルパスを指定してmkdirかNew-Itemしても良い）。

前から使っていたshareとshare2に加えてsecretを作った。

ではfsmgmt.mscに戻って、メニューから「操作」→「新しい共有」を選ぶ。

共有フォルダ作成のウィザードの2ページ目で、さきほど新たに作成したD:\secretフォルダを指定する

次のページで、共有名の最後に「$」をつける。隠しフォルダにするためにこれが必ず必要。今回は無難にsecret$と名付けた。

アクセス許可を適切に設定して、完了すればOK。

アクセス権限がある場合でも、普段はDNS名だけでアクセスすると一覧が表示されてしまう共有フォルダが、隠し仕様だと表示されない。明示的に共有名を知っていてパスをアクセスした場合のみアクセスできる。

secret$は表示されない。。

でも直パスでアクセスすると、ちゃんと使える。

ちなみに、共有フォルダの「共有のアクセス許可」と「セキュリティ」両方の設定で許可されていなければ、ユーザーはアクセスできないので注意。

やはりFSx for Windows File Serverでも問題なく隠し共有フォルダを作成して利用できた。

SharePoint OnlineのデータをAWSに同期/移行/コピーする

ryanc — Tue, 16 Mar 2021 09:43:09 +0000

SharePoint Online上のアプリケーションによって書き込まれるリストデータと、ドキュメントライブラリに保存されるファイルをAWSに同期するという要件があり、久しぶりにSharePoint Onlineからのデータエクスポート方法やらPowerShellコマンドレットやらを調べた。

SharePointに馴染みのない方のために超ざっくりした説明をつけると、

リスト：RDBでいうテーブル。データ型を指定したカラムで構成されたデータが行単位で並ぶ。バックエンドはSQL Serverのテーブル
ライブラリ：階層化された共有フォルダみたいなもので、どんどんファイルを入れていくところ。アクセス権限やバージョン管理ができる

TestSiteというSharePointサイトにTestListというリストとTestLibraryというライブラリを作った（ネーミングセンスはご容赦ください）。

AWS Toolsも使いやすいので、全体的にPowerShellでやっていく。
SharePoint Onlineからデータを取得するのに使うライブラリには主にCSOMとPnPがあるが、PnPの方が新しく、使いやすい。
[https://docs.microsoft.com/ja-jp/powershell/sharepoint/sharepoint-pnp/sharepoint-pnp-cmdlets?view=sharepoint-ps]

データ同期バッチを動かすためのWindows Serverが既にEC2上にあったので、そこで作業する。

まずPnPモジュールをインストールしておく。
Install-Module -Name PnP.PowerShell

リストデータのエクスポート

こんな感じのコードで、SharePoint Onlineに接続しローカルにデータをダウンロードできる。

# SharePointへのアクセス情報
$userName = "<データにアクセスできるユーザー@hogehoge.onmicrosoft.com>"
$userPassword = "<パスワード>"

$siteURL = "https://hogehoge.sharepoint.com/sites/TestSite/"
$secPasswd = ConvertTo-SecureString $userPassword -AsPlainText -Force

[System.Management.Automation.PSCredential]$PSCredentials = New-Object System.Management.Automation.PSCredential($userName, $secPasswd)

# PnPでSharePoint Onlineに接続する
Connect-PnPOnline -Url $siteURL -Credentials $PSCredentials

# リストのデータを取得する
$listName = "TestList"
$selectedFields = @("Title","Age", "Occupation")
$CSVPath = "C:\work\SPOnline\PnPListData.csv"

$listItems = Get-PnPListItem -List $listName -Fields $selectedFields -PageSize 500

# 取得したオブジェクト型データをイタレートしながら処理する
$listDataColl = @()
$listItems | ForEach-Object {
    $listData = New-Object PSObject
    $listItem  = Get-PnPProperty -ClientObject $_ -Property FieldValuesAsText
    ForEach($Field in $selectedFields)
    {
        $listData | Add-Member Noteproperty $Field $listItem[$Field]
    } 
    $listDataColl += $listData 
}
$listDataColl | Export-CSV $CSVPath -NoTypeInformation

これで「C:\work\SPOnline\PnPListData.csv」にCSV形式でTestListの中身がエクスポートされる。CSVに吐かずとも、その場で色々処理したりすることももちろん可能。やろうと思えばそのままDynamoDBかRDSに挿入できる（ちょっとパフォーマンスが心配だが）。

ちゃんとCSVにエクスポートできた。

ライブラリファイルのエクスポート

「PnPでSharePoint Onlineに接続する」の「Connect-PnPOnline」までは同じで、残りは次のようなコードでファイルをダウンロードする。

# ファイルの取得元ライブラリを指定
$folderSiteRelativeURL = "/TestLibrary"
$destinationFolder ="C:\work\SPOnline\PnP"

$Folder = Get-PnPFolder -Url $FolderSiteRelativeURL
$FolderURL = $Folder.ServerRelativeUrl.Substring($Folder.Context.Web.ServerRelativeUrl.Length)
$localFolder = $destinationFolder + ($FolderURL -replace "/","\")

# 取得したオブジェクト型データをイタレートしながら処理する
$filesColl = Get-PnPFolderItem -FolderSiteRelativeUrl $FolderURL -ItemType File
Foreach($File in $filesColl)
    {
        Get-PnPFile -ServerRelativeUrl $File.ServerRelativeUrl -Path $localFolder -FileName $File.Name -AsFile -force
        Write-host -f Green "`tDownloaded File from '$($File.ServerRelativeUrl)'"
    }

ちゃんとダウンロードできた。

この後は普通にAWS Tools for PowerShellを使ってWrite-S3ObjectなりすればOK。

EC2だとインスタンスプロファイル（IAMロール）を付与しておけば、S3にデータをPUTするためにアクセスキーとシークレットキーを生成しなくて良い点がプラス。

SharePoint側はユーザー名・パスワードを使っちゃっているが、ここもSecrets Managerを使うなりでハードコードを避けるか、そもそもパスワード認証以外にしたいところ。ここではその深堀りは割愛する。

rcloneを使ってみる

もう一つこんなごりごりスクリプト書かずに、何やら人気の高いOSSであるrcloneを使う方法もある。

https://rclone.org/

rcloneは色んなデータソースをサポートしていて、その中にはもちろんS3とSharePointもある。SharePoint OnlineのライブラリのバックエンドはどうやらOneDriveらしいので、OneDriveを選択すればOK。

rcloneをインストールしたら、設定でremoteを2つ作成する。
2つのリモート拠点を定義し、それらの間で（どっちの方向も可）コピーや同期ができるという概念。

S3向けには、4番の「Amazon S3 Compliant Storage Providers including AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM CO」を選ぶ。

.\rclone config

e) Edit existing remote      
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> n
name> S3
Type of storage to configure.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / 1Fichier
   \ "fichier"
 2 / Alias for an existing remote
   \ "alias"
 3 / Amazon Drive
   \ "amazon cloud drive"
 4 / Amazon S3 Compliant Storage Providers including AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM CO
S, Minio, and Tencent COS
   \ "s3"
~~~中略~~~
Storage> 4
** See help for s3 backend at: https://rclone.org/s3/ **

Choose your S3 provider.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / Amazon Web Services (AWS) S3
   \ "AWS"
 2 / Alibaba Cloud Object Storage System (OSS) formerly Aliyun
   \ "Alibaba"
 3 / Ceph Object Storage
   \ "Ceph"
 4 / Digital Ocean Spaces
   \ "DigitalOcean"
 5 / Dreamhost DreamObjects
   \ "Dreamhost"
 6 / IBM COS S3
   \ "IBMCOS"
 7 / Minio Object Storage
   \ "Minio"
 8 / Netease Object Storage (NOS)
   \ "Netease"
 9 / Scaleway Object Storage
   \ "Scaleway"
10 / StackPath Object Storage
   \ "StackPath"
11 / Tencent Cloud Object Storage (COS)
   \ "TencentCOS"
12 / Wasabi Object Storage
   \ "Wasabi"
13 / Any other S3 compatible provider
   \ "Other"
provider>     1
Get AWS credentials from runtime (environment variables or EC2/ECS meta data if no env vars).
Only applies if access_key_id and secret_access_key is blank.
Enter a boolean value (true or false). Press Enter for the default ("false").
Choose a number from below, or type in your own value
 1 / Enter AWS credentials in the next step
   \ "false"
 2 / Get AWS credentials from the environment (env vars or IAM)
   \ "true"
env_auth>     2
AWS Access Key ID.
Leave blank for anonymous access or runtime credentials.
Enter a string value. Press Enter for the default ("").
access_key_id>
AWS Secret Access Key (password)
Leave blank for anonymous access or runtime credentials.
Enter a string value. Press Enter for the default ("").
secret_access_key>

元々サーバー上にcredentialの環境設定があれば、ここで改めてアクセスキーを入力する必要はない（しない方が、コンフィグに書き込まれないので良い）。

以降はリージョンを選んだりと、難しいポイントは無し。

SharePoint Onlineの方は、26番の「Microsoft OneDrive」を選択する。

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> n
name> SP-Online  
Type of storage to configure.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
~~~中略~~~
26 / Microsoft OneDrive
   \ "onedrive"
27 / OpenDrive
   \ "opendrive"
28 / OpenStack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
   \ "swift"
29 / Pcloud
   \ "pcloud"
30 / Put.io
   \ "putio"
31 / QingCloud Object Storage
   \ "qingstor"
32 / SSH/SFTP Connection
   \ "sftp"
33 / Sugarsync
   \ "sugarsync"
34 / Tardigrade Decentralized Cloud Storage
   \ "tardigrade"
35 / Transparently chunk/split large files
   \ "chunker"
36 / Union merges the contents of several upstream fs
   \ "union"
37 / Webdav
   \ "webdav"
38 / Yandex Disk
   \ "yandex"
39 / Zoho
   \ "zoho"
         40 / http Connection
   \ "http"
41 / premiumize.me
   \ "premiumizeme"
42 / seafile
   \ "seafile"
Storage>     26
** See help for onedrive backend at: https://rclone.org/onedrive/ **

OAuth Client Id
Leave blank normally.
Enter a string value. Press Enter for the default ("").
client_id>
OAuth Client Secret
Leave blank normally.
Enter a string value. Press Enter for the default ("").
client_secret>
Choose national cloud region for OneDrive.
Enter a string value. Press Enter for the default ("global").
Choose a number from below, or type in your own value
 1 / Microsoft Cloud Global
   \ "global"
 2 / Microsoft Cloud for US Government
   \ "us"
 3 / Microsoft Cloud Germany
   \ "de"
 4 / Azure and Office 365 operated by 21Vianet in China
   \ "cn"
region>     1
Edit advanced config? (y/n)
y) Yes
n) No (default)
y/n>
Remote config
Use auto config?
 * Say Y if not sure
 * Say N if you are working on a remote or headless machine
y) Yes (default)
n) No
y/n> y
If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth?state=Be1GkMEtURoIXTTAF5jgXA
Log in and authorize rclone for access
Waiting for code...

「auto config」を利用すると認証が非常に便利に済むので、OAuth Client IdやOAuth Client Secretを入力する必要はない（ブランクのまま、Enterを押せばOK）。

このあとブラウザが立ち上がり、Microsoft365にログインすれば、このような画面が出てトークンを自動的にrcloneが取得する。

設定が終わったら、以下のようなコマンドでデータを同期することができるので、ジョブとして自動化するのも簡単。

./rclone sync SP-Online:/ S3:/sponline-to-s3-datacopy-test/

rcloneの機能で事足りるユースケースであれば、スクリプトを書かずに済むので便利。

というかAWSの内容はなく、ほとんどSharePoint Onlineの話になってしまった（苦笑）。しかしEC2上で試しているので、EC2を連携サーバーにできるという証明はできた。