Skip to content

Phone Screen Interview

When you are hiring a developer and start looking at resumes or LinkedIn profiles it is very common to find people with a great resume or professional profile – but be careful because having a great looking resume or awesome LinkedIn profile doesn’t always translates into greatness – this guy must be great, it has tons of LinkedIn recommendations and many connections!

A phone screen interview is a very common filter used when hiring for a tech position. As a software developer myself I’ve participated in a fair amount of phone screen interviews both as the candidate and as the interviewer. The phone screen interview is what the name implies, it is a relatively quick way to screen candidates and filter out the best candidates from the group of people who look good on paper (or LinkedIn). A phone screen interview can be very useful to determine if a candidate is truly a great candidate that you want to invite to a face-to-face interview with your team or just someone with a good resume.

When done right, the phone screen can save you and your team from spending hours interviewing the wrong person for the job.

The first rule of thumb is to try to talk as little as possible, just ask a few key questions and let the candidate do the talking. Listen carefully and notice how they respond to questions they know and pay special attention to how they answer and elaborate on things they are not too familiar with. This will tell you a lot about their personality and how they behave when they are under a bit of pressure. The phone screen interview should not take more than 30 minutes and ideally, it should be split into two basic sections: personality and technical skills. Remember that the goal is to decide if you want to invite this person to a face-to-face interview and not making a hiring decision over the phone.

Here are some tips that can help you get started.

The agenda

  • The phone screen interview should be kept at about 30 minutes.
  • Ask questions, listen and thank the candidate for their time.

The personality part

  • Communication skills and story telling. Ask about their decision to be in the technical field. This usually helps to tell how good are they at story telling and it also helps to know how much they love (or not) what they do.
  • Ask about their opinion about a certain framework. Most technical people, specifically developers are very opinionated and passionate about their craft and the tools and frameworks they use.
  • Ask about the reasons they want to join your company, and if they are open to it ask them if they want to share the reason they are leaving their current employer.

The technical part

  • Ask about what technology stack they have more experience with and let them go into details.
  • Once they tell you what technology stack they prefer ask a few more in-depth questions about it, this will help you figure out how much experience they really have about it.
  • Ask if they can explain how the architecture of a website or application like yours work (if applicable).
  • Ask a plain technical question such as how to reverse items in a list or characters in a string. You can also ask something more generic, for example how to handle errors in a web application.

The above has worked very well for me, I have used it more than a few times in the past with really good results. If you are the one being interviewed, my suggestion is to offer to answer some of these questions even if the interviewer does not ask you this; unfortunately many times the one person doing the phone screen interview is someone from an HR department and it might be beneficial to you if you drive the interview by offering to talk about the things mentioned above. If you are hiring for a technical position other than a web developer then you might want to change the technical questions around, just keep in mind that the goal here is to get the best candidates for a face-to-face interview that will and should contain more in-depth technical and personality questions.



How to use Active Directory groups to restrict access to controller actions in ASP.NET MVC and make your application even more secure!

It’s been a year and one of the most popular posts in this blog still today is How To: Secure your ASP.NET MVC application and use Active Directory as the Membership Provider. In that post I promised to write about how to use Active Directory groups to restrict access to controller actions to make your application even more secure by consolidating access based in already defined groups in Active Directory (AD). I finally got to it and here it is.

Remember that if you are not already using Active Directory as your membership provider in your application, you need to first follow the steps described in the first post mentioned above.

In a business, the use of Active Directory to organize user and computer accounts is very common. When we create new web applications for that business it is likely that we want to have some access control to certain areas of the application. For example, let’s say that you have a web application that helps accounting and customer support get details about a certain customer such as reports, invoice details, account information, etc… In such application there is a good chance that accounting and customer service employees will have different access to different areas in the application.

The Example

Here is an example of what such a task will look like in the controller of your MVC application:

public ActionResult DeactivateMembership(Membership model)
    // your business logic here
    return View("DeactivateMembership", model);

And here is what is going to look like with an attribute that will only allow users in the customer service group to execute such task

[AuthorizeAD(Groups = Constants.CSgroup)]</strong>
 public ActionResult DeactivateMembership(Membership model)
    // your business logic here
    return View("DeactivateMembership", model);

The custom AuthorizeAD attribute

The custom attribute labeled AuthorizeAD is what makes this happen, below is the declaration of this custom attribute that access Active Directory to determine if an specific user or group within AD has access to a defined controller action:

namespace Application.Filters
public class AuthorizeADAttribute : AuthorizeAttribute
    public string Groups { get; set; }
    protected override bool AuthorizeCore(HttpContextBase httpContext)
        if (base.AuthorizeCore(httpContext))
           /* Return true immediately if the authorization is not 
           locked down to any particular AD group */
           if (String.IsNullOrEmpty(Groups))
               return true;

           // Get the AD groups
           var groups = Groups.Split(',').ToList();

           // Verify that the user is in the given AD group (if any)
           var context = new PrincipalContext(

           var userPrincipal = UserPrincipal.FindByIdentity(

           foreach (var group in groups)
           if (userPrincipal.IsMemberOf(context, 
               return true;
         return false;

protected override void HandleUnauthorizedRequest(
AuthorizationContext filterContext)
        if (filterContext.HttpContext.User.Identity.IsAuthenticated)
             var result = new ViewResult();
             result.ViewName = "NotAuthorized";
             result.MasterName = "_Layout";
             filterContext.Result = result;

The code above overrides the AuthorizeCore call which allow us to customize the authorization check so we can use the Active Directory in our domain.

The implementation

To limit access to controller actions you will use the new custom attribute like this:

[AuthorizeAD(Groups = Constants.CSgroup)]

Where Constant.CSGroup is just a constant value I created that translates to the actual name of the AD group. This can also be used to aggregate two or more AD groups as one value if needed. In the class below I set the value of CSgroup to be the name of two different AD groups in my domain, the csr group and csr_leads group:

public static class Constants
        /// <summary>
        /// CS - Customer support and customer support leads
        /// </summary>
        public const string CSgroup = "csr, csr_leads";

If you don’t need to do this then you can use the custom attribute by simply providing the name of your AD group, a user name or the name of a Role within your Active Directory:

// Only give access to a group
[AuthorizeAD(Groups = "yourADgroup")]

<strong>// Give access to a group and a user
[AuthorizeAD(Groups = "yourADgroup", Users = "someuser")]</strong>
// Give access to a Role
[AuthorizeAD(Roles = "Admin")]

That’s it! Hope this is helpful for you and as always, if you have a recommendation, a comment or question please use the comment’s section below.


How to build a software product in your spare time

I have been writing code professionally since the early days of .NET although I remember doing lots of classic ASP as well. As a student, I did some C++, BASIC and even some Pascal but not enough to be good at it. I consider myself a great decent developer and very enthusiastic about coming up with ideas to use new frameworks and platforms to design and build new software products. It is my idea of fun and have been doing it for quite some time now. Sometimes with the idea and ambition of building companies around my product ideas.

My guess is that most software developers enjoy testing new technologies and some even do it in their spare time, outside of work and probably late at night (it’s the best time to code, especially if you have children!). However, one thing that I get asked often is where do I get the time to think about products and more specifically where do I find the time to do it. You see, to me is not about building the next killer app or anything like it, it is about thinking of how I could use that cool new JavaScript framework, experimenting with a new platform or perhaps some mobile app that will finally get me into mobile development… and it all sounds good until you start finding excuses and convince yourself that you just don’t have the time to do it. If you are in my age group you will likely find excuses involving the kids, the wife, the house chores, the full-time job, etc… and if you are much younger than me then your excuses are going to be the friends, games, parties, or even a job or school.

Excuses are evil, they offer an easy and sometimes pleasant way to avoid doing something new. I hope some of the tips provided below can help you avoid excuses and get you motivated to build a new app or try out some cool new framework.

Originating ideas

Believe it or not, coming up with ideas might be challenging sometimes, one thing I find very useful is to just take a moment, walk, and think of the things I do on a daily basis that I could do better. This task will take you probably a few minutes and you’ll be surprised with the number of ideas you will originate. Some examples of things I have built doing this are, a translation app, a spam blocker, a profile finder and a useful contact merge tool, etc… all of these were created based on this procedure.

Another great way is to ask people around you, or better yet, observe them and find out what things they struggle with while doing their work, using the computer, etc… For example, years ago while at a customer’s site I saw how some people were doing data entry on their computers and getting the information from a piece of paper, after that they scanned the piece of paper and then named it manually… one page at a time, yikes! From this came the idea of creating an application that would allow people to scan all documents at once, then display the scanned pages on the screen along with the data entry fields right next to the image so they could then do the data entry and indexing needed, reducing the task to just a few steps, much quicker and the data entry more accurate. This eventually became a product for a company. Just look around you and think… how can I do this better, how can I reduce the number of steps and if you are brave enough go out and ask people these same questions and you’ll get plenty of ideas!

Designing your product

You have an idea, now what? it is really easy as software developers to just start writing code, this is both fun and common but if you start your application from scratch then it will take you more time, especially if you are using a new framework, etc… The assumption is that you are trying to build this in your spare time at 2 AM in the morning, so you need to plan and optimize for it. The advice here is not to write any code just yet, instead search for open source projects that are using the technology or framework you want to try, download it and build on top of it. It is not cheating, it is a great way to get started and building on top of an existing open source application or software sample will get you ahead and save you a lot of time. Remember, the goal is to build something fast and useful.

Forget about adding any features, focus on the one thing you are trying to solve and nothing else… do not worry about the look or adding extra functionality, first, make sure what you build achieves what you are going after and then you can iterate and add features and improve the look and feel of it.

Finding the time to do it

This is by far the main reason people will never do something they say they want to do. The lack of time according to most is the reason a new language is not learned, a book is not read, a class is not taken and an app is not built! Time is a very valuable thing that we all protect because none of us seem to have enough of it. Let me tell you this, that is bull-crap. the idea of not enough time is overrated, we use it as an excuse to not do the things we need to be doing or worse, to avoid learning or doing something new. Also, I am against working super long hours, it is not healthy and not even productive, instead try to prioritize your tasks, and eliminate or avoid your time-wasters. All of us have a bag full of those.

I used to watch TV every evening, but haven’t had cable for about 5 years now and do not miss it. Yes, I do watch some shows but when I do it is usually using Netflix or Hulu and is usually playing in the background as I am writing or coding. The time I used to spend in front of the TV I now use to write blog postsbuild software, and organize meetups. I know many of you might say you lack the time to do any of this but I disagree, there are way too many hours in the day, spending just 2 hours every day to write that mobile app you’ve been thinking about for a while is very feasible. Above I mentioned I usually write software late at night, that is when my kids are in bed and the house is quiet – it is the perfect time! I don’t spend more than a few hours but sometimes I will spend more time learning about email marketing, writing blog posts, finding useful things on Twitter, etc… it is my hobby and I don’t see any of that as a task, it is enjoyable for me. At the same time, I help around the house, wash dishes, take the kids to school, to swimming lessons, etc. There is enough time to spend with the family since luckily I don’t have to travel much, having a balanced life is not only possible but very real, it is all about spending time on the things that really matter and avoiding the things that are neither useful nor productive.

There is also plenty of time while at work… and I am not suggesting you work in your personal projects during work hours but at times such as lunch. Yep, I love going to lunch with my co-workers but that does not mean I have to do it every day. At least twice a week I spent my lunch time eating a sandwich or cheap sushi and coding away (my own app), writing a blog post, or doing some marketing for some of my projects using email and social networks.

Are you in a different situation where you still cannot find the time to do this? if the answer is Yes then chances are you are not really motivated to do it… excuses are easy to come up with, and I am sure the next time you are watching a TV show, a movie or a game you’ll remember this and think… I guess I do have time if I really wanted to. Do not get me wrong… I love watching some TV shows and movies… maybe too much, but still find the time to do what I like which is developing software apps, sites and writing blog posts like this.

Finally, if you are lucky and use public transportation for your work commute… then use that time to do this, and perhaps, even more, things such as finish reading that book, learning that new language, etc…

Do you have any tips or ideas to add to the above post? please share them with everyone in the comments.

Bug Tracking Done Right

Many companies today track bugs and features in a bug tracking system, this is a good thing. It is necessary to record bugs which I define as things that aren’t working in a software application and that have the potential to affect the performance and output of such applications. When a customer calls and tell us that they couldn’t purchase an item in our website, or that some data does not look correct, or that they got an error and the application is throwing some obscure error message then you know that there is a problem somewhere. It doesn’t necessarily mean that there is a problem with the software itself, it could be a problem related to another system being down, corrupted data in a database, lack of permission, etc… When something like this happens, companies big and small need to have a bug triage system that allows them to sort out these bug reports before they go into a bug tracking system and are exposed to software engineers.

Bug Triage Done Right

In a hospital, triage happens the instant a patient arrives through the emergency room doors. His vital signs are checked, his status assessed, and he gets sorted in amongst all the other patients waiting for treatment.

Bug triage is a lot like that because we assess bugs to determine whether or not they have enough information to be worked on and assign a priority to them as soon as possible.

Triaging bugs consists of several things:

  • Responding to new bugs as they are filed.
  • Ensuring that new bugs have all the necessary information.
  • Assigning bugs to the proper package.
  • Confirming bug reports by trying to reproduce them.
  • Setting the priority of bugs reports.
  • Searching for and marking duplicates in the bug tracking system.
  • Sending bugs to their upstream authors, when applicable.
  • Cross-referencing bugs from other distributions.
  • Expiring old bugs.

If you receive a considerable number of bug reports every day and you don’t have a bug triage system then you are doing it wrong. Remember that each one of these “bugs” will need to go through the steps mentioned above, or at a minimum they will need to be read, assessed, and sorted so that it can be easily reproduced, fixed and tested if they are in fact bugs. I have worked in projects where software users had the ability to add bugs to our bug tracking system causing us (the software developers) to deal with a large numbers of items where only a small percentage of them were real bugs. This is wasteful and it hurts the productivity of a software team, make sure that whatever gets logged in your bug tracking system is in fact a bug that has all the information necessary to be reproduced, fixed, and tested. Have a system that checks for the things listed above and be very careful not to pass bug reports to software developers without confirming them during the bug triage step. You’ll have happier developers and a better product overall.

Below is a flow chart showing you the basic steps of bug triage:

Bug Triage Flow Chart

Image credit:

As this flow chart shows, many of the request that come from software users might not even be bugs, they could be a feature request or a support question and that is very common. The bug triage step should be the first thing you do with all bug reports added to your bug tracking system and if you are not doing some sort of triaging you are doing it wrong. If your bug tracking system doesn’t have a way for you to do bug triage, don’t worry that not everything is lost, you could simply create a spreadsheet where all the new bug reports are sent so bug triaging can be done.

Confirmed Bugs

The result from bug triaging are confirmed bugs, and when a bug is confirmed the status should change to “Ready”, “Confirmed” or “Triaged” so it can be made available to the software developer to work on it, after the importance and priority have been set. Before changing the status of a bug report make sure you have answered all the questions below BEFORE you mark it as Ready, Confirmed or Triaged, or whatever status you choose in your system to pass it on to the next level:

  • Does the bug report describe a valid bug?
  • Does the bug report contain enough details?
  • Is the bug report ready to be worked on by any software developer?

Only if ALL of these conditions are satisfied, you can change the status of the bug report and move to the next step which is setting the importance and priority of this bug.

Setting Importance Of Bugs

Below are some examples and the meanings of the most common importance values:

  • Undecided: The default for new bugs. Also means that there is insufficient information to determine importance. PLEASE mark all of your bug reports with this status as they are entered into your bug tracking system.
  • Wishlist: Missing functionality.
    • These aren’t always bugs, but can be ideas for new features which do not yet exist.
    • These can also be requests for new features.
    • If it is non-trivial to implement, it should rather be written as a feature specification.
    • These can be bugs that affect an experimental extension or non-essential feature of a given application/project.
    • Bugs that would only be fixed on a best-effort or outside-contribution basis might also be considered wishlist.
  • Low: Bugs which affect functionality, but to a lesser extent than most bugs, examples are:
    • Bugs that have easy workarounds
    • Bugs that affect unusual end-user configurations or uncommon hardware
    • Bugs that affect a non-essential aspect and limited scope of the application
    • Bugs that have a moderate impact on a non-core application
    • Cosmetic/usability issues that does not limit the functionality of a non-core application
    • Non-ideal default configurations
  • Medium: Most bugs are of medium importance, examples are:
    • A bug that has a moderate impact on a core application.
    • A bug that has a severe impact on a non-core application.
    • A bug which impacts accessibility of a non-core application.
    • A usability issue that does not limit the functionality of a core application.
  • High: A bug which fulfills one of the following criteria:
    • Has a severe impact on a small portion of your application’s users (estimated)
    • Makes an application generally unusable for some users
      • For example, if a certain area of your application does not work at all, or on a specific browser version, etc…
    • A problem with an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse)
    • Has a moderate impact on a large portion of your application’s users (estimated)
    • Prevents the application or any dependencies from functioning correctly at all
    • Renders essential features or functionality of the application or dependencies broken or ineffective
    • Impacts accessibility of a core application
  • Critical: A bug which has a severe impact on a large portion of your application’s users
    • Causes data corruption
    • Crashes the entire application or operating system
    • Renders the system temporarily or permanently unusable
    • Severely affects application’s core functionality

Once the bug reports have been set with the right importance, then it is easier for everyone involved in fixing them to know what bugs are priority.

Software developers are the ones who should set the bug report status to “Dev Complete” or something similar as soon as they have fixed a bug so the QA team can test again and make sure the bug is fixed. Involving your QA team early on in this process is key, you shouldn’t wait until a developer is done “fixing” a bug to get QA involved in the process… it is too late by then and I will write about this in a future post.

Invalidating Bugs

Sometimes, you will have to invalidate a bug report. There are bugs reports that just don’t seem as important or perhaps are lacking a lot of details so they just get added to the “to be triaged” group. Yes, I am talking about those bugs who stay in a backlog with the same status in a bug tracking system for days and even months, these should be invalidated, retired, or removed from your bug tracking system. If you keep these bug reports around because you worry these might be real bugs, then removing them will not make any difference, if it is a real bug it will be reported again, trust me.

You see, when a bug report does not seem to be critical, or perhaps it falls to the bottom of a list because there are so many other bugs with higher priority, then you should consider how you handle these not so important bugs. My advice is to let them expire automatically. You can set up your bug tracking system so if a bug report doesn’t have any status changes, or any new information added to it for 60 days then it automatically expires and it is invalidated from your bug tracking system. If you don’t do this, then is really easy to end up with an unmanageable number of bug reports and as Joel Spolsky wrote a while ago, you’ll be just adding software inventory to your team. It is not a good thing, check it out.

Keep It Simple

As with ANY other system, find what works for you and your team and stick to it. Avoid at all costs the idea of keeping ALL bug reports that get submitted to your bug tracking system. Just like your to-do lists, if it goes unmanaged, the items at the bottom of the list end up just wasting space, are forgotten and it also makes the to-do list incrementally larger than what it really is. Keep it simple, triage all bug reports, fix them and test them. Do not keep bug reports around thinking that one day you’ll get to it, you never will and if you do, it is because you or somebody else made the bad decision about spending time and effort on something that was very low priority and probably not important.

Every time you open your bug tracking application and then you look at the feature or bug backlogs and realize you have just too many items, do not cry, just remember to set an expiration date on all backlog items. I suggest 60 days, and as your process gets better you can then lower this number, IF you make it more than 60 days, don’t be surprised if some of those things never see the light of day.

Feature requests can also become a problem, every time somebody suggests a cool new feature or has an idea… make sure you look at your backlog first and decide if this new feature or idea are worth doing in the first place, this might prevent you from wasting time documenting and designing a crazy idea that might also never see the light of day.

Keep your backlog and entire bug tracking system lean and tidy, and hopefully you’ll spend less effort working on things that never see the light of day. Trust me, “Backlog grooming” sessions is something to be avoided, it just adds to the overhead and more meetings, who wants to do that?!

Switching to Windows Azure

The annoying sound of the alarm clock crying for attention at 5:00am in the morning woke me up. Everybody in my house was still sleeping, after all it is summer and it was just 5 in the morning! For a moment I thought about going back to sleep and forget about the reason I setup the alarm at such an early time, especially after going to bed around 3am, just a few hours earlier.

About 30 minutes later I was outside and in my car, and I started to drive on IH35, heading north, I was on my way to Dallas to attend a Microsoft Azure Summit. For a while I have been thinking about using Azure for my software startup but have been avoiding it since other cloud solutions offered by Amazon and Rackspace have been sufficient to host a few web applications and image files. The reason I have been avoiding Azure is because the first time I tried it, almost two years ago, I was disappointed with it for various reasons, the product didn’t seem to be ready, it lacked many basic features and there was not enough documentation. I have been using Amazon S3 for file storage and Rackspace’s Cloud Servers for my web servers and database.Continue Reading →

How To: Secure your ASP.NET MVC application and use Active Directory as the Membership Provider

Securing your ASP.NET MVC application should be priority number one every time you start a new web application. Using the attributes Authorize and ValidateAntiForgeryToken in every controller and action is the only way to avoid any security holes. In this post, I’ll show you how to secure your ASP.NET application by implementing the AuthorizeAttribute and ValidateAntiForgeryTokenAttribute classes.

The basics

At the very least, you should add an [Authorize] attribute to every controller or controller Action in case you want some of the controller actions to be accessible by anonymous users. For example, you probably want ALL users to have access to the login and register actions of your web application.

By decorating the HomeController with the Authorize attribute (notice I did not specify any user role), the application will prevent any unauthenticated user from executing any of the actions in this controller.

public class HomeController : Controller

The following is an example of decorating a controller action with the Authorize attribute, you want to do this when you only want to restrict access to some of the actions in a controller instead of all actions.

public ActionResult Create()

Protecting against Cross-site request forgery attack (CSRF or XSRF)

The Authorize attribute offers protection that is sufficient in most cases. However, there is a security hole with this, and thus it opens your web application for a cross-site request forgery attack. For example, after a user logs into your site, the website will issue your browser an authentication token within a cookie. Each subsequent request, the browser sends the cookie back to the site to let the site know that you are authorized to take whatever action you’re making, so far everything is okay.

Here is the problem with only using the Authorize attribute, let’s say that a user is logged in to your website and then they go to a spam site by clicking on a link that points to another site which causes a form post back to your site… this is bad, your browser will send the authentication cookie to your site making it appear as if the request came from your website and initiated by an authenticated user when it really didn’t.

The above scenario is called cross-site request forgery and can be avoided by adding the ValidateAntiForgeryToken attribute available in the .NET framework, this attribute is used to detect whether a server request has been tampered with.

The first step is to add the ValidateAntiForgeryToken attribute to every Post Action as follows:

[HttpPost, Authorize, ValidateAntiForgeryToken]
public ActionResult Create()

The next step is to add the HtmlHelper method @Html.AntiForgeryToken() inside the form in your view.

The way the ValidateAntiForgeryToken attribute works is by checking to see that the cookie and hidden form field left by the Html.AntiForgeryToken() HtmlHelper essentially exists and match. If they do not exist or match, it throws an HttpAntiForgeryException shown below:

“A required anti-forgery token was not supplied or was invalid.”

By adding the ValidateAntiForgeryToken to your controller actions, your site will be prepared to prevent CSRF/XSRF attacks.

Implementing Forms Authentication using Active Directory (AD)

Often times you might run across a project where you need to authenticate users of your website using Active Directory credentials, the good news is that you can use the existing “Account” controller to achieve this, only a few modifications are necessary.

When you create a new MVC Web Application project and choose the Internet Application template, the Account controller is added to the project, you can use this controller with AD to authenticate your users. For the Account controller to work with AD we need to remove all Actions but the following:

  • Logon()
  • Logon(LogOnModel model, string returnUrl)
  • LogOff()

Your Account controller should look like the following after you remove the unnecessary Actions such as ChangePassword, Register, etc…

public ActionResult LogOn()
            return View();

        public ActionResult LogOn(LogOnModel model, string returnUrl)
            if (ModelState.IsValid)
                if (Membership.ValidateUser(model.UserName, model.Password))
                    FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);
                    if (Url.IsLocalUrl(returnUrl) && returnUrl.Length > 1 && returnUrl.StartsWith("/")
                        && !returnUrl.StartsWith("//") && !returnUrl.StartsWith("/"))
                        return Redirect(returnUrl);
                        return RedirectToAction("Index", "Home");
                    ModelState.AddModelError("", "The user name or password provided is incorrect");

            // if we got this far, something failed, redisplay form
            return View(model);

        public ActionResult LogOff()

            return RedirectToAction("Index", "Home");

After this, go ahead and clean up the AccountModel as well so the only model class left is the LogOnModel:

public class LogOnModel
[Display(Name = "User name")]
public string UserName { get; set; }

public string Password { get; set; }

[Display(Name = "Remember me?")]
public string RememberMe { get; set; }

Lastly, add the following to the project’s web.config file:


That is all! The first code snippet is the connectionstring to your Active Directory server and the second one is where we specify Active Directory as the application’s default membership provider.

Save your changes, hit Ctrl-F5 and login to your application using your domain/AD account.

Hopefully, this will help you get started to secure your ASP.NET web apps and show you a straightforward way to use ASP.NET’s membership services with Active Directory.

In this post, I show how to use Active Directory groups to restrict access to controller actions and make your application even more secure!

How to: Configure SQL Express to accept remote connections

This is a copy of the post that used to exist here for which I got some complaints since some people where still trying to read it when looking at an answer I wrote on StackOverflow a few years ago and the page was not there anymore. The above is an exact replica of the original post, hope it helps:

I just installed SQL express 2008 recently and wanted to use it for a test application that I have in a hosted server. I wanted for this application to connect to my local SQL express 2008 database but soon I found out I needed to do some adjustments for this to work. So this is what I did to make my local SQL express 2008 db accept remote connections.

  1. Go to Start – All Programs – Microsoft SQL Server 2008 – Configuration Tools – SQL Server Configuration Manager
  2. Select and expand the SQL Server Network Configuration node and then select your SQL express 2008 database. In the window to the right, right-click on TCP/IP and click on “Enable”.
  3. Once you have enabled the TCP/IP protocol, right-click on it and select Properties, go to the tab labeled “IP Addresses” and make sure you clear any values under TCP Dynamic Ports (even if it is 0, remove it), and then add a new port number on each one of the TCP Portproperties. In my case I used port 14330.
    Click Apply and OK.
  4. You now need to restart SQL express 08, to do this, select the SQL Services node in the same SQL Server Configuration Manager and the right-click on the name of your SQL express 08 instance and select restart. If you receive any errors trying to restart your server, go back to step 3 and make sure you did everything I mentioned, if the error keeps coming up, then use a different port number.
  5. Finally, you need to make sure a remote connection can be made to your SQL server, so we need to open the port you assigned on step 3 (in my case 14330) in your router and make sure Windows firewall and/or any other firewall accept incoming connections to this port.

That’s it! your SQL express 2008 server should be able to accept remote connections now. As always, make sure you take the appropriate steps to make sure your systems are secure.

Good Luck!