43
Wer nutzt 2-Factor-Authentifizierung in seiner Windowsdomain?
Moin an alle Adminkollegen!
Ich werde mich demnächst um ein neues Thema kümmern müssen: Schützen der wichtigen Kennwörter. Dabei stehen die Domänenadminkennwörter im Vordergrund.
Vielleicht hat jemand Erfahrungen mit der Abwehr des folgenden Szenarios:
Ein User ist Admin auf seinem Windowsrechner (oder aber nur User, hat sich aber Adminrechte verschafft durch Exploits). Dieser User plant, mit Hilfe von Hackingtools oder Keyloggern an ein Domänenadminkennwort zu kommen. Er ruft den Support an, und gibt vor Probleme zu haben, so dass sich jemand bei ihm einloggt und, so hofft er, ein Konto benutzt, das auch netzwerkweit "was reißen kann".
Wie schützt Ihr Euch dagegen?
Mir schwebt vor, diese Supportnutzer nur noch mit Einmalkennwörtern auszustatten oder aber eine wirksame Art von 2-Faktor-Authentifizierung zu etablieren, so dass sogar etwaig beschaffte Kennwörter alleine keinen Wert haben.
Was setzt Ihr ein, wie setzt Ihr es ein, was kostet es... oder warum glaubt Ihr (ggf.) nicht an solche Maßnahmen?
Ich werde mich demnächst um ein neues Thema kümmern müssen: Schützen der wichtigen Kennwörter. Dabei stehen die Domänenadminkennwörter im Vordergrund.
Vielleicht hat jemand Erfahrungen mit der Abwehr des folgenden Szenarios:
Ein User ist Admin auf seinem Windowsrechner (oder aber nur User, hat sich aber Adminrechte verschafft durch Exploits). Dieser User plant, mit Hilfe von Hackingtools oder Keyloggern an ein Domänenadminkennwort zu kommen. Er ruft den Support an, und gibt vor Probleme zu haben, so dass sich jemand bei ihm einloggt und, so hofft er, ein Konto benutzt, das auch netzwerkweit "was reißen kann".
Wie schützt Ihr Euch dagegen?
Mir schwebt vor, diese Supportnutzer nur noch mit Einmalkennwörtern auszustatten oder aber eine wirksame Art von 2-Faktor-Authentifizierung zu etablieren, so dass sogar etwaig beschaffte Kennwörter alleine keinen Wert haben.
Was setzt Ihr ein, wie setzt Ihr es ein, was kostet es... oder warum glaubt Ihr (ggf.) nicht an solche Maßnahmen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 219128
Url: https://administrator.de/contentid/219128
Printed on: April 25, 2024 at 05:04 o'clock
43 Comments
Latest comment
Hallo,
soviel ich weiss gibt es bei vielen AV-Produkten die Möglichkeit, die lokale Installation mit einem Passwort zu schützen, sodass nicht mal lokale Admins den AV deinstallieren können (Sophos kann das sicher, Kaspersky glaube ich auch).
Dann kann der User selbst wenn er sich Admin-Rechte durch einen Exploit auf dem PC verschafft hat immer noch keine Keylogger installieren, da diese vom AV abgewehrt werden.
Für meine Verhältnisse ist dies mit einem durchdachten Patchmanagement am Client ausreichend - oder wiege ich mich in falscher Sicherheit?
mfg
soviel ich weiss gibt es bei vielen AV-Produkten die Möglichkeit, die lokale Installation mit einem Passwort zu schützen, sodass nicht mal lokale Admins den AV deinstallieren können (Sophos kann das sicher, Kaspersky glaube ich auch).
Dann kann der User selbst wenn er sich Admin-Rechte durch einen Exploit auf dem PC verschafft hat immer noch keine Keylogger installieren, da diese vom AV abgewehrt werden.
Für meine Verhältnisse ist dies mit einem durchdachten Patchmanagement am Client ausreichend - oder wiege ich mich in falscher Sicherheit?
mfg
Dein Punkt ist mir bekannt, jedoch wiegst Du Dich definitiv in falscher Sicherheit, da man die Exploit-/Hackingtools nur etwas zu modifizieren braucht, und schon werden Sie nicht mehr erkannt - das ist ja einer der Gründe für die hunderten von Varianten mancher Viren. Und dann sind da ja zusätzlich noch Hardwarekeylogger möglich, die erkennt eh kein Scanner.
Tach auch
Eigentlich ist es egal wie man welches System schützt. Wenn jemand an solche Daten unbedingt ran will dann kommt er auch ran.
Mach es mal nicht so kompliziert: Der user steht neben dir und schaut dir auf die Finger während du dich am System anmeldest -- baam und schon hat er
wieder ein Passwort.
Von außen kann man sich "relativ" gut schützen. Die schlimmeren sind die internen Angriffe.
Mfg
-s-v-o-
Eigentlich ist es egal wie man welches System schützt. Wenn jemand an solche Daten unbedingt ran will dann kommt er auch ran.
Mach es mal nicht so kompliziert: Der user steht neben dir und schaut dir auf die Finger während du dich am System anmeldest -- baam und schon hat er
wieder ein Passwort.
Von außen kann man sich "relativ" gut schützen. Die schlimmeren sind die internen Angriffe.
Mfg
-s-v-o-
Nicht ganz. "Shoulder Surfing" wird doch gerade damit auch ausgehebelt.
Hi!
PKI mit SmartCards oder USB-Dongles, da kannst du nichts mehr machen mit Keyloggern.
sg Dirm
PKI mit SmartCards oder USB-Dongles, da kannst du nichts mehr machen mit Keyloggern.
sg Dirm
Moin Dirmhirn.
Ich hoffe, dass Du das jetzt nicht nur so in den Raum wirfst, sondern noch ausführst - denn so weit bin ich auch.
Ich hoffe, dass Du das jetzt nicht nur so in den Raum wirfst, sondern noch ausführst - denn so weit bin ich auch.
Was setzt Ihr ein, wie setzt Ihr es ein, was kostet es?
Erhoffte ich zu erfahren.
Hi,
hast du denn oft den Fall das ein Support Mitarbeiter sich mit erweiterten Rechten am Rechner anmelden muss?
Oder bei welchen konkreten Problemfällen wird so verfahren?
Anstatt einer technischen Lösung reicht vllt auch einfach ein anderes Verfahren.
Hintergrund ist, dass ich mich selbst eigentlich nicht daran erinnern kann, dass sowas wirklich mal erforderlich gewesen wäre.
Nächste Frage wäre ob die Supporter wirklich Domain Admins sein müssen oder ob delegiertere Rechte für ihr Tätigkeitsfeld ausreichen.
Noch ein Punkt wäre, ein Anwender der so vertraut mit Hacking Tools ist und sich per Exploits Rechte auf der lokalen Maschine verschafft, wird sich dann eher nciht um Kennwörter kümmern sondern wahrscheinlich genauso mit Exploits gegen die DCs oder Filer oder was auch immer vorgehen.
Kurzum, ich halte das Szenario schon für unrealistisch, für den zuletzt beschriebenen Worst-Case haste mit 2 Faktor Authentifizierung eventuell ein Haufen Aufwand aber trotzdem keinen Gewinn an Sicherheit.
hast du denn oft den Fall das ein Support Mitarbeiter sich mit erweiterten Rechten am Rechner anmelden muss?
Oder bei welchen konkreten Problemfällen wird so verfahren?
Anstatt einer technischen Lösung reicht vllt auch einfach ein anderes Verfahren.
Hintergrund ist, dass ich mich selbst eigentlich nicht daran erinnern kann, dass sowas wirklich mal erforderlich gewesen wäre.
Nächste Frage wäre ob die Supporter wirklich Domain Admins sein müssen oder ob delegiertere Rechte für ihr Tätigkeitsfeld ausreichen.
Noch ein Punkt wäre, ein Anwender der so vertraut mit Hacking Tools ist und sich per Exploits Rechte auf der lokalen Maschine verschafft, wird sich dann eher nciht um Kennwörter kümmern sondern wahrscheinlich genauso mit Exploits gegen die DCs oder Filer oder was auch immer vorgehen.
Kurzum, ich halte das Szenario schon für unrealistisch, für den zuletzt beschriebenen Worst-Case haste mit 2 Faktor Authentifizierung eventuell ein Haufen Aufwand aber trotzdem keinen Gewinn an Sicherheit.
Hi Bitboy.
Wir haben diesen Fall oft genug, um sagen zu können, dass wir zumindest mal durchspielen müssen, welcher Aufwand auf uns zu käme.
Dass Du das Szenario nicht nur für evtl. unnötig, sondern auch für unrealistisch hältst, kann ich nicht teilen, aber das ist auch nicht Thema hier.
Mich interessiert noch, warum Du folgender Meinung bist:
Wir haben diesen Fall oft genug, um sagen zu können, dass wir zumindest mal durchspielen müssen, welcher Aufwand auf uns zu käme.
Dass Du das Szenario nicht nur für evtl. unnötig, sondern auch für unrealistisch hältst, kann ich nicht teilen, aber das ist auch nicht Thema hier.
Mich interessiert noch, warum Du folgender Meinung bist:
für den zuletzt beschriebenen Worst-Case haste mit 2 Faktor Authentifizierung eventuell ein Haufen Aufwand aber trotzdem keinen Gewinn an Sicherheit.
Ich habe wahrgenommen, dass Du schreibst:ein Anwender der so vertraut mit Hacking Tools ist und sich per Exploits Rechte auf der lokalen Maschine verschafft, wird sich dann eher nciht um Kennwörter kümmern sondern wahrscheinlich genauso mit Exploits gegen die DCs oder Filer oder was auch immer vorgehen.
...jedoch ist dort die Angriffsfläche sehr begrenzt im Gegensatz zu der Angriffsfläche auf den ganzen Clients. Stimmst Du zu?
HI,
ok, wenn ihr den Fall öfter habt, ich hab ihn wie gesagt praktisch gar nicht.
Ja prinzipiell bietet ein Client mehr Angriffsfläche.
Hier hängts aber von der Art des Exploits ab. Nicht wenige Patche gelten für zum Beispiel Win 7 und 2008. Ein Exploit der die Tür zum Client aufmacht könnte also genauso gut auch die zum Server aufmachen (Wie gesagt, hängt von der Beschaffenheit der Lücke ab ob sie übers Netzwerk genutzt werden kann oder nicht). Einem professionellen Angreifer unterstelle ich einfach mal, dass er genau so einen Exploit verwenden würde.
Schliesslich wäre auch sonst die Gefahr vorzeitig entdeckt zu werden recht hoch. Ich meine sich erst Rechte über den Client zu verschaffen um dann zu hoffen dass ein Supporter zeitnah und bevor die Manipulation auffällt seine Admin-Kennwörter "preisgibt", klingt mir schon nach einem wackeligen Plan.
Daher sehe ich die grössere Angriffsfläche bei dem Client schon relativiert.
ok, wenn ihr den Fall öfter habt, ich hab ihn wie gesagt praktisch gar nicht.
Ja prinzipiell bietet ein Client mehr Angriffsfläche.
Hier hängts aber von der Art des Exploits ab. Nicht wenige Patche gelten für zum Beispiel Win 7 und 2008. Ein Exploit der die Tür zum Client aufmacht könnte also genauso gut auch die zum Server aufmachen (Wie gesagt, hängt von der Beschaffenheit der Lücke ab ob sie übers Netzwerk genutzt werden kann oder nicht). Einem professionellen Angreifer unterstelle ich einfach mal, dass er genau so einen Exploit verwenden würde.
Schliesslich wäre auch sonst die Gefahr vorzeitig entdeckt zu werden recht hoch. Ich meine sich erst Rechte über den Client zu verschaffen um dann zu hoffen dass ein Supporter zeitnah und bevor die Manipulation auffällt seine Admin-Kennwörter "preisgibt", klingt mir schon nach einem wackeligen Plan.
Daher sehe ich die grössere Angriffsfläche bei dem Client schon relativiert.
Ich selbst wende es nicht an, aber der IT-Dienstleister unserer ehemaligen Muttergesellschaft, von denen wir noch etliche Dienste beziehen, nutzt es (wir haben es nur ungewollt mitbekommen).
Auf jedem Windows-System, was bei denen im Netzwerk und am Clientmanagement hängt, hat ein eigenentwickeltes Programm verpasst bekommen, welches regelmäßig bei einem lokalen Admin das Passwort ändert (Zufallswert) und das Passwort in einer Datenbank hinterlegt. Der Support hat nur noch die Passwörter aus der Datenbank und keinen DomAdmin.
Also wenn ein Benutzer oder sonstwer das Admin-Passwort herausfindet, ist nur eine Maschine akut gefährdet.
Wenn man wollte, kann man sicher soweit gehen, dass nach jeder An- bzw. Abmeldung das Passwort geändert wird.
Auf jedem Windows-System, was bei denen im Netzwerk und am Clientmanagement hängt, hat ein eigenentwickeltes Programm verpasst bekommen, welches regelmäßig bei einem lokalen Admin das Passwort ändert (Zufallswert) und das Passwort in einer Datenbank hinterlegt. Der Support hat nur noch die Passwörter aus der Datenbank und keinen DomAdmin.
Also wenn ein Benutzer oder sonstwer das Admin-Passwort herausfindet, ist nur eine Maschine akut gefährdet.
Wenn man wollte, kann man sicher soweit gehen, dass nach jeder An- bzw. Abmeldung das Passwort geändert wird.
Das ist doch keine 2-factor-auth.
hi!
jein, hab das mal testweise mit Smartcards und USB-Card Readern probiert.
Funktioniert mit Windows (2003er Domain damals) out-of-the-box recht gut.
im Prinzip musst du nur für jeden einen Dongle kaufen - die Preise hängen von der Stückzahl ab. 30-50€ pro Stück.
falls alle PCs SmartCard Reader haben, reichen dir SmartCards - die sind günstiger. gibt's ab wenigen €.
Wie schnell die USB-Dongles beim ersten anschließen an einem neuen PC erkannt werden, kann ich dir nicht sagen. Mit Card Reader aber sehr flott - die Kollegen werden neidisch sein ^^
für die Support MA kannst du die Zertifikate einfach drauf kopieren und wirst hoffentlich wenig Supportfälle dazu haben.
als Zweitfaktor hast du dann "nur" den PIN - kein OTP. Aber Dongle & PIN klauen ist schon um einiges schwerer. Vor allem da die Support MAs hier um einiges verantwortungsvoller sein sollten, als alle MAs im Unternehmen...
da es nicht alle im Unternehmen nutzen, kannst du die Smartcard nicht erzwingen, d.h. die Support MA Accounts sollten dann ein sehr langes PW haben, dass sie aber nie nutzen. (ev. kannst du jetzt auch Accountweise Zertifikatsanmeldung erzwingen, bin mir nicht sicher ob es da bei win 2008+ nicht die Option in der Kontoverwaltung gibt...)
sg Dirm
Zitat von @DerWoWusste:
Moin Dirmhirn.
Ich hoffe, dass Du das jetzt nicht nur so in den Raum wirfst, sondern noch ausführst - denn so weit bin ich auch.
> Was setzt Ihr ein, wie setzt Ihr es ein, was kostet es?
Erhoffte ich zu erfahren.
Moin Dirmhirn.
Ich hoffe, dass Du das jetzt nicht nur so in den Raum wirfst, sondern noch ausführst - denn so weit bin ich auch.
> Was setzt Ihr ein, wie setzt Ihr es ein, was kostet es?
Erhoffte ich zu erfahren.
jein, hab das mal testweise mit Smartcards und USB-Card Readern probiert.
Funktioniert mit Windows (2003er Domain damals) out-of-the-box recht gut.
im Prinzip musst du nur für jeden einen Dongle kaufen - die Preise hängen von der Stückzahl ab. 30-50€ pro Stück.
falls alle PCs SmartCard Reader haben, reichen dir SmartCards - die sind günstiger. gibt's ab wenigen €.
Wie schnell die USB-Dongles beim ersten anschließen an einem neuen PC erkannt werden, kann ich dir nicht sagen. Mit Card Reader aber sehr flott - die Kollegen werden neidisch sein ^^
für die Support MA kannst du die Zertifikate einfach drauf kopieren und wirst hoffentlich wenig Supportfälle dazu haben.
als Zweitfaktor hast du dann "nur" den PIN - kein OTP. Aber Dongle & PIN klauen ist schon um einiges schwerer. Vor allem da die Support MAs hier um einiges verantwortungsvoller sein sollten, als alle MAs im Unternehmen...
da es nicht alle im Unternehmen nutzen, kannst du die Smartcard nicht erzwingen, d.h. die Support MA Accounts sollten dann ein sehr langes PW haben, dass sie aber nie nutzen. (ev. kannst du jetzt auch Accountweise Zertifikatsanmeldung erzwingen, bin mir nicht sicher ob es da bei win 2008+ nicht die Option in der Kontoverwaltung gibt...)
sg Dirm
Moin,
wir bauen sowas ähnliches für das komplette Windowsnetzwerk und setzen dafür in Zukunft auf VASCO - OTP + PIN.
Grüße,
Dani
wir bauen sowas ähnliches für das komplette Windowsnetzwerk und setzen dafür in Zukunft auf VASCO - OTP + PIN.
Grüße,
Dani
Ich weiß, aber eine Alternative zu deinem Problem, weil 2-Factor-Auth schon ein sehr großer Eingriff darstellt und alle Systeme es ja unterstützen müssen, nicht nur die Windows-Anmeldung selbst sondern irgendwelche Systeme, die auf die gleiche Datenbasis zurückgreifen (NTLM, irgendwelche LDAP-Anwendungen, ...). Daher sind die Einmal- oder Kurzzeitpasswörter, die du ja selbst in deinem Eingangsbeitrag erwähnt hast, meiner Meinung nach einfacher und schneller umzusetzen.
@tikayevent - ja, hab ich selbst erwähnt, stimmt schon. Wobei mir bei Einmalkennwörtern zunächst eher ein Passwortgenerator vorschwebte, den der Admin anwirft und nicht der Blick in eine Liste, die, wie von Dir beschrieben, dynamisch gepflegt wird. Problematisch am lokalen Admin ist natürlich, dass er nicht an Domänenressourcen via Netzwerk rankommt und somit sein Supporthandlungsspielraum eingeschränkt ist.
Ich lass den Beitrag noch mal offen, höre mich noch anderweitig um und schreibe auf, was ich gehört habe.
--
@Dani: werde ich mir ansehen, danke. Wenn Du eine Aufwandseinschätzung geben kannst, wäre ich dankbar.
@Dirmhirn: Danke dafür.
@Bitboy:
Ich lass den Beitrag noch mal offen, höre mich noch anderweitig um und schreibe auf, was ich gehört habe.
--
@Dani: werde ich mir ansehen, danke. Wenn Du eine Aufwandseinschätzung geben kannst, wäre ich dankbar.
@Dirmhirn: Danke dafür.
@Bitboy:
Schliesslich wäre auch sonst die Gefahr vorzeitig entdeckt zu werden recht hoch. Ich meine sich erst Rechte über den Client zu verschaffen um dann zu hoffen dass ein Supporter zeitnah und bevor die Manipulation auffällt seine Admin-Kennwörter "preisgibt", klingt mir schon nach einem wackeligen Plan.
So würde er nicht vorgehen. Er hätte ja ggf. schon die Rechte (Software-Entwickler haben bei uns lok. Adminrechte) und müsste nur einen Supporter anrufen unter dem Vorwand, das etwas klemmt. Der loggt sich ein, findet kein ernstes Problem ("oh, tritt wohl nur sporadisch auf") und loggt sich wieder aus...und der Entwickler kassiert dessen Kennwort ein. Kein Keylogger notwendig, man kann sogar nach deren Abmeldung (solange bis der Rechner rebootet wird) noch Kennwörter anderer aus dem RAM in Plaintext lesen. Einzig und allein der Virenscanner könnte das Hackingtool (welches ich hier nicht nennen werde) stoppen - sofern man es nicht vorher geeignet modifiziert hat.
@DerWoWusste
Das hängt stark davon ab wie Leute und Dienste es betreffen wird. Wir stellen z.B. alle Mitarbeiter/innen um. Betroffene Awendungen sind z.B. Windowsanmeldung, Terminalserver, OWA, SSL-VPN, etc... wir rechnen mit ca. 6 Monaten.
Grüße,
Dani
Das hängt stark davon ab wie Leute und Dienste es betreffen wird. Wir stellen z.B. alle Mitarbeiter/innen um. Betroffene Awendungen sind z.B. Windowsanmeldung, Terminalserver, OWA, SSL-VPN, etc... wir rechnen mit ca. 6 Monaten.
Grüße,
Dani
Hmm. Das ist jetzt nicht wirklich eine Aufwandseinschätzung, die mich weiter bringt, denn ich weiß ja nicht, um wie viele es sich bei Euch dreht und Kosten fehlen.
Anders gefragt: wenn wir unsere Supportadmins mit Eurem System ausstatten würden, mit dem Ziel, dass sie davor geschützt sind, dass Ihre Kennwörter von lokalen Admins derart leicht abgegriffen werden können, was wäre das für ein Aufwand? Die Supp.admins müssten nur in der Lage sein, sich
A in der Sitzung des Users bewegen zu können (RemoteAssistance) und dabei bei Bedarf Ihr Kennwort zu nutzen
B Sich lokal am PC anzumelden und (wie auch in Fall A) Netzwerkressourcen zu nutzen.
Anders gefragt: wenn wir unsere Supportadmins mit Eurem System ausstatten würden, mit dem Ziel, dass sie davor geschützt sind, dass Ihre Kennwörter von lokalen Admins derart leicht abgegriffen werden können, was wäre das für ein Aufwand? Die Supp.admins müssten nur in der Lage sein, sich
A in der Sitzung des Users bewegen zu können (RemoteAssistance) und dabei bei Bedarf Ihr Kennwort zu nutzen
B Sich lokal am PC anzumelden und (wie auch in Fall A) Netzwerkressourcen zu nutzen.
Zitat von @Dirmhirn:
Hi!
PKI mit SmartCards oder USB-Dongles, da kannst du nichts mehr machen mit Keyloggern.
Hi!
PKI mit SmartCards oder USB-Dongles, da kannst du nichts mehr machen mit Keyloggern.
Das kann man so nicht sagen, weil es meist unpraktikabel ist, ausschließlich Kartenleser mit eigener Tastatur einzusetzen (und auch auf dem ist die PIN-Eingabe in dem vorausgesetzten Szenario leicht abzufangen).
Die Authentifizierung über ein kompromittiertes System wird durch 2FA nicht sicherer, wenn das System sowohl Token als auch PIN mit derselben Regelmäßigkeit bekommt wie vorher das Passwort.
Grüße
Richard
Hallo C.R.S.
Hast Du auch eine Ansicht, wie man es sicherer gestalten könnte?
Hast Du auch eine Ansicht, wie man es sicherer gestalten könnte?
Moin DerWoWusste,
a) Dazu kann ich aktuell keine praktische Aussage treffen. Ich würde aber behaupten wenn UAC aktiviert ist, sollte es möglich sein. Statt einem statischen Kennwort wird eben jedes Mal ein OTP eingeben. Ist für den Supporter eben aufwendiger.
b) Ist möglich, da über ein Plugin die Windowsanmeldung umkonfiguriert wird.
Grüße,
Dani
wenn wir unsere Supportadmins mit Eurem System ausstatten würden, mit dem Ziel, dass sie davor geschützt sind, dass Ihre Kennwörter von lokalen Admins derart leicht abgegriffen werden können, was wäre das für ein Aufwand?
Ich würde behaupten in 10 Arbeitstagen bekommt das System aufgesetzt, konfiguriert und getestet. Wenn die Serverdienste noch redudant ausgelegt werden sollen, steigt der Aufwand entsprechend. Für Software (Goldversion)/Tokens/Support wirst du mit ca. 8.000€/Brutto pro 50 Benutzer rechnen müssen.a) Dazu kann ich aktuell keine praktische Aussage treffen. Ich würde aber behaupten wenn UAC aktiviert ist, sollte es möglich sein. Statt einem statischen Kennwort wird eben jedes Mal ein OTP eingeben. Ist für den Supporter eben aufwendiger.
b) Ist möglich, da über ein Plugin die Windowsanmeldung umkonfiguriert wird.
Grüße,
Dani
Moin moin,
ich kann deine Gedankengang vollends nachvollziehen, vor diesem Problem steht man als Admin wohl immer (mal wieder). Ich habe mich vor einiger Zeit auch mal damit beschäftigen müssen und letztlich lief es auf den Einsatz von Security-Token hinaus, also diese RSA-Teilchen, die einen sechsstelligen Code anzeigen, der nur für die Dauer von n Sekunden gültig ist und sich dann ändert.
Die Krux hierbei ist die Implementierung und wieder mal der Admin selbst: Verlieren solltest du so ein Teil nicht und auch nicht auf dem Schreibtisch eines Kollegen vergessen. Zu den Kosten kann ich dir nichts konkretes sagen, die Implementierung habe ich aufgrund eines Job-Wechsels nicht mehr miterlebt.
Cheers,
jsysde
ich kann deine Gedankengang vollends nachvollziehen, vor diesem Problem steht man als Admin wohl immer (mal wieder). Ich habe mich vor einiger Zeit auch mal damit beschäftigen müssen und letztlich lief es auf den Einsatz von Security-Token hinaus, also diese RSA-Teilchen, die einen sechsstelligen Code anzeigen, der nur für die Dauer von n Sekunden gültig ist und sich dann ändert.
Die Krux hierbei ist die Implementierung und wieder mal der Admin selbst: Verlieren solltest du so ein Teil nicht und auch nicht auf dem Schreibtisch eines Kollegen vergessen. Zu den Kosten kann ich dir nichts konkretes sagen, die Implementierung habe ich aufgrund eines Job-Wechsels nicht mehr miterlebt.
Cheers,
jsysde
Moin,
Jeder Standort hat einige Tokens als Vorrat, welche aber nicht aktiviert sind. Bei Verlust wirft der Support den alten Token aus dem System und der Neue wird eingepflegt.
Grüße,
Dani
Die Krux hierbei ist die Implementierung und wieder mal der Admin selbst: Verlieren solltest du so ein Teil nicht und auch nicht auf dem Schreibtisch eines Kollegen vergessen.
Richtig, aber das gilt auch für Smartcard - Umgebungen. Allerdings finden wir den Verwaltungsaufwand mit Tokens (OTP) einfacher und übersichtlicher als eine PKI-Umgebung. Bei Verlust wirfst du den Token aus dem AD und der MA erhält einen Neuen. Ist ähnlich wie bei elektronischen Schließsysteme. Chip weg -> Chip löschen -> Fertig.Jeder Standort hat einige Tokens als Vorrat, welche aber nicht aktiviert sind. Bei Verlust wirft der Support den alten Token aus dem System und der Neue wird eingepflegt.
Grüße,
Dani
Hallo DWW,
OTP wäre "sicherer", soweit es speziell die Impersonation durch Reauthenfizierung mit erlangten Authentifizierungsmitteln verhindert.
Allerdings ist die Grundannahme, lediglich die Nutzerauthentifizierung sichern zu müssen, gegenüber der aufgeworfenen Bedrohung falsch. Der Angreifer hat lokale Admin-Rechte, kann daher zu SYSTEM aufsteigen und sich jeden User-Access-Token jedes Prozesses auf der Maschine aneignen.
Das Problem ist so nicht lösbar bzw. die Lösung lautet, keine Prozesse, deren Benutzerkontext nicht gekapert werden soll, auf einem mit höchsten Rechten kompromittierten System auszuführen.
Grüße
Richard
OTP wäre "sicherer", soweit es speziell die Impersonation durch Reauthenfizierung mit erlangten Authentifizierungsmitteln verhindert.
Allerdings ist die Grundannahme, lediglich die Nutzerauthentifizierung sichern zu müssen, gegenüber der aufgeworfenen Bedrohung falsch. Der Angreifer hat lokale Admin-Rechte, kann daher zu SYSTEM aufsteigen und sich jeden User-Access-Token jedes Prozesses auf der Maschine aneignen.
Das Problem ist so nicht lösbar bzw. die Lösung lautet, keine Prozesse, deren Benutzerkontext nicht gekapert werden soll, auf einem mit höchsten Rechten kompromittierten System auszuführen.
Grüße
Richard
Hi C.R.S.
Nein, es geht doch nicht um das Erlangen lokaler Rechte, sondern im schlimmsten Falle um das Kapern eines Domänenadmins.
Nein, es geht doch nicht um das Erlangen lokaler Rechte, sondern im schlimmsten Falle um das Kapern eines Domänenadmins.
Zitat von @DerWoWusste:
Hi C.R.S.
Nein, es geht doch nicht um das Erlangen lokaler Rechte, sondern im schlimmsten Falle um das Kapern eines Domänenadmins.
Hi C.R.S.
Nein, es geht doch nicht um das Erlangen lokaler Rechte, sondern im schlimmsten Falle um das Kapern eines Domänenadmins.
Schon klar, aber der lokale Admin kann nun mal nach Migration zum lokalen Systemkonto lokal vorhandene Token des Domain-Admins missbrauchen.
Deshalb ist grundsätzlich zu beachten, dass kein User lokale Admin-Rechte hat, alle lokalen Admin-Kennwörter verschieden sind (damit der lokal erfolgreiche Angreifer nicht auf eine andere Maschine ausweichen kann, auf der ein Prozess des Domain-Admins läuft) und generell nicht für jede Kleinigkeit ein Prozess als Domain-Admin läuft oder auf Zuruf gestartet wird.
In deinem Fall ist der Domain-Admin praktisch gekapert, sobald er sich anmeldet - egal womit.
Grüße
Richard
Ja, schon vollkommen klar. Nur bleibt die Möglichkeit, dass ein Nutzer Adminrechte hat, woher auch immer und einen Domänadminlogin, der sich, warum auch immer angemeldet hat, ausliest. Und nur dieses Szenario, wie auch immer es entsteht, wird hier diskutiert - wie kann ich erreichen, dass das Ausgelesene nicht ausreicht, um das Konto zu missbrauchen?
Dazu sammle ich hier Erfahrungen und hoffe Produktnamen zu hören und bestenfalls noch Vorgehensweisen und Aufwandseinschätzungen.
Ich verstehe Deine Aussage "In deinem Fall ist der Domain-Admin praktisch gekapert, sobald er sich anmeldet - egal womit" noch nicht. Zuvor schriebst Du schon "Die Authentifizierung über ein kompromittiertes System wird durch 2FA nicht sicherer wenn das System sowohl Token als auch PIN mit derselben Regelmäßigkeit bekommt wie vorher das Passwort" - beschreib doch bitte mal, wieso das so ist. Wenn der Angreifer den Token nicht in Händen hält, wie meldet er sich dann als Tokennutzer an?
Dazu sammle ich hier Erfahrungen und hoffe Produktnamen zu hören und bestenfalls noch Vorgehensweisen und Aufwandseinschätzungen.
Ich verstehe Deine Aussage "In deinem Fall ist der Domain-Admin praktisch gekapert, sobald er sich anmeldet - egal womit" noch nicht. Zuvor schriebst Du schon "Die Authentifizierung über ein kompromittiertes System wird durch 2FA nicht sicherer wenn das System sowohl Token als auch PIN mit derselben Regelmäßigkeit bekommt wie vorher das Passwort" - beschreib doch bitte mal, wieso das so ist. Wenn der Angreifer den Token nicht in Händen hält, wie meldet er sich dann als Tokennutzer an?
Hi,
aus dem Bauch raus würde ich sagen C.R.S meint eine Vorgehensweise ähnlich der hier beschriebenen: http://www.codeproject.com/Articles/35773/Subverting-Vista-UAC-in-Both- ...
Hat man die Möglichkeit Programme mit LocalSystem auszuführen, ist man in der Lage sich das Windows-Security Token des Benutzers (der sich grade angemeldet hat) abzugrapschen und Programme in dessen Security Kontext auszuführen.
Ein Softwareentwickler dürfte in der Lage sein, die genannten Schritte in der Frühstückspause nachzubauen.
aus dem Bauch raus würde ich sagen C.R.S meint eine Vorgehensweise ähnlich der hier beschriebenen: http://www.codeproject.com/Articles/35773/Subverting-Vista-UAC-in-Both- ...
Hat man die Möglichkeit Programme mit LocalSystem auszuführen, ist man in der Lage sich das Windows-Security Token des Benutzers (der sich grade angemeldet hat) abzugrapschen und Programme in dessen Security Kontext auszuführen.
Ein Softwareentwickler dürfte in der Lage sein, die genannten Schritte in der Frühstückspause nachzubauen.
Schön und gut, aber darum geht es nur bedingt. Es geht darum, dass er nicht nachträglich nach Abmeldung des Domadmins ein Tool anwirft, dass das Plaintext-Kennwort aus dem RAM ausliest (was möglich ist, bis der Rechner neu startet) und dieses dann nutzt. Deshalb soll eine zweite Authentifizierung neben dem Kennwort her.
Dass das Konto lokAdmin oder System in der Lage ist, irgendwas im Namen eines angemeldeten anderen zu tun, bleibt davon erst mal unbenommen. Versteh mich nicht falsch, es wird in die Überlegungen zur Absicherung natürlich mit einbezogen.
Dass das Konto lokAdmin oder System in der Lage ist, irgendwas im Namen eines angemeldeten anderen zu tun, bleibt davon erst mal unbenommen. Versteh mich nicht falsch, es wird in die Überlegungen zur Absicherung natürlich mit einbezogen.
Auch hier nochmal die Frage warum jemand das Kennwort auslesen sollte, wenn er Prinzipiell in der Lage ist Programme im Kontext eines Domain Admins auszuführen? Sobald dass passiert kann derjenige dasselbe Programm auf dem DC installieren.... Wozu sollte man dann noch ein Kennwort brauchen? LocalSystem auf einem DC dürfte auch ziemlich unbeeindruckt von irgendwelchen Smart Cards sein, und selbst wenn nicht, einfach warten bis sich der nächste anmeldet.
Mir gehts auch nicht darum dich von deinem/eurem Vorhaben abzubringen, ist ja euer Budget und euer Aufwand. Aus Security Sicht sehe ich nur einfach keine Verbesserung dadurch, deswegen der Vorschlag ob das Verfahrenstechnisch wirklich unumgänglich ist sich mit Domain Admin Rechten am Client anzumelden. Wo keine Anmeldung, da kein abgrapschen.
Im Falle eurer Entwickler wäre denkbar, dass die kein lokales Admin Konto haben sondern stattdessen auf eine VM in der sie Admin Rechte besitzen. Ist was an der VM kaputt einfach durch den Supporter eine neue machen lassen -> Keine Domain Admin anmeldung nötig.
Mir gehts auch nicht darum dich von deinem/eurem Vorhaben abzubringen, ist ja euer Budget und euer Aufwand. Aus Security Sicht sehe ich nur einfach keine Verbesserung dadurch, deswegen der Vorschlag ob das Verfahrenstechnisch wirklich unumgänglich ist sich mit Domain Admin Rechten am Client anzumelden. Wo keine Anmeldung, da kein abgrapschen.
Im Falle eurer Entwickler wäre denkbar, dass die kein lokales Admin Konto haben sondern stattdessen auf eine VM in der sie Admin Rechte besitzen. Ist was an der VM kaputt einfach durch den Supporter eine neue machen lassen -> Keine Domain Admin anmeldung nötig.
So, mal etwas langsamer bitte.
Erkläre bitte, wie er nach Abmeldung des Domänenadmins noch als dieser handelt, wenn 2-factor-auth. etabliert ist. Ich will nicht bezweifeln, dass es theoretisch zumindest geht, aber verstehe nicht, wie.
Erkläre bitte, wie er nach Abmeldung des Domänenadmins noch als dieser handelt, wenn 2-factor-auth. etabliert ist. Ich will nicht bezweifeln, dass es theoretisch zumindest geht, aber verstehe nicht, wie.
Nicht nach der Abmeldung, Währenddessen.
Ok, folgendes Szenario: Der Entwickler bastelt sich einen Lokalen Dienst, der die beschriebene Funktion nutzt.
Der Dienst wartet nun darauf, dass sich jemand mit Domain Admin Rechten anmeldet und authentifiziert (zu diesem Zeitpunkt hängt ja auch ein eventuell benötigtes Hardware Token am PC sonst könnte der Supporter ja selber auch ncihts machen) sind diese Bedingungen erfüllt, lässt er, noch während der Supporter angemeldet ist, denselben Dienst zum Beispiel auf dem DC installieren, wobei die Installation unter dem Kontext des gerade angemeldeten Supporters durchgeführt wird (mit dessen Windows Security Token).
Der Supporter meldet sich irgendwann ab. Na und? Eine "Backdoor" ist ja jetzt schon auf dem DC drauf.
Ok, folgendes Szenario: Der Entwickler bastelt sich einen Lokalen Dienst, der die beschriebene Funktion nutzt.
Der Dienst wartet nun darauf, dass sich jemand mit Domain Admin Rechten anmeldet und authentifiziert (zu diesem Zeitpunkt hängt ja auch ein eventuell benötigtes Hardware Token am PC sonst könnte der Supporter ja selber auch ncihts machen) sind diese Bedingungen erfüllt, lässt er, noch während der Supporter angemeldet ist, denselben Dienst zum Beispiel auf dem DC installieren, wobei die Installation unter dem Kontext des gerade angemeldeten Supporters durchgeführt wird (mit dessen Windows Security Token).
Der Supporter meldet sich irgendwann ab. Na und? Eine "Backdoor" ist ja jetzt schon auf dem DC drauf.
Ich kann die Gedankengänge nachvollziehen. Wäre diese Backdoor aber nutzbar?
Auf dem DC startet dann mit dem Kennwort des Domadmins ein Prozess, der aber wiederum diesen Token (den 2. Authentifizierungsfaktor) braucht - wie fordert er denn die PIN an?
Selbst wenn sich ein Domadmin lokal am DC angemeldet hat und einen Token stecken hat und die PIN dazu eingegeben hat, würde der Backdoorprozess diese PIN anfordern müssen (nach meinem Verständnis) und zwar interaktiv eingegeben - und diese unerklärliche PIN-Abfrage ließe ihn auffliegen.
Auf dem DC startet dann mit dem Kennwort des Domadmins ein Prozess, der aber wiederum diesen Token (den 2. Authentifizierungsfaktor) braucht - wie fordert er denn die PIN an?
Selbst wenn sich ein Domadmin lokal am DC angemeldet hat und einen Token stecken hat und die PIN dazu eingegeben hat, würde der Backdoorprozess diese PIN anfordern müssen (nach meinem Verständnis) und zwar interaktiv eingegeben - und diese unerklärliche PIN-Abfrage ließe ihn auffliegen.
bei SmartCards/Dongles kannst du angeben, dass der Benutzer abgemeldet wird, sobald der Tokken abgezogen wird - ev. wird damit auch aktiv der Windows Security Tokken als ungültig gekennzeichnet. (kenn mich mit den Windows tiefen aber nicht aus.)
Moin,
dazu kommt, dass das Passwort aus Token und PIN nur 30 Sekunden Gültigkeit hat. Wir haben uns für OTP-Token entschieden, die nicht mit Rechner/Notebook verbunden werden.
Grüße,
Dani
dazu kommt, dass das Passwort aus Token und PIN nur 30 Sekunden Gültigkeit hat. Wir haben uns für OTP-Token entschieden, die nicht mit Rechner/Notebook verbunden werden.
Grüße,
Dani
Vielleicht nicht ganz ersichtlich: Mit den "Token" in meinen letzten beiden Beiträgen sind die Windows-User-Access-Token (Impersonation/Delegation, hier insbesondere der Delegation Token einer Anmeldung) gemeint, die einen Prozess für einen bestimmten Nutzer authentifizieren. Mit dem Token im ersten Beitrag dagegen ein USB-Token bzw. eine Smartcard.
Deine Frage setzt die Prämisse, ein Angreifer würde Impersonation durch Reauthentifizierung betreiben, also sich das Passwort/die Authentifizierungsmittel aneignen, um sich als der entsprechende User auszugeben.
Unter der Prämisse habe ich mich am 12.10. auf den Hinweis beschränkt, dass die Nichtverfügbarkeit des Authentifizierungsmittels für den Angreifer bei 2FA meist überschätzt wird. Die Frage ist inhaltlich verwandt mit der hier: Zertifikate auf Android Gerät ablegen - sicher?
Bei Smartphones wird das Problem besonders deutlich: Verwendet wird meist eine MicroSD-Smartcard, die dauerhaft im Handy verbleibt. Die Pin kann auf dem Handy nicht sicher eingegeben werden. Wer das Smartphone konrolliert, verfügt also über Pin und Smartcard. Insoweit besteht (auf dem Handy) kein Sicherheitsvorteil der Smartcard gegenüber dem Android-Keystore, auch wenn aus der Smartcard die Schlüssel nur ungleich schwerer zu extrahieren sind. Solange das Smartphone für seine Aktionen ausreichend verfügbar ist und es auf die benötigten Dienste zugreifen kann, hat der Angreifer gar kein Interesse, die Schlüssel zu extrahieren. Zudem bedarf jede externe Verwendung von Authentifizierungsmitteln einer plausiblen Deckung. Die Impersonation auf dem Smartphone ist dagegen unauffällig, weil scheinbar immer der Berechtigte handelt, und nicht jemand, der z.B. an einer ganz anderen Stelle als üblich auf das Netzwerk zugreift.
Nun gilt für den Desktop dasselbe. Wenn der Domain-Admin seinen USB-Token an das kompromittierte System anschließt und die Pin eingibt, authentifiziert er sich erst mal selbst. Aber unmittelbar danach ist der Token immer noch am System und der Angreifer kann ihn natürlich mit der eben abgegriffenen Pin nutzen, um selbst einen Prozess als Domain-Admin zu starten. Kein Unterschied zum Passwort. Erweiterte Angriffe mit USB-over-IP-Dienste sieht man in den beliebten Konfigurationen, bei denen die User gesperrt werden, wenn sie die Smartcard abziehen, also die Smartcards immer an den Systemen hängen.
Dieses Problem wäre grundsätzlich gelöst, wenn OTP eingesetzt wird, weil das erlangte Passwort verbraucht ist. Oder der Domain-Admin nutzt einen Kartenleser mit Tastatur, den er an fremde Arbeitsplätze mitbringt und bei dessen Bedienung er immer unbeobachtet ist.
Der Punkt ist aber, und das wollte ich ab deiner Rückfrage erläutern: So würde das ein Angreifer hier nie machen.
Die oben genannte Prämisse ist insoweit falsch, nicht praxisnah oder zumindest optimistisch. Der Angreifer würde sich kein Nutzer-Authentfizierungsmittel aneignen sondern ein systeminternes, den Token.
Er bekommt in dem gestellten Szenario einen Prozess des Domain-Admins auf dem System, auf dem er System-User ist. Er würde folglich eine Local-to-Domain-Escalation machen, wie sie jeder Pentester macht, wenn er einen solchen Prozess glücklich gefunden hat. D.h. während oder noch bevor der Domain-Admin ran geht, startet er ein Skript als SYSTEM, das auf den User-Token eines Domain-Admins wartet, den übernimmt und als Domain-Admin macht, was immer er will.
Grüße
Richard
Deine Frage setzt die Prämisse, ein Angreifer würde Impersonation durch Reauthentifizierung betreiben, also sich das Passwort/die Authentifizierungsmittel aneignen, um sich als der entsprechende User auszugeben.
Unter der Prämisse habe ich mich am 12.10. auf den Hinweis beschränkt, dass die Nichtverfügbarkeit des Authentifizierungsmittels für den Angreifer bei 2FA meist überschätzt wird. Die Frage ist inhaltlich verwandt mit der hier: Zertifikate auf Android Gerät ablegen - sicher?
Bei Smartphones wird das Problem besonders deutlich: Verwendet wird meist eine MicroSD-Smartcard, die dauerhaft im Handy verbleibt. Die Pin kann auf dem Handy nicht sicher eingegeben werden. Wer das Smartphone konrolliert, verfügt also über Pin und Smartcard. Insoweit besteht (auf dem Handy) kein Sicherheitsvorteil der Smartcard gegenüber dem Android-Keystore, auch wenn aus der Smartcard die Schlüssel nur ungleich schwerer zu extrahieren sind. Solange das Smartphone für seine Aktionen ausreichend verfügbar ist und es auf die benötigten Dienste zugreifen kann, hat der Angreifer gar kein Interesse, die Schlüssel zu extrahieren. Zudem bedarf jede externe Verwendung von Authentifizierungsmitteln einer plausiblen Deckung. Die Impersonation auf dem Smartphone ist dagegen unauffällig, weil scheinbar immer der Berechtigte handelt, und nicht jemand, der z.B. an einer ganz anderen Stelle als üblich auf das Netzwerk zugreift.
Nun gilt für den Desktop dasselbe. Wenn der Domain-Admin seinen USB-Token an das kompromittierte System anschließt und die Pin eingibt, authentifiziert er sich erst mal selbst. Aber unmittelbar danach ist der Token immer noch am System und der Angreifer kann ihn natürlich mit der eben abgegriffenen Pin nutzen, um selbst einen Prozess als Domain-Admin zu starten. Kein Unterschied zum Passwort. Erweiterte Angriffe mit USB-over-IP-Dienste sieht man in den beliebten Konfigurationen, bei denen die User gesperrt werden, wenn sie die Smartcard abziehen, also die Smartcards immer an den Systemen hängen.
Dieses Problem wäre grundsätzlich gelöst, wenn OTP eingesetzt wird, weil das erlangte Passwort verbraucht ist. Oder der Domain-Admin nutzt einen Kartenleser mit Tastatur, den er an fremde Arbeitsplätze mitbringt und bei dessen Bedienung er immer unbeobachtet ist.
Der Punkt ist aber, und das wollte ich ab deiner Rückfrage erläutern: So würde das ein Angreifer hier nie machen.
Die oben genannte Prämisse ist insoweit falsch, nicht praxisnah oder zumindest optimistisch. Der Angreifer würde sich kein Nutzer-Authentfizierungsmittel aneignen sondern ein systeminternes, den Token.
Er bekommt in dem gestellten Szenario einen Prozess des Domain-Admins auf dem System, auf dem er System-User ist. Er würde folglich eine Local-to-Domain-Escalation machen, wie sie jeder Pentester macht, wenn er einen solchen Prozess glücklich gefunden hat. D.h. während oder noch bevor der Domain-Admin ran geht, startet er ein Skript als SYSTEM, das auf den User-Token eines Domain-Admins wartet, den übernimmt und als Domain-Admin macht, was immer er will.
Grüße
Richard
Ich denke diese Backdoor wäre ohne weiteres nutzbar und würde, einmal installiert, auch keine Authentifizierung mehr brauchen. Mit Domain Admin Rechten lässt sich schliesslich auf dem DC Ein Dienst einrichten, der wiederum mit LocalSystem des DCs arbeitet. Und LocalSystem wirst du kaum überreden können eine Smartcard zu benutzen und ein Pinfenster auszufüllen.
Damit wäre der "kritische" Punkt, die Installation auf dem DC selbst. Hat sich der Supporter aber einmal authentifiziert, wird er kaum bei jedem Programmstart den er tätigt nochmal nach dem Pin gefragt werden, kann also für die Dauer der Sitzung beliebige Aktionen ausführen. Dasselbe gilt dann auch für Programme die in seinem Kontext laufen, also den Backdoor-Installer. Der Dienst auf dem Client bräuchte daher nur zu warten, bis der Supporter auch die 2. Authentifizierung durchgeführt hat.
Selbst wenn für jeden zu startenden Prozess eine erneute Pineingabe verlangt wird (was die Supporter definitiv in den Wahnsinn führt) wäre auch das händelbar da der lokal installierte Dienst mühelos die Tastatureingaben aufsammeln könnte und beim aufpoppen des Fenster selber ausfüllen. Der Supporter würde also bestenfalls ein für den Bruchteil einer Sekunde aufblitzendes Fenster bemerken, wenn überhaupt.
Damit wäre der "kritische" Punkt, die Installation auf dem DC selbst. Hat sich der Supporter aber einmal authentifiziert, wird er kaum bei jedem Programmstart den er tätigt nochmal nach dem Pin gefragt werden, kann also für die Dauer der Sitzung beliebige Aktionen ausführen. Dasselbe gilt dann auch für Programme die in seinem Kontext laufen, also den Backdoor-Installer. Der Dienst auf dem Client bräuchte daher nur zu warten, bis der Supporter auch die 2. Authentifizierung durchgeführt hat.
Selbst wenn für jeden zu startenden Prozess eine erneute Pineingabe verlangt wird (was die Supporter definitiv in den Wahnsinn führt) wäre auch das händelbar da der lokal installierte Dienst mühelos die Tastatureingaben aufsammeln könnte und beim aufpoppen des Fenster selber ausfüllen. Der Supporter würde also bestenfalls ein für den Bruchteil einer Sekunde aufblitzendes Fenster bemerken, wenn überhaupt.
Ok, danke für die Mühe und Dein Punkt ist auch verständlich geworden.
Ich möchte das hiermit abschließen, da ich fürchte, dass der Umfang der Folgediskussion ausarten wird.
Mich würde freuen, wenn jsysde noch in Erfahrung bringen könnte, was in der vorigen Firma etabliert wurde (falls Du mir diesen Gefallen tun magst), damit ich mich sowohl bei dem als auch bei Danis Anbieter mal informieren kann, wie die Anbieter den Sachverhalt sehen.
--
PS: Dass hier Domänenadmins für 0815-Support genutzt werden, ist nicht gegeben, keine Sorge. Es wäre nur potentiell möglich (interaktiver Login von Domadmins ist nirgendwo unterbunden).
Ich möchte das hiermit abschließen, da ich fürchte, dass der Umfang der Folgediskussion ausarten wird.
Mich würde freuen, wenn jsysde noch in Erfahrung bringen könnte, was in der vorigen Firma etabliert wurde (falls Du mir diesen Gefallen tun magst), damit ich mich sowohl bei dem als auch bei Danis Anbieter mal informieren kann, wie die Anbieter den Sachverhalt sehen.
--
PS: Dass hier Domänenadmins für 0815-Support genutzt werden, ist nicht gegeben, keine Sorge. Es wäre nur potentiell möglich (interaktiver Login von Domadmins ist nirgendwo unterbunden).
Bitboy, Dir auch vielen dank für Deine Mühe.
N'Abend.
Ein ehemaliger Kollege hatte beim letzten Treffen im Biergarten einen RSA-Token am Schlüsselbund, also scheinen die dort wohl zum Einsatz kommen. Ich triggere ihn mal an, mal schauen, ob und was er an Infos rausrückt.
Cheers,
jsysde
Mich würde freuen, wenn jsysde noch in Erfahrung bringen könnte, was in der vorigen Firma etabliert wurde (falls Du mir
diesen Gefallen tun magst), damit ich mich sowohl bei dem als auch bei Danis Anbieter mal informieren kann, wie die Anbieter den
Sachverhalt sehen.
diesen Gefallen tun magst), damit ich mich sowohl bei dem als auch bei Danis Anbieter mal informieren kann, wie die Anbieter den
Sachverhalt sehen.
Ein ehemaliger Kollege hatte beim letzten Treffen im Biergarten einen RSA-Token am Schlüsselbund, also scheinen die dort wohl zum Einsatz kommen. Ich triggere ihn mal an, mal schauen, ob und was er an Infos rausrückt.
Cheers,
jsysde
1
Hi psannz.
Exzellent. Das sind gute Neuigkeiten und diese passen genau zur Problemstellung. 8.1 ist eine Option für uns.
Exzellent. Das sind gute Neuigkeiten und diese passen genau zur Problemstellung. 8.1 ist eine Option für uns.
Bin auch grad massiv am überlegen ob ich bei den verbleibenden XP und Vista Rechnern statt auf 7 gleich auf 8.1 mit ClassicShell wechsel. Hat sich eben schon gewaltig viel getan.
Moin Dani.
Habe gerade mit der Technik von Vasco telefoniert und sie haben mir ausdrücklich versichert, dass Ihre Systeme ungeeignet sind, dagegen zu schützen, dass jemand Pass-the-Hash oder ähnliche Attacken fährt, also gegen die im RAM gespeicherten credentials. Nun gut, wir werden uns etwas ausdenken, ich halte hier weiter auf dem Laufenden.
Habe gerade mit der Technik von Vasco telefoniert und sie haben mir ausdrücklich versichert, dass Ihre Systeme ungeeignet sind, dagegen zu schützen, dass jemand Pass-the-Hash oder ähnliche Attacken fährt, also gegen die im RAM gespeicherten credentials. Nun gut, wir werden uns etwas ausdenken, ich halte hier weiter auf dem Laufenden.
