Local Administrator mapping network drive without additional credentials
On most of the machines in our environment, when a technician is logged into the local Administrator account, they are able to map to a network share without being prompted to enter additional credentials. However, on a small subset of machines, doing so requires that they enter in credentials of an account in our Domain (like their own AD credentials).
What about our machine or AD configuration would allow the local Administrator account to be able to map a network drive without requiring credentials of an AD account? We would actually like to enable this behavior on all machines.
Thanks. Greg.
p.s we are on Windows 10 Pro on the workstations and Windows Server 2012 on the Domain Controller
What about our machine or AD configuration would allow the local Administrator account to be able to map a network drive without requiring credentials of an AD account? We would actually like to enable this behavior on all machines.
Thanks. Greg.
p.s we are on Windows 10 Pro on the workstations and Windows Server 2012 on the Domain Controller
In Theory (IT)
CERTIFIED EXPERT
a GPO written and push to these machines that are in their own OU will suffice.
Can you provide more explicit instructions? We are not using group policy, but can do so with local policy. What specifically needs to be done?
In Theory (IT)
CERTIFIED EXPERT
OK you will have to get familiar with GPO it is easy to learn, if not you will walk to every computer to do this. You will want to set up workstations into their own organization unit meaning management OU, Developer OU, BACKUP OU, you set this up under users in the gpo snap-in then you set who will be what member of, then you set gpo for the OU so whoever is in the OU is affected via that gpo policy.
Let me clarify. The machines are functioning fine as far as Domain related behavior goes. Users log in with their IDs and passwords and everything's fine. We do not want to mess with that.
The issue is that on these dozen machines, when logged in as the local Administrator on the machine. In that case, going to a command prompt and typing MAP H: \\servername\sharename results in being prompted for a domain-based ID and password.
For the rest of our machines (about 100), when doing this same thing, the user is not prompted for a domain-based ID and password and the MAP command successfully completes.
Thoughts?
The issue is that on these dozen machines, when logged in as the local Administrator on the machine. In that case, going to a command prompt and typing MAP H: \\servername\sharename results in being prompted for a domain-based ID and password.
For the rest of our machines (about 100), when doing this same thing, the user is not prompted for a domain-based ID and password and the MAP command successfully completes.
Thoughts?
In Theory (IT)
CERTIFIED EXPERT
OK it seems like the GPO that was setup to handle this was has not been update properly so not to screw up anything issue this command on the server in cmd.exe gpupdate /force this will force all computers on the network to accept and apply the policy, now you can reboot every machine to access the update or wait until each user reboots their machine
Here is a site that talks about updating group policies and forcing computers to accept them, it provides syntax where can update each computer
http://techgenix.com/How-Force-Remote-Group-Policy-Processing/
after this then, check the machines and see if problem is solved if not post back.
Here is a site that talks about updating group policies and forcing computers to accept them, it provides syntax where can update each computer
http://techgenix.com/How-Force-Remote-Group-Policy-Processing/
after this then, check the machines and see if problem is solved if not post back.
I guess they must have already tried a reboot so the problem may lie somewhere else. do you mean you have multiple users who are local admins on the pc's ?
If so you should check of user A (local administrator) when logs on the affected machine has the same behavior logging on the non-affected machine. This can help pin point the problem either with group policy or shared folder security permissions.
If so you should check of user A (local administrator) when logs on the affected machine has the same behavior logging on the non-affected machine. This can help pin point the problem either with group policy or shared folder security permissions.
OK, an update on this.
- The 14 machines that are displaying this issue are essentially the same. The same model PC, the same OS, the same local account ID and password, and all attached to the same Domain.
- Forcing a gpupdate did NOT resolve the issue. So, Natty Greg, thank you for your idea, but that didn't resolve it.
- Looking at David Johnson's idea of what's in Credential Manager did not display any credentials for Windows users that have been saved.
However, the Credential Manager idea did give me an idea. I went to one of the machines and set the local admin password to a previously used local admin password (to do this, I had to remove the computer from the domain, reboot, log into the non-Domain connected machine as local administrator, change the local administrator account user Computer Management, rejoin the Domain). When using the prior password, the machine was able to map a drive without being prompted for credentials.
Thoughts on why this might work? Are the prior credentials somehow saved somewhere on the machine? I did look at the Registry under HKEY_Current_User/Network and saw that each of these machines did have a setting for the "h" drive (the drive I am trying to map). But this was true both prior to removing the machine from the domain and after rejoining the machine to the domain.
Really, the only difference I can think of between being able to map without being prompted for credentials or not was that when using the prior local administrator password it worked, and when using a new local administrator password, it didn't work.
So where might those old local administrator credentials be stored?
- The 14 machines that are displaying this issue are essentially the same. The same model PC, the same OS, the same local account ID and password, and all attached to the same Domain.
- Forcing a gpupdate did NOT resolve the issue. So, Natty Greg, thank you for your idea, but that didn't resolve it.
- Looking at David Johnson's idea of what's in Credential Manager did not display any credentials for Windows users that have been saved.
However, the Credential Manager idea did give me an idea. I went to one of the machines and set the local admin password to a previously used local admin password (to do this, I had to remove the computer from the domain, reboot, log into the non-Domain connected machine as local administrator, change the local administrator account user Computer Management, rejoin the Domain). When using the prior password, the machine was able to map a drive without being prompted for credentials.
Thoughts on why this might work? Are the prior credentials somehow saved somewhere on the machine? I did look at the Registry under HKEY_Current_User/Network and saw that each of these machines did have a setting for the "h" drive (the drive I am trying to map). But this was true both prior to removing the machine from the domain and after rejoining the machine to the domain.
Really, the only difference I can think of between being able to map without being prompted for credentials or not was that when using the prior local administrator password it worked, and when using a new local administrator password, it didn't work.
So where might those old local administrator credentials be stored?
In Theory (IT)
CERTIFIED EXPERT
Then the password change is not taking effect and there is a cache or system override somewhere, which in not good, unless the map drive has a pre-shared key/password not necessarily attached to your credentials
Thanks for the help in getting to the root of this. Just trying to better understand your comments, Natty Greg. When I change the local admin password, the machine then requires the new password, so it appears that the password change is taking effect. But I'm certainly open to opinions on that.
So, assuming that the password change is indeed taking effect, you suggest that there is a cache or system override somewhere. Do you know where this might be? Could it be in Active Directory, even though we're dealing with a local administrator password? One possibly related oddity is that on these machines the local admin password was invalidated after a period of time (maybe the 60 day password expiration policy length) as not being complex enough. However, on other machines that use this same local admin password, they were not given this message. Could a machine somehow have its local admin account governed by AD?
Sorry that I don't know more. I recently came into this environment and am trying to understand what is going on.
So, assuming that the password change is indeed taking effect, you suggest that there is a cache or system override somewhere. Do you know where this might be? Could it be in Active Directory, even though we're dealing with a local administrator password? One possibly related oddity is that on these machines the local admin password was invalidated after a period of time (maybe the 60 day password expiration policy length) as not being complex enough. However, on other machines that use this same local admin password, they were not given this message. Could a machine somehow have its local admin account governed by AD?
Sorry that I don't know more. I recently came into this environment and am trying to understand what is going on.