panhas

Archive for May, 2008

, , , ,

Windows Server 2003 Active Directory Authoritative Restore (Ελληνική Έκδοση)

In Active Directory, Windows Server 2003 on May 18, 2008 at 2:00 am

Σενάριο:

Ο Junior Administrator διέγραψε “κατά λάθος” ένα User Account στο Active Directory. Ή μπορεί και να είχε διαγράψει ένα ολόκληρο OU το οποίο περιείχε User Accounts, Security Groups, Computer Accounts, κλπ. Μέχρι όμως να βρει το “κουράγιο” να το αναφέρει οι αλλαγές μεταφέρθηκαν (replication) και στους υπόλοιπους DC του Active Directory…

Αφού τον μαλώσουμε με ωραίο και εποικοδομητικό τρόπο κατ’ ιδίαν γιατί δε μαλώνουμε ΠΟΤΕ έναν υφιστάμενο παρουσία άλλων (αυτή είναι συμπεριφορά ατόμων χωρίς καλλιέργεια), και γιατί ο Senior Administrator διαθέτει εγκράτεια (γιατί και αυτός υπήρξε κάποτε Junior),  και με ευγένεια (είπαμε ότι έχουμε επίπεδο), προβαίνουμε σε ένα Authoritative Restore. Α ναι! Ο καλός Administrator είναι επίσης προνοητικός: Τηρεί την αρχή του System State Backup.

Παρένθεση:

Το System State Backup είναι μια διαδικασία που τηρούμε καθημερινά και προγραμματισμένα. ΔEN νοείται δίκτυο Windows με Active Directory στο οποίο δεν τηρείται καθημερινό και προγραμματισμένο System State Backup ΣΕ ΚΑΘΕ Domain Controller (σε κάποιο άλλο Post θα αναφερθώ αναλυτικά στο System State Backup το οποίο αφορά και τα Windows Client). Σε δίκτυα (συνήθως μεγαλύτερου μεγέθους) που πραγματοποιούνται αρκετές αλλαγές καθημερινά στο Active Directory, είναι ωφέλιμο να τηρούμε και ΔΥΟ φορές τη μέρα System State Backup. Μια στη μέση της εργάσιμης ημέρας (όταν συνήθως οι χρήστες κάνουν διάλειμμα για μεσημεριανό φαγητό), και μια στο τέλος της εργάσιμης ημέρας. Αν το δίκτυο βρίσκεται σε εργοστάσιο που δεν σταματά ποτέ όπως πολλές βιομηχανίες, τότε η κατάλληλη στιγμή είναι στις αλλαγές της βάρδιας. Πως κάνω System State Backup & Restore; Διαβάστε: http://support.microsoft.com/kb/240363/ Κλείνει η παρένθεση.

ΠΡΟΣΟΧΗ: Η κάτωθι διαδικασία προϋποθέτει ότι το Λειτουργικό είναι Windows Server 2003 SP1 ή νεότερο. Ωστόσο στα Links που δίνω υπάρχουν Reference και για εκδόσεις χωρίς Service Pack.

Διαδικασία:

  1. Πραγματοποιούμε επανεκκίνηση του Domain Controller (κατά προτίμηση του πιο κεντρικού για να μεταφερθούν συντομότερα οι αλλαγές στους υπόλοιπους) και πατώντας F8 πριν την εκκίνηση του Λειτουργικού, εμφανίζεται το Boot Menu.
  2. Επιλέγουμε Directory Services Restore Mode (Windows Domain Controllers Only)
  3. Το λειτουργικό εισέρχεται σε μια κατάσταση που μοιάζει λίγο με Safe Mode και μας ζητά το Username και το Password του Administrator για να κάνουμε logon. Τώρα βρισκόμαστε σε Directory Services Restore Mode, πράγμα το οποίο σημαίνει ότι η Database του Active Directory είναι κλειστή, και είναι λογικό: Δεν μπορείς να κάνεις restore σε μια ανοιχτή βάση. Η db του AD όμως περιέχει όλα τα User Accounts με τα οποία πραγματοποιείται το logon. Πώς λοιπόν εγώ συνδέθηκα στα Windows; Το Administrator Account με το οποίο έκανα logon στο Λειτουργικό ΔΕΝ είναι αυτό του Domain Administrator. Όταν είχα εγκαταστήσει το AD (ναι τότε), στο τέλος του οδηγού εγκατάστασης μου ζητήθηκε να πληκτρολογήσω ένα password για τον Directory Services Restore Mode Administrator. Αυτό το password χρησιμοποίησα για να κάνω logon. Ωχ! Κι αν δεν το θυμάμαι; Υπάρχει τρόπος να κάνουμε Reset το DSRM Administrator Password, από κανονικό mode όμως.  Διαβάστε: http://support.microsoft.com/kb/322672
  4. Αφού λοιπόν έχω συνδεθεί σε Restore Mode, πηγαίνω Start, All Programs, Accessories, System Tools, Backup και κάνω Restore το System State. ΑΝ σε αυτό το σημείο κάνω επανεκκίνηση τότε έχω πραγματοποιήσει ένα Non-Authoritative Restore ή Domain Controller Restore. Η διαδικασία τελειώνει εδώ αν ίσχυε το σενάριο αποκατάστασης ενός Domain Controller που είχε παρουσιάσει βλάβη. Στην περίπτωσή μας όμως ΔΕΝ ισχύει κάτι τέτοιο, διότι το Active Directory μετά την επανεκκίνηση όταν θα κάνει Replication, επειδή χρησιμοποιεί κάτι αριθμούς που λέγονται USN (Update Sequence Number), όταν θα διαβάσει τα διαγραμμένα που επαναφέραμε, λόγω παλαιότερου USN θα τα διαγράψει ξανά. Εδώ βρίσκεται και το “μυστικό” του Authoritative Restore. Ανοίγω λοιπόν ένα Command Prompt, πληκτρολογώ ntdsutil και enter.
  5. Μόλις μπήκα στο Command του Active Directory (ntdsutil=NT Directory Service Utility). Θα παρατηρήσετε ότι ο Cursor έχει αλλάξει σε ntdsutil: Συνεχίζω και γράφω authoritative restore και enter.
  6. Στη συνέχεια γράφουμε restore database και enter. Εμφανίζεται η ερώτηση Are you sure you want to perform this authoritative restore? Επιλέγουμε YES. Opening DIT Database λέει το Utility. Ανοίγει δηλαδή το αρχείο ntds.dit το οποίο είναι η Database του Active Directory και συνήθως αν κάνουμε Default Installation βρίσκεται στο Folder C:\Windows\NTDS. Μετά εμφανίζει τον τρέχοντα χρόνο και ημερομηνία του συστήματος, και πότε έγινε το τελευταίο Update στη Database του Active Directory. Μετά λέει Increasing Attribute Version Numbers by 100.000 (Αχά! Να λοιπόν πως γίνεται. Εφ’ όσον τα USN όλων των Objects και των Attributes αυξάνονται κατά 100 χιλιάδες, στο επόμενο replication θα θεωρηθούν από όλους τους υπόλοιπους Domain Controllers ως τα πιο ενημερωμένα άρα και θα επικρατήσουν των άλλων εκδόσεων). Μετά, το Utility κάνει καταμέτρηση των εγγραφών (Counting Records), Updating Records, Successfully Updated, γράφει ένα Text File με τα Objects που ενημέρωσε (στο Folder που είμαστε: συνήθως C:\Documents and Settings\Administrator) και ένα LDF αρχείο το οποίο θα τα χρειαστούμε για να κάνουμε Recover τα back-links των objects. Authoritative Restore Completed Successfully λέει το ntdsutil.
  7. Quit και enter δυο φορές, και μετά exit. Κάνουμε Restart τον Server.
  8. Κάνουμε Synchronize Replication με όλους τους Replication Partners του Server από Command Prompt, με την εντολή repadmin /syncall DCName /e /d /A /P /q, όπου DCName είναι το Computer Name του DC. Mας εμφανίζει ότι έκανε Sync όλα τα Partitions του AD χωρίς Errors.
  9. Τώρα θα “τρέξουμε” το LDF (από το ldif=LDAP Data Interchange Format) που αναφέρθηκα πριν για να κάνουμε recover τα back-links. Τα back-links είναι τα group memberships των objects του AD. ΠΡΟΣΟΧΗ: Αντιγράφουμε το αρχείο, και το εκτελούμε σε κάποιον ΑΛΛΟΝ DC από αυτόν που κάναμε το Restore. Από Command Prompt γράφουμε: ldifde -i -k -f FileName, όπου FileName είναι το όνομα του αρχείου που δημιούργησε το Authoritative Restore.

BONUS: Αν βρισκόμαστε σε Forest με πολλά Domains η διαδικασία πρέπει να γίνει και στα υπόλοιπα Domains.

Πρέπει επίσης συμπληρωματικά να αναφέρω ότι η διαδικασία αυτή έγινε σχετικά “γρήγορα” από τη στιγμή που ο Junior διέγραψε τον User. Αν είχε περάσει χρόνος αρκετός ώστε να είχαν γίνει και άλλες αλλαγές στο AD, π.χ. αν κάποιος άλλος user άλλαξε password ενδιάμεσα, μετά το Authoritative Restore το καινούργιο password του User ΔΕΝ θα λειτουργούσε και θα έπρεπε να το ξαναβάλει. Μικρό το κακό σε αυτή την περίπτωση. Αν όμως είχαν γίνει πιο σημαντικές αλλαγές; Λάβετε υπ’ όψιν αυτή τη “λεπτομέρεια” όταν θα αποφασίσετε για το ΠΟΤΕ θα γίνει το Authoritative Restore. Υπάρχει μια εναλλακτική εδώ. Έχουμε τη δυνατότητα να κάνουμε ένα πιο “χειρουργικό” Authoritative Restore, γιατί μπορεί να μην υπάρξει δυνατότητα “γρήγορης” αντίδρασης. Μπορούμε να κάνουμε Restore ΜΟΝΟ το object που διαγράφηκε. Πιο πολύπλοκη διαδικασία ωστόσο, λόγω της λεπτότητας του εγχειρήματος. Διαβάστε: http://support.microsoft.com/kb/840001/

Επίσημες Αναφορές:

How to perform an authoritative restore to a domain controller in Windows 2000

The effects on trusts and computer accounts when you authoritatively restore Active Directory

Performing an Authoritative Restore of Active Directory Objects

Κάτι τελευταίο. Υπάρχει άλλο ένα είδος Restore για το Active Directory πέρα από τα Authoritative και Non-Authoritative. Το Primary Restore. Όταν έχεις χάσει και τον τελευταίο Domain Controller του Domain…

Σε άλλο Post. Stay Tuned…

,

Θέματα Active Directory Design (Ελληνική Έκδοση)

In Active Directory, Windows Server 2003 on May 11, 2008 at 7:22 pm

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

Ας δούμε κάποιες από τις αρχές του Network Design σε περιβάλλον Active Directory.

Σενάριο: Μια φανταστική εταιρία που έχει έδρα στη Θεσσαλονίκη, διαθέτει τρία καταστήματα στις οδούς Παπαναστασίου 77, Εγνατία 123 και Τσιμισκή 45. Υπάρχει μόνο ένας System Administrator για όλα τα καταστήματα και επιθυμεί να διατηρήσει ένα ενιαίο περιβάλλον χρησιμοποιώντας Group Policies. Τα καταστήματα διαθέτουν μεταξύ τους μόνιμες συνδέσεις Internet.

Με βάση τις παραπάνω προδιαγραφές το Design θα μπορούσε να έχει ως εξής:

1. Επιλογή Domain Structure. Εφ’ όσον θέλουμε κεντρική διαχείριση από οποιοδήποτε κατάστημα, και όλα τα καταστήματα να ανήκουν στο ίδιο λογικό δίκτυο, τότε επιλέγουμε τη λύση του Single Active Directory Domain – Forest με Branch Offices. Σε κάθε κατάστημα πρέπει να υπάρχουν δυο Domain Controllers για λόγους redundancy. Θα υλοποιηθούν τρία Active Directory Sites με ονόματα Papanastasiou, Egnatia και Tsimiski. Σκοπός αυτής της υλοποίησης, είναι να ελέγξουμε το replication των Domain Controllers, μέσω των WAN Links που συνδέουν τα καταστήματα μεταξύ τους.

Ερώτηση 1: Γιατί να μην δημιουργήσω ένα Single Active Directory Domain – Forest σε κάθε κατάστημα;

Απάντηση: Θέλουμε κεντρική διαχείριση και διαθέτουμε μόνο έναν administrator για όλα τα καταστήματα. Αν είχαμε ένα περιβάλλον τύπου Franchise, όπου υπάρχουν καταστήματα που “μοιράζονται” μια κοινή επωνυμία-brand name και το καθένα έχει τον δικό του “τοπικό” System Administrator σε isolated περιβάλλον, τότε θα είχε νόημα ένα Single Active Directory Domain - Forest σε κάθε κατάστημα.

Άλλη απάντηση: Αν υλοποιήσουμε μια τέτοια λύση θα πρέπει να πηγαίνει ο administrator σε κάθε κατάστημα και να δημιουργεί ξεχωριστά OU, GPO, Computer Accounts, User Accounts κλπ. Χρονοβόρο και δίχως νόημα. Θα ίσχυε υπό κάποιες άλλες προϋποθέσεις, συν αν είχαμε έναν administrator σε κάθε κατάστημα.

Ερώτηση 2: Γιατί να μη δημιουργήσω ένα κεντρικό Root-Parent Domain με Child Domains για κάθε κατάστημα;

Απάντηση: Αυτή η υλοποίηση είναι καλύτερη από την προηγούμενη αλλά και πάλι δεν αρμόζει απόλυτα στο σενάριό μας. Στη σχέση Parent Domain-Child Domain υπάρχει δυνατότητα κεντρικής διαχείρισης σε κάποια θέματα του Active Directory, αλλά και πάλι αναγκαία προϋπόθεση είναι να υπάρχει administrator in σε κάθε κατάστημα. Και πάλι, θα πρέπει ο ένας και μοναδικός administrator του σεναρίου μας να κάνει πολλές φορές “διπλή” και “τριπλή” δουλειά. Η υλοποίηση Root Domain με Child Domains είναι για εταιρίες που έχουν πολυεθνική δράση και υπάρχουν διαβαθμίσεις στο IT Management. IT Manager, Enterprise Administrator, Regional Administrators ή Domain administrator s, Helpdesk κλπ. Στην περίπτωση που μελετάμε, μια τέτοια πολύπλοκη υποδομή δυσκολεύει παρά απλοποιεί τη διαχείριση.

Σημείωση: Η πρώτη αρχή του Network Design, είτε πρόκειται για Logical είτε για Physical Structure, και ασχέτως πλατφόρμας υλοποίησης, δηλαδή αν η εγκατάσταση είναι Microsoft Windows, Unix, Mac OS, Linux, ή κάτι Hybrid από τα προαναφερθέντα, είναι η Simplicity. Προσπαθούμε να απλοποιήσουμε όσο το δυνατόν περισσότερο την υλοποίηση, γιατί ο τελικός σκοπός είναι πάντοτε η ελαχιστοποίηση του χρόνου διαχείρισης (Least Administrative Effort). Καλός administrator είναι αυτός που σχεδιάζει ένα μήνα και δουλεύει μια μέρα, όχι το αντίθετο. Το συγκεκριμένο rule όμως εμπεριέχει και θέματα management που δεν αφορούν το παρόν post.

2. Naming Scheme για τα Computer Accounts. Τα Computer Names μπορούν να πάρουν την εξής μορφή. Τρεις τουλάχιστον χαρακτήρες από την οδό στην οποία βρίσκεται το κατάστημα. PAP για Παπαναστασίου, EGN για Εγνατία, και TSI για Τσιμισκή. Χρησιμοποιούμε ως διαχωριστικό το χαρακτήρα dash (-) για να είναι ευανάγνωστη η λίστα όταν αυτή θα εμφανίζεται στο Snap-In Active Directory Users and Computers. Ακολουθούν άλλοι δυο ή τρεις χαρακτήρες ανάλογα με τον ρόλο του PC. CL για Client, SRV για member server και DC για Domain Controller. Τέλος ακολουθεί αύξων αριθμός. Παράδειγμα: Ένας server στο κατάστημα της Τσιμισκή 45 έχει computer name TSI-SRV02. Οι clients στο κατάστημα της Παπαναστασίου έχουν computer names PAP-CL01, PAP-CL02 κλπ. O πρώτος Domain Controller που εγκαταστάθηκε στο κατάστημα της Εγνατία 123 έχει computer name EGN-DC01.

Ερώτηση 1: Τι κάνουμε αν κάποια στιγμή η φανταστική εταιρία μας ανοίξει κατάστημα στην Εγνατία 31;

Απάντηση: Θα βάλουμε πρόθεμα EGN31 στα pc του νέου καταστήματος για να ξεχωρίζουν από τα άλλα στην Εγνατία 123. Μπορούμε επίσης εκ’ των προτέρων να προσθέσουμε και τους αριθμούς των οδών σε όλα τα καταστήματα, για να καλύψουμε ένα τέτοιο ενδεχόμενο και να διατηρήσουμε έτσι ένα ενιαίο σχήμα (design consistency) στο σχεδιασμό του δικτύου.

Προσοχή: Αν μπούμε στον πειρασμό να κάνουμε rename όλα τα computer accounts κάθε φορά που προκύπτει μια επέκταση του δικτύου η οποία επηρεάζει το Design του Active Directory με σκοπό να διατηρηθεί το ενιαίο σχήμα που ανέφερα πριν, υπάρχει κίνδυνος αφ’ ενός να δημιουργήσουμε ένα υπερβολικά πολύπλοκο Active Directory Design άρα και χρονοβόρο στη διαχείριση και αφ’ ετέρου κάθε φορά που θα κάνουμε τέτοιου είδους αλλαγές θα δημιουργείται επιπρόσθετος φόρτος για τον administrator . Αν ωστόσο είναι αναγκαίο να προχωρήσετε σε μαζικό rename διαβάστε τα παρακάτω:

http://support.microsoft.com/kb/298593/en-us

http://www.microsoft.com/technet/scriptcenter/guide/sas_srv_fovn.mspx?mfr=true

http://www.microsoft.com/technet/scriptcenter/scripts/ad/computer/default.mspx?mfr=true

Ερώτηση 2: Κι αν η εταιρία ανοίξει και άλλα δυο καταστήματα, στις πόλεις Κοζάνη και Καβάλα;

Απάντηση: Ισχύει ότι είπαμε και στην προηγούμενη ερώτηση. Μπορούμε να δημιουργήσουμε computer names που να αρχίζουν από KOZ ή KAV κλπ.

Σε επόμενο post θα ασχοληθούμε με User Accounts, Groups και OU.

To be continued…