Skip to main content

PIM-IT Ver 0.0.2: More features and Activation Packages

Hello everyone! Hope you're having a great long weekend so far, while I type this I am in my bed with my dog and pushing the latest updates to my GitHub. It's been a minute since I last posted but I wanted to take the opportunity to give you all an update on the PIM-IT project, the PowerShell tool for streamlining Privileged Identity Management. Consider this if you will a changelog of sorts, in which I will talk about the latest features, some takeaways, and what is next in the project. Let's get started!


PIM-IT Ver 0.0.2 Latest Features

The first major update is the ability to deactivate and update roles. This is a major step towards giving users full control of managing PIM roles from initial activation to deactivation.











Updating PIM Roles

To update a PIM role, the user selects option "U" from the menu, which will then display currently active roles:





From here, the user will select the PIM role they wish to update, which will allow them to adjust the duration to what they wish. The only caveat is that the process will deactivate the role temporarily and send a new New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest so it is important that the user keep the role active for at least five minutes prior to updating.

Deactivating PIM Roles

To deactivate PIM role on the other hand, the user selects the option "D" from the main menu, which will also display active PIM roles:






This will in turn call on the New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest cmdlet to deactivate the PIM role based on what the user selects.

How does the request to Microsoft Graph work?

The request is a JSON request that is sent via the Microsoft Graph Identity Governance API. A request looks like this:
{
                        Action = "selfActivate"
                        PrincipalId = $currentUser.Id
                        RoleDefinitionId = $roleDefinitionId
                        DirectoryScopeId = $directoryScopeId
                        AssignmentType = "Eligible"
                        Justification = "Assigning role via PIM-IT CLI Tool"
                        ScheduleInfo = @{
                            StartDateTime = Get-Date
                            Expiration = @{
                                Type = "AfterDuration"
                                Duration = "PT"+$setRoleHours+"H"
                            }
                        }
                    }

So there's quite a bit happening here. The most important part of this whole request is the Action parameter of the request. This will determine what action the API will take to interact with the PIM role. 

Activation Packages

This is my favourite part of the project as it offers the most flexibility with PIM roles. Oftentimes, if I am using a PIM role, I typically know how long I want to use the PIM role for and when I want it to be deactivated. Additionally, when I use said PIM role I typically also have the same reason for doing so. I typically recommend to people that when using PIM, that you only use it for the time you need it as this creates a better audit trail if required. However, this can be quite tedious and having to jump through multiple hoops to reactivate a role takes up time. Hence, the invention of Activation Packages!

An Activation Package is a JSON file that is saved to the user's computer upon creating the package. This package comes with pre-defined parameters that the user can set to fit their needs. For example, if I am a Authentication Administrator and I am regularly updating user's MFA methods having an Activation Package would be a suitable feature if I am regularly activating and deactivating the role. I can set the reasoning and duration of the role accordingly and use it every time I need to have that role.

Creating and using an Activation Package





Users select option "A" from the main menu and are given the option to use or create an Application Package. In this case, we will create one, which will prompt us for the role name, duration, justification, and a file name like so:





Once the package is created, then they can use the Activation Package as required:
PPretty cool right? My hope is that with Activation Packages, administrators will have an easier time activating PIM roles without the process of jumping through multiple hoops to get the role and parameters they require.

Key Takeaways

Based on what I can see, there is no easy way to update PIM roles through a cmdlet. However, you can deactivate the role and update it with the time required, which was a workaround for updating PIM roles. If you are updating, activating, or deactivating a role, using New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest and updating the actions in the request seem to do the trick.

In addition to this, I also played around with App Registrations. This can be done, but I found that it was just as easy to use the Microsoft Graph Command Line Tools app registration instead. If you wish to use a separate app registration, you can modify the code to connect through that registration instead. Just ensure that you consent to the permissions needed to run the script, otherwise it will not work.

What's Next?

In the next version of PIM-IT, there will be cmdlets for activating, deactivating, and updating PIM roles. In addition to these cmdlets, there will also be cmdlets for creating Access Packages. Once this is done, I will be moving onto building a GUI for this application to appeal to standard users and power users. But for now, I am going to enjoy the remainder of my long weekend! Happy Victoria Day weekend everyone!




Labels:

test

Using Power Automate to Update Contact Information

 We've all been there- you have a large organization who has out-of-date contact information. What do you do? You could go around to each department and ask them nicely to update their information, or send out an org-wide email prompting people to do so. However, this is tedious and oftentimes a pointless task. By the time you update one department, you're running to fix another. What if you could put the power back in the department's hands to do so? This is a struggle I faced recently as I was trying to find was I could conjure up some updated contact information for each department. As I did my research, I found that I was not alone in this endeavour as it seems that many IT professionals would love to make this process a little bit less painful. With this in mind, I introduce to you my latest flow! This flow will allow you to encourage users to update their contact information, without the overhead that comes with manual effort. In addition to this, this flow utilizes t...
Read more

Using Custom Connectors and Microsoft Graph API's to Manage Licenses in Power Automate - Part Two

Hello again! Didn't I promise you that I'd be back to wrap this up? Well, here I am to give you the second tidbit of information that you need to get this started. If you haven't already, take a look at my previous post where I go into depth about creating a custom connector in Power Automate to retrieve the latest sign-in and also gather the user's licenses. Now that we have the custom connector ready, we can now get into the meat n' potatoes of this series. In this post, I will show you the flow that makes this possible and how you can use the custom connector you have created to tie it all together! Hope you enjoy. Understanding the Logic Before we can begin creating the flow, we should first understand how the flow will work. I designed this to flow to be triggered manually, but you may want to schedule it or use another trigger. The trigger will depend on your organization's policies, so please adjust accordingly. Once triggered, the flow will use the Entra...
Read more

Using Custom Connectors and Microsoft Graph API's to Manage Licenses in Power Automate - Part One

Happy June folks! I come to you with another post, but this time I wanted to change it up and show you something else I have just finished working on. As a SysAdmin, one of the most common issues we run into is managing licenses. Working at a post-secondary institution makes this an even greater challenge, as you have both students, staff and faculty constantly coming as well as going. Managing to keep up with this constant change can introduce great administrative overhead which takes away time from important upkeep of other systems and initiatives. You may also notice this same issue in large corporations or in other government organizations. To help combat this, I wanted to create a flow that can do the following: Get the user and their licenses Determine their last sign-in and the date Conditional to determine if the user is past the "cutoff" date Remove the user from a group where the license is assigned The only problem with doing this is that Power Automate does not ha...
Read more