In the first part of my tutorial about the XmlServiceExplorer, I have explained how session management is performed by the Web Interface and how the same behaviour can be reproduced by the XmlServiceExplorer. I recommend you also read the initial article: Talking to the XML Service.
Now I’d like to introduce several requests providing useful information about a farm and its servers through the XML service.
Gathering Farm Information
Starting with a single server name and port, there are several interesting pieces of information to be retrieved from the XML service without authenticating. The XML service readily produces the name of the farm it belongs to as well as a list of member servers (see the screen shots below).
By using the server and client type fields, the selection of servers can be narrowed down. But in today’s world only Win32 and Ica30 matter for the server and client type, respectively.
Retrieving Farm Capabilities
Due to the on-going development and the integration of the products, a request was introduces to read the capabilities supported by the farm from the XML service. The following screen shot shows a list of features present in Presentation Server 4.5 FP1, for example:
- separate-credentials-validation: The XML service is able to validate credentials before actually requesting applications.
- multi-image-icons: Web Interface 4.6 allows for icons to be presented in higher resolutions and colour depths. This capability enables an application to request a specific icon format from the XML service.
Using this request on Presentation Server 4.0 and MetaFrame Presentation Server 3.0 may well result in a shorter list of capabilities as some were added in the younger releases.
Resolving Addresses
The XML service provides several ways to retrieve an address for a connection to farm resources. The first screen shot below shows the response received by requesting the address of the farm which is translated to the address any member server. Such an address comes in handy if the interaction with the farm is independent of the individual server, e.g. a member server is dynamically selected to create MFCOM objects via DCOM (CreateObject(MetaFrameCOM.MetaFrameFarm, “myserver”)).
In other situations, obtaining any server does not suffice to complete a given task, instead the address of a specific server is required. By selecting the server radio button in the second screen shot, the string is interpreted as the name of a member server and resolved to its address.
In addition to the described use cases, application names can also be resolved to the address of any server publishing this resource. The third screen shot below demonstrates the use of the application name radio button to have the XmlServiceExplorer interpret the string as an application name.
The format of these presented addresses is specified by the server address type field.
After presenting several methods to resolve a name to an address, I’d like to refer back to the demonstration in the first part of this tutorial in the section how to retrieve information about disconnected sessions. I explained how to request a list of disconnected sessions for a user and client device. The RequestAddress also enables retrieving an address for a disconnected session.
Validate Credentials
The XML service does not perform any kind of session management for requests and does not perceive any logical connection between consecutive requests. Therefore, the application interacting with XML service is required to cache credentials and include them in all user-specific requests like session management.
Before such an application stores the user credentials for subsequent use, it needs to confirm the user’s knowledge of matching username and password. Just like the Web Interface, the application sends a RequestValidateCredentials to the XML service and receives and an empty ResponseValidateCredentials if the credentials are successfully validated.
The following screen shot demonstrates a request to validate credentials with the XML service. This comes in very useful to ensure the correct communication with any configured authentication backend like Active Directory.
References
Talking to the XML Service
Debugging Using XmlServiceExplorer – Part 1
Great job with the xmlserviceexplorer tool. I found it very useful, as I’m actually writing a tool for talking to the XML service as well, although for a different purpose (testing the XML service functionality that we can use as part of our monitoring solution).
I have found a few very interesting things that you might want to peek into as well.
1) apparently one can possibly request the access list for any specific app (or any app if you do not specify the app name) WITHOUT any authentication. I see this as a huge vulnerability in the XML service, namely information disclosure.
2) one can also get ALL details about every single app published also without authentication.
I’ll keep poking around and give you an update if I find anything else that might be interesting.
Alex,
thanks a lot for your comment. Isn’t it funny to be working on the same thing – exploring the depths of the XML service? ;-) Obviously, there are several request to use for a health check in a monitoring solution.
I was already working on (and have just published) part 3 of the tutorial which includes enumerating applications with their access lists. I find the level of detail very distressing as well – considering it is offered without authentication.
Take care,
Nicholas.
What’s also interesting is that one can request a ticket for a particular server with any arbitraty credentials. The credentials have to be present in the request, but then do not have to be corrrect. one will still get a ticket in the reply. I’m yet to test whether one can actually login with that ticket, but seems interesting nontheless that instead of denying the ticket request, we actually get a ticket back.
Drop me a note sometime and I’ll send you my command-line tool (very rudimentary) that can do a number of checks against the XML server. I made it command line so that it’s easy to integrate into any monitoring solution. But the tool is right along the lines of what you’re doing in a windows app, it just makes it more convinient to “consume” the results :-)
Thanks again for the idea though, XmlserviceExplorer has a lot of potential.
Alex,
in my latest article about the XmlServiceExplorer, I present a configuration option in Presentation Server / XenApp to suppress the disclosure of access lists: http://blogs.sepago.de/nicholas/2008/09/29/suppressing-access-lists-to-be-exposed-by-the-xml-service/.
Enjoy,
Nicholas.