Questions

The system detected a possible attempt to compromise security.

+
0 Votes
Locked

The system detected a possible attempt to compromise security.

artanyis
Okay, I need "rational" solutions to this issue.

I have several remote windows 7 domain users that receive this message on logon:
The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you." and it asks for username / password.

A little bit of setup:
150-ish in house users 50-ish remote users
User accounts have redirected docs / desk / etc... with offline file sync enabled.
Users have a windows based VPN that they can connect to to synchronize data and access server resources. The VPN can not be used constantly because of bandwidth limitations. VPN is set in split tunneling mode because of a dramatic performance loss caused by the bandwidth limitations.

What I understand is happening is that when the user logs on and the system tries to access the redirected documents / desktops / etc... and it is trying to authenticate the share with the server using Kerberos yet the local DNS cant find the server, because they are not on site, Kerberos fails and causes windows to display this message in an attempt to force the user to authenticate.
What I don't understand is why, since the domain controller is not present, does it not just authenticate to the cached credentials like it should? And second, why does it take entering the username / password 2-10 times before the it actually accepts them? Shouldn't it either take them immediately as authenticating against the cached credentials or never accepting them at all because it cant find the DC?

So I need a solution that will not hamper performance, but will stop this bloody message from plaguing me.

Note: Option I have not tried because of the bandwidth issue is setting the remote users VPN connections back to full tunnel and having the VPN connect on logon. Theoretically that would solve the problem but it would put such a drain on the limited bandwidth at the home site and for all of the remote users.
  • +
    0 Votes
    robo_dev

    Kerberos uses UDP protocol for the ticket exchange, per the RFC standard. UDP is a best-effort protocol, and things like VPNs or busy networks cause odd things to happen (like not being able to authenticate). Kerberos cannot tolerate packets getting out of order, which can happen due to MTU size issues, latency, etc.

    Microsoft allows you to go non-standard and force Windows to use TCP for kerberos authentication via a registry edit.

    I believe the 'trying multiple times' part has to do with either the use of roaming profiles and/or the workstation. If the user profile is not cached the credentials cannot be cached.

    You might fiddle with cached login counts:

    The following key value is set to 10 on both the Win7 and XP machines:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\CachedLogonsCount

    http: //social DOT technet DOT microsoft DOT com/Forums/en-US/w7itprosecurity/thread/bc13f194-36fa-4140-a899-2954ce62c4bf/

    One other thing, if users do not log off..just shut the lid of the laptop, then the machine can get confused and keep trying to hit the DC when they resume. They must logoff or the PC won't used cached credentials in all cases.

    +
    0 Votes
    artanyis

    I had thought about forcing Kerberos to use TCP but had dismissed the idea since the problem is that the remote users cant contact the domain before they log in since they are not on the local network.
    I'll make the change anyway and see if it helps. At the very least it may help authenticate better with a split tunnel so I could set the VPN to activate on logon...

    Thanks, for the idea, keep them coming please.

    +
    0 Votes
    robo_dev

    Correct, your issue is cached credentials, or lack therof.

    Roaming profiles tends to break cached credentials, as do users who never logout.

    I would fire up a sniffer like Wireshark and try to observe the failure...if the machine is using cached credentials properly, you should not see it sending a flurry of request packets trying to hit the DC.

    +
    0 Votes
    artanyis

    Wireshark cant help here, I know the connection is failing, the users with this error are REMOTE users, they are not local to the DC, they can not authenticate on logon. It should be using the cached credentials but it is not at first, causing it to error, a lot. I need a solution that forces the logon process to use the cached credentials and load the offline files as opposed to trying to connect to a server that is unavailable.

  • +
    0 Votes
    robo_dev

    Kerberos uses UDP protocol for the ticket exchange, per the RFC standard. UDP is a best-effort protocol, and things like VPNs or busy networks cause odd things to happen (like not being able to authenticate). Kerberos cannot tolerate packets getting out of order, which can happen due to MTU size issues, latency, etc.

    Microsoft allows you to go non-standard and force Windows to use TCP for kerberos authentication via a registry edit.

    I believe the 'trying multiple times' part has to do with either the use of roaming profiles and/or the workstation. If the user profile is not cached the credentials cannot be cached.

    You might fiddle with cached login counts:

    The following key value is set to 10 on both the Win7 and XP machines:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\CachedLogonsCount

    http: //social DOT technet DOT microsoft DOT com/Forums/en-US/w7itprosecurity/thread/bc13f194-36fa-4140-a899-2954ce62c4bf/

    One other thing, if users do not log off..just shut the lid of the laptop, then the machine can get confused and keep trying to hit the DC when they resume. They must logoff or the PC won't used cached credentials in all cases.

    +
    0 Votes
    artanyis

    I had thought about forcing Kerberos to use TCP but had dismissed the idea since the problem is that the remote users cant contact the domain before they log in since they are not on the local network.
    I'll make the change anyway and see if it helps. At the very least it may help authenticate better with a split tunnel so I could set the VPN to activate on logon...

    Thanks, for the idea, keep them coming please.

    +
    0 Votes
    robo_dev

    Correct, your issue is cached credentials, or lack therof.

    Roaming profiles tends to break cached credentials, as do users who never logout.

    I would fire up a sniffer like Wireshark and try to observe the failure...if the machine is using cached credentials properly, you should not see it sending a flurry of request packets trying to hit the DC.

    +
    0 Votes
    artanyis

    Wireshark cant help here, I know the connection is failing, the users with this error are REMOTE users, they are not local to the DC, they can not authenticate on logon. It should be using the cached credentials but it is not at first, causing it to error, a lot. I need a solution that forces the logon process to use the cached credentials and load the offline files as opposed to trying to connect to a server that is unavailable.