Cisco Meraki: Admin-Anmeldung per SAML und ADFS

Cisco Meraki bietet die Möglichkeit, Administratoren mittels SAML-Authentifizierung (Security Assertion Markup Language) anzumelden. Hierzu besteht seitens Cisco in der Tenant-Konfiguration die Möglichkeit, entsprechende Administratoren-Rollen zu definieren. Die von Cisco bereitgestellten Dokumentationen für die Konfiguration mit ADFS (Active Directory Federation Services) bieten leider nur eine sehr rudimentäre Umsetzung, da im dortigen Beispiel nur eine einzige SAML Role definiert wird. Allerdings ist üblicherweise eine Trennung der einzelnen administrativen Bereiche (Scopes) gewünscht, so dass eine passendere Form der Rollenzuweisung notwendig wird. Die nachfolgende Anleitung zeigt den Ansatz, eine Anmeldung basierend auf Sicherheitsgruppen im Active Directory umzusetzen und somit seitens Cisco Meraki ebenfalls eine Trennung der administrativen Zuständigkeiten zu erhalten.

Vielen Dank an Nils für seine Beispiele, die ich hierzu nutzen konnte.

Die verlinkte Anleitung bei Cisco diente als Vorlage für die Basiskonfiguration: https://documentation.meraki.com/zGeneral_Administration/Managing_Dashboard_Access/Configuring_SAML_Single_Sign-on_for_Dashboard

Zwei wichtige Punkte aus der obigen Dokumentation vorab:

When using SAML with Dashboard, the user must first authenticate with the IdP. This is referred to as IdP-initiated SAML. After the user has successfully authenticated and been directed to Dashboard, they will be granted access if they have a valid role and the IdP is correctly configured.

Das bedeutet, dass die Anmeldung nicht wie bei vielen Clouddiensten üblich über deren Service-Site möglich ist, sondern mittels Aufruf über die ADFS Services erfolgt.
https://sso.Testdomain.de/adfs/ls/idpinitiatedsignon.aspx
In den AD FS in Windows 2016 und 2019 ist dies standardmäßig allerdings nicht aktiviert, so dass auch dies aktiviert werden muss.
https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon

Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

If an administrator with a SAML role is configured to have full control over the organization, they will be able to adjust and delete other administrators on the account. There must be at least one non-SAML Dashboard org admin remaining on the account, so a SAML admin will not be able to delete or demote the last remaining Dashboard org admin.

Das bedeutet, bereits vorab im Dashboard (lokale) definierte Administratoren können bis auf einen gelöscht werden. Mindestens ein Dashboard-Org-Admin ist immer notwendig, denn eine SAML-Fehlkonfiguration muss im Notfall behoben werden können. Es sollte also ein generischer Account dafür verwendet werden, dessen Passwort auch hohen Ansprüchen genügt.

Im Dashboard sind zwei Schritte notwendig, damit die SAML Authentifizierung funktioniert.

1. SAML muss für die Organisation im Dashboard aktiviert werden (Anleitung im Cisco Meraki How To)
2. Definition der SAML-Rollen.

Definition der SAML-Rollen im Service Provider (Cisco Meraki)

Die Konfiguration der SAML-Rollen erfolgt im Meraki-Dashboard. Hierzu nach der Anmeldung an der Meraki Service Seite auf Organisation/Administrators wechseln.

Abbildung 1

Unter dem Punkt „SAML administrator roles“ lassen sich die erwähnten neuen Rollen definieren.

Abbildung 2

Rechte lassen sich sowohl für die Organisation (tenant) als auch für einzelne Targets (networks) vergeben. Für die Organisation sin dies: Full, Read-only, None, für die Targets Full, Read-only, Monitor-only, Guest Ambassador. Eine entsprechende Definition der einzelnen Rollen ergibt sich aus den Anforderungen für die Administrationsmöglichkeiten, welche die Administratoren jeweils bekommen sollen. Werden zum Beispiel nur die Mobile Devices verwaltet werden, wird kein Zugriff (weder lesend noch schreibend) auf die Organization benötigt.

Die hier vergebenen Rollen-Namen sollten so gewählt werden, dass eine einfache Zuordnung erkennbar ist. Im obigen Beispiel also SSO-Test-Orgadmin. Untenstehend mal ein Beispiel solcher Rollen.

Abbildung 3

Konfiguration Active Directory (Identity Provider)

Die Konfiguration des Gegenstücks zur Rolle im Meraki Dashboard erfolgt im vorliegenden How To innerhalb eines Active Directory, entspricht also einer Sicherheitsgruppe. Die grundsätzlich funktionierende Konfiguration einer AD-FS Umgebung (Active Directory Federation Services) wird vorausgesetzt. Die notwendige Konfiguration für die Meraki Anmeldung wird in Kapitel 4 beschrieben.

Im Active Directory wird für jede Rollengruppe, welche im Cisco Meraki Dashboard definiert wurde, eine Sicherheitsgruppe angelegt. Mitglieder dieser Sicherheitsgruppen erhalten im Endeffekt dann die entsprechende Berechtigung in der Cisco Meraki Umgebung.

Abbildung 4

Die Zuordnung der SAML-Rolle zur AD Sicherheitsgruppe

Konfiguration Relying Party Trust

In der ADFS Management Konsole wird die Vertrauensstellung der vertrauenden Seite konfiguriert. Nachfolgend stehen mit Absicht fast alle Screens, die man während der Konfiguration zu sehen bekommt. Da viele das nicht so häufig konfigurieren, ist es hilfreich, hier etwas ausführlicher zu sein.

Abbildung 5

Abbildung 6

Abbildung 7

Nachfolgend einen entsprechend aussagekräftigen Namen für die Vertrauensstellung vergeben. Im vorliegenden Fall also „Meraki Dashboard“.

Abbildung 8

Abbildung 9

Im folgenden Abschnitt wird die notwendige URL des SAML Dienstes von Meraki benötigt. Diese URL wird euch im Meraki Dashboard angezeigt und ist für jede Konfiguration individuell.

Abbildung 10

Abbildung 11

Der Bezeichner ist hingegen immer gleich und wird nur der Form halber benötigt (von Meraki aber nicht verwendet)

https://dashboard.meraki.com/

Abbildung 12

Der Einfachheit halber wird der Zugriff für jeden gewährt. Natürlich kann aber auch eine Einschränkung auf einzelne Gruppen oder falls vorhanden eine Multifaktor-Authentisierung konfiguriert werden.

Abbildung 13

Abbildung 14

Abbildung 15

Nach Abschluss öffnet sich der Wizard für die Konfiguration der Anspruchsausstellungsrichtlinie (Claim Rules). Zu den „Besonderheiten“ der ADFS Bezeichnungen hat Nils hier schon was geschrieben. Hilfreich, sich diese Tabelle regelmäßig vors Auge zu führen: https://www.faq-o-matic.net/2014/05/14/namensverwirrung-adfs-und-saml/

Der Nutzername kann bspw. per Attribut Email-Adressses oder per User-Principal-Name ermittelt werden. Ich nutze eher letzteres, da der eigentlich immer vorhanden ist im Gegensatz zum Mail-Attribut. Gerade bei Umgebungen, in denen UPN=Mailadresse ist, bietet sich das an.

Abbildung 16

Abbildung 17

Damit die Rolle in Abhängigkeit von Gruppenmitgliedschaften übermittelt werden kann, muss zuerst ermittelt werden, welche Mitgliedschaften ein Nutzer überhaupt besitzt.

Hierzu wird eine Regel erstellt, welche das Attribut „tokenGroups“ des Nutzers ausliest.

Hinweis: Wer sein Active Directory sicher konfiguriert hat, dessen Gruppe „Prä-Windows 2000 kompatibler Zugriff“ ist leer. Dadurch fehlt dann ggf. dem Service Account (auch group managed service account) des ADFS Services das Recht, das Attribut „tokenGroups“ der Nutzer überhaupt auslesen zu können. Mittels dsacls kann dieses Recht entsprechend an eine Gruppe delegiert werden, deren Mitglied das Servicekonto ist.

dsacls DC=domain,DC=tld /I:S /G domain\LDAP-TokenGroups:RP;TokenGroups;user

Abbildung 18

Alle folgenden Regeln sind vom Typ „Ansprüche mithilfe einer benutzerdefinierten Regel senden“.

Der Regel wird ein entsprechender Name bspw. „Retrieve Token Groups“ vergeben und als Regel folgender Block eingefügt:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = ";tokenGroups;{0}", param = c.Value);

Abbildung 19

Weitere Regeln für die SAML-Rollenzuweisung folgen. Da ein Nutzer nur eine Rolle besitzen kann, muss die entsprechende Logik von doppelten Gruppenmitgliedschaften innerhalb des Regelwerks abgebildet werden.

Als drittes wird also die SAML-Rolle übermittelt. Der Nutzer ist Mitglied der Active Directory Gruppe „SSO-Meraki-OrgAdmin“. Wurden die drei SAML Rollen „SSO-Test-OrgAdmin“, SSO-Test-MDMAdmin“ und SSO-Test-OrgAuditor“ angelegt, werden also drei weitere Regeln angelegt.

Abbildung 20

Der Inhalt dieser Regeln ist nachfolgend dargestellt.

Regel 3: Issue OrgAdmin role if user is member of Admin group

EXISTS([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value == "SSO-Meraki-Orgadmin"])
=> issue(Type = "https://dashboard.meraki.com/saml/attributes/role", Value = "SSO-Test-OrgAdmin");

Regel 4: Issue MDMAdmin role if user is member of MDMAdmin and not member of OrgAdmin group

EXISTS([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value == "SSO-Meraki-MDMAdmin"])
&& NOT EXISTS([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value == "SSO-Meraki-Orgadmin"])
=> issue(Type = "https://dashboard.meraki.com/saml/attributes/role", Value = "SSO-Test-MDMAdmin");

Regel 5: Issue OrgAuditor role if user is member of OrgAuditor and not member of OrgAdmin group

EXISTS([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value == "SSO-Meraki-OrgAuditor"])
&& NOT EXISTS([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value == "SSO-Meraki-Orgadmin"])
=> issue(Type = "https://dashboard.meraki.com/saml/attributes/role", Value = "SSO-Test-OrgAuditor");

Das Ergebnis sollte dann so aussehen.

Abbildung 21