どうも、Tです。
「ファイルサーバーにCNAMEを設定して接続すると接続できたり、できなかったり問題が発生する」という情報を聞き「んなわけねーだろ笑」と思っていました。
調べてみると確かに、チラホラ情報があるものの解決方法だけで完結している情報ばかり・・・前提条件や発生原因がよくわからなかったので検証してみました。
検証しつつ考慮できていなかった点も多かったので備忘録です。
目次
環境
今回使用したサーバーとクライアントです。
ADドメインは、devdomain.labを用意しました。
| ホスト名 | OS | 用途 |
|---|---|---|
| ad2019 | Windows Server 2019 | AD&DNS |
| file2019 | Windows Server 2019 | 共有フォルダ 別名：file2019cname |
| client10 | Windows 10 | 共有フォルダ接続クライアント |
事前設定
すべての機器に下記の設定を事前に行っています。
- Windowsファイアウォール無効化
- ADドメイン(devdomain.lab)への参加
- 検証用としてドメインユーザーdevadmin(Domain Admins所属)を用意
- files2019にshare01という共有フォルダを共有アクセス権Everyoneフルコントロールで設定
確認内容
今回ファイルサーバーの別名接続(file2019cname)方法として、DNSサーバーにCNAMEレコードを登録して接続します。
共有フォルダへの接続は、Windowsエクスプローラーのアドレスバーに共有リソース名を指定して接続します。
| 共有リソース名 | 呼称 | 認証方式 |
|---|---|---|
| \\file2019 | ホスト名接続 | Kerberos認証 |
| \\file2019.devdomain.lab | FQDN接続 | Kerberos認証 |
| \\192.168.10.151 | IPアドレス接続 | NTLM認証 |
| \\file2019cname | ホスト名(別名)接続 | NTLM認証 |
この問題を理解する上で大切なのは、接続方法によってADドメインで行われる認証が「Kerberos認証」「NTLM認証」で異なるところです。
認証の違いの説明は割愛しますが、Kerberos認証ではSPN(サービスプリンシパル名)が使われるため、別名で接続した場合に認証関連で接続できないパターンがあります。
パターン① CNAME登録しただけパターン
検証内容
最初の検証として、CNAMEを設定して正常につながるかどうかの確認を行います。
検証用設定
CNAME設定
これは、ad2019サーバー上で行います。
別名設定のためにCNAMEレコードを登録します。
DNSマネージャを開き前方参照ゾーンを開きます。ドメイン参加しているメンバーのAレコードは自動的に登録されています。
「空白部分を右クリック->新しいエイリアス(CNAME)」をクリックします。
「エイリアス名」に別名の「file2019cname」を入力して、「ターゲットホスト用の完全修飾ドメイン名(FQDN)」の「参照」をクリックします。
DNSサーバである「AD2019->前方参照ゾーン->ドメイン名」をダブルクリックして辿っていきます。
別名を設定する本来のホスト名のAレコードを選択し、「OK」をクリックします。
「ターゲットホスト用の完全修飾ドメイン名(FQDN)」にAレコードの値がセットされていることを確認し「OK」をクリックします。
別名のCNAMEレコードが登録されました。
接続確認
では、別名(file2019cname)でアクセスができるようになっているはずなので接続の確認を行っていきます。
接続した際の認証方式も確認します。認証方式の確認は、ファイルサーバー(file2019)のWindowsイベントログのセキュリティログのイベントID4624で確認します。
接続：ホスト名
clidn10からホスト名で接続が行えました。
file2019のイベントを見るとKerberos認証が行われたことがわかります。
接続：FQDN
clidn10からFQDNで接続が行えました。
file2019のイベントを見るとKerberos認証が行われたことがわかります。
接続：IPアドレス
clidn10からIPアドレスで接続が行えました。
file2019のイベントを見るとNTLM認証が行われたことがわかります。
接続：ホスト名(別名)
clidn10からホスト名(別名)で接続が行えました。
file2019のイベントを見るとNTLM認証が行われたことがわかります。
接続まとめ
ここまでの確認でCNAMEを設定しても別名でアクセスできることが確認できました。
| 共有リソース名 | 呼称 | 認証方式 | 結果 |
|---|---|---|---|
| \\file2019 | ホスト名接続 | Kerberos認証 | OK |
| \\file2019.devdomain.lab | FQDN接続 | Kerberos認証 | OK |
| \\192.168.10.151 | IPアドレス接続 | NTLM認証 | OK |
| \\file2019cname | ホスト名(別名)接続 | NTLM認証 | OK |
パターン②SPNが必要なパターン
検証内容
接続方式によって、Kerberos認証とNTLM認証が異なることがわかりました。
このパターン②では、パターン①の状態からファイルサーバー側でSPNの確認が必要だった場合、どのようになるか確認します。
SPNの説明は割愛しますが、SPNの情報はADサーバーで確認が行えます。
ADサーバーもしくはファイルサーバーのPowerShellを開き「setspn -L <コンピュータアカウント名>」を実行するとSPN情報が表示されます。
ホスト名(file2019)とFQDN(file2019.devdomain.lab)はSPNとして設定されていることが確認できます。これは、AD参加時に自動的に登録されたデフォルト状態です。
別名(file2019.cname)は、CNAMEレコードを登録しただけのためSPNには関連していません。
検証用設定
では、クライアントがファイルサーバーへ接続した際に、SPNの確認が必要なようにします。
ファイルサーバー側で設定を行います。
「ファイル名を指定して実行」で「gpedit.msc」を入力し「OK」をクリックします。
「コンピュータの構成->Windowsの設定->セキュリティの設定->ローカルポリシー->セキュリティオプション」から「Microsoftネットワークサーバー:サーバーSPNターゲット名検証レベル」をクリックします。
「クライアントに要求」を選択し「OK」をクリックします。
念のためコマンドプロンプトで「gpupdate /force」コマンドを実行します。
これでファイルサーバーにアクセスするときにSPNの検証が必須となり、SPNにない情報ではアクセスできなくなっています。
接続確認
接続：ホスト名
clidn10からホスト名で接続が行えました。ホスト名はSPNに含まれているので、接続できています。
file2019のイベントを見るとKerberos認証が行われたことがわかります。
接続：FQDN
clidn10からホスト名で接続が行えました。FQDNはSPNに含まれているので、接続できています。
file2019のイベントを見るとKerberos認証が行われたことがわかります。
接続：IPアドレス
clidn10からホスト名で接続が行えました。IPアドレスはSPNに含まれていませんが、接続できている理由は後述します。
file2019のイベントを見るとNTLM認証が行われたことがわかります。
IPアドレスはSPNに含まれていませんが、NTLM認証で接続できてしまいました。これは、下記の理由からと思われます。
ヒント
通常、RESTベースの操作にIPアドレスまたはDNS名を使用するようにネットワークコントローラーを構成できます。 ただし、Kerberosを構成する場合、ネットワークコントローラーへのRESTクエリにIPアドレスを使用することはできません。たとえば、<https://networkcontroller.consotso.com>は使用できますが、<https://192.34.21.3>は使用できません。IPアドレスが使用されている場合、サービスプリンシパル名は機能しません。
Windows Server 2016でKerberos認証とともにREST操作にIPアドレスを使用していた場合、実際の通信はNTLM認証を介して行われました。 このような展開では、Windows Server 2019にアップグレードすると、引き続きNTLMベースの認証を使用します。Kerberosベースの認証に移行するには、REST操作にネットワークコントローラーのDNS名を使用し、ネットワークコントローラーノードにSPNを登録するためのアクセス許可を提供する必要があります。
https://docs.microsoft.com/ja-jp/windows-server/networking/sdn/security/kerberos-with-spn
接続：ホスト名(別名)
ホスト名(別名)はSPNに含まれていないため、「アクセスが拒否されました」となり接続が行えません。また、ユーザー名とパスワードに正しいものを入力してもSPNに登録がないためこの状態が続きます。
file2019のイベントを見るとNTLM認証でLogonが行われ即時Logoffになる事象を何回か繰り返している状況になります。
接続まとめ
ということで、SPNに含まれない別名からの接続は行えませんでした。
| 共有リソース名 | 呼称 | 認証方式 | 結果 |
|---|---|---|---|
| \\file2019 | ホスト名接続 | Kerberos認証 | OK |
| \\file2019.devdomain.lab | FQDN接続 | Kerberos認証 | OK |
| \\192.168.10.151 | IPアドレス接続 | NTLM認証 | OK |
| \\file2019cname | ホスト名(別名)接続 | NTLM認証 | NG |
原因
原因は当初で確認しているSPNに別名が含まれていないためです。
パターン③NTLM認証が使えないパターン
検証内容
このパターン③では、パターン①の状態からNTLM認証が行えない場合、どうなるかを確認します。
検証用設定
NTLM認証を行えなくするには、ADサーバーのグループポリシーを設定します。「ファイル名を指定して実行」で「gpedit.msc」を入力し「OK」をクリックします。
「コンピュータの構成->Windowsの設定->セキュリティの設定->ローカルポリシー->セキュリティオプション」から「ネットワークセキュリティ:NTLMを制限する:このドメイン内のNTLM認証」をクリックします。
「すべて拒否する」を設定し「OK」をクリックします。
警告のポップアップで「はい」をクリックします。
念のためコマンドプロンプトで「gpupdate /force」コマンドを実行します。
接続確
接続：ホスト名
clidn10からホスト名で接続が行えました。ホスト名はKerberos認証のため接続できています。
接続：FQDN
clidn10からFQDN名で接続が行えました。FQDNはKerberos認証のため接続できています。
接続：IPアドレス
「ネットワークパスが見つかりません」のため接続できませんした。IPアドレスはNTLM認証のため接続できません。
イベントログでは、「失敗の監査」として記録されます。
接続：ホスト名(別名)
「ネットワークパスが見つかりません」のため接続できませんした。ホスト名(別名)はNTLM認証のため接続できません。
イベントログでは、「失敗の監査」として記録されます。
接続まとめ
| 共有リソース名 | 呼称 | 認証方式 | 結果 |
|---|---|---|---|
| \\file2019 | ホスト名接続 | Kerberos認証 | OK |
| \\file2019.devdomain.lab | FQDN接続 | Kerberos認証 | OK |
| \\192.168.10.151 | IPアドレス接続 | NTLM認証 | NG |
| \\file2019cname | ホスト名(別名)接続 | NTLM認証 | NG |
原因
ADサーバでNTLM認証が拒否されているため、NTLM認証を使う場合は接続が行えていません。
解決方法
検証から
検証の内容から「SPNに情報が含まれていない」「NTLM認証を使用している」ことが原因で、別名への接続が失敗することが分かりました。
解決策としては、「別名をSPNに含める」「NTLM認証ではなくKerberos認証を使用する」ことで別名での接続が可能になることがわかりました。
これの対応として、CNAMEレコードではなくnetdom computernameコマンドを用いる方法がMircrosoft Techコミュニティで公開されていたのでこちらを参考にします。
設定手順
現在設定しているDNSのCNAMEレコードは不要のため削除しておきます。下の画面は削除している状態です。file2019に関連するAレコードとCNAMEレコードはありません。
ファイルサーバー上で「netdom computername <ホスト名>) /ENUMerate」コマンドでファイルサーバーに登録されているホスト名を確認します。
現在は、「file2019.dev.domain.lab」が登録されています。
次にファイルサーバー上で「netdom computername <ホスト名> /add:<別名のFQDN)」コマンドで別名をファイルサーバーに設定します。再度確認すると登録できていることが確認できます。また、このコマンドは、ADサーバーのSPNへも情報を登録してくれます。
Microsoft Techの情報では、netdomコマンドで別名のDNSレコードの登録も自動でやってくれるように書いていたのですが登録されませんでした。「ipconfig /registerdns」コマンドでDNSレコードを登録します。
ADサーバーのDNSマネージャを見ると、「file2019」「file2019cname」のAレコードが登録されていることがわかります。
ADサーバーもしくはファイルサーバーで「setspn -L <コンピュータアカウント名>」コマンドを実行するとホスト名(別名)がSPNに登録されていることがわかります。
次にファイルサーバーを再起動します。再起動を行わないとクライアントから接続が行えませんでした。
別名と別名(FQDN)でも接続できるようになりました。
Windowsイベントログを確認するとSPNが利用できるようになっているため、Kerberos認証になっています。
この解決方法の問題点
他の解決方法でも同様の問題はでるのですが・・・・。
まず1つ目は、IPアドレスでの接続の場合は、NTLM認証になるためNTLM認証が拒否されている場合は、接続は行えません。そもそもNTLM認証を拒否している時点でIPアドレスでの接続は考えていないと思われるので、大きな問題にはならないかと考えています。
2つ目は、別名とSPNの管理の仕方です。DNSレコードはあるものの別名は「netdom」コマンド、SPNは「setspn」コマンドを用いないと見えないため煩雑になりそうです。
結論
ここまで確認するのにほぼ丸2日かかりました。
結論として、CNAMEレコードを用いて別名を付けること自体は問題ないと考えです。考慮する点としては、接続方式によってKerberos認証とNTLM認証方式に分かれるため、認証方式に制約がある場合は考慮が必要になります。
また、他のブログで問題解決しました！というパターンは、「リプレイスなどで名前を引き継ぐ過程でSPNの情報が誤っている」「クラスタソフトを使っていてSPN情報が異なっている」などが考えられそうです。
その場合は、今回の解決策ではなくsetspnコマンドを用いてSPN情報を精査する方法になるかと考えています。
備考
今回の検証を調べてて、「DisableStrictNameChecking」をレジストリで追加する方法が散見されましたが検証でも試したところSMBv1だけの対応のようです。現在のWindowsはデフォルトでSMBv1は利用できないので解決の選択肢にはならないかなぁと考えています。
SMB バージョン 1 プロトコルを実行しているファイル サーバーでこの問題を解決するには、レジストリに値 DisableStrictNameChecking を追加します。
https://docs.microsoft.com/ja-jp/troubleshoot/windows-server/networking/dns-cname-alias-cannot-access-smb-file-server-share
参考
まとめ
Windowsファイルサーバーじゃなくて非Windowsファイルサーバーの場合も調べてみたいものです・・・必要に迫られないとしないけど(´・ω・`)