Monday, July 21, 2008

Active Directory Hell

First, I must state up front that I know next-to-nothing about Active Directory and that I only think the problems I've been fighting for the last week or so are AD related. Secondly, This post is mostly a rant. I will share the workarounds I have used to address my problems, such as they are, but this post shares no great wisdom. So, if you've got better things to do with your time, you can stop here.

I moved my production desktop machine from Detroit to Virginia and nothing has been the same since.

I used to work on my Tablet out of the office and now that I think about it, I had many of these same problems. DJ, though, swears that he took his development machine to a hotel for 8 days, connected over the VPN and everything worked just as it did in the office.

I think all or most of my problems are tied to my credentials not being sent properly to the domain controller.

We're not using a standard Microsoft VPN connection. We're using the MUVPN client that came with our Watchguard SOHO box (or some more recent version.) It is my understanding that when you use the MS VPN client, you can authenticate when logging into the machine just as you would if you were on the network.

In my case, I'm logging into the machine using cached credentials. This gets me into the machine, but that's about it.

The first problem was easy to fix: machine names weren't being resolved. Added some entries to LMHOSTS and HOSTS files and I could then at least double click on the entries in "my network places" and get a response that indicated that those locations did indeed exist - I just didn't have rights to access them.

I'd get a password prompt and enter my username and password and get an error that said basically "hey, do you think I'm stupid, I already tried that user name and password. Try something else." So I did, I tried an admin user name and password and sure enough I could get into those shares. For whatever reason, our admin can see stuff, just not change it.

So, I still needed to authenticate as me but couldn't figure out how to do it. In my various searches someone asked if they could gain access by issuing a NET USE command. I tried that today and sure enough, I can now access all my shares as me.

That got me past all of my day-to-day admin problems. I can open files on the server, edit them, create new ones, yahoo!.

So, my next problem - actually the first one I discovered other than name resolution - is that I can't use MS Office Accounting 2007. I had several related problems and now I think I have just one: I can't use it. MSOA07 uses a simple text file to tell the application what files to use for a particular company.

database= filename
server=servername\instancename,5356

All these values seem to be correct.

When I launch MSOA I get prompted for a file (normally it just opens the last one used.) I select the little SBC file and I get an error:

The company could not be opened or access was denied. Please ensure that access has been granted and that the company database exists.

Well, I've Googled this six ways from Sunday and I don't have any answers. I have access to the SBC file. I can open it in Notepad, change it, save it, no problem. I cannot get past this.

I can fire up SQL Server Management Studio and query the database directly. This does seem to be a bit inconsistent depending on whether or not I'm setting the database to support connections over TCP/IP. What I've read about this is over my head, but has something to do with Kerberos and NTLM authentication and the various protocols. In any case, even when I can connect from SQL Server Management Studio, I still cannot connect from MSOA.

Then today, of all things, I discover that I cannot connect to my local SQL Server instance using an ODBC connection that worked perfectly in the office. I can access the data from Management Studio, just not through the ODBC connection I've been using for well over a year. I'd come across something about this in my various searches about using '127.0.0.1' instead of 'localhost' which wasn't quite the same as my problem, but pretty close. The post I found was specifically about an error I have seen on and off the last few days: "Cannot generate SSPI context" and this was specifically about trying to connect to a local SQL Server outside the domain. I'm not entirely sure that I was experiencing the same problem described there, but nevertheless it lead me to my solution: When reviewing my DSN settings, the "Server" had the name of my machine which had been working just fine. Not entirely understanding the issues (still don't) I tried to put in the localhost IP address and that failed as well. I noticed that one of the values was "(local)" and that failed. I then noticed that one of the pre-filled choices was '.' ( a period) and that worked. Cool. I still get a "trusted connection" prompt when I first fire up the app, but everything is good after that.

So, I'm still struggling, but I've made some progress:

  1. Name resolution - solved by HOSTS/LMHOSTS entries
  2. Shares - solved by issuing a NET USE with my credentials. I only have to do this for one share on one of our servers and then the rest of my shares (under the same AD structure) work just fine.
  3. Office Accounting 2007 - no solution. (Other than I use RDP to connect to a machine on the network and get my work done that way. This is still a big problem because it doesn't get me past the stumbling block of having Outlook tied to MSOA which is how we do our time-billing.)
  4. Connecting to local SQL server - solved by using "." instead of machine name or "localhost" or "(local)" or IP address in ODBC connection. Still get prompted for trusted connection.

My biggest remaining problem is getting OA2007 to talk to Outlook and ideally run on my machine. If the one person that has read this far knows any OA experts, I'd love to get their advice.

Labels: , , , , ,

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home