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 Finish
to 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
Pgina 1 de 13 McAfee Communities: How to Configure Transparent...
07/07/2014 https://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
Regards
Diego
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
How to Configure Transparent Authentication with Active Directory
@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 AND
Command.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 MUOZ
Ejecutivo Preventa
Jon Scholten
887 posts since
Nov 3, 2009
lancekentwell
80 posts since
Nov 10, 2009
juancdiaz
5 posts since
Nov 5, 2009
McAfee Communities powered by Jive SBS 4.5.5.2 community software
Jive Software
SOFTNET S.A
Fijo (4) 411 17 22 Ext. 108
Movil: 3108432819
Cr 80 A No 32 EE 72 Of. 1003
Medellin-Colombia
Visitenos: 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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Aut Tranps

Загружено:

Авторское право:

Доступные форматы

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

Nov 21, 2010 2:14 AM

Вам также может понравиться