APM Troubleshooting, Teil 1

Hallo liebe Leser,

wie ich nach meinem letzten Blog (Debugging Kerberos) erfahren habe, scheint das Thema Fehleranalyse doch sehr interessant zu sein. Daher habe ich mir für meinen heutigen Beitrag überlegt, noch ein wenig mehr über das Thema APM-Debugging im Allgemeinen zu schreiben.

Fangen wir bei grundlegenden Dingen an, um ggf. ein wenig mehr Verständnis für den Sessionablauf im APM zu erhalten.

Was passiert, wenn man sich zu einem virtuellen Server mit eingeschalteter APM Policy verbindet?

Vereinfacht dargestellt wird überprüft, ob die Verbindung schon zu einer bestehenden Session gehört. Hierfür wird der dann vorhandene MRHSession-Cookie überprüft. Ist dieser nicht vorhanden, was bei einer neuen Session der Fall ist, wird eine neue, einzigartige User Session-ID erstellt und die neuen Cookies werden gesetzt. Der MRHSession Cookie identifiziert hierbei die vollen 128 Bit der User Session ID, hingegen der LastMRH_Session Cookie den letzten 32 Bit entspricht. Anschließend wir der User zu /my.policy weitergeleitet. Hier kann er sich nun anmelden und wird durch die im VPE (Visual Policy Editor) konfigurierte Policy geleitet und anschließend zur ursprünglich aufgerufenen Ressource weitergeleitet, sofern als Ending kein Deny vorliegt, oder ein Redirect eingestellt ist.

DNS

Viele APM Konfigurationen hängen von korrekten DNS-Einträgen ab. Beispiele hierfür sind SAML, AD, Portal Shortcuts, Kerberos,.... Daher ist es wichtig die relevanten Einträge zu überprüfen. Hierbei helfen einem die beiden Tools „nslookup“ und „dig“ um eine DNS-Lookup und auch einen Reverse- DNS-Lookup durchzuführen. -Reverse DNS-Einträge sind z.B. bei Kerberos Konfigurationen notwendig.

Steht in einem POC kein DNS zur Verfügung kann auch mit HOST Einträgen gearbeitet werden, wobei diese nicht bei Rewrite Profilen (Reverse Proxy und Portal Access) funktionieren!

Zeit

Beim APM sind viele Funktionen von der Zeit abhängig, daher sollte man überprüfen, ob diese auch wirklich korrekt ist, bzw. besser gleich einen NTP-Server eintragen. „ntpqn –pn“ hilft hier beim überprüfen der Synchronisation:

Sollte man keine NTP Server zur Verfügung haben, dann kann man mit den Befehl „date“ die Zeit per Hand setzen. Syntax:

date MMDDhhmmYYYY

Manage Sessions

Mit Hilfe des Menüpunktes „Manage Sessions“ kann man sich ansehen, welche Usersessions im APM existieren und welchen Status diese haben. Ebenso lässt sich hier ablesen, wie weit der User in der Policy fortgeschritten ist.

Ebenso kann man auch User-Session beenden, damit man schnell neue Konfigurationen anwenden kann und nicht noch eine alte verwendet, so lange der User noch mit der alten Policy aktiv ist.

Ein grüner Punkt bei der Session bedeutet, dass die Session erfolgreich eingerichtet wurde. Der User ist authentifiziert.

Ein blaues Quadrat bedeutet, dass eine Session erstellt ist, aber der User noch nicht authentifiziert ist. Somit haben wir hier einen „wartenden“ Zustand.

Session Details

Schauen wir uns hier mal die Infos zu den beiden Session-Zuständen an.

Erfolgreich aufgebaute Session:

Pending Session:

APM Reports

APM bietet die Möglichkeit fertige Reports über Sessions anzuzeigen, oder auch eigene Reports zu verwenden

Übersicht der Sessions:

Ansicht der Session Variablen einer Session (Klick auf „View Session Variables“):

Hier kann man eine Menge ablesen, denn in den einzelnen Variablen sind nicht nur Werte wie „Username“ etc. enthalten, sondern auch z.B. Ergebnisse von End Point Checks, Client Browser Infos usw….

Im Debugging Fall sind die Variablen also oft eine gute Quelle um herauszufinden, was die Ursache des Problems ist.

Natürlich kann man sich diese auch über die Command-Line anzeigen lassen. „sessiondump“ ist hier das Tool der Wahl. Gerne auch mit einem „grep“ oder „less“ durch eine Pipe „|“ kombiniert.

„sessiondump –allkeys“ listet einem hierbei alle Variablen, aller Sessions:

sessiondump kann aber auch Variablen bestimmter Sessions anzeigen, oder auch löschen.

Die Bedeutung einzelner Session Variablen kann man gut im APM Handbuch nachlesen:

Die Variablen fallen dabei unter drei generelle Kategorien:

Variablen, die als Ergebnis von Access Policy Actions verwendet werden:

· Active Directory query Ergebnisse

· Antivirus Check Ergebnisse

· Windows Info und Registry Check Ergebnisse

· ...

User Variablen

· Zugewiesene Client IPs aus Lease Pools einer Client Session

· Username und Passwort

· ...

Network Access Ressource Variablen und deren Attribute

· Split tunnelling, DNS Settings, Compression etc

· …

Wirklich mächtig werden die Variablen mit ihrer Eigenschaft sie verändern oder vergleichen zu können. D.h. mit Hilfe von TCL können Operatoren wie +, eq, ==, <, >,.... angewendetet werden

Genauso auch logische Operatoren wie and, not, or sind ebenfalls möglich. Dies angewendet im VPE liefert ein enorm leistungsstarkes Instrument.

Sessionvariablen kann man auch mit einer Messagebox innerhalb der Policy ausgeben. Das hilft oft beim schnellen Debuggen um zu erkennen, welchen Branch man eingeschlagen hat bzw. welchen Inhalt ein Variable hat.

Nach dem Login, wird der Inhalt der Variablen angezeigt:

Aber zurück zu den Reports, denn man kann im APM auch eigene erstellen:

Einfach auf „Custom Reports“ klicken und anschliessend „Create“. Dann nur noch die gewünschten Informationspunkte für den Report auswählen.

Schon kann man sich Report mit den gesuchten Informationen erstellen.

Ich hoffe hier waren ein paar Hilfen dabei. Nächste Woche geht es weiter, unter anderem auch mit ein paar weiteren Command Line Tools.

Bis dahin, viel Spass beim Erstellen von neuen Access Policies, die hoffentlich nicht zu viel debugging verlangen ;-)

Ihr F5-Blogger, Sven Müller