Forgive any ignorance this question may indicate and any lack of necessary details that it may have. I'm coming into a situation late, and I don't have a way to get more detailed info (it's a political thing).
Here's the situation: we've got a recently acquired subsidiary that we're trying to integrate into our environment. They are in a Windows 2000 Active Directory environment. One of the early steps is to do away with the sub's need for their own ISP. We're connected via a dual T-1, so the connectivity is there. The next step is to have their remote users gain network access via VPN through our environment, and that's part of the problem. When their laptop users are connected to the sub's LAN, Internet browsing is fine. However, when they test over an isolated DSL line, the laptops cannot use SSL at all. Here's the rub--the lone tech on-site CAN use SSL, but only with his own laptop. If he logs on as a local admin on another laptop, SSL doesn't work. He insists that he's configured the 2nd laptop to be identical to his own, but that doesn't seem to be the case.
I'm not very experienced with AD (we're an eDirectory shop), but this sounds like some form of Group Policy issue, maybe for machines, but I don't know. Again, I apologize for my ignorance, but does any of this sound familiar to anyone?
Over the DSL line (testing from additional line at office), users can surf, but can't get to SSL. We have remote connectivity via Citrix (https://remote.company.com), but users can't get there over DSL. That answers another of your questions--it's just SSL, not VPN over SSL. The local tech is the only user on his laptop, but neither he nor an average user can hit SSL on other laptops over the DSL.
Are you sure this isn't a firewalling issue somewhere? Sounds like port 443 is closed somewhere. The way to test if this is an AD policy based issue is to move your machine and user account to a policy-free OU. When this refreshes you can test a standard laptop build to narrow down the possibilities. You can determine if it's user or machine based by using an account in your locked down user's area on an unrestricted machine. This may explain your tech's connectivity. Also be aware that you can have deny GPO based on group membership. Use the GPMC's Group policy results section to see the combined affect of your policies on a per user:per machine basis. also don't forget the gpresult.exe that can be run from the command line.
If one laptop can get out and the rest can't...
Check:
1) firewall or router ACLs that block by IP range
2) GPO's that activate IP blocks on the local workstations
3) Target server host-based ACLs that may be prohibiting access
4) a dynamic or static vlan that maps *that* laptop MAC address or port to a special vlan with special rights/privs/access.
Try something as simple as service ping.
try telnet 10.x.y.z 22 and see if you get an SSH prompt from the commandline of your client.
Good luck!
-april
As I suspected, it was a rogue Group Policy. The on-site tech opened a case with MS, and they were able to find the policy and change it. I still have to get the details, but I wanted to keep everyone up-to-date.
Thanks to all who took the time to share some insight. I appreciate it.
Free Guide: Managing storage for virtual environments
Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!
Discuss This Question: 4  Replies