Ο έλεγχος ταυτότητας LDAP του OpenVPN λειτουργεί αλλά ο έλεγχος ομάδας αποτυγχάνει: πού να κοιτάξετε

Ο έλεγχος ταυτότητας μπορεί να περάσει ενώ ο έλεγχος ομάδας απορρίπτει όλους. Εξετάστε με τη σειρά το μπλοκ 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 είναι το δεύτερο bit του 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 επιστρέφει κενό είναι γεγονός του καταλόγου, όχι σφάλμα της προσθήκης, και ένας λογαριασμός που εξακολουθεί να ταυτοποιείται μετά την απενεργοποίηση σημαίνει ότι στο φίλτρο λείπει η συνθήκη ελέγχου λογαριασμού. Διορθώστε πρώτα αυτή την απόδειξη και μετά ξανατρέξτε τη δοκιμή των τριών λογαριασμών. Κρατήστε τη γραμμή καταγραφής που ονόμασε το αποτυχημένο βήμα δίπλα στην αλλαγή διαμόρφωσης, ώστε ο επόμενος να μπορεί να ξεχωρίσει την εξουσιοδότηση από τον έλεγχο ταυτότητας χωρίς να επαναλάβει την αναζήτηση.

Σχετικά άρθρα