XML Broker Monitor - without plain text password

Before this Topic group existed, I had posted some info regarding what I ran into with regards to deploying Citrix.

 

 

Link:

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/44/aft/1177084/showtab/groupforums/Default.aspx

 

 

Orginal Post text:

 

Sorry if this is long and somewhat rambling, but I wanted to share what we discovered and how we got a working solution in place.

 

 

This week we just got our new Xenapp environment configured and I fired up the new XenApp template on my shiny new 3600's running 10.2.1. With just a few pieces of info, the template did a LOT of work for me. Everything looked to be working just fine, however when I sat my Citrix engineers down to show them how the F5 solution was working, we found that the XML Broker monitor created by the template was sending the domain user account password in clear text. Needless to say we all stared at the screen in disbelief and horror.

 

 

We thought that maybe this is how the XenApp Web interface makes a request on the behalf of a user, which was also frightening because if true, then the web interface would also be sending every password possibly in the clear. We fired up a TCPDUMP session on the LTM, filtering for traffic to the XML Broker VS to see the Post data being sent to the XML Broker. We then captured the traffic when the service account logged in to the Web interface. We found that the Web Interface sent a substantially different request to the XML Broker, and that request did not include a cleartext password. Big sighs of relief that passwords like mine (kind of like a janitor key ring) were not being tossed across the network in cleartext.

 

 

The post data used in the requests has a section/node called Credentials. The template produced health monitor contained different subnodes than the one which web interface sent. The template monitor contained three subnodes, UserName, Password, and Domain, yet the Web interface only provided a single subnode called ID. The ID subnode had two types, SAM and SID. The subnode data with the type of SAM was the Domain\Username and the SID was exactly that, the Security IDentity stored within AD. A SID is long globally unique identifier, aka a GUID that looks something like this - S-1-5-21-502533599-1125222469-1539856572-8330680. What surprised us was the number of SIDs that the Web Interface sent in the request(over 15), especially seeing as this domain account was supposed to be a non-privileged account with no special rights. There was so much data in the body of the post that the request had to span two packets.

 

 

So at this point we knew of two ways to get the expected response, mimic the data sent in the Web Interface request, and the template monitor. The encoding keyword used with the template monitor provided some promise, but I could not find any documentation on the options and algorithms to encrypt this data. Granted I did not look too hard, so If someone else has a line on this data please share it. Mimicking the Web Interface request exactly was not an option as it was too large, so I needed to discover what the SIDs were and whether they had any relevance to getting the apps enumerated. I found a tool to resolve SIDs to human readable names and started working the list. The first SID was for the actual user account, and the remaining ones I looked at were all various groups that the account was a member of. I removed most of the SIDs for groups which I suspected were not relevant and used Fiddler's request builder to see if the modified POST could get the answer that we needed. All the testing revealed that the first SID in the Web Interface request is the only credential data I needed.

 

 

Now I had to create a new monitor based on the revised data in the credentials section of the request. I copied everything from the template monitor into a new one, and replaced the credentials section. See the attached file for the full post body details. The forum ate my XML formatting....

 

 

I adjusted the content-length value to what I saw in Fiddler's request builder, but the new monitor kept failing. If your content-length is not precise, the receiving system will respond with a 400 Bad request. I fought this for some time and finally set the working and non working XML data portions into Notepad++ to see what I was missing. Step one, remove all of the escape characters in front of the double quotes, then count the characters for both and compare. What I found was that the length of characters for the working example were less than the number in the content-length by three. Once I added three to the total number of characters, the new monitor turned green.

 

 

Hopefully this is helpful. If anyone can dig into the encoding options, that could be an easier to implement option.

 

 

Tools Used for all of this:

 

Putty

 

TCPDUMP

 

Fiddler Tool - HTTP Debugger

 

Notepad++