Active Directory UDF - Help & Support (III)

[31290]

Water, 

That is perfect! 

Thanks again ^^

[water]

Glad to be of service

[Neutro]

Hey water,

I tried today to create a script so our PC automaticly join our domain using ad_createcomputer and ad_joindomain

Strange thing is: when the computer local name is not set to the netbios name used in ad_joindomain, ad_joindomain fails and return "WMI object could not be created" with an extended code of -2147023174

However, if I manually change the name of the computer to the name used in ad_joindomain, it works.

Used on Win7 pro client and Win2k8 R2 DC.

Any idea why this is happening?

Also, in the help file of ad_joindomain, it states that if not specified, the default credentials used will be the one used in ad_open. This is misleading because it's not, i pulled my hairs out for 2 hours before understanding that I had to manually specify the credentials in that function because it would not use the same ones specified in ad_open before

Thanks!

[water]

I have to admit that this function is one I do not fully understand.
When I started to upgrade the ADfunctions UDF written by Jonathan Clelland I only had read access to our AD (and still have).
So over time this function matured when other users joined computers to a domain or had problems with it. You'll find a lot of discussion about joindomain/unjoindomain on this forum.
If you have any suggestion how the wording of the help file should be changed I'm all ears.

"WMI object could not be created" with an extended code of -2147023174 (0x7ff8f946) means: The RPC server is unavailable.
Unfortunately this doesn't tell us much.

I take it that you have been able to solve your problem.
Should the function be modified or the help file be changed?
 

[Neutro]

Thanks for your fast answer

If you have any suggestion how the wording of the help file should be changed I'm all ears.

The help file says:

$sUserParam | Optional: User with admin rights to join the computer to the domain (NetBIOSName (domain\user) or user principal name (user@domain))
(Default = credentials under which the script is run or from _AD_Open are used)

Remarks | If no credentials are passed to this function but have been used with _AD_Open() then the _AD_Open credentials will be used for this function.

I think that even if these parameters are optional, they should always be manually specified. The _Ad_Open credentials are not used when the parameters are not specified. I used in my script _Ad_Open("domain_admin_login", "domain_admin_password", <other ad infos parameters>) before using _AD_JoinDomain but it would not use "domain_admin_login" and "domain_admin_password" automaticly as optional parameters.

So maybe if not specified the parameters use the credentials under which the script is run, but in that case, the only way it would work is if the script would be run under a domain admin account to join the computer to a different domain that the one it is already in to a domain where the domain admin account is also already a domain admin of (so in a cross forest domain case). As this is a very specific case and most of the time this function will be used to join a computer to a domain where the computer is not already a member of that domain, I think the help file should say instead:

$sUserParam | Optional: User with admin rights to join the computer to the domain (NetBIOSName (domain\user) or user principal name (user@domain))
(Default = credentials under which the script is run. Important: See remarks.)

$sPasswordParam | Optional: Password for $sUserParam. (Default = credentials under which the script is run are used. Important: See remarks.)

Remarks | Even if these parameters are optional, they should always be manually specified if joining a computer that is not already member of a domain or it will fail otherwise.

I take it that you have been able to solve your problem.

Actually I did not, I stopped there and waited for your answer to see if you had a solution before going further

But I know how to solve the problem: make the script change the local name of the computer to the one it will have on the domain, then set it up to auto logon on restart, then restart it then create a RunOnce registry key to start another script that will use the joindomain function. But as it's a bit sad to make the computer reboot where it should normally not be needed and scripting the auto login and restart is a bit borring I wanted to prevent to have to do this if possible

Edited September 26, 2015 by Neutro

[water]

Thanks for your feedback!
I will see what can be done to further automate the process and to enhance the docu.
As you can see from the links in the function header I mainly translated existing scripts to AutoIt.

[Neutro]

I checked out the AD_JoinDomain function in AD.au3. It contains this:

_AD_JoinDomain($sComputer, $sUserParam = "", $sPasswordParam = "")
(...)
Local $oComputer = ObjGet("winmgmts:{impersonationLevel=Impersonate}!\\" & $sComputer & "\root\cimv2:Win32_ComputerSystem.Name='" & $sComputer & "'")
(...)

It seems to me that this is where is the problem. It should be instead:

Local $oComputer = ObjGet("winmgmts:{impersonationLevel=Impersonate}!\\" & @computername & "\root\cimv2:Win32_ComputerSystem.Name='" & @computername & "'")

I will try to check it on a virtual machine, i will let you know how it goes.

[water]

But how should replacing a function parameter with a fixed value solve the problem?
If you need to join @computername then simply pass it as the first parameter to the function. A parameter was used so you could join other computers as well.

[Neutro]

So you mean that this function could be used on a computer to make another computer join a domain remotely? Is that even possible?

I did some tests on a virtual Win2k8R2 AD server and a virtual Win7 pro.

The following code allowed me to make the computer running the script sucessfully join the domain and rename it to whatever name I wanted with only 1 reboot:

$domain_name = "TESTDOMAIN.LOCAL"
$domain_admin_login = "TESTDOMAIN\Administrator"
$domain_admin_password = "MyPassword"
$OU="OU=Computers,DC=TESTDOMAIN,DC=LOCAL"
$new_computer_name="NEWNAME"

Local $oComputer = ObjGet("winmgmts:{impersonationLevel=Impersonate}!\\" & @ComputerName & "\root\cimv2:Win32_ComputerSystem.Name='" & @ComputerName & "'")

$oComputer.JoinDomainOrWorkGroup($domain_name, $domain_admin_password, $domain_admin_login, $ou, 3) ; 3 = create computer object and join domain

$oComputer.Rename($new_computer_name, $domain_admin_password, $domain_admin_login)

shutdown(6)

So I guess the _AD_JoinDomain() function could be simplified to not need the _AD_CreateComputer() call before, you would just need to specify the OU where you want to create the computer in the Active Directory, and an optional new name

I can rewrite it that way and post it here if you want

Edited September 27, 2015 by Neutro

[jazzyjeff]

Water,

Sorry to bring this topic back up again, but I am no nearer to a good solution for running my script from a network location and not getting an error 4 when using an AD function from your UDF. So a simple piece of code like below generates error 4 or -2147024843.

#include<AD.au3>
_AD_Open()
If @error Then
    MsgBox(0,"AD Open Error",@error & @CR & @CR & @extended)
Else
    MsgBox(0,"AD Open","Working fine")
EndIf
_AD_Close()

So I could get around the issue by copying the exe locally, but this really isn't going to be acceptable. We need it to run off the network. It's weird that this was working fine, but now isn't.

You mentioned about the secure locations before, and I looked at the group policies and tried every combination of enabling and disabling those to no avail. You also mentioned that you though it was possible to manually edit the secure locations list? Do you have any information on how to do this, because I can find anything anywhere on editing this secure locations list.

I then started wondering about the LDAP query itself and if there is a permissions issue. As a Domain Admin, I can run any script without issue, but by domain users are having problems. I started reading about rootdse and if there was a permissions setting here that is causing the issue. Not knowing too much about it i started reading and it seems that read access to this part of AD is anonymous so everyone can read the information here, so the rights can't be this. Plus it brings me back to running the file locally and that's fine, so that rules out any AD permissions. 

I granted full control rights to the user for the directory that the exe is stored in on the network, but this didn't make any difference.

I then thought that perhaps if i could have the program run the in the memory using TranceX's script (RunBinary) thinking that this would act like it is local, but this also doesn't work. To be honest that script is pretty confusing to me and I suspect I am using it incorrectly.

 

If you have any other ideas other than copying the file locally I'd appreciate it.

Thanks,
Jeff

 

[water]

Could you add _AD_ErrorNotify(2) at the top of your script for better error information?

[jazzyjeff]

AD UDF Version = 1.4.2

AutoitVersion = 3.3.14.1

Autoitx64 = 1

OSArch = x64

OSVersion = Win7

Scriptline = 306

NumberHex = 80070035

Number = 2147024843

Description = The network path was not found

LastDLLError = 0

 

 

 

Thanks!

[jazzyjeff]

If I roll back Autoit to 3.3.12.0 or 3.3.10.2 and AD version 1.4.1.1, then I get this error!

 

"C:\Program Files (x86)\AutoIt3\UDF\AD.au3" (549) : ==> Variable must be of type "Object".:
$__oAD_Command.CommandText = "<LDAP://" & $sAD_HostServer & "/" & $sAD_DNSDomain & ">;(" & $sProperty & "=" & $sObject & ");ADsPath;subtree"
$__oAD_Command^ ERROR

I don't see this error with 3.3.14.2 or the new beta, and running AD 1.4.2

 

EDIT: I went back to 3.3.14.2

Edited September 29, 2015 by jazzyjeff

[water]

So you mean that this function could be used on a computer to make another computer join a domain remotely? Is that even possible?

I think this is possible (but have never tried it myself). The WMI part of the function specifies the computer where WMI should connect to.
The MSDN links in the function header describe how it works.

[water]

So I guess the _AD_JoinDomain() function could be simplified to not need the _AD_CreateComputer() call before, you would just need to specify the OU where you want to create the computer in the Active Directory, and an optional new name

I can rewrite it that way and post it here if you want

_AD_CreateComputer does a bit more by letting you specify the OU to create the computer in and the admins who can add the computer to the domain.
But two new parameters could be added to _AD_JoinDomain to set the OU and the flags to create the computer account with the same call.

Your problems with the credentials might be caused by a bug in the function.
Can you please post how you called _AD_JoinDomain? Please mask sensitive information with stars where needed.

[Neutro]

Here it is:

$test_ad = _AD_Open("domain_admin_account_login", "domain_admin_account_password", "DC=MYDOMAIN,DC=LOCAL", "MYDOMAINCONTROLLER.MYDOMAIN.LOCAL", "CN=Configuration,DC=MYDOMAIN,DC=LOCAL")

I also tried with

$test_ad = _AD_Open("domain_admin_account_login", "domain_admin_account_password", "DC=MYDOMAIN,DC=LOCAL", "MYDOMAINCONTROLLER", "CN=Configuration,DC=MYDOMAIN,DC=LOCAL")

with same results.

By the way I managed to achieve my goal to fully automate our computer setup, so now we just boot into pxe and 15 mins
later the computer is ready to go and that's thanks to you

[water]

_AD_Open supports three ways to specify a username:

• Windows Login Name e.g. "DJ"
• NetBIOS Login Name e.g. "<DOMAIN>\DJ"
• User Principal Name e.g. "DJ@domain.com"

For _AD_JoinDomain only two formats are accepted:

• NetBIOSName e.g. "<DOMAIN>\DJ"
• User Pprincipal Name e.g. "DJ@domain.com"

So if you use the WIndows login name _AD_JoinDomain dos not work.

Which one did/do you use?

[Neutro]

I used the windows login name, as specified in _AD_Open:

 

_AD_Open will use the alternative credentials $sUserIdParam and $sPasswordParam if passed as parameters.

 

$sUserIdParam has to be in one of the following forms (assume the samAccountName = DJ)

* Windows Login Name e.g. "DJ"

* NetBIOS Login Name e.g. "\DJ"

 

* User Principal Name e.g. "DJ@domain.com"

 

All other name formats have NOT been successfully tested (see section "Link")

 

So indeed that might be the source of the problem if _AD_JoinDomain does not support this type of authentification.

#edit: I previously tried to manually specify the user credentials in _AD_JoinDomain using DOMAIN\login or login@DOMAIN format but had the same WMI error.

The only thing that made it work was to use @computername as $sComputer parameter in _AD_JoinDomain, but then I could not rename the computer name directly after the domain joining. I had to reboot and then change the name, whereas I could do these 2 actions at once with the commands I wrote earlier.

I had the same problem in my company network and on my virtual test 2008 R2 DC / Win7 client environnement.

Edited October 1, 2015 by Neutro

[water]

If you are willing to invest some time and do the testing, then I would be happy to enhance the _AD_JoinDomain function to whatever is needed.
I see the following possible enhancements:

• Better error checking if the format of the credentials is not supported
• New parameter to set the OU to join the computer to
• New parameter to set the flags to create the computer account with the same call
• New parameter to specify the new computer name

What do you think?

[Neutro]

Seems nice!

I have a lot of work until the end of the week so I won't be able to do much test until then, but i'll be avariable next week if you want me to do some tests then

Edited October 1, 2015 by Neutro