I already have a kerberos authentication / WebGateway ruleset working as per this excellent guide.
|Jon Scholten||How To: Setup Kerberos Authentication on Web Gateway 7.x|
I now want to extend the authentictaion to handle browser/device which offer a client certificate (actually Safari on IPads).
I am looking for a bit of advice on what to do.
I understand that I can create a new authentication method under settings which is of type "SSL client Certificate".
What are the next steps ? I see candidate rules sets in the library but not sure which ones are appropriate
any guidance gratefully recieved
I'm glad you liked my Kerberos guide! I hope I can help with x509 stuff too!
This is something that has been brought up here:
To achieve this we need to modify the default "Authentication Server" rules. Details on the "Authentication Server" can be found here:
Effectivley, all that is done with the "authentication server" rules is; you redirect the user to a URL on the MWG; the MWG then authenticates them (using whatever method (NTLM kerberos x509) and then MWG stores a "session" which ties the user's IP to their username for X ammount of time.
In the thread raised by jps (https://community.mcafee.com/message/280186#280186), he setup his iPads with a separate proxy pac file. He was then able to create a separate proxy port for those users, and create separate authentication rules to apply to them.
I would suggest using this method (distiguishing the users based on proxy port) in order to decide if you want to perform certificate authentication or not.
Attached is a ruleset you can use to TEST this out.
It consists of two main ruleset components.
1. "Check for valid authentication session" - This is where MWG looks in its internal session database. If it finds a valid entry for your IP address, then it populates all of your authentication information accordingly. If it does not find a valid session for your IP address, then it will redirect you to the URL configured in the "Authentication Server (port 444)" settings.
2. "Authentication Server" - This is where the MWG actually authenticates you after you have been redirected according to "Authentication Server (port 444)". Read over "https://community.mcafee.com/docs/DOC-4384" for more details on this. This ruleset can be moved out on its own at the top of the ruleset if needed.
Some of the subcomponents are:
1. You need to create an additional proxy port, just for the Authentication Server communication (in the example I used port 444). This is done on each MWG under Configuration > Proxies, then add a new listener and set ports treated as SSL to '*'.
2. Redirect URL - Leave alone to start. This will need to be configured correctly such that the client machine does not complain. The default is set to:
https://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.ip"/>$:444
3. Enrollment page or MWG generated certificates - How will the clients be getting their certificates? If they fail to present a certificate how do you want MWG to handle it? In the rules you can configure a fail over page, where MWG will redirect them to your enrollment web page to get a certificate.
4. Certificate for authentication server - The communication with MWG must be secure. As such you will need a web server certificate configured in the rules this is done under Default Certificate Based Authentication > Authentication Server > SSL Handling > Accept Incoming HTTPS Connections
5. Certificate for verifying certs presented by the clients - In order for x509 auth to work, you need a CA that is signing all of the client certificates. The public certificate can be imported into the MWG, so the MWG can verify the authority on the client cert.
I hope to add this to my authentication guide, but this should help you and others get started.
I was able to set the redirection to the authentication server to use the FQDN of the proxy, with this:
https://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.system.hostname"/>$.internaldomain.int:444
This was necessary because VMware's AirWatch browser can only set the browser's proxy exception list to FQDN's; or at least, it cannot take IP addresses (which is lame).