Secured your infrastructure? Are your custom applications ready?
by Yaroslav Pentsarskyy
Patching and applying infrastructure updates is a common thing. Keep in mind however, that running custom applications in your environment means that pretty much every component that may be used by the custom system needs to be checked to ensure it hasn’t been affected by your changes. This article describes few most common changes that administrators make without realizing the impact on the custom application. This will hopefully help developers to plan for those modifications when architecting their solutions.
The root cause was the fact that mail server IP remained the same but we lost anonymous authentication privilege for machines within the same network.
Another scenario that may cause production issues is when authentication is changed for a server hosting web services consumed by other parties. Especially in the event you provide web services for public or wide consumer base this might turn into a huge mystery next busy morning.
In one of the other cases I have been exposed to related to a web service issues, involves web service account password expiration. This scenario was even more time consuming to troubleshoot because there was no infrastructure updates happening in few weeks before the issue happened. The application was connecting to a company wide web service which was deployed about a month ago. All of the sudden the application was returning an error when it’s core function executed.
After narrowing down the problem to this piece of custom code:
|
System.Net.NetworkCredential cred = new System.Net.NetworkCredential();
cred.UserName = ConfigurationSettings.AppSettings["User"];
cred.Password = ConfigurationSettings.AppSettings["Pass"];
cred.Domain = ConfigurationSettings.AppSettings["Domain"];
localhost.Service1 myService = new localhost.Service1();
myService.Credentials = cred;
|
We realized that the password for the account that authenticated clients accessing the service has been initially set up to expire after 45 days.
Lessons learned in both of the cases were that infrastructure needs to be tightly synched with any custom components being deployed on the network. Administrators have to think outside of box what can impact the functionality. Developers must anticipate architecture changes and incorporate proper alerting and error reporting.
Hope this article helps you planning any future deployments and troubleshooting.
Yaroslav Pentsarskyy
Blog: www.sharemuch.com
Changing authentication or updating credentials on a mail server is our first one.
Many custom applications directly or indirectly interact with your email server. Whether it’s a part of the core functionality the provide or maybe for critical error notification – don’t discount them when making changes to your Exchange. In one of the cases I have been working lately is that application all of the sudden started returning the following error “Service not available, closing transmission channel”. The clock was ticking and one of the core system functions was down. After few hours of checking obvious things, we realized that due to un-communicated mail server configuration, the credentials used to authenticate to the email server have changed. For developers in the audience, here is what happened.
Instead of having the following code, which connected to the server with no authentication:
|
MailAddress from = new MailAddress("inf@sharemuch.com");
MailMessage Message = new MailMessage();
foreach (string mailAdress in mails)
{
Message.To.Add(mailAdress);
}
Message.From = from;
Message.Body = MailBody.ToString();
Message.IsBodyHtml = true;
SmtpClient smtpClient = new SmtpClient();
smtpClient.Host = System.Configuration.ConfigurationSettings.AppSettings["SmtpServer"];
smtpClient.Send(Message);
|
We now needed to add the following before sending the message:
|
System.Net.NetworkCredential cred = new System.Net.NetworkCredential();
cred.UserName = ConfigurationSettings.AppSettings["User"];
cred.Password = ConfigurationSettings.AppSettings["Pass"];
cred.Domain = ConfigurationSettings.AppSettings["Domain"];
smtpClient.Credentials = cred;
|
