Showing posts with label service accounts. Show all posts
Showing posts with label service accounts. Show all posts

Thursday 27 July 2023

Setup access for the Power Platform API using a Service Principal (secret)

 Overview: I had a hard time setting up my tenant to use the Power Platform API, so here are my notes.

1. Register a new App that will be the Service Principal (SP)

Open https://portal.azure.com and login, and open your Azure Active Directory (mine is Radimaging Ltd) > Click "App Registrations" > "New registration" > add the registration as shown below:

Click the "All applications" tab and verify that the SP has been created.  Click the application to go into it.  Mine is called "Power Platform SP".

2. Give the SP permissions to use the Power Platform API's


Click "API permissions" > "Add a permission" > select the tab "API's my organization uses", search for the "Power Platform API" ensure it has the Application(Client Id) of "8578...".  

    Optional: If the API does not show up, use Power Shell to add it. 


Add permissions.  These are the permissions I added:
Click the "Grant Admin consent for ..." I did this but not sure if it is needed.

I also change the authentication setting on the SP to "Allow public client flows"

3. Use postman to check you are generating the Access token





Sunday 1 March 2020

Power Automate Notes

What is Power Automate?
Power Automate previously called Flow.  Power Automate contains "Flows".  Power Automate is workflow including RPA options, refered to a Power Automate Desktop (PAD).  Power Automate is a workflow engine that is based on Azure Logic Apps.  Powerful extendable workflow solution for low code automation.  Allows workflows to be easily automated with 3rd part systems e.g. SAP.

Used for:
  1. Personal Workflows e.g. I send an email to all people that have not update the DevOps Scrum board on a in the last day as a scrum master.
  2. Business Process e.g. Holiday request form.  If more than 10 days, need senior manager approval.  Generate RFP based on an event.  Historically, used K2 or Nintex or WCF workflows for business processes.
  3. Integration: e.g., move twitter posts into my warehouse for data-mining later.
A key concept is who shall the flow run as, a user or a service principal.  Setup a Service Principal in Power Automate » Benedikt's Power Platform Blog (benediktbergmann.eu)

Flows run against the owners account for calculating allowable usage (default), it is common practice to use a service account (normal AAD account with user and Pswd) to own specific flows.  A service account is a normal user account from AAD/Entra's perspective.  A dedicate account ensures that when a specific user leaves your business, the flow continues to run.
Img 1. Usage limits in Flows are counted against the flow owner.



Agree Power Automate Standards:
  1. Flow Names: start with a verb  format: Verb + What the Flow does + (trigger) e.g. "Get Tax Rates (Instant)".  I like to also prefix with the Company and Project, but feel free to have a standard to suit your business.  e.g. EY-USTax Get State Taxes (Instant) or EY-USTax Get All US State Tax Rates (Scheduled) or Get SalesForce Data.  Optional, for project specific workflows I also prefix witht he project name e.g. USTax-GetTaxRate. 
  2. Description: Short description to help readers understand what the flow does.
  3. Actions: Leave the Action desc and add info e.g. Compose: Tax Note.
  4. Variables: prefix with "v" e.g. vTaxTotal in camelCase.  e.g. vUserAge.
  5. Error handling & Logging: Catch errors and log into to App Insights via an Azure Function or Log using the built in Azure Log Analytics Action.  More logging means better traceability.
  6. Scope: Add scope actions for try catch logic.  Add multiple actions inside a "Scope" Action
  7. Terminate the flow with the Terminate Action if the flow has failed.
  8. Environment Variables: Great for logging as I go thru DTAP.  Also see.
  9. Connection Reference Name: Agree a format, does this flow run as  user or as a specified user.
  10. Loop Sparingly, use First() for performance.
  11. Owner: I like to use a service account in dev, it's a good idea to add tech owners as when it needs updating to support and easily find who they should talk too.  Understand who you are running the flow as, this ties to licencing but is critical.  You need to know you Actions and licencing limits on a project.
  12. Comments:  Im not a huge fan as the naming should make most flows make sense/self documented, but for tricky logic, comments are great.  Agree a standard.
  13. Retry policy: What happens if an action fails, do you want to try again?  
I borrowed a lot of the standards from "Matthew Devaney"
I found this document later - it is excellent. by Prasad Athalye - Best Practices for Power Automate(Microsoft Flow) Development

Licencing:
  1. Seeded licence is part of O365.  Use standard functionality such as standard connectors without needing to pay more for advance.  The advance/premium connectors are not part of the O365 licence.
  2. Per User licence -  Allows the  user $15 retail, can get discount with bulk and can use the advanced connectors & on-prem. gateway.  Many users need multiple workflows, normally personal workflows.
  3. Per User RPA licence - same as above but also has amazing RPA capabilities.
  4. Per Flow/Process - $100 per process per month, min 5 flows per month licences.  Anyone can use as part of the process.  Use for few people but process does a lot of workflows.  Can add a process one at a time after the first 5.
Licencing MS page
Power Automate has some licence add-ons available: AI builder and an unattended RPA add-on.
"Power Apps licenses will continue to include Power Automate capabilities", I don't know what is included but I assume it means any connector I can use in Power Apps, assuming I'm in Power Apps I can make Flows for.

Build workflows:
  • Can get a dedicated IDE tool for Power Apps or use the browser (which i always use).
  • There are over 350 connectors (in both standard and premium) and you can always use a custom connector to any OpenAPI (Swagger) endpoint.
  • Templates have some examples and often help as a starting point to make your own custom Flows in Power Automate.
  • Easy clear tracing so you  can see what part of the workflow is working and where you fail, and you can drive into the issue.  Super easy to use.
  • Example of an Instant Cloud flow triggered by a canvas Power App...

Query a Dataverse table in a Flow using OData

ParseJSON is fantastic for converting Open API/OData/JSON into an object

Extending - break out for programmatic control, I use C# Functions from my Flows and call them via HTTP triggers.
Retrieving  a row from the Dataverse custom "Subject" table.

Robotic Process Automation (RPA):
  • Also known as UI Flows within Power Automate.  Microsoft have purchase and integrated Softomotive for UI flows to add WinAutomation.
  • Attend (user logged in) and unattended version (complete tasks without manual intervention)
  • Can have multiple instances
  • API is generally better than using RPA as it is versioned and generally not changeable, whereas using a website, they website can be changed causing the RPA flow to fail.  Useful for instance when the RESP API is incomplete.
  • Recording tool for creating UI flows - Web use Selenium to record.
  • 3 Types: 1) Windows /Desktop/Screen reader and 2) web/website (Selenium) and 3) WinAutomation (covers both Windows and Web, easy to use but not as full featured yet).
  • WinAutomation has a drag and drop IDE, has error handling.
  • UI flows are well priced.  Also get AI builder credits with UI flow licences.
  • "Power Automate Per user plan with attended RPA to use UI flows and WinAutomation" Microsoft.
AI Builder:
Cognitive builder e.g recognize forms and extract data. E.g. receive invoices and add to accounting SaaS software.

Other: Zapier is a good tool for end user automation.  Easier than Power Automate but not as structured.  I'd use Zapier to automate in small businesses without O365 or flow licencing and allow end users to do it themselves.

Problem Solving:

Problem:  Another developer created a Flow I need to use from a Canvas page inside a model app.  The Flow is showing up when i say add but i get the error "Unable to add flow"
Initial Hypothesis: The flow is owned by another developer having ownership and the connection is done thru their account, take ownership and change the Connection (Dataverse connection in my case)
ResolutionTo use an existing flow, you need: 1) flow in same solution as the canvas app, 2) Ownership and the connection string needs to be switched to the new developer

Problem: Migrating solutions between environments, all the workflows fail when they use the Dataverse connector with 403 errors. Tracing the flows, I can see the error  "Flow client error returned with status code 'BadRequest' and details {error: code: 'XrmApplyUserFailed... UserNotinActiveDirector ... does not exist in user tenantId"
Problem: Using the service Principal account needs to be registered in the new Dataverse environment.
The connector issue was fixed, we had to recreate the connection from scratch making sure it was set up with a/the service principal. Then we added the registered app into the environment as an application. user.


Monday 15 November 2010

Changing service account passwords - The Service is unavailable

Problem: Browsers return the following error "Service Unavailable  Http Error 503.  The Service is unavailable." on all SharePoint websites including central admin.
Initial Hypothesis: I changed my password yesterday causing the app polls to fail when logging in.  The domain account used on my development machine required a password change.  Starting the machine causes all the IIS web sites to display the error message "Service Unavailable".  I run various services and application polls using my domain account.  The services can no longer log on.  Application pool cannot be started after the reboot/iisreset.
Resolution:  Change the log on details for the application pools used by IIS that run using the domain account that's password was reset.  Also start the Windows services that run using the windows domain account.

Ensure the SharePoint services running

Friday 12 November 2010

Installing SharePoint using a dedicated Installation account

Problem: Best practice is to install SharePoint servers using a dedicated install account.  This account is not the farm account.  Once the installation is complete, the installation account should be disabled.  You need to install in the role of the admin account to install correctly. 

Note:  If your install and farm account are the same as is often the case, this post does not apply to you.

Initial Hypothesis:  It is only worth following this post if you are using at least 5 or more accounts for your farm install.  The idea is that the installation account is disabled after installation.

Resolution:  The farm account needs the 2 SQL Server security roles namely: dbcreator and securityadmin.  The farm account still needs local admin permission rights on each Web Front End (WFE) server.  The Installation account does not need any SQL Server permissions.

Using the codeplex AutoSPinstaller.  Launch the installer using a cmd prompt using the runs cmd to run in the farm domain admin priviledge.
cmd> runas /user:demo\farm_admin %windir%\system32\cmd.exe
cmd> D:\SP2010\Script>Launch.bat


You can also do the runas shotcut to change the account installing SharePoint.
Update 6 Dec 2010 - Hold down the shift key and right click the cmd prompt program menu, you are given the "run as .." menu option.

Update: 22 June 2011 - the current version of AutoSPInstaller is 2.5, additionallly the codeplex project is called AutoSPIntaller not SPAutoInstaller as previously named.

AutoSPInstaller - Step-by-step guide: http://blog.lekman.com/2010/11/automated-sharepoint-2010-installations.html

Wednesday 11 August 2010

Number of Accounts needed for SP2010 & Managed service accounts

Problem: How many accounts are required for SharePoint 2010?
Hypothesis: In MOSS I used 7 accounts for farm installs using my default slip-steamed medium/large farm install.  It really depended on what you needed to run.  You can use service accounts to run services in SP2010.
Resolution: SP2010 introduces managed service accounts, that are used for running SharePoint services.  You don't need to know password and it changes the account passwords per your SharePoint policy so a better option in my opinion so I have used them on my 2 installs.  Also pretty nice to only require the 3 accounts for install as shown below:
http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/a740e3ee-6f2d-473e-a63b-d97e52513754
http://technet.microsoft.com/en-us/library/ee662513(office.14).aspx

Summary:
Need AD accounts
  1. Administrator account (Admin on local SP boxes, needs domain user account permissions, pref db owner
  2. Farm service account/database access account (needs domain user account permissions)
  3. Microsoft SharePoint Foundation 2010 search service account (needs domain user account permissions)

Thursday 1 July 2010

Installing Sharepoint 2010 options & Basic SP2010 manual installation tips

You have 4 options for installing SharePoint farms:
  1. Manually sun the setup and follow the installation wizard (this is discussed below);
  2. Deploy SharePoint 2010 via a slipstream install, this was my prefered method for MOSS.  I ran the install from a batch file that got it's configuration from an xml file;
  3. PSConfig installation (sic); or
  4. Use PowerShell to Install SharePoint. and technet scripted deployment
 Summary: For environments such as live the PowerShell/Slipstreamed options are best as they allow for recreation and input is always identical.  Manual install is fine for development servers however their is no advantage except for a lower learning curve for the IT admin.
Post below is a Manual Installation:
SP2010 install video
Install the pre-requisites
  • Prerequisits will install roles and software you need internet access on the server to fetch the prerequisits software (this can be put on the server to stop the machine going to the Internet).
  • Preferably have seperate instance of SQL 2008 R2 but for dev/demo machines. If 1 machine rather setup SQL devleoper or a instance (I dislike using SQL express).
Setup / SP 2010 install tips
  • Install "Server farm" option not standalone
  • "Complete" installs all component prefered option
  • Connect to a new farm
  • Database server name us name rather than IP (incase it changes)
  • DB account (must already exist in AD)
  • Passphrase used to connect new servers to this server farm (remeber/keep it)
  • Kerbros - if your network supports it but use NTLM if you aren't sure.
  • Wizard - follow screens, services can be heavy so add them when you need them, however for demo I select all services and create a new site collection - a good options is to use the Team Site Template.
  • Need 3 accounts for min Best practices: 1) Managed Service account (domain user account) that SQL Server runs in, 2) Managed Service Account (domain user account) all services will be installed on this account (MS suggests using a seperate managed account for each service) on small farm s/dev I use 1 account,  and 3) Farm install account (domain account) this needs to be a local admin on each SP2010 server and have creator & dbsecurity accouts on SQL.
  • 5 Accounts is a better option excluding the SQL services account namely:
  1. SP-Install - domain account with admin local rights on each WFE also need SQL dbcreator and securityadmin roles (used to login and install binaries, use this account for add new servers to the farm),
  2. SP-Farm - domain account no permissions, will be the account to run timer job and other key roles,
  3. SP-Web-App-Pool - Content Web app account - Domain account only,
  4. SP-Services - Install all services to use the same domain account, this can be seperate for each services but for easy of setup and mainentance use 1 account.  Exception is the User Profiles service, setup seperately using Spence Harbors post as the user domain account needs unique security, and
  5. SP-Crawl - Used to crawl SP content.
Additional Info on accounts:
  1. SQL Server needs to run as a windows service, you need an account, I would use a managed account in AD with no permissions called SP2010-SQLService.
  2. Farm Installation account, you need to create a domain user account in AD, give the account local admin access to each SP2010 machine.  Call it SP2010-Admin.
  3. SP2010 Service account/s, you need to create a managed service account with zero permissions in AD.  You can use 1 account or create a seperate account for each service (MS Best Practice).  I call my 1 account SP2010-Services. 
Use slipstreaming for SharePoint it's faster and consistant.
Use:
  1. Windows 2008 R2 x64
  2. SQL 2008 x64
  3. On HyperV/VMWare except the db which should be a seperate physical machine/SAN
Update 08 November 2010:  Notes on deploying a 3 server farm consisting of 2 WFE's that are NLB using Windows NLB.  Installation done using AutoSPInstaller. 
Installation Notes for a 3 server NLB SharePoint 2010 farm

Update 10 November 2010: SharePoint install account - Todd Klindt.
Update 11 May 2011: SharePoint 2010 database management article