Using Powershell to manage Alchemy - Add local users to a Role

Today in an Captaris Alchemy class I got an interesting question. One of the students has a customer who wants to use local users instead of domain users when setting up integrated security. Integrated security is where you can authorize users to view databases, folders, and/or files based on the username they are logged in as. Normally associating the database ‘roles’ with domain users makes the most sense, but occasionally there is a need to set up local users. Now the problem is that the Server Console UI doesn’t allow for anything other than domain users. So the only way to add a local user is through the Alchemy API. Before Powershell that would have probably meant breaking out Visual Studio. But now I think it is far easier to deal with. Here is a sample script that will take two parameters: a role name you want to add a user to, and a user name in the format servername\username.

param($role=$(Throw "A role name is required..."),
    $user=$(Throw "A user name in the format SERVERNAME\USER is required..."))
$alc = new-object -com auserver.application
$alc.connect()
$alc.addroleuser($role,$user)

If you name this script set-roleuser.ps1, then to add the user capa\bob to the sales role, just runset-roleuser sales capa\bob. That was easy.

Comments

[Malcolm]

Why would you violate security practices?

[admin]

....but this wasn't for a lazy admin, but rather for the instance where there were no domain users. I don't remember all the details, but I think they were a novell shop. if there are no domain users, then local users are all you have. They had a question: can we set up integrated security for local users. It wasn't immediately apparent how to do that. This solves their problem. The alternative would be to come up with something that lets them use novell domain users, and sync with AD/NT domain was not an option.

[Malcolm]

If there are no Domain users, why are they worried about Integrated Security?

[admin]

I don't see where you are getting the idea of "sacrificing security". Adding yet another password to remember increases the chances of passwords being written down in some obvious location. But more importantly, this solved this one customer's problem. Would I recommend every company go this route? No way.