Active Directory 2012 LDAP統合サービスのプリンシパル名のエントリが消える？

AD属性をクエリするPythonサービスの作成

SAS 2012上でPython-LDAP over SASL（DIGEST-MD5）を使用してLinuxでPythonを実行するWebサービスとADを統合し、AD 2012ユーザー属性（部門、部門、内線番号、電子メールなど）をクエリします。AD 2003に対するサービスに固有の問題を解決した後、新しいAD 2012に対してSPNエラーが発生し始めました。ダイジェストURIがサーバー上のSPNと一致していません。両方のサーバーのSPNリストを相互参照しましたが、それらには互いに同じ類似物が含まれています。

エラー：digest-uriは、このサーバーに登録されているLDAP SPNと一致しません

修正？

これは以下を実行することで修正されました：

setspn -A ldap/<Domain_Name> <Computer_Name>

次のコマンドを実行しても、サービスアカウントを作成してもSPNエラーは修正されませんでした。

setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>

simple_bind_s（）にはSPNは必要ありません、sasl_interactive_bind_s（）にはSPNが必要です

ローカルマシンの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にはいくつかのきめ細かな監査ポリシーがあり、監査を使用して誰がこれを行ったかを追跡できます。そのためには、次のことを行う必要があります。

1. SPNの変更が発生する場所を見つける
2. AD DSオブジェクト変更監査を有効にする
3. オブジェクトに監査ACEを設定する
4. エラーを再現する
5. 問題のあるDCのセキュリティログを検査する

SPNの変更が発生する場所を確認します。

ドメインコントローラーで管理者特権のコマンドプロンプトを開き、次のコマンドを発行します。

repadmin /showobjmeta . "CN=computerAccount,DC=domain,DC=local"|findstr servicePricipalName

出力には、servicePrincipalName属性値の現在のバージョンを最初に書き込んだドメインコントローラーの名前が含まれます。

AD DSオブジェクトの変更の監査を有効にします。

グローバル監査ポリシーがまだ定義されていない場合は、前の手順で特定したドメインコントローラーのローカルセキュリティポリシーにこの変更を加えることができます

グループポリシー管理コンソール（gpmc.msc）を開き、を見つけてDefault Domain Controllers Policy編集します。

1. に行く Computer Configuration -> Windows Settings -> Security Settings
2. 選択して展開 Local Policies -> Security Options
3. [ 監査：監査ポリシーのサブカテゴリ設定を強制する...]が[ 有効]に設定されていることを確認します
4. 選択して展開 Advanced Audit Policy -> Audit Policies -> DS Access
5. Audit Directory Service Changesが少なくともSuccessに設定されていることを確認してください

オブジェクトに監査ACEを設定します。

Active Directoryユーザーとコンピューター（dsa.msc）を開き、[表示]メニューの[拡張機能]設定を確認します。
コンピューターアカウントオブジェクトに移動し、右クリックして[プロパティ]を選択します。[ セキュリティ ]タブを選択し、[詳細]ボタンをクリックします。

プロンプトで「監査」タブを選択し、「すべてのプロパティの書き込み」がEveryoneに対して監査されていることを確認します。そうでない場合、または確信がない場合は、新しいエントリを追加します。

1. 追加を押します。
2. 対象のプリンシパルとして「全員」と入力します
3. タイプとして「成功」を選択します
4. プロパティの下にスクロールして、「servicePrincipalNameの書き込み」を確認します。
5. [OK]を押してエントリを追加し、ADUCを終了します

（怠惰な場合は、「すべてのプロパティを書き込む」を選択するだけです）

エラーを再現する

あなたの質問から、SPNは1分ごとに削除されるようですので、これがおそらく最も簡単なステップです。その間に1分間の音楽レッスンを受けてください。

問題のあるDCのセキュリティログを検査する

1分が経過したので、ステップ1でオリジネーターとして識別されたドメインコントローラーのセキュリティログを調べてみましょう。大規模なドメインではこれは面倒な作業になる可能性がありますが、フィルター処理でこれを解決できます。

1. イベントビューアを開いて、 Windows Logs -> Security
2. 右側のウィンドウで、[ 現在のログをフィルター]を選択します。
3. 「<All Event IDs>」という入力フィールドに、5136と入力します（これは、ディレクトリオブジェクト変更のイベントIDです）。

これservicePrincipalNameで、コンピューターアカウントの属性に対する各変更のイベントエントリを見つけることができるはずです。

変更の原因となった「件名」を特定し、それがどこから来たかを確認します。そのプロセス/マシン/アカウントを火で殺してください！

件名がSYSTEM、ANONYMOUS LOGONまたは同様の一般的な説明として識別されている場合は、ドメインコントローラー自体の内部処理を扱っているため、何が起こっているのかを調べるためにNTDS診断ログを作成する必要があります。この場合は質問を更新してください