Workstations delete from AD still let you log in

Are these machines on the same network as a domain controller?  If not, they may be using cached credentials.  Otherwise, see what domain controller authenticated the user and see if that domain controller is replicating properly.

Can these users actually access resources on the domain, or can the users simply log in to the machine?  

Yes. On the same network. I am aware of cached credentials. There is only one DC. They can actually access network resources. I haven't paid attention in a log time but it use to be that it would give you a trust relationship broken and not let you log on.

"it use to be that it would give you a trust relationship broken and not let you log on"

This is what is supposed to happen.

Run SET LOG from a command prompt and see if the name of the domain controller comes back.

Yes. In both cases it returns LOGINSERVER=\\SERVERNAME

The object that was deleted is likely different.

Search for the computer object to confirm.

Oh, the other possibility the server reflected a logonserver might be put of sync

Dcdiag /v /e ...

This way it is unaware the object was deleted..

Yes this is freaky.  I finally got on one remotely. Added it back in ADUC. No errors about duplicates. User was still able to log in. Deleted it again from ADUC. No change. User was still able to log in. Then I looked at the workstation. It was joined to the domain, I double checked and was logging in as a AD user. Just freaky.

I searched the AD for "Reception-PC". Not found. DCDIAG /v /e passed everything.

Late breaker... I looked at the network connections on this workstation. The first thing you see underneath "Ethernet" is domain.local 3 (Unauthenticated" but all the network drives are there and access able.

The object id in the AD might be something that still sees the workstation... it is hard to say what it is.
you may have to look at the objectID on the system and then locate it in the AD.

"Yes. In both cases it returns LOGINSERVER=\\SERVERNAME"

SERVERNAME is a domain controller?

Yes. SERVERNAME is the name of the one and only DC

one option to test, is to use the powershell get-adcomputer
and see how many you have versus how many you have.

If the object is deleted, it should not authorize from the AD.

https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer?view=windowsserver2019-ps

Well..... if you look at the screenshot above it did not authenticate and it was considered a public network yet the user had access to the network drives and resources as if he did authenticate. Your reference to get-adcomputer is not clear.

Finally got on one of the problem children from the second customer. Exact same network connects problem. Shows up as a unauthenticated, public network just like the screenshot above yet he can log in and has access to his network drives. I think Microsoft has a problem. In both cases I tried restarting the NLA service and get the same results on both:

I opened a ticket with Microsoft. After being on the computer for 5 hours they came to the decision that is was using cached credentials but had no idea how to clear the cached credentials. They had me go in to Credentials Manager for that specific user and for the local administrator and delete everything. Did no good. So is that another place that the cached credentials could be stored?

Can you check the shared security properties?
The first time it asks for credentials, have you considered restarting the server where the share is whether it is the one that has the cached token?

I've not run into this.
look at the Settings, accounts , access work or school to see whether those credentials are added there.

Microsoft has not run it to this :) The Server has been rebooted several times as has the workstation. Don't know what the shared security properties is. Setting, accounts, work or school are Microsoft Accounts. The credentials are no where near the same.

To see your cached credentials, start a "Run" command, and run this:
   rundll32.exe keymgr.dll,KRShowKeyMgr

On the server, properties of the shared folders, security tab.

That one is pretty easy. Administrators and Domain Users have full. End of story. But that really isn't the problem. This gut is a Domain User. He simply shouldn't be able to login in from a computer that is not part of the Active Directory.

What about the question raised, whether the user on the non domain joined computer has the same account/password that is matched to his domain account.
I think you are working on a theory that it is using your Admin domain credentials versus matches his own domain credemtial.

Test this out, have the user open a specific file someoddlynamedfile.txt.
then access the shahred sessions which user is being reflected as accessing this file.

Is it being access by your account, administrative or the person's?

you can test it out in a subfolder you create as a test, blockadminfromaccess, add an explicit deny to your account to it. Then see whether that user has the ability access it or gets a denied access do to the restriction.

A deny rule supersedes everything.
To delete, you would have to go through the parent folder, one above and reassert Parent Folder rights rights on the subfolders.

i.e. in \\server\sharename\create_parent\fakechildfolder
and on the fakechildfolder add a deny to your account, the account you think is cached.

I think MS's sysinternals has a tool that may help as well to look who is using the file if the above are not something you want to pursue i.e. the tool can reflect who is using/accessing a specific file.

The issue might not be cached credentials, but the user has the same password with the same account.
create a new test user, see if this test user will persist in having access post logout and does not have the net use reflect a retention of the reference.
It is a rabbit hole, but ...
 

Not sure you understand the question. The user is using his network credentials to log in. He is a user in the AD but his computer is not. His computer got deleted from the AD but he can still log in and still has access to network resources. He is, as we speak, using the computer and network files like he always has. Everything works fine but it shouldn't since his computer got deleted from the AD. What he should be getting when he tries to log on is the error that the trust relationship has been broken. There are four other users that occasionally used that computer. Their profiles are still on it. When they try and log on they get the error that the trust relationship has been broken and it will not let them log in. The user that uses this computer 99% of the time doesn't get that error. It lets him log in as if nothing has happened.

As  mentioned above Microsoft spent most the day on it yesterday and was totally mystified. @PAul MAcDonald that command did not show and cached credentials. By far the easiest thing to do would be to simply delete this users profile. I am sure that would do the trick but I have this happening at a couple different customers and it really needs to be addressed.

I understand fully what the issue is, when does the network setup?
Do you use 802.1x to authorize system's access to the network?
when the user logs in, he uses cached credentials into the workstation. then the network connection is reestablished and the user has access to the resources.

The alternative, change the AD password for the user or set the user account to require to change password and see if the user gets a prompt to change their password.

Yes. There are alternatives but none of the alternatives explain why this is happening. I would like to know why this is happening.

The 802.1x if you have, the system on logon sees the computer is off network, cached credentials to login into the system.
Then, when the user logs in, the user credential authenticate the system past the 802.1x requirement.

The other possibiliy, the object being deleted is not deleted, but is present within the AD somewhere else. or is not by the name.

YOur assumption that the worstation is deleted may be the issue.

the workstation name is somebox, but the object in the AD is anotherbox.

You need to see whether the AD objectIDs that you have in AD can be matched to each station.
objectsid/sid

This may help locating the SID of the computer/system at issue
https://social.msdn.microsoft.com/Forums/en-US/88c2cce6-7c53-4553-81a6-6bc4c59226fa/how-to-find-out-objectid-or-deviceid-via-device?forum=WindowsAzureAD

i.e. someone mistakenly renamed the computer account in the AD under the impression that it will update the computer name.
or something did not go right with a rename of a system....

now using the ObjectID from the registry, see if this objectid exists in the AD. get-adcomputer

Object does not exist

Ok, when you boot the system. Does it reflect that it is connected to the network before the login attempt?

How would you determine that ?

On the login screen it should have a network status indicator.

The other is to use a user account that could never have been loged into this workstation and see whether it can login.

If the system, workstation try the rename computer name, it shold correspond with the change of the account in the AD.

There must be something obvious

Domain trust?

There is no network status indicator in the login screen. There is one for internet. That has nothing to do with AD. Please provide screenshot of network indicator.

As mentioned several times no other user can log in. They get the trust broken error.

As mentioned there is no computer in the AD

Microsoft has been at this for days. They agree is should not be happening but have not found a solution.

The system does not term the Cached credentials for the user because it is unaware that it has been removed from the domain.
This is why the user is allowed to login. and then the USER has rights to the environment. what is the end goal?
you can login, revert the workstation to a workgroup, or rejoin it to the domain to reestablish the trust.

you would need to make sure you have the local admin login if you remove it from the domain.

As stated many, many times before the goal is to find out why this user can still log in even though his computer has been deleted from the AD.

Cached credentials.
Someone deleted the object on the AD. as far as the workstation is concerned it is part of the AD while not having any rights on boot to access netlogon/sysvol or any GPOs.

only a user who previously logged in will have access.

I believe I suggested sometime ago to change the user's password in the AD and see whether while the user will be able to login into this ghost/zombie system, will the user still have access to the domain resources.

If it was a different test, the person in possesion of the system will need to know the credentials that were successfully used before. i.e. if it is a laptop that is lost, in the AD the objected is disabled or deleted, .....