VPN পরিবর্তনের পরে Outlook সাইন-ইন: Entra আসলে কী দেখে

VPN পরিবর্তনের পরে Outlook আবার সাইন-ইন চাইতে শুরু করে, অথচ মেইলবক্সের পাসওয়ার্ড বদলায়নি। Microsoft Entra ক্লাউড সেবাটি যে নেটওয়ার্ক ঠিকানা দেখে তা দিয়ে অনুরোধটি মূল্যায়ন করে, এবং একটি VPN অ্যাকাউন্ট স্পর্শ না করেই সেই পর্যবেক্ষণ বদলে দিতে পারে। প্রম্পটটি একটি নীতির ফলাফল, অগত্যা ক্রেডেনশিয়াল ব্যর্থতা নয়।

দুটি সেশন জড়িত: VPN সেশন এবং মেইলবক্স টোকেন। তারা ভিন্ন সিস্টেমে প্রমাণীকরণ করে।

সাইন-ইনের সময় Entra কী মূল্যায়ন করে

সাইন-ইনের সময় Entra কনফিগার করা শর্তগুলির বিপরীতে অনুরোধটি মূল্যায়ন করে: নেটওয়ার্ক অবস্থান, মাল্টি-ফ্যাক্টর অবস্থা, ডিভাইস সম্মতি এবং যেকোনো সেশন নিয়ন্ত্রণ। নেটওয়ার্ক শর্তটি সেবা যে ঠিকানা দেখে তা ব্যবহার করে, যা ল্যাপটপের স্ট্যাটাস পৃষ্ঠার ঠিকানার সঙ্গে সবসময় মেলে না। তাই কর্পোরেট রেঞ্জে বিশ্বাস করা একটি নীতি এমন ক্লায়েন্টকে প্রত্যাখ্যান করতে পারে যার ট্রাফিক এখন অন্য জায়গা দিয়ে বেরোচ্ছে। এটি সঠিক মূল্যায়ন, কোনো ত্রুটি নয়।

ফলাফলটিকে পাসওয়ার্ড সমস্যা হিসেবে পড়ার আগে নীতি সিদ্ধান্ত হিসেবে পড়ুন।

VPN সেশন ও মেইলবক্স টোকেন আলাদা

একটি গেটওয়ে VPN ক্রেডেনশিয়াল গ্রহণ করা কেবল প্রমাণ করে যে নেটওয়ার্ক সেশনটি বিদ্যমান। এটি Exchange Online মেইলবক্স অ্যাকাউন্ট, ডিভাইস বা বর্তমান অ্যাক্সেস নীতি গ্রহণ করেছে কিনা সে বিষয়ে কিছু বলে না।

একটি নতুন টোকেন অনুরোধ Conditional Access প্রয়োজনীয়তার মুখোমুখি হয়ে বৈধ অতিরিক্ত প্রমাণীকরণ ধাপ তৈরি করতে পারে। অন্তহীন ব্যর্থ প্রম্পট একটি ভিন্ন ফলাফল। কোনো পাসওয়ার্ড রিসেট করার আগে আপনার কোনটি আছে তা নির্ধারণ করুন।

নিরন্তর অ্যাক্সেস মূল্যায়ন আরেকটি পথ যোগ করে: একটি রিসোর্স মেয়াদোত্তীর্ণ না হওয়া টোকেন প্রত্যাখ্যান করে পুনর্মূল্যায়ন চাইতে পারে। এর অর্থ এই নয় যে প্রতিটি নেটওয়ার্ক পরিবর্তন প্রতিটি Outlook ক্লায়েন্টকে সাইন-ইন করতে বাধ্য করে।

ক্লাউড আসলে কোন ঠিকানা দেখে

সংযুক্ত VPN আইকন প্রতিটি ক্লাউড অনুরোধের পাবলিক উৎস প্রতিষ্ঠা করে না। স্প্লিট টানেল, IPv6 পথ বা প্রক্সি দিয়ে বেরোনো ট্রাফিক Entra-র কাছে Exchange Online-এর চেয়ে ভিন্ন ঠিকানা উপস্থাপন করতে পারে। ব্রাউজার যাচাই সম্পূর্ণ ভিন্ন পথ অনুসরণ করতে পারে।

প্রকৃত সাইন-ইন পর্যবেক্ষণগুলিকে অভিপ্রেত নেটওয়ার্ক নকশার সঙ্গে তুলনা করুন এবং স্থাপনা যেখানে প্রকাশ করে সেখানে রিসোর্স-দেখা ঠিকানাটিও অন্তর্ভুক্ত করুন।

পরিবহন ব্যর্থতাগুলিকে নীতি প্রত্যাখ্যান থেকে আলাদা রাখুন। অবরুদ্ধ প্রমাণীকরণ এন্ডপয়েন্ট, TLS ব্যর্থতা বা ভাঙা প্রক্সি পথ সাইন-ইন সমস্যার মতো দেখায়, কিন্তু তা Conditional Access সিদ্ধান্ত নয়। এই পার্থক্যই ঠিক করে আপনি টেন্যান্টের নিয়ম বদলাবেন নাকি পথ ঠিক করবেন। কিছু সম্পাদনার আগে এটি সংরক্ষণ করুন।

একটি প্রম্পটকে একটি সাইন-ইন ইভেন্টের সঙ্গে সম্পর্কিত করুন

একবারে একটি চেষ্টা রেকর্ড করুন: সময় ও তার সময় অঞ্চল, Outlook বিল্ড, মেইলবক্স অ্যাকাউন্ট, VPN অবস্থা এবং সঠিক ত্রুটি। ত্রুটি যদি সমস্যা সমাধানের বিবরণ প্রকাশ করে, পাসওয়ার্ড বা টোকেন কপি না করে সম্পর্ক স্থাপনের শনাক্তকারীটি রাখুন।

একজন অনুমোদিত প্রশাসক তখন Entra সাইন-ইন লগে মিলে যাওয়া ইভেন্টটি খুঁজে ক্লায়েন্ট, রিসোর্স, প্রমাণীকরণের বিবরণ ও নীতি ফলাফল পরিদর্শন করতে পারেন।

নীতি সংশোধন করুন, তারপর পথটি পরীক্ষা করুন

লগ এন্ট্রিটি মনোযোগ দিয়ে পড়ুন। সফল ব্রাউজার লগইন অগত্যা আপনার খোঁজা Outlook অনুরোধ নয়, এবং দর্শকের সময় অঞ্চল আপনার থেকে ভিন্ন হতে পারে। ব্যাকগ্রাউন্ড টোকেন কার্যকলাপও পুনর্গঠনে অন্তর্ভুক্ত।

যখন কোনো নীতি প্রম্পটটির ব্যাখ্যা দেয়, তখন অনুমোদিত পরিচয়, ডিভাইস বা নেটওয়ার্ক ব্যবস্থাটি তার মালিকের সঙ্গে ঠিক করুন। পুরো প্রোভাইডার রেঞ্জে বিশ্বাস করা বা প্রম্পট চুপ করাতে MFA বন্ধ করা মেরামত নয়।

সাইন-ইন ফ্রিকোয়েন্সিও ভুল পাসওয়ার্ড ছাড়াই পুনঃপ্রমাণীকরণ বাধ্য করতে পারে। সংশোধনের পরে একটি নতুন অনুমোদিত মেইলবক্স সিঙ্ক বা প্রেরণ দিয়ে পথটি পরীক্ষা করুন; ক্যাশ করা বার্তা পড়া কিছুই প্রমাণ করে না। Conditional Access সমস্যা সমাধান পদ্ধতি লগ সম্পর্ক স্থাপন বর্ণনা করে।