Målsättning (4117)

Projektledare, Rumsadming och deltagare

Arbetsuppgifter

Tidsplan (4021)

Kabeldragning (4021)

Uppgiften

Att skapa ett simulerat Novell IntranetWare IPX nätverk över 10 tids-zoner. Ett företag i varje tids-zon där den företags interna trafiken sköts med IPX och all extern trafik via IP/IPX gateway, ett på varje företag. Uppgiften var att hitta en lösning för att ansluta rummen 4021-4023, 4038-4140 mot 4113-4125.

Utförande

Kabeldragningens första skede var att välja en alternativ lösning på hur backbonet skulle kopplas mellan sektionerna 4140-4138, 4117-4123, 4021-4023. Ett förslag var att dra kabeln från 4113 längs trapphuset till 4021. Detta förslag tillbakavisades av Stefan Träskelin. Ett annat förslag var att gå via fönstret från 4021 upp mot 4113. Av säkerhetsskäl kunde inte heller denna lösning godkännas. Vi beslöt då att med ca 50 meter lång TP kabel, dra längs taket från rum 4023 genom korridoren riktning mot 4140 på den undre våningen. Vi använde oss av kabelstegen längs taket enligt bilden.

Kabeln nådde ända fram via ett rör upp mot 4140. Sedan förlängdes kabeln via 4138 via taket på övre våningen till rummet 4123. Problem som uppkom var själva kabel- anslutningen. Som du ser så kommer den från undre våningen. Denna kabeldragning uteslutandes nätverkets backbone.

Slutliga Lösningen

Den slutliga lösningen till att koppla ihop projektets sektioner i ett IPX nätverk kom så småningom genom Stefan Träskelin. Rum 4021 och 4023 kopplades via en hub och kabel. Sedan användes ena jacket i väggen i rum 4021 för att nå 4113 som är bunden till nätverket. Det andra jacket kopplas mot skolans TCP/IP nät. På samma sätt kopplades även rum 4113-4125 och 4138-4140 mot TCP/IP nät. Rum 4138-4140 kopplades till IPX nätverket via kabeln till rum 4123, som i sin tur är ansluten sedan tidigare till rum 4121.

Slutsats

Trafiken på backbone är således IPX. En gateway på varje server sköter routingen mot Internet. Alla servar behöver sin egen IP-adress för att komma ut mot TCP nätet. Exemplet nedan visar hur nätet konstrueras i varje rum.

Standarddokument (4125)

Inloggningsnamn = förnamn OBS! Max åtta bokstäver

Om det finns flera med samma förnamn i rummet är inloggningsnamnet = förnamn + första bokstaven i efternamnet.

 

Server	Rumsnummer_SRV
O	Rumsnummer_ORG
OU	Rumsnummer
Tree	Rumsnummer_TREE

 

Adressering

IP-adress = har vi fått av Stefan.

IPX external nätverks nummer = 12345678

IPX ixternal nätverks nummer = tre sista siffrorna i rumsnummret + fem sista i IP-adressen.

 

tillbaks till toppen

 

Skrivet av grupp 4125 / 980408

IP-nummer (4121)

Installation av huvudserver (CNE) (4117)

När vi installerade server 4117 så körde vi med custom installation. Vi startade installationen och följde sedan installationstexten som ploppar upp då och då. När vi skulle välja volymer så valde vi att ha SYS volymen på 250MB och sen hade vi en VOL1 volym på 538MB. Vi satte även compression OFF på båda volymerna samt att vi satte blockstorlek 16KB på dessa båda.

När vi kom till vad trädet skulle heta så valde vi CNE_TREE eftersom grupp 4117 skulle grunda det stora trädet.

Det interna IPX numret valde vi 11757244. De tre första siffrorna hänvisar till de tre sista siffrorna på rummen och de fem sista siffrorna är de sista siffrorna i det IP nummer som varje rum är tilldelat.

Det externa IPX numret var bestämt innan till 12345678. Det numret måste alla servrar ha för annars så blir det fel och servrarna piper och bråkar.

När vi följt anvisningarna så var installationen klar och det var bara att logga in i trädet.

Installation av MAIN_SRV

Installationen av server MAIN gick i stort sett till på samma sätt som när vi installerade våran 4117 server. Vi hade även där en SYS volym på 250MB men VOL1 volymen blev 1.6GB.

Vi försökte först att installera denna server direkt in i CNE_TREE men det gick inte så bra. Vi fick istället skapa ett träd som vi sedan mergade in i CNE_TREE. Sedan flyttade vi servern till dess rätta context.

Meningen är att MAIN_SRV inte ska finnas egentligen utan den har vi lagt under den första organistationen för att alla ska komma åt den som filserver och komma åt de olika program och filer som ligger på den. Annars så hade det inte varit så bra att lägga den där med tanke på att vi har lagt den innan alla WAN partitioner.

tillbaks till toppen

Skrivet av grupp 4117 / 980416

Att installera IntranetWare (4119)

Denna dokumentation kommer att sammanfatta hur man installerar IntranetWare på en server. Dokumentet följer stegen enligt kursen 540: Building Intranets with IntranetWare. Stegen kan sammanfattas med:

• NIAS installation
• Konfigurera TCP/IP
• Konfigurera IPX/IP Gateway
• Lägga till IPX/IP Gateway verktyg till NWADMIN
• Installera Novell Web Server
• Installera FTP
• Konfigurera FTP för en anonym användare

NIAS installation

Först är man tvungen att ange från vilken CD-rom skiva man vill arbeta från.

LOAD CDROM

CD MOUNT NIAS4

Själva installationen börjas med:

LOAD INSTALL.NLM

Därefter följer man dessa punkter:

1. Välj "Product Options", "Install a Product Not Listed".

2. Skriv NIAS4:\NIAS\INSTALL för att ange sökvägen på NIAS4 CD-rom.

3. Välj "Install Product" och ange aktuell server.

4. ESC på förfrågan om MPR och in med en licensdiskett (Novells licensdisketten för 10 användare.)

5. Klar, EXIT.

Kontrollera att installationen vart komplett med INSTALL.NLM "Configure/View/Remove Installed Products". Det ska stå ungefär:

IPXGW IPX/IP Gateway

MPR NetWare Multi Protocol Router

NIAS Novell's Internet Access Server

WANEX WAN-Extensions

Lägg till nedanstående rader till STARTUP.NCF med INSTALL.NLM, "NCF Files Options".

SET MINIMUM PACKET RECEIVE BUFFERS=400

SET MAXIMUM PACKET RECEIVE BUFFERS=1000

Sedan är det bara att starta om servern.

Konfigurera TCP/IP

1. LOAD INETCFG.NLM, svara "YES" på eventuella frågor.

2. Hoppa till INETCFGs huvud meny.

3. Välj "Protocols", "TCP/IP"

4. Se till att TCP/IP är tillgänglig (enabled), ESC.

5. Välj "Bindings", tryck på Insert knappen och välj "TCP/IP".

6. Välj sedan "A Network Interface" välj ditt nätverkskort.

7. Skriv in IP adressen.

8. Klart, starta om servern.

Konfigurera IPX/IP Gateway

1. LOAD INETCFG.NLM

2. Välj "Protocols", "TCP/IP" och sedan "IPX/IP Gateway Configurations"

3. Se till att IPX/IP Gateway är tillgänglig (enabled).

4. Tryck på ESC två gånger och logga in dig som admin.

5. Avsluta INETCFG.NLM och starta om servern.

Lägga till IPX/IP Gateway verktyg till NWADMIN

Arbetet sker vid en klient.

1. Öppna filen NWADMN3X.INI (finns under WINDOWS katalogen).

2. Skriv in under [Snapin Object DLLs WIN3X] IPXGW3X=IPXGW3X.DLL

3. Spara filen.

 Installera Novell Web Server

1. LOAD INSTALL.NLM

2. Välj "Product options", "Install NetWare WEB Server v2.51".

3. Följ instruktionerna och du är klar.

Installera FTP

1. (Skriv vid server consol prompten

LOAD NFS.NAM

ADD NAME SPACE NFS TO SYS:

dvs de volymer man vill använda för FTP.)

2. Ladda CDROM med NIAS4 enligt rutinerna under punkten "Installera NIAS4".

3. LOAD INSTALL.NLM

4. Välj "Product options" och sedan "Install a product not listed".

5. Tryck på F3 och skriv NIAS4:\NWUXPS

6. Följ instruktionerna.

7. Ignorera felmeddelandet om sys:etc…….

8. Välj "Local DNS and Local NIS".

9. Följ instruktionerna.

10. Vid "running services" tryck INS och välj "FTP server".

11. Avsluta och starta om servern.

Observera punkt 10, då många förivrar sig och avslutar installationen för tidigt, detta medför att man inte aktiverar själva FTP tjänsten (FTP server).

1. Skriv vid consol prompten ADD NAME SPACE NFS TO SYS. Upprepa denna punkt för de volymer du vill använda med FTP.

2. LOAD UNICON.NLM och logga in dig som admin.

3. Välj "Manage Services", "FTP Server" "set parameters".

4. Välj "Default Name Space" och byt den till NFS.

5. Ändra "Anonymous User Access" till YES.

6. Ändra "Anonymous User's Home Directory" till ex FTP:.(Detta gör att den anonyme användaren startar sin FTP session under denna volym/katalog, om man anger även katalog.)

7. Därefter ESC och spara.

8. Vid startmenyn välj "Perform File Operations", "View/Set File Permission".

9. Med INS knappen väljer du först FTP och sedan den katalog som du angivit under punkt 6.

10. Tryck ESC och därefter två gånger på ENTER då kommer du in i File information.

11. Ändra NFS rättigheterna till endast U=rwx för anonymous användaren.

12. Tryck ESC och ENTER. Ta bort katalogen (själva namnet) från /FTP/"katalog namn".

13. Tryck sedan tre gånger på ENTER för att komma in i File Information.

14. Välj Anonymous till UNIX User ID. Ta bort samtliga rättigheter. (Punkterna 12-14 gör att den anonyme användaren inte ser vad som finns i de andra ovanstående katalogerna. Dessa punkter kan förbises om man vill ge rättigheter till hela volymen.)

15. Avsluta och det är klart.

16. Kan eventuellt skriva vid consol prompten följande

LOAD LONG.NAM

ADD NAME SPACE LONG TO VOL1

Nu har vi skapat en anonym användare som kan komma åt våra FTP server dock endast katalogen som angivits. Ett tips kan vara att ha en specifik volym för FTP, där alla kan härja bäst de vill och hålla SYS volymen borta från FTP.

tillbaks till toppen

Skrivet av grupp 4119 / 980410

Default-rättigheter (4140)

• När NDS installeras
• När en filserver installeras i trädet
• När man skapar en användare
• När man skapar en container

När NDS installeras

Admin

När NDS installeras skapas två huvudsakliga objekt, [Root] och Admin. Admin får Supervisor objekt rättighet till [Root]. Detta gör att admin har rättigheter till att administrera allt i NDS trädet.

[Public]

Också ett objekt som skapas när NDS installeras. Varje objekt i trädet ärver de rättigheter som [Public] har. Som default får [Public] Browse objekt rättighet till [Root] vilket medför att varje objekt i NDS trädet kan se alla andra objekt. Det finns en nackdel med detta och det är att man inte behöver vara inloggad i trädet för att kunna se hur det ser ut, det räcker att man är ansluten till nätverket. För att förhindra detta kan man ta bort [Public] som Trustee till [Root] och istället ge varje organization eller organizational unit Browse rättigheter till sig själva. Detta gör att användarna bara kan se sin egen del av trädet samt att man måste vara inloggad på trädet för att kunna se det.

När en filserver installeras i trädet

Skaparen

Antingen admin eller en container administratör. Som default får den användaren Supervisor rättighet till den nya servern.

Servern

Servern får Supervisor rättighet till sig själv.

[Public]

[Public] på huvudservern får Read rättighet till en speciell server property – Messaging server. [Public] får också Read rättighet till Network address property. Detta gör att alla klienter kan identifiera servern.

När man skapar en användare

Användaren

Varje user objekt får Read rättighet till All properties på sig själv. Detta för att kunna se information om sitt eget objekt. Den får Read och Write rättigheter till Login script och Print job configuration. Detta gör att de kan ändra på sina login script. Detta bör man undvika och man bör därför ändra den rättigheten när man installerar en ny användare. Varje användare ärver också Browse rättighet till trädet från [Public].

[Root]

[Root] får Read property rättighet till Network address och Group membership hos användaren. Detta medför att alla i trädet kan se användarens nätverksadress samt vilka grupper den tillhör.

[Public]

Får Read property rättighet till Default server hos användaren. Detta gör att vem som helst kan se vilken som är användarens default server.

När man skapar en container

Varje ny container får Read och Write property rättigheter till sitt Login script vilket medför att varje användare i containern kan ändra containerns login script. Detta är oftast inte speciellt bra. Containern får också Read och Write property rättigheter till sitt Print job configuration. Detta är, likadant som med login script, oftast inte bra.

 

tillbaks till toppen

Skrivet av Tomas Lif  980410

Testmergar (4117)

Målet var att vi skulle merga ihop alla servrar i de olika rummen med varandra i ett enda träd som ska heta CNE_TREE. För att göra det så var det inte så lämpligt att göra det skarpt från början. Därför så gjorde vi en testmerge mellan träd CNE_TREE och 4119_TREE. Vi synkade servrarna med varandra, hur man gör detta beskrivs lite längre ner i stycket.

Mergningen gick bra. 4119_TREE mergades ihop så den lade sig i [root] på CNE_TREE. Problemet kom när vi skulle flytta 4119_ORG till den plats i det nya trädet som den skulle till. Vi gjorde det misstaget att vi inte mergade ihop partition 4119 med root-patition på CNE_TREE. Det medförde att servrarna och trädet låste sig. Vi väntade ett bra tag men det hände inget. Då provade vi med att merga in rum 4123. Det gick inte bra för 4117 server sa att den var upptagen med mergning av det första trädet. Det gick inte att göra någonting alls med partitionerna, servrarna mm. Så då ledsnade vi på allt och detta ledde alltså till användning av det älskade kommandot DELTREE C:\NWSERVER Vilket i sin tur följs av Fdisk och serverinstallation. Denna del av kursen sitter i ryggmärgen vill jag lova.

Det vi lärde oss av det var att vi skulle merga ihop den nya partitionen med root-partitionen innan någonting annat gjordes.

 

Tidssynkronisering

Detta är en del av arbetet som kan strula ordentligt så se till att träden är ordentligt synkade med varandra innan merge. Vi gick in i SERVMAN i serverconsolen och satte server 4117 som singel reference. Resterande servrar fick vi ställa om så att de stod som secondary time. På secondary servrarna fick vi även ställa in "TIMESYNC Time Source" till server 4117 så att source servern hämtar tiden därifrån. Innan vi mergade så ställde vi in DOS klockan på alla secondary servrar så att tiden skulle stämma överens någorlunda, det gorde vi manuellt med hjälp av ett vanligt armbandsur.

Meningen är sedan att server 4115 ska vara reference och hämta tid från ett atomur. Resterande servrar ska vara secondary, förutom en server i varje partition som ska vara primary.

När vi hade gjort detta och startat om servern så sade systemet till att de var synkroniserade med varandra. Man kunde även gå in i DSREPAIR i servern och kontrollera om secondary servern var synkad. Då fick vi ett felmeddelande på servern. Den klagade på "synthetic time" (tror jag att det var). Vi gick till Novells supportsida och kollade. Då fick vi reda på att vi skulle använda DSREPAIR för att ändra en parameter. Vi öppnade DSREPAIR och valde "ADVANCED OPTIONS" och efter det "REPLICA AND PARTITION OPERATIONS" då får ni fram en partitions betäckning på ert träd, dunka enter och välj "TIME STAMPS AND CREATE A NEW EPOCH". Därefter DOWN och sen RESTART SERVER. När secondary server startades upp så sa den till att den var synkad med server 4117 som var singel reference och även Time source.

Efter det att träden var synkade med varandra så var det dags att merga ihop träden.

 

Merge från serverconsole

När servrarna var synkade med varandra så var det dags att börja merga ihop träden. Vi började med att merga ihop 4119_TREE med CNE_TREE. Eftersom det var 4119_TREE som skulle vara sourse och CNE_TREE vara target så fick vi gå in till 4119_TREE serverconsole och merga därifrån.

I serverconsolen så körde vi LOAD DSMERGE. Där kontrollerade vi att träden var mergade med varandra. Det gjorde vi med genom att välja "Check time synchronization" i menyn som kommer upp när man kör DSMERGE. När vi var säkra på att servrarna var synkade med varandra så valde vi "Merge two trees" i samma meny i DSMERGE.

Där fick vi inte välja vilket träd som skulle vara sourse trädet utan systemet valde det trädet som man satt och jobbade ifrån. Vi fick skriva in source admins sökväg samt skriva in hans password. När vi skrivit klart source admin så gick vi ner en rad och när kunde man gå in och välja vilket träd som sourceträdet skulle mergas med. Där valde vi CNE_TREE samt sökväg till target admin och hans password. När vi kontrollerat uppgifterna så tryckte vi på F10 för att fortsätta.

När träden inte var synkade med varandra så avbröts mergningen vid 33% och då kom det ett meddelande som sa att träden inte var synkade med varandra. Då var det bara att synka träden med varandra och sedan börja mergningen igen.

Om allt var OK och vi kom förbi den där 33% gränsen så kom det upp meddelanden som det bara var att läsa igenom och köra vidare. Det kom även upp ett meddelande som rekomenderade att vi skulle ha flera replica servrar, vi läste meddelandet och körde vidare. Efter ett kort tag så fick vi upp en ruta som talade om att mergningen var OK.

 

Merge från clientdatorn

När mergningen från serverconsolen var klar så fick vi sätta oss vid en clientdator och göra resten av jobbet därifrån. Vi loggade naturligtvis in i CNE_TREE eftersom träd 4119_TREE inte längre fanns. Det första verktyget vi arbetade med i clientdatorn var NDS Manager (Ndsmgr16.EXE som ligger i SYS:PUBLIC). I det programmet kan man se vilka paritioner som för tillfället är i trädet samt att man kan ta bort och skapa nya partitioner.

När vi började jobba i NDS Manager såg vi att 4119_ORG som var den första organisationen i source trädet hade lagt sig direkt under rooten i CNE_TREE. Nu skulle vi se till att vi inte gjorde samma misstag som vi gjorde när vi gjorde våran testmergning. Nu mergade vi ihop 4119_ORG med root-partitionen för att inte låsa allt igen. När CNE_TREE bara var en stor partition så gjorde vi 4119 under 4119_ORG till en egen partition. Det måste man göra för att kunna flytta på en container. Vi flyttade container 4119 till den context som den skulle ligga i. Efter det så mergade vi ihop partition 4119 med root-partitionen i CNE_TREE igen. När det vara klart så skulle vi radera 4119_ORG från trädet. Det kunde vi inte göra från NDS Manager utan vi fick gå in i NW Admin och göra det.

När vi lyckades att merga med 4119_TREE så var det inga större problem med att merga in resterade träd. Problemen var i stort sett det samma med alla trä som skulle mergas in. Det var tidssynkroniseringen som den ofta klagade på. Men eftersom vi hade gjort en testmergning så var det inga problem att lösa dessa problem. Det märktes en stor skillnad när det kom in fler servrar i trädet på tiden det tog att uppdatera allt och ändå hade vi inte någon information utöver serverinstallationen i våra servrar utan de var ju nyistallerade. När det finns en himla massa information lagrade på varje server så kan jag tänka mig att det tar en otrolig tid att merga och uppdatera allt.

 

NDS Strul efter Merge

Ett stort problem dök upp efter merge, alla container Admins blev trustees av root i det stora trädet.

CNE admin kunde dock inte se dessa när man kollade vilka som var trustees av rootobjektet i Nwadmin, men de som var inloggade som någon av dessa admins såg varandra och även CNE admin. (Bugg i Netware?). Alla kunde skapa och radera object i hela trädet vilket inte är så bra.

Detta löstes genom att alla Admins raderades och skapades på nytt med rätt rättigheter i det nya trädet. OBS! Kolla upp superusers som skapats i de träd som mergas in i target trädet.

 

tillbaks till toppen

Skrivet av grupp 4117 / 980411

Merge (4117)

Testmerge 2

 

Träd #1. Source                                    Träd #2. Target.

[Root]                                                   [Root]

O=C3L                                                 O=MASTEN

Admin                                                    Admin

APRIL_SRV                                         MAJ_SRV

APRIL_SRV_SYS                                MAJ_SRV_SYS

APRIL_SRV_NW411                          MAJ_SRV_NW411

 

Default rättigheter för källträd C3L.

 

la. Förberedelser för mergning.

Vi skapar OU=APRIL_ORG under O=C3L och OU=MAJ_ORG under O=MASTEN.

Sedan flyttas alla

objekt i respektive träd till respektive OU.

 

[Root]                                                     [Root]

 

O=C3L                                                   O=MASTEN

OU=APRIL_ORG                                  OU=MAJ_ORG

Admin                                                      Admin

APRIL_SRV                                           MAJ_SRV

APRIL_SRV_SYS                                  MAJ_SRV_SYS

APRIL_SRV_NW411                             MAJ_SRV_NW411

Nina

 

Objekt (klass User) CN=Nina.OU=APRIL_ORG.O=C3L har blivit Trustee till objekt O=C3L och tilldelats [S] rättighet - både Object och Alla Properties .

Rättigheter.

 

ll. MERGE TVÅ TRÄD.

lla. Innan vi sätter igång

1. Kollar hårdvaruklockor på både servrar.
2. Server APRIL_SRV (source) kommer att bli seconary time server. Ändrar SET parametrar i SERVMAN.
3. Server MAJ_SRV (target) förblir Single Reference time server.

 

Det finns bara en partition på varje träd.

 

llb. Efter "mergningen".

 

[Root] Partition

O=MASTEN

OU=MAJ_ORG

 

O=C3L Partition

OU=APRIL_ORG

Partitioner och replicor.

Trädet ser nu ut på det viset: två objekt Organization under [Root]en.

 

      [Root]

O=C3L                                                                         O=MASTEN

OU=APRIL_ORG                                                        OU=MAJ_ORG

Admin                                                                            Admin

APRIL_SRV                                                                 MAJ_SRV

APRIL_SRV_SYS                                                        MAJ_SRV_SYS

APRIL_SRV_NW411                                                   MAJ_SRV_NW411

Nina

 

Rättigheter

lll. STÄDNING

Använder NDS Manager och NWAdmin.

llla. Vi splittrar partition C3L.

Måste vara inloggade på server APRIL_SRV (där det finns Master Replica av C3L partition).

 

[Root]                        Partition

O=MASTEN

OU=MAJ_ORG

 

O=C3L Partition

OU=APRIL_ORG Partition

Partitioner och replicor.

lllb. Vi flyttar OU=APRIL_ORG till O=MASTEN.

[Root] Partition

O=MASTEN

OU=MAJ_ORG

OU=APRIL_ORG Partition

 

O=C3L Partition

Partitioner och replicor.

lllc. "Mergar" [Root] partition och APRIL_ORG partition och sedan tar bort C3L partition.

Partitioner och replicor.

lV. RESULTAT

[Root]

O=MASTEN

 

OU=APRIL_ORG

Admin

APRIL_SRV

APRIL_SRV_SYS

APRIL_SRV_NW411

Nina

 

OU=MAJ_ORG

Admin

MAJ_SRV

MAJ_SRV_SYS

MAJ_SRV_NW411

 

Rättigheter

Admin.MAJ_ORG.MASTEN. Rättigheter till andra objekt.

Admin.APRIL_ORG.MASTEN. Rättigheter till andra objekt.

V. SLUTSATSER.

I detta fall behöver man inte ta bort några objekt sådana som Admin eller User med [S] rättigheter i källträd, för att denna Admin (och Superuser) förlorar sina Supervisory rättigheter. Admin.APRIL_ORG.MASTEN inte kan administrera den server Admin har skapat.

Nästa steg kan vara att tilldela Admin.APRIL_ORG.MASTEN nya Trustee rättigheter för att Admin ska kunna administrera sin hem-container (om APRIL_ORG står för "location").

 

tillbaks till toppen

 

Skrivet av grupp 4117 / 980402

Backup (4119)

Backup är till för alla dvs alla som råkar radera viktiga filer. För en användare som har gjort fel till admin som råkar skapa systemfel så är backup livsnövändig. Denna dokumentation ska försöka ge en förenklad beskrivning av NetWares SBACKUP. Dokumentet kan sammanfattas med:

- Förstå SBACKUP

- Backup strategier

- TSA och SBACKUP

- backup log och error log

Förstå SBACKUP

Host IntranetWare server som kör SBACKUP och där själva bandstationen är kopplad.

Target Vilken IntranetWare server som helst, NDS databas som har en TSA laddad.

Parent Container, katalog som innehåller andra objekt

Child Fil eller lövobject

Backup strategier

Matris om de olika strategierna, hur snabb är backupen, hur läät är åtkomsten av filer/kataloger och när bör de köras.

Strategier Backup Restore Modify Bit When

Full Slow Easy Cleared Every Friday

Incremental Quick Hard Cleared

Differential Quick Easy Not cleared Every day

Custom Whatever Your choise Doesn't matter Once a month

 

Full backup

All data kopieras oavsett om den är säkerhetskopierad. Metoden är långsam men säker. Dock snabb och enkel återskapning. Varje fils modify bit är rensad/uppdaterad, dvs nytt datum då filerna är säkerhetskopierade. Modify biten för en fil ändras då man ändrar/uppdaterar filen dvs den vill bli säkerhetskopierad nästa gång.

 

Incremental backup

Ej att föredra. Säkerhetskopierar endast filer som är ändrade. Svårt att återskapa.

 

Differential

Säkerhetskopierar alla filer som är ändrade sedan senaste Full backup. Metoden är att föredra före metoden ovan.

 

Custom backup ? du bestämmer

TSA och SBACKUP

[backup tape+Host server]?[Target, TSA]

Först och främst måste man ha enheten för backup laddat innan man startar SBACKUP. För att hitta enheten kan följande skrivas:

SCAN FOR NEW DEVICES, och därefter aktivera enheten.

Då man laddar SBACKUP (i detta fall i rum 4117) och vill göra en backup på sig själv (4117_SRV) eller på en specifik server (xxxx_SRV) så kommer inte den att hitta servern om man inte har laddat en TSA, target Service Agent, se lista

IntranetWare server TSA411

NetWare 4 server TSA410 eller TSA400

NetWare 3 server TSA312 eller TSA311

Client TSASMS.COM

backup och error log

Vid backup med SBACKUP skapas två viktiga filer (håll reda på vart de hamnar) backup log och error log. Backup log innehåller data på allt som vart säkerhetskopierat under sessionen, media ID, sessionens datum och tid, sessions beskrivning och vart datan hamnade på backup mediet. Error log hamnar på host servern och i stort sett samma information som backup log skillnaden ligger i att visa felmeddelanden. T ex namn på filer som inte vart säkerhetskopierade, filer som inte kunde återställas, error codes.

tillbaks till toppen

Skrivet av Janne Korhonen 980402

Service pack (4117)

 

Installationen av det nyaste servicepacket gick bara fint. Servicepacket fanns på våran MAIN_SRV som är våran filserver. Vi kopierade över servicepacket till sys volymen på våran 4117 server som skulle uppdateras.

Efter det så gick vi in i serverconsolen och laddade INSTALL programmet. Där valde vi "Product options" och "Install a product not listed". Därefter skrev vi in den specifika sökvägen till servicepacket och sen enter.

När den började att installera servicepacket så fick vi upp ett par rutor som bara var att läsa igenom och sedan fortsätta installationen av servicepacket. Installationen tog ett par minuter och sen så startade vi om servern.

 

tillbaks till toppen

 

Skrivet av grupp 4117 / 980416

Fil och skrivardelning (4021)

Logga in som dig själv. Klicka på ikonen Nätverket. Välj Egenskaper, klicka på Lägg till och markera Tjänster. Klicka på Lägg till. Markera Microsoft, markera sedan Fil och skrivardelning för Microsoft Network. Klicka OK.

Eventuellt måste Win95 skivan användas. Systemet talar om ifall det behövs extra information. Starta om datorn om du får det beskedet.

Logga in igen, gå till Utforskaren och C:. Skapa mapp, döp till nå´t lägligt (typ allas). Tryck F5 för att uppdatera. Markera den nya mappen, högerklicka och välj Dela ut. Markera Delad och Fullständig. Tryck sedan Verkställ och OK. Lösenord kan användas på olika sätt i samband med fildelning. Prova dig fram eller prata med nå´n i 4021 om det verkar krångligt.

Gå till Den här datorn. Välj skrivare och Lägg till skrivare. Klicka på Nästa och välj Nätverksskrivare. Välj Nästa igen och markera Ja vid frågan om Dosbaserade program. Klicka sedan på Bläddra och välj Hela nätverket. Här får du leta reda på din skrivare(som inte jag känner namnet på)!

När du funnit skrivaren markera och klicka OK. Sökvägen kommer nu fram, klicka Nästa. Ange sedan skrivarport, typ LPT1, och klicka OK. Klicka Nästa och kolla att rätt skrivarmärke står uppsatt. Klicka Nästa om allt stämmer. Har du installationsdiskett är det läge att plocka fram dem till momentet innan. Välj sedan Ja och Nästa för nu är skrivaren färdiginstallerad (om det står Slutför på "knappen"). Passa på att skriva ut en provsida, för att kolla att allt fungerar.

Namnkonventioner:

Högerklicka på nätverksikonen och välj egenskaper/identifiering:

Datornamn: <namn>_Dator

Arbetsgrupp: RUM_<rumsnr>

Datorbeskrivning: Valfritt

tillbaks till toppen

Skrivet av grupp 4021 / 980401

NAL (4113)

 

Organisation 4113 fick i uppdrag att utforska NALen för att förenkla administrationen av det stora nätverket. Vi upprättar ett testlab för ändamålet, d v s en server och en client anslutna med en korsad TP-kabel.

NAL är ett program som förenklar administratörens arbete med att distribuera mjukvara till clienterna. Istället för att besöka varje arbetsstation kan han/hon nu med hjälp av NAL utföra detta arbete från sin egen PC.

NAL återställer ordningen då en användare råkat ta bort nödvändiga programfiler. Användare av NAL får tillgång till program som alltid fungerar och alltid är tillgängliga.

Applicationerna blir katalog- och nätverksmedvetna. Genom att modifiera .INI-filer och register kan även komplexa program som t ex Microsoft Office bli anpassningsbart till nätverket.

tillbaks till toppen

Skrivet av grupp 4113 / 980404

Gömda containrar (4117)

Eftersom grupp 4117 var ansvariga för NDS trädet så var det i vårat intresse att hitta gömda object och gömda containrar i trädet.

För att göra det så var jag inne på Novells hemsida och sökte information. Där hittade jag ett program som hette "Hidden Object Locator". Det var en ZIP-fil som jag laddade ner och den var inte större än 46kb. När filen packades upp så var det två filer, en Readme.txt och en fil som hette Hobjloc.nlm.

Hobjloc.nlm lade vi i system-katalogen på server 4117. När det var klart så gick jag till serverconsolen och skrev LOAD HOBJLOC.NLM. Då startades programmet "Hidden Objoct Locator". Som vanligt så kom det upp en meny. Det första var att man valde vilken context som användaren som skulle söka gömda containrar var i. Vi började att söka med användare admin så contexten blev bara O=CNE. Man valde även vi vilken container som sökningen skulle börja och då väljer man skälvklart [root]. Sen gick vi vidare och startade söningen.

Vi hade gömt tre stycken containrar i trädet och det var inga problem för programmet att hitta dessa. Vi gick in i log-filen och kollade vad den sa. Den meddelade att den användare som vi sökte med inte hade BROWS/SUPERVISOR rättigheter till de gömda containrarna. Det var en fullständig sökväg till de gömda containrarna så det var inga problem att veta var containrarna fanns någonstans. Det stora problemet var nu att kunna bli av med dessa och det problemet är inte löst ännu.

tillbaks till toppen

Skrivet av grupp 4117 / 980402

Applications on server part one (4140)

Loggar man in som Usern Win95 som finns i USERS.4140.CNE3.CNE utan password så ska automatiskt hela windows 95´s (osr2) installation-program skickas till hårddisken vid den datorn man sitter vid.

Utförande.

Skapade usern win95 mha NWADMIN i contexten USERS.4140.CNE3.CNE.
Dubbelklickade på usern och valde Login Script och skrev in följande:


MAP R Y:=VOL1:APPS <-- stället där hela win95 installations-programmet ligger.

MAP INS S1:=SYS:PUBLIC
MAP INS S2:=C:\WIN95\COMMAND
MAP INS S3:=C:\WINDOWS\COMMAND

EXIT "SKICKA.BAT" <-- Loginscriptet avslutas och bat-filen skicka.bat tar över

 

Via NWADMIN gjorde jag usern win95 till trustee av katalogen APPS i volymen VOL1 med defaulträttigheter.

Skapade filen SKICKA.BAT i PUBLIC katalogen på SYS volymen med följande innehåll:

 

@ECHO OFF
CLS
C:
CD\
MD W95osr2
XCOPY32 Y:\W95osr2 C:\W95osr2 /S/E/Y/H/R
ECHO Nu var det klart, stang DOS-fonstret om den inte gjorde det av sig sjalv..
EXIT

Loggade in som Win95, och det blev precis som jag ville. Windows skickades från servern (4140_SRV) till en katalog kallad W95osr2 på den lokala hårddisken. För att installera windows är det sedan bara att köra install.exe som ligger i W95osr2 katalogen.

Klart !

tillbaks till toppen

Skrivet av Jonas Wibom / Säkerhetsgruppen 980403

Applications on server part two (4140)

Loggar man in som Usern Netapps som finns i USERS.4140.CNE3.CNE utan password så ska automatiskt ett menysystem komma upp där man kan välja mellan en massa program som skall skickas till den hårddisk där man sitter.

Utförande.

Skapade usern Netapps mha NWADMIN i contexten USERS.4140.CNE3.CNE.
Dubbelklickade på usern och valde Login Script och skrev in följande:


MAP R Y:=VOL1:APPS <-- stället där alla applikationer ligger.

MAP INS S1:=SYS:PUBLIC
MAP INS S2:=C:\WIN95\COMMAND
MAP INS S3:=C:\WINDOWS\COMMAND

EXIT "NETADMN.BAT" <-- Loginscriptet avslutas och bat-filen netadmn.bat tar över

Via NWADMIN gjorde jag usern Netapps till trustee av katalogen APPS i volymen VOL1 med defaulträttigheter.

Skapade filen NETADMN.BAT i PUBLIC katalogen på SYS volymen med följande innehåll:

ECHO OFF
CLS
NMENU NETADMN.DAT <-- Tar upp det här senare

 

Skapade en fil i PUBLIC katalogen kallad NETADMN.SRC med följande innehåll:

MENU 01, -= ADMIN POWERTOOLS v.0.1 =-
ITEM ^1APPS
SHOW 10
ITEM ^2NET TOOLS
SHOW 15
ITEM ^3GAMES
SHOW 20
ITEM ^4LOGOUT
EXEC LOGOUT

MENU 10, -= APPS ON SERVER =-
ITEM ^1TRANSFER WIN95 OSR2 TO C:
EXEC CALL SKICKA.BAT <-- samma som beskrevs tidigare
ITEM ^2TRANSFER NETSCAPE 3.4 TO C:
EXEC CALL NETSCAPE.BAT <-- se nedan
MENU 15, -= NET TOOLS =-
ITEM ^1UPGRADE CLIENT32
EXEC CALL UPGRADE.BAT
MENU 20, -= GAMES =-
ITEM ^1TRANSFER DOOM C:
EXEC CALL DOOM.BAT

 

Det som syns ovan är själva meny-systemet. För att det skall kunna köras måste det kompileras.
Detta görs mha av MENUMAKE.EXE som ligger i PUBLIC katalogen. Hoppade in i DOS-prompten och tog mig till PUBLIC katalogen och skrev MENUMAKE *.SRC
Efter kompileringen kommer det även att finnas en fil kallad NETADMN.DAT vilket är filen som kan köras. (Kolla NETADMN.BAT ovan)

Till sist skapade jag de resterande BAT-filerna i PUBLIC..NETSCAPE.BAT

@ECHO OFF
CLS
C:
CD\
MD Netscape
CLS
ECHO Sending...
XCOPY32 Y:\Netscape C:\Netscape /S/E/Y/H/R
ECHO Nu var det klart, stang DOS-fonstret om den inte gjorde det av sig sjalv..
EXIT

 

Testing

Loggade in som Netapps och direkt så poppade det upp en meny. Testade sedan om det funkade att skicka program till hårddisken via menysystemet, vilket det gjorde. När allt var klart så använde jag mig av det sista meny-valet Logout som gör precis som det låter loggar ut Netapps ifrån servern.

Klart !

tillbaks till toppen

Skrivet av Jonas Wibom / Säkerhetsgruppen 980403

Öka säkerheten i NDS & Servern mot hackers (4140)

I säkerhetsgruppen så har vi delat upp säkerhets-frågorna bland gruppmedlemmarna. Jag, Jonas, tog på mig att forska i hur man kan försvåra arbetetet för hackers. Jag skriver nedan några saker som kan vara bra att tänka på.

 

Guidelines

Genom att fysikt säkra servern t ex genom att låsa in servern, förhindrar man 75% av alla hacking-möjligheter. Har man flera servrar, så kan det vara smart att samla alla dessa i ett gemensamt "näst-intill-inbrotts-säkert" rum. Kommer en hacker åt servern fysiskt kan han/hon köra ett av många program ifrån diskett för att få access till servern. Att ta bort serverns diskdrive samt tangentbord är då att rekommendera. En annan sak som kan hända är att det stjäls backup-tapes som sitter i servern eller dylikt vilket kan vara ganska förödande.

Genom att fysiskt säkra servern kan man kontrollera vilka som har access till servern, vilka som har access till diskdriven, backup band, och system consolen etc. Detta genom att "logga" alla som gått in i server-rummet via en magnet-avläsare (som c3l har).

Använd Intruder Detection på alla containers som innehåller user-objekt, (detta har jag infört i CNE-trädet) för att förhindra att man har en dator som står och gissar alla möjliga lösenord tills den kommer in som en önskad user (admin) på nätverket, inte så säkert att köra utan alltså. Observera att Intruder Detection inte är någon default-setting, så det kan vara ganska bra att tänka på att sätta på det. Klicka bara via NWADMIN på en container i trädet som innehar user-objekt (huvud-organisationen är ganska viktig) och välj DETAILS -> INTRUDER DETECTION och kryssa i Detect Intruders och Lock account after detection. De enda värderna man inte ska ha som default enligt mig är Incorrect login attempts som jag ändrat från 7 till 3.

Viktiga filer bör man spara offline, filerna autoexec.ncf och config.sys kan vara bra att säkerhetskopiera då dessa är ganska lätta för utomstående att modifiera. Bindery och NDS-filer (oftast lokaliserade i SYS:_NETWARE) bör backupas och sparas offline. Alla system login script, container scripts, och user scripts bör även dessa sparas offline (dessa filer brukar ha filändelsen .000 och ligga i SYS:_NETWARE). I 4.11 så har man förvårat möjligheten att ta sig till _NETWARE-katalogen, men ett sett att gå runt detta är att köra NETBASIC och skriva SHELL och CD _NETWARE, sedan är det fritt fram och leka med login-scripts för att t ex ge sin user mer rättigheter mm :-)

Med offline menar jag på nån "säker" oberoende dator eller någon diskett.

Skriv ut en lista av alla NLMer och deras versions nummer, och en lista av alla filer som ligger i SYS:LOGIN, SYS:PUBLIC, och SYS:SYSTEM kataloger. Dessa listor bör man sedan periodvis kolla igenom och jämföra med originalen för att försäkra sig om att inget har ändrats eller lagts till.

 

Använder man bara NLMer i system-katalogen (SYS:SYSTEM) så använd kommandot SECURE CONSOLE för att förhindra att NLMer laddas in via diskett eller från något annat ställe.

 

Att hackers byter ut filer kan hända, som att använda en annan LOGIN.EXE i public katalogen som är special-programmerad för att göra mer än att bara logga in en i servrar, såsom att logga login-names + passwords. Det går också att modifiera existerande .NCF filer och Login Script för att komma in i systemet, så det kan vara bra att mha ovanstående listor kolla att inga nya har lagts till eller existerande har ändrats.

Logga system consolen, genom att använda LOAD CONLOG.NLM på servern så loggas system aktiviteten i en fil, SYS:ETC\CONSOLE.LOG. Denna fil kan vara bra att kolla (LOAD EDIT SYS:ETC\CONSOLE.LOG). Filen är iof inte speciellt svår att modifiera för utomstående, så lita inte fullt på allt som står i den filen.

På 3.x servrar bör man undvika att vara inloggad som Supervisor då det finns många program (ex. HACK.EXE) som kan göra en till Supervisor när den riktiga Supervisor är inloggad.

Använd Lock File Server Console alternativet i Monitor, denna går dock väldigt lätt att komma runt i 3.x (man hoppar in i ett debugger-program L-SHIFT - R-SHIFT - ALT - ESC och skriver in en viss rad) men i 4.x är den väldigt knepig att lura, så denna funktion bör användas flitigt!

Använd EXIT i slutet av System Login Scriptet, genom att lägga till EXIT som sista rad i System Login Scriptet, så eliminerar det möjligheten till Login Script attacker som nämdes ovan.

Leta upp gömda containers, genom att periodvis använda NLIST USER /A eller Connection Information i MONITOR bör man kolla om det finns någon "okänd" user inloggad i systemet med en "okänd" container i sin context. Finns det kan du misstänka att du har gömda containers i NDS. Du kan då ta reda på vad den usern har för MAC-adress (genom att trycka return på usern i Connection Information och titta på fältet Network Address) och sedan jämföra den med dina listor och se vilken dator som har det nätverkskortet med den adressen och sedan traska över till personen i fråga och börja smiska rumpa. Om du är intresserad av hur man går tillväga för att gömma containers följ denna länk.

Använd RCONSOLE minimalt, det finns nämligen ganska många "sniffers" som kan fånga upp RCONSOLEs lösenord, iof så är RCONSOLEs lösenord krypterade, men ändå ingen match för bra dekryptering-program. Om du känner att du måste använda RCONSOLE så skriv inte ut lösenordet i klartext i autoexec.ncf utan skriv ist. LOAD RCONSOLE SECURE eller LOAD RCONSOLE ENCRYPT.

 

Byt placering av RCONSOLE.EXE, vanligtvis brukar RCONSOLE ligga i PUBLIC katalogen som alla kommer åt. Genom att flytta denna till SYS:SYSTEM så kommer bara folk med tillräckliga rättigheter åt den, vilket kan vara bra om man vill försvåra access till servern via RCONSOLE.

 

Använd bara den version av FTP.NLM som tillåter en att använda Name Space NFS därför att den är säkraste.

 

Uppgradera servern, iom att de flesta kända hacking-teknikerna är för 3.x så kan det vara klokt att uppgradera till 4.11 och utföra de säkerhetsåtgärder beskrivna i detta dokument. Och så snart det går, uppgradera servern till 5.0 som enligt Novell ska vara väldigt säkert (inget system är helt säkert dock).

Hålla sig updaterad, genom att hänga med i de nyhetsgrupper på internet som tar upp ämnet säkerhet i dator-system så kan man hålla sig uppdaterad om nya och gamla säkerhets-hål. Jag listar några av de vanligaste nyhetgrupperna här:

• alt.2600
• alt.2600.crackz
• alt.2600.hackerz
• alt.bio.hackers
• alt.cracks
• alt.hackers
• alt.hackers.discuss
• alt.hackers.malicious
• alt.hackers.groups
• alt.security
• comp.os.netware.security

 

tillbaks till toppen

Skrivet av Jonas Wibom / Säkerhetsgruppen 980402

Nätverkssäkerhet (4121)

Säkerhetskopiering (backup) är en av de viktigaste momenten i säkerheten.
Det kan hjälpa om hårddisken kraschar eller server går sönder av någon annan anledning.

Trots allt det är inte så många som tar säkerhetskopior på sitt arbete. På de flesta företag kopieringen har automatiserats eftersom det kan kosta dyrt för ett företag om allt data försvinner. Det tar tid att installera om systemet och alla profiler och program. Dem flesta data försvinner för gått.

För att det skulle inte hända bör en nätverksadministratör göra regelbunden säkerhetskopieringen.

Den vanligaste typen av media för säkerhetskopiering är magnetbandkassetter och de kan rymma ungefär 14GB.

Man måste göra plan för säkerhetskopieringen. Och kopior av data ska bevaras i brandskåp, men inte i samma rum som server.

SBACKUP heter Novells kommandon för säkerhetskopieringen. Det är en metod att kopiera alla filer och katalogtjänstens träd från alla servrar och arberstationer på ett nät.

Det finns olika strategier för kopiering. En av de är totalkopia. Det betyder att man tar en kopia på systemet i sin helhet. Hela hårddisken kopieras. Det är ganska enkelt men det tar lång tid och mycket band. Det kan bli många band efter ett tag. En annan metod heter Inkrementell. Det betyder att man kopierar dem filer som har ändrats efter sista kopieringen . Tar mindre band och går fortare. Men svårare att återställa om något skulle hända. Tredje metoden heter Differential, ett nytt strategi. Man gör en kopia av information som har ändrast efter sista fulla kopieringen. Det är också en snabb och lätt metod för kopieringen, rekommenderas köra varje dag.

 

UPS (Uninterrupttible Power Supply)

Det kan hända att strömmen går. Då är det viktig att UPS tar över en stund så att man hinner spara data och stänga av systemet på ett sätt. UPS ser till att strömmen inte bryts hur som helst. Den kontrollerar spänningen som kommer ut ur eluttaget. När strömmet slutar komma går UPSen över till sina batterier och ser till att servern får strömmen ändå. Man kopplar UPS mellan elnätet och server resten sköter den själv. UPS batterierna håller normalt mellan fem och halvtimme. Det räknas att man hinner spara information och ta ner systemet och program på rätt sätt så att det blir enkelt att starta igen när strömmen återvänder.

Vissa UPS kan själva stänga Operativ systemet av vid ström avbrott. Då ett speciell program måste vara på server som klarar av saken. Sådana program finns från tredjepartsleverantörer att köpa. Det är viktigt att programmet klarar av att automatisk skicka ut larm till alla användare om att strömmen har gått och att de har ett visst antal minuter på sig att spara sitt arbete. Nätverksadministratörens uppgift är att se om UPS fungerar som det ska och att batterierna är fulladdade.

Hels ska programmet koppas till ett övervakningsprogram och att UPSen har lysdioder på framsidan så att det snabbt framgår hur allt fungerar. I våras fall har vi inte tillgång till sådant utrustningen.

Tillträde till datorrummen. Dörarna skall hållas låsta. Kan endast öppnas med kort.

Mat och dryck får ej förekomma i datasalarna.

 

Serversäkerhet

Servrarna skall köras "remote".

• Skapa krypterat password! (REMOTE ENCRYPT). Se till att REMOTE.NLM och RSPX laddas automatiskt m.hj.a AUTOEXEC.NCF
• "Ta bort DOS" med SECURE CONSOLE
• Lås servern med MONITOR.NLM.
• Ta bort keyboard, mus och skärm från servern.

Kablage mm Rätt kablage skall användas.

Intrång, virus mm

Virus checklista.

• Antivirusprogram skall finnas på alla datorer. På servrar förslagsvis DOS-version av Dr Salomon på DOS-partitionen. På Novellpartitionen ? Det finns antivirusprogram för Netware som vi inte provat. På klientrarna Dr Salomon.

• Kolla alla disketter! Bort med alla virus.

• Virusprogram kan orsaka problem vid installationer. Behövs det kopplas bort då.?

Login/password authentication.

Självklart skall lösenord användas. Dessa lösenord skall vara "svåra" lösenord; de skall helst inte vara namn eller ord som kan hittas i ordlistor. Blanda bokstäver och siffror.

Checklista för inställning vid skapande av users:

• Password required? Yes Obs! Ej default
• Minimum password length:6. Force unique passwords:90 dagar. (I login script)
• Ingen restriction till nod/nätverk (resande users), men concurrent logins:1
• Time restrictions:per/rum (olika tidszoner/arbetstider)?
• Grace logins:4
• Intruder detection :on

Lösenord för setup ? Svårt med installation???

Admin

Skapa en "vanlig" user med alla rättigheter till roten. Det är denna som man bör logga in till. Adminusern används bara när det verkligen behövs. Tex vid mergning.

 

Mergning av träd

Rättigheter till roten i det gamla trädet flyttas med till det nya. Varning! Om användare inte skall ha sådana rättigheter i det nya trädet bör de tas bort redan före mergning.

Gateway firewall.

Internet har blivit mycket användbar men samtidigt kopplingen mellan ett internt nät och Internet en stor fara. En bra brandvägg kan stoppa oönskade besökare. En brandvägg är en host som ligger emellan den stora världen och det lokala nätverket. Denna host skickar inte ut någon information om det lokala nätverket , vilket gör det osynligt för omvärlden. En brandvägg kan vara från router till proxy (paketfiltreringen), i våras fall är det server som ska fungera som gateway. Den ena nätverkskort avses för interna nätet och det andra för gateway. Server ska köra TCP/IP protokoll föra att kommunicera med Internet och IPX för lokal trafik. Gateway använder bara IP adressen för att gå mot Internet. Genom att skilja på interna och externa IP-adresser hindras utomstående att få tillgång till det interna nätet.
Man bör tänka på då man konfigurerar en branvägg:

1. Brandvägg maskinen måste ta emot all e-mail som skickas till systemet, och därefter vidare skicka det till rätt användare.
2. Brandvägg maskinen ska inte 'mounta' några filsystem via NFS, eller låta några av sina filsystem vara monteringsbara.

3. Brandväggs hosten ska inte lita (trusted hosts) på någon annan host, ingen lokal host ska heller inte lita brandväggs hosten. och liknande ska bara tillåtas utföras från brandväggen, om de nu tillåts överhuvudtaget.

Meningen med en brandvägg är att stoppa crackers från andra datorer i nätverket. Säkerheten måste därför vara extra hög på brandväggs datorn. Men man bör akta sig för att ha en för låg säkerhet 'bakom' brandväggen, kommer en cracker väl in i brandväggs hosten så har han då inga problem att ta sig vidare.

 

Loggfiler

Det finns flera loggfiler som är bra att veta om och använda bland annat när något oförklarligt har hänt eller för att se inloggningsförsök.

 

Audit-funktionen

Novell Netware har en Audit-funktion som låter dig spara en logg över allt som sker på nätet. Se till att den är igång. Audit skyddar inte mot intrång, men gör det enklare för dig att se om någon har försökt ta sig in och i så fall hur. Med hjälp av logguppgifterna blir det betydligt enklare att spåra inkräktaren och om nödvändigt förbättra säkerheten på en viss punkt. Hackare tycker inte särskilt mycket om Audit eftersom de därmed lämnar fotspår efter sig. De brukar därför snabbt försöka ta reda på om funktionen används och kan i så fall bli avskräckta.

 

Loggfiler:

SYS: \ GW_INFO LOG
GW_AUDIT LOG

I SYSTEM\ DSMISC.LOG

ABEND.LOG
DSREPAIR.LOG
INSTALL LOG
I ETC\ CONSOLE.LOG
AUDITSAV .LOG
AUDIT .LOG
FTPSERV.LOG

Exempel på hur DSREPAIR filen kan se ut:

/****************************************************

Netware 4.1 Directory Services Repair 4.40 , DS 5.73

Log file for server "4121_SRV.4121.4121_org" in tree "4121_TREE"

Time synchronization and server status information

Start: Thursday, 1998 April 2 15.53.08 Local Time

DS.NLM Replica Time Time is Time

Server name Version Depth Source in sync +/-

---------------------------+---------+---------+-----------+--------

4121_SRV.4121.4121_org 5.73 0 Secondary No 0

*** END ***

*****************************************************

Netware 4.1 Directory Services Repair 4.40 , DS 5.73

Log file for server "4121_SRV.4121.4121_org" in tree "4121_TREE"

Start: Thursday, 1998 April 2 15.54.50 Local Time

Retrieve replica status

Partition: [Root]

Replica: 4121_SRV.4121.4121_org 1998/04/02 15:54:20

All servers synchronized up to time: 1998/04/02 15:54:20

*** END ***

/***************************************************/

Netware 4.1 Directory Services Repair 4.40 , DS 5.73

Log file for server "4121_SRV.4121.4121_org" in tree "4121_TREE"

Time synchronization and server status information

Start: Thursday, 1998 April 2 15.57.08 Local Time

DS.NLM Replica Time Time is Time

Server name Version Depth Source in sync +/-

---------------------------+---------+---------+-----------+

4121_SRV.4121.4121_org 5.73 0 Secondary No 0

*** END ***

/**********************************************

Netware 4.1 Directory Services Repair 4.40 , DS 5.73

Log file for server "4121_SRV.4121.4121_org" in tree "4121_TREE"

Start: Thursday, 1998 April 2 15.57.20 Local Time

Retrieve replica status

Partition: [Root]

Replica: 4121_SRV.4121.4121_org 1998/04/02 15:55:41

All servers synchronized up to time: 1998/04/02 15:55:41

*** END ***

/*******************************************/

Netware 4.1 Directory Services Repair 4.40 , DS 5.73

Log file for server "4121_SRV.4121.EAST.CNE1.CNE" in tree "CNE_TREE"

Start: Tuesday, 1998 April 7 10.00.14 Local Time

Retrieve replica status

Partition: [Root]

Replica: 4140_SRV.4140.CNE3.CNE 1998/04/07 09:50:30

Replica: 4021_SRV.4021.CNE2.CNE 1998/04/07 09:50:19

Replica: 4023_SRV.4023.CNE2.CNE 1998/04/07 09:59:41

Replica: 4125_SRV.4125.EAST.CNE1.CNE 1998/04/07 09:57:51

Replica: 4113_SRV.4113.WEST.CNE1.CNE 1998/04/07 09:53:19

Replica: 4123_SRV.4123.EAST.CNE1.CNE 1998/04/07 09:53:10

Replica: 4115_SRV.4115.WEST.CNE1.CNE 1998/04/07 09:58:22

Replica: 4119_SRV.4119.EAST.CNE1.CNE 1998/04/07 09:52:40

Replica: 4117_SRV.4117.WEST.CNE1.CNE 1998/04/07 10:00:12

Replica: 4121_SRV.4121.EAST.CNE1.CNE 1998/04/07 09:53:00

All servers synchronized up to time: 1998/04/07 09:50:19

*** END ***

/************************************************/

Netware 4.1 Directory Services Repair 4.40 , DS 5.73

Log file for server "4121_SRV.4121.EAST.CNE1.CNE" in tree "CNE_TREE"

Start: Tuesday, 1998 April 7 10.01.54 Local Time

Retrieve replica status

Partition: [Root]

Replica: 4140_SRV.4140.CNE3.CNE 1998/04/07 09:50:30

Replica: 4021_SRV.4021.CNE2.CNE 1998/04/07 09:50:19

Replica: 4023_SRV.4023.CNE2.CNE 1998/04/07 09:59:41

Replica: 4125_SRV.4125.EAST.CNE1.CNE 1998/04/07 09:57:51

Replica: 4113_SRV.4113.WEST.CNE1.CNE 1998/04/07 09:53:19

Replica: 4123_SRV.4123.EAST.CNE1.CNE 1998/04/07 09:53:10

Replica: 4115_SRV.4115.WEST.CNE1.CNE 1998/04/07 09:58:22

Replica: 4119_SRV.4119.EAST.CNE1.CNE 1998/04/07 09:52:40

Replica: 4117_SRV.4117.WEST.CNE1.CNE 1998/04/07 10:00:12

Replica: 4121_SRV.4121.EAST.CNE1.CNE 1998/04/07 09:53:00

All servers synchronized up to time: 1998/04/07 09:50:19

*** END ***

/*************************************************/

Netware 4.1 Directory Services Repair 4.40 , DS 5.73

Log file for server "4121_SRV.4121.EAST.CNE1.CNE" in tree "CNE_TREE"

Time synchronization and server status information

Start: Tuesday, 1998 April 7 10.02.06 Local Time

DS.NLM Replica Time Time is Time

Server name Version Depth Source in sync +/-

---------------------------+---------+---------+---------

4140_SRV.4140.CNE3.CNE 5.73 0 Secondary Yes 0

4021_SRV.4021.CNE2.CNE 5.73 0 Secondary Yes 0

4023_SRV.4023.CNE2.CNE 5.73 0 Secondary Yes 0

4125_SRV.4125.EAST.CNE1.CNE 5.73 0 Secondary Yes 0

4113_SRV.4113.WEST.CNE1.CNE 5.73 0 Secondary Yes 0

4123_SRV.4123.EAST.CNE1.CNE 5.73 0 Secondary Yes 0

4115_SRV.4115.WEST.CNE1.CNE 5.73 0 Secondary Yes 0

4119_SRV.4119.EAST.CNE1.CNE 5.73 0 Secondary Yes 0

4117_SRV.4117.WEST.CNE1.CNE 5.73 0 Single Yes 0

4121_SRV.4121.EAST.CNE1.CNE 5.73 0 Secondary Yes 0

*** END ***

Hur kan conlog.log se ut:

CONLOG-1.03-10: System console logging started Wed Apr 8 11:51:42 1998.

CONLOG-1.03-9: Logging system console to sys:etc\console.log.

CONLOG-1.03-22: Log file size restricted to 100 kilobytes.

Loading module SNMP.NLM

SNMP Agent

Version 3.03 1996 January 3

Copyright 1992-1996 Novell, Inc. All rights reserved.

Auto-loading module TLI.NLM

NetWare Transport Level Interface Library

Version 4.10a 1995 January 30

(C) Copyright 1989-1992 Mentat, Inc.

Portions (C) Copyright 1989-1994 Novell, Inc.

All Rights Reserved.

Auto-loading module IPXS.NLM

NetWare STREAMS IPX Protocol

Version 4.10 1994 October 20

(C) Copyright 1989-1994 Novell, Inc.

All Rights Reserved.

98-04-08 13.12.24 : DS-5.73-50

Established communication with server 4125_SRV.4125.EAST.CNE1.CNE

4121_SRV:load netbasic

Loading module NETBASIC.NLM

NetBasic Runtime - Serial#: 300-051100101

Version 4.11 1996 July 9

(C) Copyright 1993-1996 HiTecSoft Corp. All Rights Reserved.

Auto-loading module MATHLIBC.NLM

NetWare Math Emulator Library Auto-Load Stub

Version 4.20 1995 October 6

Copyright (c) 1995 Novell, Inc. All rights reserved.

NetBasic: Type SHELL to start the Interactive Shell.

4121_SRV:shell

Loading module NB.NLM

NetBasic Engine NMX Component - Build 4.015

Version 4.11 1996 July 10

(C) Copyright 1993-1996 HiTecSoft Corp. All Rights Reserved.

98-04-08 13.35.45 : DS-5.73-47

Unable to communicate with server MAIN_SRV.CNE

 

98-04-08 13.35.54 : DS-5.73-50

Established communication with server MAIN_SRV.CNE

 

98-04-08 13.36.23 : DS-5.73-47

Unable to communicate with server 4119_SRV.4119.EAST.CNE1.CNE

 

98-04-08 13.36.28 : DS-5.73-50

Established communication with server 4119_SRV.4119.EAST.CNE1.CNE

 

98-04-08 13.36.29 : DS-5.73-50

Established communication with server 4117_SRV.4117.WEST.CNE1.CNE

 

98-04-08 13.36.54 : TIMESYNC-4.15-138

Time synchronization has been established.

 

98-04-08 13.45.08 : DS-5.73-50

Established communication with server 4113_SRV.4113.WEST.CNE1.CNE

 

98-04-08 13.49.16 : DS-5.73-50

Established communication with server 4117_SRV.4117.WEST.CNE1.CNE

Baselining

Genom att ta reda på och spara standardvärden på olika parametrar (från MONITOR.NLM t.ex.) i nätverket kan man upptäcka när det börjar gå snett. Spara värden tex i IntranetWare logbook. Programmet LANalyzer används för att se trender, se vidare.....

Flera volymer

För ökad säkerhet skall hårddisken delas upp i minst två Netwarevolymer. SYS-volymen skall bara de som har ett konto i CNE-trädet komma åt. Det som utomstående (anonymous) skall komma åt skall finnas i en annan volymen.

 

tillbaks till toppen

Skrivet av grupp 4121 / 980407

Partionering och replikering (4123)

Det första vi gjorde var att göra en skiss över hur trädet och dess partitioner skulle se ut. Vi ritade några förslag och detta förslag var det som vi tyckte var bäst (se bilden ovan). Det togs även upp på admin mötet så att alla visste ungefär hur det skulle se ut.

Syfet med denna partitionering var att det skulle bli lätt att administrera och inte få någon trafik över WAN länkar. Vi placerade endast replikor lokalt vilket medför att man slipper uppdateringar över WAN länkar. Det blev därför bara två replikor i B och D partitionerna.

Vi strukturera upp partitionerna efter de tre organisational units som skapats. CNE1 blev lite för stor för att den innefattade sju rum så vi valde att dela upp den i två olika partitioner. De två olika partitionerna fick namnen East och West.

När vi hade fått hela trädet i ordning och alla servrar fungerade var det dags att partionera och replikera.

Vi gjorde partitioneringen och replikeringen i NDS manager. Första steget var att partionera upp trädet i tre delar, [root] partitionen var redan skapad. Sedan gick vi in i varje server och markerade den så att man kunde se vad den hade fått för replikor. Utifrån det läget kan man sedan ändra eller ta bort replikor.

Man vill ha så lite trafik över WAN länkarna som möjligt men det måste finnas något som pekar till att det finns andra partitoner. Det gör subordinate references.

Alla servrar som har en Master replika till [root] i en partition får en subordinate references till de andra partitionerna.

De servrar som finns i [root] partitionen, vare sig de har en Master eller Read/Write får en subordinate references till alla de andra partitionerna

	4113	4115	4117	4119	4121	4123	4125	4021	4023	4140
A	R/W	R/W	M	R/W					R/W	R/W
B	S	S	S	S					S	M
C	S	S	S	M	R/W	M			S	S
D	S	S	S	S			R/W	R/W	M	S

 

klicka på bilden för att förstora

 

tillbaks till toppen

 

Skrivet av Joakim Anuell 980403

Tidssynkronisering (4115)

Skrivet av  980416

LAN och WAN topologi (4115+4117)

klicka på bilden för att förstora

tillbaks till toppen

Skrivet av grupperna 4115 o 4117 / 980416

Mobile Users (4023)

Vi (Carolina, Jakleen och Larissa) fick uppgiften att konfigurera Kalevi som Mobile User så att han kan logga in på varje lokation och kolla på resurser eller använda program.

Förklaring

Först ska vi förklara lite vad är mobile users. En Mobile User är vilken som helst LAN användare som inte alltid jobbar på ett och samma kontor och/eller samma PC. Den kan flytta mellan olika platser inom företaget, t ex byggnader, kontor osv beroende på dess arbetsuppgifter. Kontakten mellan denna Mobile User och dennas huvudkontor kan vara via lokala topologier som Ethernet eller Token Ring, Modem, eller via WAN länkar.

Mobile Users

Fixed PC:

Denna mobile user jobbar vid en och samma dator på varje kontor han befinner sig under vissa perioder.

Notebook or laptop PC with docking station:

Denna user har en bärbar dator med sig som kan bli använd med eller utan lan anslutning. När han vill ha kontakt med LAN använder han en dock-station som oftast har ett tangentbord, en bildskärm och ett nätverkskort(NIC).

Notebook or laptop PC with LAN adapter:

Denna user har också sin bärbara dator med sig som är försedd med adapter för att ha kontakt med LAN. Parallella portar tillåter användare att kontakta lan via BNC eller RJ-45 connectors.

Network connect remote node:

Är en användare som ha tillgång till lan via en internal eller external modem.

Hybrid Mobile User:

Är en användare som använder mer än en metod för att ansluta sig till lan.

För vår project valde vi att använda Fixed PC. Vi skapade user kalevi som har denna context: users.4023.cne2.cne

Mobile User Login Script

 

;*****User Information*****

;

WRITE "Common Name: %CN"

WRITE "Full name: %LAST_NAME"

WRITE "Login name: %LOGIN_NAME"

WRITE ""

;

;*****Location Information*****

;

WRITE "File server: %FILE_SERVER"

WRITE "Network: %NETWORK"

;The next string is for Mobile Users who work with laptop

;computers.

;WRITE "Node: %P_STATION"

WRITE "Location: %L"

WRITE ""

PAUSE

;*****Context Information*****

;

;The two next context identifiers can be used determine a user's

;location in the Tree if it is not already known as a result of setting

;the NAME CONTEXT="OU=Users.OU=4023.OU=CNE2.O=CNE"

;in NET.CFG file on every workstation the Mobile User loggs in.

;These two strings are better for our user Kalevi who will use the

;local PCs on every location.

WRITE "Requester context: %REQUESTER_CONTEXT"

WRITE "Login context: %LOGIN_CONTEXT"

WRITE""

;

;*****Access to Applications*****

;

;Map SYS:PUBLIC to nearst server

MAP S1:=%FILE_SERVER/SYS:PUBLIC

;

;Map Application Directories

;Here you can map to Directory Map object in the user's context.

;It allows the user to run applications in different Locations.

;MAP S2:=.....

;MAP S3:=....

;

;*****Access to Shared Data Files*****

;Here you can map to Directory Map object in the user's

;context. It allows the user to share data files in different Locations

;(if needed).

;MAP S4:=.....

;*****Access to the Home Directory******

;

MAP H:=4023_SRV/VOL1:USERS/%LOGIN_NAME

;

PAUSE

;*****Access to Printers*****

;

;Capture to Print Queues

;Capture LPT1 to a local Queue Depending on user's location.

;IF "%NETWORK"="EXTERNAL IPX NUMBER" #CAPTURE L=1 Q=...

;

WRITE "Login script end"

END

Slutsats

Med denna login script kan user Kalevi logga in i NDS trädet från vilken kontor som helst, ha tillgång till lokala resurser och hitta till sin hemkatalog i sin context. Han måste dock ha filsystem rättigheter read och file scan för att kunna köra program.

 

tillbaks till toppen

           Skrivet av grupp 4023 / 980408