Windows सेवा खाता चुनना — LocalSystem, वर्चुअल खाते और gMSA

“एक आंतरिक सेवा जिसे हम अभी तक LocalSystem से चला रहे थे, सुरक्षा ऑडिट में ‘अत्यधिक विशेषाधिकार’ चिह्नित हुई। किसमें बदलें?” “सेवा साझा फ़ोल्डर तक नहीं पहुँच सकी, इसलिए हम इसे डोमेन उपयोगकर्ता से चला रहे हैं। पासवर्ड खत्म होने पर सेवा रुक जाती है, इसलिए हमने कभी न खत्म होने वाला बना दिया और रनबुक में सादे पाठ में लिख दिया।” — ग्राहकों की Windows सेवाओं के परामर्श में ये दो बातें नियमित हैं।

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

flowchart TB
    accTitle: लॉगऑन खाता तय करने वाली तीन बातें
    accDescr: सेवा हमेशा किसी खाते के सुरक्षा संदर्भ में चलती है, और वह खाता तय करता है कि स्थानीय रूप से क्या कर सकती है, नेटवर्क के दूर पक्ष से कौन दिखती है, और पासवर्ड कौन प्रबंधित करता है
    acct["सेवा का लॉगऑन खाता"] --> local["स्थानीय रूप से क्या कर सकती है"]
    acct --> net["नेटवर्क के दूर पक्ष से कौन दिखती है"]
    acct --> pwd["पासवर्ड कौन प्रबंधित करता है"]

चित्र 1: लॉगऑन खाता चुनना वह डिज़ाइन निर्णय है जो स्थानीय विशेषाधिकार, नेटवर्क पहचान और पासवर्ड प्रबंधन एक साथ तय करता है।

प्रभावी रूप से छह विकल्प हैं — LocalSystem, LocalService, NetworkService, वर्चुअल खाता (NT SERVICE\<सेवा-नाम>), डोमेन उपयोगकर्ता, और gMSA (group Managed Service Account)। छोटे-मध्यम व्यवसायों के आईटी कर्मचारियों और Windows ऐप डेवलपर्स के लिए, यह लेख इन छह के विशेषाधिकार, नेटवर्क पहचान और पासवर्ड प्रबंधन को एक तालिका में व्यवस्थित करता है और निर्णय प्रवाह सारांशित करता है, अगस्त 2026 तक Microsoft Learn प्राथमिक स्रोतों पर आधारित।

सेवा स्वयं कैसे बनाएँ (Task Scheduler और सेवा में चुनाव, .NET Worker Service से लागू करना) “Windows सेवाएँ बनाना और चलाना” में है। यह लेख “लॉगऑन खाते” पर केंद्रित है, जहाँ सबसे अधिक दुर्घटनाएँ होती हैं।

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

• संदेह हो तो एकल मशीन के भीतर पूरी होने वाली सेवा के लिए वर्चुअल खाता पहला उम्मीदवार है, और डोमेन के भीतर सेवा-विशिष्ट पहचान से संसाधन तक पहुँचने वाली सेवा के लिए gMSA पहला उम्मीदवार है। Microsoft भी जहाँ संभव हो प्रबंधित खाता (MSA / वर्चुअल खाता) इस्तेमाल करने का मार्गदर्शन देता है।¹²
• LocalSystem इसलिए न चुनें कि “चल गया”। टोकन में SYSTEM और BUILTIN\Administrators हैं और SeDebugPrivilege जैसे मजबूत विशेषाधिकार हैं, इसलिए कब्जे पर उस मशीन पर लगभग सब कुछ खो जाता है। sc.exe create का डिफ़ॉल्ट LocalSystem होना इस दुर्घटना का प्रजनन स्थल है।³⁴
• LocalService और NetworkService का अंतर नेटवर्क पहचान है। स्थानीय विशेषाधिकार दोनों के लिए न्यूनतम हैं, पर दूर पक्ष पर LocalService अनाम दिखता है और NetworkService कंप्यूटर खाते जैसा।⁵
• **वर्चुअल खाता (NT SERVICE\<सेवा-नाम>) आधुनिक डिफ़ॉल्ट है जो प्रति सेवा पहचान अलग कर सकता है और पासवर्ड प्रबंधन नहीं चाहता।** ACL पर "NT SERVICE\\सेवा-नाम" सीधे लिख सकते हैं, और SQL Server का डिफ़ॉल्ट सेवा खाता भी यही है।[^understand-service-accounts][^sql-service-accounts]
• जब LocalSystem, NetworkService या वर्चुअल खाता नेटवर्क पर जाता है, वह कंप्यूटर खाता (DOMAIN\कंप्यूटर-नाम$) बन जाता है। साझा फ़ोल्डर या SQL Server की ACL पर PC$ देना अक्सर डोमेन उपयोगकर्ता के बिना काम चला देता है।³⁶
• सेवा के लिए डोमेन उपयोगकर्ता वाली विन्यास पासवर्ड संचालन और Kerberoasting दोनों पर ऋण बन जाती है। SCM संग्रहीत पासवर्ड से लॉगऑन करता है, इसलिए समाप्ति स्टार्ट विफलता बनती है, और उसे टालने वाला “कभी न खत्म + सादा-पाठ मेमो” हमलावर को उपहार है।⁷⁸
• gMSA में Active Directory पासवर्ड स्वतः बनाता और घुमाता है। आवश्यकताएँ डोमेन और KDS रूट कुंजी हैं, और सेवा को “DOMAIN\खाता-नाम$” पर खाली पासवर्ड फ़ील्ड से सेट करें। कुछ ऐप समर्थन नहीं करते, इसलिए पहले से सत्यापित करें।⁹¹⁰
• खाता बदलने से प्रोफ़ाइल, %TEMP% और DPAPI की मान्यताएँ बदलती हैं। पुराने खाते के DPAPI से सुरक्षित डेटा नया खाता डिक्रिप्ट नहीं कर सकता।
• वर्तमान स्थिति की सूची सेवा सूची के लॉगऑन खातों और ईवेंट ID 4624 (लॉगऑन प्रकार 5) से पुष्टि हो सकती है।¹¹

एक वाक्य में इस लेख का निष्कर्ष: “सेवा को मानव पासवर्ड न दें” वाली विन्यास (built-in खाते, वर्चुअल खाता, gMSA) को डिफ़ॉल्ट बनाएँ, और डोमेन उपयोगकर्ता को अंतिम उपाय मानें।

2. विकल्पों का बड़ा चित्र — एक तालिका में छह लॉगऑन खाते

पहले एक समीक्षा कदम। सेवा स्टार्ट पर Service Control Manager (SCM) विन्यासित खाते से लॉगऑन करता है और सफलता पर access token बनाकर सेवा प्रक्रिया को सौंपता है। उसके बाद हर संसाधन पहुँच — फ़ाइलें, पाइप आदि — इस टोकन को ACL से मिलाकर तय होती है।⁷ अतः लॉगऑन खाता चुनना वह डिज़ाइन है जो सेवा प्रक्रिया को दिए गए टोकन की सामग्री तय करता है। ये छह विकल्प हैं।

flowchart TB
    accTitle: सेवा स्टार्ट पर SCM क्या करता है
    accDescr: SCM विन्यासित खाते से लॉगऑन करता है, सफलता पर access token बनाता और सेवा प्रक्रिया को सौंपता है, उसके बाद संसाधन पहुँच टोकन को ACL से मिलाकर तय होती है
    scm["SCM"] --> logon["विन्यासित खाते से लॉगऑन"]
    logon --> token["Access token बनाएँ"]
    token --> proc["सेवा प्रक्रिया को सौंपें"]
    proc --> access["फ़ाइल या पाइप तक पहुँच"]
    access --> check{"ACL अनुमति देती है?"}
    check -->|हाँ| ok["पहुँच सफल"]
    check -->|नहीं| deny["पहुँच अस्वीकृत"]

चित्र 2: सेवा की हर संसाधन पहुँच उस टोकन को ACL से मिलाकर तय होती है जो SCM ने स्टार्ट पर बनाया।

LocalSystem, LocalService, NetworkService और वर्चुअल खाते सभी में पासवर्ड की कोई अवधारणा ही नहीं है। SCM में संग्रहीत पासवर्ड से लॉगऑन करने वाले (= समाप्ति और रिसाव संभव) केवल डोमेन उपयोगकर्ता और स्थानीय उपयोगकर्ता हैं।⁷³

नीचे हम इस तालिका को एक पंक्ति-एक पंक्ति खोदते हैं।

3. LocalSystem में क्या गलत है

3.1. “प्रशासक के रूप में चलाएँ” से भी अधिक मजबूत

LocalSystem (प्रदर्शन नाम Local System, NT AUTHORITY\SYSTEM) SCM का पूर्वनिर्धारित खाता है, और स्थानीय कंप्यूटर पर व्यापक विशेषाधिकार रखता है। टोकन में NT AUTHORITY\SYSTEM और BUILTIN\Administrators के SID हैं, और वह सिस्टम पर अधिकांश ऑब्जेक्ट तक पहुँच सकता है। आगे, SeDebugPrivilege, जो अन्य प्रक्रियाओं को डीबग कर सकता है, और SeTcbPrivilege, जो OS का भाग बनकर कार्य करता है, डिफ़ॉल्ट से सक्षम हैं।³

यह शक्ति कब्जे पर क्षति के आकार का पर्याय है। यदि LocalSystem से चलने वाली सेवा में एक मनमाना-कोड-निष्पादन भेद्यता हो, हमलावर एक साँस में उस मशीन पर हर उपयोगकर्ता की फ़ाइलें पढ़-बदल सकता है (NTFS पर SYSTEM के पास डिफ़ॉल्ट Full Control है⁵), SeDebugPrivilege से अन्य प्रक्रियाओं की मेमोरी पढ़ सकता है, और साख चुराकर वहाँ से पार्श्व गति कर सकता है (Pass-the-Hash आदि का आरंभ बिंदु)। साख चोरी और पार्श्व गति की श्रृंखला “आरेखों से NTLM और Kerberos” और “Windows LAPS व्यावहारिक मार्गदर्शिका” में है।

flowchart TB
    accTitle: LocalSystem सेवा के कब्जे पर क्षति
    accDescr: यदि LocalSystem से चलने वाली सेवा में एक मनमाना-कोड-निष्पादन भेद्यता हो, हमलावर हर उपयोगकर्ता की फ़ाइलें पढ़-बदल सकता है, अन्य प्रक्रियाओं की मेमोरी पढ़ सकता है, और साख चुराकर पार्श्व गति कर सकता है
    vuln["एक मनमाना-कोड-निष्पादन भेद्यता"] --> sys["हमलावर SYSTEM विशेषाधिकार पाता है"]
    sys --> files["फ़ाइलें पढ़ना और बदलना"]
    sys --> mem["अन्य प्रक्रियाओं की मेमोरी पढ़ना"]
    sys --> cred["साख चोरी"]
    cred --> lateral["दूसरी मशीन पर पार्श्व गति"]

चित्र 3: LocalSystem सेवा में एक भेद्यता हमलावर को एक साँस में पूरी मशीन और पार्श्व गति का आरंभ बिंदु तक पहुँचा देती है।

3.2. फिर भी क्यों चुना जाता है

कारण सरल है: यह डिफ़ॉल्ट है, और access-denied कभी नहीं आता। sc.exe create पर obj= छोड़ने का डिफ़ॉल्ट LocalSystem है,⁴ और कई पुराने नमूना-कोड व इंस्टॉलर टेम्प्लेट अभी भी LocalSystem मानते हैं। विकास में विशेषाधिकार त्रुटियों से मुक्त रहने के कारण “चल गया, तो छोड़ दो” का बड़े पैमाने पर उत्पादन करने वाला ढाँचा मौजूद है। Microsoft का अपना दस्तावेज़ भी कहता है कि अधिकांश सेवाओं को इतने ऊँचे विशेषाधिकार स्तर की आवश्यकता नहीं, और यदि नहीं चाहिए तो LocalService या NetworkService सोचें।³

flowchart TB
    accTitle: वह ढाँचा जो LocalSystem चुनता रहता है
    accDescr: sc.exe create का डिफ़ॉल्ट LocalSystem है, और पुराने नमूने व टेम्प्लेट भी LocalSystem मानते हैं, इसलिए विकास में access-denied नहीं आता और चल गया तो छोड़ दो वाली विन्यास बड़े पैमाने पर बनती है
    def["sc.exe create का डिफ़ॉल्ट"] --> lsys["LocalSystem के रूप में बना"]
    old["पुराने नमूने और टेम्प्लेट"] --> lsys
    lsys --> noerr["विकास में कोई access-denied नहीं"]
    noerr --> asis["चल गया, तो छोड़ दो"]
    asis --> mass["अत्यधिक विशेषाधिकार वाली सेवाएँ बड़े पैमाने पर बनती हैं"]

चित्र 4: डिफ़ॉल्ट और “कोई access-denied नहीं” वाला विकास अनुभव LocalSystem पर जमी सेवाएँ बड़े पैमाने पर बनाता है।

3.3. TrustedInstaller से अंतर — LocalSystem भी असीमित नहीं

LocalSystem को “Windows का सबसे मजबूत खाता” कहना सटीक नहीं। Windows Vista से Windows Resource Protection (WRP) महत्वपूर्ण OS सिस्टम फ़ाइलें, फ़ोल्डर और रजिस्ट्री कुंजियों में बदलाव केवल TrustedInstaller (Windows Modules Installer सेवा) को अनुमति देता है, और SYSTEM या प्रशासक को भी पुनर्लेखन पर access denied मिलता है।¹² Explorer का “आपको TrustedInstaller से अनुमति चाहिए” यही तंत्र है। उलटा कहें तो LocalSystem WRP-सुरक्षित क्षेत्र के बाहर लगभग सब कुछ तक पहुँच सकता है, और व्यावसायिक सेवा को वह देने का आमतौर पर कोई कारण नहीं।

flowchart TB
    accTitle: WRP-सुरक्षित क्षेत्र और TrustedInstaller का संबंध
    accDescr: WRP द्वारा सुरक्षित महत्वपूर्ण सिस्टम फ़ाइलों और रजिस्ट्री कुंजियों में बदलाव केवल TrustedInstaller को अनुमति है, और SYSTEM या प्रशासक को भी access denied मिलता है
    ti["TrustedInstaller"] -->|बदल सकता है| wrp["WRP-सुरक्षित सिस्टम फ़ाइलें आदि"]
    sysadm["SYSTEM और प्रशासक"] -->|Access denied| wrp
    sysadm -->|लगभग सब अनुमति| other["WRP-सुरक्षित क्षेत्र के बाहर"]

चित्र 5: LocalSystem भी असीमित नहीं; WRP-सुरक्षित क्षेत्र में बदलाव केवल TrustedInstaller को अनुमति है।

3.4. वे मामले जहाँ LocalSystem उचित है

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

4. LocalService और NetworkService — न्यूनतम विशेषाधिकार वाले built-in खाते

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) और NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) कम-विशेषाधिकार सेवाओं के लिए तैयार built-in खाते हैं। दोनों स्थानीय रूप से केवल न्यूनतम विशेषाधिकार रखते हैं, और Users समूह के सदस्य से अधिक कुछ नहीं कर सकते।⁵¹

दोनों का अंतर एक बिंदु है: नेटवर्क के दूर पक्ष से वे कौन दिखते हैं।⁵

• LocalService: दूर पक्ष से अनाम साख से जुड़ता है। प्रमाणीकरण चाहिए वाले संसाधन तक नहीं पहुँच सकता।
• NetworkService: दूर पक्ष को कंप्यूटर की साख प्रस्तुत करता है (डोमेन वातावरण में DOMAIN\कंप्यूटर-नाम$)।

विभाजन यह है: LocalService यदि “नेटवर्क पर नहीं जाता, या जाता है तो पहचान नहीं चाहिए”, और NetworkService यदि “मशीन की पहचान से डोमेन के भीतर संसाधन तक पहुँच चाहिए”।

flowchart TB
    accTitle: LocalService और NetworkService का अंतर
    accDescr: स्थानीय विशेषाधिकार दोनों के लिए न्यूनतम हैं, पर दूर पक्ष पर LocalService अनाम साख से जुड़ता है और NetworkService कंप्यूटर की साख प्रस्तुत करता है
    ls["LocalService"] --> anon["अनाम साख से जुड़ता है"]
    anon -.-> ng["प्रमाणीकरण चाहिए वाला संसाधन असंभव"]
    ns["NetworkService"] --> comp["कंप्यूटर की साख प्रस्तुत करता है"]
    comp -.-> pc["डोमेन वातावरण में PC$ दिखता है"]

चित्र 6: स्थानीय विशेषाधिकार समान न्यूनतम हैं, पर नेटवर्क के दूर पक्ष से दिखने वाली पहचान अनाम या कंप्यूटर खाते में बँटती है।

आधुनिक दृष्टि से दोनों की कमजोरी है। एक ही खाता कई सेवाओं से साझा है। यदि पाँच सेवाएँ LocalService से चलें, तो जब तक ACL प्रति-खाता है, पाँचों एक-दूसरे के संसाधन तक पहुँच सकती हैं। SQL Server उसी कारण Local Service खाते का समर्थन नहीं करता: यह साझा खाता है और अन्य सेवाओं से अलग नहीं हो सकता।¹

flowchart TB
    accTitle: साझा खाता अलग नहीं हो सकता
    accDescr: यदि कई सेवाएँ एक ही LocalService साझा करें, तो जब तक ACL प्रति-खाता है वे एक-दूसरे के संसाधन तक पहुँच सकती हैं
    sva["सेवा A"] --> acct["एक ही LocalService"]
    svb["सेवा B"] --> acct
    svc["सेवा C"] --> acct
    acct --> mutual["एक-दूसरे के संसाधन तक पहुँच"]
    mutual -.-> reason["क्योंकि ACL प्रति-खाता है"]

चित्र 7: एक ही खाता साझा करने वाली सेवाएँ ACL से एक-दूसरे के संसाधन से अलग नहीं हो सकतीं।

“कम-विशेषाधिकार रहें, पर प्रति सेवा अलग करें” का समाधान अगला विषय है, वर्चुअल खाता।

5. वर्चुअल खाते (NT SERVICE\<सेवा-नाम>) — आधुनिक डिफ़ॉल्ट

5.1. बिना पासवर्ड प्रति-सेवा पहचान

वर्चुअल खाता Windows Server 2008 R2 / Windows 7 से उपलब्ध “प्रबंधित स्थानीय खाता” है। तीन विशेषताएँ हैं।⁶

• खाता स्वतः प्रबंधित है; बनाना या पासवर्ड सेट करना नहीं चाहिए
• नाम NT SERVICE\<सेवा-नाम> है, और प्रत्येक सेवा के लिए अनोखी पहचान बनता है
• डोमेन वातावरण में कंप्यूटर खाते की साख (DOMAIN\कंप्यूटर-नाम$) से नेटवर्क तक पहुँच सकता है

अर्थात् LocalService/NetworkService का “कोई पासवर्ड प्रबंधन नहीं” गुण रखता है और “खाता साझा होने से अलग नहीं हो सकता” दोष हटाता है। यही कारण है कि SQL Server सेटअप NT SERVICE\MSSQLSERVER जैसे वर्चुअल खाते को डिफ़ॉल्ट रखता है।¹

flowchart TB
    accTitle: वर्चुअल खाता क्या संगत बनाता है
    accDescr: वर्चुअल खाता LocalService और NetworkService का कोई-पासवर्ड-प्रबंधन गुण रखता है, साझा-होने-से-अलग-नहीं दोष हटाता है, और प्रत्येक सेवा की अनोखी पहचान रखता है
    merit["गुण (कोई पासवर्ड प्रबंधन नहीं)"] -->|रखें| va["वर्चुअल खाता"]
    demerit["दोष (साझा होने से अलग नहीं)"] -->|हटाएँ| va
    va --> ident["प्रत्येक सेवा की अनोखी पहचान"]
    va --> auto["बनाना या पासवर्ड सेट करना नहीं चाहिए"]

चित्र 8: वर्चुअल खाता built-in खातों के गुण रखता है और केवल साझा-होने-से-अलग-नहीं दोष हटाता है।

5.2. ACL पर “NT SERVICE\सेवा-नाम” सीधे लिखें

व्यावहारिक सुविधा यह है कि आप केवल उस सेवा को नाम से ACL में जोड़ सकते हैं। “केवल यही सेवा इस डेटा फ़ोल्डर में लिख सकती है” बिना समूह बनाए और बिना पासवर्ड प्रबंधित किए संभव है।

# सेवा का लॉगऑन खाता वर्चुअल खाते में बदलें
# obj= का मान "NT SERVICE\सेवा-नाम" है। पासवर्ड न दें
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# विन्यास पुष्टि करें (SERVICE_START_NAME जाँचें)
sc.exe qc MyAppService

# केवल इसी सेवा को डेटा फ़ोल्डर पर modify अधिकार दें
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

GUI में, services.msc में सेवा के गुण → “Log On” टैब → “This account” में NT SERVICE\सेवा-नाम दर्ज करें, और पासवर्ड फ़ील्ड खाली छोड़ें (वर्चुअल खाते या MSA के लिए पासवर्ड न देना SCM की विशिष्टता है)। बदलाव के बाद सेवा पुनरारंभ लागू करता है।

5.3. बाधा — मशीन के बाहर वह “वही सेवा” नहीं

वर्चुअल खाते की पहचान मशीन-स्थानीय है और डोमेन से पहचानी नहीं जाती। नेटवर्क पर वह बाद में वर्णित कंप्यूटर खाते में सिमटती है, इसलिए दूर पक्ष “कौन सी सेवा है” नहीं बता सकता, और कई सर्वरों पर वही पहचान साझा भी नहीं कर सकते।¹⁰

flowchart TB
    accTitle: वर्चुअल खाते की पहचान मशीन के बाहर सिमटती है
    accDescr: मशीन के भीतर प्रति सेवा अनोखा वर्चुअल खाता नेटवर्क पर कंप्यूटर खाते में सिमटता है, और दूर पक्ष कौन सी सेवा है नहीं बता सकता
    vaa["वर्चुअल खाता A"] --> pc["कंप्यूटर खाता PC$"]
    vab["वर्चुअल खाता B"] --> pc
    pc --> remote["दूर पक्ष को दिखने वाली पहचान"]
    remote -.-> nodist["कौन सी सेवा है नहीं बता सकते"]

चित्र 9: मशीन के भीतर अनोखी पहचान होने पर भी नेटवर्क के दूर पक्ष हर सेवा एक ही PC$ दिखती है।

जब यह बाधा — नेटवर्क के दूर पक्ष पर सेवा-विशिष्ट पहचान चाहिए, कई सर्वरों पर वही पहचान चाहिए — समस्या बने, तब gMSA (अध्याय 8) बुलाया जाता है।

6. नेटवर्क पर जाने पर पहचान — कंप्यूटर खाते (PC$) का अभ्यास

6.1. “सेवा साझा फ़ोल्डर तक नहीं पहुँच सकती” गलतफहमी है

डोमेन-जुड़ी मशीन पर, जब LocalSystem, NetworkService या वर्चुअल खाते से चलने वाली सेवा दूर संसाधन तक पहुँचती है, वह कंप्यूटर खाते (DOMAIN\कंप्यूटर-नाम$) के रूप में प्रमाणित होती है।³⁶ आरंभ की कई परामर्श “साझा फ़ोल्डर तक नहीं पहुँची, इसलिए डोमेन उपयोगकर्ता बना दिया” वास्तव में इससे हल होती हैं। गंतव्य ACL बस PC$ अनुमति नहीं दे रही थी।

flowchart TB
    accTitle: कंप्यूटर खाते के रूप में दूर पहुँच
    accDescr: डोमेन-जुड़ी मशीन पर LocalSystem, NetworkService या वर्चुअल-खाता सेवा दूर पक्ष पर कंप्यूटर खाते के रूप में प्रमाणित होती है, और यदि गंतव्य ACL PC$ अनुमति दे तो पहुँच सकती है
    svc["सेवा (LocalSystem, वर्चुअल खाता आदि)"] --> auth["PC$ के रूप में प्रमाणित"]
    auth --> acl{"गंतव्य ACL PC$ अनुमति देती है?"}
    acl -->|हाँ| ok["साझा फ़ोल्डर या DB तक पहुँच सफल"]
    acl -->|नहीं| ng["पहुँच अस्वीकृत"]

चित्र 10: डोमेन वातावरण में गंतव्य ACL पर केवल PC$ देना डोमेन उपयोगकर्ता के बिना दूर पहुँच स्थापित कर देता है।

फ़ाइल-सर्वर पक्ष पर देना सामान्य ACL संचालन जैसा है; खाता नाम के रूप में कंप्यूटर-नाम$ दें (GUI ऑब्जेक्ट-पिकर में ऑब्जेक्ट प्रकार में “Computers” शामिल करें)।

# फ़ाइल-सर्वर पक्ष: APPSV01 पर सेवा को साझा फ़ोल्डर पर modify अधिकार दें
# साझा अनुमति और NTFS अनुमति दोनों दें
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server भी वही: कंप्यूटर खाता लॉगिन के रूप में बनाएँ और कनेक्शन स्ट्रिंग Integrated Security=true से बिना पासवर्ड चलती है।

-- DB-सर्वर पक्ष: APPSV01 पर सेवा से Windows एकीकृत प्रमाणीकरण अनुमति दें
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. PC$ दृष्टिकोण की सीमाएँ जानें

इस दृष्टिकोण की दो सीमाएँ हैं।

1. दानेदारी प्रति मशीन है। उसी मशीन पर चलने वाली LocalSystem, NetworkService और हर वर्चुअल-खाता सेवा दूर पक्ष से एक ही PC$ दिखती हैं। गंतव्य पर “केवल यही सेवा अनुमति” नहीं दे सकते, और कौन सी सेवा ने वह खाता इस्तेमाल किया ऑडिट भी नहीं कर सकते।²
2. वर्कग्रुप वातावरण में इस्तेमाल नहीं हो सकता। कंप्यूटर खाता Active Directory ऑब्जेक्ट है, इसलिए डोमेन-न जुड़ी मशीन के पास नहीं होता। गंतव्य खाते की साख स्पष्ट रूप से संभालने वाला डिज़ाइन चाहिए।

जब सीमा 1 से आगे जाना हो, 2026 का उत्तर अगले अध्याय का डोमेन उपयोगकर्ता नहीं… बल्कि उस समस्या को छोड़कर gMSA पर जाना है।

flowchart TB
    accTitle: PC$ दृष्टिकोण की दो सीमाएँ
    accDescr: PC$ के रूप में प्रमाणीकरण की दानेदारी मशीन-स्तरीय है इसलिए प्रति-सेवा अनुमति या ऑडिट नहीं, और वर्कग्रुप में कंप्यूटर खाता स्वयं नहीं है इसलिए इस्तेमाल नहीं
    pcs["PC$ दृष्टिकोण"] --> lim1["सीमा 1: प्रति मशीन"]
    pcs --> lim2["सीमा 2: कोई वर्कग्रुप नहीं"]
    lim1 -.-> noaudit["कोई प्रति-सेवा अनुमति या ऑडिट नहीं"]
    lim2 -.-> nocred["स्पष्ट साख इस्तेमाल करें"]
    lim1 --> gmsa["इससे आगे: gMSA"]

चित्र 11: मशीन-स्तरीय दानेदारी और डोमेन पूर्वापेक्षा की दो सीमाओं से आगे जाना हो तो डोमेन उपयोगकर्ता छोड़कर gMSA पर जाएँ।

7. सेवा के लिए डोमेन उपयोगकर्ता इस्तेमाल करने की समस्या

7.1. पासवर्ड की संरचनात्मक समस्या

यदि सेवा को डोमेन उपयोगकर्ता (या स्थानीय उपयोगकर्ता) दें, SCM वह पासवर्ड संग्रहीत करता है और हर स्टार्ट पर लॉगऑन के लिए इस्तेमाल करता है। SCM समाप्ति प्रबंधित नहीं करता, इसलिए पासवर्ड खत्म होने पर लॉगऑन विफल होता है और सेवा स्टार्ट नहीं होगी।⁷

वहाँ से मैदान में अक्सर दिखने वाला नकारात्मक चक्र शुरू होता है।

1. समाप्ति से सेवा रुकने की दुर्घटना होती है
2. पुनरावृत्ति रोकने के लिए “पासवर्ड कभी न खत्म” सेट होता है
3. बदलाव प्रक्रिया कभी स्थापित नहीं होती, और वही पासवर्ड कई सर्वरों की रनबुक, स्क्रिप्ट और Task Scheduler में सादे पाठ में लिखा जाता है
4. कोई जाने पर भी पासवर्ड नहीं बदलता (बदलें तो नहीं पता क्या रुकेगा)

flowchart TB
    accTitle: डोमेन उपयोगकर्ता से संचालन का नकारात्मक चक्र
    accDescr: पासवर्ड खत्म होता है और सेवा रुकती है, पुनरावृत्ति रोकने के लिए कभी-न-खत्म सेट होता है, सादा-पाठ पासवर्ड रनबुक व स्क्रिप्ट में फैलता है, और कोई जाने पर भी नहीं बदल सकता
    expire["1. समाप्ति सेवा रोकती है"] --> forever["2. रोकथाम के लिए कभी-न-खत्म सेट"]
    forever --> spread["3. सादा-पाठ पासवर्ड फैलता है"]
    spread -.-> where["रनबुक, स्क्रिप्ट, कार्य"]
    spread --> stuck["4. कोई जाने पर भी नहीं बदल सकता"]

चित्र 12: समाप्ति दुर्घटना से शुरू होकर कभी-न-खत्म और सादा-पाठ पासवर्ड का फैलाव स्थिर हो जाता है।

Microsoft यह भी बताता है कि सेवा के लिए डोमेन खाता इस्तेमाल करने वाली विन्यास पासवर्ड और SPN के मैनुअल प्रबंधन में काफी परिचालन प्रयास लेती है, और रखरखाव सेवा रोक तक ले जा सकता है।¹

7.2. Kerberoasting — सेवा खाता निशाना बनता है

डोमेन-उपयोगकर्ता सेवा खाते पर विशिष्ट दूसरा हमला Kerberoasting है। Kerberos प्रमाणीकरण लेने वाली सेवा लॉगऑन खाते पर SPN (service principal name) पंजीकृत करती है। डोमेन में कोई भी प्रमाणित उपयोगकर्ता SPN-पंजीकृत खाते को सेवा टिकट माँग सकता है, इसलिए हमलावर टिकट पाता है और पासवर्ड का ऑफ़लाइन brute-force करता है। मनुष्य-निर्धारित 10-से-16-अक्षर पासवर्ड यह हमला नहीं सहेगा।

flowchart TB
    accTitle: Kerberoasting का प्रवाह
    accDescr: SPN-पंजीकृत सेवा खाते को सेवा टिकट कोई भी प्रमाणित उपयोगकर्ता माँग सकता है, इसलिए हमलावर टिकट पाता है और पासवर्ड का ऑफ़लाइन brute-force करता है
    atk["डोमेन में प्रमाणित उपयोगकर्ता"] --> req["SPN के लिए टिकट माँगें"]
    req --> tkt["सेवा टिकट पाएँ"]
    tkt --> brute["ऑफ़लाइन brute-force"]
    brute --> weak["लगभग 10 से 16 अक्षर टूट जाएँगे"]

चित्र 13: कोई भी प्रमाणित उपयोगकर्ता टिकट माँग सकता है, और मनुष्य-निर्धारित लंबाई का पासवर्ड ऑफ़लाइन brute-force नहीं सहेगा।

प्रभावी उत्तर है पासवर्ड ऐसी शक्ति का बनाएँ जिसे मनुष्य अनुमान या तोड़ न सके। Microsoft लंबा पासवर्ड बाध्य करना, और gMSA इस्तेमाल करना भी सूचीबद्ध करता है जिसका पासवर्ड लंबा मशीन-जनित यादृच्छिक मान बनता है।⁸ वही दस्तावेज़ Kerberos armoring (FAST) भी उल्लेख करता है, पर FAST पूर्व-प्रमाणीकरण डेटा और KDC स्पूफिंग प्रतिरोध की रक्षा करता है; वह प्रमाणित उपयोगकर्ता को SPN पर सेवा टिकट माँगने से नहीं रोकता, इसलिए सेवा खाते की पासवर्ड शक्ति का विकल्प नहीं। SPN और Kerberos का संबंध, और वे शर्तें जब प्रमाणीकरण NTLM पर गिरता है, “आरेखों से NTLM और Kerberos” में हैं।

7.3. यदि फिर भी डोमेन उपयोगकर्ता इस्तेमाल करें

यदि ऐप gMSA समर्थन न करने जैसे कारणों से डोमेन उपयोगकर्ता ही इस्तेमाल करना पड़े, निम्न को न्यूनतम शमन मानें।

• पासवर्ड यादृच्छिक 25 अक्षर या अधिक बनाएँ, और पासवर्ड-प्रबंधन उपकरण के अलावा कहीं न लिखें (रनबुक, स्क्रिप्ट, साझा Excel)
• सेवा-समर्पित खाता बनाएँ और प्रति सेवा बाँटें (मानव खाते से साझा न करें²)
• इंटरैक्टिव लॉगऑन और Remote Desktop अस्वीकार करें, और केवल “Log on as a service” अनुमति दें
• सदस्यता समूह न्यूनतम रखें (Domain Admins में जोड़ना प्रश्न से बाहर)
• आवधिक-घुमाव प्रक्रिया स्थापित करें और बदलाव से प्रभावित स्थान बही में डालें

यह सब करना gMSA पर माइग्रेट करने से कम सुरक्षित और कम आसान है — वह अगला अध्याय है।

8. gMSA — पासवर्ड प्रबंधन Active Directory को सौंपना

8.1. तंत्र और प्रभाव

gMSA (group Managed Service Account) वह डोमेन खाता है जो पासवर्ड प्रबंधन डोमेन नियंत्रक को सौंपता है। पासवर्ड डोमेन नियंत्रक KDS (Key Distribution Service) रूट कुंजी से गणना करता है, और केवल अनुमति प्राप्त होस्ट उसे पाते हैं।¹³

flowchart TB
    accTitle: gMSA पासवर्ड कैसे प्रबंधित करता है
    accDescr: डोमेन नियंत्रक KDS रूट कुंजी से पासवर्ड गणना करता है, केवल अनुमति प्राप्त होस्ट उसे पाते हैं और सेवा चलाने में इस्तेमाल करते हैं, और पासवर्ड डिफ़ॉल्ट से हर 30 दिन स्वतः घूमता है
    kds["KDS रूट कुंजी"] --> dc["DC पासवर्ड गणना करता है"]
    dc --> host["अनुमति प्राप्त होस्ट पाता है"]
    host --> svc["सेवा चलाने में इस्तेमाल"]
    dc -.-> rot["डिफ़ॉल्ट से हर 30 दिन स्वतः घुमाव"]

चित्र 14: डोमेन नियंत्रक पासवर्ड बनाना, वितरित करना और अद्यतन करना ले लेता है, और मनुष्य पासवर्ड जाने बिना संचालन कर सकते हैं।

प्रभाव स्पष्ट हैं।⁹

• 240-बाइट यादृच्छिक जनित पासवर्ड: brute-force और शब्दकोश हमले अवास्तविक हो जाते हैं, और Kerberoasting प्रतिरोध काफी बढ़ता है
• डिफ़ॉल्ट से हर 30 दिन स्वतः घुमाव: मनुष्य को बदलाव योजना नहीं करनी, और सेवा रोकनी नहीं
• कई सर्वरों पर वही पहचान साझा हो सकती है: लोड संतुलन के तहत सर्वर फ़ार्म एक ही principal के रूप में परस्पर प्रमाणित हो सकते हैं
• सरल SPN प्रबंधन: SPN पंजीकरण और प्रबंधन भी सौंपा और सरल किया जा सकता है

मनुष्य पासवर्ड जाने बिना संचालन कर सकते हैं — यदि इसे वह तंत्र समझें जो सेवा खाते के लिए वही करता है जो Windows LAPS स्थानीय प्रशासक पासवर्ड के लिए करता है, स्थान पकड़ना आसान है।

8.2. आवश्यकताएँ

gMSA की पूर्वापेक्षाएँ हैं।¹⁰

• Active Directory डोमेन वातावरण (वर्कग्रुप में असंभव)
• डोमेन और फ़ॉरेस्ट कार्यात्मक स्तर Windows Server 2012 या अधिक
• KDS रूट कुंजी पहले से बनी हो
• gMSA नाम फ़ॉरेस्ट में अनोखा हो, केवल डोमेन में नहीं
• पासवर्ड-बदलाव अंतराल केवल निर्माण समय पर सेट हो सकता है

KDS रूट कुंजी बनाना एक बार का काम है, पर निर्माण के बाद 10 घंटे तक gMSA नहीं बना सकते, क्योंकि हर डोमेन नियंत्रक तक replication की प्रतीक्षा है। यह सुरक्षा उपकरण है ताकि replication पूरा होने से पहले पासवर्ड प्राप्ति विफल न हो।¹⁴

flowchart TB
    accTitle: KDS रूट कुंजी बनाने से gMSA बनाने तक
    accDescr: KDS रूट कुंजी बनने के बाद हर डोमेन नियंत्रक तक replication की प्रतीक्षा है, इसलिए 10 घंटे तक gMSA नहीं बना सकते; replication पूरा होने पर बना सकते हैं
    add["KDS रूट कुंजी बनाएँ"] --> wait["Replication की 10 घंटे तक प्रतीक्षा"]
    wait -.-> why["प्राप्ति-विफलता दुर्घटना रोकने का सुरक्षा उपकरण"]
    wait --> done["हर DC तक replication पूरा"]
    done --> ok["gMSA बना सकते हैं"]

चित्र 15: रूट कुंजी बनाने के बाद 10 घंटे तक प्रतीक्षा replication अधूरे रहते प्राप्ति विफलता रोकने का समय है।

# डोमेन प्रशासक के रूप में चलाएँ, डोमेन नियंत्रक पर (या AD PowerShell
# मॉड्यूल वाले प्रशासनिक वर्कस्टेशन पर)

# पुष्टि करें कि KDS रूट कुंजी है या नहीं, नहीं तो बनाएँ (प्रति फ़ॉरेस्ट एक बार)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # वास्तव में 10 घंटे बाद उपयोग योग्य

8.3. निर्माण से विन्यास तक प्रक्रिया

प्रक्रिया चार चरण हैं: “① प्राप्ति-अनुमत समूह बनाएँ → ② gMSA बनाएँ → ③ सर्वरों पर स्थापित करें → ④ सेवा पर सेट करें”।¹⁰

flowchart TB
    accTitle: gMSA लाने के चार चरण
    accDescr: चार चरणों में लाएँ: पासवर्ड प्राप्ति-अनुमत समूह बनाना, gMSA बनाना, प्रत्येक सर्वर पर स्थापित करना, और सेवा के लॉगऑन खाते के रूप में सेट करना
    st1["① प्राप्ति-अनुमत समूह बनाएँ"] --> st2["② gMSA बनाएँ"]
    st1 -.-> add["सर्वरों के PC$ जोड़ें"]
    st2 --> st3["③ प्रत्येक सर्वर पर स्थापित करें"]
    st3 -.-> test["Test कमांड से प्राप्ति सत्यापित करें"]
    st3 --> st4["④ सेवा पर सेट करें"]

चित्र 16: समूह बनाने से सेवा सेट करने तक gMSA लाना चार चरणों में चलता है।

# ① पासवर्ड प्राप्ति-अनुमत सुरक्षा समूह बनाएँ,
#    और सेवा चलाने वाले सर्वरों के कंप्यूटर खाते जोड़ें
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# समूह सदस्यता कंप्यूटर लॉगऑन पर मूल्यांकित होती है, इसलिए
# जोड़ने के बाद लक्ष्य सर्वर पुनरारंभ विश्वसनीय तरीका है

# ② gMSA बनाएँ
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ सेवा चलाने वाले प्रत्येक सर्वर पर gMSA स्थापित करें और सत्यापित करें
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True का अर्थ प्राप्ति काम कर रही है

# ④ सेवा के लॉगऑन खाते के रूप में सेट करें। नाम के अंत में $ लगाएँ, पासवर्ड न दें
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

services.msc से सेट करते समय भी खाता नाम CORP\svc-batch$ जैसा है — अंत में $ लगाएँ, और पासवर्ड फ़ील्ड खाली छोड़ें। MSA-परिवार खाता इंटरैक्टिव साइन-इन के लिए इस्तेमाल नहीं हो सकता।¹ उसके बाद साझा फ़ोल्डर या SQL Server की ACL पर PC$ की जगह CORP\svc-batch$ दें, और सेवा-विशिष्ट पहचान से नेटवर्क पहुँच पासवर्डरहित पूरी हो जाती है।

8.4. कुछ ऐप समर्थन नहीं करते

चेतावनी के रूप में, हर सॉफ़्टवेयर gMSA से नहीं चलेगा। मानक तंत्र से लॉगऑन पहचान विन्यासित करने वाली चीज़ें — Windows सेवा, IIS ऐप पूल, Task Scheduler कार्य — व्यापक रूप से समर्थित हैं, पर बाधाएँ हैं जैसे failover clustering स्वयं gMSA समर्थन नहीं करता, और वह ऐप जिसके आंतरिक पासवर्ड माँगते हैं इस्तेमाल नहीं कर सकता।¹⁰ Microsoft साफ़ कहता है कि उत्पादन से पहले परीक्षण वातावरण में gMSA के रूप में व्यवहार पुष्टि करें।⁹

flowchart TB
    accTitle: gMSA समर्थन कैसे बताएँ
    accDescr: मानक तंत्र से लॉगऑन पहचान विन्यासित करने वाला ऐप gMSA व्यापक रूप से समर्थन करता है, पर failover clustering और आंतरिक रूप से पासवर्ड माँगने वाला ऐप नहीं कर सकता, इसलिए उत्पादन से पहले परीक्षण वातावरण में पुष्टि करें
    app["लक्ष्य ऐप"] --> how{"लॉगऑन कैसे सेट है?"}
    how -->|मानक तंत्र| okapp["gMSA समर्थित"]
    okapp -.-> ex1["सेवा, IIS, कार्य"]
    how -->|पासवर्ड माँगा| ngapp["gMSA असंभव"]
    ngapp -.-> ex2["Failover clustering"]
    okapp --> test["उत्पादन से पहले परीक्षण"]

चित्र 17: मानक तंत्र से लॉगऑन विन्यासित करने वाला ऐप व्यापक रूप से समर्थित है, पर कुछ डिज़ाइन असमर्थित हैं, इसलिए उत्पादन से पहले सत्यापन अपरिहार्य है।

भाई-बहन भी हैं: एकल सर्वर के लिए sMSA (standalone Managed Service Account), और dMSA (delegated Managed Service Account, Windows Server 2025 में आया, जो साख चोरी रोकने के लिए डिवाइस पहचान से बँधता है)। नई निर्माण के लिए gMSA आधार लें और आवश्यकताओं के अनुसार सोचें।⁶

9. साथ का डिज़ाइन — लॉगऑन अधिकार, प्रोफ़ाइल, DPAPI और ऑडिटिंग

खाते के साथ बदलने वाली चार और बातें, याद रखने के लिए।

9.1. “Log on as a service” अधिकार (SeServiceLogonRight)

सेवा के रूप में स्टार्ट करने के लिए खाते को “Log on as a service” उपयोगकर्ता अधिकार चाहिए। LocalSystem, LocalService और NetworkService में यह built-in है, पर कोई अन्य खाता (डोमेन उपयोगकर्ता, gMSA आदि) स्पष्ट असाइनमेंट चाहता है।¹⁵

यदि services.msc GUI के “Log On” टैब से सेट करें, स्नैप-इन यह अधिकार स्वतः देता है। दूसरी ओर, CreateService / ChangeServiceConfig (sc.exe config द्वारा बुलाए गए API) यह सत्यापित नहीं करते कि निर्दिष्ट खाते के पास यह अधिकार है। स्क्रिप्ट से विन्यासित सेवा का “लॉगऑन विफलता के कारण सेवा स्टार्ट नहीं हुई” पर रुकना इसी का विशिष्ट कारण है। उपकरण के पार्श्व प्रभाव पर भरोसा न करें; परिनियोजन प्रक्रिया में स्पष्ट रूप से Local Security Policy (secpol.msc) में “Log on as a service” जोड़ना, या GPO/Intune से विन्यास शामिल करें (जिस वातावरण में यह अधिकार Group Policy से विन्यासित है, नीति लागू होने पर स्थानीय अनुदान अधिलेखित होता है, इसलिए वह भी ध्यान योग्य है)। उलटा, सेवा-समर्पित खाते का मानक कदम साथ में “Deny log on locally” सेट करना है।

flowchart TB
    accTitle: Log on as a service अधिकार के विन्यास पथ का अंतर
    accDescr: services.msc GUI अधिकार स्वतः देता है, पर sc.exe config द्वारा बुलाया API अधिकार सत्यापित नहीं करता, इसलिए बिना अधिकार वाले खाते से सेवा स्टार्ट पर लॉगऑन विफलता से रुकती है
    gui["services.msc में सेट"] --> auto["अधिकार स्वतः दिया जाता है"]
    auto --> okgui["सेवा स्टार्ट हो सकती है"]
    cli["sc.exe config से सेट"] --> noval["अधिकार सत्यापित नहीं"]
    noval --> has{"अधिकार है?"}
    has -->|हाँ| okcli["सेवा स्टार्ट हो सकती है"]
    has -->|नहीं| stop["लॉगऑन विफलता से रुकती है"]
    stop -.-> fix["secpol.msc या GPO से स्पष्ट दें"]

चित्र 18: GUI अधिकार स्वतः देता है, पर स्क्रिप्टेड विन्यास सत्यापित नहीं करता, इसलिए प्रक्रिया में स्पष्ट अनुदान शामिल करें।

9.2. प्रोफ़ाइल, %TEMP% और HKEY_CURRENT_USER बदलते हैं

SCM सेवा स्टार्ट पर उस खाते की उपयोगकर्ता प्रोफ़ाइल लोड करता है।⁷ अतः वास्तविक %TEMP%, %APPDATA% और HKEY_CURRENT_USER प्रत्येक लॉगऑन खाते पर अलग चीज़ हैं, और खाता बदलने पर पुराने खाते की प्रोफ़ाइल में सहेजी सेटिंग्स और कैश ऐसे लगते हैं मानो “गायब” हो गए।

डिज़ाइन उत्तर सरल है: सेवा का डेटा प्रोफ़ाइल के नीचे नहीं, बल्कि C:\ProgramData\<ऐप-नाम> जैसे स्पष्ट पथ पर रखें, और वह ACL लॉगऑन खाते को दें। इस तरह खाता बदलाव डेटा माइग्रेशन साथ नहीं लाता।

flowchart TB
    accTitle: प्रोफ़ाइल निर्भरता और डेटा स्थान का उत्तर
    accDescr: वास्तविक प्रोफ़ाइल प्रत्येक लॉगऑन खाते पर अलग है, इसलिए खाता बदलने से पुरानी प्रोफ़ाइल का डेटा गायब लगता है, पर स्पष्ट पथ पर रखना और ACL देना माइग्रेशन अनावश्यक बनाता है
    sw["लॉगऑन खाता बदलना"] --> newprof["अलग प्रोफ़ाइल लोड होती है"]
    newprof --> lost["पुराना डेटा गायब लगता है"]
    lost -.->|उत्तर| fix["ProgramData के नीचे रखें"]
    fix --> acl["लॉगऑन खाते को ACL दें"]
    acl --> nomig["खाता बदलने पर भी कोई माइग्रेशन नहीं"]

चित्र 19: प्रोफ़ाइल से बचें और डेटा स्पष्ट पथ पर रखें, तो खाता बदलाव डेटा माइग्रेशन साथ नहीं लाता।

9.3. DPAPI से सुरक्षित डेटा खाते से बँधा है

और भी आसानी से छूटने वाला DPAPI है। उपयोगकर्ता-दायरे DPAPI (CryptProtectData या .NET का ProtectedData) से एन्क्रिप्ट डेटा सिद्धांततः उसी खाते से ही डिक्रिप्ट होता है जिसने सुरक्षित किया। खाता बदलते ही संग्रहीत कनेक्शन स्ट्रिंग या API कुंजी नहीं पढ़ी जा सकती — वह DPAPI का सही काम है, पर यदि माइग्रेशन प्रक्रिया में नहीं है तो घटना बन जाती है।

flowchart TB
    accTitle: DPAPI-सुरक्षित डेटा और खाता बदलाव का संबंध
    accDescr: उपयोगकर्ता-दायरे DPAPI से सुरक्षित डेटा उसी खाते से ही डिक्रिप्ट होता है जिसने सुरक्षित किया, इसलिए लॉगऑन खाता बदलने के बाद रहस्य फिर दर्ज करने पड़ते हैं
    protect["पुराने खाते से DPAPI-सुरक्षित करें"] --> data["सुरक्षित कनेक्शन स्ट्रिंग आदि"]
    data --> who{"कौन सा खाता डिक्रिप्ट कर रहा है?"}
    who -->|वही पुराना खाता| okdec["डिक्रिप्ट हो सकता है"]
    who -->|नया खाता| ngdec["डिक्रिप्ट नहीं हो सकता"]
    ngdec --> re["रहस्य फिर दर्ज करें"]

चित्र 20: DPAPI-सुरक्षित डेटा उस खाते से बँधा है जिसने सुरक्षित किया, और खाता बदलने के बाद फिर दर्ज करना पड़ता है।

उत्तर है माइग्रेशन योजना में “खाता बदलने के बाद रहस्य फिर दर्ज करें” प्रक्रिया शामिल करना (कहाँ संग्रहीत करें के डिज़ाइन के लिए देखें “Windows ऐप्स में रहस्य संग्रहीत करना”)। साथ ही, gMSA या PC$ के रूप में Windows एकीकृत प्रमाणीकरण से पूरी हो सकने वाली विन्यास स्वयं रहस्य संग्रहीत करना समाप्त कर सकती है। सही क्रम है “क्या बिना संग्रहीत किए चल सकता है” को “कहाँ संग्रहीत करें” से पहले सोचना।

और यदि सेवा “कॉल करने वाले उपयोगकर्ता के विशेषाधिकार से” प्रसंस्करण चाहती है, खाता मजबूत करने के बजाय impersonation इस्तेमाल करें। उसके लिए देखें “Windows impersonation टोकन सही ढंग से संभालना“।

9.4. ऑडिटिंग — 4624 लॉगऑन प्रकार 5 देखें

सेवा स्टार्ट Security ईवेंट लॉग में ईवेंट ID 4624 (An account was successfully logged on) के रूप में लॉगऑन प्रकार 5 (Service: SCM ने सेवा स्टार्ट की) से दर्ज होता है। ईवेंट का “Virtual Account” फ़ील्ड बताता है कि लॉगऑन MSA / वर्चुअल खाते से था या नहीं, इसलिए प्रबंधित खातों के उपयोग पर नज़र रखने में भी काम आता है।¹¹

flowchart TB
    accTitle: सेवा स्टार्ट ऑडिट करने का प्रवाह
    accDescr: SCM का सेवा स्टार्ट ईवेंट ID 4624 लॉगऑन प्रकार 5 के रूप में दर्ज होता है, और Virtual Account फ़ील्ड पहचान सकता है कि लॉगऑन प्रबंधित खाते से था या नहीं
    start["SCM सेवा स्टार्ट करता है"] --> ev["ईवेंट ID 4624 दर्ज करें"]
    ev --> type5["लॉगऑन प्रकार 5 (Service)"]
    type5 --> vafield["Virtual Account फ़ील्ड"]
    vafield --> watch["प्रबंधित खातों पर नज़र"]

चित्र 21: सेवा स्टार्ट लॉगऑन प्रकार 5 के 4624 के रूप में दर्ज होता है, और प्रबंधित खातों का उपयोग भी ट्रैक कर सकते हैं।

वर्तमान स्थिति की सूची के लिए सेवा सूची के लॉगऑन खाते एकत्र करना तेज़ तरीका है।

# एकत्र करें कि कौन सी सेवा किस खाते से चल रही है
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# LocalSystem से चलने वाली गैर-मानक सेवाओं की सूची (पथ से आंतरिक / तृतीय-पक्ष बताएँ)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

यदि यह आउटपुट “LocalSystem से चलने वाली व्यावसायिक सेवा” और “डोमेन उपयोगकर्ता से चलने वाली सेवा” पंक्तिबद्ध करे, अगले अध्याय का निर्णय प्रवाह बुलाया जाता है।

10. निर्णय प्रवाह — चार प्रश्नों से तय करें

अब तक की सामग्री, चयन प्रक्रिया के रूप में। चार प्रश्नों का क्रम से उत्तर दें।

flowchart TB
    accTitle: लॉगऑन खाते का निर्णय प्रवाह
    accDescr: नेटवर्क पहुँच है या नहीं, डोमेन-जुड़ाव, मशीन-स्तरीय पहचान पर्याप्त है या नहीं, और gMSA समर्थन — इन चार प्रश्नों का क्रम से उत्तर देकर लॉगऑन खाता तय करें
    q1{"सहकर्मी को Win auth?"} -->|नहीं| va["वर्चुअल खाता"]
    va -.-> sys["आवश्यक हो तो LocalSystem"]
    q1 -->|हाँ| q2{"डोमेन-जुड़ा?"}
    q2 -->|नहीं| cred["संग्रहीत साख सुरक्षित करें"]
    q2 -->|हाँ| q3{"मशीन-स्तर पर्याप्त?"}
    q3 -->|हाँ| pcacl["वर्चुअल खाता + PC$"]
    q3 -->|नहीं| q4{"ऐप gMSA समर्थन करता है?"}
    q4 -->|हाँ| gmsa["gMSA"]
    q4 -->|नहीं| du["उपयोगकर्ता + शमन"]

चित्र 22: चार प्रश्नों का क्रम से उत्तर दें तो छह विकल्पों में से कौन इस्तेमाल करना चाहिए तय हो जाता है।

प्रश्न 1: क्या वह सेवा नेटवर्क पर दूसरी मशीन (साझा फ़ोल्डर, DB, API आदि) तक Windows प्रमाणीकरण से पहुँचती है?

यदि नहीं, वर्चुअल खाता डिफ़ॉल्ट है। केवल यदि विशेष स्थानीय विशेषाधिकार चाहिए, वह आवश्यकता पुष्टि करें फिर LocalSystem सोचें।

प्रश्न 2: (यदि पहुँचती है) क्या मशीन डोमेन-जुड़ी है?

वर्कग्रुप में न PC$ न gMSA इस्तेमाल हो सकते। गंतव्य खाते की साख स्पष्ट रूप से संभालने वाला डिज़ाइन इस्तेमाल करें (संग्रह DPAPI आदि से सुरक्षित करें), या डोमेन जुड़ने पर विचार करें।

प्रश्न 3: (डोमेन में) क्या मशीन-स्तरीय पहचान (PC$) पर्याप्त है?

यदि हाँ, वर्चुअल खाता (या NetworkService) + गंतव्य ACL पर PC$ देना पूरा है। यदि सेवा-विशिष्ट पहचान चाहिए, या कई सर्वरों पर साझा पहचान, प्रश्न 4 पर जाएँ।

प्रश्न 4: क्या अनुप्रयोग gMSA समर्थन करता है?

यदि हाँ (मानक तंत्र से लॉगऑन विन्यासित करने वाली चीज़ें — SCM, IIS ऐप पूल, Task Scheduler — आमतौर पर करती हैं), gMSA। सत्यापन वातावरण में व्यवहार जाँच न भूलें। यदि किसी भी तरह असमर्थित है, खंड 7.3 का हर शमन लागू करने के बाद समर्पित डोमेन उपयोगकर्ता इस्तेमाल करें।

तालिका में इस प्रकार है।

11. सारांश

• सेवा का लॉगऑन खाता वह डिज़ाइन निर्णय है जो स्थानीय विशेषाधिकार, नेटवर्क पहचान और पासवर्ड प्रबंधन एक साथ तय करता है। डिफ़ॉल्ट (LocalSystem) पर न छोड़ें।
• LocalSystem SYSTEM+Administrators टोकन और मजबूत विशेषाधिकार रखता है, और कब्जे पर क्षति अधिकतम होती है। अधिकांश व्यावसायिक सेवाओं को यह विशेषाधिकार नहीं चाहिए।
• LocalService और NetworkService दोनों कम-विशेषाधिकार हैं; अंतर नेटवर्क पहचान है (अनाम, या कंप्यूटर खाता)। पर खाता कई सेवाओं से साझा होने से अलग नहीं हो सकते।
• वर्चुअल खाता (NT SERVICE\<सेवा-नाम>) आधुनिक डिफ़ॉल्ट है जो प्रति सेवा अलग कर सकता है और पासवर्ड प्रबंधन नहीं चाहता। ACL पर सीधे लिख सकते हैं, और विन्यास केवल लॉगऑन-खाता नाम बदलना है।
• LocalSystem, NetworkService और वर्चुअल खाता डोमेन वातावरण में DOMAIN\PC$ के रूप में नेटवर्क पर जाते हैं। साझा फ़ोल्डर या SQL Server की ACL पर PC$ देना अक्सर डोमेन उपयोगकर्ता के बिना काम चला देता है।
• सेवा के लिए डोमेन उपयोगकर्ता इस्तेमाल करने में समाप्ति से रोक, सादा-पाठ पासवर्ड का फैलाव और Kerberoasting की संरचनात्मक समस्याएँ हैं। इस्तेमाल करें तो समर्पित खाता + लंबा यादृच्छिक पासवर्ड + लॉगऑन प्रतिबंध आवश्यक हैं।
• gMSA वह तंत्र है जिसमें AD पासवर्ड स्वतः बनाता और घुमाता है; आवश्यकताएँ डोमेन, कार्यात्मक स्तर 2012 या अधिक, और KDS रूट कुंजी हैं। सेवा को “DOMAIN\नाम$” पर खाली पासवर्ड फ़ील्ड से सेट करें।
• खाता बदलते समय “Log on as a service” अधिकार, प्रोफ़ाइल और %TEMP% स्थानांतरण, और DPAPI-सुरक्षित डेटा फिर दर्ज करना माइग्रेशन प्रक्रिया में शामिल करें। ऑडिटिंग ईवेंट ID 4624 लॉगऑन प्रकार 5 से पुष्टि हो सकती है।

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

संबंधित लेख

• Windows सेवाएँ बनाना और चलाना ── Task Scheduler और सेवाओं में चुनाव से BackgroundService को Windows सेवा बनाना तक
• Windows पर प्रशासक विशेषाधिकार वास्तव में कब चाहिए? - UAC, सुरक्षित क्षेत्र, और डिज़ाइन से कैसे बताएँ
• Windows impersonation टोकन सही ढंग से संभालना — प्रति थ्रेड विशेषाधिकार उधार लेना और सुरक्षित रूप से लौटाना
• आरेखों से NTLM और Kerberos — प्रमाणीकरण NTLM पर क्यों गिरता है
• Windows LAPS व्यावहारिक मार्गदर्शिका — सभी PC पर साझा स्थानीय प्रशासक पासवर्ड छोड़ना
• Windows ऐप्स में रहस्य संग्रहीत करना - DPAPI से सादा-पाठ विन्यास से बचना

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

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

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

क्या LocalSystem से चलाए जा रहे सेवा को तुरंत बदलना चाहिए?

तुरंत बदलाव हर मामले में सही उत्तर नहीं है। पहले पुष्टि करें कि उस सेवा को सचमुच LocalSystem-स्तर के स्थानीय विशेषाधिकार (प्रशासक से आगे के मजबूत विशेषाधिकार) चाहिए या नहीं। यदि केवल फ़ाइल पढ़ना/लिखना और नेटवर्क संचार है, तो वर्चुअल खाते (NT SERVICE\सेवा-नाम) पर जाना पहला उम्मीदवार है। माइग्रेशन पर आवश्यक फ़ोल्डरों और रजिस्ट्री कुंजियों पर पहुँच देना, प्रोफ़ाइल या DPAPI पर निर्भर डेटा का उपचार, और "Log on as a service" अधिकार की उपस्थिति पुष्टि करें। सत्यापन वातावरण में स्टार्ट और मुख्य कार्यों की पुष्टि करें, फिर उत्पादन बदलें।

वर्चुअल खाता चुनें या NetworkService?

नई पसंद के लिए हम वर्चुअल खाता सुझाते हैं। नेटवर्क पर दोनों कंप्यूटर खाते (DOMAIN\कंप्यूटर-नाम$) के रूप में दिखते हैं, और दोनों के स्थानीय विशेषाधिकार छोटे हैं। पर NetworkService कई सेवाओं से साझा है, इसलिए ACL से "केवल यही सेवा अनुमति" अलग नहीं कर सकते। वर्चुअल खाते की पहचान प्रत्येक सेवा के लिए अनोखी होती है, और ACL पर NT SERVICE\सेवा-नाम सीधे लिख सकते हैं। SQL Server जैसे हाल के Microsoft उत्पाद भी वर्चुअल खाते को डिफ़ॉल्ट रखते हैं।

क्या वर्कग्रुप वातावरण (कोई डोमेन नहीं) में gMSA इस्तेमाल कर सकते हैं?

नहीं। gMSA वह तंत्र है जिसमें Active Directory डोमेन नियंत्रक पासवर्ड बनाता और प्रबंधित करता है; डोमेन और KDS रूट कुंजी बनाना पूर्वापेक्षाएँ हैं। वर्कग्रुप में आधार यह है कि स्थानीय प्रसंस्करण वर्चुअल खाते या LocalService/NetworkService से पूरा करें। यदि दूसरी मशीन पर पहुँच चाहिए, तो गंतव्य पर तैयार खाते की साख स्पष्ट रूप से इस्तेमाल करने जैसा अलग डिज़ाइन चाहिए। कंप्यूटर खाते (PC$) के रूप में नेटवर्क पहुँच भी केवल डोमेन वातावरण में लागू होती है।

सेवा का लॉगऑन खाता बदलने के बाद सहेजी गई सेटिंग्स और साख नहीं पढ़ी जा सकतीं। क्यों?

क्योंकि प्रत्येक लॉगऑन खाता अपने उपयोगकर्ता प्रोफ़ाइल, %TEMP%, HKEY_CURRENT_USER और DPAPI कुंजी से बँधा है। विशेषकर उपयोगकर्ता-दायरे DPAPI (CryptProtectData आदि) से सुरक्षित डेटा सिद्धांततः उसी खाते से ही डिक्रिप्ट होता है जिसने सुरक्षित किया। प्रोफ़ाइल के नीचे (AppData आदि) सहेजी फ़ाइलें भी नए खाते से अलग पथ हैं। खाता बदलने से पहले DPAPI-सुरक्षित डेटा फिर बनाने की प्रक्रिया (API कुंजियाँ फिर दर्ज करना आदि) और प्रोफ़ाइल के नीचे फ़ाइलों का माइग्रेशन योजनाबद्ध करें।

यदि सेवा को केवल साझा फ़ोल्डर तक पहुँच चाहिए, क्या डोमेन उपयोगकर्ता चाहिए?

कई मामलों में नहीं। डोमेन वातावरण में LocalSystem, NetworkService या वर्चुअल खाते से चलने वाली सेवा दूर पक्ष पर कंप्यूटर खाते (DOMAIN\कंप्यूटर-नाम$) के रूप में प्रमाणित होती है। उस PC$ को साझा अनुमति और NTFS अनुमति में जोड़ें तो वह पढ़-लिख सकती है। यदि सेवा-विशिष्ट पहचान से पहुँच नियंत्रण चाहिए, या कई सर्वरों पर वही पहचान, तो डोमेन उपयोगकर्ता के बजाय gMSA सोचें।

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

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

Go Komura

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

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