Error authenticating to AD during deployment; can't seem to query AD

New to K2000;
I have been attempting to build a pre-install HTA to gather info from techs as they deploy various models.
I am converting something that I had previously working with SCCM.  However when I attempt to query AD to check that a user exists,
or to bind to an OU to check for a computer object, I get an error, "domain not found, or is not responding" when running via K2000 deployment -
in mid-level or post install tasks.

However, if I test the script form a PC, I get no errors.

I also just decided to just use the provided join domain PowerShell script and .bat file; filled in the required info and that is not working either.
We do have LDAP setup and working for authentication to the K2000 itself; but am I missing some other step that is preventing me from connecting to AD
during a deployment?

Here is part of the code I am using:

CONST strSCCMStageOU = "OU=MyOSD,OU=Ops,DC=Fabricam,DC=com"
DIM OSDUserName, OSDAddAdmin, OSDDestOU, OSDCompName
DIM strADSPath, strComputerDN, strAccount, strPwrd
DIM objRootDSE, strDomain, objConnection, objCommand, objRecordSet, strDN

' Get domain components
Set objRootDSE = GetObject("LDAP://RootDSE")
strDomain = objRootDSE.Get("DefaultNamingContext")

' Set ADO connection
Set objConnection = CreateObject("ADODB.Connection")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"

' Set ADO command
Set objCommand = CreateObject("ADODB.Command")
Set objCommand.ActiveConnection = objConnection
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
objCommand.CommandText = "SELECT distinguishedName FROM 'LDAP://" & strDomain & "' WHERE objectCategory='user' AND samAccountName = '" & OSDUserName & "'"

' Set recordset to hold the query result
Set objRecordSet = objCommand.Execute

I get the error at the following line:
Set objRootDSE = GetObject("LDAP://RootDSE")

Thanks for any help or ideas.

5 Comments   [ + ] Show comments
  • How are authenticating to the domain in order to perform the query? Are you hard coding the username and password in the section of code that is missing? - chucksteel 4 years ago
  • Yes, we have a dedicated, non-privileged account setup just for adding systems to the domain. What is odd here is that the initial step, the LDAP querry seems to be timing out. I might need to check with our network guys to see if something is blocking that traffic, since the K2000 is a new device. - jboehlke 4 years ago
  • Did you add ADSI drivers to the KBE? - cserrins 4 years ago
    • Okay, so I went through the process of getting the KBEM, and creating a new KBE with ADSI drivers, and now I cannot PXE boot to that KBE. I am getting the ipxe error:
      No such file or directory (http://ipxe.org/2d0c613b) Could not boot: No such file or directory (http://ipxe.org/2d0c613b). I saw that there is an issue with non-windows KBE not working in 4.1, but this is windows and should still work, correct? - jboehlke 4 years ago
      • If I try to browse to the ipxe path (http://>k2000IP>/boot/ipxe/14/bios/kbe_iso via a browser I get a permissions denied message from the K2000. Where are the KBEs stored on the K2000? Is there a way to troubleshoot that? - jboehlke 4 years ago
      • I opened a ticket with support and they 'fixed' the VM boot issue so I was finally able to test again today, but I am getting the same error on the line:
        Set objRootDSE = GetObject("LDAP://RootDSE").
        Is there something else I need to add to the KBE? - jboehlke 4 years ago
  • wow, @cserrins, great question!! I remember having to do this way back with SCCM boot image, but now that you mention it, I don't think we did that when the KBE was setup... - jboehlke 4 years ago
  • I wish you didn't have to hard code username and password in scripts, I wish there was a better solution to call a service account. Some type of vault that the scripts can call. - jgarcia29 3 years ago

Answers (0)

Be the first to answer this question

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ