AWS Client VPN SAML და Google Workspace: უკუძახვის ნაპრალი

app_not_configured_for_user გვერდი Google Workspace-იდან მოდის და ჩნდება მანამ, სანამ გვირაბის ერთი პაკეტიც კი იქნება შეთანხმებული. სწორედ ეს თანმიმდევრობაა მთელი დიაგნოზი. კლიენტის ხელახლა დაყენება, პროფილის რედაქტირება ან მარშრუტების შემოწმება ვერ წაშლის გვერდს, რომელიც VPN-ის ბოლო წერტილს ჯერ არ უნახავს. წარუმატებელი ნაბიჯია ბრაუზერში გადაცემა იდენტობის მომწოდებელსა და მომხმარებლის საკუთარ მანქანაზე მდებარე მსმენელს შორის, და ამ გადაცემაში ზუსტად სამი რამ ღირს შემოწმებას.

წაიკითხეთ გვერდი იდენტობის მომწოდებლის განცხადებად

Google ამას აბრუნებს მაშინ, როცა SAML აპლიკაცია არ არის ჩართული იმ ანგარიშისთვის, რომელიც შევიდა. აპლიკაცია შეიძლება გამორთული იყოს, მომხმარებელი შეიძლება იყოს მიკუთვნებული ორგანიზაციული ერთეულის ან ჯგუფის გარეთ, ან სერვისის მომწოდებლის პარამეტრები შეიძლება არ შეესაბამებოდეს იმას, რასაც მოთხოვნა ითხოვდა.

არც ერთი მათგანი არ არის სერტიფიკატის, მარშრუტის ან გვირაბის პრობლემა, თუმმცა მომხმარებელმა ეს VPN კლიენტში შენიშნა.

ორი მნიშვნელობა, რომელსაც კლიენტი მიიღებს

AWS Client VPN ასრულებს სერვისის მომწოდებლის მიერ ინიცირებულ SAML გაცვლას, ამიტომ კლიენტი ხსნის ბრაუზერს, მომხმარებელი ადასტურებს თავს, და მომწოდებელი ხელმოწერილ მტკიცებას უკან უგზავნის Assertion Consumer Service-ის URL-ს. AWS-ის მიერ მოწოდებული დესკტოპ კლიენტისთვის ეს URL არის მსმენელი loopback-ზე, ჩვეულებრივ პორტი 35001, და მოსალოდნელი აუდიტორია არის Client VPN SAML აპლიკაციის ერთეულის იდენტიფიკატორი, და არა AWS კონსოლის შესვლის ერთეული.

ორივე მნიშვნელობა უნდა შეესაბამებოდეს იმას, რასაც კლიენტი ელოდება: სად იგზავნება მტკიცება და ვის მიმართ არის გამიზნული. კონსოლის SSO აპლიკაციიდან კოპირებული კონფიგურაცია შეიძლება სრულიად დამაჯერებლად გამოიყურებოდეს და მაინც არასწორ წყვილს მიმართავდეს.

აიღეთ ორივე მნიშვნელობა Client VPN SAML-ის მოთხოვნებიდან და არა AWS-ის ზოგადი ერთიანი შესვლის სახელმძღვანელოდან. კონსოლის SSO ერთეული საკმარისად მსგავსია, რომ მაცდური იყოს. ეს სხვა აპლიკაციაა სხვა აუდიტორიით, და კლიენტი უარყოფს მტკიცებას საკუთარი თავის ახსნის გარეშე. დააკოპირეთ წყვილი ერთხელ და შეინახეთ პროფილის გვერდით.

Google არ მიიღებს ჩვეულებრივ HTTP უკუძახვას

ადმინისტრატორის კონსოლი მოითხოვს HTTPS ACS URL-ს, ხოლო კლიენტის უკუძახვა არის ჩვეულებრივი HTTP loopback-ზე. ეს მნიშვნელობა საერთოდ არ შეიძლება ჩაიწეროს Workspace აპლიკაციის კონფიგურაციაში, ამიტომ ზოგი გუნდი ცდილობს საპირისპირო პროქსის, რომელიც ამთავრებს TLS-ს და გადაამისამართებს ლოკალურ მსმენელზე. ეს არ ასწორებს შეუსაბამობას: ბრაუზერი ხედავს ერთ წარმომავლობას, კლიენტი აცხადებს მეორეს, და დაბრუნებული პასუხი შეიძლება არასწორ დანიშნულებაზე მივიდეს.

მომუშავე გადაწყვეტა შუამავალი იდენტობის მომწოდებელია. შუამავალთან არსებული SAML აპლიკაცია იღებს loopback უკუძახვას და AWS აუდიტორიას, და შუამავალი ფედერაციას უკეთებს Workspace ანგარიშს ზემოთ. Google-ის HTTPS წესი დაკმაყოფილებული რჩება, და კლიენტამდე მისული მტკიცება მაინც ასახელებს მის მიერ მოსალოდნელ მისამართსა და აუდიტორიას.

ეს შუამავალი ადმინისტრაციული დამოკიდებულებაა, რომელიც ვიღაცამ უნდა ფლობდეს, აკონტროლებდეს და შეიტანოს სამსახურიდან გასვლაში. ის ასევე მეორე ადგილია, სადაც გათიშვა შესვლის წარუმატებლობად იქცევა. შეაფასეთ ის დიზაინის დაპირებამდე. თუ არავინ იქნება მისი მფლობელი, პატიოსანი პასუხია, რომ AWS კლიენტს არ შეუძლია Workspace-ის გამოყენება როგორც მისი ერთადერთი იდენტობის მომწოდებლის.

მინიჭება და ორსაფეხურიანი დადასტურება

სანამ რამეს გადააკეთებთ, დაადასტურეთ, რომ აპლიკაცია ჩართულია სწორი ორგანიზაციული ერთეულისთვის ან ჯგუფისთვის, და რომ მესამე მხარის SAML აპლიკაციებს აქვთ საკუთარი მინიჭების კონტროლი, Google-ის მხარეს არსებული აპლიკაციების სიისგან დამოუკიდებელი.

შეამოწმეთ ასევე, ჩართულია თუ არა ანგარიშზე ორსაფეხურიანი დადასტურება. Google შეიძლება მოითხოვდეს მას, სანამ SAML აპლიკაცია მომხმარებლისთვის გამოსადეგი გახდება, და თავდაპირველ თემაში ერთი პასუხი ზუსტად ასე გადაწყდა. ეს არის ყველაზე იაფი გამორიცხვა და ყველაზე გამაღიზიანებელი ბოლოს აღმოსაჩენად.

გადაამოწმეთ სუფთა სესიით

ნებისმიერი ცვლილების შემდეგ გამოსცადეთ ახალი ბრაუზერის პროფილით და სუფთა კლიენტის კონფიგურაციით. ქეშირებული მტკიცებები და ხელახლა გამოყენებული სესიები მალავს, მოხდა თუ არა გასწორება.

შემდეგ გვერდიგვერდ შეადარეთ ორი ჩანაწერი: იდენტობის მომწოდებლის აუდიტის მოვლენა და კლიენტის ჟურნალი. გვირაბის გარეშე წარმატებული შესვლა უკან უკუძახვაზე ან აუდიტორიაზე მიუთითებს. დაკავშირებული გვირაბი მიუწვდომელი რესურსით მარშრუტიზაციის ან ავტორიზაციის პრობლემაა და სულ სხვა ადგილს ეკუთვნის.

რა არ უნდა შეიცვალოს

ნუ ამოიღებთ auth-federate-ს პროფილიდან და ნუ გამორთავთ სერტიფიკატის შემოწმებებს გვერდის გვერდის ავლით. ორივე ცვლის ავთენტიფიკაციის დიზაინს და არა წარუმატებელ უკუძახვას, და ორივე ჩვეულებრივ ტყდება შემდეგი კლიენტის განახლებისას.

ამის ნაცვლად გაასწორეთ გადაცემა, და დატოვეთ შენიშვნა, რომელიც ასახელებს შუამავალს, აუდიტორიას და loopback პორტს. გვერდის შემდეგ მნახველს სამივე დასჭირდება.