SQL सर्वर में, आपके पास या तो Windows खातों पर आधारित खाते हो सकते हैं, या अलग, विशिष्ट SQL खाते हो सकते हैं। दोनों विविधताओं के लिए, आपको प्रत्येक उपयोगकर्ता के लिए एक खाता . चाहिए जिसे आपके डेटाबेस का उपयोग करने की आवश्यकता है।
एकमात्र अपवाद Windows सुरक्षा समूह . के लिए SQL सर्वर लॉगिन बनाने की क्षमता है , जैसे MyAppUsers , और फिर उस लॉगिन के लिए आपके डेटाबेस में एक उपयोगकर्ता। इसके साथ, कोई भी Windows खाता जो उस सुरक्षा समूह (Windows/AD में) का सदस्य है, को भी आपके डेटाबेस को देखने/उपयोग करने की अनुमति होगी।
इस दृष्टिकोण के साथ, आप प्रशासन को भी स्थानांतरित कर रहे हैं जो आपके डेटाबेस का उपयोग SQL सर्वर से बाहर कर सकता है, क्योंकि यह वास्तव में केवल Windows सुरक्षा समूह में सदस्यता पर निर्भर करता है।
एक लॉगिन, एक उपयोगकर्ता - कई विंडोज़ खाते जिन्हें इसके साथ अनुमति मिलती है। मुझे एक विजेता की तरह लगता है!
अपडेट करें:
Windows AD समूह के लिए लॉगिन बनाएँ:
CREATE LOGIN [DOMAIN\GroupName] FROM WINDOWS
उस लॉगिन के आधार पर अपने डेटाबेस में एक उपयोगकर्ता बनाएँ:
USE (your database)
CREATE USER GroupNameUser
FOR LOGIN [DOMAIN\GroupName]
आपके SQL सर्वर कनेक्शन के लिए कनेक्शन स्ट्रिंग:
server=(your server);database=(your database);integrated security=SSPI;
मैं आपको और क्या बता सकता हूँ?
अपडेट #2: कोड नहीं Windows खातों का उपयोग यह है:
प्रत्येक . के लिए एक लॉगिन बनाएं उपयोगकर्ता जिसे आपके एप्लिकेशन का उपयोग करने की आवश्यकता है
CREATE LOGIN (some login name) WITH PASSWORD = 'Top$ecret'
उस लॉगिन के आधार पर अपने डेटाबेस में एक उपयोगकर्ता बनाएं - फिर से, प्रत्येक उपयोगकर्ता के लिए एक बार आपके ऐप का:
USE (your database)
CREATE USER UserName
FOR LOGIN (some login name)
आपके SQL सर्वर कनेक्शन के लिए कनेक्शन स्ट्रिंग:
server=(your server);database=(your database);
user id=UserName;Password=Top$ecret
लेकिन फिर से:इसके लिए पासवर्ड सहित एक लॉगिन और प्रत्येक डेटाबेस में एक उपयोगकर्ता की आवश्यकता होती है जिस पर आपको नज़र रखने की आवश्यकता है और संभवतः अपने डेटाबेस ऐप से "रीसेट पासवर्ड" संचालन आदि जैसे सामान करने की आवश्यकता है। व्यवस्थापक ओवरहेड के मामले में बहुत अधिक!
