By Wayne Brill
In a recent case, code that was downloading a file from an ADMS was getting an 8000 error (TicketInvalid) when that same code was accessing an AVFS and called from another exe. (The code was simulating running from a custom job).
Solution. (from a colleague in Vault Engineering)
The short answer:
It is not supported to sign in to one AVFS service with a ticket obtained from signing in to a different AVFS service.
For that case, the following strikeout code was wrong and needed to be replaced with the following highlighted code to fix the issue:
arguments += "/url \"" + loginCred.ServerIdentities.DataServer + "\" ";
arguments += "/url \"" + loginCred.ServerIdentities.FileServer + "\" ";
Here are the details:
The DataServer and FileServer is a string representing the location where the ADMS services and AVFS services live respectively. In the case of an ADMS server, the DataServer and FileServer are the same value because ADMS always have both ADMS services and AVFS services. For an AVFS server, however, the FileServer and DataServer will be different. An AVFS server always knows which ADMS server it belongs to.
So, in that setup, there were services ADMS1 and AVFS1 on Server1 and you have AVFS2 (which talks to ADMS1) on Server2.
The first process, Process1, logs in to AVFS2. So, its FileServer will be Server2 and its DataServer will be Server1. From the login it gets a Security header which has a Ticket, T1, which is associated with AVFS2 (that is the important part—that tickets are specific to the AVFS which you logged into).
Then the second process is started - Process2, giving it (among other things) T1 and the DataServer (i.e. Server1). This information is used in the constructor of UserIdTicketCredentials. The constructor expects the url you are giving it is the address of AVFS you want to login to. So this logs you into AVFS1 on Server1 (and I assume this was not intended).
This works (for a bit) because the ticket is valid—even though the ticket is not associated with AVFS1.
Upload/Download tickets are specific to an AVFS (i.e. an upload/download ticket for own AVFS will not work with another AVFS). When you ask the ADMS service for a upload/download ticket it uses the Security Header ticket to know what AVFS the ticket should be associated with. In this situation, based on the SecurityHeader ticket, it thinks you want a download ticket associated with AVFS2.
When you get that ticket back and use it, it is being used with AVFS1, and AVFS1 rejects the ticket because it is not a ticket it expects (it is not a ticket associated with AVFS1). Hence the 8000 error message is correct.
It would be nicer (IMO for troubleshooting purposes) if we just rejected the login from the get-go, but we don’t.
This blog post discusses file transfer:
http://justonesandzeros.typepad.com/blog/2013/07/file-transfer-doing-it-the-hard-way.html