Management through firewalls in relation to NT and

Claus Jespersen

Hewlett-Packard A/S Vestre Kongevej 4-6 DK-8260 Viby J Denmark Direct: (45) 4599 1829 Fax: (45) 8733 1888 e-: Mobile: (45) 4060 1829 [email protected] Solution Architect OpenView/Internet specialist

Prepared by: Claus Jespersen Solution Architect Openview/Internet specialist Date Prepared: Februar 2000 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Document Information Project Name: Management through firewalls in relation to Windows 2000 Project Manager: Document Version No: 1.0 FocusPM Phase: Document Version Date: 17. February 2000 Quality Review Method: Prepared By: Claus Jespersen Preparation Date: 17. February 2000 Reviewed By: Review Date:

Distribution List From Date Phone/Fax Claus Jespersen, Hewlett-Packard Denmark, 17. February +4545991829 [email protected] 2000

To Action* Due Date Phone/Fax

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

Version History Ver. No. Ver. Date Revised By Description Filename 1.0 17. First finished version after a few drafts win2kfwmgt-v1.0.doc February 2000

FocusPM White paper by Claus Jespersen, HP Denmark Page2of2 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

1. Proprietary Notice...... 7 2. Purpose...... 7 3. Target audience...... 8 4. Things to do...... 8 5. General introduction...... 8 6. Overview of common used protocols in Windows 2000...... 10 6.1. NetBIOS Name Resolution (WINS)...... 11 6.2. DNS (Domain Name System) ...... 12 6.2.1 DNS AND NAT...... 14 6.3. NetBIOS Datagram services (and Mailslot) ...... 14 6.4. NetBIOS session port...... 15 6.5. Remote Procedure Call (RPC)...... 16 6.6. Direct Host...... 17 6.7. Kerberos...... 17 6.8. LDAP ...... 21 6.9. SMTP ...... 22 6.10. Post Office Protocol (POP3) and IMAP4 ...... 23 6.11. HTTP, HTTPS ...... 24 6.12. DHCP ...... 25 6.13. Radius ...... 26 6.14. NNTP...... 27 6.15. SNTP...... 27 6.16. SNMP ...... 28 6.17. TELNET...... 28 6.18. FTP...... 29 6.19. PPTP, L2TP and IPSEC ...... 30

7. Windows 2000 Applications use of protocols...... 33 7.1. NT/Windows 2000 ...... 34 7.2. File Replication/DFS ...... 34 7.2.1 Replication notification and Schedule ...... 34 7.3. Directory replication ...... 35 7.3.1 NT Directory replication...... 35 7.3.2 Windows 2000 Directory Replication Protocols ...... 35 7.4. NetBIOS Browser Service/Network neighbourhood ...... 36 7.5. Search ...... 37 7.6. Boot process ...... 39 7.7. Logon Service ...... 41 7.7.1 Windows NT LAN Manager (NTLM) ...... 41 7.7.2 Kerberos Version 5 ...... 45 7.7.3 Distributed Password Authentication (DPA) ...... 49

FocusPM White paper by Claus Jespersen, HP Denmark Page3of3 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.7.4 Public-key-based protocols ...... 49 7.8. Add domain/leave domain...... 50 7.9. Trust Relation...... 52 7.9.1 Windows NT 4.0 Trusts...... 52 7.9.2 Windows 2000 Transitive Domain Trust ...... 53 7.10. DCOM ...... 56 7.11. Microsoft WMI ...... 56 7.12. Microsoft DMI ...... 57 7.13. (IE)...... 58 7.14. Outlook and ...... 59 7.15. DNS server...... 59 7.16. DHCP server ...... 61 7.17. WINS server...... 63 7.18. Internet Information Server ...... 64 7.18.1 IIS Administration ...... 65 7.19. Certificate Server ...... 65 7.19.1 Certificate server in NT ...... 65 7.19.2 Certificate server in Windows 2000...... 66 7.20. Index Server...... 66 7.21. News Server...... 67 7.22. Transaction Server...... 67 7.23. Telnet Server...... 67 7.24. ...... 67 7.24.1 Administration...... 69 7.24.2 Active Directory and NAT...... 70 7.25. Mail servers, Exchange and SMTP...... 70 7.25.1 Communication between POP3 clients and Exchange Server computers...... 71 7.25.2 Communication between IMAP4 clients and Exchange Server computers...... 71 7.25.3 Communication between Exchange Server computers and LDAP clients ...... 72 7.25.4 Communication between Exchange Server computers and NNTP clients...... 72 7.25.5 Communication between Exchange Client computers and Exchange Server3 computers ...... 72 7.25.6 Communication between two Exchange Server computers in the same site...... 72 7.25.7 Communication between two Exchange Server computers in different sites...... 73 7.25.8 Protocol summarize ...... 74 7.26. Routing and Remote Access Services...... 74 7.26.1 NAT Features in RRAS ...... 75 7.26.2 VPN support through NAT ...... 78 7.26.3 Administration...... 79 7.27. Microsoft Proxy Server...... 79 7.28. Microsoft NetMeeting ...... 80 7.28.1 Firewall Configuration in general in relation to NetMeeting ...... 81

FocusPM White paper by Claus Jespersen, HP Denmark Page4of4 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.28.2 Components of a Secured System ...... 82 7.28.3 NetMeeting and Firewalls, detailed information ...... 82 7.28.4 Establishing a NetMeeting Connection with a Firewall ...... 82 7.28.5 Firewall Limitations...... 83 7.28.6 Security and Policy Concerns ...... 83 7.28.7 NetMeeting and NAT...... 83 7.29. Quality Of Service (RSVP, Qos) ...... 84 7.30. Administrative tools ...... 84 7.30.1 Computer Management including , PerfMon and Regedit...... 84

8. How to handle network address translation...... 86 8.1. Microsoft/NetBIOS NAT issues...... 88 8.2. Switch-over from Basic(static) NAT to NAPT...... 89

9. Management through firewalls using VPN (PPTP, L2TP, IPSEC) ...... 89 9.1. VPN between client and server / Dial-in profile...... 90 9.2. VPN between Server and Server or between networks ...... 92

10. How to limit the use of ports through firewall ...... 99 10.1. NT 4.0 RPC configuration ...... 99 10.2. Windows 2000 RPC configuration ...... 100 10.3. Force use of TCP ...... 100 10.4. Application specifics setup ...... 100 10.5. Manually name resolution ...... 100 10.6. HTTP tunneling (port 80 tunneling)/COM Internet Services (CIS)...... 101 10.6.1 Limitations of the Tunneling TCP Protocol...... 102 10.7. SOAP Simple Object Access Protocol...... 103

11. Issues with management products when used through firewalls ...... 103 11.1. HP TopTools ...... 104 11.1.1 Communication between management GUI and management server...... 105 11.1.2 Communication between management server and management agents ...... 105 11.1.3 Communication between management agents...... 105 11.1.4 Communication between management server and other management server...... 105 11.1.5 Communication between management server and remote management database...... 106 11.1.6 Issues with NAT ...... 106 11.2. HP Network Node Manager ...... 106 11.2.1 Communication between management GUI and management server...... 106 11.2.2 Communication between management server and management agents ...... 106 11.2.3 Communication between management agents...... 107 11.2.4 Communication between management server and other management server...... 107 11.2.5 Communication between management server and remote management database...... 107 11.2.6 Issues with NAT ...... 107 11.3. HP ManageX...... 108 11.3.1 Communication between management GUI and management server...... 108

FocusPM White paper by Claus Jespersen, HP Denmark Page5of5 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

11.3.2 Communication between management server and management agents ...... 108 11.3.3 Communication between management agents...... 109 11.3.4 Communication between management server and other management server...... 109 11.3.5 Communication between management server and remote management database...... 109 11.3.6 Issues with NAT ...... 110

12. References ...... 112

FocusPM White paper by Claus Jespersen, HP Denmark Page6of6 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

1. Proprietary Notice

This white paper is publicly available and includes no confidential information. The white paper is not to be considered as an official HP white paper.

The information within this document is based on other white papers, books and technical notes as well as experiences from using the information in practice on Windows NT 4.0 and Windows 2000 (beta 3, RC1, RC2 and to some extend RC3).

Notices:

THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. USE OF THIS PUBLICATION IS AT YOUR OWN RISK AND HEWLETT PACKARD COMPANYSHALL HAVE NO LIABILITY FOR DAMAGES OF ANY KIND. WHILE REASONABLE PRECAUTIONS HAVE BEEN TAKEN IN THE PREPARATION OF THIS DOCUMENT, HEWLETT PACKARD COMPANY ASSUMES NO RESPONSIBILITY FOR ERRORS OR OMMISSIONS. THIS DOCUMENT MAY CONTAIN TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. THIS DOCUMENT MAY BE MODIFIED WITHOUT NOTICE.

THE NAMES OF PRODUCTS AND SERVICES INCLUDED HEREIN BY REFERENCE ARE TRADEMARKS OF THEIR RESPECTIVE OWNERS. THE PRODUCTS DESCRIBED IN THE PUBLICATION MAY ALSO BE PROTECTED BY ONE OR MORE US PATENTS, FOREIGN PATENTS AND/OR PENDING APPLICATIONS, COPYRIGHT AND/OR OTHER INTELLECTUAL PROPERTY RIGHTS.

The document is available from HP’s web site http://www.hp.dk/whitepapers

The white paper is a zip-file of an Adobe pdf-document. Please do not make this white paper available on any other WEB-server without explicit permission from the author. Please respect the hours put into making this white paper available and refer to the author and HP as being the source of this white paper and the information provided.

I would like to get feedback as I plan to update this document and include more information as the use of Windows 2000 evolves. Also as you will notice, quite a few NB! are included in the document where I need some input. The feedback may be given to the author: [email protected]

I would like to thank the following persons for giving me various inputs and feedback so far

- Christian Stahl, HP Invent Denmark - Markus Vilcinskas, Microsoft Redmond - Ib Thornø Christensen, CINET Denmark

Also thanks to Martin Lundsgård, Microsoft Denmark for establishing a link to Microsoft, Redmond and showing interest in the white paper.

2. Purpose

The purpose of this document is to give the reader an understanding of

• the challenges given when dealing with Windows NT 4.0 and Windows 2000 in an environment with firewalls and/or address translators. • which protocols and ports are used in Windows NT 4.0 and Windows 2000, with the focus on Windows 2000. • how various services and applications use the described protocols in various scenarios • Tips and tricks about how to manage and administer NT 4.0 and Windows 2000 computers in an environment with firewalls.

FocusPM White paper by Claus Jespersen, HP Denmark Page7of7 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

3. Target audience

The target readers of this white paper are Windows 2000 system administrators and Firewall administrators or responsible for the company's security and the Internet gateway.

Also people responsible for Network/System management are addressed. As the document is very technical, the target readers should have a thorough understanding of NT 4.0-, and TCP/IP and preferably some network/system management knowledge.

4. Things to do

The following items are on the “to do” list

• add more information about print services including use of Unix LPD. • add more information about CIFS/DFS. • add more information about dialup-services (see RRAS section). • add information about Exchange 2000 (including WebStore etc.). The exchange section focus on existing and older Exchange solutions. • add information about Windows Load Balancing Services (WLBS) • add information about Windows Clustering services (MSCS) • add information about Windows Terminal Services • add information on ICMP and where NT/Windows 2000 uses ICMP • add information about NT and Windows 2000 use of default protocol (based on TCP availability/ICMP Ping) • add information about NT and Windows 2000 IP filtering • add information on how to limit the use of source port range in NT and Windows 2000 through contacts to Microsoft. So far a specific range of source ports can’t be forced when using standard protocols in NT. • add information about Microsoft Message Queue • add information about Windows Services for Unix (NFS, NIS etc.) • add information about • add information about Microsoft Installer and Remote Installation Services • add more information about Microsoft SMS • add information about Site Server including WEB replication services • add information about Microsoft SQL-Server • add information about all OpenView Express products, including HP OmniBack II and PerfView/Measureware communication • make one table where all the protocols used by NT and Windows 2000 are shown • fill in all the NB!’s in the document • gather input from various readers and work it into a new version

5. General introduction

Many organizations are planning to introduce Windows 2000 in their companies. Most of these companies already have a lot of Windows NT 4.0 systems running and have experiences in managing them. A great deal of people have found out that it is a big challenge to manage many Windows machines in a distributed environment seen from a technically as well as from an organizationally perspective.

NT and eventually Windows 2000 is more and more frequently used as servers for Internet based applications. When Windows based Internet servers are placed in an environment that includes firewalls or address translators, the challenges gets even bigger. Some examples of applications that increasingly are being served by include

• WEB servers • Email servers • Directory Servers • Certificate servers FocusPM White paper by Claus Jespersen, HP Denmark Page8of8 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• Proxy Servers • DNS Servers • Firewalls

As applications and services get more and more distributed, the individual Windows machines need to communicate between each other. This is often no problem-, as long as a transparent IP connection exists between the machines. The problems start when internal or external firewalls or address translators, or for that matter just routers with access filters, are being deployed for security reasons.

A view of a company that is represented on a global level is shown below GlobalGlobal IntercompanyIntercompany ManagementManagement including internal firewalls/NAT’s

Internet Country Servers

Regions External eu DMZ na ap

Regional Servers

External Servers

Country Servers

Management Servers

The figure shows that the company has some regional data centers in each part of the world. NA (North America), EU (Europe) and AP (Asia Pacific). The IP backbone for the company is between these three main sites.

Apart from the regional data centers, the company is also represented in many countries around the world. There may or may not exist a firewall or address translator between the countries and the regional offices. Often a firewall is placed either because of shortage of IP-addresses or routing issues with various IP-subnets or due to security reasons. In any case the fact is that these internal firewalls and address translators exist in many companies even though many companies can see advantages in having one global transparent IP network.

The company has of course an Internet connection. Only one connection is shown in the figure, but in practice there may be many. There may be global Internet connections as well as local gateways to the Internet. Each connection will include at least one firewall and DMZ network (De-Militarized Network).

In such a setup there are two kinds of challenges in relation to use of the Windows platform:

Windows servers need to communicate across boundaries with a firewall or address translator in between. Microsoft and 3. parties management products are needed to manage the Windows environment across the firewalls. The management servers are often separate servers and need to be managed themselves.

FocusPM White paper by Claus Jespersen, HP Denmark Page9of9 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

In order to be able to design solutions that will work in this environment, you need to understand

• which protocols are used by the operating system • which protocols are used by each application • which protocols are used by built-in administrative tools • which protocols are used by other management tools • how to get the protocols work through firewalls and address translators • how to limit the use of ports through the firewall in order to increase security

This white paper focuses on Windows 2000 and protocols used by Windows 2000. Furthermore, some integration issues between Windows 2000 and Windows NT 4.0 will be addressed.

Information about how to utilize Virtual Private Networks, such as PPTP (Point to Point Tunnelling Protocol), L2TP (Layer 2 Tunnelling Protocol) and IPSEC as communication between Windows based systems is included as well. As you will see VPN can be used to increase security as well as make some communication work through a firewall where some other ports/protocols are not allowed or do not work through a given firewall.

You will get most benefit out of reading the white paper, if you have knowledge about Windows NT 4.0 and Windows 2000 architecture in general. This is especially in the networking area as this is the focus of the white paper and is rather technical in its nature.

6. Overview of common used protocols in Windows 2000

Firstly, most of the used protocols used in Windows 2000 are described shortly, secondly details about how the various services and applications use these protocols are given.

Windows 2000 is the common name for the next generation of Windows based operating systems. Windows 2000 exist in various bundles

• Windows 2000 Professional (for laptop/desktop) • Windows 2000 Server (for server) • Windows 2000 Advanced Server (including Windows Load Balancing Services) • Windows 2000 Datacenter Server • Windows 2000 AppCenter (including Com+ Loadbalancing)

The Professional version includes only the client functionality of Active Directory whereas the others also include the server functionality of Active Directory. Furthermore some of the applications such as Microsoft Clustering Services are only available in the Advanced Server Edition and upwards.

Windows 2000 builds on the protocols used in NT 4.0, with some important changes

• the use of NetBIOS protocol and NetBIOS as such is discouraged. The NetBIOS interface and protocols are still available in Windows 2000, but only for backward compatibility. • The use of WINS is discouraged (with no use of NetBIOS, the use of WINS should not be necessary. • The role of PDC and BDC as directory service has been taken over by Active Directory. • The NT authentication security mechanism (NTML) is still supported, but Windows 2000 now has use of Kerberos included in Active Directory. • Setup of trust relations is now very easy using transitive trusts through use of Kerberos. • DNS (Domain Name System) and dynamic DNS is critical to the use of Windows 2000 • Active Directory introduces use of LDAP (Lightweight Directory Access Protocol) • Microsoft Management Console (MMC) is THE preferred management GUI on Windows 2000 for Microsoft tools as well as 3. party tools. • Windows 2000 includes a telnet server known from the UNIX world. • Windows 2000 includes client and server support for VPN such as PPTP, L2TP and IPSEC. • Microsoft Windows Management Instrumentation (WMI) is included as a core part of the operating system.

FocusPM White paper by Claus Jespersen, HP Denmark Page 10 of 10 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• Microsoft Explorer 5.0 is built into the operating system and it cannot be removed easily. • Microsoft RRAS (Remote Access Services) is included in the server editions and is not a special add- on. • Microsoft Terminal Services can easily be installed and de-installed on Windows 2000 without major reinstall. On Windows NT 4.0 for example, the Terminal Services has only limited support for DCOM, which introduce a challenge to management applications based on DCOM.

6.1. NetBIOS Name Resolution (WINS)

WINS is the name server for NetBIOS names (Microsoft Windows Internet Name Service). A WINS server holds mappings between NetBIOS names and IP-addresses. Therefore WINS is only used with TCP/IP NetBIOS and NOT with NETBEUI. Normally a Windows NT 4.0 client points to one or more WINS servers. You don’t necessarily need to setup WINS servers, but in a NetBIOS environment with a mix of Windows 95/98, NT 4.0 and Windows 2000 it is difficult to live without it. WINS is Microsoft proprietary.

When a client uses WINS, it automatically register and unregister itself as NetBIOS name and IP-address in the WINS database, so WINS works as a dynamic name resolution mechanism for NetBIOS names.

In a command like net use g: \\servera\sharex on Windows 95or 98, the server must be a NetBIOS name and resolved by use of lmhosts or WINS. Lmhosts is an ASCII file that holds the same kind of mappings as the WINS server, between NetBIOS names and IP- addresses but is manually updated. You can make a central accessed version of lmhosts, so workstations access this file. In this way, you don’t need to manually update all lmhosts files on all workstations.

On Windows NT 4.0 and Windows 2000, the serverA can be substituted with “serverA.domain”, or the IP- address of the serverA. In this case, WINS will NOT be used, but rather DNS as name resolution mechanism. Actually when a name includes a dot or is longer than 15 characters, the DNS mechanism is used on NT 4.0 and Windows 2000.

Windows 2000 still has support for WINS for backward compability, even though Microsoft is going away from using it. As long as NetBIOS applications exist, the WINS server will be there. Windows 2000 use DNS as name resolution for applications. Even though some Windows 2000 applications still have a NetBIOS name along with a DNS name it is only the DNS name which is used by Windows 2000, whereas older applications and NT 4.0 may use the NetBIOS name. Windows 2000 actually has an option in network , where it is possible to disable the use of NetBIOS over TCP/IP (NBT).

Even though no WINS server is configured, WINS ports may be used in subnet broadcasts in order to try to locate NetBIOS names according to RFC 1001/1002.

The WINS communication is done by using the protocol given in the table below

Source address Source Port Destination Destination Port Description address IP address of client with WINS UDP/137 IP address of WINS UDP/137 Initiate server configured server WINS request IP address of WINS server UDP/137 IP address of WINS UDP/137 Response client IP address of client with NO UDP/137 IP Subnet UDP/137 Initiate WINS server configured broadcast address Name registration on subnet IP address of machine UDP/137 IP address of WINS UDP/137 Response answering request client IP address of WINS server with UDP/TCP/>1023* IP address of push UDP/TCP/135 Initial WINS MMC WINS GUI running or pull partner request

FocusPM White paper by Claus Jespersen, HP Denmark Page 11 of 11 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

WINS Server when configuring push/pull partner using WINS MMC manager NT may use UDP, Win2k force use of TCP IP address of push or pull UDP/TCP/135 IP address of WINS UDP/TCP/>1023* Response partner WINS Server server with MMC WINS GUI running IP address of WINS server with UDP/TCP/>1023* IP address of push UDP/TCP/>1023** Initial WINS MMC WINS GUI running or pull partner request WINS Server when configuring push/pull partner using WINS MMC manager. NT may use UDP, Win2k force use of TCP IP address of push or pull UDP/TCP/>1023** IP address of WINS UDP/TCP/>1023* Response partner WINS Server server with MMC WINS GUI running IP address of first WINS server TCP/>1024 IP address of TCP/42 WINS second WINS replication server between two WINS servers Initiate IP address of second WINS TCP/42 IP address of first TCP/>1024 WINS server WINS server replication Response

For more information about when the WINS servers are accessed and what kind of communication is being used, see under the WINS application section.

WINS client to server packets does not work through a device that does address translation, whereas WINS replication does. Actually a WINS request will work through a Firewall with NAT enabled, but often, you can’t use the IP-address as return address, unless it is an IP-address known by the client.

In general, WINS communication will NOT work well in NAT environments. The Push/Pull partner communication using DCE/RPC will NOT work through NAT.

NB! Support for normal WINS client/server communication and WINS replication using TCP port 42 (after initial setup) in NAT environments must be supported.

6.2. DNS (Domain Name System)

Windows 2000 introduces a new naming scheme, based on the Domain Name System (DNS) and the Active Directory. DNS is not something new, it also exists in NT and various other operating systems. It is “just” a fundamental change from the NetBIOS naming scheme used in the current version of Windows NT.

FocusPM White paper by Claus Jespersen, HP Denmark Page 12 of 12 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

DNS is the naming service used by the Internet and is the most widely deployed naming system in use today. The emphasis on integration with Internet technologies make DNS the obvious naming service for Windows 2000.

Windows 2000 makes use of some new DNS features known as Dynamic DNS. These features extend the DNS naming service, which normally uses statically defined information-, in order to cope with frequent naming updates. The features in Dynamic DNS permit frequent and efficient propagation of name changes throughout a distributed network.

Different communication is done to and from DNS servers

• Client DNS communication (from machines, users or applications) to one or more DNS servers • Client DNS communication to one or more DNS servers when requesting big packets or requesting a zone-transfer (for example by using “ls –d domainname” from within nslookup). • When a client or DHCP server wants to update the DNS with a DNS name for itself (A-record) • When a DHCP server wants to update the DNS server with reverse record (PTR record) • When a client or DHCP server refreshes the DDNS entry for a given machine’s A-record. • DNS server communication to other remote DNS servers when the other client is issuing recursive DNS query • DNS server communication from secondary to primary when refreshing status on UDP port 53 • DNS server communication from secondary to primary when requesting a full or incremental zone transfer. • primary to secondary when notifying secondaries of changes on UDP port 53 • If integrated into Active Directory, no primary and secondaries exist. Rather all are primary and can receive updates. In this case communication between DNS servers involve normal Active Directory replication.

This is summarized in the table below

Source address Source Port Destination address Destination Port Description IP address of DNS client UDP/>1023* IP address of DNS UDP/53 Initiate DNS server client request. This is also used for DDNS clients requests and verification. IP address of DNS server UDP/53 IP address of DNS client UDP/>1023* Response IP address of DNS client TCP/>1023* IP address of DNS TCP/53 Initiate DNS server client request involving big packets or zone transfer IP address of DNS server TCP/53 IP address of DNS client TCP/>1023* Response IP address of DNS server UDP/53 IP address of other DNS UDP/53 Initiate server recursive DNS request or notify request NB! Some new DNS servers may useahigh port >1023

FocusPM White paper by Claus Jespersen, HP Denmark Page 13 of 13 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

instead of port 53. This is an option in bind 8 “query- source” IP address of other DNS server UDP/53 IP address of DNS UDP/53 Response server IP address of secondary DNS TCP/53 IP address of primary TCP/53 Initiate zone server DNS server transfer IP address of primary DNS TCP/53 IP address of secondary TCP/53 Response server DNS server

Notice that use of DNSSEC or TSIG (DNS Secure updates) implies NO new protocols/ports other than those listed in the table above. DNSSEC and TSIG are more concerned with authenticating the DNS data as opposed to encrypting the DNS packet as such. However, using DNSSEC or TSIG makes use of NAT even more challenging than it already is. Actually, due to the fact that DNSSEC and TSIG use an encrypted signature mechanism, it will NOT work through NAT. Normally DNS can be set up to work with NAT (see below) depending on the firewall/NAT used.

6.2.1 DNS AND NAT

Network Address Translators (NATs) are often used when a network's internal IP addresses cannot be used outside the network either for privacy reasons or because they are invalid for use outside the network.

Ideally speaking, a host name uniquely identifies a host and its address is used to locate routes to the host. However, host name and address are often not distinguished and are used interchangeably by applications. Applications embed IP address instead of host name in payload. Examples would be e-mails that specify their MX server address (ex: [email protected]) instead of server name (ex: [email protected]) as sender ID; HTML files that include IP address instead of names in URLs, etc.

The use of IP address instead of host name in payload represents a problem as the packet traverses a NAT device because NATs alter network and transport headers to suit an address realm, but not payload. DNS provides Name to address mapping-, whereas, NAT performs address translation (in network and transport headers) in datagrams traversing between private and external address realms. DNS Application Level Gateway (DNS_ALG) outlined in RFC2694 helps translate Name-to-Private-Address mapping in DNS payloads into Name-to-external-address mapping and vice versa by using state information available on NAT.

A Network Address Port Translator (NAPT) performs address and Transport level port translations (i.e-, TCP, UDP ports and ICMP query IDs). DNS name mapping granularity, however, is limited to IP addresses and does not extend to transport level identifiers. As a result, the DNS_ALG processing for a NAPT configuration is simplified in that all host addresses in private network are bound to a single external address. The DNS name lookup for private hosts (from external hosts) do not mandate fresh private-external address bindings, as all private hosts are bound to a single pre-defined external address. However, reverse name lookups for the NAPT external address will not map to any of the private hosts and will simply map to the NAPT router. Suffices to say, the processing requirements for a DNS_ALG supporting NAPT configuration are a mere subset of Basic NAT.

6.3. NetBIOS Datagram services (and Mailslot)

NetBIOS datagrams are used for the following purposes in NT 4.0:

• Locating a logon server • Sending a logon request • Performing domain synchronization • Browser host name announcements • Browser workgroup/domain announcements

FocusPM White paper by Claus Jespersen, HP Denmark Page 14 of 14 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• NetBIOS Master Browser Existence and Election Packets • NET SEND /d: "Message"

The protocol used is UDP port 138 in source and destination port.

(Notice that normal use of “net send ” , where the computername is only one specific machine, uses either NBT TCP port 139 on NT 4.0 or direct host TCP port 445 in Windows 2000. It is only when messages are sent to the domain, that the UDP port 138 is used).

Also this port is used for mailslot communication. For example the HP OpenView product ManageX which focuses on NT management uses by default this mailslot port for sending messages from various ManageX agents to the ManageX server (console).

The NetBIOS datagram services does not work through a firewall that implements NAT, unless the Firewall has a proxy application for translating the datagram services IP-addresses which are included in the packets. Axent’s product Eagle Firewall includes such a proxy for NetBIOS communication.

Source address Source Port Destination address Destination Port Description IP address of client UDP/138 IP address of target, UDP/138 Initiate such as Domain Master Browser, other browser (for subnet) or Domain Controller IP address of target UDP/138 IP address of client UDP/138 Response IP address of client UDP/138 Local subnet broadcast UDP/138 Initiate address (for example x.y.z.255

The browser service is still supported by Windows 2000 even though you don’t necessary use it. The browser service in Windows 2000 only supports WINS. It can’t be used as a view of the DNS namespace !!. A Master Browser is registered in WINS and in NetBIOS cache as a type of <1b> in the 16. character position.

NB! This needs to be verified other than the tracing I have done. I need to understand when exactly the UDP port 138 is used and under which conditions. As described above, the UDP port 138 is used to locate a logon server, but this can also be done by asking the WINS server, so is port 138 used for this when using a WINS server, I guess not. Also I need to check what happens in Windows 2000 native mode. Is the browser used in native mode ? I guess NOT. How about “net send” in native mode. Is this then just done by using the Direct Host command even when using “Net send /domain: ”. Is NetBIOS automatically disabled when working in native mode, or must this be done explicitly.

Input from IB : Browser announcements is done on UDP 138. In order to find a Domain Master Browser in order to exchange Domain lists, WINS port UDP 137 is used.

6.4. NetBIOS session port

The NetBIOS session port is used for various NetBIOS related communication between a Windows client and a or between Microsoft Servers. Examples include

• net use commands (file sharing, printer assignments etc.) • net send • access to logical drives through the network • administrative applications in NT 4.0, such as Event Viewer and Perfmon

Notice that the use of net send command only uses NetBIOS session port, when a message is sent to a single machine. If the net send command is used for a specific domain, such as “net send /domain:domainx Test message” then NetBIOS datagram service is used. Also notice that NT 4.0 can’t use FQDN DNS names for

FocusPM White paper by Claus Jespersen, HP Denmark Page 15 of 15 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ computername in relation to the net send command, whereas Windows 2000 can. NT 4.0 requires a NetBIOS name that can be resolved by use of WINS or LMHOSTS.

Windows 2000 will sometimes do parallel requests to another Windows server with NetBIOS session port as well as the “Direct host” protocol described later. The first protocol that succeeds will be used.

Normally the NetBIOS session port is a pure TCP connection on port 139. You may also see RPC on top of NetBIOS session port. As the NetBIOS session port is based on NetBIOS on TCP/IP, the use of this protocol is discouraged in Windows 2000, even though it can be used, if NetBIOS is not disabled.

NetBIOS session protocol is able to work through firewalls even with NAT enabled and with a special proxy server for NetBIOS.

Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/139 Initiate workstation or server IP address of target TCP/139 IP address of client TCP>/1023* Response

NB! What are the restrictions on use of TCP 139 in Windows 2000 native mode. I guess it is not used at all, when in native mode. Or must the NetBIOS be disabled also, even in native mode ?

6.5. Remote Procedure Call (RPC)

Remote procedure call (RPC) exist in more than one variant:

• DCE/RPC. Many vendors including Microsoft and HP use this protocol as the RPC protocol in various products and operating systems. This is the only version of RPC that is used by Microsoft. The communication used in DCE/RPC is based on a port mapper running on port 135 (UDP and TCP). On this port the communication is initialized and further communication takes place on a port higher than 1023. It is recommended to force the use of TCP in DCE/RPC communication if it needs to work through a firewall. Often the use of UDP is default (in NT 4.0) and TCP will be enforced only by changing the registry entries shown later in this paper. The default use of UDP (in NT 4.0) for DCE/RPC is an advantage if you focus on performance. Windows 2000 by default use TCP for DCE/RPC, which makes it more safe and easier to work through firewalls. However no Firewall on the market supports use of DCE/RPC through a firewall with NAT enabled. Some RPC based applications may work anyway, for example those that do not hold any IP-addresses in the RPC packets. In general you should NOT expect DCE/RPC to work in NAT environments.

• SUN RPC or ONC/RPC. SUN’s version of RPC is well-known in the UNIX world. Applications like NFS (Network ) and NIS (Network Information Services) utilize SUN RPC. This version of RPC has a portmapper running on port TCP port 111, where communication is initialized. Further communication will be carried out by using dynamic allocated ports higher than 1023. Checkpoint Firewall-1 and Cisco PIX firewall have support for SUN RPC through the firewall with NAT enabled.

• NCS/RPC. This is the previous version of DCE/RPC before it became a standard. NCS/RPC was developed by HP (actually by Apollo that was taken over by HP). NCS/RPC is not used very much anymore other than in older versions of Unix. NCS/RPC also used port 135 to initiate communication and used dynamic allocated ports afterwards. NCS/RPC is not supported through firewalls with NAT.

Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP port 135 Initiate workstation or server IP address of target TCP/135 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/>1023** Initiate IP address of target TCP/>1023** IP address of client TCP/>1024* Response

FocusPM White paper by Claus Jespersen, HP Denmark Page 16 of 16 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

The table shows the port used by Windows 2000 clients and servers. (1023* and 1023** are used to specify a specific IP-address above 1023, so when a request to 1023* is initiated, the response will hold the same port number, referred to as 1023*, but in reality it is a specific port number above 1023. The same notation is used for 1023**). As described above you should expect use of UDP when NT 4.0 is either client or server in the communication shown.

DCE/RPC can for some application be used through firewalls with NAT. It depends on the application using DCE/RPC. If the application is only using DNS names, it may work. However many applications are known NOT to work through the firewall when using DCE/RPC. Therefore don’t expect it to work unless you somehow can verify that it is working.

For information about how to limit the number of ports used by DCE/RPC and how use of TCP can be forced on NT 4.0 see later sections in this white paper.

NB! When exactly is RPC working through a firewall with NAT enabled ? Meaning, which applications place IP- addresses in the RPC dataload ?

6.6. Direct Host

Direct host is new in Windows 2000- and it is the successor of NetBIOS session traffic. Direct host requires no NetBIOS at all-as it relies on DNS for name resolution. Commands like net use * \\servera.domaina.domainb\sharex /user:administrator between two Windows 2000 machines will normally use direct host protocol. - (In native mode “direct host” is always used!) This protocol is also used for various administrative purposes, like the Event Viewer and Perfmon application. The port used for direct host communication is TCP port 445. This protocol works through firewalls with NAT.

Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/445 Initiate workstation or server IP address of target TCP/445 IP address of client TCP>/1023* Response

Windows 2000 seems to use both NetBIOS session port 139 and Direct Host in parallel on Windows 2000 machines which are not running in Windows 2000 native mode. The protocol that is being answered first is used. This means that a Windows 2000 machine often will use NetBIOS session port TCP 139 instead of direct host protocol. This can be adjusted through bindings and the order of bindings in the network control panel.

NB! Is the use of TCP port 139 used at all in Windows 2000 native mode, or must it be disabled manually in the network control panel in order not to be used.

6.7. Kerberos

All distributed services in Windows 2000 use the SSPI to access the Kerberos SSP. A partial list of the ways in which the Kerberos protocol is used for authentication includes:

• Print spooler services • CIFS/SMB remote file access • LDAP queries to Active Directory • Distributed file system management and referrals • IPSec host-to-host security authority authentication • Reservation requests for network Quality of Service • Intranet authentication to Internet Information Server • Remote server or workstation management using authenticated RPC • Certificate requests to the Microsoft Certificate Server for domain users and computers FocusPM White paper by Claus Jespersen, HP Denmark Page 17 of 17 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Logon process:

• The user asks for admission to the ticket-granting service for the domain (AS Exchange between client logging on and the KDC for the user’s account domain.) • The user asks for a ticket for the computer (TGS exchange between client and the KDC for the computer’s account domain.) • The user asks for admission to local system services on the computer.

When accessing services such as a network share on a server in the domain, the process is

• The client uses its ticket-granting ticket and asks the KDC for a ticket to the service on the server • The KDC sends back the ticket encrypted with the server’s encryption key • The client connects to the server presenting the obtained key and gets verification without the server needing to communicate with the KDC.

When accessing services on a server outside the local domain, the process is

• The client uses its ticket-granting ticket and asks the KDC for a ticket to the service on the server • The KDC sends back a ticket-granting ticket for a domain controller/KDC in the other domain • The client connects to the other KDC in the other domain, presents the ticket-granting ticket and asks for a new ticket for the service on the server in this domain. • The KDC in the other domain sends back a ticket encrypted with the servers secret key • The client connects to the server presenting the obtained key and gets verification without the server needing to communicate with any of the KDC’s.

DNS Name Resolution

RFC 1510 specifies that IP transport should be used for messages between clients and the KDC. When the Kerberos SSP on a client computer wants to send an initial authentication service request, it needs to find an address for the KDC in the user's account domain. In order t do that, it needs the Domain Name System (DNS) name of a server where the KDC service is running. If the DNS name can be resolved to an IP address, that is where the Kerberos SSP sends its message. Otherwise, the Kerberos SSP generates an error indicating that it can find no such domain.

In Windows 2000 domains, the KDC service runs on every Windows 2000-based domain controller. In addition to being KDC servers, domain controllers are also Lightweight Directory Access Protocol (LDAP) servers. Both services are registered in DNS service locator records (SRV resource records). Clients can find a domain controller by querying DNS for SRV resource records with the name _ldap._tcp.dc._msdcs.DnsDomainName. The KDC service can be located by querying DNS for SRV resource records with the name _kerberos._udp.DnsDomainName. Clients who do not support the SRV record type in their DNS resolver can query for a host record (an A resource record) with the name of the domain.

Computers running Windows 2000 can participate in Kerberos realms, which are not Windows 2000 domains. In this case, the KDC will not be on a Windows 2000 domain controller, so the DNS names for KDC servers must be stored in the client computer's registry. The Kerberos SSP looks in the registry for the DNS domain name of the user's realm, and then resolves the name to an IP address by querying a DNS server.

Windows 2000 includes a tool for configuring clients to participate in Kerberos realms that are not Windows 2000 domains. Look for ksetup.exe in the Support folder of the Windows 2000 installation CD.

According to RFC 1510, when a client contacts the KDC, it should send a User Datagram Protocol (UDP) datagram to port 88 at the KDC’s IP address. The KDC should respond with a reply datagram to the sending port at the sender’s IP address.

UDP is a connectionless transport protocol, making it a logical choice where an exchange of messages must precede a connection. UDP is also well suited to applications with one message and one response, like the exchanges between clients and the KDC, as long as each message fits into a single datagram. However, UDP works best when datagrams are transmitted as single units—when each datagram fits into one frame. The capacity of a frame varies with the medium. The Maximum Transmission Unit (MTU) for an Ethernet frame is

FocusPM White paper by Claus Jespersen, HP Denmark Page 18 of 18 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

1500 octets. If the physical network is Ethernet, then Kerberos messages sent as UDP datagrams can carry up to 1500 octets of data.

Windows 2000 authorization data can easily contain more than 1500 octets. only computers with the Windows 2000 operating systems need this data, it is omitted from tickets to computers with other operating systems. As a result, those messages are well within the limits of UDP transport, and so that is how they are transmitted. Messages with tickets for computers running Windows 2000 are likely to exceed the limit, and so they are transmitted by using the Transport Control Protocol (TCP), which has much greater capacity. The use of TCP transport is consistent with recently proposed revisions

Three protocols

• authentication Service (AS) Exchange • Ticket-granting service (TGS) Exchange • Client/Server(CS) Exchange

Between a client program and the KDC, your firewall may need to allow traffic on the following ports/protocols:

Source address Source Port Destination address Destination Port Description IP address of kerberos client TCP/>1023* IP address of Windows UDP or TCP/88 Initiate (Windows 2000 client) 2000 Active Directory kerberos Server with KDC authenticati running on. NB! Needs to be verified. I think that only UDP 88 is used to ADS/KDC and TCP/88 is used between client and target Windows 2000 server. IP address of ADS server UDP or IP address of kerberos UDP or TCP Response TCP/88 client >/1023* IP address of Windows 2000 UDP or IP address of Windows UDP or TCP/464 Initiate client TCP/>1023* 2000 Active Directory change of Server with KDC password running for Windows 2000 client. NB! Needs to be verified as I don’t think Windows 2000 use this,itisjust for other Kerberos 5 clients. IP address of Windows 2000 UDP or IP address of Windows UDP or Response Active Directory Server TCP/464 2000 client TCP/>1023* Needs to be verified as I don’t think Windows 2000 use

FocusPM White paper by Claus Jespersen, HP Denmark Page 19 of 19 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

this, but just a normal Kerberos 5 client

Between an application server and the KDC, your firewall may need to allow traffic on the following ports/protocols:

Source address Source Port Destination address Destination Port Description IP address of kerberos client TCP/>1023* IP address of Windows UDP or TCP/88 Initiate (Windows 2000 application 2000 Active Directory kerberos server) Server with KDC running authenticati on. NB! Needs to be verified. I think that only UDP 88 is used to ADS/KDC and TCP/88 is used between client and target Windows 2000 server. IP address of ADS server UDP or IP address of kerberos UDP or TCP Response TCP/88 client >/1023* IP address of Windows 2000 UDP or IP address of Windows UDP or TCP/464 Initiate client TCP/>1023* 2000 Active Directory change of Server password for Windows 2000 client. NB! Needs to be verified as I don’t think Windows 2000 use this,itisjust for other Kerberos 5 clients. IP address of Windows 2000 UDP or IP address of Windows UDP or Response Active Directory Server TCP/464 2000 client TCP/>1023* Needs to be verified as I don’t think Windows 2000 use this, but just a normal Kerberos 5 client

Between a client program and an application server, your firewall may need to allow traffic on the following ports/protocols: FocusPM White paper by Claus Jespersen, HP Denmark Page 20 of 20 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Source address Source Port Destination address Destination Port Description Windows 2000 kerberos client TCP/>1023* Windows 2000 TCP/88 Kerberos program (NB! which program application Server or communicat could this be??, such as net use Workstation ion between * ??. As I understand all kerberos Windows 2000 clients will client and include the Kerberos ticket in the application given protocol and not TCP port server. NB! 88 kerberos request will be done Verify what by any Windows 2000 these applications. Perhaps 3.party programs applications will do this ??) are. Is the kerberos ticket just included in for example a direct host protocol ?

As the Kerberos protocol includes information about source IP-addresses, Kerberos is NOT supported through firewalls that implement NAT. There is a patch available for “standard Kerberos” on Unix, in order to get it to work through firewalls with NAT, but in Windows 2000, the status is, that it will not work.

Note that when a machine has a ticket for a given service, this ticket is included in the given protocol that is used to access the resource. The kerberos protocol is used to/from the KDC whereas other protocols are used between client and server to present the ticket. An example is the use of Direct Host protocol to access a Windows 2000 share. If the client already has the ticket for a service on servera, then the client can connect directly (after DNS lookup) to the server using only the Direct Host protocol (TCP 445) with the ticket included in this protocol. Likewise with other Windows 2000 protocols that support Kerberos as authentication mechanism.

Not everything in Kerberos packages is encrypted. Only the part about authentication information, such as username, password, kerberos ticket, session key etc. The encryption algorithm used for authentication is by default HMAC, whereas the encryption algorithm is RC4 and NOT DES which is often used by standard Kerberos implementations. RC4 is using 56 bit encryption in Europe and other countries with export restrictions and 128 bit encryption in US. RC4 is known to be better (more secure and reliable) and faster than DES.

6.8. LDAP

LDAP or Lightweight Directory Access Protocol is frequently used in Windows 2000 as opposed to NT 4.0 where it is not used at all unless a 3.party application,- such as Netscape Directory Server, which uses it, is installed.

It is first after the introduction of Active Directory that LDAP is utilized by Microsoft. LDAP is a native part of Windows 2000 Active Directory. LDAP is a directory protocol. LDAP clients as well as LDAP servers use the LDAP protocol. The LDAP client part can be used from any Windows 2000 client whereas the LDAP server part is NOT used in Windows 2000 unless you install and use Active Directory.

Five types of LDAP requests are used in Windows 2000

• Standard LDAP on TCP port 389 • LDAP on UDP port 389 to probe for availability of domain controllers before accessing them • Standard Encrypted LDAP on TCP 636 (LDAP over SSL or LDAPS) • Microsoft LDAP on TCP port 3268 to access the Global Catalog Servers • Microsoft Secure LDAP on port 3269 to access the Global Catalog Servers on Secure Sockets Layer

FocusPM White paper by Claus Jespersen, HP Denmark Page 21 of 21 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

One reason for Microsoft to use different ports to access the Global Directory Servers could be to distribute the load to separate processes and threads. Also it is easier to control the number of concurrent users to each of the Global Catalog and the Active directory separately.

Standard LDAP is used in the following cases

When you type locations such as ldap:///DC=hp,DC=com,OU=Users,CN=administrator in Internet Explorer. Actually Internet Explorer version 4 and 5 does not hold the LDAP client part. The LDAP request is given to the address book, which is a LDAP client in newer versions (\winnt\system32\dllcache\wab.exe) When a client logs on after the clients gets a LDAP server from the DNS server. When accessing search and choose “find people” from a computer that is NOT member of the domain tree.

Encrypted LDAP is not used by default in Windows 2000. Applications can utilize the API which support the use of LDAPS.

Microsoft LDAP is used by various tools, specially by Computer Management tools, which are described later. Microsoft has chosen to make their own LDAP requests on another port than the default port. This also applies for some Visual basic scripts. Applications that create objects may use LDAP port 3268 or 3269 for administrative purpose.

If a computer is member of the domain tree, then the “finding people” from the search tool also uses MS LDAP as opposed to standard LDAP when Active Directory is chosen as target for the search. Active Directory is not an option on computers which are not part of the domain tree. Here you have to set-up the directory server manually through the address book, as well as set-up accounts for the directory server(s) you want to search.

Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/389 Initiate workstation or server LDAP IP address of target TCP/389 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/636 Initiate workstation or server LDAPS IP address of target TCP/636 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/3268 Initiate MS workstation or server LDAP IP address of target TCP/3268 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/3269 Initiate workstation or server Secure MS LDAP IP address of target TCP/3269 IP address of client TCP>/1023* Response

Note that as part of a logon sequence, a client may query domain controllers on LDAP by using UDP port 386, as a probe function to check if LDAP is running. This is not included in the table.

LDAP is supported through Firewalls with NAT enabled.

6.9. SMTP

SMTP (Simple Mail Transport Protocol) is included in Windows 2000 Server editions, and it can be installed as an option. The SMTP server is a SMTP relay and NOT an email server as such. It does not support the creation of mailbox users as mail can only be sent or relayed. This implicitly means that there is no support for POP 3 (Post Office Protocol version 3) or for IMAP 4.

The SMTP server can be used if you need to be able to send mail from various SMTP email clients such as Internet Explorer or Netscape Communicator through a Windows 2000 server or from this server to another SMTP server in your own company or externally on the Internet. The SMTP server can be set up in such a way that it accepts mail sent to it as local mail, even though there is no post office function built into it. This way, you can actually receive SMTP email to various DNS domains and work with these mail on the local machine with

FocusPM White paper by Claus Jespersen, HP Denmark Page 22 of 22 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ the SMTP server. This is useful in case you need to send data by using SMTP to the Windows 2000 environment.

Windows 2000 Active Directory uses the built-in SMTP server between various Active Directory Servers for replication purposes if you have more than one Windows 2000 domain. and you choose SMTP as the transport mechanism for directory replication between domains.

A Windows email client such as Outlook or Outlook Express can be set up to send mail by using secure SMTP or SMTP over TLS. Also the communication between two Windows SMTP servers can be set up to be encrypted in the same way. The use of SMTP/TLS requires use of certificates (X.509 certificates). This certificate can automatically be created through the GUI, if the Certificate Server is on the same machine as the SMTP server.

Also the SMTP server can be set up to do the SMTP mail routing by using LDAP lookup’s in an LDAP server like ADS. In the directory server, an attribute for a given users mail destination needs to be configured in order to carry out this work. (NB! Check what the name of the actual attribute is and whether or not this attributes is default in the metadata for ADS!!).

Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address target TCP/25 Initiate server SMTP IP address of target TCP/25 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/25 Initiate server SMTP over TLS (SSL) IP address of target TCP/25 IP address of client TCP>/1023* Response IP address of SMTP server TCP/>1023* IP address of TCP/389 Initiate directory server such LDAP as ADS request to LDAP server IP address of directory server TCP/389 IP address of SMTP TCP/>1023* Response server

SMTP works through firewalls with and without NAT enabled if the SMTP headers does NOT hold any IP- addresses but rather FQDN DNS names. No firewall on the market with NAT enabled supports the use of IP- addresses included in the SMTP fields like To: and From: (like From:[email protected])

6.10. Post Office Protocol (POP3) and IMAP4

POP3 (Post Office Protocol 3) is the most recent version of a standard protocol for receiving e-mail. POP3 is a client/server protocol in which e-mail is received and held for you by your Internet server. Periodically, you (or your client e-mail receiver) check your mail-box on the server and download any mail. It's built into the Netscape and Microsoft Internet Explorer browsers (in IE this is actually part of the Outlook Express).

An alternative protocol is IMAP(Interactive Mail Access Protocol). With IMAP, you view your e-mail at the server as though it was on your client computer. An e-mail message deleted locally is still on the server. E-mail can be kept on and searched at the server.

POP3 can be thought of as a "store-and-forward" service. IMAP can be thought of as a remote file server.

POP and IMAP deal with the receiving of e-mail and are not to be confused with the Simple Mail Transfer Protocol (SMTP), which is a protocol for transferring e-mail across the Internet. You send e-mail with SMTP and a mail handler receives it on your recipient's behalf. Then the mail is read by using POP3 or IMAP.

The communication between POP3 and IMAP clients is shown below

Source address Source Port Destination address Destination Port Description FocusPM White paper by Claus Jespersen, HP Denmark Page 23 of 23 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

IP address of client TCP/>1023* IP address of target TCP/110 Initiate POP Server like MS POP3 Exchange or HP OpenMail IP address of target TCP/110 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/995 Initiate POP Server like MS POP3 over Exchange or HP SSL OpenMail IP address of target TCP/995 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/143 Initiate IMAP server like MS IMAP Exchange or HP OpenMail IP address of target TCP/143 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/993 Initiate IMAP server like MS IMAP4 over Exchange or HP SSL OpenMail IP address of target TCP/993 IP address of client TCP>/1023* Response

6.11. HTTP, HTTPS

The HTTP (Hyper Text Transport Protocol) is mainly used between WEB clients like Internet Explorer and WEB servers like Internet Information Server (IIS).

The HTTP protocol is more and more frequently being used as a tunnel for various other protocols, so you may also see the use of HTTP as a transport mechanism for applications such as Microsoft NetMeeting, Microsoft DCOM etc.

HTTP can be encrypted using SSL (Secure Socket Layer), also called HTTPS. The encryption can be either 40 bit or 128 bit depending on the country where it is used.

Often HTTP requests from the WEB browser goes through a WEB proxy server. In these cases the HTTP protocol is often used on another port than the default HTTP port, for example port 8088. However a Proxy Server can just as well run on TCP port 80 as any other WEB server does by default.

Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/80 Initiate WEB server like IIS HTTP IP address of target TCP/80 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/443 Initiate WEB server like IIS HTTPS, HTTP over SSL IP address of target TCP/443 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/8088 or any Initiate proxy server other chose TCP HTTP to port Proxy IP address of target TCP/8088 or IP address of client TCP>/1023* Response any other chosen TCP port

Please note that, only one example of using a proxy server is shown in the table, namely a WEB proxy server. A WEB client is also able to use a SOCKS-server, which functions as an application layer proxy. If use of a FocusPM White paper by Claus Jespersen, HP Denmark Page 24 of 24 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

SOCKS-server is specified, then (by default) TCP port 1080 is used instead of the WEB proxy port. All traffic is forwarded by using the SOCKS server port, just as for WEB proxy traffic.

HTTP and HTTPS is supported on most firewalls even with NAT. Often there is a special HTTP proxy server on the firewall. URL’s which include IP-addresses may not be supported in NAT environments depending on the setup.

6.12. DHCP

DHCP is open and standard-based, as defined by IETF Requests for Comments (RFCs) 2131 and 2132. DHCP can automatically configure a host while it is booting on a TCP/IP network, as well as change settings while the host is attached. This lets all available IP addresses be stored in a central database along with associated configuration information, such as the subnet mask, gateways, and address of DNS servers.

DHCP makes life easier for network administrators--especially on large networks. Without dynamic address assignment, clients have to be configured one by one. IP addresses must be managed to avoid duplicate use. Changes must be applied to clients by hand. Configuration information is not centralized; and it is difficult to get a view of all client configurations.

In contrast, DHCP provides benefits including the following: • DHCP is based on open IETF standards. • Dynamic assignment of IP addresses allows address reuse through leases. • Automatic pushdown of configurations to clients allows configuration changes to be applied transparently. For Windows 2000 Server, the Microsoft DHCP server has been enhanced with powerful new features, including: • Integration of DHCP with DNS. • Enhanced monitoring and statistical reporting for DHCP servers. • New vendor-specific and class ID option support. • Multicast address allocation. • Rogue DHCP server detection. • Windows Clustering for high availability (after IETF release of the server-to-server communications protocol). • Improved DHCP Manager

DHCP (Dynamic Host Control Protocol) is used in most environments especially for Windows clients. A client typically does NOT have an IP-address for the DHCP server configured. When the PC is turned on, a broadcast is sent on the local subnet and the client expects an answer from a DHCP server. The DHCP server or a DHCP relay must be on the same subnet as the client. From the DHCP server, the client gets information such as:

• IP-address • Default gateway • Subnet mask • DNS server addresses • WINS server addresses

More and more printers are also beginning to support DHCP.

Source address Source Port Destination address Destination Port Description IP address of DHCP client UDP/68 Subnet broadcast or UDP/67 Initiate DHCP server IP-address DHCP via DHCP relay/proxy agent such as Cisco IP- helper. IP address of DHCP server UDP/67 IP address of DHCP UDP/68 Response client

FocusPM White paper by Claus Jespersen, HP Denmark Page 25 of 25 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

DHCP is by default a broadcast based service. DHCP DISCOVER is sent to the local subnet on the subnets broadcast address and normally only DHCP servers which are on the local subnet will answer the request. DHCP broadcasts can be forwarded to specific DHCP server(s) through a DHCP relay agent as shown in the table above.

A Microsoft NT or Windows 2000 server and Cisco routers are examples of components where such a relay agent can be setup. In the case of Cisco, the Cisco IOS command is “ip helper”. Notice that if the ip helper is used, then it is (according to Microsoft article ÿþýüýûüÿþNOT only DHCP DISCOVER that is forwarded but also the protocols listed below:

• Time Service Port 37 • TACACS Port 49 • Domain Name Services Port 53 • Trivial File Transfer Port 69 • DHCP (BootP) Port 67 and Port 68 • NetBIOS Name Server Port 137 • NetBIOS Datagram Server Port 138

This means that a given DHCP server may receive lots of packets that are not meant for it. Not only can this influence the network performance but also the DHCP servers which may also run other important services.

DHCP is NOT supported through firewalls with NAT enabled.

Notice that new ports have been defined for DHCP in IPv6 environments. The ports given above are only for IPv4. Ipv6 can be installed on Windows platforms, however, it is still -not fully supported by Microsoft. The new ports defined for DHCP for Ipv6 are based on TCP.

Typically a DHCP server would also answer BOOTP requests. The ports used for boot are the same as for DHCP. Today most BOOTP requests come from printers and other network devices as opposed to client PC’s, that typically use DHCP.

6.13. Radius

If you have multiple VPN servers running Windows 2000, you need to configure remote access policies and logging for each VPN server. If you want to take advantage of centralized remote access policies and logging, you can configure the VPN servers as Remote Authentication Dial-In User Service (RADIUS) clients to a single computer (a RADIUS server) running Windows 2000 and the Internet Authentication Service (IAS).

You should also use an IAS server if you have VPN servers running Windows NT 4.0 with the Routing and Remote Access Service (RRAS) and you want to take advantage of Windows 2000 remote access policies. You cannot configure VPN servers running Windows NT 4.0 as RADIUS clients. You must upgrade a VPN server running Windows NT 4.0 to a VPN server running Windows NT 4.0 and RRAS.

Source address Source Port Destination address Destination Port Description IP address of Radius client (for UDP/>1023* IP address of Radius UDP/1812 or Initiate example the RRAS server) (IAS server) UDP/1645 Radius authenticati on request IP address of Radius client UDP/1812 or IP address of Radius UDP/>1023* Response UDP/1645 client IP address of Radius client (for UDP/>1023* IP address of Radius UDP/1813 or Initiate example the RRAS server) (IAS server) UDP/1646 Radius accounting request IP address of Radius client UDP/1813 or IP address of Radius UDP/>1023* Response UDP/1646 client

FocusPM White paper by Claus Jespersen, HP Denmark Page 26 of 26 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

NB!! Need to find out more about RADIUS and where exactly it is used other than in RRAS VPN setup.

6.14. NNTP

NNTP (Network News Transfer Protocol) is used between a news client and a news server. In NT 4.0 and Windows 2000, a News server is included together with Microsoft Exchange. A News client is built into Outlook Express. Internet Explorer can also be used as a News client by specifying a URL in the form news:///or snews:///

These News clients can of course be used against any News server and not only the Microsoft News server.

Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of News TCP/119 Initiate server News request IP address of News Server TCP/119 IP address of client TCP/>1023* Response IP address of client TCP/>1023* IP address of News TCP/563 Initiate server Secure News request. NNTP over SSL IP address of News Server TCP/563 IP address of client TCP/>1023* Response

News can be used through a Firewall with NAT enabled, if the name of the server and any URL’s does not hold any IP-addresses.

6.15. SNTP

NTP is the Internet Time Protocol. Many organizations synchronize their computers through use of NTP. NTP servers exist on the Internet which can be used. As many companies refuse to be dependent on sources on the Internet, they get the time through a satellite connection to an atomic watch and distribute the time internally by use of NTP. NTP exist in various versions, but uses the same port.

Microsoft Windows 2000 includes a Simple Network Time Protocol, which is basically equal to the NTP version 2 time protocol (NB! Needs to be checked). The Windows Time service functions as a time client. NT 4.0 does not include either NTP client or NTP server functionality. The time can be set through the network by use of the command “net time”.

In Windows 2000 it is even more critical that the time is correct and synchronized with other machines in the domain tree. This is because Kerberos will only authenticate, if the client asking for a service is not more than 5 minutes out of sync compared to the time of the server. The request will otherwise be rejected. Lots of other applications may also fail, if the time is out of sync as more and more applications requires the time to be set correctly in order to work reliable and in a secure manner.

In Windows 2000 the used NTP servers can be set through use of “net time /SETSNTP:.

Source address Source Port Destination address Destination Port Description IP address of client UDP/>1023* IP address of Time UDP/123 Initiate NTP Server request IP address of Time Server UDP/123 IP address of client UDP/>1023* Response

FocusPM White paper by Claus Jespersen, HP Denmark Page 27 of 27 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

NTP and SNTP work through a Firewall with NAT enabled (NB! needs to be verified). NTP servers are available on the Internet. However some companies choose to have their own internal time source or a connection through GPS (Global Position System) to a remote time source, so NTP not is being forced to go through the external firewall. Again there may be some internal firewalls or address translators.

6.16. SNMP

SNMP (Simple Network Management Protocol) is used to communicate with the NT 4 or Windows 2000 SNMP agent service – if installed. The Microsoft SNMP agent is a dynamic extensible agent which means that the SNMP/MIB (Management Information Base) is extended and shrinked as services are started and stopped. If for example the Internet Information Server (IIS) service is started, then information about the WEB server is accessible through SNMP in the MIB. As soon as the service is stopped, the data is no more accessible.

Actually Microsoft is going away from using SNMP. WBEM/WMI (Windows Management Instrumentation) is the new way of accessing such data. Actually WMI can be used to access SNMP/MIB data, but in the long run, native WMI will be used and SNMP become obsolete - at least for accessing management data.

Microsoft used to have a utility “perf2mib” on the resource kit. Using this tool, performance data could be extracted automatically into SNMP/MIB information. As also Perfmon metrics can be accessed through WMI, this is no longer delivered by Microsoft.

Source address Source Port Destination address Destination Port Description IP address of client (such as UDP/>1023* IP address of target NT UDP/161 Initiate network management tool) or Windows 2000 SNMP machine request IP address of target UDP/161 IP address of client UDP/>1023* Response

Neither NT 4.0 nor Windows 2000 has builtin support for sending SNMP Traps. In case this is needed, a 3.party utility must be used. SNMP Traps is using UDP/162.

6.17. TELNET

Telnet is well known from the Unix world where telnet is both a protocol and an application. Telnet is used for remote login to TCP/IP based machines. The telnet application is only able to execute ASCII based applications.

On NT 4.0 and Windows 2000, the telnet client application is included as telnet.exe. The telnet server part (or telnet daemon) is included in Windows 2000 and NOT in NT 4.0.

This means that when the telnet service is running on a Windows 2000 , you can login from any machine with the telnet client application and execute ASCII based applications. Actually Windows based applications can be started as well, however they are shown on the local screen connected to the machine which has the telnet service running. So if you log in to Windows 2000 through the telnet server and start notepad.exe, then notepad is launched and shown on the local monitor if it is turned on.

A Telnet client can also be used to connect to other TCP based services than a Telnet server. For example telnet servera 25 tries to make a connection to a SMTP mail server running on servera on port 25. In this way, telnet can also be used to verify wether other TCP based services are running.

Note that the telnet application does not encrypt usernames and passwords in the default configuration. If encryption is a requirement for remote login, then kerberos based versions of telnet or IPSEC or the well known SSH (Secure Shell) application can be used.

FocusPM White paper by Claus Jespersen, HP Denmark Page 28 of 28 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Source address Source Port Destination address Destination Port Description IP address of telnet client TCP/>1023* IP address of telnet TCP/23 Initiate server on Unix or telnet Windows 2000 request IP address of target TCP/23 IP address of client TCP/>1023* Response

The telnet application works through firewalls with and without NAT enabled.

6.18. FTP

FTP (File Transfer Protocol), a standard protocol, is the simplest way to exchange files between computers on the Internet. Like the Hypertext Transfer Protocol (HTTP), which transfers displayable Web pages and related files, and the Simple Mail Transfer Protocol (SMTP), which transfers e-mail, FTP is an application protocol that uses the Internet's TCP/IP protocols. FTP is commonly used for transferring Web page files from their creator to the computer that acts as their server for everyone on the Internet. It's also commonly used for downloading programs and other files to your computer from other servers.

As a user, you can use FTP with a simple command line interface (for example, from the Windows MS-DOS Prompt window) or with a commercial program that offers a graphical user interface. Your Web browser can also make FTP requests to download programs you select from a Web page. Using FTP, you can also update (delete, rename, move, and copy) files at a server. You need to log on to an FTP server. However, publicly available files are easily accessed by using anonymous FTP.

FTP is usually provided as part of a suite of programs that come with TCP/IP.

Source address Source Port Destination address Destination Port Description IP address of ftp client TCP/>1023* IP address of ftp server TCP/21 Initiate ftp on Unix or Windows request in 2000 etc. normal (port based) ftp mode IP address of target TCP/21 IP address of client TCP/>1023* Response IP address of ftp server TCP/>1023* IP address of ftp client TCP/20 Initiate FTP data channel request IP address of client TCP/20 IP address of ftp server TCP/>1023* Response IP address of client TCP/>1023** IP address of ftp server TCP/>1023* Client passive data channel request used if client initiates passive ftp as opposed to normal (port based) ftp IP address of ftp server TCP/>1023* IP address of client TCP/>1023** Response

Note that a normal FTP client typically uses “normal” FTP using port 21 and 20, whereas WEB-browsers uses passive FTP by default.

FocusPM White paper by Claus Jespersen, HP Denmark Page 29 of 29 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

FTP does not by default work through NAT’s. However most firewalls and NAT’s have built-in support for FTP proxies even with NAT enabled.

6.19. PPTP, L2TP and IPSEC

Microsoft has developed PPTP (Point to Point Tunnelling Protocol) together with 3COM. PPTP implements a secure (40 bit encryption) channel from PPTP client to PPTP server. NT 4.0 workstation and server has native client support for PPTP, whereas NT 4.0 (server) only has the PPTP server part if RRAS is installed.

PPTP continues to be supported in Windows 2000, almost the same way, as in NT 4.0. Only Windows 2000 server editions have support for PPTP server part. It is not a part of Windows 2000 professional.

The PPTP protocol does have some limitations even though it is able to transfer not only IP-packets but also IPX and NetBUIE packets.

Some other vendors have implemented support for PPTP. For example some ISP’s (Internet Service Providers) have chosen to support use of PPTP, so that remote clients don’t need to have PPTP client interface themselves, but rather connect to the ISP server which initiates the PPTP request to the destination PPTP server. PPTP can be used with or without encryption. If encryption is enabled, the username is used in order to generate encryption session keys to do the 40-bit encryption (or 128-bit encryption in some countries).

Cisco had a solution of their own, called L2F (Layer 2 Forwarding) and now Cisco and Microsoft together made the L2TP (Layer 2 Tunnel Protocol) which now is an Internet standard (RFC 2661). L2TP takes the best of PPTP and L2F and combines this with the new standard. As the name indicates, it works on layer 2 and is able to forward not only IP but also other protocols. L2TP is not included on NT 4.0, but only in Windows 2000. The server part of L2TP is within the Router Remote Access Service (RRAS) which is a part of the Windows 2000 server editions, that can be installed as an option.

L2TP can also be used with or without encryption. In case encryption is used, it is enforced by using IPSEC.

L2TP tunnel is created by encapsulating an L2TP frame inside a UDP packet, which in turn is encapsulated inside an IP packet whose source and destination addresses define the tunnel's endpoints. Since the outer encapsulating protocol is IP, clearly IPSEC protocols can be applied to this composite IP packet, thus protecting the data that flows within the L2TP tunnel. AH, ESP, and ISAKMP/Oakley protocols can all be applied in a straightforward way.

Whereas PPTP and L2TP are VPN solutions between client and servers, or between servers through the Internet etc., IPSEC is more positioned to make secure IP communication in a standard way between hosts. IPSEC is an Internet standard that only Windows 2000 supports (as opposed to NT and Windows 95/98).

IPSEC can use various mechanisms for authentication, key distribution and encryption. The encryption algorithms include

• use of kerberos • use of shared key • use of X.509 Certificates

Use of Kerberos is only an option if both (or all) machines are part of a Windows 2000 domain tree or forest.

Actually IPSEC itself can be used as a VPN like solution when working in tunnel mode. More on this later in this white paper.

Below is shown, which ports are used by the three different technologies

PPTP with and without encryption

Source address Source Port Destination address Destination Port Description

FocusPM White paper by Claus Jespersen, HP Denmark Page 30 of 30 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

IP address of PPTP client TCP/>1023* IP address of target NT TCP/1723 Initiate or Windows 2000 PPTP machine request IP address of target TCP/1723 IP address of client TCP/>1023* Response IP address of VPN client IP protocol IP address of target NT IP protocol 47 Initiate GRE 47 (GRE)/NA or Windows 2000 (GRE)/NA request machine IP address of target IP protocol IP address of client IP Protocol 47 Response 47 (GRE)/NA (GRE)/NA

PPTP does NOT work through firewalls with NAT enabled except if the new PPTP proxy is used-. That is part of the Windows 2000 NAT functionality built into the RRAS module.

NB! This needs to be checked. Also my guess is that PPTP proxy only works when the proxy and the clients are in the same domain tree, else how should it know the session keys without knowing the users hashed password ?

L2TP without encryption

Source address Source Port Destination address Destination Port Description IP address of L2TP client UDP/>1023* IP address of target NT UDP/1701 Initiate or Windows 2000 L2TP machine request IP address of target UDP/1701 IP address of client UDP/>1023* Response

L2TP with (IPSEC) encryption

Source address Source Port Destination address Destination Port Description IP address of L2TP client UDP/>1023* IP address of target NT UDP/1701 Initiate or Windows 2000 L2TP machine request IP address of target UDP/1701 IP address of client UDP/>1023* Response IP address of L2TP client UDP/>1023* IP address of target NT UDP/500 Initiate or Windows 2000 IPSEC machine request IP address of target UDP/500 IP address of client UDP/>1023* Response IP address of L2TP client IP protocol IP address of target NT IP protocol 50 Initiate 50/NA or Windows 2000 /NA IPSEC ESP machine request IP address of target IP protocol IP address of client IP protocol Response 50/NA 50/NA IP address of L2TP client IP protocol IP address of target NT IP protocol 51 Initiate 51/NA or Windows 2000 /NA IPSEC AH machine request IP address of target IP protocol IP address of client IP protocol 51 Response 51/NA /NA

L2TP does work through firewalls with NAT enabled if security (through use of IPSEC) NOT is used. If L2TP is used together with IPSEC as encryption mechanism, it does NOT work through NAT’s.

The weakness of NAT in context to VPNs such as L2TP using IPSEC is that by definition the NAT-enabled machine will change some or all of the address information in an IP packet. When end-to-end IPSEC authentication is used, a packet whose address has been changed will always fail its integrity check under the AH protocol, since any change to any bit in the datagram will invalidate the integrity check value that was generated by the source.

NB! Therefore it needs to be verified if L2TP with IPSEC always uses AH or just ESP.

FocusPM White paper by Claus Jespersen, HP Denmark Page 31 of 31 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

IPSEC

Source address Source Port Destination address Destination Port Description IP address of IPSEC client UDP/>1023* IP address of target NT UDP/500 Initiate or Windows 2000 IPSEC machine request IP address of target UDP/500 IP address of client UDP/>1023* Response IP address of IPSEC client IP protocol IP address of target NT IP protocol 50 Initiate 50/NA or Windows 2000 /NA IPSEC ESP machine request IP address of target IP protocol IP address of client IP protocol 50 Response 50/NA /NA IP address of IPSEC client IP protocol IP address of target NT IP protocol 51 Initiate 51/NA or Windows 2000 /NA IPSEC AH machine request IP address of target IP protocol IP address of client IP protocol 51 Response 51/NA /NA

L2TP comparison to IPSEC

• L2TP is protocol independent. It supports multi protocols, e.g., IP, IPX, and NetBEUI while IPSEC is IP dependent and Link independent. • L2TP is mainly used for remote access via PPP dial-up while IPSEC is applicable for various topologies, e.g., remote access, end-to-end, and gateway-to-gateway. • L2TP only supports authentication (CHAP). It does not support encryption by itself, - it needs to be combined with IPSEC.

Recommendation: IPSEC is complementary to L2TP. Use IPSEC and L2TP to provide a low-cost and secure remote access service over the Internet.

"For L2TP tunnels over IP, IP-level packet security provides very strong protection of the tunnel. This requires no modification to the L2TP protocol, and leverages extensive IETF work in this area." - quoted from L2TP specification.

NB! I need to check if the ports used for IPSEC in tunnel mode is different than using IPSEC in transport mode. I don’t think there is any difference.

IPSEC & NAT

Many people want to use IPSEC as an end-to-end encryption algorithm. However this is NOT possible, if a NAT is in place between the IPSEC partners, and this is a substantial problem. Therefore work is being done to find a solution to this. The answer right now seems to be RSIP, which would give IPSEC end—to-end encryption and security even with NAT involved. It would mean that the client requesting IPSEC would need to support RSIP client specifications and the NAT would need to support RSIP server specifications, whereas the destination IPSEC partner would not necessarily have to support any of those, unless it also needs to initiate IPSEC communication to other or the same client, which actually often would be the case.

The protocol UDP/500 which is used by IPSEC is actually the exchange of keys, IKE (Internet Key Exchange). In draft-ietf-nat-rsip-ipsec-01.txt, you can find more information on this subject. Below some information from this draft RFC.

“IKE packets are carried on UDP port 500 for both source and destination [ISAKMP]. Usually, UDP traffic is handled appropriately by NAPT [NAPT], and does not require RSIP. However, IKE uses a fixed source port of 500 which precludes that field being used for demultiplexing. Instead, the "Initiator Cookie" field in the IKE header field must be used for this purpose. This field is appropriate as it is guaranteed to be present in every IKE exchange (Phase 1 and Phase 2), and is guaranteed to be in the clear (even if subsequent IKE payloads FocusPM White paper by Claus Jespersen, HP Denmark Page 32 of 32 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ are encrypted). However, it is protected by the Hash payload in IKE [IKE], so simply extending NAPT does not work. Because of this, RSIP must be used to agree upon a valid value for the Initiator Cookie.

Once X and N arrive at a mutually agreeable value for the Initiator Cookie, X uses it to create an IKE packet and tunnels it to the RSIP server N. N decapsulates the IKE packet and sends it on address space B. The complete tuple negotiated via RSIP, and used for demultiplexing incoming IKE responses from Y at the RSIP server N is:

o IKE destination port Number (usually 500) o Initiator Cookie o destination IP address

Notice that RSIP does support alternate UDP ports (other than 500) for IKE, as this may be useful in certain situations.”

IPSEC is NOT supported through NAT. This means that it is very difficult to do end-to-end encryption by using this standard encryption algorithm.

In the RFC draft-ietf-nat-rsip-ipsec-01.txt, the RSIP is briefly discusses as shown below…

“For clarity, the discussion below assumes this model:

RSIP client RSIP server Host

Xa Na Nb Yb +------+ Nb1 +------+ [X]------| Addr space |----[N]-----| Addr space |------[Y] |A | Nb2|B | +------+ ... +------+

Hosts X and Y belong to different address spaces A and B, respectively, and N is an RSIP server. N has two addresses: Na on address space A, and Nb on address space B. For example, A could be a private address space, and B the public address space of the general Internet. Additionally, N may have a pool of addresses in address space B which it can assign to or lend to X. The RSIP server N is not required to have more than one address on address space B. RSIP allows X (and any other hosts on address space A) to reuse Nb. Because of this, Y's SPD SHOULD be configured to support session-oriented keying [Kent98c]. Not doing so implies that only one peer may, at any given point in time, use address Nb when exchanging IPSEC packets with Y. Additionally, Y's SPD MAY be configured to support user-oriented keying, although other types of identifications within the IKE Identification Payload are equally effective at disambiguating who is the real client behind the single address Nb [Piper98]. “

The RFC document “draft-ietf-nat-rsip-ipsec-01.txt “proposes RSIP extensions and mechanisms to enable an RSIP client X to initiate IKE and IPSEC sessions to a legacy IKE and IPSEC node Y. In order to do so, X exchanges RSIP protocol messages with the RSIP server N. This document currently does not address IKE/IPSEC session initiation from Y to an RSIP client X.”

There are a variety of NAT flavours, as described later in this document. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPSEC secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPSEC security to private domain hosts peering with nodes in external realm. The RFC RFC2709 describes a security model by which tunnel-mode IPSEC security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described. For more information on this, see ftp://ftp.isi.edu/in- notes/rfc2709.txt .

Also see the section about address translation later in this document for further information.

7. Windows 2000 Applications use of protocols

FocusPM White paper by Claus Jespersen, HP Denmark Page 33 of 33 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.1. NT/Windows 2000 Server

A Microsoft Server is typically used as

• File Server • Print Server • Web Server • Database Server • Other client/server or Internet/Intranet Application Server

The Server service itself normally only provide the File and Print Service for file and printer sharing. The protocol used to access the server is therefore given by the use of

• Direct Host • DNS • Kerberos • Logon Service

Server to Server traffic is traffic generated between server computers carrying out network maintenance tasks, such as

• Account synchronization • Trust relationships • Server browser traffic • WINS replication • Directory replication

For further details, see the related sections.

7.2. File Replication/DFS

The File Replication Service (FRS) in Windows 2000 is a multi-threaded, multi-master replication engine that replaces the LMREPL (LAN Manager Replication) service in previous versions of Microsoft Windows NT. LMREPL uses broadcast UDP port 138 to announce changes and RPC and SMB on TCP port 139 to transfer the changes using the REPL$ share.

Windows 2000 domain controllers and servers use FRS to replicate system policies and login scripts for Windows 2000 and down-level clients. Optionally, FRS can replicate content between Windows 2000 servers hosting the same fault-tolerant Distributed File System (DFS) roots or child-node replicas.

FRS uses Remote Procedure Call (RPC) over Transmission Control Protocol (TCP) for inter-site and intra-site replication for DFS content. While well suited to moving files, Simple Mail Transfer Protocol (SMTP) or mail- based replication (MBR) is limited to replication of the schema, configuration, and global catalogue naming contexts in the first release of Windows 2000.

Unlike Active Directory replication, FRS-replicated content between sites is not compressed.

DFS replication is not enabled by default. Enabling or disabling replication creates corresponding connection objects in the Active Directory to facilitate the replication of DFS content between partners. The topology for DFS replication is determined by the Distributed File System Manager and its own topology, schedule, and connection objects are separate and apart from the Active Directory.

7.2.1 Replication notification and Schedule þ The FRS service begins the replication process when the NTFS file system change log detects that a file in a DFS-held tree is closed. Changes are held in a 3-second aging cache so that only the last iteration of a file undergoing rapid updates is replicated. This replication latency is analogous to the "Replicator notify pause

FocusPM White paper by Claus Jespersen, HP Denmark Page 34 of 34 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ after modify" registry entry for Active Directory replication. File and folder filters are applied to prevent replication of unwanted files. Replication of small files between servers with low CPU and disk utilization occurs within seconds.

Similar to the Windows 2000 Active Directory service, replication in the same site occurs when upstream partners notify downstream partners of pending changes. Downstream partners pull files and folders that have changed since replication last took place, sending acknowledgement to the upstream partner with the receipt of each change.

Replication of DFS content between sites is scheduled by using the "Active Directory Users and Computers" (DSA.MSC) snap-in. Downstream partners pull changes according to the replication frequency and the hours replication is enabled. To view DFS connection objects, follow these steps:

The summary of ports used for file replication for Windows 2000 is shown below

Source address Source Port Destination address Destination Port Description IP address of client (file TCP/>1023* IP address of the other TCP/135 Initiate replication client) replication partner request IP address of target TCP/135 IP address of client TCP/>1023* Response IP address of client (file TCP/>1023* IP address of the other TCP/>1023** Initiate replication client) replication partner request on chosen port IP address of target TCP/1023** IP address of client TCP/>1023* Response

7.3. Directory replication

7.3.1 NT Directory replication In NT, user logon validation requests are processed either by the primary domain controller or by a backup domain controller (PDC or BDC). Changes to the user accounts are only made to the PDC. To ensure that each backup domain controller properly validates each user logon request, it is important that each backup domain controller has an exact copy of the user accounts databases maintained on the primary domain controller.

The communication between servers used for replicating the directory (SAM database) is given by

• The PDC announces a change to the SAM by use of NetLogon (unicast UDP port 138 to all BDC’s) • The BDC connects to IPC$ of the PDC by using TCP port 139 • The BDC establishes a secure channel to the PDC by using RPC over TCP port 139 • The BDC requests synchronization of the account database by using client RPC calls over TCP port 139. For each call a RPC Server response is sent. • The BDC uses SMN or RPC calls over TCP port 139 to transfer the updated data.

7.3.2 Windows 2000 Directory Replication Protocols

Directory information can be exchanged by using the following network protocols: • IP replication. IP replication uses remote procedure calls (DCE/RPC with dynamic port allocation) for replication within a site (intra-site) and over site links (inter-site). By default, inter-site IP replication adheres to replication schedules. IP replication does not require a certification authority (CA). • SMTP replication. If you have a site that has no physical connection to the rest of you network but that can be reached via Simple Mail Transfer protocol (SMTP), that site has mail-based connectivity only. SMTP replication is only used for replication between sites. You cannot use SMTP replication to replicate between domain controllers in the same domain—only inter-domain replication is supported over SMTP FocusPM White paper by Claus Jespersen, HP Denmark Page 35 of 35 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

(that is, SMTP can be used only for inter-site, inter-domain replication). SMTP replication can be used only for schema, configuration, and global catalog partial replica replication. SMTP replication observes the automatically generated replication schedule. If you choose to use SMTP over site links, you must install and configure an enterprise certification authority (CA). The domain controllers obtain certificates from the CA, which the domain controllers then use to sign and encrypt the mail messages that contain directory replication information, ensuring the authenticity of directory updates. SMTP replication uses 56-bit encryption.þ

7.4. NetBIOS Browser Service/Network neighbourhood

The NetBIOS browser service is constantly updating information about computers on the network. The browser services built a list of accessible computers with known NetBIOS names on the network either through use of WINS or through use of NetBIOS datagram broadcasts on the local subnet.

The browser lists are maintained by local master browsers and domain master browsers. The PDC in each domain is normally (if available) the domain master browser. BDC’s are backup browsers. Local master browsers are dynamically assigned depending on the environment and setup.

Local master browsers announce their domains to each other and update domain master browser. Furthermore, they update backup browsers with data from domain master browser. Domain master browsers query WINS servers for domain names and communicate new names to local master browsers.

Master browsers announce themselves each 15th minute by using UDP 138. Each 12th minute, each domain master browser contacts its WINS servers and queries for all registered domain names. The list is retrieved from WINS servers by using RPC over TCP port 139.

All master browsers for a single domain retrieve a browse list from the domain’s domain master browser every 12th minutes. Domain master browsers and backup master browsers initiate the communication to get the list from domain master browsers and to update the domain master browser with local domain list. The protocol used for this is TCP port 139 (SMB and TCP session to the IPC$ share is used)

To summarize:

The basics of server browsing processes are

• PDC becomes domain master browser when starting up • each BDC of the domain becomes either backup browser or local master browser (if thre is no local master browser in advance) • every 15 minutes, each master browser announces itself to the master browsers of other domains on the local subnet. • every 12 minutes, each domain master browser contacts WINS for a listing of all domains <1B> names • every 12 minutes, each master browser contacts the domain master browser to update the browse lists.

Note that the browser services and the protocols used to get the browser list depends on which model is used. NetBIOS works with different models, such as:

• B-node • P-node • M-node • H-node

The chosen model determines which methods NetBT will use to register and resolve names. A B-node system uses broadcasts. A P-node system uses only point- to-point name queries to a name server (WINS). An M- node system broadcasts first, then queries the name server. An H-node system queries the name server first, then broadcasts. Resolution via LMHOSTS and/or DNS, if enabled, will follow these methods. If this key is

FocusPM White paper by Claus Jespersen, HP Denmark Page 36 of 36 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ present it will override the DhcpNodeType key. If neither key is present, the system defaults to Bnode if there are no WINS servers configured for the network. The system defaults to Hnode if there is at least one WINS server configured, or if set manually through changes in the registry or automatically by DHCP options in case DHCP is used at all.

The browser service is a view of the NetBIOS namespace, and therefore it will mainly be used in NT 4.0 environments. If everything is converted to native Windows 2000, the browser service is obsolete and the search tools and Active Directory together with the DNS service has taken over this functionality. (See next section for protocols used for search).

The browser can actually also be used to find information in the Active Directory. Browsing will allow the user to see all computer Objects in the Forest and the Attributes associated with each of them. As has always been the case, the browse function depends on the presence of a NetBIOS transport

NB! Is the browser service used in native mode ? Is browser service used, if the use of NetBIOS is disabled ?

7.5. Search

The search tool can be accessed from properties on “My computer” or directly from the start program menu. The search tool offers an interface to find

• File or folders • People from active directory or 3. Party directory services • Computers • Internet

The interface shown, when looking for file and folders is shown below

Documents and folders can be searched locally on a remote share or from the Active Directory. The option with Directory is only shown, if the computer is member of the domain tree. When searching remote shares, the same protocols are used as when browsing the network, whereas the protocol used for searching the Active Directory is MS LDAP after a DNS lookup on the specific directory server. The DNS server is used to ask which machine is the default-first-site for LDAP requests. The request from the search is ntds://.

When finding people, and the search is run from a computer that is member of the domain tree, the interface shown in the figure below , is used.

FocusPM White paper by Claus Jespersen, HP Denmark Page 37 of 37 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

As previously explained, the protocol used is MS LDAP when the computer is member of the domain tree.

If the finding is carried out by selecting “find” from within the Active Directory MMC Snap-in, then it looks like the following:

MMC searches do not require read and write access to an Active Directory domain. The MMC find command can be used to search a domain controller over LDAP port 389 by selecting a specific domain or OU with a domain. It can also be used for searching the Global Catalog Server over LDAP port 3268 by selecting Entire Directory. FocusPM White paper by Claus Jespersen, HP Denmark Page 38 of 38 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Using MMC to search for printers also use LDAP port 386 if the search is specific to a domain or OU in a Domain and port 3268 if it is in the entire directory.

If the computer is a standalone Windows 2000 machine, not part of the domain tree, the interface below is used to search any LDAP compliant directory server

This interface is equal to the interface shown when the Microsoft Address Book (WAB) is started and it uses LDAP standard TCP port 389 by default, but this can be adjusted -when setting up the account in the address book.

This behaviour to run against a domain controller on LDAP port 389 can’t be changed in relation to the address book. So if WAB is to be used to search the global catalog server, the port on which the global catalog server runs must be changed by changing the registry setting

HKEY_CURRENT_USERS\Software\Microsoft\Internet Account Manager\Accounts\Active Directory GC “LDAP Port” changes it to use Port 389.

You would also need to customize the registry value for LDAP search base to reflect proper active directory domain component to query. This could be dc=cj,dc=hp,dc=hp for cj.hp.com.

Searching the Active Directory depends on both the LDAP standards and SRV records in the DNS zone files in order to locate a particular service on any particular server object. If, for whatever reason, access to DNS SRV records is lost or disrupted, users, administrators, and applications will be unable to locate resources in the Active Directory.

Windows 2000 clients and a Windows 9.x client add-on pack are the only ones that provide support for Dynamic DNS and use SRV records to locate both services and servers. As a result, they are the only clients that can currently exploit the full power of the Active Directory and Dynamic DNS.

Browsing (as opposed to searching) the directory from also uses LDAP port 389 to get information about available objects from a domain controller, if a specific domain is selected.

7.6. Boot process

When a Microsoft workstation boots, it goes through

TCP/IP initialisation (including DHCP) Domain logon

The DHCP part of the TCP/IP initialisation consists of four network frames:

• DHCPDiscover

FocusPM White paper by Claus Jespersen, HP Denmark Page 39 of 39 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• DHCPOffer • DHCPRequest • DHCPAck

A workstation sends a DHCPDiscover frame if it has no knowledge of a DHCP server or if it could not extend a previous configuration after 87.5 % of the lease duration has expired. Any server can make a DHCPOffer.

The Client selects the first arriving offer and tries to request it with DHCPRequest. The server has to confirm the lease with a DHCPAck frame. The workstation then sends some ICMP echo requests (pings) to avoid address conflicts with other clients. If there is no answer, the workstation continues initialising.

A workstation with a valid TCP/IP configuration tries to register its workstation and domain (or workgroup) name with a WINS server or by using a broadcast message, depending on the configuration. Using WINS doesn’t reduce the number frames sent by a client, but it does reduce the number of broadcasts messages.

The registration of names is done by using WINS with unicasts on PORT 137 or UDP port 138 broadcasts if no WINS is available.

The boot process continues and includes the following sequences for a NT client

NetLogon request to “nearest” domain controller using unicast UDP port 138 (local subnet broadcast may be sent, if no domain controller is known) with response from the domain controller on the same port Name resolution for domain controller that is using WINS port 137 or UDP 138 broadcasts if WINS is not available.

NBT sessions on TCP port 139 to domain controller with responses (on IPC$ share) Schannel requests and domain lists using TCP port 139 and RPC on TCP port 139. Registration request to WINS server that are using WINS UDP 137 or using UDP 138 if WINS not is used. Login and get policies for machine also using NBT session port TCP 139

When talking about Windows 2000 boot, the DNS server is contacted and the DNS zone is automatically updated with the name of the client or server in the given DNS zone. By default a Windows 2000 client will do the forward registration directly to the DNS server, whereas the DHCP server will do the reverse name registration.

The boot process for a Windows 2000 client to a Windows 2000 server looks like

• DHCP request • Update DDNS server with workstation name • DHCP server updates DDNS server with reverse record • DNS request to a given DNS server in order to find the nearest domain controller for the domain the PC is a member of. • Connect to the domain controller using Kerberos (UDP port 88) • Connect by using directhost (TCP port 445) (or by using NBT (TCP port 139) for NT clients trying to connect to Windows 2000 servers in PDC emulation mode). • Get domain policies for machine

NB! This sequence needs to be verified. I haven’t worked enough on it, and I am not 100% sure about this at this point.

If the client is a NT workstation using a DHCP-server that supports dynamic DNS, the DHCP server will typically update the DNS server on behalf on the client. This includes both forward and reverse name registration.

NB! The boot process is NOT supported through NAT for neither NT nor for Windows 2000 clients. This needs to be verified

FocusPM White paper by Claus Jespersen, HP Denmark Page 40 of 40 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.7. Logon Service

When a user logs on to the Domain, a series of events occur to validate the user and determine the appropriate level of access to network resources for that user. For example the major events in Windows 2000 environments when logging in are:

• The Network Starts including initialisation of the RPC interface. • Computer policies are applied (by default) in the following order: NT4, Local, Site, Domain, OU, child OU, etc. There is no user interface displayed while computer policies are being processed. • Each startup script runs and must complete its operation successfully or timeout before the next script will start. • The user presses CTL-ALT- DEL to logon. • After the user is validated, the profile is loaded. • User Policies are applied in the following order: NT4, Local, Site, Domain, OU, child OU, etc. • -based logon scripts are run (in hidden mode) and asynchronously by default. The User Object script (which is run in a normal window) is run last. • The shell starts and the Operating System user interface prescribed by Group Policy appears.

Below the logon process is explained in more details for NT and for Windows 2000.

7.7.1 Windows NT LAN Manager (NTLM)

NTLM is used by Windows NT 4.0 and previous versions of Windows NT. NTLM will continue to be supported and used for pass-through network authentication, remote file access, and authenticated RPC connections to earlier versions of Windows NT.

A workstation in a domain must establish a session with a domain controller of its domain. The logon process starts by locating one of these. The workstation can either query the WINS server for all <1C> entries or it can send this frame as a local subnet broadcast on UDP port 138. The reply may include the IP-addresses of many domain controllers. If the WINS server is used, the first returned IP-addresses are those owned by the WINS server, sorted by registration date and time.

If the query was successful, the workstation selects the first controller from the list and sends a SAM LOGON request in form of a local subnet broadcast on UDP port 138 and then as frames directed to the list of controllers, which the workstation retrieved from the previously query. The name of the IP-address of the first domain controller is resolved either by WINS or by local broadcast on UDP port 138.

The workstation uses a three-way TCP handshake via TCP port 139 to establish a NetBIOS session with the controller. The client then tries to establish a tree connection with the server’s IPC$ share (includes a SMB protocol negotiation).

After a successful logon, a client initiates an RPC request for a list of trusted domains. In this case the RPC is done over TCP port 139 session port and NOT over dynamic DCE/RPC.

The workstation then establishes a secure channel with the controller. This channel will be used every time a client needs to have its user account validated or to retrieve user information from the controller. The secure channel is using TCP port 139.

Now the workstation will register its name for additional services such as the messenger service and browser service.

A user logon does more than validating the user’s credentials: a controller also has to give user-specific information, such as group membership, back to the client if the user was validated. Each user is validated twice. The operating system first passes the users’ credentials over the secure channel to the controller to validate the user and to retrieve all information needed in order to create the users’ (a RPC call is used for this).

FocusPM White paper by Claus Jespersen, HP Denmark Page 41 of 41 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

A user session is set up with the controller in order to retrieve the contents of a policy file and a logon script (if any is available). The protocol used for this is TCP port 139. After this rather long sequence, the workstation is authenticated and ready to serve any further user or application requests.

Windows 2000 logon from NT 4.0 computer in in Windows Windows 2000 2000 domain domain

ÿýöö ÿýöö

ô÷ö ÷öôöö ô÷ö ööý÷ôýù ÷öôöö ýöø ô÷õ ööý÷ôýù ýöø ô÷õ ÿþýüûúýùø÷öõô Firewall õ with NAT ÿþýüûúýùø÷öõô õ

The logon process as described above is

Locating Controllers (WINS port 137 or UDP port 138) SAM Logon request (UDP port 138) 1) Logon to a controller a) Name resolution of domain controller (WINS port 137 or local broadcast on UDP port 138) b) Session Request (TCP port 139) c) Protocol Negotiation (SMB TCP port 139) d) Retrieving Trusted Domains (RPC over TCP port 139 e) Secure Channel Set-up (TCP port 139) f) Registering Names (WINS port 137 or local broadcast on UDP port 138) 2) User Logon a) Client validation (TCP port 139) b) Get logon scripts and policies (TCP port 139)

To access a resource located on a member server that is a member of the client’s domain, the user must establish a user session on that computer. The process includes the same steps as used for a user’s local domain logon explained above.

The logon process in this set-up does NOT work through a firewall with NAT enabled. Therefore the internal client can’t connect to the external PDC and the external client can’t connect to the internal PDC. Only if NAT is NOT used, this can be setup to work through the firewall, but you would then need to open the described protocol/ports.

FocusPM White paper by Claus Jespersen, HP Denmark Page 42 of 42 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Windows 2000 logon from NT 4.0 computer in NT 4.0 resource domain

ô÷ö ô÷ö ÿýöö ÷öôöö ÿýöö ÷öôöö ööý÷ôýù ööý÷ôýù ýöøô÷õ ýöøô÷õ

öõ öõ ÷ü ÷ü ùø ùø ûú ûú ýü ýü ÿþ ÿþ

ÿþýüûúýùý ÿþýüûúýùý ýööý÷õ Firewall ýööý÷õ ÿþýüûúýùø÷öõô with NAT ÿþýüûúýùø÷öõô õ õ

Many organisations have a number of resource domain’s and one account domain. A client PC is normally a member PC of the resource domain, which trusts the account domain where all users are defined. The trust is setup to distribute administrative authorities to the various resource domains.

Pass-through authentication is the most frequently used type of trusted relationship traffic. There are two different types of pass-through authentication: when a user in a trusted domain attempts to access a resource in a trusting domain and when a user on a NT client workstation attempts to log on by using a trusted account and the computer is member of a trusting domain.

A user in this set-up typically logs in to the account domain through the resource domain controller simply by passing the users credential through to the account domain controller. This process requires establishing more NetBIOS sessions:

• One session between client and the resource domain server (sequences as described above) • One session between the domains’ controllers (by using a secure channel. NetLogon on the resource domain controlles forwards the users credentials to NetLogon on the account domain controller via RPC over NetBIOS TCP 139). The resource domain controller needs to find the right domain controller by calling WINS or through broadcasts to find type <1C> servers and find out the right PDC for the domain. A utility setprefdc.exe from Microsoft can sometimes help setting/forcing the right DC to call from the start as opposed to trying many different DC’s. The knowledge of DC’s is cached on the resource domain controller in order to minimize this kind of traffic. • One session between the resource domain workstation and the account domain server (NB! Is this session necessary if there is no login script on the account domain controller ?, typically the NetBIOS session port TCP 139 is used for this.)

As the logon is not supported through firewall with NAT, the internal client can’t logon to the PDC on the external side and vice versa. If NAT not is used, the PDC’s can be placed wherever wanted depending on, what the security policy allows for as many ports need to be opened through the firewall.

Notice that even though the client logs on to the account domain and not to the resource domain, the logon and authentication is being done through the PDC for the resource domain as the resource domain has a trust relation to the account domain.

FocusPM White paper by Claus Jespersen, HP Denmark Page 43 of 43 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Windows 2000 logon from from NT NT 4.0 computercomputer through through firewall firewall (1) (1) External domain membership

ÿýöö ÿýöö

ô÷ö ÷öôöö ööý÷ôýù ýöøô÷õ

ÿþýüûúýøõ Firewall without NAT

The figure above shows a setup where the firewall does NOT have NAT enabled. In this setup, the client can be done through the firewall to a PDC on the other side of the firewall (that is if the security policy allows for this). In this setup, the client is member of the domain served by the PDC on the other side of the firewall and the client also logs on to the domain served by this PDC when logging in.

WINS servers can also be setup to do replication across the firewall.

The logon process is as follows

Locating Controllers (WINS port 137 or UDP port 138) SAM Logon request (UDP port 138) 1) Logon to a controller a) Name resolution of domain controller (WINS port 137 or local broadcast on UDP port 138) b) Session Request (TCP port 139) c) Protocol Negotiation (SMB TCP port 139) d) Retrieving Trusted Domains (RPC over TCP port 139) e) Secure Channel Setup (TCP port 139) f) Registering Names (WINS port 137 or local broadcast on UDP port 138) 2) User Logon a) Client validation (TCP port 139) b) Get logon scripts and policies (TCP port 139)

Depending on where the various servers are placed, the above-mentioned rules must be set-up in the Firewall to make this logon work through the firewall.

FocusPM White paper by Claus Jespersen, HP Denmark Page 44 of 44 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ WindowsWindows 2000 logon from NT 4.0 computercomputer through through firewall firewall (2) (2) Internal domain membership

ÿýöö ÿýöö

ô÷ö ÷öôöö ööý÷ôýù ýöø ô÷õ

÷ õý ÷ô

Firewall ÿþýüûúýùý without NAT ýööý ÷õ

In this set-up, the resource domain is on one side of the firewall, and the account domain’s PDC’s are on the other side. The firewall does NOT implement NAT.

A user in this set-up typically logs in to the account domain through the resource domain controller simply by passing the users credential through to the account domain controller. This process requires establishing more NetBIOS sessions:

• One session between client and the resource domain server (sequences as described above) • One session between the domains’ controllers (by using a secure channel. NetLogon on the resource domain controlles forwards the users credentials to NetLogon on the account domain controller via RPC over NetBIOS TCP 139) • One session between the resource domain workstation and the account domain server (NB! Is this session necessary if there is no login script on the account domain controller ?, typically the NetBIOS session port TCP 139 is used for this.)

Rules in the firewall must be setup according to the protocols needed (see above)

7.7.2 Kerberos Version 5

Kerberos authentication protocol replaces NTLM as the primary security protocol for access to resources within or across Windows NT domains. The Kerberos authentication protocol is a mature industry standard that has advantages for Windows NT network authentication. Some of the benefits of Kerberos protocol are mutual authentication of both client and server, reduced server load during connection establishment, and support for delegation of authorization from clients to servers through the use of proxy mechanism.

FocusPM White paper by Claus Jespersen, HP Denmark Page 45 of 45 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Native Windows Windows 2000 2000 logon

ÿýöö ÿýöö

ô÷ö ÷öôöö ô÷ö öö ÷öôöö öö

÷õýùø÷öõô Firewall õ with NAT ÷õýùø÷öõô õ

The scenario for the set-up shown above is:

• The Windows 2000 client logs on to the domain it is a member of through the GUI • The DNS servers are queried for LDAP servers (default first site LDAP server) • The client probes LDAP servers on UDP port 386 to see, if they are up running • The client connects to the LDAP server with highest priority using the protocols mentioned below • The client gets back a Ticket Granting Ticket and a ticket for it’s own services.

Protocol used from Windows 2000 client to Windows 2000 domain controller when logging on

• RPC over NBT TCP port 445 • NBT TCP port 445 • NBT UDP port 138 registration request for domain or WINS, depending on the NetBIOS node type • Client call to DNS server for LDAP default first site • LDAP query UDP port 389 to all returned DC’s (if more) to see if they are up running • LDAP query TCP port 389 to DC • DCE/RPC TCP port 135 and dynamic TCP ports from client to DC • Kerberos UDP port 88 from client to server • SMB/NBT TCP port 445

The client can only log on to domains on the same side of the firewall, as the Windows 2000 logon process is NOT supported through firewalls, this is at least the case if the firewall has NAT enabled. In case NO NAT is used, it is possible to set up the firewall to allow for this, if the security policy allows it.

If the client logs on to another domain and not its own domain, the process is

• The Windows 2000 client logs on to the domain through the GUI • The DNS servers are queried for LDAP servers (default first site LDAP server) • The client connects to the LDAP server with highest priority using the protocols mentioned below • The client gets back a LDAP v 3 referral to another domain. If the member domain is domain1.x.y and the logon domain is domainx.x.y, then the referral is to domain x.y. • The client queries DNS for LDAP servers for domain x.y.

FocusPM White paper by Claus Jespersen, HP Denmark Page 46 of 46 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• The client connects to the LDAP server with highest priority for domain x.y • The client gets back a LDAP v 3 referral to domain domainx.x.y • The client queries DNS for LDAP servers for domain domainx.x.y • The client connects to the LDAP server with the highest priority for domainx.x.y • The client gets back a ticket granting ticket and a ticket service ticket for its own services.

Notice that when running in native mode and using Universal Principal Names, the domain controllers will contact the global catalog (which may be on the same or on other domain controllers) to get a list of the groups, that this user is member of.

Theoretically, it would be possible for the logon process to succeed with the local DC, but (because of any number of problems) the local DC may fail in its attempt to obtain Universal Group SIDs from the Global Catalog. This is referred to as "Partial Authentication" or "Partial Logon."

If the Global Catalog is unavailable, logon will fail. The reason for this design is that if a Universal Group DENIAL existed, but the Global Catalog was unable to provide the necessary SIDs, a user authenticated with "Partial Access" might actually have a greater level of access than would be the case if the user were "Fully Authenticated."

This could lead to a situation where users could, under the right set of circumstances, sometimes gain access to resources they would normally be unauthorized to see. For an informed "power user" with malicious intent, it would be a simple matter to either power-down or simply unplug the Global Catalog Server from the network any time less restricted access to the network was desired.

Universal Groups can not be created in a Mixed-Mode domain (AKA "Down-Level" Domain). However, because a resource (User, Computer, Printer, i.e. any Security Principal) from a Mixed-Mode domain may be included in a Universal Group created in some other Native-Mode domain, some method must exist for correctly authenticating a user (or Security Principal) in the Mixed-Mode Domain.

Suppose a user logs on in a mixed-mode domain called MIXED. Mixed is a child domain of the NATIVE domain, which is using native mode. The user wants to access a file in the Native domain. When the user logged on in the Mixed domain, he received his credentials. When he tries to connect to the file server in Native, he will request a session ticket for the file server from a DC in Native. The DC will query the Global Catalog server for users membership in any universal domains and add any appropriate SIDs to the users credentials in the session ticket. The user then has all his credentials, and he can present the session ticket to the file server.

FocusPM White paper by Claus Jespersen, HP Denmark Page 47 of 47 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ NativeNative Windows 2000 logon through firewall (1) (1) External domain membership ÿýöö

ÿýöö

ô÷ö ÷öôöö öö

÷õýùø÷öõô õ Firewall without NAT

In this setup, the Windows 2000 client is able to log on to a domain controller on the other side of the firewall, as the firewall does not implement NAT. The client is member of the domain served by the domain controller on the other side of the firewall. The scenario is as described above, just through the firewall. Regarding DNS, there may be two DNS systems running-, One on each side of the firewall. In this case it is important, that they are synchronized in some way, so the client and servers have the same understanding of the FQDN names and IP-addresses used. In the case of one consistent contiguous DNS name space, the DNS set-up just works as normal DNS across the Firewall. The DNS zones may be integrated into the Active Directory if the Microsoft DNS is used.

FocusPM White paper by Claus Jespersen, HP Denmark Page 48 of 48 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ NativeNative Windows 2000 logon through firewall (2) (2) Internal domain membership ÿýöö

ÿýöö

ô÷ö ÷öôöö ô÷ö öö ÷öôöö öö

÷õýùø÷öõô õ Firewall without NAT

In this set-up, the computer is member of the domain defined on one side of the firewall. Furthermore, the client normally logs on to this domain. It is, however, possible for the client to log on to a domain on the other side of the firewall-, if the firewall does not implement NAT and if the given protocols are allowed for through the firewall. The Active Directory is synchronized through the firewall in this case either through use of RPC or SMTP. SMTP can only be used as synchronization mechanism-, if the domain controllers on each side serve different Windows 2000 domains.

7.7.3 Distributed Password Authentication (DPA)

DPA is the shared secret authentication protocol used by some of the largest Internet membership organizations, such as MSN and CompuServe. This authentication protocol is part of Microsoft Commercial Internet System (MCIS) services and is specifically designed for users to use the same Internet membership password to connect to any number for Internet sites that are part of the same membership organization. The Internet content servers use the MCIS authentication service as a back-end Internet service, and users can connect to multiple sites without reentering their passwords.

NB! Should I put in a table that shows which protocols are used exactly ?!?!? I don’t know much about this!!

7.7.4 Public-key-based protocols

PKI based protocols provide privacy and reliability over the Internet. SSL is today the de facto standard for connections between Internet browsers and Internet information servers. These protocols which use public-key certificates to authenticate clients and servers depend on a public-key infrastructure for widespread use. Windows NT 4.0 provides secure channel security services that implement the SSL/PCT protocols. Windows 2000 security has more enhanced features support for PKI protocols,

In order to clarify, what we are talking about, two issues related to PKI protocols exist

FocusPM White paper by Claus Jespersen, HP Denmark Page 49 of 49 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• The protocols that use PKI for authentication and encryption are as follows • SSL based protocols (HTTPS, POP over SSL, SMTP over SSL etc.) IPSEC (see IKE below) IKE (Internet Key Exchange used by IPSEC) Various other VPN solutions

• The protocols that the PKI infrastructure uses by itself to: a) Issue certificates b) Store certificates c) Publish certificates d) Administrative purposes

Please look under the various protocols and other places in this white paper for further details.

Some communication scenarios are given below in relation to protocols used by PKI infrastructure

- when an application or user interactively wants to request a certificate. This can be done, if the certificate server is running on the same machine as the applications/users requiring it. In this case no specific protocol that we need to know of is used. Typically it is done through a local API. (SSPI API for example ?) If the certificate server is running on another machine, the request is often done either by email (SMTP) or through HTTPS. This kind of request typically involves two steps. One step is to request the certificate through either of these two protocols and another step is to receive and install the new certificate. The latter is typically done by using the same protocols. A key is given to you when requesting a certificate, either on the HTTPS page, on which you requested the key or in an email sent to you. The actual retrieval of the certificate is often done from a WEB-browser using HTTPS and specifying the key mentioned.

- when a certificate server is set up to publish certificates to a directory server, LDAPS could be used (LDAP over SSL) initiated from the certificate server to the directory server, such as active directory.

- when an application checks the certificate to see if it is still valid or on a Certificate Revocation List (CRL). This would normally be done using HTTPS to the certificate server directly. The expiration date is in the certificate itself, but even though it could be on the Certificate Revocation List done by the administrator.

- DNS name resolution. The Certificate server needs to be able to locate directory servers, clients etc. The same is true for the clients asking for certificates in order to access the Certificate Server through HTTP.

- Client/application or user lookup of various certificates from the directory server (Active Directory for example). This lookup is typically done by using LDAP. (which would require a DNS lookup) NB! How is this request being authenticated ? Are the certificates typically in the Global Catalog. If yes, MSLDAP (port 3268 would be used as opposed to LDAP 386)

- Administration of Certificate Servers: The MMC GUI is typically running locally on the machine, where the Certificate server is running. NB! I don’t know if and how it is possible to get the SNAP-IN MMC for Certificate Server management to run from another machine, and if yes, what protocol would be used.

Also a WEB-browser or application using normal HTTP can be used to request/retrieve etc. certificates from the Certificate server. The URL for Win2k Certificate server is http:///certsrv .

7.8. Add domain/leave domain

FocusPM White paper by Claus Jespersen, HP Denmark Page 50 of 50 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Sometimes a NT or Win2k server or workstation is member of a workgroup and you want to change the domain membership to a “resource domain” or Win2k domain in general. In Win2k environments, the “resource domain” and “account domain” will typically be the same as if you only have one Win2k domain.

Anyway, domain relation ship can be changed by selecting “My Computer” and right click. If you have the Certificate Server installed, you will notice that you can’t change the domain. Otherwise you will be able to do this though the GUI “Network Identication”. You can also specify your fully qualified domain name (equal Full computer name: in the GUI). The figure below shows the Windows 2000 screen, where you can choose to change the identification.

When changing the domain through the GUI in Windows 2000, the protocols use are listed below

• query DNS for LDAP service • LDAP search active directory • NBT broadcast or WINS for name registration domain <1c> • UDP port 138 broadcast for domain or use of WINS depending of NetBIOS node type. • Direct host TCP port 445 • query DNS for Kerberos server • Kerberos UDP 88 from client to server • SAM netlogon request UDP port 138 • RPC over NBT 445 from client to server • SMB over NBT 445 and NBT 139 • DCE/RPC TCP port 135 + dynamic ports

If you at a later stage decide to leave the domain, (if you have certificate server running, you will have to uninstall it, before being able to change domain membership), the protocols shown below are used:

• Query DNS for LDAP service • LDAP search active directory • NBT broadcast for name registration domain <1c> UDP port 138 broadcast for new domain or WINS protocol depending on NetBIOS node type. • Direct Host TCP port 445 • Query DNS for Kerberos server • Kerberos UDP 88 from client to server • RPC over NBT 445 from client to server

FocusPM White paper by Claus Jespersen, HP Denmark Page 51 of 51 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• SMB over NBT port 445 and SMB over NBT port 139 ??

IF NT 4.0 is used, the following protocols will be used:

• Query WINS or use NetBIOS broadcast to find domain controller • NBT broadcast on UDP 138 or WINS to do name registration. • Logon using NetLogon request UDP 138 • Other NetBIOS sessions using TCP port 139 and RPC over TCP port 139 • SMB traffic using TCP port 139 to get policies etc.

NB! This needs to be verified. I haven’t traced it for NT 4.0 and have no documentation on it. The Win2k part has been traced and the text included is based on this trace rather than official documentation on the subject.

Enter and Leave domain can’t work through a NAT device. If you really need this to work (for example for home computers wanting to access company wide servers, you need to look into use of VPN (see other sections for information on this).

7.9. Trust Relation

Below, the trust relationships of server->server communication traffic is described in relation to the protocols used.

7.9.1 Windows NT 4.0 Trusts

Various scenarios exist when talking about NT trusts

• Establishing a trust relationship • Maintaining a trust relationship • Ongoing traffic related to trust relationship

Establishing a trust relationship involve

Permitting the trust: The trusted domain permits another domain to trust it. The only network traffic generated by doing this is between PDC’s and BDCs if any. (synchronization). PDC’s announce trust relation changes (every 5 minutes) to the BDC’s and the BDC’s gets the changes by using the protocols described above.

Adding a trusted domain: Now the trusting domain adds the first domain as a trusted domain.

• Determines the name and address of the trusted primary domain controller by using WINS and NETLOGON queries. • Establishes TCP and NetBIOS sessions with the PDC of the trusted domain as well as negotiates SMB protocols.All this is done on TCP port 139 as discussed elsewhere. • Establishes connections to IPC$ on the PDC by using the trusting domain’s account as a normal user in order to verify that the account has been created. • Communicates a list of backup browsers and servers in the trusted domain back to the trusting domain machine. • Establishes connections to a domain controller in the trusted domain to get domain name of the trusted domain. • Adds a query to WINS for all domain controllers of the given domain.

Maintaining a trust relationship: involves very little traffic. When the PDC is restarted, it must verify the trust relationship. The trusting domain controller queries WINS for a list of domain controllers in the trusted domain and then attempts to log in to the domain by using the trust user account. If successful, the trust has been verified.

Ongoing traffic related to trust relationship happens when

• The administrators add trusted account to local group

FocusPM White paper by Claus Jespersen, HP Denmark Page 52 of 52 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• The administrators grant trusted account access to resource • Whenever trusted accounts are displayed

This traffic involves NetBIOS session TCP port 139 traffic initiated from the trusting domain machine to the IPC$ share on the PDC.

Trust Relation between NT 4.0 PDC and Windows 2000 in PDC emulation mode

ÿýöö ÿýöö

ô÷ö ô÷ö ÷öôöö ÷öôöö ÷ôýùýöø ô÷õ ÷ôýùýöøô÷õ

Firewall ÷õýÿþýüûúýù without NAT

When a client accesses a resource in another domain, the domain controller in that remote domain (the trusting domain) must contact the domain controller in the trusted domain (be it the account domain for example). The traffic generated by the trusting domain controller to complete this process involves

• Establishing a session to TCP port 139 with the domain controller in the trusted domain. • Creating a null session to IPC$ of the trusted domain controller also by using TCP port 139 • Establishing a named pipe to the domain controller by using RPC over TCP port 139. (if not already established)

When a user on a machine which is member of the trusted domain accesses resources on a computer in the trusting (resource) domain, pass-through authentication is used as well

Trust relation communication is NOT supported through a NAT device. If you really need this to work, you have to look into the use of VPN and “bypass” the NAT. An example could be home office users who want to be able to establish trusts from a remote “home office” through a local NAT device. See other sections for information on this topic.

7.9.2 Windows 2000 Transitive Domain Trust

A trust relationship is as previously explained a relationship established between two domains that allows users in one domain to be recognized by a domain controller in the other domain. Trusts let users access resources in the other domain and also let administrators administer user rights for users in the other domain. For

FocusPM White paper by Claus Jespersen, HP Denmark Page 53 of 53 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ computers running Windows 2000, account authentication between domains is enabled by two-way, transitive trust relationships.

All domain trusts in a Windows 2000-based forest are two-way and transitive, defined in the following way:

• Two-way. When you create a new child domain, the child domain automatically trusts the parent domain, and vice versa. At the practical level, this means that authentication requests can be passed between the two domains in both directions. • Transitive. A transitive trust reaches beyond the two domains in the initial trust relationship. This is how it works: If Domain A and Domain B (parent and child) trust each other and if Domain B and Domain C (also parent and child) trust each other, then Domain A and Domain C trust each other (implicitly), even though no direct trust relationship between them exists. At the level of the forest, a trust relationship is created automatically between the forest root domain and the root domain of each domain tree is added to the forest, with the result that complete trust exists between all domains in an Active Directory forest. At the practical level, because trust relationships are transitive, a single logon process lets the system authenticate a user (or computer) in any domain in the forest. This single logon process potentially lets the account access resources on any domain in the forest. Note, however, that the single logon enabled by trusts does not necessarily imply that the authenticated user has rights and permissions in all domains in the forest. In addition to the forest-wide two-way transitive trusts generated automatically in the Windows 2000 operating system, you can explicitly create the following two additional types of trust relationships:

• Shortcut Trusts. Before an account is granted access to resources by a domain controller in another domain, Windows 2000 computes the trust path between the domain controllers for the source domain (where the account is located) and the target domain (where the desired resource is located). A trust path is the series of domain trust relationships Windows 2000 security traverses in order to pass authentication requests between any two domains. Computing and traversing a trust path between domain trees in a complex forest can take time. In order to improve performance, you can explicitly (manually) create a shortcut trust between non-adjacent Windows 2000 domains in the same forest. Shortcut trusts are one-way transitive trusts that enable you to shorten the path. You can combine two one-way trusts to create a two-way trust relationship. Although you cannot revoke the default two-way transitive trusts automatically established among all domains in a Windows 2000 forest, you can delete explicitly created shortcut trusts.

• External Trusts. External trusts create trust relationships to domains in a different Windows 2000 forest or to a non-Windows 2000 domain (either a Windows NT domain or a Kerberos version 5 realm). External trusts enable user authentication to an external domain. All external trusts are one-way non- transitive trusts. You can however combine two one-way trusts to create a two-way trust relationship.

In the Windows NT 4.0 (and earlier) operating system, trust relationships are one-way, and trust is restricted to the two domains between which the trust is established (they are non-transitive). When you upgrade a Windows NT–based domain to a Windows 2000–based one, the existing one-way trust relationships between that domain and any other Windows NT domains are maintained. If you install a new Windows 2000 domain and want to establish trust relationships with Windows NT domains, you must create Windows 2000 external trusts with those domains. To explicitly establish a trust relationship, you use the Active Directory Domains and Trusts tool.

FocusPM White paper by Claus Jespersen, HP Denmark Page 54 of 54 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ Trust Relation in native native Windows Windows 2000 2000 modemode / / Kerberos transitive trust trust

ÿýöö ÿýöö

ô÷ö ô÷ö ÷öôöö ÷öôöö

Firewall ÷õýúúúýø÷öõô without NAT ôöýöö÷

When domains establish trust, they exchange inter-domain keys. The authentication service for each domain uses its inter-domain key to encrypt tickets to the KDC of the other domain.

When a client wants to access to a server in a remote domain, the client contacts the domain controller in its home domain for a TGT. The client then presents the GTG to the KDC on the domain controller of the remote domain if the client has a direct trust relationship with the remote domain, or its parent domain. This process is repeated with all intermediate domains until a trust path has been built between the home domain of the client and the remote domain.

The client presents the referral TGT to the KDC of the remote domain controller, asking for a ticket to a server in the client domain. The remote domain controller uses its inter-domain key to decrypt the TGT of the client. If decryption is successful, the remote domain controller can be sure that the TGT was issued by a trusted authority. The domain controller then grants the client a ticket to the requested server.

The protocols used to create the trust are given below

NB! I need to find out which protocols are used: My guess would be

• DNS to locate remote domain controller (query for LDAP and Kerberos servers for the domains in question) • LDAP request to remote domain controller (TCP port 389) • Kerberos request to get tickets (UDP port 88) • DCE/RPC (TCP port 135 + dynamic TCP port allocation >1023)

FocusPM White paper by Claus Jespersen, HP Denmark Page 55 of 55 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.10. DCOM

Unlike most Internet applications which have fixed TCP and/or UDP ports, DCOM dynamically assigns -- at run time -- one TCP port and one UDP port to each executable process serving DCOM objects on a computer.

Clients discover the port associated with a particular object by connecting to and using the services provided by DCOM's (SCM). The SCM always operates at a fixed network port on every computer; in the Internet case this is always port 135 for both TCP and UDP. The SCM offers several RPC- based (not DCOM/ORPC-based) services which handle operations like: "create a new COM class object for me and tell me what TCP and UDP port it is on" or "I have an interface pointer, tell me where I need to go to actually use it", etc... A much more technical explanation of this process and of the DCOM wire protocol in general is documented in the DCOM/1.0 specification at http://www.microsoft.com/com.

DCOM's dynamic port allocation feature offers great flexibility in that programmers and administrators alike are free from the burden of having to configure (or hard code) applications to specific ports, free from resolving conflicts between multiple applications attempting to use the same port(s), and so on. Unfortunately, because DCOM (by default) is free to use any port between 1024 and 65535 when it dynamically selects a port for an application, it is rather "firewall unfriendly" out of the box. Configuring your firewall to leave such a wide range of ports open would present a serious security hole. Microsoft's developers realized this and have implemented a feature which allows you to restrict the range of ports that DCOM will use to assign to applications.

You should be aware that callbacks in DCOM are NOT handled on the same connection that is used for client- >server method calls. When a server makes a callback to a client, it creates a new connection to the client and sends method calls over that separate channel. In other words, DCOM treats callbacks just like any other client->server method call, except that your "client" is really a server and the "server" is really a client. In some circumstances (this is very rare), you may need to configure port restrictions on your clients if your firewall restricts which ports machines on the inside can connect to on the outside.

Also note that if you want to use callbacks through a firewall, you must use TCP. The reason being that when the server makes a call to the client, the source port will not be within the range below and thus when the client sends a reply to the server's source port, it will not be able to penetrate the firewall. This is not a problem with TCP because most firewalls keep track of TCP connections and permit bidirectional traffic on connections, regardless of the source port, as long as they are opened from a machine on the inside.

One last thing before I continue, the client must be able to reach the server by its actual IP address. You cannot use DCOM through firewalls that do address translation (i.e. where a client connects to virtual address 198.252.145.1 which the firewall maps transparently to the server's actual address of, say, 192.100.81.101). This is because DCOM stores raw IP addresses in the interface marshaling packets and if the client cannot connect to the address specified in the packet, it won't work.

See the section about SOAP for further discussions on protocols used for distributed (COM) objects. SOAP seems to be a replacement for DCOM.

7.11. Microsoft WMI

Microsoft Management Instrumentation or WMI is a service (as opposed to an end user application) that can provide access to various management information, such as

- Performance, PerfMon data - SNMP/MIB values - Registry - WDM (Windows Driver Model) - DMI (Desktop Management Information) - Event Log - (DNS via Win2k Resource Kit) - Active Directory

FocusPM White paper by Claus Jespersen, HP Denmark Page 56 of 56 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

The WMI service can be installed as an option on NT 4.0 SP4. On Windows 2000, it is a built-in service. Microsoft position WMI as the new management service that will obsolete SNMP and DMI on a Microsoft Platform. It is Microsofts implementation of the WBEM (Web Based Enterprise Management)) standard.

Through WMI it is also possible to execute actions. The protocol used by WMI is Remote Procedure Call (RPC). See RPC for more information on this.

On NT the client interface is typically a Visual Basic Script that accesses the WMI information or a test application wbemtest.exe, that can be used for debugging/testing purpose. In Windows 2000 the client interface to WMI is typically Computer Management, where it is included.

Also various management applications use a WMI client interface to access WMI information. This includes Microsoft SMS.

7.12. Microsoft DMI

DMI (Desktop Management Interface) is an industry framework for managing and keeping track of hardware and software components in a system of personal computers from a central location. DMI was created by the DMTF (Desktop Management Task Force) to automate system management and is particularly beneficial in a network computing environment where dozens or more computers are managed. DMI is hardware and operating system-independent, independent of specific management protocol, easy for vendors to adopt, mappable to existing management protocols such as the Simple Network Management Protocol (SNMP), and used on network and non-network computers. DMI consists of four components: Management Information Format (MIF): An MIF is a text file that contains specific information about the hardware and software being used on a computer. An MIF file consists of one or more groups containing attributes, which describe each component. By default, each MIF file contains the standard component ID group. This group contains the product name, version, serial number, and the time and date of the last installation. The ID number is assigned based on when the component was installed in relation to other components. Manufacturers can create their own MIFs specific to a component. For example, a manufacturer might write an MIF file for a fax/modem that contains two groups: a fax group and a modem group. Some group attributes include warranty information, support phone numbers, and any errors encountered. This information is then sent to an MIF database.

Service layer: The service layer is memory-resident code that acts as a mediator for the management interface and the component interface and allows management and component software to access MIF files in the MIF database. The service layer is available as an operating system add-on and is a for all programs. As the service layer must run all the time, it is designed not to use a lot of memory. The service layer also includes a common interface called the local agent, which is used to manage individual components.

Component interface (CI): The CI is an application program interface (API) that sends status information to the appropriate MIF file via the service layer. Commands include the Get and Set command that modifies the MIF as needed and the Event command that notifies management software of critical events.

Management interface (MI): The management software communicates with the service layer using the MI application program interface. The MI allows administrators to issue the Get and Set command and the List command that lists all the DMI-manageable devices.

To use DMI, you need a DMI-compliant management software package and a DMI-compliant computer. A DMI-compliant computer includes the CI, the MI, and the service layer. These drivers are available for download on the Internet. DMI is a standard controlled by IETF.

Various management products such as Microsoft SMS and HP OpenView (TopTools and other OpenView products) use DMI to get information. The DMI implementations are mainly seen on the Intel platform but some are also available on Unix platforms (Sun and HP are the only platforms I know of). DMI can actually also be used to set various values on clients. For example HP has for many years been able to write protect all disk- drives on any HP PC in the company through DMI from one single workstation/GUI.

The use of DMI seems to be superseded by the Microsoft implementation of WBEM, WMI (Windows Management Instrumentation).

FocusPM White paper by Claus Jespersen, HP Denmark Page 57 of 57 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

The access from a DMI capable application to a DMI agent is typically done by using DCE/RPC, which implies dynamically allocated ports. (See RPC and restriction of ports for further information).

7.13. Internet Explorer (IE)

Internet explorer is mainly used for accessing information on various WEB-servers utilizing the HTTP protocol. Furthermore IE can use the following protocols:

• HTTPS: Secure HTTP • FTP: File transfer • SOCKS: application layer proxy, TCP port 1080 • DNS: Domain Name System

Each connection from the browser is done through one of the three mechanisms given below

• Directly • Through a Proxy Server • Through a SOCKS Server

The protocols used from the client depends on which mechanism is used ad1)

A direct connection from the browser can initiate a

• HTTP connection to a given WEB server typically on TCP port 80 • HTTPS connection to a given WEB server (HTTP over SSL) typically on TCP port 443 • FTP connection to a given FTP server (using passive FTP, all connections are initiated from the client) • Gopher typically on TCP port 70 • SMTP (if mailto: is specified, a local connection using SMTP is being used) • DNS connections to the DNS server specified in the Network Control Panel or given by DHCP as an option. UDP port 53 is used for these requests. ad 2)

If the browser is configured to use a Proxy server for all or specific sites, then the protocol used for these sites from the client is

• HTTP from the client to the Proxy Server on the port that the proxy server uses, typically 8088

All traffic is tunnelled (or proxied) in HTTP. For example, if the user specifies ftp://ftp.servera.com as location in IE and a Proxy Server is used for this address, then all requests are sent by using HTTP to the Proxy Server. No local DNS resolution is done. The URL is taken as it is and resolved on the Proxy Server. However if the Microsoft Proxy Server is used and the client also has a Winsocks client installed, local requests on other ports including DNS may be seen.

When the Proxy Server gets the request it forwards the packet to the end destination using the native protocol. This means that it would issue a FTP request to the destination FTP server from the Proxy Server, get an answer on FTP protocols and send the response back to the client using HTTP. ad 3)

If a SOCKS server is used instead of a Proxy Server, all requests from the client are typically sent on TCP port 1080. The SOCKS server receiving the request unpacks the request and sends it to the final destination using the native protocol. So if an IE user tries to access the FTP Server by specifying ftp://ftp.serverb.com and a SOCKS server has been set up, the only protocol used from the IE client to the SOCKS server is TCP port 1080. DNS requests however are resolved locally on the client, as there is no Browser (I know of) that is able to take advantage of the SOCKS5 feature on which it can be specified where the DNS name resolution should

FocusPM White paper by Claus Jespersen, HP Denmark Page 58 of 58 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ take place (locally or remotely). All URL’s must be able to be resolved in order to access the site. However it would also be possible to put in the destination IP-address if the local DNS server not is able to resolve the external DNS name. This is not a very good solution as there may be a lot of links on that web-server or other servers that include other DNS names, so when choosing these links, it will fail with a name resolution error.

7.14. Outlook and Outlook Express

Outlook Express is typically installed by default on NT and on Windows 2000 together with IE. If you use Outlook, you normally don’t need Outlook Express, unless you want to use the Outlook Express Newsreader which is NOT part of Outlook.

Outlook Express Mail is an Internet standards based e-mail and news reader. To read e-mail with Outlook Express, you must be using a mail system that uses SMTP and POP3 or IMAP protocols. At present, you cannot use Microsoft Outlook Express to access your e-mail account with any of the following services: MS Mail, cc:Mail, CompuServe, America Online (AOL), or Microsoft Exchange Server prior to version 5. If you don't know whether your system uses these services, contact your administrator or your Internet service provider and ask if they support SMTP/POP3 or IMAP mail clients.

As previously mentioned, you can also use Microsoft Outlook Express News to read bulletin-board discussion groups, such as the Usenet, using NNTP-based news servers. Contact your Internet service provider or network administrator for the name of the news server you should use. Outlook Express News can also be used to receive support for a variety of Microsoft products on the news server msnews.microsoft.com.

In Outlook 98/Outlook 2000 you have a choice. It can be used in two modes

• With protocol support via MAPI (uses DCE/RPC to Exchange mail server and through a HP delivered MAPI->UAL driver. UAL uses one specific TCP port from the client to the server. (that can be configured). • With normal Internet standard protocol support such as SMTP, POP3, IMAP4 and LDAP as Outlook Express.

In Firewall environments, it is recommended to use the Internet standard protocol support. However, note that you may loose some functionality such as support and public folders etc. if your mail server is Exchange. In Exchange 2000, you will find support for these features even when using a standard WEB- browser, which is using using HTTP, but this product is not yet used very much. In Exchange 2000, you will also have Web-stores, which basically are local or remote folders that can be accessed through a WEB- browser. This is really a nice feature. Even though a WEB interface is available for older Exchange versions (5.x), the features provided are not as many as when using MAPI or Exchange 2000 with WEB interface.

To send mail, Outlook (in “Internet mode”) and Outlook Express uses SMTP and SMTP over SSL (still TCP port 25 even when SSL is used).

To receive mail, Outlook (in “Internet mode”) and Outlook Express uses either POP3, POP3 over SSL or IMAP4, IMAP4 over SSL.

LDAP is used to search configured directory services for address book entries etc.

The DLL’s and COM objects used by Outlook are often called from other applications, such as Internet Explorer. For example in order to send a SMTP email.

Outlook used in “Internet mode” can be used through a firewall, so the Outlook GUI is on one side and the mail-server being accessed is on the other side. Both SMTP, POP3, IMAP4 and LDAP work through a firewall implementing NAT, given that DNS names are used as opposed to IP-addresses and given that DNS has been set up correctly. The reason why SSL based applications/protocols will work through a firewall is that these are application layer security as opposed to network layer security like IPSEC.

7.15. DNS server

FocusPM White paper by Claus Jespersen, HP Denmark Page 59 of 59 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

DNS or Domain Name System (or Domain Name Services, as some call it) is used to translate from host names to IP-addresses and vice versa.

The figure below shows a typically placement of a DNS servers.

DNSDNS Server Server DHCP Server ÿýöö ÿýöö ô÷öý÷öôýý ÷ ö õ ÷öõ

DHCP Server ÿýùø÷öõô Server

Windows Server ÿ ùø÷öõô

Different communication is done to and from DNS servers

• Client DNS communication (from machines, users or applications) to one or more DNS servers on UDP port 53 • Client DNS communication to one or more DNS servers on TCP port 53 when requesting big packets or requesting a zone-transfer (for example by using “ls –d domainname” from within nslookup). • DNS server communication from secondary to primary when refreshing status on UDP port 53 • DNS server communication from secondary to primary when requesting a full or incremental zone transfer. • Primary to secondary when notifying secondaries of changes on UDP port 53

Using NAT is a challenge especially for DNS as a DNS packets holds one or more IP-addresses. If an internal client on the intranet looks up an external name for an Internet host, it does not give any problems even though this request is going through a NAT. The reason for this is that the the IP-address, which is returned by the external DNS server is the IP-address that the internal client should use. NAT is typically only a problem between networks where both networks have illegal addresses and a NAT is between these two networks. Many enterprises have internal NAT’s for example between countries or subsidiaries. In such environment it is very challenging to make a DNS design without having to duplicate the DNS, so that a given DNS name exists with more than one IP-address, one on each side of the NAT.

In order to try to meet this challenge, RFC2694 describes the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need. DNS_ALG modifies payload transparently to alter address mapping of hosts as DNS packets cross one address realm into another. The document also illustrates the operation of DNS_ALG with specific examples. So far no firewall on the market

FocusPM White paper by Claus Jespersen, HP Denmark Page 60 of 60 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ supports RFC2694. Cisco PIX can be set up in such a way that forward Zones automatically are being translated according to the NAT rules in the firewall. However, the reverse zones are not addresses and must be handled separately.

Even though vendors start to implement RFC2694 it might just be a short-term solution. More and more vendors and customers for that matter are looking into the DNSSEC and TSIG. These technologies verifies/authenticates DNS requests and require that NO data in the DNS dataload is changed, which is exactly what the RFC2694 implies.

The administrative DNS MMC tool is called dnsmgt.msc. It can be accessed through Computer Management, from the , from MMC or directly from the command line. The protocols used for this tool is explained further under Computer Management, but mainly DCE/RPC, Direct host and Kerberos is used from the MMC GUI to contact the DNS Server

7.16. DHCP server

Active Directory is now used to store records of authorized DHCP servers. When a DHCP server comes up, the directory can now be used to verify the status of that server. If the server is unauthorized, no response is returned to DHCP requests. A network manager with the proper access rights has to respond. The domain administrator can assign access to the DHCP folder holding configuration data, in order to allow only authorized personnel to add DHCP servers to the approved list.

The list of authorized servers can be created in the Active Directory through the DHCP snap-in. When the server first comes up, the DHCP server tries to find out if it is part of the directory domain. If it is, the DHCP server tries to contact the directory to see if the server is in the list of authorized servers. If the DHCP server succeeds, it sends out DHCPINFORM to find out if there are other directory services running and makes sure that it also is valid in other directories.

If the DHCP server cannot connect the directory, it assumes that it is not authorized and does not respond to client requests. Likewise, if it does reach the directory but does not find itself in the authorized list, it does not respond to clients. If it does find itself in the authorized list, it starts to service client requests.

When a DHCP server, which is not a member server of the domain (such as a member of a workgroup) comes up, the following happens: The server broadcasts a DHCPINFORM message on the network. Any other server that receives this message responds with DHCPACK message and provides the name of the directory domain it is part of. If a workgroup DHCP server detects another member DHCP server of a domain on the network, the workgroup DHCP server assumes that it is unauthorized on that network and does not service requests. If the workgroup DHCP server detects the presence of another workgroup server, it ignores it; this means that there can be multiple workgroup servers active at the same time, as long as there is no directory service.

Even when a workgroup server comes up and finds that it is allowed to run (because no other domain member server or workgroup server is on the network), it continues to probe DHCPINFORM every five minutes. If an authorized domain member DHCP server comes up later, the workgroup server becomes unauthorized and stops servicing.

FocusPM White paper by Claus Jespersen, HP Denmark Page 61 of 61 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

DHCP Server

ÿýöö ô÷öý ÷öô ÿýöö

ùýöö ùýöö

ûûø ûûø

ùýùø÷öõô

Windows ùý ùø÷öõô Firewall Server

Windows Server

The communication to and from a DHCP server in Windows 2000 include

• Client BOOTP request from older printers, routers etc. to DHCP (source UDP 68, destination request UDP 67) when printer/device is booting. • Client request (broadcast) to DHCP (Source UDP 68, destination request UDP 67) when PC is booting • Client request (broadcast) to DHCP to refresh lease • DHCP server requests to DNS to locate domain controllers (looking up SRV records) • (Maybe) Kerberos requests (UDP 88) to Active Directory Server to get access to Active Directory domain controller, if not already in cache from login or other request updating the Kerberos ticket. • LDAP requests to Active Directory (TCP port 389) to look up status of DHCP server • (if member server) DHCP Server requests to local subnet to query for other DHCP servers. • DHCP server request to DDNS server on the same or another machine using DNS UDP port 53 to update the DDNS server with PTR (and maybe A) records. The client PC instruct the DHCP server, who registers what.

NB! These scenarios need to be verified. This is especially true regarding the DHCP communication to Active Directory. I am not sure it is done using LDAP. It could be done using Direct Host protocol ?? Is Kerberos necessary in order to look up this information ? I am not sure.

Microsofts implementation of DHCP actually also includes a DHCP relay agent. If this service is used, a DHCP clients request may be taken by this relay agent and sent directly to a given IP-address of a DHCP server. The client request as well as the forwarding request is done by using normal DHCP UDP port 67.

FocusPM White paper by Claus Jespersen, HP Denmark Page 62 of 62 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.17. WINS server

The Windows Internet Name Service (WINS) has been enhanced for the release of Windows® 2000 Server. The result is an easier-to-manage and more robust solution for mapping NetBIOS names to IP addresses on TCP/IP networks.

Windows 2000 WINS includes server enhancements, additional client functions, and an improved management tool. WINS provides a distributed database for registering and querying dynamic computer name-to-IP address mapping in a routed network environment. This support for dynamic registering of NetBIOS computer names means that WINS can be used with DHCP services to provide easy configuration and administration of Windows-based TCP/IP networks.

The WINS server solves the problems inherent in resolving NetBIOS names through IP broadcasts, and frees network administrators from the demands of updating static mapping files, such as LMHOST files. WINS, which is compliant with the NetBIOS Name Server (NBNS) RFCs (1001/1002), also automatically updates the WINS database when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets. Neither the user nor the network administrator needs to make manual accommodations for such name resolutions.

The new implementation of WINS provides a number of features including support for persistent connections, manual tomb stoning, improved management tools, enhanced filtering and record searching, increased fault tolerance, and dynamic re-registration. WINSWINS Server

ÿýöö ô÷öý ÷öô ÿýöö

ÿýöö ÿýöö

öüøõüþû öüøõüþû

ÿýùø÷öõô

ÿ Windows ýùø÷öõô Server Firewall

Windows Server

When configuring a WINS replication partner, the first step is to add the other WINS server as replication partner through the WINS manager. This involves

• Local WINS server establishes a TCP/IP session with the destination WINS server over TCP port 135 (DCE/RPC portmapper)

FocusPM White paper by Claus Jespersen, HP Denmark Page 63 of 63 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• An RPC connection will be established by using dynamic ports above 1023 and is used to initialize the WINS database • A new TCP session and RPC connection is initialized. RPC is used to validate credentials of the requesting server and to get the name of the remote WINS server. • A new TCP session is established on TCP port 42 in order to verify the partner relationship and request the initial replication.

When first the replication is set up, replication will occur on given intervals or when a specific number of records have been updated. The WINS replication data transfer occurs on TCP port 42, so DCE/RPC is only used in the initial set up. This may be used when setting it up to work through a firewall.

In general it is a challenge to setup WINS replication through a firewall, especially when running through a firewall using NAT. In general it can’t be recommended to setup WINS replication through a Firewall with NAT (or PAT).

WINS servers can be configured for either push or pull partners or both and this influences which WINS server initiates the TCP connection. A WINS partner may be pull partner to one WINS server and push partner with another.

7.18. Internet Information Server

Microsoft IIS, Internet Information Server is available on NT as well as in Windows 2000. This WEB server supports

• HTTP requests • HTTPS requests • Active Server Pages (code included in HTML pages, server side scripting) requires no new protocol. Runs over HTTP and HTTPS • Remote Execution through use of Windows Scripting Host using HTTP. • DCOM Tunnelling (DCOM over TCP port 80 requires IIS) • Various IIS API applications such as Microsoft Proxy Server • Frontpage Extensions (requires no new protocol) • IIS Administrative Server • Kerberos authentication integrated with Active Directory/Kerberos services. • Integration to Transaction Services • Integration to Certificate Services • FTP requests (Well, the FTP server just happens to be bundled together with IIS as an option, when you install. • SMTP requests (Well, the SMTP server just happens to be bundled together with IIS as an option, when you install. • NNTP News Server (Well, the NNTP server just happens to be bundled together with IIS as an option, when you install. • WebDAV support: (Web Distributed Authoring and Versioning extends the HTTP 1.1 protocol to allow clients to publish, lock and manage resources on the WEB. WebDAV clients include Windows 2000 (through “Add Network Place Wizard”) , IE5 and Office 2000. This is the reason why WebDAV normally uses HTTP, but just version 1.1 with extensions. The clients initiate this communication. • Centralized administration using Internet Service Manager through a local or remote MMC IIS Snap-In or WEB client. • IIS to IIS server communication to replicate IIS metabase. (only supported in IIS5).

So the protocols/communication involved would be

• WEB client HTTP access to IIS on TCP port 80 • WEB client HTTPS access to IIS on TCP port 443 • Windows 2000 or IE5 WebDAV access to IIS on TCP port 80 (or HTTPS using 443 ?) • Mail client SMTP access to SMTP server on TCP port 25 • Mail client SMTP over SSL access to SMTP server on TCP port 25 • News client NNTP access to NNTP server on TCP port 119

FocusPM White paper by Claus Jespersen, HP Denmark Page 64 of 64 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• News client NNTP over SSL access to NNTP server on TCP port 563 • News Server NNTP access to NNTP server on TCP port 119 (or TCP port 563) • FTP client FTP access to FTP server on TCP port 21 • FTP server response to FTP client on TCP port 20 • WSH Script using HTTP to IIS on TCP port 80 • DCOM client access to IIS Server API (ISAPI) on TCP port 80 • WEB Client authentication such as Integrated Windows authentication (previously called Windows NT challenge/response authentication) can use both the Kerberos v5 authentication protocol and its own challenge/response authentication protocol. If Directory Services is installed on the server, and the browser is compatible with Kerberos v5 authentication protocol, both the Kerberos v5 protocol and the challenge/response protocol are used; otherwise only the challenge/response protocol is used. NOTE, that Integrated Windows authentication does NOT work over HTTP Proxy connections. • SMTP server to SMTP server communication using SMTP • SMTP server to Directory Server communication using LDAP (to look up routing and mail-users) • DNS requests to resolve remote server names for example in order to connect to other SMTP or backend application servers. • Kerberos and LDAP requests to domain controller in order to verify usernames used by IIS, if the set up is to use domain accounts. • In case of clients using normal NT authentication, IIS may contact a PDC or BDC to verify the users SID. This is done by using a NetLogon request UDP 138 and TCP port 139.

7.18.1 IIS Administration

The administration of IIS can be done from either a WEB browser or an MMC Snap-In – either locally or remotely.

The IIS MMC Snap-In can connect to any machine running IIS. The protocols used are

• DNS (or WINS) request to resolve host to connect to • Kerberos contact to domain controller(s), if the client and server is in the same forest and the client does not have a ticket. This may involve LDAP referrals to other domain controllers as described elsewhere. • MSRPC over NBT TCP port 445 and SMB over NBT port 445 • DCE/RPC TCP port 135 and dynamic ports

The WEB based version of Internet Service manager can be launched through

http:///iisadmin

This can also be set up to run on HTTPS in which case, it should be launched using

https:///iisadmin. It would require an installation of a IIS server certificate.

7.19. Certificate Server

Certificates can be issued for a variety of functions, such as Web user authentication, Web server authentication, secure email (S/MIME and SMTP over SSL), IP Security (IPSEC), Transaction Layer Security (TLS), and code signing. If the Windows 2000 enterprise certification authority is used in an organization, certificates can be used to logon to Windows 2000 domains. Certificates are also issued from one certification authority to another in order to establish a certification hierarchy.

The certification authority at the top of a certification hierarchy is called the root authority. It can be a standalone root authority (NT only supports this) or an enterprise root authority (Windows 2000 supports both).

7.19.1 Certificate server in NT

FocusPM White paper by Claus Jespersen, HP Denmark Page 65 of 65 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

The Certificate Server in NT is a “standalone” product (typically installed via the NT OptionPack), which can’t be integrated with directory services. This server can be set up to implement a root CA. It can’t be used as a subordinate CA or enterprise CA.

The following communication flow exist to/from the certificate server

• WEB Client requests (retrieve, request and check pending certificate) through HTTP TCP port 80 on http:///certsrv • Certificate Server communication to Active Directory (NB! I guess this MUST be done locally, a certificate server must be installed on a domain controller, it can’t just be a “normal” member server.

The administration of the NT Certificate Server can be done by

• Local MMC • Local or remote WEB access on http:///certsrv or https:///certsrv, if IIS has been set up to handle SSL and the virtual directory certsrv has been enabled/forced to use SSL.

7.19.2 Certificate server in Windows 2000

When a certificate request is submitted to a Windows 2000 enterprise certification authority, it is immediately processed, as opposed to being set to “pending”. The certificate request will either immediately fail or be granted. If it is granted, the certificate is issued, and a prompt is shown in order to install the certificate.

The following communication flow exist to/from the certificate server

• WEB Client requests (retrieve, request and check pending certificate) through HTTP TCP port 80 on http:///certsrv • Certificate Server communication to Active Directory (NB! I guess this MUST be done locally, a certificate server must be installed on a domain controller, it can’t just be a “normal” member server. • IPSEC clients requesting a certificate by using IKE protocol (UDP port 500) which is part of the IPSEC implementation. • Local administrative tools described below, such as certreq (using DCOM/RPC)

The administration of the Windows 2000 Certificate Server can be done by

• Local or remote MMC • Local or remote WEB access on http:///certsrv or https:///certsrv, if IIS has been set up to handle SSL and the virtual directory certsrv has been enabled/forced to use SSL.

Windows 2000 includes three command-line utilities to help you administer Certificate Services. They extend the functions and control of certificate requests and certification authorities that already are provided by the Windows graphic user interface. They are primarily intended for developers and knowledgeable certification authority administrators. The tools are : certutil, certreq and certsrv (stop and start server, just as net stop/start certsvc.

NB! Which protocols are used when an IPSEC client accesses a Certificate server when it is using X.509 certificates as authentication to create session keys. Also in general I need to find out exactly which protocols are used when.

7.20. Index Server

An Index Server is included in NT as well as in Windows 2000 as part of IIS. It can be used as a stand alone index server, in order to index and search local files on the IIS server. Clients can connect locally or remotely through a WEB browser and search for specific files based on various attributes. So by default, the only protocol involved in using the Index Server is HTTP or HTTPS client access. Together with Site Server, more Index servers can be set up to work together in order to offer central access to a complete search from more sources.

FocusPM White paper by Claus Jespersen, HP Denmark Page 66 of 66 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Search engines and Index servers are typically set up to work together with a robot, which automatically gets documents that are available for all anonymous users from various servers through HTTP. The Index server in this case can be used to index the data/files collected from the robots.

7.21. News Server

See the section about Internet Information Server, IIS.

7.22. Transaction Server

See the section about Internet Information Server, IIS.

7.23. Telnet Server

In Windows 2000 Server a telnet server is included as a service you can start and stop (net start/stop telnet). This server makes it possible for any telnet client to connect to the Windows 2000 server and give that user remote access. This gives a basic ASCII text based interface, just like a remote DOS box. No GUI interaction can be used through the telnet connection.

Anyway the telnet service is a nice feature, especially for administrators working in an Unix environment for administrative purposes. The Telnet server does not interact with other services. So the only communication involved is the DNS client looking for the server name and the client telnet connection to the server on TCP port 23.

In NT, a telnet server is available on the resource kit.

7.24. Active Directory

A Windows 2000 server can by set up without running Active Directory. Active Directory is enabled by calling dcpromo. After this is done, the server becomes a domain controller in the Active Directory forest. If it is the first server that is being converted, it will be the root directory server. Other domain controllers can here after be created as part of the same forest as child domains or replicas of the first domain controller. Other forests can also be created with a new root domain. Companies may choose to have one or more forests internally and a separate forest externally. In the longer run, as Internet security issues are becoming more well known in relation to Windows 2000 Active Directory, companies may choose to have just one forest and control access and authoritative rights within the forest.

Each domain controller implements various new services, such as a LDAP server and a Kerberos Server. Sometimes, but not always you may choose to install a DNS server on the Active Directory Server. DHCP servers should not be installed on domain controllers, if secure DNS (TSIG) is used as the records inserted in the DNS, would be owned by only one user, being the credentials of the running DHCP server.

FocusPM White paper by Claus Jespersen, HP Denmark Page 67 of 67 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Active Directory Server/Kerberos

ÿýöö

ô÷öý÷öô ô÷ö ÿýöö ÷öôöö öö öö

÷õýùø÷öõô ÷õýýùø÷öõô õ Windows Server õ ö Firewall ö ö ö Windows Windows Server Server

Some typically communications to the Active Directory Servers

• Client boot request (see section about boot for information on protocols used) • Client logon request (see section about logon for information on protocols used) • Client Kerberos authentication request (to get Kerberos tickets) • Client search by using LDAP TCP port 389 • Client search to global directory catalog by using LDAP TCP port 3268 • Client lookup for certificates • WMI requests using DCE/RPC (through local WMI service) • Client LDAP probe call using UDP 389 • API client interface using Kerberos and LDAP (ADSI, ADSIEDIT, LDP etc.) • Remote Installation Service requests to Active Directory to find out status of software installation • SMTP server lookup for routing and user information using LDAP • Certificate Server insertion of Certificates using LDAP over SSL (NB! is this true or will the Certificate Server always be on the local domain controller ?) • DHCP server lookup for other DHCP servers and DHCP authorization • Active Directory Administrative tools (see below)

Some typically communications from the Active Directory Servers

• Various answers to requests described above, including client LDAP referrals (answer to some LDAP requests) • DNS requests to other clients and servers • DDNS requests to itself when booting • Replication traffic to other domain controllers (using either DCE/RPC within sites in one domain or SMTP between domains). • Administrative tools/applications between domain controllers

FocusPM White paper by Claus Jespersen, HP Denmark Page 68 of 68 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.24.1 Administration

The administrative part of Active Directory is normally done through a MMC console. The MMC Snap-In’s include

• Active Directory Domains and trusts • Active Directory Sites and services • Active Directory Users and Computers

These MMC Snap-In’s are only installed on domain controllers and are available in the start menu. It is possible to invoke other MMC’s from within these, such as Domain Security Policy etc. When launched, you can administer local or remote domain controllers in the same forest.

With Windows 2000 Administration Tools, included on the Windows 2000 Server and Windows 2000 Advanced Server compact disc sets, you can manage a server remotely from any computer that is running Windows 2000. Windows 2000 Administration Tools contains Microsoft Management Console snap-ins and other administrative tools that are used to manage computers running Windows 2000 Server, and which are not provided on Windows 2000 Professional.

To install Windows 2000 Administration Tools on a local computer, open the I386 folder on the applicable Windows 2000 Server disc, and then double-click the Adminpak.msi file. Follow the instructions that appear in the Windows 2000 Administration Tools Setup wizard. After Windows 2000 Administration Tools is installed, you can access the server administrative tools by clicking Start, pointing to Programs, and then pointing to Administrative Tools.

On Windows 2000 Server, you can use the Software Installation snap-in to deploy Windows 2000 Administration Tools to other computers in your organization in two ways:

1. Assign Windows 2000 Administration Tools to other computers. It is then automatically installed on the remote computers. 2. Publish Windows 2000 Administration Tools in Active Directory. Once this is done, an administrator can use Add/Remove Programs in Control Panel on the remote computer to install it when needed.

The following is a list of the server administrative tools included in Windows 2000 Administration Tools:

• Active Directory Domains and Trusts • Active Directory Schema • Active Directory Sites and Services • Active Directory Users and Computers • Certification Authority • Cluster Administrator • Connection Manager Administration Kit • DHCP • Distributed File System • DNS • Internet Authentication Service • Internet Services Manager • QoS Admission Control • Remote Boot Disk Generator (part of Remote Installation Services) • Remote Storage • Routing and Remote Access • Telephony • Terminal Services Manager, Licensing, and Client Connection Manager • WINS

The protocols used to administer a remote (Domain) Controller are:

• DNS to resolve server names and to locate Kerberos and domain controllers

FocusPM White paper by Claus Jespersen, HP Denmark Page 69 of 69 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• Access to Kerberos authentication using Kerberos UDP 88 (often the client would have a Kerberos ticket for the domain controller in advance, so you won’t see this much in a network trace, especially not if the client and domain controller are in the same domain.) • Access to Active Directory using LDAP on TCP 389 • Access to Active Directory using secure LDAP on TCP port 636 (for example when adding a new user) • Access to Global Catalog server (which may be the same server as the domain controller) using LDAP on 3268 • DCE/RPC with dynamic port allocation. (for example used by the DNS admin GUI) • Direct Host using TCP 445 (or optionally NBT TCP port 139)

Other tools/API’s to administer the Active Directory include

• ADSI (Active Directory Scripting Interface for VB scripts etc. or using adsiedit.exe). ADSI is typically using DNS, Kerberos and LDAP to connect to Active Directory • WMI (Windows Management Instrumentation. It is rather new that the WMI now has a provider for Active Directory. Through this provider, you can read and write to Active Directory through WMI. WMI uses as described elsewhere DCE/RPC with dynamic TCP port allocation. • Support tools, such as: adsiedit.msc, dcdiag.exe, dcacls.exe, dsastat.exe, ldifde.exe, ldp.exe

These tools can be used to administer Active Directory locally or remotely.

7.24.2 Active Directory and NAT

Many of these communication scenarios and administrative tools will NOT work through a firewall with NAT. Even without NAT it can be very challenging to set it up to work correctly through firewalls with the minimal number of ports being opened.

One recommendation in environments with many internal firewalls or address translators could be to have separate domains within each boundary and use SMTP replication between domains. The SMTP replication will work through a firewall, even with NAT (NB! this needs to be verified).

A (naïve) hope could be that vendors like Microsoft will make all applications independent of the IP-addresses and able to work in NAT and firewall environments (with minimal risk involved, I should say). Many vendors perhaps rely on common communication technology to evolve and wait until the communication mechanism, their applications call and rely on, are able to handle this issue. Examples on such new standard technologies include the RSIP and DNS proxy described in this document.

7.25. Mail servers, Exchange and SMTP

In discussing network traffic associated with Exchange, there are six scenarios: (taken directly from Q176466 XGEN: TCP Ports and Microsoft Exchange: In-depth Discussion)

- Communication between POP3 clients and Exchange Server computers. Two conditions exist:

1) Downloading and retrieving messages 2) Sending messages

- Communication between IMAP4 clients and Exchange Server computers. Two conditions exist:

1) Downloading and retrieving messages 2) Sending messages

- Communication between Exchange Server computers and LDAP (Lightweight Directory Access Protocol) clients. - Communication between Exchange Client computers and Exchange Server computers. - Communication between two Exchange Server computers in the same site (intrasite communication).

FocusPM White paper by Claus Jespersen, HP Denmark Page 70 of 70 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

- Communication between two Exchange Server computers in different sites (intersite communication). This communication has two further distinctions: Intersite link uses site connector (RPC). Intersite link is an X.400 connector.

NOTE: The terms "same site" and "different site" are used here in an Exchange infrastructure design context and do not have any bearing on location. Consequently, two Exchange Server computers in the same site could be located in two different places connected via a WAN link with routers and firewalls in between.

TERMINOLOGY: When discussing ports, two terms are often used: "well-known" and "ephemeral." "Well- known" represents ports below the 1024 range that are used regularly and have in most cases a standardized assignment for certain types of network service. "Ephemeral" represents all ports inclusive of and above the 1024 range.

An in-depth discussion regarding issues for each of the six scenarios presented above will follow.

7.25.1 Communication between POP3 clients and Exchange Server computers

Exchange 5.0 supports POP3, a protocol used to retrieve messages from a mail server. In addition to POP3 mail clients such as Internet Mail and News, Windows CE Inbox, and Internet Mail Service for Windows, and clients such as Pegasus and Eudora Pro are often used to send and retrieve messages from the Exchange Server computer. This introduces a new angle to the discussion of the availability of TCP port access.

Downloading and retrieving messages

POP3 client access to messages on an Exchange Server computer is regulated by the authentication method used. There are three such authentication methods. If Basic or Windows NT Challenge/Response authentication (Windows NTLM authentication) is used, downloading and retrieval of messages using a POP3 client requires access to TCP port 110. Exchange Server listens on port 110 for any incoming connection requests from POP3 clients for message download. If the SSL (Secure Sockets Layer) authentication method is used, the Exchange Server computer listens on port 995. Therefore, if you are designing the packet filtering requirements of a network that includes an Exchange installation, keep in mind that the access to either TCP port 110 or TCP port 995 if POP3 is a supported protocol.

Sending messages

When POP3 clients send messages, the Exchange Server computer is communicating with an SMTP (Simple Mail Transfer Protocol) host. This requires access to TCP port 25. The Internet Mail Connector and the Internet Mail Service use TCP port 25 for inbound SMTP messages as defined by RFC-821. For inbound SMTP messages, the Internet Mail Connector and Internet Mail Service monitor port 25 for incoming connections from other SMTP hosts. Microsoft Exchange Server supports POP3 as defined in the RFC- 1734 and RFC- 1957 specifications.

7.25.2 Communication between IMAP4 clients and Exchange Server computers Exchange version 5.5 supports IMAP4, the Internet Message Access Protocol. IMAP4 is a superset of POP3 and therefore supports all its features and some additional ones. An example of an IMAP4 enhancement over POP3 is the ability to search messages for key words while the messages are still on the mail server. Users can then choose which messages to download to their local computer. IMAP4 also allows access to public folders and personal folders.

Downloading and retrieving messages

The ports that IMAP4 clients use when accessing messages on an Exchange Server computer depend on the authentication method in use. With Basic or NTLM authentication and TCP, the IMAP4 server listens on TCP port 143 for any incoming connection requests from IMAP4 clients for message download and retrieval. If SSL authentication is used, however, the port on which the Exchange Server computer listens is TCP port 993. Router and firewall setups should therefore take into consideration the access to TCP port 143 or TCP port 993 when this protocol is a supported feature for messaging.

FocusPM White paper by Claus Jespersen, HP Denmark Page 71 of 71 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Sending messages

As discussed above for POP3 clients sending messages, when IMAP4 clients send messages, the Exchange Server computer is communicating with an SMTP host. This requires access to TCP port 25. The Internet Mail Connector and Internet Mail Service use TCP port 25 for inbound SMTP messages as defined by RFC-821. For inbound SMTP messages, the Internet Mail Connector and Internet Mail Service monitor port 25 for incoming connections from other SMTP hosts. Microsoft Exchange Server supports IMAP4 as defined in the RFC-2060 and RFC- 2061.

7.25.3 Communication between Exchange Server computers and LDAP clients LDAP (Lightweight Directory Access Protocol) is a specification for client access to the Exchange Server directory service to provide address book functionality. It allows the client to connect to the directory and allows information retrieval, addition, and modification. LDAP was introduced in Exchange version 5.0.

For the LDAP client to connect to the Exchange Server computer, the ports that need to be configured on the firewall are based purely on the authentication method in use. With Basic authentication, the Exchange Server computer listens on port 389. For SSL authentication, the port that the Exchange Server computer listens on is 636. Microsoft Exchange Server supports LDAP as defined in RFC-1777.

7.25.4 Communication between Exchange Server computers and NNTP clients The Network News Transport Protocol (NNTP) is widely used to post, distribute, and retrieve USENET messages. Clients can access these newsgroups as Exchange public folders. NNTP clients need to connect to the Exchange Server computer via port 119. The proxy software or firewall should take this into consideration when NNTP is supported. Microsoft Exchange Server supports NNTP as defined in RFC-977.

7.25.5 Communication between Exchange Client computers and Exchange Server3 computers An Exchange Client computer on a LAN or WAN link uses remote procedure call (RPC) to communicate with an Exchange Server computer. The Exchange Server computer, an RPC- based application, uses TCP port 135, also referred to as the location service that helps RPC applications to query for the port number of a service.

The Exchange Server computer monitors port 135 for client connections to the RPC endpoint mapper service. After a client connects to a socket, the Exchange Server computer allocates the client two random ports to use for communication with the directory and the information store. The client does not communicate with other components of the Exchange Server computer.

If security concerns for a network infrastructure require blocking of any ports other than the ones used, the random assignment of ports for communication with the directory and the information store can become a roadblock. In order to avoid this, Exchange Server versions 4.0 and later versions allow you to statically allocate these ports.

For more information on the process of static allocation of ports for the directory and the information store, please see Microsoft Knowledge Base article Q155831 "XADM: Setting TCP/IP Ports for Exchange and Outlook Client Connections Through a Firewall."

At this juncture, for successful communication between client and server, the firewall needs to be configured in order to allow TCP connections to port 135 and all statically allocated ports. If you need to monitor traffic for analysis, these are the ports to monitor.

7.25.6 Communication between two Exchange Server computers in the same site All intrasite communication between Exchange Server computers uses RPC. Consequently, access to TCP port 135 becomes an important variable in the ability of Exchange Server computers to communicate if they are separated by using routers and firewalls.

Communication between two Exchange Server computers within a site is between the two message transfer agents (MTAs) and the two directory services. No other components of the Exchange Server computers communicate directly.

FocusPM White paper by Claus Jespersen, HP Denmark Page 72 of 72 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

As discussed above in client to server communication, an Exchange Server computer monitors port 135 for connections to the RPC endpoint mapper service. When an initiating Exchange Server computer connects to a socket, the receiving Exchange Server computer assigns two random ports to use for communicating with the directory and the MTA.

Already discussed above was the possibility of static allocation of a TCP port for the directory to listen and communicate on a specific port number. With the release of Exchange Server 4.0 Service Pack 4 and all releases of Exchange Server 5.0, a similar adjustment can be made to the MTA. The endpoint mapper will then relay the appropriate port number, so further communication can be achieved by going to the port number specified. For establishing a static allocation of port for the MTA, refer to the latter part of Knowledge Base article Q161931, "XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens." This explains the use of the registry value "TCP/IP port for RPC listens".

Consequently, for successful communication between two servers, the firewall needs to be configured in order to allow TCP connections to port 135 and all statically allocated ports. If you need to monitor traffic for analysis, these are the ports to monitor.

For more information about the ramifications and guidelines for static port assignment of Exchange services, please see the following article in the Microsoft Knowledge Base: Q180795 XADM: Intrasite Directory Replication Fails with Error 1720

7.25.7 Communication between two Exchange Server computers in different sites

Intersite link uses site connector (RPC)

Most of the discussion on intersite communication via site connectors mirrors the situation of intrasite communication between Exchange Server computers. The only difference is that communication between Exchange Server computers installed in two different sites is only via the corresponding message transfer agents (MTAs).

Although you continue to need the services of the RPC locator service and thereby port 135, the only adjustment you may need for static allocation of a port would be for the MTA. Again, refer to Knowledge Base article Q161931, "XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens." This article discusses the use of the registry value "TCP/IP port for RPC listens". This feature is available with Exchange Server Service Pack 4 and all releases of Exchange Server 5.0.

Intersite link is an X.400 connector

If the intersite link is an X.400 connector, then the communication between the two Exchange Server computers continues to be between corresponding MTAs only. However, RPC is not the means of such communication. Communication between the MTAs follows the RFC1006: ISO over TCP/IP. Consequently Exchange Server computers, by default, use TCP port 102 for all such communication between the MTAs. There is no need for TCP port 135 as far the Exchange communication is concerned, because no RPC traffic is involved.

Exchange Server Service Pack 4 and all releases of Exchange Server 5.0 provide the ability to change this default port assignment of port 102. Article Q161931, referred to above, discusses the use of the registry value "RFC1006 Port Number".

In this setting, for successful communication between two servers, the firewall must be configured to allow TCP connections to TCP port 102 or the manually assigned replacement port. If you need to monitor traffic for analysis, these are the ports to monitor.

IMPORTANT: If the port number for RFC1006 is changed from the default value of 102 on one server, it is absolutely essential that all servers communicating via the X.400 connector incorporate this change. All MTAs must use the same port number.

Finally, as you analyze your specific situation, keep in mind that several combinations of the above situations can exist in an Exchange infrastructure.

FocusPM White paper by Claus Jespersen, HP Denmark Page 73 of 73 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.25.8 Protocol summarize

So to summarize, the following protocols are used

• Client/Server Comm. TCP:135 • Exchange Administrator TCP:135 • IMAP TCP:143 • IMAP (SSL) TCP:993 • LDAP TCP:389 • LDAP (SSL) TCP:636 • MTA - X.400 over TCP/IP TCP:102 • POP3 TCP:110 • POP3 (SSL) TCP:995 • RPC TCP:135 • SMTP TCP:25 • NNTP TCP:119 • NNTP (SSL) TCP:563

7.26. Routing and Remote Access Services

This section discusses about routing and remote access services, which is closely related to sections about VPN, so you may want to refer to these sections as well.

RRAS can be installed on a NT Server as a separate download (add-on to NT) whereas it is included in the Windows 2000 products.

RRAS in NT offers

• Packet filtering • PPTP server • Radius Server • Remote Access Server • IP Routing Protocols such as RIP

RRAS in Windows 2000 offers

• Packet filtering per interface • Remote Access Server • Static routes handling • Dial-Up routing to other remote router using normal IP or VPN. • Dynamic routes RIPV2, IGMP Version 2, OSPF • Routing of DHCP relay agent • Network Address Translation (NAT) with features such as DNS proxy • VPN (PPTP, L2TP without encryption, L2TP with IPSEC encryption, IPSEC Tunnels)

Radius Services (called Internet Authorization Server in Windows 2000) is now in Windows 2000 separate outside of RRAS.

Typical connections to RRAS Server include

• PPP requests to Remote Access Server • VPN client requests (PPTP, L2TP or IPSEC (tunnel mode)) • RIP v1 (NT) and RIP v2 (win2k) requests from other routers (RIPv1 uses UDP port 520 and does NOT support NAT. RIPv2 also uses UDP port 520, but not as broadcasts, rather as multicasts.) • OSPF requests from other routers (OSPF uses multicast 224.0.0.5 and 224.0.0.6) • Radius client requests FocusPM White paper by Claus Jespersen, HP Denmark Page 74 of 74 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• DNS requests (to be forwarded by the DNS proxy (see NAT features in RRAS below) • DHCP requests to DHCP relay agent • NT or Windows 2000 authentication requests to establish normal IP connection (See section about logon to get an understanding of the protocols involved) • NT or Windows 20000 authentication requests to establish VPN client->server or server-> connection. (See section about logon to get an understanding of the protocols involved). • IKE (Internet Key Exchange) on UDP 500 to exchange Keys (See IPSEC and VPN sections). • Remote Administrative GUI connections (see below)

Typical connections from RRAS Server include

• DNS requests for local and remote names • DHCP requests to local or remote DHCP server in combination with VPN Server or remote access server • Authentication request to other RRAS Server or domain controller. (See section about logon for protocols used). • PPTP, L2TP or IPSEC connections to other RRAS Server (See other sections about protocols used) • Remote Administrative GUI connections (see below) (may also use Directory lookup of RRAS servers using LDAP)

7.26.1 NAT Features in RRAS

It is new in Windows 2000, that you can configure NAT as part of a normal IP connection (through Dial-Up connections) or as part of a VPN connection setup in RRAS. This is a very nice feature and can be used for various purposes. An example could be if,- you have some private addresses in some subnets within the IP- ranges described in RFC1918 (Private addresses) and you want to have clients in this subnet to connect to public addresses, hiding your own internal private addresses.

It is a bi-directional NAT feature. Outbound as well as inbound connections can be configured. However, you would typically only use this feature to outbound connections for small private networks or stand alone client PC’s connecting to the Internet.

The NAT feature is enabled when setting up a new connection from the Network Dial-Up or from RRAS GUI.

The following table summarizes the features and capabilities of Internet connection sharing and network address translation.

Internet connection sharing (Dial-Up) Network address translation (RRAS) Single check box configuration Manual configuration Single public IP address Multiple public IP addresses Fixed address range for SOHO hosts Configurable address range for SOHO hosts Single SOHO interface Multiple SOHO interfaces

When the RRAS GUI is used, the choices for connections are shown below

FocusPM White paper by Claus Jespersen, HP Denmark Page 75 of 75 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Choosing the Internet Connection Server make you able to set up an Internet connection with the NAT defined (Internet Connection Sharing, ICS). Furthermore the NAT can be set up directly from the RRAS MMC GUI through “IP Routing” -> New Routing Protocol -> Network Address Translation.

The NAT configuration can be changed as shown below

FocusPM White paper by Claus Jespersen, HP Denmark Page 76 of 76 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

The NAT support in RRAS include NAT editors for

• FTP • ICMP • PPTP • NetBIOS over TCP/IP

• H.323 (sound and video for example used by MS NetMeeting) • Direct Play • LDAP-based ILS registration • RPC

These are actually some nice features seen in no Firewall on the market (that I know of). This means for example that you can use a Windows 2000 server as a NAT device at home to separate your private home office LAN and a corporate LAN and still have the most protocols working through the NAT.

According to Q-article Q250603, there are some issues to be aware of, when using the NAT feature as part of the Dial-Up feature ICS (Internet Connection Sharing) (as opposed to the NAT in RRAS)

Internet Connection Sharing Service May Not Function Properly on a Server Running DHCP or DDNS

The information in this article applies to: Microsoft Windows 2000 Advanced Server Microsoft Windows 2000 Datacenter Server Microsoft Windows 2000 Server

SYMPTOMS When you have a server running Dynamic Host Configuration Protocol (DHCP) or Dynamic DNS (DDNS), the Internet Connection Sharing (ICS) service may not function correctly or may cause some services to stop working. In addition, various error messages may be displayed.

CAUSE The ICS service is one implementation of Network Address Translation (NAT) that Windows 2000 uses. The ICS service automatically sets up a mini DHCP scope and a DNS Proxy service to enable clients on the private network to use ICS and get on the Internet.

The DHCP allocator and DNS Proxy services are not configurable in ICS and start as soon as the service is enabled. Because these services bind to the same TCP ports that a DDNS or DHCP server uses, ICS conflicts if these services are running.

FocusPM White paper by Claus Jespersen, HP Denmark Page 77 of 77 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

RESOLUTION To resolve this issue, do not run the ICS service on a DHCP or DDNS server. NAT (which is installed using routing protocols in the Routing and Remote Access Service (RRAS) snap-in) works correctly if you do not enable the DNS Proxy service or the DHCP allocator.

For further explanation of this, see the section about NAT later in this white paper.

7.26.2 VPN support through NAT

Connections from a client to a RRAS Server are typically very difficult to get to work if a NAT device is in between. In general you can’t expect this to work. However there is a twist that you may find useful.

Think of a user, who has a home-office, as shown below Home Office connections to Corporate Office

WINS and DNS Server(s)

Home office Clients

Home Office ISDN/NAT device Dial-UP RRAS /VPN Server

Home Office Windows Server

Domain Controller

The employee has been given the ISDN/NAT device by his IT department in order to be able to work from his home. He wants to have a small LAN for the family besides being able to connect to resources in the corporate office, just as if he was sitting in the office.

The big issue here is that the NAT device will not accept all the normally used NT and Windows 2000 protocols as described in this white paper. The home PC can’t be member of a company and he can’t log on to the corporate account domain …. that is unless he configures a remote dial-up connection utilizing VPN. The NAT features in Windows 2000 (especially in RRAS) won’t help solving the problem as the ISDN/NAT is still there, which does not necessarily include NAT editors as Win2k does.

You can set up a dial-up connection with PPTP or L2TP (L2TP MUST be without encryption) from the client to the corporate VPN server. In this set up you should be able to get some of the functionality to work. All communication from the clients to the corporate network must now be carried out through the corporate VPN server, such as communication to the domain controllers, WINS servers and DNS servers.

There is still the issue of client PC domain membership. Recall, that domain membership communication (communication from the client PC to the domain controller, that the PC is member of) is initialized before logon, and therefore before the VPN tunnel is created. Even without the domain membership, you will be able to logon to the account domain and access remote servers and resources through the VPN connection by using any protocol.

It is a challenge to set this up to work with all the NetBIOS and DNS name resolution and routing working, but it can be done.

FocusPM White paper by Claus Jespersen, HP Denmark Page 78 of 78 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.26.3 Administration

The administration of RRAS can be done through use of the MMC Snap-In. The following ports are used when connecting to a remote RRAS Server

• Kerberos • MSRPC over NBT TCP port 445, SMB over NBT • LDAP queries to lookup all RRAS servers

7.27. Microsoft Proxy Server

The Microsoft Proxy Server offers

• WEB proxy service • Winsocks Proxy service • SOCKS service • Packet filtering with or without RRAS

Mircosoft Proxy Server version 2 (with combined hotfixes ) can be installed on NT or Windows 2000. The services are made as extensions to the WEB API, so it will use TCP port 80 by default. The IIS server is normally not used for normal WEB requests, even though it is possible.

The proxy server is using NetBIOS and depends on WINS or manual NetBIOS name resolution. URL requests from clients are resolved on the Proxy Server and the IP-address of the local DNS resolver is used to resolve them. The clients need to be able to resolve the NetBIOS name or DNS name of the Proxy member servers, depending of the set up. By default WINS/NetBIOS names are used to access the Proxy servers, but you can manually edit files, so that use of DNS or IP-addresses is forced.

The WEB proxy service is the most commonly used service. More Microsoft WEB proxy servers can be used in parallel, or in arrays, as it is called. Each server is a member of the array. The idea of this is that clients through a CARP algorithm and a downloadable Javascript (PAC script) will know which member in the array has the document requested. Each member has its own cache which is different to the cache for the other members.

All communication between WEB clients and Proxy Server is normally done on HTTP TCP port 80. Also the traffic between members (cluster traffic) is done on HTTP port 80. All requests from the browsers are proxies into the HTTP (or HTTPS) protocol. The proxy server takes the request and forwards it by using the native protocol to the destination, such as HTTP or FTP. Whereas WEB clients by default use passive FTP, the proxy server can use both. Its starts by using/trying normal/port based FTP and if it fails, it will try passive FTP to the final destination.

So to summarize the communication used for WEB proxy service is:

• WEB clients make WINS or manual NetBIOS name resolution of Proxy Member names • WEB clients may use DNS to do name resolution of members of Proxy Array. • WEB clients use HTTP or HTTPS to connect to one or more of the members, depending of the URL • Proxy Server members use native protocol to contact final destination • Members in a Proxy Array use HTTP to communicate between members • Proxy Server members communicate with domain controller to authenticate users. • Proxy Server members use DNS and WINS or local NetBIOS name resolution to resolve member hosts, not to resolve client URL’s.

NB! It has been noticed in practice that actually the WEB client, when using CARP may issue a DNS query for remote DNS hosts, even though this should be done by the Proxy Server. It seems that a CARP client need to be able to resolve all destinations DNS names in order to create a local hash algorithm to find out, which Proxy Server member to use. This has been reported to Microsoft and an answer is expected, but not received as this FocusPM White paper by Claus Jespersen, HP Denmark Page 79 of 79 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ point in time (16th January 2000). For companies with internal root name servers, which are not able to resolve external names, this may give a problem. One solution is to force the use of Winsocks proxy client for all clients, so that these DNS requests can be taken by the Winsocks client and in this way be transferred to the Proxy Servers resolving mechanism.

The Proxy Server serving only WEB services is most often used with just one (or two) network cards installed.

The Proxy Winsocks service offers another way of authenticating and securing other services through the Proxy Server than normal WEB requests. This service is sometimes also used as a lightweight firewall box. Some customers have a separate firewall implementation and only use the Winsocks Proxy service to authenticate services based on NT user names and to centralize the requests to the Internet through the Proxy.

Use of Proxy Winsocks service requires Winsocks client software. This software works in parallel with the normal Winsocks 1.1/2.0 implementation on the client. This piece of software will based on the destination IP- address or DNS domain send it directly to the destination or through the Proxy Winsocks service. An understanding of what IP-subnets and DNS domains are to be considered as local, is configured on the Proxy Server and automatically distributed to the clients.

The communication between the Proxy Winsocks clients and the Proxy Winsocks service is done by using UDP port 1745 by default (can be configured). So all protocols, be it TCP or UDP is packed into a UDP package and transferred to the Proxy Server, where it is unpacked and forwarded to the destination host by using the native protocol.

Applications running on a NT client can be configured to be allowed or disallowed through the GUI on the Proxy Server based on the NT user name.

The communication between Winsocks Proxy clients and Winsocks Proxy service include

• All communication is done by using UDP port 1745 for all communication, both for UDP and for TCP client services. • The client may use WINS or DNS to resolve member hosts • Proxy Server will resolve destination hosts by using local DNS resolver. • Proxy Server will resolve member hosts by using local resolver for WINS or DNS.

NB! The communication between Winsocks client and winsocks service is not supported through NAT (I guess). This needs to be verified.

Regarding the use of SOCKS, this service supports standard socks version 4 services, so clients include all clients who have a SOCKS client interface. Using a SOCKS client from a Unix machine or other operating systems does not include support for NT authentication. SOCKS uses TCP port 1080. Only TCP based application can be used with the SOCKS service. All name resolution using SOCKS version 4 must be done by the client, even remote Internet DNS names!!. Again, if the SOCKS client is running on an NT client, you may want to use the Winsocks client to transfer the DNS request to the Proxy server. However if you do have a Winsocks proxy client, there is normally no need for using a SOCKS client as well.

Some implement Microsoft Proxy Server with an internal and external LAN card. This can’t always be recommended in environments where a number of protocols must work through the Proxy Server. The Proxy Server implements a many to one address translation, which imposes difficulties for various protocols.

The CARP protocol includes in itself a high availability solution for WEB clients. However in order to have a high availability solution for Winsocks and SOCKS services, you could deploy Windows Load Balancing Services (see WLBS for further information about WLBS). In this case the proxy arrays would have a common name with a virtual IP-address. WLBS can also be used for WEB requests, IF and ONLY IF the CARP is not being used. If WLBS is used for WEB traffic, it automatically disables the CARP algorithm!!

7.28. Microsoft NetMeeting

Microsoft NetMeeting is included in the Windows operating system on both NT and Windows 2000. The latest version is version 3. NetMeeting is an application that offers data, voice and video conference through the implementation of the standards T.120 and H.323.

FocusPM White paper by Claus Jespersen, HP Denmark Page 80 of 80 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.28.1 Firewall Configuration in general in relation to NetMeeting

Below it is described how Microsoft® Windows® NetMeeting® 3 works with an organization’s existing firewall security. You will learn about NetMeeting requirements for TCP and UDP connections, as well as the IP ports needed in order to establish a NetMeeting connection. It has been taken from the NetMeeting Resource Kit documentation.

FocusPM White paper by Claus Jespersen, HP Denmark Page 81 of 81 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.28.2 Components of a Secured System

A firewall is a set of security mechanisms that an organization implements, both logically and physically, to prevent unsecured access to an internal network. Firewall configurations vary from organization to organization. Most often, the firewall consists of several components, which can include a combination of the following:

• Routers • Proxy servers • Host computers • Gateways • Networks with the appropriate security software Very rarely is a firewall a single component, although a number of newer commercial firewalls attempt to put all of the components into a single computer. The following illustration shows a firewall configuration.

For most organizations, an Internet connection is part of the firewall. The firewall identifies itself to the outside network as a number of Internet Protocol (IP) addresses, or as capable of routing to a number of IP addresses, all associated with Domain Name Service (DNS) entries. The firewall might respond as a host, resulting in a virtual computer, or pass on packets bound for these hosts to assigned computers.

7.28.3 NetMeeting and Firewalls, detailed information

You can configure firewall components in a variety of ways, depending on your organization’s specific security policies and overall operations. While most firewalls are capable of allowing primary (initial) and secondary (subsequent) Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) connections, they might be configured to support only specific connections based on security considerations. For example, some firewalls allow only primary TCP connections, which are considered the most secure and reliable. In order to enable NetMeeting 3 multipoint data conferencing—program sharing, Whiteboard, Chat, file transfer, and directory access—your firewall only needs to pass through primary TCP connections on assigned ports.

NetMeeting audio and video features require secondary TCP and UDP connections on dynamically assigned ports. Therefore, if you establish connections through firewalls that accept only primary TCP connections, you will not be able to use the audio or video features of NetMeeting.

7.28.4 Establishing a NetMeeting Connection with a Firewall

When you use NetMeeting to call other users over the Internet, several IP ports are required to establish the outbound connection. The following table shows the ports, their functions, and the resulting connection.

Port Function Outbound Connection 389 Internet Locator Service TCP (ILS) FocusPM White paper by Claus Jespersen, HP Denmark Page 82 of 82 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

522 User Location Service TCP 1503 T.120 TCP 1720 H.323 call setup TCP 1731 Audio call control TCP Dynamic H.323 call control TCP Dynamic H.323 streaming Real-Time Transfer Protocol (RTP) over UDP

If you use a firewall to connect to the Internet, it must be configured so that the IP ports not are blocked. To establish outbound NetMeeting connections through a firewall, the firewall must be configured to do the following:

• Pass through primary TCP connections on ports 389, 522, 1503, 1720, and 1731. • Pass through secondary TCP and UDP connections on dynamically assigned ports (1024-65535). The H.323 call set-up protocol dynamically negotiates a TCP port for use by the H.323 call control protocol. Also, both the audio call control protocol and the H.323 call set-up protocol dynamically negotiate UDP ports for use by the H.323 streaming protocol, called the Real-Time Transfer Protocol (RTP). In NetMeeting, two UDP ports are determined on each side of the firewall for audio and video streaming, for a total of four ports for inbound and outbound audio and video. These dynamically negotiated ports are selected arbitrarily from all ports that can be assigned dynamically.

NetMeeting directory services require port 389. Microsoft Internet Locator Service (ILS) servers, which support the Lightweight Directory Access Protocol (LDAP) for NetMeeting, also require port 389.

7.28.5 Firewall Limitations

Some firewalls cannot support an arbitrary number of virtual internal IP addresses, or cannot do so dynamically. With these firewalls, you can establish outbound NetMeeting connections from computers inside the firewall to computers outside the firewall, and you can use the audio and video features of NetMeeting. Other people, though, cannot establish inbound connections from outside the firewall to computers inside the firewall. Typically, this restriction is due to limitations in the network implementation of the firewall. Note Some firewalls are capable of accepting only certain protocols and cannot handle TCP connections. For example, if your firewall is a Web proxy server with no generic connection handling mechanism, you will not be able to use NetMeeting through the firewall.

7.28.6 Security and Policy Concerns Some organizations might have security or policy concerns that require them to limit how fully they support NetMeeting in their firewall configuration. These concerns might be based on network capacity planning or low confidence in the firewall technology being used. For example, security concerns might prohibit an organization from accepting any inbound or outbound flow of UDP data through their firewall. Because these UDP connections are required for NetMeeting audio and video features, disabling this function excludes audio and video features in NetMeeting for calls through the firewall. The organization can still use NetMeeting data conferencing features—such as program sharing, file transfer, Whiteboard, and Chat—for calls through the firewall by allowing only TCP connections on ports 522 and 1503.

7.28.7 NetMeeting and NAT Netmeeting is NOT supported through firewalls and NAT’s, unless there is a built-in application proxy for it. Many vendors do include application level proxies for H323.

NB! If only using T120 services (on TCP port 1503), it is my understanding that this can be brought to work even through a NAT not having a proxy for this installed, but this needs to be verified.

FocusPM White paper by Claus Jespersen, HP Denmark Page 83 of 83 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

7.29. Quality Of Service (RSVP, Qos)

RSVP is NOT included in NT, but rather in Windows 2000.

RSVP is positioned in the protocol stack at the transport layer, operating on top of IP (either IPv4 or IPv6). However, unlike other transport protocols, RSVP does not transport application data but acts instead like other Internet control protocols (for example, ICMP,IGMP, routing protocols). RSVP messages are sent hop-by-hop between RSVP-capable routers as raw IP datagrams by using protocol number 46. It is intended that raw IP datagrams should be used between the end systems and the first (or last) hop router. However, this may not always be possible as not all systems can do raw network I/O. Because of this, it is possible to encapsulate RSVP messages within UDP datagrams for end-system communication. UDP-encapsulated RSVP messages are sent to either port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP-enabled router).

An RSVP session, a data flow with a particular destination and transport-layer protocol, is defined by:

Destination Address - the destination IP address for the data packets.This may be either a unicast or a multicast address.

• Protocol ID - the IP protocol ID (for example, UDP or TCP). • Destination Port - a generalized destination port which is used for demultiplexing at a layer above the IP layer. • NAT devices are presented with unique problems when it comes to supporting RSVP.

Two issues are...

1. RSVP message objects may contain IP addresses. The result is that an RSVP-ALG must be able to replace the IP addresses based upon the direction and type of the message. For example, if an external sender was to send an RSVP Path message to an internal receiver, the RSVP session will specify the IP address the external sender believes is the IP address of the internal receiver. However, when the RSVP Path message reaches the NAT device, the RSVP session must be changed to reflect the IP address that is used internally for the receiver. Similar actions must be taken for all message objects that contain IP addresses.

2. RSVP provides the means, the RSVP Integrity object, to guarantee the integrity of RSVP messages. The problem is that because of the first point, a NAT device must be able to change IP addresses within the RSVP messages. However, when this is done, the RSVP Integrity object is no longer valid as the RSVP message has been changed.

7.30. Administrative tools

7.30.1 Computer Management including Event Viewer, PerfMon and Regedit

Computer Management is new in Windows 2000. By right-clicking “My Computer”, manage can be chosen, and the screen shown below is shown

FocusPM White paper by Claus Jespersen, HP Denmark Page 84 of 84 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

This interface can be used to administer local and remote computers running Windows 2000. Actually many of the items can also be used to manage a Windows NT machine, such as and Registry Editor etc.

Under Services and Applications, if expanded, a link to other applications is given, such as

• WMI control • Indexing Services • DNS • Internet Information Services

When chosen, the MMC Snap-In for that specific service is launched and uses the protocols described elsewhere in this document.

Otherwise the protocols used for computer management include

• Requests to DNS to lookup Kerberos and LDAP servers using DNS UDP port 53 • Requests to Kerberos server in order to get tickets to involved servers, using UDP port 88 • Direct host on TCP port 445 • RPC over NBT on TCP port 445 • WMI requests (for WMI and system information) using DCE/RPC • LDAP on TCP port 389 (normal directory access) • MS LDAP TCP port 3268 (search through global directory) • General DCE/RPC, using TCP port 135 initially and dynamic TCP ports >1023 in ongoing communication

It is very difficult to get all this to work through a firewall, and almost impossible to get it to work through a NAT device. Hints on how to make it work are given elsewhere in this document.

FocusPM White paper by Claus Jespersen, HP Denmark Page 85 of 85 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

8. How to handle network address translation

Not all protocols can work through a device (as a firewall) that implements address translation. Network Address Address Translation Translation

Internal Addresses (Unregistered)

IP Address

IP Address IP Address Firewall IP Address IP Address (Registered)

IP Address dynamically distributed IP address allocation

Address Translation Overcomes IP Addressing Limitations and Hides Internal Addresses from the Internet

Several types of address translation exist

• One to many or many to one address translation (PAT standing for Port Address Translation, or IP masquerade or NAPT standing for Network Address Port Translation) • One to one static address translation (static NAT) • Many to many address translation (dynamic pool of IP-addresses, dynamic NAT)

The figure below shows at what level the address translation is done, namely at the network level in the OSI model.

FocusPM White paper by Claus Jespersen, HP Denmark Page 86 of 86 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ NetworkNetwork Address Address Translation Translation - OSI

Applications Applications Presentations Applications Presentations Sessions Presentations Sessions Transport Sessions Transport Network Transport Network Network DataLink DataLink DataLink Physical Physical Physical

DynamicDynamic State State TablesAddress TranslationTables

Some pointers/links for NAT related information are given below (see references later in this document for URL’s)

• Draft-ietf-nat-traditional-03.txt • Draft-ietf-nat-protocol-complications-01.txt • DNS extensions to Network Address Translators (DNS ALG, RFC2694) • Draft-ietf-nat-app-guide-02.txt

Normal network address translation relies on the translation of:

• The IP addresses in the IP header. • The TCP port numbers in the TCP header. • The UDP port numbers in the UDP header.

Any translation beyond these three items requires additional processing and additional software components called NAT editors. A NAT editor makes modifications to the IP packet beyond the translation of the IP address in the IP header, the TCP port in the TCP header, and the UDP port in the UDP header.

For example, HyperText Transfer Protocol (HTTP) traffic on the World Wide Web does not require a NAT editor because all HTTP traffic only requires the translation of the IP address in the IP header and the TCP port in the TCP header.

The following lists two situations where NAT editors are required:

• The IP address, TCP port, or UDP port is stored in the payload. • For example, File Transfer Protocol (FTP) stores the dotted decimal representation of IP addresses in the FTP header for the FTP PORT command. If the NAT does not properly translate the IP address within the FTP header and adjust the data stream, then connectivity problems may occur. • TCP or UDP is not being used to identify the data stream. • For example, Point-to-Point Protocol (PPTP) tunneled data does not use a TCP or UDP header. Instead, a Generic Routing Encapsulation (GRE) header is used and the Tunnel ID stored in the GRE

FocusPM White paper by Claus Jespersen, HP Denmark Page 87 of 87 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

header identifies the data stream. If the NAT does not properly translate the Tunnel ID within the GRE header, then connectivity problems may occur.

Windows 2000 includes built-in NAT editors for the following protocols:

• FTP • ICMP • PPTP • NetBIOS over TCP/IP • Additionally, the NAT routing protocol includes proxy software for the following protocols: • H.323 • Direct Play • LDAP-based ILS registration • RPC

8.1. Microsoft/NetBIOS NAT issues

NATs are used in IP networks for translating addresses from one network to another. For example, if an internal network use one of the non-routable private network IDs from RFC1597, such as 10.0.0.0, you could use a NAT to translate these addresses into a public IP address and route them to the Internet. When a packet comes back to the NAT, it retranslates the address back to the private address of the originating host.

If you send a NetBIOS datagram, as Netlogon does, the NetBIOS header contains the source IP address. The reply to this NetBIOS datagram will be sent directly to the IP address that is found in the NetBIOS header as defined in RFC1002, section 4.4. If the NAT only translates addresses in the IP header, and not in the NetBIOS header, the packet may be sent to the wrong address. In this example, the packet would be sent back to the computer on the 10.0.0.0 network, which is a private address and not routable.

The following NetBIOS headers used by NT 4.0 contain an Owner IP address field which may require translation:

NetBIOS Name Management • Name Registration/Refresh/Release Request • Name Registration/Refresh/Release Response • Positive Name Query Response

NetBIOS Datagram • Datagram Service Header • Directed and Broadcast Datagram • Datagram Error Packet • NetBIOS datagrams are used for the following purposes: • Locating a logon server • Sending a logon request • Performing domain synchronization • Browser host name announcements • Browser workgroup/domain announcements • NetBIOS Master Browser Existence and Election Packets • NET SEND /d: "Message"

NB! It needs to be verified which RPC requests hold the IP-address in the header (RPC includes RPC over TCP 139 as well as DCE/RPC using dynamic port allocation)

NB! It needs to be verified which protocols in Windows 2000 that hold the IP-address as data load.

Components that can do address translation include

FocusPM White paper by Claus Jespersen, HP Denmark Page 88 of 88 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• Axent Eagle firewall • Checkpoint Firewall-1 • Cisco PIX firewall • Cisco IOS NAT extension • Microsoft Proxy Server • Microsoft Windows 2000 Server

Axent Eagle, Microsoft Proxy Server and Microsoft Windows 2000 Server implements PAT by default, which means that many internal IP-addresses are hidden by one external IP-address. Often these kinds of firewalls are often not able to pass through ICMP messages. Axent recently implemented a ping proxy in the firewall, whereas Microsoft Proxy Server needs RRAS running on the same machine in order to be able to send ping requests through.

Some of the firewalls have built-in support for NAT for most used protocols such as

• FTP • SMTP • Telnet

None of these firewalls have support for DCE/RPC other than just allowing the given ports through. No proxy for DCE/RPC has been seen so far. As stated previously, DCE/RPC does normally NOT work through a firewall with NAT enabled.

Many people think, that NAT provides more security. Actually the intention of NAT is not to provide security but primarily to give functionality and connectivity, and secondly to enhance security if possible (for example by hiding internal IP-addresses). You will often see that protocols that try to secure the communication will not work through a NAT device. This is actually designed so. Encrypted communication ensures reliable communication and integrity, which means that you are guaranteed that the data in the secure channel has not been changed. Now if some part of the data load is changed by a NAT device, such as an IP-address, the integrity can no longer be guaranteed.

Therefore NAT should only be used if it is needed. At least internally in companies, one should prioritize to get a global transparent IP-network with no address translation involved.

Vendors of products should accept that NAT is a reality now and in some years to come. Therefore products should be designed with NAT in mind before they are introduced to the market. It is a better solution to have applications not using IP-addresses in the dataload of a given protocol than it is to force firewall vendors to include NAT support for various protocols in the firewalls. In real life it will be a mix of those two solutions.

8.2. Switch-over from Basic(static) NAT to NAPT

In Basic NAT set-up, when private network nodes outnumber global addresses available for mapping (say, a class B private network mapped to a class C global address block), external network access to some of the local nodes is abruptly cut off after the last global address from the address list is used up. This is very inconvenient and constraining. Such an incident can safely be avoided by optionally allowing the Basic NAT router to switch over to NAPT set-up for the last global address in the address list. Doing this will ensure that hosts on private network will have continued, uninterrupted access to the external nodes and services for most applications. Note, however, it could be confusing if some of the applications that used to work with Basic NAT suddenly break due to the switch-over to NAPT.

9. Management through firewalls using VPN (PPTP, L2TP, IPSEC)

VPN can be very useful for making a secure connection

• Between client and server • Between two servers • Between networks

FocusPM White paper by Claus Jespersen, HP Denmark Page 89 of 89 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

This means that if it is necessary to make one or more of the protocols and services described above work through a network part, which is not secure, such as the Internet in order to remote administer and manage Windows machines on a remote network, VPN could be used. The figure below shows the setup ManagementManagement over over the the Internet Internet / / VPN

Remote VPN over the Server(s) Internet

Management Server(s) Server DMZ

Firewall

As described above, various choices exist when talking about VPN in a Microsoft environment. PPTP, L2TP and IPSEC are possible choices for Windows 2000 if Windows 2000 itself is a client or a server in the VPN communication. When talking about network to network VPN connections an obvious choice is also to let the firewall itself be endpoint for VPN connections and simply let Windows machines communicate through the VPN connection by use of normal routing mechanism. If the VPN connection is to be made by a Windows NT or Windows 2000 machine itself either for server – server VPN or for network – network VPN, the servers must be on the external side of a given firewall, because the VPN protocols are NOT always supported in NAT environments.

If the given firewall does not implement NAT, the VPN server could be behind a firewall and “just” open the described protocols through the firewall. However PPTP and IPSEC can’t be used through Microsoft Proxy Server, as it does not allow for IP-protocols other than IP itself – at least not without RRAS installed.

Some firewalls will only allow specific protocols through the firewall by a so called null-tunnel. The null-tunnel is a tunnel between internal and external network cards and can be seen as a VPN connection on the firewall itself in order to allow specific protocols that can’t work through the firewall in any other way technically. Due to security reasons the use of such a feature should be careful examined before used.

NB! Below only the use of PPTP, L2TP and IPSEC is described. Under IPSEC the IPSEC tunnel mode needs more investigation and description….!!

9.1. VPN between client and server / Dial-in profile

In Windows NT 4.0 and Windows 2000, the client to server VPN communication is setup using the Dial-up network wizard. Choose the option “Connect to a private network using the Internet” in order to setup VPN client interface. Dial-up can be used when connecting to remote destinations through modem or through normal LAN.

FocusPM White paper by Claus Jespersen, HP Denmark Page 90 of 90 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Some of the properties for this setup are shown below

When you define a dial-up profile using VPN, you specify what IP-address to connect to. This is the real IP- address of the VPN server. You can also specify whether or not the client can specify a VPN client IP-address to use or if the server should allocate an IP-address from the VPN servers pool.

Note that you can also specify dialup-filters, so that the dialup connection only is initiated through VPN if one of the specified protocols are used.

As an option it is possible to specify that the dialup VPN connection should connect to a dialup modem through PPP, before making the VPN connection.

The server side of the VPN connection can only be configured using RRAS. This is true for Windows NT 4.0 as well as for Windows 2000. The RRAS interface (MMC Snap-In) is shown below

FocusPM White paper by Claus Jespersen, HP Denmark Page 91 of 91 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

The VPN server is configured through RRAS admin by choosing one of the two options

• new demand-dial interface (PPTP, L2TP with and without IPSEC encryption) • new IP-tunnel (IPSEC tunnel)

It the server setup, you specify

• range of IP-addresses that the VPN server can allocate for VPN clients or specify use of DHCP server for this • number of VPN clients on this interface • type of VPN (automatic, PPTP, L2TP) • authentication mechanism

Normally, the (virtual) IP-address of the VPN server is the first address in the IP-address pool specified.

The client -> server VPN connection can be used for normal communication as well as for administrative/management purposes either through the LAN or through PPP dialup. If for example you have a management server on the internal side of a firewall and the companies WEB-server on the DMZ network, you could setup a client->server VPN connection and administer the WEB-server using all kinds of protocols encrypted in the VPN connection in order to make a more secure connection and/or in order to be able to use the given protocols through the firewall at all, depending on the firewall used.

9.2. VPN between Server and Server or between networks

In a VPN server-server or network-network communication, you don’t need to define a dialup-VPN connection first. At least this is true in Windows 2000, whereas you still need to do this in NT 4.0.

When configuring server-server or network-network VPN, you normally want the two VPN servers to have just one IP-address defined, being the endpoints of the VPN connection. This makes setup of routing less difficult.

The IP-address, you connect to is still a valid real IP-address on the network, that can be reached through normal routing, whereas the VPN IP-address can be any address not used in your organization. The addresses used are often sub nets from the private address space. (10.x.x.x etc.)

Normally when setting up VPN you want to use encryption, but not always. PPTP has a built-in support for encryption (Microsoft encryption, 40 bit or 128 bit), whereas L2TP uses IPSEC as encryption mechanism.

All encryption algorithm use NT usernames and passwords as the basis for creating session keys used for encryption. This session key is being changed as often as you define the VPN properties.

If you use server-server VPN , then you want to connect directly from one server to the other, for example by using a network share between the two machines. This does NOT work by default on NT 4.0. A Microsoft support article addresses this issue. Basically, you may need to put in another interface in your PC, if you only got one, or you can create a new virtual IP-address on one adapter and make the VPN connection to this address as opposed to the real IP-address. It is a bit tricky to get working on NT 4.0, but with the right understanding it is possible. Sometimes you will see, that a command like

Net use * \\\sharename /user:testusers does not work. The result will be “network path not found”. In this case you want to make use of the above ideas. Even if the connection succeeds, you need to check (through use of netmon) that all communication is actually done through the VPN channel and not directly between the real IP-addresses.

In Windows 2000 this problem has not been seen and in general VPN works a lot better on Windows 2000 with lots of new features.

A VPN connection can be defined as a dialup connection that is being brought up automatically whenever a packet to the VPN subnets or other subnets defined to go through the tunnel (through the route table). Also it is

FocusPM White paper by Claus Jespersen, HP Denmark Page 92 of 92 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ possible to define the VPN connection to be persistent, so the connection is brought up, when RRAS is started and stays up as long as the RRAS is running.

On a VPN dialup connection, dialup-filters can be specified, so only specific traffic initiates VPN connections

A screen shot of the definition of Dialup-filter is shown below

NB! It is my understanding, that the filters only define which protocols are allowed to open up/initiate the communication. After the dialup, these filters are NOT used anymore. NB! This needs to be verified. Also verify if the filters work differently depending on whether or not the connection is setup as a persistent connection. The filter is applied to traffic before given to the VPN tunnel, so it is not directly a VPN filter as such.

Regarding the set-up of authentication and encryption, this is done through the GUI shown below.

FocusPM White paper by Claus Jespersen, HP Denmark Page 93 of 93 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Normally you want to require secure password and data encryption. However, if the VPN is NOT used for security reasons, but rather for functionality reasons, you may want to disable the use of encryption because encryption makes the connection somewhat slower.

For each VPN interface, it is possible to define network properties. The network settings include settings for DNS for the VPN.

NB!! It needs to be verified how exactly this entry is used. Normally a Windows 2000 has a DNS entry (or more) defined in the normal network settings. These entries are used for all communication when accessing remote components. When VPN is used, the question is, if there is intelligence included in the setup, so one DNS server is used for VPN connections and one for normal LAN connections.

I don’t see how this should work. If a remote server “remotesrv1.domain” is requested, the operating system does not know whether or not this is a connection for the LAN or for the VPN, so how can it determine which DNS resolver to use. My guess is, that the DNS setup of a VPN connection is never used. Perhaps it could be used for reverse lookup ??? but not for forward lookup as it first knows on which interface the packet should be routed after the DNS resolution is done!!! I see a need for having both resolvers being used, but I miss a mechanism and a understanding of when which resolver entry is used!!

Also as shown in the figure above, the choice of VPN type, PPTP, L2TP or automatic can be chosen.

On each RRAS server a number of PPTP and L2TP interfaces can be defined through the “Ports” entry under the given server. In a client -> server VPN setup, a number of PPTP and/or L2TP several ports should be defined (equal to the number of concurrent active connections) whereas only one (or two ??) VPN ports are necessary in a server<->server and network<->network VPN setup.

FocusPM White paper by Claus Jespersen, HP Denmark Page 94 of 94 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

It is also in the network settings (advanced) that the use of IPSEC can be specified. Default is NOT to use IPSEC, but when using L2TP with encryption, the use of IPSEC must be enabled.

When enabling use of IPSEC, an IPSEC policy needs to be specified. Included in Windows 2000 is a tool (MMC Snap-In) secpol.msc. This tool can be used to define an IPSEC security policy for a standalone Windows 2000 machine. The MMC Snap-In gpedit.msc can also be used for this purpose.

A screenshot of the secpol.msc Snap-In is shown below

An IPSEC policy can also be defined and applied on the Active Directory as opposed to only the local machine. This makes it easy to define one policy and easily configure a number of computers to use this policy when communicating. For example a specific IPSEC policy can be defined and applied to all computers in a given Organization Unit. The way to define an Active Directory group policy for IPSEC is to start the Active Directory “Active Directory Users and Computers” tool, which is another MMC Snap-In. Choose an Organization Unit and right-click on the mouse. Through the properties an existing or new IPSEC policy can be used/created and applied to this specific OU with some computers included.

In the definition of IPSEC policies, the authentication mechanism must be chosen. As earlier described, three options are available, as you can see in the screenshot below.

FocusPM White paper by Claus Jespersen, HP Denmark Page 95 of 95 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

When the computers are members of the same domain tree or forest, the default choice Kerberos should be used. In this case, the use of IPSEC is rather easy, as everything works automatically afterwards. The needed keys used for encryption are created automatically by Kerberos based on the hash value for each username/password.

If use of Certificates is specified, a Certificate setup is needed, which is more complex. (see section about Certificate Server).

A shared key would be the choice if an encrypted session between two standalone or workgroup Windows 2000 computers. The key needs to be the same on each machine. If you only have a few, it is easy to manage, but if more computers are involved, it is practically impossible to handle, and shared key would not necessarily be the best choice in this case. The shared key is only used to create the session key which again is changed at given intervals.

In the IPSEC policy, it is also specified whether or not encryption is enforced or just negotiated when communication is initiated. In this way it is possible to define that IPSEC is only used when communicating with specific computers on given subnets.

A screenshot where these filters/filter actions can be defined is shown below.

FocusPM White paper by Claus Jespersen, HP Denmark Page 96 of 96 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

IPSEC connections can be monitored with a Windows 2000 utility, the IP Security Monitor (ipsecmon.msc), which again is a MMC Snap-In. This tool can’t show the encrypted traffic, but rather the status of the IPSEC connections in use. Actually it is not only the IPSEC communication that can be seen, but also the L2TP sessions. See below..

FocusPM White paper by Claus Jespersen, HP Denmark Page 97 of 97 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

One of the big challenges when setting up VPN is to configure routing correct, so everything works when the VPN connections are active as well as when they are not active. At least two issues must be addressed

• definition of default gateway • static or dynamic routes to/from VPN connections

FocusPM White paper by Claus Jespersen, HP Denmark Page 98 of 98 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Regarding the default gateway, then the issue here is that often the VPN connection is configured, in such a way that the default gateway is the VPN connection when active. This is not necessarily good and in some environments this must be disabled, specially when it is necessarily to have the default gateway point at some other router on the local network. It is often recommended to keep the default gateway and not having it pointing towards the VPN, depending on the setup. This change can be done through a registry setting.

When static routing is used, it is recommended to setup static routes using the RRAS GUI as opposed to using the “route add” command. This is because these routes are activated/disabled according to the status of the VPN connection. Furthermore in these static routes, it is possible to specify that the routes are on the VPN interface.

10. How to limit the use of ports through firewall

10.1. NT 4.0 RPC configuration

In NT 4.0 there are several registry settings which control the RPC port restriction functionality. These settings will be used by applications that uses RPC, such as DCOM based applications. All of the named values listed below are located under the HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet registry key (which you must create). Remember, that you only need to do this on the server machine, clients will automatically pick up the right port numbers when they connect to the SCM on the server machine. Note that you must use regedt32.exe to configure these settings-, Regedit.exe does not currently support the REG_MULTI_SZ type required by the Ports named value entry. You must also reboot your machine every time you make changes to any of the following registry settings in order for them to take effect.

Name Type Value Description One or more port Specify one port range per line. Example: ranges. The options Ports REG_MULTI_SZ 3000-4000 below determine the 5141 meaning of this named value. PortsInternetAvailable REG_SZ "Y" (don't include quotes) Always set this to "Y". If this value is set to "Y", then the Ports named value indicates which ports should be used for DCOM applications. If UseInternetPorts REG_SZ "Y" or "N" (don't include quotes) this value is set to "N", then the Ports named value indicates which ports should NOT be used for DCOM applications.

DCOM on NT 4.0 will try to use UDP wherever it can because it tends to scale much better than its connection- oriented counterpart TCP. However, developers occasionally find it necessary to force the system to use TCP because of firewall/security or technical issues. To force DCOM to use TCP only, you can remove all of the entries from the DCOM Protocols named value located under the

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc registry key except for "NCACN_IP_TCP". If you simply want to make TCP DCOM's first protocol choice, move "NCACN_IP_TCP" to the top of the entry list.

FocusPM White paper by Claus Jespersen, HP Denmark Page 99 of 99 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Note that disabling UDP on just the server side and not on the client side will cause a 30-45 second delay when Windows NT or EntireX clients attempt (and fail) to connect over UDP.

NB! Outstanding issues with RPC is: 1) how can allocation of source ports be limited 2) what happens, if the pool for RPC is being exceeded ?, 3) are there any RPC applications that work with NAT enabled through a Firewall ?

10.2. Windows 2000 RPC configuration

In Windows 2000, the default registry entry is

HKLM\SOFTWARE\Microsoft\RPC\ClientProtocol\

• ncacn_http, • ncacn_ip_tcp, • ncacn-nb_tcp, • ncadg_ip_udp

In order to limit the number/range of ports used, you need to include new registry entries as shown below:

HKLM\SOFTWARE\Microsoft\RPC\Internet

Named Value: Ports Type: REG_MULTI_SZ Setting: Range of port. Can be multiple lines such as: 3001-3010

Named Value: PortsInternetAvailable Type: REG_SZ Setting:Y

Named Value: UseInternetPorts Type: REG_SZ Setting: Y

10.3. Force use of TCP

DCE/RPC by default uses TCP in Windows 2000, whereas it must be forced in NT 4.0 where use of UDP is the default choice. To force use of TCP in NT 4.0, remove the registry entry ncadg_ip_udp or be sure that it is listed later than ncadg_ip_tcp in the registry, so that TCP is tried first.

10.4. Application specifics setup

Lots of applications use given UDP and/or TCP ports. Many of these applications have registry entries or can in some other way be configured to use another port as default. However, be careful that no more than one application uses the same destination port as this will create a conflict with the risk that the application, or worst case the whole machine crashes. Microsoft SQL Server and Microsoft Exchange Server are example of applications where the standard ports used can be configured.

10.5. Manually name resolution

It is possible to configure name lookup of a Microsoft client manually, so it doesn’t use WINS or DNS. This is normally only recommended, if you can justify this manual configuration as opposed to automatically name FocusPM White paper by Claus Jespersen, HP Denmark Page 100 of 100 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ resolution. One of the reasons why you want to do this is if you need to setup communication in an environment where WINS and DNS not is wanted, perhaps because of the security involved in using these protocols through a firewall or technical issues involved when getting name resolution to work through an address translator.

In order to prevent use of WINS servers, you must

• disable use of WINS in network control panel (by not specifying any IP-addresses for WINS servers) • make a lmhosts file with entries for the servers, your applications need to access. It is located under \winnt\system32\drivers\etc. The default name is lmhosts.sam. Copy this file to lmhosts and insert the relevant entries. In LMHOSTS, you can also insert the names of PDC’s which will then be preloaded in the NetBIOS cache when booting or reloading the NetBIOS cache.

NT may still use the WINS protocol for specific requests, such as in the logon sequence or when looking for master domain browsers, but it will NOT try to contact a WINS server, when translating names to IP.

If you don’t want to have your client issue DNS queries, these can be turned of by

• not specifying any IP-addresses in the network control panel (and assure that no DNS server IP- address is given by DHCP to the client. • using manually entries in \winnt\system32\drivers\hosts

NT and Windows 2000 has a specific algorithm for looking up names. Often users get confused about when the name is understood as a NetBIOS name that is being looked up by using WINS or by using LMHOSTS as opposed to when the name is being regarded as a DNS name and where the hosts file and DNS server entries are used.

As a rule of thumb

• NetBIOS name lookup is normally used, if the name does not hold “.” and is less than 16 characters long • WINS lookup is used when NetBIOS name lookup is applied and WINS servers are specified in network control panel. • When NetBIOS name lookup is applied, the lmhosts file is normally used before WINS entries. • If NetBIOS name lookup is applied and does not succeed, it may switch to using DNS name lookup algorithm.

• DNS name lookup (including lookup in hosts file) is used if the name holds any dots “.” • DNS name lookup is used, if the name is longer than 15 characters • When DNS name lookup is applied, the hosts-file is normally used before DNS entries • If DNS name lookup is applied and does not succeed, it may fall back to using NetBIOS name lookup. This normally is only the case when DNS name lookup is applied and the host does not include “.” and is no longer than 15 characters.

Note that there is often a difference in how the operating system does name lookup as opposed to a given application with its own name lookup mechanism. Some applications do name lookup by themselves and does not leave it up to the operating system.

10.6. HTTP tunneling (port 80 tunneling)/COM Internet Services (CIS)

Component Object Model (COM) Internet Services (CIS) introduces support for a new Distributed COM (DCOM) transport protocol known as Tunnelling Transmission Control Protocol (TCP) that allows DCOM to operate over TCP port 80. This allows a client and a server to communicate in the presence of most proxy servers and firewalls, thereby enabling a new class of COM-based Internet scenarios. In many Internet situations, the network connectivity between a client and a server is subject to a number of restrictions. For example: A proxy server that filters outbound network traffic may gate the client connection to the Internet. This is often the case for applications running in a corporate environment, but it can also apply to applications run by a user connecting to the Internet through an ISP.

FocusPM White paper by Claus Jespersen, HP Denmark Page 101 of 101 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

A firewall often controls incoming Internet traffic, defining which combinations of network ports, packets, and protocols are accepted to protect the server (or client) network environment. In practice, the net effect of such restrictions is that a client and a server will probably have a very narrow set of protocol and port combinations available to carry out a conversation. Because DCOM dynamically selects network ports in a range (1024 – 65535) on which Internet-to-intranet network traffic is typically not allowed, it is not possible to reliably use the existing DCOM transport protocols over the Internet (although they are perfectly suitable for intranets). Moreover, firewalls are often set up to restrict access to port 135, upon which DCOM depends for a variety of services.

The Tunneling TCP protocol introduces a special handshake at the beginning of each DCOM connection that allows it to pass through most firewalls and proxies. After this handshake, the wire protocol is simply DCOM over TCP. Aside from the caveats listed later in this article, this means: The protocol is transparent to both client and server. Neither the client code nor the server code needs to be modified to use CIS. (Well, the machine needs to have IIS installed to utilize the IIS API with CIS) All of the DCOM over TCP protocol services are available—including DCOM security and lifetime management (that is, "pinging") services.

10.6.1 Limitations of the Tunneling TCP Protocol The Tunneling TCP protocol is subject to the following limitations: It requires that Internet Information Server version 4.0 or higher is installed on the server-side machine hosting CIS-accessible COM objects, since part of CIS functionality is implemented using an ISAPI filter. Because Tunneling TCP consists of non-HTTP traffic after the initial handshake, CIS requires that proxy servers and firewalls permit such traffic over a port opened to HTTP. Note that because of these limitations, in practice, CIS does not support callbacks. This means, for example, that your applications cannot perform notifications using the connection point or advise sink mechanisms. However, if the CIS client can function as a CIS server and is configured as discussed later in this article, nothing prevents the client from receiving DCOM calls—including callbacks.

CIS support is included in Windows NT 4.0 Service Pack 4 and Windows 2000.

In order to enable CIS, you need to add the Tunneling TCP protocol to the DCOM protocol list. You can modify the protocol list by running DCOMCNFG.

FocusPM White paper by Claus Jespersen, HP Denmark Page 102 of 102 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

As the screen shot from Windows 2000 RC3 DCOMCNFG shows, CIS can be set per application. If no specific settings is set for a given application, the defaults is being used. The default protocols in Windows 2000 are shown below

10.7. SOAP Simple Object Access Protocol

A rather new protocol has been proposed by Microsoft to IETF as a draft RFC. The name of the draft is draft- box-http-soap-01.txt and can be found on the Internet and on Microsoft’s web-site.

The aim of this new protocol is to substitute the DCOM/RPC based protocol which is often challenging to get to work in different firewall environments.

SOAP defines an RPC mechanism using XML for client-server interaction across a network by using the following mechanisms:

• HTTP as the base transport • XML documents for encoding of invocation requests and responses

SOAP is somewhat equivalent to the other distributed object protocol IIOP which is often used by JavaBeans and CORBA Objects together with Java RMI (Remote Method Invocation). It seems that there will be two standard based protocols in the near future for distributed objects, i.e. SOAP AND IIOP.

It is the intention to include SOAP in the COM+ specifications and into various other Microsoft architectures as a standard component.

SOAP can be used together with SSL for encryption purposes. Also SOAP is supported when using NAT.

11. Issues with management products when used through firewalls

By now the various protocols used in NT and Windows 2000 have been described. As the topic of this white paper is management, it is also natural to mention some general issues with management products, other than those built into the operating system as administrative tools.

When talking about management, the integration points can be divided into

FocusPM White paper by Claus Jespersen, HP Denmark Page 103 of 103 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• Communication between management GUI and management server (typically MMC Snap-In communication or WEB based communication or other 3.party proprietary GUI communication) • Communication between management server and management agents • Communication between management agents • Communication between management server and other management server • Communication between management server and remote management database

Below some central HP OpenView products (mainly NT/Windows 2000) are described in relation to managing through firewall issues and the communication scenarios described above.

11.1. HP TopTools

HP TopTools is a web-based tool that will help you manage your computer assets, upgrade PC BIOS, manage network devices and HP printers, and keep track of your network resources and performance. Based on industry-standards such as SNMP, DMI, WMI, TCP/IP and HTTP, it will increase your efficiency by providing immediate device status from any location in your environment.

HP TopTools contains elements for device management, discovery, polling and monitoring capabilities through an intuitive browser-based user interface. HP TopTools gathers information from DMI, WMI and SNMP agents installed on each hardware device and displays this information from within Microsoft Internet Explorer or Netscape. Device status can be dynamically obtained by selecting a single device or a group of devices increasing the efficiency of your IT or helpdesk professionals.

HP TopTools includes the following modules:

• HP TopTools for Desktops: HP TopTools for DeskTops enables the System Administrator to remotely manage multiple PCs, for instance power-on remotely, change security settings, or update system software such as BIOS, hardware diagnostics or drivers.

• HP TopTools for Notebooks: HP TopTools for Notebooks is similar to the HP TopTools for Desktops component and provides Desktop Management Interface (DMI) information with instrumentation specifically written for HP OmniBook PCs. HP TopTools for Notebooks supports the same software- based features as HP TopTools for Desktops; however, the hardware components in notebook computers differ from desktop hardware components. Consequently, HP TopTools for Notebooks does not support features that are dependent on hardware and not yet available in notebook computers, such as Wake-on LAN, remote wake-up and hardware monitoring. • HP Intel based Servers (TopTools for Servers): HP TopTools for Servers enables configuration, administration and monitoring of HP NetServers to make system availability and user confidence higher than everThe TopTools Remote Control Card extends the functionality of TopTools for Servers by providing secure access to HP NetServers regardless of system state, even if the NOS is down and even if the power is down.

Administrators can take complete remote control of the server, access the system event log, redirect the console and even power the system on and off. The card can be accessed anytime, anywhere using a web browser over the company network or over a modem.

The TopTools Remote Control Card is included with some NetServer models and optional on most NetServers. HP TopTools for Servers is integrated with HP ManageX, which provides NOS and application management. Manage X/SE is included with every L series NetServer. In combination, these two products help increase server availability. For more information on this integration, visit www.hp.com/go/netserver_mgmt.

• HP Printers (WebJet Admin, TopTools for Printers)

• HP hubs, bridges and routers (TopTools for Hubs & Switches): HP TopTools for Hubs & Switches helps you get your hands around current and future challenges of managing your network. TopTools for Hubs & Switches swiftly and automatically resolves many common network problems saving network administrator's time. HP TopTools for Hubs & Switches helps plan proactively for the future by

FocusPM White paper by Claus Jespersen, HP Denmark Page 104 of 104 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

keeping customers informed on the amount and type of traffic on up to 1,500 segments of your network. HP TopTools for Hubs & Switches also analyses and summarizes information about network traffic patterns in clear and easy-to-follow reports to prepare a justification for network upgrade as the environment grows

TopTools agents can be installed on PC Desktops and Servers, whereas the built-in SNMP agents are used for hubs, bridges, routers and printers.

The TopTools product can be downloaded for free on http://www.hp.com/toptools . Also a value pack can be downloaded. The value pack gives more enterprise like features for TopTools and is not for free.

11.1.1 Communication between management GUI and management server

The GUI to TopTools is local or remote WEB-browser using HTTP. You can enable TopTools to utilize HTTPS (HTTP over SSL). It is rather easy to set up.

11.1.2 Communication between management server and management agents

The communication from Management server to and from agents include

• ICMP (used especially in discovery to various networks components, not only TopTools agents) • SNMP (initialised from management server on UDP port 161) • DMI (using DCE/RPC with dynamic ports allocated, initialised from the server) • DMI events (using DCE/RPC with dynamic ports allocate, initialised from the agent) • WMI (Windows Management Instrumentation) using DCE/RPC with dynamic port allocation • HTTP to poll for availability and status of WEB-servers

11.1.3 Communication between management agents

No communication is used between TopTools agents.

11.1.4 Communication between management server and other management server

• SNMP Traps sent as alarms to Network/System management tools like HP Network Node Manager or IT/Operations or ManageX on UDP port 162 • SMTP as alerting mechanism • Any other alerting mechanism through various other communication protocols. For example when an IT/O agent is installed on the TopTools server, IT/O messages using DCE/RPC can be sent from the TopTools server to the IT/O server. • Synchronisation to/from Network Node Manager on NT and on Unix through the Management integration solutions to TopTools (typically using a specific TCP port above 1023, that can be configured). HP TopTools for OpenView NNM-NT (version 3.1) TopTools for OpenView NNM-UX (version 1.0) TopTools for OpenView NNM-Solaris (version 1.0) TopTools for Tivoli NetView/NT (version 1.0) TopTools for Unicenter TNG/NT (version 2.0) TopTools for Microsoft SMS (version 1.0, SMS versions 2.0 and 2.01) • Web access from browser running on other management server for its clients

When the integration is used for example for Network Node Manager, the discovery on the TopTool server must be disabled, as Network Node Manager will do this.

FocusPM White paper by Claus Jespersen, HP Denmark Page 105 of 105 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

11.1.5 Communication between management server and remote management database

No communication is done to a remote database other than when synchronizing with enterprise solutions, like with Network Node Manager, where synchronisation include update of the database using a single TCP port as described above.

11.1.6 Issues with NAT

As DCE/RPC is used a lot by TopTools for DMI and WMI communication, it is very difficult to get TopTools working through a NAT device between server and agents.

SNMP through firewalls does as a rule-of-thumb not work correctly as many values returned from a remote MIB may hold information about IP-addresses on the external side of the NAT that gives no meaning for the internal TopTools server. However most of the MIB’s used by TopTools does not hold any IP-addresses so you can expect many things to work, given that the DNS name resolution and routing has been set up correctly.

NB! This needs to be verified - that SNMP in TopTools will work correctly.

The SNMP Trap and SMTP alerting can be set up to work through a NAT device. Note that the SNMP Trap version 2 does NOT hold the IP-address of the sender in the Trap packet, but only in the IP-header. Therefore when using NAT, it will be difficult for a management server receiving the trap to find out, where it comes from orginallly. It will look as if the trap came from the NAT device. (this applies, if the NAT translates the source address.

Note that name resolution protocols such as DNS and WINS should also be taken into account in an overall solution, when deploying in firewall environments.

11.2. HP Network Node Manager

HP OpenView Network Node Manager (NNM) delivers solutions that fit your organization’s needs. NNM offers a winning strategy for managing distributed multi-vendor networks and systems, from small workgroups to the entire enterprise. NNM is designed to handle the vast array of technologies, applications, and equipment used to manage the networks of today and the networks of the future.

Network Node Manager optimizes network bandwidth and computer resources. It minimizes bandwidth consumption and maximizes computer operating system resources. Network Node Manager enhances network availability and reliability. By monitoring and controlling the computing environment, it ensures successful network operations.

11.2.1 Communication between management GUI and management server

The management GUI for Network Node Manager is either the Network Node Manager Remote Console or a Remote WEB browser using HTTP or HTTPS requests to the WEB server where Network Node Manager is running.

11.2.2 Communication between management server and management agents

The communication between management server and network components (SNMP agents, HTTP Web Servers etc). includes:

• ICMP requests to various network components, especially routers • SNMP requests (v1 and v2 requests) from management server to agents • SNMP Traps from management agents to management server • HTTP requests on port 80 to discover and monitor web-servers • HTTP requests on port 280 to discover and access administrative server part of the WEB server • Remote access to NT eventlog, registry etc. from Network Node Manager on NT.

FocusPM White paper by Claus Jespersen, HP Denmark Page 106 of 106 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• DMI requests using DCE/RPC from Network Node Manager on NT • Telnet requests to remote telnet server • WMI requests for NNMGR on NT (using DCE/RPC using local NT or Windows 2000 WMI service)

11.2.3 Communication between management agents

No communication is done between SNMP agents.

11.2.4 Communication between management server and other management server Network Node Manager can function as a collection station communicating with other Network Node Managers. The communication between two Network Node Manager servers could be

• SNMP Traps on TCP port 162 (if collection stations is set up, TCP is used rather than UDP port 162) • SNMP Traps on UDP port 161 • SNMP requests from top level management stations to downlevel management station

Also Network Node Manager can communicate with other management servers, such as

• HP ManageX : SNMP Traps can be sent to/from ManageX to/from Network Node Manager. Also Network Node Manager on NT/Windows 2000 can send ManageX messages (UDP 138) to ManageX • HP IT/Operations: IT/O messages can be sent from ManageX to IT/Operations using DCE/RPC and ManageX messages can be sent from IT/O agents on NT to ManageX. • IBM/Tivoli: SNMP Traps can be sent to/from Netview/6000. Also messages can be sent from a Tivoli agent installed on the Network Node Manager server using the Tivoli->agent communication scheme. • Unicenter/TNG: SNMP Traps can be sent to/from Unicenter/TNG. Also messages can be sent from a TNG agent installed on the Network Node Manager server using the TNG communication scheme.

11.2.5 Communication between management server and remote management database

Network Node Manage normally uses a built-in ODBC database or Oracle database located locally on the Network Node Manager station. A collection station can be set up to extract data from the local database to a higher level Network Node Manager management station. The protocol involved when doing this is can any of your own choice as the physical transfer of data needs to be done manually. When Oracle is used, data can be accessed remotely through Oracle SQL*NET.

11.2.6 Issues with NAT

NAT is a big challenge for Network Management tools such as Network Node Manager. SNMP will not always work correctly with NAT involved. By applying some tricks, some parts of SNMP and access to remote MIB’s can be set up to work correctly, but is it not easy. Some NAT’s don’t support pass-through of ICMP, and in this case proxy-arp may need to be set up to make Network Node Manager work through the NAT, depending on the configuration.

SNMP Traps however, can be set up to work correctly in an environment with NAT’s. Under these circumstances it is to recommend that SNMP Traps version 1 is used, as the source IP-address of the Trap is carried in the UDP packet as well as in the IP header. In the NAT, it is only the IP-header that is being translated.

As Network Node Manager is more and more frequently being used to manage environments that have been outsourced, there is a need to make Network Node Manager able to handle duplicated IP’s – such as having 10.* addresses from more devices. This is indirectly related to the NAT issue. HP is also actively working on configurations which makes deployments of Network Node Managers in NAT environments more easy and more documented. (work includes test of SNMP proxies, that translate the data load of SNMP packets according to the address translation being applied).

FocusPM White paper by Claus Jespersen, HP Denmark Page 107 of 107 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Note that name resolution protocols such as DNS and WINS should also be taken into account in an overall solution, when deploying in firewall environments.

11.3. HP ManageX

HP OpenView ManageX 4.21, the newest version of OpenView’s Windows NT system and application management solution, is shipping with continued Windows 2000 management and new support for Microsoft Terminal Server.

With this release, ManageX continues its history of managing Windows 2000 environments from the early stages of the operating system's development. Complete adherence to Microsoft technologies such as COM/DCOM and ActiveX enabled ManageX to manage the first pre-beta versions of Windows 2000 without any code changes. With the 4.21 release, Hewlett-Packard has verified that both the ManageX agents and the console continue to run on the latest Windows 2000 versions.

ManageX 4.21 monitors the health, performance and availability of Windows 2000 systems, earning it Microsoft's "Windows 2000 Ready"1 designation. Providing policy-based management right-out-of-the-box, ManageX 4.21 policies can be deployed to both Windows 2000 and Windows NT 4.0 systems, enabling mixed environment management. In addition, by providing consolidated reporting and analysis, ManageX paves the way for a smooth migration from NT 4.0 to Windows 2000.

ManageX 4.21 also supports Microsoft® Windows NT® Server 4.0, Terminal Server Edition (with Service Pack 4 and later releases) and Terminal Server Services on Windows 2000. ManageX agents and policies can now be directly deployed to Terminal Servers in order to monitor their health, performance and availability.

The ManageX architecture consists of one or more ManageX servers (called ManageX Console’s) and one or more agents. From each console, rules can be configured and deployed to the agents. These rules define the tasks being performed by the intelligent agents on the agents themselves without requiring the Console when operating.

Normally at least one console is defined as destination server for alerts coming from the agents. This server is also typically used as integration point to other management servers, such as Network Node Manager or IT/Operations. ManageX can itself work in a hierarchy so there are more levels of ManageX consoles with each their agents reporting to them. In this set up, lower level Consoles report to higher level Consoles.

11.3.1 Communication between management GUI and management server

A full featured GUI for ManageX is included in each copy of the ManageX Console. The ManageX console is a MMC Snap-In. It supports local administration of remote ManageX agents and as such requires no communication between GUI and ManageX console (which in this case is equal to the management server)

Given the architecture of ManageX, the only GUI communication to the management server (ManageX console) is WEB traffic from remote WEB browsers accessing ManageX reports or events. The WEB traffic is normally HTTP, but can be configured to use HTTPS (secure HTTP, HTTP over SSL).

11.3.2 Communication between management server and management agents

The communication between ManageX console(s) and ManageX agents include

• NBT/SMB communication to install the first smart broker on agent using TCP port 139 (or Direct Host TCP port 445 for Windows 2000). • Optional Authentication (using UDP port 138 and TCP port 139) from ManageX agent to domain controller that the ManageX agent is member of. This is only used, if there is a NT or Windows 2000 trust relation between the Console and the agent(s). • NBT/SMB communication from agents to performance server (often equal to the Console) where performance data is being consolidated using TCP port 139 (or Direct Host TCP port 445 for Windows 2000). If the performance data is being consolidated on a special server, a TCP connection from this

FocusPM White paper by Claus Jespersen, HP Denmark Page 108 of 108 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

server will be set up to the Reporting database on another server for example by using MS SQL and TCP port 1433. Again often you will see that performance data are being transferred directly to the ManageX server depending on the configuration, especially the network throughput. • DCOM DCE/RPC initiated from server to agents to deploy functionality modules and rules. • DCOM DCE/RPC initiated from the agents to the console (or to other server defined to collect performance data) after having transferred performance data being collected on each agent. • WMI from Console to agents using DCE/RPC. • ManageX messages from agents on UDP port 138 as unicasts to the Console or as a broadcasts. • SNMP Traps can be sent from any ManageX agent to either ManageX consoles or other management server using SNMP UDP port 162. • SMTP can be sent directly from the agent, when a given rule applies or threshold is exceeded. The destination for the SMTP connection can be any IP-address and when using SMTP, it normally will NOT be sent to the console.

11.3.3 Communication between management agents

As ManageX agents are based on COM objects and are able to receive WMI and SNMP Traps locally, communication between agents is possible in various ways. One specific thing that you can do is for example to have a rule or script on one agent initiate a remote execution on another ManageX agent. If this is done using the COM object for remote execution, a DCE/RPC based communication will take place between the two agents. To make it short, which protocols are used between agents depend on the set up.

It is important to notice that the default use of ManageX does NOT require communication between the agents.

11.3.4 Communication between management server and other management server

A management console (or a ManageX agent with lights-out policies) would typically be set up to one of the given scenarios

• Forward ManageX messages to higher level ManageX server using unicast UDP port 138 • Send SNMP Traps to Network/System management tools like Network Node Manager or IT/Operations or IBM/Tivoli or CA Unicenter/TNG. • Send ManageX messages from Network Node Manager on NT or from any other management server using for example HTTP through use of Active Server Pages in a WEB page. This interface is often used, when bi-directional communication to/from ManageX is required. • Send SMTP email as alerting to any SMTP server • Send IT/O messages through local IT/O agent to IT/O server by using DCE/RPC. When a local IT/O agent is used, normal IT/O server->communication must also be encountered for. Other agents from various vendors could also be installed and used instead of a IT/O agent for those customers not having OpenView in house. • When publishing data onto a WEB server using HTTP.

It is worth mentioning, that integration packages exist between ManageX and HP TopTools , Network Node Manager and IT/Operations as built-in solutions as part of the products.

11.3.5 Communication between management server and remote management database

ManageX does NOT by default NEED a database. It can be set up to use a database in the following cases

• as datastore for events accessed by Consoles and WEB-browsers. • as datastore for performance data

The communication involved from management server would typically be one of the following

• none, if the database for both datastores is locally • MS SQL communication to a remote MS SQL Server

FocusPM White paper by Claus Jespersen, HP Denmark Page 109 of 109 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

• Oracle SQL*NET using two TCP ports through the ODBC database • Any other communication to a given ODBC compliant database

11.3.6 Issues with NAT

All the protocols used by ManageX are described elsewhere in this document, so you are encouraged to refer to the various descriptions regarding the challenge of getting them to work through a NAT device. In general you can say that the ManageX does NOT hold the IP-addresses as part of the data load and as such should be able to work through firewalls with NAT.

ManageX can for sure be configured to work through firewalls without NAT. The use of DCE/RPC can be set up, so that only a limited amount of ports are used as described under the section “limiting the use of ports”.

Regarding security issues, some customers do NOT want to open the Firewall for UDP port 138 which ManageX uses as the default protocol for messages/alerting. Various techniques can be applied to get around this. (I have a small description of ideas that can be used for this).

Please note that if you have set up ManageX to work through a firewall and followed the white paper available on http://www.openview.hp.com/managex/library or http://www.openview.hp.com/library/papers

Note that name resolution protocols such as DNS and WINS should also be taken into account in an overall solution, when deploying in firewall environments.

FocusPM White paper by Claus Jespersen, HP Denmark Page 110 of 110 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ http://www.openview.hp.com/library (Management through firewalls, white papers and presentations, big zip fil, Claus Jespersen) you may have noticed the two errors in this white paper. First the “Y” in the registry should be put in without the quotes. Secondly the use of REG_MULTI_SZ should only be used for the variable “Ports” and not the others where just REG_SZ should be used.

FocusPM White paper by Claus Jespersen, HP Denmark Page 111 of 111 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

12. References

For more information look at http://www.microsoft.com/management http://wbem.freerange.com http://www.openview.hp.com/library/papers http://www.openview.hp.com/library/papers/paper.asp?docid=18 (Management through firewalls, whitepapers and presentations, big zip fil, Claus Jespersen) http://www.openview.hp.com/docs/91.pdf (Managing your network through firewalls) http://www.openview.hp.com/pdfs/321.pdf (IT/O Firewall configuration) http://www.openview.hp.com/managex http://www.openview.hp.com/managex/library (ManageX, firewall management, zip file) http://www.hp.dk/services&support/UsingWMIasIntegrationPointsept99v13.doc http://www.ovforum.org/tech/techpapers.cfm http://www.microsoft.com/technet/network/vpntwk/vpntwk.htm http://outlook.microsoft.com/windows2000/library/resources/reskit/dpg/default.asp http://people.hp.se/stnor http://www.ncsa.edu/General/CC/kerberos/firewall.html http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-traditional-03.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-app-guide-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-interface-framework-00.txt ftp://ftp.isi.edu/in-notes/rfc2709.txt ftp://ftp.isi.edu/in-notes/rfc2694.txt ftp://ftp.isi.edu/in-notes/rfc2663.txt ftp://ftp.isi.edu/in-notes/rfc2709.txt

FocusPM White paper by Claus Jespersen, HP Denmark Page 112 of 112 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

ICMP Codes ICMP Codes ======

TYPE CODE MEANING ------0 0 ECHO REPLY (ping reply) 3 DESTINATION UNREACHABLE 0 network unreachable 1 host unreachable 2 protocol unreachable 3 port unreachable 4 frag needed 5 source route failed 6 destination network unknown 7 destination host unknown 8 source host isolated 9 destination network administratively prohibited 10 destination host administratively prohibited 11 network unreachable for TOS 12 host unreachable for TOS 13 prohibited by filtering 14 host precedence violation 15 precedence cutoff 4 0 SOURCE QUENCH 5 REDIRECT 0 network 1 host 2 network & TOS 3 host & TOS 8 0 ECHO REQUEST (ping request) 9 0 ROUTER ADVERTISEMENT 10 0 ROUTER SOLICITATION 11 TIME EXCEEDED 0 TTL=0 during transmit 1 TTL=0 during reassembly 12 PARAMETER PROBLEM 13 0 TIMESTAMP REQUEST 14 0 TIMESTAMP REPLY 15 0 INFO REQUEST 16 0 INFO REPLY 17 0 ADDRESS MASK REQUEST 18 0 ADDRESS MASK REPLY

FocusPM White paper by Claus Jespersen, HP Denmark Page 113 of 113 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ

Printout of \winnt\system32\drivers\etc\services from Windows 2000 server RC2

# Copyright (c) 1993-1999 Microsoft Corp. # # This file contains port numbers for well-known services as defined by # RFC 1700 (Assigned Numbers). # #Format: # # / [aliases...] [#] # echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users #Active users systat 11/tcp users #Active users daytime 13/tcp daytime 13/udp qotd 17/tcp quote #Quote of the day qotd 17/udp quote #Quote of the day chargen 19/tcp ttytst source #Character generator chargen 19/udp ttytst source #Character generator ftp-data 20/tcp #FTP, data ftp 21/tcp #FTP. control telnet 23/tcp smtp 25/tcp mail #Simple Mail Transfer Protocol time 37/tcp timserver time 37/udp timserver rlp 39/udp resource #Resource Location Protocol nameserver 42/tcp name #Host Name Server nameserver 42/udp name #Host Name Server nicname 43/tcp whois domain 53/tcp #Domain Name Server domain 53/udp #Domain Name Server bootps 67/udp dhcps #Bootstrap Protocol Server bootpc 68/udp dhcpc #Bootstrap Protocol Client tftp 69/udp #Trivial File Transfer gopher 70/tcp finger 79/tcp http 80/tcp www www-http #World Wide Web kerberos-sec 88/tcp krb5 #Kerberos kerberos-sec 88/udp krb5 #Kerberos hostname 101/tcp hostnames #NIC Host Name Server iso-tsap 102/tcp #ISO-TSAP Class 0 rtelnet 107/tcp #Remote Telnet Service pop2 109/tcp postoffice #Post Office Protocol - Version 2 pop3 110/tcp #Post Office Protocol - Version 3 sunrpc 111/tcp rpcbind portmap #SUN Remote Procedure Call sunrpc 111/udp rpcbind portmap #SUN Remote Procedure Call auth 113/tcp ident tap #Identification Protocol uucp-path 117/tcp nntp 119/tcp usenet #Network News Transfer Protocol ntp 123/udp #Network Time Protocol epmap 135/tcp loc-srv #DCE endpoint resolution epmap 135/udp loc-srv #DCE endpoint resolution netbios-ns 137/tcp nbname #NetBIOS Name Service netbios-ns 137/udp nbname #NetBIOS Name Service netbios-dgm 138/udp nbdatagram #NetBIOS Datagram Service netbios-ssn 139/tcp nbsession #NetBIOS Session Service imap 143/tcp imap4 #Internet Message Access Protocol FocusPM White paper by Claus Jespersen, HP Denmark Page 114 of 114 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ pcmail-srv 158/tcp #PCMail Server snmp 8161/udp snmp # SNMP Research wpaagt.exe service snmptrap 162/udp snmp-trap #SNMP trap print-srv 170/tcp #Network PostScript bgp 179/tcp #Border Gateway Protocol irc 194/tcp #Internet Relay Chat Protocol ipx 213/udp #IPX over IP ldap 389/tcp #Lightweight Directory Access Protocol https 443/tcp MCom https 443/udp MCom microsoft-ds 445/tcp microsoft-ds 445/udp #? kpasswd 464/tcp # Kerberos (v5) #? kpasswd 464/udp # Kerberos (v5) isakmp 500/udp ike #Internet Key Exchange exec 512/tcp #Remote Process Execution biff 512/udp comsat login 513/tcp #Remote Login who 513/udp whod cmd 514/tcp shell syslog 514/udp printer 515/tcp spooler talk 517/udp ntalk 518/udp efs 520/tcp #Extended File Name Server router 520/udp route routed timed 525/udp timeserver tempo 526/tcp newdate courier 530/tcp rpc conference 531/tcp chat netnews 532/tcp readnews netwall 533/udp #For emergency broadcasts uucp 540/tcp uucpd klogin 543/tcp #Kerberos kshell 544/tcp krcmd #Kerberos remote shell new-rwho 550/udp new-who remotefs 556/tcp rfs rfs_server rmonitor 560/udp rmonitord monitor 561/udp ldaps 636/tcp sldap #LDAP over TLS/SSL doom 666/tcp #Doom Id Software doom 666/udp #Doom Id Software kerberos-adm 749/tcp #Kerberos administration kerberos-adm 749/udp #Kerberos administration kpop 1109/tcp #Kerberos POP phone 1167/udp #Conference calling ms-sql-s 1433/tcp #Microsoft-SQL-Server ms-sql-s 1433/udp #Microsoft-SQL-Server ms-sql-m 1434/tcp #Microsoft-SQL-Monitor ms-sql-m 1434/udp #Microsoft-SQL-Monitor wins 1512/tcp #Microsoft Windows Internet Name Service wins 1512/udp #Microsoft Windows Internet Name Service ingreslock 1524/tcp ingres l2tp 1701/udp #Layer Two Tunneling Protocol pptp 1723/tcp #Point-to-point tunnelling protocol radius 1812/udp #RADIUS authentication protocol radacct 1813/udp #RADIUS accounting protocol nfsd 2049/udp nfs #NFS server knetd 2053/tcp #Kerberos de-multiplexor ttcp 5001/tcp #TTCP ttcp 5001/udp #TTCP man 9535/tcp #Remote Man Server

FocusPM White paper by Claus Jespersen, HP Denmark Page 115 of 115 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ ovwdb 9999/tcp # OpenView Object Database Daemon ovtopmd 2532/tcp # OpenView IP Topology Daemon ovuispmd 7777/tcp # OpenView UI Services Daemon pmdmgr 696/udp # OpenView Postmaster Manager ovspmd_req 8887/tcp # OpenView Process Manager ovspmd_mgmt 8886/tcp # OpenView Process Manager ovsessionmgr 2389/tcp # OpenView Web Session Manager ovalarmsrv 2345/tcp # OpenView Alarm Server daemon

Submitted by: Name Position Signature Date Claus Jespersen Solution Architect January 2000 Openview/Internet Specialist, HP Denmark [email protected]

FocusPM White paper by Claus Jespersen, HP Denmark Page 116 of 116 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58