Asiakkaan ohjeet löytyvät täältä.

Kyseisen ohjeen vaiheet on tehtävä, ennen kuin Microsoft Graph API -liitin voidaan määrittää kokonaan.

Tässä luvussa kuvataan Entra-liittimen määritysohjeet, joiden avulla se voi muodostaa yhteyden asiakkaan Entra ID:hen.

Provisioinnin määrittämiseksi tarvitset pääsyn Efecte Platform -määrityskonsoliin.

Edellytykset:
Asenna Microsoftiin liittyvät sertifikaatit: https://docs.efecte.com/internal-configuration-instructions/install-ad-certificates-for-efecte-provisioning-engine

1. Avaa Efecten ylläpitoalue (hammasratassymboli).
2. Avaa liittimien näkymä.
3. Valitse New connector

4. Valitse Data Source -tyypiksi Microsoft Entra

5. Anna liittimelle nimi ja lisää Entra-yhteysasetukset:

• Connector name – anna liittimelle helppokäyttöinen nimi (nimen voi muuttaa myöhemmin)
• Application (client) ID – asiakassovelluksen GUID-objekti Microsoft Entra -konsolissa
• Directory (tenant) ID – Microsoft Entra -vuokraajan GUID-objekti
• Login URL – Microsoft Entra -vuokraajan mukautettu verkkotunnus
• Graph API URL – asetettu yleensä arvoon 'https://graph.microsoft.com', muokattavissa erityistarpeisiin

6. Täytä todennusmenetelmä

• Secret – täytä secret key -arvo. Secret key -arvo kopioidaan Microsoft Entra -portaalista
• Certificate – lataa Microsoft Entra -sertifikaattikirjautumisessa käytettävän avaimen julkisen nimen alias
  
  
   

7. Täytä WebAPI-käyttäjän tiedot

• WebAPI user – valitse oikea WebAPI-käyttäjä, jota käytetään kirjoitettaessa dataa asiakkaan AD:sta asiakkaan Efecte-ratkaisuun
• WebAPI password – WebAPI-käyttäjän salasana

8. Tallenna liittimen tiedot

• Paina test connection tarkistaaksesi, että yhteystiedot on määritetty oikein
  
  

9. Asiakkaan Efecte-ratkaisu voi nyt muodostaa yhteyden asiakkaan Entra ID:hen

• Seuraava vaihe on määrittää ajastettu tehtävä datan lukemista varten tai tapahtumatehtävä datan kirjoittamista varten.

Entra-liitintä käytetään käyttäjä- ja ryhmätietojen lukemiseen asiakkaan Entra-hakemistosta, ja se määritetään Efecte Service Management -alustalla luomalla ajastettuun tehtävään perustuva provisiointitehtävä.

Miten luoda uusi tehtävä ajastettua provisiointia varten

Ajastettuun tehtävään perustuvan provisiointitehtävän määrittämiseksi tarvitset pääsyn Efecte Platform -määrityskonsoliin.

Huomaa! Jos liitintä ei ole vielä luotu, sinun on ensin luotava ”new connector”, minkä jälkeen voit luoda uusia tehtäviä.

1. Avaa Efecte Platform -määritysnäkymä (hammasratassymboli).
2. Avaa liittimien näkymä.
3. Valitse liitin, jolle ajastettu tehtävä määritetään
4. Valitse new task oikean liittimen alta

5. Määritä tehtävän ajastus (ajetaanko ajastettu tehtävä säännöllisesti ja miten). Valitse ajastusväli sen mukaan, kuinka paljon dataa asiakkaan Efecte-ratkaisuun luetaan.

Suositeltu ajastusväli riippuu siitä, kuinka paljon dataa asiakkaan hakemistosta luetaan Efecte-ratkaisuun ja onko tuonti osittainen vai täysi lataus.

Esimerkki ajastuksesta ryhmien ja käyttäjätilien lukemiseen.

5. Täytä tehtävän tiedot

• Anna ajastetulle tehtävälle yksilöllinen nimi
• Task usage ilmaisee, käytetäänkö tehtävää datan lukemiseen, kirjoittamiseen vai todennukseen. Huomaa, että jos tapahtumatyyppiä muutetaan myöhemmin, se voi rikkoa työnkulut.
• Mappings type riippuu siitä, minkä tyyppistä tietoa hakemistosta luetaan
  • Identity and access rights – käytetään, kun hakemistosta luetaan käyttäjätili- ja ryhmätietoja
  • Single (identity only) – käytetään, kun hakemistosta luetaan vain käyttäjätilitietoja
  • Single (access right only) – käytetään, kun hakemistosta luetaan vain ryhmätietoja
  • Generic (one template) – käytetään, kun hakemistosta luetaan yleistä tietoa, yleensä muuta kuin käyttäjiä/ryhmiä

Täytä suodatustiedot

• Fetch data
  • Full – kaikki tieto luetaan määritetyn suodatuksen mukaisesti
  • Incremental – vain muuttunut tieto toimitetaan Efecte-ratkaisuun
• Import users parameter – lisäsuodatin Graph API -kyselyyn, jota sovelletaan käyttäjiä poimittaessa.
• Import groups parameter – lisäsuodatin Graph API -kyselyyn, jota sovelletaan ryhmiä poimittaessa. Lisätietoja suodattimista luvussa Graph API filters & testing
• Microsoft Entra query – Graph API-kyselysuodatin, jota sovelletaan generic-objekteja poimittaessa. Lisätietoja suodattimista luvussa Graph API filters & testing
• Query headers – mukautetut otsikkotiedot, jotka lisätään lopulliseen kyselyyn käyttäjien / ryhmien / muun datan poiminnan aikana.
  EPE lisää nämä otsikkotiedot automaattisesti, joten niitä ei tarvitse lisätä erikseen:
  “Content-Type”, “application/json”
"Authorization", “Bearer token”
"Accept", “application/json”
  
  Lisätietoja suodattimista luvussa Graph API import and filters

• Excluded Users – käyttäjät, jotka jätetään ESM:ään tuonnin ulkopuolelle. Poissuljettavien käyttäjien Object ID:t (rivinvaihdoin eroteltuna)
• Excluded Groups – ryhmät, jotka jätetään ESM:ään tuonnin ulkopuolelle. Poissuljettavien ryhmien Object ID:t (rivinvaihdoin eroteltuna)
• Import users based on group-memberships – mahdollistaa ryhmäluetteloiden määrittämisen, joiden perusteella käyttäjät sisällytetään tai jätetään pois lopullisesta tulosjoukosta

Täytä failure-tiedot

Valinnaiset asetukset virheenkäsittelyä varten; jos ajastettu tehtävä epäonnistuu, se voi luoda Efecte ESM:ään tietokortin, joka näyttää virheen. Jos failure-asetukset on määritetty, ylläpitäjän ei tarvitse manuaalisesti tarkistaa ajastettujen tehtävien tilaa.

• Failure template – valitse tietokortin malli, joka luodaan, jos provisioinnin aikana tapahtuu virheitä (yhteys tietolähteisiin, aikakatkaisut jne.)
• Failure folder – valitse kansio, johon failure-tietokortti tallennetaan.
• Failure attribute – valitse attribuutti, johon virhetiedot tallennetaan failure-mallissa. Valitse text-tyypin attribuutti.
   

Esimerkki IGA-ylläpitotehtävästä, joka voi sisältää myös ohjeita ongelmien ratkaisemiseksi,

6. Täytä identity mappings

Käyttäjät tuodaan IGA Account -malliin, ja on pakollista määrittää Target folder, datasourceid sekä yksilölliset arvot, joita käytetään käyttäjien tunnistamiseen asiakkaan Entra-hakemiston ja Efecte-ratkaisun välillä.

• Target template – valitse malli attribuuttimappausten määrittämiseksi
• Target folder – valitse kansio luettelosta. Luettelo rajataan vastaamaan valittua mallia.

• Data Source Type mapping – valinnainen. Jos se on asetettu, se kirjoittaa liittimen tyypin kyseiseen attribuuttiin.
• Task Id mapping – tehtävän id-numero kirjoitetaan tähän attribuuttiin. Tämän on oltava ei-yksilöllinen attribuutti.
• Set value to datacard fo object deleted from source system – tämä toiminto otetaan käyttöön valitsemalla valintaruutu. Kun objekti, joka on aiemmin luettu kolmannen osapuolen järjestelmästä ratkaisuun, poistetaan kolmannen osapuolen järjestelmästä (eli tämän tehtävän kysely ei enää palauta sitä), ajastettu tehtävä huomaa poiston ja merkitsee kyseisen tietokortin valitun attribuutin halutulla arvolla. Tätä voidaan käyttää esimerkiksi Status-attribuutin asettamiseen arvoon Deleted (kuten alla olevassa esimerkkikuvakaappauksessa näkyy). Tämä toiminto toimii vain Full-tyyppisille tehtäville, ei Incremental-tehtäville.

• Attribute mappings
  1. External attribute – mikä hakemiston attribuutti mapataan Efecteen
  2. Local attribute – mihin Efecte-hakemiston attribuuttiin attribuutti mapataan.

7. Lisäattribuuttien lisääminen

On mahdollista määrittää lisäattribuutteja, jotka luetaan Entra ID:n käyttäjätileiltä, valitsemalla New attribute

8. Täytä Access Rights Mappings

Ryhmät luetaan IGA Entitlement -malliin, ja on pakollista määrittää target folder, datasourceid sekä yksilölliset arvot, joita käytetään käyttäjien tunnistamiseen asiakkaan Entra-hakemiston ja Efecte-ratkaisun välillä.

• Target template – valitse malli attribuuttimappausten määrittämiseksi
• Target folder – valitse kansio luettelosta. Luettelo rajataan vastaamaan valittua mallia.

• Data Source Type mapping – valinnainen. Jos se on asetettu, se kirjoittaa liittimen tyypin kyseiseen attribuuttiin.
• Task Id mapping – tehtävän id-numero kirjoitetaan tähän attribuuttiin. Tämän on oltava ei-yksilöllinen attribuutti.
• Set value to datacard fo object deleted from source system – tämä toiminto otetaan käyttöön valitsemalla valintaruutu. Kun objekti, joka on aiemmin luettu kolmannen osapuolen järjestelmästä ratkaisuun, poistetaan kolmannen osapuolen järjestelmästä (eli tämän tehtävän kysely ei enää palauta sitä), ajastettu tehtävä huomaa poiston ja merkitsee kyseisen tietokortin valitun attribuutin halutulla arvolla. Tätä voidaan käyttää esimerkiksi Status-attribuutin asettamiseen arvoon Deleted (kuten alla olevassa esimerkkikuvakaappauksessa näkyy). Tämä toiminto toimii vain Full-tyyppisille tehtäville, ei Incremental-tehtäville.

• Attribute mappings
  1. External attribute – mikä hakemiston attribuutti mapataan Efecteen
  2. Local attribute – mihin Efecte-hakemiston attribuuttiin attribuutti mapataan.
• On mahdollista määrittää lisäattribuutteja, jotka luetaan hakemiston käyttäjätileiltä, valitsemalla New attribute

9. Sisäkkäisten ryhmien mappaus
Jos haluat hakea sisäkkäisten ryhmien tietoja (ryhmän jäsenyys toisessa ryhmässä) Entra ID:stä, voit tehdä sen memberOf -attribuutilla Access Rights Mappings -osiossa.

Oikea puoli on Entra ID:stä, ja vasen puoli on M42 Pro/IGA-ratkaisusta:

10. Generic-mallin mappaukset

Generic-dataa voidaan lukea mihin tahansa malliin, jonka käyttäjä haluaa, ja on pakollista määrittää kohdekansio, datasourceid sekä yksilölliset arvot, joita käytetään datan tunnistamiseen asiakkaan Entra-hakemiston ja Efecte-ratkaisun välillä.

• Target template – valitse malli attribuuttimappausten määrittämiseksi
• Target folder – valitse kansio luettelosta. Luettelo rajataan vastaamaan valittua mallia.

• Data Source Type mapping – valinnainen. Jos se on asetettu, se kirjoittaa liittimen tyypin kyseiseen attribuuttiin.
• Task Id mapping – tehtävän id-numero kirjoitetaan tähän attribuuttiin. Tämän on oltava ei-yksilöllinen attribuutti.
• Set value to datacard fo object deleted from source system – tämä toiminto otetaan käyttöön valitsemalla valintaruutu. Kun objekti, joka on aiemmin luettu kolmannen osapuolen järjestelmästä ratkaisuun, poistetaan kolmannen osapuolen järjestelmästä (eli tämän tehtävän kysely ei enää palauta sitä), ajastettu tehtävä huomaa poiston ja merkitsee kyseisen tietokortin valitun attribuutin halutulla arvolla. Tätä voidaan käyttää esimerkiksi Status-attribuutin asettamiseen arvoon Deleted (kuten alla olevassa esimerkkikuvakaappauksessa näkyy). Tämä toiminto toimii vain Full-tyyppisille tehtäville, ei Incremental-tehtäville.

• Attribute mappings
  1. External attribute – mikä hakemiston attribuutti mapataan Efecteen
  2. Local attribute – mihin Efecte-hakemiston attribuuttiin attribuutti mapataan.
• On mahdollista määrittää lisäattribuutteja, jotka luetaan hakemiston käyttäjätileiltä, valitsemalla New attribute

11. Tallenna tehtävä

Tallenna provisiointitehtävä Save-painikkeesta. Jos joitakin pakollisia attribuutteja puuttuu, save-painike näkyy harmaana, ja se näyttää, mitä asetuksista puuttuu.

Olet nyt määrittänyt ajastettuun tehtävään perustuvan liitintehtävän Entra ID -datan lukemista varten

• Voit nyt odottaa, että tehtävä käynnistyy ajastuksen mukaisesti, tai
• Run task manually – painiketta napsauttamalla tehtävä ajastetaan käynnistymään heti. Yleensä käytetään testiajoihin tai kun ei haluta muuttaa ajastusasetuksia, mutta halutaan ajaa tehtävä nyt.

Esimerkki manuaalisen tehtäväajon käynnistysviestistä:

Jos tehtävä suoritetaan manuaalisesti (run task) tai se ajetaan ajastuksen mukaisesti, tehtävän tilaa voi tarkastella kohdasta View history.

Tapahtumatehtävää käytetään, kun dataa kirjoitetaan asiakkaan Azureen / Entra ID:hen. Nämä Provisioning Enginen ominaisuudet tileille, ryhmille ja käyttöoikeuksille ovat saatavilla vain Matrix42 IGA -ratkaisulle, ja niiden käyttö vaatii IGA-lisenssin.

Kaikki Provisioning Engineen ja tapahtumapohjaiseen provisiointitehtävään liittyvä määritys tehdään Matrix42 Core-, Pro- ja IGA-alustalla.

1. Avaa Efecte Platform -määritysnäkymä (hammasratassymboli).
2. Avaa liittimien näkymä
3. Valitse liitin, joka käyttää tapahtumatehtävää
4. Valitse ”new task” oikean liittimen alta

4. Täytä tehtävän tiedot

• Task name – anna tehtävälle nimi, se näytetään liittimien näkymässä.
  • On hyvä käytäntö nimetä tehtävä siten, että nimi kuvaa sen tarkoitusta, esimerkiksi [Mallin nimi]:[Toiminto] IGA Service request:Verify user
• Task usage ilmaisee, käytetäänkö tehtävää datan lukemiseen vai kirjoittamiseen. Sen voi vaihtaa myöhemmin, mutta sitä ei suositella, jos tapahtumatehtävä on käytössä. Se rikkoo työnkulut.
• Mappings type riippuu siitä, minkä tyyppistä tietoa hakemistosta luetaan; identity mappings -valinnat näytetään tämän asetuksen perusteella.
  • Identity and access rights – käytetään, kun hakemistosta luetaan käyttäjätili- ja ryhmätietoja
  • Single (identity only) – käytetään, kun hakemistosta luetaan vain käyttäjätilitietoja
  • Single (access right only) – käytetään, kun hakemistosta luetaan vain ryhmätietoja
  • Generic (one template) – käytetään, kun hakemistosta luetaan yleistä tietoa, yleensä muuta dataa kuin käyttäjä- tai ryhmätietoja.

Varoitus task usage- tai mappings type -arvon muuttamisesta, kun tapahtumatehtävä on käytössä:

5. Täytä security information -tiedot

Näitä tietoja tarvitaan, jos työnkulun käyttäjän luontiprosessi on liitetty tehtävään.

• Password for first login – oletussalasana, joka on sama kaikille käyttäjille; satunnainen salasana luodaan työnkulussa, ja se on yleensä yksilöllinen.
  • Default password / kirjoita alla olevaan kenttään
    • Default password – kirjoita oletussalasana, joka on sama kaikille käyttäjille ja vastaa hakemiston salasanavaatimuksia. Huomaa, että merkkien määrä ei vastaa salasanan todellista pituutta
    • Tuotantoympäristössä ei suositella käyttämään samaa oletussalasanaa kaikille uusille tileille
  • Random password / luodaan työnkulussa
    • Generated password 

Täytä suodatustiedot

• Import users parameter – lisäsuodatin Graph API -kyselyyn, jota sovelletaan käyttäjiä poimittaessa.
• Import groups parameter – lisäsuodatin Graph API -kyselyyn, jota sovelletaan ryhmiä poimittaessa. Lisätietoja suodattimista luvussa Graph API filters & testing
• Microsoft Entra query – Graph API-kyselysuodatin, jota sovelletaan generic-objekteja poimittaessa. Lisätietoja suodattimista luvussa Graph API filters & testing
• Query headers – mukautetut otsikkotiedot, jotka lisätään lopulliseen kyselyyn käyttäjien / ryhmien poiminnan aikana.
  Lisätietoja suodattimista luvussa Graph API filters & testing
• Date Attribute formatter – käytetään päivämäärien muotoiluun, kun date-tyypin attribuuttia provisioidaan kohdejärjestelmään. Voit valita muodon luettelosta tai lisätä oman mukautetun muodon. Oikeanpuoleinen kenttä näyttää esimerkin muotoillusta päivämäärästä.
• DateTime Attribute formatter – käytetään päivämäärä- ja aika-arvojen muotoiluun, kun datetime-tyypin attribuuttia provisioidaan kohdejärjestelmään. Voit valita muodon luettelosta tai lisätä oman mukautetun muodon. Oikeanpuoleinen kenttä näyttää esimerkin muotoillusta päivämäärä- ja aika-arvosta.

6. Määritä identity mappings

• Target template – valitse malli attribuuttimappausten määrittämiseksi
• Target folder – valitse kansio luettelosta. Luettelo rajataan vastaamaan valittua mallia.
• Attribute mappings
  1. External attribute – mikä hakemiston/järjestelmän attribuutti mapataan
  2. Local attribute – mihin mallin attribuuttiin attribuutti mapataan
• Add new attribute – on mahdollista määrittää lisäattribuutteja, jotka luetaan Entra-hakemiston käyttäjätileiltä, valitsemalla New attribute -painike.

7. Määritä access right mappings

• Target template – valitse malli access rights -mappausten määrittämiseksi
• Target folder – valitse kansio luettelosta. Luettelo rajataan vastaamaan valittua mallia.
• Attribute mappings
  1. External attribute – mikä hakemiston/järjestelmän attribuutti mapataan
  2. Local attribute – mihin mallin attribuuttiin attribuutti mapataan
• Add new attribute – on mahdollista määrittää lisäattribuutteja, jotka luetaan Entra-hakemiston ryhmiltä, valitsemalla New attribute -painike.

8. Määritä generic-mappaukset

• Target template – valitse malli attribuuttimappausten määrittämiseksi
• Target folder – valitse kansio luettelosta. Luettelo rajataan vastaamaan valittua mallia.
• Attribute mappings
  1. External attribute – mikä hakemiston/järjestelmän attribuutti mapataan
  2. Local attribute – mihin mallin attribuuttiin attribuutti mapataan
• Add new attribute – on mahdollista määrittää lisäattribuutteja, jotka luetaan Azure-/Entra-hakemistosta, valitsemalla New attribute -painike.

8. Tallenna provisiointitehtävä ”save”-painikkeesta

Jos pakollisia tietoja puuttuu, tehtävää ei voi tallentaa, ja save-painike näyttää puuttuvat tiedot.

9. Seuraava vaihe on määrittää työnkulun Orchestration-solmu käyttämään tätä tapahtumapohjaista tehtävää. Platformin työnkulkumoottorista on mahdollista suorittaa provisiointitoimintoja asiakkaan hakemistopalveluihin. Tämä tarkoittaa, että mitä tahansa saatavilla olevaa orkestrointisolmun toimintoa voidaan ajaa missä tahansa vaiheessa työnkulkua.

Työnkulkuviittaukset näkyvät liittimen yleiskatsaussivulla:

Huomaa: Versiota 2025.2 vanhemmissa versioissa todennustehtäviä ei synkronoida Secure Accessiin (ESA), joten näissä ympäristöissä todennustehtävää ei tule luoda tämän ohjeen mukaisesti; määritä todennus sen sijaan suoraan Secure Access (ESA) -ylläpitoportaalissa. Noudata Efecte Secure Access -määritysohjeita vaaditun todennusmenetelmän mukaan.

Todennustehtävää tarvitaan, kun asiakkaan Entra ID:tä käytetään käyttäjien todentamiseen asiakkaan Efecte-ratkaisuihin.

Uuden todennustehtävän luomiseen on kaksi vaihtoehtoa. Ensimmäinen vaihtoehto on kopioida olemassa oleva provisiointitehtävä todennustehtäväksi, jos todennusmenetelmä käyttää samoja asetuksia. Toinen vaihtoehto on luoda uusi todennustehtävä.

Vaihtoehto 1: Luo uusi todennustehtävä provisiointitehtävästä

1. Avaa ylläpitoalue (hammasratassymboli)
2. Valitse Connectors-välilehti, kopioi haluttu tehtävä Clone-painikkeesta

3. Anna uudelle todennustehtävälle nimi ja vaihda task usage -arvoksi Authentication

4. Täytä pakolliset kentät ja tallenna tehtävä
 

Vaihtoehto 2: Luo uusi todennustehtävä

1. Avaa ylläpitoalue (hammasratassymboli)
2. Valitse Connectors-moduuli
3. Valitse Authentication-välilehti
4. Valitse liitin ja Create New Task

5. Anna todennustehtävälle nimi
6. Valitse task usage -arvoksi authentication
7. Määritä suodattimet käyttäjille
8. Määritä suodatin ryhmille

9. Valitse Auth protocol todennukselle – SAML2 tai OpenID

10. Valitse Authentication realm.

• Realm, jolle todennusmääritys luodaan ESA:ssa

11. Tallenna tehtävä ja aja ESA Sync

• Synkronointi täyttää määrityksen automaattisesti Efecte Secure Accessissa

Käyttäjien suodattaminen

Suodattimen nimi: Import Users Parameter
Tämä suodatin määritetään tuomaan käyttäjiä annettujen parametrien perusteella (kuten esimerkiksi $filter=startswith givenName, 'J'). Parametreja voi olla useita, ja niitä käytetään yhdessä.

Esimerkkejä

Seuraava esimerkki löytää käyttäjät, joiden sähköpostiosoite päättyy merkkijonoon ”@efecte.com”

Seuraava esimerkki löytää käyttäjät, joiden osasto alkaa sanalla ”IT-Service”

Seuraava esimerkki löytää käyttäjät, joiden näyttönimi alkaa sanalla ”TEST”

Seuraava esimerkki löytää käyttäjät, jotka eivät ole yrityksessä nimeltä Efecte

Seuraava esimerkki löytää käyttäjät, jotka eivät ole Active Directoryssa mutta ovat jäseninä Entra-vuokraajassa

Seuraava esimerkki löytää käyttäjän, jonka sähköpostiosoite on tuija.itasalmi@efecte.com

Tämä esimerkki löytää käyttäjät, joilla on 'standard'-todennustyyppi extension_824667ba11b6468baf6ac13ac3c62c81_AuthenticationType-laajennusattribuutissa ja joiden tilit on merkitty sisäisiksi tai ulkoisiksi extension_824667ba11b6468baf6ac13ac3c62c81_AccountType-laajennusattribuutissa

Seuraava esimerkki löytää käyttäjät, joilla on mail-attribuutti

Seuraava esimerkki löytää käyttäjät, jotka ovat käytössä

Ryhmien suodattaminen

Suodattimen nimi: Import Groups Parameter
Tämä suodatin määritetään tuomaan ryhmiä annettujen parametrien perusteella. Esimerkiksi: $filter=startswith groupName, ‘E’. Huomaa, että yksi suodatin voi käyttää useita parametreja samanaikaisesti.
 

Esimerkkejä

Seuraava esimerkki löytää ryhmät, jotka ovat security-ryhmiä

Seuraava esimerkki löytää ryhmät, joiden displayname alkaa sanalla ”Efecte”

Seuraava esimerkki löytää ryhmät, jotka on luotu ja synkronoitu Active Directorysta

Excluded Groups

Azure-pohjaisissa tehtävissä syötä poissuljettavien ryhmien Object ID:t (rivinvaihdoin eroteltuna).

Käyttäjien suodattaminen ryhmäjäsenyyden perusteella

Suodattimen nimi: Import Groups Parameter
Tämä suodatin määritetään tuomaan käyttäjiä ryhmäjäsenyyden perusteella. Azure-pohjaisissa tehtävissä syötä mukaan otettavien tai poissuljettavien ryhmäjäsenyyksien Object ID:t (rivinvaihdoin eroteltuna)

Suodatus yksittäisten käyttäjien perusteella

Suodattimen nimi: Excluded Users

Tällä suodattimella voidaan sulkea tiettyjä käyttäjiä pois tuonnista. Entralle käytä poissuljettavien ryhmien ObjectGUID-arvoja (rivinvaihdoin eroteltuna).

Lisätietoja MS Graph API:sta ja suodattimista löytyy osoitteesta https://docs.microsoft.com/en-us/graph/aad-advanced-queries?tabs=http .

Miten testata EPE:n Azure-kyselyitä

Jos haluat testata Azure-kyselyitä ilman EPE:n ajamista, siirry osoitteeseen https://developer.microsoft.com/en-us/graph/graph-explorer 

Tämä testaustyökalu käyttää täsmälleen samoja sääntöjä kuin EPE. Jos jokin toimii täällä, se toimii myös EPE:ssä ja päinvastoin.

Esimerkiksi näin voit testata, toimiiko onPremisesExtensionAttribute-syntaksi EPE:ssä:

Voit määrittää ajastetun tehtävän lukemaan dataa kyselyllä ja alikyselyillä, jotka liittyvät pääkyselyn palauttamaan tulosjoukkoon.

Tässä esimerkissä deviceManagement/managedDevices on pääkysely, ja sillä on 2 alikyselyä. Alikyselyt tehdään kaikille laitteille, jotka pääkysely palautti.

Kun olet määrittänyt nämä alikyselyt, voit käyttää niitä mappauksissa alikyselyjen palauttaman datan hakemiseen. Esimerkiksi näin:
 

Kun luet attribuuttia alikyselystä, sillä on oma muotonsa. Ensin tarvitset alikyselyn etuliitteenä, sitten pisteen (.) ja sitten luettavan attribuutin nimen.

Tarkastellaan esimerkkinä tätä mappausta tarkemmin:
/deviceManagement/managedDevices/{id}/windowsProtectionState.deviceState

etuliite(sama kuin alikysely): /deviceManagement/managedDevices/{id}/windowsProtectionState

piste: .

loppuliite attribuutin nimenä alikyselyn tulosjoukosta: deviceState

Kyseinen alikyselymappaus lukee (tässä esimerkissä) kaikkien pääkyselyn palauttamien laitteiden windowsProtectionState-objektista, ja sieltä se lukee deviceState-attribuutin arvon.

Alitaulukoiden tuki lisätty versioon 2025.2

Voit lukea attribuutteja taulukoista tällä syntaksilla:
deviceManagement/detectedApps/{id}/deviceActionResults.0.actionName
Esimerkkejä (lukee dataa deviceActionResults-alikyselyn tulosjoukon ensimmäisestä taulukosta ja lukee siitä actionName-, actionState- ja lastUpdatedDateTime-attribuutit erillisiin ESM-attribuutteihin):

Rajoitukset versiossa 2025.1

Monitasoisia alikyselyjä ei tueta

Alikyselyt tukevat vain yhtä alikyselytasoa, eli et voi suoraan luoda esimerkiksi tällaisia alikyselyitä, joissa on useampi kuin 1 muuttuja {}-merkkien sisällä:

/deviceManagement/detectedApps/{detectedAppId}/managedDevices/{managedDeviceId}/users/{userId}/managedDevices 

Alitaulukoita ei tueta

Datan hakemista alitaulukoista ei tueta, eli et voi esimerkiksi lukea actionName-arvoa tästä API-kutsusta:

deviceManagement/managedDevices/{id}

Vain yksi alikysely per tehtävä on tuettu

Jos käytät useampaa kuin yhtä alikyselyä, data saattaa sekoittua alikyselyjen välillä.

Rajoitukset versiossa 2025.2

Monitasoisia alikyselyjä ei tueta

Alikyselyt tukevat vain yhtä alikyselytasoa, eli et voi suoraan luoda esimerkiksi tällaisia alikyselyitä, joissa on useampi kuin 1 muuttuja {}-merkkien sisällä:

/deviceManagement/detectedApps/{detectedAppId}/managedDevices/{managedDeviceId}/users/{userId}/managedDevices 

Vain yksi alikysely per tehtävä on tuettu

Jos käytät useampaa kuin yhtä alikyselyä, data saattaa sekoittua alikyselyjen välillä.

Rajoitukset versiossa 2025.3

Monitasoisia alikyselyjä ei tueta

Alikyselyt tukevat vain yhtä alikyselytasoa, eli et voi suoraan luoda esimerkiksi tällaisia alikyselyitä, joissa on useampi kuin 1 muuttuja {}-merkkien sisällä:

/deviceManagement/detectedApps/{detectedAppId}/managedDevices/{managedDeviceId}/users/{userId}/managedDevices 

Generic REST call -toiminnolla voit tehdä erilaisia kutsuja Azureen ja Entra ID:hen Microsoft Graph API:n kautta. Tässä on muutamia esimerkkejä näistä mahdollisuuksista, mutta mahdollisuudet eivät rajoitu vain näihin.

extensionAttributes (1–15) -arvojen asettaminen Entra ID -tilille.

Luo JSON-runko työnkulun script-solmussa (muokkaa skriptiä tarpeidesi mukaan); alla olevassa esimerkkityönkulussa tämä skripti on ”EXT Generate ExtensionAttributes payload” -solmussa:

import json



_source = this.get("source")



# EXT users extension attributes, ordered from portal

if "Self-service portal" in _source:

  # set values to variables

  _extAttr1 = this.get("iga_id")

  _extAttr4 = "EXT"

  _extAttr9 = str(this.get("work_unit"))

  _extAttr10 = "100"

  _extAttr15 = this.get("microsoft_license")



  _payload_dict = {

    "onPremisesExtensionAttributes": {

        "extensionAttribute1": _extAttr1,

        "extensionAttribute4": _extAttr4,

        "extensionAttribute9": _extAttr9,

        "extensionAttribute10": _extAttr10,

        "extensionAttribute15": _extAttr15

    }

}



  # format to json and set to extattributesEntra attribute

  _payload = json.dumps(_payload_dict, indent=4)

  this.set("extattributesEntra", _payload)

Luo Orchestration-solmu Microsoft Graph API -tietolähteelle ja Generic REST call -toiminnolle.

Aseta Action-arvoksi PATCH, rest url -arvoksi /users/$objectGUID$ ja käytä bodyssa edellisessä vaiheessa luomaasi extattributesEntra-attribuutin arvoa syntaksilla $extattributesEntra$.

Tiettyjen/listattujen käyttäjäattribuuttien tyhjentäminen Entra ID:ssä

Tällaisella Orchestration-solmulla voit tyhjentää tiettyjä attribuuttiarvoja kerrallaan yhdeltä käyttäjältä Entra ID:ssä.

Kohdekäyttäjä annetaan REST URL:iin tietokortin attribuuttiparametrina api-päätepisteen /user/ jälkeen.

Muista käyttää Action=PATCH tyhjentääksesi/poistaaksesi tiettyjä attribuuttiarvoja käyttäjäobjektista Entra ID:ssä.

Tämä esimerkki poistaa/tyhjentää lähes kaikki extensionattributes-arvot sekä lisäksi companyName-, department-, employeeType-, jobTitle-, mobilePhone- ja officeLocation-attribuutit.

Activate / Deactive User 

Yllä olevassa kuvassa ylläpitäjät valitsevat oikean Microsoft Azure AD ”Target”-arvon ja voivat tarkastella valituille Azure-tehtäville määritettyjä Identity Mappings -tietoja. Tässä orkestrointinäkymässä ylläpitäjät eivät voi muuttaa mappauksia, vaan ne esitetään ainoastaan visuaalisena apuna. Jos mappauksiin tarvitaan muutoksia, ne on tehtävä provisiointitehtävän määritysnäkymässä.

Tässä samassa solmussa ylläpitäjät voivat valita haluamansa toiminnon: ”Activate” tai ”Deactivate”. ’Activate/Deactivate’-toiminto tarkoittaa tässä 'accountEnabled'-arvon asettamista arvoon true, jos tili on käytössä, ja muutoin arvoon false.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Add User to Group

Yllä olevassa kuvassa Person-attribuutin määrityksen tulisi osoittaa malliin, josta orkestrointisolmu löytää käyttäjän tiedot (yleensä IGA account). Role-attribuutti on määritettävä osoittamaan, mistä orkestrointisolmu löytää käytettävissä olevat roolit (hakemistoryhmät, joista käyttäjä tulisi poistaa). ”Role attribute” -kentässä voi olla määritettynä yksi tai useampi attribuuttiryhmä. Luettelo käytettävissä olevista rekisteröidyistä hakemistotehtävistä haetaan EPE-masterilta.

Hakemistotehtävä on valittava, koska Efecte Provisioning Enginen orkestrointisolmu käyttää identity- ja access rights -kenttien mappauksia tietääkseen, minkä attribuuttikoodin alla käyttäjän ja hakemistoryhmän distinguished name -arvot on tallennettu.

Person attribute odottaa attribuuttia, joka sisältää käyttäjän Entra ID -tilin id-arvon.

Poikkeusten käsittely:

• Solmun tulos on tilassa ”Completed” vain, jos käyttäjän kaikki ryhmäjäsenyydet päivitetään onnistuneesti. Jos esimerkiksi käyttäjä poistetaan onnistuneesti viidestä kuudesta ryhmästä, solmun tulos on tilassa ”Exception”.
• Tästä syystä distinguishedName-JSON-kentän mappaus vaaditaan sekä Identity- että Access Right -mappauksille. Jos mappausta ei löydy, orkestrointisolmun tulos on ”Exception”-tilassa.
• Yritys poistaa käyttäjä ryhmästä, johon hän ei kuulu, päättyy virheeseen.
• Yritys lisätä käyttäjä ryhmään, johon hän jo kuuluu, päättyy virheeseen.
• Tiedot käyttäjän ryhmäjäsenyyden onnistuneesta/epäonnistuneesta päivityksestä löytyvät lokeista.
• Provisioning- ja ryhmäjäsenyyspoikkeukset ovat valinnaisia ominaisuuksia tässä työnkulun solmussa. Ylläpitäjät voivat ottaa nämä ominaisuudet käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Create user
 

Yllä olevassa kuvassa Identity Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean hakemiston ”Target”-arvon ja voivat tarkastella valituille hakemistotehtäville määritettyjä Identity Mappings -tietoja. Tässä orkestrointinäkymässä ylläpitäjät eivät voi muuttaa mappauksia, vaan ne esitetään visuaalisena apuna. Jos mappauksiin tarvitaan muutoksia, ne on tehtävä provisiointitehtävän määritysnäkymässä.

Uuden käyttäjän luova orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-kutsun Azureen. On tärkeää varmistaa, että Create User -orkestrointisolmussa käytettävä Identity Mapping sisältää vähintään kolme lisämappausta Azure AD:hen: ”displayName”-, ”mailNickname”- ja ”userPrincipalName”-attribuuteille. Huomaa: jos nämä kolme mappausta puuttuvat annetusta määrityksestä, niitä ei näytetä pudotusvalikossa.

Huomioita uuden käyttäjän luontitoiminnosta:

• Uuden käyttäjän ensimmäisen kirjautumisen salasanan luomiseen on kaksi tapaa.
  • Määritä ”Default”-salasana Provisioning Task -määritysnäkymässä
    • Tätä salasanaa käyttäjät käyttävät vain kirjautuessaan järjestelmään ensimmäistä kertaa
  • Satunnaisen salasanan luominen työnkulussa ja sen valitseminen, mihin Identity Mapping -tietokortin attribuuttiin se kirjoitetaan
  • Molemmissa tapauksissa ensimmäisen salasanan ”pwdLastSet”-arvo asetetaan nollaan (0), jotta käyttäjä pakotetaan vaihtamaan salasanansa ensimmäisen kirjautumisen jälkeen
  • Mahdollisuus valita, onko salasana vaihdettava ensimmäisellä kirjautumisella vai ei. Ylläpitäjät voivat tehdä tämän valinnan suoraan työnkulun User Creation -orkestrointisolmusta.
• Ensimmäisen kirjautumisen salasanan toimittamiseen loppukäyttäjälle on eri tapoja. Asiakkaan tarpeiden mukaan voidaan käyttää työnkulun toimintoja salasanan lähettämiseksi suoraan loppukäyttäjälle sähköpostitse tai tekstiviestillä. Toinen vaihtoehto on lähettää ensimmäisen kirjautumisen salasana esimiehelle, joka toimittaa sen loppukäyttäjälle. EPE:n orkestrointisolmu itsessään EI tarjoa tätä toimintoa, vaan se on määritettävä muualla.
• Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Create Group

Yllä olevassa kuvassa Access Rights Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-arvon ja voivat tarkastella valituille Azure-tehtäville määritettyjä Access Rights Mappings -tietoja. Tässä orkestrointinäkymässä ylläpitäjät eivät voi muuttaa mappauksia, vaan ne esitetään visuaalisena apuna. Jos mappauksiin tarvitaan muutoksia, ne on tehtävä provisiointitehtävän määritysnäkymässä.

Uuden käyttäjän luova orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-komennon Entra-hakemistoon.

On tärkeää varmistaa, että Create Group -orkestrointisolmussa käytettävä Access Rights Mapping sisältää vähintään neljä lisämappausta Azure AD:hen: ”displayName”-, ”mailEnabled”-, ”mailNickname”- ja ”securityEnabled”-attribuuteille.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.


Delete Group
 

Yllä olevassa kuvassa ylläpitäjät voivat valita oikean Azure-hakemiston ”Target”-arvon. Ryhmän poistava orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-komennon Azure-hakemistoon.

Azure Active Directory -pohjaisissa määrityksissä 'Role group attribute' -kentän tulisi sisältää ryhmän ObjectGUID.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.
 

Delete User

Yllä olevassa kuvassa ylläpitäjät voivat valita oikean Azure AD ”Target”-arvon. Käyttäjän poistava orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-komennon Entra-hakemistoon.

Person attribute odottaa attribuuttia, joka sisältää käyttäjän Entra ID -tilin id-arvon.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Remove User from Group

Yllä olevassa kuvassa ylläpitäjät voivat valita oikean Azure AD ”Target”-arvon. Ryhmästä käyttäjää poistava orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-komennon Entra-hakemistoon.

Azure Active Directory -pohjaisissa määrityksissä 'Person Attribute'- ja 'Role attribute' -kenttien tulisi sisältää käyttäjän ObjectGUID-arvo.

Poikkeusten käsittely:

• Solmun tulos on tilassa ”Completed” vain, jos käyttäjän kaikki ryhmäjäsenyydet päivitetään onnistuneesti. Jos esimerkiksi käyttäjä poistetaan onnistuneesti viidestä kuudesta ryhmästä, solmun tulos on tilassa ”Exception”.
• Yritys poistaa käyttäjä ryhmästä, johon hän ei kuulu, päättyy virheeseen.
• Tiedot käyttäjän ryhmäjäsenyyden onnistuneesta/epäonnistuneesta päivityksestä löytyvät lokeista.
• Provisioning- ja ryhmäjäsenyyspoikkeukset ovat valinnaisia ominaisuuksia tässä työnkulun solmussa. Ylläpitäjät voivat ottaa nämä ominaisuudet käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.
   

Reset User Password

Yllä olevassa kuvassa ylläpitäjät voivat valita oikean Azure-hakemiston ”Target”-arvon. Käyttäjän salasanan nollaava orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-komennon Azure-hakemistoon. Person- ja Password-attribuuttien tulisi osoittaa malliin, josta orkestrointisolmu löytää käyttäjän tiedot.

EPE-versiosta 2022.3 alkaen on toteutettu mahdollisuus valita, onko salasana vaihdettava ensimmäisellä kirjautumisella vai ei. Ylläpitäjät voivat tehdä tämän valinnan suoraan työnkulun Reset User password -orkestrointisolmusta.

Person attribute odottaa attribuuttia, joka sisältää käyttäjän Entra ID -tilin id-arvon.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Update group
 

Yllä olevassa kuvassa Access Rights Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-arvon ja voivat tarkastella valituille Azure-tehtäville määritettyjä Access Rights Mappings -tietoja.

Tässä orkestrointinäkymässä ylläpitäjät eivät voi muuttaa mappauksia, vaan ne esitetään ainoastaan visuaalisena apuna. Jos mappauksiin tarvitaan muutoksia, ne on tehtävä provisiointitehtävän määritysnäkymässä.

Ryhmän päivittävä orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-kutsun Azureen.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Update User
 

Yllä olevassa kuvassa Identity Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-arvon ja voivat tarkastella valituille Azure-tehtäville määritettyjä Identity Mappings -tietoja. Tässä orkestrointinäkymässä ylläpitäjät eivät voi muuttaa mappauksia, vaan ne esitetään ainoastaan visuaalisena apuna. Jos mappauksiin tarvitaan muutoksia, ne on tehtävä provisiointitehtävän määritysnäkymässä.

Käyttäjän päivittävä orkestrointisolmu lukee attribuutit kyseisistä tietokorteista ja suorittaa API-kutsun Azure AD:hen.

Käyttäjän salasanan päivitystä ei tueta tässä orkestrointitoiminnossa.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Verify Group

Yllä olevassa kuvassa Access Rights Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-kohdasta ja voivat tarkastella, mitkä Access Rights Mappings on määritetty valitulle Azure-tehtävälle. Tässä orkestrointinäkymässä mappauksia ei voi muuttaa, vaan ne esitetään ainoastaan visuaalisena apuna. Jos attribuuttimappauksiin tarvitaan muutoksia, ne attribuutit on määritettävä provisiointitehtävän määritysnäkymässä, jotta ne muuttuvat myös orkestrointisolmussa.

Access Rights Mappings -ylläpitopaneelissa ylläpitäjät voivat antaa ”IF”-lausekkeen, josta muodostetaan API-kutsu ryhmän olemassaolon tarkistamiseksi. Tietokortista voi valita niin monta attribuuttia kuin tarvitaan ryhmän yksilöllisyyden varmistamiseksi. Toiminnon tapahtuessa nämä attribuutit luetaan kyseisestä tietokortista ja verrataan vastaaviin Azure-attribuutteihin ”Target*”-Azure-hakemistomäärityksen mukaisesti. Ylläpitäjät voivat myös valita ”equal” tai ”not equal” -vertailun vastaavaan Azure-attribuuttiin muuttamalla ”IF”-lauseketta. ”Save result*”-kenttää käytetään määrittämään, mihin onnistuneen API-kutsun tulokset tallennetaan: ”true”, jos ryhmä löytyi, tai ”false” muussa tapauksessa.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Retry-asetukset

Solmu tukee sisäänrakennettua uudelleenyrityslogiikkaa tilanteisiin, joissa kohdehakemisto ei välttämättä heti näytä äskettäin provisioitua tiliä – esimerkiksi Azuren replikointiviiveen vuoksi.

Number of repeats määrittää, kuinka monta kertaa tarkistusta yritetään. Oletusarvo on 1 (yksi yritys ilman uudelleenyrityksiä). Jos tarkistus onnistuu millä tahansa yrityskerralla, solmu pysähtyy heti ja jatkaa työnkulkua. Vain jos kaikki yritykset palauttavat kielteisen tuloksen, solmu käsittelee tarkistuksen epäonnistuneena. Jätä tyhjäksi, jos toistologiikkaa ei tarvita.

Repeat delay (milliseconds) määrittää odotusajan peräkkäisten yritysten välillä. Oletusarvo on 0 (ei viivettä). Viive lisätään ennen toista ja sitä seuraavia yrityksiä – ensimmäinen yritys suoritetaan aina heti. Jätä tyhjäksi, jos toistologiikkaa ei tarvita.

Repeat logic (script) on valinnainen Python-skripti, joka suoritetaan ennen jokaista tarkistusyritystä, myös ensimmäistä. Skriptillä on pääsy entiteetin dataan muuttujina. Sitä voidaan käyttää hakuehtoihin vaikuttavien attribuuttiarvojen muokkaamiseen tai muiden valmistelevien toimintojen suorittamiseen ennen kuin verify-kysely lähetetään hakemistoon. Jätä tyhjäksi, jos esikäsittelylogiikkaa ei tarvita.

Verify Group Membership

Yllä olevassa kuvassa Identity Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-kohdasta ja voivat tarkastella, mitkä Identity Mappings on määritetty valitulle Azure-tehtävälle. Tässä orkestrointinäkymässä mappauksia ei voi muuttaa, vaan ne esitetään ainoastaan visuaalisena apuna. Jos attribuuttimappauksiin tarvitaan muutoksia, ne attribuutit on määritettävä provisiointitehtävän määritysnäkymässä, jotta ne muuttuvat myös orkestrointisolmussa.

”Save result*”-kenttää käytetään määrittämään, mihin onnistuneen API-kutsun tulokset tallennetaan: ”true”, jos käyttäjä löytyi, tai ”false” muussa tapauksessa.

Person attribute odottaa attribuuttia, joka sisältää käyttäjän Entra ID -tilin id-arvon.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

 Verify User

Yllä olevassa kuvassa Identity Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-kohdasta ja voivat tarkastella, mitkä Identity Mappings on määritetty valitulle Azure-tehtävälle. Tässä orkestrointinäkymässä mappauksia ei voi muuttaa, vaan ne esitetään ainoastaan visuaalisena apuna. Jos attribuuttimappauksiin tarvitaan muutoksia, ne attribuutit on määritettävä provisiointitehtävän määritysnäkymässä, jotta ne muuttuvat myös orkestrointisolmussa.

Identity Mappings -ylläpitopaneelissa ylläpitäjät voivat antaa ”IF”-lausekkeen, josta muodostetaan API-kutsu käyttäjän olemassaolon tarkistamiseksi. Person-tietokortista voi valita niin monta attribuuttia kuin tarvitaan käyttäjän yksilöllisyyden varmistamiseksi. Toiminnon tapahtuessa nämä attribuutit luetaan kyseisestä tietokortista ja verrataan vastaaviin Azure-attribuutteihin ”Target*”-Azure-määrityksen mukaisesti. Ylläpitäjät voivat myös valita ”equal” tai ”not equal” -vertailun vastaavaan Azure-attribuuttiin muuttamalla ”IF”-lauseketta. ”Save result*”-kenttää käytetään määrittämään, mihin onnistuneen API-kutsun tulokset tallennetaan: ”true”, jos käyttäjä löytyi, tai ”false” muussa tapauksessa.

Tärkeä huomio tämän solmun toiminnan ymmärtämiseksi on, että IF-lauseketta muodostettaessa ylläpitäjän on käytettävä mallin attribuutteja, mutta itse asiassa niistä luetut arvot käännetään (mapataan) oikeiksi Azure-hakemiston attribuuteiksi Identity Mapping -määrityksen mukaisesti, ja ne välitetään Azure-hakemistolle hakukyselynä.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Retry-asetukset

Solmu tukee sisäänrakennettua uudelleenyrityslogiikkaa tilanteisiin, joissa kohdehakemisto ei välttämättä heti näytä äskettäin provisioitua tiliä – esimerkiksi Azuren replikointiviiveen vuoksi.

Number of repeats määrittää, kuinka monta kertaa tarkistusta yritetään. Oletusarvo on 1 (yksi yritys ilman uudelleenyrityksiä). Jos tarkistus onnistuu millä tahansa yrityskerralla, solmu pysähtyy heti ja jatkaa työnkulkua. Vain jos kaikki yritykset palauttavat kielteisen tuloksen, solmu käsittelee tarkistuksen epäonnistuneena. Jätä tyhjäksi, jos toistologiikkaa ei tarvita.

Repeat delay (milliseconds) määrittää odotusajan peräkkäisten yritysten välillä. Oletusarvo on 0 (ei viivettä). Viive lisätään ennen toista ja sitä seuraavia yrityksiä – ensimmäinen yritys suoritetaan aina heti. Jätä tyhjäksi, jos toistologiikkaa ei tarvita.

Repeat logic (script) on valinnainen Python-skripti, joka suoritetaan ennen jokaista tarkistusyritystä, myös ensimmäistä. Skriptillä on pääsy entiteetin dataan muuttujina. Sitä voidaan käyttää hakuehtoihin vaikuttavien attribuuttiarvojen muokkaamiseen tai muiden valmistelevien toimintojen suorittamiseen ennen kuin verify-kysely lähetetään hakemistoon. Jätä tyhjäksi, jos esikäsittelylogiikkaa ei tarvita.

Create Custom Object

Efecte Provisioning Engine (EPE) esittelee versiosta 2022.2 alkaen uuden työnkulun toiminnon ”Create custom object”. Esimerkiksi laitteita, kontakteja ja sovelluksia voidaan nyt luoda EPE:llä Azure AD:hen. Huomaa, että tämä toiminto vaatii IGA-lisenssin. Tämä tarkoittaa, että Custom object -luontia voidaan käyttää IGA-asennuksissa.

Yllä olevassa kuvassa Identity Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-kohdasta ja voivat tarkastella, mitkä Identity Mappings on määritetty valitulle Azure-tehtävälle. Tässä orkestrointinäkymässä mappauksia ei voi muuttaa, vaan ne esitetään ainoastaan visuaalisena apuna. Jos attribuuttimappauksiin tarvitaan muutoksia, ne attribuutit on määritettävä provisiointitehtävän määritysnäkymässä, jotta ne muuttuvat myös orkestrointisolmussa.

Custom object class määrittää, minkä objektin EPE luo. Tässä esimerkissä EPE luo kontakteja.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Update Custom Object

Efecte Provisioning Engine (EPE) esittelee versiosta 2023.1 alkaen uuden työnkulun toiminnon ”Update custom object”. Esimerkiksi laitteita, kontakteja ja sovelluksia voidaan nyt päivittää EPE:llä Azure AD:hen. Huomaa, että tämä toiminto vaatii IGA-lisenssin. Tämä tarkoittaa, että Custom object -päivitystä voidaan käyttää IGA-asennuksissa.

Yllä olevassa kuvassa Identity Attribute Mappings -tiedot täytetään provisiointitehtävistä. Ylläpitäjät valitsevat oikean Azure-hakemiston ”Target”-kohdasta ja voivat tarkastella, mitkä Identity Mappings on määritetty valitulle Azure-tehtävälle. Tässä orkestrointinäkymässä mappauksia ei voi muuttaa, vaan ne esitetään ainoastaan visuaalisena apuna. Jos attribuuttimappauksiin tarvitaan muutoksia, ne attribuutit on määritettävä provisiointitehtävän määritysnäkymässä, jotta ne muuttuvat myös orkestrointisolmussa.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Delete Custom Object

Efecte Provisioning Engine (EPE) esittelee versiosta 2023.1 alkaen uuden työnkulun toiminnon ”Delete custom object”. Esimerkiksi laitteita, kontakteja ja sovelluksia voidaan nyt poistaa EPE:llä Azure AD:sta. Huomaa, että tämä toiminto vaatii IGA-lisenssin. Tämä tarkoittaa, että Custom object -poistoa voidaan käyttää IGA-asennuksissa.

Yllä olevassa kuvassa Object name attribute määrittää, minkä objektin EPE poistaa. Tässä esimerkissä EPE poistaa kontakteja.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Read user data

Efecte Provisioning Engine (EPE) esittelee versiosta 2022.2 alkaen uuden työnkulun toiminnon ”Read User's data”. Tietoa voidaan päivittää viittauksen taakse, esimerkiksi IGA account -dataa voidaan päivittää identiteettivarastosta.

Yllä olevassa kuvassa person attribute -kenttää käytetään oikean tilitiedon päivittämiseen hakemistosta ESM:ään.

Person attribute odottaa attribuuttia, joka sisältää käyttäjän Entra ID -tilin id-arvon.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.
 

Run provisioning task

Tätä toimintoa käytetään, kun kaikki tieto hakemistosta tarvitaan välittömästi takaisin.

Yllä olevassa kuvassa ylläpitäjät voivat valita oikean hakemiston ”Target”-arvon. Run provisioning task -orkestrointisolmu lukee attribuutit Azure-hakemistosta IGA-tileille.

Vaatimukset ”Target”-EPE-tehtävälle ovat:

• Tehtävän on oltava tyyppiä ”Schedulable task”, ei tapahtumapohjainen
• Työnkulun mallin on oltava sama kuin Identity mapping -malli
• Tehtävä on ajastettava johonkin ajankohtaan – tämä merkitsee tehtävän tilaksi ”enabled”
• Mappausten on oltava yksilöllisiä, tehtävässä ei saa olla päällekkäisiä mappauksia

Tässä orkestrointinäkymässä mappauksia ei voi muuttaa, vaan ne esitetään ainoastaan visuaalisena apuna. Jos attribuuttimappauksiin tarvitaan muutoksia, ne attribuutit on määritettävä provisiointitehtävän määritysnäkymässä, jotta ne muuttuvat myös orkestrointisolmussa.

Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.

Generic REST call

Lisää Orchestration-solmu työnkulkuusi ja määritä seuraavat asiat.

Name – anna kuvaava nimi

Description – anna kuvaava kuvaus

Orchestrate – valitse Provisioning Engine

Data Source – valitse Microsoft Graph API

Activity – valitse Generic REST call

Target – valitse tapahtumapohjainen tehtäväsi (samaa tehtävää voi käyttää useissa orkestrointisolmuissa)

Action – valitse toiminto sen REST API:n mukaan, jota kutsut (tarkista oikea toiminto API-dokumentaatiosta). Tuetut toiminnot ovat: POST, PUT, PATCH, DELETE ja GET

REST URL – kutsuttava api-päätepiste. Tämä voi olla täydellinen URL tai URL:n loppuosa. Jos käytät loppuosaa, kutsuttava todellinen URL muodostetaan yhdistämällä kaikki seuraavat: liittimen host-URL + tehtävän kysely + Orchestration-solmun URL. Voit käyttää mallin attribuuttimuuttujia samaan tapaan kuin sähköpostisolmussa, dollari-syntaksilla, kuten: $attribute_code$ ja $reference:attribute_code$.

Huomaa! Jos URL:ssäsi on välilyöntejä tai $-merkkejä, muista URL-koodata ne. Eli $ on %24 ja välilyönti on %20
Esimerkiksi tämä URL: users?%24count=true&$filter=userprincipalname eq 'test' koodataan näin: users?$count=true&%24filter=userprincipalname%20eq%20'test'

Rest Body – api-kutsun JSON-runko. Voi olla tyhjä, jos kutsuttava API ei tarvitse runkoa; voit myös käyttää arvoa {}, jos rungon jättäminen tyhjäksi ei toimi Microsoftin kanssa. Katso rungon yksityiskohdat API-dokumentaatiosta. Voit käyttää mallin attribuuttimuuttujia samaan tapaan kuin sähköpostisolmussa, dollari-syntaksilla, kuten: $attribute_code$ ja $reference:attribute_code$.

Esimerkiksi tässä rungossa on kaksi muuttujaa: $firstname$ ja $lastname$
{"name": {
   "givenName": "$firstname$",
   "familyName": “$lastname$”}}

Jos sinun on luotava monimutkainen JSON-runko API-kutsulle, voit muodostaa koko JSON:n ensin johonkin tietokortin attribuuttiin. Sen jälkeen sinulla tarvitsee olla vain kyseisen attribuutin koodi rungossa, näin: $generated_json_body_attributecode$

import json

if onPremisesExtensionAttributes:
  _data = this.get("onPremisesExtensionAttributes")
  _obj = json.loads(_data)
  _value = _obj["extensionAttribute14"]
  this.set("extensionAttribute14code",_value)

Rest Response Attribute – API-kutsun tulosjoukon JSON kirjoitetaan tähän attribuuttiin. Kaikki API:t eivät palauta vastaus-JSONia. Katso yksityiskohdat API-dokumentaatiosta.

import json

if onPremisesExtensionAttributes:
  _data = this.get("onPremisesExtensionAttributes")
  _obj = json.loads(_data)
  _value = _obj["extensionAttribute14"]
  this.set("extensionAttribute14code",_value)

Provisioning exception – jos REST API -kutsussa on ongelma, virhe kirjoitetaan tähän attribuuttiin.

Poikkeusten käsittely Generic REST call -kutsuille:

• Provisioning exception on valinnainen ominaisuus tässä työnkulun solmussa. Ylläpitäjät voivat ottaa tämän ominaisuuden käyttöön, jolloin poikkeukset voidaan kirjoittaa, jos provisiointitoimintojen aikana ilmenee poikkeuksia.
• Solmun tulos on tilassa ”Completed”, jos Microsoft Graph API:n HTTP-vastauskoodi on 200 tai suurempi ja alle 400.
• Tiedot onnistuneista/epäonnistuneista Microsoft Graph API -kutsuista löytyvät lokeista.

Tässä luvussa kuvataan vianmääritysvaihtoehtoja,

• Jos failure-mallia käytetään, tarkista virhetiedot oikeasta tietokortista
• Tarkista ajastetun tehtävän historia liitinhallinnasta
• Tarkista Matrix42 Native Connectors -lokit; ne löytyvät Connectors-välilehdeltä, Logs-osiosta
• Tällä hetkellä EPE ei tue saman EntraID id -attribuutin mappaamista useisiin ESM-attribuutteihin. Käyttöliittymä kuitenkin sallii tämän määrityksen, mikä voi johtaa virheisiin.
• Tarkista FAQ-dokumentit