Γιατί το SQL Server μέσω VPN εξακολουθεί να πέφτει σε NTLM;

Η σύνδεσή σας λειτουργεί, η είσοδος γίνεται δεκτή και το SQL Server χρησιμοποιεί NTLM ενώ όλοι περίμεναν Kerberos. Αυτό το αποτέλεσμα δεν είναι σφάλμα VPN, επειδή η σήραγγα παρέχει μόνο μια διαδρομή· το σχήμα το καθόρισαν το όνομα που ζήτησε ο πελάτης, η κύρια αρχή που είναι καταχωρισμένη στον κατάλογο και το εισιτήριο που μπόρεσε πραγματικά να αποκτήσει ο πελάτης. Τρεις προϋποθέσεις πρέπει να ισχύουν ταυτόχρονα και η ίδια η συνεδρία λέει ποια υποχώρησε. Διαβάστε το πριν επεξεργαστεί κάποιος ένα όνομα κύριας υπηρεσίας.

Η συνεδρία ονομάζει το σχήμα που πήρατε πραγματικά

Το σχήμα ελέγχου ταυτότητας ανήκει σε μια σύνδεση και όχι σε έναν διακομιστή ή μια σήραγγα, επομένως ο έλεγχος πρέπει να εκτελείται μέσα στη συνεδρία που σας ενδιαφέρει. Εκτελέστε το παρακάτω ερώτημα από τον ίδιο πελάτη, εργαλείο και λογαριασμό που παρήγαγαν την αναφορά και καταγράψτε το όνομα προορισμού και τη μεταφορά δίπλα στο αποτέλεσμα.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Μια γραμμή από ένα τοπικό παράθυρο SSMS στον κεντρικό υπολογιστή της βάσης δεδομένων περιγράφει μια εντελώς διαφορετική σύνδεση, γι’ αυτό το ερώτημα πρέπει να εκτελείται από την πλευρά του πελάτη. Αποθηκεύστε την έξοδο με χρονική σήμανση, επειδή το επόμενο άτομο που θα τη διαβάσει θα ρωτήσει πότε ελήφθη. Όταν πολλές εφαρμογές μοιράζονται ένα τελικό σημείο, πάρτε δείγμα από καθεμία, επειδή μια διαφορά πηγής δεδομένων μεταξύ δύο εφαρμογών είναι συχνά όλη η ιστορία.

Προϋπόθεση πρώτη: ταιριάζει το όνομα με το SPN;

Το Kerberos ελέγχει την ταυτότητα μιας ονομασμένης υπηρεσίας, οπότε ο πελάτης ζητά από τον κατάλογο εισιτήριο για μια συγκεκριμένη κύρια αρχή. Για τον πάροχο TCP η τεκμηριωμένη μορφή είναι MSSQLSvc/ ακολουθούμενη από το πλήρως αναγνωρισμένο όνομα κεντρικού υπολογιστή και, για προεπιλεγμένη παρουσία, τη θύρα. Μια ονομασμένη παρουσία καταχωρεί MSSQLSvc/db01.corp.example:SQLPROD, όπου το επίθεμα είναι το όνομα της παρουσίας αντί για αριθμό. Η πρόσβαση στον ακροατή μέσω ψευδωνύμου, ενός CNAME που επιλύεται αλλού ή μιας γυμνής διεύθυνσης IP αλλάζει το ζητούμενο όνομα και ένα αίτημα χωρίς αντίστοιχη κύρια αρχή δεν έχει εισιτήριο να επιστρέψει.

Γι’ αυτό μια εφαρμογή λειτουργεί σε ένα δίκτυο και υποχωρεί σε ένα άλλο: μια απάντηση DNS, μια εγγραφή ψευδωνύμου ή μια καταχώριση hosts άλλαξαν το όνομα που χρησιμοποίησε ο πελάτης. Συγκρίνετε το ζητούμενο όνομα με αυτό που διατηρεί ο κατάλογος πριν αγγίξετε την καταχώριση.

Προϋπόθεση δεύτερη: είναι το SPN στον σωστό λογαριασμό;

Ένα SPN πρέπει να ανήκει στον λογαριασμό που εκτελεί την υπηρεσία SQL, όχι στον λογαριασμό του πελάτη και όχι κατά λάθος σε ένα αντικείμενο υπολογιστή. Το SQL Server μπορεί να καταχωρεί τα δικά του SPN κατά την εκκίνηση όταν ο λογαριασμός υπηρεσίας του έχει άδεια να τα γράφει, κάτι που είναι βολικό και εξηγεί επίσης πώς εμφανίζεται ένα διπλότυπο μετά από αλλαγή λογαριασμού υπηρεσίας.

Ρωτήστε τον κατάλογο για το όνομα που περιμένετε και μετά απαριθμήστε τι κατέχει πραγματικά ο λογαριασμός. Ποιο αντικείμενο κρατά την καταχώριση έχει μεγαλύτερη σημασία από το αν το όνομα υπάρχει κάπου στο δάσος. Μια αναντιστοιχία σημαίνει ότι η είσοδος δεν ήταν ποτέ το πρόβλημα, και ο οδηγός SPN της Microsoft τεκμηριώνει τις μορφές και τις περιπτώσεις όπου ένας διαχειριστής τομέα πρέπει να δημιουργήσει την καταχώριση.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Η προσθήκη μιας ακόμη καταχώρισης δεν είναι ασφαλές πείραμα. Ένα διπλότυπο ή μια αντικρουόμενη καταχώριση μπορεί να σπάσει πελάτες που λειτουργούσαν, γι’ αυτό ελέγξτε την κυριότητα πριν από την αλλαγή και ξανά μετά.

Προϋπόθεση τρίτη: μπορεί ο πελάτης να πάρει καθόλου εισιτήριο;

Ένα σωστό SPN είναι άχρηστο αν ο πελάτης δεν μπορεί να φτάσει σε έναν ελεγκτή τομέα ή δεν έχει χρησιμοποιήσιμο πλαίσιο διαπιστευτηρίων. Η ανταλλαγή χρειάζεται το KDC και το DNS μέσω του VPN και μια σήραγγα που δρομολογεί μόνο τη θύρα SQL αποτυγχάνει ακριβώς σε αυτό το βήμα. Η προσβασιμότητα πρέπει να ελέγχεται από το ίδιο μηχάνημα και τον ίδιο λογαριασμό, όχι από το τείχος προστασίας μπροστά τους.

Ελέγξτε την προσωρινή μνήμη εισιτηρίων στο μηχάνημα και κάτω από τον λογαριασμό που εκτελεί την εφαρμογή. Μια λίστα για ολόκληρο το μηχάνημα από ένα αναβαθμισμένο παράθυρο δεν λέει τίποτα για μια υπηρεσία που εκτελείται ως άλλος χρήστης, και μια κενή μνήμη για αυτόν τον χρήστη είναι εύρημα και όχι ενόχληση.

klist
klist -li 0x3e7

Στη συνέχεια αποφασίστε τι επιτρέπεται να κάνει μια υποχώρηση. Αν η πολιτική απαιτεί Kerberos, το NTLM πρέπει να απορρίπτεται ρητά, επειδή μια σιωπηλή υποχώρηση μετατρέπει ένα σφάλμα διαμόρφωσης σε λειτουργική σύνδεση που παραβιάζει την απαίτηση. Αν το NTLM παραμένει αποδεκτό για ορισμένες εφαρμογές, ονομάστε τις και σταματήστε να αντιμετωπίζετε κάθε συνεδρία NTLM ως περιστατικό.

Η αλλαγή του εκκινητή είναι μία μεταβλητή, όχι διόρθωση

Η εκκίνηση του SSMS με άλλα διαπιστευτήρια μπορεί να θεραπεύσει μια ακούσια εξερχόμενη ταυτότητα, που είναι πραγματική κατηγορία προβλήματος. Δεν αποδεικνύει τίποτα για το όνομα προορισμού, την καταχώριση ή τη διαδρομή του εισιτηρίου και δεν αλλάζει τι δέχτηκε ο διακομιστής.

Κρατήστε τη σύγκριση ελεγχόμενη: ίδιο τελικό σημείο, ίδιος πάροχος, γνωστό πλαίσιο εκτέλεσης και μετά μια νέα σύνδεση της οποίας το σχήμα εξετάζετε. Επιβεβαιώστε την αποδεκτή είσοδο και τα δικαιώματά της στη βάση δεδομένων χωριστά, επειδή η πρόσβαση και ο έλεγχος ταυτότητας αποτυγχάνουν για διαφορετικούς λόγους.

Όταν απαιτείται Kerberos, καταγράψτε γιατί υποχώρησε η πρώτη διαδρομή, εφαρμόστε μία διόρθωση και εκτελέστε ξανά το ερώτημα από τον ίδιο πελάτη. Ένα επιτυχές ερώτημα μετά από αλλαγή του εκκινητή είναι απόδειξη πρόσβασης και δεν είναι ακόμη απόδειξη ότι η απαίτηση ελέγχου ταυτότητας ικανοποιήθηκε.