Account Typen

Account Typen Registry 1	Account Typen Registry 2	Account shared	Private Data	Account never expires	Password never expires	Login von außerhalb (ssh, vpn)	Zugang Intranet → Internet	Compromised Account will be blocked without discussion	Compromised Account will be blocked only after discussion	Approval required (D4)	Intended Purposes Examples
Primary		no	allowed	no	no	allowed	yes	yes	no	no
	Primary	no	allowed	no	no	allowed	yes	yes	no	no	always first account for a person
Personal		no	allowed	no	no	allowed	yes	yes	no	no
	Personal	no	allowed	no	no	allowed	yes	yes	no	no	admin accounts
Functional		yes	no	allowed	allowed	not allowed	?	?	?	no
	Functional	yes	no	no	no	not allowed	yes	yes	no	no	temporary guests, students, temporary services, e.g. conferences, group accounts
	Shared	yes	no	allowed	allowed	not allowed	yes	yes	no	no	shared data, email addresses, lab operation, e.g. measurements, automation solutions
	Service	yes	no	yes	yes	not allowed	no	no	yes	yes	accelerator and experiment controls, services for important infrastructure

zur Diskussion:

keine Verwendung des Begriffs Lightweight Account mehr, führt nur zur Verwirrung,
besser sinngemäß von minimal gefordertem Set an Attributen sprechen
Einführung eines weiteren Account Typen, service benötigt approval
Kein freies Setzen von ANE oder PNE über alle Account Typen, kein setzen von ANE oder PNE via Blueprint, um Mißbrauch zu unterbinden
Defaults für ANE und PNE für Shared stehen noch zur Diskussion
Approval für Service Accounts für ganze Namespaces wie MCA möglich
Kann man einen Account gleichzeitig mehr als einem Blueprint zuordnen?
Sind die Einsatzgebiete der Account Typen passend beschrieben?
Sollen Gruppenaccounts für temporär Gäste, Praktikanten, Studenten etc. abgeschafft werden?
Mahnungen / Erinnerungen an User nur an User und RT Mailadresse (statt individueller Mailadressen)
Kann man auf Account never expires evtl. komplett verzichten? (FS kann, Maschinenkontrollen, Infrastrukturdienste?)