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 অ্যাপ ডেভেলপারদের লক্ষ্য করে, এই নিবন্ধ এই ছয়টির বিশেষাধিকার, নেটওয়ার্ক পরিচয় ও পাসওয়ার্ড পরিচালনা এক সারণিতে সাজায় এবং সিদ্ধান্ত প্রবাহ সংক্ষেপ করে, আগস্ট ২০২৬ পর্যন্ত 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-এর ডিফল্ট সার্ভিস অ্যাকাউন্টও এটি।⁶¹
• LocalSystem, NetworkService বা ভার্চুয়াল অ্যাকাউন্ট নেটওয়ার্কে গেলে কম্পিউটার অ্যাকাউন্ট (DOMAIN\কম্পিউটার-নাম$) হয়ে যায়। শেয়ারড ফোল্ডার বা SQL Server-এর ACL-এ PC$ দিলে প্রায়ই ডোমেন ব্যবহারকারী ছাড়াই চলে।³⁶
• সার্ভিসের জন্য ডোমেন ব্যবহারকারী ব্যবহার করা কনফিগারেশন পাসওয়ার্ড পরিচালনা ও Kerberoasting দুটোতেই ঋণ হয়ে যায়। SCM সংরক্ষিত পাসওয়ার্ড দিয়ে লগঅন করে, তাই মেয়াদ শেষ স্টার্ট ব্যর্থতা হয়, আর তা এড়ানোর “কখনো মেয়াদ শেষ নয় + সাদা-পাঠ নোট” আক্রমণকারীর উপহার।⁷⁸
• gMSA-তে Active Directory পাসওয়ার্ড স্বয়ংক্রিয়ভাবে তৈরি ও ঘোরায়। শর্ত ডোমেন ও KDS রুট কী, আর সার্ভিসকে “DOMAIN\অ্যাকাউন্ট-নাম$” খালি পাসওয়ার্ড ক্ষেত্র দিয়ে সেট করুন। কিছু অ্যাপ সমর্থন করে না, তাই আগে যাচাই করুন।⁹¹⁰
• অ্যাকাউন্ট বদলালে প্রোফাইল, %TEMP% ও DPAPI-এর অনুমান বদলায়। পুরোনো অ্যাকাউন্টের DPAPI দিয়ে সুরক্ষিত ডেটা নতুন অ্যাকাউন্ট ডিক্রিপ্ট করতে পারে না।
• বর্তমান অবস্থার তালিকা সার্ভিস তালিকার লগঅন অ্যাকাউন্ট ও ইভেন্ট ID 4624 (লগঅন টাইপ ৫) থেকে নিশ্চিত করা যায়।¹¹

এক বাক্যে এই নিবন্ধের সিদ্ধান্ত: “সার্ভিসকে মানুষের পাসওয়ার্ড দেবেন না” এমন কনফিগারেশন (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: সার্ভিসের প্রতিটি রিসোর্স অ্যাক্সেস SCM স্টার্টে তৈরি টোকেন ACL-এর সাথে মিলিয়ে ঠিক হয়।

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 (অধ্যায় ৮) ডাকা হয়।

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 অবজেক্ট, তাই ডোমেন-যুক্ত নয় এমন মেশিনে নেই। গন্তব্য অ্যাকাউন্টের ক্রেডেনশিয়াল স্পষ্টভাবে সামলানো ডিজাইন লাগে।

সীমা ১-এর বাইরে যেতে চাইলে ২০২৬-এর উত্তর পরের অধ্যায়ের ডোমেন ব্যবহারকারী নয়… বরং সেই সমস্যা এড়িয়ে 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 চেষ্টা করে। মানুষ-ঠিক করা ১০-থেকে-১৬-অক্ষরের পাসওয়ার্ড এই আক্রমণ সহ্য করবে না।

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 সমর্থন করে না এমন কারণে ডোমেন ব্যবহারকারীই ব্যবহার করতে হলে নিচেরগুলো ন্যূনতম প্রশমন ধরুন।

• পাসওয়ার্ড এলোমেলো ২৫ অক্ষর বা বেশি করুন, আর পাসওয়ার্ড-পরিচালনা টুল ছাড়া কোথাও লিখবেন না (রানবুক, স্ক্রিপ্ট, শেয়ারড 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: ডোমেন কন্ট্রোলার পাসওয়ার্ড তৈরি, বিতরণ ও হালনাগাদ নেয়, আর মানুষ পাসওয়ার্ড না জেনেই পরিচালনা করতে পারে।

প্রভাব স্পষ্ট।⁹

• ২৪০-বাইট এলোমেলো তৈরি পাসওয়ার্ড: brute-force ও অভিধান আক্রমণ অবাস্তব হয়, আর Kerberoasting প্রতিরোধ উল্লেখযোগ্য বাড়ে
• ডিফল্টে প্রতি ৩০ দিন স্বয়ংক্রিয় ঘোরানো: মানুষকে পরিবর্তন পরিকল্পনা করতে হয় না, সার্ভিস থামাতে হয় না
• কয়েকটি সার্ভারে একই পরিচয় ভাগ করা যায়: লোড ব্যালেন্সিংয়ের নিচে সার্ভার ফার্ম একই principal হিসেবে পরস্পর প্রমাণীকরণ করতে পারে
• সহজতর SPN পরিচালনা: SPN নিবন্ধন ও পরিচালনাও অর্পণ ও সরল করা যায়

মানুষ পাসওয়ার্ড না জেনেই পরিচালনা করতে পারে — সার্ভিস অ্যাকাউন্টের জন্য সেই ব্যবস্থা যা Windows LAPS স্থানীয় প্রশাসক পাসওয়ার্ডের জন্য করে, স্থান ধরা সহজ।

8.2. শর্ত

gMSA-এর পূর্বশর্ত আছে।¹⁰

• Active Directory ডোমেন পরিবেশ (ওয়ার্কগ্রুপে অসম্ভব)
• ডোমেন ও ফরেস্ট ফাংশনাল লেভেল Windows Server 2012 বা তার বেশি
• KDS রুট কী আগেই তৈরি
• gMSA নাম ফরেস্টে অনন্য, শুধু ডোমেনে নয়
• পাসওয়ার্ড-পরিবর্তন ব্যবধান শুধু তৈরির সময় সেট করা যায়

KDS রুট কী তৈরি একবারের কাজ, কিন্তু তৈরির পর ১০ ঘণ্টা পর্যন্ত 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: রুট কী তৈরির পর সর্বোচ্চ ১০ ঘণ্টা অপেক্ষা 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 লগঅন টাইপ ৫ দেখুন

সার্ভিস স্টার্ট Security ইভেন্ট লগে ইভেন্ট ID 4624 (An account was successfully logged on) হিসেবে লগঅন টাইপ ৫ (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: সার্ভিস স্টার্ট লগঅন টাইপ ৫-এর 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: চার প্রশ্নের ক্রমে উত্তর দিলে ছয় পছন্দের কোনটি ব্যবহার করা উচিত ঠিক হয়।

প্রশ্ন ১: সেই সার্ভিস কি নেটওয়ার্কে অন্য মেশিনে (শেয়ারড ফোল্ডার, DB, API ইত্যাদি) Windows প্রমাণীকরণ দিয়ে অ্যাক্সেস করে?

না হলে ভার্চুয়াল অ্যাকাউন্ট ডিফল্ট। শুধু বিশেষ স্থানীয় বিশেষাধিকার লাগলে সেই প্রয়োজন নিশ্চিত করে তারপর LocalSystem বিবেচনা করুন।

প্রশ্ন ২: (অ্যাক্সেস করলে) মেশিন কি ডোমেন-যুক্ত?

ওয়ার্কগ্রুপে PC$ বা gMSA কোনোটাই ব্যবহার যায় না। গন্তব্য অ্যাকাউন্টের ক্রেডেনশিয়াল স্পষ্টভাবে সামলানো ডিজাইন ব্যবহার করুন (সংগ্রহ DPAPI ইত্যাদি দিয়ে সুরক্ষিত করুন), অথবা ডোমেনে যোগ দেওয়ার কথা ভাবুন।

প্রশ্ন ৩: (ডোমেনে) মেশিন-স্তরের পরিচয় (PC$) কি যথেষ্ট?

হ্যাঁ হলে ভার্চুয়াল অ্যাকাউন্ট (বা NetworkService) + গন্তব্য ACL-এ PC$ দেওয়া সম্পূর্ণ। সার্ভিস-নির্দিষ্ট পরিচয় লাগলে, বা কয়েকটি সার্ভারে সাধারণ পরিচয়, প্রশ্ন ৪-এ যান।

প্রশ্ন ৪: অ্যাপ্লিকেশন কি gMSA সমর্থন করে?

করে (স্ট্যান্ডার্ড ব্যবস্থায় লগঅন কনফিগার করা জিনিস — SCM, IIS অ্যাপ পুল, Task Scheduler — সাধারণত করে) হলে gMSA। যাচাই পরিবেশে আচরণ পরীক্ষা ভুলবেন না। কোনোভাবেই অসমর্থিত হলে ধারা ৭.৩-এর সব প্রশমন প্রয়োগ করে নিবেদিত ডোমেন ব্যবহারকারী ব্যবহার করুন।

সারণিতে এভাবে।

11. সারাংশ

• সার্ভিসের লগঅন অ্যাকাউন্ট সেই ডিজাইন সিদ্ধান্ত যা স্থানীয় বিশেষাধিকার, নেটওয়ার্ক পরিচয় ও পাসওয়ার্ড পরিচালনা একসাথে ঠিক করে। ডিফল্টে (LocalSystem) রাখবেন না।
• LocalSystem SYSTEM+Administrators টোকেন ও শক্তিশালী বিশেষাধিকার রাখে, আর দখলে ক্ষতি সর্বোচ্চ হয়। বেশিরভাগ ব্যবসায়িক সার্ভিসের এই বিশেষাধিকার লাগে না।
• LocalService ও NetworkService দুটোই কম-বিশেষাধিকার; পার্থক্য নেটওয়ার্ক পরিচয় (বেনামি, বা কম্পিউটার অ্যাকাউন্ট)। কিন্তু অ্যাকাউন্ট কয়েকটি সার্ভিস ভাগ করায় আলাদা করা যায় না।
• ভার্চুয়াল অ্যাকাউন্ট (NT SERVICE\<সার্ভিস-নাম>) আধুনিক ডিফল্ট যা প্রতি সার্ভিসে আলাদা করতে পারে এবং পাসওয়ার্ড পরিচালনা চায় না। ACL-এ সরাসরি লেখা যায়, আর কনফিগারেশন শুধু লগঅন-অ্যাকাউন্ট নাম বদলানো।
• LocalSystem, NetworkService ও ভার্চুয়াল অ্যাকাউন্ট ডোমেন পরিবেশে DOMAIN\PC$ হিসেবে নেটওয়ার্কে যায়। শেয়ারড ফোল্ডার বা SQL Server-এর ACL-এ PC$ দিলে প্রায়ই ডোমেন ব্যবহারকারী ছাড়াই চলে।
• সার্ভিসের জন্য ডোমেন ব্যবহারকারী ব্যবহারে মেয়াদ শেষে থামানো, সাদা-পাঠ পাসওয়ার্ডের ছড়ানো ও Kerberoasting-এর কাঠামোগত সমস্যা আছে। ব্যবহার করলে নিবেদিত অ্যাকাউন্ট + দীর্ঘ এলোমেলো পাসওয়ার্ড + লগঅন সীমাবদ্ধতা লাগে।
• gMSA সেই ব্যবস্থা যেখানে AD পাসওয়ার্ড স্বয়ংক্রিয়ভাবে তৈরি ও ঘোরায়; শর্ত ডোমেন, ফাংশনাল লেভেল ২০১২ বা তার বেশি, ও KDS রুট কী। সার্ভিসকে “DOMAIN\নাম$” খালি পাসওয়ার্ড ক্ষেত্র দিয়ে সেট করুন।
• অ্যাকাউন্ট বদলালে “Log on as a service” অধিকার, প্রোফাইল ও %TEMP% স্থানান্তর, এবং DPAPI-সুরক্ষিত ডেটা আবার লেখা মাইগ্রেশন প্রক্রিয়ায় রাখুন। অডিটিং ইভেন্ট ID 4624 লগঅন টাইপ ৫ দিয়ে নিশ্চিত করা যায়।

পরেরবার সার্ভিস ইনস্টল করার সময় লগঅন-সেটিং স্ক্রিনে এক মুহূর্ত থামুন এবং এটি আবার জিজ্ঞাসা করুন। কার হিসেবে, এবং কতদূর, এই সার্ভিসের অ্যাক্সেস থাকা উচিত? উত্তর এই নিবন্ধের সিদ্ধান্ত সারণির কোনো এক সারি হওয়া উচিত।

সংশ্লিষ্ট নিবন্ধ

• 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 সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।