When some users try to access PCA, they get a IIS 4.04 error. Adding the server to be a trusted site on the users computer seems to solve the issue. Why do the clients need this setting to allow access to PCA. We do not use SSL. Any help you can provide would be greatly appreciated. Our Security Dept. is curious.
To my knowledge Cisco PCA does not have such a requirement.
The source of the issue can be any of the following and possibly more:
1- IIS setting enforces NTLM over the /jakarta virtual folder.
2- Some policy is handed down from AD that enforce such a requirement on un-secured (non-SSL) web access.
3- IIS lock down tools where used?
4- Client system policy does not allow connect to un-trusted sites/domains.
5- Client third party security application (key logger, monitors, ...) does more of the same.
6- In house network settings on clients.
And so on ...
If you can give some details on the Unity version and the OS mix (server and client) where the issue is popping up for our labs?
OK, it turned out to be just some select Administrators of other systems with wierd settings that this was occuring on. On more question. When PCA validates the login to the Unity server it is sending the credentials in clear text. Isn't this supposed to be encrypted? If not, is there a way to accomplish this other than SSL?
There are 2 links where an intercept can occur.
PC+Browser --- http --- CPCA Server ---- http ---- AvXML.2
The first one should be secured as the credential will be sent from the browser to the server over the network, currently that is done in clear text.
Securing this link can be done either by the provided SSL support or if you have a more complex network with an IPSec properting your traffic (but that's over my head a bit).
The second one is a airpin (localhost) connection from the CPCA server (collocated with the unity server) to the AvXML service via http/soap to the through the IIS server.
That one can be secured by setting up acl for the AvXMl server and setting up SSL for it.
Setting up SSL on the AvXML access is a little tedious as the the CPCA container keystore data need to be updated to recognize the SSL certificate of the server. That is if using the a self-sign certificate or local root CA certificates (not one of the world known ones...).
Other method of securing this link are unknown to me at this time.
Note that on the return path, all credentials are encrypted.