FortiGate VPN MFA: مقامی ٹوکن، RADIUS یا SAML؟

ہر FortiGate VPN MFA ڈیزائن سب سے پہلے ایک سوال کا جواب دیتا ہے: دوسرے عنصر کی تصدیق کون کرتا ہے؟ گیٹ وے خود یہ کام مقامی ٹوکن یا ای میل شدہ کوڈ سے کر سکتا ہے، RADIUS بیک اینڈ اسے نافذ کر کے چیلنج واپس دے سکتا ہے، یا SAML شناختی فراہم کنندہ پوری کارروائی براؤزر میں سنبھال سکتا ہے۔ ان میں سے ہر ایک مختلف لاگ ان ترتیب، مختلف ناکامی کی علامت اور مختلف ریکوری طریقہ پیدا کرتا ہے، اور ان کے درمیان کمانڈ بلاک کاپی کرنے سے ایسی ترتیب بنتی ہے جو قابلِ فہم لگتی ہے اور کسی کی تصدیق نہیں کرتی۔ یہ ایک میکینزم مضمون ہے: ہر ڈیزائن لاگ ان کے دوران اصل میں کیا کرتا ہے، اور کہاں ٹوٹتا ہے۔

لاگ ان کی کارروائی طے کرتی ہے کہ عنصر کا مالک کون ہے

پہلے دو ڈیزائنوں میں FortiGate ہی انحصار کرنے والا فریق ہے۔ یہ اسناد جمع کرتا ہے، فیصلہ کرتا ہے کہ دوسرا عنصر درکار ہے یا نہیں، اور اسے مقامی طور پر یا چیلنج کے ذریعے تصدیق کرتا ہے۔ تیسرے ڈیزائن میں گیٹ وے تصدیق کنندہ رہنا چھوڑ کر ریلے بن جاتا ہے: یہ کلائنٹ کو شناختی فراہم کنندہ کی طرف بھیجتا ہے، ایک دعویٰ وصول کرتا ہے، اور دعویٰ شدہ شناخت کو صارف اور گروپ سے جوڑتا ہے۔ RADIUS ڈیزائن میں یہ درمیان میں ہے اور ایسے بیک اینڈ کے ساتھ درخواست جواب کا تبادلہ چلاتا ہے جس کے پاس پالیسی ہے۔

یہی فرق طے کرتا ہے کہ آپ کون سا ثبوت جمع کر سکتے ہیں۔ جب گیٹ وے تصدیق کرتا ہے تو اس کا اپنا ڈیبگ آؤٹ پٹ بتاتا ہے کہ کیا ہوا۔ جب شناختی فراہم کنندہ تصدیق کرتا ہے تو گیٹ وے صرف یہ جانتا ہے کہ ایک دعویٰ آیا، اور ”کیا MFA واقعی درکار تھا“ کا جواب فراہم کنندہ کے لاگز میں ہوتا ہے، فائر وال کے نہیں۔ غلط لاگ پڑھنا کسی ایسی رول آؤٹ کی غلط تشخیص کی سب سے عام وجہ ہے جو بالکل ویسے ہی چل رہا ہے جیسے ڈیزائن کیا گیا تھا۔ سروس خود بھی کارروائی کو محدود کرتی ہے: FortiOS 7.6.3 SSL VPN ٹنل موڈ ہٹا دیتا ہے اور IPsec کو ترجیح دیتا ہے، جبکہ ویب موڈ معاون ماڈلز پر Agentless VPN کے طور پر جاری رہتا ہے، لہٰذا ایک سروس پر ثابت شدہ کارروائی خودبخود دوسری پر دستیاب نہیں ہوتی۔

مقامی تصدیق: ٹوکن اور ای میل شدہ کوڈ

FortiGate کے زیرِ انتظام عناصر صارف آبجیکٹ سے منسلک ہوتے ہیں۔ FortiToken یا دستاویزی ٹوکن انٹیگریشن کے لیے اندراج، معاون تصدیقی کارروائی، جہاں لاگو ہو لائسنس، اور متبادل کا طریقہ درکار ہے۔ ای میل شدہ کوڈ کے لیے کام کرنے والا SMTP راستہ اور ایسا میل باکس درکار ہے جو صارف ٹنل وجود میں آنے سے پہلے حاصل کر سکے، جو ایسی انحصار ہے جس کا کرپٹوگرافی سے کوئی تعلق نہیں اور سب کچھ اس سے ہے کہ کوئی لاگ ان کر سکے۔

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

ای میل کی ترسیل تصدیق کی دستیابی کا حصہ ہے۔ صرف VPN کے ذریعے قابلِ رسائی میل باکس ایسا حلقہ بناتا ہے جو کسی کے لیے حل نہیں ہوتا، اور ترسیل میں تاخیر، کوڈ کی مدت اور ریموٹ تصدیق کی ٹائم آؤٹ تین الگ پابندیاں ہیں۔ ایک کو بڑھانا ناقابلِ رسائی میل باکس کی مرمت نہیں کرتا، اور جس ڈیزائن نے یہ حلقہ کبھی آزمایا نہ ہو وہ چھٹی کے بعد پہلی پاس ورڈ ری سیٹ میں اسے دریافت کرے گا۔

یقین دہانی کے تقاضے بھی یہیں آتے ہیں، مصنوع کی انتخاب سے پہلے۔ NIST SP 800-63B ای میل کو آؤٹ آف بینڈ تصدیق کے لیے ناقابلِ قبول سمجھتا ہے، لہٰذا مطابقت کا دعویٰ کرنے والا تعیناتی ای میل شدہ کوڈ کو دوسرے عنصر کے طور پر استعمال نہیں کر سکتا، چاہے وہ کتنا ہی آسان ہو۔ آلات میں کوئی خصوصیت موجود ہونا یہ بیان نہیں کہ وہ خصوصیت کسی معیار کو پورا کرتی ہے۔

RADIUS: گیٹ وے پوچھتا ہے، بیک اینڈ فیصلہ کرتا ہے

RADIUS کے ساتھ، FortiGate اسناد ایسے بیک اینڈ کو بھیجتا ہے جس کے پاس عنصر کی پالیسی ہے۔ تبادلہ سادہ قبول یا مسترد ہو سکتا ہے، یا اس میں ایسا چیلنج شامل ہو سکتا ہے جس کا جواب کلائنٹ کو دینا ہو، یعنی VPN سروس اور کلائنٹ دونوں کو اس چیلنج کی شکل کی حمایت کرنی ہوگی۔ جو بیک اینڈ پش منظوری نافذ کرتا ہے اور جو کلائنٹ صرف پاس ورڈ کے ساتھ چھ ہندسوں کا کوڈ جوڑنا جانتا ہے، وہ درمیان میں نہیں ملیں گے۔

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

ٹنل کو قصوروار ٹھہرانے سے پہلے بیک اینڈ کو الگ سے آزمائیں۔ اگر authserver ٹیسٹ کامیاب ہو اور VPN لاگ ان نہ ہو، تو فرق اسناد میں نہیں بلکہ چیلنج کی ہینڈلنگ میں ہے، اور گیٹ وے کے تصدیقی ڈیمن کا ڈیبگ وہیں دکھاتا ہے:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: براؤزر گیٹ وے سے نکل جاتا ہے

SAML ڈیزائن میں کلائنٹ کو شناختی فراہم کنندہ کی طرف بھیجا جاتا ہے، وہاں تصدیق ہوتی ہے، اور یہ ایسا دعویٰ لے کر واپس آتا ہے جسے گیٹ وے اعتماد کے تعلق اور گروپ میپنگ کے مطابق جانچتا ہے۔ گیٹ وے پاس ورڈ یا دوسرا عنصر کبھی نہیں دیکھتا، جو بیک وقت سیکیورٹی بہتری اور آپریشنل پیچیدگی ہے: ناکامی اب ایسے براؤزر سیشن میں ہوتی ہے جسے فائر وال معائنہ نہیں کر سکتا۔

دعویٰ قبول کرنا یہ ثابت نہیں کرتا کہ فراہم کنندہ نے اس سائن اِن کے لیے MFA لازمی قرار دیا تھا۔ ایسی فراہم کنندہ پالیسی جو کچھ ایپلیکیشنز پر MFA لاگو کرتی ہے اور کچھ پر نہیں، بالکل وہی لاگ ان دے گی جو آپ نے مانگا اور وہ یقین دہانی ہرگز نہیں جو آپ نے فرض کیا۔ اس مخصوص ایپلیکیشن کے لیے فراہم کنندہ کی پالیسی دیکھیں، اور یہ بھی دیکھیں کہ FortiGate گروپس سے میپ ہونے والے گروپ دعوے کسی بھی طرف نام بدلنے کے بعد بھی میل کھاتے ہیں۔

کلائنٹ کی حمایت یہاں سب سے زیادہ اہمیت رکھتی ہے۔ کچھ VPN کلائنٹ براؤزر کی حوالگی قدرتی طور پر سنبھالتے ہیں، کچھ سسٹم براؤزر کھولتے ہیں، اور ہیڈ لیس یا کمانڈ لائن کلائنٹ اس عمل کو مکمل ہی نہیں کر سکتے۔ پروفائل شائع کرنے سے پہلے اسی کلائنٹ سے آزمائیں جو صارفین واقعی چلاتے ہیں اور انہی پلیٹ فارمز پر جو وہ واقعی استعمال کرتے ہیں۔

ریکوری میکینزم کا حصہ ہے

اوپر کے ہر ڈیزائن میں ایک ایسی انحصار ہے جو ایک وقت میں ایک صارف کے لیے ناکام ہو سکتی ہے: ناقابلِ رسائی میل باکس، گم شدہ ٹوکن، چیلنج مسترد کرنے والا بیک اینڈ، مقفل شناختی فراہم کنندہ اکاؤنٹ۔ ابھی فیصلہ کریں کہ رسائی کون بحال کر سکتا ہے، کس معاون طریقہ سے، اور پوچھنے والے شخص کی کیا تصدیق ہوگی۔ VPN راستے سے الگ رکھا گیا ہنگامی مقامی منتظم اکاؤنٹ ایک کنٹرول ہے؛ اور غیر واضح صرف پاس ورڈ والا بائی پاس ایسا واقعہ ہے جس کا دریافت ہونا باقی ہے۔

پھر رول آؤٹ سے پہلے تین لاگ ان آزمائیں: عام والا، مسترد یا میعاد ختم شدہ عنصر والا، اور منظور شدہ گمشدہ تصدیق کنندہ ریکوری۔ ریکارڈ کریں کہ ہر ایک کس لاگ میں دکھائی دیتا ہے۔ یہی ریکارڈ ”MFA فعال ہے“ کو ایسے ڈیزائن میں بدلتا ہے جسے کوئی اور چلا سکے۔