SOF

Καλησπέρα! Για όσους θέλουν να πάρουν μια πρόγευση τι μας επιφυλάσσει η καινουργια έκδοση του Windows Server, μη χάσετε το πολύ ενδιαφέρον άρθρο του Mark Minasi! http://www.minasi.com/newsletters/nws1109.htm Στα επόμενα posts θα συζητήσουμε τα περισσότερα από αυτά αναλυτικότερα. Φιλικά SOF

Hi guys, excuse me for posting in English, but I wanted to share this article also with my friends abroad. Many of you have already heard of this small tool I’ve written. What it basically does is the following: It accepts a GUID or a SID in a text or a Base64 format and it converts it to either Base64 or text. Besides that it creates an output for binary search in LDP. Using that output you can search Active Directory for an attribute matching the SID or GUID value you entered above. You can download it from here: Needless to say: All postings are provided "AS IS" with no warranties! Greetings SOF

Καλησπέρα! Στους περισσότερους από εσάς είναι γνωστό το παρακάτω interface. Προφανώς αρκετοί διαχειριστές που θέλουν να έχουν μια γενική εικόνα του domain, χρειάζονται ένα report που να διαβάζει πληροφορίες του τύπου: Ποιοι λογαριασμοί έχουν set το flag “Password never expires”. Για να ανακτήσουμε όμως αυτή την πληροφορία πρέπει να γνωρίζουμε που αποθηκεύεται στο Active Directory. Η απάντηση είναι στο user-account-control attribute κάθε χρήστη! Το attribute αυτό είναι ένας μυστικός θησαυρός γιατί εκτός των άλλων περιέχει πληροφορίες όπως αν ο χρήστης είναι κλειδωμένος, ή αν προϋποθέτει την χρήση smartcard για login ή ακόμα αν υποστηρίζει μόνο τον αλγόριθμο DES για login. Το τελευταίο είναι αρκετά χρήσιμο για αυτούς που σκοπεύουν να αναβαθμίσουν τους DCs σε Windows 2008 R2 καθώς αυτοί δεν υποστηρίζουν DES. Εδώ θα βρείτε ολόκληρη τη λίστα με τις πληροφορίες που αποθηκεύονται στο attribute. Εχουμε λοιπόν μια υπόθεση εργασίας: Θέλουμε να βρούμε άν υπάρχουν accounts στο Active Directory που να χρησιμοποιούν τον αλγόριθμο DES πριν αναβαθμίσουμε τους DCs σε Windows 2008 R2. Υπάρχει όμως ένα σημαντικό πρόβλημα στην αναζήτηση αυτής της πληροφορίας! Η τιμή του attribute είναι δυαδική και αποτελείται από το άθροισμα των δυαδικών τιμών όλων των flags. Εμείς όμως πως μπορούμε να ψάξουμε αυτά τα αθροίσματα αν περιέχουν την τιμή “ADS_UF_USE_DES_KEY_ONLY” που είναι 0x00200000; Την απάντηση σε αυτό το ερώτημα θα επιχειρήσω να δώσω παρακάτω. Το Active Directory μας δίνει την δυνατότητα να εκτελούμε bitwise searches! Ιδου ο τρόπος: Το ldap search filter μας πρέπει να έχει την εξής μορφή: attributename:ruleOID:=value Υπάρχουν δύο RuleOIDs: 1.2.840.113556.1.4.803 – Αυτός είναι ο LDAP_MATCHING_RULE_BIT_AND κανόνας. Ο κανόνας αυτός επιστρέφει true μόνο αν όλα τα bits της τιμής του attribute ταιριάζουν στην τιμή που ψάχνουμε. 1.2.840.113556.1.4.804 – Αυτός ειναι ο LDAP_MATCHING_RULE_BIT_OR κανόνας. Ο κανόνας αυτός επιστρέφει true αν κάποια από τα bits της τιμής που ψάχνουμε περιέχονται στην τιμή του attribute. Αν δεν είστε εξοικοιωμένοι με τους δυαδικούς operators είναι λιγο περίπλοκο. Αυτό που πρέπει να κρατήσουμε είναι ότι για αυτού του είδους τα searches χρησιμοποιούμε AND. Ας φτιάξουμε λοιπόν το search filter. attributename = useraccountcontrol ruleOID = 1.2.840.113556.1.4.803 “ADS_UF_USE_DES_KEY_ONLY” = HEX 0x00200000 = DEC 2097152 Επομένως το φίλτρο έχει τη μορφή: useraccountcontrol:1.2.840.113556.1.4.803:=2097152 Αυτό το φίλτρο τώρα μπορούμε να το χρησιμοποιήσουμε σε οποιδήποτε LDAP client ή ακόμα και προγραμματιστικά. Εδώ ένα παράδειγμα με το ldp.exe Και το αποτέλεσμα: Αν δούμε τώρα τη καρτέλα του χρήστη θα παρατηρήσουμε ότι το flag είναι όντως τσεκαρισμένο: Μπρορείτε φυσικά να χρησιμοποιήσετε αυτού του τύπου τις αναζητήσεις για οποιαδήποτε δυαδική τιμή του useraccountcontrol ή οποιουδήποτε άλλου attribute. Ελπίζω να σας φανεί χρήσιμο! Φιλικά SOF

Ωραίο άρθρο! Με το LVR εκτός των άλλων ξεφεύγουμε και από το limitation των 5000 μελών σε ένα γκρουπ. Και λίγο background info: Το limitation αυτό προέρχεται από το max μεγεθος των δεδομένων που μπορούν να γίνουν replicated με μιας (10MB), και το ότι η μικρότερη μονάδα που μπορεί να γίνει replicated είναι ένα attribute. Έτσι λοιπόν αν το attribute γίνει μεγαλύτερο απο 10MB δεν μπορεί να συγχρονιστεί.

http://notepad-plus.sourceforge.net/uk/about.php Notepad++ is a free (as in "free speech" and also as in "free beer") source code editor and Notepad replacement that supports several languages. Το απόλυτο εργαλείο για την ανάλυση logs, traces, source code. Φιλικά Sof

Και μιας που πιάσαμε το θέμα του performance, συνεχίζω με το θέμα του load balancing όπου έχω να σας δώσω μια έξυπνη συμβουλή. Ας πούμε ότι πήραμε τελικά την απόφαση να προσθέσουμε ή να αντικαταστήσουμε μερικούς DCs με καινούργιο hardware. Βλέπουμε λοιπόν το εξής φαινόμενο το οποίο όμως εξηγείται λογικά. Οι παλιοί DCs έχουν ένα μέσο CPU load 50% και οι καινούργιοι 15%. Προφανώς πρέπει στο περίπου να εξυπηρετούν τον ίδιο αριθμό από LDAP ή authentication requests. Μόνο που οι καινούργιοι δεν μασάνε, και έχουν bandwidth να εξυπηρετήσουν αρκετά περισσότερα. Ιδού λοιπόν ένα trick για να τους μπαλανσάρουμε λιγάκι. Το μυστικό είναι στο weight του DNS SRV Record των DCs. Κάθε SRV Record έχει weight και priority. To priority καθορίζει την σειρά με την οποία ένας client επικοινωνεί με έναν DC. Μια τιμή 0x0 αναπαριστά την μεγαλύτερη δυνατή priority, και μια τιμή 0xffff την χαμηλότερη. Οι clients επικοινωνουν πρώτα με τους DCs με την υψηλότερη priority. Οι DCs με την χαμηλότερη priority επιλέγονται μόνο εάν δεν είναι δυνατή η επικοινωνία με τους προηγούμενους. Όταν οι DCs εχουν το ίδια τιμή στο priority τότε το weight του priority καθορίζει την πιθανότητα να επιλεγούν πρώτοι. Το weight λειτουργεί επομένως κάπως διαφορετικά. Η τιμή του καθορίζει δεν καθορίζει την σειρά αλλά την πιθανότητα ένας client να επιλέξει έναν DC μεταξύ ενός pool από DCs της ίδιας priority.΄ Ο παρακάτω τύπος χρησιμοποιείται για τον υπολογισμό αυτής της πιθανότητας. LdapSrvWeight / Sum (LdapSrvWeight for DCs of that priority) Για 3 DCs με το ίδιο priority έχουμε: DC Weight Πιθανότητα Α 3 50% (3/6) Β 2 33,3% (2/6) Γ 1 16,6% (1/6) Θέλει λίγο προσοχή λοιπόν γιατί το weight υπολογίζεται διαφορετικά από το priority. Το μεγαλύτερο weight είναι και το πιο πιθανό. Πώς όμως θα τα υλοποιήσουμε όλα αυτά στο περιβάλλον μας; Η λύση είναι αρκετά εύκολη. Δημιουργούμε ένα καινούργιο Group Policy και το συνδέουμε με το Domain Controllers OU. Επεξεργαζόμαστε τα Security Settings του Group Policy και φιλτράρουμε τους DCs για τους οποίους θέλουμε να αλλάξουμε την τιμή του weight. Για παράδειγμα δίνουμε Apply Group Policy μόνο στους καινούργιους DCs. Μια μικρή σημείωση. Συνήθως χρησιμοποιώ Sub OUs, αλλά τους DCs δεν επιτρέπεται να τους μετακινούμε έξω από το Domain Controllers OU. Αλλάζουμε το setting του weight: Η συμβουλή μου είναι να μεγαλώνουμε την τιμή τμηματικά με μικρά βήματα για να αποφύγουμε μια ανεπιθύμητη υπερφόρτωση ορισμένων DCs. To policy θα το βρείτε εδώ: Από την στιγμή που το σετάρουμε, το μόνο που χρειάζεται για να ανανεωθούν τα SRV Records είναι ένα gpupdate /force. Την δουλειά την αναλαμβάνει το netlogon service και ανανεώνει τα records αυτόματα στον primary DNS server που έχουμε καθορίσει στα TCP/IP Settings. Αν θέλετε να δείτε τι συμβαίνει στο background ή εφόσον δεν τρέξει να βρείτε τι πήγε στραβά, μπορείτε να ενεργοποιήσετε το netlogon debug logging στον DC με την εντολή nltest /dbflag:0x2080ffff. Στο αρχείο %windir%\debug\netlogon.log θα βρείτε αναλυτικές πληροφορίες της όλης διαδικασίας. Εδώ ένα μικρό κομμάτι από το περιβάλλον μου. 02/02 23:02:44 [iNIT] Group Policy is defined for Netlogon 02/02 23:02:44 [iNIT] Following are the effective values after parsing 02/02 23:02:44 [iNIT] LdapSrvWeight = 200 (0xC8) 02/02 23:02:44 [DNS] NlDnsScavenge: Starting DNS scavenge with: Force RefreshDomainRecords ForceRefreshDomainRecords 0 Με την εντολή nltest /dbflag:0x0 απενεργοποιούμε το debug logging ξανα. Εαν όλα πανε καλά τότε θα παρατηρήσουμε ότι όντως το load των DCs εξισορροπήθηκε λιγο. Προφανώς τα παραπάνω δεν αποτελούν μια NLB λύση, ούτε υπάρχει εγγύηση ότι ο κάθε client θα δημιουργεί το ίδιο load. Εξαρτάται τι εφαρμογή τρέχει κάθε φορα. Ελπίζω πάντως να σας φανούν χρήσιμα. Φιλικά SOF

5 σταρς *****!

Καλησπέρα! Πιστεύω πολλοί από εσας έχουν βρεθεί στην κατάσταση που περιγράφω στον τίτλο. Δεν χρειάζεται πανικός όμως. 100% CPU στον DC λόγω του LSASS για περιορισμένο χρονικό διάστημα δεν αποτελεί από μόνο του πρόβλημα. Το LSASS είναι το πιο σημαντικό service επάνω σε εναν DC και έχει σχεδιαστεί να δεσμεύει ότι πόρους χρειάζεται για να ολοκληρώσει τις εργασίες του. Εξάλλου γιατί τον έχουμε τον επεξεργαστή για να δουλεύει ή να κάθεται; Τα προβλήματα ξεκινάνε όταν το load δεν πέφτει κάτω απο το 100% για μια δύο ώρες, υπάρχουν προβλήματα με το replication, oi χρήστες δεν μπορούνε να δηλωθούνε, το event log γεμίζει με errors κτλ.. Δηλαδή όταν ο DC μας δεν την παλέυει άλλο Και οι περισσότεροι έχουμε την λύση έτοιμη. “Εμμμ κυριε διευθυντά χρειαζόμαστε ακόμα δύο DCs, ε δεν θα κοστίσει πολλά… κανά δεκαχίλιαρο.” Στους δύσκολους καιρούς όμως που διανύουμε η παραπάνω ατάκα θέλει κότσια, και ακόμα και αν τα διαθέτουμε, μπορώ, χωρίς να είμαι προφήτης, να μαντέψω το αποτέλεσμα. Οπότε αργά η γρήγορα θα αναγκαστούμε να ανοίξουμε το bing μας και να αρχίσουμε το ψάξιμο. Πρίν όμως αρχίσετε να ψάχνετε μανιωδώς, ρίξτε μια ματιά στα παρακάτω τα οποία ελπίζω να σας διευκολύνουν να βρείτε την αιτία του high load. Το πιο σημαντικό είναι να απομονώσουμε το πρόβλημα απαντώντας τις παρακάτω ερωτήσεις: Έχουν εγκατασταθεί τα τελευταία Service Packs και hotfixes; Το πρόβλημα εμφανίζεται σε έναν DC ή σε περισσότερους; Το πρόβλημα παραμένει ακόμα και αν τραβήξω το καλώδιο δικτύου; Το πρόβλημα εμφανίζεται σε συγκεκριμένες ώρες/μέρες ή σε τυχαία χρονικά διαστήματα. Άλλαξε κάτι από τότε που έχουμε το πρόβλημα; (βγήκε π.χ. ένας DC offline) Εφόσον απαντήσουμε τα παραπάνω θα έχουμε σχηματίσει σίγουρα μια άποψη και δεν πάμε στα τυφλά. Στο 90% των περιπτώσεων αρκεί να τρέξουμε στον DC τον Server Performance Advisor. To report που δημιουργείται είναι πολύ ευκολο να αναλυθεί από έναν έμπειρο admin και δίνει μια συνολική εικόνα του τι τρέχει επάνω στον σέρβερ μας την χρονική στιγμή που το πήραμε. Εδώ ένα μικρό παράδειγμα του τι είδους πληροφορίες μπορούμε να πάρουμε: Με μια γρήγορη ματιά βλεπουμε τι προκαλεί το load (top activity) και ποιος προκαλεί το περισσότερο (top client). Και αν θέλουμε περισσότερες πληροφορίες εχουμε και την δυνατότητα του drill down. Εκτός των άλλων δημιουργείται ένα γράφημα perfmon, με το οποίο διαλέγoντας τα κατάλληλα counters, μπορούμε να έχουμε μια γραμική εικόνα του τι διεργασίες συμπίπτουν με το high load του CPU. Ένα άλλο πολύ χρήσιμο εργαλείο είναι το XPerf το οποίο περιγράφεται καταπληκτικά στο σε αυτό το blog post. To tool σχεδιάστηκε για Windows 2008 και Vista. Μια διαφορετική και πολυ χρήσιμη μέθοδος troubleshooting είναι να παίρνουμε network traces (εφόσον διαπιστώσουμε ότι το πρόβλημα δημιουργειται από το δίκτυο) κατά την διάρκεια του high load. Όχι μόνο από τον DC αλλά και από τους clients. Για να κάνω προφανές το τι μπορεί να επιφέρει σε μια μεσαία επιχείρηση ένα απλό logίn script που διαβάζει τα groups ενός χρήστη και κάνει SID to name translation πχ. όπως αυτό. Total users (1.000) x groups the user is member of (~100) x requests for each translation (2) = 200.000 Requests. 3 hours of logon time = ~20 req/sec Και αυτό δεν είναι τίποτα… έχω δει δολοφονικά scritps. Τα traces του DC μπορούν να μεγαλώσουν πολυ σε μέγεθος καθιστώντας πολυ δύσκολη την ανάλυσή τους χωρίς τα κατάλληλα στατιστικά εργαλεία (προτείνω να ανοίγετε case στο MS support). Τα traces όμως από τους clients μπορούν να αποδειχθούν πολυ χρησιμα στην αναγνώριση των προγραμμάτων που ίσως να στέλνουνε παραπάνω traffic από το κανονικό. Εάν η ανάλυση όλων αυτών δεν αποδώσει ένα συμπερασμα υπάρχει και η τελική λύση του LSASS user dump με ADplus ή userdump. To οποίο συνηθίζεται να εμφανίζεται σαν το καλυτερο εργαλείο αλλά κατά την άποψη μου αυτό είναι υπερβολή. Σε μια κατάσταση high load load υπάρχουν αμέτρητα threads, και προσθέστε ότι ένα dump δεν φθάνει, πρεπει να πάρουμε 2 3 στην σειρά. Τα οποία είναι στην ουσία snapshot, και αυτός που τα αναλύει πρέπει σχεδόν να μαντέψει πιο thread κάνει κάτι περίεργο. Προφανώς και θα πρέπει σε αυτή την περίπτωση να ανοίξετε ένα support case στην MS, αν δεν θέλετε να κάψετε τον εγκέφαλό σας. Ελπίζω να έριξα λίγο φως σε αυτό το θέμα, θα χαρώ να απαντήσω σε σχόλια και ερωτήσεις. Φιλικά SOF

Κάποιοι από εσάς ίσως να έχουν αναρωτηθεί, γιατί ένας Admin έχει την δυνατότητα μέσω του MMC Active Directory Users and Computers να βάζει κενό password σε έναν user του domain παρόλο που έχουμε σε ισχύ τα Password Policies “Minimum password length” και “Password must meet complexity requirements”. Το μυστικό βρίσκεται σε ένα AD Attribute του User Object. To UserAccountControl. Εάν το Attribute αυτό περιέχει το flag UF_PASSWD_NOTREQD, τότε μπορεί ένας Administrator να παρακάμψει τα Password Policies και να δώσει ένα κενό password στον χρήστη. Μόνο ο Administrator έχει αυτό το δικαίωμα, αφού ένας απλός χρήστης δεν μπορεί να δώσει στον εαυτό του ένα κενό password. Πως προκύπτει όμως μια τέτοια κατάσταση; Όταν δημιουργούμε έναν νέο user στην κονσόλα, η τιμή του Attribute UserAccountControl δεν περιέχει το flag UF_PASSWD_NOTREQD. Το UserAccountControl ενός απλού χρήστη έχει συνήθως την τιμή 520. Το UF_PASSWD_NOTREQD το συναντούμε τις περισσότερες φορές σε users που έχουν γίνει migrated από ΝΤ4 domains. Μια άλλη κοινή περίπτωση είναι όταν δημιουργούμε χρήστες με script. Τα παρακάτω functions του ADSI βάζουν αυτομάτως το UF_PASSWD_NOTREQD flag. IADsContainer.Create IADs.Put, IADs.SetInfo Εάν δημιουργήσουμε έναν χρήστη μέσω της κονσόλας ADSIEDIT.msc φθάνουμε στην ίδια κατάσταση. Ή επίσης όταν κάνουμε import κάποιον χρήστη μέσω LDIFDE import file του οποίου το UserAccountControl περιέχει ήδη το UF_PASSWD_NOTREQD flag. Συνοψίζοντας τα παραπάνω, βγάζουμε το συμπέρασμα ότι η ύπαρξη του flag αυτού σε ορισμένα user objects είναι κάθε άλλο παρά απίθανη. Ώραία αλλά πως μπορούμε να ελέγξουμε το Active Directory για τους “παραβάτες”; Στο scipt center υπάρχει ένα ωραίο παράδειγμα που με λίγη τροποποίηση μπορεί να κάνει αυτή ακριβώς την δουλειά. http://technet.microsoft.com/en-gb/library/ee198809.aspx Πρέπει απλά να αλλάξουμε το Const ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED = &H80 σε Const ADS_UF_PASSWD_NOTREQD = &H20 Αλλάζοντας τις τιμές των UserAccountControl πάλι στο κανονικό ίσως να αποθαρρύνει τους Administrators να κάνουν τσαχπινιές με τα Password Policies Φιλικά Sof

Security vs. usability. Eίναι μια απόφαση που ο καθένας πρέπει να την λάβει μόνος του. Σε περιβάλλοντα όμως υψηλής κρισιμότητας π.χ. τράπεζες, ο κανόνας της χρησιμοποίησης των ελάχιστων δικαιωμάτων που είναι απαραίτητα για μια εργασία, κατά την άποψη μου είναι απαράβατος. Το παραπάνω attack μπορούμε να το αποφύγουμε θέτοντας σε ισχύ το NTLM Blocker feature του Windows 2008 R2.

Το σημαντικό που πρέπει να κρατήσουμε από αυτή την ιστορία, δεν είναι πώς μπορεί να γίνει κάποιος local admin. Υπάρχουν πολλοί τρόποι. Το κυρίως νόημα της υπόθεσης είναι πως τα hashes όλων το δηλωμένων χρηστών. Αυτών δηλαδή που έχουν κάποιο logon session ανοιχτό στο μηχάνημα αυτό δεν προστατεύονται ουσιαστικά από την κλοπή. Δεν αποτελεί προϋποθεση να ξέρουμε το όνομα του admin, μπορούμε να δοκιμάσουμε απλά όλα τα αποτελέσματα του whosthere. Βασική προϋπόθεση φυσικά είναι να χρησιμοποιούμε NTLM. Δοκίμασε το να δείς οτι ναι, είναι τόσο απλό

Ιδού λοιπόν για τους δύσπιστους. Θεωρία: Hernan Ochoa - Pass-The-Hash Toolkit for Windows Πράξη, είναι ποσταρισμένο στο youtube, με ότι αυτό συνεπάγεται: Συμπέρασμα; ΜΗΝ ΚΑΝΕΤΕ LOGIN ΜΕ DOMAIN ADMIN CREDENTIALS ΠΑΡΑ ΜΟΝΟ ΕΚΕΙ ΠΟΥ ΕΙΝΑΙ ΑΠΟΛΥΤΩΣ ΑΝΑΓΚΑΙΟ. Σχόλια; Greetings SOF

Αυτό το post είναι μια μικρή υπενθύμιση σε όλους εμάς τους Domain Admins, κάτι σαν post it. Ποτέ (και το εννοώ), ποτέ μην χρησιμοποιείτε έναν Domain Admin για συντήρηση, troubleshooting, online βοήθεια σε workstations του Domain. Ο ρόλος του Domain Admin είναι αυστηρά περιορισμένος , και τα μηχανήματα που πρέπει να κάνει login συγκεκριμένα και απολύτως ελεγχόμενα. Αμφιβάλλω αν υπάρχουν καθημερινές εργασίες συντήρησης σε workstations και member servers που χρειάζονται domain admin rights. Είμαι σίγουρος ότι οι περισσότεροι από εμάς έχουμε αυτηρά policies σε αυτό το θέμα, αλλά δεν βλάπτει μια στο τόσο να ελέγχουμε ποιος κατέχει αυτά τα rights και που τα χρησιμοποιεί. Γιατί το αναφέρω; Όχι δεν υπάρχει κάποιο καινούργιο malware, ούτε βρέθηκε κάποιο νέο vulnerability στα καινούργια λειτουργικά. Ο κίνδυνος να χάσει κάποιος το domain υπάρχει από το 1997 (εποχή ΝΤ) και συνεχίζεται μέχρι σήμερα. Και για να αποτραπεί απλά αρκεί λίγη προσοχή. Κινδυνολογίες; Ίσως. Αλλά γιατί να μην είμαστε θωρακισμένοι; Αν δεν σας έπεισα, περιμένετε το επόμενο post που θα έχει τίτλο, δώσε μου έναν local Admin να σου πάρω το domain. Φιλικά SOF

Μπράβο παιδιά! Κρίμα που το έχασα αυτό.

Σήμερα το μενού έχει scripting. Πώς κάνουμε export την τιμή ενός AD Attribute με vbscript? Ξέρω, ξέρω προφανώς και υπάρχουν αμέτρητα άρθρα επί του θέματος, αλλά διαβάστε τα παρακάτω και δεν θα χάσετε! Αρχίζουμε με τα απλά: Τι γίνεται αν το Attribute name περιέχει τον χαρκτήρα “-“; Ύστερα από αρκετό ψάξιμο βρίσκουμε το εξής post του γνωστού scripting guy: http://blogs.technet.com/heyscriptingguy/archive/2005/06/21/how-can-i-retrieve-the-value-of-an-active-directory-attribute-that-has-a-hyphen-in-its-name.aspx Τι γίνεται αν το Attribute name περιέχει τον χαρκτήρα “-“ ΚΑΙ είναι multivalued; Ooops πρόβλημα έτσι; Εμένα μου πήρε λίγη ωρίτσα να το βρώ, η λύση παρακάτω. Option Explicit Dim strMetaDataEntry, strDNSDomain, strContainer Dim objGroup, objRootDSEDim arrMetaData strContainer = "cn=<group name>,cn=<container>, " Set objRootDSE = GetObject("LDAP://RootDSE") strDNSDomain = objRootDSE.Get("DefaultNamingContext") Set objGroup = GetObject ("LDAP://"& strContainer & strDNSDomain) objGroup.getInfoEx array("msDS-ReplValueMetaData"),0 arrMetaData = objGroup.GetEx("msDS-ReplValueMetaData") ' Loop = For Each .... Next WScript.Echo "Metadata for members of: " & strContainer For Each strMetaDataEntry in arrMetaData WScript.echo strMetaDataEntry Next Wscript.Quit Ελπίζω να σας φανεί χρήσιμο! P.S Το script είναι κλινικά δοκιμασμένο , αλλά δεν αναλαμβάνω ευθύνη! Φιλικά SOF