Det här kapitlet bör studeras av dem som är involverade i installation och underhåll av SEAM. Här tas ett antal frågor kring installation och konfiguration upp, frågor som du måste ta ställning till innan du installerar eller konfigurerar SEAM.
Här följer en lista över frågor som bör ses över av systemadministratören eller någon annan erfaren tekniker:
Innan du installerar SEAM måste du ta ställning till ett antal konfigurationsfrågor. Även om det inte är omöjligt att ändra konfigurationen efter den ursprungliga installationen, så blir det besvärligare för varje ny klient som läggs till i systemet. Dessutom kräver vissa ändringar en fullständig ominstallation, så det bästa är att försöka planera för framtida behov.
En användarkategori är ett logiskt nätverk, ungefär som en domän, som definierar en grupp system under samma huvud-KDC. Precis som vid hantering av DNS-domäner, bör frågor om användarkategorins namn, antal och storlek för varje användarkategori samt förhållandet mellan en användarkategori och övriga kategorier besvaras innan SEAM installeras.
Namn på användarkategorier kan bestå av vilken ASCII-sträng som helst. Normalt är namnet samma som namnet på DNS-domänen, med versaler. Detta gör det enklare att skilja problem med SEAM från problem med DNS-namnutrymmet, förutom att namnet också är känt sedan tidigare. Om du inte använder DNS eller väljer att använda en annan sträng, kan detta vara vilken sträng som helst även om det är klokt att använda användarkategorinamn som följer standardnamnstrukturen på internet.
Antalet användarkategorier som krävs för din installation beror på flera faktorer:
Antalet klienter som ska stödjas. För många klienter i en användarkategori försvårar administrationen och kommer till slut att innebära att en delning av användarkategorin är nödvändig. De huvudsakliga faktorerna som bestämmer antalet klienter som kan stödjas är: Mängden SEAM-trafik som genereras av varje klient, bandbredden på det fysiska nätverket och hastigheten hos värdarna. Eftersom varje installation kommer att ha olika begränsningar finns det ingen regel för att bestämma det maximala antalet klienter.
Hur långt det är mellan klienterna. Det kan vara en god idé att ange flera små användarkategorier om klienterna befinner sig i olika geografiska regioner.
Antalet värdar som finns tillgängliga för att installeras som KDC:er. Varje användarkategori bör ha åtminstone två KDC-servrar (huvudserver och slav).
När du konfigurerar flera användarkategorier, måste du bestämma hur de ska sammanlänkas. Du kan etablera en hierarkisk relation mellan användarkategorierna vilket automatiskt ger sökvägarna till de relaterade domänerna, men som kräver att alla användarkategorier i den hierarkiska strukturen är riktigt konfigurerade. De automatiska sökvägarna kan lätta på administrationsbördan. Om det däremot finns domäner i flera nivåer, kanske du inte vill använda standardsökvägen eftersom den skulle kräva för många transaktioner.
Du kan också välja att etablera anslutningen direkt. En direktanslutning är som mest användbar när det finns för många nivåer mellan två hierarkiska domäner eller när det inte finns något hierarkiskt förhållande. Anslutningen måste definieras i /etc/krb5/krb5.conf på alla värdar som använder den, vilket kräver en del extra arbete. En introduktion till flera användarkategorier finns i "Användarkategorier". Konfigurationsprocedurer finns i "Konfigurera verifiering mellan användarkategorier".
Hur värdnamn avbildas på användarkategorinamn definieras i avsnittet domain_realm i filen krb5.conf. Dessa avbildningar kan definieras för en hel domän eller för individuella värdar efter behov. Mer information finns i direkthjälpsavsnitten (man pages) krb5.conf(4).
Vid användning av SEAM är det att föredra att DNS-tjänsterna redan är konfigurerade och körs på alla värdar. Om DNS används måste det antingen vara aktiverat på alla system eller inte på något av dem. Om DNS är tillgängligt ska principalen innehålla det fullständiga domännamnet (FQDN) för varje värd. Om till exempel värdnamnet är boston, DNS-domännamnet acme.com och användarkategorinamnet ACME.COM, så blir principal-namnet för värden host/boston.acme.com@ACME.COM. I exemplen i den här boken används fullständiga domännamn för varje värd.
För principalnamn som innehåller det fullständiga domännamnet för en värd är det viktigt att det överensstämmer med den sträng som beskriver DNS-domännamnet i /etc/resolv.conf. Strängen är skiftlägeskänslig. SEAM kräver att DNS-domännamnet skrivs med små bokstäver vilket innebär att endast små bokstäver används när ett fullständigt domännamn anges för en principal.
SEAM kan köras utan DNS-tjänster, men vissa funktioner, som möjligheten att kommunicera med andra användarkategorier, kommer inte att fungera. Om DNS inte har konfigurerats kan ett enkelt värdnamn användas som instansnamn. I så fall blir principalnamnet i vårt fall host/boston@ACME.COM. Om DNS aktiveras senare måste alla värdprincipaler tas bort och ersättas i KDC-databasen.
Som standard används port 88 och port 750 för KDC:n och port 749 används för KDC:ns bakgrundsadministrationsprogram. Det går att använda andra portnummer, men för att ändra dem krävs en ändring i filerna /etc/services och /etc/krb5/krb5.conf på varje klient. Dessutom måste filen /etc/krb5/kdc.conf uppdateras på varje KDC.
Slav-KDC:erna genererar referenser för klienter precis som huvud-KDC:n. Slav-KDC:erna fungerar som reservenheter om huvudservern skulle sluta att fungera. Varje användarkategori bör ha åtminstone en slav-KDC. Det kan behövas ytterligare slav-KDC:er beroende på dessa faktorer:
Antalet fysiska segment i användarkategorin. Normalt bör nätverket konfigureras så att varje segment kan fungera, åtminstone minimalt, utan resten av användarkategorin. Detta kräver att en KDC är åtkomlig från varje segment. KDC:n i det här fallet kan vara antingen en huvudserver eller en slav.
Antalet klienter i användarkategorin. Att lägga till fler slav-KDC-servrar kan minska belastningen på de befintliga servrarna.
Det är dock möjligt att lägga till för många slav-KDC:er. Kom ihåg att KDC-databasen måste överföras till varje server, så ju fler KDC-servrar som installerats, desto längre tid kan det ta innan data har uppdaterats i hela användarkategorin. Eftersom varje slav behåller en kopia av KDC-databasen, innebär fler slavar också en ökad risk för säkerhetsproblem.
Dessutom kan en eller flera av slav-KDC:erna konfigureras så att de enkelt kan växlas mot huvud-KDC:n. Fördelen med att följa denna procedur för åtminsone en av slav-KDC:erna är att om huvud-KDC:n av någon anledning slutar att fungera har du ett förkonfigurerat system som är enkelt att sätta i drift som huvudserver. Instruktioner för hur man konfigurerar en växlingsbar KDC finns i "Växla huvud- och slav-KDC:er".
Databasen på huvud-KDC:n måste regelbundet överföras till slav-KDC:erna. En av de första frågorna att ta ställning till är hur ofta slav-KDC:erna ska uppdateras. Önskan att ha uppdaterad information tillgänglig för alla klienter måste vägas mot den tid det tar att fullborda uppdateringen. Mer information om databasöverföring finns i "Administrera Kerberos-databasen".
I stora installationer, med flera KDC:er i samma användarkategori, är det möjligt för en eller flera av slavarna att överföra data så att processen kan ske parallellt. Detta minskar den tid uppdateringen tar, men det ökar också komplexiteten hos administrationen av användarkategorin.
Alla värdar som ingår i Kerberos verifieringssystem måste ha internklockorna synkroniserade inom ett angivet maximalt tidsintervall (som kallas tidsförskjutning) vilket utgör ytterligare en säkerhetskontroll för Kerberos. Om tidsförskjutningen överskrids mellan två av de ingående värdarna kommer förfrågningar att nekas.
Ett sätt att synkronisera alla klockor är att använda NTP-programvara (Network Time Protocol). (Mer information finns i "Synkronisera klockor mellan KDC:er och SEAM-klienter".) Det finns andra sätt att synkronisera klockorna så det är inte nödvändigt att använda NTP. Någon form av synkronisering bör användas för att förhindra åtkomstproblem på grund av tidsförskjutning.
SEAM-produkten inkluderar en förkonfigureringsprocedur som lagrar information på en NFS-server. Denna information kan sedan användas av installationsskriptet. Det är valfritt att använda denna procedur, men det rekommenderas starkt eftersom det sparar tid under installationen och minskar risken för att fel uppstår vid manuell datainmatning.