Γειά σας και πάλι μετά από καιρό. Έχω μαζέψει τόσα πολλά θέματα που θέλω να μοιραστώ μαζί σας που δεν ήξερα από που να αρχίσω. Διάλεξα λοιπόν να συνεχίσω από εκεί που σας άφησα την τελευταία φορά. Η ιδέα ανήκει στον 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