This is a good "from the trenches" story, especially if you like networking. I've been working on this problem for exactly a week (no, not a crazy long time, but still, it's a while) and today I finally fixed the issue.
At work our main application for hr, payroll, general ledger, and employee self-service is called Springbrook. It's a nice, though slightly bloated, application that works for us. It's important to know how Springbrook is used for this story to make sense. Please bear with me while I give you the rundown.
The Springbrook application is installed on server1 along with the programs OpenEdge and Progress to handle all of the data processing for Springbrook. We have a separate drive just for Springbrook, OpenEdge and Progress. When the app is executed, the login page is opened in Internet Explorer. Springbrook uses the LDAP protocol (in our case Active Directory) to authenticate the user trying to login against the login id’s already inside of Springbrook, so when the session is established it requires that the user logs in and is authenticated to the domain which in turn makes the connection to the LDAP connector which verifies user info and allows them access.
How do the users run Springbrook? I have setup a mapped drive to the server on their workstations. I setup a desktop shortcut to the executable so the employees don't have to go that mapped drive each time and double-click the executable. So, it looks and feels like Springbrook is installed locally on their workstations.
This setup works great for local users right? What about remote users? We have those. One currently, but we're about to have one more permanent remote user. I decided to go with the VPN option in our Sonicwall TZ 210. It worked great. It was fast, surprisingly, and the user didn't have to go through remote desktop to use Springbrook which was nice. I mapped a drive to the server so she was able to use it just like the local users do. Fantastic.
Well, eight days ago Springbrook ran a service pack for the application. No problem because they do that on occasion to correct problems in the modules. The next day my remote user couldn't use Springbrook. I asked her if the VPN connected fine and she said "yeah, I can connect to the network, but I can't login to Springbrook." I told her to wait and I would be there in about fifteen minutes. I went through the checklist and found that nothing should be preventing her from logging in to Springbrook. I was so confused. The only change was the service pack install. I contacted Springbrook about this and the tech told me that somehow the authentication isn't happening in the VPN tunnel.
Okay. I knew that, haha
He then said that they use Citrix for their remote employees. I'm sure Citrix has a very nice WebApp tool, but if I can do this through a VPN tunnel and save us money that would be great. I don't like to go with paid solutions if we can implement a solution with equipment and software we already have. So, since I couldn't figure the problem out I decided to hit the forums. A person at serverfault recommended the VPN option in Windows Server 2008. I thought, "Why not?" I set that up in my lab. The VPN connection was fast, smooth, and near painless. *I'm going to write a blog post about it because it's so simple and there wasn't a single post containing all of the steps, instead I had to piece it together from multiple posts - ugh* Anyway, I connected to the VPN server, accessed the Springbrook share, ran Springbrook and guess what? I couldn't login to Springbrook. THE EXACT SAME PROBLEM. I understood possibly having an authentication issue using Sonicwall's VPN but there is no way that my server couldn't authenticate me because I connected to that server with my Active Directory credentials.
I was livid. Suddenly, I thought, "Why don't I try adding the .local to the domain name in the domain field?" The Springbrook login window requires a username, password, and a domain. All users and I mean all of our users don't have to put the .local for the domain however when you're up against a wall you try anything. I added .local to the domain name and then Springbrook launched. That fixed the issue. I couldn't believe it. I then wondered if that was the problem going through Sonicwall? I called the remote user, asked her when I could work on this for her, she said now and so I went to her office. I enabled the Sonicwall VPN connection, ran the Springbrook application, added the .local to the domain name and like a charm I was running Springbrook. The user was happy and yeah I was happy, but I want to know why I have to add .local to the domain name when logging in remotely now. Remote users didn't have to do that before last week. Why now?
I'm not satisfied. Could it be the recent Springbrook service pack update? I contacted Springbrook support and hopefully I'll hear back from them soon.
Anyway, lesson is try the easy things first. Like usual.