Hi, Will.
The only purpose "Fake TR" serves is to manage list of attributes you want to be available in CAS flows. It doesn't affect which attribute is released to what CAS client, only defines a full list that will be available to CAS server.
Protocol details are provided [here](https://apereo.github.io/cas/5.0.x/protocol/CAS-Protocol-V2-Specification.html). Specifically, flow starts with request to `/login` endpoint like this `https://server/cas/login?service=http%3A%2F%2Fwww.service.com`. If you get "service is not known" type of error, something is most likely wrong with the way you defined your service in `cas-protocol.xml.vm` template file.
>As per the documentation, calling https://your.gluu.host/idp/profile/cas/serviceValidate does not seem to be returning with a ticket validation response, we're just seeing 'E_TICKET_NOT_SPECIFIED'.
You need to supply ticket, of course. And judging by what you said, you can't get the ticket as your service is not known to CAS server.
What CAS client do you use? Please also provide your edited `cas-protocol.xml.vm` and `attribute-filter.xml.vm` files, plus `/opt/shibboleth-idp/conf/attribute-resolver.xml` file. Then also create a HAR file with capture of the full failing flow; [here are the steps](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that, Chrome's HARs are flawed; also don't forget to set "Persist log" checkbox in the console to save everything, not just the recently loaded page.
I'm also not sure why you need to issue `transientId` in CAS flow, that hasn't been yet tested so I can't say whether it's possible.