PDCでユーザーを作成すると、0x800706BAエラーが発生します。誰かがそれを以前見たことがありますか？

Question

次のコードスニペットを使用して新しいユーザーを作成しようとしています。

using (var ad = 
    new PrincipalContext(ContextType.Domain, 
         "<domain>", 
         "<ad user>", 
         "<ad pass>")) 
{ 
    using (var aduser = new UserPrincipal(ad, "dummy", "password", false)) 
    { 
     aduser.Save(); 
    } 
} 

私は0x800706BAエラーコードでメッセージRPC Unavailableを取得しますが。

これまで見たことがありますか？

そして、より多くのimportat、それを解決！

Answer 1

.NET 3.5で提供されているAccountManagementインターフェイスは私の問題では機能しませんでしたが、忠実なLDAPが正常に動作しました。だから私は後世にここに投稿しています。

/* 
* First we need to create the user... 
*/ 
using (var dirEntry = new DirectoryEntry("LDAP://<IP/name>", 
             "<admin>", 
             "<admin pass>", 
              AuthenticationTypes.ServerBind)) 
{ 
    using (var newUser = dirEntry.Children.Add("CN=dummy", "user")) 
    { 
     newUser.Properties["samAccountName"].Value = "dummy"; 
     newUser.CommitChanges(); 
    } 
} 

/* 
* Then set its password! 
* 
* If the password is set in the same 
* transaction as the creation an error occurr. 
*/ 
using (var user = new DirectoryEntry("LDAP://<IP/name>/CN=dummy,DC=corp", 
            "<admin>", 
            "<admin pass>")) 
{ 
    user.Invoke("SetPassword", new object[] { "password" }); 
    user.CommitChanges(); 
} 

Answer 2

これは実際には一般的なドメイン設定の問題です。 Active DirectoryユーザーとコンピュータMMCスナップインを使用して、コンピュータから新しいユーザーを作成することもできなかったでしょう。私はあなたがWindows 2003 Admin toolsまたはWindows 2008 Remote Server Administration Toolをダウンロードし、最初にあなたのマシンから手動でそれを試みることをお勧めします。

これが一般的なドメイン設定の問題であることを証明したら、ServerFault.comに質問を投稿しようとすることができます。あなたはより速くより良い答えを得るでしょう。

パスワードリセットなどの多くのAD操作では、操作はMS-RPC経由で実行されますが、LDAPでは実行されません。だから、新しいADユーザーを作成するときに、RPC server unavailableというエラーメッセージが表示されることに驚くことはありません。

RPC server unavailableの原因には多くの理由がありますが、これはMSDN articileをチェックして運があるかどうかを確認できます。

以前にActive Directoryをセットアップしていない場合は、以下の基本的な情報が必要です。

1）正しいDNSサーバーを使用していることを確認する必要があります。 Active Directoryは、DNSに関する多くの有用な情報を格納します。あなたのドメイン名とPDC名だけではありません。それはいくつかのサービス記録を持っています。ターゲットPDCが設定したテストドメインだけの場合、多くのプログラマは、ローカルホストファイルを変更してPDCをIPアドレスに解決するだけで間違いを犯します。これはうまくいかず、道路に何か問題が発生します。

2）開発マシンの時計がPDCと同期していることを確認する必要があります。 Kerberos認証は時間の影響を受けます。 Active DirectoryはKerberos認証を使用しています。これは通常問題ではありませんが、一部のプログラマはVMを使いたいと考えています。同じホスト上で多数のVMを実行している場合、時間の遅れがあることが分かりました。

3）PDCのRPCサービスが実際に動作しており、ファイアウォールでブロックされていないことを確認してください。プロダクションドメインにアクセスしている場合、ネットワーク管理者は秘密の理由でポート135へのアクセスをブロックする可能性があります。

これは私が与えることができる最高のアドバイスです。お役に立てれば。上記のいずれにも役立たない場合は、ネットワークパケットを調べてトラブルシューティングを行う必要があると思います。 wiresharkを使用してネットワークトレースをキャプチャします。あなたはPrincipalContext

を構築するときに最悪のことは、コード上でしばらく が動作しないということであるContextOptions.SimpleBindを指定することで、暗号化を使用しないようにコードを修正していることを確認し、LDAPクエリを経由して 同じことをやってするように動作します

System.DirectoryService.AccountManagement namepsaceが内部DirectoryEntryを使用している魅力。 DirectoryEntryは内部でADSIを使用しています。 ADSIには、ユーザーのパスワードを設定する複雑なロジックがあります。

1. LDAPのパスワード更新
2. Kerberosはポート135
を使用して
3. MS-RPCコールをKerberosプロトコルを使用してパスワードを設定し
SSLチャネルを介して、次の順序でActive Directoryでユーザーのパスワードを設定するには、3つの方法がありますが、

SSLが設定されていない限り、ADSIはLDAPパスワード更新を使用しません。残念ながら、SSLは適切に設定されていません。それを機能させるには、特別な設定が必要です。 Windows自体がSSLをまったく使用する必要がないため、設定されていません。 Kerberosはうまく機能しています。したがって、あなたのケースでは、私はオプション1は使用されないと考えています。

オプション2は、正しいDNSを指定しなかったためにも機能しません。独自のローカルホストファイルを使用しています。

オプション3に進むと、現在のスレッドセキュリティコンテキストが許可されている場合にのみ、呼び出しを成功させることができます。あなたの説明から、あなたのワークステーションがそのターゲットドメインに全く参加していないように思えます。だから、私はあなたがKerberosトークンを持っているとは思わない。通常、NTLMを使用するには、これを元に戻す必要があります。ワークステーションで使用されているユーザーアカウントと同じユーザー名とパスワードを持つドメインユーザーがいる場合は、それが機能するはずです。また、ドメインユーザーアカウントに適切な権限があることを確認する必要があります。とにかく、それは私の知識の外です。

実際にはRPC server unavailableが届いています。あなたは3つのオプションすべてに失敗している必要があります。

はい、LDAPクエリを使用して機能しました。おそらく、SSLを使用しないシンプルなLDAPを使用しているからです。これは、あなたのパスワードが電線上にプレーンテキスト形式であることを意味します。

あなたのワークステーションを修正して、そのドメインコントローラでDNSを使用することをお勧めします。すべてがうまくいくはずです。

は、私はあなたを返信する前に、あなたの投稿のソリューションを読んでいない

を更新しました。 DirectoryEntryのアプローチが有効になっている場合、なぜAccountManagementのアプローチが機能しないのか分かりません。その違いを理解するためには、それを分解する必要があるかもしれません。