2010-08-26 36 views
15

Belirli bir Active Directory kullanıcısı için UserPrincipal dosyasını edinmek üzere .NET System.DirectoryServices.AccountManagement kitaplığını kullanmaya çalışıyorum.UserPrincipal.FindByIdentity İzinler

aşağıdaki kod var:

PrincipalContext context = new PrincipalContext(ContextType.Domain, "DomainName"); 
userPrincipal = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username); 

Bu kod geçerli bir etki alanı kullanıcısı olarak çalışan, ancak bunu çalıştırmak zaman şu istisna olsun:

System.DirectoryServices. DirectoryServicesCOMException (0x8007052E): Oturum açma hatası: bilinmeyen kullanıcı adı veya hatalı parola. ilginç olan şey

sorunsuz bir, aynı bağlam kullanarak, aşağıdaki arama yapabilirsiniz olmasıdır:

context.ValidateCredentials(username, password, ContextOptions.Negotiate) 

Fikirler?

+0

kontrol görüyoruz sebebidir: http://stackoverflow.com/questions/1863801/findbyidentity-failing-with-pricipaloperationexception-in-asp-net-webapp/3515280#3515280 Bu değil –

cevap

12

Kullanıcı adı ve parola alan PrincipalContext yapıcısını kullanmanız gerekir.

Validate'nin çalışmasının nedeni, sağlanan kimlik bilgilerini dizine bağlanmak için kullanmasıdır.

+0

bana çok şey ifade ediyor. ValidateCredentials çağrısının geçerli kimlik bilgilerini kullandığını söylüyorsunuz, ancak söz konusu içeriği kabul eden UserPrincipal.FindByIdentity çağrısı değil mi? Eğer durum buysa, çağrı yapmak için mevcut kimliği (iş parçacığının kimliğinde olduğu gibi) nasıl kullanabilirim? Yükleme zamanında bir hizmet hesabı kurulumu olarak çalışan bir uygulama olduğundan, geçmek için bir kullanıcı adı veya şifrem yok. Bu kimlik bilgilerini her yerde saklayamıyorum. – RMD

+0

Yanlış anladığınızı düşünüyorum, ValidateCredentials, ValidateCredentials için parametre listesinde sağlanan kimlik bilgilerini kullanır; tanımladığınız Bağlamın, geçerli iş parçacığınınkiyle ilişkili hiçbir kimlik bilgisi yoktur. Sorunlarınızın sunucunun yapılandırmasında/dağıtımında bulunduğundan şüpheleniyorum. Hizmeti çalıştıran hesabın alan adına atandığından emin olun. – Nate

+0

Evet, yanlış anladım. Geçerli iş parçacığının kullanıcısı kesinlikle geçerli bir etki alanı kullanıcısıdır. "Alan adı içinde yetki verildi" dediğinizde, tam olarak ne demek istiyorsunuz? – RMD

3

Kayıtlı ağ kimlik bilgileriniz olduğu anlaşılıyor. Windows'da, bir ağ kaynaklarına ulaşmaya çalışırken farklı bir ağ kimlik bilgilerini kullanmayı belirtebilirsiniz. Yanlış bir ağ kimlik bilgilerini ayarlayarak gördüğünüzle aynı sorunu yeniden üretebilirim.

Etki alanınızın yourdomain.com olarak adlandırıldığını varsayarak, Windows'unuzu, etki alanınız.com'a sahip olan bilgisayarlarla her görüştüğünde her zaman belirli bir kullanıcı adı ve parola kullanmasını söyleyebilirsiniz.

===, Windows 7/2008 ===

  1. Başlat "Crendentail Yöneticisi".
  2. Windows kimlik bilgileri bölümünün altında
  3. , yanlış kullanıcı adı veya yanlış şifre koymak kullanıcı adı ve şifre olarak
  4. *.yourdomain.com koymak ağ adresini Add a Windows credentials
  5. , tıklayın

=== Windows XP/2000/control keymgr.dll 2003 ===

  1. Başlat ve Çalıştır
  2. Tipi Bu gerçekten ise
  3. tıklayın yanlış kullanıcı adı veya yanlış parola

koymak, kullanıcı adı ve şifre olarak

  • *.yourdomain.com koymak sunucu metin kutusuna
  • iletişim "Depolanan Kullanıcı Adları ve Parolalar", renkli Ekle Karşı karşıya olduğunuz sorun, kolay düzeltme saklanan şifreleri kaldırmaktır.

    Neden context.ValidateCredentials (kullanıcı adı, parola, ContextOptions.Negotiate) çalışır?Bunun nedeni, uername ve password yeniden sağladığınızdan başka bir Kerberos/NTLM kimlik doğrulamasını başlatıyor olmanızdır. Başlık altında, Kerberos seçildiyse, alan adı denetleyicisine sağlanan kullanıcı adı ve parolayı gönderir ve bir Kerberos TGT bileti için değiştirir. Ardından, makineniz bu TGT bileti kullanılarak LDAP sunucusunda bir hizmet bileti alır. Ardından, makineniz bu hizmet biletini LDAP sunucusuna gönderecektir. Bu servis biletinin geçerli oturum açma oturumunda korunmayacağını unutmayın.

    Neden UserPrincipal.FindByIdentity çalışmıyor? Kayıtlı şifreniz yoksa, normalde işe yarayacaktır çünkü Windows LDAP sunucusu servis biletini değiştirmek için sadece geçerli oturum açma kullanıcı TGT biletini kullanacaktır. İlgili kullanıcı adı/şifre doğrulama işlemi yoktur. Ancak, kötü bir kullanıcı adı parolanız varsa, Windows geçerli oturum açma kullanıcı TGT biletini kullanmaması gerektiğini düşünür. Bunun yerine, depolanan ağ şifresini kullanarak yeni bir TGT bileti almalıdır. Yani bu cevabı System.DirectoryServices.DirectoryServicesCOMException (0x8007052E): Logon failure: unknown user name or bad password.

  • +0

    İlginç. Bu kod, bir ASP.NET uygulamasının bağlamı ile çalışmaktadır, bu yüzden saklanan şifrelerin bir fark yaratacağını düşünmüyorum. Doğru olup olmadığını kontrol edeceğim. – RMD

    +0

    @RMD Ah, bu bilgiyi kaçırdınız. Windows kimlik doğrulaması kullanıyor musunuz? Yoksa sadece AD'ye erişmek için yerel servis hesabını mı kullanıyorsunuz? –

    +0

    Orijinal yazımda dediğim gibi: "Bu kod geçerli bir etki alanı kullanıcısı olarak çalışıyor". – RMD