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.
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
news:b30d01c40b6d$973b4040$a601280a@phx.gbl... 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.
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-rxw...@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. --------------------
>References: <b30d01c40b6d$973b4040$a6012...@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: <#UR2xG4CEHA.1...@TK2MSFTNGP09.phx.gbl> >Newsgroups: microsoft.public.win2000.security >NNTP-Posting-Host:
>"kjelle" <kjell.rit...@kemi.se> wrote in message >news:b30d01c40b6d$973b4040$a601280a@phx.gbl... >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.
"Steven L Umbach" <sumb...@N0spam.ameritech.net> said
> 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
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?
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" <amitc...@removecasey.vic.gov.au> wrote in message
> "Steven L Umbach" <sumb...@N0spam.ameritech.net> said
> > 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
> 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?
My computers are W2K SP3 and XP Pro SP1 with a W2K SP3 domain controller. If 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-rxw...@online.microsoft.com> wrote in message
> 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-rxw...@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" > <sumb...@N0spam.ameritech.net> > >References: <b30d01c40b6d$973b4040$a6012...@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: <#UR2xG4CEHA.1...@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
> >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
> >"kjelle" <kjell.rit...@kemi.se> wrote in message > >news:b30d01c40b6d$973b4040$a601280a@phx.gbl... > >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 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. > *********************************************************************** > **
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)
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" <amitc...@removecasey.vic.gov.au> wrote in message
> "Steven L Umbach" <sumb...@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. > > *********************************************************************** > > **
> 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)
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.rit...@kemi.se> >Sender: "kjelle" <kjell.rit...@kemi.se> >Subject: authentication problem >Date: Tue, 16 Mar 2004 07:44:38 -0800 >Lines: 63 >Message-ID: <b30d01c40b6d$973b4040$a6012...@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.
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.
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. --------------------
>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.rit...@kemi.se> >>Sender: "kjelle" <kjell.rit...@kemi.se> >>Subject: authentication problem >>Date: Tue, 16 Mar 2004 07:44:38 -0800 >>Lines: 63 >>Message-ID: <b30d01c40b6d$973b4040$a6012...@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.
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
> 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.
> 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$a6012...@phx.gbl> > >MIME-Version: 1.0 > >Content-Type: text/plain > >Content-Transfer-Encoding: 7bit > >From: v-rxw...@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.3...@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.rit...@kemi.se> > >>Sender: "kjelle" <kjell.rit...@kemi.se> > >>Subject: authentication problem > >>Date: Tue, 16 Mar 2004 07:44:38 -0800 > >>Lines: 63 > >>Message-ID: <b30d01c40b6d$973b4040$a6012...@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.
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$a6012...@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: <O4GEcpnEEHA.2...@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
>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
>> 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.
>> 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$a6012...@phx.gbl> >> >MIME-Version: 1.0 >> >Content-Type: text/plain >> >Content-Transfer-Encoding: 7bit >> >From: v-rxw...@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.3...@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.rit...@kemi.se> >> >>Sender: "kjelle" <kjell.rit...@kemi.se> >> >>Subject: authentication problem >> >>Date: Tue, 16 Mar 2004 07:44:38 -0800 >> >>Lines: 63 >> >>Message-ID: <b30d01c40b6d$973b4040$a6012...@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.
> 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$a6012...@phx.gbl> > <HTfQ5$NEEHA.3...@cpmsftngxa06.phx.gbl> > <92b9#$lEEHA.3...@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: <O4GEcpnEEHA.2...@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
> >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
> >> 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.
> >> 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. > >> =====================================================
> >> >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.rit...@kemi.se> > >> >>Sender: "kjelle" <kjell.rit...@kemi.se> > >> >>Subject: authentication problem > >> >>Date: Tue, 16 Mar 2004 07:44:38 -0800 > >> >>Lines: 63 > >> >>Message-ID: <b30d01c40b6d$973b4040$a6012...@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.
