Bilaga 1 Benämning Utredning AD namnstandards Ansvarig Pelle Lindé, IT-strategiska avd Nils Byström, Avd f IT och inköp Marcus Torstensson, Atea Skapat Senast sparat 2008-10-30 11:22 2009-03-26 14:09 Projekt AD-design Uppsala universitet DiarieNr UFV 2009/413 Revision 1.7 Filnamn AD-namnstandard AD-design UU 1.7.doc Active Directory Namnstandard
Innehållsförteckning 1 Namnstandard för user.uu.se...3 1.1 syfte...3 1.2 Användarkonton...3 1.2.1 Studenter och personal...3 1.2.2 Administrativa konton, servicekonton och lokala konton...3 1.3 Datorkonton...3 1.3.1 Rekommendation...4 1.4 Servrar...4 1.5 Skrivare...4 1.6 Säkerhets- och distributionsgrupper...4 1.6.1 Rekommendation...4 1.7 Group Policy Objects...4 1.7.1 Rekommendation...5 1.8 Befintliga resurser som ej kan byta namn...5 2
1 Namnstandard för user.uu.se 1. 1 S Y F T E Syftet med detta dokument är att definiera krav och rekommendationer beträffande namnsättning av objekt och komponenter i den AD-design som framtagits av Uppsala universitet. 1. 2 A N V Ä N D A R K O N T O N 1.2.1 Studenter och personal Konton som hanteras av AKKA namnsätts enligt AKKA-standard. Användarkategori Pos 1-2 Pos 3-4 Pos 5-8 Studentkonton Två första i förnamn Två första i efternamn Autogenererat löpnummer Exempel: angu0756 Användarkategori Pos 1-3 Pos 4-5 Pos 6-8 Personalkonton Tre första i förnamn Två första i efternamn Autogenererat löpnummer Exempel: anigu204 1.2.2 Administrativa konton, servicekonton och lokala konton Konton i topp- eller underdomäner som ej finns i AKKA. Institutionsprefixet kan ersättas av prefix för intendentur- eller annan funktionell enhet om så krävs. Användarkategori Pos 1-4 Pos 5-6 Pos 7-8 Pos 9-10 Administrativa konton adm + _ Två första i Två första i Löpnr förnamn efternamn Exempel: adm_angu02 Användarkategori Pos 1-n Pos n+1-2 Pos n+3-4 Pos n+5-6 Lokala konton Instprefix + _ Två första i förnamn Exempel: genpat_angu01, uadm_rony03 Två första i efternamn Löpnr 1. 3 D A T O R K O N T O N Datorer och namnsättning av dessa hanteras på institutions- och förvaltningsnivå. Däremot är det ett krav att datornamnen inleds med institutionsprefix, för att lätt kunna hitta och adressera klienter i AD. 3
Så långt som möjligt bör namnstandarder och namnsättning automatiseras. Att bygga datornamn på värden som går att plocka fram programmatiskt är effektivt vid hantering av t ex om- och nyinstallationer. Förslag på namnstandard: Organisation L = Laptop D = Desktop Löpnummer Exempel Institutionsprefix D 0001 GENPAT-D00001 L 0001 ITS-L00003 1.3.1 Rekommendation För att inte tappa spårbarheten beträffande just vilken användare som använder datorn kan ett attribut som heter managed by dvs. vem bestämmer/äger/har en relation till aktuell dator användas. Detta värde lever kvar så länge datorobjektet finns i Active Directory eller ändras manuellt eller per automatik. Med hjälp av detta attribut skapas en logisk relation mellan dator objektet och användaren. Vid en förändring av huvudanvändare behöver ITansvarig bara ändra detta förhållande i Active Directory så är den nya relationen mellan dator och användare klar. 1. 4 S E R V R A R Servrar hanteras på institutions- eller motsv. nivå. Ett krav är att servernamnen inleds med institutionsprefix. 1. 5 S K R I V A R E Skall inledas med institutionsprefix. 1. 6 S Ä K E R H E T S - O C H D I S T R I B U T I O N S G R U P P E R Skall inledas med institutionsprefix. 1.6.1 Rekommendation Följande namnsättning kan användas för att kategorisera de olika grupptyperna. Appl Role Dir Dist Proj Används för att gruppera användare/datorer för behörighet till applikationer. Används för att gruppera användare efter roll. Används för att gruppera användare för filbehörighet på mappar. (arv från Novell) Används för att gruppera användare i distributionsgrupper för Exchange. Används för att gruppera användare i vissa projekt. 1. 7 G R O U P P O L I C Y O B J E C T S Group Policies ska alltid inledas med institutionsprefix. Namnsättningen bör sedan antyda syfte och vad som påverkas med policyn. Om GPO:er utan institutionsprefix påträffas i domänen kommer de att tas bort direkt. 4
1.7.1 Rekommendation Först anges om policyn reglerar dator- eller användarinställningar. Därefter anges grundsyftet med policyn. Dessa beskrivningar kan komma att ändras med tiden, därför ges enbart några exempel på dessa. Det är upp till den som ansvarar för skapandet av policyn att bestämma detta. Sedan anges vilken resurs som påverkas och därefter anges version på policyn. För att säkerställa spårbarhet i de förändringar som sker bör policys versionshanteras. Innan en förändring av en policy sker bör en ny policy skapas med ett högre versionsnummer och därefter byts den gamla policyn ut mot den nya med ett högre versionsnummer. Gamla polycier exporteras till en backup-katalog på disk och tas sedan bort ur domänen då de inte längre används. Ett skript kommer även att kunna spåra eventuella GPO:er som inte används under en längre period. Dessa inaktiva polycier kommer precis som i fallet med gamla polycier att avlägsnas ur domänen. Institutionsprefix Användar- eller datorinställningar Beskrivning vad policyn gör Vilken resurs som påverkas Version på policyn Ex ITS + - U eller C U=User C=Computer Ex Baseline,HighSec NoFirewall Laptop, Desktop, Server Ver1 Ver2 Exempel: ITS-UBaselineLaptopVer1, BMC-CBaselineServerVer3, ITS-CHighlyManagedDesktopVer1 1. 8 B E F I N T L I G A R E S U R S E R S O M E J K A N B Y T A N A M N Det finns resurser som inte kan byta namn. Det kan vara instrument, servrar för datainsamling, licenshanterare mm. Dessa måste hanteras i särskild ordning vid migrering och fortsatt användning framöver. De resurser som verkligen inte kan byta namn skall få användas fortsättningsvis. Ansvarig institution eller motsvarande skall kunna redovisa skäl varför namnbyte inte går att genomföra till systemförvaltaren av AD. 5