Partner Technical Services Blog

A worldwide group of consultants who focus on helping Microsoft Partners succeed throughout the business cycle.

June, 2012

  • Security consideration when using * domain as production environment in Windows Azure

    (Post courtesy Giuseppe Branca)

    The Windows Azure platform offers you an easy way to publish applications: just press the publish button in management user interface. I want to go a little in depth on in what can be a possible security concern if you publish applications using * a production environment.

    Let’s start with a recap

    After having deployed your Windows Azure solution package in the cloud you can start your application. Starting your application will automatically create a first type of URI related to the application; this URI follows the pattern http://* In this phase the wildcard * stands for a group of letters and digits randomly generated by Windows Azure platform, and you are in a phase of lifecycle of Windows Azure application called staging. The Staging phase is a phase intended to be used only for testing; in this phase your application is completely published in Internet but is reachable only by users who know the URI: i.e. only by you, people you’re sharing the URL with, and/or people who can access your Windows Azure Account for managing purpose.

    The second phase is just putting the solution in production, as before it is very easy: just pressing another button in Windows Azure management interface. After that your application will be published with a domain where XXXX is the name you chose when you uploaded your Windows Azure package.

    This means mainly two things:

    1. A very easy way to publish application, if you are not bothered that users will access your application through the domain.

    2. There will be a lot of Windows Azure applications running within the same * domain.

    Indirectly point 1 and point 2 bring two downsides you must be aware of, so now you will learn that for your application in production it’s better to avoid * domain and that it’s better to associate your own custom domain.


    First security concern is phishing. Phishing is a technique whereby an attacker sets up a frontend copy of a website and using social engineering techniques brings users of attacked web site to the phishing site. The user is asked to enter sensitive data (e.g. username and password) into the phishing site, and often users will provide the data because based on the look and feel and URL of the phishing website they are tricked into thinking that they are interacting with the original website they trust.

    A simple example will let you understand this scenario: you did a good job and you finally published your Windows Azure application you called myroomcolor using * domain. So it will be published as An attacker decided to attack your site. So the attacker creates a website with the same layout as your site and publishes it on Windows Azure. The Attacker publishes the application with the URL and then he uses techniques (as link in emails, etc.) to bring visitors to his site. If a user is not very careful it will not notice any difference with your own website, and may insert sensitive data (such as username and password) in phishing site. This is due to the fact that users often base their trust in being in the right place looking at site layout and also to URL of the pages. Layout can easily be cloned, and as you can see an attacker can choose a very similar URL to the attacked one with some typo, or very little differences that can mislead users.

    Cookie stealing, cookie hijacking, CSFR

    The second security concern in hosting an application in the production environment using a domain * is not related with Windows Azure Platform but with the design of HTTP protocol, which makes this scenario inconvenient.

    Let’s consider the HTTP protocol cookie policy in brief. Cookies are a simply way to share data (typically store user control data such as: user session id) between web server and HTTP client using a proper field in the HTTP header. HTTP protocol sets the scope of a cookie to a domain (cookies are bound to a domain); so every time an HTTP client (e.g. a web browser) is connected to a domain it can get/set values of cookies against the server (and the server vice versa to the client). Sending cookies is an operation done contextually and automatically on every HTTP request with every verb (GET, POST, PUT, DELETE ref. RFC2616 from the client (e.g. web browser). Users typically have not much more control of it, clients have settings to customize that behavior but a user cannot choose for every HTTP request which cookie he wants to allow or reject. Server has the same behavior but developers have more control over it because they can use custom code and they can write a custom logic for cookies’ allow/deny policy.

    Consider following scenario: application A and application B are on * domain, that A application is our application and B application is application used by the attacker. Application A binds cookie domain to * instead of

    • User uses application A for hotel reservation. After he booked a room he doesn’t log out from the application and simply closes the tab. Then the user opens a new tab and goes to application B. When user browses application B, browser sends silently cookie to B. So application B can read all the cookies set while user was dealing with application A. Application B can also set values for that cookie, so on the next visit of browser to application A, values set from application B will be sent to application A.
    • User uses application A for hotel reservation. While he’s surfing on A he decides to have a look to his favorite weather channel to have a look at the weather during his own holiday. So user opens a new tab and types URL of his application B and looks to the forecast. For every page request to application B, application B can read and set values for cookies set by application A.

    These two scenarios can be easily generalized creating a wider set of attack scenario. As you can see the fact that cookies are set by different application owners on the same web domain brings the possible threat of cookie stealing or cookie injecting.

    By default ASP.NET cookies running on Windows Azure are bound to the specific domain instead of *, but if a developer intentionally sets this value (or uses a third party framework that does not set the proper value) then the application will be vulnerable to attacks based on cookies.

    So now you are asking how to fix this behavior. The answer is very easy; as this fault is not in Windows Azure but in HTTP protocol, you have to prevent the possibility of a cookie being sent to any other application than the intended one. You can get it associating your own custom domain name to application and emit cookies bound to that domain. In this way cookies of your own application can be read or set only when a HTTP request will address the write context (i.e. right domain).

    How to set a custom web domain for your own Windows Azure application

    Setting a custom domain for your own application is a process that does not involve Windows Azure platform directly. You have to deal with your own preferred DNS provider and you can follow one of these procedures:

    • Bind IP address (A field), so you will bind IP address in Microsoft Datacenter for your application to a custom domain.
    • Use a CNAME field, so you will associate your custom domain to your application, but request will involve a double lookup in DNS.

    You can find more details at

    Additional Information:

  • Planning and Deploying Office 365 Jump Start

    If you are an IT Pro that will be deploying Office 365, or a Microsoft Partner studying for the 70-323 Administering Office 365 exam,  make sure to head over to to watch Ajinkya Pinto and Fulvio Salanitro (Partner Technical Consultants) share the information you need to know before deploying Office 365!

    Deploying Office 365 Jump Start (01): Infrastructure Planning  | TechNet Video

    You can watch the streaming video or download as a WMV, MP4, or MP3 for watching on the go.

  • How to add a custom domain name in SharePoint Online with a federated domain environment

    If you already use a federated domain environment with Office 365, you cannot add a custom domain name at the domain menu in SharePoint Online directly. In this case, you can use the new-MSolFedratedDomain cmdlet in the Microsoft Online Services Module for Windows PowerShell.

    (Post courtesy Soon Im Kim)

    As a SharePoint Online Administrator you can create a public Website. When you setup the site, you can use a custom domain name that your company owns. In this case, if your environment is federated, you should use a new-MSolFedratedDomain cmdlet in "Microsoft Online Services Module for Windows PowerShell"

    This article describes how to create a public-facing Website by using a custom domain name and you can see below 3 blocks:

    • Add a custom domain name
    • Create a Public Web Site by using a custom domain name
    • Create a CNAME record

    Add a custom domain name

    To add a custom domain name, use these steps.

    1. Navigate to Microsoft Online Services Module for Windows PowerShell by going to Start-> All Programs -> Microsoft Online Services. Right click on Microsoft Online Services Module for Windows PowerShell and click Run as administrator.


    2. Once PowerShell is open, run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 admin username and password.


    3. Run Connect-MsolService -Credential $cred. This cmdlet connects PowerShell session to your Office 365 account.

    4. Confirm domain names in the Office 365 tenant domain using Get-MSolDomain.


    5. Add a custom domain name you want to use as a public Web site address using new-MSolFederatedDomain cmdlet. Then, you can confirm your custom domain name is added using Get-MSolDomain again.


    6. Now you can find your custom domain (in this example, ) at the Office 365 Domains and using Domain Intent menu, you can make this domain as a SharePoint Online Services as below.


    Create a Public Web Site by using a custom domain name

    1. Go to SharePoint Online Administration Center and Click ‘Site Collections’.

    2. Click ‘New’ button and Click ‘Public Website’.


    3. Create your Public Website. At the URL, choose the custom domain name you want to use as a SharePoint Public Website address.


    Create a CNAME record

    Now click DNS Information and find what is suggested to add as CNAME then go to your domain manager and add a CNAME record in the DNS as per the information provided.


    After updating DNS you can browse your site from internet using your domain name. Now we can find the Public Website as below.


    Additional Information

    To learn more, check out the following articles:

    · Article 1,

    · Article 2,