OpenVPN-ის LDAP ავთენტიფიკაცია მუშაობს, მაგრამ ჯგუფის შემოწმება ვერ ახერხებს: სად ვეძებოთ

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

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

უარი მიიღეთ როგორც ავტორიზაციის პასუხი

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

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

გადაწყვიტეთ, წევრობა ფილტრში ცხოვრობს თუ ჯგუფის ბლოკში

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

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

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

ბრმა წერტილი საერთოა: წევრობის უბრალო შედარება ჩადგმულ ჯგუფებს არ ხსნის, ამიტომ ანგარიში, რომლის წვდომაც მშობელი ჯგუფის მეშვეობით მოდის, ვერ ახერხებს, მაშინ როცა კონსოლი ჯერ კიდევ აჩვენებს წევრობას. Active Directory ჯგუფზე ავლენს member-ს, სხვა სქემები იყენებენ uniqueMember-ს და არასწორ ატრიბუტზე მითითება შეცდომის ნაცვლად ცარიელ შედეგს აბრუნებს.

აირჩიეთ ბოლო წერტილი, რომელიც ჯგუფის ობიექტს შეიცავს

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

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

ანგარიშის მდგომარეობა და ძიების არე შეინახეთ საკუთარ ველებში

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

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

შედეგი სამი ანგარიშით დაამტკიცეთ

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

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

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

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

დაკავშირებული სტატიები