Hello,

I seem to be having a strange problem with my Active Directory user 
accounts.

We have a Windows 2008 AD domain, with our only domain controller 
located at a remote data center.  All of our locations have connectivity 
to the data center through a private MPLS network, with varying speeds.

Users at my largest office seem to lose the ability to properly 
authenticate to AD if they are added to too many security groups.  At 
first we thought it was a specific group causing the problem, but any 
new group will reproduce the issue.  There doesn't seem to be any magic 
number of groups that causes the problem either.  Some users are already 
members of 3-4 security groups, add a 5th one and authentication breaks.

When the problem occurs, users no longer seem to authenticate to the 
domain.  They log onto their computer and do not run the login script. 
Login also takes a lot longer -- it seems to sit and wait for a while 
before completing.  Once the user is logged into their PC, they can't 
access any networked resources.  If I try and map a network drive, I'll 
get prompted for credentials.  Enter the credentials & I can access the 
resource.

Anyone ever experienced anything like this or have any idea what might 
be going on?

Thanks!

Hi Vegas 

can you pls post the events esp. on DC.

Do you have  Events 3210,5722,5723 from netlogon?

Best Regards
Baris DOGAN 
MCT ,CCNA, MCSE 2K/2K3 + Security 


"Vegas or Bust" wrote:

> Hello,
> 
> I seem to be having a strange problem with my Active Directory user 
> accounts.
> 
> We have a Windows 2008 AD domain, with our only domain controller 
> located at a remote data center.  All of our locations have connectivity 
> to the data center through a private MPLS network, with varying speeds.
> 
> Users at my largest office seem to lose the ability to properly 
> authenticate to AD if they are added to too many security groups.  At 
> first we thought it was a specific group causing the problem, but any 
> new group will reproduce the issue.  There doesn't seem to be any magic 
> number of groups that causes the problem either.  Some users are already 
> members of 3-4 security groups, add a 5th one and authentication breaks.
> 
> When the problem occurs, users no longer seem to authenticate to the 
> domain.  They log onto their computer and do not run the login script. 
> Login also takes a lot longer -- it seems to sit and wait for a while 
> before completing.  Once the user is logged into their PC, they can't 
> access any networked resources.  If I try and map a network drive, I'll 
> get prompted for credentials.  Enter the credentials & I can access the 
> resource.
> 
> Anyone ever experienced anything like this or have any idea what might 
> be going on?
> 
> Thanks!
> .
> 

This sounds like a MTU issue and might happen because of the IP 
fragmentation that occurs over your MPLS network.
With every group added, the group SID is added to the kerberos ticket and if 
that ticket won't fit in a single frame over the MPLS network, it will be 
fragmented. Since this is happening over UDP, if the packets won't arrive in 
order some of them will be dropped, resulting in your issue.
Check here for an explanation and how to change it to TCP: 
http://support.microsoft.com/?kbid=244474

Andrei Ungureanu
www.winadmins.net

"Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message 
news:#QeL3YB4KHA.5324@TK2MSFTNGP05.phx.gbl...
> Hello,
>
> I seem to be having a strange problem with my Active Directory user 
> accounts.
>
> We have a Windows 2008 AD domain, with our only domain controller located 
> at a remote data center.  All of our locations have connectivity to the 
> data center through a private MPLS network, with varying speeds.
>
> Users at my largest office seem to lose the ability to properly 
> authenticate to AD if they are added to too many security groups.  At 
> first we thought it was a specific group causing the problem, but any new 
> group will reproduce the issue.  There doesn't seem to be any magic number 
> of groups that causes the problem either.  Some users are already members 
> of 3-4 security groups, add a 5th one and authentication breaks.
>
> When the problem occurs, users no longer seem to authenticate to the 
> domain.  They log onto their computer and do not run the login script. 
> Login also takes a lot longer -- it seems to sit and wait for a while 
> before completing.  Once the user is logged into their PC, they can't 
> access any networked resources.  If I try and map a network drive, I'll 
> get prompted for credentials.  Enter the credentials & I can access the 
> resource.
>
> Anyone ever experienced anything like this or have any idea what might be 
> going on?
>
> Thanks! 

"Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message 
news:%23QeL3YB4KHA.5324@TK2MSFTNGP05.phx.gbl...
> Hello,
>
> I seem to be having a strange problem with my Active Directory user 
> accounts.
>
> We have a Windows 2008 AD domain, with our only domain controller located 
> at a remote data center.  All of our locations have connectivity to the 
> data center through a private MPLS network, with varying speeds.
>
> Users at my largest office seem to lose the ability to properly 
> authenticate to AD if they are added to too many security groups.  At 
> first we thought it was a specific group causing the problem, but any new 
> group will reproduce the issue.  There doesn't seem to be any magic number 
> of groups that causes the problem either.  Some users are already members 
> of 3-4 security groups, add a 5th one and authentication breaks.
>
> When the problem occurs, users no longer seem to authenticate to the 
> domain.  They log onto their computer and do not run the login script. 
> Login also takes a lot longer -- it seems to sit and wait for a while 
> before completing.  Once the user is logged into their PC, they can't 
> access any networked resources.  If I try and map a network drive, I'll 
> get prompted for credentials.  Enter the credentials & I can access the 
> resource.
>
> Anyone ever experienced anything like this or have any idea what might be 
> going on?
>
> Thanks!

Although what you describe sounds like what is sometimes called "token 
bloat", I don't think it can be. When the user logs on, they get a token 
that has the SID of all security groups the user is a member of. This 
includes all groups the user is a direct member of, plus all memberships due 
to group nesting. It does not include distribution groups. If this token is 
too big you should see Event Log messages similar to those in the article 
linked by Andrei. However, my recollection is that this is experienced when 
the user is a member of many more than 5 groups.

The number of SID's in the token should be the same as the number of values 
in the tokenGroups attribute of the user. You can use ADSI Edit to view this 
attribute and count the number of values in the collection. Or you can run a 
script that counts the number of SID's in the tokenGroup attribute.

Another consideration is Universal Group membership, which is saved in the 
Global Catalog. Unless you have Universal Group caching enabled, a GC must 
be contacted during logon to determine Universal Group membership. However, 
if you have only one DC (which must be a GC), this wouldn't seem to be the 
problem. Except if the group that "breaks" authentication is a Universal 
Group, maybe this requires extra communication with the DC. Really, you 
shouldn't have any Universal Groups.

-- 
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
-- 

Like Richard sais, it sounds like the user is member of too much 
(nested) security groups which causes the Kerberos tokensize to exceed 
the max. Those 3-4 groups you are talking about must have a lot of 
subgroups nested.

Take a look at this knowlegebase article:

http://support.microsoft.com/kb/327825

When this happens the user is not known to be member of certain groups, 
which can result in just about anything.

I experienced this on the job resulting mainly in unaccesable folders.

Each unique membership makes the token larger (domain local groups even 
more than global groups). There is a tool called Tokensz (microsoft 
download) to test the user's token size, but I don't know if it's 2008 
compatible.

If the max tokensize is your problem, be aware that the MaxTokenSize 
registrykey that the knowledgebase article is talking about must be set 
on all computers on which these users logon to.

To generate an overview of all groupmemberships, including the nested 
ones, you can download GroupMemberTree on:

http://www.ZEDA.nl/en/?postid=20100402

Good luck.

ZEDA



www.ZEDA.nl - Windows Advanced Tips & Tricks


Op 20-4-2010 16:09, Richard Mueller [MVP] schreef:
> "Vegas or Bust"<tallguyinlv@hotmail.com>  wrote in message
> news:%23QeL3YB4KHA.5324@TK2MSFTNGP05.phx.gbl...
>> Hello,
>>
>> I seem to be having a strange problem with my Active Directory user
>> accounts.
>>
>> We have a Windows 2008 AD domain, with our only domain controller located
>> at a remote data center.  All of our locations have connectivity to the
>> data center through a private MPLS network, with varying speeds.
>>
>> Users at my largest office seem to lose the ability to properly
>> authenticate to AD if they are added to too many security groups.  At
>> first we thought it was a specific group causing the problem, but any new
>> group will reproduce the issue.  There doesn't seem to be any magic number
>> of groups that causes the problem either.  Some users are already members
>> of 3-4 security groups, add a 5th one and authentication breaks.
>>
>> When the problem occurs, users no longer seem to authenticate to the
>> domain.  They log onto their computer and do not run the login script.
>> Login also takes a lot longer -- it seems to sit and wait for a while
>> before completing.  Once the user is logged into their PC, they can't
>> access any networked resources.  If I try and map a network drive, I'll
>> get prompted for credentials.  Enter the credentials&  I can access the
>> resource.
>>
>> Anyone ever experienced anything like this or have any idea what might be
>> going on?
>>
>> Thanks!
>
> Although what you describe sounds like what is sometimes called "token
> bloat", I don't think it can be. When the user logs on, they get a token
> that has the SID of all security groups the user is a member of. This
> includes all groups the user is a direct member of, plus all memberships due
> to group nesting. It does not include distribution groups. If this token is
> too big you should see Event Log messages similar to those in the article
> linked by Andrei. However, my recollection is that this is experienced when
> the user is a member of many more than 5 groups.
>
> The number of SID's in the token should be the same as the number of values
> in the tokenGroups attribute of the user. You can use ADSI Edit to view this
> attribute and count the number of values in the collection. Or you can run a
> script that counts the number of SID's in the tokenGroup attribute.
>
> Another consideration is Universal Group membership, which is saved in the
> Global Catalog. Unless you have Universal Group caching enabled, a GC must
> be contacted during logon to determine Universal Group membership. However,
> if you have only one DC (which must be a GC), this wouldn't seem to be the
> problem. Except if the group that "breaks" authentication is a Universal
> Group, maybe this requires extra communication with the DC. Really, you
> shouldn't have any Universal Groups.
>

"ZEDA" <contact@zeda.nl> wrote in message 
news:4bcdbd05$0$22913$e4fe514c@news.xs4all.nl...
> Like Richard sais, it sounds like the user is member of too much (nested) 
> security groups which causes the Kerberos tokensize to exceed the max. 
> Those 3-4 groups you are talking about must have a lot of subgroups 
> nested.
>
> Take a look at this knowlegebase article:
>
> http://support.microsoft.com/kb/327825
>
> When this happens the user is not known to be member of certain groups, 
> which can result in just about anything.
>
> I experienced this on the job resulting mainly in unaccesable folders.
>
> Each unique membership makes the token larger (domain local groups even 
> more than global groups). There is a tool called Tokensz (microsoft 
> download) to test the user's token size, but I don't know if it's 2008 
> compatible.
>
> If the max tokensize is your problem, be aware that the MaxTokenSize 
> registrykey that the knowledgebase article is talking about must be set on 
> all computers on which these users logon to.
>
> To generate an overview of all groupmemberships, including the nested 
> ones, you can download GroupMemberTree on:
>
> http://www.ZEDA.nl/en/?postid=20100402
>
> Good luck.
>
> ZEDA
>

Here is a VBScript program that reports on the number of security group 
memberships, and the size of the tokenGroups attribute in bytes, for a 
specified user. Modify the Distinguished Name of the user for your 
situation:
==========
Option Explicit
Dim objUser, arrbytGroups, lngNumber, bytSID, lngSize

Set objUser = GetObject("LDAP://cn=Jim Smith,ou=West,dc=MyDomain,dc=com")
objUser.GetInfoEx Array("tokenGroups"), 0
arrbytGroups = objUser.tokenGroups
lngNumber = UBound(arrbytGroups) + 1
Wscript.Echo "Number of security groups: " & CStr(lngNumber)
lngSize = 0
For Each bytSID In arrbytGroups
    lngSize = lngSize + LenB(bytSID)
Next
Wscript.Echo "Token size in bytes: " & CStr(lngSize)
=========
The size of the tokenGroups attribute is probably not the same as the size 
of the token the user gets at logon, but it is closely related.

-- 
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
-- 

On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
<tallguyinlv@hotmail.com> wrote:

>Hello,
>
>I seem to be having a strange problem with my Active Directory user 
>accounts.
>
>We have a Windows 2008 AD domain, with our only domain controller 
>located at a remote data center.  All of our locations have connectivity 
>to the data center through a private MPLS network, with varying speeds.
>
>Users at my largest office seem to lose the ability to properly 
>authenticate to AD if they are added to too many security groups.  At 
>first we thought it was a specific group causing the problem, but any 
>new group will reproduce the issue.  There doesn't seem to be any magic 
>number of groups that causes the problem either.  Some users are already 
>members of 3-4 security groups, add a 5th one and authentication breaks.
>
>When the problem occurs, users no longer seem to authenticate to the 
>domain.  They log onto their computer and do not run the login script. 
>Login also takes a lot longer -- it seems to sit and wait for a while 
>before completing.  Once the user is logged into their PC, they can't 
>access any networked resources.  If I try and map a network drive, I'll 
>get prompted for credentials.  Enter the credentials & I can access the 
>resource.
>
>Anyone ever experienced anything like this or have any idea what might 
>be going on?
>
>Thanks!

For starters, can you provide us with an ipconfig /all of the DC and
of the client, please? This will allow us to evaluate any basic
misconfigurations, if they exist.

Thank you,


Ace

This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.

Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

I don't have remote access to the DC (it's managed by a hosting company) 
but will request a copy of the logs.

I'm seeing the following errors in the System logs on my workstation:

Event ID: 5719
Source: NETLOGON

No domain controller is available for domain XXXX due to the following: 
The RPC server is unavailable.  Make sure that the computer is connected 
to the network and try again.  If the problem persists, please contact 
your domain administrator.

Event ID: 40960
Source: LSASRV

The Security System detected an attempted downgrade attack for server 
cifs/xxx.xxx.xxx (the name of my file server).  The failure code from 
authentication protocol Kerberos was "There are currently no logon 
servers available to service the logon request.  (0xc000005e)

Event ID: 40961
Source: LSASRV

The Security System could not establish a secured connection with the 
server cifs/xxx.xxx.xxx (again, the name of my file server).  No 
authentication protocol was available.

This one is in my Application logs:

Event ID: 1054
Source: Userenv

Windows cannot obtain the domain controller name for your computer 
network. (A socket operation was attempted to an unreachable host.). 
Group policy processing aborted.



I'll post any errors on the DC once I get a copy of the logs.

Thanks.


On 4/20/2010 1:49 AM, Baris DOGAN wrote:
> Hi Vegas
>
> can you pls post the events esp. on DC.
>
> Do you have  Events 3210,5722,5723 from netlogon?
>
> Best Regards
> Baris DOGAN
> MCT ,CCNA, MCSE 2K/2K3 + Security
>
>
> "Vegas or Bust" wrote:
>
>> Hello,
>>
>> I seem to be having a strange problem with my Active Directory user
>> accounts.
>>
>> We have a Windows 2008 AD domain, with our only domain controller
>> located at a remote data center.  All of our locations have connectivity
>> to the data center through a private MPLS network, with varying speeds.
>>
>> Users at my largest office seem to lose the ability to properly
>> authenticate to AD if they are added to too many security groups.  At
>> first we thought it was a specific group causing the problem, but any
>> new group will reproduce the issue.  There doesn't seem to be any magic
>> number of groups that causes the problem either.  Some users are already
>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>
>> When the problem occurs, users no longer seem to authenticate to the
>> domain.  They log onto their computer and do not run the login script.
>> Login also takes a lot longer -- it seems to sit and wait for a while
>> before completing.  Once the user is logged into their PC, they can't
>> access any networked resources.  If I try and map a network drive, I'll
>> get prompted for credentials.  Enter the credentials&  I can access the
>> resource.
>>
>> Anyone ever experienced anything like this or have any idea what might
>> be going on?
>>
>> Thanks!
>> .
>>

Thank you for this.  I ran it against one particularly troublesome user 
and these were the results:

Number of security groups: 5
Token size in bytes: 128

Most of my users are not members of very many groups, and none of them 
have nested memberships.  It's a fairly basic implementation for a small 
company.

Thanks.

On 4/20/2010 8:07 AM, Richard Mueller [MVP] wrote:
> Option Explicit
> Dim objUser, arrbytGroups, lngNumber, bytSID, lngSize
>
> Set objUser = GetObject("LDAP://cn=Jim Smith,ou=West,dc=MyDomain,dc=com")
> objUser.GetInfoEx Array("tokenGroups"), 0
> arrbytGroups = objUser.tokenGroups
> lngNumber = UBound(arrbytGroups) + 1
> Wscript.Echo "Number of security groups: "&  CStr(lngNumber)
> lngSize = 0
> For Each bytSID In arrbytGroups
>      lngSize = lngSize + LenB(bytSID)
> Next
> Wscript.Echo "Token size in bytes: "&  CStr(lngSize)

Thank you for this information.  I made this change on one of 
workstations and it seemed to resolve the problem, however it made 
everything very slow.  Logging in takes multiple minutes (used to be 
less than a minute), opening network resources is very slow, etc.

Any idea why this makes it so slow, or if there is a way to speed things up?

Thanks.

On 4/20/2010 2:13 AM, Andrei Ungureanu wrote:
> This sounds like a MTU issue and might happen because of the IP
> fragmentation that occurs over your MPLS network.
> With every group added, the group SID is added to the kerberos ticket
> and if that ticket won't fit in a single frame over the MPLS network, it
> will be fragmented. Since this is happening over UDP, if the packets
> won't arrive in order some of them will be dropped, resulting in your
> issue.
> Check here for an explanation and how to change it to TCP:
> http://support.microsoft.com/?kbid=244474
>
> Andrei Ungureanu
> www.winadmins.net
>
> "Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message
> news:#QeL3YB4KHA.5324@TK2MSFTNGP05.phx.gbl...
>> Hello,
>>
>> I seem to be having a strange problem with my Active Directory user
>> accounts.
>>
>> We have a Windows 2008 AD domain, with our only domain controller
>> located at a remote data center. All of our locations have
>> connectivity to the data center through a private MPLS network, with
>> varying speeds.
>>
>> Users at my largest office seem to lose the ability to properly
>> authenticate to AD if they are added to too many security groups. At
>> first we thought it was a specific group causing the problem, but any
>> new group will reproduce the issue. There doesn't seem to be any magic
>> number of groups that causes the problem either. Some users are
>> already members of 3-4 security groups, add a 5th one and
>> authentication breaks.
>>
>> When the problem occurs, users no longer seem to authenticate to the
>> domain. They log onto their computer and do not run the login script.
>> Login also takes a lot longer -- it seems to sit and wait for a while
>> before completing. Once the user is logged into their PC, they can't
>> access any networked resources. If I try and map a network drive, I'll
>> get prompted for credentials. Enter the credentials & I can access the
>> resource.
>>
>> Anyone ever experienced anything like this or have any idea what might
>> be going on?
>>
>> Thanks!
>

Those are very small numbers. More likely you have DNS or configuration 
problems. Ace Fekay's request for the output from "ipconfig /all" might 
help.

-- 
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message 
news:e0gOUtL4KHA.5324@TK2MSFTNGP05.phx.gbl...
> Thank you for this.  I ran it against one particularly troublesome user 
> and these were the results:
>
> Number of security groups: 5
> Token size in bytes: 128
>
> Most of my users are not members of very many groups, and none of them 
> have nested memberships.  It's a fairly basic implementation for a small 
> company.
>
> Thanks.
>
> On 4/20/2010 8:07 AM, Richard Mueller [MVP] wrote:
>> Option Explicit
>> Dim objUser, arrbytGroups, lngNumber, bytSID, lngSize
>>
>> Set objUser = GetObject("LDAP://cn=Jim Smith,ou=West,dc=MyDomain,dc=com")
>> objUser.GetInfoEx Array("tokenGroups"), 0
>> arrbytGroups = objUser.tokenGroups
>> lngNumber = UBound(arrbytGroups) + 1
>> Wscript.Echo "Number of security groups: "&  CStr(lngNumber)
>> lngSize = 0
>> For Each bytSID In arrbytGroups
>>      lngSize = lngSize + LenB(bytSID)
>> Next
>> Wscript.Echo "Token size in bytes: "&  CStr(lngSize)
> 

First of all I would look into the network config (MPLS, VPN, MTU) and even 
DNS config of your domain controllers and workstations. Then, the next logic 
step will be to take a network capture to see what is happening over the 
wire.

Andrei Ungureanu
www.winadmins.net


"Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message 
news:#dEf6wL4KHA.5212@TK2MSFTNGP04.phx.gbl...
> Thank you for this information.  I made this change on one of workstations 
> and it seemed to resolve the problem, however it made everything very 
> slow.  Logging in takes multiple minutes (used to be less than a minute), 
> opening network resources is very slow, etc.
>
> Any idea why this makes it so slow, or if there is a way to speed things 
> up?
>
> Thanks.
>
> On 4/20/2010 2:13 AM, Andrei Ungureanu wrote:
>> This sounds like a MTU issue and might happen because of the IP
>> fragmentation that occurs over your MPLS network.
>> With every group added, the group SID is added to the kerberos ticket
>> and if that ticket won't fit in a single frame over the MPLS network, it
>> will be fragmented. Since this is happening over UDP, if the packets
>> won't arrive in order some of them will be dropped, resulting in your
>> issue.
>> Check here for an explanation and how to change it to TCP:
>> http://support.microsoft.com/?kbid=244474
>>
>> Andrei Ungureanu
>> www.winadmins.net
>>
>> "Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message
>> news:#QeL3YB4KHA.5324@TK2MSFTNGP05.phx.gbl...
>>> Hello,
>>>
>>> I seem to be having a strange problem with my Active Directory user
>>> accounts.
>>>
>>> We have a Windows 2008 AD domain, with our only domain controller
>>> located at a remote data center. All of our locations have
>>> connectivity to the data center through a private MPLS network, with
>>> varying speeds.
>>>
>>> Users at my largest office seem to lose the ability to properly
>>> authenticate to AD if they are added to too many security groups. At
>>> first we thought it was a specific group causing the problem, but any
>>> new group will reproduce the issue. There doesn't seem to be any magic
>>> number of groups that causes the problem either. Some users are
>>> already members of 3-4 security groups, add a 5th one and
>>> authentication breaks.
>>>
>>> When the problem occurs, users no longer seem to authenticate to the
>>> domain. They log onto their computer and do not run the login script.
>>> Login also takes a lot longer -- it seems to sit and wait for a while
>>> before completing. Once the user is logged into their PC, they can't
>>> access any networked resources. If I try and map a network drive, I'll
>>> get prompted for credentials. Enter the credentials & I can access the
>>> resource.
>>>
>>> Anyone ever experienced anything like this or have any idea what might
>>> be going on?
>>>
>>> Thanks!
>>
> 

It seems that forcing Kerberos over TCP instead of using UDP fixes the 
problem as per this article: http://support.microsoft.com/?kbid=244474

However, once we make this change to a workstation it becomes very slow 
when accessing network resources.  It takes 4+ minutes to login, then 
there are very noticable delays when trying to access files, printers, 
etc. over the network -- you click on something then it sits with an 
hour glass for a while.

Here are the results of ipconfig /all on the DC:

Windows IP Configuration

    Host Name . . . . . . . . . . . . : yyyy1WADC001
    Primary Dns Suffix  . . . . . . . : xxxx.LAN
    Node Type . . . . . . . . . . . . : Hybrid
    IP Routing Enabled. . . . . . . . : No
    WINS Proxy Enabled. . . . . . . . : No
    DNS Suffix Search List. . . . . . : xxxx.LAN

Ethernet adapter Front End:

    Connection-specific DNS Suffix  . : xxxx.LAN
    Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
    Physical Address. . . . . . . . . : 00-50-56-89-76-B6
    DHCP Enabled. . . . . . . . . . . : No
    Autoconfiguration Enabled . . . . : Yes
    Link-local IPv6 Address . . . . . : 
fe80::10ac:9d19:bcd:5d46%10(Preferred)
    IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 198.18.50.254
    DHCPv6 IAID . . . . . . . . . . . : 218124374
    DHCPv6 Client DUID. . . . . . . . : 
00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6

    DNS Servers . . . . . . . . . . . : ::1
                                        127.0.0.1
    NetBIOS over Tcpip. . . . . . . . : Enabled



On 4/20/2010 12:25 PM, Richard Mueller [MVP] wrote:
> Those are very small numbers. More likely you have DNS or configuration
> problems. Ace Fekay's request for the output from "ipconfig /all" might
> help.
>

Hi Ace,

It seems that forcing Kerberos over TCP instead of using UDP fixes the 
problem as per this article: http://support.microsoft.com/?kbid=244474

However, once we make this change to a workstation it becomes very slow 
when accessing network resources.  It takes 4+ minutes to login, then 
there are very noticable delays when trying to access files, printers, 
etc. over the network -- you click on something then it sits with an 
hour glass for a while.

Here are the results of ipconfig /all on the DC:

Windows IP Configuration

    Host Name . . . . . . . . . . . . : yyyy1WADC001
    Primary Dns Suffix  . . . . . . . : xxxx.LAN
    Node Type . . . . . . . . . . . . : Hybrid
    IP Routing Enabled. . . . . . . . : No
    WINS Proxy Enabled. . . . . . . . : No
    DNS Suffix Search List. . . . . . : xxxx.LAN

Ethernet adapter Front End:

    Connection-specific DNS Suffix  . : xxxx.LAN
    Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
    Physical Address. . . . . . . . . : 00-50-56-89-76-B6
    DHCP Enabled. . . . . . . . . . . : No
    Autoconfiguration Enabled . . . . : Yes
    Link-local IPv6 Address . . . . . : 
fe80::10ac:9d19:bcd:5d46%10(Preferred)
    IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 198.18.50.254
    DHCPv6 IAID . . . . . . . . . . . : 218124374
    DHCPv6 Client DUID. . . . . . . . : 
00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6

    DNS Servers . . . . . . . . . . . : ::1
                                        127.0.0.1
    NetBIOS over Tcpip. . . . . . . . : Enabled




On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
> <tallguyinlv@hotmail.com>  wrote:
>
>> Hello,
>>
>> I seem to be having a strange problem with my Active Directory user
>> accounts.
>>
>> We have a Windows 2008 AD domain, with our only domain controller
>> located at a remote data center.  All of our locations have connectivity
>> to the data center through a private MPLS network, with varying speeds.
>>
>> Users at my largest office seem to lose the ability to properly
>> authenticate to AD if they are added to too many security groups.  At
>> first we thought it was a specific group causing the problem, but any
>> new group will reproduce the issue.  There doesn't seem to be any magic
>> number of groups that causes the problem either.  Some users are already
>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>
>> When the problem occurs, users no longer seem to authenticate to the
>> domain.  They log onto their computer and do not run the login script.
>> Login also takes a lot longer -- it seems to sit and wait for a while
>> before completing.  Once the user is logged into their PC, they can't
>> access any networked resources.  If I try and map a network drive, I'll
>> get prompted for credentials.  Enter the credentials&  I can access the
>> resource.
>>
>> Anyone ever experienced anything like this or have any idea what might
>> be going on?
>>
>> Thanks!
>
> For starters, can you provide us with an ipconfig /all of the DC and
> of the client, please? This will allow us to evaluate any basic
> misconfigurations, if they exist.
>
> Thank you,
>
>
> Ace
>
> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
>
> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
>
> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&  Exchange 2007, MCSE&  MCSA 2003/2000, MCSA Messaging 2003
> Microsoft Certified Trainer
> Microsoft MVP - Directory Services
>
> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

That actually looks pretty good. I would suggest to change the
127.0.0.1 to 198.18.50.11.

Also, I noticed these are public IPs. No biggy, but assumed you had a
private IP network.

As for forcing TCP, that's a red flag that UDP ports are being
blocked, or going back to what Andrei said, i can definitely be an MTU
issue on one of the MPLS routers or firewall. 

If the MTU is anything less than default, as PPPoE routers, and
apparently what the MPLS in your case may be doing, is affecting the
LDAP PDU size. I am trying to find an old article that explains thisr,
but I can't find it, but the article Andrei posted explains a way
around it. 

I would start digging into your MPLS configuration instead of altering
your DCs. :-)

Ace



On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
<tallguyinlv@hotmail.com> wrote:

>Hi Ace,
>
>It seems that forcing Kerberos over TCP instead of using UDP fixes the 
>problem as per this article: http://support.microsoft.com/?kbid=244474
>
>However, once we make this change to a workstation it becomes very slow 
>when accessing network resources.  It takes 4+ minutes to login, then 
>there are very noticable delays when trying to access files, printers, 
>etc. over the network -- you click on something then it sits with an 
>hour glass for a while.
>
>Here are the results of ipconfig /all on the DC:
>
>Windows IP Configuration
>
>    Host Name . . . . . . . . . . . . : yyyy1WADC001
>    Primary Dns Suffix  . . . . . . . : xxxx.LAN
>    Node Type . . . . . . . . . . . . : Hybrid
>    IP Routing Enabled. . . . . . . . : No
>    WINS Proxy Enabled. . . . . . . . : No
>    DNS Suffix Search List. . . . . . : xxxx.LAN
>
>Ethernet adapter Front End:
>
>    Connection-specific DNS Suffix  . : xxxx.LAN
>    Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
>    Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>    DHCP Enabled. . . . . . . . . . . : No
>    Autoconfiguration Enabled . . . . : Yes
>    Link-local IPv6 Address . . . . . : 
>fe80::10ac:9d19:bcd:5d46%10(Preferred)
>    IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>    Subnet Mask . . . . . . . . . . . : 255.255.255.0
>    Default Gateway . . . . . . . . . : 198.18.50.254
>    DHCPv6 IAID . . . . . . . . . . . : 218124374
>    DHCPv6 Client DUID. . . . . . . . : 
>00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>
>    DNS Servers . . . . . . . . . . . : ::1
>                                        127.0.0.1
>    NetBIOS over Tcpip. . . . . . . . : Enabled
>
>
>
>
>On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>> <tallguyinlv@hotmail.com>  wrote:
>>
>>> Hello,
>>>
>>> I seem to be having a strange problem with my Active Directory user
>>> accounts.
>>>
>>> We have a Windows 2008 AD domain, with our only domain controller
>>> located at a remote data center.  All of our locations have connectivity
>>> to the data center through a private MPLS network, with varying speeds.
>>>
>>> Users at my largest office seem to lose the ability to properly
>>> authenticate to AD if they are added to too many security groups.  At
>>> first we thought it was a specific group causing the problem, but any
>>> new group will reproduce the issue.  There doesn't seem to be any magic
>>> number of groups that causes the problem either.  Some users are already
>>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>>
>>> When the problem occurs, users no longer seem to authenticate to the
>>> domain.  They log onto their computer and do not run the login script.
>>> Login also takes a lot longer -- it seems to sit and wait for a while
>>> before completing.  Once the user is logged into their PC, they can't
>>> access any networked resources.  If I try and map a network drive, I'll
>>> get prompted for credentials.  Enter the credentials&  I can access the
>>> resource.
>>>
>>> Anyone ever experienced anything like this or have any idea what might
>>> be going on?
>>>
>>> Thanks!
>>
>> For starters, can you provide us with an ipconfig /all of the DC and
>> of the client, please? This will allow us to evaluate any basic
>> misconfigurations, if they exist.
>>
>> Thank you,
>>
>>
>> Ace
>>
>> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
>>
>> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
>>
>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&  Exchange 2007, MCSE&  MCSA 2003/2000, MCSA Messaging 2003
>> Microsoft Certified Trainer
>> Microsoft MVP - Directory Services
>>
>> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

Hello,

We're still fighting with this issue.  I have some network engineers 
looking at the MTU settings, but I made a new discovery today.

I have an account here that exhibited the problem (doesn't properly 
authenticate to the domain, no login script, gets prompted every time 
she tries to access any domain resources).  Every Windows XP computer 
she logs into has the same problem.  I have a Windows 7 machine here and 
she can login just fine -- she authenticates properly, login script runs 
and she doesn't get re-prompted when accessing resources.

Does this still point to a network issue, or is it possible that 
something else is going on?

On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
> That actually looks pretty good. I would suggest to change the
> 127.0.0.1 to 198.18.50.11.
>
> Also, I noticed these are public IPs. No biggy, but assumed you had a
> private IP network.
>
> As for forcing TCP, that's a red flag that UDP ports are being
> blocked, or going back to what Andrei said, i can definitely be an MTU
> issue on one of the MPLS routers or firewall.
>
> If the MTU is anything less than default, as PPPoE routers, and
> apparently what the MPLS in your case may be doing, is affecting the
> LDAP PDU size. I am trying to find an old article that explains thisr,
> but I can't find it, but the article Andrei posted explains a way
> around it.
>
> I would start digging into your MPLS configuration instead of altering
> your DCs. :-)
>
> Ace
>
>
>
> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
> <tallguyinlv@hotmail.com>  wrote:
>
>> Hi Ace,
>>
>> It seems that forcing Kerberos over TCP instead of using UDP fixes the
>> problem as per this article: http://support.microsoft.com/?kbid=244474
>>
>> However, once we make this change to a workstation it becomes very slow
>> when accessing network resources.  It takes 4+ minutes to login, then
>> there are very noticable delays when trying to access files, printers,
>> etc. over the network -- you click on something then it sits with an
>> hour glass for a while.
>>
>> Here are the results of ipconfig /all on the DC:
>>
>> Windows IP Configuration
>>
>>     Host Name . . . . . . . . . . . . : yyyy1WADC001
>>     Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>     Node Type . . . . . . . . . . . . : Hybrid
>>     IP Routing Enabled. . . . . . . . : No
>>     WINS Proxy Enabled. . . . . . . . : No
>>     DNS Suffix Search List. . . . . . : xxxx.LAN
>>
>> Ethernet adapter Front End:
>>
>>     Connection-specific DNS Suffix  . : xxxx.LAN
>>     Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
>>     Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>     DHCP Enabled. . . . . . . . . . . : No
>>     Autoconfiguration Enabled . . . . : Yes
>>     Link-local IPv6 Address . . . . . :
>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>     IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>     Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>     Default Gateway . . . . . . . . . : 198.18.50.254
>>     DHCPv6 IAID . . . . . . . . . . . : 218124374
>>     DHCPv6 Client DUID. . . . . . . . :
>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>
>>     DNS Servers . . . . . . . . . . . : ::1
>>                                         127.0.0.1
>>     NetBIOS over Tcpip. . . . . . . . : Enabled
>>
>>
>>
>>
>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>> <tallguyinlv@hotmail.com>   wrote:
>>>
>>>> Hello,
>>>>
>>>> I seem to be having a strange problem with my Active Directory user
>>>> accounts.
>>>>
>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>> located at a remote data center.  All of our locations have connectivity
>>>> to the data center through a private MPLS network, with varying speeds.
>>>>
>>>> Users at my largest office seem to lose the ability to properly
>>>> authenticate to AD if they are added to too many security groups.  At
>>>> first we thought it was a specific group causing the problem, but any
>>>> new group will reproduce the issue.  There doesn't seem to be any magic
>>>> number of groups that causes the problem either.  Some users are already
>>>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>>>
>>>> When the problem occurs, users no longer seem to authenticate to the
>>>> domain.  They log onto their computer and do not run the login script.
>>>> Login also takes a lot longer -- it seems to sit and wait for a while
>>>> before completing.  Once the user is logged into their PC, they can't
>>>> access any networked resources.  If I try and map a network drive, I'll
>>>> get prompted for credentials.  Enter the credentials&   I can access the
>>>> resource.
>>>>
>>>> Anyone ever experienced anything like this or have any idea what might
>>>> be going on?
>>>>
>>>> Thanks!
>>>
>>> For starters, can you provide us with an ipconfig /all of the DC and
>>> of the client, please? This will allow us to evaluate any basic
>>> misconfigurations, if they exist.
>>>
>>> Thank you,
>>>
>>>
>>> Ace
>>>
>>> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
>>>
>>> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
>>>
>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&   Exchange 2007, MCSE&   MCSA 2003/2000, MCSA Messaging 2003
>>> Microsoft Certified Trainer
>>> Microsoft MVP - Directory Services
>>>
>>> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

Hello Vegas,

Still with the problem? I thought it was resolved since I haven't
heard back.

If it is only happening with the XP machines, and not the Windows 7
machine, it maybe be an SMB signing issue on the DCs that need to be
reduced. 

For example, here's a short write-up for 2008 R2 and signing. It's on
by default. Win 7 follows this, but not older OS'.

Require SMB Security Signatures
http://technet.microsoft.com/en-us/library/cc731957.aspx

Other references:

Microsoft network server: Digitally sign communications (always)
http://technet.microsoft.com/en-us/library/cc786681(WS.10).aspx 

Server Message Block communication between a client-side SMB component
and a server-side SMB component is not completed if the SMB signing
settings are mismatched in Group Policy or in the registry:
http://support.microsoft.com/kb/916846/en-us

Overview of Server Message Block signing (older article)
http://support.microsoft.com/kb/887429

Ace


On Tue, 01 Jun 2010 14:38:55 -0700, Vegas or Bust
<tallguyinlv@hotmail.com> wrote:

>Hello,
>
>We're still fighting with this issue.  I have some network engineers 
>looking at the MTU settings, but I made a new discovery today.
>
>I have an account here that exhibited the problem (doesn't properly 
>authenticate to the domain, no login script, gets prompted every time 
>she tries to access any domain resources).  Every Windows XP computer 
>she logs into has the same problem.  I have a Windows 7 machine here and 
>she can login just fine -- she authenticates properly, login script runs 
>and she doesn't get re-prompted when accessing resources.
>
>Does this still point to a network issue, or is it possible that 
>something else is going on?
>
>On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>> That actually looks pretty good. I would suggest to change the
>> 127.0.0.1 to 198.18.50.11.
>>
>> Also, I noticed these are public IPs. No biggy, but assumed you had a
>> private IP network.
>>
>> As for forcing TCP, that's a red flag that UDP ports are being
>> blocked, or going back to what Andrei said, i can definitely be an MTU
>> issue on one of the MPLS routers or firewall.
>>
>> If the MTU is anything less than default, as PPPoE routers, and
>> apparently what the MPLS in your case may be doing, is affecting the
>> LDAP PDU size. I am trying to find an old article that explains thisr,
>> but I can't find it, but the article Andrei posted explains a way
>> around it.
>>
>> I would start digging into your MPLS configuration instead of altering
>> your DCs. :-)
>>
>> Ace
>>
>>
>>
>> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
>> <tallguyinlv@hotmail.com>  wrote:
>>
>>> Hi Ace,
>>>
>>> It seems that forcing Kerberos over TCP instead of using UDP fixes the
>>> problem as per this article: http://support.microsoft.com/?kbid=244474
>>>
>>> However, once we make this change to a workstation it becomes very slow
>>> when accessing network resources.  It takes 4+ minutes to login, then
>>> there are very noticable delays when trying to access files, printers,
>>> etc. over the network -- you click on something then it sits with an
>>> hour glass for a while.
>>>
>>> Here are the results of ipconfig /all on the DC:
>>>
>>> Windows IP Configuration
>>>
>>>     Host Name . . . . . . . . . . . . : yyyy1WADC001
>>>     Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>>     Node Type . . . . . . . . . . . . : Hybrid
>>>     IP Routing Enabled. . . . . . . . : No
>>>     WINS Proxy Enabled. . . . . . . . : No
>>>     DNS Suffix Search List. . . . . . : xxxx.LAN
>>>
>>> Ethernet adapter Front End:
>>>
>>>     Connection-specific DNS Suffix  . : xxxx.LAN
>>>     Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
>>>     Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>>     DHCP Enabled. . . . . . . . . . . : No
>>>     Autoconfiguration Enabled . . . . : Yes
>>>     Link-local IPv6 Address . . . . . :
>>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>>     IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>>     Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>>     Default Gateway . . . . . . . . . : 198.18.50.254
>>>     DHCPv6 IAID . . . . . . . . . . . : 218124374
>>>     DHCPv6 Client DUID. . . . . . . . :
>>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>>
>>>     DNS Servers . . . . . . . . . . . : ::1
>>>                                         127.0.0.1
>>>     NetBIOS over Tcpip. . . . . . . . : Enabled
>>>
>>>
>>>
>>>
>>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>>> <tallguyinlv@hotmail.com>   wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I seem to be having a strange problem with my Active Directory user
>>>>> accounts.
>>>>>
>>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>>> located at a remote data center.  All of our locations have connectivity
>>>>> to the data center through a private MPLS network, with varying speeds.
>>>>>
>>>>> Users at my largest office seem to lose the ability to properly
>>>>> authenticate to AD if they are added to too many security groups.  At
>>>>> first we thought it was a specific group causing the problem, but any
>>>>> new group will reproduce the issue.  There doesn't seem to be any magic
>>>>> number of groups that causes the problem either.  Some users are already
>>>>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>>>>
>>>>> When the problem occurs, users no longer seem to authenticate to the
>>>>> domain.  They log onto their computer and do not run the login script.
>>>>> Login also takes a lot longer -- it seems to sit and wait for a while
>>>>> before completing.  Once the user is logged into their PC, they can't
>>>>> access any networked resources.  If I try and map a network drive, I'll
>>>>> get prompted for credentials.  Enter the credentials&   I can access the
>>>>> resource.
>>>>>
>>>>> Anyone ever experienced anything like this or have any idea what might
>>>>> be going on?
>>>>>
>>>>> Thanks!
>>>>
>>>> For starters, can you provide us with an ipconfig /all of the DC and
>>>> of the client, please? This will allow us to evaluate any basic
>>>> misconfigurations, if they exist.
>>>>
>>>> Thank you,
>>>>
>>>>
>>>> Ace
>>>>
>>>> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
>>>>
>>>> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
>>>>
>>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&   Exchange 2007, MCSE&   MCSA 2003/2000, MCSA Messaging 2003
>>>> Microsoft Certified Trainer
>>>> Microsoft MVP - Directory Services
>>>>
>>>> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

I have a laptop here that's experiencing the problem.  I can do a domain 
login using my own account & a couple others, but one specific account 
(the lady who owns the laptop) can't login.  I deleted her AD account & 
created a new one, but it still has the same issue.  If it were caused 
by an SMB signing issue, I would think that nobody could login to this 
machine.

The problem originally seemed to manifest on accounts that were members 
of some security groups.  If we reduced the number of groups, the 
account would start working.  They didn't have a huge number of groups 
-- maybe 4 or 5 -- without any nesting.  Now I'm seeing the problem on 
this account which is only a member of Domain Users.  I had a couple 
other problem accounts last week & was able to fix the issue by deleting 
their AD account and creating a new one, but that didn't help for this 
case.  The problem also doesn't seem to be location specific -- this 
problem laptop exhibits the same issue in multiple offices.

We tried reducing the MTU on our routers this morning to 1400.  My ping 
testing showed that 1430 was the highest MTU setting that wouldn't 
result in fragmentation.  As soon as the network engineers changed the 
MTU from the default of 1500 to 1400, all domain traffic stopped and 
they detected a ton of errors, so we restored the MTU to 1500.  I'm 
thinking that maybe we should try setting the MTU to 1400 directly on 
the DC and see if that makes a difference?  Otherwise I'm pretty much 
stumped.

Thanks again for any help or direction you can provide!!

On 6/1/2010 9:37 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
> Hello Vegas,
>
> Still with the problem? I thought it was resolved since I haven't
> heard back.
>
> If it is only happening with the XP machines, and not the Windows 7
> machine, it maybe be an SMB signing issue on the DCs that need to be
> reduced.
>
> For example, here's a short write-up for 2008 R2 and signing. It's on
> by default. Win 7 follows this, but not older OS'.
>
> Require SMB Security Signatures
> http://technet.microsoft.com/en-us/library/cc731957.aspx
>
> Other references:
>
> Microsoft network server: Digitally sign communications (always)
> http://technet.microsoft.com/en-us/library/cc786681(WS.10).aspx
>
> Server Message Block communication between a client-side SMB component
> and a server-side SMB component is not completed if the SMB signing
> settings are mismatched in Group Policy or in the registry:
> http://support.microsoft.com/kb/916846/en-us
>
> Overview of Server Message Block signing (older article)
> http://support.microsoft.com/kb/887429
>
> Ace
>
>
> On Tue, 01 Jun 2010 14:38:55 -0700, Vegas or Bust
> <tallguyinlv@hotmail.com>  wrote:
>
>> Hello,
>>
>> We're still fighting with this issue.  I have some network engineers
>> looking at the MTU settings, but I made a new discovery today.
>>
>> I have an account here that exhibited the problem (doesn't properly
>> authenticate to the domain, no login script, gets prompted every time
>> she tries to access any domain resources).  Every Windows XP computer
>> she logs into has the same problem.  I have a Windows 7 machine here and
>> she can login just fine -- she authenticates properly, login script runs
>> and she doesn't get re-prompted when accessing resources.
>>
>> Does this still point to a network issue, or is it possible that
>> something else is going on?
>>
>> On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>> That actually looks pretty good. I would suggest to change the
>>> 127.0.0.1 to 198.18.50.11.
>>>
>>> Also, I noticed these are public IPs. No biggy, but assumed you had a
>>> private IP network.
>>>
>>> As for forcing TCP, that's a red flag that UDP ports are being
>>> blocked, or going back to what Andrei said, i can definitely be an MTU
>>> issue on one of the MPLS routers or firewall.
>>>
>>> If the MTU is anything less than default, as PPPoE routers, and
>>> apparently what the MPLS in your case may be doing, is affecting the
>>> LDAP PDU size. I am trying to find an old article that explains thisr,
>>> but I can't find it, but the article Andrei posted explains a way
>>> around it.
>>>
>>> I would start digging into your MPLS configuration instead of altering
>>> your DCs. :-)
>>>
>>> Ace
>>>
>>>
>>>
>>> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
>>> <tallguyinlv@hotmail.com>   wrote:
>>>
>>>> Hi Ace,
>>>>
>>>> It seems that forcing Kerberos over TCP instead of using UDP fixes the
>>>> problem as per this article: http://support.microsoft.com/?kbid=244474
>>>>
>>>> However, once we make this change to a workstation it becomes very slow
>>>> when accessing network resources.  It takes 4+ minutes to login, then
>>>> there are very noticable delays when trying to access files, printers,
>>>> etc. over the network -- you click on something then it sits with an
>>>> hour glass for a while.
>>>>
>>>> Here are the results of ipconfig /all on the DC:
>>>>
>>>> Windows IP Configuration
>>>>
>>>>      Host Name . . . . . . . . . . . . : yyyy1WADC001
>>>>      Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>>>      Node Type . . . . . . . . . . . . : Hybrid
>>>>      IP Routing Enabled. . . . . . . . : No
>>>>      WINS Proxy Enabled. . . . . . . . : No
>>>>      DNS Suffix Search List. . . . . . : xxxx.LAN
>>>>
>>>> Ethernet adapter Front End:
>>>>
>>>>      Connection-specific DNS Suffix  . : xxxx.LAN
>>>>      Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
>>>>      Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>>>      DHCP Enabled. . . . . . . . . . . : No
>>>>      Autoconfiguration Enabled . . . . : Yes
>>>>      Link-local IPv6 Address . . . . . :
>>>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>>>      IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>>>      Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>>>      Default Gateway . . . . . . . . . : 198.18.50.254
>>>>      DHCPv6 IAID . . . . . . . . . . . : 218124374
>>>>      DHCPv6 Client DUID. . . . . . . . :
>>>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>>>
>>>>      DNS Servers . . . . . . . . . . . : ::1
>>>>                                          127.0.0.1
>>>>      NetBIOS over Tcpip. . . . . . . . : Enabled
>>>>
>>>>
>>>>
>>>>
>>>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>>>> <tallguyinlv@hotmail.com>    wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I seem to be having a strange problem with my Active Directory user
>>>>>> accounts.
>>>>>>
>>>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>>>> located at a remote data center.  All of our locations have connectivity
>>>>>> to the data center through a private MPLS network, with varying speeds.
>>>>>>
>>>>>> Users at my largest office seem to lose the ability to properly
>>>>>> authenticate to AD if they are added to too many security groups.  At
>>>>>> first we thought it was a specific group causing the problem, but any
>>>>>> new group will reproduce the issue.  There doesn't seem to be any magic
>>>>>> number of groups that causes the problem either.  Some users are already
>>>>>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>>>>>
>>>>>> When the problem occurs, users no longer seem to authenticate to the
>>>>>> domain.  They log onto their computer and do not run the login script.
>>>>>> Login also takes a lot longer -- it seems to sit and wait for a while
>>>>>> before completing.  Once the user is logged into their PC, they can't
>>>>>> access any networked resources.  If I try and map a network drive, I'll
>>>>>> get prompted for credentials.  Enter the credentials&    I can access the
>>>>>> resource.
>>>>>>
>>>>>> Anyone ever experienced anything like this or have any idea what might
>>>>>> be going on?
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> For starters, can you provide us with an ipconfig /all of the DC and
>>>>> of the client, please? This will allow us to evaluate any basic
>>>>> misconfigurations, if they exist.
>>>>>
>>>>> Thank you,
>>>>>
>>>>>
>>>>> Ace
>>>>>
>>>>> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
>>>>>
>>>>> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
>>>>>
>>>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&    Exchange 2007, MCSE&    MCSA 2003/2000, MCSA Messaging 2003
>>>>> Microsoft Certified Trainer
>>>>> Microsoft MVP - Directory Services
>>>>>
>>>>> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

Hi Vegas,

I wouldn't mess with the MTUs. Anything less than 1500 reduces the PDU
to less than 300kb which affects LDAP traffic. There's a KB on it, but
I don't have it saved in my notes.

If it's just one person, and then added that it's happening another
account only in Domain Users, indicates something else is surely going
on.

How many DCs are in the domain? If one domain, are all DCs GCs? Are
Sites configured? Errors in the event logs of the DCs or client?

Also, this may be a dumb question, but were the workstations imaged?
Just trying to see if there is a dupe SID issue occuring, which is an
effect of imaging without using Sysprep.

When creating the user account, was it copied, script created, or
manually created from scratch?

If I think of anything else, I'll post back.

Ace



On Wed, 02 Jun 2010 09:47:45 -0700, Vegas or Bust
<tallguyinlv@hotmail.com> wrote:

>I have a laptop here that's experiencing the problem.  I can do a domain 
>login using my own account & a couple others, but one specific account 
>(the lady who owns the laptop) can't login.  I deleted her AD account & 
>created a new one, but it still has the same issue.  If it were caused 
>by an SMB signing issue, I would think that nobody could login to this 
>machine.
>
>The problem originally seemed to manifest on accounts that were members 
>of some security groups.  If we reduced the number of groups, the 
>account would start working.  They didn't have a huge number of groups 
>-- maybe 4 or 5 -- without any nesting.  Now I'm seeing the problem on 
>this account which is only a member of Domain Users.  I had a couple 
>other problem accounts last week & was able to fix the issue by deleting 
>their AD account and creating a new one, but that didn't help for this 
>case.  The problem also doesn't seem to be location specific -- this 
>problem laptop exhibits the same issue in multiple offices.
>
>We tried reducing the MTU on our routers this morning to 1400.  My ping 
>testing showed that 1430 was the highest MTU setting that wouldn't 
>result in fragmentation.  As soon as the network engineers changed the 
>MTU from the default of 1500 to 1400, all domain traffic stopped and 
>they detected a ton of errors, so we restored the MTU to 1500.  I'm 
>thinking that maybe we should try setting the MTU to 1400 directly on 
>the DC and see if that makes a difference?  Otherwise I'm pretty much 
>stumped.
>
>Thanks again for any help or direction you can provide!!
>
>On 6/1/2010 9:37 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>> Hello Vegas,
>>
>> Still with the problem? I thought it was resolved since I haven't
>> heard back.
>>
>> If it is only happening with the XP machines, and not the Windows 7
>> machine, it maybe be an SMB signing issue on the DCs that need to be
>> reduced.
>>
>> For example, here's a short write-up for 2008 R2 and signing. It's on
>> by default. Win 7 follows this, but not older OS'.
>>
>> Require SMB Security Signatures
>> http://technet.microsoft.com/en-us/library/cc731957.aspx
>>
>> Other references:
>>
>> Microsoft network server: Digitally sign communications (always)
>> http://technet.microsoft.com/en-us/library/cc786681(WS.10).aspx
>>
>> Server Message Block communication between a client-side SMB component
>> and a server-side SMB component is not completed if the SMB signing
>> settings are mismatched in Group Policy or in the registry:
>> http://support.microsoft.com/kb/916846/en-us
>>
>> Overview of Server Message Block signing (older article)
>> http://support.microsoft.com/kb/887429
>>
>> Ace
>>
>>
>> On Tue, 01 Jun 2010 14:38:55 -0700, Vegas or Bust
>> <tallguyinlv@hotmail.com>  wrote:
>>
>>> Hello,
>>>
>>> We're still fighting with this issue.  I have some network engineers
>>> looking at the MTU settings, but I made a new discovery today.
>>>
>>> I have an account here that exhibited the problem (doesn't properly
>>> authenticate to the domain, no login script, gets prompted every time
>>> she tries to access any domain resources).  Every Windows XP computer
>>> she logs into has the same problem.  I have a Windows 7 machine here and
>>> she can login just fine -- she authenticates properly, login script runs
>>> and she doesn't get re-prompted when accessing resources.
>>>
>>> Does this still point to a network issue, or is it possible that
>>> something else is going on?
>>>
>>> On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>> That actually looks pretty good. I would suggest to change the
>>>> 127.0.0.1 to 198.18.50.11.
>>>>
>>>> Also, I noticed these are public IPs. No biggy, but assumed you had a
>>>> private IP network.
>>>>
>>>> As for forcing TCP, that's a red flag that UDP ports are being
>>>> blocked, or going back to what Andrei said, i can definitely be an MTU
>>>> issue on one of the MPLS routers or firewall.
>>>>
>>>> If the MTU is anything less than default, as PPPoE routers, and
>>>> apparently what the MPLS in your case may be doing, is affecting the
>>>> LDAP PDU size. I am trying to find an old article that explains thisr,
>>>> but I can't find it, but the article Andrei posted explains a way
>>>> around it.
>>>>
>>>> I would start digging into your MPLS configuration instead of altering
>>>> your DCs. :-)
>>>>
>>>> Ace
>>>>
>>>>
>>>>
>>>> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
>>>> <tallguyinlv@hotmail.com>   wrote:
>>>>
>>>>> Hi Ace,
>>>>>
>>>>> It seems that forcing Kerberos over TCP instead of using UDP fixes the
>>>>> problem as per this article: http://support.microsoft.com/?kbid=244474
>>>>>
>>>>> However, once we make this change to a workstation it becomes very slow
>>>>> when accessing network resources.  It takes 4+ minutes to login, then
>>>>> there are very noticable delays when trying to access files, printers,
>>>>> etc. over the network -- you click on something then it sits with an
>>>>> hour glass for a while.
>>>>>
>>>>> Here are the results of ipconfig /all on the DC:
>>>>>
>>>>> Windows IP Configuration
>>>>>
>>>>>      Host Name . . . . . . . . . . . . : yyyy1WADC001
>>>>>      Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>>>>      Node Type . . . . . . . . . . . . : Hybrid
>>>>>      IP Routing Enabled. . . . . . . . : No
>>>>>      WINS Proxy Enabled. . . . . . . . : No
>>>>>      DNS Suffix Search List. . . . . . : xxxx.LAN
>>>>>
>>>>> Ethernet adapter Front End:
>>>>>
>>>>>      Connection-specific DNS Suffix  . : xxxx.LAN
>>>>>      Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
>>>>>      Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>>>>      DHCP Enabled. . . . . . . . . . . : No
>>>>>      Autoconfiguration Enabled . . . . : Yes
>>>>>      Link-local IPv6 Address . . . . . :
>>>>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>>>>      IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>>>>      Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>>>>      Default Gateway . . . . . . . . . : 198.18.50.254
>>>>>      DHCPv6 IAID . . . . . . . . . . . : 218124374
>>>>>      DHCPv6 Client DUID. . . . . . . . :
>>>>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>>>>
>>>>>      DNS Servers . . . . . . . . . . . : ::1
>>>>>                                          127.0.0.1
>>>>>      NetBIOS over Tcpip. . . . . . . . : Enabled
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>>>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>>>>> <tallguyinlv@hotmail.com>    wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I seem to be having a strange problem with my Active Directory user
>>>>>>> accounts.
>>>>>>>
>>>>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>>>>> located at a remote data center.  All of our locations have connectivity
>>>>>>> to the data center through a private MPLS network, with varying speeds.
>>>>>>>
>>>>>>> Users at my largest office seem to lose the ability to properly
>>>>>>> authenticate to AD if they are added to too many security groups.  At
>>>>>>> first we thought it was a specific group causing the problem, but any
>>>>>>> new group will reproduce the issue.  There doesn't seem to be any magic
>>>>>>> number of groups that causes the problem either.  Some users are already
>>>>>>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>>>>>>
>>>>>>> When the problem occurs, users no longer seem to authenticate to the
>>>>>>> domain.  They log onto their computer and do not run the login script.
>>>>>>> Login also takes a lot longer -- it seems to sit and wait for a while
>>>>>>> before completing.  Once the user is logged into their PC, they can't
>>>>>>> access any networked resources.  If I try and map a network drive, I'll
>>>>>>> get prompted for credentials.  Enter the credentials&    I can access the
>>>>>>> resource.
>>>>>>>
>>>>>>> Anyone ever experienced anything like this or have any idea what might
>>>>>>> be going on?
>>>>>>>
>>>>>>> Thanks!
>>>>>>
>>>>>> For starters, can you provide us with an ipconfig /all of the DC and
>>>>>> of the client, please? This will allow us to evaluate any basic
>>>>>> misconfigurations, if they exist.
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>>
>>>>>> Ace
>>>>>>
>>>>>> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
>>>>>>
>>>>>> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
>>>>>>
>>>>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&    Exchange 2007, MCSE&    MCSA 2003/2000, MCSA Messaging 2003
>>>>>> Microsoft Certified Trainer
>>>>>> Microsoft MVP - Directory Services
>>>>>>
>>>>>> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

Hi Ace,

It looks like we finally solved this mystery!  We added these two 
registry entries to our workstations and (knock on wood) so far they can 
all login and authenticate properly:

1.
Registry subkey: 
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
Value name: GroupPolicyMinTransferRate
Value type: DWORD
Value Data: 0
This stops Windows XP from trying to determine if the Link is slow.


2.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
Note If the Parameters key does not exist, create it now.
On the Edit menu, point to New, and then click DWORD Value.
Type MaxPacketSize, and then press ENTER.
Double-click MaxPacketSize, type 1 in the Value data box, click to 
select the Decimal option, and then click OK. Quit Registry Editor.
This regkey changes the way Kerberos authenticates from UPD to TCP

We had previously tried entry #2 (force Kerberos to TCP) and found that 
it resolve the problem,  but made everything extremely slow.  It would 
take 15+ minutes to login and there was a 1-2 minute delay each time we 
tried to access resources.  Adding the other GroupPolicyMinTransferRate 
key seems to prevent the performance issue -- everything is now blazing 
fast.

Thanks again for all your help!

On 6/5/2010 10:46 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
> Hi Vegas,
>
> I wouldn't mess with the MTUs. Anything less than 1500 reduces the PDU
> to less than 300kb which affects LDAP traffic. There's a KB on it, but
> I don't have it saved in my notes.
>
> If it's just one person, and then added that it's happening another
> account only in Domain Users, indicates something else is surely going
> on.
>
> How many DCs are in the domain? If one domain, are all DCs GCs? Are
> Sites configured? Errors in the event logs of the DCs or client?
>
> Also, this may be a dumb question, but were the workstations imaged?
> Just trying to see if there is a dupe SID issue occuring, which is an
> effect of imaging without using Sysprep.
>
> When creating the user account, was it copied, script created, or
> manually created from scratch?
>
> If I think of anything else, I'll post back.
>
> Ace
>
>
>
> On Wed, 02 Jun 2010 09:47:45 -0700, Vegas or Bust
> <tallguyinlv@hotmail.com>  wrote:
>
>> I have a laptop here that's experiencing the problem.  I can do a domain
>> login using my own account&  a couple others, but one specific account
>> (the lady who owns the laptop) can't login.  I deleted her AD account&
>> created a new one, but it still has the same issue.  If it were caused
>> by an SMB signing issue, I would think that nobody could login to this
>> machine.
>>
>> The problem originally seemed to manifest on accounts that were members
>> of some security groups.  If we reduced the number of groups, the
>> account would start working.  They didn't have a huge number of groups
>> -- maybe 4 or 5 -- without any nesting.  Now I'm seeing the problem on
>> this account which is only a member of Domain Users.  I had a couple
>> other problem accounts last week&  was able to fix the issue by deleting
>> their AD account and creating a new one, but that didn't help for this
>> case.  The problem also doesn't seem to be location specific -- this
>> problem laptop exhibits the same issue in multiple offices.
>>
>> We tried reducing the MTU on our routers this morning to 1400.  My ping
>> testing showed that 1430 was the highest MTU setting that wouldn't
>> result in fragmentation.  As soon as the network engineers changed the
>> MTU from the default of 1500 to 1400, all domain traffic stopped and
>> they detected a ton of errors, so we restored the MTU to 1500.  I'm
>> thinking that maybe we should try setting the MTU to 1400 directly on
>> the DC and see if that makes a difference?  Otherwise I'm pretty much
>> stumped.
>>
>> Thanks again for any help or direction you can provide!!
>>
>> On 6/1/2010 9:37 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>> Hello Vegas,
>>>
>>> Still with the problem? I thought it was resolved since I haven't
>>> heard back.
>>>
>>> If it is only happening with the XP machines, and not the Windows 7
>>> machine, it maybe be an SMB signing issue on the DCs that need to be
>>> reduced.
>>>
>>> For example, here's a short write-up for 2008 R2 and signing. It's on
>>> by default. Win 7 follows this, but not older OS'.
>>>
>>> Require SMB Security Signatures
>>> http://technet.microsoft.com/en-us/library/cc731957.aspx
>>>
>>> Other references:
>>>
>>> Microsoft network server: Digitally sign communications (always)
>>> http://technet.microsoft.com/en-us/library/cc786681(WS.10).aspx
>>>
>>> Server Message Block communication between a client-side SMB component
>>> and a server-side SMB component is not completed if the SMB signing
>>> settings are mismatched in Group Policy or in the registry:
>>> http://support.microsoft.com/kb/916846/en-us
>>>
>>> Overview of Server Message Block signing (older article)
>>> http://support.microsoft.com/kb/887429
>>>
>>> Ace
>>>
>>>
>>> On Tue, 01 Jun 2010 14:38:55 -0700, Vegas or Bust
>>> <tallguyinlv@hotmail.com>   wrote:
>>>
>>>> Hello,
>>>>
>>>> We're still fighting with this issue.  I have some network engineers
>>>> looking at the MTU settings, but I made a new discovery today.
>>>>
>>>> I have an account here that exhibited the problem (doesn't properly
>>>> authenticate to the domain, no login script, gets prompted every time
>>>> she tries to access any domain resources).  Every Windows XP computer
>>>> she logs into has the same problem.  I have a Windows 7 machine here and
>>>> she can login just fine -- she authenticates properly, login script runs
>>>> and she doesn't get re-prompted when accessing resources.
>>>>
>>>> Does this still point to a network issue, or is it possible that
>>>> something else is going on?
>>>>
>>>> On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>>> That actually looks pretty good. I would suggest to change the
>>>>> 127.0.0.1 to 198.18.50.11.
>>>>>
>>>>> Also, I noticed these are public IPs. No biggy, but assumed you had a
>>>>> private IP network.
>>>>>
>>>>> As for forcing TCP, that's a red flag that UDP ports are being
>>>>> blocked, or going back to what Andrei said, i can definitely be an MTU
>>>>> issue on one of the MPLS routers or firewall.
>>>>>
>>>>> If the MTU is anything less than default, as PPPoE routers, and
>>>>> apparently what the MPLS in your case may be doing, is affecting the
>>>>> LDAP PDU size. I am trying to find an old article that explains thisr,
>>>>> but I can't find it, but the article Andrei posted explains a way
>>>>> around it.
>>>>>
>>>>> I would start digging into your MPLS configuration instead of altering
>>>>> your DCs. :-)
>>>>>
>>>>> Ace
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
>>>>> <tallguyinlv@hotmail.com>    wrote:
>>>>>
>>>>>> Hi Ace,
>>>>>>
>>>>>> It seems that forcing Kerberos over TCP instead of using UDP fixes the
>>>>>> problem as per this article: http://support.microsoft.com/?kbid=244474
>>>>>>
>>>>>> However, once we make this change to a workstation it becomes very slow
>>>>>> when accessing network resources.  It takes 4+ minutes to login, then
>>>>>> there are very noticable delays when trying to access files, printers,
>>>>>> etc. over the network -- you click on something then it sits with an
>>>>>> hour glass for a while.
>>>>>>
>>>>>> Here are the results of ipconfig /all on the DC:
>>>>>>
>>>>>> Windows IP Configuration
>>>>>>
>>>>>>       Host Name . . . . . . . . . . . . : yyyy1WADC001
>>>>>>       Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>>>>>       Node Type . . . . . . . . . . . . : Hybrid
>>>>>>       IP Routing Enabled. . . . . . . . : No
>>>>>>       WINS Proxy Enabled. . . . . . . . : No
>>>>>>       DNS Suffix Search List. . . . . . : xxxx.LAN
>>>>>>
>>>>>> Ethernet adapter Front End:
>>>>>>
>>>>>>       Connection-specific DNS Suffix  . : xxxx.LAN
>>>>>>       Description . . . . . . . . . . . : VMware PCI Ethernet Adapter
>>>>>>       Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>>>>>       DHCP Enabled. . . . . . . . . . . : No
>>>>>>       Autoconfiguration Enabled . . . . : Yes
>>>>>>       Link-local IPv6 Address . . . . . :
>>>>>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>>>>>       IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>>>>>       Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>>>>>       Default Gateway . . . . . . . . . : 198.18.50.254
>>>>>>       DHCPv6 IAID . . . . . . . . . . . : 218124374
>>>>>>       DHCPv6 Client DUID. . . . . . . . :
>>>>>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>>>>>
>>>>>>       DNS Servers . . . . . . . . . . . : ::1
>>>>>>                                           127.0.0.1
>>>>>>       NetBIOS over Tcpip. . . . . . . . : Enabled
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>>>>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>>>>>> <tallguyinlv@hotmail.com>     wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I seem to be having a strange problem with my Active Directory user
>>>>>>>> accounts.
>>>>>>>>
>>>>>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>>>>>> located at a remote data center.  All of our locations have connectivity
>>>>>>>> to the data center through a private MPLS network, with varying speeds.
>>>>>>>>
>>>>>>>> Users at my largest office seem to lose the ability to properly
>>>>>>>> authenticate to AD if they are added to too many security groups.  At
>>>>>>>> first we thought it was a specific group causing the problem, but any
>>>>>>>> new group will reproduce the issue.  There doesn't seem to be any magic
>>>>>>>> number of groups that causes the problem either.  Some users are already
>>>>>>>> members of 3-4 security groups, add a 5th one and authentication breaks.
>>>>>>>>
>>>>>>>> When the problem occurs, users no longer seem to authenticate to the
>>>>>>>> domain.  They log onto their computer and do not run the login script.
>>>>>>>> Login also takes a lot longer -- it seems to sit and wait for a while
>>>>>>>> before completing.  Once the user is logged into their PC, they can't
>>>>>>>> access any networked resources.  If I try and map a network drive, I'll
>>>>>>>> get prompted for credentials.  Enter the credentials&     I can access the
>>>>>>>> resource.
>>>>>>>>
>>>>>>>> Anyone ever experienced anything like this or have any idea what might
>>>>>>>> be going on?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>
>>>>>>> For starters, can you provide us with an ipconfig /all of the DC and
>>>>>>> of the client, please? This will allow us to evaluate any basic
>>>>>>> misconfigurations, if they exist.
>>>>>>>
>>>>>>> Thank you,
>>>>>>>
>>>>>>>
>>>>>>> Ace
>>>>>>>
>>>>>>> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
>>>>>>>
>>>>>>> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
>>>>>>>
>>>>>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&     Exchange 2007, MCSE&     MCSA 2003/2000, MCSA Messaging 2003
>>>>>>> Microsoft Certified Trainer
>>>>>>> Microsoft MVP - Directory Services
>>>>>>>
>>>>>>> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

Still sounds like a MTU issue for me. I am thinking of this based on the 
fact that changing the Kerberos to work on TCP fixed your issue. Changing 
the MTU on the network equipment was a bad idea. You should have lowered the 
MTU on the workstation, not on the routers.
Give it a try on a XP workstation.

Regards,
Andrei Ungureanu
www.winadmins.net

"Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message 
news:#K9JzW1BLHA.4388@TK2MSFTNGP04.phx.gbl...
> Hi Ace,
>
> It looks like we finally solved this mystery!  We added these two registry 
> entries to our workstations and (knock on wood) so far they can all login 
> and authenticate properly:
>
> 1.
> Registry subkey: 
> HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
> Value name: GroupPolicyMinTransferRate
> Value type: DWORD
> Value Data: 0
> This stops Windows XP from trying to determine if the Link is slow.
>
>
> 2.
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ 
> Kerberos\Parameters
> Note If the Parameters key does not exist, create it now.
> On the Edit menu, point to New, and then click DWORD Value.
> Type MaxPacketSize, and then press ENTER.
> Double-click MaxPacketSize, type 1 in the Value data box, click to select 
> the Decimal option, and then click OK. Quit Registry Editor.
> This regkey changes the way Kerberos authenticates from UPD to TCP
>
> We had previously tried entry #2 (force Kerberos to TCP) and found that it 
> resolve the problem,  but made everything extremely slow.  It would take 
> 15+ minutes to login and there was a 1-2 minute delay each time we tried 
> to access resources.  Adding the other GroupPolicyMinTransferRate key 
> seems to prevent the performance issue -- everything is now blazing fast.
>
> Thanks again for all your help!
>
> On 6/5/2010 10:46 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>> Hi Vegas,
>>
>> I wouldn't mess with the MTUs. Anything less than 1500 reduces the PDU
>> to less than 300kb which affects LDAP traffic. There's a KB on it, but
>> I don't have it saved in my notes.
>>
>> If it's just one person, and then added that it's happening another
>> account only in Domain Users, indicates something else is surely going
>> on.
>>
>> How many DCs are in the domain? If one domain, are all DCs GCs? Are
>> Sites configured? Errors in the event logs of the DCs or client?
>>
>> Also, this may be a dumb question, but were the workstations imaged?
>> Just trying to see if there is a dupe SID issue occuring, which is an
>> effect of imaging without using Sysprep.
>>
>> When creating the user account, was it copied, script created, or
>> manually created from scratch?
>>
>> If I think of anything else, I'll post back.
>>
>> Ace
>>
>>
>>
>> On Wed, 02 Jun 2010 09:47:45 -0700, Vegas or Bust
>> <tallguyinlv@hotmail.com>  wrote:
>>
>>> I have a laptop here that's experiencing the problem.  I can do a domain
>>> login using my own account&  a couple others, but one specific account
>>> (the lady who owns the laptop) can't login.  I deleted her AD account&
>>> created a new one, but it still has the same issue.  If it were caused
>>> by an SMB signing issue, I would think that nobody could login to this
>>> machine.
>>>
>>> The problem originally seemed to manifest on accounts that were members
>>> of some security groups.  If we reduced the number of groups, the
>>> account would start working.  They didn't have a huge number of groups
>>> -- maybe 4 or 5 -- without any nesting.  Now I'm seeing the problem on
>>> this account which is only a member of Domain Users.  I had a couple
>>> other problem accounts last week&  was able to fix the issue by deleting
>>> their AD account and creating a new one, but that didn't help for this
>>> case.  The problem also doesn't seem to be location specific -- this
>>> problem laptop exhibits the same issue in multiple offices.
>>>
>>> We tried reducing the MTU on our routers this morning to 1400.  My ping
>>> testing showed that 1430 was the highest MTU setting that wouldn't
>>> result in fragmentation.  As soon as the network engineers changed the
>>> MTU from the default of 1500 to 1400, all domain traffic stopped and
>>> they detected a ton of errors, so we restored the MTU to 1500.  I'm
>>> thinking that maybe we should try setting the MTU to 1400 directly on
>>> the DC and see if that makes a difference?  Otherwise I'm pretty much
>>> stumped.
>>>
>>> Thanks again for any help or direction you can provide!!
>>>
>>> On 6/1/2010 9:37 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>> Hello Vegas,
>>>>
>>>> Still with the problem? I thought it was resolved since I haven't
>>>> heard back.
>>>>
>>>> If it is only happening with the XP machines, and not the Windows 7
>>>> machine, it maybe be an SMB signing issue on the DCs that need to be
>>>> reduced.
>>>>
>>>> For example, here's a short write-up for 2008 R2 and signing. It's on
>>>> by default. Win 7 follows this, but not older OS'.
>>>>
>>>> Require SMB Security Signatures
>>>> http://technet.microsoft.com/en-us/library/cc731957.aspx
>>>>
>>>> Other references:
>>>>
>>>> Microsoft network server: Digitally sign communications (always)
>>>> http://technet.microsoft.com/en-us/library/cc786681(WS.10).aspx
>>>>
>>>> Server Message Block communication between a client-side SMB component
>>>> and a server-side SMB component is not completed if the SMB signing
>>>> settings are mismatched in Group Policy or in the registry:
>>>> http://support.microsoft.com/kb/916846/en-us
>>>>
>>>> Overview of Server Message Block signing (older article)
>>>> http://support.microsoft.com/kb/887429
>>>>
>>>> Ace
>>>>
>>>>
>>>> On Tue, 01 Jun 2010 14:38:55 -0700, Vegas or Bust
>>>> <tallguyinlv@hotmail.com>   wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> We're still fighting with this issue.  I have some network engineers
>>>>> looking at the MTU settings, but I made a new discovery today.
>>>>>
>>>>> I have an account here that exhibited the problem (doesn't properly
>>>>> authenticate to the domain, no login script, gets prompted every time
>>>>> she tries to access any domain resources).  Every Windows XP computer
>>>>> she logs into has the same problem.  I have a Windows 7 machine here 
>>>>> and
>>>>> she can login just fine -- she authenticates properly, login script 
>>>>> runs
>>>>> and she doesn't get re-prompted when accessing resources.
>>>>>
>>>>> Does this still point to a network issue, or is it possible that
>>>>> something else is going on?
>>>>>
>>>>> On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>>>> That actually looks pretty good. I would suggest to change the
>>>>>> 127.0.0.1 to 198.18.50.11.
>>>>>>
>>>>>> Also, I noticed these are public IPs. No biggy, but assumed you had a
>>>>>> private IP network.
>>>>>>
>>>>>> As for forcing TCP, that's a red flag that UDP ports are being
>>>>>> blocked, or going back to what Andrei said, i can definitely be an 
>>>>>> MTU
>>>>>> issue on one of the MPLS routers or firewall.
>>>>>>
>>>>>> If the MTU is anything less than default, as PPPoE routers, and
>>>>>> apparently what the MPLS in your case may be doing, is affecting the
>>>>>> LDAP PDU size. I am trying to find an old article that explains 
>>>>>> thisr,
>>>>>> but I can't find it, but the article Andrei posted explains a way
>>>>>> around it.
>>>>>>
>>>>>> I would start digging into your MPLS configuration instead of 
>>>>>> altering
>>>>>> your DCs. :-)
>>>>>>
>>>>>> Ace
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
>>>>>> <tallguyinlv@hotmail.com>    wrote:
>>>>>>
>>>>>>> Hi Ace,
>>>>>>>
>>>>>>> It seems that forcing Kerberos over TCP instead of using UDP fixes 
>>>>>>> the
>>>>>>> problem as per this article: 
>>>>>>> http://support.microsoft.com/?kbid=244474
>>>>>>>
>>>>>>> However, once we make this change to a workstation it becomes very 
>>>>>>> slow
>>>>>>> when accessing network resources.  It takes 4+ minutes to login, 
>>>>>>> then
>>>>>>> there are very noticable delays when trying to access files, 
>>>>>>> printers,
>>>>>>> etc. over the network -- you click on something then it sits with an
>>>>>>> hour glass for a while.
>>>>>>>
>>>>>>> Here are the results of ipconfig /all on the DC:
>>>>>>>
>>>>>>> Windows IP Configuration
>>>>>>>
>>>>>>>       Host Name . . . . . . . . . . . . : yyyy1WADC001
>>>>>>>       Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>>>>>>       Node Type . . . . . . . . . . . . : Hybrid
>>>>>>>       IP Routing Enabled. . . . . . . . : No
>>>>>>>       WINS Proxy Enabled. . . . . . . . : No
>>>>>>>       DNS Suffix Search List. . . . . . : xxxx.LAN
>>>>>>>
>>>>>>> Ethernet adapter Front End:
>>>>>>>
>>>>>>>       Connection-specific DNS Suffix  . : xxxx.LAN
>>>>>>>       Description . . . . . . . . . . . : VMware PCI Ethernet 
>>>>>>> Adapter
>>>>>>>       Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>>>>>>       DHCP Enabled. . . . . . . . . . . : No
>>>>>>>       Autoconfiguration Enabled . . . . : Yes
>>>>>>>       Link-local IPv6 Address . . . . . :
>>>>>>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>>>>>>       IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>>>>>>       Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>>>>>>       Default Gateway . . . . . . . . . : 198.18.50.254
>>>>>>>       DHCPv6 IAID . . . . . . . . . . . : 218124374
>>>>>>>       DHCPv6 Client DUID. . . . . . . . :
>>>>>>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>>>>>>
>>>>>>>       DNS Servers . . . . . . . . . . . : ::1
>>>>>>>                                           127.0.0.1
>>>>>>>       NetBIOS over Tcpip. . . . . . . . : Enabled
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>>>>>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>>>>>>> <tallguyinlv@hotmail.com>     wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I seem to be having a strange problem with my Active Directory 
>>>>>>>>> user
>>>>>>>>> accounts.
>>>>>>>>>
>>>>>>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>>>>>>> located at a remote data center.  All of our locations have 
>>>>>>>>> connectivity
>>>>>>>>> to the data center through a private MPLS network, with varying 
>>>>>>>>> speeds.
>>>>>>>>>
>>>>>>>>> Users at my largest office seem to lose the ability to properly
>>>>>>>>> authenticate to AD if they are added to too many security groups. 
>>>>>>>>> At
>>>>>>>>> first we thought it was a specific group causing the problem, but 
>>>>>>>>> any
>>>>>>>>> new group will reproduce the issue.  There doesn't seem to be any 
>>>>>>>>> magic
>>>>>>>>> number of groups that causes the problem either.  Some users are 
>>>>>>>>> already
>>>>>>>>> members of 3-4 security groups, add a 5th one and authentication 
>>>>>>>>> breaks.
>>>>>>>>>
>>>>>>>>> When the problem occurs, users no longer seem to authenticate to 
>>>>>>>>> the
>>>>>>>>> domain.  They log onto their computer and do not run the login 
>>>>>>>>> script.
>>>>>>>>> Login also takes a lot longer -- it seems to sit and wait for a 
>>>>>>>>> while
>>>>>>>>> before completing.  Once the user is logged into their PC, they 
>>>>>>>>> can't
>>>>>>>>> access any networked resources.  If I try and map a network drive, 
>>>>>>>>> I'll
>>>>>>>>> get prompted for credentials.  Enter the credentials&     I can 
>>>>>>>>> access the
>>>>>>>>> resource.
>>>>>>>>>
>>>>>>>>> Anyone ever experienced anything like this or have any idea what 
>>>>>>>>> might
>>>>>>>>> be going on?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> For starters, can you provide us with an ipconfig /all of the DC 
>>>>>>>> and
>>>>>>>> of the client, please? This will allow us to evaluate any basic
>>>>>>>> misconfigurations, if they exist.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>>
>>>>>>>>
>>>>>>>> Ace
>>>>>>>>
>>>>>>>> This posting is provided "AS-IS" with no warranties or guarantees 
>>>>>>>> and confers no rights.
>>>>>>>>
>>>>>>>> Please reply back to the newsgroup or forum for collaboration 
>>>>>>>> benefit among responding engineers, and to help others benefit from 
>>>>>>>> your resolution.
>>>>>>>>
>>>>>>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&     Exchange 
>>>>>>>> 2007, MCSE&     MCSA 2003/2000, MCSA Messaging 2003
>>>>>>>> Microsoft Certified Trainer
>>>>>>>> Microsoft MVP - Directory Services
>>>>>>>>
>>>>>>>> If you feel this is an urgent issue and require immediate 
>>>>>>>> assistance, please contact Microsoft PSS directly. Please check 
>>>>>>>> http://support.microsoft.com for regional support phone numbers.
> 

I agree. I'm not sure why ther MTU settings were even considered,
especially the sensitivity of the LDAP PDU settings if the MTU is
changed.

Either way, I'm glad it was resolved, albeit having to make registry
setting changes on workstations to make it work.

Ace


On Wed, 9 Jun 2010 10:48:54 +0300, "Andrei Ungureanu"
<someone@mydomain.com> wrote:

>Still sounds like a MTU issue for me. I am thinking of this based on the 
>fact that changing the Kerberos to work on TCP fixed your issue. Changing 
>the MTU on the network equipment was a bad idea. You should have lowered the 
>MTU on the workstation, not on the routers.
>Give it a try on a XP workstation.
>
>Regards,
>Andrei Ungureanu
>www.winadmins.net
>
>"Vegas or Bust" <tallguyinlv@hotmail.com> wrote in message 
>news:#K9JzW1BLHA.4388@TK2MSFTNGP04.phx.gbl...
>> Hi Ace,
>>
>> It looks like we finally solved this mystery!  We added these two registry 
>> entries to our workstations and (knock on wood) so far they can all login 
>> and authenticate properly:
>>
>> 1.
>> Registry subkey: 
>> HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
>> Value name: GroupPolicyMinTransferRate
>> Value type: DWORD
>> Value Data: 0
>> This stops Windows XP from trying to determine if the Link is slow.
>>
>>
>> 2.
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ 
>> Kerberos\Parameters
>> Note If the Parameters key does not exist, create it now.
>> On the Edit menu, point to New, and then click DWORD Value.
>> Type MaxPacketSize, and then press ENTER.
>> Double-click MaxPacketSize, type 1 in the Value data box, click to select 
>> the Decimal option, and then click OK. Quit Registry Editor.
>> This regkey changes the way Kerberos authenticates from UPD to TCP
>>
>> We had previously tried entry #2 (force Kerberos to TCP) and found that it 
>> resolve the problem,  but made everything extremely slow.  It would take 
>> 15+ minutes to login and there was a 1-2 minute delay each time we tried 
>> to access resources.  Adding the other GroupPolicyMinTransferRate key 
>> seems to prevent the performance issue -- everything is now blazing fast.
>>
>> Thanks again for all your help!
>>
>> On 6/5/2010 10:46 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>> Hi Vegas,
>>>
>>> I wouldn't mess with the MTUs. Anything less than 1500 reduces the PDU
>>> to less than 300kb which affects LDAP traffic. There's a KB on it, but
>>> I don't have it saved in my notes.
>>>
>>> If it's just one person, and then added that it's happening another
>>> account only in Domain Users, indicates something else is surely going
>>> on.
>>>
>>> How many DCs are in the domain? If one domain, are all DCs GCs? Are
>>> Sites configured? Errors in the event logs of the DCs or client?
>>>
>>> Also, this may be a dumb question, but were the workstations imaged?
>>> Just trying to see if there is a dupe SID issue occuring, which is an
>>> effect of imaging without using Sysprep.
>>>
>>> When creating the user account, was it copied, script created, or
>>> manually created from scratch?
>>>
>>> If I think of anything else, I'll post back.
>>>
>>> Ace
>>>
>>>
>>>
>>> On Wed, 02 Jun 2010 09:47:45 -0700, Vegas or Bust
>>> <tallguyinlv@hotmail.com>  wrote:
>>>
>>>> I have a laptop here that's experiencing the problem.  I can do a domain
>>>> login using my own account&  a couple others, but one specific account
>>>> (the lady who owns the laptop) can't login.  I deleted her AD account&
>>>> created a new one, but it still has the same issue.  If it were caused
>>>> by an SMB signing issue, I would think that nobody could login to this
>>>> machine.
>>>>
>>>> The problem originally seemed to manifest on accounts that were members
>>>> of some security groups.  If we reduced the number of groups, the
>>>> account would start working.  They didn't have a huge number of groups
>>>> -- maybe 4 or 5 -- without any nesting.  Now I'm seeing the problem on
>>>> this account which is only a member of Domain Users.  I had a couple
>>>> other problem accounts last week&  was able to fix the issue by deleting
>>>> their AD account and creating a new one, but that didn't help for this
>>>> case.  The problem also doesn't seem to be location specific -- this
>>>> problem laptop exhibits the same issue in multiple offices.
>>>>
>>>> We tried reducing the MTU on our routers this morning to 1400.  My ping
>>>> testing showed that 1430 was the highest MTU setting that wouldn't
>>>> result in fragmentation.  As soon as the network engineers changed the
>>>> MTU from the default of 1500 to 1400, all domain traffic stopped and
>>>> they detected a ton of errors, so we restored the MTU to 1500.  I'm
>>>> thinking that maybe we should try setting the MTU to 1400 directly on
>>>> the DC and see if that makes a difference?  Otherwise I'm pretty much
>>>> stumped.
>>>>
>>>> Thanks again for any help or direction you can provide!!
>>>>
>>>> On 6/1/2010 9:37 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>>> Hello Vegas,
>>>>>
>>>>> Still with the problem? I thought it was resolved since I haven't
>>>>> heard back.
>>>>>
>>>>> If it is only happening with the XP machines, and not the Windows 7
>>>>> machine, it maybe be an SMB signing issue on the DCs that need to be
>>>>> reduced.
>>>>>
>>>>> For example, here's a short write-up for 2008 R2 and signing. It's on
>>>>> by default. Win 7 follows this, but not older OS'.
>>>>>
>>>>> Require SMB Security Signatures
>>>>> http://technet.microsoft.com/en-us/library/cc731957.aspx
>>>>>
>>>>> Other references:
>>>>>
>>>>> Microsoft network server: Digitally sign communications (always)
>>>>> http://technet.microsoft.com/en-us/library/cc786681(WS.10).aspx
>>>>>
>>>>> Server Message Block communication between a client-side SMB component
>>>>> and a server-side SMB component is not completed if the SMB signing
>>>>> settings are mismatched in Group Policy or in the registry:
>>>>> http://support.microsoft.com/kb/916846/en-us
>>>>>
>>>>> Overview of Server Message Block signing (older article)
>>>>> http://support.microsoft.com/kb/887429
>>>>>
>>>>> Ace
>>>>>
>>>>>
>>>>> On Tue, 01 Jun 2010 14:38:55 -0700, Vegas or Bust
>>>>> <tallguyinlv@hotmail.com>   wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> We're still fighting with this issue.  I have some network engineers
>>>>>> looking at the MTU settings, but I made a new discovery today.
>>>>>>
>>>>>> I have an account here that exhibited the problem (doesn't properly
>>>>>> authenticate to the domain, no login script, gets prompted every time
>>>>>> she tries to access any domain resources).  Every Windows XP computer
>>>>>> she logs into has the same problem.  I have a Windows 7 machine here 
>>>>>> and
>>>>>> she can login just fine -- she authenticates properly, login script 
>>>>>> runs
>>>>>> and she doesn't get re-prompted when accessing resources.
>>>>>>
>>>>>> Does this still point to a network issue, or is it possible that
>>>>>> something else is going on?
>>>>>>
>>>>>> On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>>>>> That actually looks pretty good. I would suggest to change the
>>>>>>> 127.0.0.1 to 198.18.50.11.
>>>>>>>
>>>>>>> Also, I noticed these are public IPs. No biggy, but assumed you had a
>>>>>>> private IP network.
>>>>>>>
>>>>>>> As for forcing TCP, that's a red flag that UDP ports are being
>>>>>>> blocked, or going back to what Andrei said, i can definitely be an 
>>>>>>> MTU
>>>>>>> issue on one of the MPLS routers or firewall.
>>>>>>>
>>>>>>> If the MTU is anything less than default, as PPPoE routers, and
>>>>>>> apparently what the MPLS in your case may be doing, is affecting the
>>>>>>> LDAP PDU size. I am trying to find an old article that explains 
>>>>>>> thisr,
>>>>>>> but I can't find it, but the article Andrei posted explains a way
>>>>>>> around it.
>>>>>>>
>>>>>>> I would start digging into your MPLS configuration instead of 
>>>>>>> altering
>>>>>>> your DCs. :-)
>>>>>>>
>>>>>>> Ace
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
>>>>>>> <tallguyinlv@hotmail.com>    wrote:
>>>>>>>
>>>>>>>> Hi Ace,
>>>>>>>>
>>>>>>>> It seems that forcing Kerberos over TCP instead of using UDP fixes 
>>>>>>>> the
>>>>>>>> problem as per this article: 
>>>>>>>> http://support.microsoft.com/?kbid=244474
>>>>>>>>
>>>>>>>> However, once we make this change to a workstation it becomes very 
>>>>>>>> slow
>>>>>>>> when accessing network resources.  It takes 4+ minutes to login, 
>>>>>>>> then
>>>>>>>> there are very noticable delays when trying to access files, 
>>>>>>>> printers,
>>>>>>>> etc. over the network -- you click on something then it sits with an
>>>>>>>> hour glass for a while.
>>>>>>>>
>>>>>>>> Here are the results of ipconfig /all on the DC:
>>>>>>>>
>>>>>>>> Windows IP Configuration
>>>>>>>>
>>>>>>>>       Host Name . . . . . . . . . . . . : yyyy1WADC001
>>>>>>>>       Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>>>>>>>       Node Type . . . . . . . . . . . . : Hybrid
>>>>>>>>       IP Routing Enabled. . . . . . . . : No
>>>>>>>>       WINS Proxy Enabled. . . . . . . . : No
>>>>>>>>       DNS Suffix Search List. . . . . . : xxxx.LAN
>>>>>>>>
>>>>>>>> Ethernet adapter Front End:
>>>>>>>>
>>>>>>>>       Connection-specific DNS Suffix  . : xxxx.LAN
>>>>>>>>       Description . . . . . . . . . . . : VMware PCI Ethernet 
>>>>>>>> Adapter
>>>>>>>>       Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>>>>>>>       DHCP Enabled. . . . . . . . . . . : No
>>>>>>>>       Autoconfiguration Enabled . . . . : Yes
>>>>>>>>       Link-local IPv6 Address . . . . . :
>>>>>>>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>>>>>>>       IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>>>>>>>       Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>>>>>>>       Default Gateway . . . . . . . . . : 198.18.50.254
>>>>>>>>       DHCPv6 IAID . . . . . . . . . . . : 218124374
>>>>>>>>       DHCPv6 Client DUID. . . . . . . . :
>>>>>>>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>>>>>>>
>>>>>>>>       DNS Servers . . . . . . . . . . . : ::1
>>>>>>>>                                           127.0.0.1
>>>>>>>>       NetBIOS over Tcpip. . . . . . . . : Enabled
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>>>>>>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>>>>>>>> <tallguyinlv@hotmail.com>     wrote:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I seem to be having a strange problem with my Active Directory 
>>>>>>>>>> user
>>>>>>>>>> accounts.
>>>>>>>>>>
>>>>>>>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>>>>>>>> located at a remote data center.  All of our locations have 
>>>>>>>>>> connectivity
>>>>>>>>>> to the data center through a private MPLS network, with varying 
>>>>>>>>>> speeds.
>>>>>>>>>>
>>>>>>>>>> Users at my largest office seem to lose the ability to properly
>>>>>>>>>> authenticate to AD if they are added to too many security groups. 
>>>>>>>>>> At
>>>>>>>>>> first we thought it was a specific group causing the problem, but 
>>>>>>>>>> any
>>>>>>>>>> new group will reproduce the issue.  There doesn't seem to be any 
>>>>>>>>>> magic
>>>>>>>>>> number of groups that causes the problem either.  Some users are 
>>>>>>>>>> already
>>>>>>>>>> members of 3-4 security groups, add a 5th one and authentication 
>>>>>>>>>> breaks.
>>>>>>>>>>
>>>>>>>>>> When the problem occurs, users no longer seem to authenticate to 
>>>>>>>>>> the
>>>>>>>>>> domain.  They log onto their computer and do not run the login 
>>>>>>>>>> script.
>>>>>>>>>> Login also takes a lot longer -- it seems to sit and wait for a 
>>>>>>>>>> while
>>>>>>>>>> before completing.  Once the user is logged into their PC, they 
>>>>>>>>>> can't
>>>>>>>>>> access any networked resources.  If I try and map a network drive, 
>>>>>>>>>> I'll
>>>>>>>>>> get prompted for credentials.  Enter the credentials&     I can 
>>>>>>>>>> access the
>>>>>>>>>> resource.
>>>>>>>>>>
>>>>>>>>>> Anyone ever experienced anything like this or have any idea what 
>>>>>>>>>> might
>>>>>>>>>> be going on?
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> For starters, can you provide us with an ipconfig /all of the DC 
>>>>>>>>> and
>>>>>>>>> of the client, please? This will allow us to evaluate any basic
>>>>>>>>> misconfigurations, if they exist.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ace
>>>>>>>>>
>>>>>>>>> This posting is provided "AS-IS" with no warranties or guarantees 
>>>>>>>>> and confers no rights.
>>>>>>>>>
>>>>>>>>> Please reply back to the newsgroup or forum for collaboration 
>>>>>>>>> benefit among responding engineers, and to help others benefit from 
>>>>>>>>> your resolution.
>>>>>>>>>
>>>>>>>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&     Exchange 
>>>>>>>>> 2007, MCSE&     MCSA 2003/2000, MCSA Messaging 2003
>>>>>>>>> Microsoft Certified Trainer
>>>>>>>>> Microsoft MVP - Directory Services
>>>>>>>>>
>>>>>>>>> If you feel this is an urgent issue and require immediate 
>>>>>>>>> assistance, please contact Microsoft PSS directly. Please check 
>>>>>>>>> http://support.microsoft.com for regional support phone numbers.
>> 

We actually did try lowering the MTU on a workstation first, but it 
didn't make any difference.  Based on my tests, I found that 1400 was 
the sweet spot.  We tried 1400 all the way down to 1300 and the problem 
didn't resolve.

On 6/11/2010 4:22 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
> I agree. I'm not sure why ther MTU settings were even considered,
> especially the sensitivity of the LDAP PDU settings if the MTU is
> changed.
>
> Either way, I'm glad it was resolved, albeit having to make registry
> setting changes on workstations to make it work.
>
> Ace
>
>
> On Wed, 9 Jun 2010 10:48:54 +0300, "Andrei Ungureanu"
> <someone@mydomain.com>  wrote:
>
>> Still sounds like a MTU issue for me. I am thinking of this based on the
>> fact that changing the Kerberos to work on TCP fixed your issue. Changing
>> the MTU on the network equipment was a bad idea. You should have lowered the
>> MTU on the workstation, not on the routers.
>> Give it a try on a XP workstation.
>>
>> Regards,
>> Andrei Ungureanu
>> www.winadmins.net
>>
>> "Vegas or Bust"<tallguyinlv@hotmail.com>  wrote in message
>> news:#K9JzW1BLHA.4388@TK2MSFTNGP04.phx.gbl...
>>> Hi Ace,
>>>
>>> It looks like we finally solved this mystery!  We added these two registry
>>> entries to our workstations and (knock on wood) so far they can all login
>>> and authenticate properly:
>>>
>>> 1.
>>> Registry subkey:
>>> HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
>>> Value name: GroupPolicyMinTransferRate
>>> Value type: DWORD
>>> Value Data: 0
>>> This stops Windows XP from trying to determine if the Link is slow.
>>>
>>>
>>> 2.
>>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\
>>> Kerberos\Parameters
>>> Note If the Parameters key does not exist, create it now.
>>> On the Edit menu, point to New, and then click DWORD Value.
>>> Type MaxPacketSize, and then press ENTER.
>>> Double-click MaxPacketSize, type 1 in the Value data box, click to select
>>> the Decimal option, and then click OK. Quit Registry Editor.
>>> This regkey changes the way Kerberos authenticates from UPD to TCP
>>>
>>> We had previously tried entry #2 (force Kerberos to TCP) and found that it
>>> resolve the problem,  but made everything extremely slow.  It would take
>>> 15+ minutes to login and there was a 1-2 minute delay each time we tried
>>> to access resources.  Adding the other GroupPolicyMinTransferRate key
>>> seems to prevent the performance issue -- everything is now blazing fast.
>>>
>>> Thanks again for all your help!
>>>
>>> On 6/5/2010 10:46 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>> Hi Vegas,
>>>>
>>>> I wouldn't mess with the MTUs. Anything less than 1500 reduces the PDU
>>>> to less than 300kb which affects LDAP traffic. There's a KB on it, but
>>>> I don't have it saved in my notes.
>>>>
>>>> If it's just one person, and then added that it's happening another
>>>> account only in Domain Users, indicates something else is surely going
>>>> on.
>>>>
>>>> How many DCs are in the domain? If one domain, are all DCs GCs? Are
>>>> Sites configured? Errors in the event logs of the DCs or client?
>>>>
>>>> Also, this may be a dumb question, but were the workstations imaged?
>>>> Just trying to see if there is a dupe SID issue occuring, which is an
>>>> effect of imaging without using Sysprep.
>>>>
>>>> When creating the user account, was it copied, script created, or
>>>> manually created from scratch?
>>>>
>>>> If I think of anything else, I'll post back.
>>>>
>>>> Ace
>>>>
>>>>
>>>>
>>>> On Wed, 02 Jun 2010 09:47:45 -0700, Vegas or Bust
>>>> <tallguyinlv@hotmail.com>   wrote:
>>>>
>>>>> I have a laptop here that's experiencing the problem.  I can do a domain
>>>>> login using my own account&   a couple others, but one specific account
>>>>> (the lady who owns the laptop) can't login.  I deleted her AD account&
>>>>> created a new one, but it still has the same issue.  If it were caused
>>>>> by an SMB signing issue, I would think that nobody could login to this
>>>>> machine.
>>>>>
>>>>> The problem originally seemed to manifest on accounts that were members
>>>>> of some security groups.  If we reduced the number of groups, the
>>>>> account would start working.  They didn't have a huge number of groups
>>>>> -- maybe 4 or 5 -- without any nesting.  Now I'm seeing the problem on
>>>>> this account which is only a member of Domain Users.  I had a couple
>>>>> other problem accounts last week&   was able to fix the issue by deleting
>>>>> their AD account and creating a new one, but that didn't help for this
>>>>> case.  The problem also doesn't seem to be location specific -- this
>>>>> problem laptop exhibits the same issue in multiple offices.
>>>>>
>>>>> We tried reducing the MTU on our routers this morning to 1400.  My ping
>>>>> testing showed that 1430 was the highest MTU setting that wouldn't
>>>>> result in fragmentation.  As soon as the network engineers changed the
>>>>> MTU from the default of 1500 to 1400, all domain traffic stopped and
>>>>> they detected a ton of errors, so we restored the MTU to 1500.  I'm
>>>>> thinking that maybe we should try setting the MTU to 1400 directly on
>>>>> the DC and see if that makes a difference?  Otherwise I'm pretty much
>>>>> stumped.
>>>>>
>>>>> Thanks again for any help or direction you can provide!!
>>>>>
>>>>> On 6/1/2010 9:37 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>>>> Hello Vegas,
>>>>>>
>>>>>> Still with the problem? I thought it was resolved since I haven't
>>>>>> heard back.
>>>>>>
>>>>>> If it is only happening with the XP machines, and not the Windows 7
>>>>>> machine, it maybe be an SMB signing issue on the DCs that need to be
>>>>>> reduced.
>>>>>>
>>>>>> For example, here's a short write-up for 2008 R2 and signing. It's on
>>>>>> by default. Win 7 follows this, but not older OS'.
>>>>>>
>>>>>> Require SMB Security Signatures
>>>>>> http://technet.microsoft.com/en-us/library/cc731957.aspx
>>>>>>
>>>>>> Other references:
>>>>>>
>>>>>> Microsoft network server: Digitally sign communications (always)
>>>>>> http://technet.microsoft.com/en-us/library/cc786681(WS.10).aspx
>>>>>>
>>>>>> Server Message Block communication between a client-side SMB component
>>>>>> and a server-side SMB component is not completed if the SMB signing
>>>>>> settings are mismatched in Group Policy or in the registry:
>>>>>> http://support.microsoft.com/kb/916846/en-us
>>>>>>
>>>>>> Overview of Server Message Block signing (older article)
>>>>>> http://support.microsoft.com/kb/887429
>>>>>>
>>>>>> Ace
>>>>>>
>>>>>>
>>>>>> On Tue, 01 Jun 2010 14:38:55 -0700, Vegas or Bust
>>>>>> <tallguyinlv@hotmail.com>    wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> We're still fighting with this issue.  I have some network engineers
>>>>>>> looking at the MTU settings, but I made a new discovery today.
>>>>>>>
>>>>>>> I have an account here that exhibited the problem (doesn't properly
>>>>>>> authenticate to the domain, no login script, gets prompted every time
>>>>>>> she tries to access any domain resources).  Every Windows XP computer
>>>>>>> she logs into has the same problem.  I have a Windows 7 machine here
>>>>>>> and
>>>>>>> she can login just fine -- she authenticates properly, login script
>>>>>>> runs
>>>>>>> and she doesn't get re-prompted when accessing resources.
>>>>>>>
>>>>>>> Does this still point to a network issue, or is it possible that
>>>>>>> something else is going on?
>>>>>>>
>>>>>>> On 4/20/2010 8:02 PM, Ace Fekay [MVP - Directory Services, MCT] wrote:
>>>>>>>> That actually looks pretty good. I would suggest to change the
>>>>>>>> 127.0.0.1 to 198.18.50.11.
>>>>>>>>
>>>>>>>> Also, I noticed these are public IPs. No biggy, but assumed you had a
>>>>>>>> private IP network.
>>>>>>>>
>>>>>>>> As for forcing TCP, that's a red flag that UDP ports are being
>>>>>>>> blocked, or going back to what Andrei said, i can definitely be an
>>>>>>>> MTU
>>>>>>>> issue on one of the MPLS routers or firewall.
>>>>>>>>
>>>>>>>> If the MTU is anything less than default, as PPPoE routers, and
>>>>>>>> apparently what the MPLS in your case may be doing, is affecting the
>>>>>>>> LDAP PDU size. I am trying to find an old article that explains
>>>>>>>> thisr,
>>>>>>>> but I can't find it, but the article Andrei posted explains a way
>>>>>>>> around it.
>>>>>>>>
>>>>>>>> I would start digging into your MPLS configuration instead of
>>>>>>>> altering
>>>>>>>> your DCs. :-)
>>>>>>>>
>>>>>>>> Ace
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, 20 Apr 2010 14:55:08 -0700, Vegas or Bust
>>>>>>>> <tallguyinlv@hotmail.com>     wrote:
>>>>>>>>
>>>>>>>>> Hi Ace,
>>>>>>>>>
>>>>>>>>> It seems that forcing Kerberos over TCP instead of using UDP fixes
>>>>>>>>> the
>>>>>>>>> problem as per this article:
>>>>>>>>> http://support.microsoft.com/?kbid=244474
>>>>>>>>>
>>>>>>>>> However, once we make this change to a workstation it becomes very
>>>>>>>>> slow
>>>>>>>>> when accessing network resources.  It takes 4+ minutes to login,
>>>>>>>>> then
>>>>>>>>> there are very noticable delays when trying to access files,
>>>>>>>>> printers,
>>>>>>>>> etc. over the network -- you click on something then it sits with an
>>>>>>>>> hour glass for a while.
>>>>>>>>>
>>>>>>>>> Here are the results of ipconfig /all on the DC:
>>>>>>>>>
>>>>>>>>> Windows IP Configuration
>>>>>>>>>
>>>>>>>>>        Host Name . . . . . . . . . . . . : yyyy1WADC001
>>>>>>>>>        Primary Dns Suffix  . . . . . . . : xxxx.LAN
>>>>>>>>>        Node Type . . . . . . . . . . . . : Hybrid
>>>>>>>>>        IP Routing Enabled. . . . . . . . : No
>>>>>>>>>        WINS Proxy Enabled. . . . . . . . : No
>>>>>>>>>        DNS Suffix Search List. . . . . . : xxxx.LAN
>>>>>>>>>
>>>>>>>>> Ethernet adapter Front End:
>>>>>>>>>
>>>>>>>>>        Connection-specific DNS Suffix  . : xxxx.LAN
>>>>>>>>>        Description . . . . . . . . . . . : VMware PCI Ethernet
>>>>>>>>> Adapter
>>>>>>>>>        Physical Address. . . . . . . . . : 00-50-56-89-76-B6
>>>>>>>>>        DHCP Enabled. . . . . . . . . . . : No
>>>>>>>>>        Autoconfiguration Enabled . . . . : Yes
>>>>>>>>>        Link-local IPv6 Address . . . . . :
>>>>>>>>> fe80::10ac:9d19:bcd:5d46%10(Preferred)
>>>>>>>>>        IPv4 Address. . . . . . . . . . . : 198.18.50.11(Preferred)
>>>>>>>>>        Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>>>>>>>>        Default Gateway . . . . . . . . . : 198.18.50.254
>>>>>>>>>        DHCPv6 IAID . . . . . . . . . . . : 218124374
>>>>>>>>>        DHCPv6 Client DUID. . . . . . . . :
>>>>>>>>> 00-01-00-01-12-31-8E-A4-00-50-56-89-76-B6
>>>>>>>>>
>>>>>>>>>        DNS Servers . . . . . . . . . . . : ::1
>>>>>>>>>                                            127.0.0.1
>>>>>>>>>        NetBIOS over Tcpip. . . . . . . . : Enabled
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/20/2010 9:41 AM, Ace Fekay [MVP - Directory Services] wrote:
>>>>>>>>>> On Mon, 19 Apr 2010 16:15:33 -0700, Vegas or Bust
>>>>>>>>>> <tallguyinlv@hotmail.com>      wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I seem to be having a strange problem with my Active Directory
>>>>>>>>>>> user
>>>>>>>>>>> accounts.
>>>>>>>>>>>
>>>>>>>>>>> We have a Windows 2008 AD domain, with our only domain controller
>>>>>>>>>>> located at a remote data center.  All of our locations have
>>>>>>>>>>> connectivity
>>>>>>>>>>> to the data center through a private MPLS network, with varying
>>>>>>>>>>> speeds.
>>>>>>>>>>>
>>>>>>>>>>> Users at my largest office seem to lose the ability to properly
>>>>>>>>>>> authenticate to AD if they are added to too many security groups.
>>>>>>>>>>> At
>>>>>>>>>>> first we thought it was a specific group causing the problem, but
>>>>>>>>>>> any
>>>>>>>>>>> new group will reproduce the issue.  There doesn't seem to be any
>>>>>>>>>>> magic
>>>>>>>>>>> number of groups that causes the problem either.  Some users are
>>>>>>>>>>> already
>>>>>>>>>>> members of 3-4 security groups, add a 5th one and authentication
>>>>>>>>>>> breaks.
>>>>>>>>>>>
>>>>>>>>>>> When the problem occurs, users no longer seem to authenticate to
>>>>>>>>>>> the
>>>>>>>>>>> domain.  They log onto their computer and do not run the login
>>>>>>>>>>> script.
>>>>>>>>>>> Login also takes a lot longer -- it seems to sit and wait for a
>>>>>>>>>>> while
>>>>>>>>>>> before completing.  Once the user is logged into their PC, they
>>>>>>>>>>> can't
>>>>>>>>>>> access any networked resources.  If I try and map a network drive,
>>>>>>>>>>> I'll
>>>>>>>>>>> get prompted for credentials.  Enter the credentials&      I can
>>>>>>>>>>> access the
>>>>>>>>>>> resource.
>>>>>>>>>>>
>>>>>>>>>>> Anyone ever experienced anything like this or have any idea what
>>>>>>>>>>> might
>>>>>>>>>>> be going on?
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> For starters, can you provide us with an ipconfig /all of the DC
>>>>>>>>>> and
>>>>>>>>>> of the client, please? This will allow us to evaluate any basic
>>>>>>>>>> misconfigurations, if they exist.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ace
>>>>>>>>>>
>>>>>>>>>> This posting is provided "AS-IS" with no warranties or guarantees
>>>>>>>>>> and confers no rights.
>>>>>>>>>>
>>>>>>>>>> Please reply back to the newsgroup or forum for collaboration
>>>>>>>>>> benefit among responding engineers, and to help others benefit from
>>>>>>>>>> your resolution.
>>>>>>>>>>
>>>>>>>>>> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008&      Exchange
>>>>>>>>>> 2007, MCSE&      MCSA 2003/2000, MCSA Messaging 2003
>>>>>>>>>> Microsoft Certified Trainer
>>>>>>>>>> Microsoft MVP - Directory Services
>>>>>>>>>>
>>>>>>>>>> If you feel this is an urgent issue and require immediate
>>>>>>>>>> assistance, please contact Microsoft PSS directly. Please check
>>>>>>>>>> http://support.microsoft.com for regional support phone numbers.
>>>