Windows सुरक्षा ऑडिट नीति और इवेंट लॉग जाँच का व्यवहार — 4625 पढ़ सकने वाली IT टीम बनना

“कल रात से एक खाता बार-बार लॉकआउट हो रहा है। कारण पता करें।” “क्या किसी ने निकले कर्मचारी के खाते से साइन-इन का प्रयास किया?” “इस सर्वर पर कब, किसने, क्या चलाया?” — छोटे और मध्यम व्यवसायों के IT स्टाफ, या ग्राहक को प्रणाली सौंपने वाले डेवलपर, एक दिन अचानक ऐसे अनुरोध पाते हैं। और जिस पर वे टिकते हैं वह Windows का Security इवेंट लॉग है।

पर वास्तव में इवेंट व्यूअर खोलें तो दो वास्तविकताएँ इंतज़ार करती हैं। जो इवेंट देखना चाहते हैं वह दर्ज ही नहीं (ऑडिट नीति सक्षम नहीं), या इवेंटों के ढेर में दबकर पढ़े नहीं जाते (शोर से फूलकर बढ़े)। सुरक्षा ऑडिट “सक्षम करें तो दर्ज होता है”, पर क्या और कितना दर्ज करें डिज़ाइन न करें तो जरूरत के समय काम नहीं आता।

flowchart TB
    accTitle: इवेंट व्यूअर में इंतज़ार कर रही दो वास्तविकताएँ
    accDescr: इवेंट व्यूअर खोलने पर दो वास्तविकताएँ मिलती हैं, ऑडिट नीति सक्षम न होने से वांछित इवेंट दर्ज नहीं, या शोर से फूलकर इवेंटों के ढेर में दब जाना, इसलिए क्या और कितना दर्ज करें का डिज़ाइन ज़रूरी है
    open["इवेंट व्यूअर खोलें"] --> real{"इंतज़ार कर रही वास्तविकता?"}
    real -->|दर्ज नहीं| none["वांछित इवेंट दर्ज नहीं"]
    real -->|दबे हुए| noise["इवेंटों के ढेर में पढ़े नहीं जाते"]
    none -.-> cause1["ऑडिट नीति अक्षम"]
    noise -.-> cause2["शोर से फूलकर बढ़ना"]
    none --> design["क्या और कितना दर्ज करें, डिज़ाइन करें"]
    noise --> design

चित्र 1: “दर्ज नहीं” या “दबकर पढ़े नहीं जाते”। दोनों का कारण दर्ज करने की सीमा डिज़ाइन न करना है।

यह लेख ऑडिट नीति की बनावट (मूल और उन्नत, दो प्रणालियाँ), छोटे-मध्यम परिवेश में न्यूनतम सक्षम उपश्रेणियाँ, 4624/4625/4740/4688 जैसे मानक इवेंट ID पढ़ना, Security लॉग की क्षमता डिज़ाइन, और PowerShell से जाँच — अगस्त 2026 तक के प्राथमिक स्रोतों पर — व्यवस्थित करता है। इस साइट के NTLM ऑडिट, SMB साइनिंग, BitLocker और फ़ायरवॉल लेख “रक्षा मज़बूत करने” की बात हैं; यह लेख “बाद में पुष्टि कर सकें कि क्या हुआ” की बात है, और उन्हें बाँधने वाला अगला अध्याय है।

1. निष्कर्ष पहले

• ऑडिट नीति की दो प्रणालियाँ हैं — “मूल” और “उन्नत (Advanced Audit Policy)” — और उन्हें मिलाना मना है। Microsoft स्पष्ट लिखता है कि दोनों इस्तेमाल करने से ऑडिट परिणाम अप्रत्याशित हो जाते हैं। उन्नत पक्ष (40 से अधिक उपश्रेणियाँ) पर एकरूप रहें।¹
• वर्तमान स्थिति auditpol /get /category:* से देखें। GPO से आई हो या स्थानीय सेटिंग से, अभी प्रभावी ऑडिट सेटिंग की सूची मिलती है।²
• “सब सक्षम करें” कभी न करें। बड़ी इवेंट मात्रा पैदा करने वाली उपश्रेणियाँ चालू करें तो जरूरी इवेंट शोर में दबते हैं, और प्रदर्शन भी प्रभावित होता है। Microsoft की बेसलाइन सिफ़ारिश से शुरू करें, जरूरत की चीज़ें ही जोड़ें।³⁴
• साइन-इन सफलता 4624 है, विफलता 4625। 4624 को लॉगऑन प्रकार से पढ़ें (2 = Interactive, 3 = Network, 10 = RemoteInteractive, आदि) — “किस तरह का साइन-इन था”।⁵
• 4625 में Status/Sub Status कोड विफलता का कारण बताते हैं। मानक हैं 0xC0000064 = अस्तित्वहीन उपयोगकर्ता नाम, 0xC000006A = गलत पासवर्ड, 0xC0000072 = अक्षम खाता, 0xC0000234 = लॉकआउट।⁶
• इवेंट कहाँ दर्ज होता है, तय है। 4624/4625 उस मशीन पर दर्ज होते हैं जिस तक पहुँचा गया; साख सत्यापन (4776) और Kerberos पूर्व-प्रमाणीकरण विफलता (4771) डोमेन नियंत्रक पर। गलत मशीन देखें तो “लॉग नहीं है” का गलत निदान होता है।⁶⁷⁸
• Security लॉग का आधा डिज़ाइन पात्र स्वयं है — अधिकतम आकार और प्रतिधारण। प्रतिधारण ओवरराइट मोड हो तो पुराने इवेंट पहले मिटते हैं। Get-WinEvent -ListLog Security से अधिकतम आकार और संख्या देखें, जितने दिन रखने हैं उससे उलटा हिसाब लगाकर बढ़ाएँ।⁹¹⁰
• प्रोसेस निर्माण (4688) की कमांड-लाइन रिकॉर्डिंग शक्तिशाली है, पर रहस्य लॉग में सादे पाठ में बैठने के जोखिम के बदले। सक्षम करने से पहले स्क्रिप्टें जाँचें।¹¹¹²

2. ऑडिट नीति की नींव — “मूल” और “उन्नत” न मिलाएँ

Windows ऑडिट नीति की दो प्रणालियाँ हैं।¹

• मूल ऑडिट नीति: “Local Policies > Audit Policy” के अंतर्गत नौ श्रेणी सेटिंग। Windows Vista से पहले की पुरानी प्रणाली।
• उन्नत ऑडिट नीति (Advanced Audit Policy Configuration): “Security Settings > Advanced Audit Policy Configuration” के अंतर्गत 40 से अधिक उपश्रेणी सेटिंग। मूल की एक श्रेणी को कई उपश्रेणियों में तोड़ती है — उदाहरण के लिए मूल की एक श्रेणी “Audit account logon events” के सामने उन्नत पक्ष पर चार उपश्रेणियाँ हैं। मूल पक्ष पर एक श्रेणी सक्षम करना संगत सभी उपश्रेणियाँ सक्षम करने के बराबर है, इसलिए जिनमें आपकी रुचि नहीं वे भी बड़ी मात्रा में दर्ज होते हैं।¹

महत्वपूर्ण बात यह है कि ये दो प्रणालियाँ परस्पर संगत नहीं। Microsoft साफ़ लिखता है: “मूल और उन्नत दोनों इस्तेमाल न करें। ऑडिट परिणाम अप्रत्याशित हो सकते हैं।” Group Policy से उन्नत ऑडिट नीति लागू होने पर उस कंप्यूटर की मौजूदा ऑडिट सेटिंग पहले साफ़ होती हैं, फिर उन्नत सेटिंग लगती हैं; उसके बाद केवल उन्नत पक्ष विश्वसनीय नियंत्रण देता है। उन्नत पक्ष इस्तेमाल करने वाले परिवेश में सुरक्षा विकल्प “Audit: Force audit policy subcategory settings to override audit policy category settings” सक्षम रखें ताकि मूल सेटिंग उसे ओवरराइट न करे (स्टैंडअलोन मशीनों पर यह डिफ़ॉल्ट से सक्षम है)।¹⁴

flowchart TB
    accTitle: मूल और उन्नत ऑडिट नीति का संबंध
    accDescr: मूल ऑडिट नीति और उन्नत ऑडिट नीति संगत नहीं हैं, दोनों इस्तेमाल करने से ऑडिट परिणाम अप्रत्याशित होते हैं, इसलिए उन्नत पक्ष पर एकरूप रहें और उपश्रेणी सेटिंग बाध्य कर मूल पक्ष की ओवरराइट रोकें
    basic["मूल ऑडिट नीति（9 श्रेणियाँ）"] --> both{"दोनों इस्तेमाल?"}
    adv["उन्नत ऑडिट नीति（40+ उपश्रेणियाँ）"] --> both
    both -->|हाँ| bad["ऑडिट परिणाम अप्रत्याशित"]
    both -->|नहीं| unify["उन्नत पक्ष पर एकरूप"]
    unify --> force["उपश्रेणी सेटिंग बाध्य करें सक्षम"]
    force -.-> guard["मूल पक्ष की ओवरराइट रोकें"]

चित्र 2: दो प्रणालियाँ संगत नहीं। उन्नत पक्ष पर एकरूप रहें, और “बाध्य करें” सेटिंग से मूल पक्ष की ओवरराइट रोकें।

वर्तमान स्थिति एक कमांड से दिखती है। व्यवस्थापक कमांड प्रॉम्प्ट से चलाएँ।²

rem अभी प्रभावी ऑडिट सेटिंग उपश्रेणी के अनुसार सूचीबद्ध करें
auditpol /get /category:*

rem बदलाव से पहले बैकअप (CSV) और पुनर्स्थापन
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

auditpol का आउटपुट GPO से आई हो या स्थानीय सेटिंग से, “परिणामतः प्रभावी नीति” है। GPO से बाँटी सेटिंग न लगी लगे तो मिलान के लिए भी काम आता है। ध्यान दें कि ऑडिट सेटिंग स्वयं बदलने पर इवेंट 4719 दर्ज होता है, इसलिए “पता न चला ऑडिट बंद हो गया” बाद में भी खोजा जा सकता है।¹²

flowchart TB
    accTitle: auditpol में दिखती है परिणाम की नीति
    accDescr: auditpol का आउटपुट GPO से आई हो या स्थानीय सेटिंग से परिणामतः प्रभावी ऑडिट नीति है, GPO न लगने पर मिलान में काम आता है, और ऑडिट सेटिंग स्वयं बदलने पर इवेंट 4719 से बाद में पता चलता है
    gpo["GPO से वितरित सेटिंग"] --> eff["परिणामतः प्रभावी नीति"]
    local["स्थानीय सेटिंग"] --> eff
    eff --> get["auditpol /get से सूची"]
    get -.-> diff["GPO न लगने पर मिलान"]
    change["ऑडिट सेटिंग स्वयं बदली"] -.-> e4719["4719 दर्ज, बाद में पता चलता है"]

चित्र 3: auditpol उद्गम पूछे बिना “प्रभावी सेटिंग” लौटाता है। ऑडिट सेटिंग का बदलाव स्वयं 4719 में रहता है।

3. न्यूनतम सक्षम उपश्रेणियों की निर्णय तालिका

“फिलहाल सब सक्षम कर दें” खराब चाल क्यों है, साफ़ है। उदाहरण के लिए privilege-use उपश्रेणियों तक सफलता ऑडिट करें तो इवेंट इतने बढ़ते हैं कि अन्य प्रविष्टियाँ खोजना कठिन हो जाता है, और प्रदर्शन भी प्रभावित होता है — Microsoft चेतावनी देता है।⁴ लॉग का पात्र (अध्याय 5) सीमित है, इसलिए जितना शोर दर्ज करेंगे उतने दिन जरूरी इवेंट के प्रतिधारण कटते हैं। ऑडिट डिज़ाइन वास्तव में यह तय करना है कि क्या न दर्ज करें।

flowchart TB
    accTitle: सब सक्षम करना खराब चाल क्यों है
    accDescr: सभी उपश्रेणियाँ सक्षम करने से बड़ी मात्रा में इवेंट पैदा होते हैं, जरूरी इवेंट शोर में दबते हैं, प्रदर्शन प्रभावित होता है, और सीमित लॉग पात्र में जरूरी इवेंट के प्रतिधारण दिन कटते हैं
    all["सभी उपश्रेणियाँ सक्षम करें"] --> flood["बड़ी मात्रा में इवेंट"]
    flood --> noise["जरूरी इवेंट दब जाते हैं"]
    flood --> perf["प्रदर्शन पर असर"]
    flood --> keep["प्रतिधारण दिन कटते हैं"]
    noise --> lesson["क्या न दर्ज करें, यही ऑडिट डिज़ाइन है"]
    perf --> lesson
    keep --> lesson

चित्र 4: “सब सक्षम” जरूरी इवेंट दबा देता है। न दर्ज करने वाली चीज़ तय करना ही ऑडिट डिज़ाइन है।

Microsoft वर्कस्टेशन और सर्वर के अनुसार बेसलाइन तथा मज़बूत सिफ़ारिशें प्रकाशित करता है, और वही शुरुआती बिंदु है।³ उसके बाद छोटे-मध्यम परिवेश के दृष्टिकोण — “घटना पर न्यूनतम क्या पढ़ना है” — से व्यवस्थित तालिका यह है।

उलटा, फ़ाइल सिस्टम या रजिस्ट्री की ऑब्जेक्ट-एक्सेस ऑडिट, privilege use, और पैकेट-फ़िल्टर उपश्रेणियाँ (5152 आदि) डिफ़ॉल्ट से न छूना सुरक्षित है। ये लक्षित SACL सेटिंग या सीमित जाँच अवधि में ही काम आती हैं; हमेशा पूरा खुला छोड़ें तो लॉग निगल जाती हैं।⁴

flowchart TB
    accTitle: बड़ी-इवेंट उपश्रेणियों का व्यवहार
    accDescr: फ़ाइल सिस्टम या रजिस्ट्री की ऑब्जेक्ट-एक्सेस ऑडिट, privilege use, पैकेट-फ़िल्टर हमेशा पूरा खुला छोड़ने पर लॉग निगल जाते हैं, इसलिए लक्षित SACL सेटिंग या जाँच अवधि तक सीमित करने पर ही काम आते हैं
    heavy["बड़ी-इवेंट उपश्रेणियाँ"] --> use{"कैसे सक्षम करें?"}
    heavy -.-> ex1["ऑब्जेक्ट-एक्सेस ऑडिट"]
    heavy -.-> ex2["privilege use और पैकेट-फ़िल्टर"]
    use -->|हमेशा पूरा खुला| eat["लॉग निगल जाते हैं"]
    use -->|लक्षित SACL| ok1["काम आता है"]
    use -->|जाँच अवधि तक सीमित| ok2["काम आता है"]

चित्र 5: ऑब्जेक्ट एक्सेस और privilege use हमेशा पूरा खुला न छोड़ें। लक्ष्य और अवधि बाँधने पर ही काम आते हैं।

4. मानक इवेंट ID कैसे पढ़ें

4.1. 4624 — साइन-इन सफलता लॉगऑन प्रकार से छाँटें

4624, “An account was successfully logged on”, उस मशीन पर दर्ज होता है जहाँ लॉगऑन सत्र बना (जिस तक पहुँचा गया)।⁵ मात्रा बहुत होती है, इसलिए पढ़ते समय पहले लॉगऑन प्रकार से छाँटें।⁵

साथ देखने वाले फ़ील्ड: “New Logon” का खाता नाम, “Network Information” का उद्गम पता, “Authentication Package” (NTLM या Kerberos), और “Elevated Token” (व्यवस्थापक विशेषाधिकार सत्र है या नहीं)। केवल व्यवस्थापक विशेषाधिकार वाले साइन-इन ट्रेस करना हो तो उसी लॉगऑन ID पर दर्ज 4672 (Special privileges assigned to new logon) भी काम आता है।⁵

flowchart TB
    accTitle: 4624 पढ़ने का क्रम
    accDescr: बड़ी मात्रा में दर्ज 4624 पहले लॉगऑन प्रकार से छाँटें, खाता नाम और उद्गम, प्रमाणीकरण पैकेज, Elevated Token देखें, व्यवस्थापक विशेषाधिकार साइन-इन उसी लॉगऑन ID के 4672 से मिलाएँ
    ev["4624 साइन-इन सफलता"] --> type["लॉगऑन प्रकार से छाँटें"]
    type --> fields["मुख्य फ़ील्ड देखें"]
    fields -.-> f1["खाता नाम और उद्गम"]
    fields -.-> f2["प्रमाणीकरण पैकेज"]
    fields -.-> f3["Elevated Token"]
    fields --> admin["व्यवस्थापक विशेषाधिकार का पता"]
    admin -.-> e4672["उसी लॉगऑन ID का 4672"]

चित्र 6: 4624 को लॉगऑन प्रकार से छाँटकर फ़ील्ड पढ़ें। विशेषाधिकार साइन-इन 4672 से सहसंबंधित करें।

4.2. 4625 — विफलता का कारण Status/Sub Status कोड से पक्का करें

4625, “An account failed to log on”, उस मशीन पर दर्ज होता है जहाँ लॉगऑन का प्रयास हुआ।⁶ “Failure Reason” के शब्दों से अधिक भरोसेमंद Status/Sub Status का हेक्साडेसिमल कोड है। मानक ये हैं।⁶

• 0xC0000064: अस्तित्वहीन उपयोगकर्ता नाम। थोड़े समय में लगातार आए तो खाता-गणना हमले का संकेत
• 0xC000006A: गलत पासवर्ड। किसी खास खाते पर लगातार आए तो पासवर्ड-अनुमान हमले का संकेत
• 0xC000006D: उपयोगकर्ता नाम या प्रमाणीकरण जानकारी अमान्य
• 0xC000006F: अनुमत समय के बाहर
• 0xC0000070: अनुमत न वर्कस्टेशन से
• 0xC0000072: व्यवस्थापक द्वारा अक्षम खाता (निकले कर्मचारी के खाते पर प्रयास यहीं दिखते हैं)
• 0xC000015B: इस मशीन पर अनुरोधित लॉगऑन प्रकार अनुमत नहीं
• 0xC0000193: समाप्त खाता
• 0xC0000234: लॉकआउट

“किसने, कहाँ से, क्यों विफल” लक्ष्य खाता + उद्गम (वर्कस्टेशन नाम/IP पता) + इस कोड के तीन-बिंदु सेट से पक्का होता है। अध्याय 6 में ये तीन एक साथ निकालने वाला PowerShell है।

flowchart TB
    accTitle: 4625 की विफलता का कारण पक्का करने का प्रवाह
    accDescr: 4625 की विफलता Status/Sub Status के हेक्स कोड से पक्की होती है, कोड की प्रवृत्ति से हमले का संकेत पढ़कर लक्ष्य खाता और उद्गम के तीन-बिंदु सेट से पहचानें
    ev["4625 साइन-इन विफलता"] --> code["Sub Status कोड देखें"]
    code --> sign{"कोड की प्रवृत्ति?"}
    sign -->|0xC0000064 की कड़ी| enum["खाता-गणना का संकेत"]
    sign -->|0xC000006A की कड़ी| guess["पासवर्ड-अनुमान का संकेत"]
    sign -->|0xC0000072| disabled["निकले कर्मचारी के खाते का प्रयास"]
    enum --> triple["तीन-बिंदु सेट से पक्का"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["लक्ष्य खाता+उद्गम+कोड"]

चित्र 7: विफलता का कारण कोड से पक्का करें, लक्ष्य खाता और उद्गम के साथ तीन-बिंदु सेट से पढ़ें।

4.3. 4740 — लॉकआउट का उद्गम “Caller Computer Name”

4740, “A user account was locked out” है (उपश्रेणी User Account Management)। इस इवेंट का मुख्य फ़ील्ड “Caller Computer Name” है, जिसमें लॉकआउट का ट्रिगर बना लॉगऑन प्रयास किस कंप्यूटर से आया दर्ज होता है।¹⁶ यहाँ से उद्गम मशीन पहचानें, उस मशीन पर बची पुरानी साख खंगालें — यही मानक विधि है। कारण लगभग हमेशा पासवर्ड बदलने के बाद भी पुरानी साख इस्तेमाल करती कोई चीज़ होती है (सहेजी साख, कटा अधूरा RDP सत्र, पुराने पासवर्ड की सेवा या कार्य)।

flowchart TB
    accTitle: खाता लॉकआउट जाँच की मानक विधि
    accDescr: 4740 के Caller Computer Name से उद्गम मशीन पहचानें, वहाँ बची सहेजी साख, कटे अधूरे RDP सत्र, पुराने पासवर्ड की सेवा या कार्य खंगालें
    ev["4740 लॉकआउट हुआ"] --> caller["Caller Computer Name देखें"]
    caller --> src["उद्गम मशीन पहचानें"]
    src --> sweep["पुरानी साख खंगालें"]
    sweep -.-> c1["सहेजी साख"]
    sweep -.-> c2["कटा अधूरा RDP सत्र"]
    sweep -.-> c3["पुराने पासवर्ड की सेवा या कार्य"]

चित्र 8: 4740 के “Caller Computer Name” से उद्गम पहचानें, उस टर्मिनल की पुरानी साख खंगालें।

एक सावधानी है। 4625 लॉगऑन प्रयास स्वीकार करने वाले कंप्यूटर पर दर्ज होता है। उद्गम मशीन से फ़ाइल सर्वर आदि पर नेटवर्क लॉगऑन कारण हो तो उद्गम मशीन के अपने Security लॉग में 4625 नहीं रहता; निशान गंतव्य सर्वर के 4625 पर, या डोमेन खाते पर DC के 4776 (NTLM)/4771 (Kerberos पूर्व-प्रमाणीकरण विफलता) पर रहता है।⁷⁸ “उद्गम मशीन के लॉग में कुछ नहीं” हो तो स्वीकार करने वाले पक्ष पर जाएँ।

flowchart TB
    accTitle: विफलता का निशान किस मशीन पर रहता है
    accDescr: नेटवर्क लॉगऑन की विफलता उद्गम मशीन पर नहीं रहती, लॉगऑन प्रयास स्वीकार करने वाले गंतव्य सर्वर के 4625 पर दर्ज होती है, डोमेन खाते पर DC के 4776 या 4771 पर भी निशान रहता है
    src["उद्गम मशीन（स्वयं पर 4625 नहीं）"] -->|नेटवर्क लॉगऑन| target["गंतव्य सर्वर"]
    target -.-> e4625["4625 दर्ज होता है"]
    src -->|डोमेन खाते का प्रमाणीकरण| dc["डोमेन नियंत्रक"]
    dc -.-> e4776["4776（NTLM）/4771（Kerberos）"]

चित्र 9: 4625 स्वीकार करने वाले पक्ष पर रहता है। उद्गम मशीन पर कुछ न हो तो गंतव्य सर्वर और DC देखें।

4.4. 4720 परिवार — खाता निर्माण, बदलाव, समूह में जोड़ना

खाता-प्रबंधन इवेंट क्रमांक से सटे हैं। 4720 (उपयोगकर्ता खाता बना)¹⁷, 4726 (हटाया), 4738 (बदला), और समूह पक्ष पर सदस्य जोड़ना/हटाना। ध्यान दें कि समूह सदस्यता बदलने का इवेंट ID समूह के प्रकार से बँटता है। स्थानीय समूह 4732/4733, ग्लोबल समूह 4728/4729, यूनिवर्सल समूह 4756/4757।¹⁴ Domain Admins ग्लोबल समूह है, इसलिए उसमें जोड़ना 4728 पर दर्ज होता है — केवल 4732 पर अलर्ट लगाएँ तो सबसे देखना-चाहिए घटना छूट जाती है। रोज़ यह मदद डेस्क के काम का रिकॉर्ड है, पर “सामान्य उपयोगकर्ता अचानक व्यवस्थापक समूह में जुड़ गया” या “कोई न पहचाने खाता बन गया” एक बार भी तुरंत जाँच का विषय है। Microsoft स्वयं विशेषाधिकार समूह में अप्रत्याशित सदस्य जोड़ को एकल अलर्ट के उदाहरण में रखता है।³

flowchart TB
    accTitle: समूह प्रकार और सदस्य-जोड़ इवेंट
    accDescr: समूह में सदस्य जोड़ना समूह प्रकार से इवेंट ID बाँटता है, स्थानीय 4732, ग्लोबल 4728, यूनिवर्सल 4756 पर दर्ज होता है, इसलिए ग्लोबल समूह Domain Admins में जोड़ना 4728 देखें
    add["समूह में सदस्य जोड़ना"] --> kind{"समूह का प्रकार?"}
    kind -->|स्थानीय| lg["4732 पर दर्ज"]
    kind -->|ग्लोबल| gg["4728 पर दर्ज"]
    kind -->|यूनिवर्सल| ug["4756 पर दर्ज"]
    gg -.-> da["Domain Admins में जोड़ना यहीं"]
    lg -.-> miss["केवल 4732 निगरानी चूकती है"]

चित्र 10: सदस्य जोड़ का इवेंट ID समूह प्रकार से बँटता है। Domain Admins में जोड़ना 4728 है।

4.5. 4688 — प्रोसेस निर्माण। कमांड-लाइन रिकॉर्डिंग अलग स्विच है

4688, “A new process has been created”, हर प्रोसेस निर्माण पर बनाने वाला खाता, नए प्रोसेस का निष्पादन-फ़ाइल पथ, पैरेंट प्रोसेस, और टोकन उन्नयन प्रकार दर्ज करता है।¹¹ “इस सर्वर पर किसने क्या चलाया” का उत्तर दे सकने वाला, ऊँचे जाँच मूल्य वाला इवेंट है।

पर डिफ़ॉल्ट में कमांड-लाइन तर्क दर्ज नहीं होते। Group Policy सेटिंग “Include command line in process creation events” (Administrative Templates > System > Audit Process Creation) अलग से सक्षम करने पर ही 4688 के “Process Command Line” फ़ील्ड में तर्क आते हैं।¹¹¹² powershell -EncodedCommand ... जैसे संदेहास्पद स्टार्ट ट्रेस करने के लिए व्यवहार में आवश्यक सेटिंग है, पर अध्याय 7 में बताए रहस्य-मिश्रण के जोखिम समझकर सक्षम करें।

flowchart TB
    accTitle: 4688 और कमांड-लाइन रिकॉर्डिंग का संबंध
    accDescr: प्रोसेस निर्माण ऑडिट सक्षम करने पर 4688 में खाता, निष्पादन-फ़ाइल पथ, पैरेंट प्रोसेस दर्ज होते हैं, पर कमांड-लाइन तर्क अलग Group Policy सक्षम करने पर ही दर्ज होते हैं, और रहस्य सादे पाठ में बैठने का जोखिम है
    audit["प्रोसेस निर्माण ऑडिट सक्षम करें"] --> ev["4688 दर्ज होता है"]
    ev -.-> base["खाता, पथ, पैरेंट प्रोसेस"]
    ev --> args{"तर्क भी देखने हैं?"}
    args -->|डिफ़ॉल्ट जैसा| none["कमांड लाइन खाली"]
    args -->|अतिरिक्त GPO सक्षम| cmd["तर्क दर्ज होते हैं"]
    cmd -.-> risk["रहस्य सादे पाठ में बैठने का जोखिम"]

चित्र 11: 4688 की कमांड-लाइन रिकॉर्डिंग अलग स्विच है। सक्षम करने से पहले रहस्य-मिश्रण जोखिम जाँचें।

4.6. 4698 — अनुसूचित कार्य का निर्माण

4698, “A scheduled task was created”, कार्य नाम और कार्य परिभाषा का पूरा XML (चलाए जाने वाले कमांड सहित) दर्ज करता है। मैलवेयर रीबूट के बाद भी जीवित रहने के लिए कार्य पंजीकरण आम विधि मानता है, इसलिए Microsoft कार्य-निर्माण इवेंट की निगरानी सुझाता है।¹⁵ व्यावसायिक काम में कार्य बहुत इस्तेमाल करने वाले परिवेश में भी निर्माण रोज़ की घटना नहीं, इसलिए शोर अपेक्षाकृत कम रहता है।

flowchart TB
    accTitle: कार्य पंजीकरण से स्थायित्व और 4698
    accDescr: मैलवेयर रीबूट के बाद जीवित रहने के लिए अनुसूचित कार्य पंजीकरण आम विधि मानता है, इसलिए कार्य निर्माण पर दर्ज 4698 निगरानी से चलाए जाने वाले कमांड सहित कार्य परिभाषा तक पहुँच सकते हैं
    mal["मैलवेयर की स्थायित्व"] --> task["कार्य पंजीकृत कर जीवित रहना"]
    task --> ev["4698 दर्ज होता है"]
    ev -.-> xml["कमांड सहित पूरा XML"]
    ev --> watch["कार्य निर्माण की निगरानी से पता"]
    watch -.-> low["निर्माण रोज़ नहीं, शोर कम"]

चित्र 12: स्थायित्व की आम विधि कार्य पंजीकरण 4698 में रहती है। परिभाषा XML से चलाए जाने वाले कमांड तक पहुँच सकते हैं।

एक और याद रखने योग्य 1102, “The audit log was cleared” है। Security लॉग साफ़ करना हमेशा यह इवेंट छोड़ता है, इसलिए “लॉग खाली है” पर दुर्घटना है या संचालन, बाँटा जा सकता है।¹⁸

flowchart TB
    accTitle: 1102 से लॉग मिटाने का भेद
    accDescr: Security लॉग साफ़ करना हमेशा 1102 छोड़ता है, इसलिए लॉग खाली हो तो 1102 है या नहीं देखकर मिटाने का संचालन था या दुर्घटना, बाँटा जा सकता है
    empty["लॉग खाली है"] --> rule["साफ़ करना हमेशा 1102 छोड़ता है"]
    rule --> check{"1102 है?"}
    check -->|है| op["मिटाने का संचालन हुआ"]
    check -->|नहीं| acc["दुर्घटना की संभावना"]

चित्र 13: Security लॉग साफ़ करना हमेशा 1102 छोड़ता है। खाली लॉग 1102 की उपस्थिति से दुर्घटना या संचालन बाँटें।

5. लॉग के पात्र का डिज़ाइन — अधिकतम आकार और प्रतिधारण

ऑडिट नीति बढ़ाने से पहले पात्र जाँचें। Security लॉग का अधिकतम आकार और प्रतिधारण मोड होता है: ओवरराइट मोड (आम विन्यास) में अधिकतम आकार पहुँचने पर नए इवेंट सबसे पुराने को ओवरराइट करते हैं। उलटा, प्रतिधारण मोड (ओवरराइट न करें) में लॉग भरने पर नए इवेंट ही त्यागे जाते हैं।¹⁰ दोनों व्यवहार “ध्यान गया तो लॉग नहीं” का कारण बनते हैं, इसलिए वर्तमान स्थिति पहले जानें।

# Security लॉग का पात्र देखें: प्रतिधारण मोड, अधिकतम आकार, वर्तमान संख्या
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# अभी वास्तव में कितने दिन बचे हैं (सबसे पुराने इवेंट का समय)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog लॉग का विन्यास और संख्या एक साथ लौटाता है।⁹ “सबसे पुराने इवेंट का समय” और वर्तमान का अंतर वास्तविक प्रतिधारण दिन हैं; यह आपकी आवश्यकता (घटना जाँच में कितने दिन पीछे जाना है) से कम हो तो अधिकतम आकार बढ़ाएँ। सेटिंग wevtutil sl Security /ms:<बाइट संख्या> या Group Policy से बाँटी जा सकती है।¹⁰

flowchart TB
    accTitle: प्रतिधारण दिनों से उलटा हिसाब लगा क्षमता डिज़ाइन
    accDescr: Get-WinEvent के ListLog से विन्यास और संख्या देखें, सबसे पुराने इवेंट के समय से वास्तविक प्रतिधारण दिन निकालें, घटना जाँच में जितने दिन पीछे जाना है उससे कम हों तो अधिकतम आकार बढ़ाएँ
    check["ListLog से विन्यास और संख्या"] --> oldest["सबसे पुराने इवेंट का समय"]
    oldest --> days["वास्तविक प्रतिधारण दिन निकालें"]
    days --> enough{"आवश्यकता पूरी?"}
    enough -->|पर्याप्त| keep["वर्तमान आकार रखें"]
    enough -->|अपर्याप्त| grow["अधिकतम आकार बढ़ाएँ"]
    grow -.-> how["wevtutil sl या GPO से सेट"]

चित्र 14: वास्तव में बचे दिन देखें, जितने दिन पीछे जाना है उससे उलटा हिसाब लगा अधिकतम आकार तय करें।

साथ ही सुरक्षा विकल्प “Audit: Shut down system immediately if unable to log security audits” (तथाकथित CrashOnAuditFail) है। सक्षम हो और ऑडिट दर्ज न हो सके तो STOP त्रुटि C0000244 से प्रणाली रुकती है। ऑडिट निशान बिलकुल न खोने देने वाली प्रमाणीकरण आवश्यकताओं के लिए सेटिंग है, डिफ़ॉल्ट अक्षम है। Microsoft स्वयं चेतावनी देता है कि हमलावर बड़ी मात्रा में इवेंट पैदा कर सर्वर जानबूझकर रोकने वाले DoS में बदल सकता है — सामान्य छोटे-मध्यम परिवेश में इसे हल्के में सक्षम न करें।¹⁹

flowchart TB
    accTitle: लॉग भरने पर व्यवहार
    accDescr: प्रतिधारण विन्यास ओवरराइट मोड और ओवरराइट न करने वाले मोड दो हैं, ओवरराइट न करने पर ऑडिट दर्ज न हो सके और अलग सेटिंग CrashOnAuditFail सक्षम हो तो STOP त्रुटि C0000244 से प्रणाली रुकती है
    full["Security लॉग अधिकतम आकार पर"] --> mode{"प्रतिधारण विन्यास?"}
    mode -->|ओवरराइट मोड| ow["सबसे पुराने इवेंट ओवरराइट"]
    mode -->|ओवरराइट न करें| drop["नए इवेंट त्यागे जाते हैं"]
    ow -.-> lost["दोनों ध्यान गया तो लॉग नहीं का कारण"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail भी सक्षम?"}
    caf -->|हाँ| crash["STOP त्रुटि C0000244 से रुकना"]

चित्र 15: प्रतिधारण विन्यास ओवरराइट या त्याग, दो रास्ते। CrashOnAuditFail अलग सेटिंग है, दर्ज न हो सके तो रोकती है।

6. जाँच का व्यवहार — फ़िल्टर, Get-WinEvent, निर्यात

6.1. इवेंट व्यूअर में संकीर्ण करना

एकमुश्त जाँच के लिए इवेंट व्यूअर काफी है। Security लॉग खोलें, “Filter Current Log” से इवेंट ID (उदाहरण 4625) और अवधि तय करें। बार-बार देखी शर्तें “Custom View” में सहेजें तो अगली बार एक क्लिक। इवेंट ID के अलावा किसी खाते से संकीर्ण करना हो तो फ़िल्टर संवाद के XML टैब पर XPath क्वेरी सीधे संपादित कर सकते हैं।

6.2. Get-WinEvent से निष्कर्षण

बड़ी संख्या, कई शर्तें, या नियमित चलान वाली जाँच PowerShell के Get-WinEvent पर ले जाएँ। मुख्य बात सर्वर पक्ष पर फ़िल्टर चलाने वाला -FilterHashtable इस्तेमाल करना है।⁹

flowchart TB
    accTitle: जाँच साधनों का चुनाव
    accDescr: एकमुश्त जाँच इवेंट व्यूअर के फ़िल्टर से काफी है, बार-बार देखी शर्तें कस्टम व्यू में सहेजें, बड़ी संख्या या कई शर्तें या नियमित चलान Get-WinEvent पर ले जाएँ
    q{"कैसी जाँच?"}
    q -->|एकमुश्त| viewer["इवेंट व्यूअर से संकीर्ण करें"]
    q -->|बार-बार देखी शर्तें| view["कस्टम व्यू में सहेजें"]
    q -->|बड़ी संख्या, कई शर्तें, नियमित| ps["Get-WinEvent पर जाएँ"]
    ps -.-> hash["FilterHashtable से संकीर्ण"]

चित्र 16: एकमुश्त इवेंट व्यूअर, दोहराएँ तो कस्टम व्यू, संख्या अधिक हो तो Get-WinEvent।

# पिछले 24 घंटे की साइन-इन विफलताएँ (4625)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# "किसने, कहाँ से, क्यों" को तालिका में ढालें
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

इवेंट के XML रूप से EventData निकालने का यह साँचा एक बार रख लें तो 4624 हो या 4688, वही तरीका काम आता है। Get-WinEvent की संकीर्णता डिज़ाइन (FilterHashtable बनाम XPath, धीमी क्वेरी सुधार) “Get-WinEvent से इवेंट लॉग व्यावहारिक जाँच — संकीर्णता की गति जाँच का समय तय करती है” में विस्तार से है।

flowchart TB
    accTitle: EventData निकालकर तालिका बनाने का साँचा
    accDescr: Get-WinEvent से मिले इवेंट XML रूप में बदलें, EventData के फ़ील्ड निकालकर तालिका में ढालें, यह साँचा 4625 तक सीमित नहीं, 4624 और 4688 पर भी वही तरीका चलता है
    get["Get-WinEvent से प्राप्त"] --> xml["इवेंट को XML रूप में बदलें"]
    xml --> pull["EventData निकालें"]
    pull --> shape["तालिका में ढालकर जोड़ें"]
    shape -.-> reuse["4624 या 4688 पर भी वही तरीका"]

चित्र 17: XML रूप से EventData निकालकर तालिका बनाने का साँचा इवेंट ID बदलने पर भी दोहराया जा सकता है।

6.3. wevtutil से निर्यात

जाँच लक्ष्य मशीन के लॉग पहले निर्यात कर सुरक्षित करें, ओवरराइट से मिटने से पहले।¹⁰

rem पूरा Security लॉग evtx में सुरक्षित करें
wevtutil epl Security C:\logs\security-20260801.evtx

rem केवल 4625 XPath से संकीर्ण कर निर्यात
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

निर्यात किया .evtx दूसरी मशीन पर Get-WinEvent -Path C:\logs\security-20260801.evtx से उसी तरह विश्लेषित होता है।⁹ सुरक्षित करके फिर विश्लेषण की आदत क्रैश जाँच में “पहले डंप सुरक्षित करें” जैसी ही है (“Windows क्रैश डंप संग्रह का परिचय - WER/ProcDump/WinDbg” देखें)।

flowchart TB
    accTitle: सुरक्षित करके फिर विश्लेषण का प्रवाह
    accDescr: जाँच लक्ष्य मशीन के Security लॉग wevtutil epl से evtx फ़ाइल में निर्यात कर सुरक्षित करें, दूसरी मशीन पर Get-WinEvent के Path से उसी तरह विश्लेषण करें
    target["जाँच लक्ष्य मशीन"] --> export["wevtutil epl से evtx में सुरक्षित"]
    export --> copy["दूसरी मशीन पर ले जाएँ"]
    copy --> analyze["Get-WinEvent -Path से विश्लेषण"]
    export -.-> note["ओवरराइट से मिटने से पहले सुरक्षित"]

चित्र 18: पहले सुरक्षित करें, फिर विश्लेषण। evtx में रखें तो दूसरी मशीन पर उसी तरह जाँच सकते हैं।

7. जाल — मैदान में आसानी से पड़ने वाले चार

(1) 4688 की कमांड लाइन पर रहस्य बैठते हैं। कमांड-लाइन रिकॉर्डिंग सक्षम करने पर हर प्रोसेस के तर्क Security लॉग में सादे पाठ में आते हैं। Microsoft स्पष्ट लिखता है कि “सुरक्षा इवेंट पढ़ने की पहुँच वाले सभी उपयोगकर्ता हर सफलतापूर्वक बने प्रोसेस के कमांड-लाइन तर्क पढ़ सकते हैं। तर्कों में पासवर्ड जैसी संवेदनशील जानकारी हो सकती है।” ¹² myapp.exe /user:admin /password:P@ssw0rd जैसा स्टार्ट करने वाला कोई व्यावसायिक ऐप या स्क्रिप्ट हो तो वह लॉग देखने वाले सभी के लिए रहस्य खोल देता है। सक्षम करने से पहले रहस्य तर्क के रूप में देने वाली जगहें निकालकर सुधारें। लॉग सुरक्षित रखने या अग्रेषित करने वाले गंतव्य पर भी वही गोपनीयता स्तर चाहिए।

flowchart TB
    accTitle: कमांड-लाइन रिकॉर्डिंग सक्षम करने का क्रम
    accDescr: 4688 की कमांड-लाइन रिकॉर्डिंग सक्षम करने से पहले रहस्य तर्क में देने वाले व्यावसायिक ऐप और स्क्रिप्ट निकालें, संबंधित जगहें सुधारकर सक्षम करें, लॉग सुरक्षित रखने और अग्रेषित करने वाले गंतव्य पर भी वही स्तर माँगें
    audit["रहस्य तर्क में देने वाली जगहें निकालें"] --> found{"कोई है?"}
    found -->|है| fix["देने वाली जगहें सुधारें"]
    found -->|नहीं| on["कमांड-लाइन रिकॉर्डिंग सक्षम करें"]
    fix --> on
    on -.-> dest["सुरक्षित रखना और अग्रेषण भी वही स्तर"]

चित्र 19: कमांड-लाइन रिकॉर्डिंग “निकालकर सुधारकर फिर सक्षम”। क्रम उलटा करें तो रहस्य सार्वजनिक हो जाते हैं।

(2) लॉग भरने पर क्या होता है जाने बिना चलाना। ओवरराइट मोड में पुराने निशान चुपचाप मिटते हैं; ओवरराइट न करें सेटिंग में नए इवेंट त्यागे जाते हैं; CrashOnAuditFail सक्षम हो तो पूरी प्रणाली रुकती है (अध्याय 5)।¹⁰¹⁹ कौन सा व्यवहार चुना है जानें, और “मिटने से पहले एकत्र करें” तंत्र (नियमित निर्यात या लॉग-संग्रह मंच) रखें — यही मूल है।

(3) डोमेन नियंत्रक और टर्मिनल पर देखने वाले लॉग अलग हैं। 4624/4625 पहुँची गई मशीन पर दर्ज होते हैं।⁵⁶ दूसरी ओर डोमेन खाते की साख सत्यापन (NTLM का 4776) साख पर अधिकार रखने वाली मशीन पर दर्ज होता है — डोमेन खाते पर वह DC है⁷ — और Kerberos पूर्व-प्रमाणीकरण विफलता (4771) केवल DC पर दर्ज होती है।⁸ “फ़ाइल सर्वर पर 4625 नहीं = हमला नहीं था” नहीं; DC के 4776/4771 मिलाकर ही पूरी तस्वीर बनती है। प्रत्येक प्रमाणीकरण प्रोटोकॉल कैसे बहता है, “आरेखों से NTLM और Kerberos — प्रमाणीकरण NTLM पर क्यों गिरता है” देखें।

(4) घड़ी तुल्यकालन बिगड़े तो मिलान नहीं बनता। कई मशीनों के लॉग सजाकर “इस 4740 से ठीक पहले किस टर्मिनल पर 4625 निकला” ट्रेस करना तभी चलता है जब हर मशीन की घड़ी मेल खाए। डोमेन परिवेश में Kerberos स्वयं घड़ी अंतर की ऊपरी सीमा (डिफ़ॉल्ट 5 मिनट) रखता है, उसे पार करें तो प्रमाणीकरण स्वयं विफल होने लगता है।²⁰ जाँच की दृष्टि से पाँच मिनट नहीं, कुछ सेकंड का अंतर भी क्रम गलत पढ़वा सकता है, इसलिए w32time की तुल्यकालन स्थिति जाँच प्रक्रिया का पहला कदम बनाएँ। साथ ही इवेंट का समय UTC में संग्रहीत होता है और प्रदर्शन देखने वाली मशीन के समय क्षेत्र के अनुसार होता है, इसलिए विदेशी स्थल या UTC सेटिंग वाले सर्वर से लाए .evtx पढ़ते समय समय क्षेत्र बदलना न भूलें।

flowchart TB
    accTitle: घड़ी तुल्यकालन और मिलान जाँच की पूर्वापेक्षा
    accDescr: कई मशीनों के लॉग समय-क्रम से मिलाने की जाँच हर मशीन की घड़ी मेल खाने पर टिकती है, कुछ सेकंड का अंतर भी क्रम गलत पढ़वाता है, डिफ़ॉल्ट 5 मिनट पार करने पर Kerberos प्रमाणीकरण स्वयं विफल होता है, इसलिए w32time की पुष्टि जाँच प्रक्रिया के पहले रखें
    merge["कई मशीनों के लॉग मिलाएँ"] --> pre["घड़ियाँ मेल खाना पूर्वापेक्षा"]
    pre --> skew{"घड़ी का अंतर?"}
    skew -->|मेल खाती हैं| ok["समय-क्रम से ट्रेस कर सकते हैं"]
    skew -->|कुछ सेकंड का अंतर| misread["क्रम गलत पढ़ना"]
    skew -->|डिफ़ॉल्ट 5 मिनट से अधिक| kerb["Kerberos प्रमाणीकरण विफल"]
    pre -.-> first["w32time की पुष्टि प्रक्रिया के पहले"]

चित्र 20: कई मशीनों का मिलान घड़ी मिलाने पर टिकता है। कुछ सेकंड का अंतर भी क्रम गलत पढ़वाता है।

8. सारांश

• ऑडिट नीति की दो प्रणालियाँ हैं, “मूल” और “उन्नत”; मिलाने से अप्रत्याशित परिणाम आते हैं। उन्नत पक्ष पर एकरूप रहें, auditpol /get /category:* से वर्तमान स्थिति देखकर डिज़ाइन करें।
• “सब सक्षम” शोर और फूलने से जाँच मार देता है। Microsoft की बेसलाइन सिफ़ारिश से शुरू करें, लॉगऑन, खाता प्रबंधन और प्रोसेस निर्माण धुरी वाली अध्याय 3 की निर्णय तालिका से बढ़ें।
• 4624 लॉगऑन प्रकार से, 4625 Status/Sub Status कोड से, 4740 Caller Computer Name से, 4688 पैरेंट प्रोसेस और कमांड लाइन से — प्रत्येक इवेंट का “यहाँ देखें” बिंदु है।
• लॉग का पात्र (अधिकतम आकार और प्रतिधारण मोड) ऑडिट डिज़ाइन का आधा है। वास्तव में बचे दिन देखें, आवश्यकता से उलटा हिसाब लगा आकार तय करें, मिटने से पहले निर्यात या एकत्र करें।
• 4688 की कमांड-लाइन रिकॉर्डिंग रहस्य-मिश्रण जोखिम जाँचकर ही। मशीन के अनुसार दर्ज स्थान का अंतर और घड़ी तुल्यकालन मिलान जाँच की पूर्वापेक्षाएँ हैं।
• जाँच इवेंट व्यूअर के फ़िल्टर से शुरू करें; दोहराएँ तो Get-WinEvent -FilterHashtable; सुरक्षित रखना wevtutil epl। “पहले सुरक्षित, फिर विश्लेषण” का क्रम न तोड़ें।

संबंधित लेख

• Get-WinEvent से इवेंट लॉग व्यावहारिक जाँच — संकीर्णता की गति जाँच का समय तय करती है
• NTLM समाप्ति से व्यावसायिक ऐप रुकेंगे? — ऑडिट लॉग कैसे लें, निर्भरता मिटाने का क्रम
• आरेखों से NTLM और Kerberos — प्रमाणीकरण NTLM पर क्यों गिरता है
• SMB साइनिंग और LDAP चैनल बाइंडिंग — NTLM रक्षा का “बाकी आधा” व्यवहार में बंद करना
• Windows इवेंट लॉग और ETW का परिचय — व्यावसायिक ऐप के लॉग OS के मानक तंत्र पर रखना
• Windows क्रैश डंप संग्रह का परिचय - WER/ProcDump/WinDbg

संबंधित परामर्श क्षेत्र

KomuraSoft LLC Windows ऑडिट नीति और लॉग डिज़ाइन परामर्श, इवेंट लॉग से “कब, किसने, क्या किया” की जाँच, और व्यावसायिक ऐप्स के प्रमाणीकरण-ऑडिट संबंधी विफलताओं का मूल कारण विश्लेषण संभालता है। “लॉग देखने को कहा गया, पर कहाँ से शुरू करें नहीं पता” चरण से शुरू करना ठीक है।

• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

हमने कोई ऑडिट नीति सेट नहीं की, फिर भी Security लॉग में 4624 और 4625 क्यों दिखते हैं?

क्योंकि Windows में कुछ ऑडिट उपश्रेणियाँ डिफ़ॉल्ट से सक्षम होती हैं। उदाहरण के लिए "Logon" उपश्रेणी में Windows 10 संस्करण 1809 से सफलता और विफलता दोनों डिफ़ॉल्ट से चालू हैं, इसलिए आप स्वयं कुछ सेट न करें तब भी 4624 (सफलता) और 4625 (विफलता) दर्ज होते हैं। डिफ़ॉल्ट छोड़ देने पर, जाँच में वास्तव में चाहिए इवेंट — साख सत्यापन (4776) या प्रोसेस निर्माण (4688) — अक्सर दर्ज ही नहीं होते। अपने परिवेश में क्या सक्षम है, `auditpol /get /category:*` से देखें। उसके बाद जो उपश्रेणियाँ कमी हों, उन्हें उन्नत ऑडिट नीति पक्ष पर स्पष्ट रूप से सक्षम करना व्यवहार की मानक विधि है।

साइन-इन विफलता जाँचनी है, पर लक्ष्य सर्वर के Security लॉग में 4625 नहीं मिलता। कहाँ देखें?

पहले यह सिद्धांत पक्का करें: 4625 उस कंप्यूटर पर दर्ज होता है "जहाँ लॉगऑन का प्रयास हुआ।" उपयोगकर्ता वर्कस्टेशन पर साइन-इन विफलता हो तो वर्कस्टेशन; फ़ाइल सर्वर पर पहुँच विफलता हो तो फ़ाइल सर्वर। फिर `auditpol /get /category:*` से देखें कि "Logon" उपश्रेणी की विफलता ऑडिट सक्षम है या नहीं। डोमेन खातों पर निशान अक्सर डोमेन नियंत्रक की साख सत्यापन (4776) या Kerberos पूर्व-प्रमाणीकरण विफलता (4771) में बचता है, और वर्कस्टेशन न पकड़ सकें तो DC पक्ष से शुरू करना अक्सर तेज़ होता है। फिर भी न मिले तो पुराने इवेंट ओवरराइट हो चुके हों (लॉग का अधिकतम आकार बनाम सबसे पुराने इवेंट का समय) जाँचें।

प्रोसेस निर्माण (4688) की कमांड-लाइन रिकॉर्डिंग सक्षम करनी चाहिए?

जाँच मूल्य बहुत ऊँचा है, पर जोखिम समझकर ही सक्षम करें। चालू करने पर हर प्रोसेस के कमांड-लाइन तर्क Security लॉग में सादे पाठ में दर्ज होते हैं। यदि कोई स्क्रिप्ट या व्यावसायिक ऐप पासवर्ड या API कुंजी कमांड-लाइन तर्क के रूप में देता है, वह रहस्य Security लॉग पढ़ सकने वाले सभी को दिख जाता है। Microsoft स्वयं यह सावधानी स्पष्ट लिखता है। सिफ़ारिशी क्रम: पहले देखें कि आपकी स्क्रिप्टें रहस्य कमांड-लाइन तर्क से तो नहीं देतीं, जो देती हैं उन्हें सुधारें, तब सेटिंग सक्षम करें।

Security लॉग का अधिकतम आकार कितना होना चाहिए?

सही तरीका "कितने दिन हाथ में रखने हैं" से उलटा हिसाब लगाना है; कोई एक आकार सब पर नहीं बैठता। वर्तमान सेटिंग और वास्तविक व्यवहार `Get-WinEvent -ListLog Security` से देखें; सबसे पुराने इवेंट के समय और वर्तमान समय का अंतर "अभी वास्तव में कितने दिन बचे हैं" है। ऑडिट उपश्रेणियाँ बढ़ाने से इवेंट मात्रा बढ़ती है, इसलिए सेटिंग बदलने के बाद इस वास्तविक प्रतिधारण अवधि को फिर जाँचें। घटना-प्रतिक्रिया में हफ़्तों या महीनों पुराने लॉग अक्सर चाहिए होते हैं, इसलिए ओवरराइट से पहले नियमित निर्यात करें, या लॉग-संग्रह तंत्र से अलग मशीन पर एकत्रित रखें।

खाता लॉकआउट (4740) का कारण कैसे जाँचें?

पहला सुराग 4740 इवेंट का "Caller Computer Name" फ़ील्ड है। इसमें वह कंप्यूटर दर्ज होता है जहाँ से लॉकआउट का ट्रिगर बना विफल लॉगऑन आया। ध्यान दें कि विफलता का रिकॉर्ड स्वयं (4625) उद्गम मशीन पर नहीं, लॉगऑन प्रयास स्वीकार करने वाले पक्ष पर रहता है। नेटवर्क लॉगऑन हो तो गंतव्य सर्वर के 4625, या डोमेन खाते पर डोमेन नियंत्रक के 4776/4771, समय-क्रम से जोड़ें। उद्गम मशीन पहचानने के बाद वहाँ पासवर्ड बदलने के बाद भी पुरानी साख पकड़े चीज़ें देखें — सहेजी साख, अधूरा Remote Desktop सत्र, पुराने पासवर्ड से बनी सेवा या अनुसूचित कार्य। लॉकआउट दोहराए जाएँ तो घड़ी तुल्यकालन भी जाँचें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।