authentication problem
kjelle
Mixed environment with Windows 2000 and 2003 servers and
clients.
IPSEC policys is distributed to clients and servers on
the network through group policys to protect
the "IPSEC_Users" OU´s communication on all IPtraffic.
Secured users and clients using ipsec is placed in a OU
called "IPSEC_users".
Domain controllers are placed in default OU "Domain
Controllers".
Secured servers are placed in a OU called "IPSEC_servers".
Using the default ipsec policy filters in Windows the
computers in "IPSEC_users" OU is assigned the "Request
security" filter with certificate authentication on all
IPtraffic.
The "Domain Controller" OU is assigned "Respond only"
filter with certificate authentication on all IPtraffic.
The "IPSEC_servers" OU is assigned "Require security"
filter with certificate authentication on all IPtraffic.
Problem:
The problem arrise when the clients and domain
controllers are using these settings. The ipsec
kommunication works after a cashed login but the big
thing is that the client cannot locate the domain
controller in the domain for authentication at logon
witch result in group policy not beeing assigned. The
error message in event viewer is:
Event id 1054: Can´t read the domain controller name on
the network. The specified domain is not available or
could not be contacted.............
AND
Event id 5719: This computer could not establish a secure
session with a domain controller in this domain LABB
because of following error:
There are no logon servers available to handle the login
request.........
I doesn´t matter what kind of authentication method is
used, kerberos, pre-shared key or certificate
authentication.
I have been running a packet capture program on the
domain controller and analyzed what kind of traffic is
sent when the client is trying to login. I can clearly
see that the client is trying to do a DNS loockup of the
SRV record for the domain controller although there is no
reply sent from the server.
Although I manually add a filter action to send DNS
traffic in clear text between client and server, the
server doesn´t reply. I think this is the reason to why
the client can´t login correctly and maintain the policy
settings.
The question is why this occur?
Best regards
Kjelle
Steven L Umbach
regards to ipsec negotiation between domain members and domain controllers.
I could never get it to work without a problem. Microsoft officially does
not support ipsec negotiation communications between domain members and
domain controllers for either W2K or Windows 2003. The only way I get it to
work is to exempt all traffic between domain controllers and doman members
which is not explained in very much documentation. See the links blow for
more info. --- Steve
http://support.microsoft.com/?kbid=254949
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/DNSBJ_IPS_OVERVIEW.asp
http://tinyurl.com/2v8na --- same as above, shorter in case of wrap
"kjelle" <kjell....@kemi.se> wrote in message
news:b30d01c40b6d$973b4040$a601...@phx.gbl...
William Wang[MSFT]
Thanks for your posting. If I understand correctly,
the problem is that you can only log on to the client
computer using cached credentials after assigning the
IPSec policies when the DC is available, you failed
to log on to the domain and the policies are not
assigned.
Before we go further would you please post the exact
steps to reproduce this issue as I cannot reproduce
the exact result on my side? Please also include the
following information:
1. Is it a Win2K domain or a Win2k3 domain?
2. What's the OS of the server you are logging on?
3. Please also send the NT event logs (save them as
sys.evt and app.evt) to me at v-rx...@microsoft.com.
I'm looking forward to hearing from you.
Sincerely,
William Wang
Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
=====================================================
This posting is provided "AS IS" with no warranties,
and confers no rights.
--------------------
>From: "Steven L Umbach"
<sum...@N0spam.ameritech.net>
>References: <b30d01c40b6d$973b4040$a601...@phx.gbl>
>Subject: Re: authentication problem
>Date: Tue, 16 Mar 2004 12:11:23 -0600
>Lines: 80
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express
6.00.2800.1158
>X-MimeOLE: Produced By Microsoft MimeOLE
V6.00.2800.1165
>Message-ID: <#UR2xG4C...@TK2MSFTNGP09.phx.gbl>
>Newsgroups: microsoft.public.win2000.security
>NNTP-Posting-Host:
adsl-68-78-77-197.dsl.emhril.ameritech.net
68.78.77.197
>Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09
.phx.gbl
>Xref: cpmsftngxa06.phx.gbl
microsoft.public.win2000.security:23779
>X-Tomcat-NG: microsoft.public.win2000.security
Andrew Mitchell
> I have tried a number of various policy configurations in the past
> with regards to ipsec negotiation between domain members and domain
> controllers. I could never get it to work without a problem. Microsoft
> officially does not support ipsec negotiation communications between
> domain members and domain controllers for either W2K or Windows 2003.
> The only way I get it to work is to exempt all traffic between domain
> controllers and doman members which is not explained in very much
> documentation. See the links blow for more info. --- Steve
>
> http://support.microsoft.com/?kbid=254949
Steven,
I think you may have misread the content of the above article.
It is referring to traffic between domain controllers and *non* domain
members, not between DC's and members of the domain. If the client is not a
member of the domain it cannot retreive the IPSec policy from the DC, the
same way it will not get any other group policies. Domain members have no
such problem.
What problems have you been experiencing?
Regards
Andy.
Steven L Umbach
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.
*************************************************************************
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. 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. If I enable a reqest or require policy on a domain controller
after the clients already have a respond policy and the client is already
logged on, then I can see with ipsecmon that traffic is being negotiated and
secured but as soon as I reboot that domain computer I am unable to logon as
the computer hangs after entering user credentials [cached logons disabled].
So I abandoned by attempts to secure traffic between domain members and
domain controllers. I never have a problem using ipsec between any domain
members. If you have a policy that works to secure traffic betwen domain
computers and domain controllers via ipsec with kerberos then let me know
what has worked for you or otherwise tell me where I am going wrong. ---
Steve
"Andrew Mitchell" <amit...@removecasey.vic.gov.au> wrote in message
news:Xns94AFE9DD...@207.46.248.16...
Steven L Umbach
I my domain computers already have the client/repond policy assigned to them
via Domain Security Policy and that has been confirmed running netdiag on
them and I then enable the server/require ipsec policy in the Domain
Controller Security Policy I can not logon to the domain after I reboot a
domain computer. I can enter the credentials for the users for the domain,
but the logon just hangs. Are you saying that if the domain members have a
client/repond policy and the domain controllers have a server require policy
as is without any modifications it should work?? Thanks. --- Steve
"William Wang[MSFT]" <v-rx...@online.microsoft.com> wrote in message
news:Bj5J0WB...@cpmsftngxa06.phx.gbl...
Andrew Mitchell
> 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.
Steven L Umbach
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" <amit...@removecasey.vic.gov.au> wrote in message
news:Xns94B0D42C...@207.46.248.16...
> "Steven L Umbach" <sum...@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
William Wang[MSFT]
It is just a quick note to let you know that I am still working on this
issue for you. Due to the complexity of the issue, please be patient with
me and I will get back to you as soon as possible. I appreciate your
understanding and patience.
Sincerely,
William Wang
Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>Content-Class: urn:content-classes:message
>From: "kjelle" <kjell....@kemi.se>
>Sender: "kjelle" <kjell....@kemi.se>
>Subject: authentication problem
>Date: Tue, 16 Mar 2004 07:44:38 -0800
>Lines: 63
>Message-ID: <b30d01c40b6d$973b4040$a601...@phx.gbl>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>X-Newsreader: Microsoft CDO for Windows 2000
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
>Thread-Index: AcQLbZc7ymor10iJQKm3mo3pU7Xwgw==
>Newsgroups: microsoft.public.win2000.security
>Path: cpmsftngxa06.phx.gbl
>Xref: cpmsftngxa06.phx.gbl microsoft.public.win2000.security:23767
>NNTP-Posting-Host: tk2msftngxa14.phx.gbl 10.40.1.166
>X-Tomcat-NG: microsoft.public.win2000.security
William Wang[MSFT]
I'm sorry for the delayed response. I can reproduce this problem. Now we
can confirm that using IPSec for communications between domain members and
domain controllers is not supported. As Andrew has already mentioned
earlier, I'd also like to included details here for your reference:
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¨Cbased 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.
For more information, you can refer to
<http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deplo
yguide/en-us/dnsbj_ips_teur.asp>
If you have any further questions please let me know.
Sincerely,
William Wang
Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>X-Tomcat-ID: 358503499
>References: <b30d01c40b6d$973b4040$a601...@phx.gbl>
>MIME-Version: 1.0
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>From: v-rx...@online.microsoft.com (William Wang[MSFT])
>Organization: Microsoft
>Date: Tue, 23 Mar 2004 14:05:54 GMT
>Subject: RE: authentication problem
>X-Tomcat-NG: microsoft.public.win2000.security
>Message-ID: <HTfQ5$NEEHA...@cpmsftngxa06.phx.gbl>
>Newsgroups: microsoft.public.win2000.security
>Lines: 99
>Path: cpmsftngxa06.phx.gbl
>Xref: cpmsftngxa06.phx.gbl microsoft.public.win2000.security:24115
>NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182
Steven L Umbach
that I posted in my original reply that confuses so may people?? It states
non domain computers in the first paragraph which should be obvious anyhow
since non domain computers can not use kerberos. --- Steve
http://support.microsoft.com/?kbid=254949
"William Wang[MSFT]" <v-rx...@online.microsoft.com> wrote in message
news:92b9%23$lEEHA...@cpmsftngxa06.phx.gbl...
William Wang[MSFT]
I've forwarded your feedback to the appropriate channel. In the future,
anyone encountering this same issue will be able to benefit from your
valuable feedback.
Sincerely,
William Wang
Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>From: "Steven L Umbach" <n9...@no-spam.ameritech.net>
>References: <b30d01c40b6d$973b4040$a601...@phx.gbl>
<HTfQ5$NEEHA...@cpmsftngxa06.phx.gbl>
<92b9#$lEEHA...@cpmsftngxa06.phx.gbl>
>Subject: Re: authentication problem
>Date: Thu, 25 Mar 2004 09:03:37 -0600
>Lines: 183
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
>Message-ID: <O4GEcpnE...@tk2msftngp13.phx.gbl>
>Newsgroups: microsoft.public.win2000.security
>NNTP-Posting-Host: adsl-68-78-71-208.dsl.emhril.ameritech.net 68.78.71.208
>Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
>Xref: cpmsftngxa06.phx.gbl microsoft.public.win2000.security:24266
>X-Tomcat-NG: microsoft.public.win2000.security
Steven L Umbach
ipsec.
--- Steve MVP Windows Security
"William Wang[MSFT]" <v-rx...@online.microsoft.com> wrote in message
news:zf6ZGUz...@cpmsftngxa06.phx.gbl...