One of the hot features that OneLogin offers is an HRIS-driven workflow that onboards employees from the HRIS solution into OneLogin and includes provisioning into Active Directory from OneLogin. A common ask for an export-mode Active Directory instance is to perform additional tasks after the user has been created. One standard request is to immediately add the new user to an AD security group necessary for their job function, much like we immediately add to OneLogin Roles. These extra steps are too unique to a customer’s environment to be easily addressed in the OneLogin provisioning engine or Active Directory Connector software, but they can often be accomplished through PowerShell commandlets. PowerShell can access the user object in Active Directory easily enough, the only pieces missing - the answers to the question “which user and what are their user details?” - can be answered through the OneLogin API interface. This article describes the events and API calls necessary to find out *which user *and what are their details and provide you with some sample Windows commands to feed your creative process. The script this article builds is written so you can use the Windows scheduler to run the script in a task once a day to update accounts newly created in your AD by OneLogin or as you see fit. I will attempt to spice up this otherwise dry topic of marrying PowerShell and OneLogin API with a few memes or other relevant social cues.
Active Directory Added to their Story
“A user was added to Active Directory” is so boring! The event is much more exciting than that statement conveys – we are automatically provisioning new accounts to AD for you! That’s a big story already! So let’s think of this event in terms of an update in Social media. You need notifications about the story.
Fortunately, there are events in OneLogin to help you read the story. You could read the article in our knowledge base about Reporting and Monitoring but it barely scratches the surface. The Developers site article Event Resource and Types is a better resource on what is told in the story. Note: The events list is a growing list. It expands as we expand our functionality. You may want to regularly review the Developers site. Event Resource and Types contains the one you are interested in:
Event #80: User provisioned in directory This event is recorded in OneLogin after the user has been successfully created in the directory. This is what you want to look for, but if you fire that off now it will show the matching event potentially going back years, so you need to put a limit by specifying when you want it to look.
Not that any of these dates would be valid… Let us begin by looking at the API endpoint that you will call. The Get Events API endpoint specifies a query string that limits the results returned. You can use three options of the query_string to limit our results to just the appropriate events:
- Event_type_id
- Since
- Until
- 2021-02-25T00:35:46.697Z
- Four digit year
- Hyphen two-digit month
- Hyphen two-digit day of the month
- "T" (capital t)
- Two-digit hour in UTC
- Colon two-digit minutes
- Colon two-digit seconds
- Period three-digit microseconds
- Z (for UTC)
No Doctor needed! PowerShell makes this *somewhat* easy to calculate and specify the format exactly. You use the *Hours* parameter to instruct PowerShell to subtract however many hours we need subtracted from the time this runs and then convert the resulting calculated time to the exact format you need using this line: $start = [DateTime]::Now.AddHours(-$Hours).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")And just like that, we turned back time.
If you wish to log the time the command runs to the screen or to a logfile, populate additional variables too.
$now = [DateTime]::Now.ToString("yyyy-MM-ddTHH:mm:ss.fffz")
$utcnow = [DateTime]::Now.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
$start = [DateTime]::Now.AddHours(-$Hours).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
```bash
# PowerShell Sends Friend Request
The most daunting task is getting PowerShell and the OneLogin API endpoints on speaking terms.
<img src="/assets/img/og/powershell-friend-request.png" alt="PowerShell sent you a friend request">
You will need Read Users API credentials to perform this operation, which is the lowest permission credential that can perform the tasks necessary.
<img src="/assets/img/og/new-api-credential.png" alt="Create new API credential">
These credentials can be saved as variables in the script or passed in via command line options during execution. They will be used to [obtain an Access Token](https://developers.onelogin.com/api-docs/1/getting-started/working-with-api-credentials) from the API endpoint for authentication so you can call the other APIs to obtain events and user information.
The script example will have you define these in a *param* section, which allows you to actually store blank variables in the script (if you prefer for security's sake) and provide the specific variables necessary at runtime via the command line options. (Note: Replace <subdomain> with your OneLogin subdomain.)
```javascript
param (
# Set debug level
[int]$debug = "3",
# Set Hours Between run
[int]$Hours = "99",
# EventIds: 80 = User provisioned to directory
[string]$EventId = "80",
# APIhost
$APIhost ="<subdomain>.onelogin.com",
# Creds
$APIclientid = "therespineappleshrimplemonshrimpcoconutshrimppeppershrimpshrimpsoup",
$APIclientsecret = "shrimpstewshrimpsaladshrimpandpotatoesshrimpburgershrimpsandwich"
)A few other things in the param section that are optional but nicely handled using this mechanism:
- Debug level
- Hours
- EventID
- API host
