Filtered articles: "XmlServiceExplorer"

I have recently worked on an implementation for a customer and was concerned with a large number of group memberships. Although the solution for authenticating against the operating system are well documented by Microsoft (here, here and here), the XML service does not allow requests larger than 4KB. So if users have a large number of group memberships, authentication via the XML service can fail due to this limitation. But here's the solution.

You may well ask why I created a tool to send arbitrary requests to the XML service and parse the reply in scripts – which is, by the way, called XmlServiceReader. First of all, I did not like the tool included with the Health Monitoring and Recovery of Presentation Server and XenApp – called RequestTicket.exe – due to its limitation to being executed on the same host as the XML service is located. Furthermore, this tools has a hard-coded request and does not allow customization of the request sent to the XML service.

After writing and publishing the XmlServiceExplorer, I was asked several times just how much information is disclosed by the XML service. There were also comments (to one of my articles and in Brian’s forums) about a possible security breach caused by offering the access lists of all published applications which I described in a tutorial to the XmlServiceExplorer. Although it is possible to suppress the access lists being disclosed by the XML service, the switch is not documented.

In the last part of this tutorial about the XmlServiceExplorer, I introduced requesting useful information from the farm as well as resolving addresses.

Now, I'd like to demonstrate how chatty the XML service is when it comes to applications and their configuration. Some pieces of information are required for Web Interface to operate while others can be regarded as compromising.