Làm thế nào để xác nhận thông tin tên miền?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Security;
using System.DirectoryServices.AccountManagement;

public struct Credentials
{
    public string Username;
    public string Password;
}

public class Domain_Authentication
{
    public Credentials Credentials;
    public string Domain;

    public Domain_Authentication(string Username, string Password, string SDomain)
    {
        Credentials.Username = Username;
        Credentials.Password = Password;
        Domain = SDomain;
    }

    public bool IsValid()
    {
        using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, Domain))
        {
            // validate the credentials
            return pc.ValidateCredentials(Credentials.Username, Credentials.Password);
        }
    }
}

Tôi đang sử dụng đoạn mã sau để xác thực thông tin đăng nhập. Phương pháp hiển thị dưới đây sẽ xác nhận nếu thông tin đăng nhập là chính xác và nếu không, mật khẩu đã hết hạn hoặc cần thay đổi.

Tôi đã tìm kiếm thứ gì đó như thế này từ lâu ... Vì vậy, tôi hy vọng điều này sẽ giúp được ai đó!

using System;
using System.DirectoryServices;
using System.DirectoryServices.AccountManagement;
using System.Runtime.InteropServices;

namespace User
{
    public static class UserValidation
    {
        [DllImport("advapi32.dll", SetLastError = true)]
        static extern bool LogonUser(string principal, string authority, string password, LogonTypes logonType, LogonProviders logonProvider, out IntPtr token);
        [DllImport("kernel32.dll", SetLastError = true)]
        static extern bool CloseHandle(IntPtr handle);
        enum LogonProviders : uint
        {
            Default = 0, // default for platform (use this!)
            WinNT35,     // sends smoke signals to authority
            WinNT40,     // uses NTLM
            WinNT50      // negotiates Kerb or NTLM
        }
        enum LogonTypes : uint
        {
            Interactive = 2,
            Network = 3,
            Batch = 4,
            Service = 5,
            Unlock = 7,
            NetworkCleartext = 8,
            NewCredentials = 9
        }
        public  const int ERROR_PASSWORD_MUST_CHANGE = 1907;
        public  const int ERROR_LOGON_FAILURE = 1326;
        public  const int ERROR_ACCOUNT_RESTRICTION = 1327;
        public  const int ERROR_ACCOUNT_DISABLED = 1331;
        public  const int ERROR_INVALID_LOGON_HOURS = 1328;
        public  const int ERROR_NO_LOGON_SERVERS = 1311;
        public  const int ERROR_INVALID_WORKSTATION = 1329;
        public  const int ERROR_ACCOUNT_LOCKED_OUT = 1909;      //It gives this error if the account is locked, REGARDLESS OF WHETHER VALID CREDENTIALS WERE PROVIDED!!!
        public  const int ERROR_ACCOUNT_EXPIRED = 1793;
        public  const int ERROR_PASSWORD_EXPIRED = 1330;

        public static int CheckUserLogon(string username, string password, string domain_fqdn)
        {
            int errorCode = 0;
            using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, domain_fqdn, "ADMIN_USER", "PASSWORD"))
            {
                if (!pc.ValidateCredentials(username, password))
                {
                    IntPtr token = new IntPtr();
                    try
                    {
                        if (!LogonUser(username, domain_fqdn, password, LogonTypes.Network, LogonProviders.Default, out token))
                        {
                            errorCode = Marshal.GetLastWin32Error();
                        }
                    }
                    catch (Exception)
                    {
                        throw;
                    }
                    finally
                    {
                        CloseHandle(token);
                    }
                }
            }
            return errorCode;
        }
    }

using System;
using System.Collections.Generic;
using System.Text;
using System.DirectoryServices.AccountManagement;

class WindowsCred
{
    private const string SPLIT_1 = "\\";

    public static bool ValidateW(string UserName, string Password)
    {
        bool valid = false;
        string Domain = "";

        if (UserName.IndexOf("\\") != -1)
        {
            string[] arrT = UserName.Split(SPLIT_1[0]);
            Domain = arrT[0];
            UserName = arrT[1];
        }

        if (Domain.Length == 0)
        {
            Domain = System.Environment.MachineName;
        }

        using (PrincipalContext context = new PrincipalContext(ContextType.Domain, Domain)) 
        {
            valid = context.ValidateCredentials(UserName, Password);
        }

        return valid;
    }
}

Kashif Mushtaq Ottawa, Canada

Đây là cách xác định người dùng cục bộ:

    public bool IsLocalUser()
    {
        return windowsIdentity.AuthenticationType == "NTLM";
    }

Chỉnh sửa bởi Ian Boyd

Bạn không nên sử dụng NTLM nữa. Nó quá cũ và tệ đến mức Trình xác minh ứng dụng của Microsoft (được sử dụng để bắt các lỗi lập trình phổ biến) sẽ đưa ra cảnh báo nếu phát hiện bạn sử dụng NTLM.

Đây là một chương trong tài liệu Trình xác minh ứng dụng về lý do tại sao họ có bài kiểm tra nếu ai đó sử dụng nhầm NTLM:

Tại sao cần bổ trợ NTLM

NTLM là một giao thức xác thực lỗi thời với các lỗ hổng có khả năng ảnh hưởng đến bảo mật của các ứng dụng và hệ điều hành. Thiếu sót quan trọng nhất là thiếu xác thực máy chủ, điều này có thể cho phép kẻ tấn công lừa người dùng kết nối với máy chủ giả mạo. Là một hệ quả của việc xác thực máy chủ bị thiếu, các ứng dụng sử dụng NTLM cũng có thể dễ bị tấn công bởi một loại tấn công được gọi là tấn công phản xạ Hồi giáo. Điều này sau đó cho phép kẻ tấn công chiếm quyền điều khiển cuộc trò chuyện xác thực của người dùng đến một máy chủ hợp pháp và sử dụng nó để xác thực kẻ tấn công vào máy tính của người dùng. Các lỗ hổng và cách khai thác chúng của NTLM là mục tiêu của việc tăng cường hoạt động nghiên cứu trong cộng đồng bảo mật.

Mặc dù Kerberos đã có sẵn trong nhiều năm, nhiều ứng dụng vẫn được viết để chỉ sử dụng NTLM. Điều này không cần thiết làm giảm tính bảo mật của các ứng dụng. Tuy nhiên, Kerberos không thể thay thế NTLM trong tất cả các kịch bản - chủ yếu là những nơi khách hàng cần xác thực với các hệ thống không được kết nối với một miền (mạng gia đình có lẽ là phổ biến nhất trong số này). Gói bảo mật đàm phán cho phép thỏa hiệp tương thích ngược sử dụng Kerberos bất cứ khi nào có thể và chỉ hoàn nguyên về NTLM khi không có tùy chọn nào khác. Chuyển đổi mã để sử dụng Đàm phán thay vì NTLM sẽ tăng đáng kể bảo mật cho khách hàng của chúng tôi trong khi giới thiệu một vài hoặc không có sự tương thích ứng dụng. Đàm phán tự nó không phải là một viên đạn bạc - có những trường hợp kẻ tấn công có thể buộc hạ cấp xuống NTLM nhưng những điều này khó khai thác hơn đáng kể. Tuy nhiên, một cải tiến ngay lập tức là các ứng dụng được viết để sử dụng đàm phán chính xác sẽ tự động miễn nhiễm với các cuộc tấn công phản chiếu NTLM.

Bằng cách thận trọng cuối cùng đối với việc sử dụng NTLM: trong các phiên bản Windows trong tương lai, có thể vô hiệu hóa việc sử dụng NTLM tại hệ điều hành. Nếu các ứng dụng có sự phụ thuộc lớn vào NTLM, đơn giản là chúng sẽ không xác thực được khi NTLM bị tắt.

Cách thức hoạt động của Plug-in

Trình cắm Verifier phát hiện các lỗi sau:

• Gói NTLM được chỉ định trực tiếp trong lệnh gọi tới AcquireCredentialsHandle (hoặc API trình bao bọc cấp cao hơn).

• Tên mục tiêu trong lệnh gọi LaunchizeSecurityContext là NULL.

• Tên mục tiêu trong lệnh gọi LaunchizeSecurityContext không phải là tên miền kiểu SPN, UPN hoặc NetBIOS được tạo đúng.

Hai trường hợp sau sẽ buộc đàm phán quay trở lại NTLM trực tiếp (trường hợp đầu tiên) hoặc gián tiếp (bộ điều khiển miền sẽ trả về một hiệu trưởng không được tìm thấy lỗi trong trường hợp thứ hai khiến cho đàm phán rơi trở lại).

Trình cắm cũng ghi lại các cảnh báo khi phát hiện hạ cấp xuống NTLM; ví dụ: khi Bộ điều khiển miền không tìm thấy SPN. Chúng chỉ được ghi lại dưới dạng cảnh báo vì chúng thường là các trường hợp hợp pháp - ví dụ: khi xác thực hệ thống không tham gia miền.

Dừng NTLM

5000 - Ứng dụng đã chọn gói NTLM rõ ràng

Mức độ nghiêm trọng - Lỗi

Ứng dụng hoặc hệ thống con rõ ràng chọn NTLM thay vì đàm phán trong lệnh gọi tới AcquireCredentialsHandle. Mặc dù máy khách và máy chủ có thể xác thực bằng Kerberos nhưng điều này bị ngăn chặn bởi sự lựa chọn rõ ràng của NTLM.

Cách khắc phục lỗi này

Cách khắc phục lỗi này là chọn gói Đàm phán thay cho NTLM. Làm thế nào điều này được thực hiện sẽ phụ thuộc vào hệ thống con Mạng cụ thể đang được sử dụng bởi máy khách hoặc máy chủ. Một số ví dụ được đưa ra dưới đây. Bạn nên tham khảo tài liệu về thư viện hoặc bộ API cụ thể mà bạn đang sử dụng.

APIs(parameter) Used by Application    Incorrect Value  Correct Value  
=====================================  ===============  ========================
AcquireCredentialsHandle (pszPackage)  “NTLM”           NEGOSSP_NAME “Negotiate”