Absicherung geteilter Benutzerkonten (Active Directory)

[charmin]

Moin zusammen,

ich beschäftige mich aktuell damit die diversen Probleme unseres ADs anzugehen. Ein großer Punkt sind dabei für mich die geteilten Benutzerkonten in der Produktion (Industrieunternehmen). Mit meiner Suche bin ich bisher leider nicht weit gekommen, mehr als "geteilte Konten sind böse" finde ich nicht (ist ja grundsätzlich auch richtig, lässt sich aber nunmal nicht immer vermeiden). Meine Frage daher ob hier jemand Erfahrungen damit hat solche Konten ordentlich abzusichern (z.B. via 2FA). Würde mich über Ideen und Vorschläge freuen.

 

[Madman1209]

Hi,

• wieso lässt es sich nicht vermeiden?
• was verstehst du unter "ordentlich absichern"? Wogegen bzw. wofür? Was soll vermieden oder erreicht werden?

VG,
Mad

 

[charmin]

@Madman1209

Zu Punkt 1.):

• Anlagen und Maschinen die wir nicht in der Hand haben
• Häufe Mitarbeiter/Schichtwechsel
• Messgeräte mit vorgeschriebenen Benutzerkonten vom Hersteller
• Unregelmäßige PC Nutzung die dazu führt das Passwörter doch wieder als PostIt am Monitor hängen
• Mitarbeiter die mit z.B. Benutzerwechsel und eigenem komplexen Passwort überfordert sind
• Uralte Programme die das nicht unterstützen

Zu Punkt 2.):

• Keine Passwörter (Authentifizierung via Token, Karte, ...)
• Zuordnung Mitarbeiter zu Account um ggf. Identifizierung zu ermöglichen

 

[Madman1209]

Hi,

Windows Hello? Wäre vermutlich das Einfachste. Warum es immer der gleiche Account sein muss verstehe ich trotz allem nicht.

VG,
Mad

 

[error]

Moin,

"Funktionsuser/ geteilte Accounts" sollte nur die nötigsten Rechte haben. Absichern mit 2 Faktor usw. wird nichts bringen. Sobald mehrere das Passwort kennen, wird es schwierig.

@Madman1209
Zu Punkt 1.):

• Anlagen und Maschinen die wir nicht in der Hand haben
• Häufe Mitarbeiter/Schichtwechsel
• Messgeräte mit vorgeschriebenen Benutzerkonten vom Hersteller
• Unregelmäßige PC Nutzung die dazu führt das Passwörter doch wieder als PostIt am Monitor hängen
• Mitarbeiter die mit z.B. Benutzerwechsel und eigenem komplexen Passwort überfordert sind
• Uralte Programme die das nicht unterstützen

Sobald die Maschinen Windows haben, kannst du Sie auch mehr oder weniger in die Domäne einbinden. Entweder geht das oder die Maschinen können auch autark arbeiten. Falls ein Fernzugriff erfolgen muss, kann dieser auch auf Netzwerkebene gesichert werden indem die Kommunikation der Maschine eingeschränkt wird.
Für Messgeräte gilt dasselbe. Oder diese müssen nicht in das AD da sie sowieso nur von authorisiertem Fachpersonal bedient werden.
Gegen das PostIT kannst du wenig machen außer Accounts sperren wenn du so etwas siehst.
Das Thema "überforderte Mitarbeiter" ist nicht deine Aufgabe. Das müssen andere Hirachien lösen.
Uralte Programme können isoliert laufen z.B. auf PCs ohne Netzwerkzugriff oder über das Netzwerk mit abgeschotteter Kommunikation.

@Madman1209
Zu Punkt 2.):

• Keine Passwörter (Authentifizierung via Token, Karte, ...)
• Zuordnung Mitarbeiter zu Account um ggf. Identifizierung zu ermöglichen

In dem Fall keine Funktionsaccounts

gruß

 

[Der_kleine_Nils]

Hi Charmin,
wir haben bei uns einen Kiosk-Modus etabliert, bei dem nur das Service-Konto und das Programm, auf das alle zugreifen müssen, läuft.

Das ganze wird im AD mit einer eigenen Computer-OU für die Policy-Verteilung eingerichtet.

Funktioniert auch dann gut, wenn die notwendigen Programme ein eigenes User-Anmeldesystem haben; aber der ideale Einsatzzweck ist natürlich eher bei Systemen, die einfach immer im Hintergrund laufen müssen und alle mal draufschauen müssen, z.B. Monitoringsysteme.

Technische Einzelheiten kann ich Dir leider nicht nennen, aber es ist eine gute Lösung, die bis zur Etablierung aber u.U. einiges an Testzeit in Anspruch nimmt - wenn es dann aber erst einmal läuft thumbs up

Viele Grüße
Der_kleine_Nils

 

[Raijin]

Die Frage ist was am Ende überhaupt erreicht werden soll. Geht es darum, dass der eine oder andere Nutzer Änderungen am System macht, die man natürlich wieder rückgängig machen will, dann geht's in Richtung Kiosk-System oder zB den Write Filter von Windows selbst, der alle Schreibzugriffe auf das geschützte Laufwerk im RAM vorhält und beim Neustart verwirft. Dadurch ist sichergestellt, dass spätestens nach einem Reboot alles wieder funktioniert, wenn irgendwer dran rumgefummelt hat.

Oder geht es wirklich darum, dass jeder einzelne Nutzer eindeutig identifiziert werden kann, weil dieser dann ggfs unterschiedliche Berechtigungen am PC und/oder in anderen Programmen bekommen soll? Das wäre zumindest an unseren Industrieanlagen bei den Kunden wenig zielführend, weil da mehrere Operator quasi gleichzeitig an denselben Panels arbeiten müssen, schnell und beliebig abwechselnd. Die wären sonst nur noch mit Einloggen beschäftigt....

Gegen die Weitergabe von Logins, sei es mit PostITs oder sonstwie, kannst du wenig tun. Das ist nun mal die Schwachstelle Mensch, die kein Sicherheitsmechanismus auf dieser Erde vollständig eliminieren kann.

 

[t-6]

Ein paar Ideen in den Raum geworfen:

• eigenes VLAN für PCs die mit generischen Funktionsaccounts arbeiten müssen; Zugriff auf andere Netze/Ressourcen auf das allernötigste einschränken (default deny)
• eigene OU für die entsprechenden Bereiche; eigene GPOs
• Applocker bzw. Anwendungs-Whitelist über GPOs erzwingen
• bei gestellten PCs: eigenes VLAN das nirgendwo hin kann & den Hersteller machen lassen
• bei Anwendungen die "unbedingt" mit lokalen Admin-Rechten gestartet werden müssen,:
  • genauestens hinterfragen ob sie das wirklich brauchen
  • mit Process Monitor & Co. mal ganz genau nachschauen wo die Anwendung reingreift & entsprechend granulare ACLs setzen --> hierbei vorsichtig sein dass der Herstellersupport nicht einem einen Vogel zeigt wenn das rauskommt
  • ggf. die Anwendung/Hersteller rauswerfen

====

Letztens auch wieder so einen Fall gehabt: Bei einem Kunden wird z. Z. Sophos Endpoint + Intercept X ausgerollt.
Bei neu provisionierten PCs funktioniert eine wichtige Anwendung nicht mehr. Intercept X hält die Anwendung direkt an.

Ursache:

• Doppelklick auf die Verknüpfung startet irgendeinen Java-Webstart-Dummfug
• Java-Webstart-Fugbla initialisiert Browser
• Browser lädt ein anderes Java-Fiddelding vom Anwendungsserver runter
• dieses nächste Java-Hammelgrampf lädt eine .exe-Datei in ein temporäres Verzeichnis im AppData-Verzeichnis des gerade angemeldeten Benutzers herunter und startet sie von da aus

Wenn es wie eine Malware läuft, wie eine Malware schwimmt und wie eine Malware quackt, ist es LOB-Software.