Windows service account चुनना — LocalSystem, virtual accounts और gMSA

“एक internal service जिसे हम अभी तक LocalSystem से चला रहे थे, security audit में ‘excessive privilege’ चिह्नित हुई। किसमें बदलें?” “Service shared folder तक नहीं पहुँच सकी, इसलिए हम इसे domain user से चला रहे हैं। Password expire होने पर service रुक जाती है, इसलिए हमने कभी न expire होने वाला बना दिया और runbook में plain text में लिख दिया।” — customers की Windows services के परामर्श में ये दो बातें regular हैं।

दोनों स्थलों में समान यह है कि service का logon account “design decision” नहीं, बल्कि “संयोग से चल गई setting” के रूप में जमी हुई है। Windows service हमेशा किसी account के security context में चलती है, और वह account तय करता है कि locally क्या कर सकती है, network के remote side से कौन दिखती है, और password कौन manage करता है। इसे default पर छोड़ें तो एक service की vulnerability सीधे पूरी machine के takeover तक जाती है, और plain-text passwords runbook व scripts में बिखर जाते हैं।

flowchart TB
    accTitle: Logon account तय करने वाली तीन बातें
    accDescr: Service हमेशा किसी account के security context में चलती है, और वह account तय करता है कि locally क्या कर सकती है, network के remote side से कौन दिखती है, और password कौन manage करता है
    acct["Service का logon account"] --> local["Locally क्या कर सकती है"]
    acct --> net["Network के remote side से कौन दिखती है"]
    acct --> pwd["Password कौन manage करता है"]

चित्र 1: Logon account चुनना वह design decision है जो local privileges, network identity और password management एक साथ तय करता है।

प्रभावी रूप से छह विकल्प हैं — LocalSystem, LocalService, NetworkService, virtual account (NT SERVICE\), domain user, और gMSA (group Managed Service Account)। SMEs के IT staff और Windows app developers के लिए, यह लेख इन छह के privileges, network identity और password management को एक table में व्यवस्थित करता है और decision flow सारांशित करता है, अगस्त 2026 तक Microsoft Learn primary sources पर आधारित।

Service स्वयं कैसे बनाएँ (Task Scheduler और service में चुनाव, .NET Worker Service से implement करना) “Windows services बनाना और चलाना” में है। यह लेख “logon account” पर केंद्रित है, जहाँ सबसे अधिक accidents होती हैं।

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

• संदेह हो तो एकल machine के भीतर पूरी होने वाली service के लिए virtual account पहला उम्मीदवार है, और domain के भीतर service-specific identity से resource तक access करने वाली service के लिए gMSA पहला उम्मीदवार है। Microsoft भी जहाँ संभव हो managed account (MSA / virtual account) इस्तेमाल करने का guidance देता है।¹²
• LocalSystem इसलिए न चुनें कि “चल गया”। Token में SYSTEM और BUILTIN\Administrators हैं और SeDebugPrivilege जैसे मजबूत privileges हैं, इसलिए takeover पर उस machine पर लगभग सब कुछ खो जाता है। sc.exe create का default LocalSystem होना इस accident का breeding ground है।³⁴
• LocalService और NetworkService का अंतर network identity है। Local privileges दोनों के लिए minimum हैं, पर remote side पर LocalService anonymous दिखता है और NetworkService computer account जैसा।⁵
• **Virtual account (NT SERVICE\) आधुनिक default है जो per-service identity अलग कर सकता है और password management नहीं चाहता।** ACL पर "NT SERVICE\\service-name" सीधे लिख सकते हैं, और SQL Server का default service account भी यही है।[^understand-service-accounts][^sql-service-accounts]
• जब LocalSystem, NetworkService या virtual account network पर जाता है, वह computer account (DOMAIN\computer-name$) बन जाता है। Shared folder या SQL Server की ACL पर PC$ देना अक्सर domain user के बिना काम चला देता है।³⁶
• Service के लिए domain user वाली configuration password operations और Kerberoasting दोनों पर ऋण बन जाती है। SCM stored password से logon करता है, इसलिए expiry start failure बनती है, और उसे टालने वाला “कभी न expire + plain-text memo” attacker को उपहार है।⁷⁸
• gMSA में Active Directory password automatic बनाता और rotate करता है। Requirements domain और KDS root key हैं, और service को “DOMAIN\account-name$” पर खाली password field से set करें। कुछ apps support नहीं करते, इसलिए पहले से validate करें।⁹¹⁰
• Account बदलने से profile, %TEMP% और DPAPI की assumptions बदलती हैं। पुराने account के DPAPI से protected data नया account decrypt नहीं कर सकता।
• Current status की list service list के logon accounts और Event ID 4624 (logon type 5) से confirm हो सकती है।¹¹

एक वाक्य में इस लेख का निष्कर्ष: “Service को human password न दें” वाली configuration (built-in accounts, virtual account, gMSA) को default बनाएँ, और domain user को last resort मानें।

2. विकल्पों का बड़ा चित्र — एक table में छह logon accounts

पहले एक review कदम। Service start पर Service Control Manager (SCM) configured account से logon करता है और success पर access token बनाकर service process को सौंपता है। उसके बाद हर resource access — files, pipes आदि — इस token को ACL से मिलाकर तय होती है।⁷ अतः logon account चुनना वह design है जो service process को दिए गए token की content तय करता है। ये छह विकल्प हैं।

flowchart TB
    accTitle: Service start पर SCM क्या करता है
    accDescr: SCM configured account से logon करता है, success पर access token बनाता और service process को सौंपता है, उसके बाद resource access token को ACL से मिलाकर तय होती है
    scm["SCM"] --> logon["Configured account से logon"]
    logon --> token["Access token बनाएँ"]
    token --> proc["Service process को सौंपें"]
    proc --> access["File या pipe तक access"]
    access --> check{"ACL अनुमति देती है?"}
    check -->|हाँ| ok["Access successful"]
    check -->|नहीं| deny["Access denied"]

चित्र 2: Service की हर resource access उस token को ACL से मिलाकर तय होती है जो SCM ने start पर बनाया।

LocalSystem, LocalService, NetworkService और virtual accounts सभी में password की कोई अवधारणा ही नहीं है। SCM में stored password से logon करने वाले (= expiry और leak संभव) केवल domain user और local user हैं।⁷³

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

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

3.1. “Run as administrator” से भी अधिक मजबूत

LocalSystem (display name Local System, NT AUTHORITY\SYSTEM) SCM का default account है, और local computer पर व्यापक privileges रखता है। Token में NT AUTHORITY\SYSTEM और BUILTIN\Administrators के SID हैं, और वह system पर अधिकांश objects तक access कर सकता है। आगे, SeDebugPrivilege, जो अन्य processes को debug कर सकता है, और SeTcbPrivilege, जो OS का भाग बनकर कार्य करता है, default से enabled हैं।³

यह शक्ति takeover पर क्षति के आकार का पर्याय है। यदि LocalSystem से चलने वाली service में एक arbitrary-code-execution vulnerability हो, attacker एक साँस में उस machine पर हर user की files पढ़-बदल सकता है (NTFS पर SYSTEM के पास default Full Control है⁵), SeDebugPrivilege से अन्य processes की memory पढ़ सकता है, और credentials चुराकर वहाँ से lateral movement कर सकता है (Pass-the-Hash आदि का starting point)। Credential theft और lateral movement की श्रृंखला “आरेखों से NTLM और Kerberos” और “Windows LAPS practical guide” में है।

flowchart TB
    accTitle: LocalSystem service के takeover पर क्षति
    accDescr: यदि LocalSystem से चलने वाली service में एक arbitrary-code-execution vulnerability हो, attacker हर user की files पढ़-बदल सकता है, अन्य processes की memory पढ़ सकता है, और credentials चुराकर lateral movement कर सकता है
    vuln["एक arbitrary-code-execution vulnerability"] --> sys["Attacker SYSTEM privilege पाता है"]
    sys --> files["Files पढ़ना और बदलना"]
    sys --> mem["अन्य processes की memory पढ़ना"]
    sys --> cred["Credential theft"]
    cred --> lateral["दूसरी machine पर lateral movement"]

चित्र 3: LocalSystem service में एक vulnerability attacker को एक साँस में पूरी machine और lateral movement का starting point तक पहुँचा देती है।

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

कारण सरल है: यह default है, और access-denied कभी नहीं आता। sc.exe create पर obj= छोड़ने का default LocalSystem है,⁴ और कई पुराने sample-code व installer templates अभी भी LocalSystem मानते हैं। Development में privilege errors से मुक्त रहने के कारण “चल गया, तो छोड़ दो” का बड़े पैमाने पर production करने वाला ढाँचा मौजूद है। Microsoft का अपना documentation भी कहता है कि अधिकांश services को इतने ऊँचे privilege level की आवश्यकता नहीं, और यदि नहीं चाहिए तो LocalService या NetworkService सोचें।³

flowchart TB
    accTitle: वह ढाँचा जो LocalSystem चुनता रहता है
    accDescr: sc.exe create का default LocalSystem है, और पुराने samples व templates भी LocalSystem मानते हैं, इसलिए development में access-denied नहीं आता और चल गया तो छोड़ दो वाली configuration बड़े पैमाने पर बनती है
    def["sc.exe create का default"] --> lsys["LocalSystem के रूप में बना"]
    old["पुराने samples और templates"] --> lsys
    lsys --> noerr["Development में कोई access-denied नहीं"]
    noerr --> asis["चल गया, तो छोड़ दो"]
    asis --> mass["Excessive-privilege वाली services बड़े पैमाने पर बनती हैं"]

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

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

LocalSystem को “Windows का सबसे मजबूत account” कहना सटीक नहीं। Windows Vista से Windows Resource Protection (WRP) महत्वपूर्ण OS system files, folders और registry keys में बदलाव केवल TrustedInstaller (Windows Modules Installer service) को अनुमति देता है, और SYSTEM या Administrator को भी overwrite पर access denied मिलता है।¹² Explorer का “You need permission from TrustedInstaller” यही mechanism है। उलटा कहें तो LocalSystem WRP-protected क्षेत्र के बाहर लगभग सब कुछ तक access कर सकता है, और business service को वह देने का usually कोई कारण नहीं।

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

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

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

Exceptionally उचित वह service है जिसके आवश्यक privileges पहले से Administrator-class से आगे हैं — device driver के साथ निकट काम, OS security foundation चलाना, अन्य services या sessions manage करना आदि। Backup agent या EDR जैसा software लागू होता है। तब भी confirm करें कि सचमुच वह privilege इस्तेमाल करने वाला code path है, और सोचें कि privilege चाहिए वाले काम को अलग किया जा सकता है या नहीं (कैसे बताएँ, देखें “Windows पर Administrator privilege वास्तव में कब चाहिए?”)।

4. LocalService और NetworkService — least-privilege वाले built-in accounts

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) और NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) low-privilege services के लिए तैयार built-in accounts हैं। दोनों locally केवल minimum privileges रखते हैं, और Users group के member से अधिक कुछ नहीं कर सकते।⁵¹

दोनों का अंतर एक बिंदु है: network के remote side से वे कौन दिखते हैं।⁵

• LocalService: Remote side से anonymous credentials से जुड़ता है। Authentication चाहिए वाले resource तक नहीं पहुँच सकता।
• NetworkService: Remote side को computer के credentials प्रस्तुत करता है (domain environment में DOMAIN\computer-name$)।

विभाजन यह है: LocalService यदि “network पर नहीं जाता, या जाता है तो identity नहीं चाहिए”, और NetworkService यदि “machine की identity से domain के भीतर resource तक access चाहिए”।

flowchart TB
    accTitle: LocalService और NetworkService का अंतर
    accDescr: Local privileges दोनों के लिए minimum हैं, पर remote side पर LocalService anonymous credentials से जुड़ता है और NetworkService computer के credentials प्रस्तुत करता है
    ls["LocalService"] --> anon["Anonymous credentials से जुड़ता है"]
    anon -.-> ng["Authentication चाहिए वाला resource असंभव"]
    ns["NetworkService"] --> comp["Computer के credentials प्रस्तुत करता है"]
    comp -.-> pc["Domain environment में PC$ दिखता है"]

चित्र 6: Local privileges समान minimum हैं, पर network के remote side से दिखने वाली identity anonymous या computer account में बँटती है।

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

flowchart TB
    accTitle: Shared account अलग नहीं हो सकता
    accDescr: यदि कई services एक ही LocalService share करें, तो जब तक ACL per-account है वे एक-दूसरे के resources तक access कर सकती हैं
    sva["Service A"] --> acct["एक ही LocalService"]
    svb["Service B"] --> acct
    svc["Service C"] --> acct
    acct --> mutual["एक-दूसरे के resources तक access"]
    mutual -.-> reason["क्योंकि ACL per-account है"]

चित्र 7: एक ही account share करने वाली services ACL से एक-दूसरे के resources से अलग नहीं हो सकतीं।

“Low-privilege रहें, पर per service अलग करें” का समाधान अगला विषय है, virtual account।

5. Virtual accounts (NT SERVICE\) — आधुनिक default

5.1. बिना password per-service identity

Virtual account Windows Server 2008 R2 / Windows 7 से available “managed local account” है। तीन विशेषताएँ हैं।⁶

• Account automatic managed है; बनाना या password set करना नहीं चाहिए
• Name NT SERVICE\<service-name> है, और प्रत्येक service के लिए unique identity बनता है
• Domain environment में computer account के credentials (DOMAIN\computer-name$) से network तक access कर सकता है

यानी LocalService/NetworkService का “कोई password management नहीं” गुण रखता है और “account shared होने से अलग नहीं हो सकता” दोष हटाता है। यही कारण है कि SQL Server setup NT SERVICE\MSSQLSERVER जैसे virtual account को default रखता है।¹

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

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

5.2. ACL पर “NT SERVICE\service-name” सीधे लिखें

व्यावहारिक सुविधा यह है कि आप केवल उस service को name से ACL में जोड़ सकते हैं। “केवल यही service इस data folder में लिख सकती है” बिना group बनाए और बिना password manage किए संभव है।

# Service का logon account virtual account में बदलें
# obj= का मान "NT SERVICE\service-name" है। Password न दें
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Configuration confirm करें (SERVICE_START_NAME जाँचें)
sc.exe qc MyAppService

# केवल इसी service को data folder पर modify rights दें
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

GUI में, services.msc में service के properties → “Log On” tab → “This account” में NT SERVICE\service-name दर्ज करें, और password field खाली छोड़ें (virtual account या MSA के लिए password न देना SCM की विशेषता है)। बदलाव के बाद service restart apply करता है।

5.3. बाधा — machine के बाहर वह “वही service” नहीं

Virtual account की identity machine-local है और domain से पहचानी नहीं जाती। Network पर वह बाद में वर्णित computer account में सिमटती है, इसलिए remote side “कौन सी service है” नहीं बता सकता, और कई servers पर वही identity share भी नहीं कर सकते।¹⁰

flowchart TB
    accTitle: Virtual account की identity machine के बाहर सिमटती है
    accDescr: Machine के भीतर per service unique virtual account network पर computer account में सिमटता है, और remote side कौन सी service है नहीं बता सकता
    vaa["Virtual account A"] --> pc["Computer account PC$"]
    vab["Virtual account B"] --> pc
    pc --> remote["Remote side को दिखने वाली identity"]
    remote -.-> nodist["कौन सी service है नहीं बता सकते"]

चित्र 9: Machine के भीतर unique identity होने पर भी network के remote side हर service एक ही PC$ दिखती है।

जब यह बाधा — network के remote side पर service-specific identity चाहिए, कई servers पर वही identity चाहिए — problem बने, तब gMSA (अध्याय 8) बुलाया जाता है।

6. Network पर जाने पर identity — computer account (PC$) का अभ्यास

6.1. “Service shared folder तक नहीं पहुँच सकती” गलतफहमी है

Domain-joined machine पर, जब LocalSystem, NetworkService या virtual account से चलने वाली service remote resource तक access करती है, वह computer account (DOMAIN\computer-name$) के रूप में authenticate होती है।³⁶ आरंभ की कई परामर्श “shared folder तक नहीं पहुँची, इसलिए domain user बना दिया” वास्तव में इससे हल होती हैं। Destination ACL बस PC$ permission नहीं दे रही थी।

flowchart TB
    accTitle: Computer account के रूप में remote access
    accDescr: Domain-joined machine पर LocalSystem, NetworkService या virtual-account service remote side पर computer account के रूप में authenticate होती है, और यदि destination ACL PC$ permission दे तो access कर सकती है
    svc["Service (LocalSystem, virtual account आदि)"] --> auth["PC$ के रूप में authenticate"]
    auth --> acl{"Destination ACL PC$ permission देती है?"}
    acl -->|हाँ| ok["Shared folder या DB तक access successful"]
    acl -->|नहीं| ng["Access denied"]

चित्र 10: Domain environment में destination ACL पर केवल PC$ देना domain user के बिना remote access स्थापित कर देता है।

File-server side पर देना ordinary ACL operations जैसा है; account name के रूप में computer-name$ दें (GUI object-picker में object type में “Computers” शामिल करें)।

# File-server side: APPSV01 पर service को shared folder पर modify rights दें
# Share permission और NTFS permission दोनों दें
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server भी वही: computer account login के रूप में बनाएँ और connection string Integrated Security=true से बिना password चलती है।

-- DB-server side: APPSV01 पर service से Windows integrated authentication अनुमति दें
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

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

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

1. Granularity per machine है। उसी machine पर चलने वाली LocalSystem, NetworkService और हर virtual-account service remote side से एक ही PC$ दिखती हैं। Destination पर “केवल यही service अनुमति” नहीं दे सकते, और कौन सी service ने वह account इस्तेमाल किया audit भी नहीं कर सकते।²
2. Workgroup environment में इस्तेमाल नहीं हो सकता। Computer account Active Directory object है, इसलिए domain-न joined machine के पास नहीं होता। Destination account के credentials स्पष्ट रूप से संभालने वाला design चाहिए।

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

flowchart TB
    accTitle: PC$ दृष्टिकोण की दो सीमाएँ
    accDescr: PC$ के रूप में authentication की granularity machine-level है इसलिए per-service permission या audit नहीं, और workgroup में computer account स्वयं नहीं है इसलिए इस्तेमाल नहीं
    pcs["PC$ दृष्टिकोण"] --> lim1["सीमा 1: per machine"]
    pcs --> lim2["सीमा 2: कोई workgroup नहीं"]
    lim1 -.-> noaudit["कोई per-service permission या audit नहीं"]
    lim2 -.-> nocred["Explicit credentials इस्तेमाल करें"]
    lim1 --> gmsa["इससे आगे: gMSA"]

चित्र 11: Machine-level granularity और domain prerequisite की दो सीमाओं से आगे जाना हो तो domain user छोड़कर gMSA पर जाएँ।

7. Service के लिए domain user इस्तेमाल करने की समस्या

7.1. Password की structural समस्या

यदि service को domain user (या local user) दें, SCM वह password store करता है और हर start पर logon के लिए इस्तेमाल करता है। SCM expiry manage नहीं करता, इसलिए password expire होने पर logon fail होता है और service start नहीं होगी।⁷

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

1. Expiry से service रुकने की accident होती है
2. Recurrence रोकने के लिए “password कभी न expire” set होता है
3. Change process कभी स्थापित नहीं होती, और वही password कई servers की runbooks, scripts और Task Scheduler में plain text में लिखा जाता है
4. कोई जाने पर भी password नहीं बदलता (बदलें तो नहीं पता क्या रुकेगा)

flowchart TB
    accTitle: Domain user से operations का नकारात्मक चक्र
    accDescr: Password expire होता है और service रुकती है, recurrence रोकने के लिए कभी-न-expire set होता है, plain-text password runbook व scripts में फैलता है, और कोई जाने पर भी नहीं बदल सकता
    expire["1. Expiry service रोकती है"] --> forever["2. Prevention के लिए कभी-न-expire set"]
    forever --> spread["3. Plain-text password फैलता है"]
    spread -.-> where["Runbook, scripts, tasks"]
    spread --> stuck["4. कोई जाने पर भी नहीं बदल सकता"]

चित्र 12: Expiry accident से शुरू होकर कभी-न-expire और plain-text password का फैलाव स्थिर हो जाता है।

Microsoft यह भी बताता है कि service के लिए domain account इस्तेमाल करने वाली configuration password और SPN के manual management में काफी operational effort लेती है, और maintenance service रोक तक ले जा सकता है।¹

7.2. Kerberoasting — service account निशाना बनता है

Domain-user service account पर विशिष्ट दूसरा हमला Kerberoasting है। Kerberos authentication लेने वाली service logon account पर SPN (service principal name) register करती है। Domain में कोई भी authenticated user SPN-registered account को service ticket माँग सकता है, इसलिए attacker ticket पाता है और password का offline brute-force करता है। Human-determined 10-से-16-character password यह हमला नहीं सहेगा।

flowchart TB
    accTitle: Kerberoasting का प्रवाह
    accDescr: SPN-registered service account को service ticket कोई भी authenticated user माँग सकता है, इसलिए attacker ticket पाता है और password का offline brute-force करता है
    atk["Domain में authenticated user"] --> req["SPN के लिए ticket माँगें"]
    req --> tkt["Service ticket पाएँ"]
    tkt --> brute["Offline brute-force"]
    brute --> weak["लगभग 10 से 16 characters टूट जाएँगे"]

चित्र 13: कोई भी authenticated user ticket माँग सकता है, और human-determined length का password offline brute-force नहीं सहेगा।

प्रभावी उत्तर है password ऐसी शक्ति का बनाएँ जिसे मनुष्य अनुमान या तोड़ न सके। Microsoft लंबा password बाध्य करना, और gMSA इस्तेमाल करना भी सूचीबद्ध करता है जिसका password लंबा machine-generated random value बनता है।⁸ वही documentation Kerberos armoring (FAST) भी उल्लेख करता है, पर FAST pre-authentication data और KDC spoofing resistance की रक्षा करता है; वह authenticated user को SPN पर service ticket माँगने से नहीं रोकता, इसलिए service account की password शक्ति का विकल्प नहीं। SPN और Kerberos का संबंध, और वे शर्तें जब authentication NTLM पर गिरता है, “आरेखों से NTLM और Kerberos” में हैं।

7.3. यदि फिर भी domain user इस्तेमाल करें

यदि app gMSA support न करने जैसे कारणों से domain user ही इस्तेमाल करना पड़े, निम्न को minimum mitigation मानें।

• Password random 25 characters या अधिक बनाएँ, और password-management tool के अलावा कहीं न लिखें (runbook, scripts, shared Excel)
• Service-dedicated account बनाएँ और per service बाँटें (human account से share न करें²)
• Interactive logon और Remote Desktop deny करें, और केवल “Log on as a service” अनुमति दें
• Membership groups minimum रखें (Domain Admins में जोड़ना प्रश्न से बाहर)
• Periodic-rotation process स्थापित करें और बदलाव से प्रभावित स्थान ledger में डालें

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

8. gMSA — password management Active Directory को सौंपना

8.1. Mechanism और प्रभाव

gMSA (group Managed Service Account) वह domain account है जो password management domain controller को सौंपता है। Password domain controller KDS (Key Distribution Service) root key से calculate करता है, और केवल अनुमति प्राप्त hosts उसे पाते हैं।¹³

flowchart TB
    accTitle: gMSA password कैसे manage करता है
    accDescr: Domain controller KDS root key से password calculate करता है, केवल अनुमति प्राप्त hosts उसे पाते हैं और service चलाने में इस्तेमाल करते हैं, और password default से हर 30 दिन automatic rotate होता है
    kds["KDS root key"] --> dc["DC password calculate करता है"]
    dc --> host["अनुमति प्राप्त host पाता है"]
    host --> svc["Service चलाने में इस्तेमाल"]
    dc -.-> rot["Default से हर 30 दिन automatic rotation"]

चित्र 14: Domain controller password बनाना, वितरित करना और update करना ले लेता है, और मनुष्य password जाने बिना operations कर सकते हैं।

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

• 240-byte random generated password: Brute-force और dictionary attacks अवास्तविक हो जाते हैं, और Kerberoasting resistance काफी बढ़ता है
• Default से हर 30 दिन automatic rotation: मनुष्य को बदलाव योजना नहीं करनी, और service रोकनी नहीं
• कई servers पर वही identity share हो सकती है: Load balancing के तहत server farm एक ही principal के रूप में परस्पर authenticate हो सकते हैं
• सरल SPN management: SPN registration और management भी सौंपा और सरल किया जा सकता है

मनुष्य password जाने बिना operations कर सकते हैं — यदि इसे वह mechanism समझें जो service account के लिए वही करता है जो Windows LAPS local Administrator password के लिए करता है, स्थान पकड़ना आसान है।

8.2. Requirements

gMSA की prerequisites हैं।¹⁰

• Active Directory domain environment (workgroup में असंभव)
• Domain और forest functional level Windows Server 2012 या अधिक
• KDS root key पहले से बनी हो
• gMSA name forest में unique हो, केवल domain में नहीं
• Password-change interval केवल creation time पर set हो सकता है

KDS root key बनाना एक बार का काम है, पर creation के बाद 10 घंटे तक gMSA नहीं बना सकते, क्योंकि हर domain controller तक replication की प्रतीक्षा है। यह security device है ताकि replication पूरा होने से पहले password retrieval fail न हो।¹⁴

flowchart TB
    accTitle: KDS root key बनाने से gMSA बनाने तक
    accDescr: KDS root key बनने के बाद हर domain controller तक replication की प्रतीक्षा है, इसलिए 10 घंटे तक gMSA नहीं बना सकते; replication पूरा होने पर बना सकते हैं
    add["KDS root key बनाएँ"] --> wait["Replication की 10 घंटे तक प्रतीक्षा"]
    wait -.-> why["Retrieval-failure accident रोकने का security device"]
    wait --> done["हर DC तक replication पूरा"]
    done --> ok["gMSA बना सकते हैं"]

चित्र 15: Root key बनाने के बाद 10 घंटे तक प्रतीक्षा replication अधूरे रहते retrieval failure रोकने का समय है।

# Domain admin के रूप में चलाएँ, domain controller पर (या AD PowerShell
# module वाले administrative workstation पर)

# Confirm करें कि KDS root key है या नहीं, नहीं तो बनाएँ (प्रति forest एक बार)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # वास्तव में 10 घंटे बाद उपयोग योग्य

8.3. Creation से configuration तक process

Process चार चरण हैं: “① retrieval-allowed group बनाएँ → ② gMSA बनाएँ → ③ servers पर install करें → ④ service पर set करें”।¹⁰

flowchart TB
    accTitle: gMSA लाने के चार चरण
    accDescr: चार चरणों में लाएँ: password retrieval-allowed group बनाना, gMSA बनाना, प्रत्येक server पर install करना, और service के logon account के रूप में set करना
    st1["① Retrieval-allowed group बनाएँ"] --> st2["② gMSA बनाएँ"]
    st1 -.-> add["Servers के PC$ जोड़ें"]
    st2 --> st3["③ प्रत्येक server पर install करें"]
    st3 -.-> test["Test command से retrieval verify करें"]
    st3 --> st4["④ Service पर set करें"]

चित्र 16: Group बनाने से service set करने तक gMSA लाना चार चरणों में चलता है।

# ① Password retrieval-allowed security group बनाएँ,
#    और service चलाने वाले servers के computer accounts जोड़ें
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership computer logon पर evaluated होती है, इसलिए
# जोड़ने के बाद target server restart reliable तरीका है

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

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

# ④ Service के logon account के रूप में set करें। Name के अंत में $ लगाएँ, password न दें
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

services.msc से set करते समय भी account name CORP\svc-batch$ जैसा है — अंत में $ लगाएँ, और password field खाली छोड़ें। MSA-family account interactive sign-in के लिए इस्तेमाल नहीं हो सकता।¹ उसके बाद shared folder या SQL Server की ACL पर PC$ की जगह CORP\svc-batch$ दें, और service-specific identity से network access passwordless पूरी हो जाती है।

8.4. कुछ apps support नहीं करते

चेतावनी के रूप में, हर software gMSA से नहीं चलेगा। Standard mechanism से logon identity configured करने वाली चीज़ें — Windows service, IIS app pool, Task Scheduler tasks — व्यापक रूप से supported हैं, पर बाधाएँ हैं जैसे failover clustering स्वयं gMSA support नहीं करता, और वह app जिसके internal passwords माँगते हैं इस्तेमाल नहीं कर सकता।¹⁰ Microsoft साफ़ कहता है कि production से पहले test environment में gMSA के रूप में व्यवहार confirm करें।⁹

flowchart TB
    accTitle: gMSA support कैसे बताएँ
    accDescr: Standard mechanism से logon identity configured करने वाला app gMSA व्यापक रूप से support करता है, पर failover clustering और internally password माँगने वाला app नहीं कर सकता, इसलिए production से पहले test environment में confirm करें
    app["Target app"] --> how{"Logon कैसे set है?"}
    how -->|Standard mechanism| okapp["gMSA supported"]
    okapp -.-> ex1["Service, IIS, tasks"]
    how -->|Password माँगा| ngapp["gMSA असंभव"]
    ngapp -.-> ex2["Failover clustering"]
    okapp --> test["Production से पहले test"]

चित्र 17: Standard mechanism से logon configured करने वाला app व्यापक रूप से supported है, पर कुछ designs unsupported हैं, इसलिए production से पहले validation अपरिहार्य है।

भाई-बहन भी हैं: एकल server के लिए sMSA (standalone Managed Service Account), और dMSA (delegated Managed Service Account, Windows Server 2025 में आया, जो credential theft रोकने के लिए device identity से बँधता है)। नई creation के लिए gMSA base लें और requirements के अनुसार सोचें।⁶

9. साथ का design — logon rights, profile, DPAPI और auditing

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

9.1. “Log on as a service” right (SeServiceLogonRight)

Service के रूप में start करने के लिए account को “Log on as a service” user right चाहिए। LocalSystem, LocalService और NetworkService में यह built-in है, पर कोई अन्य account (domain user, gMSA आदि) explicit assignment चाहता है।¹⁵

यदि services.msc GUI के “Log On” tab से set करें, snap-in यह right automatic देता है। दूसरी ओर, CreateService / ChangeServiceConfig (sc.exe config द्वारा बुलाए गए API) यह verify नहीं करते कि specified account के पास यह right है। Script से configured service का “logon failure के कारण service start नहीं हुई” पर रुकना इसी का typical कारण है। Tool के side effect पर भरोसा न करें; deployment process में स्पष्ट रूप से Local Security Policy (secpol.msc) में “Log on as a service” जोड़ना, या GPO/Intune से configuration शामिल करें (जिस environment में यह right Group Policy से configured है, policy apply होने पर local grant overwrite होता है, इसलिए वह भी ध्यान योग्य है)। उलटा, service-dedicated account का standard कदम साथ में “Deny log on locally” set करना है।

flowchart TB
    accTitle: Log on as a service right के configuration paths का अंतर
    accDescr: services.msc GUI right automatic देता है, पर sc.exe config द्वारा बुलाया API right verify नहीं करता, इसलिए बिना right वाले account से service start पर logon failure से रुकती है
    gui["services.msc में set"] --> auto["Right automatic दिया जाता है"]
    auto --> okgui["Service start हो सकती है"]
    cli["sc.exe config से set"] --> noval["Right verify नहीं"]
    noval --> has{"Right है?"}
    has -->|हाँ| okcli["Service start हो सकती है"]
    has -->|नहीं| stop["Logon failure से रुकती है"]
    stop -.-> fix["secpol.msc या GPO से स्पष्ट दें"]

चित्र 18: GUI right automatic देता है, पर scripted configuration verify नहीं करता, इसलिए process में explicit grant शामिल करें।

9.2. Profile, %TEMP% और HKEY_CURRENT_USER बदलते हैं

SCM service start पर उस account की user profile load करता है।⁷ अतः actual %TEMP%, %APPDATA% और HKEY_CURRENT_USER प्रत्येक logon account पर अलग चीज़ हैं, और account बदलने पर पुराने account की profile में saved settings और cache ऐसे लगते हैं मानो “गायब” हो गए।

Design उत्तर सरल है: service का data profile के नीचे नहीं, बल्कि C:\ProgramData\<app-name> जैसे explicit path पर रखें, और वह ACL logon account को दें। इस तरह account बदलाव data migration साथ नहीं लाता।

flowchart TB
    accTitle: Profile dependency और data location का उत्तर
    accDescr: Actual profile प्रत्येक logon account पर अलग है, इसलिए account बदलने से पुरानी profile का data गायब लगता है, पर explicit path पर रखना और ACL देना migration अनावश्यक बनाता है
    sw["Logon account बदलना"] --> newprof["अलग profile load होती है"]
    newprof --> lost["पुराना data गायब लगता है"]
    lost -.->|उत्तर| fix["ProgramData के नीचे रखें"]
    fix --> acl["Logon account को ACL दें"]
    acl --> nomig["Account बदलने पर भी कोई migration नहीं"]

चित्र 19: Profile से बचें और data explicit path पर रखें, तो account बदलाव data migration साथ नहीं लाता।

9.3. DPAPI से protected data account से बँधा है

और भी आसानी से छूटने वाला DPAPI है। User-scope DPAPI (CryptProtectData या .NET का ProtectedData) से encrypt data सिद्धांततः उसी account से ही decrypt होता है जिसने protect किया। Account बदलते ही stored connection string या API key नहीं पढ़ी जा सकती — वह DPAPI का सही काम है, पर यदि migration process में नहीं है तो घटना बन जाती है।

flowchart TB
    accTitle: DPAPI-protected data और account बदलाव का संबंध
    accDescr: User-scope DPAPI से protected data उसी account से ही decrypt होता है जिसने protect किया, इसलिए logon account बदलने के बाद secrets फिर दर्ज करने पड़ते हैं
    protect["पुराने account से DPAPI-protect करें"] --> data["Protected connection string आदि"]
    data --> who{"कौन सा account decrypt कर रहा है?"}
    who -->|वही पुराना account| okdec["Decrypt हो सकता है"]
    who -->|नया account| ngdec["Decrypt नहीं हो सकता"]
    ngdec --> re["Secrets फिर दर्ज करें"]

चित्र 20: DPAPI-protected data उस account से बँधा है जिसने protect किया, और account बदलने के बाद फिर दर्ज करना पड़ता है।

उत्तर है migration plan में “account बदलने के बाद secrets फिर दर्ज करें” process शामिल करना (कहाँ store करें के design के लिए देखें “Windows apps में secrets store करना”)। साथ ही, gMSA या PC$ के रूप में Windows integrated authentication से पूरी हो सकने वाली configuration स्वयं secrets store करना समाप्त कर सकती है। सही क्रम है “क्या बिना store किए चल सकता है” को “कहाँ store करें” से पहले सोचना।

और यदि service “calling user के privileges से” processing चाहती है, account मजबूत करने के बजाय impersonation इस्तेमाल करें। उसके लिए देखें “Windows impersonation token सही ढंग से संभालना“।

9.4. Auditing — 4624 logon type 5 देखें

Service start Security event log में Event ID 4624 (An account was successfully logged on) के रूप में logon type 5 (Service: SCM ने service start की) से दर्ज होता है। Event का “Virtual Account” field बताता है कि logon MSA / virtual account से था या नहीं, इसलिए managed accounts के उपयोग पर नज़र रखने में भी काम आता है।¹¹

flowchart TB
    accTitle: Service start audit करने का प्रवाह
    accDescr: SCM का service start Event ID 4624 logon type 5 के रूप में दर्ज होता है, और Virtual Account field पहचान सकता है कि logon managed account से था या नहीं
    start["SCM service start करता है"] --> ev["Event ID 4624 दर्ज करें"]
    ev --> type5["Logon type 5 (Service)"]
    type5 --> vafield["Virtual Account field"]
    vafield --> watch["Managed accounts पर नज़र"]

चित्र 21: Service start logon type 5 के 4624 के रूप में दर्ज होता है, और managed accounts का उपयोग भी track कर सकते हैं।

Current status की list के लिए service list के logon accounts एकत्र करना तेज़ तरीका है।

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

# LocalSystem से चलने वाली गैर-standard services की list (path से internal / third-party बताएँ)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

यदि यह output “LocalSystem से चलने वाली business service” और “domain user से चलने वाली service” पंक्तिबद्ध करे, अगले अध्याय का decision flow बुलाया जाता है।

10. Decision flow — चार प्रश्नों से तय करें

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

flowchart TB
    accTitle: Logon account का decision flow
    accDescr: Network access है या नहीं, domain-join, machine-level identity पर्याप्त है या नहीं, और gMSA support — इन चार प्रश्नों का क्रम से उत्तर देकर logon account तय करें
    q1{"Peer को Win auth?"} -->|नहीं| va["Virtual account"]
    va -.-> sys["आवश्यक हो तो LocalSystem"]
    q1 -->|हाँ| q2{"Domain-joined?"}
    q2 -->|नहीं| cred["Stored credentials protect करें"]
    q2 -->|हाँ| q3{"Machine-level पर्याप्त?"}
    q3 -->|हाँ| pcacl["Virtual account + PC$"]
    q3 -->|नहीं| q4{"App gMSA support करता है?"}
    q4 -->|हाँ| gmsa["gMSA"]
    q4 -->|नहीं| du["User + mitigation"]

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

प्रश्न 1: क्या वह service network पर दूसरी machine (shared folder, DB, API आदि) तक Windows authentication से access करती है?

यदि नहीं, virtual account default है। केवल यदि विशेष local privileges चाहिए, वह आवश्यकता confirm करें फिर LocalSystem सोचें।

प्रश्न 2: (यदि access करती है) क्या machine domain-joined है?

Workgroup में न PC$ न gMSA इस्तेमाल हो सकते। Destination account के credentials स्पष्ट रूप से संभालने वाला design इस्तेमाल करें (storage DPAPI आदि से protect करें), या domain join पर विचार करें।

प्रश्न 3: (Domain में) क्या machine-level identity (PC$) पर्याप्त है?

यदि हाँ, virtual account (या NetworkService) + destination ACL पर PC$ देना पूरा है। यदि service-specific identity चाहिए, या कई servers पर shared identity, प्रश्न 4 पर जाएँ।

प्रश्न 4: क्या application gMSA support करता है?

यदि हाँ (standard mechanism से logon configured करने वाली चीज़ें — SCM, IIS app pool, Task Scheduler — usually करती हैं), gMSA। Validation environment में व्यवहार जाँच न भूलें। यदि किसी भी तरह unsupported है, खंड 7.3 का हर mitigation लागू करने के बाद dedicated domain user इस्तेमाल करें।

Table में इस प्रकार है।

11. सारांश

• Service का logon account वह design decision है जो local privileges, network identity और password management एक साथ तय करता है। Default (LocalSystem) पर न छोड़ें।
• LocalSystem SYSTEM+Administrators token और मजबूत privileges रखता है, और takeover पर क्षति अधिकतम होती है। अधिकांश business services को यह privilege नहीं चाहिए।
• LocalService और NetworkService दोनों low-privilege हैं; अंतर network identity है (anonymous, या computer account)। पर account कई services से shared होने से अलग नहीं हो सकते।
• Virtual account (NT SERVICE\) आधुनिक default है जो per service अलग कर सकता है और password management नहीं चाहता। ACL पर सीधे लिख सकते हैं, और configuration केवल logon-account name बदलना है।
• LocalSystem, NetworkService और virtual account domain environment में DOMAIN\PC$ के रूप में network पर जाते हैं। Shared folder या SQL Server की ACL पर PC$ देना अक्सर domain user के बिना काम चला देता है।
• Service के लिए domain user इस्तेमाल करने में expiry से रोक, plain-text password का फैलाव और Kerberoasting की structural समस्याएँ हैं। इस्तेमाल करें तो dedicated account + लंबा random password + logon restrictions आवश्यक हैं।
• gMSA वह mechanism है जिसमें AD password automatic बनाता और rotate करता है; requirements domain, functional level 2012 या अधिक, और KDS root key हैं। Service को “DOMAIN\name$” पर खाली password field से set करें।
• Account बदलते समय “Log on as a service” right, profile और %TEMP% transfer, और DPAPI-protected data फिर दर्ज करना migration process में शामिल करें। Auditing Event ID 4624 logon type 5 से confirm हो सकती है।

अगली बार service install करते समय logon-setting screen पर एक क्षण रुकें और यह फिर पूछें। किसके रूप में, और कितनी दूर, इस service को access सकना चाहिए? उत्तर इस लेख की decision table की कोई पंक्ति होना चाहिए।

संबंधित लेख

• Windows services बनाना और चलाना ── Task Scheduler और services में चुनाव से BackgroundService को Windows service बनाना तक
• Windows पर Administrator privilege वास्तव में कब चाहिए? - UAC, protected क्षेत्र, और design से कैसे बताएँ
• Windows impersonation token सही ढंग से संभालना — per thread privilege उधार लेना और सुरक्षित रूप से लौटाना
• आरेखों से NTLM और Kerberos — authentication NTLM पर क्यों गिरता है
• Windows LAPS practical guide — सभी PCs पर shared local Administrator password छोड़ना
• Windows apps में secrets store करना - DPAPI से plain-text configuration से बचना

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

KomuraSoft LLC Windows services और resident apps के लिए logon-account design और least-privilege hardening, LocalSystem मानकर बनी existing services को virtual accounts या gMSA पर migrate करना, और account बदलाव के बाद access denied, DPAPI और profile से हुई failures की जाँच संभालता है। “Audit में चिह्नित हुए, पर कहाँ से शुरू करें नहीं पता” चरण से शुरू करना ठीक है।

• Windows app development
• Bug और root-cause investigation
• Technical consulting और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

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

तुरंत बदलाव हर मामले में सही उत्तर नहीं है। पहले confirm करें कि उस service को सचमुच LocalSystem-level के local privileges (Administrator से आगे के मजबूत privileges) चाहिए या नहीं। यदि सिर्फ़ file read/write और network communication है, तो virtual account (NT SERVICE\service-name) पर जाना पहला उम्मीदवार है। Migration पर आवश्यक folders और registry keys पर access देना, profile या DPAPI पर निर्भर data का treatment, और "Log on as a service" right की उपस्थिति confirm करें। Validation environment में start और मुख्य कार्यों की पुष्टि करें, फिर production बदलें।

Virtual account चुनें या NetworkService?

नई पसंद के लिए हम virtual account सुझाते हैं। Network पर दोनों computer account (DOMAIN\computer-name$) के रूप में दिखते हैं, और दोनों के local privileges छोटे हैं। पर NetworkService कई services से shared है, इसलिए ACL से "केवल यही service अनुमति" अलग नहीं कर सकते। Virtual account की identity प्रत्येक service के लिए unique होती है, और ACL पर NT SERVICE\service-name सीधे लिख सकते हैं। SQL Server जैसे हाल के Microsoft products भी virtual account को default रखते हैं।

क्या workgroup environment (कोई domain नहीं) में gMSA इस्तेमाल कर सकते हैं?

नहीं। gMSA वह mechanism है जिसमें Active Directory domain controller password बनाता और manage करता है; domain और KDS root key बनाना prerequisites हैं। Workgroup में base यह है कि local processing virtual account या LocalService/NetworkService से पूरा करें। यदि दूसरी machine पर access चाहिए, तो destination पर तैयार account के credentials स्पष्ट रूप से इस्तेमाल करने जैसा अलग design चाहिए। Computer account (PC$) के रूप में network access भी केवल domain environment में लागू होती है।

Service का logon account बदलने के बाद saved settings और credentials नहीं पढ़ी जा सकतीं। क्यों?

क्योंकि प्रत्येक logon account अपने user profile, %TEMP%, HKEY_CURRENT_USER और DPAPI key से बँधा है। खासकर user-scope DPAPI (CryptProtectData आदि) से protected data सिद्धांततः उसी account से ही decrypt होता है जिसने protect किया। Profile के नीचे (AppData आदि) saved files भी नए account से अलग path हैं। Account बदलने से पहले DPAPI-protected data फिर बनाने की process (API keys फिर दर्ज करना आदि) और profile के नीचे files का migration योजनाबद्ध करें।

यदि service को केवल shared folder तक access चाहिए, क्या domain user चाहिए?

कई मामलों में नहीं। Domain environment में LocalSystem, NetworkService या virtual account से चलने वाली service remote side पर computer account (DOMAIN\computer-name$) के रूप में authenticate होती है। उस PC$ को share permission और NTFS permission में जोड़ें तो वह पढ़-लिख सकती है। यदि service-specific identity से access control चाहिए, या कई servers पर वही identity, तो domain user के बजाय gMSA सोचें।

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

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

Go Komura

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

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