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 جوڑنے کی رہنمائی منظم ڈومین ورک فلو کے لیے معاون پیشگی شرائط کی فہرست دیتی ہے۔ اسے اوپر کے تین فیصلوں کے سامنے پڑھیں، اور کسی بھی عدم مطابقت کو بچنے کی تفصیل نہیں بلکہ رکنے کی وجہ سمجھیں۔