Options for reducing maintenance of credentials used for Map Network Drive action

Automise Discussion
1

I recently had to change the password associated with the account that most of our Automise Projects run under. In the process of changing the credentials used for the Windows Task Scheduler tasks (not your problem :)), and changing the credentials associated with the numerous Map Network Drive actions I have defined across my Automise projects (more relevant), I came up with the following questions:

  1. Is there a way to default Map Network Drive credentials the same way that we currently can default Send Email options? So that, for instance, we could centralize the ID/password that we use the most when mapping a network drive, and only change it in the action properties if the options are different?

  2. If a Windows Task Scheduler task (that runs an Automise project) is set to run as user X, and I map a drive within the Automise project that is being run, will the drive mapping happen with user X’s credentials if I do not specify a login and password to use when mapping the drive?

  3. Is there a way to set a variable in a project to be the password for the user that maps the drive, and specify that variable in place of the password that is being used? This would be the least secure, but could still make it that the password only has one place in each project where it would need to be maintained.

  4. Is there anything I am missing, related to mapping a network drive or other actions that use credentials? Is there a centralized way to handle the credential maintenance?

Thank you for listening.

– Jonathan

2

Hi Jonathan

  1. No - it’s never been suggested before.

  2. Yes - if you leave the credentials fields blank then the drive will be mapped using the current user.

  3. You can use a regular project password - but as you noted, that would be insecure. Another option would be to store the password encrypted in an ini file and load that and decrypt when needed at runtime. This is probably your best bet for the time being.

  4. Not at the moment. For AT6 we are adding a passsword variable type, where the default value is always stored encrypted. We are also looking at whether we can back port this to AT5 - but that would break backwards compatibility with earlier AT5 builds - ie once you use the feature earlier builds would not be able to load the projects. This is something we generally try to avoid in a major release - however this feature may be important enough to warrant breaking this rule.

We have also looked at the windows credentials api, however we had issues with using it when running under the windows task scheduler - this is work that is still ongoing - we would like to have a much better story for working with secrets in general - whilst still allowing projects to be moved between machines etc.

3

I appreciate the responses! Your answer to #2 will actually make things easier to maintain. Looking forward to having #4 in place, whether in AT5 or AT6.