Active DirectoryサーバをLDAPサーバとして使っている場合、2026年10月のWindows Updateで接続できなくなる可能性

php2shellのパッチをダウンロードするためにONTAPのダウンロードページにアクセスしたら、phpに関する警告の他に、下記の警告も出ていた

AD-LDAP Authentication Errors After Microsoft October 2026 DC Patch Updates
Microsoft October 2026 domain controller (DCs) patches may affect AD-LDAP authentication requests from ONTAP to DCs resulting in protocol outrages or login disruptions. See SU628 for more details.

Active DirectoryサーバをLDAPサーバとして利用している場合、2026年10月のWindows Updateにより、平文のLDAPアクセスが禁止され、署名ありのLDAPアクセスもしくはLDAPSアクセスが必須となる、という話だった

具体的なWindows Server側のパッチ
 Windows Server 2025 KB5126646
 Windows Server 2022 KB5126655
 Windows Server 2019 KB5126651
 Windows Server 2016 KB5126868

基本的に、Windows Server側に適用されたセキュリティ強化設定を解除することはできない

Windows Server側のLDAP接続に関するドキュメント「Active Directory Domain ServicesのLDAPチャネルバインディング概要」と「Active Directory Domain Services における LDAP 署名の概要」

NetApp側のドキュメント「2026年10月 ドメイン コントローラ更新後のLDAP無効な認証情報 FAQ」(英語版)

まずはLDAPSでアクセスするための「Active Directory Domain Services で SSL 経由で LDAP の証明書を構成する」で、署名などで使用する証明書を用意する

この設定については過去に「Windows Server 2025で作ったActive Directory環境でldapsを使えるようにする」でRHEL からopensslコマンドとldapsearchコマンドを使って確認する方法と共に記載している

次に「Active Directory Domain Services のグループポリシーを使ってLDAP署名を設定する」でクライアントからのアクセス時にLDAP署名を強制する設定を行う、と


クライアントからアクセスする時に確認するべき点のメモ

アクセステスト内容署名不要のDC署名必須のDC
LDAP(389) + Simple bind成功失敗(Strong Auth Required / LDAPエラー8)
LDAP(389) + SASL(署名)成功成功
LDAPS(636)+ Simple bind証明書があれば成功証明書があれば成功

ldapsearch コマンドで挙動を確認する手法のメモ

① 署名必須かどうか(LDAP+Simple bind)

確認コマンド

ldapsearch -x -H ldap://dc01.example.local \
  -D "user@example.local" -W \
  -b "dc=example,dc=local" -s base "(objectClass=*)" dn

署名必須の場合、下記の様なエラー

ldap_bind: Strong(er) authentication required (8)
  additional info: 00002028: LdapErr: DSID-0C09xxxx, The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection

② LDAP+SASL(Kerberos)+署名での接続

確認コマンド

kinit user@EXAMPLE.LOCAL
ldapsearch -Y GSSAPI -H ldap://dc01.example.local -b "dc=example,dc=local" -s base dn

# 署名なしを強制して失敗するか確認(失敗すれば署名必須)
ldapsearch -Y GSSAPI -O "minssf=0,maxssf=0" -H ldap://dc01.example.local -b "dc=example,dc=local" -s base dn

③ LDAPSでのテスト

確認コマンド

# 証明書・TLSバージョンの確認
openssl s_client -connect dc01.example.local:636 -showcerts </dev/null

# LDAPSでbind
LDAPTLS_CACERT=/path/to/ca.pem \
ldapsearch -x -H ldaps://dc01.example.local \
  -D "user@example.local" -W -b "dc=example,dc=local" -s base dn

# StartTLS(389)
ldapsearch -x -ZZ -H ldap://dc01.example.local -D "user@example.local" -W -b "dc=example,dc=local" -s base dn

自己署名環境の場合、「LDAPTLS_REQCERT=never」を設定することで証明書検証を省略できる

LDAPS上でGSSAPIを使う場合、ADはTLS上のsign/sealを拒否するため「-O maxssf=0」オプションの追加、もしくは ldap.conf に「SASL_SECPROPS maxssf=0」を設定する

Windows環境で確認するためのメモ

PowerShellの場合

Add-Type -AssemblyName System.DirectoryServices.Protocols
$cred = Get-Credential   # user@example.local

# 389 + Simple bind(署名必須なら例外)
$c = New-Object System.DirectoryServices.Protocols.LdapConnection("dc01.example.local:389")
$c.SessionOptions.ProtocolVersion = 3
$c.AuthType = [System.DirectoryServices.Protocols.AuthType]::Basic
try { $c.Bind($cred.GetNetworkCredential()); "389 Simple bind: 成功(署名不要)" }
catch { "389 Simple bind: 失敗 -> $($_.Exception.InnerException.Message)" }

# 636 LDAPS
$s = New-Object System.DirectoryServices.Protocols.LdapConnection("dc01.example.local:636")
$s.SessionOptions.ProtocolVersion = 3
$s.SessionOptions.SecureSocketLayer = $true
$s.AuthType = [System.DirectoryServices.Protocols.AuthType]::Basic
try { $s.Bind($cred.GetNetworkCredential()); "LDAPS: 成功" }
catch { "LDAPS: 失敗 -> $($_.Exception.InnerException.Message)" }

Test-NetConnection dc01 -Port 636 はTCP疎通しか見ないため、TLSが成立するかの確認には上記のbindテストを使う

また、クライアント側でレジストリが設定されているか確認

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LDAP -Name LDAPClientIntegrity
# 0=なし, 1=ネゴシエート(既定), 2=必須

Active Directoryサーバ側で確認する手法

レジストリ「HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters」を確認

LDAPServerIntegrity が「1」は署名無し、「2」は署名必須

LdapEnforceChannelBinding が「0」無効、「1」サポートしてるなら使う、「2」必須

GPOでの設定項目「ドメイン コントローラー: LDAP サーバー署名必須」

イベントログでの確認

Directory Serviceのイベントログに出てくるイベントID

2886/2887:署名なしbindの存在・件数の警告

2889:署名なしbindを行ったクライアントIPとアカウント(「16 LDAP Interface Events」の診断ログを2に設定して出力)

3039~3041:チャネルバインディング関連

Windows版Claude DesktopのcodeでUbuntuへのsshが失敗する

Windows環境にClaude Desktopをインストールして、codeにてubuntuサーバへのsshを設定してみたところ接続できなかった

pcuser@192.168.1.21に接続できませんでした
SSH 接続を確立できませんでした。ホストに到達可能であること、および SSH の設定が正しいことを確認してから、再試行してください。詳細なエラーは以下に表示されています。
Host denied (verification failed)

先にうちの事例での答えを書いておくと、原因は2つ

・WindowsのOpenSSHをインストールしていなかった
 → インストールした

・環境変数HOMEが未設定だったこと
 → 設定した

これで解決しました。

解決に至るまでの経緯として。以下にメモを残しておく

まずClaude Codeでのsshトラブルの際に、Claude code側のssh設定は以下で確認できる

Get-Content "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ssh_configs.json"

設定ファイルをみてもまあわかることはないかな

実際のログを確認するには以下をPowerShellで実行して確認

Get-Content "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ssh.log" -Tail 60

今回は下記の様になっていた。

2026-08-11 22:28:06 [info] [ClaudeSSHManager] Initialized with version 5db5e4a12f88487e47c2c48259b69a2d630bb3f7
2026-08-11 22:28:08 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: warm_up)
2026-08-11 22:28:08 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 22:28:08 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 0)
2026-08-11 22:28:08 [warn] [SSH2Connection] Host 192.168.1.21:22 is not in known_hosts
2026-08-11 22:28:08 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 22:28:08 [warn] [SSH2Connection] Rejecting host key for 192.168.1.21:22 — host is not in known_hosts
2026-08-11 22:28:08 [error] [SSH2Connection] Connection error: Host denied (verification failed)
2026-08-11 22:28:08 [error] [RemoteServerController] Connection failed (79ms, trigger: warm_up): Host denied (verification failed)
2026-08-11 22:28:11 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: send_message)
2026-08-11 22:28:11 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 22:28:11 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 0)
2026-08-11 22:28:11 [warn] [SSH2Connection] Host 192.168.1.21:22 is not in known_hosts
2026-08-11 22:28:11 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 22:28:11 [warn] [SSH2Connection] Rejecting host key for 192.168.1.21:22 — host is not in known_hosts
2026-08-11 22:28:11 [error] [SSH2Connection] Connection error: Host denied (verification failed)
2026-08-11 22:28:11 [error] [RemoteServerController] Connection failed (46ms, trigger: send_message): Host denied (verification failed)
2026-08-11 22:28:19 [info] [RemoteServerController] Detaching (leaving daemon running)
2026-08-11 22:34:38 [info] [ClaudeSSHManager] Initialized with version 5db5e4a12f88487e47c2c48259b69a2d630bb3f7
2026-08-11 22:34:40 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: warm_up)
2026-08-11 22:34:40 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 22:34:40 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 0)
2026-08-11 22:34:40 [warn] [SSH2Connection] Host 192.168.1.21:22 is not in known_hosts
2026-08-11 22:34:40 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 22:34:40 [warn] [SSH2Connection] Rejecting host key for 192.168.1.21:22 — host is not in known_hosts
2026-08-11 22:34:40 [error] [SSH2Connection] Connection error: Host denied (verification failed)
2026-08-11 22:34:40 [error] [RemoteServerController] Connection failed (109ms, trigger: warm_up): Host denied (verification failed)

注目すべき点は「identityFiles: 0」

ホームディレクトリにある.ssh\known_hosts には複数の定義があるのに、「0」と報告されている

何が問題かを確認するため、HOME関連の環境変数定義の状態を確認

"HOME       = $env:HOME"
"USERPROFILE= $env:USERPROFILE"
"HOMEDRIVE  = $env:HOMEDRIVE"
"HOMEPATH   = $env:HOMEPATH"

そうしたら、HOMEが設定されていないことが判明

PS C:\Users\OSAKANATARO> "HOME       = $env:HOME"
HOME       =
PS C:\Users\OSAKANATARO> "USERPROFILE= $env:USERPROFILE"
USERPROFILE= C:\Users\OSAKANATARO
PS C:\Users\OSAKANATARO> "HOMEDRIVE  = $env:HOMEDRIVE"
HOMEDRIVE  = C:
PS C:\Users\OSAKANATARO> "HOMEPATH   = $env:HOMEPATH"
HOMEPATH   = \Users\OSAKANATARO
PS C:\Users\OSAKANATARO> 

PS C:\Users\OSAKANATARO> [Environment]::SetEnvironmentVariable("HOME", $env:USERPROFILE, "User")

設定後、Windows再起動

PS C:\Users\OSAKANATARO> "HOME       = $env:HOME"
HOME       = C:\Users\OSAKANATARO
PS C:\Users\OSAKANATARO> "USERPROFILE= $env:USERPROFILE"
USERPROFILE= C:\Users\OSAKANATARO
PS C:\Users\OSAKANATARO> "HOMEDRIVE  = $env:HOMEDRIVE"
HOMEDRIVE  = C:
PS C:\Users\OSAKANATARO> "HOMEPATH   = $env:HOMEPATH"
HOMEPATH   = \Users\OSAKANATARO
PS C:\Users\OSAKANATARO>

しかし、結果は変わらず

Claude自身に思考させるとSysteminternalのプロセス モニターで確認しろとのこと

Procmon64.exe を管理者実行。

  1. Ctrl+L でフィルタを開く
  2. Path contains ssh → Add → OK
  3. Ctrl+X で既存イベントをクリア
  4. Claude Desktop で接続を試行
  5. Ctrl+E でキャプチャ停止

なんかssh.exe を捜索してるログがたくさん・・・

Windows提供のOpenSSHを入れろとのこと

「Get-WindowsCapability -Online -Name OpenSSH.Client*」を実行して確認。

PS C:\Users\OSAKANATARO> Get-WindowsCapability -Online -Name OpenSSH.Client*


Name         : OpenSSH.Client~~~~0.0.1.0
State        : NotPresent
DisplayName  : OpenSSH クライアント
Description  : OpenSSH ベースのセキュア シェル (SSH) クライアントで、セキュアなキー管理とリモート マシンへのアクセスを
               可能にします。
DownloadSize : 0
InstallSize  : 0



PS C:\Users\OSAKANATARO>

「NotPresent」とインストールされていないので「Add-WindowsCapability -Online -Name OpenSSH.Client」でインストールする

PS C:\Users\OSAKANATARO> Add-WindowsCapability -Online -Name OpenSSH.Client


Path          :
Online        : True
RestartNeeded : False



PS C:\Users\OSAKANATARO> Get-WindowsCapability -Online -Name OpenSSH.Client*


Name         : OpenSSH.Client~~~~0.0.1.0
State        : Installed
DisplayName  : OpenSSH クライアント
Description  : OpenSSH ベースのセキュア シェル (SSH) クライアントで、セキュアなキー管理とリモート マシンへのアクセスを
               可能にします。
DownloadSize : 0
InstallSize  : 7995927



PS C:\Users\OSAKANATARO>

で・・・再起動しないでClaude Codeの再チャレンジをしてみたところ、今度は成功しました

成功した時のsshログは以下

PS C:\Users\OSAKANATARO> Get-Content "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ssh.log" -Tail 30 -Encoding utf8
<略>
2026-08-11 23:20:24 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: send_message)
2026-08-11 23:20:24 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 23:20:24 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 7)
2026-08-11 23:20:24 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending SERVICE_REQUEST (ssh-userauth)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Inbound: Received SERVICE_ACCEPT (ssh-userauth)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending USERAUTH_REQUEST (none)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Inbound: Received USERAUTH_FAILURE (publickey,password)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Client: none auth failed
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending USERAUTH_REQUEST (publickey -- check)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Inbound: Received USERAUTH_PK_OK
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending USERAUTH_REQUEST (publickey)
2026-08-11 23:20:25 [info] [SSH2Connection] ssh2: Inbound: Received USERAUTH_SUCCESS
2026-08-11 23:20:25 [info] [SSH2Connection] Connected to pcuser@192.168.1.21:22
2026-08-11 23:20:25 [info] [BinaryDeployment] Remote: home=/home/pcuser, platform=linux-amd64, shell=posix, localVer=5db5e4a12f88487e47c2c48259b69a2d630bb3f7
2026-08-11 23:20:25 [info] [BinaryDeployment] Server binary up to date (5db5e4a12f88487e47c2c48259b69a2d630bb3f7), skipping upload
2026-08-11 23:20:25 [info] [BinaryDeployment] CLI v2.1.222 cached
2026-08-11 23:20:26 [info] [BinaryDeployment] Remote server started
2026-08-11 23:20:26 [info] [BinaryDeployment] Bridge channel opened
2026-08-11 23:20:26 [info] [RemoteServerController] server capabilities: version=5db5e4a12f88487e47c2c48259b69a2d630bb3f7, methods=19, features=[process.stdin.offset]
2026-08-11 23:20:26 [info] [RemoteServerController] Connected to remote server (1557ms, trigger: send_message, reused: false)
PS C:\Users\OSAKANATARO>

ちゃんと「identityFiles: 7」と.ssh\known_hosts に登録されているホストの数が認識されていました

Windows OS上でユーザ権限でファイルシステムをマウントできるようにするDokany

バックアップソフトのCommvaultの 取得したバックアップデータを実際にはリストアしないでユーザ側に直接ファイルシステムとしてアクセスできるようにする3DFSについてドキュメントを見ていたところ、下記の記述があった。

Windowsバックアップデータを、Windowsサーバ上でファイルシステムとして見れるようにする場合、Dokany というオープンソースのコールバックファイルシステムが必要だという。

dokany を調べると github にあった

https://github.com/dokan-dev/dokany

“Dokany is a fork of Dokan 0.6.0 with bug fixes, clean change history and updated to build with latest tools.“

dokan !? 「Opendedupという重複排除機能搭載のLinux/Windows向けファイルシステム」で使われていたやつだ

2021年にdokan公式Webが消滅したので、forkしたってことですね

https://dokan-dev.github.io/ を見ると、Dokan FUSEを利用して、いろんなものをファイルシステムとしてマウントできるようにするものが作られているようです

CHUWEI UBOXにWindows 11を入れた

先日買ったGMKtec NucBox G10 mini は、32GB メモリ2枚とM.2 NVMe SSD 1TBを増設して、ESXi 8 Free版をインストールして検証に使用している

軽く使っている分には問題なかったのだが、64GBメモリを限界まで使うようになると、スワップなども行うためか M.2 SSDがめちゃくちゃ発熱する。

上の蓋を取って冷却ファンを取り付けてみたものの不格好

そんな中、aliexpressを見てたらメモリ16GB/SSD 512GBが入っているRyzen 5 7430U搭載のCHUWI UBOX が約39000円というお値段で売っているのを発見

SO-DIMMスロット2個、M.2 NVMe SSDスロット2個と置き換えには十分なスペックなので買ってみた。

開梱

届いた・・・案外大きい、というのが第一印象

3機種比較

メモリ/SSD側を開けてみる

手で持っている蓋みたいなところがSSDのヒートシンクも兼ねていて放熱シリコンが貼り付けてある

SSDをくるむ銀袋にAirDisk APF10 PCIe 3.0×4 M.2 2280とかかれたSSDが入っている

メモリも銀でくるまれているが、こちらは貼り付けられていて外せなかった

WiFi はRTL8852BEと書かれていた

逆側はCPUが付いているので、ファンが付いている

初期状態

普通に初回ウィザードを経てログイン。コントロールパネルのショートカットが作成されていた

あと、キーボード配列は英語だった。

タスクマネージャを起動して、スペック確認

CPU Ryzen 5 7430Uを確認

メモリはPC4-25600(DDR4-3200) の16GB が1枚

ディスクはAirDiskというメーカの512GB

WiFiは、Realtek 8852BE

GPUは、メモリを512MB割り当てられていた

CPU-Z

Windows 11 Proのライセンスは「RETAIL」channelではあった

プレインストールのアプリは下記

AMD Settings は Radeon管理ソフトAdrenalin。ver 2024.0819.1807.1996 で新しくはない

Realtek PCI-E Wireless LAN WiFi 6 Driver はWiFiのドライバで、ver 3.00.045

Windows Updateを実施して、Windows 11 Pro 25H2 にアップデートした後


Windows 11 Pro再インストール実施

再インストール後のドライバ適用状態確認

ネットワークコントローラが未認識・・・

有線LAN Realtek 2.5Gb NIC 2ポートは認識しているので、WiFiが未認識、ということになる。

AMD Radeon Graphicsもあるので、GPUも認識はしていた。

ドライバ調査

とりあえずGPUは認識しているのだが、ドライババージョンが古め

Radeon管理ソフトAdrenalinも入れた方がいいのだろうと、AMDのダウンロードページへ移動して、[Browse Products]の[Processors]を確認・・・

Ryzen 5 7430Uがないのですが・・・

検索すると下記のように AMD Ryzen™ 5 7530U Drivers and Downloads – Latest Version が出てくるのだが、ダウンロードはできなかった

Drivers and Support for Processors and Graphics から amd-software-adrenalin-edition-26.1.1-minimalsetup-260119_web.exe をダウンロードしてインストール

ドライバが更新されたことを確認

続いてRealtek 8852BEについて対処する。

不明なデバイスとなっているWiFI部分については「PCI\VEN_10EC&DEV_B852&SUBSYS_B85210EC」をMicrosoft Update カタログで検索して入手する

検索すると Microsoft Update カタログ が出てくるので、cabファイルを展開して適用すればOK

RealTek8852BEのBluetooth機能については、下記のように認識してるので大丈夫だろう、と思っていたのですが、実際にBluetooth接続のゲームパットをつなげようとしたら認識できないことを確認。

デバイス名「USB\VID_0BDA&PID_B85B\00E04C000001」Microsoft Update カタログ で検索して、cabファイルをダウンロードしてドライバを適用

適用後は「Realtek Bluetooth Adapter」という認識に変わり、Bluetooth接続のゲームパットも正常に認識するようになった。

license HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform

VK7JG-NPHTM-C97JM-9MPGT-3V66T


ドラクエベンチマーク

GPUメモリ16GB割り当て時

GPUメモリ4GB割り当て時

GPU自動割り当て

CPU-Z

samba 4.23.3 で立てたActive Directoryサーバの機能レベルが2008R2から動かせない件を修正する

ESXi8 Free環境上に Active Directoryサーバを立てるか、と、AlmaLinux 9 で samba 4.23.3 をソースからコンパイルして構築した

# /usr/local/samba/bin/samba-tool domain provision --use-rfc2307 --interactive
Realm [ADSAMPLE.LOCAL]:
Domain [ADSAMPLE]:
Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
DNS forwarder IP address (write 'none' to disable forwarding) [8.8.8.8]:  8.8.8.8
Administrator password:
Retype password:
INFO 2025-11-10 14:24:37,370 pid:1551 /usr/local/samba/lib64/python3.9/site-packages/samba/provision/__init__.py #2112: Looking up IPv4 addresses
<略>
INFO 2025-11-10 14:24:49,826 pid:1551 /usr/local/samba/lib64/python3.9/site-packages/samba/provision/__init__.py #501: DOMAIN SID:            S-1-5-21-1830428519-1651848948-1698044471
#

これで起動したActive Directoryサーバのフォレストレベル / ドメインレベル は下記の様にWindows 2008 R2 となっていた。

# samba-tool domain level show
Domain and forest function level for domain 'DC=adsample,DC=local'

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2008 R2
#

これをアップグレードしようと samba-tool domain level raiseコマンドを実行してみてもエラーとなる。

# samba-tool domain level raise --forest-level=2012_R2
ERROR: Forest function level can't be higher than the domain function level(s). Please raise it/them first!
# samba-tool domain level raise --domain-level=2012_R2
ERROR: Domain function level can't be higher than the lowest function level of a DC!
#

これはデフォルトのsamba設定で”ad dc functional level”が2008R2までとなっているからそういうことになっているのだという(参考:Samba domain controller: raising (all kinds of) level)

testparamコマンドを実行して現在の設定値を確認する

# /usr/local/samba/bin/testparm -s --section-name=global --parameter-name="ad dc functional level"
Load smb config files from /usr/local/samba/etc/smb.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

2008_R2
#

現状の /usr/local/samba/etc/smb.conf に記載はないが、 samba設定としては 2008_R2 として認識されている、ということを確認出来た

この結果を受けて/usr/local/samba/etc/smb.conf のglobalセクションに「ad dc functional level = 2016」という記述を追加する

# cat /usr/local/samba/etc/smb.conf
# Global parameters
[global]
        dns forwarder = 8.8.8.8
        netbios name = ADSERVER
        realm = ADSAMPLE.LOCAL
        server role = active directory domain controller
        workgroup = ADSAMPLE
        idmap_ldb:use rfc2307 = yes
        ad dc functional level = 2016

[sysvol]
        path = /usr/local/samba/var/locks/sysvol
        read only = No

[netlogon]
        path = /usr/local/samba/var/locks/sysvol/adsample.local/scripts
        read only = No
#

testparamで記述が反映されているかを確認

# /usr/local/samba/bin/testparm -s --section-name=global --parameter-name="ad dc functional level"
Load smb config files from /usr/local/samba/etc/smb.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

2016
#

sambaを再起動して、機能レベルがどうなったのかを確認

# systemctl restart samba-ad-dc
# samba-tool domain level show
Domain and forest function level for domain 'DC=adsample,DC=local'

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2016
#

Lowest function level of a DC が変更されたので、上2つも変更できるようになった

まずはドメインの機能レベルを変更

# samba-tool domain level raise --domain-level=2012_R2
Domain function level changed!
All changes applied successfully!
# samba-tool domain level show
Domain and forest function level for domain 'DC=adsample,DC=local'

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2012 R2
Lowest function level of a DC: (Windows) 2016
#

続いてフォレストの機能レベルを変更

# samba-tool domain level raise --forest-level=2012_R2
Forest function level changed!
All changes applied successfully!
# samba-tool domain level show
Domain and forest function level for domain 'DC=adsample,DC=local'

Forest function level: (Windows) 2012 R2
Domain function level: (Windows) 2012 R2
Lowest function level of a DC: (Windows) 2016
#

これで問題なくなった。