How to create multiple local users on multiple remote servers?

February 8, 2011 8:03 AM

Our company has 5 Windows 2008 Standard (non-R2) servers - none of them set up on AD. I have to create usernames individually each time for each one of them when we have new employees. What would be the best avenue to pursue in order to make this process less terrible?

Company's not open to using active directory, so I'm stuck with creating local users. It involves logging into the 5 servers via RDP, creating a local user on each account, setting a password, setting permissions, etc. Then (since we're using MDaemon) it also involves setting up a mail account, and then also adding them to a SQL Server employees table. I'm not even sure where to begin - I was going to start with trying to maybe script something in PHP I can run from a command line on my local machine, but if there's a better method for this I'd love to hear it.

posted by Mali to computers & internet (13 answers total)

It's unclear why setting up AD is not the answer you want. That is obviously the simplest way to handle this.
posted by odinsdream at 8:05 AM on February 8, 2011

Trust me, I'm aware the simplest answer. For some unbelievably stupid reason, my company's not receptive to it. I've beaten my head against this wall for about the past year, roughly.
posted by Mali at 8:08 AM on February 8, 2011

*Aware it's. Frustration leads to missing words.
posted by Mali at 8:08 AM on February 8, 2011

Company's not open to using active directory

You need to solve this problem. If you have more than three servers you need a domain controller, and you need to manage your permissions centrally with Active Directory and Group Policy, and it will become an unmanageable mess in approximately zero time. Any other way of doing this is going to be awful.

You can do this by making the business case for AD. The business case here is, your time is worth money. Your processes are worth standardizing on industry norms, to both save (a huge amount of) time and mitigate (a huge amount of) risk.
posted by mhoye at 8:13 AM on February 8, 2011

Active Directory is made for this very reason.

Even if you don't integrate workstations into AD, you can use AD on the servers so they can cross authenticate for you. That would simply resolve the creating local user accounts on each server first, making sure MDaemon is configured to use AD (it does), and you may still have to create their accounts on the SQL side depending on how that is configured, but that would save about 80% of the work you are doing right now.

Otherwise you are looking at scripting use creation manually.

How do they make sure users are deleted properly or have their passwords updated? Or do they never change passwords? Or do users write down their different passwords for each of the same systems?

There are utilities for creating / managing users in AD through PHP sessions (here is one project for that), but I don't know if the same system works for local accounts, since there aren't a standard hook in place (AD is just using LDAP with special sauce for windows, it is actually the most robust implementation I have seen of LDAP for what it provides for you).

You may have better success fighting for AD than trying to code around it.
posted by mrzarquon at 8:15 AM on February 8, 2011

Even if you don't integrate workstations into AD, you can use AD on the servers so they can cross authenticate for you.

Have you already explored this scenario? To be clear: installing and using AD can just be on the servers. There's no reason you also need workstations to join the domain. It would just be the servers, and you can actually still create local user accounts on the servers after AD is installed.

You're going to be re-creating AD's functionality with whatever you do, and you're going to do it very, very poorly in the best case.
posted by odinsdream at 8:50 AM on February 8, 2011

Ok, so, seeing your followup: I'm sorry you're in this position. Get these tools by by Mark Russinovich. I've had similar problems, but have been able to gin together some batch scripts using PsPasswd that did the right thing.

I did all of that on desktops, though, not on production servers, so you should really be just extremely cautious about this sort of thing. Get yourself a virtualized test environment, if you don't have one already.

There's no reason you also need workstations to join the domain.

Jesus, what a nightmare. I bet people are even administrators of their own desktops. I'm sorry you're in this position. It's a tough spot, and it occurs to me that what you really need to be doing here is polishing up your resume.
posted by mhoye at 8:54 AM on February 8, 2011

@mhoye - You know it. Folks have full admin rights on local machines. Granted, it's only a 25 person company, but it is still absolutely an administrative nightmare.
posted by Mali at 8:57 AM on February 8, 2011

Jesus, what a nightmare.

How is it any worse than what Mali has now? Workstations are already off-domain. Adding a domain for use between the servers only eases the administrative burden of account management on the servers. Mali, can you explain why using a domain between just the servers would not be a solution? I can (kinda) understand how management would not want to do a full deployment for all users, but what is it to them if the servers are on a domain?
posted by odinsdream at 9:39 AM on February 8, 2011

You can even tie in workstations to AD just for single signon and still give them full admin rights on their machine (either add each user to the local admin group on their machine, or add domain users to give everyone admin rights to everyone, not much different than there is now).

After that, you just have to get their accounts migrated from local to AD, which there is a tool for.

I do this for 5 person shops because there is time saving for them at that scale, and they are paying for me at $100+ an hour to do it, a 25 person shop this would be mandatory before we would even start doing anything else, because otherwise they would complain about the ongoing support costs.

But yeah, start with going for AD on the servers first, they really wont notice it (except for possibly new passwords and having to login as foo\username). Just be nice to the future mac folk, and create the domain using .lan instead of .local and don't ever use their external domain name for it.
posted by mrzarquon at 10:33 AM on February 8, 2011

How is it any worse than what Mali has now?

Don't get me wrong; I am just saying that the situation mali has now is a nightmare, not that your solution is making it worse.

If you have more than about ten machines or three servers to administer, you absolutely must have a domain controller, or your life will be hell. Mali: Start polishing up your resume and prepare to go somewhere where your advice is valued.
posted by mhoye at 12:04 PM on February 8, 2011

I'm going to make a serious push for AD at this week's meeting, because this is starting to drive me absolutely bonkers.
posted by Mali at 12:23 PM on February 8, 2011

You can use vbs scripting to automate these tasks. You'll need to rerun the script once per server.

AD is the better solution. I sympathize. I once worked for a company that small and at that size there's a lot of ignorance about IT and small company politics of "letting the IT guy control everything?! No way!"I also have worked in placed where I alone was the driving force to take away admin rights. The politics, bitching, and general animosity of doing this was highly unprofessional and really made me dislike a lot of people. Even if you get permission you need a good migration plan to go from this ad-hoc system to AD and maintaining permissions/mail/whatever and some good social skills to deal with office assholes who see good IT management as some kind of insult to their honor and independence.
posted by damn dirty ape at 12:00 PM on February 9, 2011