Re: authentication problem
From: Andrew Mitchell (amitchel_at_removecasey.vic.gov.au)
Date: 03/18/04
- Previous message: Peter Metdepenningen: "RE: corrupt service password"
- In reply to: Steven L Umbach: "Re: authentication problem"
- Next in thread: Steven L Umbach: "Re: authentication problem"
- Reply: Steven L Umbach: "Re: authentication problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 18 Mar 2004 01:50:56 -0800
"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.
- Previous message: Peter Metdepenningen: "RE: corrupt service password"
- In reply to: Steven L Umbach: "Re: authentication problem"
- Next in thread: Steven L Umbach: "Re: authentication problem"
- Reply: Steven L Umbach: "Re: authentication problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
