AD account locked when accessing shares remotely with Vista Ultimate
I have a user that will work from out of the office on occasion over a VPN connection. This has worked fine until he was given a new laptop running Windows Vista Ultimate. Now he can no longer access the shared drives on our Windows 2003 server. All our XP clients that work remotely have no trouble, but when this Vista user logs in to the VPN and tries to access one of the shared drives, his AD account gets locked out and has to be reset. It works fine when the user is in the office on his Vista laptop, but over the VPN the user account is locked as soon as access to a Windows Server 2003 shared drive is attempted. Does anyone have any ideas? This is the only remote Vista user we have so far, but it won't be our last so I'm hoping someone has some insight. One other thing to note is that our Red Hat Linux share poses no problems for this users, but it is also managed outside of Active Directory. Anyone?
What do you have your tries set to until it locks. When Windows fails a login, it tries several times (not sure about Vista for how many times it tries). This is most likely why it locks the account as its sending wrong credentials (by default the ones you log in with; but Vista I'm not positive)
First thing I would try is a wireshark sniff to see exactly how Vista is trying to login. Once on the network when it succeeds and then again via VPN to see the differences. Also, like JjcampNR mentioned, the logs will be of help to you as well, but sometimes the traffic captures give data you don't see elsewhere.
First thing I would try is a wireshark sniff to see exactly how Vista is trying to login. Once on the network when it succeeds and then again via VPN to see the differences. Also, like JjcampNR mentioned, the logs will be of help to you as well, but sometimes the traffic captures give data you don't see elsewhere.
OK, I've setup a Samba share on my Linux box and found a few things that may help you when trying to connect from Vista (which I finally got working)...try the following:
On your Vista box, go to a run box and type in: secpol.msc
Next, go to: Local Policies > Security Options
On the right, find the "Network Security: LAN Manager authentication level" setting and it from "Send NTLMv2 response only" to "Send LM & NTLM - use NTLMv2 session security if negotiated"
Samba does not yet look to fully support NTLMv2, which may cause a problem authenticating - although I'm not sure this will fix your issue since you said it will only fail over VPN, but it's definitely worth a try. If it doesn't fix your problem, simply switch it back to the original value - no harm done testing it.
Also, how are you handling authentication to the Samba share since you said it's not being done by AD? You might want to instruct your user to try using an exact name instead of just his user name. For example, if users are supposed to use their domain user names to log in, try having the person use: "username@domain.com" or "domain\username" instead of just "username". If the users are supposed to use a name that's local to that Linux box (if you gave them all local accounts on the Red Hat server to access the share), try having them use RedHatServerName\username or username@RedHatServerName instead of just their username.
Any info on how you do your authentication or lines from your log would be extremely helpful. Without that info it's a bit like wandering around in a dark room.
On your Vista box, go to a run box and type in: secpol.msc
Next, go to: Local Policies > Security Options
On the right, find the "Network Security: LAN Manager authentication level" setting and it from "Send NTLMv2 response only" to "Send LM & NTLM - use NTLMv2 session security if negotiated"
Samba does not yet look to fully support NTLMv2, which may cause a problem authenticating - although I'm not sure this will fix your issue since you said it will only fail over VPN, but it's definitely worth a try. If it doesn't fix your problem, simply switch it back to the original value - no harm done testing it.
Also, how are you handling authentication to the Samba share since you said it's not being done by AD? You might want to instruct your user to try using an exact name instead of just his user name. For example, if users are supposed to use their domain user names to log in, try having the person use: "username@domain.com" or "domain\username" instead of just "username". If the users are supposed to use a name that's local to that Linux box (if you gave them all local accounts on the Red Hat server to access the share), try having them use RedHatServerName\username or username@RedHatServerName instead of just their username.
Any info on how you do your authentication or lines from your log would be extremely helpful. Without that info it's a bit like wandering around in a dark room.
ASKER
I'm not sure if you read the question correctly JjcampNR, unless I'm misunderstanding your solution, but I do appreciate that you're trying to help. The Red Hat share DOES NOT have any problems whether it's in the office or remote over the VPN. The problem lies with the shares on our Windows Server 2003 machine. My user can access the Red Hat share without any trouble, but when he tries to access the Windows share over the VPN connection, which uses Active Directory, his AD account becomes locked. This only happens over the VPN though, and the user has no trouble when he's in the office.
I also had found that the NTLM settings needed to be changed, so they are already set to use LM & NTLM. This was a problem I encountered initially, but I already had found that fix. Again, the only problem he has occurs when he tries accessing a Windows Server 2003 share over a VPN connection with Vista Ultimate, and it seems to have something to do with Active Directory. Group policy is set to lock the account after 5 unsuccessful attempts. I just thought of one thing; I haven't tried remapping the drive after the VPN is connected. It's not that I should have to, but since the account was locked I ended up overlooking that option. I'll try that and see what happens. Thanks again for your input.
I also had found that the NTLM settings needed to be changed, so they are already set to use LM & NTLM. This was a problem I encountered initially, but I already had found that fix. Again, the only problem he has occurs when he tries accessing a Windows Server 2003 share over a VPN connection with Vista Ultimate, and it seems to have something to do with Active Directory. Group policy is set to lock the account after 5 unsuccessful attempts. I just thought of one thing; I haven't tried remapping the drive after the VPN is connected. It's not that I should have to, but since the account was locked I ended up overlooking that option. I'll try that and see what happens. Thanks again for your input.
Ahhh, I did read the question wrong - thanks for the clarification. OK, so what type of VPN is this? Are you using RADIUS or anything else to authenticate users?
ASKER
It's a VPN set up on our firewall, with all authentication done there. The VPN accounts are defined on the firewall as users, and no outside sources are used to define the users other than what's on the firewall. This is all just really odd because we haven't had any trouble, and still don't, other than this one user who is using Vista. It's definitely an Active Directory authentication thing, but I can't find any references to a similar problem yet. I also haven't ruled out the possibility of it having something to do with our firewall and some weird Vista compatibility problem. Maybe I'll post something on the forums for the firewall (Fortigate-60).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I still haven't figured this issue out, but have instead set up the user to use a terminal server to access the shared drives from home. JjcampNR was the most helpful, so thank you and the points are yours. I'm going to leave this problem alone until it comes up again.
If it does come up again, I'll be happy to help however I can.
Make sure you're looking at the Samba log at a time when the user is trying to authenticae from home, otherwise you may not see any related entires in the file.