Självstudie: Konfigurera Workday för automatisk användaretablering

Målet med den här självstudien är att visa de steg du behöver utföra för att etablera arbetsprofiler från Workday till lokal Active Directory (AD).

Anteckning

Använd den här självstudien om de användare som du vill etablera från Workday behöver ett lokalt AD-konto och ett Azure AD-konto.

  • Om användarna från Workday bara behöver ett Azure AD-konto (endast molnbaserade användare) kan du gå vidare till självstudien om att konfigurera Workday till Azure AD-användareablering.
  • Om du vill konfigurera tillbakaskrivning av attribut som e-postadress, användarnamn och telefonnummer från Azure AD till Workday kan du gå till självstudien om att konfigurera tillbakaskrivning av Workday.

Översikt

Den Azure Active Directory tjänsten för användareablering integreras med Workday Human Resources-API:et för att etablera användarkonton. Arbetsflöden för etablering av Workday-användare som stöds av Azure AD-tjänsten för användareablering möjliggör automatisering av följande scenarier för hantering av personalresurser och identitetslivscykel:

  • Anställ nya medarbetare – När en ny medarbetare läggs till i Workday skapas ett användarkonto automatiskt i Active Directory, Azure Active Directory och eventuellt Microsoft 365 och andra SaaS-programsom stöds av Azure AD, med tillbakaskrivning av IT-hanterad kontaktinformation till Workday.

  • Uppdateringar av medarbetares attribut och profiler – När en medarbetares post uppdateras i Workday (till exempel deras namn, titel eller chef) uppdateras användarkontot automatiskt i Active Directory, Azure Active Directory och eventuellt Microsoft 365 och andra SaaS-programsom stöds av Azure AD.

  • Uppsägning av medarbetare – När en anställd avslutas i Workday inaktiveras användarkontot automatiskt i Active Directory, Azure Active Directory och eventuellt även Microsoft 365 andra SaaS-programsom stöds av Azure AD.

  • Återanställande av medarbetare – När en anställd återanställs i Workday kan deras gamla konto automatiskt återaktiveras eller etableras om (beroende på dina önskemål) till Active Directory, Azure Active Directory och eventuellt även Microsoft 365 och andra SaaS-programsom stöds av Azure AD.

Nyheter

Det här avsnittet innehåller de senaste förbättringarna av Workday-integreringen. En lista över omfattande uppdateringar, planerade ändringar och arkiv finns på sidan Nyheter i Azure Active Directory?

  • Okt 2020 – Aktiverad etablering på begäran för Workday: Med etablering på begäran kan du nu testa etablering från slutet till slut för en specifik användarprofil i Workday för att verifiera attributmappningen och uttryckslogiken.

  • Maj 2020 – Möjlighet att skriva tillbaka telefonnummer till Workday: Förutom e-post och användarnamn kan du nu tillbakaskrivning av arbetstelefonnummer och mobiltelefonnummer från Azure AD till Workday. Mer information finns i självstudien om tillbakaskrivningsappen.

  • April 2020 – Stöd för den senaste versionen av WORKday Web Services (WWS) API: Två gånger per år i mars och september levererar Workday funktionsrika uppdateringar som hjälper dig att uppfylla dina affärsmål och ändra personalbehov. Om du vill hålla dig uppdaterad med de nya funktionerna som levereras av Workday kan du nu direkt ange den WWS API-version som du vill använda i anslutnings-URL:en. Mer information om hur du anger Workday API-versionen finns i avsnittet om hur du konfigurerar Workday-anslutning.

Vem passar den här lösningen för användareablering bäst?

Den här Workday-lösningen för användareablering passar utmärkt för:

  • Organisationer som vill ha en färdig, molnbaserad lösning för Workday-användareablering

  • Organisationer som kräver direkt användareablering från Workday till Active Directory eller Azure Active Directory

  • Organisationer som kräver att användare etableras med hjälp av data som hämtas från Workday HCM-modulen (se Get_Workers)

  • Organisationer som behöver ansluta till, flytta och låta användare synkroniseras till en eller flera Active Directory-skogar, domäner och organisationsenhet baserat på ändringsinformation som identifierats i Workday HCM-modulen (se Get_Workers)

  • Organisationer som använder Microsoft 365 för e-post

Lösningsarkitektur

I det här avsnittet beskrivs lösningsarkitekturen för etablering från slutanvändare till slutanvändare för vanliga hybridmiljöer. Det finns två relaterade flöden:

  • Auktoritativt HR-dataflöde – från Workday till lokal Active Directory: I det här flödet sker arbetshändelser (till exempel nyanställda, överföringar, uppsägningar) först i Hr-klientorganisationen Workday i molnet och sedan flödar händelsedata till lokal Active Directory via Azure AD och etableringsagenten. Beroende på händelsen kan det leda till att åtgärder skapas/uppdateras/aktiveras/inaktiveras i AD.
  • Tillbakaskrivningsflöde – från lokal Active Directory till Workday: När kontot har skapats i Active Directory synkroniseras det med Azure AD via Azure AD Anslut och information som e-post, användarnamn och telefonnummer kan skrivas tillbaka till Workday.

Översikt

Dataflöde från slutanvändare till slutanvändare

  1. HR-teamet utför arbetstransaktioner (joiners/movers/leavers eller nyanställda/överföringar/uppsägningar) i Workday HCM
  2. Azure AD-etableringstjänsten kör schemalagd synkronisering av identiteter från Workday HR och identifierar ändringar som måste bearbetas för synkronisering med lokal Active Directory.
  3. Azure AD-etableringstjänsten anropar den lokala Azure AD Anslut-etableringsagenten med en nyttolast för begäran som innehåller åtgärder för att skapa/uppdatera/aktivera/inaktivera AD-konto.
  4. Azure AD-Anslut-etableringsagenten använder ett tjänstkonto för att lägga till/uppdatera AD-kontodata.
  5. Azure AD-Anslut/AD Sync kör deltasynkronisering för att hämta uppdateringar i AD.
  6. Active Directory-uppdateringarna synkroniseras med Azure Active Directory.
  7. Om tillbakaskrivningsappen för Workday har konfigurerats skriver den tillbaka attribut som e-post, användarnamn och telefonnummer till Workday.

Planera distributionen

Att konfigurera Workday till Active Directory-användareablering kräver omfattande planering för olika aspekter, till exempel:

  • Konfiguration av Azure AD-Anslut etableringsagenten
  • Antal Workday till AD-användareableringsappar som ska distribueras
  • Välja rätt matchande identifierare, attributmappning, transformering och omfångsfilter

Se hr-distributionsplanen i molnet för omfattande riktlinjer och rekommenderade metodtips.

Konfigurera integrationssystemanvändare i Workday

Ett vanligt krav för alla Workday-etableringsanslutningar är att de kräver autentiseringsuppgifter för en Workday-integreringssystemanvändare för att ansluta till Workday Human Resources-API:et. Det här avsnittet beskriver hur du skapar en integrationssystemanvändare i Workday och innehåller följande avsnitt:

Anteckning

Du kan kringgå den här proceduren och i stället använda ett globalt workday-administratörskonto som systemintegreringskonto. Detta kan fungera bra för demonstrationer, men rekommenderas inte för produktionsdistributioner.

Skapa en integrationssystemanvändare

Så här skapar du en integrationssystemanvändare:

  1. Logga in på Workday-klienten med ett administratörskonto. I Workday-programmet anger du skapa användare i sökrutan och klickar sedan på Skapa systemanvändare för integration.

    Skapa användare

  2. Slutför uppgiften Skapa systemanvändare för integrationssystem genom att ange ett användarnamn och lösenord för en ny integrationssystemanvändare.

    • Lämna alternativet Kräv nytt lösenord vid Nästa inloggning avmarkerat, eftersom den här användaren kommer att logga in programmatiskt.
    • Lämna standardvärdet 0 för Sessionstidsoutminuter, vilket förhindrar att användarens sessioner tar för lång tid.
    • Välj alternativet Tillåt inte UI-sessioner eftersom det ger ett extra säkerhetslager som förhindrar att en användare med lösenordet för integrationssystemet loggar in på Workday.

    Skapa integrationssystemanvändare

Skapa en integreringssäkerhetsgrupp

I det här steget skapar du en säkerhetsgrupp för integrationssystem utan begränsningar i Workday och tilldelar den integrationssystemanvändare som skapades i föregående steg till den här gruppen.

Så här skapar du en säkerhetsgrupp:

  1. Ange skapa säkerhetsgrupp i sökrutan och klicka sedan på Skapa säkerhetsgrupp.

    Skärmbild som visar "skapa säkerhetsgrupp" som angetts i sökrutan och "Skapa säkerhetsgrupp – uppgift" som visas i sökresultaten.

  2. Slutför uppgiften Skapa säkerhetsgrupp.

    • Det finns två typer av säkerhetsgrupper i Workday:

      • Ej tränad: Alla medlemmar i säkerhetsgruppen kan komma åt alla datainstanser som skyddas av säkerhetsgruppen.
      • Begränsad: Alla medlemmar i säkerhetsgrupper har sammanhangsbaserad åtkomst till en delmängd av datainstanser (rader) som säkerhetsgruppen har åtkomst till.
    • Kontakta workday-integreringspartnern för att välja lämplig typ av säkerhetsgrupp för integreringen.

    • När du känner till grupptypen väljer du Integration System Security Group (Unconstrained) eller Integration System Security Group (Begränsad) i listrutan Typ av klientorganisationssäkerhetsgrupp.

      SkapaSäkerhetsgrupp

  3. När säkerhetsgruppen har skapats visas en sida där du kan tilldela medlemmar till säkerhetsgruppen. Lägg till den nya integrationssystemanvändaren som skapades i föregående steg i den här säkerhetsgruppen. Om du använder begränsad säkerhetsgrupp måste du också välja lämplig organisationsomfattning.

    Redigera säkerhetsgrupp

Konfigurera behörigheter för domänsäkerhetsprincip

I det här steget beviljar du säkerhetsgruppen behörighet för "domänsäkerhet"-principen för arbetsdata.

Så här konfigurerar du behörigheter för domänsäkerhetsprincip:

  1. Ange Medlemskap och åtkomst för säkerhetsgrupp i sökrutan och klicka på rapportlänken.

    Sök efter medlemskap i säkerhetsgrupper

  2. Sök och välj den säkerhetsgrupp som skapades i föregående steg.

    Välj Säkerhetsgrupp

  3. Klicka på ellipsen (...) bredvid gruppnamnet och välj Säkerhetsgrupp på menyn > Underhåll domänbehörigheter för säkerhetsgrupp

    Välj Behåll domänbehörigheter

  4. Under Integrationsbehörigheter lägger du till följande domäner i listan Domänsäkerhetsprinciper som tillåter Placera åtkomst

    • Etablering av externt konto
    • Arbetsdata: Offentliga arbetsrapporter
    • Persondata: Arbetskontaktinformation (krävs om du planerar att tillbakaskrivning av kontaktdata från Azure AD till Workday)
    • Workday-konton (krävs om du planerar att skriva tillbaka användarnamn/UPN från Azure AD till Workday)
  5. Under Integrationsbehörigheter lägger du till följande domäner i listan Domänsäkerhetsprinciper som tillåter åtkomst

    • Arbetsdata: Arbetare
    • Arbetsdata: Alla positioner
    • Arbetsdata: Aktuell bemanningsinformation
    • Arbetsdata: Affärstitel på arbetsprofil
    • Arbetsdata: Kvalificerade arbetare (valfritt – lägg till detta för att hämta arbetskvalificeringsdata för etablering)
    • Arbetsdata: Kunskaper och erfarenhet (valfritt – lägg till detta för att hämta data om arbetsfärdigheter för etablering)
  6. När du har slutfört ovanstående steg visas behörighetsskärmen enligt nedan:

    Alla behörigheter för domänsäkerhet

  7. Klicka på OK och Klar på nästa skärm för att slutföra konfigurationen.

<a name="configuring-business-process-security-policy-permissions">Konfigurera behörigheter för affärsprocesssäkerhetsprincip

I det här steget beviljar du säkerhetsprincipbehörigheter för "affärsprocesssäkerhet" för arbetsdata till säkerhetsgruppen.

Anteckning

Det här steget krävs endast för att konfigurera workday-appanslutningen för tillbakaskrivning.

Så här konfigurerar du behörigheter för affärsprocesssäkerhetsprincip:

  1. Ange Affärsprocessprincip i sökrutan och klicka sedan på länken Redigera säkerhetsprincip för affärsprocess.

    ![Skärmbild som visar "Affärsprocessprincip" i sökrutan och "Redigera säkerhetsprincip för affärsprocess – uppgift" har valts.](./media/workday-inbound-tutorial/wd_isu_12.png "Säkerhetsprinciper för affärsprocess")

  2. I textrutan Affärsprocesstyp söker du efter Kontakt och väljer Arbetskontakt Ändra affärsprocess och klickar på OK.

    Skärmbild som visar sidan "Redigera säkerhetsprincip för affärsprocess" och "Ändring av arbetskontakt" som valts i menyn Affärsprocesstyp.

  3. På sidan Redigera säkerhetsprincip för affärsprocess bläddrar du till avsnittet Ändra arbetskontaktinformation (webbtjänst).

  4. Välj och lägg till den nya integrationssystemsäkerhetsgruppen i listan över säkerhetsgrupper som kan initiera begäran om webbtjänster.

    Säkerhetsprinciper för affärsprocess

  5. Klicka på Klar.

Aktivera ändringar i säkerhetsprincipen

Så här aktiverar du säkerhetsprincipändringar:

  1. Ange aktivera i sökrutan och klicka sedan på länken Aktivera väntande säkerhetsprincipändringar.

    Aktivera

  2. Starta aktiviteten Activate Pending Security Policy Changes (Aktivera väntande säkerhetsprincipändringar) genom att ange en kommentar i granskningssyfte och klicka sedan på OK.

  3. Slutför uppgiften på nästa skärm genom att markera kryssrutan Bekräfta och klicka sedan på OK.

    Aktivera väntande säkerhet

Installationsförutsättningar för etableringsagenten

Granska installationsförutsättningarna för etableringsagenten innan du fortsätter till nästa avsnitt.

Konfigurera användareablering från Workday till Active Directory

Det här avsnittet innehåller steg för etablering av användarkonton från Workday till varje Active Directory-domän inom ramen för din integrering.

Del 1: Lägg till etableringsanslutningsappen och ladda ned etableringsagenten

Så här konfigurerar du Workday till Active Directory-etablering:

  1. Gå till https://portal.azure.com.

  2. I Azure Portal du efter och väljer Azure Active Directory.

  3. Välj Företagsprogram och sedan Alla program.

  4. Välj Lägg till ett program och välj kategorin Alla.

  5. Sök efter Workday till Active Directory User Provisioning och lägg till appen från galleriet.

  6. När appen har lagts till och skärmen med appinformation visas väljer du Etablera.

  7. Ändra etableringsläget till Automatiskt.

  8. Klicka på informationsbanderollen som visas för att ladda ned etableringsagenten.

    Ladda ned agent

Del 2: Installera och konfigurera lokala etableringsagenter

Om du vill etablera till Active Directory lokalt måste etableringsagenten installeras på en domän-ansluten server som har nätverksåtkomst till önskade Active Directory-domäner.

Överför det nedladdade installationsprogrammet för agenten till servervärden och följ stegen i avsnittet Installera agent för att slutföra agentkonfigurationen.

Del 3: Konfigurera anslutningen till Workday och Active Directory i etableringsappen

I det här steget upprättar vi en anslutning med Workday och Active Directory i Azure Portal.

  1. I den Azure Portal går du tillbaka till Workday till Active Directory User Provisioning-appen som skapades i del 1

  2. Slutför avsnittet Administratörsautentiseringsuppgifter enligt följande:

    • Workday-användarnamn – Ange användarnamnet för Workday-integrationssystemets konto, med klientorganisationens domännamn tillagt. Det bör se ut ungefär så här: @ tenant_name

    • Workday-lösenord – Ange lösenordet för Workday-integrationssystemkontot

    • Workday Web Services API-URL – Ange URL:en till workday-webbtjänstens slutpunkt för din klientorganisation. URL:en avgör vilken version av Workday Web Services-API:et som används av anslutningsappen.

      URL-format WWS API-version som används XPATH-ändringar krävs
      https://####.workday.com/ccx/service/tenantName v21.1 No
      https://####.workday.com/ccx/service/tenantName/Human_Resources v21.1 No
      https://####.workday.com/ccx/service/tenantName/Human_Resources/v##.# v##. # Yes

      Anteckning

      Om ingen versionsinformation anges i URL:en använder appen Workday Web Services (WWS) v21.1 och inga ändringar krävs för de XPATH API-standarduttryck som levereras med appen. Om du vill använda en specifik WWS API-version anger du versionsnumret i URL:en
      Exempel: https://wd3-impl-services1.workday.com/ccx/service/contoso4/Human_Resources/v34.0

      Om du använder ett WWS API v30.0+ uppdaterar du XPATH API-uttrycken under Attributmappning -> Avancerade alternativ -> Redigera attributlista för Workday i avsnittet Hantera konfigurationen och Workday-attributreferensen innan du slår på etableringsjobbet.

    • Active Directory-skog – "Namn" för din Active Directory-domän, som registrerats med agenten. Använd listrutan för att välja måldomänen för etablering. Det här värdet är vanligtvis en sträng som: contoso.com

    • Active Directory-container – Ange den dn-container där agenten ska skapa användarkonton som standard. Exempel: OU=Standard Users,OU=Users,DC=contoso,DC=test

      Anteckning

      Den här inställningen används endast för skapande av användarkonton om attributet parentDistinguishedName inte har konfigurerats i attributmappningarna. Den här inställningen används inte för användarsöknings- eller uppdateringsåtgärder. Hela underträdet för domänen omfattas av sökåtgärden.

    • E-postavisering – Ange din e-postadress och markera kryssrutan "Skicka e-postmeddelande om ett fel inträffar".

      Anteckning

      Azure AD Provisioning Service skickar ett e-postmeddelande om etableringsjobbet förs i karantäntillstånd.

    • Klicka på knappen Testa anslutning. Om anslutningstestet lyckas klickar du på knappen Spara längst upp. Om det misslyckas kontrollerar du att Workday-autentiseringsuppgifterna och DE AD-autentiseringsuppgifter som konfigurerats för agentinstallationen är giltiga.

      Skärmbild som visar sidan "Etablering" med angivna autentiseringsuppgifter.

    • När autentiseringsuppgifterna har sparats visas standardmappningen Synkronisera Workday Workers till Lokal Active Directory i avsnittet Mappningar

Del 4: Konfigurera attributmappningar

I det här avsnittet konfigurerar du hur användardata flödar från Workday till Active Directory.

  1. På fliken Etablering under Mappningar klickar duSynkronisera Workday Workers till Lokal Active Directory.

  2. I fältet Källobjektomfång kan du välja vilka uppsättningar användare i Workday som ska finnas i omfånget för etablering till AD genom att definiera en uppsättning attributbaserade filter. Standardomfånget är "alla användare i Workday". Exempelfilter:

    • Exempel: Omfång för användare med arbets-ID mellan 10000000 och 2000000 (exklusive 20000000)

      • Attribut: WorkerID

      • Operator: REGEX-matchning

      • Värde: (1[0-9][0-9][0-9][0-9][0-9][0-9])

    • Exempel: Endast anställda och inte bearbetare

      • Attribut: EmployeeID

      • Operator: ÄR INTE NULL

    Tips

    När du konfigurerar etableringsappen för första gången måste du testa och verifiera dina attributmappningar och uttryck för att se till att den ger önskat resultat. Microsoft rekommenderar att du använder omfångsfilter under Källobjektomfång och etablering på begäran för att testa dina mappningar med några testanvändare från Workday. När du har kontrollerat att mappningarna fungerar kan du antingen ta bort filtret eller gradvis expandera det för att inkludera fler användare.

    Varning

    Standardbeteendet för etableringsmotorn är att inaktivera/ta bort användare som inte omfattas. Detta kanske inte är önskvärt i integreringen mellan Workday och AD. Information om hur du åsidosätter det här standardbeteendet finns i artikeln Hoppa över borttagning av användarkonton som inte omfattas

  3. I fältet Målobjektåtgärder kan du globalt filtrera vilka åtgärder som utförs i Active Directory. Skapa och uppdatera är vanligast.

  4. I avsnittet Attributmappningar kan du definiera hur enskilda Workday-attribut mappar till Active Directory-attribut.

  5. Klicka på en befintlig attributmappning för att uppdatera den eller klicka på Lägg till ny mappning längst ned på skärmen för att lägga till nya mappningar. En enskild attributmappning stöder följande egenskaper:

    • Mappningstyp

      • Direkt – Skriver värdet för workday-attributet till AD-attributet utan ändringar

      • Konstant – Skriv ett statiskt, konstant strängvärde till AD-attributet

      • Uttryck – Gör att du kan skriva ett anpassat värde till AD-attributet, baserat på ett eller flera Workday-attribut. Mer information finns i den här artikeln om uttryck.

    • Källattribut – användarattributet från Workday. Om attributet du letar efter inte finns, se Anpassa listan över Workday-användarattribut.

    • Standardvärde – Valfritt. Om källattributet har ett tomt värde skriver mappningen det här värdet i stället. Den vanligaste konfigurationen är att lämna detta tomt.

    • Målattribut – Användarattributet i Active Directory.

    • Matcha objekt med det här attributet – Huruvida den här mappningen ska användas för att unikt identifiera användare mellan Workday och Active Directory. Det här värdet anges vanligtvis i fältet Arbets-ID för Workday, som vanligtvis mappas till ett av attributen för medarbetar-ID i Active Directory.

    • Matchande prioritet – Flera matchande attribut kan anges. När det finns flera utvärderas de i den ordning som definieras av det här fältet. Så snart en matchning hittas utvärderas inga ytterligare matchande attribut.

    • Tillämpa den här mappningen

      • Alltid – Tillämpa den här mappningen på både användarskapande och uppdateringsåtgärder

      • Endast under skapande – Tillämpa endast den här mappningen på åtgärder för att skapa användare

  6. Spara mappningarna genom att klicka Spara överst i Attribute-Mapping avsnittet.

    Skärmbild som visar sidan "Attributmappning" med åtgärden "Spara" markerad.

Nedan visas några exempel på attributmappningar mellan Workday och Active Directory, med några vanliga uttryck

  • Uttrycket som mappar till attributet parentDistinguishedName används för att etablera en användare till olika OU:er baserat på ett eller flera Workday-källattribut. I det här exemplet placerar vi användare i olika ous baserat på vilken stad de finns i.

  • Attributet userPrincipalName i Active Directory genereras med hjälp av dedupliceringsfunktionen SelectUniqueValue som kontrollerar om det finns ett genererat värde i AD-måldomänen och anger det bara om det är unikt.

  • Det finns dokumentation om att skriva uttryck här. Det här avsnittet innehåller exempel på hur du tar bort specialtecken.

WORKDAY-ATTRIBUT ACTIVE DIRECTORY-ATTRIBUT MATCHANDE ID? SKAPA/UPPDATERA
WorkerID EmployeeID Ja Endast skrivet vid skapa
PreferredNameData Cn Endast skrivet vid skapa
SelectUniqueValue( Join(" @ ", Join(".", [ FirstName ] , [ LastName ] ), "contoso.com"), Join(" @ ", Join(".", Mid( [ ] FirstName , 1, 1), [ LastName ), ] "contoso.com"), Join(" @ ", Join(".", Mid( [ FirstName , ] 1, 2), [ LastName ), ] "contoso.com")) userPrincipalName Endast skrivet vid skapa
Replace(Mid(Replace(\[UserID\], , "(\[\\\\/\\\\\\\\\\\\\[\\\\\]\\\\:\\\\;\\\\\|\\\\=\\\\,\\\\+\\\\\*\\\\?\\\\&lt;\\\\&gt;\])", , "", , ), 1, 20), , "([\\\\.)\*\$](file:///\\.)*$)", , "", , ) sAMAccountName Endast skrivet vid skapa
Switch( [ Active ] , "0", "True", "1", "False") accountDisabled Skapa + uppdatera
FirstName förnamn Skapa + uppdatera
LastName sn Skapa + uppdatera
PreferredNameData displayName Skapa + uppdatera
Företag company Skapa + uppdatera
På vilket sätt? avdelning Skapa + uppdatera
ManagerReference manager Skapa + uppdatera
BusinessTitle title Skapa + uppdatera
AddressLineData streetAddress Skapa + uppdatera
Kommun l Skapa + uppdatera
CountryReferenceTwoLetter co Skapa + uppdatera
CountryReferenceTwoLetter c Skapa + uppdatera
CountryRegionReference st Skapa + uppdatera
WorkSpaceReference physicalDeliveryOfficeName Skapa + uppdatera
Postnummer postalCode Skapa + uppdatera
PrimaryWorkTelephone telephoneNumber Skapa + uppdatera
Fax facsimileTelephoneNumber Skapa + uppdatera
Mobilt mobil Skapa + uppdatera
LocalReference preferredLanguage Skapa + uppdatera
Switch( [ ] Switch, "OU=Default Users,DC=contoso,DC=com", "Dallas", "OU=Dallas,OU=Users,DC=contoso,DC=com", "Ou=Seattle", "OU=Ou=Users,DC=contoso,DC=com", "Seattle", "OU=Seattle,OU=Users,DC=contoso,DC=com", "London", "OU=London,OU=Users,DC=contoso,DC=com") parentDistinguishedName Skapa + uppdatera

När konfigurationen för attributmappning är klar kan du testa etableringen för en enskild användare med etablering på begäran och sedan aktivera och starta användaretableringstjänsten.

Aktivera och starta användareablering

När workday-etableringsappkonfigurationerna har slutförts och du har verifierat etableringen för en enskild användare med etablering på begäran kan du aktivera etableringstjänsten i Azure Portal.

Tips

Som standard när du aktiverar etableringstjänsten initierar den etableringsåtgärder för alla användare i omfånget. Om det finns fel i mappning eller Workday-dataproblem kan etableringsjobbet misslyckas och förs in i karantäntillståndet. För att undvika detta rekommenderar vi att du konfigurerar filter för källobjektomfång och testar attributmappningarna med några testanvändare som använder etablering på begäran innan den fullständiga synkroniseringen startas för alla användare. När du har kontrollerat att mappningarna fungerar och ger önskat resultat kan du antingen ta bort filtret eller expandera det gradvis för att inkludera fler användare.

  1. Gå till bladet Etablering och klicka på Starta etablering.

  2. Den här åtgärden startar den första synkroniseringen, vilket kan ta ett varierande antal timmar beroende på hur många användare som finns i Workday-klienten. Du kan kontrollera förloppsfältet för att spåra synkroniseringscykelns förlopp.

  3. Du kan när som helst kontrollera fliken Granskningsloggar i Azure Portal för att se vilka åtgärder etableringstjänsten har utfört. Granskningsloggarna visar alla enskilda synkroniseringshändelser som utförs av etableringstjänsten, till exempel vilka användare som läses ut från Workday och sedan läggs till eller uppdateras till Active Directory. Se avsnittet Felsökning för instruktioner om hur du granskar granskningsloggarna och åtgärdar etableringsfel.

  4. När den inledande synkroniseringen är klar skriver den en granskningssammanfattningsrapport på fliken Etablering, enligt nedan.

    Förloppsfält för etablering

Vanliga frågor och svar

Frågor om lösningsfunktioner

Hur anger lösningen lösenordet för det nya användarkontot i Active Directory när du bearbetar en ny anställning från Workday?

När den lokala etableringsagenten får en begäran om att skapa ett nytt AD-konto genererar den automatiskt ett komplext slumpmässigt lösenord som utformats för att uppfylla de krav på lösenordskomplexitet som definierats av AD-servern och anger detta för användarobjektet. Det här lösenordet loggas inte någonstans.

Stöder lösningen att skicka e-postaviseringar när etableringsåtgärder har slutförts?

Nej, det finns inte stöd för att skicka e-postaviseringar när etableringsåtgärder har slutförts i den aktuella versionen.

Cachelagrar lösningen Workday-användarprofiler i Azure AD-molnet eller på etableringsagentlagret?

Nej, lösningen behåller inte ett cacheminne med användarprofiler. Azure AD-etableringstjänsten fungerar bara som en dataprocessor, läser data från Workday och skriver till Active Directory- eller Azure AD-måldata. Mer information om användarsekretess och kvarhållning av data finns i avsnittet Hantera personliga data.

Stöder lösningen tilldelning av lokala AD-grupper till användaren?

Den här funktionen stöds inte för närvarande. Rekommenderad lösning är att distribuera ett PowerShell-skript som frågar Microsoft Graph API-slutpunkten om granskningsloggdata och använder dem för att utlösa scenarier som grupptilldelning. Det här PowerShell-skriptet kan kopplas till en schemaläggare och distribueras på samma ruta som kör etableringsagenten.

Vilka Workday-API:er använder lösningen för att fråga efter och uppdatera Workday-arbetsprofiler?

Lösningen använder för närvarande följande Workday-API:er:

  • Url-formatet för Workday Web Services-API:et som används i avsnittet Administratörsautentiseringsuppgifter avgör vilken API-version som används för Get_Workers

    • Om URL-formatet är: https:// # # # # . workday . com/ccx/service/tenantName används API v21.1.
    • Om URL-formatet är: https:// # # # # . workday . com/ccx/service/tenantName/Human _ Resources används API v21.1
    • Om URL-formatet är: https:// # # # # . workday . com/ccx/service/tenantName/Human Resources/v används den angivna _ # # . # API-versionen. (Exempel: om v34.0 har angetts används det.)
  • Funktionen för tillbakaskrivning av e-post i Workday använder Change_Work_Contact_Information (v30.0)

  • Funktionen tillbakaskrivning av workday-användarnamn använder Update_Workday_Account (v31.2)

Kan jag konfigurera min Workday HCM-klientorganisation med två Azure AD-klienter?

Ja, den här konfigurationen stöds. Här är de avancerade stegen för att konfigurera det här scenariot:

  • Distribuera etableringsagent nr 1 och registrera den med Azure AD-klient nr 1.
  • Distribuera etableringsagent nr 2 och registrera den med Azure AD-klient nr 2.
  • Baserat på de "underordnade domäner" som varje etableringsagent ska hantera konfigurerar du varje agent med domänerna. En agent kan hantera flera domäner.
  • I Azure Portal du Workday till AD-användareableringsappen i varje klientorganisation och konfigurerar den med respektive domän.

Din feedback är mycket värdefull eftersom den hjälper oss att ange riktning för framtida versioner och förbättringar. Vi tar gärna emot all feedback och uppmuntrar dig att skicka in din idé eller förbättringsförslag i feedbackforumet för Azure AD. För specifik feedback som rör Workday-integreringen väljer du kategorin SaaS-program och söker med nyckelorden Workday för att hitta befintlig feedback relaterad till Workday.

UserVoice SaaS-appar

UserVoice Workday

När du föreslår en ny idé bör du kontrollera om någon annan redan har föreslåt en liknande funktion. I så fall kan du rösta på funktionen eller förbättringsbegäran. Du kan också lämna en kommentar om ditt specifika användningsfall för att visa ditt stöd för idén och visa hur funktionen kommer att vara värdefull för dig också.

Frågor om etableringsagent

Vilken ga-version har etableringsagenten?

Se Azure AD Anslut Provisioning Agent: Versionshistorik för den senaste ga-versionen av etableringsagenten.

Hur gör jag för att du versionen av etableringsagenten?

  • Logga in på Windows där etableringsagenten är installerad.

  • Gå till Kontrollpanelen avinstallera eller ändra -> ett program

  • Leta efter den version som motsvarar posten Microsoft Azure AD Anslut etableringsagenten

    Azure-portalen

Push-uppdaterar Microsoft etableringsagenten automatiskt?

Ja, Microsoft uppdaterar automatiskt etableringsagenten om Windows-tjänsten Microsoft Azure AD Anslut Agent Updater är igång.

Kan jag installera etableringsagenten på samma server som kör Azure AD Anslut?

Ja, du kan installera etableringsagenten på samma server som kör Azure AD Anslut.

Vid tidpunkten för konfigurationen frågar etableringsagenten efter autentiseringsuppgifter för Azure AD-administratör. Lagrar agenten autentiseringsuppgifterna lokalt på servern?

Under konfigurationen frågar etableringsagenten efter autentiseringsuppgifter för Azure AD-administratör endast för att ansluta till din Azure AD-klientorganisation. Autentiseringsuppgifterna lagras inte lokalt på servern. Den behåller dock de autentiseringsuppgifter som används för att ansluta lokal Active Directory domänen i ett lokalt Windows lösenordsvalv.

Hur gör jag för att konfigurera etableringsagenten så att den använder en proxyserver för utgående HTTP-kommunikation?

Etableringsagenten stöder användning av utgående proxy. Du kan konfigurera den genom att redigera agentkonfigurationsfilen C:\Program Files\Microsoft Azure AD Anslut Provisioning Agent\AADConnectProvisioningAgent.exe.config. Lägg till följande rader i den mot slutet av filen precis före den avslutande </configuration> -taggen. Ersätt variablerna [proxy-server] och [proxy-port] proxyserverns namn och portvärden.

    <system.net>
          <defaultProxy enabled="true" useDefaultCredentials="true">
             <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
             />
         </defaultProxy>
    </system.net>

Hur gör jag för att att etableringsagenten kan kommunicera med Azure AD-klientorganisationen och att inga brandväggar blockerar portar som krävs av agenten?

Du kan också kontrollera om alla nödvändiga portar är öppna.

Kan en etableringsagent konfigureras för att etablera flera AD-domäner?

Ja, en etableringsagent kan konfigureras för att hantera flera AD-domäner så länge agenten har möjlighet att se respektive domänkontrollanter. Microsoft rekommenderar att du ställer in en grupp med tre etableringsagenter som betjänar samma uppsättning AD-domäner för att säkerställa hög tillgänglighet och tillhandahålla support för redundans.

Hur gör jag för att avregistrera domänen som är associerad med etableringsagenten?

  • Från Azure Portal hämtar du klientorganisations-ID:t för din Azure AD-klientorganisation.

  • Logga in på Windows som kör etableringsagenten.

  • Öppna PowerShell som Windows administratör.

  • Ändra till katalogen som innehåller registreringsskripten och kör följande kommandon som ersätter [ ] klient-ID-parametern med värdet för ditt klientorganisations-ID.

    cd "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\RegistrationPowershell\Modules\PSModulesFolder"
    Import-Module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\RegistrationPowershell\Modules\PSModulesFolder\AppProxyPSModule.psd1"
    Get-PublishedResources -TenantId "[tenant ID]"
    
  • I listan över agenter som visas kopierar du värdet för fältet från den resurs id vars resourceName är lika med ditt AD-domännamn.

  • Klistra in ID-värdet i det här kommandot och kör kommandot i PowerShell.

    Remove-PublishedResource -ResourceId "[resource ID]" -TenantId "[tenant ID]"
    
  • Kör guiden Agentkonfiguration igen.

  • Alla andra agenter som tidigare har tilldelats till den här domänen måste konfigureras om.

Hur gör jag för att avinstallera etableringsagenten?

  • Logga in på Windows där etableringsagenten är installerad.
  • Gå till Kontrollpanelen avinstallera eller ändra -> ett program
  • Avinstallera följande program:
    • Microsoft Azure AD Anslut etableringsagent
    • Microsoft Azure AD Anslut Agent Updater
    • Microsoft Azure AD Anslut-agentpaket för etablering

Workday till AD-attributmappning och konfigurationsfrågor

Hur gör jag för att eller exportera en fungerande kopia av workday-etableringsattributmappning och -schema?

Du kan använda Microsoft Graph API för att exportera konfigurationen av Workday-användareablering. Mer information finns i stegen i avsnittet Exportera och importera konfigurationen av Workday-användaretableringsattributmappning.

Jag har anpassade attribut i Workday och Active Directory. Hur gör jag för att du konfigurera lösningen så att den fungerar med mina anpassade attribut?

Lösningen stöder anpassade Workday- och Active Directory-attribut. Om du vill lägga till dina anpassade attribut i mappningsschemat öppnar du bladet Attributmappning och rullar ned för att expandera avsnittet Visa avancerade alternativ.

Redigera attributlista

Om du vill lägga till dina anpassade Workday-attribut väljer du alternativet Redigera attributlista för Workday och lägger till dina anpassade AD-attribut genom att välja alternativet Redigera attributlista för Lokal Active Directory .

Se även:

Hur gör jag för att du konfigurera lösningen att endast uppdatera attribut i AD baserat på Workday-ändringar och inte skapa några nya AD-konton?

Den här konfigurationen kan uppnås genom att ange målobjektåtgärder på bladet Attributmappningar enligt nedan:

Uppdateringsåtgärd

Markera kryssrutan "Uppdatera" för att endast uppdatera åtgärder som ska flöda från Workday till AD.

Kan jag etablera användarens foto från Workday till Active Directory?

Lösningen stöder för närvarande inte inställning av binära attribut som thumbnailPhoto och jpegPhoto i Active Directory.

  • Gå till bladet "Etablering" i workday-etableringsappen.

  • Klicka på attributmappningarna

  • Under Mappningar väljer du Synkronisera Workday-arbetare till lokal Active Directory (eller Synkronisera Workday-arbetare till Azure AD).

  • På sidan Attributmappningar bläddrar du nedåt och markerar kryssrutan "Visa avancerade alternativ". Klicka på Redigera attributlista för Workday

  • Leta upp attributet "Mobile" på bladet som öppnas och klicka på raden så att du kan redigera GDPR för API-uttryck

  • Ersätt API-uttrycket med följande nya uttryck, som endast hämtar arbetsmobilnumret om "Offentlig användningsflagga" har angetts till "True" i Workday.

     wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Contact_Data/wd:Phone_Data[translate(string(wd:Phone_Device_Type_Reference/@wd:Descriptor),'abcdefghijklmnopqrstuvwxyz','ABCDEFGHIJKLMNOPQRSTUVWXYZ')='MOBILE' and translate(string(wd:Usage_Data/wd:Type_Data/wd:Type_Reference/@wd:Descriptor),'abcdefghijklmnopqrstuvwxyz','ABCDEFGHIJKLMNOPQRSTUVWXYZ')='WORK' and string(wd:Usage_Data/@wd:Public)='1']/@wd:Formatted_Phone
    
  • Spara attributlistan.

  • Spara attributmappningen.

  • Rensa aktuellt tillstånd och starta om den fullständiga synkroniseringen.

Hur gör jag för att visningsnamn i AD baserat på användarens attribut för avdelning/land/ort och hantera regionala avvikelser?

Det är ett vanligt krav att konfigurera attributet displayName i AD så att det även ger information om användarens avdelning och land/region. Om John Smith till exempel arbetar på marknadsföringsavdelningen i USA kanske du vill att hans displayName ska visas som Smith, John (Marketing-US).

Så här kan du hantera sådana krav för att konstruera CN eller displayName för att inkludera attribut som företag, affärsenhet, ort eller land/region.

  • Varje Workday-attribut hämtas med hjälp av ett underliggande XPATH API-uttryck, som kan konfigureras i Attributmappning -> Advanced Section -> Redigera attributlista för Workday. Här är XPATH API-standarduttrycket för Workday PreferredFirstName, PreferredLastName, Company och AttributesOrganization.

    Workday-attribut API XPATH-uttryck
    PreferredFirstName wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Name_Data/wd:Preferred_Name_Data/wd:Name_Detail_Data/wd:First_Name/text()
    PreferredLastName wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Name_Data/wd:Preferred_Name_Data/wd:Name_Detail_Data/wd:Last_Name/text()
    Företag wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data[wd:Organization_Data/wd:Organization_Type_Reference/wd:ID[ @wd:type ='Organization_Type_ID']='Company']/wd:Organization_Reference/@wd:Descriptor
    IoT -organisation wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data/wd:Organization_Data[wd:Organization_Type_Reference/wd:ID[ @wd:type ='Organization_Type_ID']='Intr']/wd:Organization_Name/text()

    Bekräfta med Workday-teamet att API-uttrycket ovan är giltigt för din Workday-klientkonfiguration. Om det behövs kan du redigera dem enligt beskrivningen i avsnittet Anpassa listan över Workday-användarattribut.

  • På samma sätt hämtas land/region-informationen som finns i Workday med hjälp av följande XPATH: wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference

    Det finns 5 lands-/regionrelaterade attribut som är tillgängliga i avsnittet med Workday-attributlistan.

    Workday-attribut API XPATH-uttryck
    CountryReference wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/wd:ID[ @wd:type ='ISO_3166-1_Alpha-3_Code']/text()
    CountryReferenceFriendly wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/@wd:Descriptor
    CountryReferenceNumeric wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/wd:ID[ @wd:type ='ISO_3166-1_Numeric-3_Code']/text()
    CountryReferenceTwoLetter wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/wd:ID[ @wd:type ='ISO_3166-1_Alpha-2_Code']/text()
    CountryRegionReference wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Region_Reference/@wd:Descriptor

    Bekräfta med Workday-teamet att API-uttrycken ovan är giltiga för din Workday-klientkonfiguration. Om det behövs kan du redigera dem enligt beskrivningen i avsnittet Anpassa listan över Workday-användarattribut.

  • Om du vill skapa rätt attributmappningsuttryck identifierar du vilket Workday-attribut "auktoritativt" som representerar användarens förnamn, efternamn, land/region och avdelning. Anta att attributen är PreferredFirstName, PreferredLastName, CountryReferenceTwoLetter respektive PreferredOrganization. Du kan använda det här för att skapa ett uttryck för ad displayName-attributet på följande sätt för att hämta ett visningsnamn som Smith, John (Marketing-US).

     Append(Join(", ",[PreferredLastName],[PreferredFirstName]), Join(""," (",[SupervisoryOrganization],"-",[CountryReferenceTwoLetter],")"))
    

    När du har rätt uttryck redigerar du tabellen Attributmappningar och ändrar attributmappningen displayName enligt nedan:  DisplayName-mappning

  • Om vi utökar exemplet ovan kan vi anta att du vill konvertera ortnamn som kommer från Workday till shorthand-värden och sedan använda det för att skapa visningsnamn som Smith, John (CHI) eller Doe, Jane (NYC), och sedan kan det här resultatet uppnås med hjälp av ett Switch-uttryck med attributet Workday Attributet Förbyt som determinant variabel.

    Switch
    (
      [Municipality],
      Join(", ", [PreferredLastName], [PreferredFirstName]),  
           "Chicago", Append(Join(", ",[PreferredLastName], [PreferredFirstName]), "(CHI)"),
           "New York", Append(Join(", ",[PreferredLastName], [PreferredFirstName]), "(NYC)"),
           "Phoenix", Append(Join(", ",[PreferredLastName], [PreferredFirstName]), "(PHX)")
    )
    

    Se även:

Hur kan jag använda SelectUniqueValue för att generera unika värden för samAccountName-attribut?

Anta att du vill generera unika värden för samAccountName-attributet med en kombination av attributen FirstName och LastName från Workday. Nedan visas ett uttryck som du kan börja med:

SelectUniqueValue(
    Replace(Mid(Replace(NormalizeDiacritics(StripSpaces(Join("",  Mid([FirstName],1,1), [LastName]))), , "([\\/\\\\\\[\\]\\:\\;\\|\\=\\,\\+\\*\\?\\<\\>])", , "", , ), 1, 20), , "(\\.)*$", , "", , ),
    Replace(Mid(Replace(NormalizeDiacritics(StripSpaces(Join("",  Mid([FirstName],1,2), [LastName]))), , "([\\/\\\\\\[\\]\\:\\;\\|\\=\\,\\+\\*\\?\\<\\>])", , "", , ), 1, 20), , "(\\.)*$", , "", , ),
    Replace(Mid(Replace(NormalizeDiacritics(StripSpaces(Join("",  Mid([FirstName],1,3), [LastName]))), , "([\\/\\\\\\[\\]\\:\\;\\|\\=\\,\\+\\*\\?\\<\\>])", , "", , ), 1, 20), , "(\\.)*$", , "", , )
)

Så här fungerar uttrycket ovan: Om användaren är John Smith försöker den först generera JSmith. Om JSmith redan finns genererar den JoSmith, om sådan finns, genereras JohSmith. Uttrycket säkerställer också att värdet som genereras uppfyller längdbegränsningen och specialteckenbegränsningen som är associerad med samAccountName.

Se även:

Hur gör jag för att du ta bort tecken med diakritiska tecken och konvertera dem till vanliga engelska alfabet?

Använd funktionen NormalizeDiacritics för att ta bort specialtecken i användarens förnamn och efternamn, samtidigt som användarens e-postadress eller CN-värde skapas.

Felsökningstips

Det här avsnittet innehåller specifik vägledning om hur du felsöker etableringsproblem med workday-integreringen med hjälp av Azure AD-granskningsloggar och Windows Server Loggboken loggar. Den bygger vidare på de allmänna felsökningsstegen och begreppen som finns i Självstudie: Rapportering om automatisk användarkontoetablering

Det här avsnittet beskriver följande aspekter av felsökning:

Konfigurera etableringsagenten för att generera Loggboken loggar

  1. Logga in på Windows Server-datorn där etableringsagenten distribueras

  2. Stoppa etableringsagenten Microsoft Azure AD Anslut tjänst.

  3. Skapa en kopia av den ursprungliga konfigurationsfilen: C:\Program Files\Microsoft Azure AD Anslut Provisioning Agent\AADConnectProvisioningAgent.exe.config.

  4. Ersätt det <system.diagnostics> befintliga avsnittet med följande.

    • Lyssnarkonfigurations-etw skickar meddelanden till EventViewer-loggarna
    • Konfigurationstexten för lyssnarenWriterListener skickar spårningsmeddelanden till filen ProvAgentTrace.log. Avkommentera raderna som är relaterade till textWriterListener endast för avancerad felsökning.
      <system.diagnostics>
          <sources>
          <source name="AAD Connect Provisioning Agent">
              <listeners>
              <add name="console"/>
              <add name="etw"/>
              <!-- <add name="textWriterListener"/> -->
              </listeners>
          </source>
          </sources>
          <sharedListeners>
          <add name="console" type="System.Diagnostics.ConsoleTraceListener" initializeData="false"/>
          <add name="etw" type="System.Diagnostics.EventLogTraceListener" initializeData="Azure AD Connect Provisioning Agent">
              <filter type="System.Diagnostics.EventTypeFilter" initializeData="All"/>
          </add>
          <!-- <add name="textWriterListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:/ProgramData/Microsoft/Azure AD Connect Provisioning Agent/Trace/ProvAgentTrace.log"/> -->
          </sharedListeners>
      </system.diagnostics>
    
    
  5. Starta tjänsten Microsoft Azure AD Anslut Etableringsagent.

Konfigurera Windows Loggboken för agentfelsökning

  1. Logga in på Windows Server-datorn där etableringsagenten distribueras

  2. Öppna Windows Server Loggboken-skrivbordsappen.

  3. Välj Windows Logs > Application.

  4. Använd den aktuella filterloggen... alternativet för att visa alla händelser som loggats under källan Azure AD Anslut Provisioning Agent och exkludera händelser med händelse-ID "5" genom att ange filtret "-5" enligt nedan.

    Anteckning

    Händelse-ID 5 samlar in agentens bootstrap-meddelanden till Azure AD-molntjänsten och därför filtrerar vi det när vi analyserar loggfilerna.

    Windows Loggboken

  5. Klicka på OK och sortera resultatvyn efter kolumnen Datum och tid.

Konfigurera Azure Portal för felsökning av tjänsten

  1. Starta Azure Portaloch gå till avsnittet Granskningsloggar i Workday-etableringsprogrammet.

  2. Använd knappen Kolumner på sidan Granskningsloggar om du bara vill visa följande kolumner i vyn (Datum, Aktivitet, Status, Statusorsak). Den här konfigurationen säkerställer att du bara fokuserar på data som är relevanta för felsökning.

    Granskningsloggkolumner

  3. Använd frågeparametrarna Mål och Datumintervall för att filtrera vyn.

    • Ange frågeparametern Mål till "Arbets-ID" eller "Medarbetar-ID" för Workday-arbetsobjektet.
    • Ange datumintervallet till en lämplig tidsperiod under vilken du vill undersöka fel eller problem med etableringen.

    Filter för granskningsloggar

Förstå loggar för åtgärder för att skapa AD-användarkonto

När en ny anställning i Workday identifieras (t.ex. med medarbetar-ID 21023) försöker Azure AD-etableringstjänsten skapa ett nytt AD-användarkonto för arbetaren och skapar i processen 4 granskningsloggposter enligt beskrivningen nedan:

Skapa ops för granskningslogg

När du klickar på någon av granskningsloggposterna öppnas sidan Aktivitetsinformation. Det här är vad sidan Aktivitetsinformation visar för varje loggposttyp.

  • Workday-importpost: Den här loggposten visar arbetsinformationen som hämtats från Workday. Använd informationen i avsnittet Ytterligare information i loggposten för att felsöka problem med att hämta data från Workday. En exempelpost visas nedan tillsammans med pekare om hur du tolkar varje fält.

    ErrorCode : None  // Use the error code captured here to troubleshoot Workday issues
    EventName : EntryImportAdd // For full sync, value is "EntryImportAdd" and for delta sync, value is "EntryImport"
    JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID (usually the Worker ID or Employee ID field)
    SourceAnchor : a071861412de4c2486eb10e5ae0834c3 // set to the WorkdayID (WID) associated with the record
    
  • AD-importpost: Den här loggposten visar information om kontot som hämtats från AD. Eftersom det inte finns något AD-konto under det första användarskapandet visar aktivitetsstatusorsaken att inget konto med attributvärdet Matchande ID hittades i Active Directory. Använd informationen i avsnittet Ytterligare information i loggposten för att felsöka problem med att hämta data från Workday. En exempelpost visas nedan tillsammans med pekare om hur du tolkar varje fält.

    ErrorCode : None // Use the error code captured here to troubleshoot Workday issues
    EventName : EntryImportObjectNotFound // Implies that object was not found in AD
    JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID
    

    Om du vill hitta loggposter för etableringsagenten som motsvarar den här AD-importåtgärden öppnar Windows Loggboken loggarna och använder Find... menyalternativet för att hitta loggposter som innehåller attributvärdet Matchande ID/Koppla egenskap (i det här fallet 21023).

    Hitta

    Leta efter posten med Händelse-ID = 9, vilket ger dig det LDAP-sökfilter som används av agenten för att hämta AD-kontot. Du kan kontrollera om det här är rätt sökfilter för att hämta unika användarposter.

    LDAP-sökning

    Posten som följer den direkt med händelse-ID = 2 samlar in resultatet av sökåtgärden och om den returnerade några resultat.

    LDAP-resultat

  • Åtgärdspost för synkroniseringsregel: Den här loggposten visar resultatet av attributmappningsregler och konfigurerade omfångsfilter tillsammans med den etableringsåtgärd som ska vidtas för att bearbeta den inkommande Workday-händelsen. Använd informationen i avsnittet Ytterligare information i loggposten för att felsöka problem med synkroniseringsåtgärden. En exempelpost visas nedan tillsammans med pekare om hur du tolkar varje fält.

    ErrorCode : None // Use the error code captured here to troubleshoot sync issues
    EventName : EntrySynchronizationAdd // Implies that the object will be added
    JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID
    SourceAnchor : a071861412de4c2486eb10e5ae0834c3 // set to the WorkdayID (WID) associated with the profile in Workday
    

    Om det finns problem med dina attributmappningsuttryck eller om inkommande Workday-data har problem (till exempel tomt eller null-värde för obligatoriska attribut) kommer du att se ett fel i det här skedet med ErrorCode som innehåller information om felet.

  • AD-exportpost: Den här loggposten visar resultatet av skapandeåtgärden för AD-kontot tillsammans med de attributvärden som har angetts i processen. Använd informationen i avsnittet Ytterligare information i loggposten för att felsöka problem med konto create-åtgärden. En exempelpost visas nedan tillsammans med pekare om hur du tolkar varje fält. I avsnittet "Ytterligare information" är "EventName" inställt på "EntryExportAdd", "JoiningProperty" är inställt på värdet för attributet Matchande ID, "SourceAnchor" är inställt på WorkdayID (WID) som är associerat med posten och "TargetAnchor" anges till värdet för AD-attributet "ObjectGuid" för den nyligen skapade användaren.

    ErrorCode : None // Use the error code captured here to troubleshoot AD account creation issues
    EventName : EntryExportAdd // Implies that object will be created
    JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID
    SourceAnchor : a071861412de4c2486eb10e5ae0834c3 // set to the WorkdayID (WID) associated with the profile in Workday
    TargetAnchor : 83f0156c-3222-407e-939c-56677831d525 // set to the value of the AD "objectGuid" attribute of the new user
    

    Om du vill hitta loggposter för etableringsagenten som motsvarar den här AD-exportåtgärden öppnar Windows Loggboken loggarna och använder find... menyalternativet för att hitta loggposter som innehåller attributvärdet Matchande ID/Koppla egenskap (i det här fallet 21023).

    Leta efter en HTTP POST-post som motsvarar tidsstämpeln för exportåtgärden med händelse-ID = 2. Den här posten innehåller de attributvärden som skickas av etableringstjänsten till etableringsagenten.

    Skärmbild som visar HTTP POST-posten i loggen &quot;Etableringsagent&quot;.

    Omedelbart efter ovanstående händelse bör det finnas en annan händelse som samlar in svaret från åtgärden skapa AD-konto. Den här händelsen returnerar det nya objectGuid som skapades i AD och anges som attributet TargetAnchor i etableringstjänsten.

    Skärmbild som visar loggen &quot;Etableringsagent&quot; med objectGuid som skapades i AD markerat.

Förstå loggar för manager-uppdateringsåtgärder

Manager-attributet är ett referensattribut i AD. Etableringstjänsten anger inte attributet manager som en del av åtgärden för att skapa användare. I stället anges manager-attributet som en del av en uppdateringsåtgärd när AD-kontot har skapats för användaren. Om vi utökar exemplet ovan kan vi anta att en nyanställda med medarbetar-ID:t "21451" har aktiverats i Workday och att den nya anställningens chef (21023) redan har ett AD-konto. I det här scenariot visas 5 poster om du söker i granskningsloggarna efter användare 21451.

Manager-uppdatering

De första 4 posterna är som de som vi utforskade som en del av åtgärden för att skapa användare. Den femte posten är exporten som är associerad med manager-attributuppdateringen. Loggposten visar resultatet av uppdateringsåtgärden för AD-kontohanteraren, som utförs med hjälp av chefens objectGuid-attribut.

// Modified Properties
Name : manager
New Value : "83f0156c-3222-407e-939c-56677831d525" // objectGuid of the user 21023

// Additional Details
ErrorCode : None // Use the error code captured here to troubleshoot AD account creation issues
EventName : EntryExportUpdate // Implies that object will be created
JoiningProperty : 21451 // Value of the Workday attribute that serves as the Matching ID
SourceAnchor : 9603bf594b9901693f307815bf21870a // WorkdayID of the user
TargetAnchor : 43b668e7-1d73-401c-a00a-fed14d31a1a8 // objectGuid of the user 21451

Lösa vanliga fel

Det här avsnittet beskriver vanliga fel med Workday-användareablering och hur du löser det. Felen grupperas på följande sätt:

Etableringsagentfel

# Felscenario Sannolika orsaker Rekommenderad lösning
1. Fel vid installation av etableringsagenten med felmeddelande: Det gick inte att starta tjänsten "Microsoft Azure AD Anslut Provisioning Agent" (AADConnectProvisioningAgent). Kontrollera att du har tillräcklig behörighet för att starta systemet. Det här felet visas vanligtvis om du försöker installera etableringsagenten på en domänkontrollant och grupprincipen förhindrar att tjänsten startar. Det visas också om du har en tidigare version av agenten som körs och du inte har avinstallerat den innan du startar en ny installation. Installera etableringsagenten på en icke-DC-server. Se till att tidigare versioner av agenten avinstalleras innan du installerar den nya agenten.
2. Tjänsten Windows "Microsoft Azure AD Anslut Etableringsagent" är i starttillstånd och växlar inte till tillståndet Körs. Som en del av installationen skapar agentguiden ett lokalt konto (NT Service \ AADConnectProvisioningAgent) på servern och det är det inloggningskonto som används för att starta tjänsten. Om en säkerhetsprincip på din Windows förhindrar lokala konton från att köra tjänsterna får du det här felet. Öppna tjänstekonsolen. Högerklicka på den Windows tjänsten "Microsoft Azure AD Anslut Provisioning Agent" och på inloggningsfliken anger du kontot för en domänadministratör som ska köra tjänsten. Starta om tjänsten.
3. När du konfigurerar etableringsagenten med AD-domänen i steget Anslut Active Directory tar det lång tid att läsa in AD-schemat och så småningom tar det för lång tid att läsa in AD-schemat. Det här felet visas vanligtvis om det inte går att kontakta AD-domänkontrollantservern på grund av problem med brandväggen. På den Anslut Active Directory-guideskärmen, medan autentiseringsuppgifterna för din AD-domän, finns det ett alternativ med namnet Välj domänkontrollantprioritet. Använd det här alternativet för att välja en domänkontrollant som finns på samma plats som agentservern och se till att det inte finns några brandväggsregler som blockerar kommunikationen.

Anslutningsfel

Om etableringstjänsten inte kan ansluta till Workday eller Active Directory kan det leda till att etableringen förs i karantän. Använd tabellen nedan för att felsöka anslutningsproblem.

# Felscenario Sannolika orsaker Rekommenderad lösning
1. När du klickar på Testa anslutning visas felmeddelandet: Det uppstod ett fel när du skulle ansluta till Active Directory. Kontrollera att den lokala etableringsagenten körs och att den är konfigurerad med rätt Active Directory-domän. Det här felet visas vanligtvis om etableringsagenten inte körs eller om det finns en brandvägg som blockerar kommunikationen mellan Azure AD och etableringsagenten. Du kan också se det här felet om domänen inte har konfigurerats i agentguiden. Öppna tjänstkonsolen på Windows för att bekräfta att agenten körs. Öppna guiden för etableringsagenten och bekräfta att rätt domän har registrerats med agenten.
2. Etableringsjobbet förs i karantäntillstånd under helgerna (fre-lör) och vi får ett e-postmeddelande om att det har uppstått ett fel med synkroniseringen. En av de vanligaste orsakerna till felet är planerade Workday-driftstopp. Om du använder en klient för implementering av Workday ska du notera att Workday har schemalagt driftstopp för sina implementeringsklienter under helger (vanligtvis från fredag kväll till lördag morgon). Under den perioden kan Workday-etableringsappar försättas i karantäntillstånd eftersom det inte går att ansluta till Workday. Workday återfår sitt normala tillstånd när Workday-implementeringsklienten är online igen. I sällsynta fall kan du också se det här felet om lösenordet för integreringssystemanvändaren har ändrats på grund av uppdatering av klienten eller om kontot är låst eller har upphört att gälla. Kontakta din Workday-administratör eller integreringspartner för att höra efter när Workday schemalägger driftstopp. Sedan kan du ignorera varningsmeddelanden under driftstoppsperioden och få en bekräftelse om tillgänglighet när Workday-instansen är online igen.

Fel vid skapande av AD-användarkonto

# Felscenario Sannolika orsaker Rekommenderad lösning
1. Exportåtgärdsfel i granskningsloggen med meddelandet Error: OperationsError-SvcErr: Ett åtgärdsfel inträffade. Ingen överordnad referens har konfigurerats för katalogtjänsten. Katalogtjänsten kan därför inte utfärda hänvisningar till objekt utanför den här skogen. Det här felet visas vanligtvis om Active Directory Container OU inte har angetts korrekt eller om det finns problem med uttrycksmappningen som används för parentDistinguishedName. Kontrollera om det finns skrivfel i Active Directory Container OU-parametern. Om du använder parentDistinguishedName i attributmappningen kontrollerar du att det alltid utvärderas till en känd container i AD-domänen. Kontrollera exporthändelsen i granskningsloggarna för att se det genererade värdet.
2. Exportåtgärdsfel i granskningsloggen med felkod: SystemForCrossDomainIdentityManagementBadResponse och meddelandet Error: ConstraintViolation-AtrErr: Ett värde i begäran är ogiltigt. Ett värde för attributet låg inte inom det godkända värdeintervallet. \nfelinformation: CONSTRAINT_ATT_TYPE – företag. Även om det här felet är specifikt för företagsattributet kan det här felet även visas för andra attribut som CN. Det här felet visas på grund av ad-framtvingad schemabegränsning. Som standard har attribut som företag och CN i AD en övre gräns på 64 tecken. Om värdet som kommer från Workday är mer än 64 tecken visas det här felmeddelandet. Kontrollera exporthändelsen i granskningsloggarna för att se värdet för attributet som rapporteras i felmeddelandet. Överväg att trunkera värdet som kommer från Workday med funktionen Mid eller ändra mappningarna till ett AD-attribut som inte har liknande längdbegränsningar.

Fel vid uppdatering av AD-användarkonto

Under uppdateringsprocessen för AD-användarkontot läser etableringstjänsten information från både Workday och AD, kör attributmappningsregler och avgör om någon ändring behöver gälla. Därför utlöses en uppdateringshändelse. Om något av dessa steg påträffar ett fel loggas det i granskningsloggarna. Använd tabellen nedan för att felsöka vanliga uppdateringsfel.

# Felscenario Sannolika orsaker Rekommenderad lösning
1. Fel i synkroniseringsregeln i granskningsloggen med meddelandet EventName = EntrySynchronizationError och ErrorCode = EndpointUnavailable. Det här felet visas om etableringstjänsten inte kan hämta användarprofildata från Active Directory på grund av ett bearbetningsfel som uppstått av den lokala etableringsagenten. Kontrollera etableringsagentens Loggboken efter felhändelser som indikerar problem med läsåtgärden (filtrera efter händelse-ID nr 2).
2. Manager-attributet i AD uppdateras inte för vissa användare i AD. Den troligaste orsaken till det här felet är om du använder omfångsregler och användarens chef inte ingår i omfånget. Du kan också få det här problemet om chefens matchande ID-attribut (t.ex. EmployeeID) inte hittas i AD-måldomänen eller inte har angetts till rätt värde. Granska omfångsfiltret och lägg till ansvarig användare i omfånget. Kontrollera chefens profil i AD för att se till att det finns ett värde för det matchande ID-attributet.

Hantera din konfiguration

I det här avsnittet beskrivs hur du kan utöka, anpassa och hantera din Workday-drivna konfiguration för användareablering. Den tar upp följande ämnen:

Anpassa listan över Workday-användarattribut

Workday-etableringsapparna för Active Directory och Azure AD innehåller båda en standardlista med Workday-användarattribut som du kan välja mellan. Dessa listor är dock inte heltäckande. Workday stöder många hundra möjliga användarattribut, som antingen kan vara standard eller unika för din Workday-klientorganisation.

Azure AD-etableringstjänsten stöder möjligheten att anpassa ditt list- eller Workday-attribut så att det inkluderar alla attribut som exponeras i Get_Workers för PERSONAL-API:et.

Om du vill göra den här ändringen måste du använda Workday Studio för att extrahera de XPath-uttryck som representerar de attribut som du vill använda och sedan lägga till dem i etableringskonfigurationen med hjälp av den avancerade attributredigeraren i Azure Portal.

Så här hämtar du ett XPath-uttryck för ett Workday-användarattribut:

  1. Ladda ned och installera Workday Studio. Du behöver ett Workday Community-konto för att få åtkomst till installationsprogrammet.

  2. Ladda ned Workday Human_Resources WSDL-filen som är specifik för DEN WWS API-version som du planerar att använda från Workday Web Services-katalogen

  3. Starta Workday Studio.

  4. I kommandofältet väljer du alternativet Workday > Test Web Service in Tester (Testa webbtjänst i testare).

  5. Välj Extern och välj den WSDL Human_Resources fil som du laddade ned i steg 2.

    Skärmbild som visar filen "Human_Resources" öppen i Workday Studio.

  6. Ange fältet Plats till , men ersätt "IMPL-CC" med din faktiska https://IMPL-CC.workday.com/ccx/service/TENANT/Human_Resources instanstyp och "TENANT" med ditt verkliga klientnamn.

  7. Ange Åtgärd till Get_Workers

  8. Klicka på den lilla konfigurationslänken under fönstret Begäran/svar för att ange dina autentiseringsuppgifter för Workday. Kontrollera Autentisering och ange sedan användarnamnet och lösenordet för ditt Workday-integrationssystemkonto. Se till att formatera användarnamnet som namnklient och låt alternativet @ WS-Security UsernameToken vara markerat. Skärmbild som visar fliken "Säkerhet" med användarnamn och lösenord angivna och token för WS-Security-användarnamn valt.

  9. Välj OK.

  10. I fönstret Begäran klistrar du in XML-filen nedan. Ange Employee_ID till medarbetar-ID:t för en verklig användare i workday-klienten. Ange wd:version till den version av WWS som du planerar att använda. Välj en användare som har attributet ifylld som du vill extrahera.

    <?xml version="1.0" encoding="UTF-8"?>
    <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="https://www.w3.org/2001/XMLSchema">
      <env:Body>
        <wd:Get_Workers_Request xmlns:wd="urn:com.workday/bsvc" wd:version="v21.1">
          <wd:Request_References wd:Skip_Non_Existing_Instances="true">
            <wd:Worker_Reference>
              <wd:ID wd:type="Employee_ID">21008</wd:ID>
            </wd:Worker_Reference>
          </wd:Request_References>
          <wd:Response_Group>
            <wd:Include_Reference>true</wd:Include_Reference>
            <wd:Include_Personal_Information>true</wd:Include_Personal_Information>
            <wd:Include_Employment_Information>true</wd:Include_Employment_Information>
            <wd:Include_Management_Chain_Data>true</wd:Include_Management_Chain_Data>
            <wd:Include_Organizations>true</wd:Include_Organizations>
            <wd:Include_Reference>true</wd:Include_Reference>
            <wd:Include_Transaction_Log_Data>true</wd:Include_Transaction_Log_Data>
            <wd:Include_Photo>true</wd:Include_Photo>
            <wd:Include_User_Account>true</wd:Include_User_Account>
          <wd:Include_Roles>true</wd:Include_Roles>
          </wd:Response_Group>
        </wd:Get_Workers_Request>
      </env:Body>
    </env:Envelope>
    
  11. Klicka på skicka begäran (grön pil) för att köra kommandot. Om det lyckas bör svaret visas i fönstret Svar. Kontrollera svaret för att se till att det innehåller data för det användar-ID som du angav och inte ett fel.

  12. Om det lyckas kopierar du XML-filen från fönstret Svar och sparar den som en XML-fil.

  13. I kommandofältet i Workday Studio väljer du Arkiv > Öppna fil... och öppnar XML-filen som du sparade. Den här åtgärden öppnar filen i XML-redigeraren i Workday Studio.

    Skärmbild av en X M L-fil som är öppen i Workday Studio X M L-redigeraren.

  14. I filträdet navigerar du genom /env: Envelope > env: Body > wd:Get_Workers_Response > wd:Response_Data > wd: Worker för att hitta användarens data.

  15. Under wd: Worker hittar du attributet som du vill lägga till och väljer det.

  16. Kopiera XPath-uttrycket för det valda attributet från fältet Dokumentsökväg.

  17. Ta bort prefixet /env:Envelope/env:Body/wd:Get_Workers_Response/wd:Response_Data/ från det kopierade uttrycket.

  18. Om det sista objektet i det kopierade uttrycket är en nod (exempel: "/wd: Birth_Date") lägger du till /text() i slutet av uttrycket. Detta är inte nödvändigt om det sista objektet är ett attribut (exempel: " /@wd: type").

  19. Resultatet bör se ut ungefär så wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Birth_Date/text() här: . Det här värdet kopieras till Azure Portal.

Så här lägger du till ditt anpassade Workday-användarattribut i etableringskonfigurationen:

  1. Starta Azure Portaloch gå till avsnittet Etablering i workday-etableringsprogrammet, enligt beskrivningen tidigare i den här självstudien.

  2. Ange Etableringsstatus till Av och välj Spara. Det här steget hjälper dig att se till att ändringarna endast börjar gälla när du är klar.

  3. Under Mappningar väljer du Synkronisera Workday Workers till Lokal Active Directory (eller Synkronisera Workday-arbetare till Azure AD).

  4. Rulla längst ned på nästa skärm och välj Visa avancerade alternativ.

  5. Välj Redigera attributlista för Workday.

    Skärmbild som visar sidan "Workday till Azure A D-användareablering – etablering" med åtgärden "Redigera attributlista för Workday" markerad.

  6. Rulla längst ned i attributlistan där indatafälten finns.

  7. I Namn anger du ett visningsnamn för ditt attribut.

  8. För Typ väljer du den typ som motsvarar ditt attribut (Sträng är vanligast).

  9. För API-uttryck anger du det XPath-uttryck som du kopierade från Workday Studio. Exempel: wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Birth_Date/text()

  10. Välj Lägg till attribut.

    Workday Studio

  11. Välj Spara ovan och sedan Ja i dialogrutan. Stäng Attribute-Mapping om den fortfarande är öppen.

  12. Gå tillbaka till huvudfliken Etablering och välj Synkronisera Workday Workers till Lokal Active Directory (eller Synkronisera arbetare till Azure AD) igen.

  13. Välj Lägg till ny mappning.

  14. Ditt nya attribut bör nu visas i listan Källattribut.

  15. Lägg till en mappning för det nya attributet efter behov.

  16. När du är klar ska du komma ihåg att ställa in Etableringsstatus tillbaka till och spara.

Exportera och importera konfigurationen

Se artikeln Exportera och importera konfiguration av etablering

Hantera personliga data

Workday-etableringslösningen för Active Directory kräver att en etableringsagent installeras på en lokal Windows-server, och den här agenten skapar loggar i händelseloggen för Windows som kan innehålla personliga data beroende på din Workday till AD-attributmappningar. För att uppfylla användarnas sekretesskrav kan du se till att inga data bevaras i händelseloggarna längre än 48 timmar genom att konfigurera en Windows schemalagd aktivitet för att rensa händelseloggen.

Azure AD-etableringstjänsten ingår i dataprocessorkategorin för GDPR-klassificering. Som en dataprocessorpipeline tillhandahåller tjänsten databehandlingstjänster till viktiga partner och slutanvändare. Azure AD-etableringstjänsten genererar inte användardata och har ingen oberoende kontroll över vilka personuppgifter som samlas in och hur de används. Datahämtning, aggregering, analys och rapportering i Azure AD-etableringstjänsten baseras på befintliga företagsdata.

Anteckning

Information om hur du visar eller tar bort person uppgifter finns i Microsofts vägledning om Windows data subject-begäranden för GDPR -webbplatsen. Allmän information om GDPR finns i avsnittet GDPR i avsnittet Microsoft säkerhets Center och avsnittet GDPR i service Trust-portalen.

När det gäller databevarande genererar inte Azure AD-etableringstjänsten rapporter, utför analyser eller ger insikter utöver 30 dagar. Därför lagrar, bearbetar eller behåller Inte Azure AD-etableringstjänsten några data längre än 30 dagar. Den här designen följer GDPR-reglerna, Microsofts regler för sekretessefterlevnad och Azure AD-principer för datalagring.

Nästa steg