এক মাস অফলাইনের পরে ডোমেইন ট্রাস্ট ব্যর্থ? আগে যাচাই করুন

একটি ল্যাপটপ ছয় সপ্তাহ VPN-এর বাইরে থাকে, ফিরে আসে, আর ব্যবহারকারী ডোমেইন অ্যাকাউন্ট দিয়ে লগইন করতে পারেন না। ত্রুটিটি ট্রাস্ট সম্পর্কের কথা বলে, তাই কেউ কম্পিউটার অ্যাকাউন্ট রিসেট করে, বা ব্যবহারকারীকে ফুল টানেলিংয়ে বাধ্য করে, আর সমস্যাটি যেন চলে যায়। দুটি কাজের কোনোটিই প্রমাণ করেনি কী ভাঙা ছিল। একটি Windows মেম্বার স্বাভাবিক মেশিন-পাসওয়ার্ড বিরতির অনেক পরে অফলাইনে থাকতে পারে এবং স্বয়ংক্রিয়ভাবে ট্রাস্ট হারায় না, তাই প্রথম কাজটি হলো পৌঁছানোর ব্যর্থতা আর প্রকৃত সিক্রেট অমিলকে আলাদা করা।

ত্রুটিটি ট্রাস্টের মতো দেখায়, কিন্তু তিনটি অবস্থা একই রকম

ব্যবহারকারী ক্যাশে করা ডোমেইন তথ্য দিয়ে সাইন ইন করতে পারেন, ওয়ার্কস্টেশনটি ডোমেইন কন্ট্রোলার খুঁজে নাও পেতে পারে, অথবা মেম্বার ও ডোমেইন মেশিন অ্যাকাউন্ট নিয়ে সত্যিই একমত নাও হতে পারে। কেবল তৃতীয়টিই কঠোর অর্থে ভাঙা ট্রাস্ট সম্পর্ক।

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

পরিচিত 30 দিনের ডিফল্ট একটি পরিবর্তন নীতি, অফলাইন মেয়াদ শেষের সময়সীমা নয়। Microsoft-এর মেশিন-অ্যাকাউন্ট পাসওয়ার্ডের ব্যাখ্যা একটি সমন্বিত পরিবর্তন প্রক্রিয়া বর্ণনা করে, এবং একটি প্রতিষ্ঠান ভিন্ন বিরতি কনফিগার করতে পারে।

একটি VPN আইকন সিকিউর চ্যানেল সম্পর্কে কিছুই প্রমাণ করে না

কোনো পরীক্ষা অর্থপূর্ণ হওয়ার আগে সংযোগটি ডোমেইন সেবা পর্যন্ত পৌঁছানোর জন্য যথেষ্ট ভালো হতে হবে। এর মানে নির্ধারিত ডোমেইন DNS রিজলভার, খুঁজে পাওয়া যায় এমন কন্ট্রোলার, পৌঁছানো যায় এমন প্রমাণীকরণ সেবা এবং Kerberos-এর জন্য যথেষ্ট কাছাকাছি একটি ঘড়ি।

ফুল টানেলিং এখানে সম্পূর্ণ বৈধ একটি ডিজাইন হতে পারে। স্প্লিট টানেলিংয়ে পরিবর্তন করা সুস্থ ডোমেইন সম্পর্কের পূর্বশর্ত নয়, আর এটিকে পূর্বশর্ত ধরা রোগনির্ণয়কে স্থাপত্য পরিবর্তনে পরিণত করে। ওয়ার্কস্টেশনটি আসলে কোন কন্ট্রোলার বেছে নেয় তা দেখুন, এবং সেই নামটি ত্রুটির সাথে রাখুন।

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

DNS সার্ভার, যে কন্ট্রোলারটি রিজলভ হয়েছে এবং সঠিক ত্রুটি পাঠ্য লিখে রাখুন। যে VPN ক্লায়েন্ট সংযুক্ত বলে জানায় সে বলে টানেল আছে, ডোমেইন পথ কাজ করছে তা নয়। যে কন্ট্রোলার Kerberos পোর্টে উত্তর দেয় কিন্তু ডিরেক্টরি পোর্টে দেয় না, সেটি ফায়ারওয়ালের ফলাফল, ট্রাস্টের নয়।

মেরামতের আগে মেম্বারটি পরীক্ষা করুন

একটি অনুমোদিত Windows ডোমেইন মেম্বারে Test-ComputerSecureChannel -Verbose হলো মেশিন ও ডোমেইনের মধ্যকার চ্যানেলের শুধু-পড়ার পরীক্ষা। এটি আপনি যে মেশিনটি তদন্ত করছেন তার প্রসঙ্গে চালান, ডোমেইন কন্ট্রোলার থেকে নয়, কারণ তার ভূমিকা ও পুনরুদ্ধারের নিয়ম ভিন্ন। পাস বা ফেল শব্দের বদলে আউটপুট ও এক্সিট স্ট্যাটাস সংরক্ষণ করুন। যদি সেই বিল্ডে cmdlet না থাকে, তবে মডিউলটি আলাদা সমস্যা।

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

ঘটনার আশপাশে মেম্বারে এবং সংশ্লিষ্ট কন্ট্রোলারে Netlogon ইভেন্টগুলো মিলিয়ে দেখুন। মেশিনের নাম, উৎস ঠিকানা, সময় এবং অ্যাকাউন্ট পরিবর্তনের যে কোনো প্রমাণ সংরক্ষণ করুন। অন্য ব্যবহারকারীর সফল লগইন, বা একটি সুস্থ কন্ট্রোলার ড্যাশবোর্ড, এই মেশিনের বিনিময়ের বিকল্প হতে পারে না।

আপনি যেটি প্রমাণ করেছেন কেবল সেই সম্পর্কটিই মেরামত করুন

একবার সংযোগ স্থিতিশীল হলে এবং একজন প্রশাসক নিশ্চিত করলে যে মেরামত উপযুক্ত, অনুমোদিত শংসাপত্রসহ cmdlet-এর -Repair মোড হলো মেম্বার ওয়ার্কস্টেশনের জন্য একটি সমর্থিত কাজ। এটি সম্পর্কটি পরিবর্তন করে, এবং এটি আরেকটি শুধু-পড়ার পরীক্ষা নয়।

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

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

ব্যর্থতা ফিরে এলে কী দেখবেন

যদি ব্যর্থতা ফিরে আসে, একই অ্যাকাউন্ট আবার রিসেট করার বদলে রোলব্যাক, নকল পরিচয় এবং অ্যাকাউন্ট পরিবর্তনের সময় দেখুন। পুনরুদ্ধার করা ইমেজ, স্ন্যাপশট, ক্লোন করা মেশিন পরিচয়, বা অন্যত্র করা কম্পিউটার-অ্যাকাউন্ট রিসেট—সবই তদন্তের যোগ্য।

সাময়িক সফল রিসেট উপকারী পুনরুদ্ধার প্রমাণ, কিন্তু এটি প্রমাণ নয় যে একটি বিরতিহীন VPN মূল অমিলের কারণ ছিল। পরবর্তী ঘটনাটিই আপনাকে বলবে কারণটি আদৌ সরানো হয়েছিল কি না।

কন্ট্রোলার, DNS সার্ভার এবং পরীক্ষার আউটপুট টিকিটে লিখুন। এই রেকর্ডই একটি প্রকৃত ট্রাস্ট ব্যর্থতাকে এমন ল্যাপটপ থেকে আলাদা করে যা সহজভাবে ডোমেইন খুঁজে পায়নি।