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

Πλησιάζοντας τον μήνα από το Release Date των Windows 2008 R2, ήδη πολλές επιχειρήσεις έχουν στο καλεντάρι τους την εγκατάσταση του πρώτου τους Windows 2008 R2 Domain Controller. Με την ευκαιρία αυτή θα δούμε σε συντομία τι πρέπει να προσέξουμε πριν την αναβάθμιση του Schema του AD σε R2 σχετικά με τα lingering objects. Προφανώς επειδή πρόκειται για σχετικά κανούργια διαδικασία, ενδέχεται να υπάρχουν σημεία τα οποία δεν τα έχω λάβει υπόψη. Σχόλια και παρατηρήσεις είναι ευπρόσδεκτα. Ας αρχίσουμε λοιπόν. Κατά την αναβάθμιση του Schema σε R2 είναι γνωστό ότι εισάγoνται και τα extensions για το Recycle Bin. Ακόμα και πριν ενεργοποιηθεί ο Recycle Bin, τα objects του AD προετοιμάζονται για να τον υποστηρίξουν με την εισαγωγή του isRecycled attribute. Αυτό φυσικά ισχύει και για τα deleted objects. Ύστερα από την αναβάθμιση μπορεί να προκύψουν μηνύματα λάθουs που να ισχυρίζονται ότι υπάρχουν lingering objects στο AD. Συνήθως το πρόβλημα αυτό προκύπτει σε περιβάλλοντα με πολλές καθημερινές εγγραφές/διαγραφές χρηστών, DNS records κ.α. Το αποτέλεσμα είναι να σταματά το replication μέχρι να τρέξει ο Garbage Collector στον source DC. Το "πρόβλημα" αυτό λύνεται από μόνο του, αφού δεν πρόκειται για πραγματικά lingering objects. Μια ματιά στο υπόβαρθρο. Το μοντέλο που ακολουθεί το Active Directory για τον συγχρονισμό των δεδομένων είναι το loose consistency with convergence Σύμφωνα με αυτό το μοντέλο, κανείς δεν μπορεί να εγγυηθεί ότι σε ένα συγκεκριμένο χρονικό σημείο κάθε replication partner θα έχει ακριβώς τα ίδια objects, αφού επιτρέπεται να γίνονται αλλαγές σε κάθε έναν από αυτούς. Εαν όμως το σύστημα αφεθεί να φθάσει σε μια ισορροπία, μην επιτρέποντας οποιεσδήποτε αλλαγές για το χρονικό διάστημα που απαιτείται για να συγχρονιστούν οι πληροφορίες μεταξύ τους, τότε η τελική κατάσταση είναι εγγυημένα η ίδια παντού. Στην περίπτωση μας συγκεκριμένα αυτό που συμβαίνει είναι το εξής: α.) Γίνεται το schema update. β.) Επηρρεάζεται ένα deleted object του οποίου το Tombstone Lifetime λήγει σήμερα, και θα το διαγράψει ο garbage collector στην επόμενη προγραμματισμένη εκτέλεσή του. γ.) Ο garbage collector του DC προορισμού έχει τρέξει ήδη, διαγράφοντας μόνιμα το αντικείμενο αυτό. δ.) O DC της πηγής προσπαθεί να συγχρονίσει με τον DC προορισμού. ε.) Ο DC προορισμού δηλώνει άγνοια για το αντικείμενο αυτό, και καταχωρεί το μήνυμα NTDS Event ID: 1988 ζ.) Ο DC προορισμού μπλοκάρει το εισερχόμενο replication, λόγω του strict replication consistency. στ.) O source DC εκτελεί τον garbage collector και το πρόβλημα λύνεται, εφόσον δεν προσπαθεί να συγχρονίσει πλέον το συγκεκριμένο object. Τα άρθρα σχετικά με το Tombstone Lifetime και τον Garbage Collector: The Active Directory database garbage collection process The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2 Εάν για κάποια επιχείρηση η καθυστέρηση του replication μέχρι 12 ώρες από site σε site μπορεί να σημαίνει σημαντική απώλεια κερδών, σκαρφιστίκαμε έναν τρόπο να ελλατώσουμε τις απώλειες αν όχι να τις αποφύγουμε εντελώς. α.) Προαιρετικά: αυξάνουμε παντού την συχνότητα εκτέλεσης του garbage collector. Στο παραπάνω άρθρο περιγράφεται πώς. β.) Συγχρονίζουμε παντού την εκτέλεση του garbage collector. Η εκτέλεση μπορεί να επιβληθεί τοπικά με την εντολή: repadmin /setattr "" "" doGarbageCollection add "1", ή ακολουθώντας τις οδηγίες εδώ. Το καλύτερο θα ήταν να προγραμματίσουμε την εκτέλεση σε κάποιο χρονικό σημείο όπου πραγματοποιούνται οι λιγότερες αλλαγές στην βάση δεδομένων του AD. γ.) Ακριβώς μετά από την εκτέλεση του garbage collector, (τουλάχιστον μία μέρα μετά τις παραπάνω αλλαγές), αυξάνουμε την τιμή του Tombstone Lifetime στο Hub site. Αυτή η αλλαγή θα μεταφερθεί στους υπολοιπους με το replication. Το σημαντικότερο πριν την εκτέλεση αυτού του βήματος είναι να έχουμε όσο το δυνατότερο την ίδια κατάσταση σχετικά με τα διαγραφέντα αντικείμενα από την προηγούμενη εκτέλεση του garbage collector. δ.) Εκτέλεση του Schema upgrade, ε.) Προαιρετικά: μείωση του TBL στην αρχική τιμή. Επιβάλουμε την εκτέλεση του garbage collector ξανά. Μειώνουμε την συχνότητα εκτέλεσης στην προηγούμενη τιμή. Προς το παρόν δεν υπάρχει κάποιο δημοσιευμένο KB επί του θέματος, αλλά απ' ότι ξέρω βρίσκεται ένα στα σκαριά. Ελπίζω να βρήκατε τα παραπάνω χρήσιμα! Έστω και αν δεν σκοπεύετε να αναβαθμίσετε το schema σύντομα, τα περισσότερα αφορούν γενικά την λειτουργία του AD replication, οπότε αξίζει να τους ρίξετε μια ματιά! Φιλικά SOF

Γεια σου Γιώργο, θα γελάσεις αλλά τα προβλήματά μου ξεκίνησαν με το πώς να βάλω στατική IP στο Linux box και τελείωσαν με το ποιό encryption υποστηρίζει το mod_auth_kerb του apache. Τα ένδιάμεσα τα κόβει η λογοκρισία. Νιώθω τυχερός που το πέτυχα. Τον περισσότερο χρόνο ουσιαστικά τον έφαγα στην εξοικείωση με το λειτουργικό και τα υπόλοιπα ήταν μικρά λάθη όπως case sensitivity. Το keytab δεν είναι τίποτα άλλο από ένα password file. Γι αυτό πρέπει το ασφαλίζουμε αναλόγως. Στην περίπτωσή μας περιέχει το shared key του service. Αυτό το key είναι βασική προϋπόθεση για να δουλέψει το Kerberos. To service χρησιμοποιεί το κλειδί για να αποκρυπτογραφήσει το service ticket που στέλνει ο Client me το ΚΡΒ AP Req. Στο παρακάτω link θα βρείς ένα toolάκι που κάνει αυτόματα dump σε keytab όλa τa AD accounts. !!!Προσοχή!!! Ποτέ σε live environment, μόνο για training purposes! Η διαφορά του με το ktpass είναι ότι κάνει extract τa hashes από το database αντί να δημιουργεί καινούργια. http://www.ioplex.com/utilities/ Μπορείς να το χρησιμοποίήσεις για να κάνεις decrypt to Kerberos traffic.

Γειά σας και πάλι μετά από καιρό. Έχω μαζέψει τόσα πολλά θέματα που θέλω να μοιραστώ μαζί σας που δεν ήξερα από που να αρχίσω. Διάλεξα λοιπόν να συνεχίσω από εκεί που σας άφησα την τελευταία φορά. Η ιδέα ανήκει στον GSimos. Το μενού σήμερα έχει λίγο απ’όλα, Windows, Linux, και το αγαπημένο μου θέμα που είναι: μαντέψτε Kerberos. Πριν αρχίσω μια μικρή διευκρίνηση, οι γνώσεις μου σχετικά με το Linux είναι <=0, οπότε θα περιοριστώ αποκλειστικά σε αυτά που θα τεστάρω. Το σημερινό θέμα είναι αρκετά δύσκολο, και προϋποθέτει βασικές γνώσεις σε αρκετά αντικείμενα. Έχουμε το εξής σενάριο: Windows Active Directory Domain. Linux Intranet Web Server Active Directory Users Θέλουμε: Οι χρήστες του Active Directory να έχουν πρόσβαση στο intranet site που τρέχει σε Linux χωρίς να χρειάζεται να δίνουν ξανά τα στοιχεία τους. Υπάρχουν πολλές σελίδες στο Internet που παρέχουν πάρα πολλές πληροφορίες πάνω σε αυτό το θέμα, οι περισσότερες όμως είναι για Windows 2000/2003 και XP, θεωρητικά δεν θα πρέπει να διαφέρει σε τίποτα από τα 2008 και Vista/W7, έτσι δεν είναι; Καλή η θεωρία αλλά για να δούμε στην πράξη. Ας το πάρουμε βήμα βήμα για να δούμε που θα μας βγάλει. Ας αρχίσουμε λοιπόν. Βήμα 1ο) Εγκατάσταση λειτουργικών σε Virtual PC. Linux Ubuntu-8.10 (Web Server = linuxwebserver) Windows Server 2008 (Domain Controller = 2008dc) Vista (Client = Vista1) Βήμα 2ο) Active Directory: βασικές ρυθμίσεις Ρυθμίζουμε static IPs. (DC = 192.168.2.100, Vista = 192.168.2.50) Εγκατάσταση του DNS Server στον 2008 dcpromo του Windows Server 2008, (FFL 2008) Domain join του Vista client Δημιουργία ενός Active Directory χρήστη για testing (intuser). Βημα 3ο) Linux: βασικές ρυθμίσεις Ρυθμίζουμε static IP. Eγκατέστησα έναν DHCP με reservation στο MAC του Linux (IP= 192.168.2.200), επίσης καταχώρησα την IP του DNS Server (192.168.2.100) στο /etc/resolv.conf. (Εχω ήδη στα VMs μου έναν Windows 2003 router που κάνει NAT, οπότε έβαλα έναν forwarder στον AD DNS να δείχνει σε έναν εξωτερικό, για να κάνω resolve τις διευθύνσεις που χρειάζονται για να εγκαθιστώ τα πακέτα) To ping dc2008.acme.com από το Linux αργεί απελπιστικά όμως. Για να δούμε το Network Trace. Reverse DNS queries. Φτιάχνω μια reverse lookup zone στο DNS και τρέχω ένα ipconfig /registerdns πάνω στον DC και τώρα πάει μια χαρά. Από networking φαίνεται να είμαστε εντάξει. Πάμε στα applications και στις υπόλοιπες ρυθμίσεις. Βήμα 4ο) Εγκατάσταση του Apache sudo apt-get install apache2 ! Τα επόμενα βήματα απαιτούν αρκετή προσοχή. Μου κόστισε μια μέρα να καταλάβω ότι τα κεφαλαία/μικρά παίζουν πολυ σημαντικό ρόλο. Case Sensitive λοιπόν. Βήμα 5ο) Δημιουργία του Web Server account στο Active Directory Ανοίγω το dsa.msc –> new user –> apacheuser Στο command prompt τρέχω: setspn -a HTTP/linuxwebserver.acme.com apacheuser setspn -a HTTP/linuxwebserver apacheuser Για να δημιουργήσω το keytab file: ktpass -princ HTTP/[email protected] -mapuser apacheuser -pass P@ssw0rd -ptype KRB5_NT_PRINCIPAL -out c:\apacheuser.http.keytab Targeting domain controller: 2008DC.acme.com Using legacy password setting method Successfully mapped HTTP/linuxwebserver.acme.com to apacheuser. Key created. Output keytab to c:\apacheuser.http.keytab: Keytab version: 0x502 keysize 72 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x17 (RC4-HMAC) keylength 16 (0xe19ccf75ee54e06b06a5907af13cef42) Καταχωρώ στο DNS ένα Α Record –> linuxwebserver.acme.com 192.168.2.200 Βήμα 6ο) Ρύθμιση του Kerberos στον Web Server sudo apt-get install krb5-user libpam-krb5 (Πιθανόν να μην χρειάζεται) krb5-config libkadm55 (Πιθανόν να μην χρειάζεται) libapache2-mod-auth-kerb Ρύθμιση του /etc/kerb.conf [libdefaults] default_realm = ACME.COM # The following krb5.conf variables are only for MIT Kerberos. kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] ACME.COM = { kdc = 2008dc.acme.com:88 admin_server = 2008dc.acme.com default_domain = acme.com } [domain_realm] .acme.com = ACME.COM acme.com = ACME.COM Αντιγραφή του keytab apacheuser.http.keytab από τον DC sto /etc/apache2/ Ρύθμιση του /etc/apache2/apache2.conf με τις ακόλουθες επιπλέον εγγραφές ServerName linuxwebserver.ACME.COM <Directory "/var/www/"> AuthName "Kerberos Login" AuthType Kerberos Krb5Keytab /etc/apache2/apacheuser.http.keytab KrbAuthRealm ACME.COM KrbMethodNegotiate on KrbMethodK5Passwd off KrbSaveCredentials off KrbVerifyKDC off KrbServiceName HTTP/linuxwebserver.acme.com Require valid-user </Directory> Κάνουμε restart τον Apache: sudo service apache2 restart Μέχρι στιγμής οι ρυθμίσεις είναι οι ίδιες με τα Windows 2003, για να δούμε αν λειτουργεί το Kerberos authentication από την μεριά του Linux. Προσπαθούμε πρώτα χωρίς το keytab: Όπως φαίνεται κάτι δεν πάει καλα, οπότε κοιτάμε το network trace στον DC όπου βλέπουμε το εξής: KRB Error: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN Κάνοντάς το ένα γρήγορο search βλέπουμε ότι έχει βγεί hotfix για αυτό ακριβώς το θέμα. An error code is returned when a Kerberos client requests a TGT against a Windows Server 2008-based domain controller: "KERB5KDC_ERR_C_PRINICPAL_UNKNOWN" Μια μικρή διευκρίνηση: το string της μορφής <service principal name>@<domain name> σύμφωνα με τα RFCs δεν είναι αποδεκτό UPN. Τα Windows 2008 είναι πιο αυστηρά σε αυτό το θέμα, αλλά για όσους θέλουν για λόγους συμβατότητας να χρησιμοποιούν και αυτή την μορφή, μπορούν να εγκαταστήσουν το hotfix. Ας δούμε μετά το hotfix τα αποτελέσματα: Ολοκληρώθηκε με επιτυχία! Εδώ και το network trace: Το τελευταίο πακέτο είναι το σημαντικό που δείχνει ότι λάβαμε το TGT, αυτό που πρέπει να προσέξουμε είναι ότι δεν χρησιμοποιούμε πλέον RC4-HMAC αλλά AES256 για την κρυπτογράφηση του TGT και του session key. Ας προσπαθήσουμε να δηλωθούμε λοιπόν με το keytab. “Key table entry no found while getting initial credentials” και εδώ είναι που κολλάμε και αρχίζουμε να τα ξεψαχνίζουμε όλα από την αρχή, SPNs UPNs conf files κτλ. Ουσιαστικά αυτό που καταλαβαίνουμε από το μύνημα λάθους είναι ότι δεν βρέθηκε η συγκεκριμένη εγγραφή με το κλειδί στο keytab file. H εγγραφή από τι αποτελείται; Από το principal και από το key, εφόσον βεβαιωθούμε ότι το principal είναι σωστό τότε δεν μπορεί να φταίει παρά μόνο το κλειδί. Βingo! To κλειδί είναι κάτι που άλλαξε από τα 2003. Δεν είναι πλέον RC4-HMAC είναι AES256. Ας προσπαθήσουμε το εξής ktpass -princ HTTP/[email protected] -mapuser apacheuser -pass P@ssw0rd -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL –out c:\apacheuser.http.keytab Αντιγράφουμε το keytab file στην γνωστή τοποθεσία /etc/apache2/apacheuser.http.keytab και δοκιμάζουμε ξάνά την τύχη μας. Δεν πέταξε λάθος οπότε είμαστε σε καλό δρόμο. Ας τεστάρουμε λοιπόν ολόκληρο το οικοδόμημα. Ρυθμίζουμε τα security settings του Vista έτσι ώστε να χρησιμοποιούμε το Negotiate protocol και απομένει να πατήσουμε το enter στον ΙΕ! Τζίφος! στο error.log του apache βλέπουμε: [client 192.168.2.50] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (Key table entry not found) Και πάλι δεν μπορούμε να εντοπίσουμε το keytab entry. Οπότε το μόνο που μας έμεινε είναι να δοκιμάσουμε με άλλη κρυπτογράφηση. Για να δούμε με Des… ktpass -princ HTTP/[email protected] -mapuser apacheuser -pass P@ssw0rd +Desonly -ptype KRB5_NT_PRINCIPAL -out c:\apacheuser.http.keytab Targeting domain controller: 2008DC.acme.com Using legacy password setting method Successfully mapped HTTP/linuxwebserver.acme.com to apacheuser. Key created. Output keytab to c:\apacheuser.http.keytab: Keytab version: 0x502 keysize 64 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 24 etype 0x3 (DES-CBC-MD5) keylength 8 (0x193d7f680845431f) Account apacheuser has been set for DES-only encryption. Επιτέλους τα καταφέραμε! Στο access.log του apache βλέπουμε ότι ο intranet user (intuser)απέκτησε πρόσβαση: 192.168.2.50 - [email protected] [13/Apr/2009:23:10:34 +0300] "GET / HTTP/1.1" 200 56 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)" Και το network trace.. όμορφο έτσι; Προφανώς ο λόγος που δεν παίζει το AES256, είναι ότι κάτι πάει στραβά στο apache module, αφού με το kinit λειτουργεί μια χαρά. Το ότι στην λύση μας χρησιμοποιούμε DES αντί για του πολύ ανώτερου AES256 είναι μειονέκτημα, αλλά λιγότερο επικίνδυνο από ενα χαμένο USB stick με τα keytabια μέσα. Ονόματα δεν λέμε οικογένειες δεν θίγουμε Δεν κρύβω ότι σερφάροντας ώρες ατελείωτες για να βρώ λύσεις στα προβλήματα πολλές φορές κουράστηκα από το άναρχο documentation του Linux, δεν ήταν λίγες όμως και οι φορές που διαπίστωσα στα forums παρόμοια διάθεση από τους φίλους Linuxάδες. Το τελικό συμπέρασμα είναι το εξής: το πάντρεμα δύο διαφορετικών τεχνολογιών είναι πάντα δύσκολο, ειδικά αν προκειται για νέα προϊόντα, αλλά όπως δείξαμε όχι ακατόρθωτο. Eλπίζω το άρθρο να σας φανεί χρήσιμο. Θα χαρώ για σχόλια updates και διορθώσεις. Φιλικά SOF

Αρχικά έρχεται στο μυαλό μας ότι κάτι δεν πάει καλά με το Account Lockout Policy, ή κάποιες υπηρεσίες στις οποίες υπάρχει καταχωρημένος ένας κωδικός που έχει λήξει. Όταν όμως αυτή η συμπεριφορά όσο πάει και χειροτερεύει και δεν αφορά έναν μοναδικό λογαριασμό αλλά περισσότερους, είναι πιθανό να έχουμε μια επίθεση στο δίκτυό μας. Όταν για παράδειγμα ένα πρόγραμμα ή ένα Malware προσπαθεί να σπάσει τους κωδικούς διάφορων χρηστών με Brute Force Attack. Όταν μια τέτοια επίθεση είναι αυτοματοποιημένη , τότε κλειδώνονται πολύ γρήγορα ένας μεγάλος αριθμός από λογαριασμούς, λόγω λάθος εισαγωγής κωδικού. Ένα παράδειγμα είναι το MalWare Win32/Conficker.B (Downandup) το οποίο είναι αυτήν την στιγμή σε έξαρση. Περισσότερες πληροφορίες για το Malware θα βρείτε εδώ: http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.B <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> Το Malware επιτίθεται σε συστήματα που δεν έχουνε εγκατεστημένο το patch MS08-067, http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx Στα μηχανήματα που έχουν προσβληθεί από τον ιό ξεκινά μια υπηρεσία με τυχαίο όνομα, και απενεργοποιεί τα services „Automatic Updates“, „Background Intelligent Transfer Service“ και „Error Reporting Service“. Στο System Event Protocol καταγράφεται η εξής ακολουθία. 12/29/2008 16:00:04 4 0 7035 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME RANDOΜ_NAME start 12/29/2008 16:00:05 4 0 7035 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Automatic Updates stop 12/29/2008 16:00:06 4 0 7036 Service Control Manager N/A CLIENTNAME Automatic Updates stopped 12/29/2008 16:00:10 4 0 7040 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Automatic Updates auto start disabled 12/29/2008 16:00:10 4 0 7040 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Background Intelligent Transfer Service demand start disabled 12/29/2008 16:00:10 4 0 7035 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Error Reporting Service stop 12/29/2008 16:00:10 4 0 7036 Service Control Manager N/A CLIENTNAME Error Reporting Service stopped 12/29/2008 16:00:14 4 0 7040 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Error Reporting Service auto start disabled Στα Services η υπηρεσία του ιού δεν είναι ορατή, γιατί είναι hidden. Το Service τρέχει κάτω από το Service Host SVCHOST Troubleshooting steps. 1) Καταρχάς θα πρέπει να βρούμε τα μηχανήματα που έχουν είδη προσβληθεί, θα πρεπει να ενεργοποιήσουμε το Neltlogon logging σε όλους τους DCs. http://support.microsoft.com/kb/109626 Τα Account Lockout Tools είναι σε αυτή την περίπτωση επίσης πολύ χρήσιμα. http://www.microsoft.com/downloads/details.aspx?familyid=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en 2) Απενεργοποίηση του Server Service για να αποφύγουμε το re-infection. 3) Ενεργοποιούμε το Windows Update και το BITS 4) Κάνουμε reset όλους τους admin passwords με πολύπλοκους κωδικούς. 5) Κατεβάζουμε το GMER Tool για να βρούμε και να απενεργοποιήσουμε την υπηρεσία. http://www.gmer.net/gmer.zip 6) Ενεργοποιούμε το Server Service ξανά. 7) Τρέχουμε το gmer, θα βρεί τον ιο με ένα quick scan. 8) Κάνουμε ένα full scan. 9) Σημειώνουμε το dll που επιστρέφεται από το gmer. 10) Δεξί κλικ στην κόκκινη γραμμή και απενεργοποιούμε την υπηρεσία. 11) Επανεκκίνηση του συστήματος. 12) Μόλις το σύστημα ξεκινήσει, βρίσκουμε το dll που σημειώσαμε προηγουμένως στο εξής path: c:\windows\system32 (ίσως χρειαστεί να αλλάξουμε τα view settings για να το δούμε) 13) Ανοίγουμε το gpedit στον DC και δημιουργούμε μια software restriction policy βασισμένη στο hash του dll που βρήκαμε. http://technet.microsoft.com/en-us/library/cc786154.aspx (Μπορούμε επίσης να δημιουργήσουμε ένα local policy για το συγκεκριμένο μηχάνημα 14) Τα παραπάνω βήματα θα σταματήσουν τον ιο τώρα μπορούμε να Patchάρουμε τα μηχανήματά μας! Καλή επιτυχία!!

Μπράβο!! Πολύ καλό το άρθρο! Τα WMI queries όπως λέει και ο Gsimos μας γλιτώνουν από αρκετά αδιέξοδα. Πρέπει όμως να τα κρατάμε "λιτά" για τους εξής λόγους. 1) Κοστίζουν αρκετά σε χρόνο εκτέλεσης, με άμεσο αποτέλεσμα το αργό logon 2) Είναι δύσκολο το troubleshooting τους. Περιμένουμε και άλλα τέτοια άρθρα!!!

Teleio!!!

Γεια σας, είμαι o Sof! Μπαίνω και εγώ στο trend των ημερών, το outsourcing. Σήμερα θα δούμε πώς μπορούμε να κρύψουμε συγκεκριμένα objects του Active Directory από επιλεγμένους χρήστες ή Groups. Παίρνουμε για παράδειγμα το εξής σενάριο .Έχουμε ένα Active Directory Integrated Application που τρέχει στο περιβάλλον μας. Αυτό το application εξυπηρετεί δύο διαφορετικές τράπεζες. Σκοπός μας είναι να μην αφήνουμε τους χρήστες της τράπεζας Α να μπορούν να δουν τα Active Directory objects της τράπεζας Β. Η λύση σε αυτό το πρόβλημα περιγράφεται εδώ: Controlling Object Visibility Καταλάβατε κάτι από το παραπάνω άρθρο; Εγώ ειλικρινά χρειάστηκε να το διαβάσω 5-6 φορές μέχρι να βρω τι παίζει. Ας δούμε παρέα πως γίνεται. 1) Ανοίγουμε το Active Directory Users and Computers. Δημιουργούμε δύο Organizational Units (OUs), μια για κάθε τράπεζα, μέσα στο ΟU θα βρίσκονται όλα τα objects (users, computers κοκ) της τράπεζας. Δημιουργούμε δύο χρήστες, έναν για κάθε OU για τεστ. Αν δηλωθούμε σε ένα workstation ως BankA_User και θέλουμε να δώσουμε δικαιώματα σε ένα φάκελο, θα δούμε ότι ψάχνοντας στο Active Directory για ονόματα, ο χρήστης της άλλης τράπεζας είναι μέσα στην λίστα μας. Προφανώς αυτό δεν πρέπει να συμβαίνει. Για αυτό λοιπόν προχωρούμε με τις ρυθμίσεις μας. 2) Στο Active Directory Users and Computers κάνουμε κλίκ στο View--> Advances Features. 3) Κάνοντας δεξί κλικ επάνω στο Bank B OU --> Properties, παρατηρούμε ότι το Security tab του OU είναι πλέον διαθέσιμο. Στα security settings του Bank B OU προσθέτουμε τον χρήστη BankA_User, και κάνουμε deny στο Read. 4) Αν πάμε τώρα στο workstation που είμαστε δηλωμένοι ως BankA_User και προσπαθήσουμε να επιλέξουμε χρήστες για να τους δώσουμε δικαιώματα στα αρχεία μας, θα δούμε ότι ο χρήστης της άλλης τράπεζας BankB_User δεν είναι εκεί. Αυτό ισχύει φυσικά για οποιοδήποτε άλλο object εντός του OU. Τα παραπάνω είναι απλά ενδεικτικά. Σε κανονικά περιβάλλοντα δεν είναι δυνατόν να κάνουμε deny σε κάθε χρήστη ξεχωριστά. Μπορούμε όμως να ακολουθήσουμε την ίδια μεθοδολογία με Groups. Εφόσον κάνουμε τις παραπάνω ρυθμίσεις. οποιοδήποτε application τρέχει με τα credentials του χρήστη από την τράπεζα Α θα του αρνείται η πρόσβαση σε αντικείμενα της τράπεζας Β. Θα χαρώ να απαντήσω σε ερωτήσεις! Θα τα πούμε σύντομα!

Γεια σας! Είμαι ο Sof, σήμερα θα αφιερώσω ολόκληρο το post στο troubleshooting του Kerberos Delegation. Σε έναν ιδανικό κόσμο όπου τα event logs είναι κάτασπρα δίχως errors και warnings (τα warnings με εκνευρίζουν αφάνταστα!), κανονικά θα έπρεπε να παραλείψω αυτή την ενότητα. Δυστυχώς αυτή η εποχή αργεί ακόμα. Ας αρχίσουμε λοιπόν. Θα προσπαθήσω να κρατήσω το post απλό, σε καταστάσεις που "καίνε" δεν υπάρχουν περιθώρια για περιττές πληροφορίες. Εφόσον διαπιστώσουμε ότι τα πράγματα δεν λειτουργούν όπως τα είχαμε φανταστεί το πρώτο βήμα είναι να ελέγξουμε τις ρυθμίσεις. Ο πιο εύκολος και γρήγορος τρόπος είναι να χρησιμοποιήσουμε το DelegConfig tool που το κάνει αυτόματα για μας. Στο 50% των περιπτώσεων το πρόβλημα εντοπίζεται σε αυτό ακριβώς το σημείο. Το tool καθώς και οδηγίες εγκατάστασης θα τα βρείτε εδώ: Blog of "Brian Murphy-Booth" a.k.a. "Brian Booth" Πριν δοκιμάσετε οτιδήποτε άλλο τρέξτε αυτό το utility!!! Κάποιες φορές αποτυγχάνει η εκτέλεση ακόμα και του troubleshooting tool. Εδώ είναι που πρέπει να προχωρήσουμε με υπομονή και σχολαστικά και να ελέγξουμε όλες τις παρακάτω ρυθμίσεις. Checklists Θα δούμε περιληπτικά τα κυριότερα σημεία που μπορεί να γίνει κάποιο λάθος, θα βρείτε αναλυτικά τις ρυθμίσεις στα δύο προηγούμενα posts. Checklist 1. Client Side Ο στόχος μας είναι να βεβαιωθούμε ότι ο client χρησιμοποιεί Kerberos, εκτός και αν έχουμε υλοποιήσει Kerberos Protocol Transition οπότε οι ρυθμίσεις του client δεν παίζουν κανέναν ρόλο. 1) Το application υποστηρίζει Kerberos Authentication. 2) O client να έχει ενταχθεί στο Active Directory forest. 3) ώρα δεν πρέπει να έχει μεγαλύτερη διαφορά από 5 λεπτά από τον Domain Controller. 4) To name resolution λειτουργεί. Κάνοντας ένα ping στο middle tier και στο back end διαπιστώνουμε εάν μπορούμε να κάνουμε resolve τα FQDN τους. Εάν βρισκόμαστε σε διαφορετικό domain από το middle tier βεβαιωνόμαστε ότι χρησιμοποιούμε το FQDN και όχι το NETBIOS. 5) Ο τελικός χρήστης δεν πρέπει να έχει ορισμένη την ρύθμιση: account is sensitive and cannot be delegated 6) Το Application είναι σωστά ρυθμισμένο. Οι ρυθμίσεις φυσικά διαφέρουν από app σε app. Στο πρώτο μέρος είδαμε παραδείγματος χάρη τις ρυθμίσεις που απαιτούνται για τον Internet Explorer. Περιληπτικά: Το site πρέπει να είναι καταχωρημένο στις local intranet zones. Και στα security settings να είναι τσεκαρισμένο το automatic logon. Για sites εντός του intranet να παρακάμπτεται ο proxy server 7) Βεβαιωνόμαστε ότι ο Client χρησιμοποιεί Kerberos για την σύνδεσή του με το middle tier. Υπάρχουν διάφοροι τρόποι για να ελέγξουμε αν ο Client όντως χρησιμοποιεί Kerberos. Προσωπικά προτιμώ να παίρνω ένα network trace στον client χρησιμοποιώντας ένα network sniffer όπως το Wireshark ή το Netmon 3.2. Good Trace (Kerberos Traffic) Μπορούμε επίσης να ελέγξουμε τα security logs του web server για successful logon events. Event Type: Success Audit Event Source: Security Event Category: Logon/Logoff Event ID: 540 Date: 12/6/2008 Time: 8:50:38 AM User: SOF\TestUser Computer: IIS-SRV Description: Successful Network Logon: User Name: TestUser Domain: SOF Logon ID: (0x0,0x106FB9) Logon Type: 3 Logon Process: Kerberos Authentication Package: Kerberos Workstation Name: Logon GUID: {09347f79-5bc9-86a9-bb0c-7e4b7c7d16a7} Checklist 2. Middle Tier Με το checklist του middle tier βεβαιωνόμαστε ότι οι ρυθμίσεις είναι τέτοιες ώστε να επιτρέπουν να γίνεται delegation. 1) Ελέγχουμε αν ο server και τα services του middle tier υποστηρίζουν Kerberos. 2) Ελέγχουμε αν τα SPN είναι σωστά καταχωρημένα (Έφαγα ένα απόγευμα γιατί αντί για http/iis-srv.sof.local είχα καταχωρίσει htttp/iis-srv.sof.local). Προσωπικά προτιμώ να χρησιμοποιώ το ldifde tool για να βλέπω τα καταχωρημένα SPNs: ldifde -f SPN.txt -l ServicePrincipalName -r "(ServicePrincipalName=HTTP/IIS-SRV*)" -d DC=sof,dc=local 3) Ανοίγουμε το Active Directory Users and Computers για να ελέγξουμε το Delegation Σε περίπτωση που χρησιμοποιούμε το computer account του middle tier για delegation: Αν βρισκόμαστε σε domain level 2000 (το unconstrained delegation ήταν διαθέσιμο ήδη από τα Windows 2000), πάμε στο general tab και τσεκάρουμε το trust computer for delegation. Αν βρισκόμαστε σε domain level 2003 τότε πάμε στο Delegation Tab και ανάλογα τι θέλουμε να υλοποιήσουμε πρέπει η ανάλογη επιλογή να είναι τσεκαρισμένη. Unconstrained Delegation: Trust this computer for delegation to any service. Constrained Delegation: Trust this computer for delegation to specified services (Use Kerberos only) --> Ελέγχουμε εάν έχουμε καταχωρίσει το σωστό service προς το οποίο θα προωθήσουμε τα credentials του τελικού χρήστη. Protocol Transition: Trust this computer for delegation to specified services (Use any authentication protocol) --> Ελέγχουμε εάν έχουμε καταχωρίσει το σωστό service προς το οποίο θα προωθήσουμε τα credentials του τελικού χρήστη. Σε περίπτωση που χρησιμοποιούμε ένα user account ως service account για delegation: Αν βρισκόμαστε σε domain level 2000, πάμε στο account Tab του χρήστη και τσεκάρουμε το account is trusted for delegation Αν βρισκόμαστε σε domain level 2003 τότε πάμε στο Delegation Tab και ανάλογα τι θέλουμε να υλοποιήσουμε, όπως και στην περίπτωση του computer account, πρέπει η ανάλογη επιλογή να είναι τσεκαρισμένη. Unconstrained Delegation: Trust this computer for delegation to any service. Constrained Delegation: Trust this computer for delegation to specified services (Use Kerberos only) --> Ελέγχουμε εάν έχουμε καταχωρίσει το σωστό service προς το οποίο θα προωθήσουμε τα credentials του τελικού χρήστη. Protocol Transition: Trust this computer for delegation to specified services (Use any authentication protocol) --> Ελέγχουμε εάν έχουμε καταχωρίσει το σωστό service προς το οποίο θα προωθήσουμε τα credentials του τελικού χρήστη. 4) Ελέγχουμε εάν το service account έχει ένα από τα παρακάτω δικαιώματα στον web server. Μπορούμε να δώσουμε τα δικαιώματα είτε τοπικά (Local security policies), είτε με Group Policies. Act as part of the operating system Impersonate a client after authentication (IIS Worker Process Group) 5) Στην περίπτωση του Protocol Transition to account πρέπει να έχει και δικαίωμα ανάγνωσης του tokenGroupsGlobalAndUniversal Attribute του Active Directory. 6) Τέλος ελέγχουμε εάν το service account έχει αρκετά δικαιώματα πρόσβασης στα resources της εφαρμογής. Πολλές φορές το application δεν ξεκινά καν για αυτόν ακριβώς τον λόγο. Checklist 3 Backend Στην περίπτωση του Backend τα βήματα είναι απλά. Ουσιαστικά περιορίζονται στα εξής: 1) Στον έλεγχο των SPNs όπως είδαμε στο πρώτο μέρος 2) Τον έλεγχο του αν ο τελικός χρήστης έχει δικαίωμα πρόσβασης στην βάση δεδομένων. Network trace Ξέρεις από Βέσπα; Αν όχι αυτά που ακολουθούν είναι ότι πρέπει για να σε πάρει ο ύπνος. Ας αναλύσουμε ένα επιτυχημένο Network trace για να δούμε τι γίνεται behind the scenes. Το σενάριο είναι ως εξής, δηλώνομαι από έναν client στο Web Site χρησιμοποιώντας Digest και θέλω να κάνω request στον Backend SQL χρησιμοποιώντας Kerberos. Δηλαδή χρησιμοποιώ protocol transition. Στο παρακάτω trace θα doυμε ουσιαστικά την παρακάτω διαδικασία (1). Στα πρώτα πράσινα frames γίνεται το Authentication του χρήστη μέσω Digest, τα frames αυτά δεν παρουσιάζουν κάποιο ιδιαίτερο ενδιαφέρον γι' αυτό δεν θα τα αναλύσουμε. (2) Στο frame 60 βλέπουμε το εξής (XP Client = 192.168.0.12 , IIS Server = 192.168.0.151, KDC = 192.168.0.101) Το service (WebAppPollUsr) το οποίο έχει ήδη γίνει authenticated στο KDC και έχει λάβει ένα TGT, ζητά από το KDC ένα service ticket για τον εαυτό του, εκ μέρους του τελικού χρήστη χρησιμοποιώντας το καινούργιο Kerberos extension S4U2self. Ο τελικός χρήστης αναγνωρίζεται από το user name και το realm εντός του PA-S4U2self. (3) Στο frame 61 το KDC επιστρέφει στο WebAppPool το ticket το οποίο απευθύνεται στο WebAppPool σαν να είχε ζητηθεί με το TGT του Testuser. (XP Client = 192.168.0.12 , IIS Server = 192.168.0.151, KDC = 192.168.0.101) (6) Συνεχίζουμε με το βήμα 6 μια και το request από τον client στην περίπτωσή μας έχει ήδη γίνει. (XP Client = 192.168.0.12 , IIS Server = 192.168.0.151, KDC = 192.168.0.101) Στο frame 66 βλέπουμε ότι το service WebAppPoolUsr ζητά ενα service ticket για το SQL service για λογαριασμό του τελικού χρήστη με Constrained Delegation. (7). Στο frame 69 το KDC ελέγχει το privilege attribute certificate (PAC) τσεκάροντας τα signature data του PAC structure.Εάν είναι έγκυρα τότε το KDC επιστρέφει ένα service ticket για το SQL, αλλά η ταυτότητα του client που βρίσκεται στα πεδία cname και crealm του service ticket είναι αυτά του Testuser και όχι του WebAppPoolUsr. (8). Από εκεί και πέρα το WebAppPoolUsr χρησιμοποιεί το SQL TGS για τον Testuser για να κάνει ένα AP Request στον SQL και να εκτελέσει το stored procedure. Δυστυχώς ο parser του Wireshark δεν μεταφράζει αυτά τα frames έτσι ώστε να είναι ορατό το AP Request. (9). To SQL service επιστρέφει τα αποτελέσματα. Στην δική μου περίπτωση ο χρήστης Testuser απέτυχε να εκτελέσει το stored procedure λόγω μη επαρκών δικαιωμάτων. \.Z:.S.q....C....N..X./.>..ekC.."....=...*.'E..@.....#....?..S........2.e4uS|..?q..)E.*..T.N....1.3...........J.C.a.n.n.o.t. .o.p.e.n. .d.a.t.a.b.a.s.e. .".K.e.r.b.S.4.u.D.B.". .r.e.q.u.e.s.t.e.d. .b.y. .t.h.e. .l.o.g.i.n... .T.h.e. .l.o.g.i.n. .f.a.i.l.e.d....S.Q.L.-.S.R.V.......f..H....%.L.o.g.i.n. .f.a.i.l.e.d. .f.o.r. .u.s.e.r. .'.S.O.F.\.T.e.s.t.U.s.e.r.'....S.Q.L.-.S.R.V................... Αλλά το Protocol Transition me Kerberos Constrained Delegation πέτυχε!!!! Εδώ τελειώνει και η μίνι σειρά για το Kerberos Delegation, ελπίζω να ευχαριστηθήκατε τα posts! To επόμενο post θα είναι για ένα tool-άκι που έγραψα σε c# για να εντοπίζει loops σε group memberships, περισσότερα σύντομα!!!

Γεια σας και πάλι, Sof σπικινγκ (κλεμμένο ) . Ύστερα απο ένα αναπάντεχο disk failure που με ανάγκασε να ξαναφτιάξω το virtual environment είμαι πάλι εδώ για να συνεχίσουμε την εξερεύνηση μας. Το θέμα μας σήμερα είναι: Protocol Transition. Στο πρώτο μέρος είδαμε πώς μπορούμε να μεταφέρουμε τα credentials ενός χρήστη από tier σε tier χρησιμοποιώντας Kerberos Constrained Delegation. Προφανώς προβληματιστήκατε από το γεγονός ότι αφορά μόνο περιβάλλοντα όπου ο web client, web server και SQL server βρίσκονται εντός του Active Directory. Τι γίνεται στην περίπτωση που ο client βρίσκεται εκτός Active directory; Πριν ανοίξετε το Visual Studio για να αρχίσετε να χτίζετε την custom λύση προώθησης των credentials, ρίχτε μια ματιά στα παρακάτω, είμαι σίγουρος ότι θα τα βρείτε χρήσιμα!!! Στα Windows Server 2003 έγιναν από την Microsoft κάποιες επεκτάσεις στο πρωτόκολλο Kerberos. Αυτές οι επεκτάσεις δίνουν την δυνατότητα σε ένα application να αποκτήσει ένα Kerberos ticket εκ μέρους του τελικού χρήστη, έστω και αν αυτός (ο τελικός χρήστης) χρησιμοποίησε κάποιο άλλο πρωτόκολλο κατά την πιστοποίηση στο application. Και όχι μόνο αυτό αλλά και ανεξάρτητα εντελώς με το πιο πρωτόκολλο χρησιμοποιήθηκε. Αν ακούγεται περίπλοκο δείτε το παρκάτω σχήμα. Ο τελικός χρήστης πιστοποιείται με μία από τις παραπάνω μεθόδους στον web server αλλά ο web server με την σειρά του "μιλάει" πάντα Kerberos με τον SQL. Το application αναλαμβάνει την ευθύνη να πιστοποιήσει τον χρήστη και να ζητήσει ένα Kerberos ticket εκ μέρους του χρήστη. Οι δυνατότητες που έχουμε με αυτού του τύπου την υλοποίηση είναι απεριόριστες! Πχ. μπορούμε να εκδώσουμε user certificates που θα είναι αντιστοιχισμένα (mapped) στο Active Directory Account, για να δίνουμε την δυνατότητα σε χρήστες εκτός δικτύου Active Directory να καλούν τα queries του SQL για τα οποία έχουν επαρκή rights μέσω SSL. Ή απλά να υλοποιήσουμε ένα μηχανισμό forms authentication για να αντιστοιχίσουμε τον χρήστη σε ένα Active Directory account. Η να πάρουμε τα NTLM credentials από ένα trusted Active Directory Domain και να τα μετατρέψουμε σε Kerberos! Εντυπωσιαστήκατε; Ας δούμε πως υλοποιείται. Για λόγους συντομίας θα κρατήσω τις ρυθμίσεις από το πρώτο μέρος και θα "χτίσω" πάνω σε αυτές. Οι ρυθμίσεις είναι για ένα application με forms authentication. Προφανώς δεν θα ασχοληθούμε με τις ρυθμίσεις του web client αφού αυτές δεν επηρεάζουν την υλοποίηση μας. Μια ανασκόπηση στις ρυθμίσεις: SQL. 1) Ρυθμίζουμε τον SQL να χρησιμοποιεί Windows Integrated Security. 2) Δίνουμε στον χρήστη (TestUser) τα απαραίτητα rights στην βάση δεδομένων. 3) Βεβαιωνόμαστε ότι έχουμε καταχωρίσει το σωστό Service Principal Name (SPN) στο Active Directory. setspn -a MSSQLSvc/SQL-SRV:1433 SqlServerSvcAccount setspn -a MSSQLSvc/SQL-SRV.sof.local:1433 SqlServerSvcAccount Middle Tier 1) Δημιουργούμε τον λογαριασμό χρήστη κάτω από τον οποίο θα τρέχει το web application (WebAppPoolUsr) 2) Καταχώρηση των SPNs του λογαριασμού WebAppPoolUsr setspn -a HTTP/iis-srv WebAppPoolUsr setspn -a HTTP/iis-srv.sof.local WebAppPoolUsr 3) Trust this user for delegation to specified services only” --> SQL Service (Kerberos Only) 4) Δημιουργούμε Application Pool (DelegationAppPool). Στα Properties à Identity, εισάγουμε τον λογαριασμό που δημιουργήσαμε (WebAppPoolUsr). 5) Δημιουργούμε ένα Virtual Directory. Το ρυθμίζουμε να χρησιμοποιεί το Application Pool που μόλις φτιάξαμε. 6) Στο Directory Security tab à Authentication and access control à Edit, θα διαλέξουμε Integrated Windows authentication. 7) Το τελευταίο βήμα είναι να καταχωρήσουμε το λογαριασμό του WebAppPoolAccount στο Local Group IIS_WPG. Αυτό του δίνει το “Impersonate a client after authentication right.” SQL Οι ρυθμίσεις του SQL παραμένουν οι ίδιες. Middle Tier 1) Θα ξεκινήσουμε με το Web application που θα το τροποποιήσουμε αναλόγως προκειμένου να υποστηρίζει Protocol Transition. Η πιο σημαντική γραμμή κώδικα είναι η εξής WindowsIdentity identity = new WindowsIdentity( <logon name>@<domain> ); Βλέπουμε ότι για να δημιουργήσουμε το Windows Identity που θα χρησιμοποιούμε από εδώ και πέρα δίνουμε απλά το UPN, (το οποίο το έχουμε από την διαδικασία πιστοποίησης), χωρίς να δίνουμε το password, μια και δεν χρειάζεται αφού έχουμε ήδη πιστοποιηθεί από το application. 2) Θα ρυθμίσουμε το Web App να χρησιμοποιεί πλέον Basic Authentication. 3) Θα τροποποιήσουμε τον λογαριασμό του Application Pool (WebAppPoolUser) να προωθεί τα credentials για οποιοδήποτε πρωτόκολλο 4) Θα δώσουμε στον λογαριασμό read access στο tokenGroupsGlobalAndUniversal Attribute του Active Directory. Στο Active Directory Users and Computers, θα κάνουμε κλικ στο Builtin. θα διαλέξουμε το Windows Authorization Access Group, θα ανοίξουμε τα Properties. Θα προσθέσουμε τον λογαριασμό ως μέλος του Group. 5) Tέλος θα δώσουμε στον WebAppPoolUsr το δικαίωμα Ast As Part of the operating system στον IIS server. Αυτές είναι και οι ρυθμίσεις που χρειάζονται. Η εφαρμογή μας είναι πλέον έτοιμη να ζητήσει από το KDC ένα Kerberos Ticket για πρόσβαση στον SQL εκ μέρους του δηλωμένου χρήστη! Τελικά δεν ήταν τόσο περίπλοκο έτσι; Σας προκαλώ να το δοκιμάσετε και μόνοι σας. Το επόμενο μέρος θα είναι αφιερωμένο εξαιρετικά στους troubleshooters, me cool tools και network traces! Φιλικά Sof PS. Η συνεχής αλλαγή γλώσσας με κουράζει αφάνταστα! Θα αρχίσω να γράφω αποκλειστικά Ελληνικά! Tεστ: Ή απλά να υλοποιήσουμε ένα μηχανισμό πιστοποίησης με φόρμες (και όχι με τζιν) για να αντιστοιχίσουμε τον χρήστη σε έναν λογαριασμό του Ενεργού Καταλόγου®. Η να πάρουμε τα πιστοποιητικά ΝΤΛΜ από μία έμπιστη περιοχή Ενεργού Καταλόγου και να τα μετατρέψουμε σε Κέρβεροοο!

Ευχαριστώ για τα καλά λόγια! Ελπίζω και τα επόμενα να σας αρέσουν το ίδιο