We are planning connect Microsoft Identity manager with Ceridian Dayforce HRIS tool. We want to use MIM then to sync with our Active Directory to get a list of all the users, roles and other details regularly.
I found Dayforce API documentation online here https://usconfigr58.dayforcehcm.com/api/ddn/swagger/
Can I use PowerShell to query and parse rest API so that I can get the information from Dayforce to our Active Directory?
Absolutely you could, you would write Powershell scripts to query the APIs using the the endpoints stated in Swagger to query the information you want, then use the resulting objects to update whatever you wanted to in AD. In Powershell the easiest way to do it would be using invoke-restmethod then use the appropriate Powershell AD commands to update the adusers mainly set-aduser
However, if you are using MIM, then you wouldn't be using Powershell to do it, you would use mim's workflow and rest connector functionality. Otherwise what's the point of using MiM if you are going to basically write your own sync?
Related
I would like to be able to call Powershell scripts using a REST API. (Please note that I am describing the _opposite_ of calling a REST API from Powershell.) Are there any prebuilt API gateways that support this use case? I've looked at Ocelot, but it currently only acts as a gateway to other REST APIs. Ideally I would simply design my Powershell script functions to follow a defined interface pattern, put the files into a defined directory, and the API gateway would either immediately make those functions available as REST API calls or with minimal configuration.
EDIT: To clarify, I am looking for something self hosted, not cloud based. I haven't found anything yet that is exactly what I need, I may create something myself.
You can try AWS Lambda and API gateway integration.
Here is an example: https://aws.amazon.com/blogs/developer/creating-a-powershell-rest-api/
Amazon offer 12 month free tier plan for this.
A couple of options. If you are on Azure you could expose your Powershell Scripts through Azure Automation :
https://learn.microsoft.com/en-us/azure/automation/automation-webhooks
That'd be a lightweight way of having your scripts enabled through a HTTP POST scenario.
You could also combine or mix it with adding API Management in front to support various scenarios (adding GET/PUT/DELETE support e.g.) or even automate or proxy more things. API Management could of course also be automated.
https://azure.microsoft.com/en-us/services/api-management/
You could also create a folder structure with modules & sub-functions and create a full REST API by using Azure Functions with PowerShell:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-powershell
The latter would also be able to execute in containers & in the supported Azure Function
runtimes.
I don't have access to the Sharepoint server and can't use remoting, and therefore don't have access to Microsoft.Sharepoint.Powershell which contains the SharePoint commandlets.
I also can't use 3rd party libraries which means I only have access to built in Powershell commandlets, or any .NET class.
How can I access a Sharepoint list using only built in Powershell commandlets or .NET classes?
Well if you are using SharePoint 2010 and you don't have access to the server itself and must interact with it remotely you have essentially three options:
https://msdn.microsoft.com/en-us/library/office/hh313619(v=office.14).aspx
You can use:
Client Side Object Model - this gives you a structured SharePoint classes approach to enumerating, viewing and interacting with SharePoint site artifacts
SOAP Web Services - Exactly what it sounds like...a set of XML SOAP end points that let you interact with a SharePoint site
REST Web Services - A set of endpoints that follow REST principles
FWIW, the CSOM libraries use the REST endpoints under the covers.
In given scenario you can make use of PnP Powershell which runs on client side. You just need to install small setup to enable PnP command on machine from where you will run Powershell.
Then you can use command Connect-PnPOnline to connect to desired sharepoint site.
PS:> Connect-PnPOnline -Url https://contoso.sharepoint.com
Once you provide valid credentials you will have access to PnP Context for that particular site.
Then using Get-PnPList command you can fetch list data
PS:> Get-PnPList -Identity Lists/Announcements
For more information on PnP-Powershell please refer Documentation : https://github.com/SharePoint/PnP-PowerShell/tree/master/Documentation
Hope it will help you..:)
Cheers,
Swapnil Lad
To authenticate to Azure and use the Azure Resource Manager cmdlets, I currently use the methods outlined here, namely using an Azure Active Directory account, encrypting the password, storing the encrypted string in a text file, and reading that into a credential object when using it in the script.
But I get the sense that maybe I should be using management certificates instead.
There is a documented method to use a publish settings file, but apparently that doesn't work for AzureRm cmdlets, only older cmdlets.
I have seen examples for using Powershell to create an application_id and service principal, and for authenticating a C# app, for instance, but I can't seem to find anything showing how to use management certificates for authentication in a powershell script, to use AzureRm cmdlets.
Maybe the secure string password storage method is the right one. But I don't have a good sense for that.
What do you use?
The best way to do it? It depends what is important to you. Ease of use, security, scripting?
Microsoft Azure Tooling (Visual Studio, Azure Powershell and CLI) lately moved to a more fine-granular, role-based access control approach based on Azure AD. This is currently a pretty good way to do it, since Management certificates allow owners to manage at subscription level and have proven to be rather difficult in environments like Azure Automation.
Refs
https://azure.microsoft.com/de-de/blog/azure-automation-authenticating-to-azure-using-azure-active-directory/
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-certs-create/#what-are-management-certificates
http://blogs.msdn.com/b/cloud_solution_architect/archive/2015/03/17/rbac-and-the-azure-resource-manager.aspx
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/
https://azure.microsoft.com/en-us/documentation/articles/resource-group-rbac/#concepts
You should have a look to Service Principal
https://azure.microsoft.com/en-us/documentation/articles/resource-group-create-service-principal-portal/
https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal/
I've been playing with RBAC in Azure AD, in particular custom application roles.
It all works well, but is a bit manual, i.e. downloading, editing and uploading the manifest and then assigning each user/group to one of these roles via the management portal.
Is there a way to do that via powershell or even code, say the Graph API?
If not, I presume it's a planned feature, so does anyone know a the likely ETA?
Right now this feature is not available via the AAD PowerShell Module, but it will find its way there eventually. We are working on releasing a new PowerShell module soon that sits atop ADAL which means we will soon be making cmdlets that directly target the Graph API.
For now, you can make direct queries using the Graph Client Library or pure REST calls. I believe an example of setting Application Roles should be available in this sample:
https://github.com/Azure-Samples/active-directory-dotnet-graphapi-console
I hope this helps!
Shawn Tabrizi
Before you can use Windows PowerShell to manage RBAC, you must have the following:
Windows PowerShell, Version 3.0 or 4.0. To find the version of Windows PowerShell, type:$PSVersionTable and verify that the value of PSVersion is 3.0 or 4.0.
Azure PowerShell version 0.8.8 or later.
To get detailed help for any cmdlet that you see in this tutorial, use the Get-Help cmdlet.
Get-Help <cmdlet-name> -Detailed
For example, to get help for the Add-AzureAccount cmdlet, type:
Get-Help Add-AzureAccount -Detailed
Since RBAC only works with Azure Resource Manager, the first thing to do is to switch to Azure Resource Manager mode, type:
PS C:\> Switch-AzureMode -Name AzureResourceManager
Here is the complete tutorial on
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-powershell/
I have been trying to install the Azure Active Directory Module for Windows for Powershell. So far I have not been able to find a combination of the Sign-In Assistant and Powershell module versions that allows me to create a connection in a Powershell session. My measure for success has been to run the Connect-MsolService cmdlet to create such a connection. I have tried it both from the command line and in a script. The (few) forum and blogs posts that reference this functionality have been very contradictory.
I am using the same credentials that I use to log into manage.windowsazure.com.
As to the specifics I have the following configuration:
Windows Server 2012R2
Powershell version 4.0 ($PSVersionTable.PSVersion)
Microsoft Online Services Sign-In Assistant version 7.250.4556.0
Windows Azure Active Directory Module for Windows Azure version
1.0.8362. The version number is based on the command (get-item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\Microsoft.Online.Administration.Automation.PSModule.dll).VersionInfo.FileVersion
My questions are as follows:
What versions work on Windows Server 2012R2?
Is there a specific .Net version that I might be missing?
Am I looking at it wrong? For example is the cmdlet
Connect-MsolService not the metric to be using? Is there another way
that I might verify that I have a connection?
My understanding is that the Powershell cmdlets, as well as all the other methods for managing Azure, are based on the REST API's. Would that be a better way to go? Of course I would not be able to dynamically enter commands, but I would be able to validate credentials etc.
Are you trying to authenicate with an MSA account? Try connecting with a Global Admin AAD account (eg. globaladminuser#tenant.onmicrosoft.com).