2015-06-17 18 views
8

Thông tin: Chúng tôi có ứng dụng bên thứ 3 mà chúng tôi sử dụng để sản xuất tại công ty của chúng tôi. Chương trình này sử dụng DSN để kết nối tới cơ sở dữ liệu SQL Server 2012 của chúng tôi thông qua ODBC. Ứng dụng này hoạt động đúng theo Server 2003 (MADC 2.8) tuy nhiên khi tôi mang nó đến Server 2008 x86 (DAC 6.0), tôi nhận được một kết nối thất bại với "Microsoft OLE DB Provider SQL Server Đăng nhập thất bại cho người dùng XXX". Tôi có cảm giác điều này là do mặc định "thông tin bảo mật liên tục" thay đổi từ True thành False trên các máy chủ Windows bắt đầu với máy chủ 2008 trở lên (Thay đổi được thực hiện trong DAC 6.0). Tôi không có quyền truy cập để thay đổi chuỗi kết nối bên trong ứng dụng vì nó là bên thứ 3. như đã thấy trong articleThay đổi ADO.Net "Thông tin bảo mật liên tục" mặc định quay lại True

Câu hỏi này: Có cách nào để thay đổi hành vi của ADO.Net để giá trị này được mặc định là True chứ không phải bên ngoài False của chuỗi kết nối. Tôi muốn ít nhất có thể chứng minh hoặc bác bỏ rằng đây là tính năng gây ra vấn đề.

Lưu ý: Tôi nhận thấy đây là vấn đề bảo mật lớn giả mạo cài đặt này và chúng tôi sẽ thực hiện các biện pháp phòng ngừa chính xác nếu nó được thay đổi để đảm bảo máy chủ và ứng dụng bị cô lập.

Giải pháp: Được cung cấp bởi @William bên dưới. Nếu bạn đang cập nhật ứng dụng của bên thứ ba SQL Server Từ Server 2003 đến Server 2008+ và bạn đang nhận được kết nối như ở trên, nơi bạn không đặt vào 2003, hãy đặt mật khẩu cho tài khoản SQL để trống (tạm thời hoặc trong dàn dựng, đây là rất nguy hiểm để trống trong sản xuất) để kiểm tra xem ứng dụng có hoạt động trở lại khi mật khẩu trống được cung cấp hay không. Nếu có thì ứng dụng sẽ không đặt Thông tin bảo mật liên tục trong chuỗi kết nối và giá trị được đặt mặc định thành true bây giờ mặc định là false. Ứng dụng của bạn có thể bị giới hạn sử dụng trong máy chủ 2003 và có thể không hoạt động đúng trên máy chủ 2008+. Không có cách nào mà tôi có thể tìm thấy để có được giá trị mặc định trở lại đúng.

+1

Bạn đã thử chỉnh sửa kết nối DSN của mình trong Registry trong [HKLM] \ SOFTWARE \ ODBC \ ODBC.INI \? – KarmaEDV

+0

Tôi có. Vì vậy, gần như tôi có thể nói đây là những gì sẽ xảy ra mỗi khi ứng dụng khởi động. Nếu ứng dụng chưa được thiết lập, nó sẽ tạo một tệp .DSN mới trong thư mục gốc, sau đó cho phép người dùng cuối cấu hình tệp này bằng các thiết đặt, khi người dùng đăng nhập vào các thiết đặt trong sổ đăng ký ODBC được cập nhật từ lần đăng nhập thành công cuối cùng, sau đó DSN reg được sử dụng cho ứng dụng. Chuỗi kết nối được xây dựng trong mã đối tượng và không được lưu trữ trong sổ đăng ký. tôi đã thử thêm các khóa bổ sung vào sổ đăng ký theo DSN nhưng chúng bị ghi đè hoặc không được tải vào đối tượng trong mã. –

+1

Tôi gặp vấn đề tương tự. Chúng ta có một ứng dụng kế thừa (mà chúng ta không có nguồn) mà chúng ta cần chuyển sang sử dụng Windows 2008 và ứng dụng dựa vào việc có thể kéo chuỗi kết nối ra khỏi đối tượng kết nối để tạo thêm các kết nối. Nó đã được viết trước khi các hiệu ứng của Persist Security Info nổi tiếng, do đó, nó không chỉ định tất cả (ngầm hoàn toàn dựa vào mặc định). Với giá trị mặc định thay đổi thành False trong Windows Vista và sau đó, ứng dụng sẽ không chạy ở đó. Tôi đã không tìm thấy bất kỳ cách nào để đặt mặc định hệ thống (hoặc người dùng) cho Thông tin Bảo mật Persist. – William

Trả lời

4

Nếu ứng dụng đang sử dụng đối tượng kết nối hiện có để xây dựng chuỗi kết nối mới, thì có thể có cách giải quyết cho vấn đề này - tùy thuộc vào ứng dụng và hạn chế bảo mật.

Vì vấn đề này có thể không tồn tại khi sử dụng bảo mật tích hợp, chúng tôi có thể giả định "bảo mật tiêu chuẩn SQL Server" là một yêu cầu. Nếu một mật khẩu trống được sử dụng cho tài khoản máy chủ SQL, thì khi chuỗi kết nối mới được xây dựng, nó sẽ chính xác (phần nào do tai nạn).

+0

Tận hưởng tiền thưởng, đây là một cách chắc chắn để chứng minh nếu thông tin bảo mật liên tục không được đặt trong chuỗi kết nối. Giống như bạn nói để lại một mật khẩu như thế này là trống là hơi nguy hiểm và không nên được thực hiện trong một thiết lập sản xuất. Trong giải quyết vấn đề của chúng tôi, chúng tôi sẽ cần phải suy nghĩ rất cẩn thận nếu chúng tôi dự định thực hiện thay đổi này. Cám ơn sự giúp đỡ của bạn! –

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