Passing credentials from job to application
-
Hi, I have a console application that gathers order data, and creates and sends email messages to sales people. I run the application in a scheduled task, and the smtp credentials are simply hard coded:
Dim smtp As New System.Net.Mail.SmtpClient("MySMTPServer.MyDomain.com")
smtp.Credentials = New System.Net.NetworkCredential("MyAccount", "MyPassword", "MyDomain")I run the job under my own account (with power-user rights), because I have no administrator rights to the domain. What I am thinking about is, that hard coded credentials are ofcourse not ideal to say the least. My question is, would it be possible to somehow pass the credentials with which the scheduled task is run, to the application? Any insights appreciated, Johan
My advice is free, and you may get what you paid for.
-
Hi, I have a console application that gathers order data, and creates and sends email messages to sales people. I run the application in a scheduled task, and the smtp credentials are simply hard coded:
Dim smtp As New System.Net.Mail.SmtpClient("MySMTPServer.MyDomain.com")
smtp.Credentials = New System.Net.NetworkCredential("MyAccount", "MyPassword", "MyDomain")I run the job under my own account (with power-user rights), because I have no administrator rights to the domain. What I am thinking about is, that hard coded credentials are ofcourse not ideal to say the least. My question is, would it be possible to somehow pass the credentials with which the scheduled task is run, to the application? Any insights appreciated, Johan
My advice is free, and you may get what you paid for.
I don't have a problem with the idea of hard coded credentials, after all it is a service that is making the call. I have a problem with the being YOUR creds, you should have a service account set up to run these services with the permissions appropriate to the service. What happens when your 30/90 days are up and you have to change you password (you do have a policy that requires password changes ;))
Never underestimate the power of human stupidity RAH
-
I don't have a problem with the idea of hard coded credentials, after all it is a service that is making the call. I have a problem with the being YOUR creds, you should have a service account set up to run these services with the permissions appropriate to the service. What happens when your 30/90 days are up and you have to change you password (you do have a policy that requires password changes ;))
Never underestimate the power of human stupidity RAH
The bad news is that we don't have such a policy, the good news is that I don't make the policy. ;-) You have a good point there actually (about the credentials), and as a solution it is much simpler, than the line of thought I found myself stranded upon. Thanks !
My advice is free, and you may get what you paid for.
-
The bad news is that we don't have such a policy, the good news is that I don't make the policy. ;-) You have a good point there actually (about the credentials), and as a solution it is much simpler, than the line of thought I found myself stranded upon. Thanks !
My advice is free, and you may get what you paid for.
We have a number of accounts set up specifically for different server jobs from SSIS to reporting and some WCF services, this is over and above the accounts that support the sa in each server. We do have such a policy, even on the servers and their accounts, thakn God I don't have anything to do with it. The have scripts that change the passwords on all the 1000+ servers, including oracle, sql server, sybase and a couple of other breeds. You should see the chaos when they forget to include a new server in the script.
Never underestimate the power of human stupidity RAH
-
We have a number of accounts set up specifically for different server jobs from SSIS to reporting and some WCF services, this is over and above the accounts that support the sa in each server. We do have such a policy, even on the servers and their accounts, thakn God I don't have anything to do with it. The have scripts that change the passwords on all the 1000+ servers, including oracle, sql server, sybase and a couple of other breeds. You should see the chaos when they forget to include a new server in the script.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
thank God I don't have anything to do with it.
I am with you on that one.
Mycroft Holmes wrote:
We have a number of accounts set up specifically for different server jobs
We are just a small subsidiary company, so I only need to take care of a relatively small amount of jobs that are specific to just us. Though I am sure that our HQ employs a setup similar to what you describe. I'll be in contact with them about getting a service account like you suggested.
My advice is free, and you may get what you paid for.