If possible to add domain user to a workstation's local administrators group by scrpting?

I am wondering if possible to add domain user to a workstation's local
administrators group by scrpting.

You konw, in most scenario we use {objLocalGroup}.add function to achieve
this target, but what if a workgroup?
When I try this on workgroup, script prompts fails with "unknow user name or
bad password".

Any ideas?

Owen
Mon Mar 17 12:24:47 CDT 2008

On Mar 17, 9:38=A0am, "jogging" <v-xi...@microsoft.com> wrote:
> I am wondering if possible to add domain user to a workstation's local
> administrators group by scrpting.
>
> You konw, in most scenario we use {objLocalGroup}.add function to achieve
> this target, but what if a workgroup?
> When I try this on workgroup, script prompts fails with "unknow user name =
or
> bad password".
>
> Any ideas?

Workgroups don't recognize domains so you won't be able to do this
unless you join it to the domain of the user you want to add.
If the machine is not part of the domain, there's no way for it to
know who that domain user is, so therefore it can't be added to the
Administrators group.

Richard
Mon Mar 17 12:30:22 CDT 2008

jogging wrote:

>I am wondering if possible to add domain user to a workstation's local
>administrators group by scrpting.
>
> You konw, in most scenario we use {objLocalGroup}.add function to achieve
> this target, but what if a workgroup?
> When I try this on workgroup, script prompts fails with "unknow user name
> or bad password".

You can add a domain user to a local group if you are authenticated to the
domain. Otherwise, the domain object cannot be found.

If you are logged into another computer joined to the domain, and you are
authenticated to the domain, perhaps you can use alternate credentials to
bind to the workgroup computer. Otherwise, if you are authenticated to the
workgroup computer, perhaps you can use alternate credentials to bind to the
domain object. For example:
======
Const ADS_SECURE_AUTHENTICATION = &H1
Const ADS_USE_ENCRYPTION = &H2

strUser = "MyAdmAcct"
strPassword = "xyz321q"

Set objNS = GetObject("WinNT:")
Set objDomainUser = objNS.OpenDSObject("WinNT://MyDomain/JimSmith,user", _
strUser, strPassword, _
ADS_SECURE_AUTHENTICATION Or ADS_USE_ENCRYPTION)
===========
You can use similar code to bind to a local object remotely while
authenticated to the domain. The ADsPath would specify the NetBIOS name of
the local computer rather than that of the domain.

--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--

CoreyThomasMCSEMCSAMCDBA
Mon Mar 17 13:01:03 CDT 2008

So code similar to this will not work?

strComputer = "atl-ws-01"
Set objGroup = GetObject("WinNT://" & strComputer & "/Administrators")
Set objUser = GetObject("WinNT://fabrikam/kenmyer")
objGroup.Add(objUser.ADsPath)


-Corey

"jogging" wrote:

> I am wondering if possible to add domain user to a workstation's local
> administrators group by scrpting.
>
> You konw, in most scenario we use {objLocalGroup}.add function to achieve
> this target, but what if a workgroup?
> When I try this on workgroup, script prompts fails with "unknow user name or
> bad password".
>
> Any ideas?
>
>
>

Richard
Mon Mar 17 13:52:54 CDT 2008


"Owen Gilmore" <aogilmore@gmail.com> wrote in message
news:3172189a-2467-4ed8-b60a-3072eb9d50e2@e10g2000prf.googlegroups.com...
On Mar 17, 9:38 am, "jogging" <v-xi...@microsoft.com> wrote:
> I am wondering if possible to add domain user to a workstation's local
> administrators group by scrpting.
>
> You konw, in most scenario we use {objLocalGroup}.add function to achieve
> this target, but what if a workgroup?
> When I try this on workgroup, script prompts fails with "unknow user name
> or
> bad password".
>
> Any ideas?

Workgroups don't recognize domains so you won't be able to do this
unless you join it to the domain of the user you want to add.
If the machine is not part of the domain, there's no way for it to
know who that domain user is, so therefore it can't be added to the
Administrators group.
---------

I don't have any workgroup computers to experiment with. If my suggestion of
using alternate credentials works, then the local machine will add the SID
of the user to the group. You will be able to see that the SID is a member,
but the OS will not be able to resolve the SID to a name.

The other issue, of course, is that the domain user will not be able to take
advantage of the group membership, as they cannot authenticate to the
machine with their domain account. They would need to first authenticate
with a local account, then use alternate credentials to authenticate to the
domain with their domain account (if this can even be done).

I have done this, authenticated to a computer with a local account, then
used alternate credentials to authenticate to a domain with a domain
account, but the computer was joined to the domain. I don't know if this is
possible when the client is not joined to the domain.

--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--

jogging
Mon Mar 17 21:17:18 CDT 2008

Thanks for all yr help.

But Richard,in my script I have already get a domain user account SID
through OpenDSObject function, of course the script was running on a
workgroup rather than a domain member server.

But the problem is, when I pass the objDomainUser to objLocalGroup.add (this
is the recommended way to add a domain obj to local group), seems it
couldn't open objDomainUser.ADsPath from current xecurity naming contex.

I think the problem was objLocalGroup.add itself.
Any ideas else?

"Richard Mueller [MVP]" <rlmueller-nospam@ameritech.nospam.net> wrote in
message news:uK6JeSFiIHA.4076@TK2MSFTNGP05.phx.gbl...
> jogging wrote:
>
>>I am wondering if possible to add domain user to a workstation's local
>>administrators group by scrpting.
>>
>> You konw, in most scenario we use {objLocalGroup}.add function to achieve
>> this target, but what if a workgroup?
>> When I try this on workgroup, script prompts fails with "unknow user name
>> or bad password".
>
> You can add a domain user to a local group if you are authenticated to the
> domain. Otherwise, the domain object cannot be found.
>
> If you are logged into another computer joined to the domain, and you are
> authenticated to the domain, perhaps you can use alternate credentials to
> bind to the workgroup computer. Otherwise, if you are authenticated to the
> workgroup computer, perhaps you can use alternate credentials to bind to
> the domain object. For example:
> ======
> Const ADS_SECURE_AUTHENTICATION = &H1
> Const ADS_USE_ENCRYPTION = &H2
>
> strUser = "MyAdmAcct"
> strPassword = "xyz321q"
>
> Set objNS = GetObject("WinNT:")
> Set objDomainUser = objNS.OpenDSObject("WinNT://MyDomain/JimSmith,user", _
> strUser, strPassword, _
> ADS_SECURE_AUTHENTICATION Or ADS_USE_ENCRYPTION)
> ===========
> You can use similar code to bind to a local object remotely while
> authenticated to the domain. The ADsPath would specify the NetBIOS name of
> the local computer rather than that of the domain.
>
> --
> Richard Mueller
> Microsoft MVP Scripting and ADSI
> Hilltop Lab - http://www.rlmueller.net
> --
>
>

Owen
Tue Mar 18 12:26:25 CDT 2008

On Mar 17, 7:17=A0pm, "jogging" <v-xi...@microsoft.com> wrote:
> Thanks for all yr help.
>
> But Richard,in my script I have already get a domain user account SID
> through OpenDSObject function, of course the script was running on a
> workgroup rather than a domain member server.
>
> But the problem is, when I pass the objDomainUser to objLocalGroup.add (th=
is
> is the recommended way to add a domain obj to local group), seems it
> couldn't open objDomainUser.ADsPath from current xecurity naming contex.
>
> I think the problem was objLocalGroup.add =A0itself.
> Any ideas else?

If you want more ideas you need to clarify what you mean by workgroup
and what you hope to accomplish by doing this. If you're talking
about a Domain Local group, that's something quite different from a
workgroup.

It's already been explained why what you want can't be done on a
computer that's not joined to your domain. It's probably the way
you've got your machine set up and not the script function that's the
problem. Either that, or the account it's run with can't do it due to
security.