Don't use generic domain names

Posted on Posted in Uncategorized

Ever since I start­ed on my newest client's project over a year ago, I've had prob­lems with their VPN. When con­nect­ed, I could no longer authen­ti­cate to remote Share­point or SQL servers on my local net­work (rend­ing my VMs use­less), name res­o­lu­tion would be fine for awhile and then stop resolv­ing (mak­ing it a race to sync up source code with their serv­er before I could no longer see it), group poli­cies failed to update... any­thing that could go wrong seemed to on a very reg­u­lar basis.

When vis­it­ing the client's site last year, I found that I could not log into my lap­top with my domain's cre­den­tials while plugged into their net­work. It became a game of turn off the wire­less, log in to my lap­top, turn wire­less back on. We even­tu­al­ly fig­ured out that my domain name (the nice and gener­ic DEV/dev.local) was con­flict­ing with their DEV domain. While plugged into their net­work, my lap­top would sud­den­ly send login requests to their DEV domain con­trollers. The same thing hap­pened when con­nect­ed through VPN, caus­ing SQL and Share­point to believe a hijack attempt was underway.

Over a year lat­er, I final­ly got around to renam­ing the domain to a less gener­ic BLUEYDEV/blueydev.local and sud­den­ly every­thing works. I can final­ly work con­nect­ed to VPN and source con­trol rather than try­ing to sync every­thing up as quick as pos­si­ble when connecting.

The moral of the sto­ry: When set­ting up your domain, nev­er give them gener­ic names that oth­ers might use, like DEV or TEST. This is espe­cial­ly impor­tant for lap­tops that you may be con­nect­ing to cus­tomers' networks.

Leave a Reply

Your email address will not be published. Required fields are marked *