Re: authentication problem
From: Steven L Umbach (sumbach_at_N0spam.ameritech.net)
Date: 03/18/04
- Next message: Petr Kazil: "Re: Decoding NTLM passwords (+ catching worms)"
- Previous message: Marc Reynolds [MSFT]: "Re: Error 52"
- In reply to: Andrew Mitchell: "Re: authentication problem"
- Next in thread: William Wang[MSFT]: "RE: authentication problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 18 Mar 2004 12:38:51 -0600
Thanks for that information. I was reading the Designing Network Security
for Windows 2003 MCSE Microsoft Press book last night and it also says
someting similar in there. I have tried a lot of variations, more just to
see if I could get it to work. Assuming a domain controller is not doing
double or triple duty most traffic [authentication and AD replication] is
already encrypted. It just is that a LOT of people are asking how to protect
their domain resources from non domain computers such as employee/vendor
laptops and I bring up ipsec as a possible solution with the caveat on
domain controllers because many admins right away want to enable the require
policy at the domain level which can bring their network to it's knees. I am
glad to see that 802.1x switches are becoming more affordable as another way
to protect the network. I need to buy one to try it out. --- Steve
"Andrew Mitchell" <amitchel@removecasey.vic.gov.au> wrote in message
news:Xns94B0D42C593FFcasey01@207.46.248.16...
> "Steven L Umbach" <sumbach@N0spam.ameritech.net> said
>
> > Hi Andrew.
> >
> > The KB is ambigous but the second paragraph I think is more definitive
> > of what ipsec traffic will work in a domain and there is no mention of
> > domain computer to domain controller there. I have see other
> > references to this issue as well including the W2003 ipsec guide which
> > does not flat out say it will not work but in so many word says avoid
> > it and there must be a reason for that. I pasted a paragraph from the
> > W2003 Ipsec guide below that I am referencing.
> >
> > ***********************************************************************
> > * a.. Traffic between Active Directory domain controllers and the
> > application server is permitted, because using IPSec to secure
> > communication between domain members and their domain controllers is
> > not a recommended usage due to the complexity of the IPSec policy
> > configuration and management required in Active Directory.
> > ***********************************************************************
> > **
>
> It's stated even stronger at http://tinyurl.com/25jj9
>
> IPSec is based on the authentication of computers on a network;
> therefore, before a computer can send IPSec-protected data, it must be
> authenticated. The Active Directory security domain provides this
> authentication using the Kerberos protocol. Accordingly, when IKE uses
> Kerberos to authenticate, the Kerberos protocol and other dependent
> protocols (DNS, UDP LDAP and ICMP) are used for communication with domain
> controllers. Additionally, Active Directory-based IPSec policy settings
> are typically applied to domain members through Group Policy. As a
> result, if IPSec is required from domain members to the domain
> controllers, authentication traffic will be blocked and IPSec
> communications will fail. In addition, no other authenticated connections
> can be made using other protocols, and no IPSec other policy settings can
> be applied to that domain member through Group Policy. For these reasons,
> using IPSec for communications between domain members and domain
> controllers is not supported.
>
>
> While I haven't tried it (yet), what should be possible is to allow
> unencrypted packets by default, but specify kerberos for traffic on
> specific ports. eg Port 139 for a file server, 1433 for SQL server etc.
>
> I'll give it a go in my lab and let you know.
>
> >
> > The "complexity of the IPSecc policy configuration" tells me that just
> > enabling client/respond on domain members first and then a require on
> > domain controllers after being sure that the policy has propagated to
> > the domain members may not work quite right and that has been my
> > experience.
>
> Correct. The number of ports you would need to make exempt from the rule
> would make it a nightmare.
>
> > I tried a number of different configurations for domain
> > controllers inlcuding just using AH, trying to exempt ldap,dns, and
> > others and could never get it to work right.
>
> Maybe try it the other way around. Allow everything and just protect the
> ports you want to protect. (comparing it to a firewall that sounds weird,
> but it looks like the only way to do it)
>
> Regards
> Andy.
- Next message: Petr Kazil: "Re: Decoding NTLM passwords (+ catching worms)"
- Previous message: Marc Reynolds [MSFT]: "Re: Error 52"
- In reply to: Andrew Mitchell: "Re: authentication problem"
- Next in thread: William Wang[MSFT]: "RE: authentication problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
