Specifying ADUsername, ADDomain and ADPassword

Mar 29, 2010 at 3:22 PM

Hi

I try to specify ADUsername, ADDomain and ADPassword through cs.ini or my script so the user who initiate the installation will be used for the SetComputerNetbootGuid operation. But it does not work.

If I specify the same user in IIS Application Pool it's able to update net netbootGuid in AD.

Is it not possible to specify this parameters through script or cs.ini?

Script
--------
strDomain = oEnvironment.item("DomainAdminDomain")
strPassword = oEnvironment.item("DomainAdminPassword")
strUser = oEnvironment.item("DomainAdmin")
strComputerName = oEnvironment.item("OSDComputerName")
strDomainDC = oEnvironment.item("DomainDC")
strUUID = oEnvironment.item("UUID")

oEnvironment.Item("ComputerName") = strComputerName
oEnvironment.Item("ADUsername") = strDomain & "\" & strUser
oEnvironment.Item("ADDomain") = oEnvironment.item("JoinDomain")
oEnvironment.Item("ADPassword") = strPassword

Set oService = new WebService
oService.IniFile = "customsettings.ini"
oService.SectionName = "SetNetbootGuid"               
Set oXML = oService.Query

cs.ini
------
[SetNetbootGuid]
WebService=http://sds-dist-03/DeploymentWebservice/ad.asmx/SetComputerNetbootGuid
Parameters=ComputerName,UUID
OSDComputerName=ComputerName
UUID=netbootGuid

Mar 31, 2010 at 1:46 PM

Not sure if this will help, but try changing your Paramaters in you cs.ini

from

Parameters=ComputerName,UUID

to

Parameters=OSDComputerName,UUID

Coordinator
Apr 5, 2010 at 3:56 PM

No it's not possible to supply a username via cs.ini that get's used by the webservice to execute. The general idea is to have an account configure for the webservice that is able to execute all the necessary functions. If necessary you can restrict the access to the webservice itself using the default IIS methods.

The necessary account to access the webservice could then be configured in the cs.ini like

[Default]
UserID=MyUserAccount
UserPassword=MySecureP@ssword
UserDomain=MyDomain

The MDT ZTIDataAccess script will then use these credentials to authenticate against the webservice.

See it as some kind of layer between them. This way you can make sure the webservice is working but at the same time give only specific accounts access to the webservice without giving them explicit permissions in SCCM and/or AD.