Γεια σας! Είμαι ο 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, περισσότερα σύντομα!!!