aut tranps

19022 Views 42 Replies Latest reply: Sep 26, 2011 12:11 PM by lancekentwell

Nov 21, 2010 2:14 AM

How to Configure Transparent Authentication with Active Directory

How to authenticate users whilst connecting transparently to the Web Gateway.

Thanks to the hard work of my colleagues at McAfee Support, we have put together a working rule that will enable transparent authentication with Active Directory.

To achieve this it is a two step process:

1. Configuring Web Gateway.

2. Configuring Internet Explorer.

The first step in configuring transparent authentication you will need to download the rule attached (Authentication Server) and import this into your Rule Sets.

• Go to Policy > Rules Sets > Add > Rule Set from Library > Import from file.. >browse to the location of the rule > select and Open the rule.

When you import the rule there may be conflicts that can be Auto-Solve by selecting Solve by referring to existing objects.

Next, move the rule into place in my case I placed this just below Common Rules which is incorrect but it served its purpose for my testing environment.

Once in place you want to go to the Authentication server request rule-set and edit the Authenticate user againts AD rule to point to your domain controller.

• Go to Policy > Rule Sets > expand Authentication Server > select Authentication server request > select the Authenticate user againts AD rule > and click Edit.

• In the Edit Rule box go to Rule Criteria > select the Authentication.Authenticate criteria and click Edit.

• In the Edit Criteria box go to > Settings (For 'Authentication') and using the dropdown select your configured Domain Controller or add one using the Add button below.

• Once done click OK to close from the Edit Criteria box > click Finishto close the Edit Rule box > Save Changes.

When completing the steps above your newly imported Rule-Set will look as follows:

salanis

44 posts since

Oct 30, 2010

Página 1 de 13McAfee Communities: How to Configure Transparent...

07/07/2014https://community.mcafee.com/thread/29947?decorator=print&displayFullThread=true

Attachments:

IE-AuthServer.doc (84.5 K) Preview

Authentication Server.xml (21.7 K)

If you want to determine how long will the Web Gateway Authentication Server hold users' credentials go to Policy > Settings > expand Authentication > select Auth Server Redirect and edit the Session TTL for the authentication server. By default the Authentication Server will store the credentials for a total of six minutes.

Now that Web Gateway is properly configured next we'll prepare Internet Explorer to trust and pass users' credentials to the Authentication Server.

To maintain brevity I have provided all the necessary steps in the attached Word document 'IE-AuthServer.doc'.

We feel good about this in that it will get all Authenticating Transparently, however we left some basic steps out assuming the following had already been configured:

1. Joining the Web Gateway to the Windows Domain Membership.

2. Configuring the Web Gateway for Transparent Filtering.

Thank you for your time and please contact us if you have any questions or if you see anything missing on any of these steps.

on 11/21/10 2:14:02 AM CST

Tags: web, gateway, authentication, internet, active, directory, transparent, domain, explorer, controller

Like (0)

1. Dec 16, 2010 2:05 PM (in response to salanis)

Re: How to Configure Transparent Authentication with Active Directory

How would you determine the URL for the Authentication Server or does



http://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.ip"/>$:$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.port"/>$

take care of that for you?

Message was edited by: ittech on 12/16/10 3:05:39 PM EST

Report Abuse Like (0)

2. Dec 16, 2010 2:07 PM (in response to ittech)


If you are referring to the URL you need to enter in the trusted sites you will want to add the IP address of your Web Gateway as follows:

http://ip.address.https://ip.address

Please let me know if this answers your question?




Sorry for the confusion, I was reffering to the Authentication Server URL as seen in your second picture.




You can obtain this by downloading the Authentication_Sever rule

on 12/16/10 2:37:51 PM CST




So I don't have to change that particular setting when I implement the rule?


ittech

463 posts since

Jan 25, 2010

salanis

44 posts since

Oct 30, 2010

ittech

463 posts since

Jan 25, 2010

salanis

44 posts since

Oct 30, 2010

ittech

463 posts since

Jan 25, 2010





That is for internal functionality and no need to edit this.


7. Jan 5, 2011 10:54 AM (in response to salanis)


Attachments:

Authentication Server - Corrected.xml (22.1 K)

I discovered a possible issue with the "Authentication Server" ruleset which would prevent authentication from occuring for HTTPS sites. Attached is a corrected ruleset. See screenshot for more details. The reason it does not work is because Authentication server ruleset was loosley based on the Cookie auth ruleset, it contained some undeed criteria.

BEFORE:

AFTER:

Saul, could you replace the exising file with the one attached?

Also, I have asked that development add a default "Authentication Server" ruleset to the library, and asked to vet it.

~Jon


8. Jan 5, 2011 1:40 PM (in response to Jon Scholten)


This totally fixed my HTTPS problem. Thanks!


salanis

44 posts since

Oct 30, 2010

Jon Scholten

887 posts since

Nov 3, 2009

ittech

463 posts since

Jan 25, 2010





Thanks Jon.




Actually I am having a small problem with it now. After the Session TTL for the Authentication Server is up, the HTTPS sites are not getting through. I have to close the browser and reopen it again to reauthenticate.

I did up the TTL to an hour, just pointing out that there is still a flaw with the work around.

Message was edited by: ittech on 1/7/11 2:09:24 PM EST


11. Jan 20, 2011 5:49 PM (in response to ittech)


This could be related to setting of the client ssl context with the CA. So if you have SSL scanning disabled, then this wouldnt work. To remedy this you could add a rule that applies always to "set the client context with CA" as the event. (this rule is found in the default SSL scanning rule at the top)

Let me know if that helps.

~Jon


12. Jan 21, 2011 8:47 AM (in response to Jon Scholten)


Testing it now.

Thanks Jon!


13. Jan 24, 2011 10:49 AM (in response to Jon Scholten)


Seems to be working. Thanks!

salanis

44 posts since

Oct 30, 2010

ittech

463 posts since

Jan 25, 2010

Jon Scholten

887 posts since

Nov 3, 2009

ittech

463 posts since

Jan 25, 2010

ittech




14. Feb 7, 2011 5:15 PM (in response to salanis)


Hi, I've an issue with this configuration. On first sight it works like a charm and I can filter by AD group. The problem begins with Terminal Servers. Those servers have one client id for MWG and therefor it treated all users inside the Terminal Server with the privileges of the first user that authenticates to the server. The thing is that I have many users that must have diferent profiles on one server with a single client id. Do you know how to adapt this rules on this scenario? Thanks in advance

RegardsDiego


15. Feb 9, 2011 1:47 AM (in response to cabai)


Hello,

There are two options to deploy the Authenication server, one is "Client ID" where the Authentication server remembers the IP Address to get the Usernames, the other one would be "Cookie Authentication" which stores a local Cookie on the Client PC. I think for your environment the "Cookie Authentication" should be the right approach and I would expect this to work with Terminal Servers. Can you let us know if you are already using "Cookie Authentication"?

Best,Andre


16. Feb 15, 2011 9:11 PM (in response to ittech)


ittech,

I am having the exact same problem. Right now we are not sending SSL traffic to the gateways at all because we were getting the same affect. Had to close the browser and open it again for https sites to get through.

What did you do? I want to send https traffic to the gateways with the SSL scanner turned off to be able to block and log https sites.

Message was edited by: jont717 on 2/15/11 9:11:36 PM CST


17. Feb 15, 2011 8:28 PM (in response to salanis)


463 posts since

Jan 25, 2010

cabai

2 posts since

Feb 2, 2011

asabban

1,383 posts since

Nov 3, 2009

jont717

291 posts since

Jan 4, 2011



Well, with Cookie Auth enabled and Client ID disabled I can get the Terminal Server working fine and everything is ok, except for the SSL traffic that shows me only an error when I try to browse, but not a McAfee error, a simple IE or Firefox error. Well so I enabled the SSL Scanner rule but with that rule enabled the SSL traffic gives me a McAfee error that it is not authenticated. I checked the Cookie Auth rule and by default exclude the "CONNECT" command.name so it didn't authenticate that traffic. If I remove that filter the SSL traffic won't work again. So I put the CONNECT filter back on the Cookie rule but with that I can't get the SSL traffic authenticated. Any try that I do gives me the browser error page. So, I make a filter and send the CONNECT traffic as Client ID that works fine and the rest as Cookie. That is not the best configuration, but I don't know why I can't make the SSL traffic to authenticate with Cookies. If you can help me would be very appreciate. Thanks


18. Feb 16, 2011 11:50 AM (in response to jont717)


@jont717

A few posts up Jon Sholten suggests taking out "Command.Name does not equal "CONNECT"" of the criteria for one of the Authentication Server Rules, I think. Combine that with the suggestion he made to set up a "set the client context with CA" rule.

That works for us...kinda.

My transparent proxy users haven't really had any problems since doing this except for a fiasco we are going through right now with https://www.aetna.com , it comes up with an incorrect category and I can't seem to fix it.

On the other hand, our users who VPN in and are authenticated by proxy

are still having this issue and I can't seem to work around it




@ittech,

If you wait till your authentication drops, for you I guess after an hour, and open your IE to an HTTPS site by a desktop shortcut or by setting your homepage to an HTTPS site, do you get the warning about certificate mismatch address?

This is the problem we have. It will not authenticate correctly until we click the "Continue (Not recommended) 2 times, then it authenticates and the site opens. Then all HTTPS sites will work fine until authentication is dropped again.




@jont717

That was a problem until we did as Jon suggested:

cabai

2 posts since

Feb 2, 2011

ittech

463 posts since

Jan 25, 2010

jont717

291 posts since

Jan 4, 2011

ittech



This could be related to setting of the client ssl context with the CA. So if you have SSL scanning disabled, then this wouldnt work. To remedy this you could add a rule that applies always to "set the client context with CA" as the event. (this rule is found in the default SSL scanning rule at the top)

Let me know if that helps.

~Jon

Now, I only have problems with mobile users who VPN in.


21. Feb 21, 2011 9:45 AM (in response to ittech)


This is what we have set and still the same problem. See picture

I can replicate this problem every time without fail.

Please share your rule set.




Attachments:

2011-02-21.htm.zip (15.3 K)

Originally I coudn't reproduce this, but giveing my self more than an hour I tried again. I do get the screen, but I only have to click to continue once.

Attached an HTML of my backup.




I figured you would have the same problem cause we have pretty much the same setup.

What troubles me is that Firefox and Chrome work just fine, they don't throw any certificate errors and the user authenticates and the HTTPS pages loads fine. It is only IE that throws this certificate mismatch error when trying to authenticate the user in the background.

If I disable "warn about certificate address mismatch" in IE, then the problem disappears. But I wonder about doing that...

Message was edited by: jont717 on 2/21/11 2:14:51 PM EST


463 posts since

Jan 25, 2010

jont717

291 posts since

Jan 4, 2011

ittech

463 posts since

Jan 25, 2010

jont717

291 posts since

Jan 4, 2011



24. Feb 21, 2011 1:22 PM (in response to jont717)


It just depends on your setup. Disabling that option is something I had to do on my PC because I recently upgraded from IE9 beta to IE9 RC. IE9 RC played havoc on the internet and I got one of those pages on almost every website and I still got it from that HTTPS shortcut on my desktop! The main reason I had to disable it was IE9 RC would warn me about the certificates and not give me an option to continue at all; I only got the option to navigate away from the page. What the heck is that about!?


25. Feb 22, 2011 3:25 AM (in response to ittech)


Hm... I would assume the steps provided by Jon would solve the issue. It is strange to me that you have to accept some certificates but honestly I do not know which is expected.

Can you let me know if we already have an SR for this topic? I would like to check and get this working myself, I think then we can provide a detailed answer here, since multiple installations seem to have some issues with this.

Thanks!Andre


26. Feb 22, 2011 7:57 AM (in response to asabban)


Yes, it is 3-1402060418


27. Apr 25, 2011 8:06 PM (in response to jont717)


Is "Authentication Server Time/IP based" a new ruleset that was introduced in 7.1 to cover this? I'm looking in the release notes and it shows a new enhancement rule set. I'm going to be implementing the transparent auth with AD, so great timing!


28. Apr 26, 2011 10:41 AM (in response to productivityenhancer)


The "Authentication Server Time/IP based" ruleset in 7.1 contains fixes discussed in this post. With jont's help we found some issues with SSL handling as a result, the "fix hostname" rule was added to it.

ittech

463 posts since

Jan 25, 2010

asabban

1,383 posts since

Nov 3, 2009

jont717

291 posts since

Jan 4, 2011

productivityenhancer

64 posts since

Mar 17, 2011



~Jon


29. Apr 26, 2011 11:36 AM (in response to Jon Scholten)


I can confirm that the "fix hostname" rule works great.


30. Jul 19, 2011 9:07 PM (in response to salanis)


Can you exlain the benefit\difference between using this method or simply putting in the Try-Auth rule form the library?

Thanks.


31. Jul 20, 2011 12:00 PM (in response to lancekentwell)


Hi Lance,

There is many differences, but to start, the Try-Auth rule in the library is for proxy authentication, the Authentication server (time based) is for transparent setups (wccp/router/bridge).

I'll post a "try auth for auth server" ruleset later.

~Jon


32. Jul 20, 2011 12:35 PM (in response to Jon Scholten)


Attachments:

tryauthserver.xml (40.1 K)

Here is an example "try auth server" ruleset.

~Jon


Jon Scholten

887 posts since

Nov 3, 2009

jont717

291 posts since

Jan 4, 2011

lancekentwell

80 posts since

Nov 10, 2009

Jon Scholten

887 posts since

Nov 3, 2009

Jon Scholten

887 posts since

Nov 3, 2009





Thanks Could the Transparent option also be used for if your running it as an explicit proxy and have the proxy address configured in the browser or even proxy settings of an application? IF it was do you see any issues or things I woul dneed to look out for with this?

The reason im asking is I have loads of application on my network that need internet access. You can confiured them to use a proxy but they dont support the ability to responsd to a http 407 request like a browser does so if this transparent methid helps to get even some of them authenticated then i'd prefer to use that method provided it doesnt break any of my borwsers authenticating. Out of interest could transparent also allow me to authenticate Safari browser?

Thanks




Jon ive had great success with your XML config. I wondered if it is effected by the issue reported in this article?

https://kc.mcafee.com/corporate/index?page=content&id=KB72524


35. Jul 26, 2011 9:07 AM (in response to lancekentwell)


Hi Lance,

Yes this ruleset would be affected by what is described in KB72524 (basically any authentication server ruleset could be affected), but that issue is planned to be fixed in the next release 7.1.5.1.

In addition, in the rule "Redirect clients that do not have a valid Session to the Authentication Server" I think I have the criteria mixed up.

It needs to be reversed to be:Authentication.Authenticate<auth server> equals false ANDCommand.Name does not equal CONNECT

I will correct the ruleset later today.

~jon




Hi Jon

Thanks for the feedback, i didnt actually create the auth ruleset in the first place i just improted and used the one you attached earlier. Look forward to see your new one. Im still trying hard to learn V7 its loads better than 6 but more complicated so im having a hard time fully understanding parts of it. It

lancekentwell

80 posts since

Nov 10, 2009

lancekentwell

80 posts since

Nov 10, 2009

Jon Scholten

887 posts since

Nov 3, 2009

lancekentwell

80 posts since

Nov 10, 2009



would be great if you could maybe give me a few sentences on what each part does so i can better understand it.

Thanks.


37. Jul 26, 2011 6:00 PM (in response to lancekentwell)


Attachments:2011-07-26_17-55_Try-Authentication-Server.xml (38.6 K)

Hi Lance,

Here is the fixed "Try Authentication server" ruleset (just one change to the "Redirect clients that do not have a valid Session to the Authentication Server" rule).

As far as an explanation of what each rule does, I eventually want to write a guide on it, but have a few things I need cleared up before doing so.

Essentially though, the rule names are representative of what the rule accomplishes.

~Jon




Hi Jon,

Im wondering if you could check your XML file named 2011-07-26_17-55_Try-Authentication-Server.xml

I imported it and it all works great except for HTTPS. I was in Hotmail and noticed that im not gettin gauthenticated, the logs dont show my username but as soon as I come out of the HTTPS portion of the site it shows my username in the logs.

Thanks.


39. Aug 19, 2011 4:15 PM (in response to salanis)


Hi Jon / Lance.

In Check for Valid Authentication Session criteria is command name does not equal "CERTVERIFY" and within Check for Valid Authentication Session - Fix Hostname criteria is command name equals "CERTVERIFY", never go to rule?.

Thank you if you correct me.

JUAN CARLOS DIAZ MUÑOZEjecutivo Preventa

Jon Scholten887 posts since

Nov 3, 2009

lancekentwell80 posts since

Nov 10, 2009

juancdiaz5 posts since

Nov 5, 2009



McAfee Communities powered by Jive SBS ® 4.5.5.2 community software © Jive Software

SOFTNET S.AFijo (4) 411 17 22 Ext. 108Movil: 3108432819Cr 80 A No 32 EE 72 Of. 1003Medellin-ColombiaVisitenos: www.softnet.com.co


40. Sep 23, 2011 9:18 AM (in response to Jon Scholten)


Jon,

Can you help me. I have been using your config in testing for some time now and it works great but i think im going to have an issue with Citrix and Terminal Server based connections since they all come from the same IP. Can you direct me how to modify this to be cookie based instead of IP, this should fix my problem.

Thanks.


41. Sep 23, 2011 5:45 PM (in response to lancekentwell)


Hi Lance,

Such a ruleset already exists, look for the "cookie auth" ruleset in the ruleset library. Policy > Add > Ruleset from Library.

~Jon


42. Sep 26, 2011 12:11 PM (in response to Jon Scholten)


Sorry Jon I should have given more info. I did indeed see that and tried it but just cant get the damn thing to work. It just doesnt try to authenticate me. I even checked the authentication server it uses is the same NTLM one that your original sample XML file uses (which works just fine). THats why I was hoping maybe it only take a couple of tweaks of your original config.

Any help would be great.


Go to original post

lancekentwell

80 posts since

Nov 10, 2009

Jon Scholten

887 posts since

Nov 3, 2009

lancekentwell

80 posts since

Nov 10, 2009



aut tranps

Documents