Viele die mit Entra (ehemals AzureAD) arbeiten kennen und schätzen die Möglichkeiten, welche Conditional Access bietet. Es lässt sich einfach via verschiedensten Signale definieren, wann ein User Zugriff auf eine bestimmte Resource/Applikation erhält, der Zugriff blockiert oder eine Multi-Faktor Authentisierung (MFA) verlangt wird.
Auch die zentralen SiginIn Logs sind ein Segen für Troubleshootings ganz im Vergleich zu OnPremise. Muss OnPremise ein SignIn Problem analysiert werden, müssen die Logs zuerst auf den verschiedenen Systemen (einzelne DCs, Applikationsserver, Client) gefunden und danach korreliert werden.
Viele wünschten sich solche Möglichkeiten auch OnPremise vor allem die Möglichkeit bei gewissen Zugriffen via AD MFA zu verlangen. Für MFA gibt es diverse Anbieter und Möglichkeiten, meist wird hier aber eine Installation von Agents auf jedem Client und/oder Server vorausgesetzt. Entsprechend aufwändig ist die Implementation und der Unterhalt der Lösung.
Silverfort bietet genau diese Funktionen, jedoch ohne dass überall ein Agent installiert und unterhalten werden muss.
Funktionsweise
Abbildung 1: How Does it Work; Quelle: Silverfort
Silverfort funktioniert anders als die meisten Lösungen. Die Authentisierung wird nicht vor dem Identity Provider (IdP) abgefangen und ausgewertet, sondern erst danach. In den meisten Fällen ist der IdP ein Active Directory. Ähnlich wie in Entra greift auch dort Conditional Access erst nach der initialen Authentifizierung.
Das heisst, dass alle Authentisierungsanfragen, die ein Domain Controller erhält, nach der Verifikation durch den DC an Silverfort weitergeleitet werden. Silverfort bestätigt, verweigert sie oder löst einen MFA Request aus. Silverfort ist sozusagen die Zweitmeinung des Domain Controllers und nur wenn von dort auch das OK kommt, wird der Zugriff bzw. die Authentisierung gestattet.
MFA OnPrem
Silverfort integriert sich mit allen gängigen MFA-Providern, sei es Microsofts Entra MFA, DUO von Cisco, die eigene Lösung von Silverfort u.v.m.
Entsprechend können auf alle Authentisierungen, welche vom AD an Silverfort weitergeleitet werden, eine MFA Bestätigung angefordert werden. Das umschliesst in den meisten Fällen Kerberos Tickets oder falls noch ältere Authentisierungsverfahren zum Einsatz kommen, auch NTLM oder LDAP-Authentisierungen. Da insbesondere bei Kerberos die Tickets granularer auf Service Principal Names (SPN) ausgestellt werden, können auch einzelne Services unterschieden werden. So kann z. B. für die Anmeldung auf einem Server via RDP MFA verlangt werden, für den reinen File Zugriff wird dies jedoch nicht benötigt.
Ein viel gewünschter User Case ist z. B., dass lokal privilegierte Accounts (z. B. Domain Admins) bei Anmeldungen an Server, sei es via RDP oder Remote PowerShell MFA erfüllen müssen. Die nativen Protokolle (Kerberos/NTLM) bieten uns hierzu keine Möglichkeit. Silverfort kann diese Anforderung jedoch erfüllen. Als Beispiel wurde für Domain Admins via Silverfort konfiguriert, dass sie MFA via Microsoft Authenticator (Entra MFA) erfüllen müssen. Die Anmeldung sieht nun wie folgt aus:
- Domain Admin meldet sich mit Username/Credentials im RDP Loginfenster an
- Der Domain Controller prüft die Credentials
- Wenn OK sendet er den Request weiter an Silverfort
- Silverfort fordert nun gemäss der definierten Policy eine MFA Bestätigung via Microsoft Authenticator an.
Die RDP Anmeldung bleibt sistiert bis diese erfüllt ist. - Der User bestätigt die MFA Pushnachricht in der Microsoft Authenticator App
- Silverfort meldet an den DC zurück, dass die Anmeldung in Ordnung ist
- Der Domain Admin ist auf dem Zielserver erfolgreich angemeldet
Gerade Domain Admins sollten nach den gängigen Best Practices nicht nach Entra synchronisiert werden. In Silverfort kann definiert werden, dass der MFA-Request für einen Domain-Admin an einen anderen Entra-Account des Nutzers gesendet wird. Dadurch lässt sich die MFA z. B. über den regulären Office-Account oder einen privilegierten Entra-Account bestätigen.
Abbildung 2: MFA geschützte RDP Anmeldung; Quelle: Bithawk
Zentrale Logs/Analysen
Jegliche Authentisierungsanfragen – ob erfolgreich oder nicht – werden von den Domain Controllern an Silverfort gesendet. Somit sind in Silverfort alle Authentisierungsanfragen zentral verfügbar, einschliesslich Details wie Client-Herkunft und verwendetes Protokoll.
Diese zentralen Logs sind nicht nur fürs Troubleshooting von grossem Vorteil, sondern erlauben es Silverfort auch, Analysen via dem Loginverhalten zu machen.
So können ungewöhnliche Logins, die Verwendung veralteter Protokolle oder unsicherer Kryptoalgorithmen einfach erkannt werden. Analog zu Entra beeinflussen diese Faktoren den «Risk-Level» eines Users, der dann in den Policy-Rules verwendet werden kann. Dies hilft den Administratoren besser zu versehen, was im Unternehmen noch für Authentisierungs-Schwachstellen offen sind und von wo bzw. welchen Accounts diese verwendet werden.
Weiter können auch direkt die SignIn-Logs aus Entra mit denjenigen vom Lokalen AD verknüpft werden, um so eine ganzheitliche Sicht auf das Login verhalten der User Accounts zu gewähren.
Virtual Fencing Service Accounts
Mithilfe der oben beschriebenen Logs kann Silverfort eigene Analysen über die bestehenden User machen und so aufgrund des Verhaltens erkennen, ob gewisse Accounts als Service Accounts benutzt werden. Dies hilft den Administratoren zu erkennen, wo fälschlicherweise normale Account als Service Accounts verwendet wurden und auf welchen Systemen diese konfiguriert sind bzw. von welchen Systemen aus diese verwendet werden. Die reine Erkennung, was als Service Account verwendet wird und von wo diese verwendet werden, ist jedoch nicht alles. Durch das Virtual Fencing können diese Accounts mit Silverfort ebenfalls eingeschränkt und doppelt abgesichert werden. So kann unter anderem einfach verhindert werden, dass ein interaktives Logon erfolgt. Zudem lässt sich genau festlegen, von welchen Systemen ein solcher Account verwendet werden darf und welche Protokolle er nutzen kann.
Möchten Sie eine Demo? Oder benötigen Sie weitere Informationen, zögern Sie nicht und kontaktieren Sie uns der unter marketing@bithawk.ch oder 058 226 01 01. Unsere Experten stehen Ihnen gerne zur Verfügung.
Weitere Themen auf unserem Blog
Zukunftsbeständige IT: Trends für 2025 – Teil 1
Open Source & Effizienz: Wie DeepSeek die KI-Welt in Aufruhr versetzt
Cybersecurity Risikomanagement mit dem BitHawk Framework