Local Machine Accounts


??? ??? ?
Political Access
8 Apr 2005
My company implemented a "strong" password policy on 8/22, problem is it breaks one of our "home-grown" applications. We have this program, let's call it "Application X", that feeds off of two local user accounts - let's call them USER1 and USER2. In some cases, you have to delete and re-create USER1 and USER2, with very specific passwords that are coded into the application itself.

Due to this policy, you can't use the passwords that the program needs to work since they don't meet the criteria. The only fix we have at the moment, is to remove the machine from the domain, make the change (since the domain settings are no longer applicable), and then re-add it.

Couldn't I just essentially reset the security template, without having to remove from the domain?

Any thoughts on how to create passwords for LOCAL accounts that don't meet DOMAIN criteria, without removing them?
im trying to figure out what application needs two local user accounts...

Can you set it where you have to log on the domain via a true domain account prompt? Leaving the account local. That makes sense to me but im very tired.
Well it's a home grown application, the machine accounts are local because they logon as system services. It could be changed, but as I mentioned it is coded into the application for these usernames and passwords to perform certain functions. In order to change it, it would cost a large amount because a decent chunk of the program would have to be re-written, or so I'm told.

Kinda hard to explain really, and it's a poorly designed program IMO but the need still exists to find a way for local accounts to somehow operate outside of domain policies with regards to password standards.
Since the account names and passwords never really change, they just have to be deleted and re-created, would it be possible to perform this via a script, and force to the local policy rather than the domain policy?
Mixture of both actually, we still have some 2K boxes out in the wild.

Both are on the domain obviously, and both run the application.
Personally, I wouldn't have applied the policy to the domain, instead applying it to the OU that the users are apart of.

Domain_Users (Policy Applied Here)
'--- User_Group1
'--- User_Group2
Agreed, but things like that are out of my control. Out of most everyon'es control actually, as my company is a subsidiary of a bigger company, which forces down most of our policies, this password change included.

I'm just looking for a more efficient way to do this, rather than knocking a machine off the domain to do it.
I want to try and approach this in pieces...

I know how to write a script that will delete an account from a domain, but how can I write a script that will delete an account that is local to the machine?

Once I have that, I'll try to play around with seeing if I can force the script to look at the local policy, rather than the domain policy.
sorry it took me so long to chime in here.. took a couple days off work over the labor day weekend here and have been trying to get caught up locally.

Do you want this in VB or in DOS Batch?

edit: not sure how we'll work around the policy.. is it possible for you to apply a different password policy to the OU that this machine belongs in? A password policy on the OU will not affect domain accounts (those will still be affected by the domain policy requirements, but it will impact the local account password requirements)

edit2: in DOS you can just user "Net user" commands to add/remove local accounts and set passwords. VBScript will take a couple more lines of code to do..

Depending on how your passfilt is setup, it may or may not allow you to set the password. If you can't do it now as an admin on the local machine, neither DOS or VBScript will probably allow you to set the password either.
Last edited:
No problem fitz, and thanks for your input.

Unfortunately, the whole domain is in a single OU (sigh), and I can't change that. So unfortunately I can't get creative with how the policies are applied or filtering of the such.

I'm playing around with netdom.exe, I might be able to write something that doesn't require a reboot. Worst case scenario though I will still have to reboot inbetween, so that's a bit pointless.
Even if it's all in one OU, they can enforce a domain wide policy on domain accounts by applying the policy to the domain and create a second password policy on the OU that will only affect local accounts..

But, it sounds like you don't have much input/influence to change their OU or their policies so you may be out of luck there..
Actually that may be something I could at least suggest, do you have any links or info regarding that?


Best I can tell, you can only have one password policy per Domain, unless you kick into different OU's.
Last edited:
The domain policy would be applied at the domain level. This would affect all the domain accounts.

If you create a seperate policy and specifically disable the strong password filters and apply it at the OU level, it will only impact the local computer accounts. The domain users are still bound by the domain policy.

So, yes, in a sense, you can only have one password policy per domain because if you try to create another one, it doesn't affect the domain accounts.. but it will affect the local accounts of where the policy is applied..

Domain <--domain password policy applied here (strong passwords required)
-> Domain Computers (second password policy applied here)
-> Domain Users

edit: here.. found the link (http://technet2.microsoft.com/Windo...b53d-41d0-9867-199f6595a01b1033.mspx?mfr=true)

The policy settings under Account Policies are implemented at the domain level. A Windows Server 2003 domain must have a single password policy, account lockout policy, and Kerberos version 5 authentication protocol policy for the domain.Configuring these policy settings at any other level in Active Directory will only affect local accounts on member servers. If there are groups that require separate password policies, they should be segmented into another domain or forest, based on any additional requirements.

By default, workstations and servers joined to a domain — the domain member computers — also receive the same account policy for their local accounts. However, local account policies for member computers can be differentiated from the domain account policy by defining an account policy for the OU that contains the member computers.
(emphasis added)
Last edited:
I was actually able to figure something out along those lines myself when I was tinkering. Now I just have to write it up and test it.

Thanks Fitz, your a genuis :D
*blush* aww.. shucks..

I'm gonna get a Big head now! :)
You should have one. You really know what you're talking about and it's obvious with your posts. Good information.
I'm putting a proposal together tomorrow, everything has to be submitted for review :dead:

I am also going to present the option of using Global Groups. By this I will put all the machines that the software runs on, in a Global Group. Make a policy JUST for the strict password policy, and then the domain policy which will not have the password strength in place. Then, I will deny the Global Group from applying the strict policy.

Makes sense in my head, just a long day.

Maybe I'll post the proposal, should be good :D

Members online

No members online now.

Latest profile posts

Also Hi EP and people. I found this place again while looking through a oooollllllldddd backup. I have filled over 10TB and was looking at my collection of antiques. Any bids on the 500Mhz Win 95 fix?
Any of the SP crew still out there?
Xie wrote on Electronic Punk's profile.
Impressed you have kept this alive this long EP! So many sites have come and gone. :(

Just did some crude math and I apparently joined almost 18yrs ago, how is that possible???
hello peeps... is been some time since i last came here.
Electronic Punk wrote on Sazar's profile.
Rest in peace my friend, been trying to find you and finally did in the worst way imaginable.

Forum statistics

Latest member