User login into the workstation with cached credentials. One of them will be his logon server and he will get all his policies during login process.īut when he is in untrusted network by default he has no direct communication to the domain, Since you are not exposing your internal domain controller to the internet. When a user is in trusted network (wan), his workstation can communicate to all domain controllers in your domain. I’m assuming that you are using dfs share for the map drive. Let me try to answer in way a security person would understand. I'm happy to trade some network/security expertise for your Windows expertise! I'm NOT an AD/GPO guy so I apologize if this is a silly question. Any ideas? Do I need to run a special script to destroy and recreate drive mappings once VPN connects? Several users have reported this problem. Is it possible that these machines are trying to logon using email address instead of network/user ID? If so, why does it work in the office and not on VPN? Users assure me they login to their computers with their network ID.
#Viscosity vpn connecting to remote computers password#
I click "use other account" and enter domainname\userid and have the user enter their password and the drive maps fine. What's weird is when I re-add the mapped drives (after deleting) it auto-completes the "default" username that will be used to complete the mapping but it autocompletes with the users' e-mail address instead of a domain user ID. If I try to force a gpupdate over VPN the computer portion passes but user fails (I have not investigated this error). If I delete the drive mappings and re-add them that works fine.
Once they're on VPN they can ping the DC and resolve with internal DNS but drives aren't mapping. When they take their lapotps home for the night the drive mappings don't work. Users logon to domain computers with domain creds and everything is great. I set one of my clients up with a few mapped drives using GPO.
0 kommentar(er)
