Σύνδεση VM Azure σε Entra Domain Services: αποφασίστε πρώτα

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

Καθορίστε το μοντέλο, την επίλυση και τον λογαριασμό πριν αγγίξετε τον διακομιστή, και μετά η εντολή εκτελείται μία φορά.

Ποια από τις τρεις συνδέσεις θέλετε πραγματικά

Η σύνδεση συσκευής καταχωρεί ένα μηχάνημα στο Microsoft Entra ID για υπό όρους πρόσβαση και ενιαία σύνδεση και δεν δίνει στο φορτίο εργασίας εισιτήριο Kerberos προς τομέα τοπικού τύπου. Η παραδοσιακή σύνδεση τομέα δεσμεύει ένα αντικείμενο υπολογιστή μέσα σε κατάλογο και του δίνει λογαριασμό μηχανήματος, πολιτική ομάδας και έλεγχο ταυτότητας τομέα. Ένας διαχειριζόμενος τομέας παρέχει αυτό το δεύτερο μοντέλο ως υπηρεσία. Τα ονόματα ακούγονται παρόμοια και τα αποτελέσματα όχι.

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

Η απόφαση εξαρτάται συνήθως από την εφαρμογή και όχι από την προτίμηση. Λογισμικό που θέλει σύνδεση LDAP, λογαριασμό υπηρεσίας με SPN ή αντικείμενα πολιτικής ομάδας ανήκει στο μοντέλο τομέα. Λογισμικό που χρειάζεται μόνο να γνωρίζει την ταυτότητα του χρήστη σε εταιρική συσκευή συνήθως δεν ανήκει.

Η διαδρομή DNS αποφασίζει αν η σύνδεση μπορεί να ολοκληρωθεί

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

Δοκιμάστε τον εντοπισμό και όχι ένα γυμνό όνομα κεντρικού υπολογιστή. Ένα ping στο όνομα τομέα δεν αποδεικνύει σχεδόν τίποτα, ενώ ένα ερώτημα SRV για τις εγγραφές ελεγκτή τομέα είτε επιστρέφει τους αναμενόμενους στόχους είτε αποτυγχάνει αμέσως:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53

Αντικαταστήστε το όνομα τομέα και τις δύο διευθύνσεις με τις τιμές από τη διαμόρφωση του διαχειριζόμενου τομέα σας· οι αριθμοί εδώ είναι παραδείγματα. Αν το ερώτημα επιστρέφει απαντήσεις άλλης ζώνης, η VM χρησιμοποιεί resolver που δεν προωθεί τον διαχειριζόμενο χώρο ονομάτων, και καμία επανάληψη της σύνδεσης δεν θα το αλλάξει.

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

Η καταλληλότητα του λογαριασμού ελέγχεται πριν από το μηχάνημα

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

Οι συγχρονισμένοι υβριδικοί λογαριασμοί έχουν τις δικές τους προϋποθέσεις που ένα ορατό αντικείμενο χρήστη δεν ικανοποιεί από μόνο του. Το να είσαι καταγεγραμμένος στον κατάλογο δεν είναι το ίδιο με το να μπορείς να πάρεις εισιτήριο από αυτόν, γι' αυτό δοκιμάστε τον λογαριασμό πριν από το παράθυρο συντήρησης και όχι κατά τη διάρκειά του.

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

Η ίδια η σύνδεση είναι μία εντολή

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

Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru

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

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

Τι δεν παρέχει η ιδιότητα μέλους

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

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

Οι οδηγίες της Microsoft για τη σύνδεση Windows Server απαριθμούν τις υποστηριζόμενες προϋποθέσεις για τη ροή εργασίας του διαχειριζόμενου τομέα. Διαβάστε τις απέναντι στις τρεις αποφάσεις παραπάνω και θεωρήστε κάθε ασυμφωνία λόγο να σταματήσετε και όχι λεπτομέρεια προς παράκαμψη.