Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X
Looking for a switch or option on this or I will file ticket with PTC. When Creo View launches and presents the user a login prompt, if the authentication fails, nothing happens. The user is not asked to try again or given any indication that authentication was unsuccessful. Not sure it matters but we are using WC 12, Creo View 9.1 and AD to handle authentication from the web server.
The normal behavior is for prompt to go away and then Creo View launches. There is a pause where nothing is showing. I can tell from experience that if Creo View does not launch, I assume I fat fingered my password and try to launch it again. If I get a login prompt again, that confirms what I suspected. Is this a known issue or is there a setting to have user try again?
Solved! Go to Solution.
I found this case today when searching so I am closing this thread. Looks like PTC is has addressed it:
https://www.ptc.com/en/support/article/CS395733?source=search
Looks like we need to move to Creo View 10.1.
tried on CV8.0 and WC12.1 , the Authentication is prompted again .
I would suggest to open a TS Case , and provide fiddler logs to investigate the communication between the CV client and Windchill .
Interesting. Any special settings. The only thing I changed in this area is increasing the timeout from 300 seconds to 7200 seconds. Thanks, I will try TS route since its certainly different than yours. pvagent.exe did not remain running if I gave bad creds.
Hi @avillanueva
I would suspect a communication wit the AD can case the issue.
This is my first thought
PetrH
@HelesicPetr ,I agree with you ,it's also worth to investigate the fiddler logs .
Got the exact same problem with windchill 12.0 and creoview 9.0, very common because users are required to change their AD password regularly, creoview remembers the old password and does nothing when authentication fails.
@rhart, @RandyJones , glad I am not alone. Aside from versions, what else is common about us? We are using an Apache webserver with authentication configured back to AD. I also employ an Apache reverse proxy for HTTPS ahead of that.
I am not sure that this is related to password changes or caching. I see this all the time when I fat finger my own password which was not changing. I can understand if you had run Creo View earlier, agent remains in memory then you do a password change that day. I would not expect it to work until it was closed out and and new agent started.
My expectation would be that it would just prompt again for creds. Aside from watching packets, how else could we diagnose this issue?
I think I found a BIG clue. Who knew I was still had debug logging for my Creo View session running:
Info 9:3:55.468 16 June 2023 20168 11112 internet DownloadTask Status code from download: 401
Info 9:3:55.468 16 June 2023 20168 12592 pvsa CvAgent AUTHENTICATE_SERVER_MESSAGE
Info 9:4:14.394 16 June 2023 20168 12592 pvsa CvBasicAuthentication Credentials were sent successfully to server following Authenticate() callback
Info 9:4:14.413 16 June 2023 20168 12592 pvsa CvBasicAuthentication Operation aborted.
Info 9:4:14.413 16 June 2023 20168 12592 pvsa CvBasicAuthentication GetBindResult() = 0000000000000000
Info 9:4:14.413 16 June 2023 20168 12592 pvsa CvBasicAuthentication SessionAuthenticationComplete. status = 3
Error 9:4:14.414 16 June 2023 20168 12592 pvsa CvBasicAuthentication Error while creating HTTP Stream for server authentication - BindToStorage() failed
Info 9:4:14.414 16 June 2023 20168 12592 pvsa StartupDialog OnSessionAuthenticatedFailed
Info 9:4:14.415 16 June 2023 20168 12592 pvsa StartupDialog OnDestoy()
Info 9:4:16.342 16 June 2023 20168 12592 dom Exchange Shutdown()
Info 9:4:16.342 16 June 2023 20168 1120 dom Exchange Got Clean Exchange shutdown.
Info 9:4:16.342 16 June 2023 20168 1120 dom WindowsListener StopThread().
Info 9:4:16.343 16 June 2023 20168 1240 dom WindowsListener Run() - got shutdown.
Info 9:4:16.344 16 June 2023 20168 1120 dom Connector StopThread().
This is the log for my failed session. I searched for "Error while creating yada yada" and came across this ticket:
https://www.ptc.com/en/support/article/CS387326?source=search
Sure enough, describes that I am using a reverse proxy. The article says resolution is a redirect for code 301 (https://en.wikipedia.org/wiki/HTTP_301) which is not present in my 30-app-Windchill.conf file. I do have redirects on my proxy like such:
RedirectMatch ^/$ https://<go pound sand>/Windchill/
RedirectMatch ^/windchill$ https://<not a chance>/Windchill/
Why would their solution be any different?
We were getting an INET_DOWNLOAD_FAILURE Error in our logs and found that unchecking this box resolved the authentication issue.
Same issue here with Windchill 12.1.2.2 and Creo View 10.0.0.0.
In my case, AD is configured in Apache for authentication along with Open DJ as secondary for non-AD accounts. Windchill uses Open DJ only as its LDAP.
We are using OpenLDAP and WindchillDS for both Apache and Windchill. We have slightly different OpenLDAP filters for Apache vs Windchill - eg lookup certain attributes to determine if user can actually login (Apache) vs if the system can "see" the user (Windchill).
I found this case today when searching so I am closing this thread. Looks like PTC is has addressed it:
https://www.ptc.com/en/support/article/CS395733?source=search
Looks like we need to move to Creo View 10.1.