Outlook-ში შესვლა VPN-ის შეცვლის შემდეგ: რას ხედავს Entra სინამდვილეში

Outlook VPN-ის შეცვლის შემდეგ ისევ ითხოვს შესვლას, ხოლო უჯრის პაროლი არ შეცვლილა. 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-ის ხარვეზის აღმოფხვრის პროცედურა აღწერს ჟურნალების კორელაციას.