私はADをWebサービスと統合しています。Python Linux上でPython-LDAP over SASL(DIGEST-MD5)を使用してAD 2012ユーザー属性(部門、部門、内線番号、電子メールなど)をクエリしています)AD 2003に対するサービスに固有の問題を解決した後、新しいAD 2012に対してSPNエラーが発生し始めました。ダイジェストURIがサーバー上のどのSPNとも一致しなかったためです。両方のサーバーのSPNリスト。これらのサーバーには、互いに同じ類似物が含まれています。
これは以下を実行することで修正されました:
setspn -A ldap/<Domain_Name> <Computer_Name>
次のコマンドを実行しても、サービスアカウントを作成してもSPNエラーは修正されませんでした:
setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>
ローカルマシンのSPNリストにSPNを追加するだけで、sasl_interactive_bind_s()を使用したPython-LDAPサービスで機能しました。また、simple_bind_s()を使用するとSPNステップをスキップできることにも注意してください。ただし、このメソッドは資格情報をクリアテキストで送信するため、許容できません。
しかし、レコードがSPNリストに残っているのは約1分間しかありません。 setspnコマンドを実行してもエラーは発生せず、イベントログは完全に空で、ベースDNの-Fフォレスト全体の検索で何もチェックされていない重複はありません。 SPNを追加して削除し、オブジェクトからオブジェクトに移動して、どこにも隠れていないことを確認しましたが、2番目にオブジェクトをどこかに追加してから再度追加しようとすると、重複が通知されます。だから、どこかに隠されている複製がないと私は非常に確信しています。
今のところ、スケジュールされたタスクを実行してコマンドを再実行し、レコードをリストに保持して、サービスが適切に動作するようにします"SPN Hack"
cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"
sPNがリストから削除されている理由がわかるまで。
私はこの特定のADのプライマリ管理者ではありません。管理者は、ADの別のサービスからSPNを同期するサービスを実行していて、それを認識できませんか?私のタイトルは言い訳としてではなく、Active Directoryに関する私の無知を説明するためのWeb開発者です。 ADをマスターユーザーDBにするように言われ、たくさん読んでいますが、SPNが定期的に「上書き」または「クリーンアップ」されているという問題が発生している場所はどこにもありません。管理者は、SQLServerエントリ以外のSPNに精通しています。
これまでのところ、私のハッキングによってユーザーやサービスに問題が発生したことはなく、エラーも発生していません。そのため、管理者はそれを実行させるだけなので、引き続き調査します。しかし、私は、実装が組み込まれているサービス、本質的にはcronハック/ shiverを作成するという不安定な状況にいることに気づきます。
システム管理者との会話の後、ハックの上にサービスを構築することは解決策ではないことに同意し、したがって、目的に使用できるエンドポイント暗号化を使用してローカルサービスを起動する許可を彼に与えられました、結果は同じです。 SPNがクリアされる原因を監視します。ローカルバインドはPython-LDAPを使用する問題ではなく、ローカルサービスは1時間ほどですでに稼働しています。基本的にLDAPに組み込まれている機能をラップしているのは残念ですが、私たちがしなければならないことは行います。
これは本当に興味深い(そして迷惑な)現象であり、私はここで何が起こっているのかを知るように強く要求します。
さいわい、2008年以降、Windows Serverにはきめ細かな監査ポリシーがいくつかあり、監査を使用してwhoがこれを行ったことを追跡できます。そのためには、次のことを行う必要があります。
ドメインコントローラーで管理者特権のコマンドプロンプトを開き、次のコマンドを発行します。
repadmin /showobjmeta . "CN=computerAccount,DC=domain,DC=local"|findstr servicePricipalName
出力には、servicePrincipalName属性値の現在のバージョンを最初に書き込んだドメインコントローラーの名前が含まれます。
グローバル監査ポリシーがまだ定義されていない場合は、前の手順で特定したドメインコントローラーのローカルセキュリティポリシーにこの変更を加えることができます
グループポリシー管理コンソール(gpmc.msc
)を開き、Default Domain Controllers Policy
を見つけて編集します。
Computer Configuration -> Windows Settings -> Security Settings
に移動Local Policies -> Security Options
Advanced Audit Policy -> Audit Policies -> DS Access
Active Directoryユーザーとコンピューター(dsa.msc
)を開き、[表示]メニューの[拡張機能]設定を確認します。
コンピューターアカウントオブジェクトに移動し、右クリックして[プロパティ]を選択します。 Securityタブを選択し、[詳細]ボタンをクリックします。
プロンプトで、Auditingタブを選択し、Everyone。そうでない場合、または確信がない場合は、新しいエントリを追加します。
(怠惰な場合は、[すべてのプロパティを書き込む]を選択できます)
あなたの質問から、SPNは1分ごとに削除されるようですので、これがおそらく最も簡単なステップです。その間に 1分間の音楽レッスン を受講してください。
1分が経過したので、ステップ1でオリジネーターとして識別されたドメインコントローラーのセキュリティログを調べてみましょう。これは、大規模なドメインでは苦痛になる可能性がありますが、フィルター処理でこれを解決できます。
Windows Logs -> Security
に移動します<All Event IDs>
」という入力フィールドに、5136と入力します(これは、ディレクトリオブジェクト変更のイベントIDです)これで、コンピューターアカウントのservicePrincipalName
属性に対する変更ごとにイベントエントリを見つけることができるはずです。
変更の原因となった「件名」を特定し、それがどこから来たかを確認します。そのプロセス/マシン/アカウントを火で殺してください!
件名がSYSTEM
、ANONYMOUS LOGON
または同様の一般的な説明として識別されている場合は、ドメインコントローラー自体の内部処理を扱っているため、次のようにいくつかのNTDS診断ログを作成する必要があります。何が起こっているのかを調べてください。この場合は質問を更新してください