Active Directory'de kimlik doğrulaması yaparken hangi alan kullanılır?

12

Active Directory kullanıcı nesneleri, tanımlayıcı olarak kabul edilebilecek bir dizi alan içerir. Aşağıda, ADUC'daki etiketleri ve özellik adları ile bunlardan bazıları listelenmiştir:

Tam Adı - cn
? - isim
Kullanıcı sAMAccountName logon - sAMAccountName
Kullanıcı UPN Oturum Açma: userPrincipalName
? - Ayırt edici adı

AD karşı kimlik doğrulayan özel kod yazarken geliştiricilerimizi bunlardan sadece birini kullanarak standart hale getirmeye çalışıyorum - sorun hangisi "doğru" olandan emin değilim ya da farklı olanlar farklı doğru olan koşullar. Yukarıdaki alanlardan herhangi birinin kullanılması gerektiğinden bile emin değilim!

Tutarlı kullanmak için başka birini seçti mi ve bu kararda sizi ne etkiledi? Sorunu açıklayan herhangi bir belge var mı?

active-directory ldap authentication

— dunxd
kaynak

Cn alanını kullanarak LDAP aracılığıyla kimlik doğrulaması yapan birkaç uygulama ile karşılaştım (hem dahili olarak geliştirildi, hem de başkalarının yaptığı şeyler). Ad veya soyadı alanlarını değiştirirseniz, bu alan artık AD Yönetici Merkezi'nde (Tam Ad olarak etiketlenir) otomatik olarak güncellenir, yani cn alanının bir kullanıcı adı alanı olarak kabul edilebileceğini varsayamazsınız. Bu geliştiriciler yanlış alanı kullanıyor mu veya Microsoft cn'yi bozdu mu?

— dunxd

18

Bir CN (ortak ad) oturum açmak için iyi değildir, çünkü tek başına bir CN bir kullanıcıyı benzersiz olarak tanımlamaz. Alabilirim

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

ve ayrıca bir

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

Bir kullanıcının CN'si aynı zamanda bir RDN'dir (göreceli ayırt edici ad.) Aynı CN'ye, ancak farklı DN'lere sahiptir. Kuruluşunuzda Ryan Ries adında iki kişi varsa sorunla karşılaştığınızı fark edebilirsiniz ve ikincisi için SamAccountName'i böyle bir şey yapmanız gerekir rries2.

Bir DN (ayırt edici ad) ile giriş yapmak iyi değildir, çünkü kullanıcı gibi bir sisteme kim giriş yapmak ister CN=ryan,OU=Texas,DC=brazzers,DC=com? Bir DN kullanmak bir kullanıcıyı benzersiz ve kesin olarak tanımlarken, yazmak zorunda olmak can sıkıcı bir durumdur. Bir dosya sistemindeki göreli yollar ve mutlak yollar arasındaki aynı kavramdır. Ayrıca, nesnenin arama yapmadan dizin dizininde tam olarak nerede olduğunu bildiğiniz anlamına da gelir. Hangi sık sık değil.

Buna Belirsiz Ad Çözümlemesi (ANR) adı verilir - ayırt edici adı olmadığında dizinde bir kullanıcı arar.

UPN (Kullanıcı asıl adı) oldukça iyidir çünkü e-posta adresleri gibi görünürler, kullanıcının kurumsal e-posta adresiyle aynı olabilirler, hatırlanması kolaydır ve ad aranacakları için giriş yapmayı tercih ederler önce yerel etki alanında, ormanda arama yapmadan önce.

Microsoft şunları söylüyor: UPN'nin amacı, kullanıcının yalnızca tek bir adı hatırlaması için e-posta ve oturum açma ad alanlarını birleştirmektir. UPN, Windows kullanıcıları için tercih edilen oturum açma adıdır. Kullanıcılar etki alanında oturum açmak için UPN'lerini kullanıyor olmalıdır. Oturum açma sırasında, bir UPN önce yerel etki alanı, sonra genel katalog aranarak doğrulanır. UPN'nin yerel etki alanında veya GC'de bulunmaması, UPN'nin reddedilmesine neden olur. Kullanıcı hesabı oluşturulduğunda UPN atanabilir, ancak zorunlu değildir .

Uygulamalarınızı tasarlarken sonunda "gerekli olmayan" bitin aklınızda bulundurun.

SamAccountName de iyidir çünkü SamAccountName'in etki alanındaki herkes için benzersiz olması gerekir (ancak orman değil.) Ayrıca, SamAccountNames kısadır. Çoğu kişi SamAccountNames ile giriş yapar, ancak sizi bir AD ormanında benzersiz olarak tanımlamasalar da, bu nedenle SamAccountName ile birlikte gitmek için bir etki alanı adı belirtmeniz gerekir, böylece sistem hangi etki alanında oturum açmaya çalıştığınızı bilir .

Daha fazla okumak için bu konuyla ilgili bazı harika belgeler:

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

— Ryan Ries
kaynak

4

Kullanıcı adına, birisinin giriş yapmak için yazacağı bir şey olarak atıfta bulunuyorsanız sAMAccountName, ya bir alan adıyla birlikte benzersiz olacak ya da userPrincipalNamebir orman içinde benzersiz olacak olanları öneririm .

Windows, benzersiz tanımlayıcı olarak kullanıcı adına kadar, tüm erişim denetim girdileri için SID'yi kullanır ve kullanıcı adlarından SID'lere çeviri için tam bir yöntem kümesi sağlar. SID'ler, bir etki alanındaki yeniden adlandırmaların ve hareketlerin bir etkisi olmadığından, yeni bir SID'de sonuçları silerek ve yeniden oluştururken, hesabın ömrü boyunca kullanıcı metaforuyla eşleşir.

Bu amaçla, LookupAccountNamekullanıcı adını temsil eden bir dize alır ve kullanıcının bulunduğu etki alanının sAMAccountName, SIDve etki alanı adını döndürür .

Kullanıcı daha sonra oturum açmak için pencereler tarafından desteklenen herhangi bir sözdizimini kullanabilir ve ek eğitim gerekmez.

— Mitch
kaynak

LookupAccountName UPN veya sAMAccountName veya tam nitelikli DOMAIN \ sAMAccountName veya yukarıdakilerin tümünü kabul ediyor mu? Bağlandığınız belgelerden net değil.

— dunxd

Dokümantasyon listeleri desteklediği formatlar: DOMAIN\Account, DOMAIN.COM\Account, Account, Account@DOMAIN.COM. Tam nitelikli isimlerin daha hızlı olduğunu söyler, ancak diğerleri hala kullanılabilir.

— Mitch

0

Kullanıcının kullanmak istediği adın biçimini seçmesine ve uygulama tarafında kullanıcının girdisini belirlemesine izin vermenizi öneririm. örneğin: Kullanıcı şunu yazarsa: kullaniciadi@alanadi.com - bunu UPN olarak düşünün ve AD'de UPN'yi arayın. Kullanıcı şunu yazarsa: kullaniciadi - önceden tanimlanmis bir varsayılan etki alani için samAccountName ve tabii ki kullanici alan \ kullaniciadi yaziyorsa - bunu belirtilen etki alanindan samAccountName olarak kabul edin. Her zaman kullanıcının SID'sini alın ve insanlar evlendiğinden ve kullanıcı adı değişebileceğinden SID'ye tüm izinleri atayın.

— Stan
kaynak