क्या मुझे दूरस्थ उपयोगकर्ताओं के लिए अपनी सक्रिय निर्देशिका को सार्वजनिक इंटरनेट पर उजागर करना चाहिए?


46

मेरे पास एक क्लाइंट है, जिसका कार्यबल ऐप्पल और विंडोज 7 पीसी / लैपटॉप के मिश्रण का उपयोग करके पूरी तरह से दूरस्थ कर्मचारियों से युक्त है।

उपयोगकर्ता इस समय एक डोमेन के खिलाफ प्रमाणित नहीं करते हैं, लेकिन संगठन कई कारणों से उस दिशा में बढ़ना चाहते हैं। ये कंपनी के स्वामित्व वाली मशीनें हैं, और फर्म खाता निष्क्रियीकरण, समूह नीति और कुछ प्रकाश डेटा-हानि की रोकथाम (रिमोट मीडिया, यूएसबी आदि को अक्षम करना) पर कुछ नियंत्रण रखना चाहता है, वे चिंतित हैं कि AD तक पहुंचने के लिए वीपीएन प्रमाणीकरण की आवश्यकता होती है। विशेष रूप से एक समाप्त कर्मचारी के चौराहे पर और एक दूरस्थ मशीन पर क्रेडेंशियल बोझिल होगा।

संगठन की अधिकांश सेवाएँ Google- आधारित (मेल, फ़ाइल, चैट आदि) हैं, इसलिए केवल डोमेन सेवाएँ ही DNS और उनके सिस्को एएसए वीपीएन के लिए अनिवार्य हैं।

ग्राहक यह समझना चाहेंगे कि जनता के लिए अपने डोमेन नियंत्रकों को उजागर करना स्वीकार्य क्यों नहीं है । इसके अलावा, वितरित दूरस्थ कार्यबल के लिए एक अधिक स्वीकार्य डोमेन संरचना क्या है ?

संपादित करें:

Centrify मुट्ठी भर मैक क्लाइंट्स के लिए उपयोग में है।


4
एक संबंधित सवाल ही नहीं है यहाँ । अपने AD को सिंक्रोनाइज़ या ऑथेंटिकेट करने के लिए अपने AD से कनेक्ट करने के लिए बाहरी सेवाओं की अनुमति देना एक भयानक अभ्यास नहीं है, लेकिन आपके डोमेन नियंत्रकों को एक खुले DMZ पर रखना, अनिवार्य रूप से जैसा आपने पूछा है, बहुत असुरक्षित है। जगह में सुरक्षा के बिना आप विभिन्न संभावित हमलों और मुद्दों के लिए पूछ रहे हैं। मैं इसके खिलाफ अत्यधिक अनुशंसा करता हूं और स्थानीय डिवाइस उपयोगकर्ताओं के साथ सोनिकवॉल जैसे फ़ायरवॉल से वीपीएन या वीपीएन क्लाइंट का सुझाव देता हूं।
माइक नायलर

10
एक हमेशा चालू, मशीन चौड़ा, ऑटो-फिर से कनेक्ट करना, प्रमाण पत्र-आधारित वीपीएन सेट करें। (OpenVPN, DirectAccess, आदि) इसलिए वीपीएन प्रमाणीकरण उपयोगकर्ता खातों से बंधा नहीं है, और उपयोगकर्ता का वीपीएन सॉफ्टवेयर के साथ कोई सीधा संपर्क नहीं है।
Zoredache

डीए एकदम सही है, लेकिन ग्राहक की जरूरतों को पूरा करने के लिए गंभीर समापन बिंदु आवश्यकताएं हैं (मैक, निश्चित रूप से।)
mfinni

1
+10 - ज़ाराडशे के सुझाव के लिए।
इवान एंडरसन

7
यदि आप अंत उपयोगकर्ता उपकरणों का समर्थन कर रहे हैं तो आप इसे गलत कर रहे हैं। यदि आप USB के माध्यम से अंत उपयोगकर्ता उपकरणों का समर्थन कर रहे हैं तो आप वास्तव में गलत कर रहे हैं।
MDMarra

जवाबों:


31

मैं इसे मुख्य रूप से उत्तर के रूप में पोस्ट कर रहा हूं क्योंकि सभी के पास अनुभव के आधार पर अपनी "शिक्षित राय" है, आईटी के भीतर 3 पार्टी की जानकारी, हार्से और जनजातीय ज्ञान है, लेकिन यह Microsoft से सीधे "सीधे" उद्धरणों और रीडिंग की एक सूची है। मैंने उद्धरणों का उपयोग किया क्योंकि मुझे यकीन है कि वे अपने कर्मचारियों द्वारा किए गए सभी विचारों को ठीक से फ़िल्टर नहीं करते हैं, लेकिन यह तब भी उपयोगी साबित होना चाहिए, यदि आप authoritativeMicrosoft से सीधे संदर्भ के बाद हैं ।


BTW, मुझे भी लगता है कि DOMAIN CONTROLLER == सक्रिय डायरैक्ट्री कहना बहुत आसान है, जो कि काफी मामला नहीं है। AD FS परदे के पीछे और अन्य साधनों (OWA, EAS, इत्यादि के लिए आधार पर आधारित फॉर्मूला) स्वयं को DC को उजागर किए बिना कम से कम AD के माध्यम से प्रमाणित करने का प्रयास करने के लिए ग्राहकों को अनुमति देने के लिए वेब पर "एक्सपोज़" करने का एक तरीका प्रदान करते हैं। किसी की OWA साइट पर जाएं और लॉगिन करने की कोशिश करें और AD को बैकएंड DC पर प्रमाणीकरण के लिए अनुरोध मिलेगा, इसलिए AD तकनीकी रूप से "उजागर" है ... लेकिन SSL के माध्यम से सुरक्षित है और Exchange सर्वर के माध्यम से अनुमानित है।


उद्धरण # 1

Windows Azure वर्चुअल मशीन पर Windows सर्वर सक्रिय निर्देशिका को नियोजित करने के लिए दिशानिर्देश

इससे पहले कि आप "एज़्योर इज़ एडी" नहीं हैं ... आप एज़्योर वीएम पर एडीडीएस को तैनात कर सकते हैं।

लेकिन संबंधित बिट्स उद्धृत करने के लिए:

कभी भी इंटरनेट से STS को सीधे उजागर न करें।

सुरक्षा सर्वोत्तम अभ्यास के रूप में, इंटरनेट के संपर्क को रोकने के लिए STS को एक फ़ायरवॉल के पीछे रखें और अपने कॉर्पोरेट नेटवर्क से कनेक्ट करें। यह महत्वपूर्ण है क्योंकि एसटीएस भूमिका सुरक्षा टोकन जारी करती है। परिणामस्वरूप, उन्हें डोमेन नियंत्रक के समान सुरक्षा स्तर के साथ व्यवहार किया जाना चाहिए। यदि किसी एसटीएस से छेड़छाड़ की जाती है, तो दुर्भावनापूर्ण उपयोगकर्ताओं को भरोसेमंद संगठनों में पार्टी के अनुप्रयोगों और अन्य एसटीएस पर भरोसा करने के लिए उनके संभावित दावों तक पहुंच टोकन जारी करने की क्षमता होती है।

एर्गो ... सीधे इंटरनेट पर डोमेन नियंत्रकों को उजागर न करें।

प्रशस्ति # 2

सक्रिय निर्देशिका - AD LDS का यूनिकोडपवाद रहस्य

इंटरनेट के लिए एक डोमेन नियंत्रक को उजागर करना आम तौर पर एक बुरा अभ्यास है, चाहे वह एक्सपोजर सीधे उत्पादन वातावरण से या परिधि नेटवर्क के माध्यम से आता है। परिधि नेटवर्क में सक्रिय निर्देशिका लाइटवेट डायरेक्ट्री सर्विसेज (AD LDS) भूमिका के साथ Windows Server 2008 सर्वर को रखने का प्राकृतिक विकल्प है।

उद्धरण # 3 - एमएस से नहीं ... लेकिन आगे देखने में अभी भी उपयोगी है

सक्रिय निर्देशिका के रूप में एक सेवा? Azure, Intune hinting क्लाउड-होस्टेड AD भविष्य में

अंत में, कोई महान "संक्षिप्त" उत्तर नहीं है जो एज़्योर विकल्प के बदले में एडी सर्वर के कार्यालय से छुटकारा पाने के लक्ष्यों को पूरा करता है। यद्यपि Microsoft को Azure में सर्वर 2012 और 2008 R2 बॉक्स पर सक्रिय निर्देशिका डोमेन सेवा की मेजबानी करने के लिए ग्राहकों को अनुमति देने में संकोच किया जा रहा है, उनकी उपयोगिता केवल वीपीएन कनेक्टिविटी के रूप में आपके कर्मचारियों के लिए आवश्यक है। DirectAccess, एक बहुत ही आशाजनक तकनीक है, जबकि इसकी अपनी दुर्भाग्यपूर्ण सीमाओं के कारण इसके हाथ बंधे हुए हैं।

उद्धरण # 4

एकल साइन-ऑन और Windows Azure वर्चुअल मशीनों के साथ AD DS या AD FS और Office 365 परिनियोजित करें

डोमेन नियंत्रकों और AD FS सर्वर को कभी भी सीधे इंटरनेट पर उजागर नहीं किया जाना चाहिए और केवल वीपीएन के माध्यम से पहुंच योग्य होना चाहिए


यह एक उचित उत्तर है, हालांकि केवल पहला उद्धरण कुछ भी कहता है कि यदि आप सलाह की अवहेलना करते हैं तो क्या बुरा हो सकता है।
केसी

19

सक्रिय निर्देशिका (AD) उस तरह की परिनियोजन के लिए डिज़ाइन नहीं किया गया था।

उत्पाद के डिज़ाइन में उपयोग किए जाने वाले खतरे के मॉडल नेटवर्क सीमा पर फ़िल्टर किए गए कुछ शत्रुतापूर्ण अभिनेताओं के साथ "पीछे-फायरवाल" की तैनाती करते हैं। यद्यपि आप निश्चित रूप से सार्वजनिक नेटवर्क के संपर्क में आने के लिए विंडोज सर्वर को सख्त कर सकते हैं, सक्रिय निर्देशिका के सही कामकाज के लिए एक सुरक्षा मुद्रा की आवश्यकता होती है, जो सार्वजनिक रूप से सामना करने वाले नेटवर्क के लिए कठोर होस्ट की तुलना में निश्चित रूप से अधिक ढीली होती है। एक बहुत सेवाओं के ठीक से काम करने के लिए विज्ञापन के लिए एक डोमेन नियंत्रक (डीसी) से अवगत कराया जाना है।

टिप्पणियों में ज़ाराडशे का सुझाव, विशेष रूप से मशीन-वाइड सेवा w / प्रमाणपत्र प्रमाणीकरण के रूप में चल रहे OpenVPN जैसे कुछ को संदर्भित करना, बस एक अच्छा फिट हो सकता है। DirectAccess, जैसा कि दूसरों ने उल्लेख किया है, वास्तव में आपको इसकी आवश्यकता है, सिवाय इसके कि इसके पास वह क्रॉस-प्लेटफ़ॉर्म समर्थन नहीं है जिसे आप पसंद करेंगे।

एक तरफ के रूप में: मैंने सीधे इंटरनेट पर विज्ञापन को उजागर करने के लिए प्रमाण पत्र-आधारित परिवहन-मोड IPSEC का उपयोग करने के विचार के साथ खिलवाड़ किया है, लेकिन वास्तव में ऐसा करने का समय कभी नहीं था। Microsoft ने Windows Server 2008 / Vista टाइमफ्रेम में बदलाव किए हैं जो माना जाता है कि यह संभव है लेकिन मैंने वास्तव में कभी इसका प्रयोग नहीं किया है।


2
एक सेवा के रूप में चल रहे OpenVPN के लिए +1, मैंने अतीत में सफलतापूर्वक सड़क योद्धाओं के साथ इस दृष्टिकोण का उपयोग किया है। हालांकि, सीनियर के ऐडिंस से मिश्रित भावनाएँ थीं, खासकर क्योंकि अगर किसी मशीन से छेड़छाड़ की गई थी, तो वह नेटवर्क में एक स्वचालित बैकडोर है। निश्चित रूप से प्रत्येक पर्यावरण के लिए, हालांकि खुद को पूछना चाहिए कि क्या लाभ जोखिम से आगे निकलते हैं?
MDMoore313

2
Microsoft IPSec के साथ सार्वजनिक इंटरनेट पर अपना कॉर्पोरेट नेटवर्क चलाता है। तो यह उल्लेखनीय है।
माइकल हैम्पटन

1
@Michael Hampton लेकिन वे Windows फ़ायरवॉल और IPSec के साथ डोमेन आइसोलेशन का उपयोग करते हैं, इसलिए यह इंटरनेट पर "AD" इंटरनेट पर "AD" नहीं है और इसके समान एक सुरक्षा ज़ोन में है, जो फ़ायरवॉल होस्ट-आधारित फ़ायरवॉल का उपयोग करके प्रदान करेगा "
एमडीएमरा

2
@ MDMoore313 - प्रमाणपत्र निरस्तीकरण FTW, यद्यपि उपयोगकर्ता को रिपोर्ट करने की आवश्यकता है कि चोरी की मशीन जल्दी से।
इवान एंडरसन

कनेक्शन के बाद लॉगऑफ़ को बाध्य करने के लिए कुछ वीपीएन क्लाइंट (उदाहरण के लिए जुनिपर) के साथ तरीके भी हैं। यह पुराने GINA के रूप में अच्छा नहीं है, लेकिन यह उपयोगकर्ता को वीपीएन पर लॉग इन करने के लिए मजबूर करता है, जबकि वास्तव में AD के खिलाफ प्रमाणित होता है और GPO मिलता है, आदि। आप पहले से कैश किए गए क्रेडेंशियल्स के साथ लॉग इन करें, यदि आवश्यक हो तो वीपीएन लॉन्च करें, और जब आप वापस लॉग इन करते हैं तो यह आपको तुरंत बंद कर देता है और कनेक्ट रहता है।
TheCleaner

15

बाकी सभी ने क्या कहा। मैं क्रिस्टोफर कारेल द्वारा उल्लिखित पाशविक बल प्रयासों के बारे में विशेष रूप से घबरा गया हूं। पिछले डेफ कॉन में एक प्रस्तुति इस विषय पर थी:

तो आपको लगता है कि आपका डोमेन नियंत्रक सुरक्षित है?

जस्टिन हेनरिक सुरक्षा इंजीनियर, MICROSOFT

डोमेन कंट्रोलर एक संगठन के क्राउन गहने हैं। एक बार जब वे गिरते हैं, तो डोमेन में सब कुछ गिर जाता है। संगठन अपने डोमेन नियंत्रकों को सुरक्षित करने के लिए बड़ी लंबाई तक जाते हैं, हालांकि वे अक्सर इन सर्वरों को प्रबंधित करने के लिए उपयोग किए जाने वाले सॉफ़्टवेयर को ठीक से सुरक्षित करने में विफल होते हैं।

यह प्रस्तुति आमतौर पर उपयोग किए जाने वाले प्रबंधन सॉफ़्टवेयर का दुरुपयोग करके डोमेन व्यवस्थापक प्राप्त करने के लिए अपरंपरागत तरीकों को कवर करेगी जो संगठन तैनात करते हैं और उपयोग करते हैं।

जस्टिन हेंड्रिक ऑफिस 365 सुरक्षा टीम में काम करते हैं जहां वह रेड टीमिंग, पैठ परीक्षण, सुरक्षा अनुसंधान, कोड समीक्षा और उपकरण विकास में शामिल हैं।

मुझे यकीन है कि आप कई अन्य उदाहरण पा सकते हैं। मैं डोमेन नियंत्रकों और हैकिंग के बारे में लेखों की तलाश कर रहा था और यह वर्णन करने की उम्मीद कर रहा था कि डीसी कितनी जल्दी मिल जाएगा, आदि, लेकिन मुझे लगता है कि अभी के लिए क्या करेंगे।


1
यहाँ श्री हेंड्रिक्स की प्रस्तुति का वीडियो है: youtube.com/watch?v=2d_6jAF6OKQ मैं डिफॉन 21 वीडियो देखना चाहता हूं और मुझे लगता है कि मैं इसके साथ शुरू करूँगा।
इवान एंडरसन

14

यदि आप प्रबंधन को समझाने की कोशिश कर रहे हैं, तो एक अच्छी शुरुआत यह होगी:

It goes against Microsoft's Best Practices for Active Directory Deployment.

अद्यतन : हमले के खिलाफ डोमेन नियंत्रकों, और उस राज्य शीर्षक वाले खंड को सुरक्षित करने के लिए इस तकनीकी लेख को देखें Perimeter Firewall Restrictions:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

और वह खंड जिसका शीर्षक Blocking Internet Access for Domain Controllersहै:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

मुझे यकीन है कि आप इस मामले पर कुछ Microsoft दस्तावेज़ों को ड्रम कर सकते हैं, इसलिए ऐसा है। इसके अलावा, आप इस तरह के कदम के खतरों के बारे में बता सकते हैं:

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

कैश्ड क्रेडेंशियल्स बस हैं - कैशेड। वे स्थानीय मशीन के लिए काम करते हैं जब यह डोमेन से कनेक्ट नहीं हो सकता है , लेकिन अगर वह खाता अक्षम किया गया था तो वे किसी भी नेटवर्क संसाधन (svn, vpn, smb, fbi, cia, आदि) के लिए काम नहीं करेंगे, इसलिए उन्हें इस बारे में चिंता करने की ज़रूरत नहीं है । यह भी याद रखें कि उपयोगकर्ताओं को पहले से ही किसी स्थानीय मशीन पर अपने प्रोफ़ाइल फ़ोल्डर में किसी भी फाइल पर पूर्ण अधिकार हैं (और संभवत: हटाने योग्य मीडिया) तो अक्षम क्रेडेंशियल या नहीं वे उस डेटा के साथ क्या कर सकते हैं। एक बार जब यह नेटवर्क से जुड़ जाता है तो वे स्थानीय मशीन के लिए भी काम नहीं करेंगे।

क्या आप उन सेवाओं का उल्लेख कर रहे हैं जो सक्रिय निर्देशिका या एक डोमेन नियंत्रक प्रदान करता है, जैसे LDAP? यदि हां, तो प्रमाणीकरण और निर्देशिका क्वेरी के उद्देश्यों के लिए LDAP को अक्सर सुरक्षित रूप से तोड़ दिया जाता है, लेकिन बस Windows फ़ायरवॉल को बंद करने (या जनता के लिए सभी आवश्यक पोर्ट खोलने - इस उदाहरण में एक ही बात) गंभीर समस्याएं पैदा कर सकता है।

AD वास्तव में Mac को प्रबंधित नहीं करता है, इसलिए एक अलग समाधान की आवश्यकता होगी (OS X सर्वर सोचें)। आप किसी डोमेन में मैक से जुड़ सकते हैं, लेकिन यह नेटवर्क क्रेडेंशियल्स के साथ उन्हें छोटा करने की तुलना में बहुत कम करता है, मैक पर स्थानीय ऐडमिट के रूप में डोमेन व्यवस्थापक सेट करें, आदि कोई समूह नीति नहीं। MS SCCM के नए संस्करणों के साथ उस आधार को भंग करने की कोशिश कर रहा है, जो दावा करता है कि macs और * nix बॉक्स पर एप्लिकेशन को तैनात करने में सक्षम है, लेकिन मैंने इसे अभी तक उत्पादन के माहौल में नहीं देखा है। मेरा यह भी मानना ​​है कि आप OS X सर्वर से जुड़ने के लिए macs को कॉन्फ़िगर कर सकते हैं जो आपके AD आधारित निर्देशिका को प्रमाणित करेगा, लेकिन मैं गलत हो सकता है।

कहा जा रहा है कि कुछ रचनात्मक समाधान तैयार किए जा सकते हैं, जैसे कि एक सेवा के रूप में ओपनवीपीएन का उपयोग करने के लिए इवान का सुझाव, और यदि उस कर्मचारी को जाने देने का समय आता है, तो मशीन प्रमाणपत्र को अक्षम करना।

ऐसा लगता है कि सब कुछ Google आधारित है, इसलिए Google आपके ldap सर्वर के रूप में कार्य कर रहा है? मैं अपने मुवक्किल को इस तरह से रखने की सलाह दूंगा यदि संभव हो तो। मुझे आपके व्यवसाय की प्रकृति का पता नहीं है, लेकिन वेब आधारित ऐप्स जैसे git या redmine सर्वर, तब भी जब घर में सेटअप OAuth के साथ प्रमाणित हो सकता है, Google खाते का लाभ उठा सकता है।

अन्त में, रोडवार सेटअप जैसे कि लगभग एक वीपीएन को सफल होना आवश्यक है। एक बार मशीनों को कार्यालय में लाया जाता है और कॉन्फ़िगर किया जाता है (या स्क्रिप्ट के माध्यम से दूरस्थ रूप से कॉन्फ़िगर किया जाता है), उन्हें कॉन्फ़िगरेशन में किसी भी परिवर्तन को प्राप्त करने का एक तरीका चाहिए।

वीपीएन के अलावा मैक को एक अलग प्रबंधन दृष्टिकोण की आवश्यकता होगी, यह बहुत बुरा है कि वे अब असली मैक सर्वर नहीं बनाते हैं, लेकिन उन्होंने ओएस एक्स सर्वर में पिछली बार जब मैंने जाँच की थी (कुछ साल पहले) )।


दरअसल, अभी कुछ मुट्ठी भर मैक सिस्टम पर पॉलिसी के प्रबंधन के लिए इस माहौल में सेंट्रिफ का इस्तेमाल किया जा रहा है।
ewwhite

@ समीक्षा करने से आपका क्या मतलब है? ऐसा लगता है कि केंद्रीय प्रमाणीकरण उपयोगिता से अधिक कुछ नहीं है।
MDMoore313

@ MDMoore313 आप कुछ घंटों से देर कर रहे हैं, मैं जीता हूं: chat.stackexchange.com/transcript/127?m=13626424#13626424 - :)
TheCleaner

@ TheCleaner haha ​​ऐसा प्रतीत होता है, आप इस समय जीतते हैं, आप Google फू की कला को अच्छी तरह से जानते हैं, लेकिन आपकी तकनीक आपको भयानक लिप्सिंग आवाज के साथ मेरी सबसे अच्छी कुंग फू में शामिल करती है। आपके द्वारा अपना उत्तर पोस्ट करने के बाद, मुझे एक खोजने के लिए दोगुना कठिन खोजना पड़ा जो कि आपकी नकल नहीं थी !
MDMoore313

2
LOL, कोई चिंता नहीं ... अगली बार जब हम जीतेंगे तो आपकी जीत हो सकती है। (भयानक
होठों की

7

यह दुर्भाग्यपूर्ण है कि DirectAccess केवल Win7 + एंटरप्राइज़ संस्करण पर उपलब्ध है, क्योंकि यह आपके अनुरोध के लिए दर्जी है। लेकिन आपके संस्करण को नहीं जानना, और यह देखना कि आपके पास मैकओएस है, जो काम नहीं करेगा।

/ संपादित करें - ऐसा लगता है कि कुछ 3 पार्टियों का दावा है कि उनके पास यूए के लिए डीए क्लाइंट हैं: http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability .asp

एमडीएम समाधान उपलब्ध हैं जो आपकी आवश्यकताओं को पूरा करने के लिए काम कर सकते हैं; हम उनमें से एक (MAAS360) को एक क्लाइंट के लिए रोल कर रहे हैं जो एक समान स्थिति में है।


5

यह स्पष्ट रूप से एक महत्वपूर्ण सुरक्षा जोखिम होगा। इसके अलावा, यह शायद आप के साथ भी काम नहीं करेंगे। यदि इंटरनेट पर यादृच्छिक लोग आपके AD वातावरण में लॉगिन का प्रयास करने में सक्षम हैं, तो संभावनाएं अच्छी हैं कि आपके सभी उपयोगकर्ता लॉक आउट होने वाले हैं। सदैव। और लॉकआउट आवश्यकताओं को हटाने का मतलब है कि यह सरल पासवर्ड के लिए बल जांच को आसान बनाता है।

इससे भी महत्वपूर्ण बात यह है कि, आपको अपने लक्ष्य को लागू करने में कोई समस्या नहीं होनी चाहिए (अंतिम उपयोगकर्ताओं को डोमेन क्रेडेंशियल्स के साथ एक लैपटॉप में प्रवेश करना), जो कि AD सर्वर को सीधे सुलभ नहीं बनाता है। अर्थात्, विंडोज़ मशीनें अंतिम X सफल लॉगिन को कैश कर सकती हैं, ताकि डिस्कनेक्ट होने पर वही क्रेडेंशियल काम करें। इसका अर्थ है कि अंत उपयोगकर्ता आपके AD सर्वर को छूने की आवश्यकता के बिना, लॉगिन और उपयोगी कार्य कर सकते हैं। उन्हें स्पष्ट रूप से अन्य प्रमुख कॉर्पोरेट संसाधनों से कनेक्ट करने के लिए वीपीएन का उपयोग करने की आवश्यकता होगी, और एक ही समय में एडी / जीपीओ सेटिंग्स को ताज़ा कर सकते हैं।


2
AD किसी भी चीज के लिए (या कम से कम उस पर निर्भर) प्रसारण का उपयोग नहीं करता है, जब तक कि यह AD मेरे ज्ञान के लिए है। कुछ तकनीकों के लिए WINS की आवश्यकता हो सकती है, जो कि अगर कोई WINS सर्वर उपलब्ध नहीं है, तो प्रसारण अनुरोधों पर वापस गिर सकता है, लेकिन यह सामान्य रूप से AD के लिए प्रासंगिक नहीं है। यदि यह प्रसारण में निर्भर करता है, तो आपके पास स्थानीय डीसी के बिना दूरस्थ उपयोगकर्ता नहीं हो सकते।
mfinni

2
उस लाइन को संपादित किया। इनपुट के लिए धन्यवाद। Cllearly मेरे जैसा एक लिनक्स आदमी विंडोज पर अतिथि नहीं होना चाहिए।
क्रिस्टोफर कारेल

यदि यह "स्पष्ट" होता तो यह एक प्रश्न नहीं होता, क्या यह होता?
केसी

2

Ewwhite,

आपका प्रश्न अत्यंत मान्य है और एक सावधानीपूर्वक समीक्षा के योग्य है।

सभी सुरक्षा पेशेवर किसी भी नेटवर्क संसाधन के सामने सुरक्षा की परतें लगाने की सलाह देते हैं, जिसमें एसपीआई फायरवॉल, आईडीएस, होस्ट बेस्ड फायरवॉल आदि शामिल हैं। आपको हमेशा जब संभव हो तो आईएसआई (अब टीएमजी) जैसे प्रॉक्सी परिधि गेटवे फ़ायरवॉल का उपयोग करना चाहिए।

कहा कि, Microsoft सक्रिय निर्देशिका 2003+ में सार्वजनिक रूप से प्रकट की गई कोई बड़ी कमजोरियां नहीं हैं। LDAP तकनीक और यह हैश एल्गोरिदम आमतौर पर बहुत सुरक्षित हैं। यकीनन यह एसएसएल वीपीएन से अधिक सुरक्षित है यदि एसएसएल वीपीएन ओपनएसएसएल चलाता है और हार्दिक रूप से कमजोर है।

मैं 5 चीजों की सावधानी रखूंगा:

  1. अन्य सेवाओं के बारे में चिंतित रहें जो नेटवर्क का सामना करते हैं जैसे कि टर्मिनल सर्वर, डीएनएस सर्विसेज, सीआईएफएस और विशेष रूप से आईआईएस अपने भयानक सुरक्षा रिकॉर्ड के साथ।

  2. तार पर स्पष्ट पाठ डोमेन क्रेडेंशियल्स से बचने के लिए एक सुरक्षा प्रमाणपत्र के साथ LDAPS का उपयोग करें। प्रमाणपत्र सेवाएँ स्थापित करने के बाद स्वचालित रूप से ऐसा होता है (PKI के लिए एक अलग मशीन का उपयोग करें)

  3. इंटरफ़ेस पर एक पैकेट स्निफ़र डालें और अपने ट्रैफ़िक को देखें, किसी भी स्पष्ट पाठ पासवर्ड को ठीक करें क्योंकि फ़ायरवॉल या नहीं, अगर आपका वीपीएन या एलडीएपीएस का उपयोग नहीं किया जाता है, तो कुछ विरासत सिस्टम स्पष्ट पाठ पासवर्ड भेजेंगे।

  4. यह जान लें कि MITM हमले देशी प्रमाणीकरण तंत्र को कमजोर NTLM प्रमाणीकरण के लिए पासवर्ड को डाउनग्रेड करने और उजागर करने के लिए मजबूर कर सकते हैं।

  5. कुछ उपयोगकर्ता गणन कमजोरियों से अवगत रहें जो अभी भी मौजूद हैं।

उस ने कहा, सक्रिय निर्देशिका में सुरक्षा के लिए एक महान ट्रैक रिकॉर्ड है। इसके अलावा, एमएस एक्टिव डायरेक्टरी पासवर्ड को स्टोर नहीं करता है, केवल हैश जो एक समझौता की गंभीरता को कम कर सकता है।

आप अधिक सहज सुरक्षा अवसंरचना से लाभान्वित हो सकते हैं, आपको विशेष DNS सर्वर सेट करने या domain.local का उपयोग करने की आवश्यकता नहीं है और आप अपने वास्तविक डोमेन जैसे domain.com पर वास्तविक डोमेन का उपयोग कर सकते हैं।

मेरे पेशेवर विचार में सार्वजनिक रूप से सक्रिय निर्देशिका जैसी सुरक्षा तकनीकों को तैनात करने का पर्याप्त लाभ है, जहां एक्सचेंज और डीएनएस और वेब सर्वर जैसी अन्य प्रौद्योगिकियां बस कोई लाभ और सभी जोखिम प्रदान नहीं करती हैं।

नोट: यदि आप सक्रिय निर्देशिका को तैनात करते हैं तो इसमें DNS सर्वर शामिल होगा। अपने DNS सर्वर पर पुनरावृत्ति को अक्षम करने के लिए CERTAIN बनें (डिफ़ॉल्ट रूप से सक्षम) या आप बिल्कुल सेवा हमलों से इनकार करने में भाग लेंगे।

चीयर्स,

-ब्रायन


-3

डेल (क्वेस्ट खरीदने के माध्यम से (विंटेला खरीदने के माध्यम से)) में एक क्रॉस-प्लेटफ़ॉर्म समाधान है जिसे इस एक्सप्रेस उद्देश्य के लिए F500 उद्यमों में अक्सर तैनात किया जाता है ।

विचार करने के लिए बातें...

  1. क्या आपके उपयोगकर्ता हमेशा कनेक्टेड हैं? यदि ऐसा है तो आपको सबसे अच्छा VM- आधारित होस्टिंग वातावरण प्रदान किया जाएगा जो कि बहुत सारे सक्रिय उपयोगकर्ताओं के LDAP को चलाने के दौरान फ्लेक्स कर सकता है
  2. क्या आप एक से अधिक भौतिक डेटा केंद्र में चल रहे हैं? उपयोगकर्ताओं और आपके सिस्टम के बीच हॉप्स की संख्या को कम करने के लिए AD सेवाओं के सामने भौगोलिक लोड-संतुलन पर विचार करें
  3. इसके अलावा, यदि # 2 का उत्तर हाँ है, तो सुनिश्चित करें कि आपने अपने जंगल को दर्शाने के लिए कुछ समर्पित नेटवर्क संसाधन स्थापित किए हैं

और सुनिश्चित करें कि आपका फ़ायरवॉल समाधान अत्यधिक उच्च पुनः प्रसारित दरों को संभालने में सक्षम है यदि आपके पास थ्रॉटल अपलिंक पर उपयोगकर्ता हैं, जो शोर वाईफ़ाई केंद्रों से जुड़ते हैं, आदि।


यह विंडोज़ मशीनों का प्रबंधन कैसे करता है, या इंटरनेट के संपर्क में आने वाले डीसी की तरह कुछ भी सुरक्षित करता है? यह ऐसा नहीं पढ़ता है जैसे यह सब करता है।
mfinni
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.