Re: authentication problem

From: Steven L Umbach (n9rou_at_no-spam.ameritech.net)
Date: 03/25/04 

Date: Thu, 25 Mar 2004 09:03:37 -0600

Now that has been resolved could you please have someone revise KB254949
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-rxwang@online.microsoft.com> wrote in message
news:92b9%23$lEEHA.3968@cpmsftngxa06.phx.gbl...
> Hi Kjelle,
>
> 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$a601280a@phx.gbl>
> >MIME-Version: 1.0
> >Content-Type: text/plain
> >Content-Transfer-Encoding: 7bit
> >From: v-rxwang@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.3568@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
> >
> >Hi Kjelle,
> >
> >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.ritter@kemi.se>
> >>Sender: "kjelle" <kjell.ritter@kemi.se>
> >>Subject: authentication problem
> >>Date: Tue, 16 Mar 2004 07:44:38 -0800
> >>Lines: 63
> >>Message-ID: <b30d01c40b6d$973b4040$a601280a@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
> >>
> >>Cenario:
> >>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
> >>
> >
> >
>

Relevant Pages

  • Re: authentication problem
    ... >> can confirm that using IPSec for communications between domain members ... >> members to the domain controllers, authentication traffic will be blocked ... >> settings can be applied to that domain member through Group Policy. ...
    (microsoft.public.win2000.security)
  • Re: authentication problem
    ... > of what ipsec traffic will work in a domain and there is no mention of ... > communication between domain members and their domain controllers is ... IPSec is based on the authentication of computers on a network; ... are typically applied to domain members through Group Policy. ...
    (microsoft.public.win2000.security)
  • Re: MSFT Bans insecure hashes - was"Passwords with Lan Manager (LM) under Windows"
    ... After I pointed out that "IPsec based auth" is not a basic netlogon ... authentication protocol like Kerberos, LM, NTLM and NTLMv2, you said I was ... based auth" to authenticate the request as opposed to LM, NTLM, or NTLMv2. ... Up to 75% of cyber attacks are launched on shopping carts, forms, ...
    (Pen-Test)
  • RE: Passwords with Lan Manager (LM) under Windows
    ... A device's security associations are contained in its Security Association Database ... Internet Protocol Security (IPSec) provides application-transparent encryption services for IP network traffic as well as other network access protections for the Windows 2000 operating system. ... As for "article you reference does indeed use the phrase "IPSec Authentication," but as any who reads it ...
    (Pen-Test)
  • Re: Kerberos machine authentication - apparent authentication fail
    ... as the case may be) which will delay authentication until ... I also have an Intel network adapter and WAP that does not have this> problem and even works well with 802.1X EAP-TLS for domain logon. ... In> most cases [ipsec a possible exception] kerberos authentication is not> needed to access domain resources as long as the client and server use a> common authentication method for lm/ntlm/ntlmv2. ... The main issue is to> NEVER include an ISP dns server in the preferred server list in the tcp/ip> properties or DHCP scope of any domain computer or any computer you want to> join to the domain in which case your computers may be trying to locate the> domain _srv records on the ISP dns server and fail. ...
    (microsoft.public.windows.server.security)