In the last post I talked about my first impressions with Permissions Management and AWS account. Since then, I had a chance to play a bit more with this configuration. Specifically, I configured federated access from my Azure AD tenant to AWS account. One of the reasons I wanted to test this configuration is to see if we can use privileged access workstation (PAW) for cloud services management, which is joined to Azure AD tenant and managed via Azure based controls and uses Azure AD account, to manage AWS Account. The configuration is shown in the following diagram.
Federated access with AWS does not require an account in AWS IAM. If we look in AWS Account IAM, we will not see AWSAdmin user account. As we configure this configuration, we create a role in the AWS Account and assign this role with necessary policy, as in the below diagram I configured it with the highest permission – AdministratorAccess policy. As part of this configuration this role is synchronized to Azure AD application for AWS federated access. Azure AD then can assign AD based user account to this role.
The authentication flow works at high level in the following order:
- User logs on to their PAW with Azure AD account, in this example AWSAdmin account
- User initiate an IDP Initiated SSO to AWS account
- User is authenticated to AWS Account with their AWSAdmin federated account and have permissions in AWS Account based on the role permissions, in this example, AdministratorAccess policy
So what does it have to do with Entra Permissions Management?
I was pleasantly surprised to find that Permissions Management reports federated accounts used to access AWS Account as privileged accounts and shows them as SAML user accounts. This is very valuable information as we need to perform account disposition on AWS account.
To be fair, there should be a way to identify these accounts by looking in AWS logging or other native way to identify it, but as mentioned before, I’m not an expert in AWS and having tool like Entra Permissions Management identifying it in single user interface accounts that require attention is very helpful.
The following diagram shows couple accounts from my Azure AD tenant that have Super Identity access to AWS Account.
Till next time my friends!
Well, after a few years of absence, I’ll try to write here once in a while.
Something about cloud security… mainly Microsoft technology stack… as that is what I am most familiar with 🙂
See you soon!
Hi there, in my last post (yes, more than 15 month ago), I started describing overall framework that can be used to securely design and implement applications in Azure.
Secure administration is one of the foundation blocks of overall security for applications deployed into Azure. Over the next few blog posts we’ll discuss different aspects of secure administration over Azure resources and some ideas on how to make it all work.
One of the main principals of secure administration is trust in user identity that is used to perform administration over resources. This trust assures us that identity is not compromised and is not subject to compromise by the bad guys. To have this trust we need to have a solid administrative architecture that ensures that privileged accounts can be used only from approved, properly managed devices with no or very limited attack surface. The goal of such architecture is to ensure that trusted identity can be used only from managed trusted devices and its use on any other device would be denied.
Before we can look at different administration models of Azure based resources, we need to understand how resources in Azure can be controlled via different technical controls.
Means of Control over Azure based Resources
Resources deployed in Azure can be controlled via the following mechanisms.
1. Administration of Azure based resources via Azure Control Plane
Azure Control Plane is the de facto access mechanism to control anything in Azure. All Azure AD accounts with administrative roles must be protected to reduce the likelihood of compromise of the customer environment.
- What is controlled: All Azure resources, such as Azure AD, Resource Groups, RBAC, Networking, VM resources, Encryption, SQL DBs, ie any resource in Azure
- Tools used on the client side:
- Browser,
- PowerShell,
- Cross Platform CLI,
- Visual Studio,
- VSTS,
- Visual Code,
- GitHub and many other
- Azure technologies and controls used for administration:
- Account resets,
- ARM templates,
- Azure DSC,
- Azure Automation and other
- Accounts used for administration:
- Azure AD account with assigned RBAC permission to accomplish the task
- Account can be cloud based only or being synchronized from on-premises ADDS
- Main type of accounts with admin access:
- Account Admins in Enterprise Portal
- Tenant level Admin roles:
- Global Admins in Azure Tenant
- Other AAD Roles
- Subscription level Admin roles:
- Owner
- Service Admin and Co-Admin (access to the legacy portal)
- User Access Administrator
- Accounts with RBAC roles assigned at Subscription level, resource group level or resource level
- Means of Control over the resources in Azure:
- Direct via AAD account via assigned permissions on Azure resource
- Indirect via one of the Azure controls that has ability to modify Azure resource or the state of the compute resource (like VM)
It is important to understand that Azure control plane can be used not only to configure Azure resource settings as it relates to Azure, it is also used to configure and manage internal settings and applications on the resource itself. For example, it can be used to configure VM with specific roles and applications and then ensure that this VM is configured exactly as needed, all without ever logging into this VM via traditional remote access mechanisms.
The following diagram shows different means of control over Azure via Azure Control Plane:
2. RDP, SSH or remote management into target VM
Console based access or access via remote management tools is the classic way to manage most operating systems.
This can be done via one of the following mechanisms:
- Connect to the target VM via direct connection, such as ExpressRoute, Site-Site VPN, Point-Site VPN. It requires a routed connection from the client to the target VM
- Connect via Jump Server VM
- Connect via Jump Server VM configured with VM JIT
- Accounts used for administration:
- Operating System based account, such as Windows local accounts or AD DS based domain accounts
- AuthZ within VM is done via OS based authorization model
3. Manage via tools like project “Honolulu”
- What it is: Project “Honolulu” is the code name for new set of remote management tools which use Browser as its client.
- Management of the target system is done via one of the following:
- Direct connection from the client to the target system, with OS based account
- Connection via Web Server Management Proxy that has direct connection to the target systems, authN is done via OS based account
- https://aka.ms/ProjectHonolulu
Behind all of these “means of control” mechanisms are identities (user accounts) which must be properly secured. In the next post we’ll look at current administrative practices and identify where they fall short.
It’s been a while since I blogged here. Perhaps writers block or something. Not like I was not busy over the last 18 or so months since my last post. I have been busy doing different type of work related to security of Microsoft platform, most of it related to the on-premises implementations, not whole lot of Cloud based solutions. This is starting to change and recently I’m getting more involvement with doing bit of security related work with Microsoft Cloud, ie Azure.
Azure adoption is going like crazy. Customers starting to implement their new apps in Azure IaaS or move their existing apps from on-premises to Azure IaaS. Many security conscious customers starting to ask on how to deploy this in the right way, using Azure provided security controls and shift their management strategies from how it was done in on-premises environments, where a lot of things are done via brick & mortar, to pretty much software only environment.
If you done any work in Azure and think about security, then you already found that there is a lot of Azure documentation available on all type of different topics, many are very detailed, some maybe not as one would wish. Azure Security team is starting to consolidate many topics under single umbrella here, which is totally awesome. There are many personal blogs from folks as well, documenting different Azure features. This is all good, having documentation available for specific technical areas.
But there is something missing. It the framework that would take a comprehensive look at all the different areas in Azure and provide guidelines and recommendations on how to design security around application that is being deployed in Azure IaaS. If we could have a framework that can adopt to the constantly improving Azure security controls and have some practical guidelines on how to apply it to our own applications, then I think companies would have a better way to deploy their applications in Azure in a secure way.
I have been thinking about it, read bunch of documentation and other blogs, and came up with initial security framework that I think every application deployed in Azure IaaS should be designed against. This is of course work in progress and subject to change.
If you wonder what it is all about, in the next blog post I’ll try to get a bit more detailed about each of the main pillars in this framework. Thanks!
Token Replay Detection is used to protect applications against replay of the issued tokens by Identity Provider Security Token Service. Active Directory Federation Services (AD FS) provides this capability when it is installed with SQL as its configuration store database. If AD FS is installed with Windows Integrated Database (WID) then this capability is not provided. When implementing AD FS services, it is common question to ask, should it be installed with WID or with full SQL back end. SQL back end provides other benefits besides token replay detection, so it should be evaluated for its full capabilities, not just token replay detection, but if you are wondering if you should use SQL while installing AD FS for token replay detection, you should fully understand in what type of federation topologies this capability is actually will be used.
The following couple diagrams are showing when token replay detection actually used and SQL back end should be used with AD FS implementation. Open them to see all the details.
Hello everyone! Hopefully you had a great summer, I had a good one, not even bothered to post anything on this blog. I do post almost daily on my travel blog, some cool photos from a few places I happen to visit, but this one does require a bit more thought about the technical stuff, not as easy as posting travel photos. Now summer is over, I’ll try to get back into the publishing mood with technical stuff as well.
Today we are going to review a few different ways we can do an audit and usage on the AD FS service.
By default when you install AD FS it does not provide any intelligence into how users use this service. For example if our AD FS is configured with couple Identity Providers (IdP) and a few Relying Parties (RP), and we want to know which users from what IdP are using what RP, and potentially what type of claims are being passed, there is no easy way to collect this data in manageable and usable way.
Let’s review a few different ways that we can do an audit on the AD FS.
1. Use AD FS Debug Tracing Log
See here how to enable it. While this log will collects the information about issued tokens, the way it is collected is not the most convenient way to analyze this data. It collects it in multiple events that would need to be used to extract relevant data. AD FS Debug Tracing logs are really designed for troubleshooting purposes and should not be used for any type of long term data collection.
2. Use Security Audit Logs
See here how to enable it. We can enable Success Audit and Failure Audit in the AD FS Properties. This will log all activities in the Windows Security log. The key thing here to note is that it will log all information into the log. All information in the assertion will be logged into the Security log. If we have a farm of AD FS servers, it will log into the local log and there will be a need to push these logs to some central collection system and then figure out how to do some intelligent analysis against that data. As with the AD FS trace logs, each transaction is collected via multiple event entries, linked to each other by correlation ID.
Using Security Audit will allow to collect all necessary data, it has a few drawbacks:
- Logs from each AD FS server will need to be pushed to a central collection system
- To make any sense of the collected data, there will need to be a software that can comb through the events and pull out data that we are interested to analyze
- As mentioned, these logs will contain all information in the security assertion, potentially including PII and other sensitive data.
So while it is possible to collect data and do an audit, making this type of collection on a long term basis might be fairly complicated to implement and manage.
3. Use SQL Attribute store
This is a custom way to collect information, but this will provide the most flexibility in what we can collect and then it will allow us to create custom reports against collected data in more streamlined way. The following diagram shows the concept of this solution:
1. User will attempt to access application and will be redirected to the AD FS (ADFS Server1 or 2) server.
2. They will be redirected to authenticate to their IDP (not shown) and come back to the AD FS to get a token for the application.
3. AD FS Server will process claims rules for the application and issue required claims for it. At the same time it will connect to the SQL Attribute Store and insert specified claims into the SQL DB.
4. SQL DB can be exposed to the administrator via different mechanisms, such as reporting web service or manual data transfer from DB into text format document.
The type of data collected and how it is collected is really up to you to design and implement. There are different ways to make this work. Let’s take a look at one of them. To use SQL Attribute store to collect data we’d need to perform the following configuration:
1. Create DB on the SQL server with a minimum of one table. You can use on-premises SQL or cloud based SQL. I use Azure SQL in my lab.
2. The table should have columns for the types of claims we want to collect. For example:
Create a stored procedure that will be used to inject data into this table:
Configure AD FS with SQL Attribute store and configure Claims rule on each RP to send claims to this attribute store. You’ll need to make sure that the account you use to connect to the SQL server have write permissions to the specified table.
Here is an example claims rule that works with the stored procedure and our table:
For this rule to work you’d need to make sure that all eleven claim types are present in the pipeline. If one of them is missing then the rule will not trigger the “add” action and it will not run the stored procedure on the target SQL server.
If it is all properly configured, every time user getting a new token for the target application, AD FS will insert a new row into the SQL DB. Based on that entry we will have information about their IP address, their UPN, their Company, the application they have accessed, timestamp etc. You can add or remove required columns as needed.
Of course, the table can be designed differently as well, for example have only two columns: claim type and claim value.
Now we can do some targeted logging and do very intelligent reporting on who uses our applications, where they are coming from, their affiliation, the rate of access etc. There is really no limit to flexibility of what can be done via this logging mechanism.
Security and Identity in the Cloud 