NetExtender შედის, მაგრამ წვდომა არ არის: SonicWall ლოკალური + LDAP
NetExtender უკავშირდება, მაგრამ არაფერი პასუხობს: გამოყავით SonicWall-ის ავთენტიფიკაცია, SSL VPN სერვისის წევრობა და VPN წვდომის ნებართვები ლოკალური და LDAP მომხმარებლებისთვის.
შესვლა წარმატებით სრულდება, გვირაბი ამოდის და firewall-ის უკან არაფერი პასუხობს. SonicWall SSL VPN -ზე ეს ნიმუში ჩვეულებრივ ნიშნავს, რომ ანგარიშმა ავთენტიფიკაცია გაიარა და შემდგომი ორი ნებართვიდან ერთზე გაჩერდა: SSL VPN სერვისში მიღება, ან რესურსზე მისასვლელი ნებართვა. შერეული ლოკალური და LDAP ანგარიშები ამძიმებს სიტუაციას, რადგან ორი საცავი ამ ნებართვებს სხვადასხვა გზით აღწევს. სიმპტომი კლიენტის მხრიდან იდეალურად იგივეა, ამიტომ ფენები განზრახ უნდა გაიყოს.
სიმპტომი და მის უკან სამი ნებართვა
მომხმარებლის სახელსა და მისაწვდომ სერვერს შორის სამი დამოუკიდებელი გადაწყვეტილება დგას. ავთენტიფიკაციის მეთოდი წყვეტს, მიიღება თუ არა მონაცემები და რომელი საცავი იღებს. SSL VPN სერვისის წევრობა წყვეტს, შეუძლია თუ არა ამ იდენტობას SSL VPN-ის გამოყენება საერთოდ. VPN წვდომის სია წყვეტს, სესიას რომელ კერძო დანიშნულებებზე შეუძლია მისვლა. ერთის გავლა არაფერს ამბობს შემდეგ ორზე.
მომხმარებელი, რომელიც ავთენტიფიცირდება, მაგრამ SSL VPN სერვისის ჯგუფში არ არის, ხედავს კავშირს, რომელიც მყარდება და შემდეგ არაფერს გადააქვს, ხოლო firewall-ის ჟურნალი აჩვენებს მიღებულ შესვლას და არა წარუმატებლობას. ეს არის შემთხვევა, რომლის სწრაფად ცნობა ღირს, რადგან გადაწყვეტა ჯგუფის წევრობაა და არა პაროლის აღდგენა.
მომხმარებელი, რომელიც მიიღება, მაგრამ რესურსები არ აქვს, ხედავს სესიას, რომელიც უკავშირდება და არსად სასარგებლოდ არ მიდის. მხარდაჭერის თვალით ორივე გატეხილ გვირაბს ჰგავს, და ორივე კონფიგურაციაა და არა კავშირი.
დომენის ველი დირექტორია არ არის
NetExtender დომენს ითხოვს, და ეს ველი Active Directory-ის საძიებო ბაზა არ არის. ნაგულისხმევ განლაგებაში ველი უნდა უდრიდეს იმ SSL VPN მომხმარებლის დომენს, რომელიც firewall-მა დააკონფიგურირა, და ამისთვის დოკუმენტირებული ნაგულისხმევი მნიშვნელობა LocalDomain. შედარება დიდ და პატარა ასოებს არჩევს, ამიტომ სხვა ასოს ზომით აკრეფილი მნიშვნელობა მარცხდება მაშინაც კი, როცა ანგარიში სწორია.
როცა ავთენტიფიკაციის დაყოფა კონფიგურირებულია, დანაყოფების სახელები ირჩევენ გარე ავთენტიფიკაციის კონტექსტს, ხოლო კონფიგურირებული ნაგულისხმევი თავის როლს ინარჩუნებს. ორივე განლაგებაში კლიენტის მხარის დომენის ლეიბლი მომხმარებლის სახელის ნაწილად არ გადაეცემა LDAP-ს ან RADIUS-ს, ამიტომ მას დირექტორიის ძიების წარმართვა არ შეუძლია.
სამი სტრიქონი ცალ-ცალკე შეინახეთ თქვენს ჩანაწერებში: კომპანიის DNS სუფიქსი, LDAP ძიების ბაზა და NetExtender-ის დომენის ლეიბლი. ისინი ერთნაირად გამოიყურება და არც ერთი არ ცვლის მეორეს. დააკოპირეთ ოპერატორის მნიშვნელობა ამ ინსტალაციისთვის და არა სხვა firmware-ის ვერსიაზე ფორუმის პოსტიდან მნიშვნელობა.
მიღება და რესურსზე წვდომა ცალკე ნებართვებია
ლოკალურ ანგარიშებს სჭირდებათ SSL VPN სერვისის ჯგუფის წევრობა, სანამ სერვისი მიიღებს მათ. დირექტორიის ანგარიშები აღწევენ იმავე ჯგუფს მხარდაჭერილი ჯგუფების რუკების სამუშაო ნაკადით, რაც ნიშნავს, რომ LDAP ჯგუფის კავშირი უნდა დაკონფიგურირდეს და შემდეგ შემოწმდეს როგორც ეფექტური წევრობა, და არა დირექტორიის მხრიდან ნავარაუდევი.
რესურსზე წვდომა შემდეგ მოდის, მომხმარებელზე ან ჯგუფზე VPN წვდომის ქვეშ. მიეცით კონკრეტული ქვექსელები და სერვისები, რომლებიც როლს სჭირდება, და დაუპირისპირდით მთელი LAN-ის მიცემის მოკლე გზას, რადგან ერთი აპლიკაციაა საჭირო. სესიის მარშრუტები, წვდომის წესები და დანიშნულების სერვისის ნებართვები ყველა უნდა შეესაბამებოდეს ამ ფარგლებს.
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
კლიენტზე არსებული მარშრუტი დანიშნულებას არჩევადს ხდის და არ ანიჭებს უფლებას. SSL VPN ჯგუფის წევრობა ანგარიშს firewall-ის ადმინისტრატორადაც არ აქცევს, და ის არ უნდა განიხილოს როგორც ზოგადი პრივილეგიის მინიჭება.
ორი იდენტობა, თითოეულს ოთხი შემოწმება
სცადეთ ერთი ლოკალური და ერთი დირექტორიის ანგარიშით, ორივე ვიწროდ უფლებამოსილი და ორივე ტესტურ ანგარიშად დოკუმენტირებული. თითოეულისთვის ჩაწერეთ შესვლის მიმღები ავთენტიფიკაციის წყარო, ეფექტური ჯგუფები, მინიჭებული რესურსზე წვდომა და ერთი დაშვებული აპლიკაციის ოპერაცია. ოთხი შემოწმება, ორი საცავი და წერილობითი შედეგი ყოველი კომბინაციისთვის.
შემდეგ სცადეთ უარყოფითი შემთხვევები: რესურსი, რომელზეც ანგარიშს არ უნდა მიუწვდებოდეს, და ანგარიში, რომელიც დაუყოვნებლივ უნდა უარყოს. დიზაინი, რომელიც მხოლოდ დადებით გზას ამტკიცებს, ხშირად ღიად ტოვებს მეორე შესასვლელს, განსაკუთრებით მაშინ, როცა იგივე მოკლე მომხმარებლის სახელი ორივე საცავშია. გამორთეთ დირექტორიის ანგარიში და დაადასტურეთ, რომ ლოკალური ჩუმად არ აგრძელებს მუშაობას.
გადახედეთ განმეორებულ სახელებს გაშვების ნაწილად, და არა ინციდენტის შემდეგ. ერთი ადამიანი ორ საცავში ერთდროულად მხარდაჭერის მოხერხებულობა და აუდიტის პრობლემაა, და firewall სიამოვნებით ავთენტიფიცირებს იმას, რაც თქვენ დააკონფიგურირეთ.
აღდგენის გზა ვიწრო შეინახეთ
შეინარჩუნეთ MFA პოლიტიკა თითოეული ანგარიშის კლასისთვის, ნაცვლად იმისა, რომ ლოკალური ანგარიშები გაათავისუფლოთ მისგან. თუ ლოკალური ანგარიშები დირექტორიის შეფერხებისთვის დამტკიცებულ აღდგენის გზას გვაძლევს, შეზღუდეთ ეს გზა დასახელებული ადმინისტრატორებით და ამუშავეთ განზრახ, რადგან თითოეული თანამშრომლისთვის ლოკალური საგანგებო ანგარიში მეორე ავთენტიფიკაციის სისტემაა უფრო სუსტი ზედამხედველობით.
ჩაწერეთ კლიენტის დომენი, ავთენტიფიკაციის წყარო და ეფექტური წვდომა ერთსა და იმავე ჩანაწერში. შემდეგ ადმინისტრატორს შეეძლება მუშა შერეული ანგარიშების დიზაინის გამეორება, დომენის სტრიქონების ცდის ნაცვლად, სანამ შესვლა წარმატდება.