VPN სერტიფიკატი LDAP მონაკვეთს არ იცავს

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

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

ორი კავშირი, ორი ნდობის გადაწყვეტილება

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

ამიტომაც მარცხი ჩუმია და არა ხმამაღალი. კარიბჭე, რომელიც არასდროს ამოწმებს დირექტორიის სერტიფიკატს, მაინც სწორად ავთენტიფიცირებს მომხმარებლებს; ის უბრალოდ ავთენტიფიცირებს მათ არხზე, რომელიც არ გადაუმოწმებია.

StartTLS და LDAPS, განზრახ არჩეული

StartTLS იხსნება როგორც ჩვეულებრივი LDAP და ადგილზევე ახლდება, ჩვეულებრივ პორტზე 389. LDAPS TLS-ს კავშირთან ერთად იწყებს, ჩვეულებრივ 636-ზე. ორივე ლეგიტიმურია და ადაპტერმა უნდა შეესაბამებოდეს იმას, რასაც დირექტორია გვთავაზობს. StartTLS-ის მოთხოვნა განსხვავდება მისი ცდისა და გაგრძელებისგან, როცა განახლება ვერ ხერხდება, და სწორედ ამ სხვაობაში შეიძლება bind პაროლი გაჟონოს. დააყენეთ მკაცრი რეჟიმი და ნუ დაუშვებთ დაუცველ სარეზერვო გზას პაროლიანი bind-ისთვის.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ პარამეტრი მთელი აზრია: მოთხოვნა ვერ სრულდება, ნაცვლად იმისა, რომ განახლების გარეშე ჩუმად გაგრძელდეს. ამ ხაზში მოცემული სახელები და ანგარიშები მაგალითებია. OpenLDAP-ის TLS დოკუმენტაცია მოიცავს იმ ნდობის პარამეტრებს, რაც ამის უკან დგას.

რომელ ნდობის საცავს კითხულობს LDAP კლიენტი?

OpenLDAP-ის კლიენტის ბიბლიოთეკა საკუთარ ნდობის კონფიგურაციას კითხულობს, იქნება ეს სისტემური ფაილიდან თუ დანამატის სპეციფიკური პარამეტრიდან. VPN-ის CA დირექტივა ეხება VPN პირებს და არ არის მტკიცებულება, რომ LDAP ბიბლიოთეკა იმავე ფაილს კითხულობს. გამოიყენეთ დირექტორიის ის ჰოსტის სახელი, რომელსაც სერტიფიკატი რეალურად ფარავს, პლუს ის გამომცემი ჯაჭვი, რომელსაც ბიბლიოთეკა ენდობა. Active Directory-ში განათავსეთ დირექტორიის სერვისის სერტიფიკატი სერვერის ავთენტიფიკაციის სწორი გამოყენებით, ნაჩვენები სახელიდან მსჯელობის ნაცვლად.

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

bind ანგარიში ცალკე პრობლემად რჩება

ტრანსპორტის დაცვა არ ამცირებს იმას, რისი გაკეთებაც bind ანგარიშს შეუძლია. დირექტორიის ძიების არეალი, ჯგუფური ავტორიზაცია და სერვისის ანგარიშის უფლებები ცალკე გადაწყვეტილებებია, და ფართო bind ანგარიში ფართოდ რჩება TLS-ის ჩართვის შემდეგაც. გამოიყენეთ ყველაზე ვიწრო სერვისის ანგარიში და ძიების ბაზა, რაც ინტეგრაციას სჭირდება, და ჩაწერეთ საბოლოო წერტილი, TLS რეჟიმი, ნდობის მფლობელი და განახლების პროცესი VPN კონფიგურაციასთან ერთად.

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

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