If your company is born in the cloud, and you are using Azure, you will have an Azure Active Directory (AAD) tenant created. This will allow you to create cloud-only user accounts that you can then assign permissions to in Azure (or a host of 3rd party services that AAD integrates with).
As part of your security policy, you should have an comprehensive password policy that is based on industry best practices. NIST has just released a draft policy that updates previous password guidance that has been in effect for ages.
So the questions here becomes, what is the current/default password policy for AAD, how does it compare to the new guidance, and what customization options do you have.
To answer question one, Microsoft has provided a comprehensive guide on the password policy in use for cloud-only accounts. You can find that documentation here. Question 3 is also easy to answer. Based on the documentation, the only things you can change are the password expiry duration and the password expiry notification.
So, how does the policy compare to the new NIST guidance?
Characters Allowed
According to the documentation, Azure does allow a host of characters, but restricts unicode characters and spaces. This goes against current NIST guidance which states:
- All printing ASCII characters as well as the space character should be allowed
- Unicode characters should be allowed
Password Length
According to the documentation, Azure allows for a minimum of 8 characters and a maximum of 16 characters. NIST documentation follows for the minimum, but states the maximum should be at least 64 characters in length.
Password Restrictions
According to the documentation, Azure requires 3 of 4 listed character classes for a password to be considered secure. The new NIST guidance states that verifiers SHOULD NOT impose composition rules.
Password Expiry
According to the documentation, Azure has built-in mechanisms to auto expire a password and provide notification to end users about password expiry. As per the new NIST guidance, users should not be forced to periodically change their passwords. You can configure this behaviour in AAD using the Set-MSOLPasswordPolicy cmdlet.
In conclusion, it is interesting to see the difference between current Azure password policies and the new NIST guidance. If memory serves me correct, the new NIST guidance is still in draft, but provides a preview of some of the changes AAD will hopefully make into the future. When using AAD for your business, you do have limited options in how you can customize the policy that is being enforced. (Please note that this does not hold true for Azure AD B2C)
Friday, February 23, 2018
Wednesday, February 21, 2018
Experimenting with permissions for Azure JIT VM Access
At this point, I've written a couple of posts on Azure JIT VM access.
Getting Started
A look at the activity log
The goal of this post is to discuss a little bit about permissions for Azure JIT VM Access.
Usecase: Here is my example use case. What I'd like to do is have my VM users make use of Azure JIT to request access to their VMs. What I want is to give them the least amount of permissions required to execute the action. So, basically, a server admin who has limited access in Azure, should be able to log in to the portal and request access to a VM.
Ultimately there are two parts that I think need to be factored in here. The first is how does a user actually get access to the portal experience to request access. The second part is how are those requests authorized in the system.
Starting with the second part is actually easier. According to the documentation, the security center will auto-approve a request access provided that the user has write access to the VM. I personally don't like this (particularly for my use case) as now my server admin has access to write to the VM definition directly. But this is what we have to work with in the preview.
The second part is a little bit more complex, and I'm sad to say, that I don't have a good answer here. The first thing I tried was to use the Get-AzureRmProviderOperation cmdlet to inspect what operations were JIT related. Here is a snippit of what actions are available.
The first thing I tried was to create a custom role that contained the following:
"Microsoft.Security/locations/read",
"Microsoft.Security/locations/jitNetworkAccessPolicies/read",
"Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action",
Unfortunately, when I ran the above configuration, I was unable to even access the JIT screen.This is what I saw.
Interesting. At this point I figured that it isn't showing me the JIT options because I don't have access to see that security center is in standard mode (and thus that I do have access to JIT). I tried adding a couple of other actions including:
"Microsoft.Security/securitySolutionsReferenceData/read"
But nothing I did seemed to give me access into the JIT screen. At this point, I gave up and just created a custom role that had read access to security center. Not the best solution, but enough for my current needs. This will probably be something I revisit at some point in the future.
Hopefully this post helps a bit with understanding the permissions required to execute JIT actions in the portal.
Getting Started
A look at the activity log
The goal of this post is to discuss a little bit about permissions for Azure JIT VM Access.
Usecase: Here is my example use case. What I'd like to do is have my VM users make use of Azure JIT to request access to their VMs. What I want is to give them the least amount of permissions required to execute the action. So, basically, a server admin who has limited access in Azure, should be able to log in to the portal and request access to a VM.
Ultimately there are two parts that I think need to be factored in here. The first is how does a user actually get access to the portal experience to request access. The second part is how are those requests authorized in the system.
Starting with the second part is actually easier. According to the documentation, the security center will auto-approve a request access provided that the user has write access to the VM. I personally don't like this (particularly for my use case) as now my server admin has access to write to the VM definition directly. But this is what we have to work with in the preview.
The second part is a little bit more complex, and I'm sad to say, that I don't have a good answer here. The first thing I tried was to use the Get-AzureRmProviderOperation cmdlet to inspect what operations were JIT related. Here is a snippit of what actions are available.
The first thing I tried was to create a custom role that contained the following:
"Microsoft.Security/locations/read",
"Microsoft.Security/locations/jitNetworkAccessPolicies/read",
"Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action",
Unfortunately, when I ran the above configuration, I was unable to even access the JIT screen.This is what I saw.
Interesting. At this point I figured that it isn't showing me the JIT options because I don't have access to see that security center is in standard mode (and thus that I do have access to JIT). I tried adding a couple of other actions including:
"Microsoft.Security/securitySolutionsReferenceData/read"
But nothing I did seemed to give me access into the JIT screen. At this point, I gave up and just created a custom role that had read access to security center. Not the best solution, but enough for my current needs. This will probably be something I revisit at some point in the future.
Hopefully this post helps a bit with understanding the permissions required to execute JIT actions in the portal.
Subscribe to:
Posts (Atom)