विंडोज एडी डोमेन में लॉक यूजर अकाउंट का कारण कैसे पता करें


18

आउटलुक के साथ एक हालिया घटना के बाद, मैं सोच रहा था कि मैं निम्नलिखित समस्या का सबसे कुशलता से समाधान कैसे करूंगा:

मध्यम आकार के AD अवसंरचना के लिए काफी सामान्य रूप से छोटे मान लें: कई DC, आंतरिक सर्वर और विंडोज़ क्लाइंट की संख्या, DMZ (SMTP रिले, VPN, Citrix, आदि) और कई आंतरिक से उपयोगकर्ता प्रमाणीकरण के लिए AD और LDAP का उपयोग करने वाली कई सेवाएँ। प्रमाणीकरण (एक्सचेंज, एसक्यूएल सर्वर, फ़ाइल और प्रिंट सर्वर, टर्मिनल सेवा सर्वर) के लिए विज्ञापन पर निर्भर सभी सेवाएं। आपके पास सभी प्रणालियों तक पूर्ण पहुंच है लेकिन वे व्यक्तिगत रूप से जांच करने के लिए बहुत अधिक हैं (ग्राहकों की गिनती)।

अब मान लें कि, किसी अज्ञात कारण से, हर एक मिनट में पासवर्ड लॉकआउट पॉलिसी के कारण एक (या अधिक) उपयोगकर्ता खाता लॉक हो जाता है।

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


प्रभावशाली प्रश्न। अच्छी तरह से बाहर निकाल दिया।
पेकोस बिल

जवाबों:


13

मेरे द्वारा दिए गए उत्तरों में कुछ ऐसा नहीं है जो मैं देख रहा हूँ।

इसके लिए जिम्मेदार सेवा / मशीन को खोजने का सबसे अच्छा तरीका क्या होगा?

आप केवल PDCe पर सुरक्षा लॉग को नहीं देख सकते हैं , क्योंकि, जबकि PDCe में संपूर्ण डोमेन के लिए खाता लॉकआउट के बारे में सबसे अद्यतित जानकारी है, इसमें किस क्लाइंट (IP या से) के बारे में जानकारी नहीं है hostname) विफल लॉगऑन प्रयास से आया, यह मानते हुए कि विफल लॉगऑन प्रयास PDCe के अलावा किसी अन्य DC पर हुआ। PDCe कहेगा कि "खाता xyz को बंद कर दिया गया था", लेकिन यह नहीं कहेगा कि यदि डोमेन में किसी अन्य डीसी पर विफल लॉगऑन हो रहे थे, तो वह कहां से होगा। केवल डीसी जो वास्तव में लॉगऑन को मान्य करता है, क्लाइंट के पते सहित लॉगऑन विफलता रिकॉर्ड करेगा। (इस चर्चा में RODCs को नहीं लाना।)

यह पता लगाने के दो अच्छे तरीके हैं कि विफल लॉगऑन प्रयास कब से आ रहे हैं जब आपके पास कई डोमेन नियंत्रक हैं। इवेंट फ़ॉरवर्डिंग , और Microsoft का खाता लॉकआउट टूल

मैं केंद्रीय स्थान के लिए ईवेंट फॉरवर्ड करना पसंद करता हूं। फ़ॉरवर्ड लॉगऑन प्रयास आपके सभी डोमेन नियंत्रकों से एक केंद्रीय लॉगिंग सर्वर तक पहुँचते हैं। तब आपके पास अपने संपूर्ण डोमेन में विफल लॉगऑन देखने के लिए केवल एक स्थान होता है। वास्तव में मैं व्यक्तिगत रूप से Microsoft के खाता लॉकआउट टूल से वास्तव में प्यार नहीं करता, इसलिए अब एक अच्छा तरीका है।

घटना अग्रेषण। आपको बहुत पसंद आएगा।

बुनियादी सुविधाओं को शुद्ध मानकर, बिना किसी अतिरिक्त प्रबंधन टूल के मानक विंडोज और डिफ़ॉल्ट रूप से कुछ बदलाव हैं, क्या इस तरह के लॉकआउट के कारण खोजने की प्रक्रिया में तेजी या सुधार हो सकता है?

ऊपर देखो। आप तब अपना निगरानी तंत्र रख सकते हैं, जैसे SCOM या नागिओस या जो भी आप उपयोग करते हैं, उस एकल ईवेंट लॉग को कंघी करें और अपने सेल फोन को टेक्स्ट मैसेज या जो कुछ भी हो, से उड़ा दें। यह उससे अधिक त्वरित नहीं है।

इस तरह के अकाउंट लॉकआउट डॉस के खिलाफ सिस्टम के लचीलेपन को सुधारने के लिए क्या किया जा सकता है?

  1. उपयोगकर्ता शिक्षा। उन्हें बताएं कि अपने डोमेन उपयोगकर्ता खातों के तहत चलने के लिए विंडोज सेवाओं की स्थापना को रोक दें, आरडीपी सत्रों को लॉग ऑफ करें जब वे काम कर लें, तो उन्हें Outlook के लिए कैश्ड पासवर्डों के विंडोज क्रेडेंशियल वॉल्ट को कैसे साफ़ करें, आदि सिखाएं।
  2. प्रबंधित सेवा खातों का उपयोग करें जहां आप उपयोगकर्ताओं को अब उन उपयोगकर्ता खातों के लिए पासवर्ड का प्रबंधन नहीं कर सकते हैं। उपयोगकर्ताओं को सब कुछ मिल गया। यदि आप किसी उपयोगकर्ता को एक विकल्प देते हैं, तो वह हमेशा गलत चुनाव करेगा। तो उन्हें एक विकल्प मत देना।
  3. GPO के माध्यम से दूरस्थ सत्र टाइमआउट लागू करना। यदि कोई उपयोगकर्ता RDP सत्र में 6 घंटे के लिए बेकार है, तो उन्हें बंद कर दें।

1
+1 के लिए "किसी उपयोगकर्ता को एक विकल्प दें, वह हमेशा गलत चुनाव करेगा"
Devon_C_Miller

प्रबंधित सेवा खातों को इंगित करने के लिए धन्यवाद । सेवाओं के रूप में चल रहे उपयोगकर्ता खातों को छोड़ने का तरीका खोजते समय मुझे कुछ दिनों पहले का विवरण याद नहीं है।
जॉन उर्फ ​​हॉट

3

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


पेशेवर बनाम नि: शुल्क संस्करण पर कोई टिप्पणी?
बोजोजो

3

इस तरह के अकाउंट लॉकआउट डॉस के खिलाफ सिस्टम के लचीलेपन को सुधारने के लिए क्या किया जा सकता है?

आप नहीं कर सकते।

बहुत सी चीजें हैं जो आपके घर को जला सकती हैं। डीएचसीपी गुंजाइश समाप्त होने तक आईपी पते को बार-बार अनुरोध करने के लिए सरल कोड की तरह। या सरल कोड जो निर्देशिका बनाता है जब तक कि एमएफटी भरा हुआ है और आपको इसे पुनर्स्थापित करने के लिए अपने विभाजन को पुन: स्वरूपित करना होगा। आप हर चीज से रक्षा नहीं कर सकते।

लॉकआउट्स के साथ एक अधिक सामान्य परिदृश्य वे लोग हैं जो कुछ साल पहले की तुलना में बहुत अधिक विविधता वाले उपकरणों में अपनी साख दर्ज करते हैं। जैसे प्रिंटर (ईमेल स्कैन करने के लिए), या स्मार्टफोन या टैबलेट। यदि वे भूल जाते हैं कि उन्होंने अपनी क्रेडेंशियल कहाँ दर्ज की है, या यदि उनके पास डिवाइस तक पहुँच नहीं है, तो संभव है कि डिवाइस हमेशा के लिए प्रमाणीकरण का प्रयास करता रहेगा। ईमेल युक्ति इन उपकरणों को ट्रैक करने के लिए एक कठिन वेक्टर है, और यहां तक ​​कि अगर आप ऐसा करते हैं, तो उपयोगकर्ता के पास इस तक पहुंच नहीं हो सकती है या पता नहीं चल सकता है कि यह कहां है। आईपी ​​10.4.5.27? मुझे एक उपयोगकर्ता के बारे में पता है जिसे अपने खाते को अनलॉक करने के लिए हर दिन हेल्प डेस्क पर कॉल करना पड़ता था, फिर वे तुरंत लॉगऑन करते थे, और फिर उनका खाता फिर से लॉक हो जाता था। उन्होंने महीनों तक ऐसा किया। मैंने उनसे कहा कि वे अपना नाम बदल लें।

जीवन में विसंगतियां हैं, हम उन सभी को दूर नहीं कर सकते।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.