Cloud HR-Identitymanagement

Es gibt immer mehr Personalverwaltungs-Lösungen in der Cloud. In Verbindung mit einem lokalen Active Directory und insbesondere AzureAD kann sich ein Administrator das Leben einfacher machen, indem die Daten von HR zugleich zur Verwaltung der Anmeldekonten genutzt werden. Diese Seite beschreibt die verschiedenen Ansätze mit Links zu verschiedenen Produkten.

Anknüpfungspunkte

Große Firmen nutzen schon lande entsprechend Lösungen, um die Anmeldekonten von Benutzern nicht mehr manuell zu pflegen, sondern durch HR direkt oder indirekt pflegen zu lassen. Entweder hat die HR-Software direkt die AD-Konten mit verwaltet oder es wurde ein DirSync, z.B.: mit FIM, aufgesetzt, der einen richtigen Verzeichnisabgleich durchgeführt hat oder eine Provisioning-Lösung wie z.B. Adaxes wurde als Hilfs angesprochen. Natürlich gibt es auch ungezählte selbst gebaute Lösungen per VBScript oder PowerShell, die aber selten auch publiziert wurden.

Mit der HR-Verwaltung aus der Cloud und AzureAD in der Cloud eröffnen sich aber ganz neue Wege, für Hersteller und Kunden, wenn Sie OnPremise-Umgebungen hinten anstellen können. Dies ist gerade für kleine Firmen oder Startups interessant, die quasi ohne lokales AD unterwegs sind. Drei Faktoren finde ich hier bei Cloud-HR-Systemen wichtig:

  • Authentifizierung
    Die HR-Mitarbeiter und vielleicht auch die Anwender selbst möchten natürlich auf das HR-System zugreifen. Firmen ohne AzureAD werden dazu im HR-System selbst die Benutzer mit Kennworten anlegen aber sobald es ein AzureAD gibt, bietet es sich ja an, die Anmeldung an das AzureAD über Federation zu koppeln. Die Anwender müssen sich nur noch ihre AzureAD-Anmeldung merken und können sogar per SingleSignOn auf das HR-System zugreifen und der Administrator kann in seinem AzureAD auch ConditionalAccess/2FA konfigurieren.
    Wer ein lokales AD hat, sollte sich auch ein AzureAD zulegen, um keine lokalen ADFS-Server betreiben zu müssen. AzureAD mit ADSync ist sogar kostenfrei nutzbar, wenn Sie keine sonstigen Microsoft 365 Dienste nutzen.
  • AzureAD Identity
    Um sich natürlich mit den AzureAD-Anmeldedaten am HR-System anmelden zu können, braucht es eine AzureAD-Identität. Sicher können Sie diese Benutzer auch manuell anlegen aber interessanter fände ich es, wenn das HR-System die entsprechenden App-Berechtigungen erhält, um damit dem Administrator die Benutzerverwaltung zu ersparen und letztlich die HR-Abteilung für die Pflege der Stammdaten zuständig ist. Diese Funktion können durchaus einige Produkte von Hause aus
  • LocalAD Identity
    Kniffliger wird es natürlich mit dem lokalen AD. Eine Cloud App kann erst einmal nicht per LDAP o.ä., direkt auf ein lokalen AD zugreifen und sie wollen vermutlich auch nicht eine Schnittstelle zum Domain Controller aus dem Internet erreichbar machen. Daher ist ein lokaler Agent das Mittel der Wahl, um Änderungen aus dem Cloud-System ins lokale AD zu übertragen. Der Agent könnte nun natürlich die Daten direkt beim HR-System abrufen oder vielleicht aus dem AzureAD auslesen.

Damit haben wir drei Aspekte, die wie bei der Bewertung und Betrachtung von Produkten ermitteln sollten.

Produkte

Mittlerweile haben mehrere Kunden schon ein "CloudHR-System" im Einsatz und natürlich kommt die Frage der Integration und Kopplung. Daher pflege ich hier eine Tabelle, die aber nicht zwingend aktuell oder vollständig ist, sondern immer nur einen Momentaufnahme von Kundenprojekten und einer schnellen Internet-Recherche ist. Einige Produkte sind sogar bei Microsoft dokumentiert aber mit den Anleitungen dürften sich auch viele andere nicht gelistet Produkte einfach integrieren lassen. Letztlich "ticken" alle irgendwie gleich:

Produkt Anmeldung AzureAD
Provisioning		 LocalAD
Provisioning

SAP Success factors

AzureAD

Ja

Azure AD Connect provisioning agent

Workday HCM

AzureAD

Ja

Azure AD Connect provisioning agent

Personio

AzureAD

Ja

?

BambooHR

AzureAD

?

?

rexx systems

 

 

 

HRlab

 

 

 

HIBob

AzureAD

 

 

AlexisHR

AzureAD

Ja

 

CakeHR

AzureAD

?

 

Cezanne

AzureAD

?

 

SmartHR

AzureAD

?

 

Provisioning über AzureAD ins lokale AD

Die Anleitungen zu SAP Success Factors und Workday zeigen einen Weg auf, über die eine Cloud-Applikation die Änderungen an den "Azure AD Provisioning Agent" in der Cloud senden kann, der dann seinerseits die Änderungen an einen lokalen Agenten zur Umsetzung im lokalen Windows AD überträgt.


Quelle: https://learn.microsoft.com/de-de/azure/active-directory/saas-apps/workday-inbound-tutorial

Mit etwas suchen finden Sie dann auch weitere Details zu dieser Option. Wenn Sie mit dem AzureAD Bereitstellungsassistent die Benutzer auch im lokalen AD Bereitstellung wollen, muss dazu lokal der Agent auf einem Windows 2016 oder höher Server installiert werden.


Quelle: How Application Provisioning works in Azure Active Directory https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/how-provisioning-works

Das ganze sieht Agenten aus AzureAD Cloud Sync sehr ähnlich. Leider habe ich noch nicht viel mehr über die hier abgebildete "Source API Connector" gefunden. Ich tippe aber auch hier darauf, dass es sich um SCIM - System for Cross-Domain Identity Management handelt.

Achtung: Microsoft beschreibt, dass Sie eine AzureAD Premium P1 oder höher-Lizenz für jeden Benutzer benötigen, der durch das HR-System provisioninert wird

Vielleicht gibt es aber noch einen einfacheren Weg.

Beispiel Personio-Export

Nehmen wir einmal an, dass ihre Firma mit "Personio" als Personalverwaltung aus der Cloud arbeitet. Die Personalabteilung (HR) pflegt in dem System alle Mitarbeiter mit den kompletten korrekten Stammdaten. Da würde ich mir als Administrator doch die Hände reiben, um diese Daten als Basis für mein eigenes Provisioning zu machen. Aber das ist meist erst der zweite Schritt. Zuerst möchte nämlich die Firma und die HR-Abteilung, dass sich nun alle Mitarbeiter auch an Personio anmelden können. Schließlich sollt jeder Mitarbeiter doch bitteschön direkt per Browser dort seine Lohn/Gehaltsabrechnung abrufen und Fehlzeiten, Urlaub, Krankheit melden können. Um sich hier doppelte Konten zu sparen, möge der Administrator doch mal eben eine Anmeldung am AD umsetzen. Wohl dem der schon einen Microsoft 365 Tenant hat und sich damit die Anwender auch am Azure AD anmelden können. Dann ist die Einrichtung sehr schnell gemacht und gut dokumentiert

Personio beschreibt auch eine Anmeldung mit Google-Konto oder per OAUTH-2.0 an Okta aber leider nicht die Anmeldung an einem On-Premises-ADFS-Server.

Schlimm finde ich das aber nicht, denn die meisten Firmen haben schon ein AzureAD mit ADSync und Password Hash Sync.

Damit hat nun der Geschäftsführer und die HR-Abteilung ihre Ruhe aber wie kann ich nun als IT-Abteilung auch von Personio profitieren. Kann die HR-Software nicht genauso gut die Benutzer bei mir verwalten?. Ja kann sie, aber nur mit AzureAD (Stand Jun 2023)

Die Option können sie aber nur mit "CloudOnly"-Konten nutzen, denn der Connector verwaltete die Konten im AzureAD über SCIM - System for Cross-Domain Identity Management. Wenn es ein lokale AD gibt und man ADSync nutzt, denn dann ich aber ins lokale AD schreiben und per ADSync/ADCloudSync die Daten wieder ins AzureAD replizieren lassen. Die Objekte im AzureAD sind in weiten Teilen "ReadOnly". das ist durchaus auch mit AzureAD als Vermittler möglich, wie MIcrosoft für SAP Success Factors und Workday öffentlich dokumentiert:

Personio hat für ein lokales AD aus meiner Sicht komplett unverständlich noch keine Roadmap.

As you already know, we do not support Azure AD onprem solutions and we are currently not planning to extend this. However, one of our partners does. With e2mod you can have an integration between Azure AD onprem and Personio. 
https://community.personio.com/other-topics-31/plans-to-support-hybrid-identity-aka-provisioning-to-On-Premises-active-directory-1674

Es wird aber z.B. auf einen Partner "e2mod" im Personio Marketplace verwiesen:

Es gibt durchaus Argument für ein Provisioning-Produkt zwischen Personio und dem lokalen AD und E2mod ist hier nur ein Vertreter. Sie müssen aber schon genau hinschauen, was ein Produkt verspricht. Eine andere Kopplung verspricht z.B. "Sync Blue" (https://info.sync.blue/sync/personio/microsoft-active-directory/de/), welches aber nach meinem Verständnis die Personen als "Kontakte" im AD oder auch im Exchange/Outlook-Kontaktordner oder anderen LDAP-Verzeichnissen anlegt. Aber vielleicht geht es ja einfacher. Aus der Beschreibung geht hervor, dass die E2mod-Integration auch "nur" die Personio-API nutzt, um an die Daten zu kommen.

Als Personio-Admin müssen Sie in der Konfiguration zuerst einen API-Key anlegen und Berechtigungen vergeben, damit sich dann ein Skript authentifizieren und mit dem Token über die REST-API eine Mitgliederliste beziehen kann. Im Grunde ganz einfach.

Damit sollten sie mit wenigen Zeilen PowerShell und Invoke-Restmethod erst mal einen Export der User als CSV-Datei durchführen können. Hier ein Beispielcode. Die vier Parameter sind für ihre Umgebung individuell.

param( 
    $AppID = "Personio ApplicationID",
    $PartnerID = "Hier eine PartnerID",
    $clientid = "Personio ClientID rein",
    $clientsecret = "und_das_geheime_Kennwort"
)

Write-Host "Request OAUTh Token with AppID and Client Secret"
$authUri = "https://api.personio.de/v1/auth?client_id=$($clientid)&client_secret=$($clientsecret)"
$authheader = @{
    "Accept-Charset"        = 'UTF-8'
    "Accept"                = "application/json"
    "X-Personio-App-ID"     = "$($AppID)"
    "X-Personio-Partner-ID" = "$($PartnerID)"
}
$tokenresponse = Invoke-RestMethod `
                    -Method 'Post' `
                    -Uri $authUri `
                    -Header $authheader

$Uri = 'https://api.personio.de/v1/company/employees?limit=100&offset=0&attributes\[\]='
$requestheader = @{
    "Accept"                = "application/json"
    "Authorization"         = "Bearer $($tokenresponse.data.token)"
    "X-Personio-App-ID"     = "$($AppID)"
    "X-Personio-Partner-ID" = "$($PartnerID)"
}

$employeeslist = Invoke-Webrequest `
                    -Method 'Get' `
                    -Uri $Uri `
                    -Header $requestheader

$EmployeeData = ($employeeslist.Content | ConvertFrom-Json)
Write-host "Total Users $($EmployeeData.metadata.total_elements)"

$EmployeeData.data | Select-Object  @{name='Vorname' ; expr={$_.attributes.first_name.value}}, `
                                    @{name='Nachname'; expr={$_.attributes.last_name.value}}

Die zurückgelieferte JSON-Struktur ist leider keine einfache Tabelle. Die erste Ebene liefert einen Status und unter "metadata" die Anzahl der Elemente. Denken Sie an "Paging", wenn sie mehr Benutzer haben, als mit einem Request geliefert werden.

Interessanter sind dann die Stammdaten im Zweig "data". Dies ist eine Liste mit einem "type" und den "attributes"

Als Kunde können Sie in Personio auch eigene "Custom Properties" pflegen. So könnten sie in Personio z.B. die Rufnummer für Microsoft Teams hinterlegen lassen oder den SAM-Accountname, den gewünschten UPN oder die zuzuweisenden Lizenzen. Es ist aber ebenso denkbar, dass ihr Skript diese Werte nach eigenen Regeln und unter Berücksichtigung der erlaubten Zeichen und Eindeutigkeit diese Felder selbst ermittelt und dann zu Personio zurückschreibt.

Der Code liefert natürlich alle aktuellen Benutzer. Sie müssen schon selbst ermitteln, welche Benutzer nun neu, geändert oder nicht mehr vorhanden sind. Das ist dann wieder das übliche Thema eines "Verzeichnisabgleich", bei dem Sie im Ziel oder einem Zwischenspeicher die Änderungen zu erkennen und davon die erforderlichen Aktionen ableiten.

Unterstützung durch Net at Work:
Ich kann ihnen leider kein fertiges Skript liefern, da die Kopplung einige Festlegungen und Vorarbeiten in Personio und AD erfordern. Sie können meine Kollegen und mich aber gerne ansprechen.

Wenn ihr Provisioning mehrstufig erfolgt, z.B. erst wird der Benutzer im AD angelegt. Sie müssen dann aber einen ADSync-Lauf abwarten, bis der Benutzer auch im AzureAD und Teams vorhanden ist und die nachfolgenden Einstellungen möglich werden. Sie könnten über das Rückschreiben der HR-Abteilung quasi den aktuellen Status des Benutzers im Active Directory mitteilen und diese Werte auch selbst zur Steuerung nutzen. Spätestens dann sind sie aber ganz tief im Thema Provisioning und Automatisierung von Identitäten eingetaucht.

Sonstiges

Die Verwaltung von Identitäten anhand von HR-Daten ist eine sehr wichtige Komponente, da es sich dabei um aktive Konten handelt, die zur Anmeldung verwendet werden. Sie wollen also sicherstellen, dass neue Mitarbeiter auch arbeitsfähig sind aber im Umkehrschluss auch ausgeschiedene Mitarbeiter auf jeden Fall rechtzeitig "deaktiviert" oder z.B. aus Lizenzgründen auch irgendwann gelöscht werden. Aber Benutzer sind nur ein Anfang. Aus einer HR-Verwaltung können Sie auch Abteilungen, Hierarchien und weitere Informationen beziehen, und damit z.B.:

  • Windows Gruppen und Mailverteiler verwalten
    So können Sie bei Sicherheitsgruppen die Mitglieder pflegen lassen, die über den Weg dann Zugriffsrechte, Gruppenrichtlinien o.ä. erhalten.
  • Office Groups und Microsoft Teams verwalten
    Denkbar wäre auch das Provisioning diese Datentöpfe über HR
  • Andere Plattformen (Google, Slack, Webex etc.) unterstützt
    Wobei man hier sagen muss, dass viele dieser anderen Dienste problemlos an das AzureAD angebunden werden können und damit die direkte Kopplung der HR-Software nur relevant ist, wenn Sie kein AzureAD haben.

Das sind auch nur erste Überlegungen, welche Informationen sie aus ihrer HR-Lösung in die IT-Welt übertragen. Meist

Weitere Links