Active Directoryに対して認証するときに使用するフィールドはどれですか？

Active Directoryユーザーオブジェクトには、識別子と見なすことができるいくつかのフィールドが含まれています。以下に、ADUCのラベルと属性名とともにこれらの一部をリストします。

• 氏名-cn
• ？- 名前
• ユーザーsAMAccountNameログオン-sAMAccountName
• ユーザーUPNログオン：userPrincipalName
• ？- 識別名

私は、ADに対して認証するカスタムコードを記述するときに、開発者にこれらの1つのみを使用して標準化するようにしようとしています。状況。上記のフィールドを使用する必要があるかどうかさえわかりません！

他の誰かが一貫して使用するものを選びましたか？その決定にあなたに影響を与えたものは何ですか？問題を明確にするドキュメントはありますか？

CN（一般名）は、CNだけではユーザーを一意に識別しないため、ログインには適していません。私が持つことができる

CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com

そして私も持つことができます

CN=Ryan Ries,OU=New York,DC=Domain,DC=com

ユーザーのCNもRDN（相対識別名）です。ユーザーは同じCNを持ちますが、DNは異なります。組織内にRyan Riesという名前の2人のユーザーがいる場合、問題が発生することに気付くかもしれません。2番目のSamAccountNameを次のようにする必要がありますrries2。

DN（識別名）は、次のようなユーザー名でシステムにログインしたいので、ログインに適していませんCN=ryan,OU=Texas,DC=brazzers,DC=com。DNを使用するとユーザーが一意かつ明確に識別されますが、入力するのは面倒です。ファイルシステム上の相対パスと絶対パスの概念は同じです。また、オブジェクトを検索することなく、ディレクトリ構造のどこにオブジェクトがあるかを正確に知っていることも意味します。あなたはしばしばそうしません。

これはあいまいな名前解決（ANR）と呼ばれます-ユーザーの識別名がないときにユーザーのディレクトリを検索します。

UPN（ユーザープリンシパル名）は、メールアドレスのように見え、ユーザーの会社のメールアドレスと同じである可能性があり、覚えやすく、名前が検索されるため、ログインすることをお勧めします。フォレストで検索する前に、まずローカルドメインで検索します。

マイクロソフトによると：UPNのポイントは、ユーザーが1つの名前を覚えるだけで済むように、電子メールとログオンの名前空間を統合することです。UPNは、Windowsユーザーの優先ログオン名です。ユーザーは、UPNを使用してドメインにログオンする必要があります。ログオン時に、最初にローカルドメインを検索し、次にグローバルカタログを検索することにより、UPNが検証されます。ローカルドメインまたはGCでUPNが見つからないと、UPNが拒否されます。UPNは割り当てることができますが、ユーザーアカウントの作成時に必須ではありません。

アプリケーションを設計するときは、最後に「不要」ビットを付けてください。

SamAccountNameは、ドメイン内の全員（フォレストではなく）に対して一意である必要があるため、SamAccountNameも優れています。さらに、SamAccountNamesは短いです。ADフォレストで一意に識別されない場合でも、ほとんどの人はSamAccountNamesを使用してログインします。そのため、SamAccountNameと共に使用するドメイン名を指定して、システムがログインしようとしているドメインを認識できるようにする必要があります。

詳細については、この問題に関する優れたドキュメントを次に示します。

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx

ユーザーがログインするために入力するものとしてユーザー名を参照している場合sAMAccountName、ドメイン名と組み合わせて一意になる、またはuserPrincipalNameフォレスト内で一意になるのいずれかをお勧めします。

ユーザー名が一意の識別子である限り、Windowsはすべてのアクセス制御エントリにSIDを使用し、ユーザー名からSIDに変換するためのすべてのメソッドを提供します。ドメイン内での名前の変更と移動は効果がありませんが、SIDはアカウントの存続期間中のユーザーのメタファーと一致しますが、削除して再作成すると新しいSIDになります。

そのために、私が呼ぶようなLookupAccountNameユーザー名を表す文字列を受け取り、戻りれ、sAMAccountName、SIDおよびドメインのドメイン名をユーザーが発見されました。

その後、ユーザーはWindowsでサポートされている任意の構文を使用してログインでき、追加のトレーニングは必要ありません。

ユーザーが使用する名前の形式を選択し、アプリケーション側でユーザーの入力を決定できるようにすることをお勧めします。たとえば、次のように入力します。username@ domain.com-UPNと見なし、ADでUPNを検索します。ユーザーが次のように入力した場合：ユーザー名-定義済みのデフォルトドメインのsamAccountNameと見なし、もちろんユーザーがdomain \ usernameと入力した場合-指定したドメインのsamAccountNameと見なします。ユーザーは結婚し、ユーザー名が変更される可能性があるため、常にユーザーのSIDを取得し、すべての権限をSIDに割り当てます。