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
Domain Server is Windows 2008 R2
Systems are Dell Latitude 6430
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 45058Please revisit your system event log log and filter for that source and/or eventID.
"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"
ASKER
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
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.
ASKER
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.
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.
ASKER
Both mimikatz and pwdump (dowloaded both) do not even show the domain user as the dump.
They should. What do they show?
ASKER
Administrator:500:6841338F DB14EEB85B A26A7EC5EE 177D:24717 9FE2ACFB1F 3F3C80BB0A 6906287:Bu ilt-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:6FF6961C47A8A3 25F749C1C8 1F7F539B:0 8ED1A4FF01 542BF92736 A48C3AF317 B:::
I do not show any domain accounts yet in the c:\users account i see the login.domain folder for the user
Guest:501:****************
DefaultAccount:503:*******
dablum:1001:6FF6961C47A8A3
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.
ASKER
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?
ASKER
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
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.