Link to home
Start Free TrialLog in
Avatar of David_Blumberg
David_Blumberg

asked on

Windows 10 Domain Account Not Logging in away from office

Our employees used to have the ability to leave the office with a notebook and it would allow them to logon to their account and any changes to desktop/documents would update when back at the office.  Since a new update came about the users cannot login to the domain account and will just say incorrect password and the only way they can login is to be hooked up to the network.  Any thoughts?

Domain Server is Windows 2008 R2

Systems are Dell Latitude 6430
Avatar of McKnife
McKnife
Flag of Germany image

Look, updates are like scapegoats. Whenever something happens that admins cannot explain, they tend to look at the windows update history and get a feeling that it must have been the latest update.

But updates don't delete password hashes. There is no logical explanation that they do.

What might be the reason: if we have a machine with default settings, exactly 10 user passwords are hashed&cached. When some 11th user logs on, the oldest hash gets deleted (let's call it hash1) and user1 can no longer logon without being in contact with a domain network.

So please verify if your settings for hashes are at default (you would normally know if you changed those) and also verify using the security eventlogs if a hash got deleted.
Avatar of David_Blumberg
David_Blumberg

ASKER

There were no changes to hashes and not sure why you would indicate this would not be an update.  These are machines tied specifically to the user and there is a just a local admin account and the domain user on each machine.  Also, we removed the user profile and setup a new profile with the domain account and same issue.  Our GPO is set to 30 cached.  Thank you
Hm, could it be I gave you an incorrect log name? I looked at it again: It's not the security event log, but the system event log section. Example entry:
Source: LSA (LsaSrv), EventID 45058
"A logon cache entry for user myuser@mydom.local was the oldest entry and was removed. The timestamp of this entry was 11/2/2016 17:27:15"
Please revisit your system event log log and filter for that source and/or eventID.
Error I see:
Event 1129
The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.


Don't see anything in LSA
Ok, you say, you don't see an Event 45058 with source LSA in the log "system"? That would mean, the hash is still there (and thus, would have to work). To verify, one would need to consult a hash analysing tool ("pwdump" or "mimikatz") and see if it can at least verify there is a hash and name it. Then, have your password hashed using this site: https://www.tobtu.com/lmntlm.php and compare the hashes. It's just a little effort between you and a usable result that can tell you what happened to the cached logon.
Ok, I will work on it and get back.  thanks
I hope I made clear that this is a very small operation. Download mimikatz (or pwdump) and run it on an elevated command prompt to get the existing hashes. Then visit the site that I linked, enter the users password (he needs to tell you or do it himself) and let the site calculate the hash and compare it to what  mimikatz found. Three possible outcomes:

1 mimikatz does not find the hash ->it got deleted for some reason
2 the hash is found and matches the password hash ->very unlikely, because then, logon should work
3 the hash does not match ->we would need to find out if the user is perfectly sure he uses the correct password.
Both mimikatz and pwdump (dowloaded both) do not even show the domain user as the dump.
They should. What do they show?
Administrator:500:6841338FDB14EEB85BA26A7EC5EE177D:247179FE2ACFB1F3F3C80BB0A6906287:Built-in account for administering the computer/domain::
Guest:501:********************************:********************************:Built-in account for guest access to the computer/domain::
DefaultAccount:503:********************************:********************************:A user account managed by the system.::
dablum:1001:6FF6961C47A8A325F749C1C81F7F539B:08ED1A4FF01542BF92736A48C3AF317B:::


I do not show any domain accounts yet in the c:\users account i see the login.domain folder for the user
Ok. That is very odd. You don't see cached domain credentials at all. Please logon with a domain account now and see if it gets cached. So logon and off, disconnect from the network and see if you get in and if yes, run mimikatz again.
Still does not show any cached credentials.  One thing to note is there are no entries in event viewer when trying to login with the domain account.
And what about logging on when disconnected now?
Same as before, it says incorrect password.  One thing I notice is that when signing out it gets stuck on Closing 1 app and signing out and have to choose sign out anyway.
ASKER CERTIFIED SOLUTION
Avatar of McKnife
McKnife
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
So I have upgraded the systems to the new build 14965 and it is now working, I am assuming this was a bug with an older build of windows.  Thank you again for your help.
I have not seen this problem and we use some laptops with win10 from the very first minute.
So it could rather be that your inplace upgrade to an insider build has repaired it just like any stable build of 1607 would have done.
Be warned, the insider builds show problems from time to time.