セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってAmazon FSx for NetApp ONTAPにSMBで接続してみた
2024.06.18異なるドメインに参加しているファイルサーバーにアクセスしたいな
こんにちは、のんピ(@non____97)です。
皆さんは異なるドメインに参加しているファイルサーバーにアクセスしたいなと思ったことはありますか? 私はあります。
特に起こりうるシチェーションとしてはAmazon Workspaces(以降Workspaces)を使用している場合です。WorkspacesはManaged Microsoft AD(Managed MSAD)に参加させ、ファイルサーバーはオンプレミスやVPC上にあるセルフマネージドADに属しているという場面はよくあるかと思います。
異なるドメインに参加しているファイルサーバーにアクセスする場合は、ドメイン間で信頼関係を組んであげる必要があります。信頼関係の仕組みは以下Microsoft公式ドキュメントをご覧ください。
また、その場合どのようにしてグループアカウントの運用を行い、どのようにしてアクセス許可をすれば良いのかも気になるかと思います。
試しにAmazon FSx for NetApp ONTAP(FSxN)をセルフマネージドADに参加させ、セルフマネージドADと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってFSxNにSMBで接続をします。
いきなりまとめ
- セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってFSxNにSMBで接続することは可能
- FSxNのSMBサーバーが属しているドメインと異なるドメインのユーザーからのアクセスを許可したい場合は、SMBサーバーのドメインからアクセス許可したいドメインユーザーのドメインへの片方向の信頼関係を作成する
- マルチプロトコルアクセスの場合は双方向の信頼関係を組む必要がある
- ドメインユーザーをグローバルセキュリティグループやドメインローカルグループに所属させた場合、一度サインアウトされるまで所属しているグループに対するアクセス権限はドメインユーザーに反映されない
やってみた
検証環境
検証環境は以下のとおりです。
今回はcorp.non-97.netとnon-97.privateという2つのシングルフォレスト・シングルドメインの間で信頼関係(フォレストの信頼)を行います。なお、外部の信頼でも問題ないようです。
企業ドメインは信頼されたドメインのロールを担い、AWS Directory Service マネージドドメインは信頼するドメインのロールを担います。検証済み認証リクエストは、ドメイン間を一方向にしか移動しません。これにより、企業ドメインのアカウントがマネージドドメインで共有されているリソースに対して認証を行うことができます。この場合、Amazon FSx はマネージドドメインとのみ対話します。マネージドドメインは、認証リクエストを企業ドメインに渡します。
注記
信頼されたドメインに対して Amazon FSx で外部の信頼タイプを使用することもできます。チュートリアル 1:スタートするための前提条件 - Amazon FSx for Windows File Server
今回はセルフマネージドADからManaged MSADへの一方向の信頼関係を組みます。マルチプロトコルアクセスを実現するためにUNIXユーザーをドメインユーザーにマッピングする際は双方向で信頼関係を組む必要があるようです。
原因
ONTAPは最初にUNIXユーザを認証し、次にS4U2Selfを使用してWindowsクレデンシャルを構築します（トークングループへのフォールバック）。
Kerberos制約委任では、ドメインAのサーバ（サービス）が、ドメインBのユーザの認可情報を要求している場合、双方向の信頼が必要なユーザの代わりにサービスチケットを取得できる必要があります。
RFE 1052237-NFSマウントが混在/ NTFSセキュリティ形式のボリューム/ qtreeを使用していて、環境に一方向の信頼がある場合に中断される
解決策
- この問題を解決するには、双方向の信頼が必要です。
- 双方向の信頼によるエクスポージャーを制限するには、 選択認証を 使用して、CIFSサーバコンピュータオブジェクトなどの特定のオブジェクトのみが信頼を通過できないようにします。
- ファイル所有権の設定ワークフローの一環として 、ONTAPはユーザ（所有者として設定）のWindowsグループメンバーシップを取得して ユーザクレデンシャルを作成します。
- これにより、SVMは S4U2selfを使用してユーザのクレデンシャルを取得できます。これは 匿名のSAMRパイプを使用した場合に比べて正確であるだけでなく、より安全な 方法でもあります。
ONTAP は、一方向の信頼を介して、信頼できるドメインからWindowsユーザにUNIXユーザをマッピングすることができません - NetApp
シングルフォレスト・シングルドメインの場合はAGDLP、マルチフォレストの場合はAGUDLPが推奨とされているようです。
アルファベットのそれぞれの意味は以下のとおりです。
- A : Account (アカウント)
- G : Global Group (グローバルグループ)
- DL : Domain Local Group (ドメインローカルグループ)
- U : Universal Group (ユニバーサルグループ)
- P : Permission (権限)
急にユニバーサルグループやグローバルグループ、ドメインローカルグループと出てきましたが、こちらフォレストやドメインのリソースのグルーピングをする際に使用します。詳細は以下Microsoft公式ドキュメントをご覧ください。
ざっくりとした使い分けは以下で良いと思います。
- ユニバーサルグループ: フォレスト内の複数のドメイン内のユーザーをグルーピングする場合
- グローバルグループ: 単一ドメイン内のユーザーをグルーピングする場合
- ドメインローカルグループ: 特定のコンピューターやオブジェクトの権限設定をする場合
今回はシングルフォレスト・シングルドメインなのでAGDLPで行います。ユニバーサルグループを使ってフォレスト内の複数ドメインユーザーをまとめる必要はないためです。
AGDLPのイメージは以下のとおりです。
AGDLPを言葉で説明すると以下のとおりです。
- アカウント(A)を
- ドメイン内でグローバルグループ(G)を使ってまとめ
- グローバルグループをドメインローカルグループ(DL)に所属させ
- ファイル共有にて、ドメインローカルに対して権限を付与する(P)
つまりは、ドメインローカルグループを権限付与の単位で分け、グローバルセキュリティグループをユーザー管理単位を分離することになります。これにより、「この権限が割り振られているユーザーは、このグループに属している」や「これらの役職のユーザーには、まとめてこの権限を割り当てるべき」などが分かりやすくなり、ファイルサーバーへのアクセス権限の管理がしやすくなります。
一方、グローバルグループ個別に権限を割り当てるAGPはファイル共有数が増加する場合、ドメインローカルグループに直接ユーザーを所属させるADLPはユーザー数が増加する場合に権限を見直す回数が増加するため、管理がスケールしづらいです。これらで管理する場合は小規模環境で使用するようにしましょう。
corp.non-97.netのAD DCの作成
実際に試してみましょう。
corp.non-97.netのAD DCの作成は以下記事の検証で使用したものを流用します。
また、ドメインユーザーtest-user01とtest-user02を用意し、どちらもFSxAdminGroupというグローバルセキュリティグループに属させています。こちらも以下記事で用意したものを流用します。詳細はやってみた-ドメインユーザーの準備の章をご覧ください。
corp.non-97.netドメインに参加しているSMBサーバーの確認
FSxNファイルシステムはマネジメントコンソールから作成しました。
FSxNファイルシステムおよび、SVM(正しくはSMBサーバー)がドメイン参加するために必要なサービスアカウント作成方法は以下記事のやってみた-サービスアカウントの作成とやってみた-Amazon FSx for NetApp ONTAPのファイルシステムの作成を参考にしてください。
FSxNに接続して、corp.non-97.netドメインに参加しているSMBサーバーSVM.corp.non-97.netの状態を確認します。
> ssh <fsxadmin@management.fs-01f10c043502538c8.fsx.us-east-1.amazonaws.com>
The authenticity of host 'management.fs-01f10c043502538c8.fsx.us-east-1.amazonaws.com (10.0.8.27)' can't be established.
ECDSA key fingerprint is SHA256:P3tf0rtdzgJUWApBIgWZvDmI96cvvd+P/+SkCyXugz0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'management.fs-01f10c043502538c8.fsx.us-east-1.amazonaws.com,10.0.8.27' (ECDSA) to the list of known hosts.
Password:
This is your first recorded login.
Your privilege has changed since last login.
# SMBサーバーの確認
::> cifs show
Server Status Domain/Workgroup Authentication
Vserver Name Admin Name Style
----------- --------------- --------- ---------------- --------------
svm SVM up CORP domain
::> cifs show -instance
Vserver: svm
CIFS Server NetBIOS Name: SVM
NetBIOS Domain/Workgroup Name: CORP
Fully Qualified Domain Name: CORP.NON-97.NET
Organizational Unit: OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
Default Site Used by LIFs Without Site Membership:
Workgroup Name: -
Authentication Style: domain
CIFS Server Administrative Status: up
CIFS Server Description:
List of NetBIOS Aliases: -
# ファイル共有の確認
::> cifs share show
Vserver Share Path Properties Comment ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm c$ / oplocks - BUILTIN\Administrators / Full Control
browsable
changenotify
show-previous-versions
svm ipc$ / browsable - -
2 entries were displayed.
正常にドメイン参加していそうですね。
non-97.privateのManaged Microsoft ADの用意
non-97.privateのManaged Microsoft ADのマネジメントコンソールから作成します。
ディレクトリタイプではAWS Managed Microsoft ADを選択します。
今回は検証用途なのでStandard Editionを選択します。組織規模によってはEnterprise Editionを選択してください。なお、2024/6/18時点では作成後にEditionを変更することはできないのでご注意ください。
VPCやサブネットを選択します。
内容を確認してディレクトリの作成をクリックします。
30分ほど待つと、ステータスがアクティブになっていました。
Managed Microsoft ADにアタッチされているセキュリティグループは以下のとおりです。インバウンドルールで0.0.0.0/0で許可されているものが多いため、実際に運用する際は適切なレンジを指定することを推奨します。
-
Managed MSADのセキュリティグループのインバウンドルール
-
Managed MSADのセキュリティグループのアウトバウンドルール
non-97.private操作用EC2インスタンスの用意
non-97.private操作用EC2インスタンスの用意をします。
今回はAMIにWindows_Server-2022-Japanese-Full-Base-2024.05.15を使用しました。
起動完了後、Managed Microsoft ADを管理するEC2インスタンスに必要な機能をインストールします。
# 必要な機能のインストール
>
> $result = Install-WindowsFeature -Name RSAT-ADDS,RSAT-DNS-Server,GPMC
# インストールされている機能の確認
>
> $result.FeatureResult | Format-Table -AutoSize
Display Name Name Success # Msg Restart Needed Skip Reason
------------ ---- ------- ----- -------------- -----------
グループ ポリシーの管理 GPMC True 0 False NotSkipped
リモート サーバー管理ツール RSAT True 0 False NotSkipped
Active Directory 管理センター RSAT-AD-AdminCenter True 0 False NotSkipped
Windows PowerShell の Active Directory モジュール RSAT-AD-PowerShell True 0 False NotSkipped
AD DS および AD LDS ツール RSAT-AD-Tools True 0 False NotSkipped
AD DS ツール RSAT-ADDS True 0 False NotSkipped
AD DS スナップインおよびコマンドライン ツール RSAT-ADDS-Tools True 0 False NotSkipped
DNS サーバー ツール RSAT-DNS-Server True 0 False NotSkipped
役割管理ツール RSAT-Role-Tools True 0 False NotSkipped
インストール後、Managed Microsoft ADのドメイン(non-97.private)に参加します。参加する際に事前にDNSサーバーをManaged Microsoft ADを向けさせます。
# NIC情報からDNS Clientオブジェクト取得
>
> $client = Get-NetAdapter | Get-DnsClient
# 変更前設定確認
>
> $client | Get-DnsClientServerAddress -AddressFamily IPv4
InterfaceAlias Interface Address ServerAddresses
Index Family
-------------- --------- ------- ---------------
イーサネット 3 8 IPv4 {10.0.0.2}
# 設定変更
>
> $dnsServers = @("10.0.8.44", "10.0.9.185") # Managed Microsoft ADのIPアドレス
> $client | Set-DnsClientServerAddress -ServerAddresses $dnsServers
> $client | Get-DnsClientServerAddress -AddressFamily IPv4
InterfaceAlias Interface Address ServerAddresses
Index Family
-------------- --------- ------- ---------------
イーサネット 3 8 IPv4 {10.0.8.44, 10.0.9.185}
# ドメイン参加
>
> $password=ConvertTo-SecureString -AsPlainText -Force "<Managed Microsoft ADのAdminのパスワード>"
> $credential=New-Object System.Management.Automation.PSCredential("non-97.private\Admin",$password)
> Add-Computer -DomainName non-97.private -Credential $credential -Restart -Force
OS再起動後、non-97.private\AdminでRDP接続します。接続後、non-97.privateのAdminでログインしていることを確認します。
> whoami -fqdn
CN=Admin,OU=Users,OU=non-97,DC=non-97,DC=private
信頼関係の作成
以下ドキュメントを参考に、non-97.privateからcorp.non-97.net上のリソースにアクセスできるように、corp.non-97.netからnon-97.privateへ片方向の信頼関係を作成します。
事前準備として、corp.non-97.netのAD DCのセキュリティグループで、non-97.privateのManaged Microsoft ADからの全ての通信を許可します。
corp.non-97.netがnon-97.privateの名前解決ができるように、corp.non-97.netにてnon-97.privateへの条件付きフォワーダーを設定します。
# 現在のDNSサーバー設定の確認
>
> Get-DnsServerZone ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned
-------- -------- ------------- -------------- ------------------- --------
_msdcs.corp.non-97.net Primary False True False False
0.in-addr.arpa Primary True False True False
127.in-addr.arpa Primary True False True False
255.in-addr.arpa Primary True False True False
corp.non-97.net Primary False True False False
TrustAnchors Primary False True False False
# 条件付きフォワーダーの設定
>
> $fqdn = 'non-97.private'
> $dnsServers = @('10.0.8.44','10.0.9.185') # Managed Microsoft ADのDNS IPアドレス
> $params = @{
Name = $fqdn
MasterServers = $dnsServers
ReplicationScope = 'Domain'
}
> Add-DnsServerConditionalForwarderZone @params
# 条件付きフォワーダーが設定されたことを確認
>
> Get-DnsServerZone
ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned
-------- -------- ------------- -------------- ------------------- --------
_msdcs.corp.non-97.net Primary False True False False
0.in-addr.arpa Primary True False True False
127.in-addr.arpa Primary True False True False
255.in-addr.arpa Primary True False True False
corp.non-97.net Primary False True False False
non-97.private Forwarder False True False
TrustAnchors Primary False True False False
corp.non-97.netからnon-97.privateへ片方向の信頼関係を作成します。
まずはcorp.non-97.net側からです。
# 現在の信頼関係一覧
>
> Get-ADTrust -Filter *
# 信頼関係の作成
>
> $targetForestName = 'non-97.private'
> $trustPassword = '<信頼パスワード (後でManaged Microsoft AD設定時に使う)>'
> $trustDirection = 'Outbound'
> $forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
> $forest.CreateLocalSideOfTrustRelationship($targetForestName, $trustDirection, $trustPassword)
# 信頼関係が作成されたことを確認
>
> Get-ADTrust -Filter *
Direction : Outbound
DisallowTransivity : False
DistinguishedName : CN=non-97.private,CN=System,DC=corp,DC=non-97,DC=net
ForestTransitive : True
IntraForest : False
IsTreeParent : False
IsTreeRoot : False
Name : non-97.private
ObjectClass : trustedDomain
ObjectGUID : 420b253d-a88d-4de4-b0b6-5d22e12e4cb3
SelectiveAuthentication : False
SIDFilteringForestAware : False
SIDFilteringQuarantined : False
Source : DC=corp,DC=non-97,DC=net
Target : non-97.private
TGTDelegation : False
TrustAttributes : 8
TrustedPolicy :
TrustingPolicy :
TrustType : Uplevel
UplevelOnly : False
UsesAESKeys : False
UsesRC4Encryption : False
Managed Microsoft AD側でも信頼関係の作成を行います。
フォレストの信頼で、corp.non-97.netに対して入力方向で信頼するように信頼関係を作成します。10.0.0.139はcorp.non-97.netのAD DC用EC2インスタンスのIPアドレスです。
数分待ち、信頼関係の作成が完了したことを確認します。
信頼関係を作成すると同時にcorp.non-97.netに対する条件付きフォワーダーが設定されているため、non-97.privateのAdminユーザーでSVM.corp.non-97.netの名前解決ができることを確認します。
> nslookup SVM.corp.non-97.net
サーバー: ip-c61301d0.non-97.private
Address: 10.0.8.44
権限のない回答:
名前: SVM.corp.non-97.net
Address: 10.0.8.153
問題なく名前解決できました。
non-97.privateにRDP接続用ユーザーの追加
以下記事を参考にnon-97.privateにRDP接続用ユーザーを追加します。
作成するユーザーはtest-user-1とtest-user-2です。
# ユーザーの作成
>
> New-ADUser `
-Name "test-user-1" `
-UserPrincipalName "<[email protected]>" `
-Accountpassword (Read-Host -AsSecureString "AccountPassword") `
-Path "OU=Users,OU=non-97,DC=non-97,DC=private" `
-PasswordNeverExpires $True `
-Enabled $True
AccountPassword: ***********
> New-ADUser `
-Name "test-user-2" `
-UserPrincipalName "<[email protected]>" `
-Accountpassword (Read-Host -AsSecureString "AccountPassword") `
-Path "OU=Users,OU=non-97,DC=non-97,DC=private" `
-PasswordNeverExpires $True `
-Enabled $True
AccountPassword: **********************
# ユーザーが作成されたことを確認
>
> Get-ADUser -Filter "*" -SearchBase "OU=Users,OU=non-97,DC=non-97,DC=private"
DistinguishedName : CN=CORP$,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled : True
GivenName :
Name : CORP$
ObjectClass : user
ObjectGUID : 5944a11f-fe73-4e1c-bbcb-48c14b6071ad
SamAccountName : CORP$
SID : S-1-5-21-1859619966-4240876272-1758126325-1146
Surname :
UserPrincipalName :
DistinguishedName : CN=test-user-1,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled : True
GivenName :
Name : test-user-1
ObjectClass : user
ObjectGUID : 29ec8a3a-6fe5-41b7-961b-e3ca5732d31a
SamAccountName : test-user-1
SID : S-1-5-21-1859619966-4240876272-1758126325-1609
Surname :
UserPrincipalName : <test-user-1@non-97.private>
DistinguishedName : CN=test-user-2,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled : True
GivenName :
Name : test-user-2
ObjectClass : user
ObjectGUID : f981c655-784a-40b6-9ddd-3abb4055ee79
SamAccountName : test-user-2
SID : S-1-5-21-1859619966-4240876272-1758126325-1610
Surname :
UserPrincipalName : <test-user-2@non-97.private>
DistinguishedName : CN=Admin,OU=Users,OU=non-97,DC=non-97,DC=private
Enabled : True
GivenName :
Name : Admin
ObjectClass : user
ObjectGUID : 298727de-a19b-4bad-9b94-6598a93dfaa2
SamAccountName : Admin
SID : S-1-5-21-1859619966-4240876272-1758126325-1112
Surname :
UserPrincipalName : <admin@non-97.private>
rdp-groupというグローバルセキュリティグループを作成し、作成したユーザーを追加します。
non-97.privateのComputers OU内のコンピュータ内にRDP接続できるようにGPOを作成します。名前はrdp-gpoとしました。
rdp-groupに属するユーザーにRemote Desktop Users (ビルトイン)を適用します。
GPOを強制的に反映させます。
> gpupdate /force
ポリシーを最新の情報に更新しています...
コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。
non-97.privateのtest-user-1でRDP接続できることを確認します。
> whoami -fqdn
CN=test-user-1,OU=Users,OU=non-97,DC=non-97,DC=private
RDP接続できました。
ファイル共有の作成
SMBサーバー上でshare1というファイル共有を作成します。
::> cifs share create -vserver svm -share-name share1 -path /vol1
::> cifs share show
Vserver Share Path Properties Comment ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm c$ / oplocks - BUILTIN\Administrators / Full Control
browsable
changenotify
show-previous-versions
svm ipc$ / browsable - -
svm share1 /vol1 oplocks - Everyone / Full Control
browsable
changenotify
show-previous-versions
3 entries were displayed.
ファイル共有でEveryone Full Controlで許可している場合に、non-97.privateのユーザーが操作できることを確認
share1というファイル共有のACL(共有アクセス権)はEveryoneのFull Controlで許可です。
この状態でnon-97.privateのユーザーtest-user-1がファイル共有内で読み書きできるかを確認します。
# share1をマウント
>
> New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\SVM.corp.non-97.net\share1"
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Z FileSystem \\SVM.corp.non-97.net\share1
# share1上に書き込みできることを確認
>
> echo test.txt > Z:\test.txt
# 書き込みできたたことを確認
>
> ls Z:\
ディレクトリ: \\SVM.corp.non-97.net\share1
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2024/06/14 8:40 22 test.txt
> cat Z:\test.txt
test.txt
問題なく読み書きできました。
cifs session showで現在のセッション一覧を確認します。
::> cifs session show
Node: FsxId01f10c043502538c8-01
Vserver: svm
Connection Session Open Idle Connection
ID ID Workstation Windows User Files Time Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
2968530356 3286220353096908806 1m 47s 4
10.0.0.223 NON-97\test- 3
user-1
::> cifs session show -instance
Vserver: svm
Node: FsxId01f10c043502538c8-01
Session ID: 3286220353096908806
Connection ID: 2968530356
Incoming Data LIF IP Address: 10.0.8.153
Workstation IP Address: 10.0.0.223
Authentication Mechanism: NTLMv2
User Authenticated as: domain-user
Windows User: NON-97\test-user-1
UNIX User: pcuser
Open Shares: 1
Open Files: 3
Open Other: 0
Connected Time: 3m 0s
Idle Time: 1m 52s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 4
Active Shares: share1
現在接続しているnon-97.privateのtest-user-1のセッションを確認できました。
ドメインローカルグループの作成
それではcorp.non-97.net内にドメインローカルグループを作成し、AGDLPの形で権限を付与する準備をします。
domain-localというドメインローカルグループを作成しました。
作成したドメインローカルグループにcorp.non-97.netのFSxAdminGroupとnon-97.privateのrdp-groupを所属させます。
FSxAdminGroupのメンバーは以下のとおりです。
なお、corp.non-97.net上からnon-97.private上のリソースを参照する際に認証が求めらたら都度入力をしてあげます。
ドメインローカルグループに付与した権限で動作することを確認
ドメインローカルグループに付与した権限で動作することを確認します。
corp.non-97.netのdomain-localにReadを許可します。
# Everyone Full Controlの許可を削除
::*> cifs share access-control delete -share share1 -user-or-group Everyone
# corp.non-97.netのdomain-localにReadを許可
::*> cifs share access-control create -share share1 -user-or-group CORP\domain-local -user-group-type windows -permission Read
# 共有アクセス権限の確認
::*> cifs share access-control show -share share1
Share User/Group User/Group Access
Vserver Name Name Type Permission
-------------- ----------- --------------------------- ----------- -----------
svm share1 CORP\domain-local windows Read
この状態のイメージは以下のとおりです。(FSxAdminは割愛)
この状態でnon-97.privateのtest-user-1から読み込みできるか確認します。
> ls Z:
ls : アクセスが拒否されました。
発生場所 行:1 文字:1
- ls Z:
- ~~~~~
+ CategoryInfo : PermissionDenied: (Z:\:String) [Get-ChildItem], UnauthorizedAccessException
+ FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand
ls : パス 'Z:\' が存在しないため検出できません。
発生場所 行:1 文字:1
- ls Z:
- ~~~~~
+ CategoryInfo : ObjectNotFound: (Z:\:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
はい、拒否されました。
これはグループの変更は既存のセッションに影響を与えないためです。
ユーザーがリソース セッションを開始した後にユーザーのグループ メンバーシップが変更された場合、変更がユーザーのリソース アクセスに実際に影響を与えるタイミングは、次の要因によって制御されます。
- グループ メンバーシップの変更は、既存のセッションには影響しません。
既存のセッションは、ユーザーがサインアウトするか、それ以外の場合はセッションを終了するか、セッションの有効期限が切れるまで続行されます。 セッションの有効期限が切れると、次のいずれかが発生します。
- クライアントはセッション チケットを再送信するか、新しいセッション チケットを送信します。 この操作により、セッションが更新されます。
- クライアントはもう一度接続しようとしません。 セッションは更新されません。
- グループ メンバーシップの変更は、現在の TGT や、その TGT を使用して作成されたセッション チケットには影響しません。
チケット付与サービス (TGS) は、TGT からのグループ情報を使用して、Active Directory 自体にクエリを実行する代わりにセッション チケットを作成します。 TGT は、ユーザーがクライアントをロックするかサインアウトするか、TGT の有効期限が切れる (通常は 10 時間) まで更新されません。 TGT は 10 日間更新できます。一部の VPN 接続でグループ メンバーシップの変更が更新されない - Windows Client | Microsoft Learn
今回はtest-user-1にRDP接続してから、test-user-1が所属しているグローバルセキュリティグループrdp-groupを、ドメインローカルグループのdomain-localに所属させています。そのため、domain-localに対するアクセス権限を付与したとしても、既存のRDP接続のセッションには反映されません。
一度test-user-1のRDP接続からサインアウトして、再接続します。
再接続後同様の操作をしたところ、問題なく操作できました。
> whoami -fqdn
CN=test-user-1,OU=Users,OU=non-97,DC=non-97,DC=private
> ls Z:\
ディレクトリ: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2024/06/14 10:11 22 test.txt
> cat Z:\test.txt
test.txt
> echo test2.txt > Z:\test2.txt
out-file : パス 'Z:\test2.txt' へのアクセスが拒否されました。
発生場所 行:1 文字:1
- echo test2.txt > Z:\test2.txt
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (:) [Out-File], UnauthorizedAccessException
+ FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.OutFileCommand
意図したとおり、書き込みは拒否されていますね。
Full Controlを付与して書き込みできることを確認します。
::> cifs share access-control modify -share share1 -user-or-group CORP\domain-local -permission Full_Control
::> cifs share access-control show -share share1
Share User/Group User/Group Access
Vserver Name Name Type Permission
-------------- ----------- --------------------------- ----------- -----------
svm share1 CORP\domain-local windows Full_Control
> echo test2.txt > Z:\test2.txt
> cat Z:\test2.txt
test2.txt
> ls Z:\
ディレクトリ: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2024/06/14 10:11 22 test.txt
-a---- 2024/06/18 0:25 24 test2.txt
問題なく書き込みできました。
corp.non-97.netのtest-user01からも試してみます。
> whoami -fqdn
CN=test-user01,OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
> New-PSDrive -Name "Z" -PSProvider FileSystem -Persist -Root "\\SVM.corp.non-97.net\share1"
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Z 0.00 60.80 FileSystem \\SVM.corp.non-97.net\share1
> ls Z:\
Directory: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/14/2024 10:11 AM 22 test.txt
-a---- 6/18/2024 12:25 AM 24 test2.txt
> echo test3.txt > Z:\test3.txt
> ls Z:\
Directory: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/14/2024 10:11 AM 22 test.txt
-a---- 6/18/2024 12:25 AM 24 test2.txt
-a---- 6/18/2024 12:41 AM 24 test3.txt
> cat Z:\test3.txt
test3.txt
こちらでも問題なく読み書きできました。
セッション一覧を確認します。
::> cifs session show
Node: FsxId01f10c043502538c8-01
Vserver: svm
Connection Session Open Idle Connection
ID ID Workstation Windows User Files Time Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
2968530356 3286220353096908826 14m 20s 4
10.0.0.223 NON-97\test- 3
user-1
2968530389 3286220353096908829 14m 11s 4
10.0.0.139 CORP\test-user01 1
2 entries were displayed.
::> cifs session show -instance
Vserver: svm
Node: FsxId01f10c043502538c8-01
Session ID: 3286220353096908826
Connection ID: 2968530356
Incoming Data LIF IP Address: 10.0.8.153
Workstation IP Address: 10.0.0.223
Authentication Mechanism: NTLMv2
User Authenticated as: domain-user
Windows User: NON-97\test-user-1
UNIX User: pcuser
Open Shares: 1
Open Files: 3
Open Other: 0
Connected Time: 14h 36m 42s
Idle Time: 14m 48s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 4
Active Shares: share1
Node: FsxId01f10c043502538c8-01
Session ID: 3286220353096908829
Connection ID: 2968530389
Incoming Data LIF IP Address: 10.0.8.153
Workstation IP Address: 10.0.0.139
Authentication Mechanism: Kerberos
User Authenticated as: domain-user
Windows User: CORP\test-user01
UNIX User: pcuser
Open Shares: 1
Open Files: 1
Open Other: 0
Connected Time: 3h 56m 45s
Idle Time: 14m 39s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 4
Active Shares: share1
2 entries were displayed.
それぞれのセッションを確認できました。
test-user-1で、ファイル共有上のファイルをメモ帳で開き、cifs session file showで開いているファイル一覧に表示されるのかも確認しましょう。
::> vserver cifs session file show
This table is currently empty.
表示されませんね。
NetAppのKBを確認したところ、メモ帳はフォーカスが外れたタイミングでファイルを閉じてしまうようです。
によって報告されるオープンファイルの数は、アプリケーションによってvserver cifs session file show現在使用されている数です。アプリケーションの動作によっては、混乱を招く可能性があります。
たとえば、フォーカスが別のアプリケーションに移動されたときにメモ帳がファイルを閉じるのに対して、 Internet Explorer は使用されていない期間が経過するとファイルを閉じます。
vserver cifs session file showコマンドを実行して開いているファイルの数を確認しようとしている場合、ファイルロックはこの合計にカウントされます。 vserver locks show 代わりに使用できます。
「 vserver cifs session file show 」で開いているファイルが一部表示されないのはなぜですか？ - NetApp
メモ帳にでファイルを開いた瞬間にcifs session file showを叩いてみます。
::> cifs session file show
Node: FsxId01f10c043502538c8-01
Vserver: svm
Connection: 2968530356
Session: 3286220353096908826
Connection Count: 4
File File Open Hosting Continuously
ID Type Mode Volume Share Available
------- --------- ---- --------------- --------------------- ------------
42 Regular r vol1 share1 No
Path: test.txt
::> cifs session file show -instance
Node: FsxId01f10c043502538c8-01
Vserver: svm
File ID: 49
Connection ID: 2968530356
Session ID: 3286220353096908826
Connection Count: 4
File Type: Regular
Open Mode: r
Aggregate Hosting File: aggr1
Volume Hosting File: vol1
CIFS Share: share1
Path from CIFS Share: test.txt
Share Mode: rw
Range Locks: 0
Continuously Available: No
Reconnected: No
FlexGroup MSID: 0
開いているファイルの情報を確認できました。
信頼関係を組んで適切な権限を付与しよう
セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってAmazon FSx for NetApp ONTAPにSMBで接続してみました。
最低限片方向の信頼関係があれば問題なく接続できるようです。
アクセス権限の設定は組織規模や既存のグループ設計によって適切なものは異なると感じています。最初はAGPでスタートし、徐々にAGLDPに寄せていくという形も良いかなと思います。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] ONTAP接続時に使用するユーザーとロールを作成してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
