Thanks for a great article, Steve. We are using most of the conventions described in it (OK, maybe not "15-20 character, mixed case, numbers, letters, very strong passwords") and at times I've wondered if the extra work setting it up was worth it. After reading your article I no longer have those doubts.
I also wanted to share experiences similar to those in the post from LP in the hopes others may benefit. I apologize if this topic has been covered in previous articles/posts.
I had some struggles when first developing DTS jobs using "Windows Authentication" and scheduling them with Server Agent. I'd develop the jobs using an account with Sys Admin privileges (poor practice) and wonder why they didn't work when scheduled with Server Agent. Then I realized when I ran the job from DTS designer on my workstation it used MY domain account's security context (and my workstation's file system context) but when I ran the job from Server Agent it used Server Agent's domain account security.
As soon as I adopted the practice of creating SQL Server logins from windows domain groups, putting them in database roles, and granting permissions to the roles, life got much better. I have a "normal" test domain account that I put into the appropriate domain group. I then log into my workstation with it and test the DTS job in DTS Designer. I also create a Server Agent domain account login on the target SQL Server(s), add it to the appropriate SQL Server role(s) and rest assured it will not run with reduced permissions. This works for server to server jobs because the Server Agent account uses Active Directory authentication to the target servers. If security problems are still suspected, one can always dig out that paper list of very strong passwords and log in to their workstation with the Server Agent account to brute force test it directly in Designer.
It would be much cleaner to put the Server Agent domain account in the domain group (instead of the SQL Server role on the target server) , but changes in domain group memberships are only recognized at log in. (If you're already logged in with an account and you add it to a domain group, your "session" won't reflect addition to the group.) So, you'd have to stop and start the Server Agent service for its new domain group membership to be recognized. In some cases that's no big deal, in others it may not be practical.