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.
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.
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
Thanks for the expert insightful observations on MD4 collisions.
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:
I can set you on the right track - email me a firstname.lastname@example.org. 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...
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.
On re-reading your opening post I can see that you tried to log in to Azure using a standard LiveID.
To get those new AD features enabled in the portal, you need to log in to the Azure portal using your WAAD account. That means you need to CREATE THE WAAD TENANT FIRST. Go to 11:18 in the video and be sure to follow that initial step. Some steps are not shown in that part because it was recorded on a pre-production system. You need to associate a WAAD tenant with the Azure subscription of the admin of the tenant. Right now, that means creating a new trial subscription. In the spring that restriction will be lifted and you'll be able to associate an existing Azure subscription with your tenant.