2009-05-06 57 views
17

Tôi đã luôn luôn nghĩ rằng để kết nối với máy chủ SQL bằng cách sử dụng xác thực cửa sổ với thông tin xác thực rõ ràng, bạn phải LogonUser, Impersonate, sau đó kết nối.Cơ sở dữ liệu + Xác thực Windows + Tên người dùng/Mật khẩu?

Dường như với tôi rằng this link cho thấy rằng có thể kết nối với máy chủ SQL mà không gặp phải rắc rối nào, chỉ cần xác định "uid = ...; pwd = ..." trong chuỗi kết nối. Tôi đã thử nghiệm phương pháp này chỉ để chắc chắn nó không hoạt động, và - lo and behold - nó không. Nếu bài đăng trên blog đó không có trên msdn.com, tôi sẽ chỉ bỏ qua nó là noob talk, nhưng đúng vậy.

Có ai có ý tưởng nào tôi bị thiếu không?

EDIT1: Nhiều người trả lời hiểu lầm những gì tôi đang đề cập đến. Đây là một bản sao/dán những gì tôi đã nói về. Đó là không tích hợp SQL, cũng không phải nó là một mạo danh ASP.NET do IIS:

string sql4 = String.Format(
    @"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);  
// Database + Windows Authentication + Username/Password 
+0

đó có thể là thông tin đăng nhập máy chủ sql. – DForck42

+0

QUOTING: chuỗi sql4 = String.Format (@ "Nguồn dữ liệu = {0}; Bảo mật tích hợp = SSPI; uid = ; pwd = ", máy chủ); // Cơ sở dữ liệu + Xác thực Windows + Tên người dùng/Mật khẩu – galets

Trả lời

27

Có hai loại bảo mật riêng biệt với SQL Server. "Xác thực Windows" và "Xác thực máy chủ SQL". Khi bạn thấy uid và pwd bạn thấy cái sau. Các uid trong trường hợp này không phải là một hiệu trưởng Windows - hệ điều hành không biết gì về nó.

Vì vậy, câu trả lời cho câu hỏi của bạn là, no, bạn không thể chuyển tên người dùng và mật khẩu Windows trong chuỗi kết nối để đăng nhập vào SQL Server.

+0

Bảo mật tích hợp = SSPI [cho biết NT auth]; uid = ; pwd = [cho biết sql auth] - cả hai tùy chọn trong một dòng, tại sao họ sử dụng nó trong ví dụ này? – galets

+2

Nó không phải là một ví dụ. Đó là một bài báo. Đi đọc bài báo và bạn sẽ hiểu. –

+0

Yep .. Tôi đoán tôi chưa đọc kỹ bài viết này :( – galets

3

Nó phụ thuộc - nếu bạn kết nối từ một dòng lệnh hoặc ứng dụng Winforms TRỰC TIẾP đến SQL Server, bạn DÙ chỉ định "Integrated Bảo mật = SSPI; " và sau đó sử dụng thông tin đăng nhập Windows của bạn làm thông tin đăng nhập, HOẶC bạn chỉ định "id người dùng = ....; pwd = ....." - nhưng đó là sau đó đăng nhập SQL - KHÔNG đăng nhập Windows của bạn.

Bạn đề cập đến "mạo danh và sau đó kết nối" - dường như chỉ ra ASP.NET - đó là một câu chuyện hoàn toàn khác một lần nữa. Nếu bạn mạo danh, thì về cơ bản bạn đang sử dụng thông tin đăng nhập Windows của mình, ví dụ: máy chủ web sẽ "mạo danh" bạn và đăng nhập với bạn (sử dụng thông tin đăng nhập Windows của bạn). Trong trường hợp đó, một lần nữa, không cần chỉ định "uid = ....; pwd = ....." (nếu có, nó sẽ bị bỏ qua).

Vì liên kết mà bạn đã đề cập hiển thị rõ ràng - nếu bạn có thể kết nối trực tiếp và bạn chỉ định "Tích hợp bảo mật = SSPI;" thì điều này sẽ được ưu tiên hơn bất kỳ uid = ...; pwd = .... mà bạn có thể cũng đã chỉ định và ghi lại bạn bằng cách sử dụng thông tin đăng nhập Windows của bạn; những uid = ...; pwd = .... miếng được bỏ qua.

Marc

2

Bài viết và điểm liên quan đến bảo mật SQL, không được tích hợp bảo mật. Bạn có thể chuyển thông tin đăng nhập cho người dùng SQL và đăng nhập theo cách này nếu xác thực SQL (chế độ hỗn hợp) được bật. Nếu máy chủ SQL được thiết lập để chỉ sử dụng bảo mật tích hợp thì điều này sẽ không hoạt động. Nó cũng sẽ không hoạt động để cho phép đăng nhập bằng thông tin đăng nhập Windows.

1

Trong cửa hàng của chúng tôi, chúng tôi thường xuyên sử dụng các chuỗi kết nối như bạn mô tả. Không vấn đề gì. Nhưng cơ sở dữ liệu máy chủ sql của bạn phải được thiết lập để sử dụng bảo mật sql, không phải cửa sổ xác thực.

Một chuỗi kết nối mẫu (từ web.config) trong ứng dụng của chúng tôi trông giống như:

<connectionStrings> 
<add name="ConfigurationData" connectionString="server=DevServer; 
database=travel_expense_management_dv;uid=userid;pwd=password!;" 
providerName="System.Data.SqlClient" /> 
</connectionStrings> 

Mặt khác, các guru DBA cho cửa hàng của chúng tôi đặt tôi lên một cơ sở dữ liệu cá nhân trên máy chủ chính mà có tích hợp bảo mật với đăng nhập Windows của tôi.Tôi không cần uid và pwd vì nó lấy thông tin xác thực của tôi từ ngữ cảnh.

0

Vâng, như bạn nói, bài báo đề cập đến điều này:

string sql4 = String.Format(@"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);  // Database + Windows Authentication + Username/Password 

Nhưng nếu bạn đọc kỹ vài dòng sau đó, nó nói này:

chuỗi sql4 -> Logs ở với Windows đăng nhập , I E. được ưu tiên hơn tên người dùng/mật khẩu.

:)

0

này rất cũ nhưng có lẽ ai đó có cùng một vấn đề.

Bạn thể kết nối sử dụng WindowsAuthenticationxác định id người dùng và mật khẩu trên chuỗi kết nối của bạn, nhưng không phải trên mọi thiết bị. Bạn có thể đạt được điều này ví dụ: trên thiết bị WinCE (https://technet.microsoft.com/en-us/library/aa275613(v=sql.80).aspx).

Tôi không biết liệu bạn có thể thực hiện điều tương tự trên hệ điều hành khác chỉ bằng chuỗi kết nối (không thực hiện thao tác mạo danh).

Hy vọng điều đó sẽ hữu ích.

0

cũng chỉ đóng góp cho một số người vẫn gặp sự cố như thế này. Dựa trên kinh nghiệm của tôi nếu bạn không chỉ định bất kỳ người dùng/mật khẩu nào trong kết nối của bạn, nó sẽ tự động kết nối với db bằng cách sử dụng xác thực cửa sổ. Có nghĩa là nó sẽ nhận được userid và đó là thông tin xác thực của người dùng đã đăng nhập vào máy. Hệ thống sẽ cho phép bạn kết nối với cơ sở dữ liệu nếu nó xác định rằng userid của bạn tồn tại/được tạo trong cơ sở dữ liệu. Nhưng một khi bạn chỉ định userid và mật khẩu của bạn trong kết nối của bạn nó bỏ qua các cửa sổ xác thực và sử dụng xác thực máy chủ sql thay thế.

Các vấn đề liên quan