Azure VM-কে Entra Domain Services-এ যুক্ত করা: আগে সিদ্ধান্ত নিন
যুক্ত হওয়ার আগে তিনটি সিদ্ধান্ত: ওয়ার্কলোডের প্রয়োজনীয় ডিরেক্টরি মডেল, ডোমেইন সমাধানকারী প্রাইভেট DNS, এবং প্রমাণীকরণ করতে সক্ষম একটি অ্যাকাউন্ট।
তিনটি সিদ্ধান্ত একটি Windows Server VM-এর সামনে দাঁড়িয়ে আছে, যেটিকে একটি ম্যানেজড ডিরেক্টরি ব্যবহার করতে হবে, আর জয়েন কমান্ডটি তাদের মধ্যে সবচেয়ে ছোট। ভুল ডিরেক্টরি মডেল বেছে নিলে জয়েন সফল হয়, অথচ অ্যাপ্লিকেশনটি তখনও প্রমাণীকরণ করতে পারে না। নাম রেজোলিউশন ভুল হলে ব্যর্থতাটি এমন জায়গায় দেখা দেয় যা ক্রেডেনশিয়াল সমস্যার মতো দেখায়।
সার্ভারে হাত দেওয়ার আগে মডেল, রেজোলিউশন ও অ্যাকাউন্ট ঠিক করুন, তারপর কমান্ডটি একবার চলে।
তিনটি জয়েনের মধ্যে আসলে কোনটি চান
ডিভাইস জয়েন একটি মেশিনকে Microsoft Entra ID-তে নিবন্ধন করে শর্তসাপেক্ষ অ্যাক্সেস ও একক সাইন-অনের জন্য, এবং এটি ওয়ার্কলোডকে অন-প্রিমাইজেস ধাঁচের ডোমেইনে কোনো Kerberos টিকিট দেয় না। প্রচলিত ডোমেইন জয়েন একটি কম্পিউটার অবজেক্টকে ডিরেক্টরিতে বেঁধে দেয় এবং তাকে মেশিন অ্যাকাউন্ট, গ্রুপ পলিসি ও ডোমেইন প্রমাণীকরণ দেয়। ম্যানেজড ডোমেইন সেই দ্বিতীয় মডেলটিকে সেবা হিসেবে দেয়। নামগুলো একই রকম শোনায়, ফলাফল নয়।
শুধু শেষ দুটি সাধারণ অর্থে ডোমেইন কন্ট্রোলার জড়িত করে, এবং কেবল ম্যানেজড বিকল্পটিই সার্ভারগুলোকে আপনার প্যাচিং তালিকা থেকে সরায়।
সিদ্ধান্তটি সাধারণত পছন্দের বদলে অ্যাপ্লিকেশননির্ভর হয়। যে সফটওয়্যার LDAP বাইন্ড, SPN-সহ সার্ভিস অ্যাকাউন্ট, বা গ্রুপ পলিসি অবজেক্ট চায়, সেটি ডোমেইন মডেলে পড়ে। যে সফটওয়্যার কেবল কর্পোরেট ডিভাইসে ব্যবহারকারীর পরিচয় জানতে চায়, সেটি সাধারণত পড়ে না।
| Model | What the server gets | Where it appears |
|---|---|---|
| Entra device join | Device identity and conditional access signals | Microsoft Entra ID |
| Managed domain join | Machine account, Kerberos, group policy | The managed directory |
| Self-hosted AD DS | The same, plus every controller you operate | Your own forest |
DNS পথই ঠিক করে জয়েনটি শেষ হতে পারবে কি না
ডোমেইন জয়েন শুরু হয় ডোমেইনের কন্ট্রোলার রেকর্ডের জন্য লোকেটর অনুসন্ধান দিয়ে, তাই কোনো ক্রেডেনশিয়াল যাচাইয়ের আগেই নাম রেজোলিউশন কাজ করতে হবে। VM-কে ম্যানেজড ডোমেইনের ডিরেক্টরি ঠিকানার দিকে নির্দেশ করুন, হয় ভার্চুয়াল নেটওয়ার্কের DNS সেটিংস দিয়ে, নয় শর্তসাপেক্ষ ফরওয়ার্ডার দিয়ে যা কেবল ওই নেমস্পেসটি তাদের কাছে পাঠায়। নেমস্পেসে সীমিত ফরওয়ার্ডার সাধারণত নিরাপদ পছন্দ, কারণ এটি VM-এর বাকি রেজোলিউশনটি অপরিবর্তিত রাখে।
শুধু একটি হোস্টনেম নয়, লোকেটরটি পরীক্ষা করুন। ডোমেইন নামে পিং প্রায় কিছুই প্রমাণ করে না, অন্যদিকে ডোমেইন কন্ট্রোলার রেকর্ডের জন্য SRV কোয়েরি হয় প্রত্যাশিত লক্ষ্য ফেরায়, নয় সঙ্গে সঙ্গে ব্যর্থ হয়:
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53ডোমেইন নাম ও দুটি ঠিকানাকে আপনার ম্যানেজড ডোমেইন কনফিগারেশনের মান দিয়ে বদলে দিন; এখানকার সংখ্যাগুলো উদাহরণ। যদি কোয়েরি অন্য জোনের উত্তর ফেরায়, তাহলে VM এমন রিজলভার ব্যবহার করছে যা ম্যানেজড নেমস্পেস ফরওয়ার্ড করে না, এবং জয়েন যতবারই পুনরায় চেষ্টা করুন না কেন তা বদলাবে না।
ওয়ার্কলোডটিকে সেই সাবনেটের বাইরে রাখুন যা ম্যানেজড ডোমেইন তার নিজের সেবা সম্পদের জন্য সংরক্ষিত রাখে, এবং ডিরেক্টরি পোর্টগুলো ব্যক্তিগত পথে রাখুন। সেই পোর্টগুলোর পাবলিক এক্সপোজার কোনো শর্টকাট নয়; এটি ভিন্ন ঝুঁকি প্রোফাইলের ভিন্ন ডিজাইন।
মেশিনের আগে অ্যাকাউন্টের যোগ্যতা যাচাই হয়
যে অ্যাকাউন্ট জয়েনটি সম্পাদন করে তার লক্ষ্য কন্টেইনারে কম্পিউটার অবজেক্ট তৈরির অনুমতি দরকার, আর তাকে ম্যানেজড ডোমেইনের বিপরীতে প্রমাণীকরণ করতে সক্ষম হতে হবে। ম্যানেজড ডোমেইন তৈরির আগে তৈরি শুধু-ক্লাউড অ্যাকাউন্টে ডোমেইনের প্রয়োজনীয় পাসওয়ার্ড-উদ্ভূত উপাদান না-ও থাকতে পারে, আর পাসওয়ার্ড বদল বা রিসেট করলে তা আবার তৈরি হয়। এই খুঁটিনাটিই জয়েন ব্যর্থতার একটি শ্রেণি ব্যাখ্যা করে যা পাসওয়ার্ড সঠিক থাকলেও ভুল পাসওয়ার্ডের মতো দেখায়। রক্ষণাবেক্ষণ উইন্ডো খোলার আগেই ডোমেইনের বিপরীতে ক্রেডেনশিয়ালটি পরীক্ষা করুন।
সিঙ্ক্রোনাইজড হাইব্রিড অ্যাকাউন্টের নিজস্ব পূর্বশর্ত থাকে যা একটি দৃশ্যমান ব্যবহারকারী অবজেক্ট একা পূরণ করে না। ডিরেক্টরিতে তালিকাভুক্ত থাকা আর তা থেকে টিকিট পেতে পারা এক নয়, তাই রক্ষণাবেক্ষণ উইন্ডোর সময়ে নয়, আগে অ্যাকাউন্টটি পরীক্ষা করুন।
জয়েনের অধিকারটি সংকীর্ণভাবে অর্পণ করুন। একটি নিবন্ধন ঘটানোর জন্য প্রত্যেক ভবিষ্যৎ সার্ভার ব্যবহারকারীকে ডোমেইন অ্যাডমিনিস্ট্রেটর সদস্যপদ দেওয়া অস্থায়ী সমস্যার জন্য স্থায়ী অনুমতি।
জয়েন নিজেই একটিমাত্র কমান্ড
মডেল বেছে নেওয়া, DNS উত্তর দিচ্ছে আর অ্যাকাউন্ট যোগ্য হলে কাজটি সাধারণ Windows কাজ। প্রম্পট পাসওয়ার্ডকে স্ক্রিপ্ট ও শেল ইতিহাসের বাইরে রাখে:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThruএই রূপে কমান্ডটি নিজে মেশিন পুনরায় চালু করে না, তাই রিবুটটি রক্ষণাবেক্ষণ পরিকল্পনার অধীনে এবং পুনরুদ্ধার পথ এখনও উপলব্ধ থাকতে ঘটে। ভিন্ন ডোমেইনে ইতিমধ্যে যুক্ত সার্ভারের মাইগ্রেশন পরিকল্পনা দরকার, প্রথমটির উপরে দ্বিতীয় জয়েন নয়।
কম্পিউটার অবজেক্টটি যে কন্টেইনারে গিয়েছে এবং যে অ্যাকাউন্ট এটি তৈরি করেছে তা লিখে রাখুন। পুনর্নির্মাণের পরে মেশিনটিকে আবার যুক্ত করতে হলে দুটোই গুরুত্বপূর্ণ, আর পরবর্তীতে সার্ভার থেকে কোনোটিই স্পষ্ট নয়।
সদস্যপদ যা দেয় না
ডোমেইন সদস্যপদ কাউকে লোকাল অ্যাডমিনিস্ট্রেটর বানায় না, এবং রিমোট ডেস্কটপ বা ফাইল শেয়ার অ্যাক্সেস দেয় না। ওই অধিকারগুলো আলাদাভাবে কনফিগার হয়, আর ম্যানেজড ডোমেইনে সেগুলো তার সমর্থিত প্রশাসনিক পরিধির মধ্যেই থাকে।
নেটওয়ার্ক পথ সেটআপ ধাপ নয়, চলমান নির্ভরতা। ব্যক্তিগত সংযোগটি হারিয়ে গেলে সার্ভার ক্যাশ করা ক্রেডেনশিয়াল নিয়ে চলতে থাকে যতক্ষণ না কোনো কিছু ডিরেক্টরি চায়, আর তখন ব্যর্থতাটি পরিবর্তিত কনফিগারেশনের পাশে নয়, অ্যাপ্লিকেশন লগে আসে।
Microsoft-এর Windows Server জয়েন নির্দেশিকা ম্যানেজড-ডোমেইন ওয়ার্কফ্লোর সমর্থিত পূর্বশর্তগুলো তালিকাভুক্ত করে। উপরের তিনটি সিদ্ধান্তের সঙ্গে মিলিয়ে পড়ুন, আর যেকোনো অমিলকে এড়িয়ে যাওয়ার খুঁটিনাটি নয়, থামার কারণ হিসেবে ধরুন।