none
possible attempt to compromise security RRS feed

  • Question

  • I have Windows 7 64bit Pro and Ultimate clients, and Windows Server 2003 R2 32bit domain.  All systems are fully updated.  I have no problem with Windows XP clients.

    When the Win7 clients try to browse to a network share, such as \\servername they get the following error message:

    The system has detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

    Sometimes, I also get the following message:

    Windows needs your current credentials to ensure network connectivity.  Please lock this computer, then unlock it using your most recent password or smart card. To lock your computer, press CTRL-ALT-DEL and then press Enter.

    Of course, authentication should be automatic and behind the scenes.  These messages should not come up.  But even when I type in my credentials or lock/unlock as it says, there is no change.

    Friday, March 19, 2010 9:55 PM

Answers

All replies

  • One more comment.  There is only one thing I can think of, that I ever did, that might be uncommon.  A long time ago, I went into AD Users & Computers.  I right-clicked my domain name, and chose "Raise Domain Functional Level."  At the time, it said my domain was at functional level 2000, and I upgraded it to 2003.  It was successful and smooth.  Seemed like a good thing to do at the time.

    I have no reason to think this caused the problem now, except that I admin more than one site, and this is the only site having the problem.  Still, it's probably unrelated.

    Friday, March 19, 2010 10:00 PM
    • Marked as answer by Novak Wu Tuesday, April 6, 2010 2:21 AM
    Friday, March 26, 2010 1:57 AM
  • I have the same problem -- but only on my Windows 7 clients trying to stay connected to my Window 2003 R2 server (my XP clients are fine).   I am in a single domain situation and the Windows 7 clients are all members of that domain so the article referenced above does not apply.  I use a logon script to map to a share on the server but at some point (after a long idle period), the mapped drive fails and I get that error message. I can ping the server from the Windows 7 PC, I can resolve the name as well, so it is not a network problem and it works again after reboot so it is not a firewall problem.

    If the user reboots, the mapping works again but I need to find a solution that does not require me to tell the president of the company "Stop what you are working on and restart your computer repeatedly".

    Any help would be appreicated.

    Laurie

     

    Thursday, April 8, 2010 4:20 PM
  • The resolution to the problem listed in that article Novak posted is so simple you should check your Windows Firewall anyway...

    It says, "To resolve this problem, configure the network firewall so that TCP port 88 and UDP port 88 are not blocked for either domain."

    Interestingly, a quick scan through Windows Firewall's predefined rules does not show any for port 88 specifically.

    If I were you, I'd try adding specific rules to allow connections to those ports and see if the problem is resolved.  Alternatively, as a quick check to see if it is indeed a firewall issue you could try temporarily disabling the firewall entirely.

    Keep in mind that Windows 7's firewall is the first Windows firewall to switch over to the new "disallow incoming connections unless they match a rule" philosophy.

    -Noel

    Thursday, April 8, 2010 6:03 PM
  • As a quick check, I dropped the firewall entirely and tried to reconnect the drive.  It threw the same error.  Repeated attempts resulted in a different error -- "An unexpected network error occurred".  However, even as the reconnect failed, I could ping the server, both by IP and by name.  However, to fully test the firewall theory, I will run the scenerio again from the beginning (starting with a good connection).

    Once I shutdown and restart (reconnecting the drive), I have to wait for it to drop again to test if any given solution works, which is going to make this a very long process.  My first test will be to reconnect by restarting  a test machine tonight and making sure that the firewall is completely down on that machine overnight.  Then I will see if I have lost connection again by tomorrow morning.

    Thanks,

    Laurie

     

     

    Thursday, April 8, 2010 6:36 PM
  • Opening port 88 did NOT resolve the problem. 

    Any more ideas of what I might try?

    Thanks,

    Laurie

     

    Thursday, April 15, 2010 1:47 PM
  • Sorry to hear that.

    I'm out of ideas, though my thoughts drifted briefly toward at least lengthening the connection timeout on the server to possibly lessen the appearance of the problem.  I used to know exactly how to do that, but I've since forgotten...  Something about NET CONFIG SERVER...

    -Noel

    Thursday, April 15, 2010 4:44 PM
  • I was receiving this error on a client in a single domain situation. I found that the DNS server addresses for the TCP/IP connection had been set manually to servers out on the net. I set it to obtain DNS server address automatically and it's been fine since.

    Conrad

     

    • Proposed as answer by WildDoktor Friday, June 1, 2012 12:20 AM
    Tuesday, May 11, 2010 3:19 PM
  • I will try that next.

    Thank you.

    Laurie

    Tuesday, May 11, 2010 5:45 PM
  • I have this problem almost everyday (SBS08). I have tried a ton as well. I got so fed up and angry I reimaged the machines. Still happens. Im guessing now its a server issue. They are XP Pro machines. Firewalls all off. After I reimaged the machines I noticed that I could not add the stations back onto the domain unless I specified DNS manually. Then it worked.

     

    Any conclusion as to what the problem is?

    Monday, December 27, 2010 2:07 PM
  • This was solved. A group policy waaaaaaaaaaaaay nested inside of the 1000 default policies SBS makes has kerberos ticket to expire every 10 hours.
    • Proposed as answer by CCA Admin Thursday, February 3, 2011 3:20 PM
    Thursday, February 3, 2011 3:19 PM
  • did you remove the policy or just change it?
    --- ian
    Thursday, March 24, 2011 10:22 PM
  • That's not working for most of us. (I have Win 7 client, Server 2003 R2 64 bit AD)

    This seems more likely to be a Kerberos time-out issue, as recently suggested by CCA-Admin. However, there's no suggested route to changing these.

    Any help proferred, gratefully accepted.

    Thanks

    Brian


    25 years in IT?
    Thursday, April 7, 2011 10:02 AM
  • I have similar problem.

    My windows7(64) Enterprise PC, is a member of domain ABC.  I am logged in with a ABC domain user with local administrator privileges.

    I am using my PC inside a different network, no connection to domain ABC.  I am able to successfully  file share to server 123 in domain XYZ, however I get same error when attempting start>run>\\456\c$  .   I am given the "an attempt to compromise security...blah blah" message at the bottom of window before I ever attempt putting in credentials, when I do enter the credentials, i get the "unknown username or bad password" error. 

    Any help fellow geeks? :) 


    Friday, May 13, 2011 4:26 PM
  • Manyhat,

     

    Windows 7 stores domain log on credentials locally allowing you to log on your system when your not connected to the domain your system is associated with. When your logging in to the xyz domain your not authenticating to that domain your logging in to your system with the cached credentials from domain abc. Doing this doesn't provide you network access rights and definitely not to a system admin share. You have to be joined to the domain and use admin credentials or local admin credentails for xyz domain to access \\456\c$.

     

    You should try command  net use Z: \\ip\share /user:domain\username password  to log on to \\456\c$. You have to use credentials for xyz domain. You could also map a drive and check the box"Use different user name and password to connect".

     

    As for successfully file sharing to server 123 in domain xyz it appears that security for 123 isn't setup correctly or the share your accessing allows for anonymous access.

     

    Saturday, May 14, 2011 9:50 AM
  • I have a similar issue.

    Server 2008 R2

    Desktop running 7

    DNS-DHCP set to AD serer.

    It is NOT a Kerberos issue (all patches and work-a-rounds have been used).

    All the users have their own log-in script that work. (all maps are to the one server/domain)

    Of the 50+ desktops only one is giving this error.

    I have set the "Amount of idle time required before suspending a session to": 99999.

    All desktops are shutdown at night.

    If I run the user log-in script from the user desktop, all maps are restored.

    Any thoughts?

     

    Tuesday, May 31, 2011 4:42 PM
  • OK I have a similar issue but narrowed my issue down to a particular user ID. One of my desktop people got a new laptop and loaded a corporate image of Windows 7 Enterprise that we have been using for a few months now. Her old laptop works fine with WinXP. The Win7 one will also propmt her for credetials on trying to access any network resources. If I login with my normal user credentials on her machine everything works fine. I thought OK it is her ID or profile. I then had her login to my laptop with her credentials and see what happens, she had never logged into mine or me hers so no cahed credetials were used. The problem followed her from system to system on Win7. We had firewalls disabled on both systems. I would think it is related to her User account except that the XP system works fine. We also tried changing her password at the PC and it will not change it either. No real messahe other than a small yellow triagle with exclamation point and the word "set". Any ideas guys?

     

    JD

    Monday, August 8, 2011 11:36 PM
  • I having the same exact problem. When I moved to the new laptop, I used the same computer name as the old laptop and connected to the domain. And my user account password had expired at that time. I am not too sure if that contributed to the problem. I cannot change my password either, as I receive the same yellow triangle with no information apart from "status". The AD administrator will look through the logs to check if there is anything wrong?
    Tuesday, August 23, 2011 8:53 AM
  • Been a long time....but the problem for me was related to the syntax I was using for entering credentials.    I have never been able to memorize which is the correct "slash / or \ to use when entering credentials, so when I stumbled across this syntax username@domain I was like "SWEET", my memory block is fixed.

    It seems however that this syntax isn't liked on the server I was attempting to access.  I had to use the old slash syntax "domain<slash>username" and it worked !!

     

     

    Tuesday, January 3, 2012 6:39 AM
  • You nailed it, ConradMSP.  I had a hardcoded nameserver in my connection. TY :)
    Thursday, January 12, 2012 8:23 PM
  • You nailed it, ConradMSP.  I had a hardcoded nameserver in my connection. TY :)

    ConradMSP was right!

    I too had 1 machine Win7 that was having this issue... I had forgotten that I changed the DNS on this machine to Google's DNS servers as a test and never set them back.

    So I changed it back to auto (Set from the DC) and BINGO! Problem gone.

     

     

    • Proposed as answer by itguyinbend Wednesday, February 8, 2012 6:15 PM
    Friday, February 3, 2012 3:09 PM
  • Almost always a DNS issue with Windows. I too had changed my PCs DNS server to my ISP's to temporarily bypass my content filter. I forgot to change it back. Imagine that...it worked!!!
    Wednesday, February 8, 2012 6:17 PM
  • We were experiencing the exact same issue, but the resolution was not related to DNS or Firewall.  Turns out the user had Kerberos DES encryption types enabled in Active Directory Users & Computers.  Disabling this option fixed the problem.  RjZ

    Thursday, April 12, 2012 1:07 PM
  • I was receiving this error on a client in a single domain situation. I found that the DNS server addresses for the TCP/IP connection had been set manually to servers out on the net. I set it to obtain DNS server address automatically and it's been fine since.

    Conrad


    Brilliant...I'd changed DNS for testing. Changed it back to "auto" and am in again. Thanks ConradMSP!!

    Bill Hagen, Owner That Computer Geek Newberg, OR www.thatcomputergeek.com

    Friday, June 1, 2012 12:21 AM
  • My issue ended up being a problem with one of my DNS servers. When trying to troubleshoot this further and look at policy settings, I was not able to open that server's setting with a very similar error in GP. Try checking your DNS servers or forcing your workstations to use one or the other DNS servers and see what happens. Fixing this really sped up the network for those affected.

    Thanks to all who suggested options. Helped solve my issue and get head of an even bigger future issue :)


    • Edited by MuddauberE Wednesday, May 7, 2014 7:50 PM
    Wednesday, May 7, 2014 7:48 PM
  • I know. Old post, just tossing in my 2 cents.

    We ran into this with one of our clients. Of course none of this worked and I was not about to start messing with firewall settings or AD settings as that almost always leads to bigger headaches down the road. Troubleshooting the rest of the connectivity we found that a handful of clients were no longer receiving DHCP updates. We checked the DHCP server and it was completely frozen (MS DHCP). We stuck static IP addresses on the affected clients, restarted, and connectivity resumed.

    The server is scheduled for a restart later today.

    It all goes back to the saying "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.” ~Arthur Conan Doyle, Sr.

    Before making any significant changes to firewalls, AD, etc. Make sure you eliminate any and all possibilities no matter how crazy it sounds and exhaust all simple, stupid troubleshooting tactics before changing system settings.

    Hope this helps someone further down the road with the same problem.

    Thursday, July 2, 2015 6:14 PM
  • SOLVED---This issue was NOT from a different domain as the MS article suggest.  Others have solved this with bad DNS settings, or static DNS setting to public dns from local computer.  Mine was different, RDP saved session credentials from a different user were saved to the connection and once the logged in user tried map to this server these "other" saved credentials would be used.    Once I deleted these in RDP/MSTSC for that server I was trying to connect to the issue was gone.
    Thursday, July 30, 2015 2:01 PM
  • Thank you. This worked.
    Tuesday, September 20, 2016 4:50 PM
  • I had the same problem almost 3 months, today  open TCP port 60, 66,  1514  now system is working 
    Thanks
    Nirosha

    Tuesday, November 8, 2016 7:09 AM
  • ConradMSP post above worked for me thank you.  Was driving me crazy


    • Edited by jdwigginton Thursday, January 31, 2019 5:56 PM
    Thursday, January 31, 2019 5:55 PM