Entries:
Comments:
Discussions:

Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Planky

Planky Planky

Niner since 2010

Planky is the Azure evangelist in the UK who is obsessed with the concept 2 rowing machine...

See more entries…

  • Click-by-click - Creating load balanced VMs using Azure Resource Manager in the Azure portal

    Well, kind of, yes. It's security by obscurity because you still have a public endpoint with a public IP address, it's just that it's attached to a load-balancer. Having NAT rules for the RDP endpoints on each VM would allow you to map high ports on to 3389 (rdp). So an attacker would have to know which port to use to get to a login prompt on the VM. They'd obviously know the URL because it's the URL of your website. They could just do a port scan at that DNS name.

    Having additional IP addresses for each VM increases the attack surface by adding extra IP addresses, which I think is your point. But your attacker would have a more difficult time finding those IP addresses than scanning the ports at a known DNS name.

    But then again, there are limitations on the numbers of IP addresses you can expose. Also you could put NSGs to allow only certain external IP addresses through. But you can also do that, for the RDP protocol, on the load balanced endpoint as well.

    At the end of the day you have to make some decision on how you protect it, one way or the other - with each having their own advantages and disadvantages.

    Perhaps the best way to achieve this is to have no directly attached IP address (ie have all traffic coming from the load balancer) but have NSGs to forbid all traffice except HTTP (and possibly SSL). If you want to RDP in to the machines, you have a site-to-site VPN from your on-prem infrastructure. That way you'd use an "internal" IP address to get to RDP for those times you need to configure something or perform troubleshooting.

    But thanks Viron - it's a good point you make. I made the video to show how to configure these things, rather than give security guidance on which method to choose. Until recently, the Public IP address, Load Balancer, NSG etc didn't appear in the Azure portal and you were forced to use Powershell/CLI/REST/Resorce Group Templates. It's probably easier to test and experiment while things are in the portal's UI.

    Thanks for your observations.

  • Introduction to Azure Active Directory Administrative Units

    Good point. But think about it. Groups are security principals. They are the entity that is granted or denied access to a certain resource. A group is granted read access to a file. A group is denied access to the payroll file and so on.

    Admin Units are the resources. They are closer in equivalence to the files in the above example. Sure you put users in them and they are a container in that respect, but they aren't security principals.

    Then we get in to the age-old argument about "yeah, but seeing as they are containers (or more accurately, they are lists), they are a bit like groups, so why don't you just modify the system so that groups can be both resources and security principals. That way, there'd be no need to think about yet another container-type".

    But of course that would require fundamental changes to the underlying system and the way it's been set out architecturally from first principles. Maybe we could have a special type of group that only has the properties of a resource, not of a security principal. Well, luckily - that's effectively what an Admin Unit is. But I get your point, on the surface it seems like inventing something that's already been invented. But hopefully this explains why it's not like that.

  • Crypto Primer: Understanding Encryption, Certificates, Public/Private Key & Digital Signatures

    Hi carstenbh,

    Thanks for the insight. I had considered posting some example collisions - there are examples on the net. Ron Rivest predicted collisions for MD4 many years before it was released, which was 23 years ago and the creation of collisions for fixed-length function outputs have been known for many hundreds of years.

    Yes - there are groups who assert that MD4/5 are broken, with the availability of modern high-speed computers. MD4/5 are still heavily used as the digest in many systems and protocols so I guess we live with what's out there in the real world. We have to be realistic about what we want to change and what's already in circulation

    What you say about finding MD4 collisions is interesting. When you say they "can" be found in less than one second do you mean "it has been shown to be possible to do it in less than 1 second" or "you will find a collision in less than 1 second". I didn't know that, if it's the former. Could you post some example code that would do it? - and I'll add that factoid in to the video. It'd certainly make it more interesting showing a demo spewing out MD4 collisions at 60 per minute! That'd be incredible!

    "Amateurs shouldn't be writing about cryptography" - I guess you can please all of the people some of the time, or some of the people all of the time - but you can't please all of the people all of the time Sad 

    Thanks for the expert insightful observations on MD4 collisions.

    Planky

  • Crypto Primer: Understanding Encryption, Certificates, Public/Private Key & Digital Signatures

    Thanks bPratik. Hope it helped your understanding...

  • What is Windows Azure Active Directory?

    Hi NRGfx,

    Best place to go at first is this video:

    http://channel9.msdn.com/Series/Windows-Azure-Active-Directory/WAADCommonSignupsigninquestions

    Which covers all the common sign-up questions like the ones you have.

  • What is Windows Azure Active Directory?

    Hi BraveStarr,

    Yes - that's exactly right. In federated environments, the authentication itself is performed by the "identity provider" (IP). It the creates a token which is signed and forwarded to the consumer who trusts it. It means the app and WAAD don't do the password management. That is done by the folks who know it best - the IT admins INSIDE your organisation. If somebody forgets their password, they get it changed in AD. If somebody leaves the org, when you disable their account in AD, they are automatically locked out of not only the AD-integrated environments, but also the environments that are federated with the local AD - such as WAAD based apps.

    There's a video which describes the process (using the "old" Ofice 365 directory and apps - exactly the same principles though) here:

    http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-federation-gateway-work-together-up-in-the-office-365-cloud.aspx

     

  • Windows Azure Active Directory: Control Access to Windows Azure

    Hi Dean,

    I can set you on the right track - email me a splank@microsoft.com. I just won't be able to get involved in detail - I'm in the UK. I can put you on to a partner who know this very well - UK based but they have international offices.. I don't know any swiss partners in this cloud/identity space...

  • Windows Azure Active Directory: Control Access to Windows Azure

    Hi CodeGrue - I'd recommend you watch a video I made to explain possibilities between on prem AD and Office 365 (AKA Azure AD) Dirsync. The click-by-clikc screencast first: http://blogs.msdn.com/b/plankytronixx/archive/2011/01/24/video-screencast-complete-setup-details-for-federated-identity-access-from-on-premise-ad-to-office-365.aspx

    and the theory second:

    http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-federation-gateway-work-together-up-in-the-office-365-cloud.aspx

  • Windows Azure Active Directory: Control Access to Windows Azure

    Hi mrpaulb.

    You are describing a feature of IE (since IE8 I think) where if you have ANY instance of IE open, it maintains the authentication cookie across all instances. You could alternatively open private tabs.

  • Windows Azure Active Directory: Control Access to Windows Azure

    Do you mean you had to try 3 different browsers to get the button to appear?

    Anyway I'm glad you have it all working now.

See more comments…