Hi everyone,
I'm facing a weird behavior with MCP.
I have a set of rules including this one to authenticate users:
Authentication.Authenticate<NTLM> equals false -> Athenticate<Default>
Proxy's working fine if I set up proxy manually on my client's OS. But if this rule is activated, MCP shows no connectivity even if the authentication test passes with no issue.
Any Idea to troubleshoot this?
I'm trying to found anything with a Wireshark on my client but to be honest, I'm not sure about what I should look for.
I hope smoeone can give me a hint on this. 😄
Thanks !
Solved! Go to Solution.
The MCP client has to have connectivity to hxxp://mcp.webwasher.com/test/MCP.txt in order to "pass" connectivity checks (I believe that's the link).
Have you done a rule trace to confirm the client is authenticating at that rule as expected? We have a few rules for MCP on-prem authentication:
Get Customer ID (save Header.Request.Get ("X-SWEB-AuthCustID" in a userdefined field)
Verify Headers: Authentication.IsAuthenticated = fase AND user.defined.customerID = customerid_number and authentication.authenticate<MCP> = true (where <MCP> is our our setting with the customer ID and shared password).
In the latter, we set authentication.username and Authentication.UserGroups to match, just to ensure the name and groups are set.
My suggestion is rule tracing to validate it's hitting that rule. That would be the first step to troubleshooting
The issue is solved.
If you want to know, it's quite simple:
NTLM auth rule was hit even with MCP client. This simply can't work.
If your clients have MCP installed, you have to use MCP or LDAP auth. NTML can't work with MCP the client. 😂
The MCP client has to have connectivity to hxxp://mcp.webwasher.com/test/MCP.txt in order to "pass" connectivity checks (I believe that's the link).
Have you done a rule trace to confirm the client is authenticating at that rule as expected? We have a few rules for MCP on-prem authentication:
Get Customer ID (save Header.Request.Get ("X-SWEB-AuthCustID" in a userdefined field)
Verify Headers: Authentication.IsAuthenticated = fase AND user.defined.customerID = customerid_number and authentication.authenticate<MCP> = true (where <MCP> is our our setting with the customer ID and shared password).
In the latter, we set authentication.username and Authentication.UserGroups to match, just to ensure the name and groups are set.
My suggestion is rule tracing to validate it's hitting that rule. That would be the first step to troubleshooting
Thanks for your reply. I'm not sure to understand everything you said on the second part of your answer but I've got some update.
First, you were right about mcp.webwasher.com.
We had a rule that said URL matches in list with "mcp.webwasher.com" in the list, but we need URL.host instead.
Now connectivity is good but the solution revealed another issue. xD
If I set up the gateway manually as proxy on a client everything is ok. But if I let MCP do the job, I've then have either "ERR_UNEXPECTED_PROXY_AUTH" or "ERR_SSL_PROTOCOL_ERROR" (on Chrome).
I don't understand how the behavior can be different.
It looks like it is the authenticate rule that does not work properly with MCP, because any site I add to the exclusion rule of this ruleset shows up with no error.
The fun of MCP on-prem rules.
In your Authenticate rule with MCP Settings, the password you enter in the MCP Settings, has to match the password configured in the MCP policy in ePO. If they are the same, MCP will authenticate on-prem and "in the cloud" without issues. If they are different, one of those two will fail to authenticate.
YES !
I figured this out here: https://community.mcafee.com/t5/Web-Gateway/How-to-Properly-Authenticate-MCP-Traffic-on-MWG-Without-...
😄
Now I'm trying to found how to make them match. I'm not the one that installed this solution so I'm always searching for everything. I'll keep you in touch and close this tread if it works.
Thank you for your help !
I am familiar with that. If you cannot find the password, and if you can get the xml from the ePO it should have a section "<MCP Credentials><SharedPassword>". You should be able to paste that value into MWG's settings to get the credentials to sync (there are certain MWG version limitations on this). That should, hopefully, sync up your passwords in MCP and MWG.
Good luck!
Hey !
So... I tried reapplying the sharedkey on the GTW, then extracted it as xml to upload it on the ePo.
Same issue...
But I don't see how the issue could be there since the MCP auth happens only if we are in the cloud. My issue with NTLM happens in the LAN !
I've done a Wireshark on a test client and it looks like nothing happens after the 407 request.
Does it look normal to you?
The issue is solved.
If you want to know, it's quite simple:
NTLM auth rule was hit even with MCP client. This simply can't work.
If your clients have MCP installed, you have to use MCP or LDAP auth. NTML can't work with MCP the client. 😂
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA