sowais has asked for the
wisdom of the Perl Monks concerning the following question:

Hello Monks! I am an amatuer in Perl and have created a simple DB insert script that is giving login issues. The script is invoked by an application upon an event. The DB connection part of the script does not use credentials(user & pass). When I place the script in the C:\ of the application's server and run it from command line, it runs fine, but when I place the script in a mapped drive of the same server (accessible from other servers but meant only for this application) and invoke it via the application I get an error 'Login failed for user 'HASH(0x34882c)'(SQL-28000)'. I know the former is using the serviceacct credentials and hence succeeding but the latter is what has got me puzzled.

The not putting in the user and pass is a requirement by our infosec. I was asked to use Active Directory to use the credentials of the server the application is residing on. Since I am new to this aspect of Perl, I did some searching online and found that LDAP might be the way to go but I haven't played around with AD nor LDAP at all, so a little lost and would greatly appreciate any kind of help or direction. I have included below the DB piece of my code for reference. Also, I am on Windows Server Ent.

You can also examine the SQL ERRORLOG file at %programfiles%\Microsoft SQL Server\INSTANCE\mssql\log\ERRORLOG for more details. (See this msdn blog post)

My goal ... to kill off the slow brain cells that are holding me back from synergizing my knowledge of vertically integrated mobile platforms in local cloud-based content management system datafication.

The most-immediate problem is that the parameter-list being passed to DBI->connect() is obviously wrong. The username and password positional-parameters are missing entirely. So, the hash (most-likely stringified as “HASH(0x34882c)”) is being taken to be the username.

For example, if you know that (thanks to LDAP or whatever ...) the Perl app does not require user/pass to connect, then you should nevertheless supply undef, undef in those two positions, so that the attributes-hash is still in its proper place in the list.

When you run it from c: or other dir under your security context, it works (ie, logged in as your user).
When you run it under the security context of the application, it does not work.
My guess is that the the user under which the application run has no rights on the database.

For what it's worth, AD is simply an LDAP schema created by Microsoft. So, yes, in order to use AD credentials, you'll probably need to use LDAP and LDAPS (LDAP over an SSL tunnel for security) to accomplish that. You may find this link helpful: LDAP & AD - allow user to reset password.