none
Added domain account to local group (non-domain-joined PC)

    Question

  • At a point in the distant past, I figured out how to add a domain account (maybe just using the SID?) to the local Administrator group on a non-domain-joined PC. I need to do it again, because I need to update our Windows XP image and have to start with a fresh install.

    I found this MDSM blog which indicates it is possible, but I don't understand how to implement the code.

    Thanks

    Tuesday, July 12, 2011 7:41 PM

Answers

  • ah... i think i see the problem.  but it's the same problem we've been discussing as before (sort-of).  so you apparently joined the computer to the domain (that's great).  and you say when you log in with your DA credentials, the script runs fine but when you log in with the local administrator, you get Network Path Not Found...  which makes complete sense (maybe).  To test my theory, log into yoru computer with your local account, use runas to execute another cmd shell as your DA, this should run just fine to do what you want.  Then runas another cmd shell with a normal user account -- this should fail.  it shouldn't fail because of network path not found but because access is denied.  then run your script with just your local admin.  my assumption is that the winnt provider is using the local admin credentials which will fail against trying to enumerate the local domain.  but add the script (using gpedit.msc) to the startup script) and then reboot.  you either have to do something like this or use credential impersonation to use alternate credentials....

    Tuesday, July 19, 2011 8:39 PM
  • In the past, when we've joined golden-image machines to the domain before capturing the image, things have broken. The example that comes right to mind is that the security descriptor for Windows update have broken in the cloned PCs.

    This sounds like a separate problem. If I remember correctly, the image can be corrected so you don't encounter this problem. (Not a topic for this forum)

    The PCs that should have this domain group as a local admin are co-mingled with those that should not have that setting. Additionally, we regularly re-image machines so there is no practical way of keeping computer group membership accurate

    This seems like a good argument for adding the needed accounts after imaging, not before.

    Bill

    Tuesday, July 19, 2011 10:16 PM

All replies

  • Hi,

    While this may be possible, I doubt it is supported. I would recommend joining the imaging PC to the domain, adding the domain accounts, unjoining it, and then run Sysprep.

    Bill

    Tuesday, July 12, 2011 9:38 PM
  • If the user naem and password are the same then just create an account that mqtches the domain caccount and pu ti in the admins group.

    It is called a proxy login.


    jv
    Tuesday, July 12, 2011 11:14 PM
  • Since you're updating your image (singular) I take it this domain user should be present on all your clients? If so, I don't think scripting this is the way to go.

    I would use a GPO and GPP or the restricted groups setting to make sure that the user (or group) is always present on the clients.
    I wrote something about it a while back (I really should add more pictures!):
    http://ahultgren.blogspot.com/2011/03/domain-computers-local-administrators.html

    If it should only be present on some clients, you can narrow the GPO scope/security filtering and/or GPP item level targetting.

     


    Andreas Hultgren
    MCTS, MCITP
    http://ahultgren.blogspot.com/
    Wednesday, July 13, 2011 7:54 AM
  • Even if it is possible (which I doubt (and your link to your article is missing, incomplete, or dead)), why would you want to add a domain account to a computer that wasn't on the domain?  ...just use the local Administrator account (or renamed local Administratror) to do whatever it is you need to do.

    If you have to start with a fresh install, why not just wipe/reload and use the default administrator account?

    If your computer is on your network but just not on the domain, you can use domain\user still but depending on how your DNS/DHCP configuration is set, you may have to specify the FQDN instead of the NETBIOS name.  So lets say your domain is corp.mydomain.com and your NETBIOS name is just Corp, when you're adding a user to your machine, you'd need to specify corp.mydomain.com\myUser.  But this fix presupposes that your off-the-network computer is configured to point to DNS servers that can resolve your domain and actually validate that the user you specify exists...

    Wednesday, July 13, 2011 11:48 AM
  • I aree that it should be a GPO.

    Domain and non-domain accounts alike can be added with a GPO.  A little knon thing is that computers with a Workgroup name can partake in som e of a domain but htey cannot receive domain policy.

    The big issue here is that you cannot add policy to a non-domain computer so GP will not, in this case, work.

     


    jv
    Wednesday, July 13, 2011 11:14 PM
  • My interpretation of the scenario was that the new image will be rolled out to new clients and when joined to the domain, a domain user is already present in the local admin group. Using a GPO would accomplish the same thing, since it would add the domain user during the initial GPO application.

    A possible solution to the scenario itself, if not the exact question. :-)

     

    (On the other hand.. if they won't be joined to the domain, I'm swinging quite a miss!)

     


    Andreas Hultgren
    MCTS, MCITP
    http://ahultgren.blogspot.com/
    Thursday, July 14, 2011 8:05 AM
  • I agree that that would be great if the user ws going to join the domain.

    The desire to add an account to a non-domian machine is sensible only if teh account is able to proxy.  This wuyld allow someone from a domain to get in without loggin into the machine.  A convenience which might have a purpose although it seems like the hard way to do things.

    A custom installation answer file could also add a domain account SID/name to teh admins group.

    Either way it would not accomlish very much in my opinion.

     


    jv
    Thursday, July 14, 2011 8:10 AM
  • Your blog post does not exist.

     

     


    jv
    Thursday, July 14, 2011 8:11 AM
  • What a failed OP :) Let me refine the question and provide more information.

    1. the MSDN blog post is right here
    2. When the image is pulled down to a new PC, the PC will be joined to a domain.
    3. I'm actually adding a domain group to the local administrators group, this way I can give domain users temporary administrative rights
    4. Using group policy isn't ideal because the computer objects where this group should be applied are mingled with computer objects that don't get this setting. Additionally, we reimage PCs often so keeping the filtering accurate would be cumbersome
    5. Joining the domain during the image setup process isn't viable because it breaks stuff. For example, when we've done so in the past, Windows Update has broken in the image

    I know this can be done because we've done it before. I don't remember how, but I assume it was with a vbscript.

    Thursday, July 14, 2011 4:04 PM
  • Re-reading the thread, I have an idea. 

    I wonder if I can add company.com\groupName and just provide my domain credentials to add the group. I'll have to give it a try.

    Thursday, July 14, 2011 4:09 PM
  • isn't that what i said?  ...only with a user instead of a group?  you may need to try the FQDN of the domain instead of just the netbios domain name.

    this is the same concept as having a computer on your network that pulls a DHCP address but isn't authenticated.  you can still access resources via UNC paths, you simply get prompted to supply domain-based credentials in order to access those resources...

    Thursday, July 14, 2011 4:46 PM
  • That is what you said :) It sounds familiar. I bet that's how I did it before.
    Thursday, July 14, 2011 5:11 PM
  • Darn, it didn't work. I put in company.com\groupName and dc.company.com\groupName. Both times, it says that the object is not from a domain listed in the Select Location dialog box.
    Thursday, July 14, 2011 8:50 PM
  • so... dc.company.com is not correct.  it should not be a host.  it just needs to be the fully qualified domain name of your AD/DNS site.

    do an ipconfig /all and look at your primary dns suffix

    that is the value that should be prepended before the group name.

    so if the value is:   seattle.contoso.com

    you need to put:  seattle.contoso.com\myGroupName

     

    Edit:  and then of course, you need to verify that you can actually reach that domain:  ping seattle.contoso.com  


    Friday, July 15, 2011 12:01 PM
  • Has to be the sid.

     

    When we add a member to a group we browse by name but it is stored as a SID.  Remember theat teh SID has the RID for the domian so it can resolve the name whenit needs to.  Remeber that names ina group or SD look like SIDs if teh machine is unjoined from a domain.  That is because the name is discovered and cacjed locally for a short time but eventtually the system only shows you the SID because it cannot resolve the name.

    To add teh SID we need to use teh DS API which is not abaialable to VBScript and I am not sure if it works inPowerShell when not jpoied to a domain.  The post referred to was about putting teh SID of a non-joined PC account into AD and not the other way around.

    I know it can be done with teh Win32 API call.

     


    jv
    Friday, July 15, 2011 12:23 PM
  • as i said already -- this can be done.  bring in a personal laptop from home and plug it into your corporate network (as long as it won't get you fired (although it should)).  UNC path to one of your file servers:  \\myfileserver\myshare, you'll get prompted for credentials even though the computer has nothing to do with that network.  as long as you can actually pull an IP (DHCP) and resolve the domain (DNS), you can absolutely use:  myworkdomain\myworkusername coupled with your workpassword to access this network resource...
    Friday, July 15, 2011 12:29 PM
  • Yes - but can you add it to a local group?

     

    I suspect that you can easily with teh GUI user manager but what happens when you want to script it.  The WinNT provider for scrip doens't know anything about SIDS.  If you give it a SID it willtry to look it up.

    VBScript has no way of authenticating on a domain for WinNT:. System.,DirectorySerices can.

    How about using WMI.  Do we know if WMI can add a SID to a group.  Usually we want a principle and teh API validates it and storesd the SID.

    I don't know for sure but maybe.

     


    jv
    Friday, July 15, 2011 12:53 PM
  • meh I suppose it's an assumption more than anything; a) you can authenticate with your domain credentails doing something so b) you should be able to add a user/group from the domain.  however, i see how that logic could be flawed.  i'm still at a loss as to explain why a domain user needs to be on a non-domain computer for imaging to occur properly though
    Friday, July 15, 2011 1:41 PM
  • That is, by the way, a very good question.  I too am curious.

    Here is mhashemi's request/issue

    1. I'm actually adding a domain group to the local administrators group, this way I can give domain users temporary administrative rights
    2. Using group policy isn't ideal because the computer objects where this group should be applied are mingled with computer objects that don't get this setting. Additionally, we reimage PCs often so keeping the filtering accurate would be cumbersome
    3. Joining the domain during the image setup process isn't viable because it breaks stuff. For example, when we've done so in the past, Windows Update has broken in the image

    I don't believe that any of this is correct.  None of these things are truly an issue as there are many ways to force the groups to be applied correctly. Many of us do this all of teh time. Using GP to apply the group is normal.  APplying a single user can be an issue however.

    The user account can be added after the machine is staged and joined.  It can be added by using a simple script that an admin can run ar any time.  It can be fully automated if teh user  account is set as the 'Managed By" entry in AD.

    Users shoudl NEVER be administrators under any circumstances.  Companies that still do this are not in compliance with any of the new Federal, and Stae rules requireing specific levels of security in most commercial settings.

    The reason these things are hard to do is because you are not supposed to do them.  The system has beenpuposefully designed that way.

     

     


    jv
    Friday, July 15, 2011 2:10 PM
  • I also have two questions regarding this scenario:

    1. Why not join the imaging machine to the domain, add the account to the local group, unjoin the machine again (back to a workgroup), and then run sysprep?
    2. Why not add the account after the machine is joined to the domain (e.g., using a startup script or something similar)?

    While it may be possible to add a domain account to a local group with proper credentials when that computer is not a member of the domain, I am not sure it is supported. It seems to me that the above two solutions are a simpler and more straightforward way of solving the problem.

    Bill

    Friday, July 15, 2011 2:20 PM
  • I don't believe that any of this is correct.  None of these things are truly an issue as there are many ways to force the groups to be applied correctly. Many of us do this all of teh time. Using GP to apply the group is normal.  APplying a single user can be an issue however.

    The user account can be added after the machine is staged and joined.  It can be added by using a simple script that an admin can run ar any time.  It can be fully automated if teh user  account is set as the 'Managed By" entry in AD.

    Users shoudl NEVER be administrators under any circumstances.  Companies that still do this are not in compliance with any of the new Federal, and Stae rules requireing specific levels of security in most commercial settings.

    The reason these things are hard to do is because you are not supposed to do them.  The system has beenpuposefully designed that way.

     

     


    jv

    1. Just because you would do something differently, does not make alternatives incorrect
    2. I don't want the local admins to run a script, I want this built into the image
    3. Just because you would do something differently, does not make alternatives incorrect. There are tasks that must be completed during a uers's initial login that require administrative rights. Is it ideal? No. Is it temporary? Yes (as I said before)
    4. The Federal and State governments do not control my user-rights assignment

    Perhaps there is a problem with the script I'm using to make this change. I've put the code below.

     

    Set oNet = WScript.CreateObject("WScript.Network") 
    sComputer = oNet.ComputerName 
    
    MyDomain = "company.com" 
    GlobalGroup = "groupSID" 
    
    Set oDomainGroup = GetObject("WinNT://" & MyDomain & "/" & GlobalGroup & ",group") 
    Set oLocalAdmGroup = GetObject("WinNT://" & sComputer & "/Administrators,group") 
     
    oLocalAdmGroup.Add(oDomainGroup.AdsPath) 
    

    There are two message I get back. If I don't browse to \\company.com (in Windows Explorer), I get back:

    (7,1)Microsoft VBScript runtime error: Permissiondenied: 'GetObject'

    Line 7 is:

    Set oDomainGroup = GetObject("WinNT://" & MyDomain & "/" & GlobalGroup & ",group")

    So then I browse to the domain and enter domain admin credentials and I get back:

    (7,1)(null): The network path was not found.


    Monday, July 18, 2011 7:11 PM
  • Hi mhashemi,

    I have two questions regarding this scenario:

    1. Why not join the imaging machine to the domain, add the account to the local group, unjoin the machine again (back to a workgroup), and then run sysprep?
    2. Why not add the account after the machine is joined to the domain (e.g., using a startup script or something similar)?

    While it may be possible to add a domain account to a local group with proper credentials when that computer is not a member of the domain, I am not sure it is supported. It seems to me that the above two solutions are a simpler and more straightforward way of solving the problem.

    Bill

    Monday, July 18, 2011 7:18 PM
  • What I don't think you understand is that everyone here is trying to get you to see that this cannot be done for many reason.

    When we add somethng to a Group ADSI validates that teh memner exists.  When you try to do this with a non-connected workstation The WinNT provider will try to fund the account and retrieve its SID.  An unconnected workstation cannot read AD so how do yu propse that it wil be able to validate the accoutn.

    The method of forcing a SID can only be done via thae API which is unavailble to script.

    If you tempoarily join the workstation to th edomain and add the account then remove it from the domain the account will be automatically removed.  If you disconenct teh workstation first (this worn in XP but may not in Vista/7) then force it nack to a workgroup the account will remain but when you look at teh group it should display as a SID.  I have not tested this for  a few years so I am bot sure if MS changed that.  I ysed ot always have to remove orphaned SIDS when we moved PCs from one company to another.

    The one thing you have not tried is to conenct to the domain with c4redentials.  Unfortunately most WS2003 and later domains wil lnot allow this for AD without altereing AD security.  YOu can however connect to shares if they allow guests or Everyone I believe.

    The issue of doing things differently is not a 'law of the land'.  It is something that most of us have learned over time. It is also Best Procatices and it is actually illegal on almost all Federal Government systems.  Most business insurance companies are sending out quesitonaires asking if the corporate system are secure.  One question is on all of them.  'Do you allow your users to have administative privileges on there workstations?'  The recommendations and/or reqiorements from teh insurance companies are very clear.  They want companies to run with least provileged accounts.

    I have not run as an Admin on my systems for years.  I connect as admin when needed.

    I suspect that there is a tool that will do what you are looking for. There is always a tool.  You might search for it. I did for a short time but only dound dozens of people Sking how to do what you are trying to do but none had found an answer.

    You note that you get back 'permisison denied' when trying to access teh domain.  This is exactly what one would expect.  YOu cannot authenticate.  You have  no domain credentials.  The only possible way to do this would be to use ADSOpenObject with credetials and ask for a secured connection.

    Her eis an example you can try but it will only work if your domain AD has been set to allow untrusted connections. 

    Set oNamesp = GetObject("LDAP:")
    
    Set
    oObj = oNamesp.OpenDSObject("LDAP://cn=myUser,dc=myCompany,dc=com", sUserID,sPassword, &h201)

    THis will, if it can conenct, het you an object that can be used to return the SID.  You can try to add teh account to the local group using the UPN but I don't think it will work with script.  Try it.

    If that doens't work try using the SID.  I have not place to test this so it is really up to you to work this out.


     

     


    jv
    Monday, July 18, 2011 7:46 PM
  • AdqBill, I answered those higher in the thread :)

    But to reiterate:

    1. In the past, when we've joined golden-image machines to the domain before capturing the image, things have broken. The example that comes right to mind is that the security descriptor for Windows update have broken in the cloned PCs.
    2. The PCs that should have this domain group as a local admin are co-mingled with those that should not have that setting. Additionally, we regularly re-image machines so there is no practical way of keeping computer group membership accurate
    Monday, July 18, 2011 7:50 PM
  • AdqBill, I answered those higher in the thread :)

    But to reiterate:

    1. In the past, when we've joined golden-image machines to the domain before capturing the image, things have broken. The example that comes right to mind is that the security descriptor for Windows update have broken in the cloned PCs.
    2. The PCs that should have this domain group as a local admin are co-mingled with those that should not have that setting. Additionally, we regularly re-image machines so there is no practical way of keeping computer group membership accurate

    Use groups to separate the policy.  As long as teh machine keep that same NETBIOS name you will only have the policy you select applied.

    I agree with Bill and I think we are just beating a dead horse.

    I would aslo wonder why you haeve to re-image macines so often.  I suspect it is because you allow users to run as admins.  This makes the machines prone to malware whenever connected to the Internet.  We use to have that issue until we locked down IE and revoked all Admin and PowerUsr privileges.  We haven't reimaged a machine in years.

     

     


    jv
    Monday, July 18, 2011 7:56 PM
  • jrv, thanks for your speculation. Let me confirm that your suspicions regarding our PC re-image requirements are 100% inaccurate.

    Now, returning to the real issue, once joined to the domain, but still logged in with the local administrator account, how can I add the domain group to the local admin group? When I log in with my domain admin credentials, the script (see code in previous post) works, but network path is not found when running as a local admin.

    Thanks.

    Tuesday, July 19, 2011 4:39 PM
  • Save yourself a lot of aggravation and log in as a domain admin.

     


    jv
    Tuesday, July 19, 2011 5:06 PM
  • mhashemi,

    is there any reason you're using the group SID instead of the group name?  i checked this against our old method of applying admin rights (startup scripts) and this is what we used to use:

    On Error Resume Next

    Set ws = WScript.CreateObject ( "WScript.Shell" )
    compname = ws.ExpandEnvironmentStrings ( "%COMPUTERNAME%" )
    Set adGrp = GetObject ( "WinNT://" & compname & "/Administrators,group" )

    adGrp.Add ( "WinNT://ourDomainName/Domain Admins,group" )

    ...this looks to be about the same script minus the variables and the SID specification.  Would you mind trying the group display name and see if that resolves your problems?? or the scirpt I posted and just replace the pertinent values...

    Tuesday, July 19, 2011 5:59 PM
  • jrv, I think I'll save a lot of aggravation and stop reading your replies ;)  

    thepip3r, Yeah, same thing with the group name.

    Tuesday, July 19, 2011 8:06 PM
  • ah... i think i see the problem.  but it's the same problem we've been discussing as before (sort-of).  so you apparently joined the computer to the domain (that's great).  and you say when you log in with your DA credentials, the script runs fine but when you log in with the local administrator, you get Network Path Not Found...  which makes complete sense (maybe).  To test my theory, log into yoru computer with your local account, use runas to execute another cmd shell as your DA, this should run just fine to do what you want.  Then runas another cmd shell with a normal user account -- this should fail.  it shouldn't fail because of network path not found but because access is denied.  then run your script with just your local admin.  my assumption is that the winnt provider is using the local admin credentials which will fail against trying to enumerate the local domain.  but add the script (using gpedit.msc) to the startup script) and then reboot.  you either have to do something like this or use credential impersonation to use alternate credentials....

    Tuesday, July 19, 2011 8:39 PM
  • In the past, when we've joined golden-image machines to the domain before capturing the image, things have broken. The example that comes right to mind is that the security descriptor for Windows update have broken in the cloned PCs.

    This sounds like a separate problem. If I remember correctly, the image can be corrected so you don't encounter this problem. (Not a topic for this forum)

    The PCs that should have this domain group as a local admin are co-mingled with those that should not have that setting. Additionally, we regularly re-image machines so there is no practical way of keeping computer group membership accurate

    This seems like a good argument for adding the needed accounts after imaging, not before.

    Bill

    Tuesday, July 19, 2011 10:16 PM