webnetwork Pre-Installation Configuration Checklist

Transcription

1 webnetwrk Pre-Installatin Cnfiguratin Checklist Stneware, Inc. Date: Oct 3rd 2012 Prduct: webnetwrk versin 6.0 sp9 and 6.1 Dcument revisin:

2 Intrductin This dcument is intended t prvide infrmatin that will assist in webnetwrk architecture design, server hardware selectin, OS chice, firewall cnfiguratin, directry services cnfiguratin, and DNS cnfiguratin prir t a webnetwrk prductin installatin engagement. During the pre-installatin kickff meeting, a Stneware cnsultant will wrk with yu t answer any questins and help yu make apprpriate chices based n yur individual needs. The installatin prcedure will require a technical cntact within the rganizatin that will prvide access t netwrk resurces. It is highly recmmended that this technical cntact be actively invlved in the installatin prcess fr the purpse f knwledge transfer. The frmat will be a learn-as-yu-g and will nt include any frmal training prcess. Executive Gals In rder t deliver the mst effective webnetwrk slutin, rganizatinal gals need t be established and pririties set - within the scpe f the PID (Prject Initiatin Dcument.) It is imprtant that the rganizatinal gals f the IT Executive are cmmunicated t the Stneware cnsultant, as well as the custmer IT technical resurce. Executive gals will be discussed during the pre-installatin kickff meeting. webnetwrk Architecture Determinatin webnetwrk is designed with a tw-tiered architecture cnsisting f a webnetwrk Server and webrelay. Bth the webnetwrk Server and webrelay can run cncurrently n a single (physical r virtual) server, r the webnetwrk Server and webrelay can be implemented independently n separate servers. The decisin t implement a single server r multiserver cnfiguratin will have an effect n the hardware cnfiguratin, perating system chice, and firewall cnfiguratin. A Stneware cnsultant will help yu determine the apprpriate webnetwrk architecture based n yur needs and capabilities. Example f typical true dual firewall DMZ architecture with ne cmbined internal webnetwrk Server/webRelay, and ne dedicated public webrelay: 2

3 Example f typical simple firewall architecture with ne cmbined internal webnetwrk Server/webRelay: 3

4 a) Size f deplyment 1. Stneware webnetwrk implementatins can range frm as few as ten cncurrent users t thusands f cncurrent users. Fr increased perfrmance and security, especially in larger implementatins, a tw-tier cnfiguratin (dedicated webrelay and cmbined webnetwrk Server/webRelay) is highly recmmended. 2. Fr smaller rganizatins (25 cncurrent users and less), where it is impractical t deply a multi-server cnfiguratin due t the additinal hardware expense, a basic single server installatin running bth the webnetwrk Server and webrelay (n the same hst server) can be utilized. As the webnetwrk System grws, it can be recnfigured int a tw-tiered cnfiguratin withut additinal licensing expense. b) Firewall Capabilities and Cnfiguratin 1. The tw-tiered nature f Stneware s webnetwrk allws it t be easily deplyed within a true dual firewall DMZ architecture prviding additinal security and flexibility. Stneware suggests a tw-tiered (multiple server) implementatin where maximum security is a pririty. A basic single server implementatin can be utilized if the rganizatin des nt have a DMZ implemented and the deplyment is supprting less than 25 cncurrent users. c) Cmmn webnetwrk Server / webrelay Cnfiguratins 1. One cmbined internal webnetwrk Server/webRelay (ne physical/virtual server - basic budget cnfiguratin) 2. One cmbined internal webnetwrk Server/webRelay, and ne dedicated public webrelay (tw physical/virtual servers - recmmended minimum cnfiguratin mre secure tw tiered cnfiguratin) 3. One cmbined internal webnetwrk Server/webRelay, and tw dedicated public webrelays (three physical/virtual servers - useful fr lad balancing between DMZ webrelays a hardware lad balancer* t balance the lad between the webrelays is recmmended (nt required) fr maximum flexibility and perfrmance) 4. Tw cmbined internal webnetwrk Server/webRelays, and tw dedicated public webrelays (fur physical/virtual servers - useful fr lad balancing fr bth Internal and DMZ webrelays - hardware lad balancers*, t balance the lad between the internal and public webrelays, are recmmended (nt required) fr maximum flexibility and perfrmance) 5. Tw dedicated internal webnetwrk Servers, tw dedicated internal webrelays, and tw dedicated public webrelays (six physical/virtual servers fully-meshed clustered servers and independent redundant internal and DMZ Relays - hardware lad balancers*, t balance the lad between the internal and public Relays, are recmmended (nt required) fr maximum flexibility and perfrmance) 4

5 Please see the webnetwrk Server Prgressin dcument fr visual representatins f these cmmn webnetwrk Server / webrelay design ptins: * Stneware will NOT be respnsible t prvide, cnfigure, r maintain any lad balancing devices. The lad balancer vendr shuld be cnsulted fr apprpriate cnfiguratin changes. The alternate methd f Rund-rbin DNS is supprted, but is nt recmmended as it des nt prvide true lad balancing r fault tlerance. Hardware Cnfiguratin Stneware recmmends (nt required) server class hardware fr all webnetwrk Servers and webrelays. Stneware webnetwrk will take full advantage f multiple CPU/cre prcessrs and available RAM dependent n hst perating system limitatins. The fllwing specificatins are a basic guide t assist in chsing an apprpriate hardware platfrm. a) Hardware Recmmendatins 1. Prcessr Minimum: 1.2 Ghz prcessr (less than 25 cncurrent users) Recmmended: 2+ Ghz dual (dual-cre, multiple-cpu, etc.) prcessr r greater (mre than 25 cncurrent users) 2. Memry Minimum: 1GB RAM (less than 25 cncurrent users) Recmmended: 4GB RAM r greater (webnetwrk can nly utilize 1GB f RAM n a 32bit perating system due t OS limitatins, 64bit OS memry addressing capability is virtually limitless) 3. Netwrking 4. Disk 100mb r gigabit netwrk interface Minimum: 1GB available disk space Recmmended: 4GB available disk space A redundant disk subsystem is recmmended n all servers fr increased availability and reliability, but is nt required. webnetwrk is nt a read/write disk intensive applicatin. b) Which cmpnent f webnetwrk shuld run n the faster server in an envirnment with multiple physical servers f different specificatins? This depends n the webnetwrk services being implemented. In an envirnment where many cre services will be used (e.g. Reprt Services, Cmmunity Services, File Services, Pipeline Services, teampages, webpages, etc.) it is advantageus t utilize the mre pwerful hardware fr the webnetwrk Server. If few services will be implemented it may make sense t utilize the mre pwerful hardware n the webrelay. A Stneware cnsultant can wrk with yu t help decide hw t efficiently prvisin hardware based n individual webnetwrk implementatins. 5

6 Operating System a) Chsing an perating system - Stneware webnetwrk is platfrm independent and can run n mst current server perating systems. It is recmmended t chse yur perating system based n the fllwing criteria: 1. Security - Ability t secure r harden the perating system frm malicius attacks. Operating system manufacturers shuld be cnsulted fr infrmatin related t securing the OS based n the envirnment in which it will be deplyed. Dcumentatin is available fr mst perating systems that will prvide instructins fr securing the OS based n the intended use. 2. Skill General cmfrt and ability t supprt the perating system frm a technical standpint b) Supprted Operating Systems - c) Install, Cnfigure, and Patch Operating System - It is recmmended t install Stneware webnetwrk n a clean perating system, withut any services that culd interfere with webnetwrk functinality. A web server is included as part f the webrelay; therefre ther web servers shuld nt be installed n the same server as webnetwrk. All perating systems shuld be updated with the latest patches prir t webnetwrk installatin. d) Assign static IP address t all systems and dcument IP addresses e) Disable anti-virus and firewall sftware Anti-virus and firewall sftware shuld be disabled n servers prir t (and during) installatin f webnetwrk these services may be re-enabled after installatin. Brwser Supprt Stneware's webnetwrk requires a brwser with JavaScript supprt. Sme features require Java (1.6 r higher) n lcal wrkstatin t wrk. Clients will need t meet the minimal requirements f a brwser and Internet/netwrk cnnectin fr full functinality. The list belw utlines a list f suggested brwsers that have been tested and are currently in use by ur custmers. a) Recmmended Brwsers - 6

7 Firewall Cnfiguratin The webnetwrk Installatin and Cnfiguratin Guide, included in the full webnetwrk nline dcumentatin, prvides a cmplete descriptin f the cnfiguratin necessary in a DMZ/Firewall setting. This sectin prvides the basic prt cnfiguratin infrmatin needed t install the webrelay and webnetwrk Server in a prductin envirnment. a) Web brwser cmmunicatin with webrelay - Open prts 80 and 443 bi-directinally between the public Internet and the webrelay(s) b) webrelay cmmunicatin with webnetwrk Server (separate Relay/Server installatin) Open prts 1099, 4500, 4501, and bi-directinally fr TCP traffic between the webrelay and webnetwrk Server when cnfigured n separate bxes. 1. Prts 1099 and 4500 are used fr RMI (remte methd invcatin) 2. Prt 4501 is used fr Pipeline Services 3. Prt is used fr Relay Central Directry Services Preparatin Stneware s webnetwrk utilizes directry services as its primary cnfiguratin and user accunt stre. Directry health must be verified and varius directry features must be enabled, befre webnetwrk can be installed int a prductin netwrk envirnment. Cmplete the fllwing checklist items fr the relevant directry in the prductin envirnment. Micrsft Active Directry (2000, 2003, and 2008) a) Run Stneware Envirnment Check utility - T dwnlad the utility, visit ur Stneware Supprt Utilities page and dwnlad and install the Env Check utility. Fr instructins n hw t run the utility, visit ur Running Env Check page. IMPORTANT exprt the utilities utput and t yur Stneware Cnsultant when cmpleted fr verificatin. b) Enable SSL access t LDAP if nt already enabled T enable full functinality webnetwrk needs t cnnect t LDAP via a secure SSL (prt 636) cnnectin. Micrsft Certificate Server (Enterprise rt CA r Enterprise subrdinate CA) must be installed n an AD member server t enable LDAP ver SSL. DO NOT install this n the Stneware webnetwrk Server(s). If yu cannt run the swenvcheck utility with SSL enabled, please see Enable SSL ver LDAP n hw t set up the Micrsft Certificate Server with default settings. c) Dmain administratr accunt needed fr installatin - webnetwrk Server requires the real dmain administratr accunt t extend the Active Directry schema during installatin. Once the schema is extended, 7

8 and installatin is cmplete, a different (e.g. swadministratr) accunt can be created with reduced access privileges limited t users/grups/cntainers accessed by webnetwrk Server. d) Verify administratr accunt has schema-admin rights, the dmain cntrller used fr LDAP is the schema master, and allw schema updates is enabled G t Stneware Supprt Utilities and click Schema Diag t dwnlad the AD Schema Diagnse applicatin. This applicatin will verify that the administratr accunt has schema-admin rights, which server is the schema master, and if allw schema updates is enabled. The applicatin must be run frm a Windws cmputer that is part f the Active Directry dmain (e.g. desktp lgged int dmain, Dmain Cntrller server, etc.), and is lgged in with the admin accunt that will be used fr the prductin installatin. Please click the Save buttn in the Schema Diag utility, save the results t a file, and the file t yur Stneware Cnsultant. The Active Directry server must have Allw Schema Updates ptin enabled t extend the schema and install webnetwrk. If Allw Schema Updates is nt enabled, please see fr mre infrmatin n hw t enable schema updates (n Windws Server 2003 and abve yu will nt be able t enable Schema Updates via the Schema Management Cnsle yu will have t enable Schema Updates by means f the Windws Registry.) e) Run Micrsft utilities dcdiag and DNSLint t check Active Directry health DNSLint will make sure there are n replicatins issues. Please see fr mre infrmatin n DNSLint. Dcdiag will analyze the dmain cntrller s state and reprt any issues. See fr detailed infrmatin n the dcdiag.exe utility. Cnsult Micrsft dcumentatin fr any errr messages fund using these utilities. f) Verify Dmain Cntrller DNS Reslutin frm webnetwrk Server - T verify prper reslutin f the DNS Name / IP Number, bring up a cmmand prmpt n the machine t be used as the webnetwrk Server, and then d a ping -a xxx.xxx.xxx.xxx f the DNS Name / IP Number f the dmain cntrller. This shuld reslve t the REAL name f the dmain cntrller - if the dmain cntrller is named DC1 then the address shuld reslve t dc1.rganizatin.cm. If the DC des nt reslve crrectly the issue needs t be reslved r a manual entry will need t be made in the hsts file n the webnetwrk Server machine t prperly reslve the dmain cntrller. If manual mdificatin f the hsts file is necessary re-d the ping -a xxx.xxx.xxx.xxx test after mdifying the file t make sure it nw reslves prperly. C:\>ping -a Pinging 3-win2k3.swstney3.rg [ ] with 32 bytes f data: Reply frm : bytes=32 time<1ms TTL=128 g) Verify Dmain Tree Rt Reslutin If, fr example, the AD dmain is dc=rganizatin,dc=cm, then at a cmmand prmpt n the webnetwrk Server machine type the fllwing: ping rganizatin.cm - and verify that the IP number is the same IP number frm the Verify Dmain Cntrller DNS Reslutin frm webnetwrk Server checklist item abve. If ping rganizatin.cm des nt reslve t the dmain cntrller IP number then the hsts file f the webnetwrk Server needs t be manually edited t add the entry. This entry must be the LAST entry in the hsts file. After making the change and saving the hsts file verify the hsts file manual entry using the same ping cmpany.cm cmmand as befre. C:\>ping swstney3.rg 8

9 Pinging swstney3.rg [ ] with 32 bytes f data: Reply frm : bytes=32 time<1ms TTL=128 Nvell edirectry (8.5 and newer) a) Verify edirectry versin is 8.5 r newer webnetwrk requires Nvell edirectry versin 8.5 r newer t run. b) Perfrm an edirectry Health-check - See fr infrmatin n hw t perfrm an edirectry health check. c) Timesync Timesync must be accurate thrughut the entire edirectry tree and all servers that are part f the tree must be up and running t avid causing replicatin issues. d) Determine LDAP server with lcal cpy f directry - Fr best perfrmance, Stneware recmmends directing the webnetwrk Server t the IP address f an LDAP server that is als a lcal cpy f the directry. e) Cnfigure LDAP access t edirectry - webnetwrk Server requires LDAP access n prt 389 (nn-secure) r 636 (secure). In a nn-secure (prt 389) cnfiguratin, ALLOW CLEAR TEXT PASSWORDS must be enabled n the LDAP directry bject. f) edirectry tree administratr accunt needed fr installatin - The webnetwrk Server needs t use the REAL tree admin accunt t access the directry and extend the schema during installatin. Once the schema has been extended, and installatin is cmplete, a separate (e.g. swadmin) accunt can be created with reduced access privileges limited t users/grups/cntainers accessed by webnetwrk Server. g) Test LDAP cnnectin via SSL - Verify LDAP cnnectivity t the edirectry LDAP server using the REAL admin username / pass. An LDAP tl like LDAP Brwser r JXplrer can be used t test the LDAP cnnectin t edirectry. Bth f these utilities can be dwnladed frm DNS Cnfiguratin Stneware s webnetwrk technlgy utilizes DNS t prvide virtual access t internal web servers and applicatins. The use f DNS allws webnetwrk t create secure web applicatin cnnectins withut implementing client-side sftware. a) webrelay(s) DNS Names the webrelay requires a unique DNS entry t be addressed by name instead f IP address. This DNS name (e.g. prtal.rganizatin.cm) shuld reslve t the static IP address f the webrelay server. Public DNS servers must reslve the DNS name t the public IP address f the Relay, and the private DNS server must reslve the same DNS name t the private IP address f the webrelay. T simplify cnfiguratin bth the public and private DNS names shuld be identical even thugh they will reslve t different IP addresses based n whether they are reslved frm a public r private DNS. A simple example wuld be prtal.rganizatin.cm reslves t (which will be an IP address f a webrelay) frm inside the private netwrk, and prtal.rganizatin.cm reslves t (als a webrelay) frm the public Internet. The DNS 9

10 name that reslves t Relays and webnetwrk Web Applicatins must be a sub-dmain (must cntain tw dts) f the primary dmain fr example prtal.rganizatin.cm is valid, rganizatin.cm is nt. It is pssible, but will require additinal cnfiguratin and add cmplexity, t use different internal and external dmain names. b) Reverse DNS as f Java 6 Update 22, a reverse DNS lk-up f the IP address must als reslve t the chsen name (prtal.rganizatin.cm). This must reslve crrectly n private DNS and public DNS servers. T test if reverse DNS reslves crrectly, use nslkup frm a cmmand prmpt. First type in the DNS name (example shws prtal.rganizatin.cm) then hit Enter. Next type in the IP address frm the first entry ( ) and make sure it reslves t the DNS (prtal.rganizatin.cm). c:\>nslkup Default Server: dns.rganizatin.cm Address: > prtal.rganizatin.cm Server: dns.rganizatin.cm Address: Name: prtal.rganizatin.cm Address: > Server: dns.rganizatin.cm Address: Name: prtal.rganizatin.cm Address: c) Web Applicatin Virtual DNS Names each web-based applicatin (e.g. Outlk WebAccess, GrupWise WebAccess, PwerSchl, etc.) that will be accessible thrugh the webnetwrk System will need a new unique Virtual DNS Name exclusively fr use by the webrelay(s). This name shuld be unique and nt be in use by any ther system (e.g. swutlk.rganizatin.cm, swgrupwise. rganizatin.cm, swpwerschl. rganizatin.cm.) End users will nt need t knw these Virtual DNS Names as they are used exclusively by webnetwrk. All unique Virtual DNS Names need t be cnfigured t reslve t the static IP address (private and public) f the webrelay(s), nt the IP address f the actual web applicatin web server. Every Virtual DNS Name that reslves t a webnetwrk Web Applicatin must be a sub-dmain (must cntain tw dts) f the primary dmain fr example swwebmail.rganizatin.cm is valid; rganizatin.cm and rganizatin2.cm are nt valid. 10

11 Applicatins, Databases, SSL Certificate, and File Systems Checklist The fcus f many installatins is t integrate and secure the internal applicatins thrugh the webnetwrk prduct. T speed implementatin rganizatins shuld have the fllwing infrmatin fr each applicatin, file system, and database that is t be integrated int the webnetwrk system: Applicatins (web, Windws, Terminal Services, Citrix, etc.): a) Stneware webnetwrk des nt natively hst Windws applicatins, but there are several ways t deliver Windws applicatins seamlessly thrugh webnetwrk. The methd f delivery shuld be chsen based n existing r planned Windws applicatin hsting architecture and specific applicatin requirements. Windws Terminal Server Citrix VDI Applicatin Virtualizatin (e.g. ThinApp) Lcal Windws Applicatins (installed n client PC) RDP r VNC access t individual desktp PC b) Applicatin name c) IP address and Prt Number fr applicatin server If a Citrix r Windws Terminal Server applicatin please prvide applicatin PATH and WORKING DIRECTORY d) Lgin URL fr the applicatin (web applicatins) e) Valid User ID and Passwrd t test the applicatin f) The applicatin administratr shuld be available during webnetwrk applicatin cnfiguratin t assist with technical details as needed g) Web-apps cntaining Adbe Flash as part f the lgin page may have issues with Single Sign-On please cnsult the applicatin develpers fr an alternate lgin page r supprted Single Sign-On methd 11

12 Databases: a) Fur Stneware applicatin databases (teampages, webpages, Relay Lgging, and Cmmunities) default t the included Hypersnic database fr testing and dem purpses nly. Stneware recmmends MySQL 4.x r higher, and Micrsft SQL Server 2000 r higher fr prductin implementatins. An external database (nt the included Hypersnic) is required fr all Stneware Cluster implementatins. b) Database name c) IP address and Prt Number fr database server d) Current supprted JDBC database driver e) Valid User ID and Passwrd t the database / table f) The database administratr shuld be available during webnetwrk database cnfiguratin t assist with technical details as needed g) Stneware Reprts Services supprts mst current database servers with a current JDBC/ODBC driver. SSL Certificate: a) A valid wildcard SSL certificate (*.cmpany.cm) is recmmended b) Chse the preferred Certificate Authrity (CA) fr the rganizatin c) Create accunt and purchase the certificate frm CA d) Certificate Request (CSR) will be generated at time f installatin File System: a) File System Name b) IP address r UNC f the file system c) Supprted file system type (e.g. Windws share/cifs, FTP, etc.) d) Valid User ID and Passwrd t the file system e) The file system administratr shuld be available during webnetwrk file system cnfiguratin t assist with technical details as needed 12

13 webnetwrk Pre-Installatin Checklist Summary Hardware Cnfiguratin and Operating System Checklists Hardware meets expectatins OS cnfigured and patched N firewall/anti-virus/webnetwrk Server.. Firewall Cnfiguratin Checklist External and DMZ firewall cnfigured Directry Services Preparatin Checklist All Directry tests cmpleted DNS Cnfiguratin Checklist DNS recrds created Applicatins, Databases, SSL Certificate, and File Systems Checklist Applicatin servers cnfigured SQL Database installed SSL certificate chsen/purchased File System cnfigured 13