Our programmers have managed to find a solution to the problem!
The solution comes in the form of an iSeries PTF (SI38554). Note: This requires an IPL to apply the fix.
We have a tested this PTF on our test/dev machine and we can see the shares on the 2008 R2 server and also read/write to them as well.
Since we can't just IPL the live machine at will, they have come up with an ingenious solution to get us by in the mean time. What they've done is set up a share on the test machine (which has had the PTF and been IPL'ed) which basically passes through to the Server 2008 machine - i.e on the live system, doing a WRKLNK '/QNTC/QDEVSYS/SVR01'
will show the share contents of the 2008 R2 server.
I hope this helps anybody else having this problem - hopefully it will save someone else a lot of time and effort.
I opened a case with Microsoft Premier Support. Here is the email between me and Microsoft support. They basically say that it's a known issue. It's not a bug and it's not a feature.
The back-end will parse the user name and strip out the illegal characters properly
The front-end doesn't do any UI validation because there might be some other third party logon UI. Their requirement on the user name might be different. I think what they are referring to is the 3rd party Credentials Providers.
Oct 05, 2012 morning
I just got on the call with one of their engineers. Explain the whole problem to him once again. He is pretty sure that :something
has no special meaning internally as of today but he cannot guarantee it might mean something in the future.
However, he doesn't have source code to confirm that. He is going to send out an email to somebody else with source code to confirm that.
Oct 03, 2012 night - my reply
Thanks for the info. However, I did try some other illegal
characters, like ; and |.
The Logon UI can successfully detect that and tell me my user name or
passwords are not correct.
If the front end really doesn’t do any input validation and the
back-end can really strip out all illegal characters, why won’t Logon
UI allow me to login as Harvey@company.com|something or
Harvey@company.com;something but Harvey@company.com:something.
This strange behavior happens only on “:”.
-Harvey
Oct 03, 2012 afternoon - MS support reply
Hello Harvey,
There is no Bug in the front end validation as the front end doesn’t
perform any validation. The validation is performed once you enter
your credentials and try to login, then in the background the
validation is performed and the respective error is displayed.
The reason behind not performing a Validation in front is because
there are other third party logon UIOs which are used and there
requirement to work and authenticate a user could be different. Some
UIs might require the username in a diff format, so to perform a
validation when user is entering the credentials will break those UIs.
As for Backend, every UI makes a call to backend Authentication APIs,
irrespective of which UI is present in the front end. So to perform
validation in the backend ensures proper authentication
Regards XXXX
Oct 03, 2012 afternoon - my reply
I understand the explanation on different handling in
front-end and back-end as I am also a programmer.
So, it sounds like a minor bug in the front end UI input validation
logic although there is no bug in the back-end.
Note that I also tried to do the same thing using runas.exe. The
runas.exe showed me the error message before passing the malformed
user name to the back-end. So, to me, runas.exe is doing the correct
input validation.
If you still think that there is no bug in the UI front end, can you
please explain the purpose of allowing end user to type in a malformed
user name and then display it on the screen?
Thanks,
Harvey
Oct 03, 2012 morning - MS Support reply
Hello Harvey,
I apologize for the delay. I had forwarded your question to my SME and
here is his reply: no bug. the UI displays what you typed. The back
end parses the string to determine the domain and username. It does
that properly since : is an illegal character.
Please let me know if it clarifies your questions or if I can assist
you further.
Regards
XXXXX
Best Answer
Found a work-around. ThinPro 5.0 uses freeRDP. In the command registry, you can enter freeRDP command line arguments under the connection itself as follows:
Now, when you open that connection, freeRDP will pass the domain name and username over to Server 2008 R2, but no password. So, you get the login screen with all three options available.
We use a dummy username to trigger the screen, but if one user uses that terminal frequently enough, you can place that user's username in the argument instead. That way all they need is their password.
This works well enough as you can clone the ThinPro settings and update all of the TCs with it. It is a pain to change the username, though, and I hope HP can find a way to make it easier to get that argument inserted.