Thanks Chuck, I thought that might be the case and I am in complete agreement. I know that it would be a while before a new AD environment for test would become a priority, and I think this is a good opportunity to show how we have to sacrifice certain features when we don't have the proper support.
Also +1 for "thread-jack". On Nov 14, 7:25 pm, Chuck van der Linden <[email protected]> wrote: > Is it possible to create a local user who has minimal rights, and no > access to the domain, on the system where the webserver is running and > use those credentials? > > Personally speaking, I'm not putting MY domain level credentials into > any script or datafile, no matter HOW it's encrypted. Because if the > script can decrypt it to use for testing, someone can easily modify > that code to output the UN-encrypted value. Furthermore it likely > violates security policy regarding your password etc. > > I'd fight back hard on the no test user aspect. a low rights test > user with very restricted permissions (just enough to do your tests > and NOTHING more) is far less of a security risk than embedding > passwords of real users into scripts (even if 'encrypted'). > > Alternatively setup a 'test' AD, and have the testbeds use that for > authentication.. production points at the real AD, test system point > at the 'test' AD which has no real users in it. > > If the IT guys won't relent, and your manager insists the tests be > automated, then let them put their darned password and user ID into > the scripts. > > On Nov 14, 9:12 am, Adam Reed <[email protected]> wrote: > > > > > > > > > Edit/Update: I have handled this in other cases by including a flat > > file in Subversion with the variable names for user/pass, but no user > > information. In order for the script to run, the user (me) has to add > > their credentials to the file and make sure not to check it back into > > Subversion once changes are made. Is that as good as it gets? > > > On Nov 14, 10:55 am, Adam Reed <[email protected]> wrote: > > > > This started out as an encryption question, but it may end up being a > > > testing best practice question. I have an application that is not > > > customer-facing, so new accounts cannot be created. It uses personal > > > Active Directory information, and we have no (nor are we allowed to > > > obtain) test accounts for Active Directory. > > > > I have a personal account that can access the content to be tested, > > > but I do not want my AD password to be easily obtained. I am using > > > Jenkins to launch scripts so I can easily prompt the user for a > > > password and store it in a variable to be used... but I know how easy > > > it would be to then log these passwords to a flat file. I'd like to > > > provide more security for coworkers if I'm setting up a system that > > > accepts user input (instead of using my own as an encrypted master for > > > the script). > > > > The test case is pretty standard - log in, assert a few features and > > > functions and that's it. I looked into AES encryption thinking that I > > > would encrypt the password manually and then take the encrypted string > > > and paste it into a decrypt function in the script... but that > > > function would obviously list the decryption keys so it's really only > > > adding a step of obfuscation to the process of retrieving the > > > password. > > > > What's the best practice for this scenario? > > > > Thanks, > > > Adam -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
