I want a network share to be mapped to I:\ drive on a client computer. This share is accessible from the client computer, but not from BigFix console.
I wrote a batch script to map the I:\ drive to the network drive and stored this batch file on the client computer. When I run this batch script through a fixlet/task, it doesn’t create this new network drive.
By default the client runs as “SYSTEM” and it does not have access to any network resources, so most-likely that is why the mapping is failing. Look into the override functionality and might need to change whatever command (run/wait/runhidden/waithidden/dos/etc) you are running to be overwritten with runas some kind of account. Give this a try.
This worked for me! Instead of having the user enter password in a dialog that appears every time we run the fixlet, how do we enter password as a secure parameter. The script should automatically pick up the password defined. I saw sample fixlet for “Secret parameter”. I am not sure how to integrate with this code
You will need to export the fixlet and edit it with some kind of text editor (Notepad++ is what I use but there are a ton) and you’d need to add the javascript function + HTML form to hardcode the password.
Just one thing though - what you have is a “secure parameter”, hardcoding the password is no longer secure! I mean, when you run it as an action it will not be in the action as a parameter and if you check the client log it will not be visible there either but if someone “exports” the fixlet and opens it in a text editor that password will be there for them to see in plain text! It’s just not 100% secure where what you have is - the password isn’t stored anywhere, it’s encrypted and then disposed of.
I hardcoded the password in the javascript+HTML form of the “Secret” fixlet. I want this hardcoded password value to be assigned to the “pasword” field when I run the Action script with “RunAs=localuser”. How to achieve this?
HTML+Javascript
<![CDATA[This fixlet will help you distribute a password or other kinds of secrets within BigFix v9 or greater.
<label for="secret">Secret</label>
<input type="password" id="secret" name="secret" value="abcdef"/>
<script>
document.body.ontakeaction = function() {
var theSecret = document.getElementById( "secret" ).value;
TakeSecureFixletAction( Relevance('id of current fixlet'), Relevance('id of current bes site'), "Action1", {}, { secret: theSecret } );
return false;
}
</script>
]]></Description>
I’m not sure I understand any more what you’re trying to accomplish.
At the root, you’re trying to map the I: drive to some UNC share, but I’m not sure which user you want it mapped under?
Suppose user “Bob” is logged on to the Windows target endpoint.
Are you trying to map the “I:” drive for Bob, or trying to start a new login session as user “Alice” and map the drive under her account (in which case Bob will not see an I:\ drive)?
There could be many users that can login to the Windows target endpoint. For simplicity, let’s assume “Bob” has logged on to the endpoint.
I want to start a new login session as user “Alice” , password “abcdef” and want to map the drive under her account. You are right. Bob will not be able to see the mapped I: drive.
Every time I run the fixlet, I do not want a Take Action Dialog popping up for me to enter the password. If there is a way the password could be pre-populated in the text box (from the password hardcoded in the html+javascript), I should simply be able to run the fixlet.
I’ll be writing up a longer post on this, but for now I’ll give the short version.
I’m not sure that I’ve exhausted every option, but I’ve run through a lot of scenarios on the ‘override’ options. I’m not happy with some of them, the parameter options seem to have some arbitrary constraints. To supply the password as a literal value, we have to specify ‘asadmin=interactive’. To use the ‘asadmin=interactive’ option, we have to enable connecting to a user session - there must be someone logged on to the endpoint.
This option should work…
What I don’t like about this, is that “Bob” must be logged on, even if we don’t want to interact with him. The override parameters don’t allow a literal password unless we specify ‘asadmin=interactive’, and to do that we need to have some logged-on user with whom to interact (Domain\Bob), even if we are not actually going to interact with the user (hidden=false)
You can use relevance substitutions in the user, password, or targetuser parameters. One relevance I have used quite a bit and I think will be useful for setting targetuser to “whoever is logged on to the machine, since we don’t care anyway” is
targetuser={(preceding text of first "|" of it | it) of concatenation "|" of ((if exists domain of it then domain of it & "\" else "") of user of it & name of it) of logged on users}
However, if there is nobody logged on at all, I don’t think there’s any path to running the script.
Also, one important effect to be aware of - using this option ‘asadmin=interactive’, the script you execute will run with Administrator privileges, even if neither Bob nor Alice are members of the Administrators group.
Ah, a little bit more digging. When I used ‘Take Custom Action’ along with the ‘password=required’ parameter, the Console sends the action but hasn’t evaluated that a secure parameter is needed. When the client fails to execute the command, it gives an error message with a clue in it -