MENU

PowerShellでSPN登録とKerberos認証を構成する方法を徹底解説

PowerShell

PowerShellスクリプトを使用したWindows環境でのService Principal Name (SPN)登録とKerberos認証構成は、セキュアな認証プロセスを確立するために重要です。Kerberos認証は、ネットワーク環境でのユーザーとサービス間の信頼性を確保するための標準的なプロトコルです。この記事では、SPNの概念から登録手順、そしてKerberos認証の設定方法までを詳細に解説します。特に、PowerShellを用いた効率的なSPN管理方法や、エラー発生時のトラブルシューティングについても触れていきます。これにより、システム管理者やエンジニアが、堅牢で信頼性の高い認証システムを構築できるようになることを目指します。

目次

Kerberos認証とは


Kerberos認証は、ネットワーク内で安全な認証を提供するためのプロトコルであり、特にMicrosoftのWindows環境で広く採用されています。このプロトコルは、信頼できる第三者（キー配布センター、KDC）を通じて認証を行う仕組みを提供し、パスワードをネットワーク上で送信することなく、ユーザーやサービスを認証できます。

Kerberos認証の仕組み


Kerberos認証は以下の3つの主要なコンポーネントで構成されています。

  1. Key Distribution Center (KDC): 認証を管理する中心的なサービス。以下の2つの役割があります。
  • 認証サービス（AS）
  • チケット発行サービス（TGS）
  1. クライアント: サービスにアクセスを要求するエンドユーザーやアプリケーション。
  2. サービス: クライアントがアクセスする対象のサーバーやリソース。

基本的な認証フロー

  1. ASリクエスト: クライアントはKDCに自身を認証するリクエストを送信。
  2. チケットの取得: KDCはクライアントに対してチケット（TGT: Ticket Granting Ticket）を発行。
  3. サービスリクエスト: クライアントはTGTを用いてサービスへのアクセス要求を行い、セッションキー付きのサービスチケットを取得。
  4. 認証完了: クライアントがサービスチケットを用いてリソースにアクセス。

Kerberos認証におけるSPNの役割


Service Principal Name (SPN) は、Kerberos認証プロセスで重要な役割を果たします。SPNは、特定のサービスを一意に識別するための名前であり、クライアントがサービスにアクセスする際、正しい認証を確立するために必要です。SPNが正しく登録されていない場合、Kerberos認証は失敗し、代わりにNTLMなどの非推奨の認証方式が使用される可能性があります。

Kerberos認証は、セキュリティと効率を兼ね備えたプロトコルであり、特に企業ネットワーク環境において、その信頼性が評価されています。

SPN (Service Principal Name) の仕組み


Service Principal Name (SPN) は、Kerberos認証の基盤を支える重要な要素であり、特定のサービスをネットワーク上で一意に識別するための名前です。これにより、クライアントが正しいサービスを認証し、接続することが可能になります。

SPNの基本構造


SPNは以下の形式で構成されます:

<サービス名>/<ホスト名>:<ポート番号>

例:

  • HTTP/webserver.example.com:80
  • MSSQLSvc/dbserver.example.com:1433

これらのフィールドは以下を意味します:

  1. サービス名: 提供されるサービスの種類を表す識別子（例: HTTP、MSSQLSvc など）。
  2. ホスト名: サービスが実行されているサーバーの完全修飾ドメイン名（FQDN）。
  3. ポート番号（オプション）: サービスがリッスンしているポート番号。

SPNの役割


SPNは、以下のような場面で重要な役割を果たします:

  1. サービスの一意性の保証: 同じネットワーク上に複数の同一サービスが存在しても、SPNによって正しいサービスを特定可能。
  2. Kerberos認証のトラストチェーン構築: SPNを使用して、クライアントとサービス間で暗号化されたチケットがやり取りされます。
  3. 認証エラーの回避: SPNが正しく設定されていないと、Kerberos認証に失敗し、接続エラーや代替認証（NTLM）の発生が起こり得ます。

SPNの管理


SPNの登録や管理には、Active Directoryの機能が必要です。具体的には、次のような操作が一般的です:

  1. SPNの登録: setspn コマンドやPowerShellを使用して登録を行います。
  2. 重複の確認: 同じSPNが複数のサービスに登録されている場合、認証エラーが発生するため、事前に重複チェックが必要です。
  3. 削除や修正: 不要なSPNは削除することで、認証プロセスの混乱を防ぎます。

SPNの管理例


以下は、setspn コマンドを使用したSPNの操作例です:

# 新しいSPNの登録
setspn -A HTTP/webserver.example.com DOMAIN\WebServiceAccount

# SPNの一覧表示
setspn -L DOMAIN\WebServiceAccount

# 重複するSPNの確認
setspn -X

SPNの正確な管理は、Kerberos認証の成功に直結します。特に、大規模なネットワークではSPNの重複や誤設定が問題となることが多いため、定期的な確認が推奨されます。

PowerShellでSPNを登録する準備


PowerShellを使用してSPNを登録する前に、いくつかの前提条件と環境設定を整える必要があります。このステップを適切に行うことで、後続の操作がスムーズに進行します。

1. 必要な権限の確認


SPNの登録や管理を行うには、適切な権限が必要です。以下の点を確認してください:

  • Active Directoryに登録されているドメインアカウントを使用すること。
  • SPNを登録する対象のサービスアカウントの所有者であること、または管理者権限を持っていること。

2. 必要なツールとモジュールの準備


PowerShellでSPNを登録するには、以下のツールとモジュールが必要です:

  • Active Directoryモジュール: PowerShellでAD関連の操作を実行するために必要です。以下のコマンドでインストール状況を確認します:
  Get-Module ActiveDirectory -ListAvailable


インストールされていない場合は、以下のコマンドを使用して追加します:

  Install-WindowsFeature RSAT-AD-PowerShell

3. 登録するSPNの設計


SPNを登録する際、正しい形式と命名規則を事前に設計することが重要です。設計時には以下を考慮してください:

  • SPNがサービスを一意に識別できること。
  • ドメイン環境での重複を避けること。
  • サービスアカウントの命名が明確であること。

4. SPNの重複チェック


SPNの重複は認証エラーを引き起こします。PowerShellを使用して既存のSPNを確認しましょう:

# 特定のアカウントのSPNを確認
Get-ADUser -Identity "ServiceAccount" -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

# ドメイン全体の重複SPNを確認
Get-ADObject -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName

5. テスト環境での検証


SPN登録の操作を実施する前に、テスト環境で手順をシミュレーションすることを推奨します。これにより、誤設定や意図しない影響を未然に防げます。

事前準備を確認するためのチェックリスト

  • [ ] 使用するアカウントが適切な権限を持っている。
  • [ ] PowerShellにActive Directoryモジュールがインストールされている。
  • [ ] 登録するSPNが事前に設計され、重複がないことを確認済み。
  • [ ] テスト環境での動作確認を実施済み。

以上の準備を完了したら、SPN登録作業をPowerShellで安全に進めることができます。準備を整えることで、設定ミスを減らし、スムーズな運用を実現できます。

PowerShellスクリプトでのSPN登録手順


PowerShellを使用してSPNを登録することで、手動でのミスを防ぎ、効率的に作業を進めることができます。このセクションでは、PowerShellを活用したSPN登録の具体的な手順を解説します。

1. 基本的なSPN登録コマンド


SPN登録には、Set-ADUser コマンドレットまたは setspn コマンドを使用します。以下は、PowerShellを使用したSPN登録の基本例です。

# 新しいSPNを登録する
Set-ADUser -Identity "ServiceAccount" -Add @{ServicePrincipalName="HTTP/webserver.example.com"}

# 結果を確認
Get-ADUser -Identity "ServiceAccount" -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

2. 自動化スクリプトの例


複数のSPNを登録する場合は、スクリプト化することで効率化を図れます。以下は、リスト形式でSPNを登録するスクリプト例です。

# SPN情報のリスト
$SPNList = @(
    "HTTP/webserver1.example.com",
    "HTTP/webserver2.example.com",
    "HTTP/webserver3.example.com"
)

# SPNを登録するアカウント
$ServiceAccount = "ServiceAccount"

# SPNを一括登録
foreach ($SPN in $SPNList) {
    Write-Host "Registering SPN: $SPN for $ServiceAccount"
    Set-ADUser -Identity $ServiceAccount -Add @{ServicePrincipalName=$SPN}
}

# 登録結果を確認
Get-ADUser -Identity $ServiceAccount -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

3. SPNの重複チェックと登録


SPN登録前に、重複チェックを自動化するスクリプト例です。

# SPNとアカウントの定義
$SPN = "HTTP/webserver.example.com"
$ServiceAccount = "ServiceAccount"

# SPNの重複チェック
$ExistingSPN = Get-ADObject -Filter {ServicePrincipalName -eq $SPN} -Properties ServicePrincipalName

if ($ExistingSPN) {
    Write-Host "SPN '$SPN' already exists for another object: $($ExistingSPN.DistinguishedName)"
} else {
    # SPNを登録
    Write-Host "Registering SPN: $SPN"
    Set-ADUser -Identity $ServiceAccount -Add @{ServicePrincipalName=$SPN}
}

4. ログ記録とエラーハンドリング


スクリプトの実行結果をログに記録し、エラー発生時に適切に処理する例です。

# ログファイルの定義
$LogFile = "C:\Logs\SPNRegistration.log"

# ログ記録用関数
function Write-Log {
    param([string]$Message)
    $Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$Timestamp $Message" | Out-File -Append -FilePath $LogFile
}

# SPN登録
try {
    Set-ADUser -Identity $ServiceAccount -Add @{ServicePrincipalName=$SPN}
    Write-Log "Successfully registered SPN: $SPN"
} catch {
    Write-Log "Failed to register SPN: $SPN - Error: $_"
}

5. 結果の検証


SPN登録後は、必ず登録結果を検証してください。

# 登録済みSPNの確認
Get-ADUser -Identity "ServiceAccount" -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

PowerShellを使用したSPN登録をスクリプト化することで、効率的かつ正確にタスクを実行できます。また、エラーハンドリングやログ記録を追加することで、トラブルシューティングを容易にすることが可能です。

Kerberos認証の構成方法


登録したSPNを利用してKerberos認証を構成するには、適切な設定と手順を実行する必要があります。このセクションでは、Kerberos認証の基本的な構成手順を解説します。

1. Active Directoryでの設定確認


Kerberos認証を構成する前に、Active Directoryで必要な設定が正しく構成されていることを確認します。

サービスアカウントの確認


SPNが正しいアカウントに登録されているかを確認します。以下のコマンドでSPNを確認します:

Get-ADUser -Identity "ServiceAccount" -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

Kerberos認証が有効であることの確認

  • サービスアカウントのプロパティにおいて、「信頼できるデリゲーションを使用するサービス」が正しく構成されているか確認します。
  • Active Directoryユーザーとコンピュータ（ADUC）ツールを使用して設定を確認するか、PowerShellで以下を実行します:
  Get-ADUser -Identity "ServiceAccount" -Properties TrustedForDelegation

2. サービスでのSPN利用設定


サービスが登録されたSPNを利用して認証できるよう、以下の手順で設定します。

IISでの設定例

  1. アプリケーションプールの設定:
  • IISマネージャーを開き、対象のアプリケーションプールを右クリックして「詳細設定」を選択。
  • 「ID」フィールドを、SPNが登録されたサービスアカウントに変更します。
  1. 認証方法の設定:
  • 対象のWebサイトを右クリックし、「認証」を選択。
  • 「Windows認証」を有効化し、その他の認証方法（匿名認証など）を無効化。

SQL Serverでの設定例

  1. サービスアカウントの設定:
    SQL ServerサービスがSPNを登録したアカウントで実行されていることを確認します。SQL Server構成マネージャーを使用して設定します。
  2. SPN確認:
    登録したSPNが正しく適用されているかを確認します。以下のコマンドを実行:
   setspn -L "ServiceAccount"

3. テスト環境での動作確認


Kerberos認証が正しく動作するかをテスト環境で確認します。

テスト方法

  1. クライアントマシンでの接続確認:
    クライアントマシンで、Kerberos認証を使用したサービスに接続し、認証が成功するかを確認します。
   Test-Connection -ComputerName "webserver.example.com"
  1. Kerberosチケットの確認:
    クライアントマシンで以下のコマンドを実行して、Kerberosチケットが取得されていることを確認します:
   klist

成功例の確認ポイント

  • Kerberos認証に成功した場合、klist の出力にSPNが含まれていることを確認します。
  • IISやSQL Serverのログで認証エラーが発生していないことを確認します。

4. デリゲーションの構成（必要に応じて）


Kerberos認証を使用したデリゲーションが必要な場合、以下を構成します。

Active Directoryでの設定

  1. Active Directoryユーザーとコンピュータ（ADUC）ツールで、サービスアカウントを選択します。
  2. 「プロパティ」→「デリゲーション」タブを開きます。
  3. 「信頼できるデリゲーションを使用するサービスのみ」または「すべてのサービスに対して信頼する」を選択します。

PowerShellでの設定例

Set-ADAccountControl -Identity "ServiceAccount" -TrustedForDelegation $true

5. 本番環境への展開


テストが完了したら、本番環境に設定を適用します。適用後は、再度Kerberos認証の動作を確認し、設定に問題がないか検証します。

Kerberos認証を正しく構成することで、ネットワーク上の認証プロセスがセキュアかつ効率的になります。特に、SPNとサービスアカウントの設定が正確であることが成功の鍵です。

トラブルシューティング


SPN登録やKerberos認証の構成中に発生する問題を迅速に解決するための方法を解説します。典型的なエラーとその解決策を理解することで、設定プロセスを円滑に進めることができます。

1. SPN登録に関するエラー


SPN登録時に発生する一般的なエラーとその解決策を紹介します。

1.1 SPNの重複


エラー例:

An SPN cannot be registered because it is already assigned to another account.


原因: 同じSPNが複数のアカウントに登録されています。
解決策:

  1. 重複するSPNを確認します:
   setspn -Q "HTTP/webserver.example.com"
  1. 重複が確認された場合、該当アカウントからSPNを削除します:
   setspn -D "HTTP/webserver.example.com" DOMAIN\ConflictingAccount

1.2 アカウントの権限不足


エラー例:

Access is denied.


原因: SPNを登録するための権限が不足しています。
解決策:

  • 登録対象のアカウントに十分な権限があることを確認してください。
  • 管理者権限でPowerShellを実行します。

2. Kerberos認証に関するエラー


Kerberos認証時に発生する一般的な問題について解説します。

2.1 NTLMにフォールバックされる


症状: Kerberos認証ではなくNTLM認証が使用される。
原因:

  • SPNが正しく登録されていない。
  • サービスアカウントが正しく設定されていない。
    解決策:
  1. SPNが正しいアカウントに登録されていることを確認:
   Get-ADUser -Identity "ServiceAccount" -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName
  1. クライアントがSPNを正しく解決できるか確認:
   ping webserver.example.com

2.2 Kerberosチケットが発行されない


症状: klist コマンドでKerberosチケットが見つからない。
原因:

  • ドメインコントローラーとクライアント間の通信が問題を抱えている。
  • クライアントの時刻がドメインコントローラーと同期していない。
    解決策:
  1. ドメインコントローラーとの通信を確認:
   Test-Connection -ComputerName "DomainControllerName"
  1. 時刻同期を確認し、必要であれば同期:
   w32tm /resync

3. サービス固有のエラー

3.1 IISでの認証失敗


症状: IISサイトへのアクセス時に認証エラーが発生。
原因:

  • サイトのアプリケーションプールが正しいサービスアカウントを使用していない。
    解決策:
  • アプリケーションプールのIDをSPNが登録されているアカウントに設定します。

3.2 SQL Serverでの認証失敗


症状: SQL Serverに接続する際、Kerberos認証に失敗。
原因:

  • SQL ServerのサービスアカウントにSPNが登録されていない。
    解決策:
  • 登録されているSPNを確認し、必要に応じて再登録します。

4. ログの確認とデバッグ


問題が発生した際には、ログを確認して原因を特定します。

4.1 Kerberosイベントログ


WindowsイベントビューアでKerberos関連のログを確認します:

  • ログのパス: Windows Logs -> Security または Applications and Services Logs -> Microsoft -> Windows -> Kerberos

4.2 ネットワークトレースの取得


Wiresharkなどのツールを使用して、Kerberos認証時のトラフィックを分析します。

5. まとめ

  • SPNの正確な登録と重複の回避が重要です。
  • クライアントとサーバーの時刻同期を必ず確認してください。
  • ログやツールを活用して問題を迅速に特定しましょう。

トラブルシューティングのポイントを押さえることで、SPN登録やKerberos認証構成時に発生する問題を効果的に解決できます。

応用例: 複数ドメイン環境でのSPN管理


複数ドメイン環境でのSPN管理は、単一ドメイン環境よりも複雑です。クロスドメイン認証や信頼関係の設定が必要になるため、SPNの適切な構成が重要です。このセクションでは、複数ドメイン環境でのSPN管理の具体例と注意点を解説します。

1. 複数ドメイン環境における基礎


複数ドメイン環境では、以下の条件を考慮する必要があります:

  • ドメイン間に信頼関係が構築されていること。
  • SPNが正しいドメインアカウントに登録されていること。
  • クライアントが正しくドメインを解決できること。

クロスドメイン認証の基本


クロスドメイン認証では、SPNはドメイン全体で一意である必要があります。また、Kerberos認証では、信頼関係を利用してトラストチェーンが構築されます。以下を確認してください:

  1. ドメイン間のトラストを確認:
   Get-ADTrust -Filter *
  1. トラストの種類:
  • 双方向トラスト（推奨）
  • 一方向トラスト

2. SPNの一意性の確保


複数ドメイン環境では、SPNの一意性が重要です。同じSPNが異なるドメインのアカウントに登録されている場合、認証エラーが発生します。

SPNの一意性確認スクリプト


全ドメインでSPNを検索し、一意性を確認します:

# ドメインリスト
$Domains = @("DomainA.com", "DomainB.com")

foreach ($Domain in $Domains) {
    Write-Host "Checking SPNs in $Domain..."
    Get-ADObject -Filter {ServicePrincipalName -like "*"} -Server $Domain -Properties ServicePrincipalName | 
        Select-Object DistinguishedName, ServicePrincipalName
}

3. クロスドメインSPN登録の手順


ドメインAでホストされているサービスに対し、ドメインBのクライアントがアクセスする場合を例に解説します。

手順

  1. ドメインAでSPNを登録:
    サービスアカウントにSPNを登録します:
   Set-ADUser -Identity "[email protected]" -Add @{ServicePrincipalName="HTTP/service.DomainA.com"}
  1. ドメインBで信頼関係を設定:
    ドメインBからドメインAのSPNを解決するため、信頼関係を確認または設定します。
  2. DNS設定の確認:
    クライアントがサービスを正しく解決できるようにDNSを設定します。
   Resolve-DnsName -Name "service.DomainA.com"

4. 複数ドメイン環境でのトラブルシューティング


複数ドメイン環境では、特有の問題が発生する場合があります。

4.1 ドメイン間認証エラー


症状:
クライアントが他ドメインのSPNを解決できない。
原因:

  • 信頼関係が正しく構成されていない。
  • DNS設定が不足している。
    解決策:
  • 信頼関係を再設定:
  New-ADTrust -Name "DomainB.com" -TargetName "DomainA.com" -Direction Both
  • DNSフォワーダーを設定します。

4.2 SPNの重複


症状: SPNが複数のドメインで登録され、Kerberos認証に失敗。
解決策:

  • 全ドメインでSPNを検索し、重複を削除します。

5. ベストプラクティス

  • SPN命名規則を統一: SPNの命名規則をドメイン間で統一し、混乱を避ける。
  • SPN管理の自動化: スクリプトやツールを使用してSPN登録を自動化。
  • 定期的な監査: SPNと信頼関係を定期的に監査し、潜在的な問題を防止。

6. 応用例: 複数地域の拠点でのSPN管理


地域ごとに異なるドメインを持つ企業環境では、以下の手順を応用します:

  • 地域間トラストの構築。
  • DNSのゾーン転送設定。
  • サービスアカウントの統一ポリシー策定。

複数ドメイン環境におけるSPN管理は、規模が大きくなるほど複雑になりますが、適切な設計と監査を行うことで、効率的かつセキュアな認証環境を構築できます。

セキュリティ上の考慮事項


Kerberos認証を安全に構成するためには、SPNの登録や運用においてセキュリティを重視する必要があります。適切な設定とベストプラクティスを採用することで、不正アクセスや認証エラーのリスクを低減できます。

1. SPN管理のセキュリティ

1.1 最小権限の原則


SPNを登録するアカウントには、最小限の権限を付与します。不必要に高い権限を付与すると、不正アクセスのリスクが高まります。
具体例:

  • SPNの登録には、サービスアカウント専用の権限を設定する。
  • 管理者アカウントを使用せず、専用のサービスアカウントを作成。

1.2 SPNの定期的な監査


登録されているSPNを定期的に監査し、不正な登録や不要なエントリを確認します。
監査スクリプト例:

# ドメイン内の全SPNを取得
Get-ADObject -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName | 
    Select-Object Name, ServicePrincipalName

これにより、意図しないSPNの登録や重複を発見できます。

2. Kerberos認証のセキュリティ

2.1 時刻同期の維持


Kerberos認証では、クライアントとサーバー間の時刻同期が不可欠です。時刻の不一致は、認証エラーや攻撃のリスクを引き起こします。
対策:

  • ネットワーク内のすべてのデバイスでNTP（Network Time Protocol）を設定し、時刻を同期します。
  • コマンドで時刻同期を確認:
  w32tm /query /status

2.2 Kerberosのデリゲーション設定


デリゲーションは、慎重に管理しないと、不正なサービスが別のサービスに対して認証を偽装するリスクがあります。
対策:

  • 制限付きデリゲーションを使用:
    Active Directoryで「信頼できるデリゲーションを使用するサービスのみ」を選択します。
  • PowerShellで制限付きデリゲーションを設定:
  Set-ADUser -Identity "ServiceAccount" -Add @{"msDS-AllowedToDelegateTo"="HTTP/service.example.com"}

2.3 Kerberosイベントログの監視


Kerberosの使用状況を監視することで、不正アクセスや異常な認証試行を検出できます。

  • イベントログの確認:
  Get-WinEvent -LogName "Security" | Where-Object { $_.Message -like "*Kerberos*" }

3. SPNに関連するセキュリティリスク

3.1 SPNの悪用防止


攻撃者はSPNを利用してパスワードを解析する「Kerberoasting」攻撃を試みる可能性があります。この攻撃を防ぐには以下を実施してください:

  • 長く複雑なパスワードを使用: サービスアカウントのパスワードを強化する。
  • 不要なSPNの削除: 使用されていないSPNは削除します。
  • サービスアカウントのロックダウン: サービスアカウントに対し、対話ログインを無効化します。
  Set-ADUser -Identity "ServiceAccount" -LogonWorkstations ""

4. ベストプラクティス

4.1 監査ログの有効化


SPNの登録や変更が発生した場合にログを記録することで、変更履歴を追跡できます。

4.2 ネットワーク分離


重要なサービスアカウントや認証サーバーをネットワークセグメントで分離し、セキュリティを強化します。

4.3 定期的なトレーニング


管理者向けにSPNやKerberos認証に関するトレーニングを実施し、設定ミスやセキュリティリスクを最小化します。

5. まとめ


セキュリティ上の考慮事項を適切に実施することで、Kerberos認証システムの安全性を向上させることができます。SPNの登録や管理においては、最小権限の原則、定期的な監査、そしてセキュリティベストプラクティスを徹底してください。これにより、不正アクセスや認証エラーのリスクを大幅に軽減できます。

まとめ


本記事では、PowerShellを用いたSPNの登録方法とKerberos認証の構成について詳しく解説しました。Kerberos認証の基本概念、SPNの仕組み、PowerShellによる効率的なSPN登録、複数ドメイン環境での応用、セキュリティ上の考慮事項など、構成と運用のために必要な知識を網羅しました。適切なSPN管理とKerberos認証の設定により、セキュアで効率的なネットワーク認証環境を構築できます。今回の内容を参考に、システムの安定性と安全性を確保してください。

PowerShell
PowerShell Windows Kerberos認証 SPN

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次