Spricht mit den Systemen, die Sie schon betreiben
ip·Solis ist Klebstoff, kein Ersatz. Bringen Sie Ihr AD, Ihr SCCM, Ihren Hypervisor und Ihren IdP mit. Wir verdrahten sie.
Active Directory
Der PowerShell-7-Worker verbindet sich mit AD über ADWS per NTLM-Signierung oder Kerberos, sodass bestehende Domain-Credentials ohne zusätzliche Konfiguration funktionieren. Runbook-Schritte können Nutzer zu Sicherheitsgruppen hinzufügen oder daraus entfernen, beliebige Nutzerattribute setzen und das Verzeichnis abfragen. Die Vorgesetztenbeziehung wird zum Zeitpunkt der Auftragserfassung live für das Genehmigungs-Routing aufgelöst — nicht gespeichert — sodass Änderungen in der Berichtslinie sofort berücksichtigt werden.
SCCM
Die SCCM-Integration umfasst Geräteimport, Task-Sequence-Auslösung via WinRM und AdminService-REST-API-Aufrufe mit Kerberos-Authentifizierung. Eine integrierte Status-Probe pollt den Task-Sequence-Abschluss asynchron und setzt den Auftragsstatus automatisch weiter, sodass Operatoren den Fortschritt in Echtzeit sehen, ohne selbst Polling-Logik schreiben zu müssen. Funktioniert mit On-Premises-SCCM und Microsoft Endpoint Configuration Manager.
XenServer / XCP-ng
VMs in einem XenServer- oder XCP-ng-Pool können direkt aus Runbook-Schritten per XenAPI geklont, ein- und ausgeschaltet, gesnapshoted und gelöscht werden. SSL-Bypass für selbstsignierte Pool-Master-Zertifikate ist vorkonfiguriert, und Stdin-Injection übernimmt interaktive Prompt-Workarounds, damit Air-Gapped-Lab-Umgebungen ohne Skriptanpassungen funktionieren.
VMware vSphere
PowerCLI-basierte Runbook-Schritte verwalten den vollständigen VM-Lebenszyklus gegen vCenter — Klonen aus Templates, Hardware konfigurieren, Ein-/Ausschalten, Snapshots erstellen und zurücksetzen sowie Löschen. Selbstsignierte vCenter-Zertifikate werden automatisch behandelt. Credentials werden in der Admin-UI gespeichert und pro Ausführung injiziert — nie im Skript hartkodiert.
Generischer Webhook
Der eingehende ServiceNow-Webhook nimmt HMAC-SHA256-signierte Payloads entgegen und leitet sie durch dieselbe Genehmigungs- und Runbook-Pipeline wie Portal-Aufträge. AD-Attribute des Anfragenden werden zum Erstellungszeitpunkt als Snapshot gespeichert, sodass Webhook-Aufträge korrekt in Kostenstellen- und Abteilungsaufschlüsselungen erscheinen. Dasselbe Muster funktioniert für jedes HRIS- oder ITSM-System, das einen signierten JSON-Payload senden kann.
SCIM-2.0-IdPs
Der /scim/v2/-Endpunkt integriert Okta, SailPoint, Ping Identity, Entra ID und jeden RFC-7644-konformen Identity Provider. Nutzer-Provisionierungsaufrufe werden als No-Op bestätigt — ip·Solis führt kein eigenes Nutzerverzeichnis. Deaktivierungsereignisse (DELETE oder PATCH active=false) lösen sofort den vereinheitlichten Leaver-Flow aus, der alle aktiven Aufträge widerruft und Deprovision-Runbooks startet.
SMTP
Alle ausgehenden Benachrichtigungen — Genehmigungsanfragen, Erinnerungen, Ablaufwarnungen, Leaver-Bestätigungen, Kostenschwellwert-Alarme — werden über Ihren eigenen SMTP-Server verschickt. STARTTLS und SSL/TLS werden beide unterstützt. Absenderadresse, Reply-to und Credentials werden in der Admin-UI konfiguriert und können ohne Container-Neustart aktualisiert werden.
Microsoft Teams
Genehmigungsanfragen werden als Adaptive Cards an einen konfigurierten Teams-Kanal per Webhook zugestellt — Führungskräfte genehmigen oder lehnen mit einem Klick ab, ohne Teams zu verlassen. Kostenschwellwert-Alarme und Zertifizierungserinnerungen werden ebenfalls parallel zur E-Mail an Teams gesendet, damit die richtigen Personen dort benachrichtigt werden, wo sie arbeiten.
Versionierte Runbooks
Runbooks können als strukturiertes JSON exportiert und in ein Git-Repository eingecheckt werden, was Code-Review, Diff-Historie und Rollback über Standard-Pull-Request-Workflows ermöglicht. Dasselbe JSON kann in jede ip·Solis-Instanz zurückimportiert werden, was die Runbook-Promotion über Dev-, Staging- und Produktionsumgebungen unkompliziert macht.